質問される力 - 未来のいつか/hyoshiokの日記
セミナーとか勉強会で話をしていて、あるいはそのような勉強会を主催していてよくある悩みの一つが質問が出ないというのがある。 質問がでないのは、日本人が奥ゆかしいのだとか、質問するのが恥ずかしいとか、文化的な何かにその原因を求める人もいれば、講師の発表がそもそも質問を前提としていないとか、セミナーの形式にその原因を求める人もいる。 原因はなんであれ、一方通行のセミナーより、インタラクティブな質疑応答が活発にあるものの方が、参加者にとっても講演者にとってもメリットが多いと思うのだが、なかなかその価値観が共有されていない。 その問題についてFacebookで話題になっていたので、ちょっと考えをまとめてみた。 なぜ質問が必要なのか。なぜ質問が重要なのか。 勉強会などで質問が求められるのはなぜなのだろうか。もちろん質問を受けることを前提としないセミナーや講習というものはある。そうではなくて自主的な勉強
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
勉強会とかイベントとかビール代とかつまみ代とかについて - 未来のいつか/hyoshiokの日記
わたしもカーネル読書会とか1000 speakers conference in English(1000 spと称す)とか、いろいろイベント的な勉強会的なものを主催する機会が多くて、参加者のみなさまの満足度はどうだったのだろうかと気にもむことも少なくない。 主催者側の手間ひまを最小限にするために、いかに手を抜くか、コストをかけないかというところで運営しているため、参加者の皆様にはいろいろとご迷惑、ご不便、不愉快なことを強いているのではないかと思う。 とはいうものの、手弁当でやっているので、そこはひとつ多目に見ていただきたいというか、大人の対応でお願いしたいと思ったり思わなかったり。 カーネル読書会も1000 spも飲み物（ビールなど）とつまみ（乾きものとかピザとか）を出して1000円という予算になっている。カーネル読書会の長い歴史の中で、1000円から1500円くらいでやりくりしていて、
自分の業務以外のシャドーワーク - 未来のいつか/hyoshiokの日記
サイボーズ式の小崎さんのインタビューが面白い。*1 仕事が楽しくなくて、後ろ向きな動機からはじめた仕事が本職になっちゃうとか、人生のなかで二つの俺プロジェクトとか、仕事をサボって勝手にやってみたらうまくいったとか、なかなか面白い。 言われたことをちゃんとやるというのは重要だけど、言われたことしかやらないというのでは成長がない。勝手に何かをやって、学んでいくと言うのが成長には欠かせない。 自分にとってもオープンソースなんかは業務とは一切関係ないところからはじめていつのまにかにそれが仕事になっていて、あまつさえ会社を立ち上げてしまった。 Googleの20％ルールはそれを制度化したものとして有名だが、正式な業務以外を勝手にやるものをシャドーワークとか、スカンクワークとか言う。社内でそれを黙認したり、むしろ奨励したりする企業もある。DECはそのようなプロジェクトをミッドナイト・プロジェクトとよん
ブルックスの法則 - 未来のいつか/hyoshiokの日記
ムーアの法則（18ヶ月で半導体の能力が２倍になる）というのは有名だが、それに比べてブルックスの法則は知られていない。 http://commons.wikimedia.org/wiki/File%3AFred_Brooks.jpg *1 ブルックスは1960年代、IBM System/360用オペレーティング・システムOS/360の開発責任者で、後にそのときの経験をもとに人月の神話という本を書いた。 大規模ソフトウェア製品開発の難しさを書いた画期的な書物である。IT産業に従事しているなら必読の書である。ソフトウェア開発あるいはプロジェクトマネジメントに関わる人はだまされたと思って読んだ方がいい。わたしの日記でも何度となく紹介している。 それはともかく第二章人月の神話だ。次のような例題がある。12人月かかると見積もられた仕事があるとして、３名で４ヶ月でその作業を完了すると考えた。そして一月毎
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版を出し
社内勉強会とパートナーエンジニア - 未来のいつか/hyoshiokの日記
社内勉強会は参加者の利便性を考えて昼休みに開催することが多い。昼休みならば、時短勤務のお母さんも参加できるし、夜学に通っている人でも参加できる。 とは言え、社外の人を講師として呼ぶ場合は、必ずしも昼休みにお願いするということが可能とは限らない。その場合は、夜7時ごろから開催になる。 今回たまたま開催した勉強会では、参加者が少なかったこともあって、各自自己紹介をした。そうすると意外と協力会社のパートナー（常駐）エンジニアの方が多かった。 今まで気がつかなかったのだけど（人数が多いときは自己紹介をしないので）、パートナーさんの勉強会に対するニーズというのは潜在的には大きいのではないのだろうか。勤務時間中の勉強会の出席は契約にもよるだろうけど、勉強会は業務ではないのでパートナーさんが参加することは難しい。勤務時間外であれば、問題はない。 職場での勉強会のメリットは移動時間がゼロというところもある
エンタープライズ系とウェブ系 - 未来のいつか/hyoshiokの日記
エンタープライズ系ってなんだろう。ウェブ系ってなんだろう。勝手に脳内イメージを言語化してみた。読者諸氏のコメントを待つ。(想像でものを言っています) エンタープライズ系 ウェブ系 開発手法 ウォーターフォール アジャイル 開発 外注 内製 会議 多い、長い 少ない、短い 資料 人数分カラー印刷 印刷なし 進捗管理 エクセル バーンダウンチャート ソースコード管理 ファイル名日付 Git 服装 スーツ Tシャツ 新技術の取得 ベンダーのセミナー 勉強会 テスト 人海戦術 自動化している 休日の過ごし方 休日出勤 趣味のプログラミング 休日の過ごし方、その２ ゴルフ 趣味のプログラミング、子供と遊ぶ ダイバーシティー 最近結婚してやめた人がいる 最近外国籍の人が増えている 上司 年上 年下もいる 飲み会 おじさんばっか おたくとコスプレ 転職 したことがない 同業他社から転職して来た 趣味、尊
かつてオープンソースが当たり前じゃないころがあった - 未来のいつか/hyoshiokの日記
先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/
ブルックスの法則とはなにか - 未来のいつか/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の日記
あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。 まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。 少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。 もちろん英語を学ぶとか学ばないとかは余計なお世話である
社内が英語化してよかったこと - 未来のいつか/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/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
まつもとゆきひろのコピーは作れるのか。 - 未来のいつか/hyoshiokの日記
「Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871 まつもとゆきひろのコピーは作れるのか？ コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを１０年間続けるにはどうすればいいのだろう。 OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。 githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。 にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのような
集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続きの続き - 未来のいつか/hyoshiokの日記
先日の話の続き。 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど） http://d.hatena.ne.jp/hyoshiok/20140115/p1 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続き http://d.hatena.ne.jp/hyoshiok/20140118/p1 さすがに長いけど、fjからのコピペはこれで最後になる。 https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/_m2HEa5QpGMJ Hirotaka Yoshioka 1998/06/02 "SENOH Yasushi" writes: > 妹尾です。 > >いずれにしてもなんとなく > >私の賛成していない設計とプログラミングの分離を前提にしている > >ような気がするんですが…． > 私
昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続き - 未来のいつか/hyoshiokの日記
先日の話の続き。http://d.hatena.ne.jp/hyoshiok/20140115/p1 実名、所属名付きでお話をするスタイルで議論は進んでいく。しかしこうやってまとめてみると無駄に長い。言葉を定義して少しずつ進む。やり取りがリアルタイムではないので進行がもどかしい。結構めんどうなことをいい歳をした大人がやっているという印象である。 追記(2014/1/19) 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続きの続きを書いた http://d.hatena.ne.jp/hyoshiok/20140119/p1 https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/RSlNBEeQ_uUJ SENOH Yasushi 1998/05/28 OOA is prerequisite to OOP?
昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど） - 未来のいつか/hyoshiokの日記
1990年代のインターネットというのは利用者も少なく閉じた世界観があって、自由というもののある種の見えない掟みたいなものがあった。あったのかもしれない。当時ネットニュースという掲示板みたいなものがあって、今で言うところの中二病をこじらせたいい歳をした大人たちが日夜あーでもないこーでもないと言い合っていた。 fjというネットニュースがあって、日々いろいろな話題が議論されていた。あなたの会社のエラい人も若い頃、そのネットニュースに書き込んでいたかもしれない。若き日の（15年前）まつもとゆきひろさんとかがいるよ。 たまたま、そのころのニュースを発見して、あまりの懐かしさにここに再掲することにする。若き日の、あの人やこの人の中二病時代の書き込みである。 編集解説はわたし。それ以外は、当時の誰か。 https://groups.google.com/forum/?hl=ja#!topic/fj.co
OSS利用の成熟度 2013-12-29 - 未来のいつか/hyoshiokの日記
OSS利用を下記の段階で考える 発見(find) 利用(use) 参加(participate) 革新(innovate) 発見(find) OSSを発見し、試しに利用してみる。本格的な導入というよりも試し使い。この段階で問題が発生すると本格的な導入に至らない場合がある。 ライセンスフィーがかからないので、無料で利用できるため、ちょっと試してみるという段階である。ただし、インストールなどが難しい場合は、利用に至らないで挫折する場合もある。 利用(use) 試し使いをしてみて、意外と便利なことがわかると、本格的に利用してみるということになる。 ユーザが多いとインターネットには情報があふれているので、それをもとにより高度な使い方をし始める。ちょっとしたトラブルはインターネットで検索するとどうにか解決できる。 参加(participate) 本格的に利用をはじめしばらくするといろいろな問題にぶつ
MIT license を読む 2013-12-22 - 未来のいつか/hyoshiokの日記
MIT licenseはシンプルだ。3段落しかない。 最初の段落で、何を認めるか(grant)を述べている。2番目の段落で、どのような条件の時、上記の許可(permission)を与えるか、そして3段落目は無保証ということを宣言している。 ソフトウェアは著作権で保護されているので、第三者が勝手にコピーしたり、変更したり、何かにそのまま含めたり、出版したり、再配布したり、サブライセンスしたり、販売したりはできない。 そこでMITライセンスは、著作権者が自分の著作物に対して、第三者が上記のことをすることを許可している。"Permission is hereby granted" このライセンスは契約なのか、著作権の権利の不行使の宣言なのかという法律上の論争があるがここではそれに踏み込まない。 The MIT License (MIT) Copyright (c) Permission is h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
