ssig33.com - 自動運転車が奪うもの
自動運転が社会に浸透する結果ドライバーが無職になる！！大変！！という話ばかりを見るような気がしますが、事態はもっと深刻なのではないでしょうか。 自動運転タクシーが社会に浸透し、定額乗り放題プランが普通となり、そして車を所有するよりも定額乗り放題を契約するほうが遥かに安いという日は、すぐに来るでしょう。そのようになった日、誰が車を買うだろか、という問題があります。 そのような日、車の需要とは自動運転タクシー会社の消耗分のみになるでしょう。一部超高級車や趣味性の高い車は依然として需要が残るでしょうが、それらの需要では大した雇用を生まないことは分かりきっています。 車の需要が大幅に減少する結果として車一台一台のコストは上昇するでしょうが、いずれにせよ自動車製造業という莫大な雇用がほぼ消滅に追い込まれることは確実なのではないでしょうか。 また住宅の需要という問題もあります。通勤/通学の時間が多少伸
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 - 最悪！意地でも Heroku を無料で使う
Heroku は最近料金体系に変更があって、無料では一日 18 時間までしかアプリを起動できなくなりました。 自分専用のアプリとかそういうものなら全く問題はないのですが、それなりにユーザーがついているようなアプリだとなんだかんだで 24 時間 Dyno が起動しっぱなしということはおおいと思います。 一番安いプランは 7 ドルで、とりあえずこれだけ払えば 24 時間 Dyno を起動しっぱなしにできます。 公開しているアプリが 1 個ならまあ 7 ドルぐらい払っとけよで済む話なのですが、私のように 18 時間制限にひっかかってるアプリが 30 個もあるとなると 210 ドルを払うのは躊躇してしまいます。 ということで今日は石に齧りついてでも Heroku をタダで使う方法を考えていきます。 基本的なアイディア Heroku でアプリ 2 個用意して、同じ DB 向くようにして、 12 時間
ssig33.com - 最近見つけた意外な XSS
ほぼ出オチに近いんですが。 これで発動する XSS を実際に見かけました。 iOS アプリと Web アプリが両方あるアプリである Web アプリがわにアカウントにひもづいているデバイスを一覧できる画面や投稿元デバイス名が表示される画面がある そこでデバイス名がエスケープされてない という事例です。一昔前は Rails や CakePHP やらがテンプレートエンジンで普通に HTML を出力すればエスケープしてくれたものですがが、最近は JavaScript で HTML を構築することが多く、手動でエスケープするような暗黒時代に戻ってしまっている感があります。 「たいていのところはちゃんとエスケープしてあるけど、↑のような意外なところが抜けてたりする事例があります。 iOS のデバイス名由来のものについては簡単に調べた結果 3 件ほど XSS を見かけたので、それについては報告はしておき
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 - Docker 運用しまくって得られたしょぼい知識
よく知られているように Docker ではコンテナ自体は使い捨てで、アプリケーションが保持すべきデータはコンテナの外に格納する必要があります。 RDBMS 多くのアプリケーションが RDBMS を使用しています。 RDBMS の運用は実際のところかなり厄介ですが、まあ Amazon RDS を使っちゃいましょう。それが一番楽です。 EC2 じゃないところにサーバー置いてて RDS との通信量課金を払いたくないという場合は適宜頑張ってください。 Redis と memcached 現代の多くのアプリケーションが Redis や memcached を使っています。これも Amazon Web Services に ElastiCache があるので EC2 にサーバー置いてる場合はこれを使います。置いてない場合は適宜頑張ります。 その他 ここまでのことは特に何ということもないのですが、ここか
ssig33.com - Rails のファットモデル対策
http://37signals.com/svn/posts/3372-put-chubby-models-on-a-diet-with-concerns これ読めばいいんじゃねえかと思います。 Rails を設計している人達は module に切り出せばそれでいいだろ糞 include された結果生成されるドメインモデルが超絶巨大だろうが知ったことか糞 という発想で生きていることが伺えます。 module に切り出す粒度はどうするかとかこれはこれで難しいとろはあるのですが簡単な考え方ですし、現実的な落とし所がこの辺にある場合は多いと思います。 無意味に複雑なやり方を導入しようとする人間を殺せ。 back to index of texts Site Search
ssig33.com - 運営と技術者の距離を近くして開発効率を上げよう！！！
みたいの結構良さそうな感じがするんですが。実際そうではないです。 運営はユーザーからのクレームやサービスの問題点を大声で議論をします。エンジニアは大抵気が弱いので四六時中聞かされていると会社を辞めてしまいます。 また運営は四六時中エンジニアから「そんなこと言いますけどそれ実装するの無理です」と言われ続けますからストレスで会社を辞めてしまいます。 そうして誰もいなくなる。残るのは悪意に鈍感なウスノロだけでそんな奴は使い物になりません。なので大抵の場合運営と開発はある程度物理的に距離をとってしまうほうがよいです。 ですがまあ距離を近くしよう的な策が取られることが多いです。これは何故かというと、「企業家」「経営者」といった連中は上記のような地獄をとおりぬけてきた人間や、それをなんとも思わないような人間だからです。その辺こういう話に近いと思います。 雇われてるだけの人間は精神壊す前に逃げましょう。
ssig33.com - 山本一郎さんからメールがきました
ロシアでも国内情報機関の機密情報についてアメリカ製サービスの問題だけでなく、インターネットそのものに対する信頼性が欠落しているということで対策を打っているのと同様に、日本でも安全保障や重要な行政に関わる情報についてはネットをなるだけ経由しない方法を検討するべきというのが主張です。 というメールがきました。ですので機密にGmail使うなって言ってんだろ: やまもといちろうBLOG（ブログ）というこの記事は、日常のあらゆる箇所において外国の諜報機関の人間を警戒しなければならないような人がアホなことをしていて辛いみたいな話らしいので、皆さんにおかれましては全く関係の無い話です。 ついでに mixi が倒産すればいいと思いました。 back to index of texts Site Search
ssig33.com - 機密情報をどうやりとりすればよいか
機密にGmail使うなって言ってんだろ: やまもといちろうBLOG（ブログ） この人の話とか反応したら負けだと思うんですが、あまりにも内容が酷いと思うので。 まず Gmail が信用できないというなら何を信用しろという話になるんでしょうか。 「アメリカ法人のサービスなんだから」信用できないという話ですが、現実問題としてアメリカの諜報機関がアメリカ法人のサービスを盗聴するのは大変めんどくさい手続を踏んでいるわけです。 一方 CIA が NSA と協力して外国の会社を盗聴するとか、 CIA が日系人の工作員を日本のサービスプロバイダに潜り込ませるとか、そういうのであればアメリカ国内法の問題は一切発生しないわけです。どちらが工作員に情報を詐取されるリスクが大きいか考えるべきだと思います。 そもそも一切機密情報をメールで送るべきではありません。この点について Amazon のアプローチを参考にすべ
高密度小池 ／ Twitter の Streaming API を使って Web アプリケーションを作りました
Twitter の Streaming API を使って Web アプリケーションを作りました http://nl.amatz.com/ nicoline Twitter の Streaming API でニコニコ動画関連と思われる発言を地引してきて、ニコニコの API とマッシュアップしてタイムラインとして再構成するサービスです。 ある Twitter ユーザーがニコニコでどういう動画を見ているかであるとか、ある動画には Twitter でどういう反応があるかとか、ある動画を見てる人は他にどういう動画を見ているか、といったものが監視できます。 現在追加で開発中の機能としては、あるユーザーについて、視聴傾向が似たユーザーをリストアップするだとか、そんなの作ってます。作ってますっていうかコード自体は仕上がってるのですが、驚異的に遅いのと（Fiber&NeverBlock とか使って
高密度小池 ／ たった 3 秒で驚くほど手を清潔にする方法
たった数秒で驚くほど手を清潔にする方法 otsuneさんから教えていただきました。 なんと、手を洗う際に、水だけでなく石鹸を使うと効率よく汚れをおとせるそうです。 いやはや、石鹸は流しなどには必ずと言っていい程置いてありますが、手を洗うのに使うというのは全く気付きませんでした。 これを応用して、洗濯をする時は、洗剤を一緒にいれると、汚れが確実に取れるそうです。なんとも、これも盲点でした。 他にも、プリウスはアクセルを踏むと、なんと速くなるといった情報も教えていただきました。 似たような事例として、掃除機のスイッチを「強」にすると吸い込みが強くなる、というものもあるそうです。是非試してみたいと思います。 それから、 2008 年頃の Cyber Agent さんのプレゼンで知りましたが、 MySQL にインデックスを張ると、なんと速くなるそうです！！！ 2008 年にこういう
高密度小池 ／ Rails で非同期処理
Rails で非同期処理 1.何故非同期処理が必要か Rails に限らず Web アプリケーション全体の話。クローラーとかバッチ系のものはとりあえず置いときます。 Web アプリケーションとはリクエストに対して処理を行ないレスポンスを行なうものですが、 1 リクエストにつき何個の処理があるというのはそれなりによくあることだと思います。仮にリクエストに対して 3 個の処理があったとします。 通常では、 3 個の処理が全て終ってからレスポンスを返すことになりますが、例えば処理 A B C がそれぞれあったとして、レスポンスには処理 A B の結果のみが記されていて C の結果はレスポンスには含まれないとします。 この時、処理 C が時間がかからず終わるものならば大した問題にはなりませんが、処理 C が極めて時間がかかるものだったとすると、全体のレスポンスが遅くなってしまいます。
高密度小池 ／ スーパーコンピューター
スーパーコンピューター 1.当初の目的は、ベクトル計算機を作ることだった 2.富士通の他には、 NEC とかが参加してた。 NEC いないとベクトル計算機は作れない 3.プロジェクト失敗して NEC 抜けた 4.でもコンピューターいれる建物だけは作っちゃった 5.富士通一社で作るよ！！ 6.富士通、なんと SPARC を沢山乗せたコンピューターを作ると言い出す 7.世界の趨勢は、 x86-64 なマシン、つまり普通のパソコンの凄い奴、だってその方がアプリケーション開発楽だから こういう情勢で、例のスーパーコンピューターを国の金で作るべきとか言ってる人は頭おかしいか富士通や Sun の利害関係者なのではと思う。 それに富士通にまともなプロダクトが作れると思ってる人マジウケる。 はっきり言って、もう日本に画期的かつ世界水準のスーパーコンピューターを作る技術力などない。それは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
