[B! 設計] sakaharaのブックマーク

シンプルでわかりやすいコードを書くためにあなたがすべきこと - give IT a try

はじめに先日、とある知りあいのRubyプログラマからこんな相談を受けました。（内容はちょっとボカしてます）社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。伊藤さんのアドバイスを聞きたいです。この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。ただ、具体的にどうすればいいの、という答えは一言では言えません。というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。（その前に）もくじかなり長い記事になってしまったので、先に目次を載せておきます。はじめに（その前に）

sakahara 2016/05/18

リンク

Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合にバッチ処理を選択する事が多い。実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。利用者の操作に対して対話的・同期的な処理はオンライ

sakahara 2016/02/18

リンク

Web API設計指針を考えた｜デロイトトーマツウェブサービス株式会社（DWS）公式ブログ

小文字のみを使用する。単語をつなげる必要がある場合はダッシュを利用する。単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。（APIに実装を反映させるべきではない。）スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。ページングにはper_page、pageというパラメータ名を使用する。と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。 1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間