「文字列を文字の列とみなす単純化」ってどういうこと？解説編 - 西尾泰和のはてなダイアリー
先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528
書評：アンダースタンディングコンピュテーション - 西尾泰和のはてなダイアリー
監訳者のささださんから「アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで」を頂いたので紹介。 「プログラムの『意味』とは何か？」という抽象的な問いに真っ向から挑む本。プログラムの「意味」には、「それによって計算機がどう操作されるか」で表現する方法と、「それを別の（もっとシンプルな）言語に変換するとしたらどうなるか」で表現する手法とがある。本書ではこの２つの手法があることを解説し、それぞれの手法について深堀りしていく。 「計算機がどう操作されるか」路線では、もちろん次に「『計算機』って何だ？」という問いに挑む必要性が出てくる。まずは能力の劣った計算機である「決定性有限オートマトン」から初めて、それが正規表現というある種のプログラミング言語とどういう対応の仕方をしているのかを解説するのにまる1章割いている。このストーリー仕立ては面白い。 その後、有限オートマトン
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
コード進行を五度圏で可視化してみた - 西尾泰和のはてなダイアリー
Songleの外部埋め込みプレイヤーがJavaScriptでカスタマイズできるので、それを利用して五度圏の可視化をするデモを作ってみました。 スピッツの「ロビンソン」 中島みゆきの「地上の星」 きゃりーぱみゅぱみゅの「ファッションモンスター」 ロビンソンはコードの動きがわりとおとなしいですね。一方ファッションモンスターはGm Fmを交互にピコピコ動いてダンスを見ているような楽しさが。 Songleは音楽の理解を支援するサービスで、楽曲からコード進行などの情報を抽出し、可視化したり、コード進行を強調して再生したりしてくれます。詳しくはSongleのサイトの解説をごらんください。外部埋め込みプレイヤーを使うと、JavaScriptからそのコードの情報が取れるようになるので、以前から興味のあった五度圏での可視化を試してみました。100行未満のソースコードで実現できてとても手軽でした。このデモのソ
「エンジニアの学び方」を執筆しました。 - 西尾泰和のはてなダイアリー
4月24日発売のWEB+DB PRESS Vol.80に、特別企画として「エンジニアの学び方」という記事を書きました。 Vol.80自体は4月発売ということもあって「新人さん大歓迎！」と銘打っています。「エンジニアの学び方」もこの4月に就職・進学をした人を想定読者にしています。ですが、きっとその他の人にも役に立つ内容だと思います。 この記事を書くきっかけとなったのは、ベストセラーにもなった拙著「コーディングを支える技術」のコラムです。余白があるからコラムを書けと言われて、学び方についてのいくつかのコラムを書きました。 p.23「理解を確認するためにはまずアウトプット」 p.26「何を学べばよいかがわからない理由」 p.79「具体的な知識と抽象的な知識」 p.80「噛み砕く」 p.82「必要なところからかじる」 p.134「おおまかにつかんで徐々に詳細化する」 p.235「端から順番に写経す
Qiitaの話を聞いている - 西尾泰和のはてなダイアリー
Qiitaとブログの違いがわからないと思ってたがだいぶ違うってことがわかった ブログでは記事に間違いがあった時にコメントで指摘して著者が修正するしかないが、Qiitaではプルリクエストを投げられる(投げてくれるかどうかわからないけど) 間違いがあって修正した時に、その記事を「ストック」している人に変更通知を飛ばすことができる Kobitoってアプリがあってローカルでリアルタイムmarkdownプレビュー Kobitoなら画像のアップロードもドラッグドロップでよい、Gistでは面倒 Emacsで編集してKobitoでリアルタイムプレビューも可 投稿データをJSONでダウンロードできる、他人のも テンプレートを作れるので社内Wiki的に同じフォーマットで複数の人が書く場合に揃えるのが楽 コメントを書いたりするのにgithubやQiitaのアカウントが必要なので非エンジニア避けになる 外に見えて
でかい企業のOSSがApache License 2.0だと嬉しい理由 - 西尾泰和のはてなダイアリー
「無期限で世界規模で非独占的で使用料無料で取り消し不能な特許ライセンスを付与します」という条項があるので使わせてもらう側が「わーい、便利なライブラリだー」と思って使っていたら後から「特許料払え！」と言われるという悲劇が起こらないことだって。 3. 特許ライセンスの付与 本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物を作成したり、使用したり、販売したり、販売用に提供したり、インポートしたり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与します。ただし、このようなライセンスは、コントリビューターによってライセンス可能な特許申請のうち、当該コントリビューターのコントリビューションを単独または該当する成果物と組み合わせて用いることで必然的に侵害されるものにのみ適用されます。あなたが誰かに
FPGAでライフゲームを作りました - 西尾泰和のはてなダイアリー
動画の内容 ランダムに初期化(see 線形帰還シフトレジスタ - Wikipedia) しばらく実行(高速モード：1ステップ3msec。VGA60Hzの画面の更新が17msecなので画面1回更新されるごとに5ステップ進んでいる計算) 画面をクリア、低速モード(256倍遅い)に移行 Rペントミノを配置するボタンを押す しばらく走らせる 高速モードに変える 実装 読み書き用のアドレスをインクリメントする 2行+3マス文の323bitのシフトレジスタに読んだデータをpushする(see シフトレジスタ - Wikipedia) シフトレジスタの0, 1, 2, 160, 161, 162, 320, 321, 322の9ビットを束ねてアドレスとし、ライフゲームのルールがハードコードされた512bitのROMから1bit読む 読んだ値をVRAMに書き込む 各1クロックでできるかな〜と思ったけども、
ArduinoでVGA信号を読む - 西尾泰和のはてなダイアリー
「VGA端子 - Wikipedia」を参考に、5, 6, 7, 8, 10ピンをGNDに、1, 2, 3ピンをそれぞれアナログピンに、13, 14ピンをデジタルピンに接続した。出力値が変動しているのを観察することができた。 ハードウェアをやる時も「早すぎる最適化は諸悪の根元」を唱えながらやるべきだな。ついついサイズを最適化したせいで半田付け大変だった。 横に伸びている3本はDisplay Data Channelとかいう、モニタのサイズや周波数を伝えるための信号線で、「繋がなくても大丈夫なはず、でも一番下の列だから『やっぱ繋がなきゃ』ってなったら後からハンダ付けは至難」と思って一応引っ張りだしておいた。結論から言うとこの3本はオープンなままで大丈夫だった。RGBの3本をアナログピンに、HSYNCとVSYNCをデジタルピンにつなぐ。 で、こんな感じのプログラムを走らせる。 void loo
ITにおける発明的問題解決の理論 - 西尾泰和のはてなダイアリー
「発明的問題解決の理論」(TRIZ)という、発明を「ひらめき」に頼るのではなく「既存の発明を集めたデータベースから類似の問題とその解決方法を探すこと」で効率化しようという方法論がある。 簡単に説明すると、解決したい問題を「強度は増やしたいが重さは増やしたくない」などの「特性の矛盾」として表現する。そして既存の特許情報から同じ問題を解決しているものを探し、参考にするという仕組み。特性を39個に分類し、39x39のマトリクスから解決の典型的なパターン40個を調べる「矛盾マトリクス」などの補助システムがある。 しかし作られた時代が古いため(1946〜1969)、その後発展した情報技術に関する特性が不足している。ディスク容量や回線速度なんかが属性のリストにない。ディスク容量を「体積」に相当するとみなしていいのか？回線速度は何に相当するのか？？ そういうわけで既存の「解決手法」を「何と何の矛盾を解決
「めんどくさい」「やる気がでない」時のチェックリスト - 西尾泰和のはてなダイアリー
「めんどくさい」「やる気がでない」にも色々なパターンがあります。そこで質問に答えていくと解決策にたどりつくようなチェックリストを作ってみました。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 Q1: やる気がでないのは今日に入ってからですか？ 数日やる気がでない状態が続いているのですか？それとも今日に入ってからかですか？ 今日に入ってから→Q2 数日続いている→Q8 Q2: 最近なにか新しい情報が明らかになりましたか？ たとえば計画段階では知らなかった事実が明らかになって、今までやってきた作業が無駄になったとか。何らかの情報が最近明らかになりましたか？ はい→状況が変わったのであれば、計画の通りに実行することが必要とは限りません。状況の変化に合わせて計画を変更したり中止したりしてはいけないのですか
リーンスタートアップ：レバレッジメモ - 西尾泰和のはてなダイアリー
「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす」のレバレッジメモ Q: 「需要がある」と「技術的に実現可能」のどちらの仮説を検証すべきか？ 「この製品を作れるか」ではなく「この製品を作るべきか」「この製品を中心に持続可能な事業が構築できるか」を問うべき(P79) コダックは次の4つの問いに答えることをチームに求めていると書いてある(P91) １：我々が解決しようとしている問題に消費者は気づいているか ２：解決策があれば消費者はそれを買うか？ ３：我々から買うか？ ４：その解決策を我々は用意できるか？ そして、1〜3を飛ばして4に進み、顧客が問題を抱えているかどうかを確認する前に解決策を作ってしまう失敗が多い、とも書いてある。 消費者が問題に気づいていない場合→「ファイルの同期はほとんどの人が存在に気づいていない問題だとドロップボックスでは考えていた」から製品を
LISPを学ぶサイトを作った - 西尾泰和のはてなダイアリー
作りたいもの: プログラミング言語のコア概念を学ぶサイト、その2の続編。 ブラウザの上で対話的にLISPのコードを実行できるサイトを作りました。 http://nhiro.org/learn_language/LISP-on-browser.html 現状ではまだ説明が足りないから、LISPをまだまったく知らない人がこのサイトを見て理解できるようになるかというと、そうではない。 TODO サンプルコードを1歩ずつ学べる粒度で用意する ツリーのリアルタイム可視化のコードとくっつける see 構文木を可視化するサイトを作った コードリーディングのための解説を書く 関連記事 ブラウザ上で演算子の優先順位と結合性を学ぶ
heXeを試してみた(jQueryのcssとclickを使ってみる) - 西尾泰和のはてなダイアリー
haXe(ヘックス)は静的型付け言語で、コンパイルするとJavaScript(とかいろいろな言語)ができるらしい。JSXをいじっていたら「コンパイルするとJavaScriptが出力される静的型付け言語にはhaXeもある」を教えてもらったのでこれも試してみよう。JSXでやった「型のことを全然考えてないjQueryを使ってクリックのハンドラを付けたり色を変えたりする」というのをゴールにする。 インストールする Download - Haxe インストーラをダウンロードして起動する。特に問題なくインストール完了。 ~$ haxe haXe Compiler 2.09 - (c)2005-2012 Motion-Twin Usage : haxe -main <class> [-swf|-js|-neko|-php|-cpp|-as3] <output> [options] Options : .
作りたいもの: JavaScriptのコードの質を保つためのガードレール - 西尾泰和のはてなダイアリー
増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったので早速やってみました。3つ目。 JavaScriptのコードの質を保つためのガードレール JavaScriptは柔らかい言語で、typoとか変数名の変え忘れが実行時までエラーにならない。しかもしれっとundefinedとかになって、そのままHTMLやSVGのpath文字列に埋め込まれてたりしてデバッグにコストが掛かってしまう。人間は間違える生き物だから、間違いをなくすことはできない。だから間違えた時になるべく早く気づけるようにする仕組みが必要だ。 Google Closure CompilerはJavaScriptのソースコードを静的に検証してエラーを報告してくれる。であれば自分がソースコードを編集している時にバックグラ
作りたいもの: プログラミング言語のコア概念を学ぶサイト - 西尾泰和のはてなダイアリー
増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったので早速やってみました。とはいえ、僕の『いつかやる』リストは一つのリストの要素に色々な設計やアイデアが書かれていて、全部一度に載せると読むのも大変。とりあえず1つ目だけ載せてみます。動機なんかを加筆。 プログラミング言語のコア概念を学ぶサイト 日本語や英語で書かれた解説を読むより、実際に動かしてみたほうがわかりやすいこともある。 しかし、広く使われている言語は既に長年の改良が繰り返されていて、改築・増築を繰り返した老舗旅館みたいに複雑なものになってしまっている。 学習のために、小さくシンプルな、全体像を理解しやすい、わかりやすく可視化された「言語の実装」が必要だ。 そんなものはすでにあるのでは？ かつて色々な方法で(Jav
言語女子会: undefとnullは両方必要？ - 西尾泰和のはてなダイアリー
Twitterのタイムラインが面白すぎて、ついうっかり言語を擬人化して脳内で言語女子会なるものを開いてしまいました。なお、登場人物と実在の人物は1対1に対応しません。 undefinedとnullの両方必要なの？ とあるプログラミング言語が集う女子会にて: Perl: そういえばさ、なんでJavaScriptちゃんってundefinedとnullの両方もってるの？ JavaScript: えっ、未定義の変数にアクセスした時undefined返したいじゃない？ Python: 例外投げて死ねばいいじゃん Ruby: 例外投げて死ねばいいよね Python & Ruby: ねー♡ Java: いやそこは参照型ならnull、数値型なら0で初期化すべきでしょ C: これだから最近の若い子は…初期化にだってコストが掛かるんだからね！デフォルトで初期化するなんて無駄遣いよ！必要な人だけが責任をもって初
他の言語に慣れた人が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
講義資料「テストとデバッグ」を公開しました - 西尾泰和のはてなダイアリー
昨年行われたセキュリティ＆プログラミングキャンプ2011で中学生〜大学生を対象として行った講義「テストとデバッグ」の発表資料を公開します。 テストとデバッグ View more presentations from nishio
遺伝子をモチーフにした言語「Genomy」を作りました - 西尾泰和のはてなダイアリー
最近、3年くらい前に書いた「そろそろ例のプロジェクトについて言及するか」についてTwitterで言及があったので思い出しました。「条件を満たしたものをすべて呼び出す」という設計思想でプログラムが書けてしまうという点について意外とみんなピンと来ないみたいだからコンセプトプルーフを実装してみようと思っていたんでした。 という訳で作りました。https://github.com/nishio/genomy 解説 「遺伝子はタンパク質の設計図」というところまでは教科書などでもよく言及されます。でも、その設計図には「どういう状況になったら作るべきか」「どういう状況では作るべきではないか」という情報も書かれています。 この「作るべきではない」(発現の抑制)がどう実現されているか、ザックリ説明しましょう。体の中にあるタンパク質があると、これがある遺伝子の周辺にへばりつき、その遺伝子からタンパク質を作る過
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
