ssig33.com - シン・ゴジラ感想
本作のゴジラは非常に強力な防空火力を誇っておりこの問題への対処は物語の鍵の一つとなっている。今日はこの問題について考えていきたい。 本作においてゴジラの強力な外皮を貫通するために地中貫通爆弾を B-2 爆撃機から投下するシーンがある。当該爆弾自体は現存しないためこれは架空の兵器であるが 長細い外見にすることで空気抵抗を減らす 高高度から投下する ということで終端速度を上げて貫通力を上昇させるという実在の地中貫通爆弾と同じアプローチであることが想像される(僕の見間違いでなければこの爆弾の弾体は GBU-28 などに似ていたように見える)。 実際の運用でこの手の爆弾がどれくらいの高度から投下されるのか僕はよく知らないのだが 投下高度が低すぎると貫通力が減衰する 投下高度が高すぎれば例え誘導爆弾と言えど精度に問題が出てくるはず という問題を総合して考えると高度 6000m ほどから投下すると考え
ssig33.com - 日本人がいまいち情報社会にフィットできない理由
日本の情報社会がいつからはじまったかという問題についてまず考えてみます。いやその前に情報社会とは何かという問題について考える必要があるかもしれない。ここは面倒なので、情報が機械により大量生産され機械により消費、加工される社会ということにしておきます。 サプトンの発明、新聞社への普及をもって日本の情報社会が達成されたという考え方は、日本社会の情報化を最もはやく見積る考え方の一つだと思います。ただし、これはいくらなんでも無理があるのではないかと思います。 あるいは、 1960 年代末からのカナモジタイプライターやテレタイプの企業への普及をもって日本社会の情報化がなされたと考える人もいるかもしれません。 しかし、現実にはこれらのシステムは非常に限定された帳票の作成の機械化にのみ用いられていたというのが実態で、こうしたシステムをもって企業内の情報作成、処理の全面機械化を達成していた企業はかなり限定
ssig33.com - 君の名は。そして銀河帝国とその時代
君の名は。という映画をみたところ大変に感動しました。 この映画では二人の人間の意識をつなぐという形で時間遡行が行われます。そしてその時間遡行/超越能力は主人公である宮水三葉の一族に相伝されてきた能力であることが示唆されます。 そしてその宮水の一族が暮らす糸守町は何度も隕石による災害を受けてきました。確認できる限り最低二回、あるいは三回もの隕石の直撃を受けています。 隕石だと確実なもの 御神体クレーター 作中のメインイベントである 2013 年彗星災害 不確実 糸守町の隣にあるクレーター状の湖 また彗星の軌道が非常に不可解であることが有志により指摘されています。 これが意味するものは何か。それはティアマト彗星とは自然現象ではなく糸守の排除を目的としている軌道爆撃機だということです。作中でもティアマト彗星の分離が自然現象としては説明し難いということが解説されており、同じ個所を何回も隕石が衝突す
ssig33.com - 最悪！意地でも Heroku を無料で使う
Heroku は最近料金体系に変更があって、無料では一日 18 時間までしかアプリを起動できなくなりました。 自分専用のアプリとかそういうものなら全く問題はないのですが、それなりにユーザーがついているようなアプリだとなんだかんだで 24 時間 Dyno が起動しっぱなしということはおおいと思います。 一番安いプランは 7 ドルで、とりあえずこれだけ払えば 24 時間 Dyno を起動しっぱなしにできます。 公開しているアプリが 1 個ならまあ 7 ドルぐらい払っとけよで済む話なのですが、私のように 18 時間制限にひっかかってるアプリが 30 個もあるとなると 210 ドルを払うのは躊躇してしまいます。 ということで今日は石に齧りついてでも Heroku をタダで使う方法を考えていきます。 基本的なアイディア Heroku でアプリ 2 個用意して、同じ DB 向くようにして、 12 時間
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
ssig33.com - Docker を個人が使う時の注意点
Docker が何かとかそういう話は全部抜きにして書きます。 Docker においてよくある運用は どっかにプライベートなレジストリを立てる ローカルかなんかでビルドしたコンテナをそこにプッシュする 実際の実行環境ではそれを pull してきて起動 という感じではないかと思います。 3. の後にリバースプロキシだのなんだのいろいろ設定しないといけませんから、それは各種自動化フレームワークが用いられます。 ここまではいいのですが、問題は 2 です。 Docker は 2 をやるごとにほぼフルの Linux 環境をネットワーク経由でアップロードするということになります。これが案外バカにならなくて、測定してみたところこの二週間でこれでのアップロードの合計は 350GB ほどになっていました。 もうちょっと激しくなるとプロバイダの設定する帯域規制だったり強制解約要件にひっかかってしまいますし、単純
ssig33.com - Rails アプリでのビューキャッシュ戦略
キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ
ssig33.com - AWS Elastic Beanstalk メモ
最近ちょこちょこ触ってみて得られた知識。 Beanstalk 専用に AWS アカウントを作ったほうがよい 試行錯誤と共に膨大な量の Security Group が作られていって意味不明な事態になる Beanstalk に Environment を作る時に一緒に RDS を作らないほうがよい スワップしてデプロイするやつが使えなくなる。 正確には使えないわけではなくて、 RDS の設定をアプリケーションに直接記述すればよい。 RDS と紐づいていない Env からは環境変数が見えない。なので環境変数から設定読み込むやつが使えなくなる。なので一緒に RDS 作るのは意味がないし管理が複雑になる。 スワップしてデプロイするやつは初期に設定しておきましょう。 そうじゃないと上記のようなめんどくさいことが起きます。 Beanstalk はデプロイスクリプトの実行に 10 分かかるとデプロイを勝
ssig33.com - Docker 運用しまくって得られたしょぼい知識
よく知られているように Docker ではコンテナ自体は使い捨てで、アプリケーションが保持すべきデータはコンテナの外に格納する必要があります。 RDBMS 多くのアプリケーションが RDBMS を使用しています。 RDBMS の運用は実際のところかなり厄介ですが、まあ Amazon RDS を使っちゃいましょう。それが一番楽です。 EC2 じゃないところにサーバー置いてて RDS との通信量課金を払いたくないという場合は適宜頑張ってください。 Redis と memcached 現代の多くのアプリケーションが Redis や memcached を使っています。これも Amazon Web Services に ElastiCache があるので EC2 にサーバー置いてる場合はこれを使います。置いてない場合は適宜頑張ります。 その他 ここまでのことは特に何ということもないのですが、ここか
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 - Docker をプロダクトのデプロイに使う
コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。 Docker の利点と欠点で 開発環境の配布が容易にできる プロダクトのデプロイにつかうにはなにかとキツい みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。 Docker をデプロイに使う際の問題点としては以下があります Dockerfile に 42 個しか命令かけないみたいなやつ なんだかんだでコンテナのビルドに時間がかかる コンテナの管理とかどうするのか リバースプロキシの設定とかどうするのか 一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ
ssig33.com - 退職時に古巣に砂をかけるべきではないのかという問題
結論: 程度問題だし個別に判断しろ この辺に関する話 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 プロジェクトそんなに売り上げたってないっぽい
ssig33.com - なぜメールを大量に高速に配信する為に Erlang は必要なのか
Erlang の国内での活用事例として 1 時間あたり300万通のメール配信するメール配信サーバー というのがよく知られています。ですがこれ 1 秒あたりにすると 833 通なので一見全然凄くなさそうに見えます。 833 通ならスクリプト言語のスレッドでも十分に達成可能やで。 しかしメール配信の本質というのはそこではありません。国内においてメール配信とは携帯電話のキャリアメール宛てに行なうものです。携帯電話のキャリアメールには 同一 IP アドレスから大量にメールを送るとハネる 同一ドメインから送るとハネる とかそういうのがあります。それを越えるのは複数拠点（物理的な距離が離れている必要はありませんが要件上ネットワーク的な距離は離れることになります）に大量のマシンを用意しそれを連携してメールを送信する必要があります。 そういう環境で大量のマシンを連携させて一つのシステムとして動作させるには
ssig33.com - サブドメインを沢山使いたい
http://kure.ssig33.com http://darui.ssig33.com http://nemui.ssig33.com みたいのを沢山作ってコンテンツをそこに置きたい。めんどくさいことはしたくなくて、設定ファイルをいじるのは最初の一回だけにしたい。コンテンツの更新はブラウザ経由でやりたい。置きたいコンテンツは精々静的な HTML 一枚。 そんな需要が僕にはあったので解決してみた。 もともと ssig33.com は Sinatra で作ったアプリで、その前段に nginx がいるという構成になっていた。 nginx の設定は upstream ssig33.com{ server localhost:9233; } server { listen 80; root /home/ssig33/dev/site/public; index index.html index
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - 4 月にエンジニアとなった人たちに知っておいてもらいたいこと