Anne Linux・Windowsをがんばるのだ

2008年09月14日

チェス.将棋 VS コンピュータ

ほんとにコンピュータとゲームをしてる筈もなく、あれはプログラムの設計者と対戦していると思うんですが何か？

翻訳ソフトは、創り作り側のボキャブラリ次第だとおもうんですが何か？

HAL9000や、ナイトライダーのキット、最近だとマトリックスに登場する様なコンピュータがあれば別ですが、まだまだ先のようです。

自動車や船舶の製造、アパレル、観光、どんな業界でも、人が人の為に何かを創造・提供し、またその製造、販売に至るまでのプロセスも本質の部分ではみな共通なはずなんですが、とりえず簡単に参入出来てしまうこの業界は

まー、楽しくやりましょう。

投稿者 Anne : 11:14 | コメント (0)

2008年09月03日

Google Chrome ついに自社ブランドのブラウザ「Google Chrome」を公開へ

ついに自社ブランドのブラウザ「Google Chrome」を公開へ

Googleが自社ブランドのブラウザ「Google Chrome」を近いうちに公開する予定であることが明らかになりました。

従来のタブブラウザとは異なるレイアウトや、ほかのブラウザに採用されている便利な機能に近いものを採用するなどしており、「Internet Explorer」や「Firefox」の対抗馬としてどれだけ存在感を発揮できるかに期待が寄せられます。

抜粋
http://gigazine.net/index.php?/news/comments/20080902_google_chrome/

開発者Blogの日本語訳
http://googlejapan.blogspot.com/2008/09/blog-post.html

投稿者 Anne : 00:50 | コメント (0)

2007年11月16日

IT業界は変わろうとしている

http://itpro.nikkeibp.co.jp/article/MAG/20070413/268207/

聞いた事をそのまま現場へ落とすだけの間の抜けたSEの横行、ちょっと本を読んだ程度のプログラマー、パソコンを使えばなんでもうまくいくと思っている管理者、全てのことが最優先で順番すら付けられない人たち。

ITに夢を見てはだめでちゅよ。

どの業界でも実力が無ければ通用しませんよ。

はやし立てるマスコミにつられて、一攫千金なんてむりです。宝くじのほうがよほど当たる確立がよいと思いますよ。

それらを狙うのも悪くはないですが、本業がしっかりしていないとダメです。

8割は本業に、2割程度で夢に向かってがんばりましょう。

今世間で騒がれている会社は、世界中に何百万・何千万とある会社の中の数社なんですよ。

夢と現実をはっきり区別しましょうね。

投稿者 Anne : 23:52 | コメント (0)

2007年11月15日

国内　トラフィック　試算　集計

総務省は27日、国内のインターネットにおける2006年11月時点のトラフィック（通信量）の実態を公表した。これは、国内大手ISP6社や学界の支援・協力を得て、トラフィックの集計・試算が行われたものとなっている。

　これによると、2006年11月時点のトラフィック総量の試算結果は平均「636.6ギガbps」となり、1年前と比較して1.4倍、2年前と比較して2倍近くの伸びとなっている。また、今後も同様の傾向で増加すると仮定した場合には、2008年頃にはトラフィック規模が1テラbpsを超える勢いになるとしている。

投稿者 Anne : 01:06 | コメント (0)

2007年11月01日

問題にある長方形は・・

問題にある長方形は、中心座標(x,y)とそこから端までの長さ(w,h)を与えると一意に表される。
これを用いると、２つの長方形が重なる条件は、
|Ax-Bx| < (Aw+Bw) かつ |Ay-By| < (Ah+Bh)
と表される。

---------------------

X軸方向については以下の2つの場合です。
leftA > rightB || leftB > rightA

Y軸方向については以下の2つの場合です。
bottomA > topB || bottomB > topA

この4つのうちがどれかが成り立たっていればよいです。
leftA > rightB ||
leftB > rightA ||
bottomA > topB ||
bottomB > topA

問題では重なるときですから、集合の概念から反対になります。
leftA <= rightB &&
leftB <= rightA &&
bottomA <= topB &&
bottomB <= topA

-------------------------------------

投稿者 Anne : 22:04 | コメント (0)

2007年03月14日

楽しんでますか？

楽しんで仕事をしていますか？
楽しんで遊んではいないですよね。

投稿者 Anne : 23:56 | コメント (0)

2007年02月03日

目的・目標・手段

http://jibun.atmarkit.co.jp/lskill01/rensai/kokugo08/kokugo01.html
ココからの転載ですが、

目的　パリを陥落させる ↓ だんだんと具体的行動へと展開
　　　　↓そのために
目標　フランス軍を撃破する
　　　　↓そのために
手段　機甲師団で電撃的に侵攻する

（「目標」と「手段：その1」が似ているように見えるが、「目標」の段階では具体的な手段を語っていないことに注意しよう。「契約内容を確認できる機会を増やす」ためにその1、その2とは別な手段を講じたとしても、「目標」に変更は必要ない）

いつもの仕事のなかで、「目的・目標・手段」を常に考えて行動しているでしょうか？

言われたことを、そのままやっていませんか？

私の身近なところでの話しですが、「業務マニュアルの作成」をしているメンバーがいます。

一生懸命作成している姿をみて関心しているのですが、時折内容を見させてもらうと愕然とする事が多々あります。

現在の業務環境をより良くする・儲かる仕組みを作る（無駄をなくす）・業務内容を全員が把握しやすくする・など色々な意味があって作成しているのだとは思うのですが・・・

沢山あるページの中から1ページだけ抜き出して、そのページに書かれているフロー・文言の意味を質問してみると、答えが返ってこないんです。

何のために作っているのか？と質問してみると「マニュアルを作るためです」と答えがきます・・・

うーん、これってどうなんでしょう。確かに「マニュアル作成」の指示がでているので間違っていない様に思いますが、仕事ですよ。暇つぶしじゃないんですよ。

マニュアル・プログラム・車・家・ゲームなど・・・を作るってことは全て目的ではないって事に気がついていない人があまりにも多すぎます。
（仕事に限ってであり、プライベートな趣味なら口出しはしません。私も趣味でガーデニングなどもやってますが、誰かに認めて欲しいのでは無く、自分の自己満足です。
しかし、たとえ趣味で合っても目的は存在しており、「自己満足する事」が目的で、ガーデニングは目標であり、手段は、バラの挿木を成功させるなどです。）

家を建てても、誰も住んでくれないのであれば、何のために建てたのですか？趣味ならばよいのですが。

物凄い複雑なプログラムを、物凄い時間を費やして作成しても誰も見てくれなければ、何のためにがんばったのですか？趣味ならば良いのですが。

仕事であれば、必ず目的があります。

目的が分からない仕事の指示がきた場合、何も考えずにそのまま行動を起こすと会社のためだけではなく、自分にとっても無駄な時間を過ごしてしまう事になる場合が多いとおもうのですが、いかがなもんでしょう。（簡単な作業ならば別ですが・・）

投稿者 Anne : 19:09 | コメント (0)

2006年11月27日

ソフトウェアの仕様書は料理のレシピに似ている

優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで）２０対１ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。そもそも、就職した段階で詳細仕様書に従ってしかプログラムを書けないような人が、ソフトウェアエンジニアになっても幸せになれるとは思えない。・・・・・・・

ソフトウェアの仕様書は料理のレシピに似ている

これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。・・・・・・・・・・

ソフトウェアの仕様書は料理のレシピに似ている

世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。・・・・・・・・

投稿者 Anne : 22:19 | コメント (0)

2006年07月12日

地域IP網

NTT東西が都道府県単位で用意した、電話局間を結ぶバックボーンネットワークの事。

ISDNやADSL・Bフレッツといった常時接続サービスにおいて、加入者宅までのアクセス回線とインターネットサービスプロバイダの間の中継網に使われる。

地域IP網は収容局同士を接続したIPネットワークで、電話回線網と異なり1本の回線に複数のデータを流すことができるため、回線効率がよく、コストを安く押さえることができるが、伝送速度が保証されないベストエフォート型の運用となっている。

NTT法によって県間通信への進出が規制されているNTT東西地域会社は、都道府県の範囲内でIP網を整備してプロバイダと接続する形態を採用しているため、プロバイダ側からは県単位での接続となり、従来の市内単位のアクセスポイント開設に比べると設備投資が少なくて済むというメリットがある。

投稿者 Anne : 13:01 | コメント (0)

2006年06月07日

How to Make Big Things Happen with Small Teams

http://37signals.com/svn/archives2/2005/03/sxsw_2005_prese.php

Less people, more power
人数が少ないと、より能力を発揮できる

Less money, more value
予算が少なければ、より付加価値がある

Less resources, better use
資産が少ないと、より良い使い方ができる

Less time, better time
時間が少なければ、より充実した時間にできる

投稿者 Anne : 15:32 | コメント (0)

2006年05月27日

GoogleMapAPI

GoogleMapAPIを利用した僕の勤め先の地図です。

ちなみにこんなページもあります。（Googleじゃありっません）

投稿者 Anne : 22:35 | コメント (0)

2006年05月26日

テスト

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

建築屋は鉄を、システム屋はテストを削る
テーマ：テスト

昨年から話題の耐震偽装問題。簡単にいえば、建物に使う鉄筋の量を減らすことで、材料費を安くして儲けようというわけだ。

ソフトウェアの開発プロセスは、時折、建築のプロセスに例えられる。しかし、決定的な違いがある。ソフトウェアには物質的な「材料」がないのだ。だから、材料費を削ろうにも削れないので、安心 ・・・ なんてことは全くない。

ソフトウェアは、ほとんど「人力」で出来ている。削れるものがあるとすれば、人間の作業時間、つまり開発工数なのである。費用面でも、人月（にんげつ）ベースの価格設定をしているような受託開発では、開発工数（期間×人数）が少ないほうが、安くなる。

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

★

もちろん、普通のシステム開発会社が、悪意のある「偽装」をすることはないだろう（と思いたい）。問題は、顧客から無理な納期を設定された場合である。金額面での要求なら、営業的な対応もできる。しかし、開発期間が十分に確保できないにもかかわらず、納期を延ばしてもらえず、要件も削ってもらえない、といった状況は、どうしようもない（※１）。

当然、開発者は、出来ないものは出来ないと主張するだろう。見積精度云々の問題もあろうが、その道のプロが出来ないと言うのだから、出来ないとみなすのが正しい判断だ。しかし、顧客は「なんとかしてくれ」という。そして、商売上の理由だとか会社の力関係だとか、技術者には理解できない暗黒の力が働いて、結局は開発がスタートしてしまうのである。

開発者が、無理な納期を守るために、まずできることは、残業や休日出勤による作業量の確保である。この業界では、徹夜続きでおかしくなってしまった人の話は珍しくない。鉄筋を削る前に自分の命を削るあたり、耐震偽装の連中とは違うのである。

もちろん、開発手法の工夫や技術的な工夫によって、効率化できることもあるだろう。しかし、それにも限界がある。

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

★

もともと出来る見込みのないことが出来るはずはない。やってみたら出来ました、なんて都合のいい話は期待しないほうがよい（※２）。結局、「出来たように見せかける」ための偽装が始まる。

システム開発で削られる「鉄筋」は、「テスト工数」だろう（※３）。結果としてモノが出来る工程ではないため、削りやすいのだ。もちろん、品質を確保する上で、最も重要といってもよい工程のはずなのだが・・・。

ひどいときには、発注者の側から「テスト工数は減らしてもいいから、納期内に納めてくれ」といった要求が出されることすらある。建築業者に「鉄筋を減らしてもいいから、安くしろ」と言うのと全く同じではないか。

品質はどうあれモノが出来ればよい、という考え方が、耐震偽装問題と同じなのである。しかし、こうして納期内に納められたモノは、実は全く「出来ていない」のだ。

品質の悪いシステムを使うことは、システム化をしない場合よりも悪い結果になることも多い。それなら、最初から納期を延ばしておけばよかった、ということになるのである。

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

★

もちろん、開発側の問題で、納期に間に合わなくなることもある。しかし、私の経験からいえば、顧客側の無理なスケジューリングや、無理な仕様変更、要件提示の遅れなどが原因となることのほうが多いように思う。

納品を「する側」と「される側」とでは、どうしても納期というものを受け止める重さが違う。そのことが、スケジュールに対する姿勢の違いに現れるのだろう。

納期が動かせないようなプロジェクトなら、どうしてもっと早く取り組まないのか、と言いたくなることがよくある。開始が１ヶ月早かったら、無事に開発できただろうに、というケースもよくあるのだ。

システム開発を発注しようという人には、「納期厳守」という言葉がどういう意味を持つか、よく考えてもらいたいものである。

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

※１
単純に作業者の数を増やせばよいという問題ではない。１人で100日掛かる仕事が、100人いれば１日でできるか、といえば、そんなことはない。システム開発は「袋貼り」のような単純作業ではないのだから。そんな簡単なことも分からない人は多いのだが・・・（→ 関連記事: 続・プログラマは誰でも同じ？）

※２
この業界は見積の精度が低いので、十分ありうることではある（→ 関連記事: やってみなきゃわからないという現実）。しかし、それを期待すべきではない。

※３
「悪魔に心を売っても納期を守る！ 裏技術 （@IT）」を読めば、システム屋は共感し、そうでない人は驚愕するだろう。これが現実である。

↓このページから引用しました↓
http://ameblo.jp/argv/entry-10008018829.html

投稿者 Anne : 14:50 | コメント (0)