Githubにあがっている全ての差分をレビューするためのプルリクの作り方 | mah365
全ての差分を対象にコードレビューをしたいときがありますが、Githubのコミット1つ1つにコメントをつけていくと、後から追いにくいですよね。そういうときは一番最初のコミットでブランチを切って、そのブランチとmasterブランチ（最新のコードベースがあるブランチ）を比較するプルリクエスト（以下、プルリク）を作ると便利です。 そういうプルリクの作り方 以下のコマンドで一番最初のコミットを探します。 git log --pretty=oneline --reverse | head -1 で、そのコミットハッシュを元にブランチを切ります。（以下のハッシュは例です） git checkout fca81c19ed4f3b61400f6b1a23bffe78d7fb2913 -b review_20141128 そしてこのブランチをpushして、 git push origin review_201
AngularJSとRailsの丁度良い関係を探る | mah365
AngularJSとRailsのインテグレーションと言うと、やれ「RailsはAPIに専念してビューは全部AngularJSだ！」という極端な話になりがちな気がするのですが、それだとRailsの良いところが活かせませんよね。AngularJSの持ち味はDOM操作三昧で複雑になりがちな画面を良い感じにコーディングできるところにあると思うので、そういう画面でだけAngularJSを使ってはどうか？というのが今回のアイデアです。 丁度良い感じに使う そういう訳で今回作ったサンプルのアプリとソースコードがこちらになります。 https://todo-rails-sample.herokuapp.com/ https://github.com/mahm/todo-rails/ ユーザー認証はふっつーにdeviseを使って、Todoを編集する画面だけAngularJSを利用している、という感じのサンプ
YEOMANのチュートリアルでいきなりハマった人向け | mah365
LET’S SCAFFOLD A WEB APP WITH YEOMANというチュートリアルでいきなりハマった人向けに補足を。概ねチュートリアル通りに進めていけば良いはずなのですが、若干コケるポイントがあるようです。 本稿で使用した各コンポーネントのバージョン node 0.10.28 npm 1.4.9 yeoman 1.3.3 generator-angular 0.9.2 bower 1.3.12 grunt-cli 0.1.13 ハマリ１）grunt serveしたら「Fatal error: Unable to find local grunt.」って言われるんですけど！ 順調にチュートリアルを進めているのもつかの間、Step 5: Preview your app in the browserでいきなりハマる訳ですが、プロジェクトローカルにgruntがインストールされていないた
インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） | mah365
Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない！という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか？というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ
勝手にRubyのオープンソースプロジェクトのソースをチェックする「REFACTORCOP」 | mah365
勝手にオープンソースプロジェクトのコードをRuboCopにかけてみよう、という粋な試み。 これはリファクタリングテロの自動化だ！ あの人がやってるデザインテロと呼ばれる、オープンソースのプロダクトにかっこいいデザインをあてるというのをパクって、リファクタリングテロというのを思いついた。やってもいいというプロダクトはありますか？ — Akihiro Matsumura (@mat_aki) 2012, 9月 27 みたいなことをしていた人もいますが（懐かしい）、このREFACTORCOPはそれを自動化してしまう試み。 とはいえ、RuboCopではRubyの書き方レベルの話しか抽出できないので、そこまでレベルの高いリファクタリングができるわけではないのですが、REFACTORCOPの目的はRuboCopに引っかかったコードを晒しあげることではなく、引っかかったコードをメンテナ以外の人にも直して
スマホで見たときのページをポップアップで確認できるChrome拡張 | mah365
Githubで公開されているdevice emulation chrome extensionが地味に便利です。 使い方 yaomanのアイコンに「mobi」と書かれたアイコンが追加されて、クリックすとスマホサイズのページがポップアップで開きます。 入れ方 githubのリポジトリをローカルにclone Chromeのメニューのツール > 拡張機能から、デベロッパーモードにしたあとに「パッケージ化されていない拡張機能を読み込む」ボタンをクリック クローンしたリポジトリのappディレクトリを選択 とすると、拡張機能が読み込まれます。 LiveReloadと組み合わせると、本体のページとポップアップされているページ両方が自動更新されるのが便利ですねー。
モバイルアプリへのhot code pushにより、Webの当たり前がアプリの当たり前に | mah365
モバイルアプリのようなスタンドアローンアプリとWebアプリの違いは、ソフトウェアの更新のタイミングを、ユーザーの自由にできるか否かという部分がとても大きい。例えばアップデートによって一部データが不正に書き換えられてしまうバグがあったとして、開発者としては緊急アップデートを出したいとしても、ユーザーが更新してくれなければ更新されないままになってしまう。 AppStoreの設定で自動更新されるようになったとはいえ Androidアプリでは特に審査がないためすぐに修正版を配布することができるが、iOSアプリは新しいバージョンを出すために数日間の審査期間を要してしまう。Webアプリではバグ発覚から修正適用まで、（適切な自動デプロイプロセスが整備されていれば）ほぼ作業に要する時間のみで完了するのに対して、この差は大きい。 このためAppStoreの設定で新しいバージョンのアプリが並んだ際に自動更新さ
目の前にある問題から目を背けない〜レガシーコード改善勉強会で得たもの〜 | mah365
先日9/27に「納品のない受託開発を支える レガシーコードを作らない仕組み」というテーマでレガシーコード改善勉強会にてお話をさせていただきました。 お話したスライド レガシーコード改善勉強会、と銘打たれている場所で話すにしては、レガシーコードへの直接的な対処法についてお話している内容ではないので、見る人によっては期待とズレてしまっていたかも知れません。 ただスライドで述べている通り、実際にレガシーコード化してしまうとシステムへの変更に多大なコストがかかってしまいます。更にシステムへの変更という観点ではアプリのコードだけでなくインフラの構成自体も問題になることがあり、個々のシステムの総体を含めてレガシー化させることなく継続的に保守を行うためには、どんな観点で対策を考える必要があるのか？というのが話の趣旨でした。 そもそもレガシーコードを改善できたとしても、レガシーコードが生まれる仕組みがある
Railsのapp/views以下をS3に置いてリリース無しにViewを変更できる「s3_rails」 | mah365
「いちいちちょっとしたViewの変更をリリースするの面倒だから、app/viewsごとS3に置いて管理できるようにしちゃえば良いじゃん」という、何ともマジかよ的な発想を実現できるGemがs3_railsです。 app/viewsを切り分けるという発想 app/views以下を切り分ける発想というのは珍しいものではなく、Crafting Rails4 ApplicationsではViewをDBで管理する方法も紹介されているようです。一方で、S3 RailsではそれをS3で管理できるようにしたよ、とのこと。 DBで管理できるようにすると、もはやそれはRailsの名を借りたCMSだよね、という感じで、むしろRails as a CMSのような使い方をしている人にはマッチするのかも知れません。 ただ更新の差分管理だとか、いろんな機能を実装する必要があると思うので、sonicgarden.jpは静的
JSON-RPC 2.0に準拠したAPIをRails4で実装する | mah365
HTTPで通信するAPIはRESTで設計するのが定石ですが、利用者から見ると不便な場合があります。 RESTは設計に強い制約を与えるため、多人数で開発するときでも設計の一貫性を確保することができるのが利点です。更に一定のパターンに従っている分、既存のRESTクライアントを使って手軽にAPIを利用した機能を実装できるのも魅力的です。 しかし設計がRESTに従う分、例えばいくつかの処理をまとめてトランザクションとして扱いたい、といった場合に、インターフェースを独自に拡張しなくてはいけない状況に立たされることがあります。そもそもRESTだとAPIの単位が細かすぎて、利用者から見て使いにくい、といったケースもあります。 そういった場合はRPC（Remote Procedure Call）でAPIを設計することを検討してみても良いかも知れません。RPCの中でもJSON-RPCという仕様が比較的実装し
内部設計で「どっちでも良い」とき、どっちを選ぶか | mah365
どっちの内部設計方針をとったとしても、ユーザから見える振る舞いは変わらないので、正味どちらでも良い。でも、どちらの方針を取るか決めなければならい、どうしよう？ そんな岐路に立たされたこと、あると思います。 振る舞い上はどちらでも良い 例えばRailsであれば、 ユーザ種別毎にnamespaceでURLを切るべきか？ それともURLではなく、内部のロジックで権限制御するか？ ユーザのテーブルを種別毎に用意するか？ それとも単一テーブル継承で種別毎にクラスをつくるか？ といったような設計判断は、たびたびあると思います。 振る舞いとしてはどちらも同じだけれども、今後の開発を考えると、どちらがベストなのか？ という問題です。方針を誤るとロジックに無理が出てきて不具合を生みやすくなったり、そのためテストも複雑化して保守性に悪い影響をもたらします。 制約を探す ありきたりな答えになりますが、「こっちの
SWIFTという観点で良いテストが書けているか評価する | mah365
Rails 4 Test Prescriptionsをポチったので読んでいます。その中の”What makes great tests”という章の中で、良いテストかどうか評価する観点が書かれていたのでメモ。 Straightforward（率直であること） Well-defined（明確に定義されていること） Independent（独立していること） Fast（実行が速いこと） Truthful（テストの内容が正しいこと） Straightforward（率直であること） テストを見たときに即座にテストの目的が分かるようになっていること、というのが最初の観点です。つまり率直であること。 例えばこんなテストがあったとき、 before do User.create!(points: 32.1) User.create!(points: 5.3) end # ... describe '.a
ChromeでREST APIをテストするならコレ！「DHC」 | mah365
「え、Chrome使ってるのにDHC知らんの？」と言われて「え、化粧品の話ですか？？？」と壮大なボケをかましたのですが、REST APIをテストするためのChromeアプリでした。 こんな便利なツールを知らなかったとは・・・って感じ こちらのリンクからDHCをインストールすると、Chromeのアプリ一覧にDHCが並ぶようになります。そこからDHCを開くと、↑の画像のような感じの画面が表示されます。 使い方は画面を見れば分かるほど分かりやすいですね。リクエストは名前をつけて保存することができるので、「あのAPI、どんな値が返って来たっけ？」というときでも安心です。 POSTリクエストの場合は↑の画像のような感じでリクエストボディの値を書くことができます。 Formモードにすると、かなり直感的な形でリクエストボディの値を指定することができます。凄いぜ。。 ブラウザベースなので、セッションを保持
不完全な製品でなく、半分の製品を作る | mah365
「必要最低限の機能をまずリリースする」、と言うとまるで不完全なプロダクトを作るように聞こえてしまうし、プロトタイピングレベルのものをリリースするべき、みたいに聞こえてしまうけど、そうではないんですよね。 本当に必要なものにこだわる タイトルの「不完全な製品でなく、半分の製品を作る」というのは僕の好きなGetting Realの中の一節です。 ウェブアプリ開発に対して「何でもかんでも」というやり方には気を付けましょう。舞い込んでくる立派なアイディアをちりばめようものなら、不完全バージョンの中途半端な製品に終わるだけ。本当にしなければならないことは、しっかりした半分の製品を作ることです。（Chapter5 機能選択） あれもこれもと不完全なものを取り入れるより、本当に必要なものに時間をかけてその品質を上げた方が、そのプロダクトを使うエンドユーザーにとっての価値が高まるというロジックです。エンド
「一人でもコードレビューはできる！」Sendagaya.rbでコードレビューについてディスカッションしました | mah365
先日デキるプログラマだけが知っているコードレビュー7つの秘訣というテーマでSonicGarden Studyというオンライン放送にてお話をさせていただきました。参加者が500人とかなり大盛況の放送だったのですが、その分流れる質問量も激しく、十分に質問にお答えできなかったなーという感がありました。そこでその放送の翌週にあたる8/18（月）にSendagaya.rbの場をお借りして（thanks @tkawa！）コードレビューについてディスカッションする機会を設けさせていただいたのでした＠ソニックガーデンオフィスにて。 スライド 前半はこのスライドを元にざっくり15分ほどでSonicGarden Studyでどんなお話をさせていただいたかを紹介しました。3分ぐらいでざっくり、と前置きしたのに15分ぐらい話してた・・・。 話に上がった内容 いろいろと面白い話が上がっていたので、覚えている範囲でつ
英語力がピンチなので英語リーディング教本をやり直そうと思ったらドリルが出ていた | mah365
ふと、英文が読解できなくなっていることに気付いた。いつもなんとなーく流し読みをしていたら、着実に英語力が落ちているようなのだった。どういうこっちゃ。 はっきりと読めない なんとなーく読めるんだけど、正確に意味を取ろうとすると読めない。そういう訳で、やっぱり基礎的な何かが抜け落ちてしまったんだろうと、僕の心のバイブルである英語リーディング教本を手にとって例文を読んでみたところ、やっぱり正確に意味が取れなかった。なんてこった・・・。 英語リーディング教本は品詞分解を正確に行うことでちゃんと英文を読めるようになろう、という、「英語をシャワーのように浴びれば読めるよ！」といった考え方とは間逆な本で、「分かってもらえない人にあえてこの本を読んでもらう必要はないよ」的な前書きで最初からある一定層を突き放すステキな本です。 確かに、本書は表面的な文法用語が使えることになることを目標にしています。ところが
コーディングスタイルガイドをみんなで議論するということ | mah365
コーディングスタイルガイドとは、ある言語、あるフレームワークを使用するときに守る、コードの書き方のガイドのようなものです。システムに対してより抽象度の高い表現が可能になった昨今、コーディングとはシステムにおける設計そのものであり、コーディングスタイルガイドはその設計を支える標準化の仕組みと言えるでしょう。 コーディングスタイルガイドはシステムの品質を支える源泉 チームでコーディングスタイルを合わせるのには重要な意味があります。何より他人のコードが読みやすくなるし、読みやすければ表現したい処理に対してコードが妥当かどうかチェックするのに時間がかからない、つまり品質とコスト（時間）を両立して改善することができます。 ところでコーディングスタイルは随時進化するものです。使用している言語で表現できることもバージョンを重ねるにつれて広がっていきますし、何よりチームが時間を重ねるにつれて成長しています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AngularJSのTipsはCodepenのAngularJSタグを見ればいいね！ | mah365
DevTools Tipsというブログは見るべき | mah365
Chromeのタブを検索できるAlfred Workflowがすこぶる便利 | mah365
