知る人ぞ知る、桁下制限高1.5メートルのガードで山手線の下をくぐってきた。 泉岳寺（第一京浜）方面から歩いてみた。 ちょうど京浜東北線が通過した。 天井に頭がぶつかりそうである。 芝浦側はさらに天井が低くなっていて、タクシーの上についているのがぶつかりそうである。 山手線が上を通過した。正面が泉岳寺方面で撮影した。進行方向振り返る感じ。 検索してみたらタクシーの提灯殺しという別名がついているらしい。まとめがあった。 【山手線新駅で消滅危機？】東京名物「提灯殺し」のトンネル - NAVER まとめ https://www.google.co.jp/maps/place/35%C2%B038'20.0%22N+139%C2%B044'27.0%22E/@35.6388884,139.7408333,15z/data=!3m1!4b1!4m2!3m1!1s0x0:0x0?hl=ja

英語を社内公用語にしてはいけない３つの理由を読んだ。 英語社内公用語化は、１）日本語・日本文化の軽視、２）社会的格差・不平等の助長と固定化、３）言語権の侵害、なので、著者は反対という立場をとっている。 あらかじめお断りしておくが、わたしは、この著者の立場を取らない。また、ここでのわたしの意見は所属会社のそれを表すものではなく、あくまで個人としてのものである。 まず、簡単に本書を紹介し、その後、自分の意見を述べたいと思う。 「英語を社内公用語にしてはいけない３つの理由」 本書の構成は、序文「楽天、ユニクロへの手紙」、第１章英語社内公用語化の実態、第２章英語公用語論の歴史、第３章英語を社内公用語にしてはいけない理由１、日本語の衰退を招く、第４章英語を社内公用語にしてはいけない理由２、格差を生み、拡大する、第５章英語を社内公用語にしてはいけない理由３、言語権を侵害する、第６章もしあなたの会社が英

タイムラインに英語化の弊害とかいうのが流れて来て『デキル人がダメ人間に見える』みたいなのを目撃する。 そーゆーのあるよなーとか思う。 でも、日本という地域でデキルと思われていても、世界に出るとガラパゴスってのはよくある話で、結局だめなんじゃんということか。身も蓋もない話で救いがないなー。 とか思ったのだが、この気持ちを精密に言語化できないので、推敲なしに脳内の思いをだだ漏れしてみる。 わたしの英語の原体験はDECとかOracleとか米国系企業の日本法人に勤めていたころにさかのぼる。DEC時代も米国本社に出向する機会はあったのだけど、本当のところはOracle時代、片道切符で米国本社でぺーぺーのエンジニアで働いた経験だ。 当時はもちろんインターネットが商用化した前後で、欲しい情報も十分にあったわけではないし、Oracleの米国本社でエンジニアとして働くということがどのようなことかの情報もまっ

武雄市図書館、ＴＳＵＴＡＹＡが運営へ 佐賀県武雄市は４日、レンタルビデオ店「ＴＳＵＴＡＹＡ」を展開する「カルチュア・コンビニエンス・クラブ」（ＣＣＣ）に市図書館の運営を任せることで同社と合意したと発表した。市は６月定例会に同社を指定管理者とする議案を提出。認められれば来年４月に年中無休でカフェや雑誌、文具の販売コーナーを設置した図書館が誕生する。ＣＣＣが公立図書館の運営を行うのは初めて。 http://kyushu.yomiuri.co.jp/news/national/20120506-OYS1T00146.htm ネットでも早速いろいろな議論が巻き起こっている。 まづ当事者の武雄市長のブログ 武雄市長物語 http://hiwa1118.exblog.jp/15827483/ 当日の記者会見の映像 http://www.ustream.tv/recorded/22339926 当日の映

大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す

先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン

社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという

わたしが学生だったころ（1980年代前半）の就職活動というのを思い返して見ると、高校生のときに漠然と大学の学部を決めて、大学生活を送るうちに希望の業界をイメージしていくという感じだった。 例えば、工学部であれば車が好きな奴は自動車メーカーに、経済学部であれば、商社とか銀行とか。工学部でも電気メーカーを希望するのは電気科とかであり、自動車メーカーを希望するのは機械科を専攻しているやつで、その逆はあまり考えられなかった。電気回路全然だめだよという奴は電気科にはいかないし、熱力学とか製図をとらない奴は機械科にはいかない。（必修がどうだこうだというより、自分の好きな科目とか得意な科目、あるいは苦手な科目を勘案の上、学部や学科を選択していくイメージだ） 高校生ころにざっくりとした学部の選択をし、大学生活を送りつつ、徐々に職業というのをイメージしていく。わたしの場合、2年生を二度やっているので（とほほ

4/14-16、サンフランシスコで開催のLinux Collaboration Summitに来ている。*1 アジェンダは次を参照のこと http://events.linuxfoundation.org/events/collaboration-summit/agenda 簡単に初日のセッションの報告および感想を記す。 Keynote: Welcome and State of the Linux Union, Jim Zemlin, Executive Director at The Linux Foundation Jim ZemlinのキーノートでCollaboration Summit 2010 は幕を開けた。 Linuxの成功の要素を、（１）コスト（無償）、（２）新しいデバイスへの対応、（３）サービスへの移行とまとめた。（３）はITのビジネスモデルがソフトウェアのライセンス料を

なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して

会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその

20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数

2008年の10月ごろ受けたインタビューが最近再掲された。スーパーハッカー列伝というタイトルなんで、ちょっと気恥ずかしいが、まあ、それはそれとして、昔話をはてなの方でも引用してみる。 http://web-engineer.buyuden.net/hacker/2009/10/1-1.html DECでの仕事。 川井その先は、どんな仕事をされてたんですか？ 吉岡DEC の中で日本語COBOLを作って、その後にいくつかプロジェクトはあったんですけど、 RDBMSでVAX Rdbっていうのがあって、それの日本語化をやったんです。 そのソースコードを持って、香港のエンジニアリングチームが中国語版とか韓国語版かなんかを作ったんですね。ソースコードを1つにしてアジア共通のRDBを作ったわけです。 Cで言う所の#ifdefでソースをかき分けるみたいなことをやっていたわけだ。だけど、複数のバイナリが出来

自己紹介というのは、簡単なようでいて難しい。自分は何者かを5秒でいう。15秒でいう。3分でいう。それぞれに難しいものがある。 社会人として、自分を知ってもらうということは、仕事の一環として、最初の一歩だ。仕事じゃなくても、コミュニティでの自己紹介とか、親戚一同での自己紹介とか、簡単なようでいて難しい。 その場所にあなたはなぜいて、何者かを簡潔に表現する。それが難しい。 例えば、仕事上での初対面であれば、名刺交換をしつつ、XX株式会社、開発のよしおかでございます、でいいのであるが、勉強会で、全然自分の会社のことを知らないあるいは興味のない人に、第二営業部第三課の営業やるおです、なんて所属を説明しても、自己紹介にはならないし、そもそも第二営業部第三課が何をやっているかなんてことは参加者は知りもしないし、しったこっちゃない。なんできみがここにいるのかが意味がわからない。勉強会で営業やるお君が自己

日本は全体主義の国ではないから、職業選択の自由はあるし、思想信条の自由ももちろんある。自分の親が仮に政治家だったとしても自分が政治家にならなければいけないということはない。どっかの国の主席の後継者がどうだこうだというのは、国レベルのリーダーを世襲で選ぶという前近代的なわかりやすいシステムに対する日本人の憧れの表現である。親の仕事を継ぐのが正しい親子関係であると心の底では思っているのである。世襲でしょうやっぱしと思っている。 日本にも政治家の世襲という世界に誇るべきシステムはある。日本の総理大臣になるには親が政治家でないといけない。日本の憲法にはそんなことは一切書いていないが、日本人は皆知っている。政治家という要職につく人間はどこの馬の骨かわからないようなものには勤まらない。由緒正しい血筋を持った人間でなければ任せられない。そのために親が政治家でないような人間には総理大臣は勤まらない。総理大

昔DECという会社があった。米国のハードウェアベンダーだ。それでもIBMの次に大きいコンピュータベンダーだった。80年代前半飛ぶ鳥を落とす勢いでVAXというコンピュータを引っさげてIBMを追撃していた。年率二桁成長を何年も続けていた。コンピュータ産業は垂直統合の会社に支配されていた。ハードウェア（VAX）、OS（VMS）、コンパイラ、RDBMS、各種ミドルウェア、開発ツール（エディタ、リンカ、デバッガなどなど）、アプリケーションすべて上から下まで自社製品だった。 何か問題があれば、それがプロセッサの問題でもOSの問題でもRDBMSの問題でも、何から何まで自社で完結していたのでどーにかなった。どーにかした。それが垂直統合というわけだ。あこがれのエンジニアは社内にいた。VAXのアーキテクトもVMSのアーキテクトもVAX FORTRANのプロジェクトリーダもVAX Rdb/VMSのプロジェクトリ

文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる