なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
Linuxに代表されるオープンソースソフトウェア（OSS）は、文字通りソースコードを公開していることが最大の特徴です。ソースコードが企業秘密のベールに覆われている伝統的な商用ソフトウェアでは、ソースコードにアクセスできる開発者とコンパイル済みのバイナリファイルしか利用できないユーザは厳格に区別され、ユーザがソフトウェアに不具合を見つけても、開発者がそれに対応してくれるまでは指をくわえて待つしかありませんでした。 一方、ソースコードが公開されているOSSの世界では、ユーザと開発者がソースコードという同じ土俵の上で互いに切磋琢磨することができます。今回はそのような例として、ソースコードの不具合を見つけて修正した例を紹介しましょう。 今回取りあげるソフトウェアはfile-rollerという GNOME用の書庫ソフトウェアです。 file-rollerとは file-roller とは、GNOME
プログラミングでのコメントについての話題。 コメントだけで一章使って説明してる本は知る限りではこの本のみ (のはず)。 CleanCode Chapter 4:Comments - 予定は未定Blog版 こちらの本『Code Craft 〜エクセレントなコードを書くための実践的技法〜』もコメントだけで一章使って説明している。ちょうどいい機会なので、一部抜粋してまとめてみた。 Code Craft ~エクセレントなコードを書くための実践的技法~ 作者: Pete Goodliffe,後藤正徳,鵜飼文敏,平林俊一,トップスタジオ,まつもとゆきひろ出版社/メーカー: 毎日コミュニケーションズ発売日: 2007/11/29メディア: 単行本（ソフトカバー）購入: 3人 クリック: 216回この商品を含むブログ (83件) を見る どれくらいの数のコメントを書くべきか 量よりも質を重視する。コード自
レビログ (Make a little happier) 13周年+3i年 レビログの半分は管理人の独断と偏見でできています。残りの半分は現在残 希少につき 入荷待ちです。旧称 貧乏だけど心は萌え : 総務省が十数億円の税金の無駄遣い？がんばって、成功させて下さいね 2008年8月23日 Category > 6_日記 > 渋谷式オタク少年 > TAG( ) Comment : 0 (link this page) 総務省が十数億円かけてネット上の殺人予告などを自動検知するソフトを開発へ – GIGAZINE これは、金額的には、ビジネスとして妥当な金額だと思う。 ただ、政府系の開発期間には、もはや、この手の高度な技術を要するハッカークラスのプログラマーはあまり多くは残されておらず、ほとんど、ベンチャーや、外資に吸収されてしまっている昨今の、政府系ITベンダーの技術力を考えると、恐ろしいほ
私は仕事のほとんど全ての時間をコーディングに費やしています。 最近仕事をしていて、そのさらにほとんど全てが、だいたい同じ作業である、と感じるようになりました。 それは何なのか？としばらく考えてみた所、 どうも「適切な抽象を作り出す」という作業であるという気がします。 「適切な抽象を作り出す」という作業は、 「何となく漠然と感じたり居るような気がする存在」に、 名前を与え コード上に存在するようにコードを書き換える 事を意味します。 ここでは短くする為、「何となく漠然と感じたり居たりするような気がする存在」を「何か」、 そしてそこに抽象を与える作業を「何か化」と呼ぶとします。 実際の順番としてはそういう向きだけでは無く、 名前を与えてコード上にそれを存在させてみて始めてそれが「何」なのかが分かる事もあります。 本当の理解には、名前を与えて存在させてみないと辿りつけない事の方が多い。 まず名前
電通、三菱UFJ信託銀行など大手企業が相次ぎ参入を表明する「情報銀行」。ここに挑むベンチャー企業がDataSign（東京・渋谷）だ。同社の太田祐一社長は情報銀行という言葉が生まれる…続き 中部電力が「情報銀行」参入へ 電力データを活用 ［有料会員限定］ 「情報銀行」説明会に２００社 データ流通の枠組み始動
ソフトウェアの部品化という信仰 ソフトウェアの部品化で何回失敗すれば気が済むのだろう。 経済産業省のとある外郭団体の委員をしている方と話をしていたら「我が国のソフトウェア産業を改革するためには、ソフトウェアの部品化を推進しなければならない」と話していた。うーん……ソフトウェアの部品化かぁ……。正直、頭をよぎったのは1980年代後半に国内のソフトウェア部品の集積を目指して立ち上げられたが、失敗した「Σ（シグマ）プロジェクト」だ。 ハードウェアにおいても部品化は生産性向上をもたらさなかった そもそも、ハードウェアにおいても、部品化は必ずしも生産性向上をもたらさなかった。「“標準”の哲学―スタンダード・テクノロジーの三〇〇年 (講談社選書メチエ (235))」によれば、元々、製品の一個一個に使われる部品には互換性が無かったらしい。高い製造技術が無かったため、製品毎にすりあわせで調整して作られた。
「Step数を報告して」と言われると「Step数(笑)ですか」と言いたくなる今日この頃、 みなさん、いかがお過ごしでしょうか。 ところで、Step数って何が悪いのかを説明できますか？ その数字の示すところを知った上で正しく使うには問題ないのですが…。 Step数は規模に対して正の相関関係を持つ まず、Step数と規模にはなんらの関係もないわけではありません。 Step数は確かに規模と正の相関性を持っています。 ただし、誤差があまりに酷いというだけのことです。 Step数という指標の誤差には以下のような原因が考えられます。 コードのフォーマットによる誤差 マルチステートメントなどの記法による誤差 ロジックによる誤差 冗長性による誤差 他にもあると思いますが、挙げ始めるときりがありませんね…。 コードのフォーマットによる誤差 コードのフォーマットによる誤差は for (int i=0; i<1
「誰が書いても同じコード」は大事なことなのかで 語られている話は非常に興味深ものです。 SIerの言うところの「仕様書」というものはなんなのでしょうか。私のblogでも 内部仕様書はロジックを書くものではない で仕様書を話題に挙げたわけですが、仕様書の在り方を、システム開発の分業の在り方を今一度考えてみたいと思います。 「誰が書いても同じコード」になるためには コードとは何でしょうか。プログラミング言語で書かれたアルゴリズムの表記のことです。 プログラムするということはどういうことでしょうか。 ある目的を適える為のアルゴリズムを考え、プログラミング言語でそれを表現する過程を言いいます。 「誰が書いても同じコードになる」ということは、誰もが同じアルゴリズムを採用し、 そして、その表記さえも同じ書式になることです。 書式のブレは瑣末なことです（コード規約の自動チェックツールなどを導入すれば容易
もっとも「ロジック」というのも程度問題なのだけど、 少なくともプログラム言語で記述するレベルでのロジックを書くというものではありません。 いや、特定の企業ではそういう書類を（しかもプログラム前に！）書かせるように強要してきたりするけども。 参考：IEEE830-1998におけるソフトウェア仕様書（内部）の書き方 そもそも業界ではさも当然のように「外部仕様書」とか「内部仕様書」という言葉を使っていたりしますが、 あまりきっちりした定義はありません。上記でも「内部仕様書」という定義ではないわけですし。 各社の文化で独自に解釈されているのが実情ですかね。 ニュアンスとして外部/内部というのはI/O境界面からの外部/内部といった感じ。 他のチーム(別会社だったりする)とかとやり取りするために、この機能は外から見たらこんな感じ、というのが外部仕様で、 中はこう言う風に作るっていうのが内部仕様とされま
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
ソフトウェアの欠陥はなぜ無くならないのか 先日、公衆電話がうるう年を処理できなくてサービス停止というニュースが流れました。 自己診断プログラムに欠陥があり、次の診断日時を設定する際、うるう年を考慮できなかったことがきっかけで、障害が発生したのだそうです。 こういったソフトウェア──機械的・物理的なもの(ハードウェア)以外の部分──の欠陥は、日増しに増えています。 2005年には証券取引所で単純なプログラムミスで半日取引停止になっていますし、同年にウィルス対策ソフトウェアが障害を起こしてパソコンがまともに動かなくなるなどの症状を出しました。 普通に使われてるパソコンに入ってるOSと呼ばれるソフトウェアも、毎月のように欠陥を見つけては修正を配布しています。 さて、こういった問題はなぜ起こるのでしょうか? ちょうど先日、NHKのクローズアップ現代でソフトウエア危機〜誤作動相次ぐハイテク製品〜とい
2007-11-01 14:29 : 平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみた 最近、八角研究所で技術記事を書いているのですが、私が参加した 2006 年度下期未踏ソフトウェア事業（2006 年 11 月 ～ 2007 年 8 月末まで）の体験談を書いてみました。 未踏の体験談を書こうと思った動機について書きます。 私がお世話になった PM は東工大の千葉先生だったのですが、同じ PM 配下でも他の方は凄腕のエンジニアであり、能力的にも住む世界が異なるという感じでした。そういうエンジニアは目立つので、私は未踏のエンジニアというともの凄い凄腕ばかりを思い浮かべてしまうのですが、未踏ソフトウェア創造事業そのものは、適切な提案ができれば平凡なエンジニアにも門戸が開かれています。 というか、普通のエンジニアこそ挑戦すべき制度です。とはいえ、
このテクニカルノートでは、Mac OS Xのさまざまな「隠れた」デバッグ機能、つまり環境変数、環境設定、GDBから呼び出し可能なルーチン、特殊ファイルなどについて説明します。Mac OS X向けの開発をしている場合は、このリストに目を通して、開発作業を楽にしてくれるものを見逃していないか確認してください。 はじめにMac OS Xには、個々のサブシステムの開発とデバッグを支援するために、エンジニアリングチームが追加したデバッグ機能がいくつか含まれています。これらの機能の多くは、リリース後のシステムにも残っており、コードのデバッグに利用できます。このテクニカルノートでは、広く役立つデバッグ機能をいくつか説明します。別の場所で文書化されているデバッグ機能については、機能の簡単な概要と既存ドキュメントへのリンクを記載しています。このテクニカルノートでは、デバッグ機能を網羅的には文書化しておらず、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く