「文字列を文字の列とみなす単純化」ってどういうこと？解説編 - 西尾泰和のはてなダイアリー
先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528
例えば「写経」という言葉を避けてみる。 - 西尾泰和のはてなダイアリー
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。 ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。 プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」を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「端から順番に写経す
U理論が面白い - 西尾泰和のはてなダイアリー
U理論の本を流し読みしてたけど、これは結構面白い。 PDCAサイクル(計画→実行→評価→改善)は、既にサイクルが回っている人にとっては納得感があるのだろうけども、回ってない人にやらせようとすると「で、計画はどうやって立てるの？」で悩んで止まってしまったり、逆に問題に対する知識が不足してる可能性に無自覚なまま、詳細すぎる計画を立ててしまって、後からわかった情報で瓦解したりする。 科学的思考法の「仮説→実験→検証→修正」のサイクルでも、流行りのリーンスタートアップの「仮説検証のサイクルを高速に回せ」でも、やっぱり実際にやろうとすると「で、仮説はどうやって見つけるの」というところでつまずく人がいる。 この手の「サイクル」に入る手前でつまずいている問題について、僕はいままで「まず観察を」と言ってきたのだけど、U理論はこの部分を7段階に分けて考えている。 一つ目は、物事を既成概念に当てはめて見ている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
