github という公的なインフラを使うために必要なこと - アンカテ を盛大に dis っとかなきゃなという気持ちになった。 Pull Request ベースの開発 階層型組織構造 は特に対立するものではないですし、階層型がいいのかフラットがいいのかは場合場合によるでしょう。階層型でばりばりに管理するような開発チームでも ディレクターが issue を起案する 開発リーダーとディレクターがプロダクトマネージャーなどを交えてスケジュールを決定する 開発リーダーがその issue を閉じる Pull Request を作る人とそれをレビューする人を決定しスケジュールを伝達する 所定のタイミングでリリース権限を持っている人がマージボタンを押す みたいなカチカチした運用でいろいろやっていけると思いますし、これでも Github Flow というか Pull Request ベースの開発の恩恵を十

Rails 5 がリリースされました。多分目玉としては ActionCable の導入なのですが、既存コードベースのアップグレードに関して一番重要な問題は、コントローラーテストが廃止されるというものになるのではないでしょうか。 というわけで気持ちになってやっていきます。 一般的に今でも Rails のテストの記述には RSpec が用いられることが多いのではないでしょうか。僕も以前 RSpec の記法のメリットについて書きました。ですが私達のチームでは RSpec ではなく test-unit を使っています。理由としては RSpec のマッチャーとかの記法がヤバくなった(こういう話) xUnit のアサーションの方が書きやすくね?という RSpec の context は確かに強力な機能だが実際には特に生かされていなかった RSpec のメンテナのアイコンがキモい というわけですから私達

顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな

Rails アプリを Docker で稼動させる際に、 Gemfile と Gemfile.lock を先に ADD して bundle install してからアプリケーション全体を ADD することで、 bundle install の結果をキャッシュする手法はよく知られています。 ADD Gemfile /app/Gemfile.lock ADD Gemfile /app/Gemfile WORKDIR /apps RUN bundle -j4 ADD . /app こういうやつ。 ところがこの手法は Jenkins のように毎回リポジトリが clean にチェックアウトされる環境では全く無効です。 何故なら、 Docker は ADD するファイルが更新されているかどうかを、ファイルの中身そのものではなく、タイムスタンプなどのメタデータで確認しているからです。 git checko

結論: 程度問題だし個別に判断しろ この辺に関する話 http://mizchi.hatenablog.com/entry/2013/09/07/171644 http://shunirr.hatenablog.jp/entry/2013/07/01/000944 http://d.hatena.ne.jp/gnarl/20120407/1333725733 退職時に古巣に後ろ足で砂をかけるようなブログ記事をかけるような人達がいる。それに怒っている人達がよくいる。という訳で個別の事例について考えていきましょう。 mizchi 技術力はそこそこある。人格は糞。月給 24 万とかだったらしいし 24 万が新卒として安いかというと、まあ安くもない。絶対的に人的資源としての価値だけ考えれば多分微妙に安い。彼は「成果」を主張しているが結局あの地獄の JS プロジェクトそんなに売り上げたってないっぽい

実際に危険な例 データの変更が出来るドメインに XSS がある 秘匿されたデータが閲覧できるドメインに XSS がある 声優の住所を公開するサイトがある 実際には危険ではない例 ameblo.jp に XSS がある Twitter クライアントの Consumer Key と Consumer Secret を第三者が取得できる 声優の携帯電話の情報をブログからまとめて公開するサイトがある 後者は大して危険ではないですし、こういうものを危険だ危険だといっていると真に危険なものについて話している人の声が届くべきところに届かないことになります。 ところで実際のところ、インテリジェンスなるもの大半は公開情報を検索可能な形に編集し意味のあるデータを作成する行為であり、声優の携帯電話に対してインテリジェンスの暴力を声優に翳すなと言う批判は成立するのだと思います。 例えば鹿野優以の使っていた携帯電話