昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。 - 未来のいつか/hyoshiokの日記
大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す
素人をプロに育ててくれた社内コミュニティ - 未来のいつか/hyoshiokの日記
20数年前に新卒で入社したわたしを育ててくれたのは配属先の上司であり、社内エンジニアリングコミュニティだ。 最初のプロジェクトは日本語COBOLのプリプロセッサを作るというものだった。大学でソフトウェアを学んだが、職業としてプログラムを組むという経験はなかった。プログラムを作ることのいろはをその会社で学んだ。 新卒の初心者プログラマの日常はこんな感じだ。 よ「プログラム書きました〜」、先輩「あれ〜、どこにファイル置いたの？チェックインした？」、よ「まだでした」、ぱたぱたぱた、よ「チェックインしました〜」、先輩「あれー、ビルドできないなあ、コンパイルエラーが出るよ」、よ「コンパイルしていませんでした〜。今直します〜」、あれやこれや、よ「出来ました。ばっちりビルドも出来ます〜」、先輩「あれー、テストが通らないなあ、ちゃんとテストしたの？」、よ「テストはしていません（きっぱり）」、先輩「おいおい
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
図書館の使い方 - 未来のいつか/hyoshiokの日記
自分は図書館が大好きなので、しょっちゅう図書館に行っている。中学時代に可愛いこが図書委員をやっていたので、その頃から図書館が好きだ。図書館短大の女子と合コンをしたこともある（関係ないけど） 通勤の行き帰りに図書館に寄るのがもはや日常と言っても過言ではない。 ネットのおかげで図書館に直接行かなくても本を予約できる。 図書館好きならば誰でも使っている、日本最大の図書館検索サイト・カーリルを使いこなそう。 https://calil.jp/ 面白そうな本を見つける ネットで図書館検索をする ネットで予約する 忘れた頃に予約した本が借りられる 図書館に行って借りる 図書館でぶらぶらして関係ない本も借りる 感想をネットに書く 読んでも読まなくても期限がきたら返却するので積ん読にはならなくてネットの感想だけが残る。 予約してすぐ借りられる本もあれば、予約が殺到していて何ヶ月も待つ本がある。すぐに読みた
チームで学ぶ - 未来のいつか/hyoshiokの日記
PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。 産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1 キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a serv
Linusが2週間でgitを作った話。 - 未来のいつか/hyoshiokの日記
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し
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の日記
あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。 まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。 少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。 もちろん英語を学ぶとか学ばないとかは余計なお世話である
enPiT第2回ビジネスアプリケーション分野ワークショップに参加した - 未来のいつか/hyoshiokの日記
産業技術大学院大学で開催された第2回ビジネスアプリケーション分野ワークショップに参加した。昨年、enPiTという産学協同の教育プロジェクトで、スクラムによるアジャイル開発手法のコースを永瀬美穂さんと担当した。その成果報告会。われわれのPBL (Project Based Learning) を受講した4チームのうち、琉球大学学生のチーム、Ryupitが参加してポスター発表をした。 http://www.cs.tsukuba.ac.jp/enPiT/html/workshop201302.html 招待講演は上野 新滋 さん(CeFIL 理事，(株)FUJITSUユニバーシティ 産学官連携グループ長 エグゼクティブ・プランナー）で、富士通の取り組み、JMOOCの紹介など。 連携三大学（筑波大学、産業技術大学院大学、公立はこだて未来大学）からの活動報告、PBL参加学生チームからの発表（3分）と
社内が英語化してよかったこと - 未来のいつか/hyoshiokの日記
なんだか、ネガティブなことばかり世間では書かれているので、個人的によかったことなど感想を一つ二つ書く。 どーでもいいことから 英語への抵抗感がなくなる。どっかで英語で話しかけられても怖くない。へらへら対応できる。切符を買えなくて困っている外国人とお友達になれる自信ある。 30分くらいの英語の会議だったら集中力が持続する。 外国籍の友達が増えた。会社に外国籍の人がいっぱいいるので、顔見知りがいっぱい増えた。英語で雑談するのが好きだ。仕事で絡みがなくても気さくに話しても大丈夫である。 海外情報がいろいろ回ってくるような気がする。翻訳される前の情報がいろいろ出回っているような気がする。（まあ、気がするだけかもしれないけど） インターネットで流通している技術情報のほとんどは英語であるということを確信した。日本語の情報は遅い、古い、不正確で、量も少ない。ググるときに日本語じゃなくて英語のページを見た
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
OSC 2014 Tokyo/Sprintに行ってきた。 - 未来のいつか/hyoshiokの日記
https://www.ospn.jp/osc2014-spring/ 法林さんの司会 15時15分の開始前から法林さんとあれやこれや雑談しつつお話をさせていただいた。かなり雑駁なお話で恐縮である。 質疑応答で、企業に属する人がOSSに貢献するときのポイントのようなことを聞かれた。弊社では、その規定があるので、その規定に則って行う。すなわち、知財や法務の確認を前提に、ビジネス上のメリット・デメリットを判断した上でオープンするかどうかを決定する。単純なバグフィックスのような場合は、ビジネス上のデメリットはほとんどないので、公開する。というような判断をする。 OSCは今回約100回目の開催ということで、記念の回に参加できてよかった。講演をしたので、ブースを回る事がほとんどできなかったのが若干残念であった。 2014-03-01 (土) 15時15分 jus研究会東京大会「オープンソースの利用と
ビブリオバトル - 未来のいつか/hyoshiokの日記
１）お勧めの本を持ち寄り、２）それを5分で紹介し、３）2〜3分質疑応答をし合い、４）最後にどの本が読みたくなったかを参加者全員で投票で決める、というルールで運営される読書会のようなもの、ビブリオバトルというのを教えてもらった。 http://www.bibliobattle.jp/ そのルールは厳密に定義されていて、その公式ホームページもあれば、入門書もある。その入門書を読んだ。 読書会、輪読会という形式の勉強方法というのは昔からあったが、このビブリオバトルというのは、それにちょっとしたゲーム的な要素を加えてルールを決めた。 読書会同様に１）本の内容を共有できる、２）発表の練習になる、３）いい本が見つかる、４）お互いの理解が深まる、というような機能がある。 ５分と言う発表時間の制約から、その本の魅力を凝縮し伝える努力が発表者には求められし、発表時間がそれほど長くないので、10冊程度の本の紹
まつもとゆきひろのコピーは作れるのか。 - 未来のいつか/hyoshiokの日記
「Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871 まつもとゆきひろのコピーは作れるのか？ コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを１０年間続けるにはどうすればいいのだろう。 OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。 githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。 にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのような
Subversion (SVN), Mercurial (Hg), Gitの早見表 - 未来のいつか/hyoshiokの日記
下記で見つけた各バージョン管理システム(VCS)のコマンドの比較表。 http://japan.blogs.atlassian.com/2012/03/mercurial-vs-git-why-mercurial/ Subversion (SVN) Mercurial (Hg) Git svn add hg add git add svn blame hg blame git blame svn cat hg cat git show svn checkout hg clone git clone svn commit hg commit ; hg push git commit -a ; git push svn delete/remove hg remove git rm svn diff hg diff git diff, git diff –cached svn help hg h
gitって難しいのかなー - 未来のいつか/hyoshiokの日記
いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください） 前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。 それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもい
人は怠惰なので。 - 未来のいつか/hyoshiokの日記
新しいことをするのには大変なエネルギーがいる。達人プログラマのように毎年毎年新しいプログラミング言語を覚えるというようなことは基本しない。そんな人は言語オタク以外そうそういない。 勉強会に行く奴はほっといても行くし、行かない奴はどんなことを言ってもまずいかない。カンファレンスの報告を聞いても、行かない奴はまず行かない。行くという発想がそもそもない。 行かない奴を強制的に行かせることは仮にできたとしてもカンファレンスで得られる無形の価値をどれだけ獲得してくるか、その経験もノウハウもほとんどないので、豚に真珠、猫に小判である。 自分は勉強会とかカンファレンスの無名の価値を信じている口なのでどうにかこうにかそれを言語化したいと思っているのだけど、全く違う分野のナニかについて、本当はすごいのだけど全然そのすごさに気がついていないものが世の中にはいっぱいあるに違いない。絶対ある。根拠なくあると思う。
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)にサービスをデプロイするので、誰でもその週に作ったものを確認できる。最初はデプロイがうまくいかな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてな日記など - 未来のいつか/hyoshiokの日記
