9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC
ローカルで作ったリポジトリをgithubに初めてpushする方法 2013-05-05 - 未来のいつか/hyoshiokの日記
例えば以下のようにローカルにgitで管理していて、ふとgithubあたりで公開したくなったとする。はじめからgithubにレポジトリを持っていた場合は、それを $ git clone して、ローカルでごにょごにょして $ git push すればいいのだけど、その順番が逆の場合。 $ git init $ git add . $ git commit -m "initial commit" ... ここで、あー、githubにpushしたいなーとふと思う。 おもむろにgithubにsign inしてrepositoryをnewする。仮にユーザ名がuser-nameでリポジトリがrepositoryというのを作ったすると、ローカルからのpushは下記のような感じになる。 $ git remote add origin git@github.com:user-name/repository 最
IT産業には民族誌が必要だ 2011-11-08 - 未来のいつか/hyoshiokの日記
先日からContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1 本日は第3章Continuous Integration（継続的インテグレーション）だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。（うひひ） コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。 そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。 Conti
Twitterの書き込みをきっかけに仕事についてあれやこれや考えてみた - 未来のいつか/hyoshiokの日記
先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
達人プログラマーの思考法と学習法 - 未来のいつか/hyoshiokの日記
無理してベストセラーを読む必要はない。自分にあった本を自分にあったペースで読んでいけばいい。GW中に昔（1年くらい前）献本された「リファクタリング・ウェットウェア」を読んだ。 達人プログラマでお馴染みのAndy Huntの著書である。正直言って、この本のタイトルにぐっとこなかったので、本書を1年近く寝かせておいたのであるが（献本いただいた宮川さんすいません）、ふと思いたち、読んだ。面白かった。副題の「達人プログラマーの思考法と学習法」が本書の内容を的確に表現している。 情熱プログラマーを読みながらも感じたことなんだけど、プログラマーとして、どのように学ぶかという問題にはもちろん正解はない。だけど、人間は弱いものなので、そのような正解を求めて本を読む。様々な自己啓発書が本屋にあふれているのがその証拠だ。私自身、そのような自己啓発書の類の書籍にはあまり興味がないので、買うことも読むこともほとん
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
ソースコードリーディングワークショップ2010に行ってきた。 - 未来のいつか/hyoshiokの日記
ソースコード理解と勉強会というタイトルでお話をした。ソースコードを読むことの意義などを話した後、わたしのしょぼいテクニックを恥ずかしながら披露した。 Sourcecode Reading Workshop2010View more presentations from Hiro Yoshioka. ワークショップは下記にあるようなプログラムになっている。 http://se.naist.jp/events/srw2010.html Javaアプレットのコードがあって、それぞれのパッチをあててよいかというのを判定するというのを実際のコードを読みながら行う。当初、コードを読むというハンズオンには参加するつもりもなかったのだが、2時間ほどぼーとしているのもヒマだし急遽参加することにした。ソースコードをPCにダウンロードしておけばよかったのであるが、ダウンロードしていなかったので紙でソースコードを
シリコンバレーで見た自由闊達な議論の場所 - 未来のいつか/hyoshiokの日記
自分が受けたインタビューを自分が解説するという変な企画の第4弾（笑）。スーパーハッカー列伝。吉岡弘隆氏 その１ ソフトウェアの国際化をやっていたころの話をしよう http://d.hatena.ne.jp/hyoshiok/20100113#p1 その２ そろそろUnicodeについて一言いっておくか http://d.hatena.ne.jp/hyoshiok/20090419#p2 その３ そろそろオラクルについて一言いっておくか http://d.hatena.ne.jp/hyoshiok/20100116#p1 会社に依存しないで技術に真面目に向き合う 最近のキーワードは勉強会 吉岡 私が最近、勉強会とか熱に浮かされたように言ってるのは、そういうコミュニティを作りたいからなんですよ。 川井 なるほど。 そういうコミュニティというのは、プロフェッショナルがプロフェッショナルとして評価
急募：プロの経営者 - 未来のいつか/hyoshiokの日記
ogochanが『「天才エンジニア」でIT業界は変わらない 』*1 と吠えている。業界に必要なのはプロの経営者だ。 カーネル読書会なんていう、勉強会だか飲み会だかわかんないへんなものを10年続けているとわたしみたいな盆栽、もとい、凡才でもよくわかる。すげー技術者はいっぱいいる、面白い技術者はいっぱいいる。にもかかわらづ日本にはMicrosoftもOracleもIntelもGoogleもない。そして日本にはBill GatesもLarry ElisonもAndy GroveもEric Schmidtもいない。 いないいないと嘆いてもしょうがないのである。元気のいい技術者を発見して、面白がって、それすげーよと言ったり励ましたり拍手をしたり、そーゆーことをするくらいしか自分にはできない。半径5メートルのなかで自分ができることをできる範囲でやるしかない。 とは言うものの、ここでプロの経営者がいない
わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記
プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 たまたま手元にあった、C実践プログラミング(ISBN4-900900-64-8)という10年くらい前に買った参考書では、450ページのうちデバッガの利用については、4行ほど記述がある。たった4行である。診断用のprintf()を挿入するということは3ページにわたって記述されているのにだ。 流石に21世紀になってprintf()デ
上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記
はてぶとか見ていると、すげー上から目線の人がいて、あああ、こーゆー人達って、何様？とか思ってしまう。あ、俺様かあ、なるほど。 デブサミのコミュニティLTの裏番組で、株式会社はてなの開発戦略*1というのがあって、わたしも司会なんかしていなかったら、聞きにいきたかったセッションなのだけど、それが予想にたがわず、素晴しいものだったということは、皆さんのブログの感想戦などを拝見していると思ったりする。 gitいいよねgitという内容なのか、そうでないかは現場にいなかったので微妙な空気まではわからない。git移行のきっかけが、SVNのリポジトリの崩壊、瓦解、というのがほほえましくもあり、ツッコミどころでもあり。 はてぶのコメントで http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/rx7/20090212/p1 なんかで、エラソーに言っている人がいる
オープンイノベーションとオープンソース 2009-01-03 - 未来のいつか/hyoshiokの日記
オープンイノベーションというのはカリフォルニア大学バークレー校のヘンリー・チェスブロウ教授が提唱した用語である。従来の閉鎖的イノベーションが、企業の研究機関内で研究開発されたのに対し、オープンイノベーションは、社外の知識、研究などを積極的にとりこもうというのが特徴である。垂直統合型研究開発モデルではなく水平分業型研究開発モデルというのが特徴になる。 イノベーションをビジネスにするためにビジネスモデルを必要とするが、オープンイノベーションの場合、ビジネスモデルと対になって議論される。 近年オープンイノベーションというモデルの成功事例としてオープンソースがよくひきあいにだされる。社外にR&Dと価値の源泉を見いだすという意味でオープンソースはオープンイノベーションに他ならない。しかし投資に見合うリターンをどのように確保するかという確固たるビジネスモデルを確立しているとはいいがたい。 Linuxな
世の中の大多数の人は動かない 2008-09-25 - 未来のいつか/hyoshiokの日記
あなたは何をしたのか？ 色々な批判が出てきてるけど、批判以外であなたは何をしたのか教えてほしい。 (ライ麦畑で子供が落ちないように見張るだけの簡単なお仕事に戻ってはどうか？／Yoshioriの日記) http://yoshiori.org/blog/2008/09/post_229.php 一緒にやろうぜと声をかけても世の中の大多数の人は動かない。何か現状に不満があるんだったら一緒に変えようぜと言っても世の中の大多数の人は動かない。ごく少数の人が手を動かさないで批判する。罵倒する。提案者の人格を否定する。 世の中、そーゆーものかもしれない。 だけど、批判するだけじゃなくて実際この場所に来ている200人は、誰に命令されるわけでもなく、自分の意思で、ここに来ている。すごいではないか。素晴しいではないか。それをわたしは奇跡だと言った。あなたたちは意識していないかもしれないけれど、今奇跡を起してい
2006-03-04
http://www.planarity.net/ 丸を動かして線が重ならないようにするゲーム。 どこのコミュニティに行っても（とはいうもののわたしの見聞きして範囲は日本のPostgreSQLとか、Samba-jpとか、MySQLとか、OpenOffice.orgとか先日のMozilla-Japanとか限られた範囲でしかないのだけど）、開発者の数が圧倒的に少ないと言う声を聞く。しかも新規参入がほとんどない。古参ばっかりで新陳代謝がない。 オープンソースのエコシステムが持続可能な形で回っていくためには、OSSそのものを作る人、紹介する人、使う人、サポートする人等々、それぞれがいないとならない。作る人ばっかりでも使う人がいなければ発展しない。適度なバランスがないとね。 ソフトウェアの価値を向上させるのは人だ。開発者であり、エバンジェリストであり、利用者であり、そのコミュニティに参加するすべての
未来のいつか/hyoshiokの日記 - 日記を書くこととオープンソースソフトウェアに関わること
Hardcoded さんからトラックバックをいただいた。 Blog 悲観論にモノ申す http://www.dmtj.net/pm/archives/000040.php 例えばの話、超優れた職業プログラマがいてさ、その人がオープンソース・コミュニティに参加もしくは貢献しないといってそれを責める権利はどこのどいつも持っちゃいないのよ。Blog だって同じことが言えると思わないか？ あ、多分梅田さんの意図を誤解していると思う。 梅田 Blog論2005年バージョン(2) http://d.hatena.ne.jp/umedamochio/20050426/p1 裏切られた期待として、 大組織に属する超一流の技術者や経営者が本気でBlogを書くということも、どうも日本では起こりそうもない。 と悲観している。確かにその印象はある。日本の大企業に属する超一流の誰かが実名でBlogを書くという状況は
無駄なドキュメントは書くな - 未来のいつか/hyoshiokの日記
ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。 ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。 コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
