[! {! "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_edited_by" : [! "shiba_yu36",! "shiba_yu37"! ]! },! {! "blog_url" : "http://blog.example.com/",! "permission" : "public",! "can_be_edited_by" : [! "example-user"! ]! }! ] [! {!

6/1 github kaigi

デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一

Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ

最近では 最適化 という言葉を使う場合、GPUメモリ消費やネットワークトラフィックの最適化、などと明示的に言わない限りは、 実行時間の最適化 という意味で使われるケースがほとんどです。 自分が何を最適化しようとしているかを知ろう 私がプログラムを始めた頃、プロセッサの処理能力は遅く、メモリサイズもとても限られていて、キロバイト単位で計算されていました。ですからメモリ容量をよく考え、メモリ消費を上手に最適化しなくてはなりませんでした。大学では最適化について2つの極論を教わりました。 メモリを犠牲にして実行スピードを最適化する。 または何度も計算を繰り返して、メモリ消費を最適化する。 最近では誰もメモリについては大して気にしていません（デモシーン製作者、組み込みシステムのエンジニア、一部の携帯電話ゲームのディベロッパなどは別です）。RAMだけでなく、ハードディスクの容量についても同様です。 W

Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ

まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど

Bacon.jsという、Functional Reactive Programming のFrameworkを使ったJava Scriptライブラリを使って業務アプリを書いてみました。関数型の考え方をふんだんに使いつつも、GUIなどのユーザ入力を伴うような処理に柔軟に対応している、マイナーながら優れたライブラリです。 実際にBacon.jsを使って実装してみて、何が良かったかなってところを、 ちょっと素人なりに色々と考えてみました。 1. 出てくるワードが直感的であるBaconでは、EventStream, Propertyなどといった独自のワードがいくつか出てきます。　ライブラリを読んで色々と使うのは大変だなあと個人的にはよく思いますが、Baconに関しては、新しい概念を取り入れているのにも関わらず、非常に直感的且つイメージがつきやすいワードを選択しているので、頭の中に構造を描きやすい仕

JavaScriptのFunctional reactive programming(FRP)ライブラリ「Baconjs」を使ってFRPの考え方を勉強してみたメモ。 なお、このメモはFRPの勉強のためにいくつかの資料をざっくりまとめただけなので、Bacon.jsの使い方は解説しない。 なのでBacon.jsの使い方を知りたいだけなら元記事を読んだほうが良い。 Bacon.jsのReadme Bacon.jsのチュートリアルブログ(これとかこれ) 三行で FRPでは従来のプログラミングでは間接的にしか扱えなかった「徐々に変化する値」を第一級のオブジェクトとして扱うことができる。 さらに関数型のcompositionalな性質が合わさって素敵。 Bacon.jsは良いものだ。 従来のプログラミングでは時間とともに変化する値の扱いが難しい 例えば次のフォームの例を考えてみる。 <form> <i

はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数

original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,

はじめに Rails4.1でテスト環境を構築する方法を調べてました。以下のブログ（英語、、）が参考になったので紹介します。 Setup Rails 4.1, Spring, Rspec, and Guard - Girders Setup Rails 4.1, Spring, Rspec, and Guard Rails4.1では、Springを使うことでrailsコマンドやrakeコマンドの起動を素早く実行することができます。Springはアプリケーションのバックグラウンドで動作し、アプリケーション起動時のもろもろの動作をサポートします。Springに関連する情報を見つけるのに苦労してので、ここにまとめておきます。 私はテストフレームワークにRSpec、テストランナーのイベントウォッチャーにGuardを使っています。Springを使えば、エディタで編集したファイルを速やかにテストしてくれ

KAIZEN platform Inc.  Senior Technology Advisor 伊藤直也氏（@naoya_ito） 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を

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