CoffeeScriptのリファクタリング - ワザノバ | wazanova CoffeeScriptのリファクタリングと聞いたので、いてもたってもいられなくなった。まず、お題の結果を見ずにやってみる。 これが元のコード $(document).ready -> photoHTML = (photo) => "<li> <a id='photo_#{photo.id}' href='#{photo.url}'> <img src='#{photo.url}' alt='#{photo.alt}' /> </a> </li>" $.ajax url: '/photos' type: 'GET' contentType: 'application/json' onSuccess: (response) => for photo in response.photos node = $(phot

CoffeeScript を導入したことによってクラス化が比較的易しくなり、導入前よりもずっと見通しの良いコードが書けるようになってきました。クラス化することによって関連する機能を一箇所に集約することができ、後から機能を追加する際も関連するクラス内に迷わず追記することができるので、コードがあちこちに散らばることがなくなります。そして各クラスは、それぞれが与えられた役目だけに徹する（関連機能が集約されているから）ので、他のクラスのことなど知ったこっちゃないと言わんばかりに意識しなくなり、自然と疎結合なコードになっていきます。 と、いうのが理想なわけですが、実際そうも言ってられなくなったりします。ひとつ以下の様なケースで考えてみます。 出版社（Publisher）と読者（Reader）という2つの登場人物がいます。読者は出版社が近日発売予定のとある書籍を購入したいと考えていますが、出版社内で編

周辺で話題になったので書いておく。if notとunlessをどう使い分けるか。 検索してみると、青木さんのRubyCodingStyleや、前田さんのRubyコーディング規約などが目に付く。どうやら、世間での標準は、「使えるところではなるべく unless を使い、if not は使わない」ということらしい。 が、僕の場合はちょっと違うので書いておく。他にもこういう人はいるだろうか？ 正常処理の分岐にはif not、異常処理にunless 使い分けは簡単明瞭（だと思う）。正常処理の分岐にはif not、異常処理（例外処理）にはunlessを使うというもの。また、if文を使って正常と異常を分岐する場合は、どんなときでも if <正常> else <異常> end となるようにしている。notが入ろうが入るまいが。 このようにする理由はいくつかある。上から順に大きな因子。下に行くほど、いわゆ

POSTD は、ニジボックスが運営する、エンジニアに向けたキュレーションメディアです。ニジボックスはWebサービスの企画、制作、開発、運用を一貫して担うリクルートの100%子会社です。 リクルートグループのオンラインサービスをはじめ、様々な業種・業界・業態のサービス開発を行っております。

先週流行ってたこの辺りの記事が面白かったので自分のスタイルを。 プログラミングの生産性を上げるには コードを書き続けるためにやってること 時間がなくて乗り遅れたけど、6日遅れで書いてみた。 すごいエンジニアな人たちが書いているので、僕はちょっと違う視点で。 小さい会社ですが社長をやっていると、営業やら総務やら経理やら他のメンバがやっているプロジェクトのマネジメントやら、コードを書く以外の仕事がバカにできないくらい色々あって時間がない。でも、やっぱりコードを書くのが好きなので、そんな中でもコードを書き続け、成長するためにやっている工夫を書いてみます。 要件を聞きながら（考えながら）DB設計とプログラムのざっくりロジックを頭のなかで書く主に受託開発でやっていること。 お客さんから要件をヒアリングしながら、同時に頭の中で大まかなDB設計とざっくりロジックを組み立ててます。 どれだけ要件をちゃんと

プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1 . README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら Trello にタスクを移す 2 . 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く よく iPhone でコードを書いているのだが、オレオレ言語で書いている Erlang っぽい

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

システム開発をする上で、完了条件は避けて通れない。完了条件とは、いつ仕事が終わったかを定義するものである。この仕事が完成したということをステークホルダー間で合意できる基準といってもよい。 仕事全体の完了を示す完了条件もあれば、仕事が次のステップへと移っていいという指標になる完了条件もある。完了条件は、下位の完了条件が満たされることという完了条件もあれば、同じような大きさの完了条件が全て満たされてはじめて完了となるようなものもある。おおよそ仕事として分割できる単位であれば、完了条件があるといってもよい。それだけに、完了条件は重要である。 完了条件というと、どうも固い言葉で手戻りを許さないウォーターフォール型の開発でしか使われていないと感じる人もいるかもしれない。ところが、スクラムといったアジャイルプロセスであってもDoneの定義（＝完了条件）は重要な位置を占めている。もちろん、ウォーターフォ

ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であるクラスの検証では、成果

TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを

DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

実戦的なコードの書き方は、どのようにして身に付くものなのでしょうか？ 文法を覚えること？　それともオブジェクト指向言語であれば、オブジェクト指向自体を学ぶこと？　見方を変えて、関数型のエッセンスを学ぶこと？ アンチパターン プログラミングを学ぼうとするときに、プログラミング言語自体を完璧に学ぼうとするのは、無駄ではないのですがそんなに効率的ではない気がしています。 Ruby技術者認定試験【Gold】模擬問題 例えば上記の問題集をきっちり解けるようになると、Ruby自体の振る舞いについては、はっきり分かるようになりますよね。ただ、仕様を聞いて「これを作ろう！」と思ったときに、やり方に困るのではないでしょうか。 「Rubyでプログラミングできるようになりたい」という要望は、「Rubyというプログラミング言語を学びたい」のではなく、「Rubyという生産性が高いと言われている言語を使ってプログラミ

以前ちょっとお高いプライベート・ジムでトレーニングしていたことがあるのですが、筋力トレーニングって「あ、もうだめかも」というところからが勝負で、そこから歯をくいしばってどのぐらい行けるかが、効率よく筋力アップするコツだということを教わりました。 そういった意味では、プログラミング能力に関しても同じことが言えるのかも知れない、と最近思ったのです。 自分が最高だと思ったコードしかコミットしない 過去を振り返って、今いる会社ソニックガーデンに入社したとき、CTOであるmat_akiから、「自分が最高だと思ったコードしかコミットしないで下さいね」などと言われた記憶があります。 「えー、素早く確認してもらいたいときにそんなことこだわっていたら、スピード落ちない？」 みたいなことを言った記憶もあるのですが、 「いいえ。コードのクオリティは落とさないんです。クオリティは落とさずにスピードを上げるんです」

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この文章について OOP（オブジェクト指向プログラミング、オブジェクト指向パラダイム）について プログラミング勉強中の大学生さんに説明する機会が何度かあったので、 自分の中で整理するために書きました。 中には適切でない説明もあります。ばっさり省いているところもあります。 詳細より イメージを掴んでもらうことを優先しているためです。 「それにしてもあんまりだなー」という表現がありましたらご連絡いただけると嬉しいです。 大学生さん 大学生さんたちはいろんな背景を持っています。 プログラミングを始めたばかりの人 独学で Objective-C や JavaScript を書いた経験がある人 Web やコンピュータの仕組みについてもこれから勉強する予定の人 使用言語 大学生さんたちはプログラミングの第一歩として JavaScript と PHP を使っています。ここでは説明に PHP のコードを使

以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_

日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。