いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策

インターネットが面白くなくなっただとか、アニメが面白くなくなっただとか、金を使うような面白いものがなくなっただとか、そういうことを言う人がだいたい常にいます。 そういう現象を一言で表す言葉があって「老い」と言います。 老いは誰にでも来るものですしそれはしょうがないです。アニメは面白いですし、インターネットで意味不明な面白いことやってる人は今でもたくさんいます。 さて老いてなんで意欲が減退するかというと、筋力が落ちるからです。筋力が落ちると精神力も落ちてわざわざインターネットしたりアニメみたりする気も無くなってきますから、筋肉を鍛えよう。 back to index of texts Site Search

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

行ったらブログ書けって言われたので。 HUB のビールはおいしかった HUB のビール以外もたぶんおいしかった あとはだいぶ記憶がない 会場の入り口に HUB があるというのは致命的な脆弱性で、まずは駆けつけ一杯みたいな感じでビールを沢山飲んでからトークを聞くみたいになってしまう。結果としてトークの内容を全然理解できないで帰ってくることになる。というかいつどうやって会場をでてどうやって帰ってきたのかとか全然記憶が無い。 とはいえなんかもう Perl の話はあんまりなくて、いろんな言語にまたがるふわっとした話が多い感じだったのでそんな感じの参加態度でいいかなとか思っている。 Web 開発もモバイル開発も思想は完成されていて、あとはどう大トラフィックに耐えるかとか、思想の実践をいかに洗練させていくかみたいな状態になっているのでまあふわっとした話が多いのはそういうことだと思う。しかしそうやって油

前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか？ メリットはあります。金です。 Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使える Amazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。 Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージを Google Drive でごまかしごまかし運用したと

以前から面識のあった小林銅蟲が糸柳なども来る飲み会があるなどと言うので、銅蟲のことをあんまり知らない shunirr なども連れて横浜までいってきた。松浦だるまなどもいてマンガの話をする。絵の話をする。肉が焼かれる。肉が食べられる。犯罪者も出席しており、罰金の督促状みたいなものが回覧される。肉が焼かれ、肉が食べられる。そういう会でした。 何を主に言いたいかというと ゆいゆい検索 http://shunirr.hatenablog.jp/entry/2014/04/10/143119 このような感じのことをしている異常者と松浦だるまに面識があるということです。だるま先生塩の件よろしくお願いします。 back to index of texts Site Search

これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip

コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ