Ruby に型が欲しい理由 - Qiita
Help us understand the problem. What is going on with this article? 2018/07/05 追記 JavaScript と漸進的型付について詳しい mizchi さんが記事を書いたので、併せて読むと良さそうです。 漸進的型付け言語の時代に必要なもの 前置き RubyKaigi2018 の発表で型の導入の検討についての話がいくつかあったものの、 Matz 自身は型アノテーションに否定的であるという発言をしているとのことを受けて、自分の意見の表明として書いている。 筆者は Ruby に育てられて Ruby は好きであるが、業務経験は主に JavaScript(TypeScript) や Python(Type Hinting) が多く、漸進的型付けによるコードの健全化を経験した上で、型付きの方が好きであるという立場である。 なお
Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/19
http://sorehito.xyz/enjou_rails_is_not_programming/
