過去より未来に近い今

30オーバーでも始めるには今より遅いことはない。育児と技術両方諦めないようにアウトプット。

すくすく!子育てエンジニアMeetp#3に参加してきた

現在3歳&0歳の子供がいる身として気になっていた勉強会へ参加してきた。

子育てエンジニアというネーミングでもある通り、父母の方々が多く、他の勉強会にはないほっこりした雰囲気の勉強会だった。

すくすく!子育てエンジニアMeetupとは?

イベント概要から抜粋。

・家庭や育児においてもっとエンジニアリングで何か出来るのではないか?と思ったことはありませんか?

・困っていることがあるのだけど、実はこれは何か解決出来るツールを作っている人がいるのではないか?

・今後、こういった困り事が出るから今のうちにツールを作っておいたほうがいいと伝えたい。

そういった家庭や育児におけるtipsを皆で共有しようという場です。 そこで得たナレッジを家庭で共有し、さらによくしていこうという集まりです。

家庭や育児をエンジニアリングでサポート、そのノウハウを共有しよう、という集まりということだった。

家庭や育児など身近な部分をエンジニアリングで良くしていこう、というのは課題解決の敷居としてアプローチしやすい&自分事なので、当事者としての課題設定がしやすい、という面がある一方、実はこういう家庭内でのエンジニア的なアプローチは共有される場面が少ないように感じていたので、このような集まりを企画していただいたのは非常にありがたい。

#3の開催概要

場所:マネーフォワード社新オフィス(田町)

21階ということもあり、夜景が綺麗に見えた。新しいオフィスとのことで全体的にきれいでおしゃれだった。

エンジニアの勉強会としては珍しく、子供向けのお土産あり、黒烏龍茶などの健康配慮された飲料の提供(アルコールはなし)ということで、奥様マネジメント的には好感度が高い運営となっていた。

勉強会で得たこと

身近な課題、悩みを考え方含め整理して、解決するアプローチを複数の事例で伺えた。自分でもちょっとした「こうなっていればいいな」と思うことがエンジニアリングで解決する課題設定になるのだと気づけたのはアウトプットを増やしたい思いと家庭内でもやることをやる必要があるということを両立できるチャンスだな、と思った。

以下、それぞれの発表ごとでの気付きなど。

発表枠(1):tknzk さん

  • VUIを使った育児ログの記録についての話

我が家にもVUI端末があるのだが、イマイチ利用しきれていない。IFTTTとそれだけだと不足する部分はスクリプトを書いて補うというTipsは参考になった。IFTTTなど使えるものは使ってなるべく楽することも時間がない子育てエンジニアには必要なTipsだな、と感じた。

発表枠(2):おおやまみちのくさん

  • Scrapboxを家庭に導入された話

私自体はScrapboxは利用したことがあったが、現在はNotionへ移行している。そのため、ある程度使い心地は知っているつもりだったが、リンク機能や地図などのデモを拝見して、確かに子供とのお出かけ計画などには非常に便利かもしれない、と感じた。

ただ我が家の場合、奥様マネジメント的に利用してもらう敷居が高そう。

発表枠(3):Yuu Ito さん

  • 夫婦でお買い物アプリを作った話

ご夫婦共にエンジニアで、買い物リストの共有が既存サービスでイマイチはまらなかったからアプリを開発されたそうだ。他の人に利用してもらうと環境によってはそれほど効果が出なかったが、ご夫婦にはハマって効果が出たということだった。家庭内のやり取りやその家族の悩みどころというのは世界で1つ、とまではいかないが、ある程度ニッチな悩みになるのかもしれない、と感じた。その時それをエンジニアリングで解決する、という方法はありで、またそのニッチな悩みは世の中にある程度同じ境遇の人がいるような気がした。

アプリを公開されるかもしれないとのことだったが、自分の悩みやその解決方法も他の誰かの役に立つのかもしれないと考えさせられた。

発表枠(4):chocopie116さん

  • 音声を拾うことで奥様の大変度合いを感じる仕組みを作られた話&家庭内マネジメントについての話

TDDを元にした奥様サイクルや家庭内の負のスパイラルの話などエンジニアリング以前に把握しておくべき考え方の話があり、頷く内容だった。よくエンジニアは作ることばかり考えるのではなく、作らずに済むことも考える必要があるという話があるが、抱っこを変わる、アイスのお土産で喜ばすなどはまさにこれに当たる内容で、なんでも何か作ればいいと思ってはいけないな、と感じた。

その上で音声を拾い、それをモニタリング、しきい値を超えるとアラートが上がる仕組みを入れ、赤ちゃんの泣き状況を把握する仕組みを構築され、奥様の大変な状況を共有するということを実施されているというのは家庭内でのエンジニアリングの事例としては自分では思いつかない内容だった。

発表枠(5):shikicheeさん

  • 妊娠されて不安な奥様に対して準備したことの話

家事の外注、家庭内カフェ化=作業効率を上げる環境の構築、Trelloを使った献立管理、保活の実体験として利用した資料や検討の仕方のお話。

我が家の場合Trelloを奥さんに使ってもらうのは敷居が高いなどなかなか展開できそうにないが、webサービスとして保育関係の情報が結構出ている(東京だけかもしれないが・・・)というのは参考になった。

次回に向けて

全体的に子供の紹介が出るとみんなでニコニコしたり、登壇内容も既存サービスを家庭で適用した事例紹介や、家庭内Tipsや自身で開発したものを育児などに活かした話など幅が広く、登壇しやすい雰囲気であった。

次回はチャンスが有れば登壇にチャレンジしてみたい。

Google Apps Scriptをローカルでコーディングするためにclaspを導入した

Google Apps Script(以下GAS)は便利なので、業務効率化のために利用することが多いが、標準のオンライン開発環境だとコーディング補助や静的解析が弱いので、ローカルでコーディングできないものか?と思っていた。

調べてみると少し前から「clasp」というCLIツールがgoogleより提供されており、これを利用するとローカル環境での開発が可能となることから入れてみた。

環境

参考資料

qiita.com

qiita.com

qiita.com

claspとは?

googleから提供されているCLIツール。これを使うとGASのプロジェクトを作成したり、G Suiteからソースをpullしたり、pushしたり、バージョン作成やバージョン確認が可能となる。

claspを使って何が嬉しいのか?

  • GASは便利だが、web上の開発ツールだとちょっとしたところが足りない。それがローカル環境だと自分の慣れた環境で開発できる。

  • GASはほぼJavaScriptなので、JavaScript的補完が効き、開発効率UP。

  • gitなどでソースのバージョン管理できる。

  • GASはWindows officeでいうところのVisual Basicなので、なんとなく開発と言い切れない部分がローカル環境の開発ツール使って(黒い画面で)操作しているとかっこよく、開発しているっぽさが増す。

claspを入れてみよう

  1. node.jsとnpmのインストール

  2. npmを使ってclaspを導入

$ npm i @google/clasp -g
  1. GAS APIをONにする

このあたりは参考リンクを参照。

  1. clasp loginする

ログインするとwebでいつものグーグルの認証画面が出るので認証を通す。するとwindowsの場合、ユーザーのhomeディレクトリ直下に

.clasprc.json

というjsonファイルが作成される。

$ clasp logout

とするとログアウトするのだが、この時login時に作成された

.clasprc.json

が削除されている。

つまりこのファイルが認証情報になっている様子。

ちなみに自分の環境では上記のlogoutコマンドを叩かない限り、PCそのもののシャットダウンなどをしてもjsonファイルは残り続けており、かつclasp loginせずにいきなりclaspコマンドが利用できた。

claspを使った自分流のローカル開発環境の実現

  • ざっくりした開発の流れ

    1. cloneまたはcreateでプロジェクトを作る

    2. gitリポジトリ作成

    3. VSCodeで開発

    4. Gitステージング→コミット

    5. clasp push

    6. G Suite上でデバッグ

      • この時エラーが出るなど修正があれば、3-5を繰り返す
    7. 正常に動けばclasp version 'hogehoge'でバージョン作成

claspで疑問に思ったこととその確認した結果

  • GASプロジェクトを切り替えるにはどうしたらいいのだろうか?

    参考にした資料でもgoogleのclasp説明資料でもイマイチよくわからなかったので、いろいろ試してみた。

    その結果、最初にcreateまたはcloneをすると

    .clasp.json

    というファイルがカレントディレクトリに作成されるのだが、この中にスクリプトIDが記載されていて、その設定ファイルを処理時に参照してGASと紐づけて処理していることが判明した。

    つまり、プロジェクトの切り替えは特別なコマンドで操作する、などではなく、単純にカレントディレクトリを移動するだけでよかった。

    具体的には以下のようなディレクトリ構成があったとする。

    gas

    ├ gasprojectA

    │ └ .clasp.json

    │ └ hoge.js

    └ gasprojectB

      └ .clasp.json

      └ hogeB.js

    作業時にgasprojectAとgasprojectBを交互に操作したい場合があったとしたら、コマンドプロンプトでカレントディレクトリを都度移動して、claspコマンドを打てば、そのカレントディレクトリにあるjsonファイルに記載されたスクリプトIDに紐づくGASプロジェクトに対して、カレントディレクトリ内のファイルをやり取りしてくれる、ということ。

  • ローカル環境でどのようなディレクトリ管理がよいか?

    参考にしたリンクにはGASのjsファイルに「/」を入れるとclasp pullした時にディレクトリ階層にしてくれるとあるのだが、この「/」があることがもやもやしてしまい、結果自分はローカル環境でそれぞれプロジェクトごとにディレクトリを作成して、そのディレクトリ内にcloneすることにした。

例としては上記のプロジェクト切り替えの通り。

これでwebのGAS上でも「/」がなく、かつGASプロジェクトごとにディレクトリが分割しているので、gitリポジトリもそれぞれ個別で作成可能となった。

claspでもやはりまだイマイチな点

  • pushしないとイマイチデバッグができない

    GASにもよると思うが、スプレッドシートとセットなどG Suiteのサービスとセットになっている場合が多いため、ローカルでの動作確認には限界がある。

  • ネットワーク環境にもよると思われるが、処理に時間がかかる

    もしかしたら都度json見に行っているから?自分のネットワーク環境もあるので、これはイマイチ原因はわからないが、webでコーディングしてそのまま動かす、というclasp利用なしと比べるとこの点はどうしても劣る。

なんだかんだでclaspいいよ

イマイチな部分はあるが、やはりローカル環境での開発とgitでのバージョン管理ができるのはよい。

最近はGASのコンソール画面もあり、webでできることも一覧で確認する方法も充実してきているので、web上でのサービスとclaspと組み合わせると結構幸せなGASライフを送れる。

G Suiteを利用して、GASでなにかしている人にはclaspオススメ。

Djangoのmigrateでハマった

Djangoのmigrateでハマったので、その内容と解決方法をメモ。

背景

Djnagoのオンラインコースが一通り完了したので、参考にしつつ、自分で別のアプリケーションを作成することにした。 models.pyで定義後、一度makemigrationsとmigrateを実行し、adminサイトで確認したところ、想定していたデータベース構成と異なる部分があったので、models.pyを修正し、再度migrationをしようとしたところエラーが発生した。

発生事象①

makemigrationsしたところ以下のエラーが発生。

f:id:gohh56:20181003004742p:plain

作成したmodelの中でデフォルト設定がないが追加しようとしている項目があるがどうするの?ということらしい。

解決方法①

select an option:

と聞かれたので、ここでは1を選択。実際にデフォルト設定値を入力するよう促されるので、e.g.にある内容を参考に入力。

私の場合はtimezone.nowで解消した。

発生事象②

次にmigrateをしようとしたところ、今度は以下のエラーが発生。

f:id:gohh56:20181003005534p:plain

どうやらmakemigrationsのデフォルト設定が良くなかった様子。

解決方法②

ググったところ、以下の記事に遭遇。

まだデータ登録はしていなかったので、データベースを作り直してもよいと思い、migrations以下のファイルを削除、再度makemigrationsとmigrateを実行したところ正常に処理が完了できた。

qiita.com

エラー自体は解消したのだが、削除したファイルが一体何の意味を持つものなのかはっきりしなかったので、調べた。するとDjango公式ドキュメントに以下の記述を発見。

マイグレーションというのは、データベーススキーマに対するバージョン管理システムのようなものです。makemigrations はモデルの変更点を1つのマイグレーションファイルにパッケージングし(コミットのようなものです)、migrate はその変更点をデータベースに適用する、というわけです。

migrationsディレクトリ内のファイルはこのマイグレーションファイルに該当していたようで、この情報を一度削除することでリセットされたということらしい。

ちなみにより調べるともう少し丁寧なデータベースリセット方法があった。次はこのやり方を参考にして再度対応しよう。

https://trybeetle.com/en/detail/4/

育児休職を振り返る

3ヶ月程度ではあるが、妻と同時期に育児休職(以下育休)を取得した。 終了にあたって、育休について自分の体験談としてまとめておきたい。

ちなみに育休そのものについては以下にきれいにまとまっている。

13imi.me

育休を取得しようと思った背景

実は一人目の時はうまく取得できなかった。その背景としてはまだ自分に

  • 仕事大事だよね

という気持ちと

  • 父親になる自覚

というものが足りなかったため、と今では思う。結果、仕事の調整ができず、育休は取得できなかった。しかし、一人目はよく泣く子で妻は育児の疲労感漂う様子の中、父親になれていない自分とのギャップで更にイラ立ち、家庭内がギクシャクしてしまった。その後子供も無事保育園に入ることができたため、妻も仕事に復帰し、家庭内の環境は良くなったのだが、この時に妻がイラ立ちを示してくれたことで、父親としての自覚がだいぶ育まれ、育児、家事を共同経営者としてやってきた(はず)。

二人目ができた時はこの一人目の時の反省を活かすと共に私も赤子時代を妻と共有したい!と思い、育休を取得した。

妻に取れ、と言われたというよりは自分から取りたい、と思って取得した。この考え方の切り替わりは振り返ると一人目の誕生をきっかけにライフスタイルが変わったと共に自分の思考の変化が大きいと思う。

近年よく考えたことが、自分の人生において、死ぬまでの期間で考えたときに仕事よりも家族の方が一緒にいる期間が長く、また誰にどう思っていて欲しいか?を考えたときにも仕事仲間や上司はずっと一緒にいるわけではないので、最悪どう思われてもいいが、家族に悪く思われるのは避けたいということだった。

多少計算しているような思考ではあるが、この結果家事育児を手伝うのではなく、自分事として捉えるのが当たり前になった。(そのため、イクメンと言われるのは違和感があって、単に父であり、夫であるということで受け取って欲しいのが正直なところで、イクメンと言われても全く嬉しくない。)

育休取得の準備

一人目の時は上記の通り、自分の自覚の問題もあったが、もう一点、

がよくわからなかった、ということがある。

幸か不幸か、自分に子供が生まれる前後は「コウノトリ」のドラマがやっていたりして、出産=当たり前のものではない、という感覚だけはあって、悪い方向になった場合のことなども考えてしまうことがあった。結果、「安定期」になってようやく動き出す始末だったため、タイミングが遅くなってしまったのだった。

一人目の反省から、二人目の時は直接の上司だけに「まだ安定期ではないんで、何があるかわからないんですけど・・・」と前置きをしつつ、子供ができたことと育休を取るつもりでいるということをかなり早い段階から相談していた。たぶん妊娠4ヶ月とかそのぐらいだったかと思う。この頃はまだ期間は決めておらず、ただただ意思表示というか、希望を伝えるだけではあった。当時は最低でも半年、長ければ1年と考えていたのだが、給付金が出るとはいえ、夫婦共に無給状態を続けることがやや心配になり、妻と相談した結果、産後直後が辛いので、妻のケア含め同時取得&3ヶ月強ということにして、それを会社には妊娠8ヶ月頃に正式に伝えた。

上司や会社の担当部署への調整と並行して、準備したこととして、早い段階から会社の制度を確認した。また人知れず自分の仕事を棚卸ししたり、復職タイミングを考慮して、「これはお願いすること」「これは復職後でよいこと」を整理しておいた。育休の取得期間によってはこの調整が変わると思うが、数ヶ月であったため、年次の作業やイベント事は依頼対象外となったので、その点は準備が少なく済んだ要因だと思う。ただ、復職してみて思うのだが、意外に自分がいなくても仕事は回るものなので、もう少し長い期間取得してしまえばよかった、とも思った。

育休中にやれたこと

育児(主に寝かしつけと日中のふれあいと風呂)、家事(食事以外全部)、各種申請事項などは育休中の通常業務として行ったが、以下のような副産物があった。

というのも私の場合、妻と同時に育休を取得したこともあり、妻の体調が戻った後はお互いに育児と自分時間を交代で取得して、自分時間にはそれぞれのやりたいことに時間を使うことができた。(ちなみに妻は主にオンライン英会話をやっていて、私が復職した後も子供の昼寝などに合わせて継続している。ワンオペでも工夫次第、と気付かされる我が妻の行動に頭が上がらない・・・。)

  • プログラミングや技術勉強

    実は想定していた以上にはできなかった。

    それでも日々30分〜2時間程度は不安定ながらもできたのはよかった。

  • 家でヨガ

    我が家にあるAmazonFireTVにてYouTube動画を見ながらリビングでヨガ。外は暑いので嫌だし、教室に通うのはやりすぎ(というか、育休なので教室に通ってしまうのは家庭内問題を引き起こす原因になりかねない・・・。)

  • 英語少々

    プログラミングの気分にならない時はオンラインの英語講座をやった。昼間の我が家なので、声に出しても気にならなかった。

  • 自分のやりたいこと、やろうと思っていたけどためていたことを整理した

    これは精神衛生上一番やってよかった。

    やってみるまで気づかなかったのだが、どうやら私はマルチタスクが苦手なようで、なかなか仕事しながらだと家のことと合わせて、2種類の考え事をしなければならないため、脳みその容量をうまく振り分けることができなかった。

    これが仕事のことを一旦忘れてもよい環境になると脳みそがスッキリして、整理することに集中できた。

育休取ってよかった!

振り返ってみると育休中は楽しく過ごせた。

私個人の考えでは、育児の方が仕事より大変だが、それでも大変さを楽しさが上回ったようだ。

心なしか二人目の子は私になついてくれているような気がするので、一緒の時間を過ごした効果が出ているように思う。この状態を継続するために残業はなるべくしないようにしたい。

また、何より妻の機嫌というか調子が一人目のときに比べ格段によい状態を保っており、これだけでも育休をとった効果はあったと実感している。

以前転職を検討していた時に「育児したいので残業したくないが、仕事は楽しく、給与もいい会社がいい。」と言ったら、「ワークライフバランスとか言っていますが、まだまだそんな環境は整っていない会社の方が多いですよ」とエージェントの人に言われて、「ええ、そうなの?」と自分の意識と環境とのギャップを感じたことがあった。

自分自身が短いながらも育休をとってみて、改めて、男性の育休が取りやすい会社が増えて、どこにいっても仕事も家庭も楽しめる様になってくれると結構いいことあるんだろうな、と感じた。

自分も育休を取る時にいろいろ体験談など調べたので、多少なり育休取得の参考になるといいなーと思う。

viがこなれないのでnanoインストールした

GCE上でCentOSを立ち上げて、設定を行っていたが、viになれず、nanoをインストールして対応した。

ちなみにGCEでCentOS7でVMインスタンスを設定したが、viはデフォルトあったが、nanoはインストールが必要だった。(常識・・・?)

参考

以下のブログを参考にさせていただいた。

dotnsf.blog.jp

nanoとは?

  • ターミナル上で利用可能なviよりメモ帳慣れした人に向いている軽量エディタ

viはチュートリアルをやってみたことがあるが、確かにカーソル移動時のキー操作など指の移動が少なくて済むのだが、モード変更がイマイチなれなかった。また通常コーディングではVSCode利用中のため、ちょっとしたVMの設定変更する程度であるとnanoで十分であるため、こちらにした。

インストール

yum install nano

ログインユーザーの権限次第ではインストール権限がないことがあるのでその場合は

sudo yum install nano

でインストール可能。自分の設定環境では後者だった。

操作

操作自体はメモ帳やVSCodeキーバインド未設定時に近く、迷わず作業できた。

保存なども画面の下部分にガイドがあるため、それに従って実行すると都度ガイドメッセージが出たので、迷わなかった。

Google Cloud Next Tokyo 18に参加してきた

2018/9/19-20と開催されていたGoogle Cloud Next Tokyo 18に参加してきた。

子供のお迎えや通院などがあったので、2日目のみ、かつ途中退席ではあったが、得られたものもあり、来年も参加したい。

Google Cloud Next Tokyoとは?

cloud.withgoogle.com

Next は、Google Cloud Platform(以下GCP)やG Suiteといったクラウドサービスに関するイベント。

イベントページによると以下のとおり。

クラウドによって、私たちの働き方はどう変わっていくのか、いかにビジネスを成功に導いていくのか、多彩なテーマのセッションを通して学んでいきましょう。

参加意図

GCPは少し触っていたし、G Suiteは利用中の上、好きなサービスであったので、もう少し使えるようになりたい、という思いがあった。

また、GCPに限らずだが、サーバレスとFirebaseに興味があったので、そちらのセッションを聞きに行った。

基調講演

保育園送迎があったため、途中参加。

デモを交えつつ、新しい情報なども紹介されていた。

DevOpsの自動化デモはソース変更後テストやデプロイなど自動で進んでいったのは印象的であった。

セッション: Cloud Functionsではじめよう、サーバレスアプリケーション開発

改めてサーバレスとは何か?からCloud Functionsそのものの説明とあまり知らない私でもスムーズに理解ができた。

Cloud Functionsを利用すると従来のアプリ設計とは異なり、トリガーとなるイベントから複数の処理を並行して走らせることができる。例えば画像をCloud Storageに保存したら、

  1. 画像のサムネイルを作成する

  2. 画像分析を行う

ということが同じイベントから処理されるということを実現できる。いづれも個別処理となるため、並列処理に伴う性能低下等はない。

その他の気付きメモ。

  • サーバレスとは

    1. みえないインフラ=管理不要なサーバ

    2. 自動スケーリング

    3. 使用時のみ課金

  • インフラスケールの規模

    サーバ構築>IaaS>コンテナ化>PaaS>FaaS

  • 対応言語はNode.js。Python3.7、Goなどがβ版またはα版となっており、今後拡大予定。

    LamdaはPython対応済だったと思うので、このあたりはまだ差がある様子。

セッション: Firebase入門、低コストで迅速な開発を行うには?

Firebase=サーバの代わり + 便利なツール集。

Firebaseはバックエンドを支える基盤として利用可能であるため、とりあえず利用してみる、ということが容易にできる。

リアルタイム同期ではあるが、アクションゲームなど動機頻度があまりに短いものには向かないが、それ以外はサービスメニューも増えてきているため、対応可能は範囲は広い。

Firebaseにすることで開発チームのメンバー構成がシンプルになるため、Firebaseの費用だけでなく、エンジニアの費用+コスト(時間、手間など)のトータルコストで考えると効果を出しやすい。

中規模までのアプリケーションであればFirebaseへ一気に切り替えてしまうのがオススメ。(大規模は移行方法を考慮して切り替える必要がある。)

また、Googleからも日々新しいメニューが提供されているので、今後もFirebaseでできることは拡大するだろう、ということだった。

FirebaseはmBaaSと言われていたので、スマホアプリのバックエンド用と思っていたが、webでも利用可能なので、触ってみようと思う。

セッション: BigQueryを使用した分析基盤の運用を進めていく上で見えてきた課題、乗り越えてきた軌跡

リクルートライフスタイル社の事例紹介と運用経験での課題解決の紹介。

課題やそれに対する解決方法について具体的に紹介されていたが、これほどのレベルのデータや複雑なデータ収集をするというケースが自分の場合当てはまらないので、そのまますべてというよりは一部、特にBigQueryそのものの便利さや注意点が参考になった。

特に

  • GCPサービスとの連携の容易さ

  • データ連携をbotを作成し、ビジネス部門にも扱いやすくした

  • 不足している部分は開発で補い、運用コストを下げた

という点は参考になった。

おまけ

もらいもの

  • 折り畳み傘

    受付したらいただいた。ちょうど雨が降った&会場が2箇所に分かれていたので、大活躍した様子。

  • サコッシュバッグ

  • Tシャツ

  • USBケーブルつきスピナー

    イベント中のクエストとハンズオンを行ったらいただいた。

会場、設備等

  • ランチ

    ランチセッションは満席で参加できなかったが、カフェスペースにておにぎり、パンと飲み物の無料提供がされていた。

    外出せずにお昼を取れたのでそれは助かった。

  • シャトルバス

    東京プリンスホテル

    ザ・プリンス パークタワー東京

    の2箇所開催であった。徒歩でも10分ぐらいだが、観光バスほどの大きさのシャトルバスが15分間隔で運行しており、そちらを利用しての移動も可能だった。

  • 電源とネットワーク

    チャージスポットが用意されており、スマホ用ケーブルとコンセントが用意されていた。電源難民にならずに済むのでこれは助かる。

    wi-fiもあったが、こちらは展示スペースのみでセッション会場までには展開されていなかったのが残念だった。

  • カフェスペース

    軽食と水が用意されていた。これもありがたい。

  • 公式アプリ

    iOSAndroidの公式アプリがあり、これが思いの外役にたった。

    事前に登録したセッション情報が見れるだけでなく、アプリ上で申し込み、キャンセル、アンケート回答ができ、また会場の地図やwi-fiの情報なども確認が可能。セッションにはQRコードでチェックインするのだが、それをアプリ上でも参加済といったカタチで反映される。

    一部残念だったのが、そのチェックイン用のQRコードはアプリでは表示できず、メールかwebページか印刷した紙を利用していた点で、これは来年改善されることを期待したい。

    それでも、こういったイベントの公式アプリとしては使いやすく、他のイベントでもあったらいいな、と思った。こういうイベント用のアプリを簡単に作れるサービスがあったら、需要あるかな・・・?

サービス紹介関係のイベントなので、参加は無料でできるが、全体的に充実した内容だった。来年は全参加して、最後のネットワークパーティーにも参加してみたい。

PyCon JP 2018 2日目参加メモとまとめ

1日目に引き続き、2日目も参加してきた。諸事情によりKeynoteは参加できず、セッションから参加。また途中で退散となった。

2日目は平日だからか1日目よりやや人が減っている?と感じたが、おやつ戦争は健在。

セッション: 「リモートペアプロマントルを突き抜けろ!」AWS Cloud9でリモートペアプロ&楽々サーバーレス開発

セッションタイトルの「マントルを突き抜けろ!」はリモートするなら地球の反対側ともやれないと意味がない、ということでつけたタイトルだそう。ふざけているように思えてリモートワークの本質だなーと思ったし、それを可能とする環境が本当に整ってきているということがよくわかったセッション。

実際にAWS CodeStarというサービスを利用して、環境構築、Cloud9というAWSが以前買収したブラウザベースのIDEでリアルタイムでリモートTDDペアプロ、途中からソロ、をしながらどのような環境でそれを実現しているかを解説するという内容だった。

リモートペアプロは想像以上にスムーズに画面が動いて、環境としては問題なさそうという印象。

実際にやっているところを見ての気づきとしてはリモートワークはペアプロにかかわらず、役割分担と何に取り組むかを決めておく、ということが実は重要と感じた。

AWS CodeStarは環境構築をパパパっとやってくれるサービスで、こんな便利なものが存在しているのか!とびっくりした。料金もそれほど高いものではないので、試してみよう。

AWS CodeStar – アプリケーションを迅速に開発および構築して AWS にデプロイ

セッション: REST API に疲れたあなたへ贈る GraphQL 入門

  • GraphQLすげー

  • AWS AppSync便利ー

という結論。

そもそもGraphQLは聞いたことがあっただけで内容は全く把握できていなかったので、そもそもなところから話をされていたので、勉強になった。

GraphQL=API用のクエリ言語 + サーバ側のランタイム

GraphQLのメリットはクライアントとサーバ間のインターフェースがクリアになること。

その理由としては

  • 型指定スキーマ

  • クライアントからどんな風に取りたいかを指定できる

  • サブスクリプションを利用したリアルタイム処理  イベントトリガーでデータが取得できるので、データが追加されたなどをトリガーにクライアントへ飛んでくる、ということが容易に実装できる

AWS AppSyncはGraphQLの環境をAWSのマネージドサービスを組み合わせて提供してくれる。かつテンプレートプロジェクトのようなものも提供されているのでそれを参考に進めてみることも可能。

aws.amazon.com

GraphQLが魅力的に感じたので、試してみたい。

セッション: Pythonでざっくり学ぶUnixプロセス

もともとRubyで書かれた「なるほどUnixプロセス」という本があり、それがオススメということでPythonでやってみたという内容。

Unixは会社の研修含めちょいちょいやっているが、カーネルシステムコール、プロセスなどの話は今回の話でよくわかった(というかこれまで全然理解できていなかったことが判明した)。

本すべての話までは限られた時間ではできないが、Unixのベースとなる考えや基本的な設計思想が分かる内容で、最後に紹介された参考資料で継続学習できそう、という基本の内容としては密度の濃い内容だった。

1日目の「webアプリケーションの仕組み」もあったが、Pythonという言語を知るだけではなく、周辺技術、別レイヤーの技術の知識も深めていくことがより広範囲なサービス開発の実現につながる、ということを感じたセッションだった。

gohh56.hatenablog.com

セッション: Pythonによる異常検知入門

異常検知そのものの定義、異常検知の種類、そしてその種類ごとの分析手法とその手法をPythonで実現するとこうなる、という内容が30分でコンパクトにきれいにまとまった内容だった。

異常とは何か?ということについてはその事象だけでは判断できない。その事象の背景を理解する必要がある。

また、分析手法を活用して出た結果が必ずしも正解ではなく、分析対象をよく知る人などから分析結果に対するフィードバックをもらっていくことが必要である。

分析手法についても知識が必要なので、データサイエンスが難しそうと感じていたが、それ以上に実はかなり泥臭くビジネスドメインに関わっていくということが必要ということが、データサイエンスの最たる困難さだな、と感じた。

別のカンファレンスで某飲食チェーンのデータサイエンス部門の方の話でもやはり泥臭く(=悪い意味ではなく)一つ一つを積み重ねていく、ということを実践されていたことを思い出した。

データサイエンスや分析というのは閉じこもってごにょごにょするという勝手なイメージがあったが、全く違ってフットワークの軽さが必要な業務だと感じた。

PyCon JP 2018を振り返って

  • 個人的にはPyCon JP 2017より多様なトピックのセッションがあり、楽しく参加させていただいた。特にDjango関係が結構あったのは嬉しかった。

  • 紙コップが整っていなかったのが残念。

  • 今回メモツールとしては、Notionを利用したが、Notionよい。 ページ階層化できるし、URL貼ると埋め込み形式で貼れるし、md形式っぽく書けるし。オススメ。

(蛇足)カンファレンスに参加してみる、ということについて

Pythonを独学でちゃんと勉強し始めて1年ぐらい経ったが、それでも全然雑魚である状態。それでもこういったカンファレンスや勉強会には行ってみる、ということをおすすめしたい。

参加側の場合、アウトプットする場ではないので、「勉強した気になる」という話があるが、初心者だったら、とりあえずインプットを増やしてみる、というのは手だと思う。

特にネットや書籍が様々にある状態においてはそれらを自分で取捨選択するのは意外に労力がいることで、また対象トピックが絞られた状態になってしまう。

カンファレンスに行くと

  • 様々なトピックのセッションが用意されていて

  • それらを短時間で、知識や経験をもつ方が話をしてくれる

ので、多様なトピックに触れつつ、まとまった内容をインプットしやすい。正直最初は??が相当数ある状態になってしまうが、わからないことがわかるので調べようがあり、調べたりやってみると理解ができていく。徐々に知識が増え、できることが増え、やっていることがはっきりしてくると自分で絞ることもできるようになる。そしたら、参加頻度や対象を見直していけばよいと思う。

来年のPyCon JP2019は2019/9/16-17@大田区産業プラザPiOとのこと。来年も楽しみ。