9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC
人生100年時代の働き方についてエフスタ!!TOKYOというところでお話をした #efsta56 - 未来のいつか/hyoshiokの日記
福島という地元で働くか、東京で働くか、ざっくり言ってそんなようなお題の元、議論するというのが今回の趣旨と理解した。そこになぜか呼ばれてお話をすることになった。 それはともかく、自分は東京出身なので、地元で働くというのは東京で働くことになる。地元ではない場所という意味でいうと、30代の頃シリコンバレーに行って働いていたので、その時の経験をもとに地元とどこかという軸でお話をすることにした。 エフスタというのは福島の地域ITコミュニティだ。 福島のITコミュニティ「エフスタ!!」は ITっておもしれえんだよ！と感じてもらい、ITで地方を面白くするミッションを目的とする市民活動（コミュニティ）です。 みんなで地方からITの未来を変えていきましょう！ HP http://efsta.com Facebookにて情報発信中！ https://www.facebook.com/efsta.it エフスタ
自分の業務以外のシャドーワーク - 未来のいつか/hyoshiokの日記
サイボーズ式の小崎さんのインタビューが面白い。*1 仕事が楽しくなくて、後ろ向きな動機からはじめた仕事が本職になっちゃうとか、人生のなかで二つの俺プロジェクトとか、仕事をサボって勝手にやってみたらうまくいったとか、なかなか面白い。 言われたことをちゃんとやるというのは重要だけど、言われたことしかやらないというのでは成長がない。勝手に何かをやって、学んでいくと言うのが成長には欠かせない。 自分にとってもオープンソースなんかは業務とは一切関係ないところからはじめていつのまにかにそれが仕事になっていて、あまつさえ会社を立ち上げてしまった。 Googleの20％ルールはそれを制度化したものとして有名だが、正式な業務以外を勝手にやるものをシャドーワークとか、スカンクワークとか言う。社内でそれを黙認したり、むしろ奨励したりする企業もある。DECはそのようなプロジェクトをミッドナイト・プロジェクトとよん
「納品」をなくせばうまくいく、倉貫義人著、読了 - 未来のいつか/hyoshiokの日記
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデルを倉貫さんからいただいた。ありがとうございます。早速読んだ。 倉貫さんの会社「ソニックガーデン」はいわゆるソフトウェアの受託開発の会社である。 SonicGarden 株式会社ソニックガーデン ソフトウェア受託開発というのは顧客の要望するソフトウェアを作って、それを納品するということが基本的なビジネスモデルである。売上は通常、「納品」することによってたてる。納品しなければ売上がたたないという仕組みになっている。 ところが、ソニックガーデンは受託開発の会社にも関わらず、納品をしないという。意味がわからない。非常識である。そして、その非常識なビジネスモデルがどういうものかを説明したのが本書になる。 １章 常識をくつがえす「納品のない受託開発」 ２章 時代が「納品のない受託開発」を求めている ３章 顧客から見た「納品の
自分は緩やかに死んでいくのだなと思った - 未来のいつか/hyoshiokの日記
先日参加したとある勉強会。 原宿のちょっとおしゃれなビルの地下二階。受付をしている時、いきなり、火災報知器の音が鳴り響き、「ただいま火災が発生しました」という録音されたメッセージが流れてくる。 おいおい。なんだよ。しょうがないので、地下から地上まで戻って、様子をみる。講演者の中島さんも出てくる。なんだか、まいっちゃいますよね、とか緊張感もなくしばし歓談する。「火災報知器の誤作動でした」みたいなアナウンスが聞こえてくる。やれやれ。もう一度、受付に行くと、また火災報知器。しょうがないので、また一階まで行く。異常はありませんというアナウンスがながれたので、しょうがないなーと思いつつ、イベント会場に入って、開場を待つ。 司会が、CEOを紹介してプレゼンがはじまる。また、火災報知器。ざわつく。しょーがねーなー。どうなってんだよ。CEOが「今確認しますので、しばらくお待ちください」数十名の観客。静かに
エンジニアの英語化戦略 - 未来のいつか/hyoshiokの日記
あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。 まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。 少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。 もちろん英語を学ぶとか学ばないとかは余計なお世話である
GitHub実践入門を読んでGitとかGitHubについて考えた - 未来のいつか/hyoshiokの日記
みんなでGitHubを勉強するにゃんっ！に参加するのでいろいろGitとかGitHubについて再勉強ちう。 そしたらGitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)を著者の大塚さんから送付いただいた。読了。ありがとうございます。 目次をみるとなかなかよさげだったので、期待しながら読んだ。素晴らしい。 http://gihyo.jp/magazine/wdpress/plus/978-4-7741-6366-6/0001 第1章GitHubの世界へようこそ 第2章Gitの導入 第3章GitHubを利用するための準備 第4章Gitを操作しながら学ぶ 第5章GitHubの機能を徹底解説 第6章はじめてのPull Request 第7章Pull Requestが送られてきたら 第8章GitHubと連携するツールとサービス 第9章GitHubを利
ワークシフト（Work Shift）を読んだ。 2012-11-25 - 未来のいつか/hyoshiokの日記
仕事の世界の「古い約束事」とは？ 『私が働くのは、給料を受け取るため。その給料を使って、私はものを消費する。そうすることで、私は幸せを感じる』342頁。 所得を増やし、消費を増やすという価値観だ。それが20世紀の大量生産、大量消費の価値観だ。 『過去二十年間の働き方や生き方の常識が多くの面で崩れようとしている。例えば朝九時から夕方五時まで勤務し、月曜日から金曜日まで働いて週末に休み、学校を卒業してから引退するまで一つの会社で勤め上げ、親やきょうだいと同じ国で暮らし、いつも同じ顔ぶれの同僚と一緒に仕事をするーーそんな日々が終わりを告げ、得体の知れない未来が訪れようとしている』4頁。 得体の知れない未来 その得体の知れない未来とはなんなのか。その未来にどのようにわたしたちは対応するべきなのか、そのヒントがある。 2025年頃をこの本では想定していて、様々なシナリオを提示しつつ、３つの働き方のシ
英語化の弊害 2012-10-03 - 未来のいつか/hyoshiokの日記
タイムラインに英語化の弊害とかいうのが流れて来て『デキル人がダメ人間に見える』みたいなのを目撃する。 そーゆーのあるよなーとか思う。 でも、日本という地域でデキルと思われていても、世界に出るとガラパゴスってのはよくある話で、結局だめなんじゃんということか。身も蓋もない話で救いがないなー。 とか思ったのだが、この気持ちを精密に言語化できないので、推敲なしに脳内の思いをだだ漏れしてみる。 わたしの英語の原体験はDECとかOracleとか米国系企業の日本法人に勤めていたころにさかのぼる。DEC時代も米国本社に出向する機会はあったのだけど、本当のところはOracle時代、片道切符で米国本社でぺーぺーのエンジニアで働いた経験だ。 当時はもちろんインターネットが商用化した前後で、欲しい情報も十分にあったわけではないし、Oracleの米国本社でエンジニアとして働くということがどのようなことかの情報もまっ
2010-08-07
@kakutaniにお勧めされて禅とオートバイ修理技術を読んだ。禅の本でもなければ、オートバイ修理技術の本でもない。では何の本なのか。 一種のロードムービー仕立てになっている。主人公は息子クリスと友人夫妻とでオートバイによる旅にでる。ミネアポリスからカリフォルニアまでオートバイでいく。いったいどのくらいの距離があるのだろう。*1 ロードムービーと言うのは、主人公が旅をしながら、様々な問題に直面し、それを乗り越えることによって成長していくという骨格をもった物語で、本書はまさにその形式に則っている。 バイクによる旅なんてことをいうとわたしの世代ではイージーライダーなのであるが、60年代のヒッピー世代を彷彿とさせる物語になっている。 自分もいつの日か全米を車で（オートバイはさすがに体力的にきつそうなので）旅をしてみたいと思っているのだが、ハイウェイをひたすら西に行くというのにそこはかとなく憧れる
データセンターがコンピュータになる時代 - 未来のいつか/hyoshiokの日記
話題のThe Datacenter as a Computerなる論文を読んでみた。Googleの中の人が書いたインターネット時代のコンピュータの話だ。 http://www.morganclaypool.com/doi/abs/10.2200/S00193ED1V01Y200905CAC006 The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines: Synthesis Lectures on Computer Architecture, 2009, 108 pages, Luiz André Barroso Google Inc. Urs Hölzle Google Inc. ムーアの法則で、半導体の集積度がどんどん上がってきて、通信コストも安くなってきて、コンピュー
gdb豆知識 2008-09-26 - 未来のいつか/hyoshiokの日記
意外と知っているようでよく知らない自分が日々使う道具。そこで、gdbについて復習がてらいろいろ調べることにする。 gdbはemacsから使う gdbをコマンドラインから素で使うのはいかがなものかなと思う。やっぱemacsと固く結合されているわけだからemacsから使うのが正しい姿であろう。 「え〜、だってvi使いだし〜」とか「秀丸からは使えないんすかね」とか言うやつがいるが、秀丸ってなんだよ、とりあえづubuntuでも入れて、emacsいれて、gdb使いなさいとか指導したくなる。いかんいかん、説教くさくなってはいかんいかん。 先日もある会議でデバッガの話が話題になったのだが、「TCPなんちゃらのストール問題のデバッグ方法なんですけどね」、みたいな話題で、「それってカーネルの話？」とわたしが聞くと、「いや、ユーザランドっす」と若いハッカー、「じゃ、gdbでほげほげでいけそーね」、「そーっすね
Rebase Early, Rebase Often - 未来のいつか/hyoshiokの日記
昨日会社のブログ（git入門/ユメのチカラ）gitの話をしたが、その続き。(資料はこちら) 開発は基本的にはリモートのレポジトリをローカルにコピーして、そのコピー（ブランチ）に対して変更を行い、ローカルにコミットを繰り返す。 ローカルなブランチに対するコミットがずんずん増えていくわけであるが、それと並行してリモート（マスタ）もどんどん変更されていく。ローカルな変更とオリジナルな変更をいつの時点かで同期をとらないといけない。ローカルな変更はいわば、オリジナル対する機能追加であったり機能変更であったり、あるいは単純なバグフィックスであったりするわけであるが、開発期間が長ければ長いほど、ローカルな開発期間中にオリジナルが相当量変更されることになる。 最終的にオリジナルにマージするには、並行開発期間中のローカルな変更を矛盾なくオリジナルに統合する必要がある。 ローカルなブランチ1をZの時点で作りそ
2006-04-17
パソコンで最もよく利用されているエンコーディングの一つがシフトJISなのだが、その誕生については、なかなかまとまった資料がない。当時の関係者の証言を断片的にまとめたものしかない。 まづ小形さんの以下のBLOGとコメントを読む。当時の当事者が証言をしている。 http://d.hatena.ne.jp/ogwata/20051228/p1 シフトJISを発明したのは誰か？ http://d.hatena.ne.jp/ogwata/20051229/p1 シフトJISを発明したのは誰か？(2) http://d.hatena.ne.jp/ogwata/20051230/p1 「BASIC80を漢字化した経理専用マシン」のこと http://d.hatena.ne.jp/ogwata/20060102/p1 たくさんのコメント、ありがとうございます 安岡さんの日記も参考になる。 http://s
ユーザーのチカラ - 未来のいつか/hyoshiokの日記
思いもかけず弾さんからトラックバックをいただく。ありがとうございます。 コードには力があるんです。社会をよくする力があるのです。 それに力を与えるのは、ユーザーである。 コーダーには時間がないんです http://blog.livedoor.jp/dankogai/archives/50539250.html そのとおりだ。まったく持って異論はない。インターネットに価値があるのはネットワークの向こうに人がいるからである。SNSやらブログやら、それらに価値があるのはそれを利用するユーザーがいるからである。ユーザーの参加なしには意味はない。 誰も読まないブログ、誰も参加しないSNS、利用されないソフトウェア、荒涼とした地平線。誰もそんな世界は望んでいない。 われわれが目指しているのは参加者によって価値が高まると言うWeb2.0的世界観でもある。 一方で、SNSやらブログという技術を日々開発し
『 プログラマの仕事』
U-20プログラミング・コンテストの審査員を務めたミラクル・リナックス取締役の吉岡弘隆氏は「今年，ついにLinuxカーネル・コミュニティへデビューした」と嬉しそうに話していた。彼の書いたパッチがAndrew Morton氏がメンテナンスするLinuxカーネルに採用されたのだ。Linuxベンダーがカーネル開発に参加するのは当然かもしれないが，吉岡氏は今年47歳。47歳にしてカーネル・ハッカーのスタートラインに立った。その目標は「生涯一プログラマ」だそうだ。 http://itpro.nikkeibp.co.jp/article/OPINION/20051017/222923/ 本当にラッキーだと思う。ひょんなことで「仕事」でカーネルのパッチを書く機会を得てコミュニティにデビューできた。C言語とちょっとした経験さえあればプログラミングは誰でもできる。プログラミングは体力を使わないので年齢を重ね
未来のいつか/hyoshiokの日記 - オープンソースの開発で飯を食う
リナ飯（Linuxで飯を食う）とかオプ飯（オープンソースで飯を食う）とかとオープンソースのボランティア活動はまったく直交している。独立した事象であるとわたしは思う。 生活のためにコードを書く人は昔も今も明日もいるだろうし、趣味でコードを書く人も、（コードを書きたいから書く人も）、昔も今も明日もいるだろう。プロもいればアマチュアもいる。それによって金銭的な報酬を受けている人もいれば受けていない人もいる。金銭的な報酬ではなくコミュニティからの尊敬を受けている人もいれば受けていない人もいる。自己の満足度を金銭的報酬以外のものに求める人もいればそうでない人もいる。 お金だけですべてを語るのは間違いである。もちろんそう思う。しかしオープンソースソフトウェアの開発と言うだけで過度に自己実現のためにコードを書く人が多数だと言うような言説はいかがかと思う。ソフトウェアの多くは趣味で自分のためにだけ書かれた
無駄なドキュメントは書くな - 未来のいつか/hyoshiokの日記
ひたすら実装に関するドキュメントをしこしこ書いている人がいるが、好きで書いているわけではなく、書かされているのかもしれないけれど、そーゆー無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。 ソフトウェア工学の教科書にドキュメントの重要性が書いてあるからといって信用してはいけない。ウオーターフォールモデルが商用ソフトウェア開発の現場で役にたたないように、実装に関する詳細ドキュメントは百害あって一利なしである。 コードがドキュメントだ。 http://capsctrl.que.jp/kdmsnr/wi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
