ﾅｶﾞﾓﾄ の blog

Full Cycle Developerを目指すエンジニアが有用そうな技術記事や、ポエムのようなよしなしごとを投稿するブログです。

メディア勉強のために観光用(壱岐)サイトを作る

ポエム

ここでいうメディアとは、キュレーションメディアやオウンドメディアといった技術的にはシンプルな仕組みのWEB上で展開するメディアのことを指します。

勉強する理由

フルスタックエンジニアを目指す身としてはエンジニアリングのみならず、ビジネスに関しても一定の理解が必要です。WEBメディアは技術的にシンプルな仕組みに対応してビジネスとしても比較的シンプルで、一気通貫して取り組みやすい領域だと感じ、勉強することにしました。*1

とはいえ、ビジネスとして稼ぐことは目標に入れてはいません。メディア作成に必要なタスクはどれほど存在し、どれほどのコストがかかるのかを経験として知っておきたいと考えています。これらを知ることで非エンジニア領域への理解を深め、自身の協調性を高めることもできるでしょう。

作成方針

  • Glideに完全にのっかって技術的な部分はショートカット*2
  • こだわり過ぎない(Glideだからこだわれない)
  • 画像など素材を自分の足で集めて取材?を経験する(権利確認が面倒)
  • 文章も自分で考え、ライターを経験する
  • GW中に完成させる 「Done is better than perfect」*3
  • GW Advent Calendarに1日1成果を投稿していく

観光用サイトを選んだ理由

  • 壱岐好きだなあとエモい気持ちになった*4
  • 発想力が乏しく、貢献できるアイデアが観光用サイト作成しか浮かばなかった
  • Glideで技術的には簡単そう
  • GWに帰省する
  • 先日てきとーに作ってみたものが既にある

iki-kanko-navi.glideapp.io

最後に

GW Advent Calendar WEBメディア作成10DAYSで1日1成果をリンクで公開します。お付き合いいただけると嬉しいです。

毎日ブログの形で成果を出すつもりはなく、このブログを毎日騒がしく更新することはありません。

*1:WEBメディアを舐めているわけではありません。シンプルが故に競争が激しく、その領域で成功している会社を尊敬しています。

*2:Glideについてはこちらをどうぞ ngmt83.hatenablog.com

*3:ザッカーバーグが言ったかは怪しいらしい http://hagex.hatenadiary.jp/entry/20120208/p5

*4:https://www.makuake.com/project/ikiteck/ こういった記事に影響を受けた

ブログメンティーOB会所感

ポエム

こんな感じでブログメンティー会が開催され、私も参加してきました。簡単にメモとして書き残しておきます。

ブロハラ被害報告は多分ありませんでした(笑)

印象に残った話

  • 記事の粒度・単位が難しい
  • 卒業後も継続する工夫や仕組みが必要*1
  • エンタメ寄りの記事も書いてみたい
  • YouTuberやってみたい
  • トレンドにのらなくてもある程度アクセスがあるのでQiitaのトラフィックはすごい
  • 自分のブログとQiitaとの使い分けは人それぞれ
  • Xの人というブランディングを目指したいが難しい
  • 本を書けばいいんですよ
  • 本を書きましょう
  • こんなイベント(技術書同人誌博覧会)がありますよ
  • カックさんはオブラートに包みながらも耳が痛いことを言ってくれる
  • その分リツイートされるなどガチの評価を受けると非常に嬉しい
  • カックさんの生活リズムはマネはするものじゃない(栄養ドリンクを飲んでも眠い)
  • カックさんが底辺であってたまるか笑*2

私にとっての収穫

  • 仕事関係なく勉強することが当たり前な人と話したことでいい危機感・刺激をもらえた
  • 話題が多岐に渡り興味が尽きなかったため、多様性の重要さを実感できた
  • 当たり前ながら、みんな悩みながらも地道に努力を継続していると再認識できた

所感

「仕事ではX、趣味はYです(どちらも技術)」なんて言う人が集まるととても面白い話ができて最高でした。メンバーがそれぞれ個性的だったのも非常によかったです。ぜひこういうコミュニティで切磋琢磨していきたいです。

また、「あの記事よかったですね！」などみんな褒め上手で、かつ聞き上手で、そしてたまにブログ圧*3を発したり、ブログ圧を過剰に感じたりする*4ところにメンターの教えが根付いていると感じました。個性的で多様なメンティー達を指導し、しっかり影響を与えるカックさんほんとすごい。

雑感

  • お通しのプロテインで乾杯するかと思ったら筋肉エンジニアはすぐに飲み干した笑
  • ブロガーオフ会＠筋肉食堂って文字にするとパワーワードだし、胡散臭すぎる笑

鉄は熱いうちに打つ

やる気をもらったので、早速アドベントカレンダーに登録しました。実家に帰省するGWにしかできないことをやっていきます。

WEBメディア作成10DAYS

技術書執筆は日和りました・・・

*1:write-blog-every-weekやchallenge-every-monthなど

*2:

*3:ブログ書きますよね？的なプレッシャー

*4:無意識にブログ圧をかけているかもしれない

市区町村議員選挙のバグ(構造的欠陥)

ポエム

私は激怒した。私には政治がわからぬ。けれどもバグに対しては、人一倍に敏感であった。

みなさんは投票したでしょうか。投票したらならば候補者を選ぶ際にかなり悩んだのではないでしょうか。今回の選挙は国会議員選挙と比較すると格段にわかりにくく、よく考えるとバグではないか？と思うようなおかしい点が多数ありました。

特に市区町村議員選挙についてあまりに納得いかないので、私が感じた構造的欠陥と所感とを並べます。*1

前提

次の前提を理解の上で読んでいただけると幸いです。

  • 筆者は政治に熱心な関心を寄せているわけではない(人並み)
  • 筆者は特定政党・候補者に肩入れしているわけではない
  • 筆者は恥ずかしながら選挙にさほど詳しくはない
  • 筆者は千葉県流山市で選挙に参加
  • 各市区町村によって事情が異なる

最大の構造的欠陥

最大の欠陥は投票権と候補者数・定員の比率がおかしいことです。

例えば渋谷区は候補者数が55名、定数が34名です。当然ですが区民が持つ票は1人1票です。聞いただけで何かがおかしいと気付くかと思います。

そもそも規模感もレベルも全く異なるのに国会議員や知事らと同じ投票形式なのは異常です。 衆議院選など数名の候補者から1人に投票する場合は、誰かを選び、誰かを選ばない選択ができます。 しかし、市区町村議員選挙では選ばないことが大した意味をなさず、2番目によいと評価する候補者と最も悪いと評価する候補者が全くの平等です。*2

これは、「悪名は無名に勝る」状況を作り出してしまいます。有権者の90%を超える人が反対をするような候補者でも、数%の支持者により当選してしまいます。多様性のある議会になるというメリットもあるかもしれませんが、これでは宗教団体などがバックにつく候補者は簡単に当選します。

「悪名は無名に勝る」を利用している例としては、頻繁に炎上するインフルエンサーがわかりやすいでしょう。個人の活動ではなんら問題ないですが、政治の場にそういった人がいてほしいでしょうか？過激なパフォーマンスをし、敵を作りながらも当選するだけの票を獲得する。そんな選挙・議会は私は見たくありませんし、民意を反映することは難しいように思います。

構造的欠陥については以上です。以降は違和感の殴り書きです。

ここが変だよ市区町村議員選挙

  • 数十名の候補者から1名を選ぶという苦行
  • 選挙を一日程にまとめて世界史上最も複雑な選挙にしている*3
  • 選挙カーが迷惑だが、うるさい人こそが当選しうる状況
  • 「住みやすい街にします、そのために頑張ります」という政策・展望への具体性の欠如
  • アピールする気がない、ITなど全く生かさない
  • 出来レースじみた選挙・穴場自治体

数十名の候補者から1名を選ぶという苦行

大切な1票を誰に投じようか、ちゃんと考えよう・選ぼうとしたため大変な苦行でした。ポスターや自治体が公開するpdfの前の方に掲載されている候補者でいいやと投げやりに決めた人もいるのではないでしょうか？

選挙を一日程にまとめて世界史上最も複雑な選挙にしている

どうしてこうなったのか・・・投票率が低いことを問題と認識していたはずなのになぜわかりにくくするのか全く理解できません。一日程にまとめることで選挙にかかる費用が抑えられるのでしょうか。試算を見たいです。

選挙カーが迷惑だが、うるさい人こそが当選しうる状況

前述した「悪名は無名に勝る」の状況です。しかも選挙カーは一瞬で通り過ぎるため、耳聞こえのいい抽象的なことか挨拶しかできません。情報量としては0です。

個人的な恨みですが、家に小さい子供がいるため、何度となく昼寝を邪魔されて本当に迷惑でした。

「住みやすい街にします、そのために頑張ります」という政策・展望への具体性の欠如

選挙活動期間は選挙カーという騒音で住みにくい街になるという皮肉付きです。

どうやるか・Howこそが大事でしょう。仕事で目標を聞かれた部下が「売り上げをあげるために頑張ります」と言ったらもっと詳細に聞き直しませんか？ 詳細には難しくともどんな背景を持った候補者で、どんな姿勢でどの領域に重点的に取り組むのかくらいは考えておいて欲しいです。

アピールする気がない、ITなど全く生かさない

選挙ポスターに書く情報には限りがあります。自治体が公開するPDFについても同じです。私が候補者ならもっとアピールしたいと考えます。「これをやりたい、あれもやりたい、だから投票してほしい」と思うならHPのリンクくらい載せるのが自然だと思います。HPを見てもらうためにQRコードくらい掲載すべきではないでしょうか。その程度のこともせず、有権者に見てもらえないと嘆いたり、余計に人件費をかけてビラ配りをするのは無駄が多いです。

また、これからの時代ITに理解のある政治家が求められています。HPでアピールすると他の候補者に差をつけられます。Facebookページでもいいでしょう。費用対効果は高いのでぜひやってほしいです。

出来レースじみた選挙、穴場自治体

私が参加した千葉県流山市は定員28名に対し、候補者30名でした。落選する方がよっぽど難しい・・・

投票後に知り、候補者選びにかけた時間を返して欲しいとすら思いました。

しかもそこそこ給料は高い(若者としては)です・・・ 議員報酬 | 流山市議会

当然、市区町村によって異なると思います。しかし流山のような穴場というか出来レースじみた自治体は他にもあるでしょう。

最後に

文句ばかり並べたててしまいましたが、投票した議員さんには特に、当選した議員のみなさんにはぜひ頑張っていただきたいです。

選挙の構造的欠陥については、市区町村ではどうしようもないはずなので、国・国会から改善を進めてもらえる日を夢みることにします。

*1:政治ネタですがポエムとしてブログに綴ります。技術オンリーブログではないので許してください

*2:八方美人ばかりが当選するのも不健全だとは思います

*3:https://www.yomiuri.co.jp/world/20190417-OYT1T50145/

「QRコード完全に理解した」ので要点まとめ

技術

QRコード非常に便利ですよね。しかし、便利かつ適度にブラックボックス化されているがために理解が乏しいまま使っていないでしょうか。 私は先日「QRコード完全に理解した」ので、エンジニアとしてQRコードを使う上で知っておきたいことをまとめました。

表現できる最大容量は？

QRコード - Wikipediaより引用します。

種類 最大容量
数字のみ 7089文字
英数 4296文字
バイナリ 2953バイト
漢字・かな(Shift_JIS) 1817文字

これはQRコードのバージョンを最大の40。誤り訂正レベルを最低のLにした場合です。

バージョンと誤り訂正レベルに関しては後述します。

種類によって異なりますが、基本的にデータは01で表されるため、1文字1バイトの文字と1文字3バイトの文字とでは3倍の文字数の差がでるというだけです。1文字あたりのバイト数節約という点でUTF-8よりもShift_JISの方が文字数を多く含めることができるため、QRコードで表現する際には便利と言えます。

バージョンとは？

バージョン毎にセルの数が決まっており、バージョン1(セル 21 * 21)からバージョン40(セル 177 * 177)まであります。

バージョン≒QRコードの大きさ≒最大容量

くらいの認識でいいでしょう。

誤り訂正レベルとは？

QRコードの情報を100%正しく読み込むことは難しいですが、ある程度誤っていても復元できるよう、QRコードには誤り訂正の仕組みが組み込んであります。表現したい情報とその情報を元に作成した誤り訂正符号をQRコードに含むことで、誤りを検出・訂正します。 *1

手ブレしているスマートフォンでもQRコードをスムーズに読み込めるのは誤り訂正符号のおかげです。*2

そして誤り訂正レベルは復元できる情報量(の割合)を表します。レベルにはL~Sが存在し、7~50%の情報が復元可能です。誤り訂正レベルを高くすればそれだけ多くの誤り訂正符号が必要になるため、容量が小さくなることは覚えておきましょう。

便利なQRコード作成サイト

QRコード(二次元バーコード）作成【無料】

このサイトだけでもとりあえずQRコードを作ったり、試すことが十分に可能です。どの程度の文字数でどれくらいの大きさのQRになるのか、読み取り精度・速度は十分か、誤り訂正レベルはどれが良いか簡単に検証できるでしょう。

QRコード作成| Softel labs

このサイトでは文字コードによるQRコードの変化(密度・大小)を検証できます。試しに平仮名51音をQRにした結果が次の通りです。

f:id:ngmt83:20190419190315p:plainf:id:ngmt83:20190419190259p:plain
UTF-8←→Shift_JIS

UTF-8の方が密度が濃いことがみて取れます。*3平仮名51音の場合においてはShift_JISのほうがバージョンが低く、小さくても多くの情報を表現できることがわかります。

まとめ

  • バージョン(QRの大きさ)と誤り訂正のレベルでQRに格納できる情報量が変動する
  • 文字を格納する場合は種類(文字コードなど)によって文字数が変動する

豆知識

QRコードを開発したのは現在のデンソーウェーブです。特許権を行使しないと宣言しているそうです。素晴らしいです。

今では世界で使用される日本発の誇れる規格ですね！

*1:詳しく知りたければもっともシンプルな誤り訂正符号パリティビットについて調べることをおすすめします

*2:誤り訂正符号は通信時のパケットにも同じように含まれていてなくてはならないものです。

*3:4.2 Alignmentの数がバージョンの目安になります。

f:id:ngmt83:20190419190638p:plain
wikipediaより

https://ja.wikipedia.org/wiki/QR%E3%82%B3%E3%83%BC%E3%83%89より引用

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

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

これから

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

kakakakakku.hatenablog.com

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

最後に

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

*1:https://twitter.com/kakakakakku/status/1105035305071992832

*2:ngmt83.hatenablog.com

*3:ngmt83.hatenablog.com

*4:ngmt83.hatenablog.com

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

技術 Python

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

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

要件・チーム状況

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

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

言語選定

要件より、Dlibというライブラリを利用するため、C++かPythonに限定されました。C++、Python共に熟練者はいませんが、PythonはRubyと類似する点が多く、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の実装例なども近いうちに記事にしたいと思います。