9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC
継続的インテグレーション(CI)と継続的デリバリー(CD)について知りたかったら、闘うプログラマを読め - 未来のいつか/hyoshiokの日記
継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして
SQLを作った人たち - 未来のいつか/hyoshiokの日記
リレーショナルデータベース管理システム(RDBMS)は言うまでもないことだけど、データベース管理の基礎中の基礎だ。NoSQLというRDBMSではないデータベース管理システムが出て来ているがそれもSQLがあってこそのNoSQLだ。 リレーショナルモデルはIBM E.F. Codd博士が提唱した。Edgar F. Codd - Wikipedia Codd博士は後にチューリング賞を受賞している。 http://en.wikipedia.org/wiki/File:Edgar_F_Codd.jpg そのデーターモデルを利用したデータベース管理システムのプロトタイプがSystem Rだ。IBM System R - Wikipedia 1974年ごろ発表された。 その成果の一つがSQLだ。誰でも使っているSQLはSystem Rの論文が発祥の地である。そしてその論文を読んでRDBMSを作った男がL
ハッカーズ大辞典の参考文献 - 未来のいつか/hyoshiokの日記
ハッカーズ大辞典にはハッカーマインドを理解する上で役に立つ本を紹介している。邦訳があるものを調べてみた。 こーやってリストを眺めてみると未読が多い。日本語訳が出ているのが12/14と多数なので、日本語環境と言うのはずいぶん整っているのだなあと思った。絶版になっているものなどは図書館かなんかで探してみてほしい。 カーリル | 日本最大の図書館蔵書検索サイト ハッカーズ大辞典（英語版）、参考文献 ハッカーズ大辞典 (Ascii books) Godel, Escher, Bach ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版 Illuminates! ピラミッドからのぞく目〈上〉―イルミナティ〈1〉 (集英社文庫) ピラミッドからのぞく目 下 (2) (集英社文庫 シ 14-2 イルミナティ 1) The Hitchhiker's Guide to the Galaxy 銀
ハッカーズ - 未来のいつか/hyoshiokの日記
ハッカーとは何者かにかんする定番のリンクなど。 How To Become A Hacker(Eric Steven Raymond による) ハッカーになろう(山形浩生氏他による日本語訳) Great Hackers (Paul Grahamによる) 素晴らしきハッカー(川合史郎氏による日本語訳) How to become a hacker Eric Raymondのハッカーになろうは、 この世界は解決を待っている魅力的な問題でいっぱいだ 同じ問題を二度解くような無駄はいやだ 退屈と単純作業は悪 自由は善 心構えは技能の代用にはならない という基本的な考え方、心構えから始まる。 そして基本的な技能として プログラミングを身につけること。 オープンソース UNIX 類のひとつを入手し、使いかたと動かしかたをおぼえること。 World Wide Web の使い方を学び、HTML を書くこと
ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記
ソフトウェア開発におけるブルックスの法則とは何か。 http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】というエッセーを執筆した。 人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。 初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40
英語で学ぶ方法、英語の教科書を読む - 未来のいつか/hyoshiokの日記
ソフトウェア技術の定番の教科書は英語で書かれている。世界で最初に日本語で書かれることはまずない。 そこで、英語の定番の教科書を読書会するのをお勧めする。英語の本を一人で読むのは最初はちょっと敷居が高くて難しく感じる。読書会ならば少しずつ読めるし、理解を確認できるし、ちょっと分からないことがあっても参加者に聞くことができる。 何人か仲間を募って、定期的に集まって、章ごとに担当を決め、発表するという定番の方式でもいいし、本の感想を皆で言い合うという緩い形式でもいい。 参加者には、その技術についての共通の理解、語彙が出来るので、仕事にでも応用できる。 英語の本を英語で要約するのは意外と難しくない。章は節からなっていて、節をつなげると章の主張になる。節はさらに小節になっているので、小節をつなげると節になる。小節は段落からできているので、それぞれの段落で何を主張しているかを理解できれば、小節、節、章
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
そろそろオラクルについて一言いっておくか - 未来のいつか/hyoshiokの日記
自分が受けたインタビューを自分が解説するという変な企画の第3弾（笑）。スーパーハッカー列伝。吉岡弘隆氏 その１ ソフトウェアの国際化をやっていたころの話をしよう http://d.hatena.ne.jp/hyoshiok/20100113#p1 その２ そろそろUnicodeについて一言いっておくか http://d.hatena.ne.jp/hyoshiok/20090419#p2 イノベーションのジレンマによって駆逐されたDECという会社 川井 そんな歴史があったんですね。「オラクル」さんに移られたのは「DEC」さんの終焉に伴ってていうのがあるんですか？ 吉岡 ありますね。1993年ぐらいから「DEC」が大赤字を出してる年なんですよね。 それで日本の「DEC」もどんどんシュリンクするという方向もあって、希望退職制度かなんかで200人ぐらい募集したんですよ。 そうするとやっぱり同僚がど
不格好経営 チームDeNAの挑戦 南場智子。読了。 - 未来のいつか/hyoshiokの日記
不格好経営―チームDeNAの挑戦を読んだ。 1999年秋、当時のオフィスにて（17ページ） 彼女のキャリアはよく知られている。マッキンゼーでキャリアを積みパートナーになるが、インターネットベンチャーのDeNAを創業し社長になる。そして夫の看病のため社長を退任し現在にいたる。そして本書は、彼女のビジネスに対する考え、DeNAの原点を余すことなく記している。 コンサルタントとして順風満帆だった著書がなぜか起業し、それまでのキャリアが張り子の虎だったことを学ぶ。とんでもない失敗を繰り返し、その度に学んでいく。失敗を成長の糧にしていく過程がこれでもかこれでもかと記されている。 インターネットのオークションサイトを作るというのが創業時のビジネスモデルだ。そして、詳細な仕様書を作りサイト構築を外注する。さすがコンサルあがり、やることにそつがない。システム開発を発注する。そして、「開発が完了したはずのそ
学習コストってなんだろうな。 - 未来のいつか/hyoshiokの日記
http://d.hatena.ne.jp/hyoshiok/20140205/p1 集中型バージョン管理システムと分散型バージョン管理システムってでいろいろコメントをいただく。ありがとうございます。 結局、学習コストの話になる。何事もなれですね、そーですね。では、さすがに何を議論しているかわからなくなる。 前提として、ソフトウェア製品とかサービス開発の現場のエンジニアの素養としてのVCS利用スキルをどう身につけるかということに限定してみたい。プロのプログラマの必須スキルということを考えている。 サンデープログラマが趣味でプログラムを作っているとかではなく、職業としてソフトウェア製品とかサービスを開発する人のことだ。 そのような人を養成する授業を大学が用意するとしたらどのようなカリキュラムになりうるのか？ ソフトウェア開発の現場の経験がないけど、プログラミング経験くらいはある。エディタは使
集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
パターンによるソフトウェア構成管理 - 未来のいつか/hyoshiokの日記
パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。 16個のパターンを紹介している。 Pattern Name Summary Mainline マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。 Active Development Line Active Development Lineを作ることによって急激に成長するコードラインを安定化する Private Workspace Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする Repository 必要なものを全て持っているRepositoryを設定する Private System Build Repositoryにコミットする前にPriva
gitって難しいのかなー - 未来のいつか/hyoshiokの日記
いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください） 前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。 それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもい
Heroku meetup でLTした。 - 未来のいつか/hyoshiokの日記
http://herokujp.doorkeeper.jp/events/8004 ネタは産業技術大学院大学で開催したスクラムによるWebアプリケーション開発講座のお話。 http://aiit.ac.jp/enpit/ http://aiit.ac.jp/enpit/program.html 事前学習（座学）、夏期集中講座（チーム編成など）、そして分散PBL(Project Based Learning)で実際にWebアプリケーションを構築した。 スクラムをしつつ実際にサービスをチームで構築するので、モダンな開発手法を試していろいろな知識、スキルを身につけるとこができる。 毎週、土曜日に全チームが集まって、その週に開発したものをデモをする。(Demo or Die)。 クラウド(Heroku)にサービスをデプロイするので、誰でもその週に作ったものを確認できる。最初はデプロイがうまくいかな
ローカルで作ったリポジトリを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 最
Macの電源アダプターのしまい方 2012-05-27 - 未来のいつか/hyoshiokの日記
電源アダプターですね。コードはじゃまなので、ぐるぐる本体に巻くとこんな感じです。 不思議な羽みたいなのがついています。ぱかっと開ける。 そこにコードをぐるぐるまけば、ちょっとスッキリ。 なるほどー、こーなっていたのか。先週の金曜日に知りました。アップル製品は奥が深いなーー。
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MOOC - Massive Open Online Courses - 未来のいつか/hyoshiokの日記