何をどう学ぶか？ from nishio 「コーディングを支える技術」を執筆している時に考えていたことをスライドにまとめました。

あるブログが「写経には効果がない」という趣旨のことを書いていて「何を言ってるんだ？」と思いじっくり読んでみたら、彼の言う写経は「動くとわかってる10000行のコードを何も思考せず作業として書き写すこと」を指しているようだった。「そんなわけないじゃん」と笑ってから「もしかして世の中は写経をそういう捉えてるのか？」と不安になった。 写経は自分の中にモデルを作るための行動で、他のもっと効率のよい方法と比べた場合の利点は「自分の中にモデルがなくても使える」点に尽きる。全く知識ゼロでいきなり「自分で考えて書く」ができる人はいない。考えるための材料となる知識をまず脳内に運び込む、それが写経だ。 写経の過程で大事なことは以下の3つだ。 1: 早く学びが得られるように、なるべく小さいコードで実験し、すぐに結果を確認する。 2: 疑問に思ったこと、考えたこと、気づいたことを書き留める。どうしてこういう書き方

「めんどくさい」「やる気がでない」にも色々なパターンがあります。そこで質問に答えていくと解決策にたどりつくようなチェックリストを作ってみました。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 Q1: やる気がでないのは今日に入ってからですか？ 数日やる気がでない状態が続いているのですか？それとも今日に入ってからかですか？ 今日に入ってから→Q2 数日続いている→Q8 Q2: 最近なにか新しい情報が明らかになりましたか？ たとえば計画段階では知らなかった事実が明らかになって、今までやってきた作業が無駄になったとか。何らかの情報が最近明らかになりましたか？ はい→状況が変わったのであれば、計画の通りに実行することが必要とは限りません。状況の変化に合わせて計画を変更したり中止したりしてはいけないのですか

「原稿書かなきゃいけないんだけどなぁ」とか言いながら現実逃避で読んでいた本「心は病気―役立つ初期仏教法話〈2〉」に心に刺さる言葉があったのでここに書いておく。 正確な引用ではないので、正確な言葉が知りたければP.60から3ページくらいを読むとよい。 人間が自信をなくす原因は、自信の持ちすぎである。 自分が「この程度の仕事サクッと終わらせられる」と思っているのに、実際にやるとうまくいかないとき、人は自信をなくす。 「抜群のスピーチをしよう」と思って、実際にはうまく喋れなくて、自信をなくす。 妄想の中の自分が事実に反して素晴らしすぎるから、その「妄想の中の素晴らしい自分」が振る舞うように振舞おうとして、できないので苦しむ。 「自分の仕事に自信がない」というのは、奇跡的な成功を頭で妄想しているせい。現実の自分ができるようにしかできない。できることをすればよい。「自分は精一杯やった」と思える状態を

妻が読んでた 「考えない練習」がタイトルからの予想に反してかなり良い本だった。今までのタスク管理とか生産性向上ライフハックとかには、脳に対しての刺激を増やす方向のものが多い。それは結局はストレスとして積み上がってしまう。それでは一時的に生産性が上がってもやがて息切れしてしまう。ストレスを減らすためにはどうするか、を考えることが生産性の向上には必要。 集中力が落ちた時の対策に、僕はアップテンポな曲を聞いたりカフェインを摂取したりという「刺激を追加すること」が多いけど、これは筆者に言わせれば苦(ストレス)を増やしている。心が平穏であることを願うなら、強い刺激を追加するのではなく既に感じているのに無視している感覚に注意を向けるほうがよい。たとえば、指がキーボードに触れている感覚に集中するとか、自分の呼吸に注意を向けるとか。集中の前にまず心を穏やかにする。 外部からの刺激などに心が無意識に反応して

今日質問されて、以前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

以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに

この本は人間の絶望・無気力・おっくうの原因の解説書ではない。無気力になる傾向を持つ人が、どうやってそこから抜けだして元気に生きられるかという本である。無気力になる傾向を持つ人には私も入っている。 この記事は筆者の『「やる気がでない人」の心理学』を読んだ際の読書メモです。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 セリグマン本人が書いた本(の翻訳)としては世界でひとつだけの幸せ―ポジティブ心理学が教えてくれる満ち足りた人生とかがいいのかな。 前回、同じ著者(加藤諦三)の不安のしずめ方 40のヒント(レバレッジメモ)を読んで意外とよかったので別の本を買ってみた。「やる気がでない人」の心理学 セリグマンの論文から引用しつつ、人間が無気力になる原因などについて解説した本。セリグマンの元々の実験の話が明

学び方を学ぶ --- 2011-05-14 - 未来のいつか/hyoshiokの日記 良いエントリーなんだけど1点気になるところがありました。 常に新しいことを何らかの形で学んでいく事が運命づけられているのがIT産業なのかもしれない。 よく言われるフレーズではあるのですけど、これを読んで「そうか、IT産業は大変そうだからやめておこう」とか誤解する人が出てももったいないかと思いました。IT産業がすべて「学び続ける必要」があるのか？IT産業でなければ「学び続ける必要」はないのか？今日はそこのところについて書いてみようと思います。 まず、資本主義ってのはなんだったのかおさらいしてみましょう。例えば糸紡ぎの仕事は最初は家庭内で小さな紡ぎ車を回していました。しかし技術の進歩によって「もっと効率よく糸を紡ぎ出すことが出来る機械」が発明されました。家庭で人力の紡ぎ車を使って糸を作るよりも、その機械を使っ

世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが

Twitterより転載 ポモドーロの肝はPDCAのCの部分だと思う。僕が割り込みの比較的少ない職場なのになぜプラン通りに作業ができていないのかをチェックするには割り込み頻度にフォーカスしたレコードでは足りなくて、ポモドーロ終わったのに作業を続けてしまうとか、タイマー付けずに作業しちゃうとかも計測されるべき 何をレコードすべきか ここしばらくポモドーロ作業をしていて起きた割り込み 地震 話しかけられる 一日平均1回未満だと思う。きっと割り込みの少ない職場のはず。だから僕の生産性向上に関しては割り込みを減らすことより、もっと別の注力すべき課題があるはず。 バッドパターン タイマーを回さないで作業をして、カウントされるべきポモドーロがカウントされない 休み時間に調べ物をしていたら、そのまま作業に移行していて1ポモドーロくらいの時間を使っていたが計測していない 休み時間の調べ物が予想以上に手間取っ

最近まわりで実践している人が多いので「アジャイルな時間管理術 ポモドーロテクニック入門」を買ってみた。 一番目立つ特徴はキッチンタイマーを使って時間を区切ることで一定時間集中するって所だろうけど、まあこれは昔から知的生産性の向上に興味のある人にとっては目新しい話じゃないよね。1992年発行の知的生産性向上システムDIPS(ディップス)でも言及されているくらい昔からある発想だ。 他にも本書には他にも昔からよく知られているいろいろなテクニックが入っている。 タスクレビューが重要 やることのコミットメントが重要 PDCAサイクル 大きすぎるタスクは分割せねばならない タスクに掛かる時間を見積もること、見積が正確であったかどうかのチェックをして見積能力を鍛えること タスクリストが長くなりすぎると見るだけでやる気がなくなってしまう、短く保たねば などなど。 しかしこういうことを頭で知ってはいるのに、

Twitterだと流れ去ってしまうのでまとめて転載 nishio みんなソースコード読むときは何を使っているのかな？ shibukawa grepとテキストエディタと、自作のログ出力デコレータ(Python限定)あたりかな？大したことしてないです。 hmori 色々ツールはあるけれど、別の意味で便利だったのはTextMate (OSX シュアウェア) プロジェクトを作ってプロジェクトフォルダーに放り込むだけでソースコードファイルがtreeで見られてクリック１つで開く。まあそれだけだけど。 voluntas vim と ctags くらい。 kumarobo less(lv), cat -n, grep, emacs(xyzzy) あたり。うっかりvisual studio起動することもあるけど jmuk テキストエディタやgrep、viewsvnなど以外だと、globalとかかなぁ。 ug

初めての人のためのLISP[増補改訂版]を読んだ。 「こう書けた方が自然だから、そう書けるという約束にしよう（約束なんていつでもできる！）」(p.60)とか 「一時的なメモ用紙だの、束縛だのという苦し紛れの言葉や概念を持ち出したのは、人間にとって自然なモジュール性を保証するためのメカニズムを理解するためにやむを得なかったから」(p.64)とか 「再帰呼び出しだけをことさらに強調してLispの特徴だと言うのは間違っている」(p.91)「美しいということと、実用的価値が常に一致しているとは限らん」(p.107)とかとか この本は初めてプログラミングを学ぼうとする人が、間違った教科書に触れてダークサイドに落ちないために、最初に読むべきプログラマの思想書なのかもなーと思った。 世の中にはいろんな種類の間違った教科書がある。 「こう書くのが正しいのです。そういう決まりなんです。なんで？じゃありません

5分でわかる Python を知らない人が Python の便利さを学べる記事をかいたよ | HIROKI.JPが、Pythonの説明なのにところどころ「Rubyでは」になっていたり、そもそも無理やりPHP的なことをしようとしていていまいちなのでTwitterでひどいなぁと言っていたら @bellonieta: ここは是非とも@nishioさんに正しい5分記事を書いてもらいたいところ… と言われてしまった。まー、ぼやくのは生産的じゃないからねぇ。Pythonを使ってて色々便利なことはあるけど、一番手軽そうなものを軽く説明してみよう。たとえばなんか書類をつくっているとするじゃない、こんな感じの。 社長: 山田太郎 支社長: 田中一郎 部長: 山川三郎面倒なので3人分しか書いてないけど本当はもっとたくさん30行くらいあるとしよう。さー書けた、と思ったらそこに上司が来て「あーあー、そうじゃないよ

プログラミング言語は人が作ったもの。人は誤るもの。なので完璧なプログラミング言語は存在しない。 「人は誤るもの、しかし誤りに固執するのは馬鹿の所業だ。」(キケロ) プログラミング言語も、間違った設計をして、馬鹿でない人がそれを修正することの繰り返しで発展してきた。 というわけで言語間での設計判断の食い違いとか失敗した設計とかを収集中。一部抜粋して講義資料に入れるつもりなので他の事例をご存知でしたらぜひ情報をいただけるとありがたいです。 if(x = 0) C言語では代入が式であるためif(x == 0)のつもりでif(x = 0)と書いてしまい、常に偽になってしまう。 x = 0の値はint、条件式はboolでないといけないので型エラーだよ派: Java x = 0は式ではないので条件式に入れたら構文エラーだよ派: Python 条件式にx = 0をいれたらx == 0と解釈するよ派: H

ルール原文: http://www.silcom.com/~tomjolly/pnrules.htm チャット: http://www.lingr.com/room/programmers_nightmare プログラムをコントロールするゲーム(Ver.2では作っていく) 10点からスタートして20点になったら勝ち、0点になったら負け 「コントロールトークン」(Bit)を全部失っても負け Ver.1の方がルールを学びやすいが、より戦略性が問われる(じゃあそれでいいじゃん。以下Ver.1についてのみ記述する) まず次のカードをデッキから取り除くthe Break (3枚), Run (4), Secret (2), Insert (1)。Ver.1では使わない。 カードにはいろいろな命令が書かれていて、最初にそれが表向きに机の上に円形に配られる。これがプログラム。 その上に各プレイヤーが「B