ソースコードを表示するためのフォント「Source Code Pro」をアドビがオープンソースで無料公開 － Publickeyプログラミングやマークアップなど、コーディング作業のときにソースコードを表示する目的で開発されたフォント「Source Code Pro」を米アドビがオープンソースとして無料公開しました。24日（日本時間24日深夜）に開催された同社のイベントCreate the Webで発表されました。
［速報］アドビがHTML5とモバイルにフォーカスした新ツール群「Adobe Edge Tools & Services」を発表。アニメーション作成、レスポンシブデザインなどが効率的に
［速報］アドビがHTML5とモバイルにフォーカスした新ツール群「Adobe Edge Tools & Services」を発表。アニメーション作成、レスポンシブデザインなどが効率的に 米アドビは24日（日本時間24日深夜）、サンフランシスコでイベント「Create the Web」を開催。CSSやJavaScriptを使ったアニメーション作成、画面の大きさによって動的にレイアウトが変化するレスポンシブなWebデザイン、複数のモバイルデバイスへの対応、HTML5やCSS3に対応したコーディングなど、最新のWeb技術に対応した開発を支援する新ツール群「Adobe Edge Tools & Services」を発表しました。 発表された新ツールやサービスを日本語で解説するWebサイトもすでに公開されています。サンフランシスコで開催されたイベントの内容を、ダイジェストで紹介しましょう。 Adobe
HTML5勧告へのロードマップ。HTML 5.0とHTML 5.1に分けて、まずは2014年内を目指すとの案をW3Cが発表
2014年内にHTML5をW3Cの勧告にすることを目指して、HTMLワーキンググループのチェアとProtocols and Formatsワーキンググループのチェア、およびW3Cチームは連名で「Plan 2014」という文書を公開しました。 「Plan 2014」では、現在勧告候補にあるHTML5を、HTML 5.0とHTML 5.1の二段階に分けて、HTML 5.0を2014年内に勧告とし、HTML 5.1は2016年内に勧告とすることが提案されています。 また限られた時間内でバグや懸案事項を解決するためにmodularity（モジュール機能）を活用し、仕様の複雑さや影響範囲をうまく管理していくことも提案されています。 インターオペラビリティの問題を、まず優先的に対処 現在、勧告候補の状態にあるHTML5には、勧告となるまでに解決しなければならない多くの仕様のバグや懸案事項があります。
ザッカーバーグ氏の「HTML5に賭けたのは失敗」発言には続きがある。長期的にはHTML5への期待も語る
ザッカーバーグ氏の「HTML5に賭けたのは失敗」発言には続きがある。長期的にはHTML5への期待も語る これまでFacebookはiOS向けのアプリをHTML5ベースで開発していましたが、起動が遅い、反応が重いなど不評でした。そこで方針を転換。8月にリリースされた新バージョンは性能を重視してネイティブアプリケーションとして開発されました。 ザッカーバーグ氏はこの、HTML5で開発するという方針を指して「HTML5に賭けたのは失敗」と発言したわけです。 ザッカーバーグ氏の発言のここだけを見れば、FacebookはこれからHTML5を捨ててネイティブアプリへ注力するように受け取れます。しかしザッカーバーグ氏のこの発言には続きがあります。そこまで聞くことで、本当は何を言いたかったのかがはっきりしてきます。 彼の発言を、TechCrunchで公開されているビデオから追ってみましょう（ビデオはこの記
JavaScriptは業務アプリの開発言語として有力な存在になる
この記事は、日経SYSTEMS 8月号に掲載された連載「新野淳一の技術インパクト」第5回のオリジナル原稿をPublickey掲載用に編集したものです。Publickeyでは日経SYSTEMS編集部との合意を得て、雑誌発行から一定期間後に記事をPublickeyに掲載しています。 JavaScriptは1995年の登場から何年にもわたって、Webページにちょっとした動きを与えるための簡易なプログラミング言語とみなされてきた。しかしいまやJavaScriptはモバイル向けアプリケーションの開発、業務アプリケーションのフロントエンド開発、そして大規模なWebアプリケーションのサーバサイドプログラミングなど、あらゆる分野での活用が始まりつつある。最も注目を集め、急速に適用分野を広げて進化しているプログラミング言語だ。 業務システム開発の視点で見れば、今後の開発言語としてJavaScriptが有力候
HTML5を中心とした「Web標準」がどれだけあるのか、図にしてみると……
急速に立ち上がろうとしている「プラットフォームとしてのWeb」。そのために現在たくさんのWeb標準が提唱され、標準化作業が行われています。 その全体像を1枚の図として示したのは、Mozilla Japanのdynamis（でゅなみす）氏こと浅井智也氏。先週行われたオープンソースカンファレンス2012京都で行った講演のスライドから許可を得て引用します。 HTML5を中心に、円の色は標準化団体の色を示しています。青ならW3C/WHATWG、黄色はIETF、茶色はECMA、赤はKhronos。また、円の外側はまだまだこれからの技術という位置づけになっているそうです。 こうして1枚の図にして見ると、実にたくさんの技術がWebで実現されようとしていることに驚かされます。 このすべての技術を使いこなす必要はないかもしれませんが、Webをプラットフォームとするアプリケーションの構築には、HTML5のマー
HTML5仕様をめぐるW3CとWHATWGについて、Ian Hickson氏がメーリングリストに書いたこと
HTML5の仕様策定が、今後W3CとWHATWGに分裂するのではないか、といった言説が流れています。発端となったのは、W3CのWHATWGグループにIan Hickson氏が投稿したメールです。 [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification from Ian Hickson on 2012-07-19 ([email protected] from July 2012) [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 spec
HTML5 vs ネイティブ。モバイルアプリはどちらで開発するべき？（後編） Google I/O 2011
HTML5 vs ネイティブ。モバイルアプリはどちらで開発するべき？（後編） Google I/O 2011 モバイルアプリケーションを開発する方法として、JavaやC/C++とSDKを用いてネイティブアプリケーションを開発する以外に、HTML5/CSS/JavaScriptを用いて開発する方法が登場してきています。 この2つのアプリケーション開発にはどのような違いや利点があるのでしょうか？ Androidを題材にして解説したセッション「HTML5 versus Android: Apps or Web for Mobile Development?」がイベントGoogle I/O 2011で行われました。 （この記事は「HTML5 vs ネイティブ。モバイルアプリはどちらで開発するべき？（前編） Google I/O 2011」の続きです） ネイティブアプリケーションを開発する理由 Re
HTML5 vs ネイティブ。モバイルアプリはどちらで開発するべき？（前編） Google I/O 2011
HTML5 vs ネイティブ。モバイルアプリはどちらで開発するべき？（前編） Google I/O 2011 モバイルアプリケーションを開発する方法として、JavaやC/C++などのプログラミング言語とSDKを用いてネイティブアプリケーションとして開発する方法以外に、HTML5/CSS/JavaScriptを用いて開発する方法が登場してきています。 この2つのアプリケーション開発にはどのような違いや利点があるのでしょうか？ Androidを題材にして解説したセッション「HTML5 versus Android: Apps or Web for Mobile Development?」がイベントGoogle I/O 2011で行われました。 HTML5でモバイル開発を行う利点 Reto Meier氏（左）、Michael Mahemoff氏（右）。
Twitterがページ表示時間を5分の1に高速化。どのようなテクニックを使ったのか？
Twitterがフロントエンドのアーキテクチャを見直し、Webページの読み込み速度を改善したことをブログで明らかにしています。 新しいアーキテクチャでは、これまでWebブラウザ上でJavaScriptの処理によって行ってきたWebページのレンダリングを見直し、サーバ側でレンダリング済みのHTMLページを送信し表示することにしています。これによってWebページの読み込みから最初のツイートの表示までの時間が大幅に短縮されることになりました。 When we shipped #NewTwitter in September 2010, we built it around a web application architecture that pushed all of the UI rendering and logic to JavaScript running on our users’
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
アドビ、オープンソースのHTMLエディタ「Brackets」を公開。まだまだ開発中
アドビがオープンソースとして公開している「Brackets」は、HTML5とJavaScriptで作られたHTMLエディタです。アドビ自身はBracketsについてブログやプレスリリースでのアナウンスは何もしておらず、Github上にAdobeのコードとしてひっそりと公開されています。 アドビには統合的なWeb開発環境として確固たる地位を持つDreamweaverがありますが、Bracketsの画面を見るかぎり、目指すものはDreamweaverを置き換えるようなものではなく、もっと直感的で軽くシンプルなHTML/CSS/JavaScriptエディタを実現しようとしているように見えます。 Bracketsはまだ開発が始まったばかりで、それほど多くの機能が実装されているわけではありません（実際に起動してみましたが、短時間では使い方もよく分かりませんでしたし……）。今後もう少し機能が追加されて
HTML5に続く“HTML.next”へ取り組むための体制変更へ。W3CのHTMLワーキンググループ
W3CでHTML5の仕様策定を進めてきたHTMLワーキンググループ共同チェアの1人、 Maciej Stachowiak氏は24日、メーリングリストに「HTML Working Group Changes」というタイトルで次のような内容で始まるメールをポストし、HTML5に続くHTML.nextの検討に向けた体制作りを始めると宣言しました（Mozillaの浅井氏のつぶやきで知りました）。 HTML Working Group Changes from Maciej Stachowiak on 2012-04-23 ([email protected] from April 2012) We have reached a point in the HTML WG where the W3C process and community expects to finalize the HTML
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
