TENTO×デジタルポケット 第3回プレゼン大会の幹事をしてきた #tentodp2014

LINEで送る
Pocket

去る10月26日(日)、DeNA様の会議室にて、ボランティア先の小中学生向けプログラミングスクール「TENTO」と、主にViscuitを利用した教育を行う「特定非営利活動法人デジタルポケット」(以下 DP)さんと共催で、第3回プレゼン大会を催しました。当日の模様は、「TENTO×ビスケット塾 第三回プレゼン大会 模様のまとめ #tentodp2014 – Togetterまとめ」にトゥギャりました。

今回は以前にまして、TENTO, DPに通う40名の小中学生が登壇し、自慢のプログラムをLTしました。

IMG_6828

当日の模様をブログを書いていただいた方がいらっしゃいます。ぜひ、ご覧ください!

また、過去の模様は、以下のエントリに残していますのでご覧ください。

さて、僕は今年から本格的にTENTOの講師ボランティアとして加わったため、準備開始の段階からイベントの一切のマネジメントに関わる事となりました。とはいえ、第1回から撮影係として関わってきましたので、何をしなければならないかの大筋は確認できていてあまり不安はありませんでした。そこで、今回の事後blogでは、今までとは違う気付きがあった3つの話「ポスターセッションの導入」「テキストプログラミング部門の審査員について」そして「プレゼンテーションとプログラミングを考える」についてまとめようと思います。

ポスターセッションの導入

第3回から導入した事として「2セッション同時進行」「保護者会」そして「ポスターセッション」があります。さて、この中でポスターセッションについてお話しします。

IMG_0970

一般にポスターセッションとは、カンファレンス等で、自分自身の研究成果を1枚の模造紙にまとめ、決められたブースに待機して対面で説明する事を言います。今回は、それを拡大解釈して、生徒自身が開発したソフトウェアを他の人に触ってもらいながら対面で説明できる場を作りました。デモブースと言っても良かったかもしれません。

これは、今回共催するにあたりDP 渡辺さん(たけしぃ)から「作ったプログラムは触れられた方が良い」という提案を受けて設定したものです。たけしぃさんが言うのは最もでして、僕もプログラムは実際に使ってなんぼのものだと考えていました。また、たけしぃさんはワークショップの実務経験が豊富であったため、彼の知見をベースにうまくできるのではないかとも考えました。

実際、やってみて成功だったと僕は考えています。ポスターセッションにて、3つの発見がありました。

  1. 違う拠点の生徒同士の交流が生まれる
  2. 技術の交流が生まれる
  3. プログラミングのモティベーションがより高まる

1は、TENTOやDPは首都圏各所で教室を開いていますが、通常は別の教室の生徒同士が交流する機会はありません。そんな中、生徒一人一人が、自分は一人や狭い世界にいるのではなく、多くのプログラミングを学ぶ友達がいることを身をもって知ってもらえたのではないでしょうか。

2は、実際に他の人のプログラムに触れると、自分が知らない技術や実装の工夫をしていることを知る場合があります。そんなときに、開発した子と直接会話する事で、技術を通じた交流が生まれます。本人が席を外しているときに、「〇〇を作った人、来て下さい〜!」と呼んで説明を求める子さえいました。僕はこれを見て心底やってよかったと思いました。

3は、1や2を通じて、人との交流やより高い技術の研鑽を通じて、より高度な技術、より魅力的な演出ができるプログラムを書こう、という生徒のモティベーションが上げられたのではと考えています。仲間同士で鍛えあう姿は、僕個人はとても素晴らしい事だと理解しています。

これらは、たけしぃさんの段取りあってこその成功でした。本当に感謝しています。

最後に、1点問題がありました。Wi-Fiです。今回はDeNA様のWi-Fi環境がありましたので無事乗り切る事ができました。今後は、過去のエントリ「JPA Thanks CONBU トークセッションでWi-Fi設定の知見を聞けた #yapconbu」で学んだ知識をベースにより良い環境を構築しなければならない事を痛感しました。

テキストプログラミング部門の審査員について

テキストプログラミング部門は、Webアプリエンジニア養成読本の共著者で81忘年会仲間である @uzulla さんに依頼し、二つ返事で引き受けてくれました。

IMG_7456

今回、運営担当者内で部門の特性(Viscuit, Scratch低学年, Scratch高学年, テキストプログラミングの4部門)に沿って手分けして依頼をしたのですが、その際にテキストプログラミングを担当していたのが僕でした。なぜuzullaさんだったかというと、「現場でソフトウェア開発をしている」「若い人と柔軟に交流できる」そして「YAPC::Asia Tokyo 2014 ベストトーク賞受賞者」であるという点でした。ソフトウェアの完成度は当然評価するとして、プレゼン大会なのですからプレゼンテーションのよさを知っている方にお願いしたかったのです。また、ソフトウェア開発の現場にいる方に審査をお願いするのは、これが初めてです。

実際、彼にお願いして本当に良かったと思います。実務の現場で働く人がどのような視点でプログラミングに関わっているのか、そして生徒の皆さんも自分自身がどこを磨くとより魅力的になれるのか、強い刺激をもらえたのではないかと思います。 uzulla さん自身の感想はエントリにまとまっているのでぜひご覧ください(冒頭でリンクしています)。

もし可能であれば、ソフトウェア開発に興味をもつ現場にいる人たちを交わり、よりプログラミング開発のスキルを高めつつ、そしてより広くたくさんの人たちとの輪を広げる…そう、コミュニティ参加への道も開く事ができたらと考えています。

uzulla さんをはじめ、審査を担当いただいた皆様に深く感謝致します。

プレゼンテーションとプログラミングを考える

TENTOでは、ピアノや水泳教室のように、社会に出る時の教養としてプログラムを学ぶ環境を提供するよう努めています。中には社会人になってプログラム開発の現場に入る子もいるかもしれませんが、それは一部だと考えています。

「構成を考え(モデリングスキル)」「開発を行い(プログラミングスキル)」そして「多くの人に自分が開発したプログラムの良さを知ってもらう(プレゼンテーション)」の3つを指導しています。言い換えれば、モデリングスキルを養う事で論理的思考(再現性のある説明・可視化するスキル)を学び、プログラミングを通じてこれから長く付き合うであろうコンピュータの活用方法や技術の学習方法を学び、そしてプレゼンテーションを通じて自分自身を表現する方法を獲得します。これらは全て、社会に出ると求められるスキルであることは、皆様同意していただけるかと思います。

IMG_7367

その上で、学習のマイルストーンとして、このプレゼン大会と関わり続けて行きたいと考えています。そうすることで、生徒自身はもちろん、私たち指導に携わる者としても、共に学習しより成長して行くために何をすれば良いのか、計画的に考えて行動できるようになります。

10年後、20年後に、ここで学んだ生徒さんたちが、コンピュータを当たり前に活用しながら、論理的に考えて仲間や多くの人にその考えを伝え、より多くの人に新しい価値を提供してくれるようになればいいなと願っています。そこまでいかなくとも、彼らが社会に出たときに、彼らの力でソフトウェア開発の際に発生する意思疎通に起因したトラブルがせめて少しでも減ってくれれば、との思いもあります。

まとめと今後について

ここまで、第3回プレゼン大会について「ポスターセッションの導入」「テキストプログラミング部門の審査員について」そして「プレゼンテーションとプログラミングを考える」の3点に分けてお話ししました。特に、ポスターセッションの導入はDPさんの知見と協力があってこその成功でした。重ねてありがとうございました!

プログラミング教育と一口に言っても、1回〜数回のワークショップ型もあれば、TENTOのような寺子屋教室型、そして今後は学習塾のような一斉指導型も出てくるのではないかと思います。また、英国をはじめとして先進国から順に公教育におけるプログラミング教育の普及が既に始まっています。従って、プログラミング教育はこれからもどんどん盛り上がるのではないかと私は考えています。

ただし、そのときにどのような形を目指しているのかは、充分確かめておく必要がありそうです。プログラムを書く楽しさを伝える所もあれば、TENTOのように論理的思考を通じてプレゼンテーションスキルを高める所もあれば、プログラミングは一つの手段として情報システムの仕組みや倫理を学ぶ所もあるでしょう。他にも出る事でしょう。

ソフトウェア開発者がプログラミング教育を考える事は、どのような後進を育成したいか、そして自分たちがどのような世界にしていきたいのかを考える事に通じます。「コードで世界を変えられる」という有名な言葉があります。もし、変えられたとき、その後の継続性をどのように担保するのか?という点は、あまり議論されてこなかったのではないでしょうか。勝手に誰かが引き継ぐ?それは滅びて別のものが出る?確かにそれはあるでしょう。でも、それだけで良いとは僕は思いません。

恐らく…僕がプログラミング教育に関わる最大のモティベーションは、未来を見つめることができるからだと、考えています。

IMG_0541

会場をお貸し出しいただいたDeNA様、ありがとうございました。一緒に運営して下さったTENTO, DPのみなさん、審査員の皆様、大変お疲れさまでした。保護者の皆様、大変ありがとうございました。そして、発表した生徒の皆さん、お楽しみ様でした!

LINEで送る
Pocket

JPA Thanks CONBU トークセッションでWi-Fi設定の知見を聞けた #yapconbu

LINEで送る
Pocket

昨夜、JPA(Japan Perl Association)主催の「JPA Thanks CONBU トークセッション」へ足を運んできました。前日、なんとかギリギリ登録する事ができました。模様は「JPA Thanks CONBU トークセッション まとめ – Togetterまとめ」にまとめられています。

CONBU(CONBU – COnference Network BUilders)さんとは、大規模な勉強会やカンファレンスなどのネットワークの敷設・管理を行うネットワークエンジニア集団の名称です。様々なベンダーの人たちが協力して、素人ではなかなか手に負えない大規模ネットワークを、短い時間で作り上げられるプロが集まっているのです。なかなか珍しいです。

あの1,000人超が来訪するイベントにおいて、短い準備期間で滞りなく快適なネットワークを提供できることは、非常に高い技術とモティベーションのもとに成立している事に他なりません。特にWi-Fiは素人が設置すると、大規模になってしまうとあっという間に破綻します。それを思うと、彼らに感謝せずにはいられません。

そして、どうやったらそれができるのだろうと、僕はふと興味が沸いたのです。実は、YAPC::Asia 2014の際にHUBで少しだけ話を聞いた事があったのです。できれば、もっと深く聞いてみたいなと思っていた矢先だったので、これは伺うしかないと思ったのです!

また、最近はボランティア先のTENTOで数十台のマシンをつないで移動教室を立てる事もよく行っているのですが、Wi-Fiの設定で色々苦労していました。YAMAHAのRTX1200WLX302を買ってもらったのに宝の持ち腐れだね自分!!!だから、この機会にしっかり知見を獲得したかったのです。

伺ってみて、その話の内容には期待以上でした。ご自身の技術的好奇心、そして違う分野の人とより広く関わっていきたいと考える志高いプロフェッショナル集団に、自分たちは支えられていた事を改めて認識できたのでした。このようなお互いの知見を出し合いながら面白い事をする機会がより増えれば良いなと思ったのでした。

CONBUのみなさん、ありがとうございました!会の準備や食事を提供いただいたJPAの皆様、ありがとうございます!そして、会場を提供いただいたmixiさん、お世話になりました〜

それでは、いつものようにノートをアップしておきます。

YAPCとLL、異なるカンファレンスのNWをさくっと構築する

  • 高橋さん
    • NWエンジニア
  • 話す事
    • NWのこと
    • 資料公開します(あとでリンク張る)
  • 会場ネットワークを提供したけど
    • テーマ
      • ポータブル化
      • 低コスト化
    • 準備期間: LLの後だから4日!!!
    • 通常は1〜2ヶ月でやる仕事!!!
    • 要件も増える
      • セキュリティ
      • 高速
      • 低コスト
      • v6?
    • でもやるしかない!
  • 求められる機能はイベントを問わず変わる事は少ない
    • 一度作ったものを再利用して低コストに
      • 計画・論理設計・検証の一部
    • だめなもの
      • 物理設計・下見・検証の一部
  • 構築方法
    • 設定済みにして運ぶ: 今まで通り
    • テンプレを作ってデプロイ:
    • クラウドに機能を持たせる: 今回採用。クラウド側にVPNを張ってつなげる。
      • 集まって作業する必要がかなり減る
  • 配送
    • 段ボールかなり運ぶらしい
    • コスト結構かかる
    • 運搬中にサーバが壊れた事さえあって、去年のLLではタイムトライアル状態…
      • こういうのもクラウド側におくと避けられる
  • NFV
  • 突然の要件変更!!!
    • それも前日!
    • VPNあかんやん!
    • VLANで
  • 当日どうなの?
    • トラブル
      • 違うVLAN IDで動いてた: 借りている装置とかで、調整をしていたつもりが思った設定になってなかった。
      • L2TPつながらない: パケットがお漏らし…宙に浮く。
        • (ちなみに私もこの問題引っかかりました)
    • Abuse
  • その他のこと
    • 1,200台あまりのMac(MACIDベース)がつながったらしい
    • 口に出して言えない言葉をパスワードにする

Wi-Fiの電波の話

  • @tinbotu さん
  • ざっくりまとめると
    • 遅い受信レートではつながらないようにする
    • 到達距離を制御するにはAPの高さと向きを変える事で対処
    • チャンネルの衝突に気をつけながらセットアップ
  • 切れちゃう原因
    • 電波が弱い
    • 混んでる
  • 強さと速度
    • 電波の強度によって、リンク速度がリアルタイムで変わっている。
    • 切れると別のAPをさがす。
    • 壁とか貫通しづらい。
    • 水も通りづらい(人間が壁になる)。
      • 人が増えると電波が届きづらくなる。
  • 時空間の問題
    • 遅い端末が、電波を使う時間を奪う。
      • 通信時間が延びる→電波占有時間も延びる。
    • だから、遅い端末を切ってしまおう!
      • 電波が弱いほど受信レート(リンク速度)は落ちる。
      • そこで受信レートが低い=弱い電波の端末を締め出す事が可能。
      • CiscoとかYAMAHAのAPには受信レート設定の項目がある。
      • 受信レートの設定ができると、実は安いWi-Fi APでもいけるかもしれない(でもそんな製品は今の所ないらしい)。

    • しかし、APを増やして対策すると電波が衝突する。
      • チャンネル設定だけでは限度がある。
  • 譜面台にWi-Fi APを乗せる理由
    • 高さはもちろん、角度も変えやすい!
      • 低いと狭く、高いとより遠くへ。
      • より飛ばしたい方向へ届くよう傾ける。
    • だから、飛ばす方向を柔軟に変更できる。
    • これで、電波が飛んで行ってほしい方、飛んで行ってほしくない方、それぞれコントロールしやすくなる。
      • チャンネルが衝突しそうな時はより効果的。
    • 出力調整で、下げても電波の届く範囲があまり狭くならない。
      • そして、受信性能は設定ではどうやっても抑えられない。
      • だから高さで調整するのが手軽で確実。
  • 電波の混雑は、inSSIDerなどのツールで、使用率も含めて確認する。チャンネルが埋まっているだけでも、使用率が低い事があるので見逃さない。
  • 電波の到達距離は、感覚でわかるそうです…これはすごい。現場でたくさんの知見を獲得されているのでしょうね。これだけはまねできそうにありません。

CONBUのみらい

  • 資料と発表内容のみ公開OKのセッション
  • CONBUが注力するところ
    • ホットステージ (Interopとかのカンファレンスネットワークの準備)
    • クラウド化
    • 構築のマネジメント
  • ホットステージ
    • 超短時間化!を目指す。
    • 配線に32%の時間がかかってる。27, 32, 27 ,14 = 休憩,配線,開梱と梱包,確認
    • AP 25台 大変だ!
      • 専用 配送箱作った!18台はいる。
      • 梱包工数が減らせたと思う 10倍ほどのパフォーマンスアップ
  • 土管
    • みんなと手を組みたい
    • コンテンツを提供しなきゃ
    • 「誰々はどこにいる?」
    • 「人気発表プログラムは何?」→AP毎にとれると…へへへっ
      • 面白い事を話していると、トラフィック量が 減る んだ。
      • サイトの発散具合・エリア毎のトラフィック・プログラムにマッピング→わかる!?
  • アイディアだし
    • 人気URLをだす→GitHub, CPAN等に絞って
    • 同じトークを聞いている人をマッチング→昼飯食いに行こうぜ
    • sandboxあると誰か作るかも

CONBUはみんなと仲良くなりたい

  • たじまさん
    • JANOGとか手伝ってます
    • 次回 JANOG35 も来てね!1月だよ!
  • 最初にやるべきだけれど、最後にやります!
  • CONBUって?
    • NWエンジニアにとって
      • 最近遊べない
      • 実験できない 特に壊せない
  • 前史
    • 2009年くらいまで
    • ネットワークを提供すらしてなかった
    • 運営向けのみくらいかな
      • NW屋のカンファレンスなのに…
  • 第一世代
    • 2010年頃
    • 細々と来場者向けに提供
    • ノウハウなく大失敗
      • NW屋のカンファレンスなのに…
  • 第二世代
    • SNS大躍進
    • 会場で仕事をしたい(ふりをする)要望の増大
    • 備え付けWi-Fiの崩壊
    • 大変な労力とコスト
      • NW屋のカンファレンスなのに…
    • よくよく考えると
      • メインコンテンツはプログラム
      • NWは道具なのにコストがかかる
      • 毎回作っては壊し…
      • NW屋のカンファレンスなのに…
  • ほめられると嬉しい!
    • 同じ業界ならつるんでいる事が多い。
    • だけど、違う分野の人とあまりつながっていない。
    • YAPCなどを通じてコミュニティを越えて絡んで行く。
  • 理想
    • 僕らがいなくてもNWが作れる時代に。
    • カンファレンス運営担当が何もせずにNWが組める時代に。
    • そして、機器だけでなく、人もつなげたい。

おまけ: CONBUさんへ

ブログに書いておいて!とお話を伺ったので残します。

まず、こんな話を聞きたい!です。

  • クラウド上のサーバの設定
    • Juniper FireflyのConfig例
    • エッジにいるルーター(RTXとか)のConfig例
    • VMイメージがあると嬉しい
  • オリジナル梱包箱を作る時の材料…と思ったら書いていただいてました。

  • NOCツアー: 大変だと思いますが…PyConでやっていただいてかなり勉強になりました

続いて、ネットワークを絡めてこんな事をやってみたらどうだろう!です。

  • 位置情報スタンプラリー: 満遍なくまわってもらう動機にする
  • IPアドレスで抽選会: DHCPから割り振られたIPで当選番号が決まる! 開発あんまりいらない
  • ハッカソン: 機器のsyslogをfluentd等を経由してGoogle BigQuery等に蓄え(MAC IDなどは伏せて)、そのデータを使ったハッカソンをやる。
LINEで送る
Pocket

小中学生にプログラムのデバッグを教えるときに僕が引っかかった3つのこと

LINEで送る
Pocket

※エントリの最後にお知らせがあるよ!

プログラミング教育の熱が高まり始めている今日この頃。今年から本格的に、小中学生向け プログラミングスクール「TENTO」にて、ソフトウェア開発教育のボランティアをしています。巷ではワークショップ型で1回ぽっきりのものが多いですが、TENTOでは書道やピアノの塾と同様、継続して指導している点が特徴です。

さて、最近こんな記事がありました。

 イギリスの場合は、Key Stage 1(5歳〜7歳)のコンテンツは以下の通り。アルゴリズムって何?から始まり、デバッグしたり、学校外でのテクノロジーの利用とか、個人情報についてのこととか、たしかに大事!と思うことが多い。

(中略)

 そして、どちらかというと、プログラミングの教え方がわからない先生ほど、「お手本を見て、このとおりに書いてみましょう」みたいな授業をしてしまうんじゃないかな、と思います。そうすると、子どもたちはきっと、「わけがわからないまま」に、ただ写してしまうのではないかと思います。
 ただ写すのがトレーニングになるかもしれない、という可能性もありますが、本来与えたかった学習目標はそうしたことなのか、というのが考えるポイントだと思います。

プログラミング教育について思うこと – 教育ICTリサーチ ブログ より引用

一つ一つの項目について、いろいろな話があるのですが、今回は「デバッグ」について僕が指導中に引っかかったお話を、「知識」「モデリング」そして「心理」の3つまとめてみようかと思います。

知識が無いばかりに遠回りな実装をしている

まずは、知識の有無によって出る問題です。

知識が無いばかりに、遠回りな実装をしてしまう生徒さんがいます。例えば、Scratchでゲームを作る際、単に敵キャラを増やすために複数のスプライトを予めコピーして増やそうとする事があてはまります。

こうしてしまうと、あらかじめ複製した敵キャラ スプライトの一つのプログラムを変更してしまうと、他のものも同様に実装し直すか、コピーし直さなければなりません。そうしていくと、いつかどのスプライトのどのプログラムをなおしたのか、そもそもどういう実装にしたかったのか、生徒さん自身がわからなくなることがしばしあります。

この問題を解決する方法の一つは、基となるスプライトをクローンして増やす事です。こういった知識を、指導者は提供します。また、僕は指導の時に実装例を積極的に作って、理解してもらうようにしています。こうする事で、どういった境遇のときにどのようなメソッドを使えば良いのか、腹の底で理解してもらいやすいのです。また、他者の実装をまねてみることで理解を深める場合もあり、その場合はどのように探し出すのかを指導しています。

これは、アルゴリズムなどでも同様です。プログラミングで必要な数学の知識は高校以上で学習する事が多くあります。例えば、敵キャラを動かすために三角関数を用いたり、出現率を計算するために確率論を用います。とはいえ、これはほんの触りです。

従って、指導者は各種プログラミング言語で実装できる力が求められます。Scratchは阿部先生が書かれた本がありますので、ぜひ参考にしてみて下さい。

構造を生徒自身で理解できないでいる

続いて、モデリングの問題です。

小学生は、特に「こんなものを作りたい!」と思って、ガシガシとコーディングします。この集中力は目を見張るものがあり、感服するばかりです。しかし、ここは小学生、途中でコードがこんがらがり始め、バグが出てきます。そのときに、どこでどのような問題が起きているか生徒自身が理解できなくなってくるのです。例えば、Scratchではメッセージをブロードキャストする事で他のスプライトの挙動を制御する事ができるのですが、そのメッセージの管理が破綻したりするのです。

この問題の解決方法は実に様々あり、実際に開発現場で働く方々の中でも数多くの知見があるかと思います。そんな中、僕は2つの方法をとって解決を促しています。

  1. プログラムのライフサイクルを整理する
  2. グローバルに影響するメッセージや変数を整理する

1つ目ですが、次の2次元に分けます。Scratchですと、1次元目は「背景」及び「スプライト」毎に分けます。2次元目は、「初期時」「実行時」そして「終了時」の3つの時間軸に分けます。肝は2次元目です。例えば、ゲーム開発であれば、敵キャラですと「初期時」にはどこに生成するか、HPはいくつにセットする、など初期状態とは何かを整理し、生徒自身が定義します。これを忘れてしまうと、ゲーム中に敵キャラがおかしな場所に登場したり、ダメージを受けきった状態で生成されてしまっていきなりやられてしまうなどの問題が出ます。また「終了時」は、ボスを倒したあとに敵キャラを全て隠してステージクリアの背景に変える、そしてスコアを保存してランキングにまとめる、等の整理をしてもらいます。

ライフサイクルを理解しないまま進めてしまうと、どのタイミングでどのスプライトがどのような動きをしているか理解できず、問題を切り分ける事ができません。そのため、生徒自身でバグを収束させる事が大変困難になってしまいます。

2つ目ですが、これまたScratchを例にとります。メッセージを使うと全てのスプライト・背景にブロードキャストされる事はご存知かと思います。これを使って別のスプライトを制御する事はよく使われる実装ですが、このメッセージがどこでどのように掴んで処理しているのか、そしてそもそも1つ1つのメッセージがどのような意図を持って発しているかを定義せず、生徒さんがなんとなく実装を進めてしまっている場合があります。コードを書いた事がある方であれば、あーこれはいわゆるスパゲッティコードになる要素が満点!である事がおわかりいただけるかと思います。

僕は、メッセージ毎に何をしているか、整理して書き出してもらう事で解決しています。見通しが立ちますと、自分自身がどのような実装をしているのか、生徒自身で理解できるようになります。そうすれば、自分で問題を解決するのは時間の問題ですね。

プログラミングに限らず、問題をどのように発見し、クールに解決するかは、以下の本が大変参考になります。

問題を自分自身に受け入れない

これは、気持ちの持ち方の問題かもしれません。

上記の2つの問題を指摘した時、素直に聞く生徒さんと、そうでない生徒さんがいます。素直な子はここではあまり問題になりません。問題は後者です。

これは僕自身の分析ですが、次のような心理になっているのだと思います。

  1. 自分は正しいと思っているのに間違いを指摘されるのが辛い
  2. コードの問題を追及しているときに自分自身が追及されていると思っている
  3. 気が乗らない

1は、大人でも難しい時があります。ただ、プログラムは大変素直でして、原則「実装した人が書いた通りに動く」のです。話を聞いたあと、だいたい僕はそれを伝えています。ただ、それをいち早く生徒さんに飲み込んでもらえるための良い方法を知りません。どなたかと知見を共有できたら良いなと思います。

2は、これまた大人でも難しい問題です。行った作業について問題を指摘しているのに、自分自身の人間性に問題があると捉えてしまい、かたくなになる生徒さんがいます。この、物事と自分自身を分離させるのは、一度紐づくと切り離すのはなかなか難しいのです。特に、自分自身で精魂込めたプログラムだとしたら、問題はより深くなります。僕は、「君ではなくてプログラムの作りについて指摘している」点を明確にしながら指導しています。ただ、先の1の問題と同様、より良い方法を誰かと共有できたらと思っている今日この頃です。

3は、僕自身も仕事のときにあります。想定と違い動かなくなったコードを目の前にするのは辛い事です。ですので、気が乗らない時は、気が乗るまで待ちます。大人と違い、小中学生は切替が早い子が多く、気分転換すればだいたいあとは大丈夫だったりします。また、気を晴らすのがあまり上手でない子は、全く違うプログラミング言語や教材に触ってもらって、気持ちを切り替えてもらう時もあります。または、雑談をする事もあります。実は、僕が妖怪ウォッチを知るきっかけはTENTOだったりします。

必要であれば、児童心理学をやった方がいいのかなとも考えています。

生徒と同じ目線で 成長は早い

ここまで、僕がプログラミング教室でデバッグの指導をしている際の3つの事柄を、「知識」「モデリング」そして「心理」の3つに分類してお話ししました。

将棋や囲碁に「多面打ち」というのがあります。これは、指導者や上級者が、複数の生徒と同時に対局します。僕はやっているのはまさに(便宜的に言うと)ペアプログラミングの多面打ちなのです。というのも、プログラミングは一人一人が違う成果物を作りますから、成果物に対する指導は画一的に行う事はほぼできません。講義形式の指導は、できたとしても多くの人が使う知識に関する部分までです。

また、ここまで「指導」や「教える」という言葉を便宜的に使いましたが、僕自身はその意識はありません。あくまで、問題を「一緒に考える」事を通じて、生徒さん自身がプログラミングを学ぶ際の手伝いをしているだけです。それどころか、中学生にもなってくると、自力でプログラミングスキルを磨き続けてきた子は、指導者の知識を凌駕する分野を持つため、まるで大学院生が指導教授に相談する姿そのものをやるだけです。それほどまでに、生徒さんの成長が早いのです。従って、同じ目線で接する事が今は最善であると、僕は考えています。

そう考えて行きますと、指導者はめまぐるしく変わるコンピュータ技術の知識を日々獲得し実践しつつ、その技術を支えるモデリングスキルと心の持ちようを予め作り上げておく事が大切だと、僕は思っています。その上で、日々指導者の立場として生徒と向き合う事を試されているのではないでしょうか。

お知らせ: 小中学生が開発したプログラムの発表を聴きにいらっしゃいませんか?

TENTO

来る2014/10/26(日) 13:00より 渋谷ヒカリエにて、TENTO・ビスケット塾(デジタルポケット)で学ぶ生徒さんたちが開発したプログラムを発表する「第3回 プレゼン大会」を催します!一般の方も観覧できます(1,000円)。ご家族そろって足を運んでいただけましたら幸いです。プログラミング教育の一つの例、そしてTENTO・デジタルポケットがプログラミング教育を通じて何を目指しているのか、知っていただけると思います。

事前にWebサイトからお申し込みをお願いします。直前でも大丈夫です。

また、過去の模様はブログにまとめています。どのような雰囲気か知っていただけるものと思います。あわせてご覧ください。

LINEで送る
Pocket

ITインフラ 業務自動化現状確認会を催しました #infra_auto

LINEで送る
Pocket

昨日、「ITインフラ 業務自動化現状確認会」という勉強会を催しました。前々からゼミナール形式の勉強会を開いてみたいと思っていまして、ちょうど @kuwa_tw さんとある話をしているときに流れで「一緒にやりましょう!」と話しかけた事で実現しました。

人が集まるか心配したのですが、ふたを開けてみれば自動化に造詣が深い10人の方にお集まりいただきました。Togetter「ITインフラ 業務自動化現状確認会 (2014.10) #infra_auto」に模様もまとめています。

僕の発表内容

社内向けに開発した”hb-agent”という構築自動化・ドキュメント自動生成ツールについて紹介しました。

勤務先のハートビーツはMSPとして、お客様のサーバを預かり、構築・運用・障害対応・チューニングを一手に引き受けています。その中で、これまで培ってきたノウハウがたくさん存在します。一方、IaaSをはじめとして大量のサーバが即座に構築できる時代になり、かつ自動化が進展しています。そんな中、自社サービスとはちがい、たくさんいらっしゃるお客様それぞれ違った環境がある中で、どのような形で自動化すれば良いのか、自分たちで模索する必要がありました。今回は、その経緯についてお話ししました。

話している中で皆さんに刺さったのが、こういったツールを社内に普及させるために半年程度で完了した、という点でした。良い技術、良いツールを準備しても普及させるのが大変である事は、各地で聞かれます。そんな中で普及できたのは、次の点があったからだと考えています。

  1. 社内勉強会での宣伝
  2. ハンズオン会の開催
  3. CTOを初めとした上層部の後押し

1は、まずは「存在を知ってもらう」事を目的としてやりました。興味がある人を見つけて、まずは同志を作る事ができます。

2は、今考えると最も大切なプロセスだったのだろうと思います。数人を会議室に集めて、ハンズオンを行います。当然、全員集まらないので、何回も(確か5回はやった)行います。その上で、「触って」「感動して」そして「理解」してもらう事で普及を進めます。触る事で何者かがわかりますし、今までと変わる部分をきちんと体験してもらう事で良さを伝えようとしていました。そして、良いと思ってもらえれば、自然と使ってもらえます。

3は、CTOの @netmarkjp さんの「プログラム開発を通じてITインフラ 構築・運用業務を効率化するぞ!」という強い意志のもと、自動化を後押しをしていただけたのはとても大きかったのです。大方針を上層部の方たちと共有でき、その上でリーダーシップを発揮していただけるほど、やりやすいものはありません。

あと、ひらしーさんからドキュメント自動生成部分は公開されないの?という話を頂きました。時間を作って、ちょっとがんばってみようかなと思います。

なお、今回紹介したのは、自動化を進めている事の一部です。他の話は、また機会があれば現状確認の題材にします。

感想

ITインフラの自動化、本当に進展が早いですよね。「Automation Tech Casual Talks #1」という勉強会が2012年にありましたが、その頃とはだいぶ変わりました。1年前ともまた違いますよね。

さて、今回は名だたるWebサービス企業やITインフラを支える会社にお勤めの方が来ていて、とても濃厚な時間でした。そんな中で、話を聞いていて次の点が印象に残りました。

  1. 業務内容によって自動化の方針が大きく違う
  2. 規模と自動化の進展状況により悩みが違う
  3. ツールを調べる・作る力が自動化をより楽にする

iは、特に自社サービス・受託で自動化の方針が大きく違う事がわかりました。自社サービスですと、開発した製品に沿って完成度の高い自動化を進めます。一方で、似て非なるものが出来上がってしまう事があり、その整理に心血を注がねばならない悩みがある事がわかりました。受託ですと、お預かりしたお客様毎に状況が違うなかで、共通した秘伝のタレや結果をベースに最大公約数を見つける必要があります。非常に大変な作業なのですが、これができるとどのようなお客様に対しても、より素早くかつ人によってばらつきが少ない品質のサービスを提供する事ができるようになります。非常に面白い話でした。

iiは、大規模な場合、小規模がたくさんある場合とでまた悩みが変わってくることがわかりました。 例えば tnmt さんの話ではありませんが、皆さんの会社ではどのようなホスト・ロール管理をされていますか?その必要は無い規模?でもその環境って再構築できます?ふむふむ…と色々出ますね。

iiiは、ひらしーさんのように serverspec-runner というプロダクトを作り、B2Bだとよくあるテスト項目書の生成を自動化する事でみんなを幸せにできる人がいます。また、れいさんのように最新の技術をキャッチアップし、より自動化を楽にする事でみんなを幸せにできる人がいます。その中で、自分は何に貢献することが良いのか?は自問自答し続け行動する必要があると、覚悟を新たにしました。

まとめますと、ITインフラ、特にこの日参加した自動化を担当する人たちは、自分の所属する組織の状況を俯瞰し、その中で最も効果がある点に手を入れる事で、組織に貢献している事がわかりました。このような優れた視点と技術を持っている人たちと情報交換をする機会に恵まれ、僕自身とても幸せな時間を過ごす事ができました。

皆さんの発表内容

いつものノートです。オフレコ部分は省いています。

@noexpect さん

  • Jira を用いた大組織におけるノウハウ共有の方法についてのお話

  • ※公開するか判断に迷ったので一旦オフレコにしておきます

@rrreeeyyy さん

スライド: Itamae 使ってみた

  • Provisioning Toolの話

  • Ansible + Serverspec
    • Python + Ruby
    • いろいろ覚えないといけない
    • れいさん的には気持ち悪いとのこと (確かにそうだ)
  • Itamae
    • 先日の Infrastucture as Code 現状確認会 で発表された
    • よいところ
      • Agent Less
      • Simple
      • Ruby DSL Like a Chef (互換性は無い)
      • Specinfraの上で成立している
      • gemでレシピが管理できる(Berkshelfいらない)
  • dry-runいい感じ!
    • diffも映っていい感じ (あれChefでも出なかったっけ)
  • 設定も集約させやすそう
    • 変更も他の設定に波及させやすい
  • ディレクトリ構造
    • provision
      • レシピ
      • いらない場合はInclude Recipesを削除するだけで事足りる
    • spec
      • Serverspecのテストコード
  • デモよかった!
    • レシピ公開が期待される

@oko_chang さん

スライド: 発表資料

  • Cloud Automator のインフラ+開発担当

  • 開発
    • Rails
    • AWS SDK for Ruby
    • AWS Flow Framework (AWS Simple workflowを動かすために使う)
  • 監視サービスは持たず、全部Cloud Watchに集約。
    • 通知もSNSから。
  • SaaSは積極的に使う
    • 人が少ない
    • HipChat連携してる
    • Errbitを使ってエラーもとりまとめている
  • メンバー なんと5人
    • 仕事は兼任
    • 自動化をして開発時間を捻出
  • OpsWorks
    • Load Averageベース・時間スケール(Job集中を見積)でAuto Scaling
    • Auto Healing – インスタンス障害への対処
  • Itamae, serverspec 積極導入中

  • EC2再起動祭り
    • これにも対処しやすかった
  • 問題
    • Web上の設定が見える化できない
  • まとめ
    • 効率化して開発にリソースを割く
    • 設定内容の見える化
  • 議論
    • North Californiaにあるのは?: DRが主目的 マルチリージョンでできるように
    • OpsWorks インスタンス枯渇問題
      • 日本だと起きやすい
      • 足らない問題が出やすいインスタンスは避ける t2系とか
      • 最終的にはSpot Instanceを使う

@koemu

  • 自分自身: 前述の通り

@y05_net さん

スライド: インフラ構築とテストについて

  • serverspec-runner

  • serverspecのテストコードをそのまま利用する
    • テスト結果がテキスト(テキスト表、Markdown, CSV)に出せる!
    • 納品ドキュメントがすぐ作れる!
    • 最高だ!!!

@kuwa_tw さん

スライド: Chef環境の闇

  • 統合Chef Cookbookリポジトリの問題
    • 集約しよう!となるよね普通
    • はまりポイント
    • 依存度高い問題
      • リポジトリの間の依存度が高い
      • yumぐちゃぐちゃ どこ見てるの?
      • 整理した
    • 名前かぶり問題
      • apache, nginx めっちゃあるで
      • Community Cookbook使えない
      • Chefサーバやめない?
      • Renameで対応
      • 今後はCommunity Cookbookにしたい
        • しかし今度はどれ使うの?
        • ★の数?
  • 最初の設計間違えない!
    • (とはいえ、初期の頃はベストプラクティスも無かったから色々頭が痛い。)
  • Community Cookbook どう使うのか問題

  • 集約は無理にしなくても良いと思う

  • Chef-solo + Berkshelf 移行で幸せになれました

  • Chef-serverはサーバ管理に直結しないと使いづらい

@hokkai7go さん

スライド: なし

  • 前の会社の知見が本に活きた!とのこと。

  • Cookbook CI
    • やりすぎなのでは!?
    • 成果物をみるのが正しいアプローチだよね
      • Serverspec
    • コードの見通しも必要だが
    • テストのやり方は決まってない感ある
    • 全部の設定はみられない
    • 全体がちゃんと動く所まで確認できないのがわからん、どうすりゃいいんだ!
  • 自動化に至る軌跡
    • 受託・自社サービス それぞれ違う
    • どんなステップを踏んでどうするのか
    • そこを突き詰めて行きたい

@tnmt さん

  • 資料を作ったモティベーションをはなします

  • 10分デモし倒します!
    • Puppet
  • ホスト管理
    • みんなどうやって管理してる?
    • ホスト名の命名ルール
    • インベントリ収集ツールの結果
    • Zabbixの情報 → 監視しているサーバは存在すると決める
  • インベントリ管理サーバ パワーアップ

  • 議論
    • Consul
      • サーバ一覧出せるよね
      • DNSとも連携できるよね

@buty4649 さん

発表メモ: 発表資料

  • Hubot

  • デモンストレーション!

  • ChatOps事例
    • muninのリンクを返す
    • nagiosのリンクを返す
    • httpingする
    • テストメール送信
    • リマインダー
    • 自動デプロイ
      • CapのWrapperを叩いている
  • 議論
    • Hubotがいいところ
      • 流行っている
      • mentionのハンドリングとかは楽
      • 他のチャットエンジンと切り替えやすい
    • CoffeeScriptの辛み → 非同期パターン

@OmochiStrike さん

  • オフレコ話

おわりに

「理想の勉強会」とは何でしょうか。僕は、ゼミナール形式で知見を交換し、議論しあう場だと思っています。今回、こうして自分自身が参加してみたい勉強会を催せた事を本当に嬉しく思っています。仕事、家庭、個人、色々ある中ではありますが、またゼミ形式で現状確認会を開催したいと考えています。3ヶ月も経てばまた時代は動いているでしょう。その節はよろしくお願いします。

最後に。呼びかけに応じていただいた @kuwa_tw さん、懇親会会場をセットアップしてくれた @rrreeeyyy さん、そして誘導やセッティングを支援いただいた @ttkzw さん、どうもありがとうございました!

LINEで送る
Pocket

EOS 7D Mark II 体験イベントへ行ってきた #eos7dmk2

LINEで送る
Pocket

ええ、行ってきましたとも。Canon Grand Presentation 2014 Tokyoに。

デジカメWatchの「EOS 7D Mark IIの体験イベントレポート」に広く多くの方が欲していると思われる情報が既にあるので、自分で見た内容をとりあえず書いておきます。

※EOS 7D Mark IIは、以下7D2と略して表記します。

DSC_0174

入場時

28日(日) 15:00過ぎに入りました。
それなりに人がいましたが、体験ブース、説明ブース、共に待ち時間なしで入ることができました。講演のブースは人が多かったので見るにはなかなか厳しい状況でした。

説明ブース

EF-S15–85mm F3.5–5.6 IS USM を着けて色々話を聞きました。本当はEF 24–105mm F4L IS USM(いつも使っているレンズ)がよかったんですが、隣の人が使ってたのでやむなしです。

ここでは、動画撮影を試したのだけれど、吸い付くように歩いている人にフォーカスが合い続けます。なお、録画は連続30分まで(一旦切れば続きは撮れる)、電池はどの程度持つかの公称値は発表していない、との事でした。ちょっとしたものか、映像作品を作る際に何カットか撮る場合はあまり問題にはならなさそうです。ただ、長時間連続のビデオ撮影時は外部電源供給で利用した方が良さそうです。

体験ブース

バスケットボール 3 on 3の模様を撮影できるブースにも行きました。

レンズはEF 70–300mm F4.5–5.6L IS USM、EF400mm F2.8L IS II USM、EF400mm F4 DO IS II USM、そしてEF200–400mm F4L IS USM エクステンダー 1.4×です。尚、全て手持ちで試しています。

ISO6400にあげてISを駆使すると、手持ちでも十分問題なく撮影できる事がわかりました。まあ、後で腕がちょっと痛かったですね…。
それに、下手な鉄砲数うちゃあたると言わんばかりに撮れます。ゾーンAFにしておけばだいたい狙った所にピントは来ていまして、あとはちゃんとフレームに収められるかどうかだけの問題でした。

相方もEF200–400mm F4L IS USM エクステンダー 1.4×がついたカメラで試していましたが、ちゃんと問題なく撮影できていました。なお、このレンズは3,620gもあります!10年前だったら屋内で手ブレ無しで撮ろうとすると一脚は必須だったでしょう。

なお、撮影したデータをSDカードに保存はさせてもらえませんでした。EOS 70Dの展示会のときはやらせてもらえたのですが、今回はダメなようです。

ショールーム

常設のショールームも開いていました。

意外に空いていたので、7D2にEF 24–105mm F4L IS USMをくっつけてもらって試させてもらいました。ここでわかったのが、カメラが重いせいか手に持った時のバランスがちょうど良いのです。50Dだとカメラが軽いのでレンズの重さを感じるのですが、7D2だとそうならない。こういう事もあるんだなと感心しました。その分、結婚式等の長時間の使用時は体力を要求されそうです。

せっかくなので、普通に近くのものを撮ったり、部屋全体を撮ったりと自分自身が通常使う状態に近い感覚を試しました。すると、当然でしょうが通常の1枚撮影も問題なくこなせることがわかりました。また、ミラー消失時間も短いのもなかなか良かったです。高速連射のために、ミラーが上がるのも速いのでしょうね。

相方は、カメラもそうですが、カメラ教室の方に興味を持っていたようでした。NikonよりもCanonのほうが写真教室が充実してますものね。

退場時

タオルを人数分、パンフレットを1セット(何か一杯入ってた)、そしてインプレスのムックをもらいました。

手荷物がだいぶ重たくなりました…

まとめと感想

7D2はカメラの性能で動きものが「撮れてしまう」恐ろしいカメラだという事がわかりました。

基礎ができていないと、カメラの性能に飲み込まれてしまいそうです。

僕としては、屋内のイベント撮影時にISOが遠慮なく6,400まであげられて(EOS 50Dではノイズの関係から1,000くらいで止めていた)、かつ普段見慣れているAPS-Cの画角を使い続けられる点が良いなと思っています。あと、EOS 50Dよりもモノとしての耐久性がありそうなのも、安心感があります。

5年使ってきたEOS 50Dは、そろそろ交代の時期です。良い選択肢が生まれました。

LINEで送る
Pocket