マイペースなRailsおじさん

Ruby、Ruby on Rails、オブジェクト指向設計を主なテーマとして扱います。だんだん大きくなっていくRuby on Rails製プロダクトのメンテナンス性を損なわない方法を考えたり考えなかったりしている人のブログです。

ここ数日のニュース・投稿に一言

↓のような経緯があり、今週のニュースをたくさん読んだ。

かなり数は絞ったが気になるニュースが多くあり、たくさん目を通してしまった。しかし読み返してみたら全然内容を覚えていないことに気付いた。せっかくなので、読んだものに一言ずつコメントをつけてみようと思う。

今後の情報収集の反省にもつながると思うので、構築した情報収集の仕組みについても書いておく。

情報の集め方

feedlyを使って気になるサイトを登録して毎日チェックした。特にインパクトの大きかったものはツイートした。

下記のサイトにあるようにPocketを組み合わせたりということも考えたのだが、feedlyの後で読む機能で十分ではないかと思ったため特に組み合わせてはいない。 Feedly / Pocket /Evernoteを使い、情報ファネルを構築して最小限の時間で最高の情報収集をする方法 | スリーク・トライブ

フィードの選び方

  • 習慣の記事数が100未満
  • カバー範囲が広そうなもの

気になった記事

ここに書くために読み直すということはせず、覚えているままに書いている。

Deno ってなんだっけ? https://qiita.com/kt3k/items/e1647683ad08ff6b6e95?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

Node.jsの次みたいなやつ。Node.jsの作者が、Node.jsの反省を生かして作っているサーバーサイドJSの処理系。Promissが使えたり、node_modulesデカすぎ問題が解決されている。

感想

全然覚えていない。そもそも読んでいる記事の数が多すぎる気がする。反省。今後をお楽しみに。

非同期処理のことを考えていたら頭がバグった

この記事

Rubyで非同期処理しよ～、って思ってちょっと調べ始めた。調べれば調べるほど訳わかんなくなって来てしまい、頭が飽和してきた。もうなんかほんとによくわかんない。今の頭の中のダンプをとっておき、ちょっと頭をリフレッシュしたくなってきた。 という感じでただ吐き出すだけなので、この記事の信憑性は低いです。

Rubyの非同期処理API

Process

プロセスを作れる。つまりfork(2)できる。他の２つと比べるとメモリ使用量、生成コストともに大きい。

コピーオンライトがあるのでメモリをそのままコピーするわけではない。賢い。

Rubyで並列処理（ここでは時間的に厳密に同時に処理を行うことを指す）をするための唯一の方法。

Thread

スレッドを作れる。しかし、タイムアウト、I/O待ちを除いてマルチコアで並列処理ができない。な、なんだってー！というやりとりは、Rubyだとよくある話。Global VM Lock(GVL)という制約があるので、同じコアでしか処理できない。

別スレッドとして動いてはくれるので、同じコアだけど同時に動いてるように見える。並行処理だけど並列処理じゃない。

Fiber

軽量スレッドを作れる。作った軽量スレッドの実行、停止、再開をプログラマが指示する。動かしている間は呼び出し元をブロッキングする。

つまり別スレッドなんだけど、並列処理してくれるわけではないし、自動的に並行処理してくれるわけでもない。

使い分け

Rubyでの計算を高速化したい

Process。

IO待ちの時間を削減したい

Thread, Fiber, あるいはまた別の方法。

Threadは並列処理してくれない。でもIO待ちのときは並列に動ける。てことはIO待ちが発生するようなタスクだったらThreadが有効活用できそうだっていう話。Processでももちろんできるけど、Threadのほうがコストが小さい。Pumaはこれ。

でもよく考えると、Unixにはselectってやつがある。こいつを使うと、IO待ちになっている複数の場所を監視して、使えるようになったやつを選択できる。ということは、IO待ちの時間を有効に使おうと思ったとき、そもそもThreadを使わなくてもいいんじゃないかって話になってくる。

Fiberは、処理を実行途中で停止できるので、あ！IO待ちになりそうだ、Fiber.yieldでぬけよう。って感じのことができる。selectでIO待ちを回避できていることがわかれば、resumeする。これでブロッキングせずに処理を続けられる。selectをしたときに使える口が見つからなかったときは、新しいタスクを開始してあげれば、計算リソースを無駄にせずに済む。

コールバックを使う、というやり方をしてもよい。計算リソースの使われ方はだいたい同じ。IO待ちじゃなくなったときに実行する処理を登録しておく。ただ、コールバックはよくコールバック地獄っていう言葉で揶揄されるようにどうも人類には早すぎるらしい。

あれ、コールバック地獄への有効打って他にもないっけ

なんかこのへんでほんとに訳わかんなくなってきてしまった。よく理解していない知識を頭の中にとどめておくのって良くないですね。

EventMachine

というgemがある。このひと全く知らないのだけど、jsのコールバック付きの関数群みたいな関数群みたいなやつを提供してくれるやつっぽい。

Observerパターン

このタスクが終わったらこれやっといてね、っていうのを登録してくやつ。 これの実行タスクとして非同期処理を登録してやると、あとの後続処理をオブザーバーにかけるので、コールバック使わなくて済むのではなかったか。

EventMachineとObserverパターン組み合わせれば最強じゃね？みたいなことを思った。それがすべての元凶。

Future

ScalaのFuture。JSでいうPromise。非同期で処理して、後続処理を登録できる。 あれ、Observerパターンと似てる。Scalaでは登録された動作に対してスレッドを作る。作った瞬間勝手にどこかで処理されている、みたいな感じ。

2つのWebAPIからのデータを取得してまとめる、みたいなことをしようとしたとするじゃないですか。そうすると、外部との通信のコストを考えると非同期でやりたいなーと思うわけですね。

thread_a = Thread.new { api_a_call }
thread_b = Thread.new { api_b_call }
pp "I got #{thread_a.value} #{thread_b.value}"

こんな。なんかこれがダサいと思ったんですね。 APIは実際はこんな関数を入れます。時間が止まればいいです。

def api_a_call
  sleep 10
  'answer_from_api_a'
end

def api_b_call
  sleep 10
  'answer_from_api_b'
end

２つのAPIを並列に取得してあげると、10秒で帰ってきてくれるはずです。しかし、これってthread_a.valueがthread_bの定義よりも先にきてはいけないんですね。いけないというか、意図しない待ち方をして、２０秒かかってしまうんです。

ここで、Futureを使ったらこんな書き方ができるんですね。

Future.new { api_a_call }
      .zip { Future.new { api_b_call } }
      .onComplete { |a, b| pp "I got #{a} and #{b}" }

わあかっこいい！素敵！ いやでもこれFutureってどうやって実装するんだろう難しいなー。みたいなことを考えていました。

ReactiveExtentions

これってScalaのFutureの強い版ではなかったっけ。なんかAPI仕様がてんこ盛りで過ごそう。Futureとどう違うの君は。

だめだ、あたまがバグってきた

Fiber使わなくても、JSみたいなコールバッグを扱うAPIがあって、それを地獄に堕ちずに使える方法があるならそっちのほうがいいのでは。というようなことを思ったのです。

そうしたら、心当たりがあったのだけど、中途半端な知識しかなくて調べれば調べるほどわけわからなくなってきた。 ちょっと整理したいけど、溜め込みすぎたので一旦脳を休めたい。

SOLID, KISS, YAGNIをどう活かすのか

オブジェクト指向設計 デザインパターン

SOLID, KISS, YAGNIはいずれもソフトウェア開発において重要とされる原則です。原則というくらいなので、様々な形態を持つソフトウェア開発において共通して適用することができます。逆に言えば、特定のコンテキストに依存しない程度に抽象化されていると言えるのではないでしょうか。

私はこれらの原則を聞いたことはあるのですが、「わかるわ～」程度の刺さり方しかしませんでした。重要であるけれどいまいち具体的な対処がわからないこれら原則について、今一度おさらいします。

SOLID

オブジェクト指向を用いた開発で、メンテナンスが容易なプログラムを作るための5つの原則の総称。

最高にわかりやすい記事を見つけたので、私が説明をすることはDRYの原則に反します。 postd.cc

単一責任の原則の説明に、まさにActiveRecordのインターフェースを持ったクラスが良くない例として載っています。そうでした。Railsを使っているのですっかり忘れていましたが、本来ActiveRecordはたくさんの責務を持っているのでした。

自分なりの理解

  • 単一責任の原則: 一つのクラスが一つのことに関する知識を持つように設計する。
  • 開放閉鎖の原則: クラスを追加、拡張しようとしたとき、他のクラスもつられて修正しなくてもいいようにする。
  • リスコフの置換原則: サブクラスに依存した実装が存在しないようにする
  • インタフェース分離の原則: すべての実装クラスで必要なものだけをインターフェースにまとめる。必要なら細分化する。
  • 依存性逆転の原則: 実装でなくインターフェースに依存させる。実装クラスは引数として外から渡す。

SOLIDすべてを満たして設計～実装するのは、慣れていないとなかなかに骨の折れることのように思います。作るときの労力で言えば、新しくクラスを作るよりも、if文を追加してしまったほうがはるかに少ない、というケースが現実にはよくあるからです。

それでも、「ここはこの原則に反しているけど、適用するほど変更が加わりそうな場所でもない」とか、「この原則にしたがって設計したからこのインターフェースになっているんだな」といったことを考えることは、よりよい設計を目指す上で役に立ちそうです。

GoFのデザインパターンを思い出してみると、これらの原則に忠実に設計する方法について述べられていたんだなあと気づきました。これらの原則を意識しつつGoFのデザインパターンをおさらいすると、定着させることができるかもしれません。

KISS

"Keep it simple, stupid" の略。「シンプルにしておけバカ」という意味。

これを最初に聞いたとき、「お、おう。そうだよね。」くらいにしか思いませんでした。

ソフトウェア開発への適用についての詳しい記事を見つけたので、時間があるときに少しずつ読んでいこう。 thevaluable.dev

ソフトウェアは、すぐに複雑になりがちです。複雑なソフトウェアというのは何かというと、たくさんの要素によって構成されていたり、たくさんの要素とつながっているソフトウェアです。シンプルというのはその反対です。

ソフトウェアは、変更によってどんどん複雑になっていきます。このため、KISSの原則を一貫して徹底する、ということがソフトウェアのメンテナンスをかんたんにするという面で重要になってきます。

ソースコードをシンプルに保つ、というのは種々の技術によって実現できるでしょう。でも、システムをシンプルに保つのにはまた別の力が必要です。

とりあえず、KISSは本当に奥が深い、ということがわかったところでよしとしておきます。

YAGNI

"You ain't gonna need it"の略。「そりゃ必要にならんよ」てな意味。XPに関する格言で、必要になるまで実装するなという意味。 http://ja.wikipedia.org/wiki/YAGNI

これはめっちゃわかるし、必要のない機能を付け加えたくなる気持ちもめっちゃわかる。そういうコードの末路も見てきた。いらないコードは書かない、単純なことだけど気をつけていないと忘れがち。

References

下記の素晴らしい記事を参考にしました。

developer-roadmapを見ながら足りない知識を洗い出す

エンジニアになって2年半、ここのところ勉強したいことが多すぎてどれからやろうか、と考えてしまう時間が増えてきました。WebDveloper Roadmapに載っているものから優先して取り組んで行こうと思ったので記録しておきます。私のスキルの振り返りなので、他の方の参考になることは少ないと思います。

github.com Web Developer Roadmapは、Web開発者になるために必要な知識とアクションを順序付き表現した図です。 tajawal UAEでリードエンジニアを務める@kamranahmedse(https://twitter.com/kamranahmedse)さんによって作られました。

内容についてはこちらが参考になります。 Web Developer Roadmap 2018が2019年版になっていたので比較してみる - Qiita

自分の開発経験をおさらい

大学~大学院: C, JavaでアルゴリズムとUNIXシステム操作を学んだ。RaspberryPi+Railsで動画転送システムを作った。 社会人一年目: とある大規模システムのテスト設計やリリース戦略の設計をした 社会人二年目: JavaでWebシステムの裏で動くバッチを書いていた。 社会人三年目: RailsでWeb開発

あまりコードをゴリゴリ書くような開発の経験は少ないことに気づきました。Web開発っぽいことをし始めたのも最近です。ただ、使っている知識や技術はあまり変わっていません。

スキルの抜け

Introduction, Frontend Roadmap, Backend Roadmap, Devops Roadmapの4つのロードマップがあります。今回は、IntroductionとBackend Roadmapに記載のあるスキルのうち、自分が持っていないものをそれぞれ見ていきます。内容について概要を説明できて調べながら実践できそうなものを抜けていないことにして、実装経験がなくても良しとします。

Introduction

  • SOLID, KISS, YAGNI 聞いたことあるけど、内容が全く思い出せない。メンテしやすいコードを書くための心構えだったような。自然にやってる気もする。
  • Semantic Versioning 初耳。 記載のあるスキル11中2個抜けていた。

Backend Roadmap

こちらはアクションが主ですね。

  • Standards and Best Practices 今メインで使っているRubyは抜けてる。
  • Make and Distribute Some Package/Library 作ろ！ってなる状況にならなかったな～
  • Learn a NoSQL Database mongoDB使ったことはあるけど、いつ使い分けるの？とかわからん。
  • Caching キャッシュ実装することになったら、どうすればいいかわからん。
  • Creating RESTful APIs RESTはできるけどRESTfulはむずそう。
  • Authentication/Authorization Methodologies Oauthとベーシック認証くらいしかわからない
    • Token Authentication
    • JWT
    • OpenID
  • Message Brokers 何ができるかわからない
    • RabbitMQ
    • Kafka
  • Learn a Search Engine つかってみたい
  • Learn how to use Web Sockets だいたいの仕組みはしってるけど、これを使う実装できないです。
  • Look into Graph Databases なんですかそれは。
  • All things that weren't mentioned above ここが埋まることは一生ないだろう。DDD、SOAPは知ってるので、基礎を固める前にジャンプしちゃってた感。

24個のステップのうち、11個スキップしていた。

抜けまとめ

Introduction 2/11 Backend Roadmap 11/24

これからどうする？

今やりたいことが、非同期処理について学んだりとか、Railsへのコントリビュートとか、とかだったんだけど、その前に勉強しておいたほうがいいことが多そうだ。 Webエンジニアとして働いて行くために、何を学んだらいいかっていう観点が一貫していて、すごくいいロードマップでした。どうしてもプログラミング言語とか、フレームワークに対して興味が行きがちになってしまうけど、Webシステム全体を見た上で知識をつけていくほうが、Webエンジニアとしてはよさそう。

"Ask Me Anything" by DHH での質問と答え part2

ここにいる全員にあなたのようにStimulusとturbolinksを使うことを薦めますか？

まず第一に、ブログ、カンファレンスあるいはtwitterで人気のあるものと、実際に作られているアプリケーションで人気のあるものには違いがあります。 私は、それらの間には大きな違いがあるということに気が付きました。 今のところのブログ、カンファレンス、Twitterで人気のあるものは、react.jsやvue.jsあるいは他のツールを使ってたくさんのJavaScriptを記述するものです。 これらは、私には人気があるわけではなくとても誇張されているようにみえるのです。

私はそういったことの見極めについておそらくエキスパートです。 なぜなら、かつてRubyとRailsの利用についてまた誇張されていたからです。 2000年台中期に、RubyとRailsが人気になったとき、みんながそれについて語っていました。 しかし、実際に書いていたのは一部の人々だけです。

たくさんの人と話をしてみて、turbolinksやstimulusや少ないJavaScriptのアプローチが好きな人がたくさんいるということに気がついたんです。 そういった人々はあまり声を大にして主張しません。 皆さんは彼らの主張を、重厚なJavaScriptフレームワークを使っている人たち程は聞かないでしょう。 ときどき人々は、声を大にして主張されているものが人気のあるものだと誤解してしまいます。 もう一つ言いたいことは、ほとんどのアプリケーションはturbolinksやstimulusのみを使ってシンプルにスタートし、必要性が高まったとき、より洗練された、あるいは複雑なフレームワークに移行したほうがいいということです。

たくさんのアプリケーションがごく僅かなフォームを扱うだけであっても、とても洗練されていて複雑なJavaScriptを備えてスタートしてしまっていることは残念に思います。 ほとんどのアプリケーションの基本的な要求は、10年前と変わっていません。すなわちデータベースを扱うCRUDアプリケーションを作ることです。 そう言うと、それは良くない、もっと洗練されたアプリケーションを作ろうという野望を持つべきだと考える人がいます。 私はそれはくだらないことだと思います。

我々が今日作っているような情報技術における大多数は、良い方法に向かっているとは言えません。 なぜなら、我々は良くしているのではなく、たくさんのアプリケーションにJavaScriptフレームワークを導入するなどの理由で複雑にしてしまっているからです。 多くのアプリケーションは、よりシンプルな方法で開発することで少数の開発者でのデリバリーを高速化した場合などは、良くなったと言っていいでしょう。

BaseCampでの経験で言えば、我々が作ったすべての要素の中で極稀にそういった種類のフレームワークを必要とします。 BaseCampはどちらかといえば、react.js, vue.jsのようなフロントエンドフレームワークを使いサーバがJSONだけを返すようなスタイルが完璧にはフィットしない大規模アプリケーションの典型です。 私は、そのようなスタイルがフィットするアプリケーションは人々が思っているよりも一般的でないと考えています。

あなたはajaxやcoffee scriptを広めました。それって過ちだったのでは？

そうですね。私の失敗です。

それは当初からの計画でしたか？（この辺質問よくわからない）

もっと簡単にしようという思いがありました。 そして、多くのWebアプリケーション、ほとんどのWebアプリケーションは、JavaScriptを使うことで改善できるということに気づきました。もしJavaScriptを全く使えないなら、アプリケーションは良くないものになってしまいます。ただ、どれくらい多く使うかについては選択の余地があります。私はJavaScriptは少量のふりかけとして使うなら、うまく作用すると思います。少しの塩が（料理の）うえに乗っているだけなら風味を与えてくれますが、もしお皿が塩でいっぱいになってしまったら美味しくありません。これは現実にいつも起こっていることです。

人々は、新しいアイディアや進歩を手にしたとき、そのアイディアでどこまでもやって行きたいと思ってしまいます。だってこんなに素晴らしいアイディアなんだから、もしこれをすべてのことに使ったらどうだろうかと考えてしまうのです。そして、すべてのことに使おうと試行錯誤したあとで、悪いアイディアだったということに気づくのです。

今朝、yamlと、yamlがXMLと同じ轍を踏んで悪いプログラミング言語として使い始めてしまうかについての記事を読みました。 初めは設定ファイルとして使いますが、次第に条件分岐や変数をはじめプログラミング言語で使える要素を使おうとし、それにもかかわらず設定ファイルとして扱おうとしてしまうために巨大な化け物に変貌してしまうのです。 これは、一度良いと思ったものを使い始めてしまうときの状態とすこし似ています。

良いものは、限られた範囲での特定の運用ではうまくいきます。しかし、詰め込みすぎてしまうと途端に破綻します。

RubyとRailsについても、同じようなことが言えます。 これは最高だ！と思うと、適していないことであっても全て同じものを使ってしまうのです。 もともと考えられていたよりも、Rubyとrailsの適用範囲は広がっているように思います。 一部はアーキテクチャの優先事項の問題です。

必ずしもいつも正しい方法があるとは考えないほうが良いでしょう。 Webの美しさは、バックエンドでどんなプログラミング言語でも利用できる多様性にあるのです。 私がWebアプリケーションをRubyで書く一方で、他の人はPythonで、また他の人はGoでもJavaでも書くことができて、その上ユーザーはそんなことを気にしないのです。これはwebの固有かつとても特別な特徴です。ほとんどのソフトウェア開発プラットフォームは、特定の開発環境に大きく依存します。iosのアプリを作りたいならばswiftを使わなければならないし、 Androidのアプリを作ろうと思ったらJava を勉強しなければなりません。Web ならそんなことは気にしません。C でもBASICでも、HTMLを生成できる言語なら何でも使うことができます。だから、どれぐらいのJavaScript が使われていればいいのかっていうことだってユーザーは気にしません。シンプルに作ろうが複雑に作ろうが素早く作ろうがユーザは気にしません。Web の素晴らしいところはそういった多様性を許容できるところです。他の開発プラットフォームと違って、人が違えばアイディアも違います。そういったところが Web の本当に美しいところだったと考えています。

"Ask Me Anything" by DHH での質問と答え part1

www.youtube.com

これの質疑応答を日本語にしようとしましたが、ボリュームがすごくて全然ゴールが見えません。多分part5くらいまで行きます。

多分50%くらいは間違ってるんだと思います！ 編集リクエスト、指摘、訂正お待ちしてます！！

誰か同じようなもの作ってないかなーとビビりつつ書いてます。 Youtubeの自動文字起こしを参考に書いてます。 日本語字幕つけたかったけど、あれって動画投稿者からのリクエストが必要なんですな～。

Railsdm運営の皆さん、素晴らしい動画を短期間で公開してくださり大変助かっています。本当にありがとうございます！

質問と答え

あなたは今どこにいて、そこは今何時ですか？

カリフォルニア州のマリブにいて、夕方のちょうど6時半です。

簡単に自己紹介をお願いします

私の名前はデイヴィッド・ハイネマイヤー・ハンソンです。Railsの作者で、2003年からRubyで仕事をしておりRailsにも同じ時期から取り組んでいます。Basecamp社の共同創業者で共同出資者で共同経営者です。

Basecampはrailsアプリケーションの起源です。 私はrailsをBasecampの外に持ち出して2004年にリリースし、それ以来ずっとrailsに取り組んできました。

私はRubyの大ファンです。Rubyは私をプログラマーになりたいと思わせ、またプログラマーであり続けたいと感じさせてくれるプログラミング言語です。長い年数経っても未だにRubyでプログラミングをし、楽しめていることをとても誇らしく思います。

2006年のRubyKaigiにRubyプログラマーとして来日したときの思い出を教えてください

とてもよいカンファレンスだったと記憶しています。 日本のRubyカンファレンスに行ったのはその時が初めてで、何に期待すればいいのかもよくわかりませんでしたが、ただただ素晴らしかったです。 とてもたくさんの幸せそうなプログラマーたちがいた事を思い出します。彼らのことを私は知らないのに、彼らはrailsを使っていたんです。 私はときどきオープンソースの開発者として、間違いなく自分のためにrailsをプログラミングしていると思います。私はただ家で座ってrailsを作っていて、私が作ったものを使っているプログラマーが何千人もいることなんて本当に気づいていないんです。 みなさんも、自分が作ったものを知らない誰かが仕事で使っていて、最終的にカンファレンスでそういう人たちに個人的に会ったときはちょっとした衝撃ですよね。信じられないことです。

私は日本でのRubyカンファレンスに行ってからだいぶ時間が経っていると言いましたが、実はプログラミングではなくてレーシングで日本にはほぼ毎年行っています。 だから、東京には10月にしばしば行って、富士スピードウェイでレースをしています。 私はRubyで仕事をし始める前から日本と日本の文化の大ファンなので、ほぼ毎年行けていることが嬉しいです。 いつかRubyKaigiに戻ってきます

一日の中でどれくらいRubyを書いていますか？

週によりますね。 本当に良い週は、ほとんどの時間をRubyを書いて過ごします。 あまり良くない週は、ほとんどプログラミングをしません。 大抵はひどく悪い週です。

少なくとも多くの時間をRubyを書くのに費やす機会を得たときは最高に良い週です。 BaseCampで新しいプロジェクトを動かしているときには、Rubyコードを書くたくさんの機会がありますし、Railsのために働くことにもなります。 Railsの新しいバージョン6のフレームワークであるaction textとaction mailboxは、新しいプロジェクトの成果から展開したものです。

そういった理由で、私は新しいプロジェクトで働くのが大好きです。 私はまっさらな状態からrailsアプリケーションを構築する機会を得ると、新しいアプリケーションで使うときどのようになるか見ます。過去のアプリケーションから新しいアプリケーションで再利用したいアイディアを展開して、railsがもっとできることを探します。 それがたくさんのRubyコードを書くきっかけになります。そういうときはいつもいい日ですね。

実際のところ、JavaScriptは自分で書いていますか？

かなり書いています。 私はここ何年かで、JavaScriptを書くことに前向きになりました。 私が2005年から2006年にJavaScriptを書かなければならなかったとき、たぶん私はあまりハッピーではありませんでした。 JavaScriptはかなり良くなったと思います。 私はJacvaScriptフレームワークの大ファンというわけではありませんが、モダンなツールや私の大好きなJavaScriptのエコシステムは言語自体態を良くしていっています。

Basecampでは、最近自分たちのためのJavaScriptフレームワークを作りました。 とてもミニマルなフレームワークで、Stimulusと呼んでいます。 だいたい2年位前だったと思いますが、クリスマス中座り込んで、我々がBaseCampで書いてきたすべてのJavaScriptコードをみて、どのようにするのか、いくつかの意味と順序を見つけようとしました。

Basecampでは、JavaScriptを書いていますが、モダンJavaScriptと呼ばれるようなものではありません。react.jsやvue.js、それらに類するフロントエンドのフレームワークを使いません。 我々はturbolinksをすべての基本として、たくさんのsprinkleを使い、それらを呼び出すのを好みます。すべてのHTMLで、殆どの場合はサーバーサイドでレンダリングされ、クライアントに送られると、少しの動的な魔法をふりかけます。

最近では、Stimulusを使ってそれらのsprinkleをカプセル化します。 これは、私がJavaScriptを書くのが好きではないということではありません。ただ、ほとんどのアプリケーションが最近他の界隈で考えられているほど大量のJavaScriptを必要としているとは思わないということです。もし、もう少し少ないJavaScriptともう少し多くのRubyで書けるなら、多くのアプリケーションはもっと速く、もっと弾力がある状態で、かつプログラマーがハッピーに作ることができるはずです。

勉強会レポート UIT#6 進化する React.js

UIT#6

フロントエンド開発の勉強会。LINE株式会社が運営していて、1クォーターに1回のペースで開催している。

  • テーマ: 進化する React.js
  • 場所: LINE本社 カフェテラス（新宿ミライナタワー23階）
  • 参加費: 0円
  • 参加人数: 100人
  • 参加方法: connpassで抽選

https://uit.connpass.com/event/119594/

Hooks で作る React.FC

Takepepe / DeNA/デザイン本部・デザインエンジニアリンググループ

https://speakerdeck.com/takefumiyoshii/hooks-tezuo-ru-react-dot-fc

Hooksというreactの新機能を使ってアニメーションを実装できますよという話。 従来はFunction Componentに実装しなければ行けなくて、それが結構辛かったけど、Hooksならもう少しきれいに書けるみたい。 そもそもなんでアニメーションにそこまでこだわって実装するの？に対して深い考察がされていた。要は、コンテキストによってアニメーションが重要となる場合があり、場所を見極めて適切に使うことで機能価値を高められるかもしれませんよ、という話だった。詳細はスライドを見てくださいぜひ。

Page Stack again in React

sunderls / LINE株式会社 - フィナンシャル開発室

https://speakerdeck.com/sunderls/pagestack-in-react-again

  • ユーザーはweb（ブラウザ）よりnative(アプリ)を好む傾向にある
    • そもそもサービス提供者側がアプリ推し
    • とはいえ起動速度、新規ページのロード速度はあまり変わらない
    • ページ繊維時のサクサク感、特に前画面への戻りは圧倒的にnativeのほうが良い
  • nativeのサクサク感をwebに取り入れるために、Page Stackを開発した
    • 表示したのページのDOMをページごとに記録するスタックを持つReactComponentを作った
    • 戻るときはスタックから取り出すのでサクサク！
    • 画面遷移が多いとスタックが多くなりすぎて重たくなってしまうので、アプリの性質によって使えたり使えなかったりする
    • スタックのサイズは設定できる

native > webの構図に対して一石投じたい！という取り組みでした。どうしてそんな構図になってるか？に対する考察が大変興味深かったです。 nativeとwebでページロードがそんなに変わらないっていうのが、動画で比較されててめちゃくちゃわかりやすかったです。

現場から届けるReactの悩みと改善

sakito / ヤフー株式会社 https://speakerdeck.com/mukai21/xian-chang-karajie-kerureactpuroziekutofalsenao-mitogai-shan

開発していく中で、UIまわりのコードが複雑になりすぎて開発スピードが落ちてきていたので、いろいろ技術を導入して解決しようと奮闘した話。 - TypeScript - Emotion - Formik - Re-ducks - Immer

アプリに対して適切な技術を取り入れて改善していくの、かなり大変だと思うけど、どんどんやっていけるのはsakitoさんのパワーかなと思った。すごい。 導入する前の準備を他のエンジニアを巻き込んで丁寧にやっていたみたいなので、そのへんの根回しというか技術からちょっと外れてるけどすごく大事なノウハウを聞けたのすごく良かった。もうすこし踏み込んで話し聞ければよかったな（質問すればよかった）

所感

どの発表も、なぜそれをやるのか、どんな価値があるのかというところを丁寧に説明していたのが印象的だった。UIに対してどんな貢献があるのか、UIが変わるとユーザーがどう嬉しいのかという点について発表者の考察が聞けたのでわかりやすかった。今回はreact.jsが副題に入ってはいるが、そこまでreact.jsに特化した話でもなかった（ように聞けるプレゼンだった）。

懇親会への参加は20名程度。ピザとかオードブルがたくさん出てきてとても豪華でした。

potato4dさんが司会なさってました。司会上手でした。すごい。