ssig33.com - なぜ SPA か
顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな
ssig33.com - テレビ番組をノベルゲーム風にするものを作った
と言ってもなんのことか分からないと思うので現物を見てもらうのがいいかと思う。動画 H.264 な MP4 なので Firefox （と多分 Opera）では見られないと思います。 J と K で進んだり戻ったりできます。 字幕情報から諸々組み立てているので字幕がある番組じゃないと駄目。あとブラウザで動いてます。 番組の質にもよるが、 1 時間ぐらいの番組を 5 分とかで内容が把握できるのでかなり便利だと思う。特にドキュメンタリーや教育番組では有効。 字幕情報をパースする奴とかその辺に転がってるのでその気になれば 30 分もあれば作れます（作った）。 back to index of texts Site Search
ssig33.com - Docker 運用しまくって得られたしょぼい知識
よく知られているように Docker ではコンテナ自体は使い捨てで、アプリケーションが保持すべきデータはコンテナの外に格納する必要があります。 RDBMS 多くのアプリケーションが RDBMS を使用しています。 RDBMS の運用は実際のところかなり厄介ですが、まあ Amazon RDS を使っちゃいましょう。それが一番楽です。 EC2 じゃないところにサーバー置いてて RDS との通信量課金を払いたくないという場合は適宜頑張ってください。 Redis と memcached 現代の多くのアプリケーションが Redis や memcached を使っています。これも Amazon Web Services に ElastiCache があるので EC2 にサーバー置いてる場合はこれを使います。置いてない場合は適宜頑張ります。 その他 ここまでのことは特に何ということもないのですが、ここか
高密度小池 ／ 中学受験とか
中学受験とか 昔中学受験とかいうのをさせられた。 別に自分でしようと思ったのではなく、当然親の意志。父親は超大企業のエリートで、バブル期に家を買うようなこともしてなかったので経済的に余裕がある家庭だった。なんか底値のころに家買ってた記憶がある。杉並区の駅まで徒歩十分のそこそこの広さの土地が 4500 万円とかの頃。 小学五年生の春から中野坂上にあった日能研に通っていた。日能研は成績順でクラス決まるとかいうシステムだったと思うけど、一応一番上のクラスだった気がする。 その中野坂上の日能研だったけど、算数の先生の体臭が臭くて耐えがたかったので親に泣き付いて吉祥寺の日能研に移った。あの人以上に体臭がキツい人に結局出会っていない。 吉祥寺の日能研には体臭が臭い先生はいなかった。かわりに理科の先生が生死に問題がありそうなレベルで太っていた。 吉祥寺の日能研でもなんか一番上のクラスにいた記
高密度小池 ／ Rails で非同期処理
Rails で非同期処理 1.何故非同期処理が必要か Rails に限らず Web アプリケーション全体の話。クローラーとかバッチ系のものはとりあえず置いときます。 Web アプリケーションとはリクエストに対して処理を行ないレスポンスを行なうものですが、 1 リクエストにつき何個の処理があるというのはそれなりによくあることだと思います。仮にリクエストに対して 3 個の処理があったとします。 通常では、 3 個の処理が全て終ってからレスポンスを返すことになりますが、例えば処理 A B C がそれぞれあったとして、レスポンスには処理 A B の結果のみが記されていて C の結果はレスポンスには含まれないとします。 この時、処理 C が時間がかからず終わるものならば大した問題にはなりませんが、処理 C が極めて時間がかかるものだったとすると、全体のレスポンスが遅くなってしまいます。
高密度小池 ／ 産経新聞取材ログ
産経新聞取材ログ 産経新聞に金くれが掲載されました。 http://sankei.jp.msn.com/economy/it/091029/its0910290748001-n1.htm 【Ｗｅｂ】ネットで長者かおねだりか 不景気反映？ 夢と危険性混在 その取材のログです。 サイト「金くれ」管理人様 拝啓 突然のメールにて失礼いたします。 私、産経新聞社のweb面担当記者の織田淳嗣と申します。 私どもは現在、ネットを通じての募金活動や物々交換について取材を進めているところですが、 このたび、管理人様が設立されましたサイト「金くれ」について質問させていただきたく、メールをお送りいたしました。 一部、他紙の質問と重複するかと思いますが、以下、ご回答をよろしくお願いします。 ・サイト設立の動機、設立年月日、現在の登録者数について教えてください。 ・多数の登録があるようで
高密度小池 ／ サン牧の本質的な問題
サン牧の本質的な問題 サン牧には問題がいくつかあって、表面的なことを言えば、 OpenSocial にちゃんと従っていないという点と、外部課金回りに重篤な不具合があるという二点です。 OpenSocial に従っていないという点は、 mixi がわがしっかりした作りになっているので、これはさほど問題になりませんが、外部課金のお粗末さはかなりのものと言えます。 ここでサン牧運営の Rekoo の技術力やモラルの問題を糾弾するのは簡単で面白いことですが、これもあまり本質的ではないと思います。 結論から言うと、本質的な問題は mixi が mixi アプリの提供を急ぎすぎたことであると僕は思っています。 mixi アプリは、資金を集めるために始められたサービスであると理解するのが、やはり正当かと思いますが、 mixi にマネーなり話題なりを集めるサービスを mixi アプリ上で展開して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高密度小池 ／ 楽天テクノロジーカンファレンスで LT を行ないました