大学のバス時刻表のWeb-APIを作ってAWS Serveless Java Containerに上げるまで(2/n日目)

あけおめです。この記事はCIST (公立千歳科学技術大学) Advent Calendar 2022の6日目の記事だったことにします(書かれていなかった日を後日ハックしました)*1

はじめに

記事の目的や方針は前回の記事をご覧ください!

前回は、目指すサービス全体像を整理して、鳥瞰的なゴール「大学サイトにアップロードされたバス時刻表PDFに基づいて、バス発着時刻のデータ利用希望者に(もう少し扱いやすい形式で)データ提供を行うWeb-APIの作成」を定めました。

この記事では、さらに作成するシステムの概要を見据える手順を進めていきます。

「作ってみよう!」のその前に、システム概要を整理する

ゴールに向けて、さて早速プログラミング...となりたいところですが、もう少し堪えて、システムの概要を整理します*2

今回、最終的に作成したいのはWeb-API、というゴールの内容からもあまり大きいシステムにはならなそうな予感はしますが、一旦レイヤードアーキテクチャの中で、本件で行いそうな処理内容を当てはめて、どんなシステムにになりそうか概要を見据えてみます。

レイヤードアーキテクチャに当てはめた想定処理

プレゼンテーション層は、いつか学生が作ってくれるイケてるアプリ(クライアント)からの要求を捌くWeb-APIです。どんな要求がくるのか・どんなJSONを返答すれば良いかは後ほど考えましょう。

アプリケーション層は、ゴールの達成に必要なサービス群から構成されます。今回は、バス時刻表PDFからバス時刻を抽出してキャッシュするぐらいかなあと思いましたが、後述するデータ層に任せても良い様な気もします。そのほか、利用管理ぐらいはWeb-APIの設計上はあるんではという気がするので入れてあります*3*4

インフラストラクチャ層は、通常はDB操作などを行いますが、今回は大学サイト上のバス時刻表PDFを取得します。上述のとおり、PDFからの抽出もやってしまってもいいかもしれないと思います。ただし、テストのしやすさや、バス時刻表PDFが将来違った形で提供された時*5を考えると、サクッと実装を切り替えたい様な気もしますので、ここはアプリケーション層のインターフェースを実装する様な形ですすめたいと思います。

正直この辺りは、作成しながら調整をしていく可能性も大きいです。今回もガチガチには決めず、まあこんなものかなというアタリで進めます。なので、まだ手がついてない後半に取り掛かる中で、変わる可能性もあります。

簡単なことを文章や図にしてるけれど

なお、現実世界ではここまで思い立って脳内だけで組み立てるなら10分ぐらいです。

その脳内イメージをこうやって文章や図に出力するだけで10倍以上の時間かかってますが、でも文章や図に直す過程で、その10分の思いつきについてクールダウンしてもう一度考えたり、改めて自分の知識も含めてあやふやなところを再確認したりする*6機会を得ています。

多くの場合、これをチームでやるわけで、そうするとその人たちの脳内はさらにバラバラなわけで。こういう過程にしっかり時間をかけるのは改めて大事だと思います。

PDFの取得部分にむけて

さて、だいぶプログラミングのパートに近づいてきました。

定めたゴールからも、上記のシステム概要からも、当然、PDFの取得や抽出が一番重たい仕事になりそうです。

このあたり、実際のWebサイトの状況を見ながら、作戦を立てていきましょう。

実際のPDFを取得するWebサイトを見て、作戦を立てる

大学Webサイトから時刻表PDFを取得するので、実際の大学Webサイト(アクセスページ)がどうなっているのか確認してみましょう。

某大学のバス時刻表サイト

スクリーンショットを撮ったのが学休期直前なので、学休期とその後のバス時刻表PDFが一度に3つ掲載されています。ここに何個のPDFが提供されるかは週によってまちまちで、1ファイルの場合もあれば、2ファイルの場合もある様です。

ちなみにファイル名は

  • R4年度シャトルバス時刻表秋学期_1226-0110.pdf
  • R4年度シャトルバス時刻表秋学期_0113.pdf

の様に、命名規則がやや人間味あふれる感じです*7*8*9

また、このサイトには他にも乗り場などのPDFファイルが存在しているので、それらの中からWeb-APIで表示するPDF(例えば、時刻表PDFの一番上と決め打ちする、クライアントからのパラメータ等での指定を受け入れるなど)を考慮して取得しないといけなさそうです。

スクレイピングは少しオーバーかなあと思いながら、まずはシンプルな実装として、以下の様な処理フローを考えました。

  1. 大学のアクセスページのBodyを取得する
  2. 大学のアクセスページ内から、バス時刻表のpdfのパスを取得する
  3. バス時刻表のpdfのパスから、一番上に表示されているものをファイルで取得する(とりあえず、クライアントからの要求は想定しないことにする)

次回はこの処理フローの想定に基づいて、実際にPDF取得部分のプログラミングを進めていきたいと思います。

*1:年も明けましたが、まだ俺たちのクリスマスは終わってないぜ!

*2:本来のシステム開発であれば、この前段階でステークホルダーとのレビューを開始して、要求分析の続きや要件定義:ユースケースやユーザーストーリーを整理したり...を行いますが、前回述べた通り、この記事は業務ドメイン等に触らない、小規模な開発なのでスキップします。

*3:利用管理はこの記事の着眼点とは違うので触れない予定です。完全なオープンデータならいらないかも。

*4:難しそうな業務ロジックが入って来れば、それはアプリケーション層から利用されるドメイン層等に置きます。

*5:とはいえ、提供方法変わったらさっさと実装書き換えた方が早い気がします。なので実のところオニオンアーキテクチャっぽくしておきたいだけのカッコつけです。

*6:漫画から引用したいあのセリフどこだっけ?とか探すのも含む

*7:何故、人類(日本人)は全角と半角を混ぜてしまうのか...

*8:ブラウザキャッシュを回避するためファイル名を変えてると思いたい。

*9:PDFファイルの中身も人間味があふれており、こっちの方が後々問題になりそうだなと思ったので見なかったことにしよう。

大学のバス時刻表のWeb-APIを作ってAWS Serveless Java Containerに上げるまで(1/n日目)

この記事はCIST (公立千歳科学技術大学) Advent Calendar 2022の4日目の記事です。(本来投稿したかった日が埋まってたので、書かれていなかった日を後日ハックしました)

CIST (公立千歳科学技術大学)のカレンダー | Advent Calendar 2022 - Qiitaqiita.com

はじめに

AWS Serverless Java Container(参考1, 参考2)というのがあり、一度技術検証しておきたいなあと思いました。

実は、サンプルのping/pongがさくっと苦労なく数コマンドで動いてしまい、面白みがないので何か役立ちそうなものがあれば検証がてらAPIを立ててみたいなと。

せっかく本学のアドカレがあったので、情報系の学生に何か役立つような形にまとめていければと思いました。

想定する読者と書くこと

プログラミングを勉強した(している)が、授業レベルの課題以外にはあまり使ったことがない/実際にシステム開発等に挑戦中ぐらいのレベルの学生さんに向けて。

学生が読む価値が少しでもあればと思い、個人で作業をする時の範囲ではありますが、「私が(Javaで)何かソフトウェアを作るときはこういう手順を踏むなあ」というのを丁寧に書いていこう と思います。

メインのはずのAWS Serverless Java Containerの話は、最終回1回分ぐらいの予定です。何回連載になるのかは不明です。

以下本編です。

大学バスの時刻表について

課題感

某大学は、バス事業者に運行を委託する形で、市内や最寄駅から大学へのシャトルバス(以後、大学バス)を運行しています。

この大学バスの時刻表は、大学側が学生からの声を頑張って汲み取って「毎週変えていく」という体制になってからしばらく経ちます。

私は大学バスユーザーではないのでわからない部分もありますが、最寄駅の列車の発着時刻や毎週の開講状況にあわせてバス発着時刻をコーディネートしてくれるのはサービスフルに思える一方で、学生にはWebサイトで配布されるバスの時刻表PDFを都度確認する手間がある、というネガティブな部分も出てきているようです*1*2

こうした課題に、学生がこれまでにも色々なアイディアを出して改善(主にアプリ化)に挑戦してみる姿を見かけましたが、なかなかうまく行ってません*3*4

こういう状況を少しだけでも支援するには?

そんな中「時刻表PDF内のテキストを読み取り、オープンデータっぽくすれば、もう少し課題解決に迫りやすいのでは」と気づき、試した学生がいました。これは結構うまく動いていた(しばらくの間、時刻表の更新に同期していた)のですが、その後、あっさり時刻表PDFのフォーマットが変わってしまい、学生も卒業してしまったので現在は動いていません。

ただし、この例ように 大学の公開データを誰もが使いやすい形にしておくことは、学生が陥りがちな状況の一部が解決されている前提でさらなる挑戦に取り組める支援 となるかもしれませんね。

ちょうど、AWS Serverless Java Containerにも興味があったので、今回は「大学のバス時刻表のWeb-APIを作ってAWS Serveless Java Container に上げるまで」 として行ったことを一つ一つまとめていきたいと思います。

少なくともこの記事を執筆時点で完了している話でないので、ちょっとずつ暇を見つけて取り組む形です。完成するといいなぐらいで進めていきます*5

「作ってみよう!」のその前に、サービスの現状と目指すことを位置付ける

ここまで話をしてくると「じゃあ早速開発しよう!」という気持ちでコーディング等に走りがちですが、まずは落ち着いて、土台となるサービスの現状とやることを位置付けるところから始めましょう。

今回は、現状のサービスと、目指すサービスの全体像がどうなるのか、図などを使って整理 してみます。

現状のサービス全体像の整理

現状のサービス全体像(ステークホルダーとプロセス)を図示してみましょう。

[図]

現状のサービスの全体像(一部は仮定)

①大学職員は(内部的な情報に基づいて)時刻表の元データ(おそらくExcelと予想)を作成します。これが、次週のバス時刻表(案)の元データです。

②大学職員は、バス事業者にバス運行委託を行っています。ここで、大学職員からバス事業者へ、次週のバス時刻表(案)の承諾を得ていると考えられます。ここは時刻表元データ(もしくはPDF)をバス事業者に毎週提出しているのではないかと仮定しています*6

③承諾を得た大学職員は、バス時刻表(案)データからバス時刻表PDFを作成します。④また、大学Webサイトにアップロードを行います。

こうして準備されたバス時刻表PDFを、大学バスの利用者は随時大学Webサイトにアクセスして確認を行う形になります。

目指すサービス全体像の整理

今回目指すことは、④で大学サイトにアップロードされたバス時刻表PDFに基づいて、バス発着時刻のデータ利用希望者に(もう少し扱いやすい形式で)データ提供を行うWeb-APIの作成 です。①から④の業務プロセスは触らないので、良く言えば従前通りのまま*7、ちょっとしたバス利用者アプリを卒論/学生プロジェクトなどで作りたいという場合には役立ちそうなものを目指します。

これを反映した、目指すサービス全体像を図示してみましょう。

[図]

目指すサービスの全体像

今回、開発を行うのは画面下の青い部分です。

大学Webサイトから、バス時刻表PDFを取得します。更新される頻度を見ると、Web-APIのアクセスの度に取得することは避け、日ごとや時間ごとで取得し直すような工夫もしておきたいところです。

取得したバス時刻表PDFからテキストデータでバスの時刻を抜き出し、JSONにして、他のシステムやサービスから利用できる様にします。

ただし赤い部分は、Web-APIが無事完成したら誰か学生に使ってもらえればいいなという形で、今回の開発の範囲に含めません。

ここまでのまとめと次回

本稿では、ざっくりとしたモチベーションを述べた上で、さて開発!...となる前に、サービスの現状と目指すことを整理しました。

開発に取り掛かる上で、まずは全体像と目指すところを整理 してみましょう。

大学のサービスやその基となる業務プロセス上の課題は、学生にとっても身近なテーマで挑戦しやすい内容です。

その一方で現状のサービス全体像や目指すゴールの整理を怠ってしまうと、自分や他者が感じる面白さは別として、結局何のための成果物なの?になってしまうこともよくあります。今回の方法も業務サービス自体に触れるものではないので、そもそものサービス改善や課題解決を目指したゴールではありません。なので本当はこのサービス自体に意義があるのか?などもここで検討が出来そうですね。

目指す物事に優劣はないと思いますし、私は 車輪の再開発はすべき派で、別にサービス改善に繋がろうが繋がらなかろうが、面白そうならどんどんやってったらいい という考えなのですが、その一方で、自分達の挑戦する意義や価値、目的や目標がどこにあるのか、それによって現実の何がどう変わるのかという視点を持ったり、時にそれを再確認や振り返りながら物事を進めていくことは、ソフトウェアの開発はもとより、学生の間のさまざまな挑戦の中でも、社会に出てからも常に自問自答しながら進めていくことだと思っています。まずは全体像と目指すところを整理するのは、こうした点にも役立ちます。

次回は、「さて、PDFを取得する部分をどうしようか」というパートを例に、私ならこう進めるなという内容で続けていきたいと思います。

*1:"潜んでいたパワーを引き出せば隠れていたネガも当然出てくる━━" 湾岸ミッドナイト SERIES 63 より

*2:職員の業務的にも結構な負担が大きい気はする。

*3:例えば「サービスの要求(や、ステークホルダー・業務ドメインの)分析をせずに取り組んでしまい、各ステークホルダーが求めるサービスに届いていない」「スキル or 時間不足」「長期的に運用やメンテナンスする前提ではないので、継続されない」などに陥りがちになることが多い。とはいえ学生なんだから、形になったのなら胸をはって良いと思う。

*4:個人的には、GTFS-JPを吐き出せるExcelフォーマットに時刻表を喰わせてGoogleMapあたりで公開すればもうそれで円満解決ではと思っている。ただし各ステークホルダーとの調整もあるので趣味レベルで終わる話ではなさそう。そこまでやるならGTFS-RTぐらいまでやったら面白いんだけど。

*5:未完にならないようにしたいが、すでに記事を載せたかった日から10日ぐらい経過してて、もう男坂登り始めてる。

*6:例えば、バス時刻表の管理業務を支援・改善するサービスを作りたい場合は、ここまで、時刻表の元データの作成過程も含めて大学職員・バス事業者と要求分析(ジャーニーマップを作ったり)すべきだが、今回はゴールが異なるので仮定のままとしている。興味がある学生はぜひ取り組んでみたらいいのでは。

*7:悪く言えば、サービスや業務プロセスは何ひとつ改善されてないのでやる意味ないなと思うけど、私個人はServerless Java Containerが使ってみたいだけなので良しとする

ゆるWeb札幌アドベントカレンダー2021・箸休め的なアレ

はじめに

ゆるWeb札幌アドベントカレンダー2021 の 18日目の記事です。

ゆるWeb勉強会@札幌 Advent Calendar 2021 - Adventaradventar.org

このブログの最後の記事が2年前のゆるWebアドベントカレンダーの記事でして、2年ぶりの記事もアドベントカレンダーです。

ゆるWeb札幌アドベントカレンダー2021も4分の3が過ぎ、Web技術ど真ん中からデザイン、クラウドマイコン、通信と幅広い話題が共有されているのが、ゆるWeb札幌が手掛けるジャンルの広さ、懐の深さを体現されているようですね。

なので、モニターの話をしますね。

私もWebエンジニアに片足だけを突っ込んでいるような仕事を30年近く続けておりますが、なんと、驚くべきことに、いままで出会ったどのWebエンジニアの方も皆、例外なくモニターを使っていらっしゃいました

https://1.bp.blogspot.com/-hk-wB0PZBjo/XyZ_RMcHCyI/AAAAAAABaZ4/iEm-0O-3lZYFXHypV3vxNoD83GDt8OPKQCNcBGAsYHQ/s400/computer_shigotoscreen_back_man.png

これは私的な予想ですが、もしかしたら、世界中のほとんどのWebエンジニアが、モニターを使っていると言っても過言ではないのではないでしょうか。

きっとこの記事を読まれている皆様も、エンジニアライフの相棒とも言えるようなモニターには並々ならぬ情熱を持ち、こだわりぬいて選び出したモニターを我が子のように可愛がり使っているのではと存じます。

私とモニター

お恥ずかしながら私も、若かりし頃になけなしのバイト代で手に入れたCRTモニター、ウキウキで電源を入れたところフォントの滲むハズレ品であった経験を経て、モニターの購入時には襟を正し吟味するようになりました。

学生の頃は研究室の片隅に設置されていた5BNCコネクタ接続のNANAO*117インチCRTを使い、その性能を存分に発揮したきらびやかな白黒ターミナル画面でVimを起動しJavaプログラミングをしていました*2

https://image.itmedia.co.jp/ait/articles/1209/14/wi-5bnc-cbl-l.jpg

その後は液晶モニターも購入しやすくなり、大学院の頃は上級生の権限を存分に発揮し当時研究室にあった一番高価なEIZOの17インチ液晶のデュアルモニターにしていたようです。

f:id:gishi_yama:20211218031026j:plain
2004年の頃の環境。この頃から「顧客が本当に必要だったもの」の画像があることに驚き

グレア液晶がメジャーになってコーディング中に目が死んでるおっさんの顔が反射するようになってからは、いかにノングレア液晶のモニターを確保するかにも苦心 しました。*3

2010年代に入ってからは、16:10の24インチ程度のモニターを好んで使ってきました。基本的には仕事用途で、15時間ぐらいはPCの前に座っていることも多いので、目が疲れない、色味の綺麗な出力のIPS液晶を選んできました。

ディスプレイアームでデュアルモニターにし、片方を縦置きにしてログやWebページ用にするのや、ノートパソコンを下に置いて、上にサブモニターを配置するスタイルが好き です。デュアルモニターにすると、同じメーカーの製品でも劣化や型番で色味が違ったりするので、そういったばらつきが経験的に少ないEIZOのモニターをよく使っています*4

フレームレス液晶などは、「枠が小さいのがなんだ、見やすさには関係ないんじゃい」と手に入れるまでは意地をはっておりましたが、今となっては枠の細さやフラットさの美しさでご飯何杯かイケるなと思う次第でございます。

お気に入りは27インチ正方形モニターであるEIZO EV2730Q*5の横にEIZO EV2456を縦置きで配置するという環境で、ここ5年ほどこれを使っておりました。

https://www.eizo.co.jp/products/lcd/ev2730q/img_001.jpg

...つい先日までは。

出会い

ある日、研究室を歩いていると、学生の机の上に、横長の、湾曲したモニターが置いてありました。まさにそのモニターでFPSをプレイしている学生に「そのモニターは何」と問いかけてみると「ウルトラワイドモニターですよ」と答えるではないですか。

https://www.lg.com/jp/images/about/768x512_mnt.jpg

画像は、その時みたモニターと似てる感じのやつで、そのものではないです)

ウルトラワイドモニター。なんだそれは。

最初にその姿を見た時に受けた個人的な印象は、正直言って、好ましいものではありませんでした。奇妙に曲面してスペースをとりそうなボディ、狭すぎる縦幅はソースコードやログ、Webページを縦に一覧するには不便そう。アームで縦置きすることもできない。右や左に表示領域はありますが、かといって首を回さないと見渡すこともできなさそうだし、歪んで見えそう。

横幅が活かせそうな動画編集とか、映画鑑賞もやるわけじゃないし、正直なところ、これは私は合わないかなと思ったわけです。

けれども、フレームレス液晶に感じたような、何か、羨ましいような、近未来的な美しさ、ワクワク感を感じなかったといえば嘘になります

ところで、大好きなEIZOからもウルトラワイドモニター EV3895が出たんですよ。

https://www.eizo.co.jp/products/lcd/ev3895/product_photo_01.png

🤔

f:id:gishi_yama:20211216103351j:plain
違うんだ聞いてくれ

私とウルトラワイドモニター

当初印象との違い

使ってみて1ヶ月ほどですが、まず、私が最初に感じてた印象は全て思い込みで、良い部分が多いなあと思っています。

  • 奇妙に曲面してスペースをとりそうなボディ
    • 横幅は大きいけど、ウルトラワイドは個人的に高い位置に配置した方がみやすく、空いたモニター下のスペースを使いやすくなった
  • 狭すぎる縦幅はソースコードやログ、Webページを縦に一覧するには不便そう
    • 解像度にもよるけど、縦が1440pxから1600pxぐらい出るので、縦にも広く使える
    • 24インチ縦置きで縦1920px出てた時に比べると短いけど満足できるレベル
  • アームで縦置きすることもできない
    • これはそう
    • でもそもそも、アームがなくても良い位置に収まる
  • 首を回さないと見渡すこともできなさそう
    • モニターから少し距離を取る体勢になるように配置すると違和感は少ない。むしろその方が目線の移動だけで済むので良さげ
  • 歪んで見えそう
    • 乱視があるからかもしれないが、糸巻き型のディストーションがウィンドウに起こっているように見えることがある
    • でも、意外と人間注視できる範囲はせまいようで、ぼーっとウィンドウをみてると気になるけど、ウィンドウの中で集中すると全く気にならない(気にならないくらい視野が狭まる)

https://optipedia.info/wp-content/uploads/distortion-fig001.png

面倒になった部分

ただ、やっぱり前の環境よりも面倒になったなと思う部分もあります。

  • ウィンドウレイアウトソフトが必須
    • デュアルモニターの頃はディスプレイごとに最大化などの手段が使えたが、ウルトラワイドだとウィンドウごとのレイアウトをうまく配置しないと面積を使いきれない
    • キーボードショートカットでウィンドウのレイアウトなどが整えられないと、ウィンドウを開くたびにちょっとストレス
  • クイックビューにやたら時間がかかる
    • メインマシンが古いMac Pro (2013)&最大解像度だからかもしれないが、クイックビューやプレビューなどを開くとすごく時間がかかる*6
    • 手軽にスペース押下とかで内容を確認したいが、重たくてちょっとストレス

予想以上に良くなった部分

そのほかにも、思いもしなかったけど良かったと思う部分もあります。

  • 前の構成(EV2730Q + 縦置きEV2456)よりも、ミニウィンドウ1枚ぐらい増やして開けるようになった(画面面積が増えた)
  • アームやケーブル1セット分が減ったので、物理的にもすっきりした
  • USB-Cで電源と信号を同時共有できる(らしい:今後メインマシンがアップグレードしたら試してみたい)

細かい部分ですけど、嬉しい変化だなと思います。

おわりに

Webエンジニアの重要な開発環境といえるモニターについて、特にウルトラワイドモニターの導入の所感・私見について語りました。

開発の間ずっと使い続ける開発環境にこだわるのは、クオリティオブエンジニアライフの向上のためにもとても大事ですよね。

おそらく私のように、ウルトラワイドモニターには興味があるけど使い勝手はどうなんだろう?と思っていらっしゃる人もいるかと思いますので、そういう方が未知の扉を開け、ウルトラワイドニュービーが一人でも増えることにこの記事が少しでも寄与すれば幸せに感じます。

長文になりましたが、読んでくださった皆さん、ありがとうございました。

来年こそはもうちょっと開発の仕事ができるようにして*7ゆるWeb札幌を出禁にならないように真面目な発表や記事を書けるように頑張りたいです。

*1:今のEIZO

*2:あとAdobe Flashもやってた

*3:Mac Bookも毎回ノングレアを選んでたけどもう諦めた

*4:Mac Bookのモニターとの色味の違いももう諦めた

*5:この正方形モニターが個人的にはメチャ使いやすく、今後も後続品が出てくれることに期待しています...使ってる人ほとんどみたことないけど...DisplayPort専用だけど...

*6:Macのクイックビューは人間が見やすいように解像度にあわせた自動リサイズがはいるので、それが重いっぽい

*7:今年は本業の変化で1000行ぐらいしかコード書いてない気がする...

開発環境(物理)にもこだわろう!

ゆるWeb勉強会@札幌 Advent Calendar 2019 12月15日分です。

adventar.org

一週間ぶり2回目の記事です。システムメンテナンス入ったり、PCのアダプタが壊れたりとゴタゴタしているうちに次の日になってしまいました🙇(今期のアドベントカレンダーは一度も〆切守れてない)

今回も長いので目次です。

はじめに

ゆるWeb勉強会では開発環境などの話も活発に交流されます。開発環境というとIDEやパッケージングツール、最近だと構築自動化やDockerなどが注目されていますね。

でも皆さん、お忘れではないですか?
開発環境の大前提としてもっと大事な、物理面の開発環境の整備を!

この記事では物理面の開発環境について、今年のゆるWebで発表した内容もふり返りながら、「いつ机の話してくれるんですか!」となぜか参加者から毎回期待されている内容について、自分なりのこだわりを述べておきたいと思います。

重要なことを先に述べておきます。ネタ枠です。

キーボード

コードを1文字進めるためには最低1文字以上キーを押下しなくてはならない。人の意思を指先のマリアージュととともに叩き込むキーボードこそ、開発環境の中で最も重要な部分といえようと思います。

キーボードで大事なポイントは、キー配列(※左右分離型なども含む)、キー種別、キー数 ではないでしょうか。その他はこの3つの優先度を上回る...ということはなかなかないような気がします。例えばピカピカ光るとかはモチベーションUPに重要ですが、手になじないまま光ったとしてもむしろ煽られている感が増します。

キーボードへの熱い思いは、ゆるWeb勉強会@札幌 #4のおまけ枠で下のスライドのように発表していますが、もう一度こだわりをまとめておきます。

speakerdeck.com

キー配列

多くの方は日本語配列を利用されていると思いますが、私は Mac US 配列 一本でたしなんでおります。幅広いスペースキー、適切なブラケット( [ ] )の位置、command キーによるショートカットバリエーション、キー数が少ないことによるキートップ面積の広さ、何をとっても素敵です。

通常のUS配列だけなら、かなり製品の選択肢も広がるのですが、ただのUS配列だと多くの場合
ctrl win/command alt
の並びになり、ctrl + alt しずらくない?ってなります。

あと Fn の位置が不定で自由すぎます。ctrlalt の右にあったりする Fn は実は Fu**ing Negative キーなんじゃないかって思います。

キー種別

ここは納得のメカニカルキースイッチ、もしくは静電容量無接点方式がベターでしょう。

「でも、お高いんでしょう?」

はい。12月の賞与がもうすぐという方も少なくなかろうと思いますので、握りしめていきましょう。

カニカルキースイッチ

軸の色は「それを口にしたら...戦争だろうがっ...!」って感じになりがちなので個人的な宗派を語ることはできるだけ避けておきたいところですが、私はCherry MXの赤軸が好きです。手に入りずらすぎず、重すぎず、うるさすぎず、軽快に入力できます。

静電容量無接点方式

実は昔つかっていたのですが、当時使ってたマシンと相性が悪くてハングアップしがちだったのと、キーの押し返しが弱く感じて期待より疲れるなあと思い、手放してから何年か経ちます。

2019/12/12 にMac配列のRealforceが発売*1されて、久々にこれは!と思ったのですが、試打したらまた敬遠しちゃいそうな気がするな...

ユーザー諸氏は30g静音か、変荷重かどっちが好きなんでしょうかね。ぜひコメントください。

ノートパソコンはどうするか問題

どうしようもなく、辛ければ外付けしようという感です。

ノートパソコンの純正ではほぼ選択肢がないですが、私はMac環境なので、Butterfly Keyboard Gen 3はマジで辛いと思いながら、Mac Book Proを買い換えた時に選択肢がそれしかなかったので使ってます。今もかなりタイポがひどいのを直し直しこの記事を書いてます。

最近でたMBP 16インチ はGen2の様なタッチ感にもどっていて(まだ)良い感じですね。

パンタグラフは、実は結構すきなんですけど、キートップとれすぎじゃないですか?

キー数

テンキーがほしければ10x、いらなければ8xキーあたりが好きです。割と職場では数字を打つことも多いのでテンキーがほしくて104キー*2、自宅はテンキーいらずの87キーにしてることが多いです。

ネットワークエンジニアの方は6xキー使っているイメージが強く(偏見)*3、身の回りでHHKBブームがあったときに買おうか悩んだんですが、さすがに1つのキーに役割に集約しすぎで辛いな...ってなりました(特にF1〜F10と数字の同居)。

ワーキングチェア

開発をゆりかごから墓場リリースまで進めるには長時間PCの前に座らなくてはならず、運良く昇降デスクがあたったとしても24時間スタンディングコーディングはなかなか辛いものがあるわけで、人間の脊椎と背骨を守り最適なポジッション・荷重移動を可能にするワーキングチェアも、キーボード並に開発環境で重要であろうと思われます。

でも、最近はIT系であればワーキングチェアの選定は当たり前になっている気がしますね。アーロンチェア完備の会議室とか普通に見ます。むしろIT系以外の業種の方が辛いイスで苦労されている方が多いイメージです。

ワーキングチェアの大事なポイント...これはキーボードよりも個人差が大きい気がします。私も試座(しざ)った感じで判断、というのが最終的な所ですが、背中へのフィット感、ヘッドレスト、アームレスト で選ぶことが多いです。

あと諸事情により、ここ10年くらいは座面はメッシュ*4にしています。

椅子への熱い思いも、ゆるWeb勉強会@札幌 #6のおまけ枠で下のスライドのように発表していますが、なんだかんだで軽自動車1台分ぐらい椅子に使っているので、ここも買った椅子の良いところを簡単にまとめて賞与を供養しておきます。

speakerdeck.com

チェアJr.

最初に買ったのがチェアJr.*5です。これは個人的に背中へのフィット感が最高で、高校時代に市内の東急ハンズで試座してから就職するまで、ずっと買いたかった一品です。

あまりに欲しすぎて、初めての賞与を墓地に捨てて職場に(勝手に)召喚し、その後10年弱、毎日の私の開発環境と残業の下支えをしてくれました。

ただ、ヘッドレストがないことが加齢とともにじわじわと効いてきて、職場の引っ越しにあわせて、コンテッサに鞍替えしてしまいました。

今はヘルニア気味の同僚の椅子として第二のイス生を過ごしています。

エンボディチェア

自宅のPC利用環境を充実させたくて買ったのが、ハーマンミラーのエンボディチェア*6です。

これは...このチェア自体はしっかりしてて良いモノだと思うんですが、試座せずに買ったのがフィット感のミスマッチの原因となりました。ヘッドレストがないのもやっぱり辛かった。

あと背面のデザインが独特すぎ、妻に「人体骨格みたいで気持ち悪い」と嫌がられる悲しい理由により、今は舞台を職場に移し、来客用の椅子として第二のイスを過ごしてくれています。

たまに書類仕事するときに座ると、座面の力づよさに安心感を覚えます。

コンテッサ

ヘッドレストを条件にいれると途端に選択肢が狭まるような気がしていますが、最終的に今は(キーボードほど奇をてらわず)定番のオカムラ コンテッサ*7に座っています。職場も自宅もコンテッサ。起きてから寝るまでの座り時間は9割コンテッサな感じです。

ド定番すぎて語れるところがないぐらい安定しています。日本メーカーだからかフィット感もバッチリ、華奢な感じもしつつしっかりと体を支えてくれます。座面やアームレストの調整可能箇所も十分。ヘッドレストはおにぎり型・幅広型で宗教戦争がありますが、私はどっちも好きで、職場は幅広型、自宅はおにぎり型です。

コンテッサIIにもこの前、試座ってきましたが、視座できる仕様がヘッドレスト無しノンメッシュのものだったので、色々な仕様のコンテッサIIに試座ってみたいなーと思います。

ワークデスク

机も重要ですよね*8

個人的にはワークデスクも、学生時代に使っていたCRTディスプレイ用のパソコンキャビネットから数えると5代目です。

机は、キーボードやワーキングチェアよりさらに選定の難易度が高いのではと思います。職場や自宅で配置が許されるスペースの問題は大前提として、天板の面積、長机かL型か、耐荷重と安定性 などが選定のポイントかなと思います。あと、昇降デスクはなんか別軸な気がするけど、使っている人からは肯定的な感想を多く聞いています。(私は使ってないので、この記事では昇降デスクは取り上げません)

先述のとおり、ゆるWeb札幌の関係者にお目にかかると「次は机の話ですね」と期待されてたり、前日の @mkn_39 さんも「楽しみで震えますね!(物理)」 とおっしゃってくださっているので、せっかくの機会、ここでこだわりを述べておきたいと思います。

天板の面積

天板の面積は、配置スペースにかなり左右されますね。また広すぎても作業場所が広がる反面、掃除が大変になるというデメリットもあります。デスクトップや大型ラップトップを使う用途だとそんなに配置をずらさないこともあり、面積が大きい=正義じゃないこともよくありませんか?

横幅はいくらあってもいいけど、奥行きが長い場合は本当に掃除大変(ディスプレイの裏とか、配線回りとかの奥側が特に)なので、個人的には 45〜50cmぐらいの奥行き が、掃除もしやすくちょうど良いかなと思います。例えるとコーヒーショップのカウンター席に10〜15cm追加された ぐらい。 ディスプレイアームがあれば、ノートPCの上にディスプレイを配置できる感じ。

ただ、実際に購入しようとなると奥行き60cmはサイズが揃っているんですが、奥行き50〜45cmぐらいはオーダー前提になることもよくあります。

職場

自分のスペースに Fantoni GFデスク + 丸形カウンターテーブル*9 を置かせてもらっています。(下はGarageの公式なイメージ図)

f:id:gishi_yama:20191216034833p:plain
Garage Fantoni GF + 丸形カウンターテーブル

配置する前は、病院の診療スペースみたいにしたかったイメージです。

奥行きが71cmとかなり広いので、書類仕事はキーボードをディスプレイの下にどかして行う感じです。前述のとおり奥側の掃除が面倒ですが、技術書広げたり書類を広げたりということはどうしても職場で主に発生するので、手間よりも面積を重視。

学生との面談やレビューをしやすいように、丸形カウンターテーブルを備え付けにしています。この丸形カウンターテーブルは、とても気に入ってます。面談やレビュー時は、普段は自分に向けてるディスプレイ(デュアルディスプレイにしてます)のひとつをアームで伸ばしてシェアしてみる感じですね。コードレビューやペアワーク業務が多いような立ち位置の人には結構オススメです。

実は最近はモブプログラミングなど1:多の対応の方が多くなっており、面談スペースよりも、検証したいプログラミングトイを動かしてみたりIoTの機材を広げてみたりと、ちょっと広めで便利なワークスペースとして活用するシーンが増えてきました。書類や機材を置く向きを変えておけば、見えない国境ができて自然と複数の異なる作業のスペースが作れたり、L字とは違ったよさがあります。丸形。

自宅

自宅はGarageのデスクAF*10を、サイズセミオーダーをして使っています。(現在、セミオーダーは休止中のようです)

横140cm*奥行き45cmのデスクAFを横に2つ並べて、1つはL字デスクにしています。 こうすると長方形の部屋の2辺(長編の140cm×2、短辺L字デスク分+45cm)を使って、6畳ぐらいのスペースにぐるっと作業スペース ができます。

f:id:gishi_yama:20191216031958p:plain
引っ越した当初、6畳の2辺に配置したデスクAFカスタマイズとコンテッサ

写真だとノートPCの後ろに幅がないように思えますが、実は15cmぐらいまだ奥行きが空いています。いまは生活感あふれてるので写真は掲載できないのですが、その空き幅でディスプレイアームをたてて、上に外部ディスプレイ、下にノートPCのディスプレイが見えるようにしています。

書類仕事は左を向けばL字部分があるし、ノートPCやタブレットを横におきたいなと思えば右に置けるスペースがある感じです。息子が成長したら、右側の2つめの机部分で彼の宿題を見ながら自分の仕事もできるかなあと、そんなイメージで配置しています。

長机かL型か

上記の職場に配置したような丸形はちょっと異端で、通常は長机をひとつ置くか、オプションなどでL型にするかを選択するかと思います。

L型デスクを使っている方は結構いるんじゃないかと思いますが、私も 基本はL型をベース に考えます。L型部分は内側から使ってもよし・外側から使ってもよしと考えると、 部屋の隅・角にあわせて配置するのもよいし、向きを変えて部屋の中心に配置するのもよいし、万能な机の構成 だと思います。例えば内側と外側からL型部分を挟んで対面して、簡易ペアワークスペース(ちょっと狭そうですが)にもできますしね。

ただL型にするときは、机の脚の形状は考慮ポイントにしています。足が柱状で机の下がぬけていると、対面利用や掃除がしやすい反面、ちょっとしたモノが立てかけづらく置きづらくなったり、特に北海道は冬場の足下が寒かったりします。足がパネル状になっていてぬけていない場合は全くその逆で、対面しても足のやり場がない、掃除がしずらい反面、モノや暖房器具をおいておくにはあまり困りません。

個人的には、足下にオイルヒーターを置きたいので、熱が逃げない後者をとることが多いです(足が冷えるとおなかが痛くなる体質なので...)。

耐荷重と安定性

耐荷重は、必ず自分が乗っても大丈夫な重量が明記されているものを選びます。机に乗って作業するってことが、どうしてもどこかであり得るかなと思ったので(実際は電球変えるぐらいしかないですが、学生時代や前の職場は天井近くの架空配線をいじったり、ということがよくあったのです)

安定性は、組立済みにしろユーザー組立のものにしろ、メーカーで選ぶのがコツかなと思っています。初代〜3代目と、今使っている4代目(職場)と5代目(自宅)で決定的に異なるのは、初代〜3代目はいわゆるホームセンターや家具量販店で、4・5代目はGarageで購入している点です。

Garageの家具は(さすがプラスが運営してるだけあって)作りがしっかりしてる なあと思います。ユーザー組立すると起こりやすい、なんかちょっとぐらつく...という失敗経験も今のところ皆無。その剛健さの割に、あんまりオフィス家具オフィス家具してない、カジュアルなアトモスフィア もあります。Garage好き。額が額なので頻繁に買って応援とかはしづらいけど、これからも頑張って欲しい。

終わりに

開発環境の話と言いつつ、後半になるにつれて単なるオフィス家具大好きおじさんの独白みたいになってしまいました。

可能な範囲で開発環境(物理)を整えることは、意外と自分の仕事効率やテンションマネージメントにもつながる のではないかなと思っています。仕事の内容や自分の体調、生活スタイルも変わっていく中で、物理的な環境もできるだけ合わせていける or 変化に対応できるようにしていくのが理想かなと。

最近はフリーアドレスな職場も珍しくなく、そういう意味では 職場で自分(だけ)の環境をどう整えるか、という考え方は古くなっていく のかもしれません。一方で テレワークやフリーエンジニアな働き方がもっと増えてくる前提に立つと、いかに自分の家で仕事と生活を重ねやすい環境を作るか、というのも面白そうなテーマに思えてきます。

ゆるWeb勉強会で開発環境(物理)の話をどのくらいして良いのか(ここまでやっておきながら)悩ましいなーと思いつつの今日の記事ですが、仕事・開発環境(物理)について意見やノウハウを交換できる場ももっと増えることを期待して、この辺で締めたいと思います。

明日12月16日は、 DE-TEIU さんの 一筋の光が差し込むWebサイト がもう投稿されてました!

*1:REALFORCE @TOPRE_REALFORCE

*2:高校が工業系だったので電卓を打つ訓練とかさせられてたのでテンキー結構好きなんですけど、今もそういった訓練やるんですかね?商業系は左手縛りとかあった気がする

*3:でもサーバールームとかに10x/8xキー置くスペースあるの?携帯するの?というのは確かに...ってなる

*4:座面スポンジが潰れて堅くなってきたりすると、特定の病院にかかる可能性が高まる

*5:Keilhauer/キールハワー Jr ジュニア

*6:Hermanmiller Embody Chairs

*7:Okamura Contessa

*8:長文になってきたので疲れて導入が投げやりになってきた

*9:Garage Fantoni GF + 丸形カウンターテーブル

*10:Garage パソコンデスク AFデスク

首都圏のコミュニティと地方のコミュニティをつなげる話

地方IT勉強会 Advent Calendar 2019 (Part.1)の4日目です。

adventar.org

1. はじめに

北海道、主に札幌を中心に、2015年7月から Javaエンジニアグループ北海道(Java Do)を、2017年9月から IoTLT 札幌 をそれぞれ運営しています。

javado.connpass.com

iotlt.connpass.com

(IoTLTは札幌の個別公開サイトがないので、本家サイトで)

まずは両コミュニティにご協力をくださっている皆さん、スタッフの皆さん、参加してくれる皆さんに改めましてお礼を申し上げます🙇。私(たち)が地方で順調にコミュニティを続けていけているのは、皆さんのご尽力・ご協力にほかなりません。

さて、この2つのコミュニティの特徴や大事にしていることは「首都圏のコミュニティとつながっていること」かなと思いました。この記事では、どうやって 首都圏のコミュニティとのつながりを得ることができたか&大事にしている理由 を、その経緯をふまえて書ければと思います。

長文なので、ご興味があれば 4. 地方だからこそ、外部とのつながりを大事にしたい だけでもぜひ。

2. コミュニティをはじめた理由

「IT勉強会でエンジニア人生が変わったから」

2000年代中頃、地方の一介の情シスだった自分が自身のスキル・経験と技術書だけではもうどうしようもない、そんな困難にぶち当たったときに、エンジニアとしてやっていく考え方・ノウハウ・新しい技術を得られたのが、初めて参加した首都圏の某IT勉強会とその懇親会*1でした。

たった一晩でしたが、様々な年代の、多様なスキルをもった、(自分と同じように)それぞれの現場の悩みや課題も抱えたエンジニア達が、コミュニティを交流・学習・娯しみ・挑戦の場として進んでいる姿 は、閉鎖的な環境にいた自分にとって、生き方の模範、吹雪の中の矢羽根標識にも思えました*2

これを機に地元や首都圏のいろいろな勉強会へ参加するようになり、数年後、地元でお世話になっていた札幌Javaコミュニティ*3のバトンを引き継ぐ形で、Javaエンジニアグループ北海道(Java Do)を立ち上げました。

3. 首都圏のコミュニティとつなげられた経緯

3-1. 地元から首都圏のコミュニティにつなげたケース

Java Doの立ち上げは、Java以外の言語や新たなアーキテクチャに着目が集まっていた時期でもあったので、 「札幌でJavaが好きな人、Javaに関わっている人が、Javaについて交流・学習・挑戦、楽しめる場をもっと盛り上げたい」 そして自分なりの+αもしていくなら 「学生や若手が上の世代と交流できるような企画をしたい」 気持ちからでした*4

振り返ってみると、最初の数回は開催するにもいっぱいいっぱいで、 自分たちがテーマとして取り上げられるものをなんとかひねり出して勉強会に仕立てていました

そんな最中、日本Javaユーザーグループ(JJUG)の一大イベント JJUG CCCの懇親会で、「札幌でJavaのコミュニティを立ち上げました」というLTをさせていただきました*5Java界隈は世界各地でユーザーグループ(JUG)の活動がとても活発です。「 "いつかは" Java Doも北海道全域に拡大し、JUGの末席に加わりたい」と表明したつもりが、いろいろな方から「北海道に新たなJUGができたんですね」とお声がけをいただき、 思いがけずその日のうちに北海道のJUGとして認識され てしまいました。

まだ実のない中でこれは大変なことになったと思いながらも、 全国的なイベントで一気に認識していただけたことも追い風 になり、寺田佳央さん*6が講演に来てくださったり、札幌の大きなイベントで伊藤敬さん*7が「札幌にJUGがありますよ」と伝えてくださったり、海外のJavaチャンピオンの日本縦断ツアーに札幌を組み入れていただき、JJUGからも櫻庭祐一さん*8が講演に来てくださったり...と首都圏・海外からの豪華ゲストが立て続き、一気に勉強会の内容の幅、そして参加してくれる人たちが増えました。

このつながりに加え、自分たちが次第にコミュニティとして成熟しはじめたこともあり、最近のJava Doが 名実ともにJUGのひとつとして、一年を通してバラエティに富んだ勉強会を実現できている ことが本当に嬉しく、ありがたく感じています。

3-2. 首都圏から地方のコミュニティにつなげたケース

Java Doが軌道に乗り始めた頃、たまたま出張先でIoTLT大阪が開催されていました*9。当時、IoT関係の業務が舞い込んできたところだったので、その勉強になれば...というつもりでの参加だったのですが、自分たちが開いて・参加してきた勉強会とはまた違う、 プロトタイピングベース・挑戦色多めの相次ぐライトニングトークや、学生も気兼ねなく作品を発表する雰囲気は、とても新鮮に・熱く 感じました。

当時、IoTLTではすでに地方版のフォークや領域のスピンオフがいくつかはじまっていたのですが(こういうときは大体)札幌にはまだありませんでした。 どうしてもこの雰囲気を札幌にも持って行きたい、運営するコミュニティがひとつからふたつに増えてもどうってことない と思い切って、IoTLT大阪のその場で開催の経緯を聞いてみたところ、すぐに本体主催の菅原のびすけさん*10、土屋敬さん*11につないでいただけました。さらにすぐ「札幌版ぜひどうぞ」とご快諾いただいたのですが「さすがに本家は一度参加しておかねば」と思い、東京版に参加して 200人を超える参加人数に圧倒されながら自分もLTをしてみたり、のびすけさん達にもご挨拶して、札幌版の開催にこぎつけました。

札幌版IoTLTも静かに・小規模でスタートしましたが、本体の皆さんがLTをしにきてくれて以降、定期的に・安定的な人数で続けてられています。札幌で登壇される皆さんの話も、もちろんハード・ソフトの技術的な話だけなく、 スマートルアー、スマートスピーカー(自作)、画像認識、IoTボタンと毎回多様で目新しいプロトタイプ が提示されて、毎回とても楽しみです。

4. 地方だからこそ、外部とのつながりを大事にしたい

母校の建学の精神に「人知還流」という好きな言葉がありました*12。もちろん在学生向けの言葉ではありますが、転職やリモートワークが実現しやすくなったり、地方での働き方が見直されてきたり、そして地方のコミュニティが増え始めた今、 人と知の還流は地方や首都圏を取り巻くコミュニティやIT業界全体にも当てはまること と感じています。

Java Doを始めたときは、地方の自分たちの力だけでコミュニティや勉強会を進めていくことには部分部分で近いところに限界がある ようにも感じていました。地方のJUGのひとつとして JJUGや首都圏のコミュニティの方々とつながることができて、今は色々なテーマの勉強会を地元でも展開できる可能性や、全国ツアーなどには全体の一端として少しでも貢献できる可能性を感じながら、少しずつ実現して 進められています。

IoTLTは、首都圏発の魅力的な勉強会を地方に持ってくることができた事例 と思っています。この秋には岩手でIoTLT北日本が、そして札幌で鋳造IoTLTが開催されるなど、各地方・各業界がさらに連係・合同する場面にも立ち会うことができ、新しい発展の仕方が見られた ように感じています。 首都圏と地域をつなぐスター型ではなくて、首都圏と地域・業界同士が相互につながるメッシュ型になると、もっと素敵な成果が見えてくるのかもしれません。

どちらの勉強会のつながりも、自分がはじめて参加した勉強会と同じように、自分たちが少し踏み出すだけで可能性や発展が見られた僥倖な例かもしれませんが、人知還流が自分たちの関わりあいでも実現できるように、外部のコミュニティとつながることをこれからも大切にしていきたい と思います。

5. おわりに

ドイツ旅行のときに聞いた話ですが、ぶどう農家が苗を育てて水や手入れをすることはできるけど、それが沢山のおいしい実をつける一面のぶどう畑になりワインを作れるようになったのは、ライン川があったからこそだったとか。ブドウ畑が地元のコミュニティ、水や光が勉強会やイベント、ライン川が首都圏や他のコミュニティと当てはまりそうだなあと。

なんか良いたとえになりませんでしたが、投稿予定日を過ぎてしまったので、そんな感じで締めます。

明日(2019-12-05)は、Hiromi Kanae さんの「何か書きます」 です!

更新履歴

  • 2019-12-05 誤字脱字直しました
  • 2019-12-04 初版公開しました

息子5歳とプログラミング教材、そして教室への応用

こどもとプログラミング Advent Calendar 2018 22日目です

adventar.org

一日おくれました...

はじめに

息子が3歳の頃から、プログラミング教材で遊ばせています。

もちろん自分がプログラミングを好きで、彼と休日にキャッキャウフフしたいなというのが主な動機ですが、彼が大きくなる頃には(これまで以上に)AI技術やプログラミングの利用が当たり前になるでしょうから、別に情報系に進まなくてもプログラミングの基礎的なスキルは身につけておいてほしいなという思いと、私自身が子供むけのプログラミング教室を主催しているので、そのテスターになってもらおうという打算的な思いもあります。

この記事では、同じような思いや境遇の親御さんにむけて、自分が息子や教室で試してきた教材と、その所感を共有できればと思います。

Ozobot

息子が3歳の頃、はじめて使ってみたのがOzobotです。

www.ozobot.jp

私が購入したときには Ozobot 2.0 Bit が最新のものでした。いわゆる小型のライントレースカーなのですが、読み取っている線の色にあわせてロボットが動いたり、3色違う色の点を並べるとOzobotがそれを命令として読み込んで、ダンスやUターンの様々な動作をします。

f:id:gishi_yama:20181223105556j:plain
Ozobotではじめて遊ぶ息子(3歳時)

画用紙に自由に線を書かせても良いし、アプリを使ってタブレット上に線や命令を配置できるドローツールがあります。自分の描いた線の通りにロボットが動いてくれるのは、子供も喜びます。

f:id:gishi_yama:20181223105717j:plain
アプリの場合。画面の明るさが結構重要。

使い方が難しい点として、紙でやる場合は紙質とペン(カラーシールでも可)の選択が非常に重要に感じます。にじんだり、スキマがあったり、発色が悪いとうまく線や命令を認識してくれません。ライントレースの精度が良いので子どもたちの期待も大きいためか、何度も思い通りに動かないと機嫌が悪くなりがちです...

f:id:gishi_yama:20181223105846j:plain
Coder Dojoにて。色の違うところが命令ですが、うまく読み取るように作るのが難しい...

アプリも英語で、特に線の上に命令を配置するインターフェースが複雑なため、未就学児がどんどん使い方を学んで自由に動かすというのにはちょっとハードルがあります。(ただ絵を描いてなぞらせる遊び方になりがち)

文字やUIの使い方が十分に理解できるようになる小学生以降には、より強力なツールになるのではと思っています。

Spero

次にやってみたのはSperoです。

www.sphero.com

プログラミングやドローツールで描いたとおりに、球状のロボットが動いてくれるというものです。

動作精度は非常に高いです。「体育館でライトを太陽、ボールを地球と見立てて、地球の周りを回るSpheroの影で月の満ち欠けを理解する」といった凄い事例もあり、とてもポテンシャルを秘めている教材だと思います.....が、とにかく狭い自宅だとSpheroを動かすスペースがなく、購入当初からほぼタンスの肥やしになってしまっています...(mini買えば良かったのかな)

たまに実家に戻ったときに起動してみるのですが、息子にとってはただのラジコンになってしまったり、自宅で体験的に学ぶにはひと工夫が必要そうです。

今後、広い場所が確保できる教室で使えるような内容も考えたいです。

chibi:bit(micro:bit

3台目は chibi:bit(micro:bit)です。

はじめよう | micro:bit

micro:bitはとても有名になったので敢えて語ることもないと思いますが、ブロックに使われている言葉の難しさや自由度の広さから、未就学児が使って遊ぶには少し手に余るかな...というのが現状です。

息子もたまに「micro:bitちゃんを光らせてー」とせがんでくることはあるのですが、自分でmicro:bitで何かを作ろうという発想はまだ難しいようです。

ちとせプログラミング教室でもmicro:bitを使った体験会は何度かやっているのですが、集中して自分で作りたいものを実現していくのは、やはり小学3年生ぐらいからのイメージです。

f:id:gishi_yama:20181223112438p:plain
ちとせプログラミング教室での利用。
右側の子は4年生(Scratch経験者)で、教えていないこともどんどん進めていく。

今後は小学校などでの教材や利用事例も沢山増えていくでしょうから、注目のツールですね。

ちょっと宣伝

micro:bit を使ったプログラミング体験の内容で、ちとせプログラミング教室のテキスト(pdf)を公開しています。

GitHub - gishi-yama/techitose: ちとせプログラミング教室

小学校の先生から意外と好評をいただいていますので、もしお手元でお役に立てられそうでしたら、ぜひ使ってみてください。
(※エディタ画像が前バージョンものなのですが、年明けまでに画像を新バージョンに差し替える予定です)

Hour of Code

ここまで息子に遊ばせて見た中で、未就学児でも少しブロックプログラミングに挑戦させた方が良いかな?と思い、4歳になった段階でHour of Codeをやってもらいました。

f:id:gishi_yama:20181223114632j:plain
Hour of CodeのMinecraftに挑戦する息子(4歳時)

これが、未就学児でも意外とうまくいくな...というのが感想です。

自分でひらがなを読んだり、足し算をすることもまだたどたどしいので、表示されるブロックをすべて理解しているわけではないようですが、

  • ステージによって使えるブロックしか出てこない
  • ブロックの配置場所や色がだいたい同じ

という、敢えて設けられている制限がよいガイドとなって進められるのか、大人がちょっとやってみせると自分でもチャレンジし始めました。

とくに Minecraft の教材 が気に入ったようで、5歳になった今は「何がゴールなのか」ということを本人に伝えて、読めない漢字だけを変わりに読んであげれば、Hour of Code の「Minecraft: アドベンチャー」、「Minecraft: 主人公の旅」は大体クリアできるようになりました。「Minecraftデザイナー」や、「Minecraft Voyage Aquatic」にも挑戦していますが「条件分岐」「関数」的な考えが出てくると、Scratch的な形式のブロックではまだ使いこなせないようです。

あとは、右と左がどちらか、という概念をこのHour of Codeの体験の中で理解し始めました。なかなか覚えてはくれないですが...

codeSpark Academy with the Foos

今、息子が一番ハマっていて、私も一押しな教材が、 codeSpark Academy with the Foos です。

codespark.com

Hour of Codeで体験版が公開されているのですが、息子の食いつきがとてもよかったので、アプリ版を購入して使っています。

f:id:gishi_yama:20181223115151j:plain
忍者を動かしてゴールまでつれていく。繰り返しも普通に使う4歳。

このツールも原則はブロックプログラミングで進めていくのですが、基本的には文字が出てこない(英語の単語でブロックの説明が鳴ったりはする)ので、字が読めなくても数字がわかれば自由にプログラムを組んだり、ゴールに向けてトライ&エラーすることができます。

内容も多岐にわたり、

  • 順次処理
  • 繰り返し
  • イベント
  • 条件分岐
  • 自動化
  • 変数・不等式
  • スタックとキュー
  • ブール論理
  • ゲーム作成と公開

が体験できるようになっています。凄い。

進め方としては、基本的なプログラミングの概念や操作方法を、ゴールが定められたパズル的なブロックプログラミングで学び、最終的に自分で自由にゲームを作れる形です。

作成したゲームは公開できるし、公開されているものをフォークもできるという完成度の高さです。キャラクターもかわいい。

息子は4歳時から1年かけてパズルは4週ぐらい達成してしまい(セーブスロットが3つで、全て達成以外のスロットを消して再チャレンジしてる)、最近はもっぱらゲームを作ったり、誰かが作ったゲームでクリアできないものを自分がクリアできる難易度に改変したり😅しています。

f:id:gishi_yama:20181223120126j:plain
甥っ子6歳とペアプロをする息子4歳。
4歳が6歳に「こうしたら良いよ!」と提案したり、6歳が4歳のプログラムを最適化したり。

プログラミング教室でも使ってみたところ、子供達から大変好評です。

未就学児に近い小学1年生も、保護者と一緒に楽しめる教材になっています。小学3年生ぐらいだとむしろ簡単に感じるようで、数時間でパズル部分を終えてしまいます。

ただし、ゲーム色は強いので、教室で使うときに単に「ゲーム大会」になってしまわないように注意しないとな...と頭を悩ませています。

f:id:gishi_yama:20181223121141j:plain
ちとせプログラミング教室の一コマ。
わかりやすい教材なので、保護者の方と盛り上がれるのがとてもよい

おわりに

息子が3歳から5歳までの2年間でチャレンジしてきた教材の遍歴と、教室での利用例を簡単に紹介しました。

どれか一つのツールや教材で、プログラミングの考え方や応用方法を身につけることは難しく、多様なツール・教材を組み込んで使っていくのが、家庭・教室・教育現場で重要かなと思っています。

うちではこういう使い方をしている!といったような事例がありましたら、ぜひ教えてもらいたい&公開してもらいたいなと思います。

違う地域のコミュニティや勉強会に足を伸ばそう!FuraIT編

FuraIT Advent Calendar 2018 22日目の記事です。

adventar.org

はじめに

北海道と本州の大きさの違いがたびたび話題になったりする昨今ですが、広域分散型の土地柄だからこそ、各地域のコミュニティや勉強会がゆくる連係・連携できることは、将来のIT業界を支える教育・人材育成・人材交流の面でとても大事だと思っています。

なんかもっとコミュニティに関わる・参加する方々が
お互いに「明日お邪魔しにいきますわ」的な感じになるといいな

と思いますよね。

特に札幌であれば、公共交通機関のパイプが太い小樽、石狩、千歳、苫小牧、富良野旭川などが交流しやすい地域かなと思っています。

けれども、

  • 地元とは違う地域の勉強会やコミュニティになかなか足が向かない...
  • 他の地域の勉強会にどうやって参加したら良いかわからない...
  • ○○って北海道のどのへんにあるの(失礼)

という方も少なからずいらっしゃるかもしれません。

そんなあなたにむけた一事例として、普段は札幌・千歳のコミュニティで活動する筆者が、富良野の FuraIT さんに参加したときの実例をもとに、
あなたはどうすればFuraITに参加できるか
をまとめておこうと思います。

実例に使うのは、この2月に開催された FuraIT #44 - 「セキュリティ分野入門」「プログラミング教室を作る心構え」です。

furait.connpass.com

同様のスケジュールの勉強会がFuraITさんで開催された想定で、書いていきます。

FuraITに申し込む

まずは勉強会に申し込みましょう。

FuraIT - connpass から、参加したいイベントに申し込みます。地球の裏側からでも申し込めます。

ついでになんか発表を申し出てみると最高に楽しめると思います。

FuraITに行く

事前の準備

  1. とりあえず地元のおやつを買っていくとよいです。(20〜30人に行き渡るぐらい)
  2. 発表するひとは発表資料を作っていくとよいです。

道外から

  1. 最寄りの空港から 新千歳空港 に来てください。
    だいたい前泊になるでしょうから、タイミングが合えば ちとせプログラミング教室 とかに寄っていくといいと思います。
  2. その後は札幌に向かってください。
    だいたい前泊になるでしょうから タイミングが合えば Java Do とか IoTLT札幌 とかに寄っていくといいと思います。
  3. あとは道央圏からの項と同様です。

道央圏から

道央圏からであれば、札幌からバス×バスがかなりいい感じです。

  1. 札幌駅バスターミナル、もしくは札幌ターミナル(地下鉄バスセンター駅)から富良野行きの高速バス 高速ふらの号 が出ています。
    FuraITはだいたい13:30頃から開催の様な気がする(筆者調べ、もくもく会を除く)ので、札幌8:15発がベターです。(9:30発でも途中遅れがなければ間に合いはしますが、お昼が厳しい)
  2. 3時間ぐらいバスに乗りますので、乗車前のお手洗いはマストです。車内ではスマホなりPCなり読書なりでリラックスして過ごします。山の中や集落を通ったりするので景色もオススメです。
    f:id:gishi_yama:20181221105917j:plain
    車窓から。めっちゃ吹雪いてる。
  3. 8:15発であれば、11時すぎ頃に富良野駅に着きます。
    とりあえず 富良野 オムカレー 富良野 ランチ 富良野 名店 などでググって気に入った店に食べに行きます。
    f:id:gishi_yama:20180217111535j:plain
    富良野駅。めっちゃ吹雪いてる。
  4. FuraITはだいたい中富良野で開催の様な気がする(筆者調べ、もくもく会を除く)ので、富良野からさらに移動ですが、JRよりもラベンダー号12:50富良野駅発が、ゆっくりオムカレー食べられて(その上喫茶店でコーヒー飲みながら発表スライド調整できたりして)ベターです。
    f:id:gishi_yama:20181221110813j:plain
    オムカレー。レンズがめっちゃ曇ってる。
  5. 富良野に着きます。JR駅の前の通りにつきますので、道をググりながらふれあいセンター なかまーるまで5〜10分程度歩いて行きます。
    不要かもしれませんが、真冬だとスマホがじゅうぶんに充電されていても、寒さで外に出てすぐ電源ダウン&起動しないことがあるので、あらかじめバスの中で肌着に貼っておいた(←ここ重要、スマホにいきなり貼るとあたたまらないため)貼るタイプのカイロをスマホの裏側に貼り付けると、2時間ぐらい保ちます。
    (※北見市 厳寒の焼き肉祭り 外気温-10度での、いち検証結果)
    f:id:gishi_yama:20180217131320j:plain
    富良野。めっちゃ晴れてる。(同じ日です)

その他の地域・方法から

  • JR・バス等・自家用車等、最適な交通手段をご利用ください(なげやり
  • 自家用車の場合、片道400kmを超えるとドライバーが複数いた方が安全な気はします(サブドライバーが1日保険とか掛けるとモアベターです)。お住まいの地域から最適な運転体制・スケジュール・安全運転で行きましょう。

FuraITで過ごす

  1. FuraIT開催中の会議室に行きます
    f:id:gishi_yama:20180217131744j:plain
    やったーついたよー
  2. 熱い発表を聞いたり、熱く発表したりします
    f:id:gishi_yama:20181221111213j:plain
    FuraIT開始の儀。
  3. おやつを食べたり、おやつを配ったりします

初心者も熟練者も子ども(学生)も大人も混在で発表する、凄く良い雰囲気です。

ちなみにこのときは私はプログラミング教育のほうのセッションに参加しまして、地域のコミュニティをどう根付かせていくか、勉強会はどんな体制で進めていくか、上級生が下級生を教えることで下級生が上級生をロールモデルにする手法などを議論しました。充実のひととき。

FuraITが終わったら

だいたい富良野で懇親会がある(ですよね?>関係各位)ので、皆と一日を振り返りながら大人の参加者の後をついていって富良野まで戻ります。「社会人になったら呑もうぜ!」などの言葉とともに、名残惜しいですが学生さんとはここでお別れです。

FuraITの懇親会

  1. 食います
  2. 呑みます
  3. 食います
  4. 呑みます

以下無限ループ。写真を取り忘れるほど酔っていたようです。

ホルモン焼き肉おでんを食べにいってめちゃウマだったことは覚えてる!

FuraITの宿泊

  • 富良野駅前にホテルや民宿がありますので、事前に予約の上で宿泊します。雪質がいいからか、冬期は部屋がサクッと埋まってます。早め早めの予約がいい感じです。
  • スキー場下のペンション・ホテルも原理的には可能な気がしますが、富良野駅からは距離があるので、懇親会の後の移動手段がヤバいかなという雰囲気があります。

FuraITから帰る

二日酔いのぐったり具合にあわせて流動的に動きます。

  1. 駅の高架橋から大雪山系が見渡せるので、見に行ったり写真をとったりするといい感じです。
    f:id:gishi_yama:20181221111535j:plain
    右から十勝岳トムラウシ山大雪山(多分)。実際に見ると凄い迫力です。
    あとめっちゃ風が冷たい。
  2. 富良野 オムカレー 富良野 ランチ 富良野 名店 などでググって気に入った店に食べに行きます。(このときは @tomio2480 さんにオススメの所に連れて行ってもらいました!ありがとうございます!)
    f:id:gishi_yama:20181221111834j:plain
    黒いオムカレー。コクがあって美味。
  3. 観光します。夏であれば 富良野 ラベンダー 富良野 北の国から などで名所やアクセス方法が見つかります。冬であればウィンタースポーツもいいですね。
  4. おみやげを買ったりします。菓子司 新谷であえてチーズケーキを外して菓子詰め合わせとか買ったりすると楽しいです。うまい。
  5. 満喫した後は、来たときと同様の交通手段で札幌・空港・ご自宅に向かってください。

FuraITから帰ったら

報告するまでが勉強会という意気込みのもと、 ブログとか Facebookとか Twitterで報告し、それぞれの日常に戻ります。

おわりに

この記事では、あなたはどうすればFuraITに参加できるか、私の参加実例にフォーカスし、手段やノウハウを述べました。

ここまでお読みくださった皆さんは、
FuraITは 道内はもちろん、道外からでも1泊・2泊で気軽に参加できるコミュニティ・勉強会だという魅力
を十分ご理解いただけたのではないかと自負しています。

FuraITに限らず、普段は参加しない違う地域のコミュニティや勉強会に皆さんがどしどし足をのばしていただけるようになれば、そしてこの記事がそのきっかけや一助になれば素敵だなと思います。

ちょっと宣伝

Javaユーザグループ北海道・IoTLT札幌・ちとせプログラミング教室では、特に北海道の各地域とのゆるい連係を歓迎しています。JavaやIoTの勉強会を地元やってみたい、子ども達へのプログラミング体験会をやってみたいなどのご要望がありましたら、ぜひご連絡ください。