ngmt-ke

フルスタックエンジニアを目指す元しまんちゅが都会で子育てしたりするブログです

GlideでRubyKaigi2019の非公式アプリ作ってみた

4/17 追記 Glideでアプリを作って得た知見をQiitaにも投稿しています。 https://qiita.com//ngmt83/items/5581a177d13540237623

つい先日話題になったGlide – amazing apps without codeでアプリを作ってみたので、作成の流れとGlideの使用感をお伝えします。

話題になった記事

paiza.hatenablog.com

自作アプリが一向に進んでいなかった私には渡りに船というか、やるっきゃないという感じで思い立ってそのまま徹夜の勢いで完成させました。 いつもお世話になっているRubyに僅かでも貢献できると嬉しいと思い、RubyKaigi 2019のスケジュールを一覧するアプリにしました。

(やっつけクオリティでむしろ迷惑をかけたらすみません)

成果物

アプリはこちらです。使ってもらえると嬉しいです。

rubykaigi2019.glideapp.io

PWAも簡単にできました。

作り方

所要時間は全体で4時間程度です。慣れてしまえばGlideでアプリを作るところは1時間で終えられそうです。

Schedule - RubyKaigi 2019から材料となる情報を取得

サイトに行って素直にhtmlをダウンロードしました。特に言うこともないですね。

htmlからセッション情報のマスターとなるcsvを出力するするスクリプト作成

Rubyスクリプトを書きました。CSVとNokogiriを使いました。フロントエンドに知見があってセレクタをよく使用する人であれば容易に作れます。

参考

qiita.com

googleスプレッドシートにマスターをアップロード

作成したCSVをコピペしました。定期的に更新が必要なアプリであればスクレイピングからマスターのアップロードまでGoogle Apps ScriptでCIできるように設定するとよさそうです。

ngmt83.hatenablog.com

Glideでアプリを作りながら、アプリ用に情報を並べ替えた複数シートを作成

これはただただ試行錯誤でした。ぽちぽちするだけで今時のアプリができるように見えますが、やはり自由度は高くないです。 マスターシートを元にGlideが解釈しやすいシートをいくつか作りました。アプリのためにどんどんと非正規化する形になるので醜いスプレッドシートになります。 また関数もかなり駆使するので人が作ったものは見るのは辛いでしょう。

参考までに実際に使用しているスプレッドシートを公開します。Readのみでユーザ情報が保存されるシートは非表示にしているので安心して閲覧してください。

Schedule - Google スプレッドシート

使い方は公式の動画がわかりやすいです。

www.youtube.com

Glideの感想

一言で言うと「スマホ閲覧が前提のPWA版ペライチ」です。

基本的には一覧と詳細の機能を持つのみで、どのデザインで見せるのか?という選択肢はいくらかあります。今時なグリッドデザインも選べます。基本的にクセがないデザインですが、流行ればBootstrapのように一目見ただけでGlideっぽさを感じるようになるかもしれません。

どの程度の使用に耐えるかですが、閲覧がメインのアプリであればGlideで作っても問題ないように感じます。またボタンなどにURLを設定できるので、ハッシュタグ付きのツイートなど他のSNSをうまく使って活用の幅を広げることもできそうです。(どの程度の負荷に耐えれるかは不明)

継続的に更新が必要なアプリ・サイトの場合はスプレッドシートを如何に綺麗に設計するかの勝負になります。基本的には作りっぱなしにするか、自分一人でメンテすることをおすすめします。

どんなところで力を発揮するか

幅広く活躍すると予想できます。具体的には、

  • まとめサイト(~10選みたいな列挙型サイト)
  • 商店街食べ歩きアプリ
  • 学園祭アプリ

などは簡単に実現できると思います。「学園祭のアプリをお小遣い程度の金額で作って欲しい」といった依頼もこれなら採算が取れるかもしれません。そもそもエンジニアに頼むまでもなく、スプレッドシートが得意な人がいれば実現できると思います。RubyKaigiもそうですが学園祭などイベント関連のアプリは保守期間が短く、非常に相性がよさそうです。 メールアドレスによる認証機能も備えているため、クローズドなサークル専用のアプリ・サイトとして使うのもありかもしれません。

また、スタートアップがMinimum viable productの検証に使うのにも非常に相性がよさそうです。エンジニアリング経験のないインターン生に任せたとしてもすぐに形を作ることができると思います。グーグルスプレッドシートを用いたクックパッドマートのMVP検証が記憶に新しいですが、それをより簡単に、しかも体験もリッチに作ることができるGlideは非エンジニアこそ使いこなせるようになるべきツールです。

techlife.cookpad.com

最後に

GASやIFTTT、Zapierなど機能を簡単に提供するサービスはありましたが、フロントエンド・UIを簡単に提供するサービスは新しいですね。いよいよエンジニアでなくともフルスタックにアプリケーションを作れる時代になってきたと感じます。 職業エンジニアの私としては危機感もありますが、世の中が便利になるのはワクワクしますね。

ブログメンティーで学んだことと卒業後1ヶ月の振り返り

1,2月にカックさんからブログメンタリングを受け、卒業しました。

twitter.com

実際身についているか?を自分で検証する意味も込めて、卒業後1ヶ月を過ごした上での卒業エントリです。

そもそもブログメンタリングとは?

開始時はある程度流れがあります。それについてはご本人のブログに記載されている通りです。

最初にメンティに「最低20個」出してもらって,それをさらにブラッシュアップして「30-50個」まで増やす.重要なのは「これもブログネタになるんだ!」という気付きの部分で,そこに気付いてしまうと,あとは自律的に「ブログネタ探し」ができるようになる.メンタリングでは「ブログネタがないから書けない」という理由(言い訳)を排除していくことからスタートする.

楽しく!アウトプットを習慣化しよう - kakakakakku blog

それ以降のメンタリング期間中は「習慣化とよりよいアウトプットのためのフォローをする」の一言に終始します。 非常にシンプルですが、その中でメンティに応じてパーソナライズしたフォローをするというスタイルです。メンターにかかる負担はなかなかのものだと思います。 お金を払わせてほしいとすら思いました。*1私としては感謝しかありません。

フォロー内容

次のようなフォローをしていただきました。

  • ブログネタの深掘り
  • メンティが持つ強みの理解促進とそれに合わせたブログの方向性のアドバイス
  • アウトプット(ブログ・LTスライド)のレビュー
  • ブログのKPI設定
  • 改善のための仮説・課題設定、実施サポート

他のメンティOBの記事からより詳細を知ることができます。

2ヶ月のブログメンティによる成果

  • 21記事を投稿
  • LTを3回*2*3*4
  • twitterフォロワー数約100->約200
  • 平均週間PV100(元は6ヶ月で500)

他のメンティのようにはてブでバズったり、目覚ましい成果をあげることはできていませんが、「毎週のアウトプットとそれを実現する学習の習慣化」ができたことがなによりの収穫です。実際メンタリングを受ける前と比べると学習が自然と生活に入り込むようになり、学習時間が取れないとそわそわするようになりました。これは非常に大きな変化で進化です。

想定外の学び・副産物

メンタリングを通して想定外の学びもたくさんありました。

小さいプロジェクトのPDCAサイクルの回し方

アウトプットを改善するために、その改善を測る為にKPIを設定し、仮説をたて、課題を設定し、実践、そして振り返り・・・

これはプロジェクトのPDCAサイクルそのものでした。私は少人数チームで働いていますが、これまでPDCAサイクルをあまり意識できていなかったと気付きました。 目標とすべき数値はどれなのか?数値を改善するために何が必要なのか?実践できるレベルの施策にどう落とし込むか? 自分のアウトプット活動という小さいプロジェクトを回すことでPDCAの基本を一通り経験することができたと言えるでしょう。プロジェクトの回し方を学べるなんて嬉しい誤算でした。

良いメンターの1つの解

まずカックさんがそもそも尊敬できる人であり、メンタリングされながらHRTを備えたロールモデルを身近に具体的に感じることができました。

カックさんは非常にストイックで、アウトプットにおいて先輩で、多くの結果を残しています。そして私はメンティとして師事する関係でした。(しかも無料) この関係においても、カックさんは個を尊重し、意見ややり方を押し付けることなく、ストレスを極小にするような配慮の上でメンタリングしていただきました。

カックさんの姿勢を見習い、盗み、実践して身につけていきたいです。

他のブログメンティとの縁

ブログメンティをやっていると、いつの間にかなんとはなしに数人とtwitterで仲良くなっていました。他のメンティやOBのアウトプットは質が高く、また当たり前のように継続しています。それは私にとっては非常によい刺激だったため、気付いてからは意図的に他のメンティをフォローして学びを加速させることができました。 卒業した今も、メンティOBとして恥じないアウトプットをせねばと心地よいプレッシャーを感じています。

一緒に頑張る仲間の感覚もありますが、見習うべき師匠がたくさんできた感覚の方が強いです。

卒業してからの1ヶ月の振り返って

3月も週1記事以上ブログを書くことができました。 まずこれには驚きです。私は2月まで休職しており、3月から復職するタイミングだったのですが、それでも継続できたことは大きな自信になりました。

しかし、3月は技術記事をあまり投稿できませんでした。これはもとより抱いていた課題でしたが改めて浮き彫りになりました。 ただブログネタへのアンテナは身についたようで、業務を通してブログネタがたくさん増えました。 カックさんは仕事してたらブログネタがないなんてことはないと言っていましたが、全くその通りだと実感できました。

これから

私には文章力が足りていない為、次の記事にオススメされている「理科系の作文技術」を読んでいます。ブログでの実践を通してわかりやすい文章を書く力をじっくりしっかり身につけていきたいです。

kakakakakku.hatenablog.com

技術記事が投稿できないという課題については、最近はAngularでの国際化対応やPythonでの画像処理など新しい学びが多く、ネタには困っていないので書くだけです。頑張って書いていきます。

最後に

ワークショップとブログメンティー会(カックさん非公認?)が楽しみです!実現のための協力もさせてください!

新機能に用いるAPI作成の技術選定の流れ ~Python製Framework Falconを選ぶまで~

API作成の技術選定の流れを要件を踏まえた上で、複数のPython製Framework(以下FW)の特徴にざっくり触れつつ、どういった観点でFalconを選択したかを書きます。

まずは要件やチーム状況の確認からです。

要件・チーム状況

  • 画像解析を行うため機械学習ライブラリdlibを利用したい
  • なる早でプロトタイピングが求められており、正式な稼働は決まっていない
  • 新規APIのエンドポイントは1つで事足りる
  • 既存のサーバーサイドアプリケーションはRuby on Railsを使用している
  • Pythonの熟練者と言えるメンバーはいない

上記を元に言語を選びます。

言語選定

要件より、dlibというライブラリを利用するため、C++Pythonに限定されました。C++Python共に熟練者はいませんが、PythonRubyと類似する点が多く、WEBアプリケーションの作成にも向いているためPythonを選択しました。

次にPythonでどこにAPIを作成するかを考えました。

LambdaかEC2か

まずAWS Lambda上に実装するか、EC2にサーバーを立てるかを考えました。勉強したいという気持ちもあったため、Lambdaについて先に調査・検証しました。

するとLambdaにはデプロイパッケージサイズに制限(50MB)があり、機械学習ライブラリdlibをセットアップした環境を50MB以内に抑えるのは難しいということがわかりました。そのため、EC2にサーバーを立てることにしました。

EC2にサーバーを立てることは決まったので、サーバー実現のためのFrameworkを選びます。

FWの選定

候補として上がったのは次のFWです。

Django

Rails、Laravelと並び3大WEBアプリケーションFWとも言われるほど有名で人気のフルスタックFWです。O/Rマッパーやテンプレートエンジンなどを筆頭に豊富な機能を備えています。

しかし、今回の要件に豊富な機能は必要ありません。シンプルにすぐに使える、もっと言えば使い捨てられるくらいの方が向いています。ということでDjango並びにその他フルスタックFWは採用を見送りました。

Flask

Djangoと並んで人気のFWです。フルスタックではなく、microもしくはmiddle FWと言える軽量さが特徴です。フルスタックFWと比較するとシンプルに書け、1つのpyファイルにまとめることも可能なほどです。

Bottle

micro FWです。API作成のために最小限の機能をシンプルに実現するための最小Python製FWと言えるでしょう。小さいため動作も速いです。私にとっては初めて見るmicro FWだったため、5行でHello World!を実現できるのは衝撃でした。

qiita.com

軽量で高速動作は非常にいいですが、更新頻度が低く、最新版でもver1未満のため採用は見送りました。

Falcon

Bottle同様なmicro FWです。RESTFUL API作成に特化し、高速な動作と拡張性の高さが特徴です。micro FWの中では人気も高く、Add-onも多く提供されています。

etc

他にも高速な動作を売りにしたJaprontoやAPI Star、高速かつ最新のFastAPIも気になりました。ただし情報が多くは出回っていないのと、最新版でもver1未満のため、選外としました。

github.com github.com github.com

最終的に

FlaskとFalconの2つに絞り込めました。2つで比較すると、Falconの方がロゴがかっこよく、Flaskのほうがやや多機能なFWであり、テンプレートエンジンも持ちます。今回は最小限のもので十分だと判断したため、Falconを利用することにしました。

参考情報

medium.com fgimian.github.io kokensha.xyz

所感

要件やインフラ構成を含めて0から考えて、初めての言語、初めてのFWで実装することは難しかったですが、非常に学びが多かったです。それだけでなく、0から作り上げている中で「これがエンジニアリングの醍醐味だ」とワクワクも感じていました。こういう仕事をどんどんやっていきたいですね。

予告

Pythonに学ばされたこと、Dockerでdlibの環境構築をしたこと、Falconの実装例なども近いうちに記事にしたいと思います。

Rails Developers Meetup 2019 Day2 参加レポート

Rails Developers Meetup 2019 Day2の参加レポートです。

Day1の参加レポートはこちら。 ngmt83.hatenablog.com

投稿が遅れましたが、聴講したセッションの感想を軽く述べる程度のレポートです。資料は各URLの先にリンクがあるのでそちらを参照してください。セッションの動画もアップロードされているのでよりライブ感を楽しみたい方は下のプレイリストからどうぞ。スタッフの動画班?ありがとうごじざいます。

www.youtube.com

Day2で聴講したセッションは次のとおり。

  • サービス開発初期の「時間を金で買う」技術
  • 入門 名前
  • みんながやりたがらない仕事をやって食っていく
  • モチベーションクラウド、マイクロサービス化計画
  • Ruby on Railsの正体と向き合い方
  • コードレビューしない
  • Rails 6, Progress and Maturity

サービス開発初期の「時間を金で買う」技術

https://railsdm.github.io/#session-masa-iwasaki

「エンジニアの時間は高いし、エンジニアの時給換算より安いならお金で解決すべき」というのは言葉ではわかるものの、実際に決裁権を持つ人を説得するのはなかなか難しいため、どう説得するかも実践ベースの知見があってありがたかったです。

また、採用コストとしても今時のツールを入れておいた方がいいというのは私には盲点でした。

確かに監視ツール・CIサービス・ドキュメント管理ツール・プロジェクト管理ツールなどどれが欠けても確かに不便を強いられますね。

入門 名前

https://railsdm.github.io/#session-fujimura

このぐらい名前について真剣に考えたセッションでした。哲学的な話のみでなく、実際のコード例も踏まえたいい名前・悪い名前にも言及されていて非常によかったです。

セッションとは関係ない過去のツイートですが、私が名前を大切に思っていることがわかるツイートがあったので貼っておきます。

みんながやりたがらない仕事をやって食っていく

https://railsdm.github.io/#session-idesaku

カカポがかわいいかったです。社内部活動で薄く広くリソースを確保するよりも少人数で集中的に進めるほうが費用対効果がよいというのはなるほどと感じさせられました。

また、実際に現地でプレゼンを聞いて完成するタイプのセッションでクオリティが非常に高く、満足度も高かったです。懇親会で後藤さんと話した際には「時間を割いて足を運んでもらった人に最高のセッションをしたかった」とプロ意識を感じる熱い言葉をいただきました。他にもカカポのように独自の進化を遂げた動物を筆頭にたくさんの幅広い話題をお持ちでした。

モチベーションクラウド、マイクロサービス化計画

https://railsdm.github.io/#lunch-session-linkandmotivation

泥臭く・地道にマイクロサービス化を進めている話でした。失敗も含めて発表できるところが等身大でいいと思いました。リンモチさんがもともと非WEB系で上場していた企業ということは驚きでした。

Ruby on Railsの正体と向き合い方

https://railsdm.github.io/#session-yasaichi

立ち見でしたが最高でした。言語化が上手すぎです。Rails学を語るための筆頭論文とも言うべき資料は必見です。

私は「Railsは死んだ」論に対しては「向き不向きでしょ」という立場をとるのですが、それを説明するのはあまり簡単ではありません。しかしこれからは「じゃあRailsは何に向いてるの?なんでそれに向いてるの?」と聞かれたらこれを見てくれ!と言えるようになりました。そんな決定版とも言うべきセッション・資料でした。

リスペクトの気持ちが溢れてしまったツイート

コードレビューしない

https://railsdm.github.io/#session-hanachin

攻めたタイトルですが真摯にコードレビューと向き合ったセッションでした。レビュの目的・いいレビュとは何かなど丁寧に述べられており、業務でレビュに不穏な雰囲気を感じたら思い出したいセッションでした。

Rails 6, Progress and Maturity

https://railsdm.github.io/#keynote-session-jeremy

カンファレンス2日分の疲労があったのも手伝い、英語がほとんど理解できませんでした。すごくポジティブな気持ちになってことは覚えています。Youtubeで字幕を表示して見直したいと思います。

全編を通しての所感

RailsDMをキメた

と言っても過言ではないくらいにテンションをぶち上げてくれました。平日になり、日々の業務に戻った今(3/26)もなお余韻が感じられるほどです。最高のカンファレンスをありがとうございました。

キメた感溢れるツイート

〜そして伝説へ〜

振り返りもあるよ!

rails-developers-meetup.connpass.com

Rails Developers Meetup 2019 Day1 参加レポート

Rails Developers Meetup 2019が始まりました。楽しみすぎて事前にブログを投稿してしまっていた*1のですが、期待通りいや期待以上にいいカンファレンスだというのが正直な感想です。

2日間開催されますが、ボリュームが半端なく、2日終わってから参加レポートを書いていてはいつ書き終わるかわからんと思ったので、ざっくりとDay1分を早速書きました。聴講したセッションに関しての簡単な感想だけです。 聴講したセッションは次のとおり。

  • "Ask Me Anything" by DHH
  • スポンサートーク
  • アプリケーションを作るときに考える25のこと
  • 少人数でサービスをすばやく開発するためのRails活用事例
  • CSSの技術的負債との向き合い方
  • 万葉のRails新人研修のコードレビューコメントを分析してみました
  • 7年目を迎えたRailsアプリケーションの傾向と対策
  • 毎日の開発に役立つRailsプラグインづくりの秘訣
  • まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

"Ask Me Anything" by DHH

英語のセッションで英語力うんちの私にはしっかり理解はできませんでした。しかし、多くの英語できるマンがツイートしてくれていたので、それで大枠はつかめました。togetterにまとめているので気になる方はどうぞ。 togetter.com

特に印象に残ったのは「モノリスが辛いんじゃなくて、綺麗でないコードが辛いだけだ。まずは綺麗に書き直そう」(意訳)です。

スポンサートーク

Oracleさん、Reproさん、STORES.jpさん、Speeeさんスポンサーありがとうございます。感想はこんな感じです。

ツイートにはないですが、Speeeさんの代打登壇の方の次の言葉はとても印象的でした。

かっこいいエンジニアの活動を伝えたい

コードをかけない人の中でもっとも技術に貢献する人になりたい

私はこの人をかっこいい人だと思いました。

アプリケーションを作るときに考える25のこと

「価値はあるけど難しいものに取り組もう」「Railsの使いどころ」「gemを使いこなそう」「gemはこう探そう」など盛りだくさんな内容でした。gemに関しては様々なものが紹介されていました。資料が公開され次第改めて確認したいです。

「2004年から蓄積された社内記事が読めるという福利厚生があります」という発言がとくに面白く、それは実際に魅力的だし、それを断言できるだけのドキュメンテーション文化はすごいと思いました。

少人数でサービスをすばやく開発するためのRails活用事例

「エンジニアの人件費が一番高い。Paasにお金をかけてお任せする」というのはまさにその通りだと思いました。また、Angular + IonicでPWAしてるし、サーバーはRailsだし、福岡オフィスがあるし、ピクシブさんむっちゃ面白そうだ!と思いました。

CSSの技術的負債との向き合い方

まさにCSSの負債に困っていたので聴講しました。CSSRailsなどと同様に応急処置的な施策と、根本的解決のための施策を地道にやっていくしかないんだなと思いました。チームで話し合う際にはまずみんなでこの資料を見たいです。

万葉のRails新人研修のコードレビューコメントを分析してみました

コーディングスタイルの基礎訓練、用語認識のすり合わせ、初心者の発想を広げるセルフチェック、暗黙知の価値観に基づいたレビュなど、わかりやすい良いレビュをするためのヒントをたくさんもらえました。研修プログラムの公開もそうですが、研修からのフィードバックを公開し、コミュニティに還元する万葉さんの姿勢はほんとに素晴らしいです。

歴戦のエンジニアはよく直面する難しい問題に自分の回答を持っていて、すぐ答えられるのがかっこよかったです。これぞプロフェッショナル。ちなみにタイトルは雑ですが、セッションは非常にわかりやすくダークローンチしてみたいと思いました。

7年目を迎えたRailsアプリケーションの傾向と対策

レールを外れる時いかにうまく外れるかというときの具体例を提示されており、非常にわかりやすかったです。セッション中に紹介された参考記事はすべて永久保存版の素晴らしい記事なので、Railsでレールを外れる前にみておきましょう。

毎日の開発に役立つRailsプラグインづくりの秘訣

gemの名前もスライドもジョジョだらけでした。松田さんがジョジョ好きだということが言葉でなく、心で理解できました。

まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

エモかったです。年齢を重ねた時の生々しいつらみを述べつつも、いかに戦っていくか(戦わないか)も複数の例で説明されてわかりやすかったです。圧倒的な実力で倒せるようになりたいです。

また、序盤に「他人の人生は参考にならない」といっていて、ちょうど先日の引退会見でイチローが話していた内容と被っていたこともあり、心に強く突き刺さりました。

あくまでも秤(はかり)は自分の中にある。

それで自分なりに秤を使いながら、自分の限界を見ながら、ちょっと超えていくを繰り返していく。

イチローの引退会見を文字起こししてみた - 俺の遺言を聴いてほしい より

最後に

Day2も楽しみです。楽しみましょう!

Rails Developers Meetup 2019が楽しみすぎる話

タイトルの通りです。楽しみすぎて深夜3時までこんな記事を書いてしまうくらいです。

railsdm.github.io

ここがすごいよRails Developers Meetup 2019

国内最大のRailsのMeetupです。2日間3トラック並行での開催です。大規模で単純にすごいですね。儲かるわけでもないのにその準備・運営をやりきろうという主催者には頭が上がりません。カルパスさんありがとうございます。

KEYNOTEが豪華

"Ask Me Anything" by DHH

Rails 6, Progress and Maturity

私が語るまでもないですね、Rails生みの親であるDHH氏とRails Core TeamのJeremy Daer氏の話は楽しみで仕方ないです。DHH氏への質問はこちらへどうぞ。 railsdm.herokuapp.com

まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

こちらも豪華です。高橋 征義氏は技術書典の仕掛け人でもあり、Ruby, Railsに限らず日本のエンジニアリングに貢献し続けています。*1誰も避けることのできないプログラマが歳を重ねた先を考えるというテーマも非常に気になります。エモい内容でも、現実に即した実用的なケーススタディでもいずれにしても今後のキャリアの参考になりそうです。

余談ですが、Ruby歴20年以上の人ってどれくらいいるんでしょうか・・・

Ruby歴約20年のRubyist

参加者の熱も強い

techplay.jp 上記リンクで確認できますが、参加費がかかります。そして2日間のうち1日は平日です。参加したいという強い意欲がなければ参加できません。にもかかわらずチケットはすぐに売り切れました。*2

カンファレンス会場で生じる交流も非常に価値のあるものとなるでしょう。

ngmtが特に気になっているセッション

  • 少人数でサービスをすばやく開発するためのRails活用事例
  • 万葉のRails新人研修のコードレビューコメントを分析してみました
  • 7年目を迎えたRailsアプリケーションの傾向と対策
  • サービス開発初期の「時間を金で買う」技術
  • 入門 名前
  • Ruby on Railsの正体と向き合い方
  • コードレビューしない
  • 自分たちを信じられるチームが作りたくて私はこうした

直感的なものもありますが、振り返るときの備忘録としてなぜ気になっているか記しておきます。

少人数でサービスをすばやく開発するためのRails活用事例

詳細は公式サイト参照

Railsは少人数で素早く開発するためのフレームワークだと私は考えています。そのRailsにとっての王道とも言えるチーム構成で、いかに素早さを突き詰めていったか非常に気になります。今話題(当社比)のピクシブ株式会社の方の発表ということもあります。

万葉のRails新人研修のコードレビューコメントを分析してみました

詳細は公式サイト参照

私は教えるのが好きで、これまでも10人程度インターンをみてきました。しかしまだまだ難しいと感じているため、研修や育てる体制が充実していると噂の株式会社万葉さんのお話を聞けるのは非常に楽しみです。

7年目を迎えたRailsアプリケーションの傾向と対策

詳細は公式サイト参照

私は次の記事が非常に好きで、何度となく参考にさせてもらいました。 tech.kitchhike.com この記事を書いた株式会社キッチハイク 小川 剛さんのトークに興味があります。

余談ですがキッチハイクというサービスは創業者の原体験がよく現れていてエモくて好きです。

サービス開発初期の「時間を金で買う」技術

詳細は公式サイト参照

そもそもRailsはサービス開発初期の時間を削減するために選定するものだと思っています。「時間を金で買う」というのは、時間を大切に捉えるRailsの方針と合致しています。どこにお金をかけるとどこの時間を抑えることができるのか、非常に気になります。

入門 名前

詳細は公式サイト参照

命名は非常に重要だと考えています。煽り気味の新書タイトル風に言うと「プログラミングは命名が9割」です。名著リーダブルコードも命名が大事ってことが全編を通して書いてありました。コードレビュでも命名は頻繁に議論されます。そんな命名に関して整理したというセッションは期待せざるを得ません。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Ruby on Railsの正体と向き合い方

詳細は公式サイト参照

期待するしかないよなあ!

コードレビューしない

詳細は公式サイト参照

タイトルに釣られました。このセッションを聞けば今後のコードレビューがより有意義なものになるのではないかと思っています。

自分たちを信じられるチームが作りたくて私はこうした

詳細は公式サイト参照

私はいかに信頼を勝ち取るか、いかに周りを信頼するかを自分の課題だと思っています。そのためにリーダーとして実際に行動した話には非常に興味があります。

最後に

聞きたいセッションが並行トラックで被っているものもあり、すべて聞くことは難しいと思いますが、聞いたものはしっかりブログにアウトプットしていきたいと思っています。また、他の参加者がどのように感じたか、聞けなかったセッションはどんなだったかも非常に気になるので、参加者はぜひ参加レポート書いてください!

私はあなたの参加レポートを待っています。

*1:技術書典6も楽しみです、運営ありがとうございます

*2:私は有給休暇で自腹で行きます。

通勤時間ながらUdemyのすヽめ

2019年1月に初めてUdemyのコースを購入し、勉強に取り入れました。最近になってようやくコンスタントに進める方法を見つけたので紹介します。

その方法は「通勤時間ながらUdemy」です。

通勤時間ながらUdemy概要

  • コースをWiFi環境でダウンロードしておく
  • 通勤中聞く
  • わかっている箇所は飛ばしたり、ブラウジングなど休憩をする
  • わからない箇所はブックマークをつける

ポッドキャスト感覚で使用することを推奨します。また、Udemyは動画にブックマークとコメントを残すことができます。ただ聞き流すだけでは身につかない or わからない箇所はブックマークをつけ、あとで手を動かしながら復習しましょう。

メリット

  • 聞くだけでもよく、通勤中でも取り組みやすい
  • Udemyのコースは体系的にまとめられていることが多いため、知識の抜け漏れを見つけやすい
  • コースの聴講はどんどん進むため、学習の進捗を出しやすく、達成感を得やすい
  • 英語のコースを聴講すると英語学習もできる
  • 講師の話すスピードや理解度に合わせて倍速再生ができる
  • 動画を事前にダウンロードすることで通勤時間格安simの通信低速問題が気にならなくなる

向いている学習テーマ

かじった程度の知識・経験を持つフレームワークや言語は通勤時間ながらUdemyで学ぶのにとても向いています。*1逆に全く知らない領域は向いていません。理解に時間がかかり、動画をいちいち停止させたり、わかった気になってしまうだけだったりするためです。

例えば、私は業務でAngularを利用したWEBアプリ開発をしています。ただし、体系的に一通り学習を終えたわけではなく、既存のコードを参考にしつつその時々で検索して覚えています。必要になった時に必要な勉強をすることは悪いことではないですが、既存のコードに引っ張られすぎたり、便利な機能やベストプラクティスを知らないために回りくどい実装をしたことがありました。特にどこがわからないのかわからない状況になってしまうと、手をつけることができなくなってしまいます。そこでUdemyのコースを最初から最後までざっと通して聞くことで、自分に自信のない箇所をあぶりだすことができました。

最後に

積ん読はページめくりなど能動的に取り組まなければ進みませんが、動画教材は再生ボタンを押した後はほぼ何もしなくても進んでいくのでどんどん勉強していきましょう。

そういえばちょうど今セールやっているので買い時ですよ!Udemyコース購入駆動学習しましょう! www.udemy.com

*1:似ているものも良さげ。Railsできる人がLaravelを学ぶなど