ログに残したくない情報 Webアプリケーションを開発していると時々生のままではログに残したくない情報ってありますよね。 パスワード、クレジットカード番号やCVCなんかは残したくないものの代表じゃないかと思います。 よくやる方法 initializersの中でこういうコードを入れるか、 Rails.application.config.filter_parameters += ['password', 'card_number']

「Gartner's 2016 Hype Cycle for Emerging Technologies Identifies Three Key Trends That Organizations Must Track to Gain Competitive Advantage」から、縮小のため一部改変。赤線はPublickeyによる ハイプサイクルは、技術の登場から安定までを以下のステージに分けて説明したもの。 黎明期（Innovation Trigger） 「過度な期待」のピーク期（Peak of Inflated Expectations） 幻滅期（Trough of Disillusionment） 啓蒙活動期（Slope of Enlightenment） 生産性の安定期（Plateau of Productivity） 2016年版のハイプサイクルの中から、注目されるキーワー

Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内

アプリケーションのUI（主にGUI）の設計・評価をする際、ほとんどの場合は評価の範囲が画面（ページ）単位で行われることが多く、この設計・評価のフォーカスの粒度についてもっと考えたほうがいいのではないかと最近よく思います。 画面単位での評価をしていてよくあることは…画面 A 画面 B どちらにもリストがあり、そのリストは同じリストアイテムを表示していたりする場合でも、 「画面 Aとリストがー…」 「画面 Bのリストがー… 」 と同じリスト要素なのに画面単位で話をしてしまうことがよくあります。これはかなり無駄なことをしているように思えます。 もちろん、《そのデザイン要素はどういうコンテクストなのか》を議論する上で画面を持ち出すのは必要な事と思いますが、そもそもそのコンテクストは何に依存するものでしょうか？ それはコンポーネントとして分解していくと実は画面そのものにあまり依存していない事が見えて