RubyKaigi 2014 talk. Points for *practical* use of metaprogramming in Ruby.
Practical Metaprogramming in Application
RubyKaigi 2014 talk. Points for *practical* use of metaprogramming in Ruby.
Hypermedia: The Missing Element to Building Adaptable Web APIs in Rails
This document summarizes Takuto Wada's presentation on reviewing RESTful web apps. It discusses best practices for designing RESTful resources and representations, including using nouns instead of verbs in URLs, making URLs reflect the meaning of resources, and ensuring resources are connected through hypermedia links and forms. It also covers appropriate use of HTTP methods, status codes, and con
Why does React scale? - JSConf 2014
min(Time To Find Root Cause) We want to reduce the number of bugs in the system but it’s not really actionable Instead, we found that focusing on minimizing the time to find the root cause of bugs was a better proxy to meet our goal Once you have a repro case, you want to know what code was being used to generate this value To do that, you are going to right-click/inspect element and look at it in
OSCON - React Architecture
型付け力を強化するための Hoogle のすゝめ / Boosting Your Type Mastery with Hoogle
APIドキュメントを実装と乖離させないために - Qiita
内部用APIであるか外部の開発者向けのAPIであるかに関わらず、ドキュメントと実装との乖離は極力避けたいものであるが、注意深く開発を進めない限りこの状況は容易に起こり得る。何が乖離を引き起こし、どうすればこの状況を回避できるのか考えながら、JSON Schemaの利用例を紹介する。なおこの投稿では、HTTP経由でデータの通信を行うような狭義のAPIのことをAPIと呼ぶことにする。 同じ情報源を参照する APIドキュメントと実装が同じ情報源を参照するようにすれば、論理的に関連した要素は統一的に変更され、これらの変更は完全に同期が取れたものになる。つまり、変更時に乖離が生じにくくなる。但し情報の見せ方によって乖離が発生する可能性は十分にだろうし、乖離が発生するのは理解しようとする側の認識の問題であるから、論理的に全く起こり得ないということではない。 この参照の形には、両者が別の情報源を参照する
中高生にプログラミングを教えて分かった５つのこと - Qiita
0. まえがき この記事について 中高生にプログラミングを教えてきて 一年半以上が経ちました。とても素敵な コミュニティである一方で、教える自分たちの 高い技術力と確固たる教育への哲学と信念が求められる 向上心ある職場でもあります。 そんな貴重な経験をしてきて感じたことを この記事にまとめようと思います。 あくまで個人的な感想で、会社や団体の代表意見ではありません。 1. 成果より感動 "Hello, world"だけでいい 何を作るか、ではないのです。 何か作れた、なのです。 はじめてプログラミングに触れる子にとっては、 それはそれはターミナルやエディタどころか PCやキーボードだって新鮮。 いつもLINEやTwitterを触っていたり スマホやタブレットを触っていたりしていても 作り手に回ることは初めての子が多い。 そんな子にとっては、index.htmlに <p>Hello, wor
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
気づいたらプログラマになってた話
@mizchi / Quipper 自己紹介 @mizchi- 竹馬 光太郎 ソフトウェアエンジニア / Quipper まず名古屋方面へ 自分について よく燃えるブログ うるさいTwitter 経歴 2008 大学入学(文系) 2012.3~ Aiming ゲームエンジニア(フルタイム) 2013.9~ Quipper ソフトウェアエンジニアに中途転職 2014.3 学部6年生で大学卒業 来年度から業界3年目の新卒？？？？ それはさておき 大学時代にやってたこと 最低出席日数を確保し、 サークルへも入らず、 バイトもせず、 家にこもってTwitter 家にこもってゲーム 家にこもってプログラミング独学 ↑ これの話する 当時(2008年)のTwitter ほとんどエンジニア みんなリテラシー高い(非エンジニアもすごい) なんか楽しそうだしプログラミングやってみるか 大学以前のプログラミン
クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
仕様の決まる速度で実装する - mizchi's blog
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
Web開発野郎の「エビデンス」としてGUIグリグリな実装したときのgyazo gifほしさ - mizchi's blog
スクショを「Excelに」貼るのはわけがわからないけど、実際スクショを貼るのはテストケースが不足しがちなGUI開発にとっては実装アピールとして有用だし、コードレビューの助けになるのでJavaScriptでグリグリ動く機能作ったときはgif添付するの便利だからみんな貼って欲しい— ﾉ鰻鯉ｼﾍ鮪 (@mizchi) 2014, 8月 4 @koizuka コードだけみせてもこれで何が出来たのかわからん、って言われることあって、確かに自分が他人のGUI実装みても何が起こるかわからなかったりするし、副作用が外部から値チェック可能な形で観測できなかったりするしで、辛いですね…— ﾉ鰻鯉ｼﾍ鮪 (@mizchi) 2014, 8月 4 もちろんサーバーサイドエンジニアの皆様に於かれましては、GUIの遷移で俺たちの実装した何がわかるんだ感があるでしょうが、サーバサイドでは値の変化が確認しやすいのに対し、
CoffeeScriptのリファクタリング - ワザノバ | wazanova
http://blog.arkency.com/2014/07/6-front-end-techniques-for-rails-developers-part-i-from-big-ball-of-mud-to-separated-concerns/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 シングルページアプリもあり、それでなくてもフロント側のコードを書く機会は増えてきてますが、コードをうまく整理して、 簡単に、もっとテストしやすいコードを書く。 クオリティを下げることなく開発スピードをあげる。 ためのノウハウの一端を開発会社のArkencyがシェアしてくれています。 シリーズの初回は、シンプルなリファクタリングのケーススタディ。 CoffeeScriptのコードが、DOM変換、イベントハン
ストリーム表現とその変換 - ✘╹◡╹✘
データをストリームとして表現する方法と、ストリームを変換する方法を紹介する。 ストリームはメッセージが流れる川である Pub/Subメッセージングモデルでメッセージを流すためのオブジェクトのことをストリームと呼ぶことにする。ストリームにはメッセージをPublishでき、またメッセージを受け取ったときの処理をSubscribeできる。例えばキーボードからの入力をPublishして、内容をコンソールに出力するような処理をSubscribeできる。 kamo.jsでストリームを表現する ストリームについて説明するために、kamo.jsというストリームを表現するためのライブラリをつくった。kamo.jsは、ストリームを作成するためのkamo.Streamというコンストラクタ関数を提供する。このコンストラクタ関数から作成されたオブジェクトは、publishとsubscribeというメソッド(※プロパ
コーディングスタイルガイドをみんなで議論するということ | mah365
コーディングスタイルガイドとは、ある言語、あるフレームワークを使用するときに守る、コードの書き方のガイドのようなものです。システムに対してより抽象度の高い表現が可能になった昨今、コーディングとはシステムにおける設計そのものであり、コーディングスタイルガイドはその設計を支える標準化の仕組みと言えるでしょう。 コーディングスタイルガイドはシステムの品質を支える源泉 チームでコーディングスタイルを合わせるのには重要な意味があります。何より他人のコードが読みやすくなるし、読みやすければ表現したい処理に対してコードが妥当かどうかチェックするのに時間がかからない、つまり品質とコスト（時間）を両立して改善することができます。 ところでコーディングスタイルは随時進化するものです。使用している言語で表現できることもバージョンを重ねるにつれて広がっていきますし、何よりチームが時間を重ねるにつれて成長しています
テストしにくいコードは、嫌なコード | mah365
来週話すクソコードに思いを馳せる毎日ですが、クソコードと言うか、嫌なコードだなと思うコードの一つに、テストしにくいコードがあります。 テストできないんじゃどうしようもない アプリを開発していてテストできないというのは、もう、なんというか、どうしようもない状態な訳です。 「テストコードがないコードをレガシーコードと呼ぼう」を合言葉にレガシーコード改善ガイドという本すらあります。この本で語られているのは、テスタビリティの欠片もないコードを、何とかテスト可能なように改良してテストを追加するテクニックです。そのテクニックだけで472ページにも及ぶ大型本が書けてしまうのですから、テスタビリティのないコード恐るべしという感じです。
自分がメンテしないコードの品質を上げようとするわけがないよね | mah365
先日、リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないかというエントリを書いたのですが、こんなことを思ったのもある思い出話があったからでした。 「どうしたらこんなコードを納品できるの！？」 僕にとってのはじめてのオフショア。外部設計書を書いて「これ作ってねー」と海の向こうへ投げるだけの簡単な仕事を引き受けまして、設計書を投げた後、いい感じの時間が過ぎた頃に「どれどれ」とコード（PL/SQL）を見てみたのですが、 「このプロシージャ、すごく・・・長いです・・・」 ・・・うーん、外部設計書の章単位でプロシージャが区切られています。 確かにまぁ、設計書通りっちゃ設計書通り。 しかしいろんなプロシージャ間での処理が書かれていてDRYじゃない。共通の設定を読み出すところもハードコードされているので、仕様変更したいときに死んでしまいそう。 「どうしたらこん
「一人でもコードレビューはできる！」Sendagaya.rbでコードレビューについてディスカッションしました | mah365
先日デキるプログラマだけが知っているコードレビュー7つの秘訣というテーマでSonicGarden Studyというオンライン放送にてお話をさせていただきました。参加者が500人とかなり大盛況の放送だったのですが、その分流れる質問量も激しく、十分に質問にお答えできなかったなーという感がありました。そこでその放送の翌週にあたる8/18（月）にSendagaya.rbの場をお借りして（thanks @tkawa！）コードレビューについてディスカッションする機会を設けさせていただいたのでした＠ソニックガーデンオフィスにて。 スライド 前半はこのスライドを元にざっくり15分ほどでSonicGarden Studyでどんなお話をさせていただいたかを紹介しました。3分ぐらいでざっくり、と前置きしたのに15分ぐらい話してた・・・。 話に上がった内容 いろいろと面白い話が上がっていたので、覚えている範囲でつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://plus.appgiga.jp/masatolan/2014/08/27/53422/
止まっちゃいけないフロントエンド開発
