量子将棋が面白い - 西尾泰和のはてなダイアリー
量子将棋というゲームが遊べるようになったということで、さっそくプレイしてみた。ルールは簡単に言うと、すべての駒は量子的な重ね合わせの状態にあり、どう動かしたかによって駒の状態が収束する。王将に収束した駒を取れば勝ち。(追記: ルールの解説書きました: 量子将棋 Q&A) 2勝2敗で結構面白かったので流れ去ってアクセスできなくなる前に感想をメモ。 1回目(勝ち) 棋譜: http://shogitter.com/kifu/884 僕の戦略 駒の種別が確定すれば取れる選択肢が減る。ということは必要がない限り駒は動かないほうが良い。動かさなければいけないのであれば歩の振りをするのが一番可能性が狭まらない。 王将に確定した駒を取れば勝ちなのであれば、相手の「王将かもしれない駒」をどんどん取って行って可能性を狭めるべき。 感想 駒の上にマウスポインタを置くと可能性のある駒の種類が出てくる 飛車を取る
「めんどくさい」「やる気がでない」時のチェックリスト - 西尾泰和のはてなダイアリー
「めんどくさい」「やる気がでない」にも色々なパターンがあります。そこで質問に答えていくと解決策にたどりつくようなチェックリストを作ってみました。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 Q1: やる気がでないのは今日に入ってからですか？ 数日やる気がでない状態が続いているのですか？それとも今日に入ってからかですか？ 今日に入ってから→Q2 数日続いている→Q8 Q2: 最近なにか新しい情報が明らかになりましたか？ たとえば計画段階では知らなかった事実が明らかになって、今までやってきた作業が無駄になったとか。何らかの情報が最近明らかになりましたか？ はい→状況が変わったのであれば、計画の通りに実行することが必要とは限りません。状況の変化に合わせて計画を変更したり中止したりしてはいけないのですか
他の言語に慣れた人が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
もっとよいGitチートシート - 西尾泰和のはてなダイアリー
世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが
日本人なら必ず誤訳する英文 - 西尾泰和のはてなダイアリー
本屋で立ち読みしてて「英語を正しく理解しているかどうかを知るには訳してみるしかない。『英語を英語のまま理解する』とよく言われるが、それはあくまで最終目標であって、正しく日本語に訳せない文章は絶対に理解できていない。」ということが書いてあって、納得したので買ってきた。越前敏弥の日本人なら必ず誤訳する英文 この本の著者はダヴィンチコードとか訳している人で、十数年英語を教えてきてて、みんながつまづくパターンを集めたらしくてかなり密度が高い。あと、自然言語って冗長性が高いからおおざっぱな理解で問題ないケースも多いんだよね。だから土台がシロアリに食われているのに気付けない。こういう本で「ああ、この英文はこうだろ？」と訳してみて「いや、それはよくある間違い」ってつっこまれないと自力で気付くのは難しい。 I bought the book, which I have not read yet. これを間
「プログラミング言語を理解するにはどうしたらいい？」という話を聞いて思うこと - 西尾泰和のはてなダイアリー
「プログラミングとか特定のプログラミング言語とかを習得したくて色々勉強したけど、いまいち理解できた感じがしない、何がいけないのだろう、何を学べばいいんだろう」という話を聞いて思ったこと。 それって、目的が曖昧だから達成感が得られないというだけじゃないのか？ 僕の今までの人生の中には「プログラミングを習得した！」と思える瞬間も「Pythonを理解した！」と思える瞬間もなかった。具体的な「Pythonで継続のある言語を実装できた！」とかならある。でも「継続の概念を完全にマスターしましたか」と言われるとそんな気はまったくしない。まだまだ先は長い。しかし僕よりはるかに継続に詳しい人たちが集まって継続に関する議論をしてたりするのを見ると、この道に明確なゴールはないことがわかる。どこまで行っても「まだ先がある」という感じが残るに違いない。 手段が間違っているのではなく、目的が間違っているんだ。「○○を
そろそろ例のプロジェクトについて言及するか - 西尾泰和のはてなダイアリー
以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
