昨年行われたセキュリティ＆プログラミングキャンプ2011で中学生〜大学生を対象として行った講義「テストとデバッグ」の発表資料を公開します。 テストとデバッグ View more presentations from nishio
講義資料「テストとデバッグ」を公開しました - 西尾泰和のはてなダイアリー
昨年行われたセキュリティ＆プログラミングキャンプ2011で中学生〜大学生を対象として行った講義「テストとデバッグ」の発表資料を公開します。 テストとデバッグ View more presentations from nishio
遺伝子をモチーフにした言語「Genomy」を作りました - 西尾泰和のはてなダイアリー
最近、3年くらい前に書いた「そろそろ例のプロジェクトについて言及するか」についてTwitterで言及があったので思い出しました。「条件を満たしたものをすべて呼び出す」という設計思想でプログラムが書けてしまうという点について意外とみんなピンと来ないみたいだからコンセプトプルーフを実装してみようと思っていたんでした。 という訳で作りました。https://github.com/nishio/genomy 解説 「遺伝子はタンパク質の設計図」というところまでは教科書などでもよく言及されます。でも、その設計図には「どういう状況になったら作るべきか」「どういう状況では作るべきではないか」という情報も書かれています。 この「作るべきではない」(発現の抑制)がどう実現されているか、ザックリ説明しましょう。体の中にあるタンパク質があると、これがある遺伝子の周辺にへばりつき、その遺伝子からタンパク質を作る過
もっとよいGitチートシート - 西尾泰和のはてなダイアリー
世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが
日記 - 西尾泰和のはてなダイアリー
今年のプロシンで印象に残ったことの一つは、3ヶ月だか6ヶ月掛けて一つのプログラムのバグを取った話だった。ストーリーの詳細は忘れたが重要なのはその時に僕が「今の自分ではその状況に耐えられない」と思ったことだろう。 6ヶ月の間、自分の作っているものが完成せず、あとどれくらいの時間をかければ完成するのかがわからない状況に耐えられるかどうか？ ふと思い出したのは、まったく別の人の話。ゲーム業界で働いている友人の友人で、自分の担当しているところはゲームのごく一部で全体像のどこを担当しているかわからない、達成感の得られにくい状態がかなり長い時間続く、そんな状況らしい。彼女がその状況にどう対処したかというと、余暇で「料理」という数時間で成果の出る作業をして達成感を得たんだそうな。ケーキを焼くなどの、自分の成長が認識できて、しかも数時間で終わるような作業をやることで精神を維持するんだそうな。 話をもとに戻
Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 - 西尾泰和のはてなダイアリー
はい、Ruby 1.9.2がリリースされましたね。このバージョンではWEBrick にゼロデイ攻撃可能な脆弱性 - スラッシュドット・ジャパンで紹介されている脆弱性が僕が書いたパッチで修正されているわけなのですけど、そもそもなんで僕が修正しているのか、って顛末がわりと面白いので紹介します。 Apple、upstreamに報告してくれないまま脆弱性をCVEに届け出る upstreamに連絡が来ないまま脆弱性が公開される ruby-devにAppleが書いたと思われるパッチが貼られる(Appleでない人間によって) パッチのライセンスが不明なので取り込めない ライセンスを問い合わせるAppleの窓口が不明なので問い合わせもできない ruby-devを読んだ人はライセンス上安全なパッチを書けない 脆弱性だから話は非公開に進めたい yuguiさんがruby-devを読んでない僕に書かせることにする
レバレッジメモ: レガシーコード改善ガイド - 西尾泰和のはてなダイアリー
レガシーコード := テストがないコード テストを作成するためには対象とするクラスから他のクラスへの影響を把握する必要がある。依存関係を排除しておけばニセのクラスを突っ込んで影響を直接観察できる。 テストをするたびに本番コードを編集するわけには行かない、なのでコードを編集せずにテストに不都合な挙動を変えられる場所が必要である。これをseamという。どのseamも、その挙動を変更するenabling pointを持っている。 日本語で「接合部」っていうとくっつけることに意識が向きがちだけど「そこで切り離せる」というほうが重要なのだな。 既存のレガシーコードに機能追加をする方法 1: スプラウトメソッド テストされてない既存のコードに書き足すのではなく、新しいメソッドを作ってそれを呼び出すようにし、その新しいメソッドにテストを書く 2: ラップメソッド テストされていない既存のメソッドの前か後
Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い - 西尾泰和のはてなダイアリー
ラボの昼休みに光成さん、中谷さんとご飯を食べながら話した内容を一応ざっくりとまとめておく。 発端はたしか最近Haskellを勉強の光成さんが、Haskellのかっこいいsieveは実はとても遅い(俺は Haskell の sieve についてとんでもない思い違いをしていたようだ...)という話を見て、同様にかっこいいけど遅い下記のフィボナッチ数列の定義の速度を調べてみたら2.5乗くらいのオーダーになっていたという話だったかと思う。 fib = 1:1:zipWith (+) fib (tail fib) 僕も確認するために、コマンドライン引数でNを与えられるフィボナッチ数列のN番目を求めるコードを書いた。 import System fib = 1:1:zipWith (+) fib (tail fib) main = do args <- getArgs print $ (0 *) $
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
