特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
Rafal Tomalの書いた『The Essential Web Design Handbook』という本を読んだ。初心者のためにWebデザインの基本となる知識を広く紹介している。構成としては、筆者がWebデザインを行うときのプロセスをまず最初に紹介し、その各段階を追っていきながら、「この作業は無視されがちだけどこういう点で効率的だからやった方がいい」「これを考えるときにはこういう知識を使う。今回の例ではこうやって考えた」という具合に進んでいく。 プロセス 筆者が推奨するWebサイトのデザインプロセスは次の通り: 調査して計画をつくる 発想を膨らませる スタイルガイドをつくる ワイヤーフレームを組む モックアップをつくる コードを書く 調査と計画 調査するというのは、明確なクライアントがいる場合は要求を聞くことであったり、競合サイトの様子を調べてくることであったり、使えそうな資料を広範に
この記事は webcomponents.org の記事とのクロスポストです。 Template や Shadow DOM、Custom Elements を使うことで、機能ごとの UI コンポーネントが実現できるようになることはこれまでに説明してきました。しかし、それらを使ったコンポーネントの HTML、CSS、JavaScript を別々に呼び出すのは、非効率です。 依存関係の解決も容易ではありません。jQuery UI や Bootstrap を思い出して下さい。JavaScript、CSS、Web Font といった各種リソースを、必要に応じて別々のタグに記述しなければなりませんでした。特にタグごとにコンポーネントとして扱うことが想定されている Web Components の場合、状況が複雑化することは簡単に想像できます。 これらのリソースを、ひとつの HTML ファイルにまとめて
Chrome では、リリース 40 からごく一部で「マシな AppCache」とも言われている ServiceWorker がデフォルトで使えるようになります。ServiceWorker はオフライン API の1つとして紹介されていることが多いですが、実は 「Webの世界観を変える (かもしれない) 大注目API」の1つです! ここでは、Chrome 40 で出来たての ServiceWorker をひと通り試す方法を書いてみたいと思います。 ServiceWorker とは? 詳しいことは最新スペック (Editor's Draft)やHTML5Rocks の記事を見てもらうとして、ものすごくざっくり書くと ServiceWorker とはバックグラウンドで実行される Javascript 環境のことで、 ブラウザ内で動くJavascriptで書いたネットワークプロキシ のように動作さ
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
この記事はIwate Developers Advent Calendar 2014の6日目の記事です。 Iwate Developers Advent Calendar 2014 - Qiita 記事の内容はというと、岩手にまったく関係ありません。 学生の頃はフロントエンドを軽視してクソコードを量産していたので、今の学生の方にこんな風に作り始めるといいよって紹介する感じで書きたいと思います。 はじめに 昨今のフロントエンド開発はとにかく複雑になってきていて、学習コストが半端なくなってきてます。 angularとかbackbone.jsとか、最近ではreact+fluxなど、トレンドの移り変わりが激しいです。 またGruntやgulp.jsなどのタスクランナーの活用がフロントエンドでは欠かせなくなっていて、使ってないなら今すぐ導入すべき、とも言えます。 最近gulp.jsを使っていて、gu
こんにちは!ChatWork CTOの山本です。 チャットワークのバックエンドをPHPからScalaへの切り替えることを決断し、現在は移行に向けての大プロジェクトが進行中です。 バックエンドはScalaにしていく。じゃあフロントエンドはどうするの?ということで、今回はチャットワークのフロントエンド開発における今後の戦略を書いてみようかと思います。 現在のフロントエンドにおける課題現在のJavaScriptコード量は、ざっと5万行ほどになっています。(OSSライブラリ、言語キーなどを除く。たぶん大規模・・ですよね?) 約5年前の開発スタート時より、素のJavaScriptとjQueryをベースにゴリゴリと書き重ねられ、これぐらいのコード規模になったソースコードはご想像通りメンテナンスコストがかなり高くなってしまっています。。。 バックエンドの刷新に伴い内部APIも一新されるため、どうせ大幅に
Chrome 38が出て<picture>が有効になったので、いくつか記事を訳した。 レスポンシブイメージのネイティブサポート - HTML5 Rocks Dev.Opera — ネイティブサポートされたレスポンシブ・イメージ Dev.Opera — レスポンシブ・イメージ:ユースケースと入門用のコードサンプル HTML5 Rocksのは<picture>の簡単な使い方をざっと紹介。Dev.Operaのネイティブうんぬんは<picture>と<img srcset>, <img sizes>を細かく説明。もひとつのDev.Operaのサンプルのやつはユースケースごとに組み合わせをいろいろ書いたサンプル。それぞれ少しずつ違っている。おすすめは2つ目。ちょっと長いけど、書いているのがBlink, WebKitで<picture>とかを実装しているYoavなので。 以下いろいろ。 だいたい<im
我々Web開発者がWeb Componentsという言葉を耳にしてから、もう2年程経ったでしょうか。Web Componentsが変えるWeb開発の未来という記事に、「今のWeb開発がどのような課題を抱えているか、それをWeb Componentsがどう解決するか」を書きました。これを踏まえて、本連載ではWeb Componentsの仕様から実装、PolymerやX-TagといったWeb Componentsを支えるライブラリなどの周辺知識まで解説していきます。 Web Componentsを支える4つの仕様 連載第1回目となる本記事では、Web Componentsを支える4つの仕様について解説します。Web Componentsは以下の4つの独立した仕様から構成されます。 Custom Elements – 独自のカスタム要素をユーザーが定義することを可能にする Shadow DOM
TL;DR I struggled for a long time trying to understand React. This is what I wish someone had told me. What is React?How does React compare to Angular, Ember, Backbone, et al? How do you handle data? How do you contact the server? What the heck is JSX? What is a "component"? Stop. Stop it right now. React is MAINLY THE VIEW LAYER. React is mentioned in the same breath as other Javascript framework
画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです: とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な
パート1:メディア・クエリのどこがまずいのか? そう、もし君がウェブサイトを作っている時代が1993年2月23日から2010年5月25日の間だったら、画像の扱いなんてチョロかったね! それはこんなふうに単純だった。 幅の固定されたレイアウトをにらみつける 画像がきっかり何ピクセルかを測る――その画像はあらゆるユーザーの画面で変わらないスペースを占めることになる Photoshopのエンジンをかける 画像をさっき測ったとおりのサイズで「ウェブ用に保存」する それを<img>タグでマークアップする グラスにビールを注ぎ(または新鮮なグリンピースの缶を開け)、仕事がうまくいったことを祝う ときおり聡明なる預言者が荒野から現れては、この手法に潜む問題について深遠な真実を説くこともあった。それでもこのやり方は、20年もの間、ウェブ・デザイナーを生業とするものたちに受け入れられてきた。 しかし、時代は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く