ssig33.com - なぜ SPA か
顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
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 - DHH についての見解
DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話
ssig33.com - DCI の話 - Ruby On Rails Advent Calendar 乱入
乱入します。そういうのあるのか調べてないけどどうせあるでしょ。あんまりまとりないです。 DCI か Concern かみたいな話です。 Rails のファットモデル対策 これの続き。 module に切り出す粒度はどうするかとかこれはこれで難しいとろはあるのですが という部分について適当に書いておく。 まず DCI というアプローチではモデルが肥大化するという問題は本質的に一切解決していない。結局のところさまざまなコンテキストで責務が呼ばれた結果最終的に生成されるドメインモデルは極めて巨大なものであることに変わりはない。 結局のところ、改善されるのは「コードの見た目」に過ぎない。しかしながら我々プログラマーは「コードの見た目」が如何に重要であるか知っている。コードの見た目はプロダクトの品質のかなりの部分を占める。 DCI というアプローチは単純に Concern するという戦略と何が違うか
ssig33.com - ダンピングをするな
これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip
ssig33.com - エリック・エヴァンスのドメイン駆動設計読んだ
昨日の夜買って読み始めたら朝の 10 時に読み終わった。いろんな人がいろいろ感想書いてるからごちゃごちゃ書くことはしない。 「利口な UI」というコラムが序盤にあった。これは「バカにプログラミングさせるとビューにロジックが集中する」「かといってバカにはモデル駆動開発は無理」という話です。極めて説得力を感じるのですが、この問題に関して最後まで読んでも特に解決策は載ってませんでした。 優秀なエンジニアがその辺にいくらでも生えてるということは稀なので、教育とかいう難しいやつをやる必要がある(難しい) — トデス子 (@todesking) February 22, 2014 というようなのが現実だと思います。ここから得られる課題は、「利口な UI」しか書けない人をどのようにモデル駆動開発に耐えられる専門家に教育するかという点です。 ある程度の人間が「ビジネスサイドの人間と会話する共通の言語を基に
ssig33.com - VAIO Pro を Linux で使う + バッテリー延命
VAIO Pro 11 を買いました。大変に軽量でよいコンピューターだと思います。鞄に入れていても「あれ PC 持ってくるの忘れたっけ」とかなること結構あります。タッチパネル着けてないので重量は 770g でさすがに軽量です。 これまでこういうふうに持ち歩くにあたって一切負担の無い重量のコンピューターは多々あったとは思うのですが、ミドルレンジ以上の性能を持っていて作業環境として十分に使用できるものは少なかったように思います。 というわけで僕は Web 系の技術者でもありますから Linux で使っていくことになります。 インストール ここ読んどけって感じなのですが、この解説も若干古くなっているので適当に書いておきます。 Debian は stable が普通にインストールできます。 Ubuntu は 13.04 では駄目らしいので 13.10 の Daily Build を使うといいと思い
ssig33.com - Windows マシンを買うべき理由
タブレットと呼称される計算機にあっても少しづつ Windows の存在感が増してきている昨今です。僕はいまのところ Android や iPad ではなくこの Windows が普及することが望ましいと考えています。それは以下の理由からです。 Visual Studio と VirtualBox が現実的に動く 「iPad こそが完璧なダイナブックだ」などと言っている人が一時期いましたが、プログラミングが不可能なこの機械がダイナブックなどであるわけがありません。パーソナルコンピューターだとも若干言い難いものでしょう。 Android では開発環境がいくつかありますがどれもまあ使いたくなるような代物ではありません。 ところが Windows では液晶サイズが 8 インチで 350g のタブレットで Visual Studio などの本物の開発環境が現実的に動きますし、 VirtualBox
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 - 機密情報をどうやりとりすればよいか
機密にGmail使うなって言ってんだろ: やまもといちろうBLOG（ブログ） この人の話とか反応したら負けだと思うんですが、あまりにも内容が酷いと思うので。 まず Gmail が信用できないというなら何を信用しろという話になるんでしょうか。 「アメリカ法人のサービスなんだから」信用できないという話ですが、現実問題としてアメリカの諜報機関がアメリカ法人のサービスを盗聴するのは大変めんどくさい手続を踏んでいるわけです。 一方 CIA が NSA と協力して外国の会社を盗聴するとか、 CIA が日系人の工作員を日本のサービスプロバイダに潜り込ませるとか、そういうのであればアメリカ国内法の問題は一切発生しないわけです。どちらが工作員に情報を詐取されるリスクが大きいか考えるべきだと思います。 そもそも一切機密情報をメールで送るべきではありません。この点について Amazon のアプローチを参考にすべ
ssig33.com - EC サイトの使用を即刻辞めろ！！！
要約: EC サイト運営者が Google Groups を経由して個人情報を大公開する事例が多々あります 現在話題になっている以下のニュース Googleグループに残る「非公開のつもり」のメーリングリスト 公開範囲設定に注意を http://www.itmedia.co.jp/news/articles/1307/11/news045.html に関連して、いろいろと検索をして遊んでいたのですが、最初は 会議 go.jp 出演 交渉 とかそんな感じのワードで検索して組織に関する情報を探し出しては喜んでいました。しかし検索ワードをちょっと工夫すると（どのように工夫するかは伏せます）、一般人の個人情報が沢山出てくることに気付きました。 以下のような実態があります 「**** という商品を買いたいのだがこれに **** は付属しているか」という問い合わせが本名つきで晒されている オタクグッズを
ssig33.com - なぜメールを大量に高速に配信する為に Erlang は必要なのか
Erlang の国内での活用事例として 1 時間あたり300万通のメール配信するメール配信サーバー というのがよく知られています。ですがこれ 1 秒あたりにすると 833 通なので一見全然凄くなさそうに見えます。 833 通ならスクリプト言語のスレッドでも十分に達成可能やで。 しかしメール配信の本質というのはそこではありません。国内においてメール配信とは携帯電話のキャリアメール宛てに行なうものです。携帯電話のキャリアメールには 同一 IP アドレスから大量にメールを送るとハネる 同一ドメインから送るとハネる とかそういうのがあります。それを越えるのは複数拠点（物理的な距離が離れている必要はありませんが要件上ネットワーク的な距離は離れることになります）に大量のマシンを用意しそれを連携してメールを送信する必要があります。 そういう環境で大量のマシンを連携させて一つのシステムとして動作させるには
ssig33.com - ネイティブアプリ並のウェブアプリを云々
なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ssig33.com - 東亜飯店に行ってきた