Rails6.0リリースまでの予定
weblog.rubyonrails.org の非公式な日本語訳です。
Timeline for the release of Rails 6.0 Posted by dhh, December 20, 2018 @ 12:00 am in News
Rails6.0に向けて、我々がリリースまでの「楽観的な」予定を公開するのに十分な進捗がありました。リリースよりも「楽観的な」がキーワードです 😄。ソフトウェアが予定通りに公開されるのはまれで、今までたくさんの予定通りに行かなかった野心的なリリース予定日がありました。とはいえ、楽観主義がオープンソースの面白いところとして許容されなければ、我々はどうすればいいでしょう？
というわけで、これが我々が現在それぞれのバージョンについての予定です。
- 1月15日: Beta 1
- Action MailboxとAction Textという2つの新しいフレームワークをマージする予定です。
- 2月1日: Beta2
- 他にも大きな改善が含まれる予定です。
- 3月1日: リリース候補版1
- 新機能はここまでで出揃います。
- 4月1日: リリース候補版2
- ほぼリリース直前の状態です。バグ修正だけを行います。
- 4月30日: 最終リリース
- RailsConf 2019で、Rails6.0のリリースを祝いましょう！
こうやって並べてみると、すてきできれいに見えますよね？真面目なエンジニアがこれを理解するのに真面目にエンジニアリングをしたように。夢と希望を描いたソフトウェア作家も少なくありません。しかしながら、これが私達がやってきたエンジニアリングの部分なのです。
（訳注：ここぜんぜんわかりませんでした。） 原文：It always looks so nice and neat when laid out like that, right? Like some serious engineers did some serious engineering to figure this out. And not just a bunch of software writers plotting down their hopes and dreams. But yeah, it’s really the engineering part we went for (no it wasn’t).
Rails 6.0にはRuby 2.5が必要です！このバージョンを実行できることを確認して準備できます。また、Rails 6.0のリリースのあとは、 Rails Coreチームによるメジャー、マイナー両方のセキュリティ修正を受けられることが保証されているとはRails 6.x.yとRails5.2.xのみであることに注意してください。（いつものことですが、我々はもっと前のバージョンにも修正版を提供する選択をするかもしれませんが、保証はありません。）
いつものように、もしあなたが新規アプリや既存のアプリをrailsリポジトリのマスターブランチのrailsで動かすという大冒険の遺伝子に突き動かされるなら、（または、バグを踏んでも解雇される恐れがないのなら）、この方針を実現するのを手助けしてください。Basecamp 3はすでに本番環境でrails/masterを可動させているので、このメインブランチはすくなくともとてもよく作業されていということです！
Rails6.0のリリースマネージャは、Kasper Timm Hansenの支援のもと、Rafael Françaとなるでしょう。🙏
To Rails Six Oh And Beyond! 🚀🚂
Ruby on Rails 6.0 beta2がリリースされました
リリースされました
このベータ第2版のリリースで、Rails6の最終リリースに向けて、また一歩近づきました。我々は、多くの問題を修正し、いくつかのマイナーな機能の追加を行いましたが、大きな変更としては、オートロードの処理をXavierの新しいWeirwerkライブラリに切り替えたことです。これは我々が実行時に依存を要求する方法の大きく、また構造的な変更です。この変更はレガシーな見苦しい機能やおかしな挙動を取り除くはずです。Xavierさんは、あなたが確認するに値する大きな変更を加えました。
それ以外の点は、Beta第1版とほとんど同じです。リリースノートを読んで、6.0の全体像を理解することをおすすめします。
beta 1.0以降追加された532のコミットをより深く確認することもできます。
6.0の最終版について公開したスケジュールに向けて今の所順調に進んでいるので、あなたのアプリケーションの移行計画はその計画を参考にしてください。とはいえ、どうかbeta 2をあなたのアプリケーションでテストして我々を援助してください。中レベル程度のRailsの経験を方なら誰でも、Rails 5.2.xシリーズよりもむしろbeta 2を使って新規のアプリケーションを作ることをおすすめします。BasecampとShopifyはすでにRails 6.0.0 beta2を実稼働させています。
このリリースとRails 6.0最終版までの全てのリリースは、Kasper Timm Hansenの支援のもと、リリースマネージャーであるRafael Françaによって手動されています。
Railsの改善に向けて貢献し続けてくださる全ての方々に、重ねてお礼申し上げます。
とのことです。
Masonry Layoutを使いたい
masonry layout
pinterestみたいなレイアウトを、Masonry(石積み) Layoutと言うらしい。
デモ
こんな特性のものをmasonryと呼んでる気がします。
- サイズの違う要素を並べられる
- 表示領域のサイズが変わると並べ直す（これがおしゃれ）
二番目は副産物で、masonryのことではないかも？
使いたい
masonryが実装できて、SSR(next.js)対応で、速くて、コンポーネントライブラリを使いたい。
初めてコンポーネントを探した。 まずやりたいことがmasonryだってわかるまでが長かった。 わかってしまえば、githubで「masonry component」とおもむろに調べる。
でてきた。
Masonryにしたいところを
しかし初期表示とウィンドウサイズを変えたときの動きが結構もたつく。
この記事の筆者はIsotope · Filter & sort magical layoutsというJSライブラリで、どうして遅いか調べたそうだ。
だいたいこんなかんじ
- フレキシブルにするための機能が重い
- 様々なサイズの画像に対応している
- サイズ変更の再描画に時間がかかる
- 数百の要素のサイズを取得取得しなければいけない
- 見えていないところの画像も再描画している
ので、
- ページが大きくなるにつれて指数関数的に計算が増える。
のだそうです。
で、固定サイズの画像にだけ対応するなど機能を絞ってレイアウトエンジンを実装するくらいしか解決策がないと。
そもそも本当にMasonryにしないと行けないのかっていうのはちゃんと考えたほうが良さそうですね。
DDDの浅いまとめ
ドメイン駆動設計（DDD）が何なのかわかるまで時間がかかったので、あまり踏み込まずにまとめます。
DDDはわかりにくいか
エリック・エヴァンスのDDD本が示しているのは、一つの大きなパターン・ランゲージである。パターン・ランゲージとは複数のソフトウェアパターンを組み合わせたもののことで、それを構成している各パターンには結び付きがある。
ドメイン駆動設計とは
ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする[1]。この名称は、 Eric Evans が同名の著作で用いた[2]。
考え方
ソフトウェアを、そのソフトウェアが解決したい問題領域（ドメイン）とその他（永続化機構、ユーザインターフェースなどなど）に分けて考える。 ソフトウェアの価値や保守性の向上するためには、ドメインモデリング（ドメインを分析してソフトウェアのモデルにする）を頑張るといい。
とはいっても
- ドメインに詳しい人（ドメインエキスパート）と言葉が通じません
- ソフトウェアの規模が大きくなりすぎてそれどころじゃない
- ドメインモデルをちゃんと作るためのアーキテクチャほしい
- 複雑なドメインロジックだとモデリングするの難しいっす
戦略的モデリング（Strategic Modeling）
ざっくりいうと組織とかその編成の工夫。
戦術的モデリング（Technical Modeling)
設計について勉強し始めました
私は毎月イテレーションしながら開発しているプロジェクトに参加しています。 メンバーはSIerでSEとして経験を積んできた人が大半を占めています。 明確に設計を行う期間は設けておらず、設計書も作りません。 しかし、コードレビューを受けると、設計が悪い、外部設計を行っていない、基本設計ができていないといった指摘をもらいます。 私はWFでの開発経験が無いので、正直何を言っているかわかりません。 要は、専門用語の壁に阻まれコミュニケーションが取れていない状態です。
という問題を抱えていたので、設計について勉強し始めました。
はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)
- 作者: 吉原庄三郎
- 出版社/メーカー: 翔泳社
- 発売日: 2008/12/11
- メディア: 単行本（ソフトカバー）
- 購入: 17人 クリック: 193回
- この商品を含むブログ (26件) を見る
まだ読んでいる途中ですが、外部設計と内部設計について気になったところをメモします。
外部設計と内部設計
- 外部設計≒基本設計、機能設計、概要設計
- 入力と出力を決める
- ユーザーの振る舞い、外部システムとのメッセージング方法を決める
- 顧客との合意を反映する
- 内部設計≒詳細設計、プログラム設計
- 入力から出力の実現方法を決定する
所感
私が今やっている仕事は実装だと思っていたのですが、実際は要件定義、設計、実装、移行まででした。 決めなければいけないことがバッサリすっぽ抜けいていたのです。 レビューのときにいろいろと指摘が入っていたのはまさに要件定義と外部設計を行っていなかったからでした。 アジャイルな現場においては、要件定義と設計についてもチーム内で議論を進めながらコードを書いていくことになります。私がうまく行っていなかったのは、「合意の上で決めないといけないこと」が何なのかわかっていなかったからでした。
アジャイルな現場にいながらウォーターフォールの設計手法を学ぶことは意味の無い事のように思えていましたが、私に撮ってはとても重要なことでした。 理由は、SIerのチームメンバーとコミュニケーションが円滑に進むようにになることです。これまで、〇〇設計はできているの？と聞かれても、なんのことかわからず、聞いても経験しないとわかんないよ的な答えが返ってくることが多かったのです。要は、決めるべきことは決まっているのか、何を決めるべきか把握しているのかということをチーム内で全く共有できていなかったのです。 設計について学ぶことで、チーム内で話し合うべきことがわかるようになったので、今後はもっとスムーズに仕事を勧めていけるように思います。
追記
途中で読み飛ばしたところもあるものの、全体を読み終えました。
設計について、広く浅く解説された本でした。
なぜ設計が必要なのかについてわかりやすく語られており、まさに「はじめての設計をやり抜く」ための本でした。
この本は設計について学ぶためのガイドとして非常に優秀な本であると思います。
