2012年5月3日木曜日

"Learn to Code" と、Python を勉強してみるの話と、 #GTUGGirls

せっかくのゴールデンウィークですが、旅行にも行かず、ソーシャルメディアからもなるべく足を遠ざけて、僧侶のように写経をする毎日です。

実は、SXSW で面白かったセッションの一つが、「コードの書き方を勉強して、自分が作りたいソフトウェアを作れるようになろう」というセッションでした。講演者は Picturelife Inc の Nate Westheimer さんと Yipit の Vinicius Vacanti さん。

内容を詳しく知りたい方は、"Learn to Code and Make the Software You Want"に音声ファイルが公開されています。コードを書いたこともなかった二人のビジネスマンが、プログラミングを学び、世界が変わり、「ぜひみんなもコードを書き始めるといいと思う!」という講演をしていました。メモから抜粋:

  • コードを書けるようになる人とそうでない人の違いは、「コードの書き方を勉強したか勉強しなかったか」ではなく、「どうしても作りたい物があるかどうか」。
  • どうしても作りたいサービスがあったので、会社を辞めて、80ページの仕様書を作り、4週間で作れるという会社に外注したところ、4ヶ月かかった末、仕様と全く違うものができてきた。このスタートアップにかけていたのに。。。会社もやめちゃったのに。。。orzというわけでもう一人の共同創業者と二人で、コードの書き方を勉強し始めた。一人はフロントエンドを、もう一人はバックエンドを。とにかく5日間、他のことは何もせずにプログラミングの勉強だけをした。1日目は、難しくて一体何をしているのか全くわからなかったけれど、5日目には自分が何かを作れるような気持ちになっていた。ちょこちょこやってもだめ。まとめた時間を作って、一気にやった方がいい。こうして、外注して4ヶ月かかっても出来なかった物が、自分で勉強したら、自力で2週間でできてしまった。
  • プログラミングの勉強は、どんどん簡単になってきており、数年前は難しかったことが、この1年半ぐらいですごく簡単になった。今までも何度かプログラミングの勉強をしかけてあきらめたけれど、今と5年前の学習環境は全然違う。
  • 考えなければいけないことはひとつ。あなたのサービスには、ユーザーがいる。ユーザーがやりたいと思うことを、実現するのがあなたのアプリ・サービスだということ。複雑なことを色々考えがちだけど、最終的には「あなたのサービスのユーザーは一体何をしたいのか」を追求した方がいい。シンプルに考えよう
  • あなたの最終目標は Facebook の CTO になることじゃない。まずは人が使いたくなるようなサービスを考えて、プロトタイプを作ることだ。「ハッキングとかされちゃったらどうしよう」とか考えても無駄。あなたが作ったサービスなんて、誰も知らないしわざわざハックしに来たりしません!「何百万人もアクセスして来ちゃったらどうしよう。スケーリングの仕方を勉強しないと。。。」あなたが作ったサービスなんて、誰も知らないし、そんなにたくさんの人が最初から来たりしません!「綺麗なコードを書かないと。。。」とか考えない。コードは汚くてもいいから、まずは書いて動かしてみること。「データベースの変更とかありうるよね。コードのメンテナンスの仕方とか勉強してからじゃないと。。。」データベース変更とかする程のサイトになるなら、その時はマネタイズして、開発者を雇ってその人に任せられるようになってる。セキュリティも、スケーラビリティも、コードの美しさも、メンテナンスも、最初から全部わかっている人なんていません。知らないことは恥ずかしいことじゃない。あなたがまず考えるべきことは一つ。。。何を作りたいのか。
  • では、どの言語を勉強するべきか。答えは、Pythonでも、Rubyでも、なんでもいい。自分は、Python と Django を勉強した。Instagram も Hunch もみんな Django を使っている。Python を使ってウェブサービスを作ろうと思う人はたくさんいて、彼らのナレッジが積み重なっているから、Pythonでウェブサービスを作ろうと思ったら、Django を使えば3日でできる。オンラインで勉強したい人は Django Book とかのサイトにいけばいい。Yipit Django Blog にも、Django を学ぶためのリソース集をまとめておいた。(この記事 "15 Key Resources to Learn Django" ですね。Google の Python Programming Class とか、Google Python Style Guide とかも載ってるようです。)Ruby on Railsなら、railstutorial.org で勉強し始めて、その後 railscasts.com とかで勉強するのがオススメ。で、最終的にどの言語を選ぶかは、「あなたが、ほんとにほんとにほんとに困ったときに、助けてくれる人はどの言語だったらいるのか」で決めるといい。でも、誰も助けてくれる人を知らなくても、今はオンラインのリソースがたくさんあるので心配しなくていい。あと、CSS や HTML はたくさん本が出ている。CSS Mastery とか。
  • 重要なことがひとつ。簡単に質問しないこと。「24 時間ルール」と呼ぶのだけれど、わからないことがあったら、まず最初の 24 時間は、自分で検索してみたり、調べてみたりして、自分で問題を解決できないか考えてみる。そんな中で、知らないことを学んだり、後で役立つ他のことを知ったりすることになる。人に聞くと、すぐに答えを教えてもらえちゃうので、学ばないものなんだ。自分で学んだことが、一番身につくということを覚えておくといい。汚くても、よくないコードでも、馬鹿な処理の仕方でもいいから「自分で、動くコードを書く」ことが、「あなたにとってはベストなコード」で、それを書くプロセスの中で、どういう風に物が動くのかを学ぶことができる。お友達に聞いたら、すぐに綺麗なコードでの書き方を教えてくれちゃうので、あなた自身の経験にも学びにもならない。そうやって自力で学んでいけば、すぐに自分で以前書いた汚いコードを、綺麗に書き直せるようになるよ。
  • 以前はなかった非常に素晴らしいサイトの一つが Stack Over Flow。今は、テクノロジー関係でわからないことがあったら、ここに行けばたいてい誰かが答えてくれる。Django の Stack Over Flow をちょっと見せるけど、質問の回答率はなんと 84%。しかも、すごくいい回答が返ってくる。あなたが困ったことはたいてい他の人が既に困ったことがあって、たいてい Stack Over Flow にその質問も回答も入っているし、そこになければ聞けば誰かが答えてくれる。しかも、早い。答えた人にはポイントが入り、ポイントでランクが上がっていくと業界のエキスパートとして仕事にもポジティブな影響があるので、回答する人にもメリットがある。Stack Over Flowがなかった頃、色々な情報を探すのがどんなに大変だったか。「こんな簡単な質問、聞いたら馬鹿だと思われるかな」と思うかもしれないけど、あなたが質問をすることで、のちのち同じ事で困る他の人のためにもなっていると考えよう。また、質問がなくても、Stack Over Flow を読むことで、すごくたくさんの勉強ができる。あと、さっき言った「自分で問題を解決していく」方法を取っていれば、他の人が困ったポイントを自分が通過しているので、2週間もすればあなたが誰かの質問に回答してあげられるようになるよ。初心者でも、他の人に教えられることはあるんだ。あなたがわからなくて検索したってことは、他の人も検索することになるってこと。学んだことはブログとか、github とか、色々なところで共有していこう。あと、http://www.djangosites.org/ もチェックしよう。4000を超える Django を利用したウェブサイトの事例紹介になっていて、オープンソースになっているサイトやサービスから設定とか色々なことを学ぶことができる
  • プログラミングを勉強し始めて、週末プログラミングで3日でちょろっと作ったのが 140it というサイト。長いツイートを 140 文字に縮めてくれるサービスがあったら便利だなと思って作って、ぺろっと TechCrunchに送ってみたら、なんと記事にしてくれて、最初のコメントが Mike Arrington で、「使ってみようかな」とか書いてあってびっくりした。Twitter上ではこんなサービスを作ってもいいのかとか、(短くするために母音を抜いちゃうので)読みにくいからTwitterがサービスを停止させるべきだとか、大騒ぎになった。ちょっと前までプログラミングのやり方も知らなかったのに、こんなことになるなんて。その後もいくつかサービスを作ってみて、3 日で Yipit というサービスを作ってみたら、Ron Conwayのようなエンジェル投資家やベンチャーキャピタルの投資を受けるようになり、エンジニアのチームもできた。それもこれもあの日僕があのイケてないネズミの表紙の本を手にとったからなんだなあと思うと感慨深い。そして、僕は今は「こういう物が作りたいなあ」と思ったらたいていの物は自分の手で作って実現することができる。それって本当に素晴らしいことだよね。

  • まあ、でもこれだけ言ってもたいていの人はやらないってこともわかってる。「素晴らしいね、でも僕にはできないや」と。まあ、そんなもんですわ。でも、例えば FourSquare を作った Dennis Crowley なんかも僕らにちょっと似てて、 FourSquare のアイディアが浮かんだけど、作ってくれる人がいない。じゃあってことで自分でプログラミングの勉強を始めて、FourSquareを作ってブレイクをさせた。この部屋に来ている人は、全員そんな可能性をもっているはず。プログラミングをするために頭がいい必要はないし、資質なんて関係ないよ。「作りたい物がある」っていう、それだけ。で、その作りたいものを自分で作れて、世界中の人に提供できること、そのために自分がコードを書けるようになるってことは、世界で最高のことだと思う。世界中の人がコードの書き方を勉強した方がいいと思ってるよ。本を読むとか、文字を書くとかと同じぐらい、コードを書くのは、基本的スキルとして身につけておくべきだと思う。
最近、こういう話が増えている気がする。このセッションの物ではないけれど、ご参考:
「3 日で作っただとー (#゚Д゚) ゴルァ!!」とか「こういうことをされるとプログラマーのレベルが落ちるぞ」とか思う方もおられると思いますが、まずはスタートラインに立てる人を増やして、その上でセキュリティやスケーラビリティ、アクセシビリティやメンテナンスの話もしていければなあと思います。

ちなみに、SXSW でその後に参加したセッションは「死なない方法:独裁国家でテクノロジーを使うには」という、これまた恐ろしく興味深いセッションでした。3日でぺろっとサイトを作ってのほほんとファンドレイジングできちゃう国と、作るサイトのセキュリティに相当気をつけないと命を落とす国の差がものすごい。音声を聞きたい方はこちらにて>  "How Not to Die: Using Tech in a Dictatorship"そういえばトゥギャってました。そこでも話されていましたが、「多くのネットユーザーはネットのせいで殺される人がいるということを考えなくていいかもしれないけど、ツールを作っている人は自分が作ったツール(やサイトやサービスやアプリ)を使って殺される人がいることも考えなければいけない」という自覚をもつ必要があるわけです。

ちなみに下記はユーザー向けですが:
衛星電話の安全な使い方のマニュアル(主にシリア向け)
安全にメディアを使う方法のマニュアル


そういうわけで、SXSWに参加した3月ぐらいから、今年のゴールデンウィークはプログラミングをやってみようと思っていたのでした。まずは 5-6 年ぐらい前に買った "Python Programming for the Absolute Beginner "を引っ張りだしてみることに。


ゲーム開発者が書いた Python の本なので、一行目が Hello World ではなく Game Over(笑)書いてある通り写経してみるも、動くコードも、エラーが出て動かないコードもありますが、とにかくそこで止まってうんうんしていると前に進まないので、とりあえず最後まで読んでみた。ほとんどのサンプルがゲームになっていて、CUI で動くHangman とかは、ちゃんと動いた。RPG のパーティを作って持ち物を持たせて、武器がなくなったり、アイテムを交換したりするのも、動いた。Tic-Tac-Toe(日本で言うマルバツゲーム)は、なんかエラーが出て動かない。BlackJackもなんかエラーが出て動かない。せっかく書いたのに動かないと、悲しい。しかしエラーを読んでも原因がよくわからない上に今は 24 時間ルールを使うのがもったいないので、先へ進む。最後の3章はGUIの作り方、グラフィックの使い方(シェフが屋根から飛ばしてくるピザを拾うゲームを作る)、音声とアニメの使い方(小惑星を避けたり破壊したりしながら進む宇宙船ゲームを作る)なので、後回し。 

同時進行で「みんなのPython Webアプリ編 」も読んだ。上記は英語、こちらは日本語なので、交代交代にすると飽きない。英語では気にしていなかったけど、こちらではまず日本語処理の話。コードにはutf-8。。。そうだよねそうだよねー。上記がIDLEでプログラミングしましょうなので、そのまま始めたら、Python の IDLE は、なんと日本語が通らないっぽい?パソコンが壊れたかと思った。しょうがないので CotEditor をインストールしてみた。上記はローカルでガンガンゲームを作って動かしていくのに対して、こちらは Chapter3 でもうwebサーバ立てちゃって、chapter6ではRSSリーダを作っちゃう。しかし。。。写経したサンプルが色々動かない。。。orzどこがおかしいのかよくわからないまま、読み進める。

ちなみにこの本は絶版になっているようで、PDF で無料でダウンロードできるようです :)


そして今日、更に別のマテリアルを発見。こちらはPythonと銘打ちながら、実は UNIX の基礎から始まっていてちょっと大変そうだwエディターはTextWranglerを使えと。

ところでなんでこのブログ記事を書く気になったかというと、さっきまで読んでいた "Python Programming "で書かれていることが、先週開催した GTUG Girls のミニ勉強会、一條さん (@ichijo3)を講師にお迎えした「プログラムコーディングの準備体操」で学んだことにとても似ていたので。「生徒は10人未満で、ディープに」というお達しにより、生徒はスタッフで埋まってしまって一般募集はしないミニイベントだったのですが、メモより:

  • 「ソースを書く」ことはプログラムコーディングの最後で、重要なのはその前にある「作りたいものに関する情報の整理」。この情報の整理は3点セットで、「写実派画家のように、プログラムを動かした結果となる状況を細かく描き出す」「料理研究家のように、行われることの順序、結果への段取りを描き出す。なるべく細かく。」「イベント運営者のように、誰が何を使って何を行うのか、役割・道具・条件をイメージする」
  • コードを書き始める前に、プロセスを細かく分解して書き出し、あいまいな点をなくし、複数の視点をもって見通すことで、色々なシチュエーションに対応し、バグを減らすことができる。そして、それらを先にコメントとして書いていく。コメントをしっかり書いておくことは、特に複数のエンジニアでプログラムを作っていく場合や担当者が変わるような企業での開発の場合、とても重要なこと。"Python Programming"の筆者も、まずはプロセスや条件などを箇条書きに書き出し、それらをコメントとして入れ込み、そのコメントの下に実際のコードを書いていくようでした。


最後に、ゴールデンウィーク初日に行ってきた、ニコニコ超会議「超エンジニアミーティング」での名言を載せておきましょう。「業務でやってないからわかんないは理由にならん。いつか勉強して作ろうじゃなく、今日勉強を始めよ。いつかは今だ!


追記:そういえば、SXSW のセッションをトゥギャってたのを思い出しました。

Disclaimer このブログは山崎富美の個人的なものです。ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には一切の関係はありません。