TheCodestReview #3 - 週刊ソフトウェア・エンジニアリング・ジュース

カミル・フェレンス

成長部門責任者

こんにちは、そしてTheCodestReviewシリーズの第3回をご覧いただきありがとうございます。私たちにとって、とても大切な時間です。

私たちは生きている。 Ruby on Rails今週は、現代的なサッカーに代わる新たな選択肢として、コミュニティで注目を集めているStimulusReflexにスポットを当てることにした。ジャバスクリプト Railsプロジェクトでフレームワークを使いすぎないようにする。さらに、スクラムがうまくいかないときと、プライバシーエンジニアリングのフィンテック Plaid (https://plaid.com/eu/) に基づくプロジェクト

私たちが取り組んでいる側面についての用語集：

Reactは死んだ。StimulusReflex万歳！
スクラムがうまくいかないときは？

3 Plaidに基づくフィンテック製品のプライバシーエンジニアリング

今週のStimulusReflexとScrumのコメントは、Rubyエンジニアとプロジェクトマネージャー

次回は、Vinted.comのReactエンジニアをゲストにお迎えします。Vintedを聞いたことがない方のために（確率は低いですが、それでも可能性はあります）、Vintedはリトアニアのヴィリニュス発祥のファッションマーケットプレイスで、2019年にユニコーンの評価額に達しました。このプラットフォームは、フロントエンド部分のReactに支えられた強固なRuby on Railsの基盤の上に構築されている。

Reactは死んだ by オビー・フェルナンデス

（ユーモア警告）

物議を醸すタイトルでしょう？正直言って、私にとっても同じように衝撃的なタイトルだったので、このスローガンの裏に何があるのか、それとも単なるクリックベイトなのか、読んで確かめたいと思った。私は懐疑的だったが、公正を期すために希望にも満ちていた。誤解しないでほしい。ReactやJavascript全般に問題があるわけではないのですが、「Reactive Rails」を読んだとき、私の想像は狂ってしまいました。私の感情についてはもう十分なので、この記事でジューシーなものを要約しよう。

このユーモアと誇大宣伝に満ちた記事は一見カオスに見えたが、私はこのユーモアのセンスが好きだし、最初の段落が私の希望を膨らませ、さらに私を興奮させたので、試してみた。

Obie Fernandez氏が「Reactive Rails」という名前の背景にあるものを説明します。簡単に説明すると、主にStimulusReflexとViewComponentを使っています。 この2つの強力なツールによって、その開発者はReactはもう必要ないと確信した。彼はそこに「Rails開発者がReactを使う技術的な必要性はもうまったくない」とまで書いています。 鈍感だろう？

もちろん、著者はこのスローガンをそのままにしているわけではない。彼の言葉を証明するために（信じない人がいるなら）、彼はReactive Railsのアプローチを箇条書きにまとめている。また、Vanilla RailsとjQueryを使っていたサイドプロジェクトの一部を書き直すという冒険も紹介してくれています。コードを使って、Reactive Railsのアプローチに従った。彼は、セットアップが比較的簡単で、新しいツールの習得にそれほど時間をかけずとも、すぐに生産的になることを発見した。もちろん、このプロセスで何が起こったかをよりよく理解するために、コード例ですべてがフォローされています。

退屈させないためにも、この記事を読んでほしい。正直なところ、私はこの記事を読んで本当に興奮し、興奮しています。Obie FernandezがReactive Railsを紹介する様子はとても衝撃的で、Rubyコミュニティで何か大きなことが起こっているという希望を与えてくれました。彼はこの記事で私を買いました。私は必ずこの新しいアプローチを探求します。

Codestの推奨 - StimulusReflexは、あなたがRubyを持っているアーリーステージのスタートアップであれば、試してみる価値があるかもしれません。チームそして、フロントエンドの能力不足。あなたのプラットフォームのUIがB2Cユーザー向けで、最初から派手でピカピカにする必要がある場合は、jQueryクラシックコードよりもStimulusReflexを使うことを検討してもよいでしょう。モダンなJSが不足している既存のRailsプロジェクトにモダンなアプリケーションの感触を加えたい場合、StimulusReflexが堅実で時間効率のよい代替案であることがわかるはずです（Railsのバージョンが最新であることが前提です）。既存のプロジェクトに実装するのは比較的簡単なはずです。

なぜあなたのスクラムはうまくいかないのか？

組織による誤った解釈

開発チームによる誤った解釈

ルールは非常にシンプルに見えても、その実行は難しい。チームメンバー全員の努力と関与が必要なのだ。何もしない人を置く余裕はない。スクラムの声明が従業員の信念と一致していれば、プロセス全体は朝飯前だ。人々は喜んで追加責任を引き受け、彼らの協力は非常に効率的になる。しかし、もし彼らの 考え方に共通点はない スクラム・アプローチでは、大変な作業になり、ほとんどの仕事量がScrum Masterの肩にかかることになる。しかし、チームが十分に関与していれば成功する可能性はある。具体的には製品タイプも、スクラムが助けになるどころか、むしろ邪魔になる要因になり得る。これらは主に、ハードウェアのような有形製品に関するプロジェクトである。アジリティとは異なるアプローチを必要とするプロジェクトもある。その理由は、プロジェクトに参加する人々にあるかもしれない。 スクラムは、プロダクトオーナーとScrum Masterの存在を要求する。

こちらもお読みください：アジャイルはなぜ勝てるのか？

でもね：スクラムのキラーディルク・ボルテ

ポッドキャスト「Modern CTO」のエピソード#242は、Plaidのジャン＝ドニ・グレーズ氏によるものです。

プライバシー・エンジニアリングと、製品の最初からセキュリティが組み込まれていることを確認することについての考え。

パンデミックはいかに人々のデジタル体験を加速させたか。

エンジニアリング・チームが成長し、一人ひとりを把握しきれなくなったとき、どのように自分自身をスケールアップさせるか。

いくつかの興味深いテーマの中で、ジーンはフィンテック企業としての経験に基づき、プライバシーとプライバシー・エンジニアリングについて触れている。派生データの問題、適切なデータ削除の慣行、データの匿名化、第三者への転売など。アドテックカルーセルデータのプライバシーに関する企業のユーザーに対する責任とは？フィンテックにとって最善のデータ・プライバシー慣行とは何か？ジャンはまた、GDPRを遵守し、同時にイノベーションを殺さないために、バランスの取れたPPPを作成する過程において、政府や規制当局と民間セクターが協力することの重要性を強調する。