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

PyCon JP 2014 Day 3 感想とノート #pyconjp

LINEで送る
Pocket

昨日に続いてPyCon JP 2014に足を運んできました。日本のカンファレンスながら、英語が飛び交う国際感高いものとなっています。実行委員の皆様、話者の皆様、お会いした皆様、大変お世話になりました。お楽しみ様でした!

それでは、今回もノートをアップしておきます。こちらは2014/09/14(日)に行われた3日目、カンファレンスとしては2日目のノートです。

IMG_2360

抽選会ではpepperが当選番号を読み上げていました。先進的!

2日間を通した全般の感想

  • 科学計算系、特に機械学習とそれに派生する話が他のカンファレンスに比べて多かった。自分がこれらに携わっている時に聞けていたら、もっと研究を楽に進められたはず。
  • PythonとITインフラ系の話を絡めたセッションは特になかった。というか、機会があれば自分が話せばいいのかとも考えている。
  • オフィスアワーが設定されていたのはとても良かった。実は、YAPC::Asiaの発表をしてから、質問したいけどkoemuを捕まえられなかったというコメントをもらっていて、何か申し訳ない気持ちになっていたからだ。実際、PyConの懇親会でもYAPCの発表の件で声をかけられてもいる。
  • Python 2と3の間にある溝をどう捉えるか、Pythonに入れ込んだ事がある人は考えなければならない課題となっている。ただ、僕の中ではまだ3にどっぷりという判断ができないので、辛い。
  • 懇親会は向き・不向きがある事を再発見した。当たり前の事だが、身内だとより現実的に捉える事ができた。今後は、懇親会に来てみたいんだが迷っている人の背中を押す事ができればと考えている。
  • 西尾さんの講演の後、ポスター展示を見てしまうと時間を持て余してしまって、さてどうしたものかと悩んだ。例えば、YAPC::Asia 2014のように、無限コーヒーコーナーを通じて交流を深められる場があると良いのかもしれない。
  • 相方とイギリスに旅行に行ってから英語がスムーズに話せる事の重要性をひしひしと感じていたが、今回さらにその認識を深める事となった。やはり、英語で質問・会話できないのはかなりの機会損失になっている。かなりやり込まないと行けない。もっと異文化交流したい。
  • 弁当やケータリングにハラル・ベジタリアンメニューがあるのは素晴らしい。そして、日本では本当に珍しい。海外のカンファレンスではよく準備されているので、日本人もそう言う意識は高めた方が良いと思った。

Keynote

  • @nishio さん
    • サイボウズラボ
    • 邪悪なPythonista www
    • Slide
  • 感想
    • ソフトウェア技術者の育成、これまで職人芸っぽいものがあってモデル化されていなかった所を、西尾さんが取り組まれているのはいつも感服する。
    • 西尾さんが持っているテーマを改めて棚卸しして伺っているように思った。
    • ソフトウェア工学とはまた違った、ソフトウェア技術者育成のモデルを作る事に、自分も加担していくモティベーションをあげる良い時間となった。
    • 「盲点」がみつかると思わず死にたくなるほど辛い気持ちになりますが、西尾さんの話を基準に考えるとそれは普通の事でそれほど気にする事でもないのがわかり、安心した。
  • 1行でPythonを書くwww ワンライナーの話
  • サイボウズラボ
    • 次世代のグループウェアを研究
    • 利用シーン
    • 自動化
      • 設定管理
      • テスト
      • Jenkinsスクリプト
    • インフラ
      • DRでのバックアップスクリプト
      • P2P automatic failure recovery system 月読
    • 解析
      • 収集
      • データクレンジング
      • 統計処理 NumPy, SciPy
      • 今日はここをクローズアップ
  • 解析について
    • 西尾さんの担当
    • kintoneとGitHubの比較: ソースではなく、データを溜め込む所が違う。
    • kintoneにはたまっているデータを見て、どのようにビジュアライズするか提案する機能がある。これはすごい。 詳細:「おすすめグラフ」の裏側
    • プロトタイプ、Flask + NumPy。
  • Groupware
    • Group + Software
    • Douglas C. Engelbart: Augmenting Human Intellect
    • Googleのある状態: 知性が強化されていると感じませんか?
    • コンピュータによって人間を強化する
    • モニタリング
      • 自分自身をモニタリングする事はできない。ダメな時にダメな自分でモニタリングしても、気づけないのではないか。
      • 他の人にモニタリングしてもらう: 精度は上がるかもしれないが、プライベートな情報等を渡さなければならず、人間関係が問題になる。
      • ではコンピュータにやらせてみよう。
      • やる気の出るアドバイス
        • 僕は前使った時にやる気が出ました!!!
    • 人間の情報を取り込む能力を強化するために、コンピュータを利用していく。
  • 人間の増強の4要素 (Augmenting Human Intellect)
    • Artifacts
      • Computer, Software …
    • Language
      • Design Pattern, 専門用語…
    • Methodology
      • 問題解決のための手順、戦略…
    • Training
      • これらを利用できるための育成・教育
  • Discover – 方法論
    • 詳しくなればなるほど、バイアスに縛られて見えなくなるものがある。
    • だからこそ視点を変えて行く必要がある。
    • Known <–> Unkonwn の間に「不明」な領域がある。
    • まずは「知っている領域」を明確にする。そうすると、盲点を理解できる。
  • 抽象的なものは、具体的なものに紐づける事で理解する事ができる。
    • 例えばTrueの定義の違いとPythonの事例
  • 歴史を追うことで盲点に気づく
    • 例えばなぜPythonにはNew-Styleクラスがあるのか
    • それは型とクラスを融合する必要性があったから
  • 経験をする事で理解する
    • 例えばPythonは 1 / 2 = 0.5 にならない
    • これってMediatorパターンって名前だったんだ!→経験に名前が付けられる事で言語化できる
  • 学びは必ずしもひとりでする事ではない
    • 経験の異なる他人と会話する事で盲点に気づく
    • オフィスアワー、ブログ、メールでのコミュニケーションしましょう!
    • 今後、情報は英語化を進めます。
      • 僕もやろう。
  • 質問
    • Q: 認知的不協和
    • A: U理論 (どう書くか後で西尾さんに聞いた、ありがとうございました!)では7つのステップに分解されている
      • 自分以外の他人を自分が啓蒙するのは、良い思考ではない。自分が変わる方が良い。
    • Q: CEで成功するポイントを挙げていると思う。モデリングをどう考えるかもポイント思うがどうか?Abstraction自体が大事なのではないか?
    • A: とても大事な話だと思う。 エンジニアの学び方─効率的に知識を得て,成果に結び付ける の第3章にまつわる話。
      • 試作して試して確認して…を繰り返して精度を上げる。
      • 人文系のような実験が難しい場合は、Grounded TheoryやKJ法を適用する。

OpenCVのpythonインターフェース入門

  • Masaki Hayashiさん
    • 機械学習の画像認識の研究に従事 (D3)
    • 人物姿勢推定を動画から解析する研究をしているらしい
    • Slide
  • 感想
    • がんばってC++を書く事が減るのはとても良いですよね。今度からPythonで書く。
    • CUDAとかはサポートしていないそうですが、これが直ちに問題になるのは限られた状況かなと理解している。
    • (話とは関係ありませんが)会場設営をもっと早め、せめてもう10分早くやるといいと思った。ポスターセッションが長く続いていたので、入場待ちの人が廊下に溢れていた。
  • 概要
    • OpenCVのPython I/Fのチュートリアル
    • C++で時間を損している人もいる!ぜひPythonでも触ってほしいなー
    • Scikit-learnやPandasが使える人が画像認識も使えるようになるといいな
  • OpenCV
    • Python, Java用のラッパーもあり、C++と同じように使える。
    • 現在は 2.4.9、先日 3.0.0のα版も出た。
  • 応用モジュール
    • 機械学習のライブラリは、OpenCVではなくscikit-learnの利用をお勧めする。実際、連携しやすいそうです(pandasも)。
  • 画像の可視化
    • matplotlib,PIL,scikit-imageはRGB画像で保持するのに対して、nnOpeCVはBGR画像がデフォルト。変換処理が必要。
  • あとは、実際の使い方を解説。
  • HOG, SVMを使って人の検出がOpenCVで検出
    • 詳しい話は GitHub リポジトリにて。
  • 質疑応答
    • Q. デメリット
    • A. 計算速度が遅い
    • Q. 2.4.9か2.5か?
    • A. anacondaで入るのが2.4.9なのでこっち
    • Q: GPUアクセラレーション対応のラッパはあるか
    • A: ラッパがない

Pythonによる非同期プログラミング入門

  • Hironori Sekineさん
    • アライドアーキテクツさん
  • 感想
    • 非同期なコードを書きやすいというだけでもPython 3.4に移行するのはありなのではと考えた。
    • サンプル、あまり実感が沸かなかった。もう少し現実に即した例だと嬉しい。
  • Agenda
    • 同期・非同期のおさらいと違い
    • Pythonの非同期F/W
    • asyncio概要とサンプル
  • 同期・非同期のおさらいと違い
    • 非同期はCPUバウンドな処理には有効ではない
  • Pythonの非同期F/W
    • twisted
    • tornado
    • gevent
    • そして thread, multi process (これはライブラリという訳ではないけど)
  • Twisted
    • イベントドリブン型 NWプログラミングF/W
    • 2003年〜
    • defferedを駆使して書く
  • Tornado
    • FriendFeedが作り始めて今でもメンテされている
    • Web F/W + 非同期通信ライブラリ どちらかを選択する事も可能
    • 非常に高速 アドテクでも使われているくらい
  • さて
    • 選べるけど、どれがスタンダードかわかりづらい。
  • asyncio
    • PEP 3154 のリファレンス実装
    • Python 3.4 から標準ライブラリとなった
    • 各種プラットフォームサポート
    • 既存のF/Wを保管している
    • アーキテクチャ
      • Event loop: プラットフォームに最適なI/O処理を提供する
      • Corutines: PythonでいうGenerator
      • Future, Task: 非同期実行をカプセル化

NOCツアー

  • NOCのみなさん
  • 感想
    • 最高のカンファレンスは最高のITインフラに支えられている。
    • カンファレンスネットワークと、携わっている人はもっと評価されていいと思う。
    • 敷設、及びトラブル対応の手際の良さはハンパない。普段相当取り組まれているのだろう。
    • NOCツアー、仕事の差し障りがあるはずなのであまり大々的にできないかもしれないけど、話がこうして聞けただけでも良かった。そして、いきなりお邪魔してすいませんでした…。
  • See also: PyCon JP 2014 開催前レポート 第3回 会場・パーティについて :CodeZine
  • プログラムになかったけど、急遽(?)開かれていた模様。
  • ネットワーク機材、NOCの模様、及び各部屋への配線の事例について解説。
  • 設計
    • 事前に建物の配置等を確認していた。
    • 綿密に設計書を書かれていた。特に配線。
  • ゲートウェイ
    • Flet’s Nextをこのために引き込んでいる
      • (ONUはいつも家で見るそれそのもの)
    • DualStack-lite
      • IPv4はv6をトンネルしている
      • v6のIPが降ってきているのはそのため
      • IPv4は局側のLS-NATを使って外に出ている
    • カンファレンス2日目は最大110Mbpsをマークしたそうだ(カンファレンス1日目はもっとあったらしい)
  • Macのifconfigの結果
$ ifconfig   # 一部省略
en0: flags=8863 mtu 1500
	ether 84:38:35:??:??:?? 
	inet6 fe80::8638:35ff:fe44:8584%en0 prefixlen 64 scopeid 0x4 
	inet 10.1.0.25 netmask 0xfffffc00 broadcast 10.1.3.255
	inet6 2409:10::504:8638:35ff:fe44:8584 prefixlen 64 autoconf 
	inet6 2409:10::504:5481:e39:453e:628f prefixlen 64 autoconf temporary 
	media: autoselect
	status: active
  • DHCP
    • 約1,000個確保
    • 500〜600個程度リースされている実績を確認している
  • 機材
    • 事前に別の場所で設定、稼働テストを実施。 (これはLTで聞いた)
    • 機材の死活は Dead Man で監視。
      • Interopでも使われていたもの。確かにShowNetで同じものを見たな。
      • Pingのみでシンプルだがいいソフトっぽい。
    • YAMAHAさんから提供を受けている
    • Wi-Fi AP
      • YAMAHA WLX302 がメイン。
      • 予備はIIJのWi-Fi APがいくつか。
      • 大ホールは5台。
      • メディアホールは 2台。
      • 各会議室は1台。
      • 急遽、懇親会会場や1階のテラスに増設。
    • スイッチ
      • 動画送信だけ、品質が落ちないようQoSで優先して使えるようにした。
      • スイッチをリピーターとしても使っている。
      • 急遽AP追加もある程度見据えて設置。
      • 看板の裏等に隠してあまり目立たないようにしている。セキュリティ、及び景観を考慮。
  • ケーブリング
    • 3時間で構築 ただし事前の設計は綿密だったようだ。
    • 機材は看板の裏に隠して置いている。
    • 3階から4階は階段経由。隙間をうまく使ってケーブルをショートカットさせている。
    • メディアホールは3階から直接接続しづらかったため、調整室の窓から出している。なので3→4→3階と経由している。
    • 断線を考慮して、その可能性がある部分は部分的に取り替えられるようにメス・メスのコネクタでケーブルを分離。
      IMG_2357
    • その他の配線の様子はこちら。足の踏み場や防火扉をうまくかわして配線されています。
      IMG_2359
      IMG_2356

Python Quest in Taiwan

  • Keith Yangさん
  • 感想
    • 台湾、ソフトウェア開発教育に積極的だ。
    • 教材にPythonが使われているケースが増えているような気がしている。
    • ローカライズしてまで使ってもらおうとする組織力、すごい。日本ももっと大きな集団でやれたらいいなと思っている(実際ちょっとやってる)。
  • 変化・チャンス・そして挑戦
    • 教え、学び、書き、そして教育する
    • Pythonは学びやすい(と思う)
    • イギリス: Code Club
      • 放課後教育で9〜11歳に教えている
      • BBCがソフトウェア開発教育に関する番組をはじめているらしい
      • (前にLondonで聞いた話と同じだった)
    • CheckIO
      • 体験の共有?交換?
    • PyCon Taiwan (2014)
      • CheckIOを中国語で
      • 地元での挑戦
      • 英語から中国語に訳さないと
      • カスタマイズしたゲーム
      • 旧来の教科時間とぶつかってしまう
        • あー、とりくめなくね?これだと。
    • geekpy.org
      • 優秀者にはpycon taiwan 2014に参加できる
      • 楽しさを拡散させて行く
      • モティベーションを持つのが大変
  • PyCon Taiwan 2014
    • 100枚の学生チケットが売り切れた
  • 教え学ぶ勉強会
    • Taipei Python Workshop
      • 朝: setup games
      • 昼: チームプレー
        • Web, GUI, Mobile, Data
      • 良い結果を得られた
  • その他のイベント
    • PyLadies Taiwan
    • Django Girls Taiwan
    • Raspberry Pi Workshop
LINEで送る
Pocket