＠IT 会議室 Indexリンク Windows Server Insider Insider.NET System Insider XML & SOA Linux Square Master of IP Network Java Solution Security & Trust Database Expert RFID＋IC リッチクライアント & 帳票 Server ＆ Storage Coding Edge ＠ITクラブ Cafe VB業務アプリケーション開発研究 ＠IT SpecialPR

2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同

レジデント初期研修用資料 引っ越し前の旧blogです。新しいアドレスは http://medt00lz.s59.xrea.com/wp/ になります ギャングネイルがトラスを広めた 鉄橋や塔を作る三角形、「トラス構造」を木材で再現するのは難しい。 少ない材料で高強度が出せるやりかた。合理的で、見た目もきれいだけれど、 構造材は全て斜め組み。木材でこれをやるときは、材料の両端を複雑に削れないといけない。 トラスを作れる人は少数で、技術者は高価。建築物に「トラス構造」を持ち込むときは、 それを建物の「売り」にしたいときとか、よっぽど象徴的な建築物に使うとか。 市場にはたぶん、「芸術的なトラスを作れる職人」が求められて、 大工さん達はそれに応えて。 木造トラス構造を採用したホールとか、有名な建物はいくつかあるけれど、 「軽くて丈夫」というトラス構造本来の機能からは少し遠くて、ほとんど芸術品。 状

↑タコシエ・オンラインにて絶賛発売中！通販可能！在庫切れの際はご容赦ください。 【関連サイト】 ・純粋なココロ（旧サイト） ・世界のはて（はてなダイアリー別館） ・Twitter@Masao 【そこそこのIT技術者に、コミュニケーション能力は要らない】 ・町場のＳＥに求められる素養の第一は「技術」ではなく「人柄」 ・プロ^2グラマーは社交が8割 共にSEやプログラマといったIT技術者に一番必要な能力は、「人柄」なり「社交」なり、要は「コミュニケーション能力」（以下コミュ力）だよというお話。 でもコレ、違うと思うんですよね。このふたつの記事の前提になっているのは、「『優秀な』IT技術者を目指す人間にとっては」ってことなんじゃないかなぁ*1。 「そこそこの」IT技術者には、コミュ力なんて要りませんよ。まぁ最低限の業務連絡をこなせるくらいのコミュ力は流石に必要だけど、ここに書いてある

こんな単純明快なことが理解できないと言われても，想像できない．理解できる側からするとあまりに当たり前のことなので，これを「才能」と呼ぶのさえおこがましいと思う カレーなる辛口Javaな転職日記 - プログラマーになれる人となれない人 自分が昔から違和感を持っていた事、 「ポインタは難しいか？」 ぶっちゃけると難しくないですよね。 神様なんて信じない僕らのために - ポインタは本当に難しく、プログラマになるのに大事な事なのか？ この辺を読んで･･･ （才能を）持ってる人は持たない人の気持ちが理解できないんだなぁ 多分、悪気とか悪意とかは全然なくって 純粋に持たない人の気持ちが本当に文字通り理解できないんだろうなぁと思った。 個人的には 甘いと言われるかも知れないけど 別にポインタも再帰も 難しいと感じても出来なくても良いと思う。 プログラマになりたくない人を無理矢理プログ

この間あるイベントに参加したら、有名なフリーランス・エンジニアが「サラリーマン・エンジニアの人たち」という言葉を使い上から目線の発言をしていてちょっと反発を感じた。最近、組織に所属していてもいなくても、自由に活動をしているいわゆる「フリーランスな」人に注目が集まっている。よく見ると本当のフリーランスはいなくて、ある組織が「好きにさせてる」だけなのにね。 エンジニアの仕事がArticsticなものだとしても、それは個人のものではなくてチームのものだと思う。その人が言う「サラリーマンな人たち」が、実はソフトウェア業界のクリエイティビティを実質生み出しているのは誰にも否定できない事実。だからお前なめんなよ。っていう単純な反発心じゃないんだよ。 この状況って、結局エンジニアの現状。限界だと思う。能力がある程度高まったんで、サラリーマンやってるより個人契約というか、個人事業主になったり、自由に遊ばせ

SQL データベース操作言語SQLについて、またRDBMSの持つ機能について詳しく解説します。 DB概要、SQL、テーブル操作、データ操作 ... 特集：replication PostgreSQLのレプリケーションシステムを紹介し、それらの機能を比較していきます。 特集：pgbench PostgreSQLのベンチマークテストに用いられるプログラムである pgbench について解説します。 SQL演習問題 各章に用意された演習問題を集めました。

ソフトウェア開発という作業は，（ウォーターフォールやイテレーションなどの単位は抜きにして）設計から実装という流れに沿って行われる。業務的な設計から，最終的にはコンピュータ語に翻訳し，ソフトウェアという成果物を作り出すための「プログラミング」という作業が必ず存在する。 近年，プログラミングを軽視している組織やプロジェクトが非常に目に付くようになった。 プログラミングという作業は，日々の経験と，それによって蓄積されるパターンをどれだけ多く持っているか，が鍵だ。「○○ということをしたければ，△△という記述をすれば良い」という成功パターンを多く持っていれば持っているほど，プログラミングは面白く，しかもスムーズになる。選択肢を多く持っていれば，適切かつ最短なコードを書ける確率が高くなる。最短なコードになればなるほど，その品質やバグの混入率は低くなる。 仕事や比較的規模の大きなOSS開発には，チーム開

COBOL全盛の時代は，１つのメーカによる統一的な「閉じた」アーキテクチャだったために，ロックされたベンダーが提供する技術情報を身に付けるだけで，多くの案件をこなすことができた。それに，COBOLをやったことのある人ならわかると思うが，OSやデータベースなどによって提供されるサービス（トランザクションモニタやロギングなど）は非常に手厚く，しかも個々のプログラムで全く意識する必要はなかった。1プログラマから考えたら，COBOL全盛時代の方が現在よりも，よっぽどEoDの恩恵に預かることができていたと言えるだろう。 しかし，オープン化の波が押し寄せ，異ベンダー，異機種，異プロトコルは当たり前となり，日々システムは複雑になっていく。それに伴って，当然アーキテクチャも複雑になり，システム全体を考えた場合の必要とされる技術的な知識量も増加しているのが現実である。つまり，システムを構築するために組閣され

東京都文京区本郷でとあるCMS開発会社を営む社長のブログ。さっきまで「越後のCMS問屋」だったのですが、会社が新潟に移転したと勘違いされたようなので変えました。 モバイル、ゲーム、フィード、Ajax、Flash、ハイテクグッズあたりのはやりモノが好きです。 最新作「メルルーの秘宝」がドワンゴから提供中 週刊アスキーで「2045年の週刊アスキーをつくる」連載中 昨夜、僕がとても可愛がっていた若者が、とあるベンチャー企業のCTOになることを受諾したのだというメールを受け取った。 「清水さんとUEにはとてもお世話になったのにこんなことになってすみません」 んで、僕としてはどう思ったかというと 「気にすることはない。君は天才だ。天才は他人に迷惑をかけるもので、僕は天才に迷惑をかけられるのが好きだ」 ということ。まあそんなことをメールにして返信した。 それで思った。ああ愛しているのだ

今回、説明する文字操作・数値・日付に関するコーディング規約は、規約違反の箇所が見つかった場合、比較的簡単にコードの修正ができてしまうものばかりです。 簡単にコードの修正ができるという点から疎かにしてしまいがちですが、これらの規約に違反したコードを実装すると次のような問題を引き起こします。

SDAS（エスダス）（注1）は、開発期間短縮を実現し、お客様のビジネスのスピードアップに貢献する為の総合システム開発体系です。 新しい「SDAS」は、「短期間・高品質」のシステム開発を実現するとともに、「オープン性・国際標準」「ライフサイクル全般でのシステム最適化」「エンジニアリングとマネジメントを両輪とするプロジェクト遂行」を特長としています。 これにより、システム開発期間を従来と比べ、概ね半減することが可能となり、ITの観点から、お客様のマーケットの動きを先取りしたビジネス展開を支援していくことで、競争優位確保に貢献します。 システム開発を「要件定義」「設計」「構築」「テスティング」の4フェーズに分け、それぞれのフェーズを最短化する開発手法、標準技術に基づくツール群およびテンプレートを適用することで、トータルの期間短縮を実現します。 注1 SDAS： System Developmen