main() blog

プログラムやゲーム、旅、愛する家族について綴っていきます。

『CoderDojo 千葉』に参加しました!

 

今日はCoderDojo千葉に参加しました。 

 

f:id:takezoh_1127:20170605194944j:image

 

CoderDojo とはアイルランドから始まったムーブメントです。
ボランティアと小中学生が一緒になり、プログラミングにはげむ「道場」です。

 

coderdojo.jp

 

メンターと呼ばれるボランティアの人がいますが、基本的には手取り足取りは教えません。

自分で課題を見つけて分からないことがあればメンターに聞く、ただしメンターも全ての教えるのではなく、一緒に考えるというポリシーとのころです。 

 

以前、たまたまこのイベントを知って今回初めて参加してみました。

 

千葉での活動は30回を超えていてすでにまる3年は活動しているそうです。

千葉の活動は広がっているらしく、千葉をはじめ、柏、市川、若葉、木更津などで行われているようです。

 

メンター(ボランティア)の方が3名ほどいて、親子での参加が6組ほどいました。

 

はじめての人向けにスクラッチでのプログラムを教えてくれます。

でもさすが子供ですね。

ちょっと教えたら勝手に色々弄り始める子もいました。

 

何回も参加していて、すでに出来る子は隣のテーブルで勝手にプログラミングをしています。

分からなかったら親やメンターさんに聞いて自分で作っていきます。

 

午前は2時間で終わりでしたが、子供たちも楽しんでていたようです。

 

今日は午前の部のみの参加でしたが、

午後はマインクラフトをjavaでmodプログラムのような事もするそうです。

 

f:id:takezoh_1127:20170605005230j:image

 

仕事ではところでプログラムの機会に触れるというのは中々刺激的です。

あと子供が作るものって大人じゃ思いつかないようなこともするのでゲーム作りの刺激にもなります。

 

とりあえず午前の部で作ったゲームを公開しておきます。

 

scratch.mit.edu

 

なんかきっちり作ろうとしてそんなに面白くない感じです。

子供が作ったのを見ると動きがガクガクしていたりしていますが、なんか勢いを感じる作品に仕上がったりしています。

動きがおかしいのは気にしないのです。

自分の場合はなんか動きがおかしいと結局不具合を探してしまいます。

 

次回からは自分もメンターとして参加します。

自分の子供も興味があれば連れて行きたいんだけどなぁ。

 

市原にはまだDojoが無いので、そのうち市原でもやってみようかと思います。

 

バグを出さないプログラマになるための「心得」

1.はじめに

長年コンシューマゲーム開発に携わってきた中で毎回思うことがある。
開発の終盤には必ずテストプレイが行われ、毎回大量のバグと闘っている。
なぜ大量のバグが出ているのか、どうしたら大量のバグが出なくなるのかについて考え、まとめてみることにした。

バグは「潰す」のではなく「出さない」ことに注力すべき!

バグを「出さない」ようにするためには以下の2つを心掛ける必要がある。

「自分」のところでいかにして「バグを出さない」ようにするか。

  • 実装確認をする
  • 自己完結させる
  • 常に自分を疑う

「他の人」のところでいかにして「バグを出させない」ようにするか。

  • エラーは早い段階でエラーとして処理する
  • エラーを分かりやすく教えてあげる

バグを「出している」というのは新人でもベテランでも一緒。
たとえ学術的なコーディングスキルがあっても、新人が書いたコードでもバグは出る。
実装範囲の大小も関係ない。

いかに「責任」を持って取り組んでいるかで、バグを出すか出さないかに違いが出てくる。

これがイケてる(=バグを出さない)プログラマである。

続きを読む

【記憶のゴミ箱】MZ-80Cと将来の夢

あの「MZ-80C」が手のひらサイズで復活!?

 

f:id:takezoh_1127:20170522123932j:plain

 

ハル研究所から「PasoconMini MZ-80C」という新商品が発売されるとのニュースをネットで見かけた。

 

www.pcmini.jp

 

流石に手のひらサイズでキーボードもディスプレイも、そもそもテープレコーダーもどうするんだ?と思いきや、中身は「Raspberry Pi」で、USBやら画面出力用のHMDIを備えているらしい…

 

 

それでも、これを見ると欲しくなってしまう。

 

 

 

もう30年以上前の話。

 

当時、小学5年生だったろうか。

父親がMZ-80Cを家に持って帰って来た。

買ったかどうかは不明ではあったが、とにかく家にマイコンがやって来た。

 

銀色のカバーを外すと漂う電子機器の独特な匂い。

ブラウン管、キーボード、テープレコーダーが一体型のマイコン

臙脂色、黒、シルバーの筐体。

電源を入れるとディスプレイに表示される緑一色のフォント。

テープレコーダーで数分読み込ませてようやくBASICの入力が行えるようになる。

 

 

とにかく興奮したことは覚えてる。

小学生で理解出来る範囲は限られているので最低限のことだけ教えてもらい、父親のいない平日でも勝手に起動して遊んでいたものだ。

 

ゲームもいくつかあって遊んだりしていた。

汚染されていく建物の中から汚染を食い止めるために壁の隙間に防御壁を埋めつつ、倒れている人を救い出すゲームや、着陸用のロケットを月面に着陸させるゲーム、左右に揺れるバルーンを障害物を避けながらゴールに導くゲームなど、ASCIIで表現されたゲーム画面にくらいついて遊んでいた。

 

そのうちBASICでプログラムも始め、文法も理解しないまま、雑誌のプログラムを入力しては動かない、入力間違いを探してようやく動いたを繰り返していた。

それだけでも大喜びだった。

 

 

それに飽き足らず自分で作るようになり(自分で考えて作ると言ってもPRINT、GOTOだけの簡単なテキストアドベンチャーだった。たいていは途中で作るのをやめてしまっていたが…)作っては友達に見せたりしていた。

 

そんな小学生だったせいか、小学校の卒業文集の「将来の夢」にはこうかいてあった。

 

プログラマー

サラリーマン

 

プログラマーという言葉を知っていたのか分からないがプログラムをする人になりたいと言うことで書いたのだろうか?

それからサラリーマン…

なにかカッコイイものと勘違いでもしていたのか?それとも他に夢もなく書いていたのか?

 

とにかく将来の夢にはこんなこと書いていた。(ハズ)

 

中学にあがるとMSXを持ってる友達の家に行ってはBASICでプログラムをしていたがすぐにゲームに夢中になってしまい、その後はTRPGPCエンジンと移っていき、プログラミングはしなくなっていった。

 

高校になると友達の家でPC98でたまにゲームは遊んでいたが、プログラミングからは遠退いて行った。

 

専門に進みロボット工学の様な学科でハードもソフトも学ぶ中で再びプログラミングに出会い、プログラムで作る楽しさ、表現できるものはやはりゲームだと思い、就職はゲーム業界に進んだ。

 

小学生の時に書いた将来の夢が2つとも叶ってしまった。

 

その後20年ゲーム業界にいるがゲームプログラマーやらゲームディレクターとしていくつものゲームを作ってきた。

 

ただ、最近は仕事になりすぎている感がある。

もちろん作ることは楽しいがどこか仕事としてこなしている部分があるような気がする。

 

MZ-80Cの記事を読んで遠い昔の忘れていた熱い気持ちを思い出させてくれた。

現状に満足せずに何か新しいことを始めてみよう。

 

 

 

あのMZ-80Cはまだ実家に眠っているだろうか。

年に一度帰るかどうかだが、今度実家に帰る機会があったら探してみるか。

 

 

【書籍】リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック

感想

リーダブルコードを読みました。

もっと早く読んでおくべきだったと思います。
初心者は良い勉強になりますし、むしろベテランにも読んでもらいたい本です。

自分は読みながら胸を痛めている側で、「あー、あるある」と思いながら読み進めていましたし、
読む前から実践していたことが出てくると「やってて良かったんだ」と思えたりします。
読んでいても楽しいのぜひ読んでみてください。

あくまでも「こうしたら良くなるよね」という主観的な意見で正解が無いというか、
コーディング規約なども含めてこのような内容は宗教論争になりそうですが、
事例を踏まえて書かれていて読み物としてうまくまとめられていると思います。

「技法」の紹介もありますが「考え方」のお話としてまとめられています。
でもこれって大切なお話だと思います。

コモンセンスがあるとプログラマ同士でもコミュニケーションも取りやすくなります。
コードレビューなどをする際にも、今まではなんとなく「こうだよね」としか言えず
お互い曖昧なままだったりしていましたが、もう少し具体的に話ができてお互いに納得できるようになります。

どちらにしても関わるひとには読むように勧めていきたいです。
もしくはコーディングスタイル(プロジェクトでの推奨の書き方)の様なものにまとめ直して運用するのもありだと思います。
本に書かれていることを全部をやらなくても部分的に取り入れるだけでも効果はあると思います。

でもこの本の一番の効果はコーディングに対する意識が変わることだと思います。

この本を読んだ後では自分のコードを何度でも読み返すようになります。

意識を忘れないためにも数カ月に一度目を通すだけでも本を読み直した方が良いと思います。

概要

1章 理解しやすいコード

コードは理解しやすくなければいけない。
コードは他の人が最短時間で理解できるように書かなければいけない。

第Ⅰ部 表面上の改善

2章 名前に情報を埋め込む

名前に情報を埋め込む

  • 明確な単語を選ぶ
  • 汎用的な名前を避ける(あるいは、使う状況を選ぶ)
  • 抽象的な名前よりも具体的な名前を使う
  • 接尾辞や接頭辞を使って情報を追加する
  • 名前の長さを決める
  • 名前のフォーマットで情報を伝える

気取った言い回しよりも明確で正確なほうがいい。

3章 誤解されない名前

名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する。

4章 美しさ
  • 読み手が慣れているパターンと一貫性のあるレイアウトを使う。
  • 似ているコードは似ているように見せる。
  • 関連するコードをまとめてブロックにする。

一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

5章 コメントすべきことを知る

コメントの目的は、書き手の意図を読み手に知らせることである。

  • コメントすべきでは「ない」ことを知る。
  • コードを書いているときの自分の考えを記録する。
  • 読み手の立場になって何が必要になるかを考える。

コードからすぐにわかることをコメントに書かない。

コメントすべきでは「ない」こと:

  • コードからすぐに抽出できる
  • ひどいコード(例えば、ひどい名前の関数)を補う「補助的なコメント」。コメントを書くのではなくコードを修正する。

記録すべき自分の考え:

  • なぜコードが他のやり方ではなくこうなっているのか(「監督のコメンタリー」)。
  • コードの欠陥をTODO:やXXX:などの記法を使って示す。
  • 定数の値にまつわる「背景」。

読み手の立場になって考える:

  • コードを読んだ人が「えっ?」と思うところを予想してコメントをつける。
  • 平均的な読み手が驚くような動作は文章化しておく。
  • ファイルやクラスには「全体像」のコメントを書く。
  • 読み手が細部に捕らわれないように、コードブロックにコメントをつけて概要をまとめる。
6章 コメントは正確で簡潔に

コメントは領域に対する情報の比率が高くなければいけない。

第Ⅱ部 ループとロジックの単純化

7章 制御フローを読みやすくする

条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。

行数を短くするよりも、他の人が理解するのにかかる時間を短くする。

変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る。

8章 巨大な式を分割する

巨大な式は飲み込みやすい大きさに分割する。

9章 変数と読みやすさ

変数のことが見えるコード行数をできるだけ減らす。

変数を操作する場所が増えると、現在値の判断が難しくなる。

第Ⅲ部 コードの再構成

10章 無関係の下位問題を抽出する
11章 一度に1つのことを

コードは1つずつタスクを行うようにしなければいけない。

12章 コードに思いを込める
13章 短いコードを書く

最も読みやすいコードは、何も書かれていないコードだ。

第Ⅳ部 選抜テーマ

14章 テストと読みやすさ

他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。

コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。

テストには最もキレイで単純な値を選ぶ。

15章 「分/時間カウンタ」を設計・実装する

【Git】GitHubをはじめよう!

はじめに

GitHubをはじめる前にGitの環境をインストールしておく必要があります。
下記のページを参考にインストールをしてください。

GitHubのアカウント登録

まずはGitHubのアカウントの登録を行います。

GitHub

ユーザー名とメールアドレス、パスワードを入力します。

github_000.png

プランを選択します。
Freeで進めます。

github_001.png

自分の経験にあった内容を選択してsubmitします。

github_002.png

登録が完了しました。
メールでメールアドレスの確認を求められるので確認しておきます。

github_003.png

早速、リポジトリを作成してみます。

github_004.png

無事にリポジトリが作成されました。

github_005.png

後は今まで通りの手順でGitHubの共有リポジトリで作業できるようになります。

GitHubに作成した共有リポジトリで作業

まずは先ほど作成した共有リポジトリをクローンします。
TortoiseGitで作業してみます。

github_006.png

URLに先ほど作成した共有リポジトリのURLを入力します。
ディレクトリはローカルのパスを指定してください。

これ以降はGitHubの共有リポジトリにpushできるようになります。

GitHub Desktop

GitHub Desktopもインストールしてみます。

GitHub Desktopをインストー

githubdesktop_000.png

インストール中…

githubdesktop_001.png

GitHubのアカウントでログイン

GitHubのアカウントを入力してログインします。

githubdesktop_002.png

コンフィグを設定

今までに設定したユーザー名とメールアドレスを入力します。

githubdesktop_003.png

インストール完了

githubdesktop_004.png

リポジトリの追加

ここで今までに作成したリポジトリを追加してみましょう。
Desktopで表示されるようになりました。

githubdesktop_005.png

初夏の庭

今日は妻の庭造りのお手伝いです。

 

派手な色はあまり好まないので地味な感じになりそうですが落ち着いた雰囲気が涼しげな空間を生んでくれます。

 

f:id:takezoh_1127:20170508004217j:image

f:id:takezoh_1127:20170508004231j:image

f:id:takezoh_1127:20170508004243j:image

f:id:takezoh_1127:20170508004252j:image

f:id:takezoh_1127:20170508004259j:image

 

ナメクジと大量のゾウリムシと闘いながらなんとか作業は終わりました。

 

庭をやってる時に見たことのない野良猫がやって来ました。

下の子は「なお!(にゃお)なお!」と興奮し、お姉ちゃんは勝手に「ジンナイ」と名前を付けていました。

眼光鋭い野良猫でしたが意外に人懐っこく子供たちが着いてまわっても一向に逃げる気配がありません。

そのうちトカゲを見つけて臨戦態勢に。

お尻を振り始め、飛びつくまでを三人で観戦してました。

シャーッと飛びつくとものの見事シッポ切って逃げて行きました。

お姉ちゃんも切れたシッポは初めてだったらしく「動いてる!動いてる!」とギャーギャー騒いでいました。

f:id:takezoh_1127:20170508010223j:image