プログラムの可読性を上げるための条件分岐を減らす方法7個 - QiitaHelp us understand the problem. What is going on with this article?
大きな Rails アプリケーションをなんとかしよう。まずは計測と可視化からはじめよう。 - クックパッド開発者ブログ
こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開
アジャイル設計と5つの原則 - かまずにまるのみ。
アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。 アジャイル設計 アジャイルな設計 「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。 悪い設計 第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。 硬さ （設計変更が難しい） 脆さ （設計が壊れやすい） 移植性のなさ （再利用が難しい） 扱いにくさ（正しい設計をするのが困難なソフトウェア、面倒な開発環境） 不必要な複雑さ（"後で必要になるかもしれない"と考えて先行実装したコード） 不必要な繰り返し （コピペ） 不透明さ （目的や意図がわかりにくい） 原則 システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。 ただし無条件で原則に従うと「不必要な複雑さ」を招
関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘
関数の適切な長さとは？ マーチン・ファウラー氏は、長さより意図と実装の分離、そしてよい関数名が重要だと指摘 一般にプログラムは多くの関数などから構成されています。関数には数百行に渡る長いものから数行程度の短いものまでさまざまな長さがありますが、果たして関数にとって適切な長さというのはあるのでしょうか？ マーチン・ファウラー氏は関数の長さについて書いたコラムで、重要なのは意図と実装の分離であり、適切な名前を付けることが大事だと指摘します。同氏のブログは翻訳が許可されているので、記事「FunctionLength」の本文を翻訳しました。 FunctionLength（関数の長さ） 私のキャリアにおいて、関数の長さはどれくらいであるべきか、という議論を何度も聞いてきた。これはより重要な問いに置き換えることができる。それは、どのくらいの長さのコードになったらそれを関数にすべきか、ということだ。 い
mattnさんのリファクタリングを読み解く - 生涯未熟
現在絶賛開発中のkirimoriですが、なんとGolang界隈で有名なmattnさんにリファクタリングをして頂くという、とても嬉しい事態がありました✨ kirimoriについてはこちら↓ syossan.hateblo.jp リファクタリング前提でかなり雑に書いていたのですが、めちゃくちゃ良い感じにコードを直して頂けたので自分の勉強のために読み解いてみます👏 リファクタリング前 kirimoriは以下の機能を有しています。 initコマンドでkirimoriの設定ファイル（toml形式）を作成します addコマンドでコマンドライン引数に指定したプラグインを追加します removeコマンドでコマンドライン引数に指定したプラグインを削除します listコマンドでプラグインの一覧を表示します で、構成的には kirimori.go に全てのコマンドの処理をベタ書きにしてある感じになっております
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
静的解析ツール「RubyCritic」のUIが良くなっていたので紹介したいです！ - パラボラアンテナと星の日記
この記事は feedforce Advent Calendar 2016 - Adventar の2日目の記事です。 1日目は 源義経のシンプルな考え方が好き - Marketing book でした。良い話だ。(ちなみに大河ドラマが平清盛だった年は、我が家では後白河院の評価が高かったです。懐かしい。) RubyCriticのご紹介 rubyエンジニアなのでrubyのことを書きます。 RubyCriticはrubyコードを静的解析するツールです。rubygemで提供されています。 単純な使い方としては、$ gem install rubycritic するなりbundler使うなりしてインストールし、 $ rubycritic . を実行します。$ rubycritic ./app ./lib のように、指定のディレクトリだけを対象にして実行することもできます。 実行すると./tmp/ru
ActiveSupport::Concernの意味と歴史
Takuto Wada @t_wada @june29 伝統的には「関心事」ですかね…? Crosscutting Concern とか Core Concern とかの訳語に使われることが多いです。 2013-01-23 14:23:42 OHWADA Jun🚿 @june29 @t_wada 反応ありがとうございます！なんとなくわかってきたような気もしますが、なぜ ActiveSupport の中のこの Module が Concern という名前なのかは、まだ自分の言葉で説明できるほど腑に落ちてきていません…！引き続き考えてみます！ 2013-01-23 14:29:38
長くなりがちなRailsのモデルをきれいに分割する - Qiita
FrogApps 技術ブログ始めました！ RailsやiOS、HTML5の情報を発信中!! → http://qiita.com/teams/frogapps Railsでアプリを作っていると、app/models/以下にあるモデルファイルの行数が非常に長くなることになります。 そこでincludeメソッドを使ってモデルファイルを機能毎に分割してみましょう。 ファインダー関係のメソッドだけを、user/finder.rbに切り出します。 このときクラスメソッド関係は通常の定義方法が異なります。 クラスメソッドの定義は、ClassMethodsモジュールの中で行う様にします。 has_many, belongs_toなどのクラスメソッドの実行は、self.includedの中でbase.has_manyの様にして呼び出します。
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！ - Qiita
てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
ハンガリアン記法って気持ち悪い。 | Tetoatom
こんにちは、Tetoatomです。 あるプロジェクトのソースコードがすべて、ハンガリアン記法で記述されていました。 私はハンガリアン記法が気持ち悪くて、気持ち悪くてしょうが無いです。 ハンガリアン記法とは ハンガリアン記法とは主に、変数名などの先頭に、その変数の方を示す接頭語をつけるソースコードの記述スタイルです。 例えば、以下の様にintとunsigned intの変数があったら、iCountとしたり、uiNumberとしたりすることです。 int iCount; unsigned int uiNumber; 変数がどこに記述されていても、宣言部まで遡らずに方がわかるため、明示的でわかりやすいです。 ただ、ほんとにそんな情報必要でしょうか？？？ 単純に宣言部まで遡ってこの変数はこういう方なんだと覚えてから、トレースなりするのは大した労力ではないと思います。 しかし、このように方を
HTMLを15年書いてる僕が語ってみる vol.1 - Qiita
僕はHTMLを書き始めて約15年。割と年齢は若い方で、いわゆる「ベテラン」という感じではないのですが、 長く付き合ってきたこの言語について、最近思うことが多いので語らせてください。 元W3Cメンバーとして考えていたことなので、 マークアップエンジニア、フロントエンドエンジニアには刺さるかもしれません。 以下が今回のお話です。 語りたいこと HTMLの変遷 HTMLってそもそも何 僕が書いた15年間 1. HTMLの変遷 1-1. 僕のマークアップの始まり 約15年前、僕は自分が産まれる前にできたファミコンのスーパーマリオブラザーズが大好きで、 なんとなく勢いで「ホームページ」を作ってみました。 母親がドリームキャストでホームページを作っていたので、「あ、なんかできそう」みたいな感覚で。 1-2. テーブルレイアウト 当時はHTMLが主に大文字で書かれていて、ほとんどがtable要素でマーク
[iOSアプリ開発] いまさら聞けないモダンな書き方 | DevelopersIO
Xcode 4.4 から Objective-C が書きやすくなりました、という今更のいまさらな話ですが、ネット上に転がっている少し前のサンプルソースなどは古い書き方のものもあるようなので、今回はよく使う NSArray と NSDictionary と NSNumber の書き方についてだけ備忘録として残しておこうと思います。 NSArray インスタンスの生成 // 古い書き方 NSArray *oldArr = [NSArray arrayWithObjects:@"value1", @"value2", @"value3", nil]; NSMutableArray *oldMutableArr = [NSMutableArray arrayWithObjects:@"value4", @"value5", @"value6", nil]; // 新しい書き方 NSArray *n
イニシャライザが守るべき3つのルール - Qiita
オブジェクトを初期化するイニシャライザ、init で始まるメソッドですね。 init とか initWithString とか。他言語でいうところコンストラクタ代わりです。 iOS開発している人なら、「指定イニシャライザ」 という単語は聞いたことある人多いと思いますが、これの意味と役割を理解せずに組んでいる人も多いのではないでしょうか？ そしてイニシャライザではいくつか守ったほうがいいルールがあります。 3 Rules for initializers 結論から書くと、以下の３つルールをイニシャライザでは守ると効率的になります。 (1)必ず一つの指定イニシャライザを持つ(基本的に複数はナシ) (2)指定イニシャライザ以外のイニシャライザは、必ず指定イニシャライザ経由で初期化する (3)親クラスの指定イニシャライザは必ずオーバーライドする 理由はこの記事で説明します。（※長いです） clas
[iOS] AppDelegateを綺麗に保つ4つのテクニック - Qiita
AppDelegateはアプリ全体のライフタイムイベントを管理するためのクラスですが、その性質上、様々な処理が書かれやすいです。 しかし、あらゆる処理が書かれ肥大化していくと、見通しが悪くなってメンテナンスがしづらくなったり、チームで開発してる場合はコンフリクトが起こるなど開発速度に支障をきたすようになってしまう場合があります。 そこで、この記事では、そんな膨れがちなAppDelegateを綺麗な状態に戻すための方法をいくつか紹介します。 1. AppDelegateの責務外の処理は他クラスに移す AppDelegateの主な責務はライフタイムイベントの管理です。具体的には「起動」「停止」「バックグラウンド状態の切り替わり」などなどUIApplicationDelegateで定義されているような処理です。 にもかかわらず、例えば全Controllerから触れる値を定義したいなどの理由で、責
![[iOS] AppDelegateを綺麗に保つ4つのテクニック - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e17a34fd061917d11e574cba6142026b8740f4ca/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCaU9TJTVEJTIwQXBwRGVsZWdhdGUlRTMlODIlOTIlRTclQjYlQkElRTklQkElOTclRTMlODElQUIlRTQlQkYlOUQlRTMlODElQTQ0JUUzJTgxJUE0JUUzJTgxJUFFJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJThCJUUzJTgzJTgzJUUzJTgyJUFGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iYjhmMTIwYjIzZDM5YTM4YjliYWFkMWU0ZWNmOWI3Ng%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbm9yaTA2MjAmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWUzYTk0YTc1MGY5NzFkOGQ4NWY4NjQ2YWQxZjk1NjM3%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Df2053a25af1f0b7e60dcc237ffabd200)
Rubyのcaseを〇〇(言語名)のswitch文だと思っている人たちにぼくから一言ガツンと申し上げたい
「Rubyのcase」を一瞥し「あー要は〇〇(言語名)のswitchね」などと早合点し、その後もその真の価値を知ることなく一生を終えるプログラマが近年跡を絶たない。加えて、「今更条件分岐？RubyはOOPなんだからポリモフィズムじゃね？」とか「HashにProc突っ込んでcallするのがオレ流。」とかうそぶく人たちもまた増加の一途を辿っている。 そんな世の中にあって、ぼくは一言、できればガツンと一言申し上げたい。生まれも育ちもRubyなぼくから、是非ともそんな人たちに「Rubyのcase」について一言申し上げておきたい。 ─ 問題１ ─ 名前name、レベルlevel、ポイントpointの各属性を持った複数のCharacterオブジェクトcharlie, liz, benがある。 class Character < Struct.new(:name, :level, :point) def
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/32
Code Climate