unsigned int v; //only works if v is 32 bit v--; v |= v >> 1; v |= v >> 2; v |= v >> 4; v |= v >> 8; v |= v >> 16; v++;
unsigned int v; //only works if v is 32 bit v--; v |= v >> 1; v |= v >> 2; v |= v >> 4; v |= v >> 8; v |= v >> 16; v++;
Qwintryチームは最近、既存のすべてのプロジェクトのフロントエンドをVue.jsに移行しはじめました。新しいプロジェクトでもVue.jsを使います。 レガシーなDrupalのシステム(qwintry.com) ゼロから新しく書きなおすqwintry.comのブランチ Yii2で動くb2bシステム(logistics.qwintry.com) その他、比較的小さめのプロジェクト(ほとんどは、PHPとNode.jsでバックエンドを構築しているもの) プロジェクトの規模についていうと、 Qwintry は世界中で約50万人の顧客が使っています。アメリカとドイツに倉庫を持っていて、アメリカ国内 最大の郵送先 のひとつで、東欧や中東への出荷に注力しています。Qwintryは、アメリカのオンラインストアでグッズを購入する人たちのためのツールです。私たちの倉庫に届いた荷物をコントロールパネルで管理で
データベースをクエリすると、一般的に、クエリにマッチするすべての結果を返すことが期待されます。最近、これがMongoDBには当てはまらないことを知り、驚きました。具体的には、クエリの実行中にドキュメントが更新された場合、更新前と更新後のドキュメントが共にクエリにマッチしたとしてもMongoDBのクエリが結果を返さないことがあるのです。MongoDBを使用する場合はこのようなことが起きることに注意し、クエリが犠牲にならないように気を付けましょう。 問題の発見 最近の私の主な仕事は、 Meteor Galaxyホストサービス のバックエンドの構築となっています。実行したすべてのコンテナの状態を含む多くのデータを MongoDB のデータベースで保存しています。コンテナは”起動中”、”正常”、”問題あり”、”停止”など、多くの状態を持っています。 我々のサービスのひとつが、データベースのポーリン
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか?」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
Goというプログラミング言語の強みの1つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす
パスワードにはうんざり。改善しましょう。 誰もが経験するあの瞬間。新しいサービスに登録し、パスワードを選んで入力する。でも、入れません。選んだパスワードは十分安全なはずなのに、使いたいサービスが独善的にそれを拒むのです。 記号、数字、大文字、小文字を少なくとも1つずつ使用しなければなりません。 小文字の長いパスワードの方がドルマークだらけの短いパスワードより安全だということを証明する、 XKCDの有名なコミック のことは忘れましょう。まず、あなたの主力パスワードが $$ICECREAM$$ だとします。アイスクリームは、恐ろしい人生の希望の灯火とも呼べるほどの大好物なので簡単に思い出せます。そして、このパスワードにはブートのための特殊文字が入っています。 残念なことに、 $$ICECREAM$$ には小文字と数字がないので、客観的に見れば安全ではありません。そこで、このサービスのためのパス
この記事でWeb開発の未来を垣間見ることができるでしょう。UIの構築やサーバ、データ・エンドポイントの新しい見解を得ることができると思います。ここで、ブラウザとサーバコードの両側を含めたフルスタックな話をしていきます。これを読めば、 完全に機能するGitHubリポジトリ で紹介されたすべてのコードの検証や実行ができるようになります。皆さまが開発者として次の資質を持っていることを前提に話を進めていきます。 JavaScript中級者 HTML中級者 クライアント/サーバ間通信の基礎知識 JSONの基礎知識 Node.jsの基礎知識 上の知識がなくても、 おそらく この記事の進行についていけるでしょう。しかし、知識がないと私の紹介するコードを現実的なシナリオあるいは重要なシナリオに応用するのは難しいでしょう。インターネットは情報の宝庫なので、理解に必要な概念などをたくさん提供してくれます。必要
私が好むと好まざるとに関わらず、誰もが私のWebアプリをiOS9の搭載されたiPhone 6SやNexus 6Pで、超高速Wifiに接続して使っているわけではありません。 現実は甘くありません。3Gでの接続や、古いハードウェアも珍しくありません。Googleのレポートによれば、 Androidのアクティブユーザは14億人 だそうです。彼らの多くは間違いなく、最先端ではないハードウェアを使っていることでしょう。 Androidのパフォーマンスについての Jeff Atwood氏の最近の記事 などを読んだことがあるなら、モバイルWebには希望がないように感じるかもしれませんね。 その記事からいくつか注目すべき文を引用します。 端的に言えば、今日最も高速なAndroidデバイスとして知られているものでも、新しいiPhone 6Sよりも5倍遅く、2012年代のiPhone 5上のEmberに比べて
(訳注:2015/11/1、いただいた翻訳フィードバックを元に記事を修正いたしました。) 成長し続ける様々な脅威に対抗すべく、この10年間でWeb認証システムは進化を遂げてきました。この記事では、架空のWebアプリケーション開発者とアタッカーのせめぎ合いを通じて、最新のセキュリティ技術がどのように様々な脅威に対抗することができるかを提示したいと思います。 以下のやり取りにおいて、ユーザはアタッカーが出現する前に、すでにディフェンダーでいくつかのトラストアンカー(パスワードやハードウェアトークンなど)を正規に確立していることが前提となっています。暗号は、時間や空間にわたって、既存のトラストや秘密を伝達する場合にのみ 使うことができます 。もし、トラストやセキュリティが確立される前にアタッカーがディフェンダーになりすましたとしたら、正規のものを見分けるのは極めて難しいでしょう。また、サイトには
Malwarebytes は、驚くべき成長を見せています。1年以上前にこのシリコンバレーの会社に入社して以来、私の主な仕事は急成長するセキュリティ企業の力となるシステムの設計と開発です。日々数百万人が利用する製品をサポートするために必要な、全ての基盤をつくります。私は12年以上、アンチウイルスとアンチマルウェアに関わるいくつかの会社で働いてきました。毎日処理する膨大なデータのせいで、これらのシステムがどれだけ複雑なものになるかを理解しています。 面白いことに、ここ9年ほどで私が携わったWebのバックエンド開発のほとんどは、Ruby on Railsが使われていました。誤解されないように言っておきますが、私はRuby on Railsが大好きですし、すばらしい環境だと思っています。しかし、Rubyでシステムを設計し始めると忘れてしまうのは、マルチスレッド化や並列化、高速化、メモリオーバーヘッ
ここでは、私がたどりついた最善のやり方を紹介しましょう。個人的に過去数年にわたって大量のGoコードと付き合ってきた経験から集めたものです。これらは全て非常にスケーラビリティがあると思っています。私が、スケールする、と言うときは次のような意味があります。 アプリケーションが求める環境は、アジャイル環境の中で変化していきます。開発の3、4か月後に、全てをリファクタリングする必要が出てくるなど、考えたくもないはずです。新しい機能は簡単に追加できなくては意味がありません。 あなたのアプリケーションは多くの人々によって開発されます。可読性が高く、維持しやすいものでなくてはなりません。 あなたのアプリケーションは大勢の人々に使われます。バグは容易に特定でき、修正できなくてはなりません。 長期的にみるとこれらのことが重要になる、ということを私は今までに学んできました。小さなことであっても、多数に影響しま
1. 各々の入力欄に、常に見えて分かりやすいラベルを付けよ 記入する前の入力欄にだけ、フォームのラベルを表示するのがWebデザインの主流になっています。これはユーザネームやパスワードなどを入力する際にはシンプルで使い勝手がいいのですが、それ以上に長い文字列になると少々勝手が悪くなります。 そのため余白があるのであれば、ラベルを表示すべきです 特に、長いフォームの場合では、ユーザは入力したものを見直すでしょう。どのラベルが入力欄と合致するのか分からなければ、間違いがないよう見直すことなどできるはずがありません。 改善前:入力欄中にラベルが記入してあります。今は見やすいかもしれません。 しかしフォームに入力するとラベルが見えなくなってしまい、間違いを見つけにくくなってしまいます。 改善後:それぞれの入力欄に、クリアでいつでも見えるラベルを付けましょう。 2. 十分な大きさのフォントを使用せよ
「Reactが素晴らしい理由は、UIをアプリケーションの状態の純粋関数にできるからだ」いうような話を聞いたことがあるでしょう。しかしそれだけではなく、不変性と仮装DOMを利用して動作するということも聞きますよね。その上、保存、読み込み、取り消し、それにタイムトラベル・デバッグと呼ばれるすごい機能まで自由に手に入れられる。でも知っていますか? Reactの核となるアイデアを利用し、その恩恵に預かるのにこれらのことは必要ありません。jQueryの数行にしてお見せします。 <span id="colored-counter">0</span> <input id="color"></input> <button id="inc"></button> <script> $('#color').on('keyup', function () { $('#colored-counter').css('
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く