SF(すごくふつう)なブログ

記録・メモ・自己啓発・他

規約重視なフロントエンドフレームワークにはまっている

以下日曜の夜に書いたポエムです。

最近、Ember.jsというRails的なフロントエンドフレームワークにはまっている。(Rails的、ということは設定より規約が重視され、アプリケーションの構造が決められたものになる、ということである)

かなり前から存在しているフレームワークで、英語版WikipediaのEmber.jsの記事によると、2011年の暮れに最初のバージョンがリリースされたようだ。

さらに同じ記事の歴史の項目を見てみると、

History In December 2011, the SproutCore 2.0 framework was renamed to Ember.js, to reduce confusion between the application framework and the widget library of SproutCore 1.0.[59][60] The framework was created by Yehuda Katz, a member of the jQuery, Ruby on Rails and SproutCore core teams. Like many of Katz's other projects, it advocates convention over configuration.

とあり、SproutCoreという前身があってそれがEmber.jsにリネームされたのだという。さらに豆知識で、そのSproutCoreというのはAppleも開発にかかわっていたようだ。

Appleは今もEmber.jsを利用しているようで、Apple Musicのブラウザ版はEmber.jsで作られている。

あと有名どころとしては、NASAのトップページもEmber.jsである。まぁアメリカ/ヨーロッパ圏では色んなところで使われているようだ。

日本で流行っていない

アメリカ/ヨーロッパ圏はそこそこ使われていそうなEmber.jsであるが、私が住む日本ではほぼ聞かない。QiitaのEmber.jsタグも、最近の私の投稿を除けば、2018年が最後である。2年ほど記事が投稿されていなかったということになる。

なぜこれほど流行らなかったのだろうか?

実を言うと弊社が提供しているidobataというサービスではEmber.jsを使っている。だから全く使われていない、ということではない、と思う。ただあまり盛り上がることなくReact/Vueが開発者をかっさらっていった、ということなのだろう。理由になっていないような気がするが、ウェブ技術は水物であり流行ったものが基本的には勝ちである。

ではなぜ今更そんな流行らなそうなフレームワークに興味を持ってしまったのか?

それは私がもっとフロントエンドフレームワークの開発者生産性の部分に焦点を当てたいと思ったからである。

今仕事ではReactNative/Reactをずっと触っているが、なんというか生産性が悪い。確かにエコシステムは巨大だし情報も腐るほど広がっている。ただ、新規(初学者)の人やフロントエンドフレームワークにそれほど熱意がない人が入ってきたときに説明が面倒くさいのである。ReactはViewしか面倒を見ないので、当然Redux/React-Router-Domなどなど色んなライブラリを突っ込んで肥やしていく。それぞれにドキュメントがあり、こういうやり方でやれば良いよね、という思想がある。

それを全部見てもらうというのは当然不可能なので、こちらがかいつまんで説明する。もしくはコードを見様見まねでコピペして使ってもらう。

これで良いんだっけ?と思ってしまったのだ。

よくカスタマイズ出来るということはアプリケーションごとに最適なものを探そうとしてしまう。もちろんNext.jsなどを使えば少し規約が入ると思うので、カスタマイズの幅も狭まるだろう。が、そもそもSSR/SSGなんて必要としてない案件も多い。そんなCDNにファイルを置いて爆速でやる必要がない案件では当然create-react-appでアプリを作ってしまうわけだがそうするとカスタマイズしないといけなくなる。(ちなみにcreate-react-appすら使わずにParcelでやってしまったこともあります、テヘペロ

ほえええ

俺が思う最強のReactアプリの構造を作ったとして、それを誰かにメンテさせるのか。長期的にアプリをメンテしていく状況で、Class/Hookが混在し、テストはEnzyme/React-Testing-Libraryが混じり合った混とんを誰かに任せるのか。(それはちゃんと統一しないのが悪い)

ほえええ

俺たちはどれだけ学び、人に学ばせれば満足するのだ。(ウェブエンジニアは学ぶことを忘れたら死ぬかもしれない)

ほえええ

というわけで、Ember.jsならオールインワンで楽チンだなと思ったわけです。ただ多分これから先も日本で流行ることはないでしょう。でも好きなんだ、このemberコマンドの使い勝手が、アプリケーションの規約が、Handlebarsというテンプレートシステムの柔軟さの塩梅が(Angularのテンプレートは複雑すぎて諦めた)、Octaneコンポーネントの書き味が、日本語の訳をPR出しただけでContributorsに入れて紹介してくれるコミュニティのスモールさが、そしてTomsterとZoeyという謎ハムスターたちが。

f:id:lycaon_mk2:20201109011650p:plain

Ansibleもくもく会 #1 に参加してきました

今週の木曜日(2018/3/1)に、Ansibleユーザー会主催のAnsibleもくもく会(第1回)に参加してきました。

f:id:lycaon_mk2:20180304181037j:plain

もくもく会開始前の会場(顔が映っている方は、スタンプで消しています)

Ansibleは本当に少しだけ触った程度なので、ほぼ知らない状況での参加でした。

タイムテーブルと概要

  • ~ 19:00
    • 会場入場
    • 恵比寿ネオナートビルというとこでの開催でした。恵比寿といえばガーデンプレイスのイメージだったので、少しわくわく。
  • 19:00 ~ 19:12
    • イントロ
    • もくもく会なので、それぞれのペースでやれることをやってくださいという指示。
  • 19:12 ~ 21:05
    • もくもく
    • Redhat JPの社員の方が何人かいて、気軽に質問できる感じでした。また、Slackのチャンネルも用意されており、もくもくする環境としては最高だったと思います。
    • 僕はansible lightbulb(自習用のエクササイズ集)をひたすらやってました。その途中で、サンプルymlコードに問題を見つけたので、PRを出したりしました。
    • 参加者には一人あたり4台のインスタンスが用意されていて、すぐにlightbulbのエクササイズが始められるという状況。ありがたいです。
  • 21:05 ~ 21:30
    • 発表
    • 4人の発表。以下うろ覚えのメモ。
      • 1人目
        • towerインストールした
        • ジョブスケジューラとか過ごそう
      • 2人目
        • towerインストールした
      • 3人目
        • 自分
        • LightbulbにPR出した、以上
      • 4人目
        • ansible towerとcloudformationの違い
        • ansible towerのほうが優秀

感想

発表者の方は大体Ansible Towerを試している方だったので、Ansibleをすでにプロダクションで使っている方が多いのかな~という印象。Towerは確かに便利そうですが、10ノード以上はコストがかかってくるっぽいので、そこは導入できるチームと出来ないチームで評価は違ってくるのかなと思いました。ただ、やはりlightbulbが全編英語で、そこの壁があるかなと少し思いました。Google翻訳使えば大丈夫ですが、個人的にはきっちり日本語訳されたドキュメントが欲しいです。

余談

発表した人 or ブログ発表者には、Ansibleグッズプレゼントいう特典がありました。僕はAnsibleマグボトルをもらったのですが、これが大変便利で役立っています。本当にありがとうございました。

f:id:lycaon_mk2:20180304182830j:plainf:id:lycaon_mk2:20180304182826j:plain

2018年のほにゃらら

今年は上半期がめちゃくそプライベートで忙しいので、多分何かをガッツリはできないと思ってます。

何となく漠然とやってみたいこととしては、

ぐらいでしょうか。多分そんなにガッツリコーディング出来るモチベもないので、勉強会などに参加しつつゾンビ状態で上半期は過ごそうと思っています。

下半期はどうなっているかわからないですが、もしかしたら北陸行きを考える・着手してるかもしれません。

そんなわけで今年もよろしくお願いします。

退職しました

  • そろそろ転職後1ヶ月経ちそう
  • 前職の同僚に催促されていた

ので書きます。次の転職ではおそらく書かないと思います。

2017年11月末まで株式会社ニジボックスで働いていました。2014年6月に入社したので、かれこれ3年半ぐらいいたことになります。 いろいろと思い出しつつ、Q&A形式で書いてみました。質問者は、私の中の内なる批判者だと思ってください。

なぜ転職したの?

3年ちょい経ったから、というのがマジで主な理由です。私的な話なのですが、数年後に妻の実家(そういえば今年結婚しました)に帰ろうと思っています。実家は北陸の方で、当然IT系の会社が非常に少ないです。なので東京にいるうちに別の会社・業界を経験してみたかったというのが大きいです。もちろん他にもいっぱい理由はありますが、一番大きいのは3年経ったから、ですね。

ニジボックスは嫌だった?

基本好きでした。勤怠はエンジニアに優しい感じで(察してください)、休みもしっかりとれます。特に夏休みとかマジすごいです。夏の期間で好きな時に何日か(年によって変わりますが、5日貰える年も)休めます。正直名の知らないIT企業よりは圧倒的に働きやすい環境であると思います。ただ、ニジボックスはその設立経緯から雇用形態が普通の会社とは異なっている(でも実体は普通の会社と違わない)ので、そこを気にする人は辞めておいたほうが良いかもです。詳しくはニジボックスの採用担当にお問い合わせください。

ニジボックスでは本当にいろいろな経験ができたので非常に感謝しています。親会社であるRのとある部署とのつながりが深く、そこで1年ちょい働いたときの経験や学んだことは、今も何度も記憶の中で振り返ったりしています。また会社のメンバーも基本よい人が多いイメージでした。

でも嫌なとこはあったでしょう?

もちろん、会社というのは組織なので、嫌な部分はあります。

  • 独特な雇用形態
  • 営業のパワーが強い
  • 勝どきの交通の便の悪さ

とかでしょうか。営業のパワーが強いのは、営業と仲良く出来るエンジニアにとっては逆に良いポイントかもしれない(かつやっぱり売上は重要)のでそれ自体悪いわけではない故に難しいです。しかし僕は営業さんが基本苦手なタイプなので、若干辛かったです。あと勝どき駅は明らかに鉄道に対して乗客がキャパオーバーしてます。駅を拡張しているようですが、それでも足りるんでしょうか?

またニジボックスで働きたいと思う?

難しい質問ですね。多分僕が独り身であれば全然働きたい、と言うと思います。ですが、今は既婚で、1,2年後には子供も欲しいという話をしています。その状態でまたあの独特な雇用形態に戻るのは少しリスキーかなという感じがしています。そもそも個人的に、実体が普通の会社と変わらないなら、そちらに制度を合わせるべき、という思いも持っています。結局歪みを引き受けるのは労働者側なので。

また将来北陸の方に行くので、どうやって働くのかもあまりイメージがわかないです(今のニジボックスにはリモートワークの制度も北陸支社もない)。そういう点を考えると、基本出戻る可能性は限りなく低いと思います。

最後に言い残したことは?

ニジボックスは、新卒で入った会社を半年で辞めて、その次に「絶対3年は働こう」という思いで入った会社でした。最初はソーシャルゲームの開発・運営などを経験し、その後会社のピボットに合わせて色々な開発を経験しました。時には会社の悪口なども言ったりしましたが、なんやかんやで3年ちょい在籍し、在籍中に結婚もしました。多分これから先、何度も思い返す時間になるのではと思います。良い時間を過ごせたと思います。

これから先はどうするの?

もう転職済みです。東京だけで出来ることをやって、ある程度満足したら北陸に行こうと思います(実はまだ転職先の上司には言ってないんですが><;)。地方でITエンジニアがどう生きていくのか、フルリモートなのか、それとも地場のITベンチャーなのか、わからないですが、どちらに転んでもいいように常に技術を磨き続けていく所存です!

当ブログのコンテンツの引用は自由です。