僕は結城さんのことが好きなんだなぁ - 西尾泰和のはてなダイアリー
僕は結城浩さんのことが好きなんだなぁ。彼の書いた「文章を書く心がけ」は自分が執筆をするときにも何度もお世話になった。彼の日記などに時々かいま見える「読者によりよいものを届けよう」という真摯な態度には好感を感じる。以前の僕は宗教と名の付くものが全て嫌いだったのだが、敬虔なクリスチャンである彼の日記を読んでいるうちに、その嫌悪感が軽減した。結局のところ、どんな集団にもいい人もいればわるい人もいるということなんだ。 では、わるい人に対してどう対処するのがよいのか。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 なるほどね。400年も経つけども、人間の社会はあんまり変わって
プログラミングシンポジウムでの情報教育の議論について - 西尾泰和のはてなダイアリー
今年のプログラミングシンポジウムの夜のセッションでは情報教育についての熱い討論が行われました。その場で出た「この議論に関してブログなどに書くことは有益」という意見に賛成なのでこの記事を書きました。 手段の良しあしを議論するためには、まず「その手段を行うことでで達成したい『目的』は何なのか」が明確である必要があります。そうしなければ「手法Xは(目的Aのために)有益だ」「いや、手法Xは(目的Bのためには)有益ではない」という無意味な水掛け論につながるからです。 以前、首藤先生が指摘されたことですが、プログラミング教育の目的は少なくとも3つあります。「プログラミングのやり方の教育」「コンピュータ科学教育」「プログラミング行為の楽しさの伝道」です。 「『プログラミング教育』とひとくくりにされていて、違いが認識されていないことは、不幸のもとかもしれない」(首藤先生) この意見に私も賛成です。 2番目
正統的周辺参加論が生まれるまでの心理学の流れ - 西尾泰和のはてなダイアリー
Facebookに書いていると「この前メモしたアレをもう一度見たい」と思ったときに検索でヒットしなくて不便なのでこちらに転載。 - 今回の「組織科学」が「現場における学習」特集で、佐伯胖による記事が載っていて、イリイチのコンビビアリティの概念が出てきて、最終的に学ぶとは他者とコンヴィヴィアルな関係を生み出すことだ、と結論している。面白い。 組織科学 Vol.48 No.2 pp.38-49 佐伯胖 "そもそも「学ぶ」とはどういうことか：正統的周辺参加論の前と後" 正統的周辺参加論が生まれるまでの心理学の流れと、その後の変革の可能性についての話。 1913年にWatsonが「行動だけに注目したら心理学も自然科学になる（逆に言えばそれ以外は科学じゃねーよ）」と言ってから心理学は行動主義の全盛時代になった。この時代の考え方は「行動が起きた直後に報酬を与えたらその行動が強化される」（オペラント条件
Facebookに書き続けることは損失なのではと思い始めた - 西尾泰和のはてなダイアリー
ブログの更新頻度が落ちてるのは、Facebookに書いた方が有益なフィードバックの頻度が高くて、ついついそっちに書いてしまうから。 そうやってFacebookにばかり書いていると「あれ、この前Facebookに認知心理学が生まれてきた流れについて書いたと思うんだが、あれどこだったかな、参考にしたいのだが…」なんてことが起こるようになってきた。以前であれば、だいたいそういうのは自分のブログに書いているので、Googleに行って「西尾泰和 認知心理学」とかで検索すればすぐ見つかった。しかしFacebookに書いたものはそういうわけにはいかない。 で、発掘するのにすごく時間がかかったり、発掘できなくてあきらめてしまったりする。これってものすごい損失なのではないか？クロールして手元に保存して検索できるようにする必要があるのではないか？ そしてそのクロールもまた手軽ではない。エクスポートの機能はある
「キャリア戦略論 - 人・生き方・働き方の多様性」講義資料を公開しました - 西尾泰和のはてなダイアリー
10月19日に灘校土曜講義にて、キャリア戦略に関して多様性にフォーカスして1時間半の講義をしました。講義資料を一部公開します。 参加者のみなさんがアンケートに書いてくれた感想は、全部目を通しました。一点、僕がうまく伝えられてなかったらしきところがあるのでここで補足します。 「マジック・ザ・ギャザリング」と「プログラミング」のどちらがよいか 「マジック・ザ・ギャザリングに時間をさくよりプログラミングを学ぶべきという趣旨か？」という質問がありました。いいえ、違います。 中学高校時代の時間を投資する対象として「マジック・ザ・ギャザリング」(MtG)が「プログラミング」よりも劣ると主張したようなとらえられ方をしてしまったようですが、そう主張したいわけではありません。僕がプログラミングに時間を投資したのは「将来役に立つ」とおもったからではなく、単にそれが楽しかったからです。MtGに投資している人も、
トレイトを勉強していたらクラスの定義の食い違いに気づいた話 - 西尾泰和のはてなダイアリー
以前自分が書いた記事Scalaのtraitはmixinか？を元に、トレイトに関する補足記事を書こうとして「そうだ、どうせならば元論文の記述とも照らしあわせたほうがよいな」と「Traits: A Mechanism for Fine-grained Reuse」を読んだ。そこで気づいたのだけども、この件に関して意見が咬み合わないことがあるのは、そもそも「クラス」の定義に食い違いがあるせいではないか？ 「Traits: A Mechanism for Fine-grained Reuse」での定義ではクラスとは「空クラスnil」もしくは「属性の集合と、メソッドの集合と、親クラス」と定義されている*1 で、トレイトとは「メソッドの集合」と定義されている*2 これがどういうことかというと、トレイトなどから作られたクラスは「自分を構成するのにどういうトレイトが使われたか」という情報を持たないってこと
何をどう学ぶか？ - 西尾泰和のはてなダイアリー
何をどう学ぶか？ from nishio 「コーディングを支える技術」を執筆している時に考えていたことをスライドにまとめました。
プログラミング学習手段としての写経について - 西尾泰和のはてなダイアリー
あるブログが「写経には効果がない」という趣旨のことを書いていて「何を言ってるんだ？」と思いじっくり読んでみたら、彼の言う写経は「動くとわかってる10000行のコードを何も思考せず作業として書き写すこと」を指しているようだった。「そんなわけないじゃん」と笑ってから「もしかして世の中は写経をそういう捉えてるのか？」と不安になった。 写経は自分の中にモデルを作るための行動で、他のもっと効率のよい方法と比べた場合の利点は「自分の中にモデルがなくても使える」点に尽きる。全く知識ゼロでいきなり「自分で考えて書く」ができる人はいない。考えるための材料となる知識をまず脳内に運び込む、それが写経だ。 写経の過程で大事なことは以下の3つだ。 1: 早く学びが得られるように、なるべく小さいコードで実験し、すぐに結果を確認する。 2: 疑問に思ったこと、考えたこと、気づいたことを書き留める。どうしてこういう書き方
Squeakをかじる その4 - 西尾泰和のはてなダイアリー
前回(その3)、Traitの挙動をSqueakのGUIを使わずに試すところまでやりました。その時に動いたコードがこちら： https://github.com/nishio/learn_language/blob/master/squeak/test_trait.st 今回は、そのトレイトを複数にして、2つあわせてクラスからusesできることを確認しようとしました。コードはこちら： https://gist.github.com/nishio/5098115 これはSqueakのGUI上で1文ずつ実行すると期待通りの挙動をするのですが、スクリプトとしてSqueakに渡すと「InMidstOfFileinNotification」というエラーが起きてしまいます。うーん、どういうことなんでしょう。ググってもよくわかりません。 お、例外をキャッチするための囲み(下記)を削ったら動くようになりまし
Scalaのtraitはmixinか？ - 西尾泰和のはてなダイアリー
Rubyのmixin(モジュール)、Squeakのtrait、Scalaのtraitそれぞれについて： Q1: メソッドの実装を持てる？ はい、はい、はい Javaのクラスは「はい」、インターフェイスは「いいえ」、C++とPythonのクラスは「はい」 Q2: クラスがそれを複数個継承できる？ はい、はい、はい Javaのクラスは「いいえ」、インターフェイスは「はい」、C++とPythonのクラスは「はい」 Q3: インスタンスを作れる？ いいえ、はい、いいえ C++とPythonのクラスは「はい」 Q4: 複数個継承した際に名前が衝突しました、どうなる？ しれっと上書き、エラー(*)、エラー (*) Squeakはクラス定義時には例外を投げず、衝突したメソッドを「衝突した旨の例外を投げるメソッド」に置き換える。ユーザが衝突に気づくのは、クラスブラウザでメソッドを確認した時か、そのメソッド
やる気エンジニアリング - 西尾泰和のはてなダイアリー
やる気を出すための未整理リスト その「やる気のなさ」は急性か慢性か？急性なら体のコンディション不良を疑うとよい(2011-09-09追記) 糖分を取らずに12時間くらい経つと体調が悪くなってやる気が出なくなる。空腹感を感じたときに食事をとらないと空腹を感じなくなって「なんかやる気が出ない」「なんとなくだるい」とか感じる。 気密性の高い部屋で長時間換気をせずにいると酸素濃度が下がるのかだるくなってやる気がなくなる気がする。換気をするとよい。換気と無関係にじっと座っていることによっても似たような症状が出る。これは散歩などの有酸素運動をすればよい。(2011-10-20追記) 冷房をつけるべき気温なのに気付いていなくて体温が異常に上がっている。軽い脱水症状を起こしている。 体温が下がり過ぎて眠い。温めると直ることがある。(2010-12-30追記) 体温が下がりすぎて肩こりが起き、それが原因で頭
「めんどくさい」「やる気がでない」時のチェックリスト - 西尾泰和のはてなダイアリー
「めんどくさい」「やる気がでない」にも色々なパターンがあります。そこで質問に答えていくと解決策にたどりつくようなチェックリストを作ってみました。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 Q1: やる気がでないのは今日に入ってからですか？ 数日やる気がでない状態が続いているのですか？それとも今日に入ってからかですか？ 今日に入ってから→Q2 数日続いている→Q8 Q2: 最近なにか新しい情報が明らかになりましたか？ たとえば計画段階では知らなかった事実が明らかになって、今までやってきた作業が無駄になったとか。何らかの情報が最近明らかになりましたか？ はい→状況が変わったのであれば、計画の通りに実行することが必要とは限りません。状況の変化に合わせて計画を変更したり中止したりしてはいけないのですか
リーンキャンバス：レバレッジメモ - 西尾泰和のはてなダイアリー
リーンキャンバスに関するレバレッジメモ ■ビジネスモデルの仮説検証のためのリーンキャンバス 仮説を立てる際に、WHAT、WHO、HOWで考えている。 1: WHAT: 問題 自分が解こうとしている問題は何か 2: WHO: 顧客 誰がその問題を抱えているのか 3: HOW: 製品/市場 どうやってその問題を解くのか 市場はどれくらい大きいのか(how big) どうやって顧客にリーチするつもりか どうやって需要をかきたてるのか どうやってお金を儲けるのか リーンキャンバスに書いていく順番(筆者の好きなもの) 1: Problem: 問題: 解こうとしている問題トップ3 2: Customer Segment: 顧客: 誰が顧客か？それをもっと細かく分割できるか？もし複数のセグメントがあるなら、それぞれについてキャンバスを作るのがオススメ。 3: Unique Value Propositi
git(VCS)の未来について - 西尾泰和のはてなダイアリー
gitが素晴らしいとか自由度が高すぎてわかりにくいとかUIが酷いとか色々議論になっているけど、ちょっと歴史を振り返ってみると 1990 CVS 2000 Subversion 2003 SVK = Subverionをラップして分散バージョン管理に対応 2005 Git 2008 GitHub = Gitをラップして「ワークフローを限定してわかりやすく」 2010 gitflow = Gitをラップして「ワークフローを限定してわかりやすく」 2012 今ここ と進んできているんだからきっと2020年頃には GitHubやgitflowのような「ワークフローを限定してわかりやすくしたバージョン管理」がメジャーになってますよ。 近いうちに、かつて「svnは小学生までだよね、これからはSVKだよ」と言われたように「Gitを生で使うなんて小学生までだよね」と言われるようになり、 次に、かつて「SV
5分でポモドーロが終わってしまったらどうするか - 西尾泰和のはてなダイアリー
PySpaに行く車の中でid:Yoshioriと話していた内容の続きをTwitterに書いたので、流れ去らないようにブログに転載 1ポモドーロ未満で作業が終わって余ってしまった時に何をするかって話、自分の過去ブログを見ても何度も質問されてた。原著では「やったことの見直し」「学んだことの繰り返し」「仕事の改善方法を考える」「結論のメモをする」などが挙げられている。 多分著者は「25分掛かると思ったタスクが5分で終わる」という事態は想定していないのでは。25分のタスクが22分で終わったとかなら、残りの時間をそういう方法で使うのはまだイメージできるし、勉強のようなインプットのタスクなら残り時間に繰り返すこともできる。 だけどもデバッグみたいな「見積りが困難なタスク」で5分で終わって20分余ってしまった時に、その場で20分使うような新しいタスクを考えて残り時間を「潰す」のは正しくないように思う。そ
ポモドーロテクニック入門：レバレッジメモ - 西尾泰和のはてなダイアリー
「アジャイルな見積りと計画づくり」を読んでから「アジャイルな時間管理術 ポモドーロテクニック入門」を読みなおしてみたら、色々新たな発見があったのでレバレッジメモを作りなおしてみた。 4章以降は読みなおしてみてもあまり面白くなかったので割愛。 前書き 当初は1日に12ポモドーロくらい出来るだろうと思っていたが、現実的には8ポモドーロがせいぜいだった。 ScrumやXPなどでは「イテレーションあたりどれくらいの仕事を完了させたか」を計測する(ベロシティ)。ポモドーロでは1日に「完了させたポモドーロの数」(=連続して25分間集中できた回数)を計測する。ポモドーロは「集中することに集中する」方法論。 1章: 活動は1度に1つ 一度に複数のことをすることはできない 25分で予定したタスクが終わらなくてもそれは失敗ではない。タイマーの音は25分集中したあなたへの拍手。 複雑だとやる気が減る。複雑なタス
「自信がない」は自信の持ちすぎ - 西尾泰和のはてなダイアリー
「原稿書かなきゃいけないんだけどなぁ」とか言いながら現実逃避で読んでいた本「心は病気―役立つ初期仏教法話〈2〉」に心に刺さる言葉があったのでここに書いておく。 正確な引用ではないので、正確な言葉が知りたければP.60から3ページくらいを読むとよい。 人間が自信をなくす原因は、自信の持ちすぎである。 自分が「この程度の仕事サクッと終わらせられる」と思っているのに、実際にやるとうまくいかないとき、人は自信をなくす。 「抜群のスピーチをしよう」と思って、実際にはうまく喋れなくて、自信をなくす。 妄想の中の自分が事実に反して素晴らしすぎるから、その「妄想の中の素晴らしい自分」が振る舞うように振舞おうとして、できないので苦しむ。 「自分の仕事に自信がない」というのは、奇跡的な成功を頭で妄想しているせい。現実の自分ができるようにしかできない。できることをすればよい。「自分は精一杯やった」と思える状態を
リーンスタートアップ：レバレッジメモ - 西尾泰和のはてなダイアリー
「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす」のレバレッジメモ Q: 「需要がある」と「技術的に実現可能」のどちらの仮説を検証すべきか？ 「この製品を作れるか」ではなく「この製品を作るべきか」「この製品を中心に持続可能な事業が構築できるか」を問うべき(P79) コダックは次の4つの問いに答えることをチームに求めていると書いてある(P91) １：我々が解決しようとしている問題に消費者は気づいているか ２：解決策があれば消費者はそれを買うか？ ３：我々から買うか？ ４：その解決策を我々は用意できるか？ そして、1〜3を飛ばして4に進み、顧客が問題を抱えているかどうかを確認する前に解決策を作ってしまう失敗が多い、とも書いてある。 消費者が問題に気づいていない場合→「ファイルの同期はほとんどの人が存在に気づいていない問題だとドロップボックスでは考えていた」から製品を
Re: プログラマの実力は〜 - 西尾泰和のはてなダイアリー
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな 要約して「Xを学ぶべきだ」になる主張は、その主張が正しいかどうか聞き手が判断できない。Xについて知らないのだから、判断できるはずがない。 話し手も正しく判断できているかどうか怪しい。単に自分がXを学んだから、それが無意味だったと思いたくないがために「Xを学ぶべきだ」と思っているのではないか？これに答えるのは難しい。Xを学ぶ時間でYを学んだほうがよかったのでは？この質問には答えられない。Yを学んでいないのだから、判断できない。 だから「Xを学ぶべきだ」という主張は本質的に不毛なのではないか。代わりに「私はXに興味がある」「私はXを学ぶことが有益だと思っている」「私はXを学ぶこと自体が楽しい」「あなたが『Xなんか学んでも意味ないよ』と思うのであれば、どうぞご自由に。私は私のしたいことをするだけです」とでも言っ
manに「cp -rは使うな」と書いてあった話 - 西尾泰和のはてなダイアリー
cp -rでシンボリックリンクまで実体としてコピーされて困ったのでMacのmanを読んでいたのだが、そもそもcp -rってオプション一覧に載ってない。あれれ？と思って続きを読んでいたら互換性の章でstrongly discouragedと書かれていた。 COMPATIBILITY Historic versions of the cp utility had a -r option. This implementation supports that option; however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links, or fifo's. 代わりに-Rを使うべきだそうだ。その場合のシンボリックリンクの扱いをどうするかはオプションで指定でき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
