再帰呼び出しを再帰呼び出しなしで実現 - 西尾泰和のはてなダイアリー
拙著「コーディングを支える技術」の第5章「関数」では、P.50で「再帰呼び出しを使っているプログラムは、再帰呼び出しを使わなくても書くことができる」と説明しました。この件に関してここで補足記事として解説することにしました。 P.53の簡単な再帰呼び出しの例(total関数)をターゲットにします。これは空行とコメントを除くと8行の簡単な例です。このコードから、挙動を変えずに再帰呼び出しを取り除いてみましょう。腕に自身のある人はは続きを読む前に自分で実装してみるとよいでしょう。 チャレンジする人向けの注意点 今回の対象では再帰呼び出しをしながら行う処理が「要素の足し算」でした。足し算は順番を入れ替えても結果が同じです。なので、うっかり計算の順番を変えてしまっても、結果からは間違いに気付けません。例えば深さ優先探索を幅優先探索に変えてしまうと、[1, [2, 3], 4]が本来の1, 2, 3,
アジャイルな見積りと計画作り：レバレッジメモ - 西尾泰和のはてなダイアリー
PySpaで id:Yoshioriに「見積りって難しい」という話をしたら「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を教えてもらった。さっそく読んでみたのでレバレッジメモ。 「不確実性に対処するためにバッチサイズを小さくしてアジャイルに開発しよう」とか言いつつ「見積りはプロジェクトの最初に立てて変更しません」という運用をしているのはおかしい。見積りや計画づくりもアジャイルに、状況に応じて変わって行かなければ、という本。 要するに「プロジェクトの最初に正確な計画・見積りが作れるはずがない。最初に正確な計画・見積りづくりをしようとして過剰にコストを掛けるのではなく、イテレーションごとにより精度の高い見積りへと更新していく形を取ろう」ということ。 従来型の見積りの仕方が失敗するパターンがいくつか上げられていて興味深い。 例えば「タスクXに何日掛かるか見積もれ」
ポモドーロについて - 西尾泰和のはてなダイアリー
質問されてTwitterでつぶやいておいたので、流れ去らないようにここにまとめておく。 まず「25分で1ポモドーロだから8時間だと16ポモドーロか」とか言ってる人はそれが「人間は100メートルを10秒で走れるから、42キロを4200秒で走れるはずだ」と言うくらいおかしいということを理解した方がいい。短距離走の速度を長距離走で維持することはできない。そういう「1日8時間働く」を前提とした計算をしている人はポモドーロの「短時間に集中して成果を出そう」という目標をそもそも理解できていない。 これは僕流の解釈というわけではない。アジャイルな時間管理術 ポモドーロテクニック入門の前書きでも読んだことがあればすぐに誤解に気づくはずだ。こう書いてある。「1日に12ポモドーロ分はこなせるだろうと思っていました。しかし、ふたを開けてみると、せいぜい8ポモドーロが現実的なラインということがわかりました」(文意
講義資料「テストとデバッグ」を公開しました - 西尾泰和のはてなダイアリー
昨年行われたセキュリティ＆プログラミングキャンプ2011で中学生〜大学生を対象として行った講義「テストとデバッグ」の発表資料を公開します。 テストとデバッグ View more presentations from nishio
遺伝子をモチーフにした言語「Genomy」を作りました - 西尾泰和のはてなダイアリー
最近、3年くらい前に書いた「そろそろ例のプロジェクトについて言及するか」についてTwitterで言及があったので思い出しました。「条件を満たしたものをすべて呼び出す」という設計思想でプログラムが書けてしまうという点について意外とみんなピンと来ないみたいだからコンセプトプルーフを実装してみようと思っていたんでした。 という訳で作りました。https://github.com/nishio/genomy 解説 「遺伝子はタンパク質の設計図」というところまでは教科書などでもよく言及されます。でも、その設計図には「どういう状況になったら作るべきか」「どういう状況では作るべきではないか」という情報も書かれています。 この「作るべきではない」(発現の抑制)がどう実現されているか、ザックリ説明しましょう。体の中にあるタンパク質があると、これがある遺伝子の周辺にへばりつき、その遺伝子からタンパク質を作る過
首都圏で引っ越す人が知らないともったいない情報 - 西尾泰和のはてなダイアリー
「引越れんらく帳」にお客さまのお名前や引越先のご住所などを登録しておけば、電気・水道・ガスなどの引越に関する手続きで何度も同じことを入力する手間が省けます。他にも、ＮＨＫ、クレジットカード、損害保険等々、主要な企業の住所変更などにも対応しています。 東京電力 引越コンシェルジュ すごい、こんなものがあったなんて。1回住所や電話番号、メールアドレスなどを入力したら、東京ガスや水道局は違うウェブサービスなのにちゃんとデータが引き継がれてさくさく入力できる。12分くらいで電気とガスの手続きを完了した。水道はお客様番号をメモしてこなかったので後でやろう。
電車内プログラミングの生産性が高いのは何故かに関する考察 - 西尾泰和のはてなダイアリー
Twitterから転載 電車の中でやるコーディングは自由意志でやりたいと思ってやるコーディングなので生産性が高い 電車の中ではインタラプトが入らないから生産性が高い 近づいてくるデッドラインが明確なので締め切り効果が発生して生産性が高い 電車の中では調べ物ができないので、調べ物が必要なタスクが後回しにされて、結果として下調べが済んでいるもしくは脳内の知識でできるタスクを実行するから生産性が高く見える タイミングが予想出来る乗り換えインタラプトが存在するので、乗り換えの間に考えていたことを忘れないようにファイルに出力すること、そして歩くことが問題の整理に役立っている 電車の適度な騒音や移動していることによる海馬への刺激がなんか集中力を高めたりするのかもしれない 「目的地につくまで15分だからその間にアレを実装出来るかな？」というのがまさに「自発的に設定した制限時間へのチャレンジ」なのでドーパ
LinCityがHomelessだらけになっている - 西尾泰和のはてなダイアリー
快適な環境を作って放置していたら住む場所もないのに産めよ増やせよしたらしい。人口の98%くらいホームレス。 人口が多すぎてうっとうしいのでちょっと死んでもらおうかと思ったが(物騒) 農場を配置しすぎて飢え死にしてくれない。2.0に入っていた「井戸」の概念を最初は「無駄にすること増やしてよくないな」と思っていたけど、このシチュエーションで井戸をつぶしてしまえば人がどんどん死んで行く！ そしてこの破滅的な状況の中でなぜか高まって行く技術力。 しかし、人が死なないように病院を作ったり、ゴミが溜まって公害が発生すると慌ててリサイクルセンターを作ったりしてたんだけど、そうやって快適な環境を整えたのが間違いだったのだろうか。もっと劣悪な環境にして一方的に増え続けないようにするべきだったのだろうか。ほどほどに汚染したりして。土地の量は有限なのだから、増殖率が1を超えたままではいつか溢れ出す。出生率が下が
僕のサイボウズラボでの仕事について - 西尾泰和のはてなダイアリー
よく質問されるけども、いつもうまく答えられない。 今回、ちょっといい説明方法が思いついたのでメモしておく。 僕のサイボウズラボでの仕事は、3年で1個の「イノベーティブななにか」を作ること。そして、そのために3年で10個の「リリースできるサービス/利用できる技術」を作ること。そしてそのために3年で100個の「プロトタイプ」を作ること。そしてそのために3年で1000個の「新しいアイデア」を思いつくこと。 逆に言えば、3年で1000個思いつき、100個作り、10個リリースして、1個のイノベーションを起こすこと。 イノベーションは狙って起こすことができないので、こうやるしかないのだと思う。本当は、1000個の「新しいアイデア」を出すために10000個の「既存のアイデア」を学ぶべきなのだけど、そこはまだまだ追いついていない。 - あ、なんかブックマークがいっぱいついてる…。誤解がないように補足してお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
