ソフトウェア名については気にしないのが良さそうです。kawaiiはごく単純に言えばgetUserMediaを使った顔認識ソフトウェアになります。以前紹介したHTML5 Face DetectionはHTML5のvideoタグを使っていましたが、こちらはそれをベースにgetUserMediaにしています。 さらに顔を認識するだけでなく、顔の上に画像をかぶせて表示しているのが特徴となっています。 kawaiiの使い方 カメラへのアクセスを許可すればこんな感じで表示されます。 顔の動きにもきちんとついてきますが、手を間に入れたりするとずれます。 HTML5は様々なAPIが追加されていますが、Webカムを使った技術は特に面白いですね。ぜひ自分の顔で試してみてください。 kawaiiはHTML5/JavaScript製のソフトウェアです。 HTML5 Face Detection - JavaScr

gulpのタスクは基本的に非同期で実行されます。例えば以下のコードでは、ファイルコピーが完了する前に "done" と表示される可能性があります。 gulp.task('copy', function() { // ファイルをコピー gulp.src('src/file').pipe(gulp.dest('dest')); }); // copyに依存するタスク gulp.task('done', ['copy'], function() { // ファイルコピー完了「前」に実行される！！ console.log("copy done"); }); gulpが高速に動作する理由の一つはこの非同期性ですが、どうしても同期的に処理したい場合（すなわち特定のタスクの完了を待ってから別なタスクを実行したい場合）もあると思います。 この記事では同期的にタスクを実行する方法として、gulp API d

セッションについて Railsのsecret_tokenの意味がよく分かってなかったので少し調べたことのメモ。まず「セッション」という概念について。 セッションとHTTPというステートレスなプロトコル上において、一連の通信、およびそれを実現するのに必要な「状態」を記憶しておく仕組みのことだ。もうちょっと噛み砕いてみる。 よくあるたとえだけど、以下のような流れを考える。 あるショッピングサイトにアクセスする。 ↓ ログインする ↓ Ａを買い物かごに入れる ↓ Ｂを買い物かごに入れる 当然私たちの脳内文脈では、「ログインした後」に「商品をかごに入れてる」んだから何もおかしなことはないわけだけど、最初の方に書いた文章を思い出してもらうと、 HTTPというステートレスなプロトコル とある。つまり、素のままだとログイン後に送る通信の上に「私は今ログインしていますよ」、という状態情報を乗せることはでき

先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

エンジニアがアプリ担当とAPI担当で分かれているチームで、API担当のエンジニアがアプリ開発経験が無かったりすると、アプリ担当のエンジニアはどんなAPIがクライアントアプリにとって使いやすいのか、上手く伝えるのに苦労する事がありますよね?本記事はそんな場面でAPI担当のエンジニアに読んでもらう事を想定しています。 APIと型 アプリ側はRESTクライアントにRetrofitやRestkit等、既に広く使われているライブラリを使用する事が多いです。それらのライブラリは、オブジェクト・JSON間の変換機能があり、アプリ側ではJSON等シリアライズされるデータ形式を意識せずに、処理系上のオブジェクトをそのまま扱えます。即ちAPI経由でやり取りされるデータは全て型を持つのです。 例えばAPI側のコードで以下の様に定義されたクラスが

WEBサービスの通信を安全にするために、HTTPSを使って通信経路を暗号化する場合があります。Amazon ELBには、SSL Terminationという機能があり、これを使うと簡単にHTTPSが使えるようになります。 Elastic Load Balancing SSL Terminationを使うと、WEBサーバではなくロードバランサがHTTPS接続を受け、裏側にいるWEBサーバは単にHTTPリクエストを処理すれば済むようになります。 随分前のブログで少し怪しいですが、「既存のAmazon ELBにSSL証明書を導入してHTTPSを使えるようにする。」では、SSL証明書を購入してELBに導入しました。(ちなみに、現在はManagement Consoleからでも既存のELBに導入することできます。) 証明書を買うお金がない 本番環境はともかくとして、開発環境、ステージング環境などのた

Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。（改ざんをすると、検証時に失敗するので。） 全体的には、なんか変更できな

2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

Internet Explorer 11以下でSVGをmax-width: 100% (max-height: 100%)を使って親要素の幅(高さ)に合わせてリサイズしようとすると、SVGのアスペクト比が考慮されないバグがあった。width: 100% (height: 100%)や、SVGではなくPNGやJPEGなら大丈夫。max-*とSVGの組み合わせの時のみなぜか起こるバグ。 Demo: SVG Resizing Bug on ~IE11 デモのSVG画像とPNG画像は共に256x256。IE11以下のみ縦にびよ～んと伸びて(64x256で)表示される。併記したPNG画像ではIE11以下でもちゃんとアスペクト比が維持され真ん丸(64x64)で表示される。ChromeやFirefoxではSVGであろうとPNGであろうとちゃんと維持される。 img[src$=".svg"], img[s

jQueryのDeferredを用いたモダンなAjax処理の書き方が結構読んでもらっているみたいなので、今回はdeferred第二弾として、jQuery.Deferred is the most important client-side tool you haveの翻訳をしました。 jQueryのdeferredの導入は、近年のjQueryの歴史における最もパワフルな拡張だ。jQuery自体はとくに新しい概念ではないが、deferredの導入は多くのクライアントサイド開発者にとってメリットがある。非同期プロセスにおいてdeferredパターンはシンプルでありながらも、パワフルなツールだ。皆さんご承知の通り、クライアントサイドの開発においてそういった非同期を使う状況は数多く存在する。 ここでは、deferredおよびjQueryによって提供されるAPIについて概観する。読者が理解できるよう

ServiceWorker解説 – オフラインWebアプリケーション開発技術の最前線 岩瀬 義昌（HTML5 Experts.jp編集部） 今月上旬5月8日に、W3CよりServiceWorkerの草案初版が提示されました。ServiceWorkerは、オフラインWebアプリケーションの開発者が問題と考える点を解決する、非常に魅力的な仕様です。日本語の情報がほとんどないこのタイミングで、HTML5 Expert.jp編集部が解説いたします！ ServiceWorkerとは ServiceWorkerは、リソースの永続的なキャッシュを可能にする、およびWebアプリケーションのリソース要求の処理を可能にする新しい機能です。Webページを開く前であっても（ネットワークの接続/切断の有無にかかわらず）、独自の処理を挟み込めるのがポイントです。クライアント側に、一種のプロキシサーバがあるようにイメー

Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！ 白石 俊平（HTML5 Experts.jp編集長） 人気のCSSフレームワーク「Bootstrap」のバージョン3が正式にリリースされました。この記事では早速Bootstrap3をレビューし、特にグリッドシステムを掘り下げて解説してみます。 フラットデザイン採用、フルレスポンシブ！ Bootstrap2からの変更点のリストは、公式のリリース文を参照してください。特に大きな変更点は以下のとおりです。 フラットデザインの採用 現在流行のフラットデザインを採用しました。ただこれは「流行りに乗った」のではなく、テーマの一つとして提供されているという位置付けのようです。 例えば以下は、Bootstrap3のボタングループです。 レスポンシブWebデザインの全面採用 以前までのBootstrapは、レスポンシブWebデザイン

Tweet Tweet前回は、TCP/IPをベースとしたプロトコルであるHTTPの基本についてまとめた。ここでは、Webの成功理由とも言われる8つのHTTPメソッド、特にGET、POST、PUT、DELETE、HEAD、OPTIONSについて説明する。 １　8つしかないメソッド HTTPには、クライアントが行いたい処理をサーバに伝えるという重要な役割がある。HTTP 1.1においてその役割を果たすのが、以下の8つのメソッドである。ここでは、ほとんど使われていないTRACEとCONNECTを除いた6つのメソッドについて解説する。 GET　　　：リソースの取得 POST　　 ：子リソースの作成、リソースへのデータの追加、その他の処理 PUT　　　：リソースの更新、リソースの作成 DELETE　 ：リソースの削除 HEAD　　 ：リソースのヘッダ（メタデータ）の取得 OPTIONS   ：リソー

MDN のページのヘッダ部分に、開発者が使っているサービスについてのアンケートがあったので回答してみた。 内容は、開発の上で使える様々なサービスについてだったんだけど、その選択肢が知らないのもいくつかあっておもしろかった。 MDN のアンケートの選択肢にあがるってことは、今こういうサービスがメジャーなんだなーと思ったので貼っておく。 (ただし、 Code Hosting -> Github や IaaS -> AWS みたいな分かりきってるのは省く) ちなみにサーベイは以下。 load-test Loader.io LoadImpact.com Loadstorm.com browsertest SauceLabs BrowserStack W3C validators CrossBrowserTesting Browsera security Nessus WebInspect ? Ne

この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

結論#go 言語でウェブアプリケーション書くなら、go-bindata使うべし。 はじめに#go で書いたサーバは一つのバイナリに全部入るからデプロイが楽だという話がありますけども、それは全部のコードを go で書いた時だけです。 ウェブアプリケーションでは、ユーザインターフェース用のテンプレートファイルなど、どうしても go のコードではないリソースが発生します。 例えばテンプレートをパーズする標準 API を見ると、こんな風になっています。 html/template#ParseFiles func ParseFiles(filenames ...string) (*Template, error) { return parseFiles(nil, filenames...)}コピー この API 構造はソースコードを配置しているディレクトリ構造が単純だと特に問題ないのですが、少し複雑

Help us understand the problem. What is going on with this article? 仕事で Golang を使ってウェブアプリを作ることになりそうなので、どんな構成がいいのか考えてみる。あくまで前提ありきの選択なので、何でもかんでも適用できるわけではない。 JS や静的ファイル部分は今のところ考慮していない。単によく知らないので。 突っ込み大歓迎です。これいいよ！とか教えてください 前提 多機能なフレームワークよりシンプルなフレームワークに色々組み合わせる方法をとりたい。 開発者は数名程度。Golang に精通している開発者が 1 名いる。残りはこれから。 開発者は Django での開発経験が豊富な人が多い 全員ウェブ開発経験はそれなりに積んでいる。 HTML と JSON 両方のパターンが存在するのでテンプレートエンジンは重要。 JS