一般社団法人未踏の理事に就任しました - 西尾泰和のはてなダイアリー
昨日9月29日の一般社団法人未踏(未踏社団)の社員総会にて、私と川合秀実さんの理事就任が決まりました。このブログ記事で理事就任のあいさつに代えさせて頂きます。 未踏社団とは 公式ページはこちら: http://www.mitou.org/ 簡潔に言えば、未踏事業の関係者を中心に、創造的な人材の一人一人が創造性を最大限に発揮出来るよう、環境を整えていくことを目指す組織です。 西尾泰和とは 2002年度未踏ユース採択者で、現在はサイボウズ・ラボ株式会社にて研究開発をしています。主な関心分野は、ソフトウェアなどによる知的生産性の向上や、アイデアづくりの支援です。未踏社団の目標である「創造的な人材が創造性を最大限に発揮できる環境づくり」は、私自身の関心とも強い関連性があります。 何を大事だと考えているか ここから自己紹介もかねて、私個人が何を大事だと考えているかを共有したいと思います。 「一緒に居
僕は結城さんのことが好きなんだなぁ - 西尾泰和のはてなダイアリー
僕は結城浩さんのことが好きなんだなぁ。彼の書いた「文章を書く心がけ」は自分が執筆をするときにも何度もお世話になった。彼の日記などに時々かいま見える「読者によりよいものを届けよう」という真摯な態度には好感を感じる。以前の僕は宗教と名の付くものが全て嫌いだったのだが、敬虔なクリスチャンである彼の日記を読んでいるうちに、その嫌悪感が軽減した。結局のところ、どんな集団にもいい人もいればわるい人もいるということなんだ。 では、わるい人に対してどう対処するのがよいのか。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 なるほどね。400年も経つけども、人間の社会はあんまり変わって
「文字列を文字の列とみなす単純化」ってどういうこと？解説編 - 西尾泰和のはてなダイアリー
先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528
例えば「写経」という言葉を避けてみる。 - 西尾泰和のはてなダイアリー
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。 ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。 プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い
U理論が面白い - 西尾泰和のはてなダイアリー
U理論の本を流し読みしてたけど、これは結構面白い。 PDCAサイクル(計画→実行→評価→改善)は、既にサイクルが回っている人にとっては納得感があるのだろうけども、回ってない人にやらせようとすると「で、計画はどうやって立てるの？」で悩んで止まってしまったり、逆に問題に対する知識が不足してる可能性に無自覚なまま、詳細すぎる計画を立ててしまって、後からわかった情報で瓦解したりする。 科学的思考法の「仮説→実験→検証→修正」のサイクルでも、流行りのリーンスタートアップの「仮説検証のサイクルを高速に回せ」でも、やっぱり実際にやろうとすると「で、仮説はどうやって見つけるの」というところでつまずく人がいる。 この手の「サイクル」に入る手前でつまずいている問題について、僕はいままで「まず観察を」と言ってきたのだけど、U理論はこの部分を7段階に分けて考えている。 一つ目は、物事を既成概念に当てはめて見ている
状態のあるコードに対するテストの自動生成 - 西尾泰和のはてなダイアリー
BLUE*アルゴリズムを実装してみたので、せっかくだからテストの自動生成をやってみた。 今回テスト対象にするコードの仕様は 開く、閉じる、書き込む、の3つの操作ができる 開いてないのに書き込んだり閉じたりしたらエラーになる というもの そしてこちらがそれの「バグのある実装」： class Target(object): # bad impl. def __init__(self): self.opened = False self.closed = False def open(self): self.opened = True def write(self): if not self.opened: raise RuntimeError if self.closed: raise RuntimeError def close(self): if not self.opened: rais
一方バルタザール・グラシアンはこう言った (RE: ネットで毒を吐いている人たちにツイッターで反撃するのは、リスクばかりで、ほとんど何のメリットも無いという話) - 西尾泰和のはてなダイアリー
[徳力]ネットで毒を吐いている人たちにツイッターで反撃するのは、リスクばかりで、ほとんど何のメリットも無いという話。を読んで連想したこと。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 人と争ってはいけない。公正に戦うものなどほとんど居ないのだ。敵は使えるものなら何でも利用しようとし、本来使うべきでない卑劣な手まで繰り出してくる。そんなことしても何の得にもならないのだが、仕返しができたと言うさもしい満足感が得られれば彼はそれで十分なのだ。 失うもののないものと戦ってはいけない。仮に相手を打ち負かしても、なくしたものを取り返すことはできない。 400年経っても人間はあ
他の言語に慣れた人がPythonを使ったときにつまずきがちな10のポイント - 西尾泰和のはてなダイアリー
今日質問されて、以前Twitterで書いたのを思い出して、そして検索性が悪くて見つけ出すのに苦労した。こちらに転載しておく。詳細は気が向いたときに埋める。 オプション引数の評価タイミング Rubyではオプション引数は関数が呼ばれるたびに評価される。 def foo() print "foo!" end def bar(x=foo()) end bar #=> foo! と出力される bar #=> foo! bar #=> foo! Pythonでは関数の定義時に1回だけ評価される。 def foo(): print "foo!" def bar(x=foo()): pass #=> foo!と出力される bar() #=> 何も出力されない bar() 「引数が省略されたら今の日時」みたいな毎回評価したい場合はデフォルト値をNoneにしておいて「Noneだったら＝省略されていたら」のif
30歳になりました＆入籍しました - 西尾泰和のはてなダイアリー
60歳還暦までの折り返し地点を迎えました。一緒に走ってくれる人も見つかりました。これからも頑張っていきたいと思います。今後ともよろしくお願いします。 参考文献(何) こんな嫁です: Q:「「嫁の参考文献」がまったく読み解けないぞ……。単に欲しいものを列挙してるだけなんだろうか？」 A: 嫁「欲しいものではありません！構成要素です！」僕「えっ、おなかにルンバ入ってるの？！」嫁「ルンちゃんは家族！まどかは概念！」
Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 - 西尾泰和のはてなダイアリー
はい、Ruby 1.9.2がリリースされましたね。このバージョンではWEBrick にゼロデイ攻撃可能な脆弱性 - スラッシュドット・ジャパンで紹介されている脆弱性が僕が書いたパッチで修正されているわけなのですけど、そもそもなんで僕が修正しているのか、って顛末がわりと面白いので紹介します。 Apple、upstreamに報告してくれないまま脆弱性をCVEに届け出る upstreamに連絡が来ないまま脆弱性が公開される ruby-devにAppleが書いたと思われるパッチが貼られる(Appleでない人間によって) パッチのライセンスが不明なので取り込めない ライセンスを問い合わせるAppleの窓口が不明なので問い合わせもできない ruby-devを読んだ人はライセンス上安全なパッチを書けない 脆弱性だから話は非公開に進めたい yuguiさんがruby-devを読んでない僕に書かせることにする
同じ内容で発表する際の注意点 - 西尾泰和のはてなダイアリー
同じ内容で複数回発表するとき(特に前にやった同じ内容の発表を見た人が場にいる場合)にやってしまいがちなこと。 「これは○○の時に発表した資料なんですが」 「ご覧になった方もいらっしゃるとは思いますが」 「使い回しでゴメンナサイ」 「あんまり変わってないですけど」 「これ前やったんで飛ばしますね」 「(笑いを取るポイントで)ネタバレしているのでアレですね」 その発表は、まだその発表を聞いていない人がターゲットなのだから、すでに聞いた人がどう思うかを気にしすぎて初めて聞く人の体験を損ねてはいけない。初めて聞く人にとって上のような発言は「無駄な情報」であったり「不快」であったり「疎外感を与える」ものでしかない。 これはid:s******の今日の発表だけの話じゃない。12月のid:s******_***の発表やこの前のid:i**_***の発表を見たときからずっとぼんやりとしたもやもや感を抱えて
僕のサイボウズラボでの仕事について - 西尾泰和のはてなダイアリー
よく質問されるけども、いつもうまく答えられない。 今回、ちょっといい説明方法が思いついたのでメモしておく。 僕のサイボウズラボでの仕事は、3年で1個の「イノベーティブななにか」を作ること。そして、そのために3年で10個の「リリースできるサービス/利用できる技術」を作ること。そしてそのために3年で100個の「プロトタイプ」を作ること。そしてそのために3年で1000個の「新しいアイデア」を思いつくこと。 逆に言えば、3年で1000個思いつき、100個作り、10個リリースして、1個のイノベーションを起こすこと。 イノベーションは狙って起こすことができないので、こうやるしかないのだと思う。本当は、1000個の「新しいアイデア」を出すために10000個の「既存のアイデア」を学ぶべきなのだけど、そこはまだまだ追いついていない。 - あ、なんかブックマークがいっぱいついてる…。誤解がないように補足してお
セカンドライフについて一言いっちゃおうかな - 西尾泰和のはてなダイアリー
まずこのページを開いて、平成何年の話なのかと、スクリーンショットとを見る。気が向いたら全部の文章を読んでもいいし、「NHK」で検索してそこだけ読んでもいい。 http://www.ipa.go.jp/NBP/12nendo/12mito/mdata/6-42gh.htm 次にその1年後のこのページのスクリーンショットを見る。 http://www.ipa.go.jp/NBP/13nendo/13mito/mdata/6-61.htm 僕の記憶が確かなら僕は当時Python歴半年くらいだったと思う。タコがなぜ飛ぶのかについての議論で意見が分かれたのでPythonで糸の張力と空気抵抗をシミュレートするスクリプトを書いて実験してみたり、「ブライテンベルグの車」という興味深い話を教えてもらったのでついでにそれを進化するようにしてワールドにたくさん入れてみたり(さすがに重くて秒間8フレームくらいにな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
