集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
なぜシリコンバレーは復活し、ボストン・ルート128は沈んだか。 2011-03-05 - 未来のいつか/hyoshiokの日記
「現代の二都物語」を読んだ。 米国東海岸ボストン近郊の、ルート128。そのまわりには、70年代ハイテク企業がひしめいていた。ボストンにはMITやハーバート大学がありハイテク産業に人材を供給していた。DECや、DG、ワングなどのミニコンピュータベンダーがそこにはあった。 そのベンダーがなぜ競争力を失って、シリコンバレーに破れるのか。地域としての優位性を保てなかったのか。それについて本書は書いている。 結論から言えば、一社で上から下まですべて作り上げる垂直統合型のビジネスモデル、それが東海岸ボストン・ルート128の企業の典型だった、それが自社の技術に固執するばかりに時代の変化に取り残されて、破れさっていくということである。 シリコンバレーでは、各社は自分の得意なところ以外は積極的に外部から調達する。コンピュータベンダーですら、CPUからなにから何まで外部に依存したりする。水平分業型のビジネスモ
デブサミで『ハッカー中心の企業文化を日本で根付かせる』という講演をしてきた 2011-02-27 - 未来のいつか/hyoshiokの日記
ハッカー中心の企業文化ってなんだなんだ。一体何について話をするんだ。という疑問は自分でも持っていた。ずいぶん大げさなタイトルにしてしまった。後の祭り。発表のずいぶん前からあれやこれや悩んでいたのあるが、今ひとつ構想がまとまらなかった。 その悩みに一つのヒントをくれたのがケンオルセンが亡くなったというニュースだった。自分が新卒として入社したDECという会社はどのような会社だったのか。そして、その会社が自分のエンジニアとしてのキャリアにどのような影響を与えたのか、与えなかったのか、それを軸に自己紹介をしつつ、自分の考えるハッカーセントリックな企業文化とは何かを話してみようと言う風に思い至った。*1 デブサミは2月17日、18日と2日間目黒雅叙園で開催される。わたしのセッションは18日の朝一である。 ハッカーセントリック(Hacker Centric)というフレーズはポールグレアムのエッセイ「Y
レガシーコード改善ガイド読書会 2010-04-03 - 未来のいつか/hyoshiokの日記
先日、会社でレガシーコード改善ガイド読書会を行った。1回しかやっていないので、今後どんな感じになるのか正直わからないが、1回目の振り返りを記してみる。 〆会、テスト勉強会（社内）などで有志を募ったところ、なんやかんやで10数名が名乗りを上げてくれた。どんなペースでやるかとか運営をどうするかとかを相談するために、参加希望者で集まった。週1回（木曜日、19時開始）、担当の章などを決めた。第1章〜第5章までは各自で読んで、読書会への参加の動機などを含めて簡単なポジションペーパーとしてまとめることにした。 わたしが、読書会の世話役として、会議室の確保（空き会議室を見つけて予約しただけ）、開催のアナウンスなどを行った。資料置き場の共有ディレクトリ、社内Wikiなどを立ち上げた。*1 テストがないコードはレガシーコードだ！ 「テストがないコードはレガシーコードだ」という強烈なフレーズが表紙に書いてある
Innovation Sprint 2011 に参加した - 未来のいつか/hyoshiokの日記
Innovation Sprint 2011に参加した。コミュニティによる価値の創造の一旦を垣間見た気がした。http://innovationsprint.com/ みたままに記す。 川口さん(@kawaguti)がスクラムの父ジェフサザーランドと祖父野中さんを呼んでカンファレンスをしたいと考えているというのを聞いたのは勉強会カンファレンス2010の時だったと思う。おお、いいすね。と適当に答えていたと記憶している。平鍋さん、ピークワン代表の前田さんらが動いて野中さんをひっぱりだし、川口さんが、ジェフとコンタクトをとったようだ。*1 平鍋さんと楽天の田澤さんはIPAの非ウォーターフォール研究会（名前？）の縁で、正式（？）には平鍋さんから田澤さんへの依頼が夏頃にあった。すぐに田澤さん経由で、こんな話が来ているんだけどどうよと来たので、やりましょうよとノリで答えた。 わたしに出きることと言えば
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
社内公用語を英語にすること - 未来のいつか/hyoshiokの日記
最近楽天の社内会議を英語でやっているということをおもしろおかしく伝えられているが、中の人として一言ふたこと。http://mainichi.jp/select/biz/news/20100513mog00m300020000c.html まあ、言うまでもないことだけど、日本のGDPが今後全然増えないなかで企業が成長していくとしたら、海外にでなければいけないことは火を見るよりもあきらかなので、外に出て成長するか、外にでないで成長を放棄するか極端に単純化するとそのようなお話になる。いやいや、日本国内でも十分成長余力はあるという立場ももちろんあるが、それ以上に海外の成長が大きかったとしたら、限りある経営資源を有効活用するために、どっちの方に投資するかということである。 日本のサービス業で海外で成功した事例というのはほとんどない。製造業であれば、SONYやトヨタなどいくらでもあるし、かつての日本の
自分にとっての情熱プログラマー - 未来のいつか/hyoshiokの日記
先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
Rubyベストプラクティス - 未来のいつか/hyoshiokの日記
オライリージャパンの高さんより献本をいただく。ありがとうございました。 Rubyベストプラクティスをざっと拝見して、コミュニティが持つ価値観を明示的に言葉にする事の価値を再確認した。コミュニティの価値観というのは、通常はどのようなコミュニティであれ、その構成員によって明示的にしろ暗黙的にしろ共有されるもので、外のものからはなかなか伺いしれない。 そのような価値観は一子相伝で奥義を決して外部に漏らさないというものから、広く世間に流通しているものまで様々なものがある。閉じたコミュニティというのは、その奥義がなかなかコミュニティ構成員の外に伝わらないもので、一方で開いたコミュニティというのは、その逆である。 コミュニティというのは、一人一人の人によって構成されるので、その人が移動することによって、少しずつその奥義が伝承することになるのだが、一子相伝のコミュニティでは、人の出入りというのは極めて限
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか - 未来のいつか/hyoshiokの日記
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
DevLOVEに会った 2010-03-16 - 未来のいつか/hyoshiokの日記
井の頭公園の入り口にある焼き鳥屋でプロジェクトのキックオフをやるのだと、唐突に@papandaが言った。その焼き鳥屋の名前がどーしても出てこない。なんだっけかな〜〜。あまりに気持ちが悪いので@papandaにTwitterで聞いてみたらどうかねという指令をだしたのが、http://twitter.com/papanda/status/10567492313 『急募。井の頭公園にある焼き鳥屋の名前。』 それがDevLOVEとの出会いである。*1 デブサミのお母さん岩切さんがDevLOVEの@papandaは熱いと熱く語るものだから一度勉強会でじっくりお話をしてみたいとかねてから思っていた。 楽天に転職して早いものでもう半年以上たった。楽天の芸風を変えるのだと、勉強会だなんだといろいろ試行錯誤をする日々であった。 勉強会に行く奴は放っといても行くし行かない奴はなにをしても行かない。熱い奴もいれ
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
ソースコードリーディングワークショップ2010に行ってきた。 - 未来のいつか/hyoshiokの日記
ソースコード理解と勉強会というタイトルでお話をした。ソースコードを読むことの意義などを話した後、わたしのしょぼいテクニックを恥ずかしながら披露した。 Sourcecode Reading Workshop2010View more presentations from Hiro Yoshioka. ワークショップは下記にあるようなプログラムになっている。 http://se.naist.jp/events/srw2010.html Javaアプレットのコードがあって、それぞれのパッチをあててよいかというのを判定するというのを実際のコードを読みながら行う。当初、コードを読むというハンズオンには参加するつもりもなかったのだが、2時間ほどぼーとしているのもヒマだし急遽参加することにした。ソースコードをPCにダウンロードしておけばよかったのであるが、ダウンロードしていなかったので紙でソースコードを
学生諸君、おじさんの昔話を聞いてほしい - 未来のいつか/hyoshiokの日記
学生時代のサークルのOB会なるものに参加したせいか、あるいは楽天がACM国際プログラミングコンテスト(ICPC) *1 のスポンサーになったおかげで学生さんとお話しする機会があったせいかは分からないが、ちょっと学生時代のよた話をしてみたい。 本日ICPCの東京大会に参加した学生さんが楽天に会社見学に来て、ランチを一緒に食ったりしたのだが、午前中はGoogleに行ったそうで、Googleでは会社見学時にNDA（機密保持契約）のサインを求められたそうだ。まあ、それはともかく、自分が学生のころの会社訪問ってどんな感じだったかなとか考えた。 学生時代（もう30年くらい前の話）、電子計算機研究会という色気もなにもないサークルに入っていて学園祭のときに機関誌を出版するというのが主な活動だった。当時は、パソコンというものはなくて、計算機と言えば、大学にあるメインフレームを利用していろいろ活動をしていた。
ムーアの法則を理解しているということ（第98回カーネル読書会） - 未来のいつか/hyoshiokの日記
第98回カーネル読書会は、はてなの田中さんによる、はてなでのハードでの性能の引き出し方というお題で思う存分お話をいただいた。 1年半で半導体の集積度が2倍になるというムーアの法則は誰でも聞いたことはあると思うし、IT系の技術者であれば、知っていて当然の「法則」である。問題は知っていることとそれを理解していることというのはまったく別のことである。将棋のコマの動かし方を知っていたとしても名人にはなれない。ムーアの法則を知っていても、それが自分の仕事にどのような意味を持つかということを理解し、実践している人は驚くほど少ない。 田中さんは数少ないムーアの法則を理解し実践している技術者の一人である。 1年半で様々なコストが半分になるとしたら、それを前提にシステムを組むことによって、どのような競争優位性をもたらすのか。それを自社のサービス戦略にどのように組み入れるか、ということをムーアの法則の文脈の上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
