ssig33.com - Rails のコントローラーテストをインテグレーションテストに最低限の手間で移行する
Rails 5 がリリースされました。多分目玉としては ActionCable の導入なのですが、既存コードベースのアップグレードに関して一番重要な問題は、コントローラーテストが廃止されるというものになるのではないでしょうか。 というわけで気持ちになってやっていきます。 一般的に今でも Rails のテストの記述には RSpec が用いられることが多いのではないでしょうか。僕も以前 RSpec の記法のメリットについて書きました。ですが私達のチームでは RSpec ではなく test-unit を使っています。理由としては RSpec のマッチャーとかの記法がヤバくなった(こういう話) xUnit のアサーションの方が書きやすくね?という RSpec の context は確かに強力な機能だが実際には特に生かされていなかった RSpec のメンテナのアイコンがキモい というわけですから私達
ssig33.com - なぜ SPA か
顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな
ssig33.com - 清原の経済状態
という問題について今日は考えていきます。 問題意識 清原は金に困窮していたとされているが、実際それは覚醒剤のせいなのか？というのが気になる。 覚醒剤 清原容疑者は群馬で１５０回分の使用量にあたる覚醒剤５グラムを入手、１カ月間で使い切った http://www.sankei.com/sports/news/160216/spo1602160001-n1.html 清原容疑者が小林容疑者から買ったとされる価格は１グラムに換算すると２０万円 http://www.asahi.com/articles/ASJ2J3GQGJ2JUTIL00P.html 上記二つの情報から、清原が覚醒剤に使った額は年間 20*5*12 で 1200 万円であることが分かります。 住居 捜査関係者などによると、清原容疑者が住んでいたのは東京都港区東麻布の１４階建てマンションの一室。 http://www.zakzak.
ssig33.com - ドワンゴもめ事の一番面白い点
最後は総務部を追い出し部屋にしたことです。やめさせたい人間をグループウェアから登録解除し、総務部という名前を持った統合思念体に統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間がスーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。 ドワンゴは大量退職に関する印象操作をやめろ - hiroki-uemuraのブログ 一番大きなのは給与の問題。ソシャゲバブルのタイミング。開発環境の問題。インフラの問題。そのほかいろいろな理由。ほぼ、事実認識としては間違ってないじゃん。ニュアンスの違いは立場が違うからしょうがない / “ドワンゴは大量退職に関する…” http://t.co/cEZY0Pa9zf — kadongo38 (@kadongo38) September 1, 2015 ドワンゴ川上、 kuzuha のエントリが事実として間違ってないといってるし
ssig33.com - Docker についてアメリカの大学で工学博士から英語で話を聞いてきました
というわけで YAPC Asia 2015 の 0-1 日目のレポートです。 技術ブログを書くことについて語るときに僕の語ること はてな社員 id:y_uuki の発表。技術ブログ書いてブクマ稼ぐにはみたいな話。 人間は先頭しか読まない、日本人はアメリカに弱い、はてなブックマーカーはアカデミズムに弱い、信じられないレベルで役に立つ知見だ — チャレンジ (@fuba) August 20, 2015 Docker という単語が後ろに行くだけでブックマーク数が半分になる — チャレンジ (@fuba) August 20, 2015 というような内容。スライドの後半にはいい文章書くにはみたいな話もあったんだけど時間なくてそこはかっとばされてた。あとは「僕がブログ書くときの哲学」みたいな話とかしてたけど、わりとどうでもいい感じだった。 「人は先頭しか読まない」ということをいってたので質疑応答で
ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
ssig33.com - ベンチャーについて極めて基本的なこと
本当に基本的なことを書きます。これから書くのは本当に基本的なことです。ですが以下のことへの理解が足りない事例をよく見ます。その結果の悲劇もよく見ます。 経営者の皆さんへ あなたの会社の社員はあなた程仕事へのモチベーションがありません。あなたが掲げる理念をあなた程信じてもいません。当然です。あなたと同じようにモチベーションがあり、あなたと同じように強烈な信念があれば、あなたと同じように起業するはずです。 もしあなたが仕事のモチベーションも信念もなく適当に会社を売り抜ければそれでいいなどと考えているならば、あなたのその価値の無い仕事は売り抜けることなど出来ないでしょう。 経営者の皆さんは起業した自分の理念に命を賭す価値があると信じていることでしょう。実際その価値は本物かもしれません。ですがあなたの会社の従業員は給料に見合っただけの労力を提供すればいいと思っています。そんなもんです。社員があなた
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
ssig33.com - アンジェム・チャウダリー(チョードリー)氏について
ロンドンを拠点に活動するイスラム教の指導者、アンジェム・チョードリー氏は(略)「アメリカの政策によって多くのイスラム教徒が死んでおり、どんな形であれアメリカを支持するならば日本の市民やジャーナリストが捕らえられても驚きはしない」と述べました。 「日本 中立とは見られていない」 NHKニュース という記事が NHK ニュースで配信されました。また以下のようにもあります アンジェム・チョードリー氏は、シリアやイラクへ渡って戦闘に加わるイギリスの若者に影響を与えているとされ、去年９月にはテロを扇動した疑いで一時、身柄を拘束されるなど、当局が監視を続けています。 とあります。 ところで NHK ニュースでの表記では Choudary をチョードリーとしていますが、一般的にはチャウダリーと表記されてきた歴史があると思いますので、以下ではチャウダリーと統一します。後述しますがこの表記についてもかなり問
ssig33.com - Angular.JS について
いろいろ文句言いたくなるところ山のようにあるんですが、 Internet Explorer の古いやつとかサポートしてくれてるのが Angular しかないだとか、だいたいみんな Angular なら分かるだとか、いろいろあって現実的に Angular しか使えるものが無いねみたいになりがち。 そういうわりと消極的な理由で使われることが多いので、みんな文句たれてるんですけど、文句たれてる人が多いから使わなくていいプロダクトなんだなみたいに思って勉強怠ったりするとそれはそれで嫌な目にあいますから、みなさん一緒に Angular で苦しみましょう。 IE のことを忘れられる場合は Vue.js 使ったほうが圧倒的に幸福になります。 付記 React について 一番真面目に React を使ってるはずの Facebook のサイトがあんなに激重メモリバカ食いなので、 仮想 DOM を操作して差分
ssig33.com - 一般番組まで含めて録画しまくる
アニメだけだと http://karia.hatenablog.jp/entry/2014/10/28/044718 でいいと思うんですが、 Fast'N Loud などを見たいのでディスカバリーチャンネルとナショジオの新番組は全部録画するだとか、ジャニーズタレント出演番組全部録画したいだとか、 Twitter で follow してる人達の発言ひろって録画したいとかなると foltia では生きていけません。 うちの場合 うちの場合は合計 3 台の PC でまわっています ストレージサーバー兼アプリケーションサーバー 55TB のハードディスクがぶらさがっていて、 KVM な仮想マシンや、多数の Docker コンテナが動いています 録画機 チューナーが合計 3 個 12 チューナーついててひたすら録画する エンコーダー Intel Quick Sync Video でエンコードする ス
ssig33.com - Jenkins で Rails アプリを docker build する話
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
高密度小池 ／ Vim で日本語を書く
Vim で日本語を書く 先日までのエントリで少々触れた通り、僕はアニメやゲームに関わる仕事などをしていて、仕事では主に開発言語として日本語を使っています。開発環境は主に Vim を使っているのですが、僕の周囲の Vim ユーザー(主にプログラマーが多いですね)は Vim はまるで日本語に向かないクソだというふうに主張している。 実際には Vim は日本語のプロ(自分で自分のことをこういう風に言うのはとても恥しいし、アホっぽいですね)の道具としても十分使い物になる道具ですので、その辺りのことを紹介していこうと思います。 1.IME を適切に選びましょう Vim で日本語を書く際の最大の問題点が Vim のモードと IME のモードの問題です。一言で言うと「コマンドモードに戻った時に同時に IME も死んで欲しい」というアレです。これは gVim を使うか、 Vim 協調モードのある適
ssig33.com - 旅と在宅勤務
2 年間以上在宅勤務しています。会社から借りた MacBook Air はとっくにぶっ壊れて適当に放置されています。 2 年間のうち自宅にいた日数が 365 日に達しているかどうか分からないレベルで旅行その他をしてきました。 生産性は確実に落ちます 家でそれなりの机と椅子もしくは無印ダメソファで仕事をする場合の生産性は非常に高いものです 一方アジアのよくわからん所や不安定な衛星回線しかない飛行機や船の上で仕事をする場合生産性はそこまで高くありません そのようにまあムラは出るのですがそこまで含めて自分の生産能力だと会社に認めてもらえるかどうかという問題になってきます。 あとまあそういうふざけたことをしてるのを同僚に認めてもらえるかどうか。 環境にロックインされます 好き勝手どっかいきつつクリティカルな責任は会社に背負ってもらいつつ 500 万とか 600 万とか貰ってみたいなことが出来る環境
ssig33.com - Rails アプリでのビューキャッシュ戦略
キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ
ssig33.com - DHH についての見解
DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話
ssig33.com - Ruby On Rails でサブドメインを使った Web サイトを作る
という地獄の話です。 基本的な部分 # config/initializers/session_store.rb Hogehoge::Application.config.session_store :cookie_store, domain: ".#{ENV['DOMAIN']}", key: '_hogehoghoge' というような感じにする。アプリを起動する時に環境変数でドメインを指定する。 .#{ドメイン} と cookie のドメインを指定しておくことでサブドメインでもクッキー共有できるようにする。クッキー共有したくないならこうしない。 ./bin/rails server とかを使うなら、この場合 localhost としてアプリが起動するのだから、 DOMAIN=localhost ./bin/rails server とかする。 hoge.localhost とかで名前解
ssig33.com - ダンピングをするな
これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip
ssig33.com - Web アプリケーションを配布する
Web アプリケーションを配布するにあたっていろいろとあって、 PHP スクリプトが圧縮されていたり、 Rails のプロジェクトディレクトリが圧縮されてたり、プロジェクトディレクトリを git clone してこいだとか、だいたいそんな感じじゃないかと思います。 これは実際使用者にしてみればめんどくさくて、そのプラットフォーム毎の作法というのを覚えなければいけなかったりする。それくらい覚えろやカスといえばまあそうなんですが、そこをなんとかしたい。 ところで僕は Ruby を使って Web アプリケーションを作りますので、 gem install web-application とかで一発でアプリケーションをインストールできて、 web-application コマンドとかを叩けば起動できるとかだと嬉しいなあと思っていました。 というわけでそういうの作りました https://github
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - 生産性の高いエンジニアは本当に 10 倍の生産性があるのか