先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528

「Hooked ハマるしかけ 使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール」を読んだ。 サービスが「使われ続ける」ためには、顧客の「習慣」をいかにして作るかが重要だ。そこで「習慣が作られる過程」を以下の4つのフェーズで考えている。 トリガー アクション リワード インベストメント トリガー・アクション・リワードで行動が強化されるって話は心理学を学んだ人ならよく知っている話。スキナー箱の実験とかパブロフの犬とかを聞いたことがある人も多いのではないかな？ 僕もそこまでは知っていたのだけども、この本を読んで盲点に気づいた。これらの実験には当たり前だけどビジネスの視点はない。 ビジネス視点、つまり、自分が作ったサービスをユーザーに使ってもらおうと考えた時には、トリガーのコストが問題になる。トリガーは無償ではない。広告を打つのにもお金がかかる。そこで、ユーザが自分自身をトリガー

Qiitaとブログの違いがわからないと思ってたがだいぶ違うってことがわかった ブログでは記事に間違いがあった時にコメントで指摘して著者が修正するしかないが、Qiitaではプルリクエストを投げられる(投げてくれるかどうかわからないけど) 間違いがあって修正した時に、その記事を「ストック」している人に変更通知を飛ばすことができる Kobitoってアプリがあってローカルでリアルタイムmarkdownプレビュー Kobitoなら画像のアップロードもドラッグドロップでよい、Gistでは面倒 Emacsで編集してKobitoでリアルタイムプレビューも可 投稿データをJSONでダウンロードできる、他人のも テンプレートを作れるので社内Wiki的に同じフォーマットで複数の人が書く場合に揃えるのが楽 コメントを書いたりするのにgithubやQiitaのアカウントが必要なので非エンジニア避けになる 外に見えて

プログラミング作業を将棋に例えてみる - Yamashiro0217の日記 「考える負担を減らすことが重要」という点は、先日公開した講義資料でも強調したところ。人間は自分の能力を高めるために道具や言語や方法論を作り出してきたんだ。方向性は正しいはず。 一方でこのエントリーへの反論：道具に拘るエンジニアはだいたい無能 Googleなどの世界的な企業で活躍する、畏敬する人々は得意な道具こそあれ道具の差や環境の差で、パフォーマンスが落ちたりしない 「得意な道具こそあれ、道具の差でパフォーマンスが落ちたりしない」えっ、あなたの言う「得意な道具」ってのはそれを使ってない時とパフォーマンスが変わらないような代物なの？ 彼の言いたかったことは「すごい人は、得意でない道具を使っている時でもパフォーマンスが高い」なのかな。だとすると何と比べて『高い』と言ってるのだろう？彼は「道具にこだわっているけどパフォー

「自分の仕事を無断で中国に“アウトソーシング”していた従業員」が頭がいいとかなんとか話題になってたけど、給与水準の異なる国にアウトソースすることのメリットは8ヶ月前に発表した(アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-)し、会社の仕事を全部アウトソースすることのデメリットについても既に書いた(Yoshioriの質問に対する解答)ので、僕にとっては今更感が強い。 アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法- View more presentations from nishio で、仕事を中国にアウトソースした彼が頭がいいのかどうか、という話。無断で会社のVPNに接続させてただって？アホとしか言いようがない。全部丸投げ？問題にならないように切り分ける能力が欠如してたとしか思えない。いくらでも方法はあるのに。 具体的な戦術は、具体的な状況に依存するが、もちろん「上

昨日Pythonでメモリを食い過ぎた時に見直すポイントを書いたが、使ったツールの説明を忘れていた。 Guppy-PE: A Python Programming Environmentを使うとこんな感じの出力が得られる。 Partition of a set of 2330379 objects. Total size = 355901024 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 447287 19 125240360 35 125240360 35 dict of __main__.Node 1 53016 2 85891008 24 211131368 59 dict (no owner) 2 467204 20 66360776 19 277492144 78 str 3 457

ちょっと複雑なアルゴリズムをPythonで実装してみて、自分の予想以上にメモリを食ってしまったので何が原因なのかプロファイルしてみた。 辞書を大量に使ってはいけない 指摘されてみれば当たり前のことなんだけども、辞書はハッシュテーブルなのでメモリをたくさん使う。「グラフの頂点ごとに整数→整数のマッピングを持ちたいな」と思って、うっかり辞書を使ってしまったのだが、エントリー数が6個でも 1048バイト×頂点数 のメモリが吹っ飛んでいく。いくらハッシュのアクセスがO(1)だからといって、1048バイトmallocしてスラッシング起こしてんだったら全然安くない。エントリの個数とアクセス頻度によってはO(n)で線形探索したほうがよっぽどよい。 エントリーの個数が5件までならハッシュテーブルではないコンパクトな持ち方をするので280バイト。それでもでかい。 自作クラスのインスタンスも辞書を持っている

プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな 要約して「Xを学ぶべきだ」になる主張は、その主張が正しいかどうか聞き手が判断できない。Xについて知らないのだから、判断できるはずがない。 話し手も正しく判断できているかどうか怪しい。単に自分がXを学んだから、それが無意味だったと思いたくないがために「Xを学ぶべきだ」と思っているのではないか？これに答えるのは難しい。Xを学ぶ時間でYを学んだほうがよかったのでは？この質問には答えられない。Yを学んでいないのだから、判断できない。 だから「Xを学ぶべきだ」という主張は本質的に不毛なのではないか。代わりに「私はXに興味がある」「私はXを学ぶことが有益だと思っている」「私はXを学ぶこと自体が楽しい」「あなたが『Xなんか学んでも意味ないよ』と思うのであれば、どうぞご自由に。私は私のしたいことをするだけです」とでも言っ

この動画は一見の価値がある。英語にひるんで見ない人がいるともったいないので和訳した。(追記: これはバージョン3.0らしい。) (追記:字幕付きのバージョンがニコニコ動画で公開されました) 知っていましたか？ もしあなたが中国で「100万人に1人の逸材」なら… あなたみたいな人が国内に1300人います。 中国はまもなく世界一英語が話されている国になります。 インドの「IQが高い側から25%」は アメリカの全人口より多い。 つまりアメリカに生まれる全ての子供よりインドに生まれる優等生の方が多い。 知っていましたか？ 2010年に需要のある仕事上位10位は 2004年にはまだ存在していませんでした。 今私たちは学生を教えています。まだ存在しない仕事に備えて。 まだ発明されていない技術を使って まだ知らない問題を解く仕事に備えて。 米国労働省は今の学生は10〜14の仕事につくと推測しています 3

昨日Twitterでつぶいたことのまとめ。こういうアプリが既にあったりしないのかなぁ。既にあるなら喜んでそれを使うんだけど。あったら教えて下さい。 技術書と小説の違い 技術書の小説と大きく異なる点は、シーケンシャルアクセスじゃなくてランダムアクセスが必要になるケースが多い点だ。 小説のように頭から順に読んでいくのではなく「ざっくり眺めておいて必要なところだけじっくり読む」という読まれ方のニーズがある。 「ざっくり斜め読み」をどうやって電子ブックビューワ上で実現するか？ ページを画像として縮小しても漫画じゃないから「全く読めないゴミ情報」の山にしかならない。章タイトルだけ表示とか、太字や図などだけ表示とかが必要 ざっくり読んだ後の「あれどこに書いてあったっけ」支援のために検索とタグクラウド(検索キーワードのサジェスト)が重要 縦書きの対応は必要ない 理想を高く持つ 電子書籍ビューワはページを

作りたいもの: プログラミング言語のコア概念を学ぶサイト、その2の続編。 ブラウザの上で対話的にLISPのコードを実行できるサイトを作りました。 http://nhiro.org/learn_language/LISP-on-browser.html 現状ではまだ説明が足りないから、LISPをまだまったく知らない人がこのサイトを見て理解できるようになるかというと、そうではない。 TODO サンプルコードを1歩ずつ学べる粒度で用意する ツリーのリアルタイム可視化のコードとくっつける see 構文木を可視化するサイトを作った コードリーディングのための解説を書く 関連記事 ブラウザ上で演算子の優先順位と結合性を学ぶ

質問されてTwitterでつぶやいておいたので、流れ去らないようにここにまとめておく。 まず「25分で1ポモドーロだから8時間だと16ポモドーロか」とか言ってる人はそれが「人間は100メートルを10秒で走れるから、42キロを4200秒で走れるはずだ」と言うくらいおかしいということを理解した方がいい。短距離走の速度を長距離走で維持することはできない。そういう「1日8時間働く」を前提とした計算をしている人はポモドーロの「短時間に集中して成果を出そう」という目標をそもそも理解できていない。 これは僕流の解釈というわけではない。アジャイルな時間管理術 ポモドーロテクニック入門の前書きでも読んだことがあればすぐに誤解に気づくはずだ。こう書いてある。「1日に12ポモドーロ分はこなせるだろうと思っていました。しかし、ふたを開けてみると、せいぜい8ポモドーロが現実的なラインということがわかりました」(文意

増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったので早速やってみました。3つ目。 JavaScriptのコードの質を保つためのガードレール JavaScriptは柔らかい言語で、typoとか変数名の変え忘れが実行時までエラーにならない。しかもしれっとundefinedとかになって、そのままHTMLやSVGのpath文字列に埋め込まれてたりしてデバッグにコストが掛かってしまう。人間は間違える生き物だから、間違いをなくすことはできない。だから間違えた時になるべく早く気づけるようにする仕組みが必要だ。 Google Closure CompilerはJavaScriptのソースコードを静的に検証してエラーを報告してくれる。であれば自分がソースコードを編集している時にバックグラ

言語女子会: undefとnullは両方必要？、言語女子会2: varは必要？/privateがない？の続編です。 Rubyに恋愛相談 Python: 最近悩んでるのよね… Ruby: んー、何に？ Python: 自分はどんな人が好きなのかなぁ…とか… Ruby: あー、そんなの簡単よ！一緒にいて楽しいことよ！ *1 Python: そんなの誰とだって仲良くなったら楽しいんだから差別化にならないじゃん Ruby: そうとは限らないわよ、たとえば、あっ… C: ごめーん、会議が長引いちゃって遅れちゃった！(髪の毛ファサーっ) Python: ああ…なるほど… C C: 何の話？え、恋愛に悩んでる？そんなの簡単よ。卓越性よ。 Python: 卓越性？？ C: そうよ。なんらかの分野で「わたしが一番」という状況を作ることよ。そうすれば男の側からいくらでも寄ってくるわ。 Python: なるほど

言語女子会: undefとnullは両方必要？の続編です。 varは必要なの？ とあるプログラミング言語が集う女子会にて: Python: JavaScriptちゃんってさ、なんでvarだらけなの？ JavaScript: えっ、変？ Python: varなんかいらなくない？私ぜんぜん持ってないよ？ JavaScript: えー、じゃあ変数をどうやって宣言するの？ Python: 宣言っていうか…「x = 1」みたいな代入文があれば変数xが必要なのって自明じゃない？宣言とか必要？ Ruby: 必要ないよね。っていうか変数宣言とか古臭くない？ JavaScript: そうかなー。 Python: 少しダサイかも。ほら断舎離ブームだし要らないものは捨てなきゃ！ JavaScript: 要らないかなぁ、変数宣言。Pythonちゃんは関数がネストしているときに外側のスコープの変数に代入するのって

Pythonには "Zen of Python"という、Pythonの設計原則を簡潔に20個の格言にまとめたものがあります。それを単純に翻訳しても伝わりにくいだろうなぁと思ったので、訳注をたくさんつけて翻訳してみました。 美は醜より良い 明示は暗黙より良い 単純は複雑より良い 複雑なほうが理解しにくいよりは良い *1 平坦は入れ子より良い 疎は密より良い *2 読みやすさが重要 「特殊なケース」はルールを破るほど特殊ではない*3 しかし、実利は純粋さより重要 *4 エラーを黙って通してはいけない ただし、明示的に黙らせた場合は別 *5 曖昧さに面したら、正解を推測したくなる誘惑を退けよ *6 一つの明確なやり方があるべきだ。そしてただ一つであることが望ましい。 *7 しかし、その方法はオランダ人以外にはとっつきにくいかもね *8 今やる方がやらないより良い しかし、やらないほうが、今 *す

Twitterのタイムラインが面白すぎて、ついうっかり言語を擬人化して脳内で言語女子会なるものを開いてしまいました。なお、登場人物と実在の人物は1対1に対応しません。 undefinedとnullの両方必要なの？ とあるプログラミング言語が集う女子会にて: Perl: そういえばさ、なんでJavaScriptちゃんってundefinedとnullの両方もってるの？ JavaScript: えっ、未定義の変数にアクセスした時undefined返したいじゃない？ Python: 例外投げて死ねばいいじゃん Ruby: 例外投げて死ねばいいよね Python & Ruby: ねー♡ Java: いやそこは参照型ならnull、数値型なら0で初期化すべきでしょ C: これだから最近の若い子は…初期化にだってコストが掛かるんだからね！デフォルトで初期化するなんて無駄遣いよ！必要な人だけが責任をもって初

最近、3年くらい前に書いた「そろそろ例のプロジェクトについて言及するか」についてTwitterで言及があったので思い出しました。「条件を満たしたものをすべて呼び出す」という設計思想でプログラムが書けてしまうという点について意外とみんなピンと来ないみたいだからコンセプトプルーフを実装してみようと思っていたんでした。 という訳で作りました。https://github.com/nishio/genomy 解説 「遺伝子はタンパク質の設計図」というところまでは教科書などでもよく言及されます。でも、その設計図には「どういう状況になったら作るべきか」「どういう状況では作るべきではないか」という情報も書かれています。 この「作るべきではない」(発現の抑制)がどう実現されているか、ザックリ説明しましょう。体の中にあるタンパク質があると、これがある遺伝子の周辺にへばりつき、その遺伝子からタンパク質を作る過

バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間

by Lior Shapira under CC BY-NC-ND 2.0 このエントリーは新卒準備カレンダー 2011春という、みんなで仕事に関して自分が考えることなどをエントリーに書いていく企画で書かれたものです。 渋川さんの話を聞く会のつもりが、なぜかいつの間にか名前入りで「新卒準備カレンダー 2011春 : ATND」を作られていたので、空気を読まずに農業の話をします！！ お前だれよ？ 西尾泰和と申します。サイボウズっていうグループウェアの会社のサイボウズラボっていう研究部門子会社で、まあ研究とかをしています。一番最近のアウトプットはこのブログの右サイドバーに出ている「 Amazon.co.jp： WEB+DB PRESS Vol.60」で「言語設計の基礎知識」という特集を書いたことかな。そうそう、3年くらい英語版のプロフィールページしか更新していなかったら3年前の日本語版を最新版