フジテレビのドラマ「ifもしも」で放映され、テレビドラマにも関わらず日本映画監督協会新人賞を受賞した岩井俊二の出世作です。
その『打ち上げ花火』が23年の時を経てアニメーション映画として復活!
続きを読む
今日はCoderDojo千葉に参加しました。
CoderDojo とはアイルランドから始まったムーブメントです。
ボランティアと小中学生が一緒になり、プログラミングにはげむ「道場」です。
メンターと呼ばれるボランティアの人がいますが、基本的には手取り足取りは教えません。
自分で課題を見つけて分からないことがあればメンターに聞く、ただしメンターも全ての教えるのではなく、一緒に考えるというポリシーとのころです。
以前、たまたまこのイベントを知って今回初めて参加してみました。
千葉での活動は30回を超えていてすでにまる3年は活動しているそうです。
千葉の活動は広がっているらしく、千葉をはじめ、柏、市川、若葉、木更津などで行われているようです。
メンター(ボランティア)の方が3名ほどいて、親子での参加が6組ほどいました。
はじめての人向けにスクラッチでのプログラムを教えてくれます。
でもさすが子供ですね。
ちょっと教えたら勝手に色々弄り始める子もいました。
何回も参加していて、すでに出来る子は隣のテーブルで勝手にプログラミングをしています。
分からなかったら親やメンターさんに聞いて自分で作っていきます。
午前は2時間で終わりでしたが、子供たちも楽しんでていたようです。
今日は午前の部のみの参加でしたが、
午後はマインクラフトをjavaでmodプログラムのような事もするそうです。
仕事ではところでプログラムの機会に触れるというのは中々刺激的です。
あと子供が作るものって大人じゃ思いつかないようなこともするのでゲーム作りの刺激にもなります。
とりあえず午前の部で作ったゲームを公開しておきます。
なんかきっちり作ろうとしてそんなに面白くない感じです。
子供が作ったのを見ると動きがガクガクしていたりしていますが、なんか勢いを感じる作品に仕上がったりしています。
動きがおかしいのは気にしないのです。
自分の場合はなんか動きがおかしいと結局不具合を探してしまいます。
次回からは自分もメンターとして参加します。
自分の子供も興味があれば連れて行きたいんだけどなぁ。
市原にはまだDojoが無いので、そのうち市原でもやってみようかと思います。
長年コンシューマゲーム開発に携わってきた中で毎回思うことがある。
開発の終盤には必ずテストプレイが行われ、毎回大量のバグと闘っている。
なぜ大量のバグが出ているのか、どうしたら大量のバグが出なくなるのかについて考え、まとめてみることにした。
バグは「潰す」のではなく「出さない」ことに注力すべき!
バグを「出さない」ようにするためには以下の2つを心掛ける必要がある。
「自分」のところでいかにして「バグを出さない」ようにするか。
「他の人」のところでいかにして「バグを出させない」ようにするか。
バグを「出している」というのは新人でもベテランでも一緒。
たとえ学術的なコーディングスキルがあっても、新人が書いたコードでもバグは出る。
実装範囲の大小も関係ない。
いかに「責任」を持って取り組んでいるかで、バグを出すか出さないかに違いが出てくる。
これがイケてる(=バグを出さない)プログラマである。
続きを読むあの「MZ-80C」が手のひらサイズで復活!?
ハル研究所から「PasoconMini MZ-80C」という新商品が発売されるとのニュースをネットで見かけた。
流石に手のひらサイズでキーボードもディスプレイも、そもそもテープレコーダーもどうするんだ?と思いきや、中身は「Raspberry Pi」で、USBやら画面出力用のHMDIを備えているらしい…
それでも、これを見ると欲しくなってしまう。
もう30年以上前の話。
当時、小学5年生だったろうか。
父親がMZ-80Cを家に持って帰って来た。
買ったかどうかは不明ではあったが、とにかく家にマイコンがやって来た。
銀色のカバーを外すと漂う電子機器の独特な匂い。
ブラウン管、キーボード、テープレコーダーが一体型のマイコン。
臙脂色、黒、シルバーの筐体。
電源を入れるとディスプレイに表示される緑一色のフォント。
テープレコーダーで数分読み込ませてようやくBASICの入力が行えるようになる。
とにかく興奮したことは覚えてる。
小学生で理解出来る範囲は限られているので最低限のことだけ教えてもらい、父親のいない平日でも勝手に起動して遊んでいたものだ。
ゲームもいくつかあって遊んだりしていた。
汚染されていく建物の中から汚染を食い止めるために壁の隙間に防御壁を埋めつつ、倒れている人を救い出すゲームや、着陸用のロケットを月面に着陸させるゲーム、左右に揺れるバルーンを障害物を避けながらゴールに導くゲームなど、ASCIIで表現されたゲーム画面にくらいついて遊んでいた。
そのうちBASICでプログラムも始め、文法も理解しないまま、雑誌のプログラムを入力しては動かない、入力間違いを探してようやく動いたを繰り返していた。
それだけでも大喜びだった。
それに飽き足らず自分で作るようになり(自分で考えて作ると言ってもPRINT、GOTOだけの簡単なテキストアドベンチャーだった。たいていは途中で作るのをやめてしまっていたが…)作っては友達に見せたりしていた。
そんな小学生だったせいか、小学校の卒業文集の「将来の夢」にはこうかいてあった。
サラリーマン
プログラマーという言葉を知っていたのか分からないがプログラムをする人になりたいと言うことで書いたのだろうか?
それからサラリーマン…
なにかカッコイイものと勘違いでもしていたのか?それとも他に夢もなく書いていたのか?
とにかく将来の夢にはこんなこと書いていた。(ハズ)
中学にあがるとMSXを持ってる友達の家に行ってはBASICでプログラムをしていたがすぐにゲームに夢中になってしまい、その後はTRPG、PCエンジンと移っていき、プログラミングはしなくなっていった。
高校になると友達の家でPC98でたまにゲームは遊んでいたが、プログラミングからは遠退いて行った。
専門に進みロボット工学の様な学科でハードもソフトも学ぶ中で再びプログラミングに出会い、プログラムで作る楽しさ、表現できるものはやはりゲームだと思い、就職はゲーム業界に進んだ。
小学生の時に書いた将来の夢が2つとも叶ってしまった。
その後20年ゲーム業界にいるがゲームプログラマーやらゲームディレクターとしていくつものゲームを作ってきた。
ただ、最近は仕事になりすぎている感がある。
もちろん作ることは楽しいがどこか仕事としてこなしている部分があるような気がする。
MZ-80Cの記事を読んで遠い昔の忘れていた熱い気持ちを思い出させてくれた。
現状に満足せずに何か新しいことを始めてみよう。
あのMZ-80Cはまだ実家に眠っているだろうか。
年に一度帰るかどうかだが、今度実家に帰る機会があったら探してみるか。
リーダブルコードを読みました。
もっと早く読んでおくべきだったと思います。
初心者は良い勉強になりますし、むしろベテランにも読んでもらいたい本です。
自分は読みながら胸を痛めている側で、「あー、あるある」と思いながら読み進めていましたし、
読む前から実践していたことが出てくると「やってて良かったんだ」と思えたりします。
読んでいても楽しいのぜひ読んでみてください。
あくまでも「こうしたら良くなるよね」という主観的な意見で正解が無いというか、
コーディング規約なども含めてこのような内容は宗教論争になりそうですが、
事例を踏まえて書かれていて読み物としてうまくまとめられていると思います。
「技法」の紹介もありますが「考え方」のお話としてまとめられています。
でもこれって大切なお話だと思います。
コモンセンスがあるとプログラマ同士でもコミュニケーションも取りやすくなります。
コードレビューなどをする際にも、今まではなんとなく「こうだよね」としか言えず
お互い曖昧なままだったりしていましたが、もう少し具体的に話ができてお互いに納得できるようになります。
どちらにしても関わるひとには読むように勧めていきたいです。
もしくはコーディングスタイル(プロジェクトでの推奨の書き方)の様なものにまとめ直して運用するのもありだと思います。
本に書かれていることを全部をやらなくても部分的に取り入れるだけでも効果はあると思います。
でもこの本の一番の効果はコーディングに対する意識が変わることだと思います。
この本を読んだ後では自分のコードを何度でも読み返すようになります。
意識を忘れないためにも数カ月に一度目を通すだけでも本を読み直した方が良いと思います。
コードは理解しやすくなければいけない。
コードは他の人が最短時間で理解できるように書かなければいけない。
名前に情報を埋め込む
気取った言い回しよりも明確で正確なほうがいい。
名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する。
一貫性のあるスタイルは「正しい」スタイルよりも大切だ。
コメントの目的は、書き手の意図を読み手に知らせることである。
コードからすぐにわかることをコメントに書かない。
コメントすべきでは「ない」こと:
記録すべき自分の考え:
読み手の立場になって考える:
コメントは領域に対する情報の比率が高くなければいけない。
条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る。
巨大な式は飲み込みやすい大きさに分割する。
変数のことが見えるコード行数をできるだけ減らす。
変数を操作する場所が増えると、現在値の判断が難しくなる。
コードは1つずつタスクを行うようにしなければいけない。
最も読みやすいコードは、何も書かれていないコードだ。
他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。
テストには最もキレイで単純な値を選ぶ。