01.Intro - High Performance Web 2015 - Qiita
Web のパフォーマンスの今 自分の持っている Web のパフォーマンスに関する知識を、一旦全部吐き出してまとめたいと思っていたので、それをやってみようと思う。 予定 この辺が頭にはある。 Metrics TCP TLS Rendering Prebrowsing Async/Defer Cache Priority HTTP2 QUIC とりえず、思いついた順に書いて後で整理する。 スタンス まずは知識のダンプを目的としたい。 デモとか実際の計測細かく作ると時間がかかるので、まず書くだけ書いて、やるとしても後でやる。 あといつも、自分で書き溜めて、見直して、書き直して、、、とやっていて気がつくと飽きて出さずに終わることが結構多いので、 今回はとにかく出して、追記や修正は後からがんがん更新していく感じにしたい。 更新履歴は Qiita で勝手に残るので、そこに任せる。 書いたものリスト こ
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
モダンなWebプロジェクトにおけるベストプラクティス | POSTD
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
Webサービス開発の変遷と現在
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Webパフォーマンスにおけるイニシャライズとランタイム
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
グロースハックについて思うこと - 運河
Webサービスにおいて定量的に評価できる数字とユーザー体験はトレードオフであることが多い。たとえば、広告のクリック率を上げようと思えば、広告枠を過剰にチカチカさせたりボタンに隣接させて配置したりすればよい。運営者の小遣いが増える代わりに、ユーザーにとっての心地よさを犠牲にする。 必要なのはバランス感覚だ。価値基準が歪むと"Don't be evil"という言葉も機能しなくなる。 ユーザー体験を犠牲にする黒魔術に一度手を染めると、そのサービスはいつしかスパムと区別がつかなくなる、と僕は思う。 “月間34億PV、新規会員登録1日1万人！ pixiv片桐代表が明かす、驚異のグロースハック術 | ログミー[o_O]” http://t.co/q36cwDbmeq— ウイウ (@uiureo) 2014, 2月 17 会員登録しないと著しく不便なようにして無理やりユーザーに登録させるのをグロースハッ
The Web API Checklist – 43 Things To Think About When Designing, Testing, and Releasing your API
When you’re designing, testing, or releasing a new Web API, you’re building a new system on top of an existing complex and sophisticated system. At a minimum, you’re building upon HTTP, which is built upon TCP/IP, which is built upon a series of tubes. You’re also building upon a web server, an application framework, and maybe an API framework. Most people, myself included, are not aware of all th
Webの未来 〜 PNaClとasm.jsでカワルミライ - いま、モバイルWebの先端で起こっていること
Webの未来 〜 PNaClとasm.jsでカワルミライ - いま、モバイルWebの先端で起こっていること
Undo | SachaGreif.com
I love the Internet. But I just wish it would give us “undo” back. The ability to undo mistakes is one of the most powerful advantages of computers over their analog competitors. Yet ever since web-apps started taking over, I feel like we’ve been slowly losing this superpower. After all, undo might be ubiquitous on the desktop, but when was the last time you saw a web app with an undo command? DRO
「新しい」を生み出すためのWebアプリ開発とその周辺
3. 自己紹介 • 和田裕介 1981/12/23 生 • 慶応義塾大学政策メディア研究科修了 • 株式会社ワディット代表取締役社長 • 株式会社オモロキ取締役
ssig33.com - ネイティブアプリ並のウェブアプリを云々
なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ
GoogleがSafariの設定を迂回してトラッキングしていたとされる件について(2) - 最速転職研究会
http://d.hatena.ne.jp/mala/20120220/1329751480 の続き。書くべきことは大体既に書いてあったので、補足だけ書く。 Googleは制裁金2250万ドルを支払うことでFTCと和解した http://jp.techcrunch.com/archives/20120809google-settles-with-ftc-agrees-to-pay-22-5m-penalty-for-bypassing-safari-privacy-settings/ まさか(まともに調査されれば)こんなことになるとは思わなかったので驚いた。異常な事態である。そしてGoogle側の主張を掲載しているメディアが殆ど無いのも異常な事態である。 2250万ドルもの制裁金(和解金)が課せられるのは、2009年に書かれたヘルプの記述が原因だという。 問題の記述 http://obam
「10 年続ける」ということ : niPhotane
18:33:01 <k*****> あともう一点気になってるのがデータ削除タイミングです 18:33:21 >nipotan< ○○が削除されたら削除したいところ 18:34:37 <k*****> なるほど。あと放置しとくとどんどんデータが増えていくと思うのですが、ログのローテートみたいな感じで古いのを消す感じにするのかーとか、悩んでます 18:36:01 >nipotan< ○○が消えてないかぎりは残したほうがいいのかも 18:36:38 <k*****> 本番系のハードディスクサイズはどんなかんじなんだろう 18:37:06 <k*****> 実質無限にあるみたいな感じなのかな 18:37:37 >nipotan< そうなるとおもう 18:37:40 >nipotan< スケールするようになってるし 18:38:21 >nipotan< ペタバイトとか超えたら考えたほうがいいけど 1
OWASP Foundation, the Open Source Foundation for Application Security | OWASP Foundation
This website uses cookies to analyze our traffic and only share that information with our analytics partners. Accept Who is the OWASP® Foundation? The Open Worldwide Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブパフォーマンスの基礎とこれから
Gershom Bazerman on Dynamic, Interactive Web Applications that Scale Forever and Upgrade Seamlessly
Flat UI - Free Bootstrap Framework and Theme
Introduction to Web Technologies
Web Developer Checklist: Website Launch Checklist | Toptal®
bon3 (盆のTシャツ販売サイト)
