ブログ枠ということなので書く。 Scrapbox 個人ではあんま使ってないのでここに書きます。 Scrapbox Drinkupへの参加の感想を1週間後までに書いていただき、インターネットに公開していただけることが条件になる枠です とあるのがどういうふうに書けとは指示がないのでそのように行なわれるでしょう。各セッションの細かい内容などはイベントの Scrapboxを参照されたし。 サポートチケットから Scrapbox のページが作られるという話について思ったこと これに関して、使っているツールは Slack なのだけど僕が働いている会社でも同じようなことをやっていて大きな成果が出ていると考えている。 サポートチケットそのものとは別の場所にコミュニケーションのための場があるのは極めて良いことであると思う。 Nota 社の取り組みのうちユビレジの取り組みより進んでいると感じたのは、対応用ペー

という地獄の話です。 基本的な部分 # 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 とかで名前解

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

Heroku は最近料金体系に変更があって、無料では一日 18 時間までしかアプリを起動できなくなりました。 自分専用のアプリとかそういうものなら全く問題はないのですが、それなりにユーザーがついているようなアプリだとなんだかんだで 24 時間 Dyno が起動しっぱなしということはおおいと思います。 一番安いプランは 7 ドルで、とりあえずこれだけ払えば 24 時間 Dyno を起動しっぱなしにできます。 公開しているアプリが 1 個ならまあ 7 ドルぐらい払っとけよで済む話なのですが、私のように 18 時間制限にひっかかってるアプリが 30 個もあるとなると 210 ドルを払うのは躊躇してしまいます。 ということで今日は石に齧りついてでも Heroku をタダで使う方法を考えていきます。 基本的なアイディア Heroku でアプリ 2 個用意して、同じ DB 向くようにして、 12 時間

ほぼ出オチに近いんですが。 これで発動する XSS を実際に見かけました。 iOS アプリと Web アプリが両方あるアプリである Web アプリがわにアカウントにひもづいているデバイスを一覧できる画面や投稿元デバイス名が表示される画面がある そこでデバイス名がエスケープされてない という事例です。一昔前は Rails や CakePHP やらがテンプレートエンジンで普通に HTML を出力すればエスケープしてくれたものですがが、最近は JavaScript で HTML を構築することが多く、手動でエスケープするような暗黒時代に戻ってしまっている感があります。 「たいていのところはちゃんとエスケープしてあるけど、↑のような意外なところが抜けてたりする事例があります。 iOS のデバイス名由来のものについては簡単に調べた結果 3 件ほど XSS を見かけたので、それについては報告はしておき

表題の件について、個人ユーザーが「WD Green や Seagate はすぐ壊れるからだめ」みたいなことを言っているのをよく見ますが、 頻繁に電源を入れたり切ったりする個人ユーザーではありがちな環境 ほこりが多かったり住宅の環境自体が悪い 運用が適当 といった問題で故障率は大幅に上昇しますから、 HDD に何選ぼうが大してかわりゃしません。そして何より HDD の故障の原因となるのは、システムに繋がず電源切ったまま放置しておくことです。壊したくなければ常に電源入れときましょう。 そして HDD の故障率云々以上に rm コマンド間違えて打ったとかによるデータロストのリスクの方がはるかに大きいのではないでしょうか。 運用環境が悪いのを WD Green や Seagate のせいにするな、 WD Green はソフトウェア RAID なら特に問題はない、黙って一番安いのを買え。壊れたら H

失敗学 (図解雑学) 賢者は歴史に学び、愚者は経験に学ぶという。その仮定が正しい場合、人類の知能はそこまで広く分布しているわけではないので人類はだいたいみんな歴史からは学べないということになる。 正直自分の実感としても他人の失敗事例から学べたということは少なく(歴史から学ばない態度)、人は自分の失敗から学ぶしかないのではないかと思う。ただまあ他の技術者が事故にどのように対処したかとか、対処に失敗したかとか、歴史から学べた稀有な事例は何かといったことを読むのは楽しい。 爆笑問題のハインリッヒの法則―世の中すべて300対29対1の法則で動いている (祥伝社黄金文庫) ハインリッヒの事故防止の研究とは何の関係もないけど、爆笑問題カーボーイが一番面白かったころの本。今読んでも面白い。 Web業界 受注契約の教科書 Textbook for Business Contracts in the Web

サンフランシスコやニューヨークの家賃、スタジオ(日本で言うところのワンルーム)で月 2000 ドルとかする。家族と一緒に住める家とか月 3000 ドルは最低かかる。 家賃だけで年間 250-400 万円は持っていかれるという話になる。 Dropbox のあるテキサス州オースティンとかだとこの 1/3 なんだけど。 前に IT とか全然関係ない話でダラスに住もうとしたんだけど、家賃高すぎて結局断念した。 あと有名な問題が保険で、保険会社が指定する病院でしか診療受けられないしょぼい方の HMO というタイプの保険でも月 150 ドルかかる。年間 20 万円で家族が 4 人いたら保険だけで年間 80 万円は見ておこうという話になる。 医療に関して有名なもう一つの問題は「歯の治療の保険請求が異常に難しい」という問題で、アメリカに移住した知人が歯医者で保険適用された事例見たときない。虫歯になったら日

なんのこっちゃという感じですが、具体的にやりたいことは以下の通り Amazon の コンテンツと端末の管理 から購入した Kindle 書籍を自動ダウンロード 何故こんなことをしたいかというと、 Kindle 本は DRM をクラックする確実な手段があります。 DRM をクラックすることは違法ですが、 Amazon という企業が消滅した時に、購入した本が読めなくなるのは困ります。 Amazon が消滅するときは世紀末のような社会でしょうから、 DRM のクラック程度の犯罪が問題になることは無いでしょう。 AZW3 をローカルに保存しておけば、その時がくれば DRM をクラックすればいいということになります。 以上の考えは半分本気、半分はまあスクレイピングしづらそうなものがあればやってみたい、というだけです。 JavaScript を含まないページのスクレイピングはどうとでもなります。 Ja

いろいろ文句言いたくなるところ山のようにあるんですが、 Internet Explorer の古いやつとかサポートしてくれてるのが Angular しかないだとか、だいたいみんな Angular なら分かるだとか、いろいろあって現実的に Angular しか使えるものが無いねみたいになりがち。 そういうわりと消極的な理由で使われることが多いので、みんな文句たれてるんですけど、文句たれてる人が多いから使わなくていいプロダクトなんだなみたいに思って勉強怠ったりするとそれはそれで嫌な目にあいますから、みなさん一緒に Angular で苦しみましょう。 IE のことを忘れられる場合は Vue.js 使ったほうが圧倒的に幸福になります。 付記 React について 一番真面目に React を使ってるはずの Facebook のサイトがあんなに激重メモリバカ食いなので、 仮想 DOM を操作して差分

キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ

DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話

乱入します。そういうのあるのか調べてないけどどうせあるでしょ。あんまりまとりないです。 DCI か Concern かみたいな話です。 Rails のファットモデル対策 これの続き。 module に切り出す粒度はどうするかとかこれはこれで難しいとろはあるのですが という部分について適当に書いておく。 まず DCI というアプローチではモデルが肥大化するという問題は本質的に一切解決していない。結局のところさまざまなコンテキストで責務が呼ばれた結果最終的に生成されるドメインモデルは極めて巨大なものであることに変わりはない。 結局のところ、改善されるのは「コードの見た目」に過ぎない。しかしながら我々プログラマーは「コードの見た目」が如何に重要であるか知っている。コードの見た目はプロダクトの品質のかなりの部分を占める。 DCI というアプローチは単純に Concern するという戦略と何が違うか

あんまそういうこと気にしないで黙ってコード書きまくるといいです。それで限界が見えてきたらいろいろそういう方面のことを勉強しましょう。 back to index of texts Site Search

クラウドソーシングやってる会社から求人メールがくる ssig33「自社のサイトで人集めたらどうなんですか」 ク「それはいまいちなので、、、」 ということがこの前ありました。全部が全部そんなんだとは思いませんが、ちゃんとドッグフード食ってるところあんまないなあというのはまあ。 大変ですね。 back to index of texts Site Search

選挙になってマック赤坂が立候補してくると、冗談なのか本気なのか知りませんが「全候補者のなかでマック赤坂が一番マシ」みたいなこと言う人達が結構大量に出てきます。 具体的にこんな感じ ですが僕はこの人は本当に絶対に当選してはいけない人だと思っています。理由は以下です。 スマイル党公式ホームページ (2)(3) についてはまあともかく(2 に関しては若干の説得力があるのはまたしかでしょう)、(1)はかなり問題です。 抗精神病薬には一般に言ってアカシジアなどの重篤な副作用があるものであり、副作用との兼ね合いをみながら投薬をしていくことになります。現代において「とりあえずこれ」みたいな感じで出されているジプレキサに至っては一般的な副作用に加えて 太る とにかく太る そして糖尿病になる という副作用があります。しかしながら、こうした副作用があるにせよ、投薬と生活習慣のコントロールにより影響を低く抑え最

というようなのよく言われますがこれは間違っていて 生産性の低いエンジニア: ある閾値を越えたものは作れない 生産性の高いエンジニア: 生産性の低いエンジニアの作れないものでも作れる というような感じであることが殆どで、生産性の低いエンジニアに 10 倍の時間を与えたからどうにかなるというようなもんでもないでしょう。 時間が何でも解決すると思ったら大間違いだ。 back to index of texts Site Search

本日を持って **** を退職しました。諸々掛け持ちで酷い状態なの全然変わってないんですが、まあいろいろマシになると思います。 退職した理由は新しいボスが **** でそれはさすがにないだろと思ったからです。 HQ が **** なので **** で **** な事情なので税金が **** で **** となるので各位そこは御安心頂きたく思います。 来年からは他の作業の精度と速度に改善が見られることと思います。 あとそろそろ言っておきますが僕と山岸和利は Web 系エンジニアとしてはハートレイルズという会社で働いています。この会社は受託と自社サービスでやっている古きよきごく普通の Web 系の会社なのですが、オフィスが存在しないという特徴があります。 自由な働きかたをしたいがしかし生活の保証は欲しいという都合のいいことを考えている人間には極めてオススメの会社です。またそれなりの高給やそれな

https://plus.google.com/107002572043873162468/posts/4sBboJT6GMW http://blog.toshimaru.net/cool-ui/ この辺の話。正直こいつらただのバカだとは思うんですが、 Gunosy が多機能化したら不評だったので旧 UI を別アプリで出した話 FxCamera が SNS 機能追加したら不評だったので旧 UI を別アプリで出した話 みたいなダサいことになるくらいなら masarakki さんの精神性を見習ったほうがまだマシじゃないかと思います。正しいと思ってやったことがユーザーからダサいと判定されたときは、「これが最高にクールなんだ！！！」と主張しつつしれっと不評な部分を直していくぐらいのほうがいいと思います。 そのほうが自分や開発者のプライドを防衛できるし、プライドの防衛というのはよいアプリケーションの

この画像がなんなのかということについて気にしている人がいるようなので、解説します。 これはブラジルさんという著名なプログラマが、仕事中に無修正エロ画像をリブログしまくって仕事をクビになった報告をしたエントリに載っていたものです。当該エントリはもう消えて残ってません。 それ以来 IT エンジニアが退職エントリを書く時はこの画像を掲載するのが伝統的なしきたりになっています。 back to index of texts Site Search