Feeds:
投稿
コメント

Posts Tagged ‘Browser’

BN-FO462_Keywor_G_20141116150543

Christopher Mims, Wall Street Journal:

“The Web — that thin veneer of human-readable design on top of the machine babble that constitutes the Internet — is dying.”

     ↓

John Gruber, Daring Fireball:

“I can’t believe someone is still writing this in 2014.”

     ↓

MG Siegler, Five Hundred Words:

“The Web, Still Dying After All These Years”

Read Full Post »

donmelton

[元アップルプログラマー Don Melton:image

少し前に話題になった元アップルプログラマーの Safari 開発秘話が大変オモシロい。

Don Melton は Scott Forstall の下で極秘に Safari 開発に当たった責任者だった。

Don Melton: “Keeping Safari a secret“: 03 January 2013

     *     *     *

本名を名乗らなかった Safari

日夜 Safari の開発をやっていた頃、まだ Safari という名前で呼ばれるようになるずっと以前のことだが、それはマイクロソフトの Internet Explorer のふりをしていたものだ。そう、1998 年以来 Mac OS にバンドルされていた Internet Explorer for Mac のことだ。Safari 発表の半年前のころには、Mozilla ブラウザのふりをし始めた。

For much of the time we spent developing Safari — long before it was called by that name — it pretended to be Microsoft Internet Explorer. Specifically, Internet Explorer for Mac, which Apple had provided with the OS since 1998. Less than six months before Safari debuted, it started pretending to be a Mozilla browser.

     *     *     *

なぜそんなことを?

なぜそんなことをしたのかって? コードも動作も非常に異なる Safari をどうやって偽ることができたのかって?

Why did we do this? And how did we make Safari pretend to be these browsers when its code and behavior were so different?

チームを編成してそんなブラウザを作成するよう Scott Forstall に命じられたせいだけではない。このプロジェクト全体を極秘にしておかなければならなかったのだ。そのために、オリジナルチームの大部分を雇うのに、仕事を始めるまでは何をやるのか教えてやるワケにもいかないというひどく込み入った状態で、管理上の難問題だったのだが、その話は別の機会に譲るとしよう。

Not only was I tasked by Scott Forstall with building a browser and building a team to build that browser, I had to keep the whole damn project a secret. Which, by the way, really complicated the shit out of hiring most of the original team since I couldn’t tell them what they were working on until they took the job. Talk about your management challenges. But that’s another story.

     *     *     *

極秘任務

そう、極秘だった。かといって、Jony Ive のデザイングループが当時そうだったように、あるいはまた数年後には iPhone チームがそうなったように、肉体的にも閉じ込められていたワケではなかった。しかし名指しで訪ねてこない限り、われわれをキャンパスで見つけるのは不可能だった。できたとしても、われわれの誰かが実際に Safari を動かしている現場 — 通常密室でやっていたが — を見ない限り、何をやっているのか分からなかっただろう。

So, secrecy. We weren’t under physical lockdown like Jony Ive’s design group was then, or like the iPhone team would be years later. But unless you knew who to look for, you were never going to find us on campus. And if you did, it’s unlikely you could tell what we were doing unless you caught one of us actually running Safari — something we usually did with our office doors closed.

     *     *     *

チームの心配はしなかった

ウワサになることについては心配していなかった。Forstall が私を信頼していたからだ。その点は — 他にもいろいろあるが — 彼が偉大なボスだった証拠だ。それに私も自分のチームを信頼していた。さもなくばそもそも彼らを雇ったりはしなかっただろう。われわれの誰も、そしてアップル内部のベータテスターたちの誰も、密告などしなかった。ベータテスターの数は非常に限られていたが、みな非の打ちどころがなかった。

I wasn’t worried about talk either. Forstall certainly trusted me – that’s one of the many things that made him a great boss. And I trusted my team — otherwise I wouldn’t have hired them. None of us nor any of the internal beta testers at Apple were going to snitch. There were too damn few beta testers, but they were above reproach.

     *     *     *

何が心配だったか

当時はツィッターもなかったし、フェイスブックもなかった。仕事内容をブログに書くようなバカはアップルにはいなかった。それじゃいったい何を心配したのかって?

Twitter and Facebook didn’t exist then. Nobody at Apple was stupid enough to blog about work, so what was I worried about?

サーバーのログだ。死ぬほどそれが怖かった。

Server logs. They scared the hell out of me.

     *     *     *

ユーザーエージェント文字列

ウェブブラウザがウェブサーバーからページを読み込むとき、ブラウザは ID としてサーバーに対してユーザーエージェント文字列(user agent string)を明らかにする。基本的には名前、バージョン、プラットフォームなどのことだ。同時にまたブラウザはサーバーに IP アドレスも手渡すので、サーバーはどこにページを送ればいいのか分かるワケだ。このやり取りのおかげでウェブは動くことができ、さらに誰がどこで、どのブラウザを使っているかをサーバーに教えることができるのだ。

When a Web browser fetches a page from a Web server, the browser identifies itself to that server with a user agent string — basically its name, version, platform, etc. The browser also gives the server an IP address so the server knows where to return the page. This exchange not only makes the Web work, it also allows the server to tell who is using what browser and where they’re using it.

何をいいたいのか分かるだろう? でもそれだけではない・・・

You can see where this is going, right? But wait, there’s more…

     *     *     *

固定 IP アドレス

1990 年当時、先見の明のあるアップルの IT 担当者は、アップルのために IP アドレスの Class A ネットワーク全体を確保しておいた。そうなのだ、アップルは 16,777,216 個の固定 IP アドレス(static IP addresses)を確保していた。そしてこれに属するアドレスは — 今では「/8 block」と呼ばれているが — すべて同じ数字で始まるのだ。アップルの場合、それは 17 だった。

Back around 1990, some forward-thinking IT person secured for Apple an entire Class A network of IP addresses. That’s right, Apple has 16,777,216 static IP addresses. And because all of these addresses belong together — in what’s now called a “/8 block” — every one of them starts with the same number. In Apple’s case, the number is 17.

IP アドレスが 17.149.160.49 なら、それはアップルだ。17.1.2.3 もアップルだし、17.18.19.20 もアップル、17.253.254.255 もアップルというワケ。クソッ!

IP address 17.149.160.49? That’s Apple. 17.1.2.3? Yes, Apple. 17.18.19.20? Also, Apple. 17.253.254.255? Apple, dammit!

すっかり騙されていた。

I was so screwed.

     *     *     *

CIA 並みのプロジェクト

みんなが忠誠を宣誓をして CIA の非合法活動なみに密かにこのプロジェクトを遂行していたけれど、アップルキャンパスのネットワークを利用するときに Safari を「Safari」という名前で使うワケにはいかなかった。さもないと、ウェブサーバーの管理者がどこかでログファイルをスキャンして、ユーザーエージェント文字列と発信元の IP アドレスを突き合わせるかもしれないのだ。そうなれば 2003 年1月7日の Macworld で Steve Jobs が発表しようとしているビッグサプライズがダメになってしまう。ひいては自分もそうなるということなのだ!

Even though we operated the project like some CIA black op — with loyalty oaths and all — we couldn’t let Safari be “Safari” when we used it on the Apple campus network. Otherwise, some Web server administrator somewhere might be scanning their log files and notice the connection between user agent string and IP address origin. Then the big surprise Steve Jobs wanted to unveil at Macworld on January 7, 2003, would be shot. And, likely, so would I.

     *     *     *

自分が考案したユーザーエージェント文字列

そこでわれわれは自分が巧く考案した Safari のユーザーエージェント文字列を隠したのだ。「自分が考案した」という意味は、それが実際に Safari および WebKit の数少ないコードのひとつであり、1)それを考案したのは自分だと主張でき、2)今でもソースコードに残っているからだ。残りのハッキングについては自分のエンジニアチームがすべて削除ないしは更新してしまった。実に頭のいい連中を雇ったものだよ。

So we hid my cleverly designed Safari user agent string whenever we were at Apple. And I say “my” because that’s actually one of the few pieces of code in Safari and WebKit that 1) I can claim to have designed and 2) is still actually in the source. Thank God my engineering team removed or refactored all my other hacks. I hired good people.

     *     *     *

今でもその名残り

アップルキャンパスのネットワークを使うとき以外、すなわち自宅ではいつも、Safari をいじって本当のユーザーエージェント文字列を有効にしていた。互換性テストのためにそうせざるを得なかったのだ。文字列をいじることで当時のウェブサイトと最大限の互換性を確保することができたのだ。Safari のユーザーエージェント文字列には今でも余分な情報 — KHTML、Gecko など他のブラウザエンジンの名前 — が残っているのはそういうワケだ。

Whenever we were off the Apple campus network, e.g. in our homes, we modified Safari to enable its real user agent string. And we had to do this for compatibility testing. That allowed me to tweak the string for maximum compatibility with the websites of that time. Which explains why the Safari user agent string has so much extra information in it, e.g. KHTML, like Gecko — the names of other browser engines.

     *     *     *

ちょうど10年前の今ごろ

真の Safari ユーザーエージェント文字列を無効にしたまま出荷するワケにはいかなかったので、次善の策として、一定の日時が来たら自動的に有効になる方法をとった。ちょうど10年前の今ごろ、発表の数日前のこと、ついに Safari は世を忍ぶ隠れ家から堂々と自分を名乗れるスポットライトの下へ出て行ったのだった。

We couldn’t ship with the real Safari user agent string disabled, but we came up with the next best thing — automatically enabling it after a certain date. Just about this time 10 years ago, days before it was to debut, Safari went from hiding its light under a bushel to being proud of who it really was.

私は発表前の数日間、インターネットのサーバーログをくまなく探しては心配で眠れぬ夜を過ごしたものだった。

And I spent the days before that debut nervous and losing sleep as I combed the Internet for server logs.

     *     *     *

敵を欺くにはまず味方からというワケだろう。

ジョブズ時代の開発秘話だ。

Don Melton については彼をゲストに迎えたポッドキャストがメチャオモシロい。

Forstall のインタビューを受けたときや開発当時の様子のほか、あまり耳にすることのないアップルプログラマーの名前が続出する・・・

★ →[原文を見る:Original Text

Read Full Post »


Web Browser Shootout: BlackBerry Torch 9800 vs. iPhone 4 vs. Samsung Captivate – YouTube]

iPhone の実力はスマートフォンの中でダントツなのか、それとも比較的優位にとどまるのか。

そんな疑問にヒントを与えてくれる興味深いテストがある。

iPhone 対抗策として RIM が満を持して投入した最新機種 BlackBerry Torch 9800 と iPhone、Android フォンのブラウザのスピード対決だ。

CrackBerry.com: “Comparison: New BlackBerry WebKit Browser vs. the Competition (iPhone 4 and Samsung Captivate)” by Kevin Michaluk: 04 August 2010

*     *     *

本当のところどうなのか

本当のところ新しい BlackBerry の Web ブラウザは、他社の最新機種のそれと比べてどうなのだろうか。自分でもその答えが知りたくて、BlackBerry Torch 9800、アップルの iPhone 4、それに最新の Android ベースのサムスン Captivate のブラウザ対決を行なった。Dieter の手を借りてそれぞれキャッシュを消去、3機種を一緒に並べて比較した。・・・

But how does the new BlackBerry web browser stack up to the latest and greatest devices from the competition? I wanted to know the answer to that myself, so with some help from Dieter we cleared the cache on the BlackBerry Torch 9800, Apple iPhone 4 and new Android-based Samsung Captivate and put the devices head to head to head in a one take, no messing around web browser shootout. […]

*     *     *

いい線いってる

さて結果はどうだったか? うん、いいニュースと悪いニュースが半々だ。まず悪いニュースから。われわれのささやかなテストでは、BlackBerry Torch 9800 は iPhone 4 や Captivate に対して一勝もあげることができなかった。しかし、いい方のニュースは、なかなかいい線をいって、ひどくやられたという感じではなかったことだ。たった数秒の差で、古い BlackBerry のネイティブなブラウザに比べると大進歩だと思う。対決戦の結果を比較して、Dieter と私は次のような結論に達した。敵わなかった原因の大半はブラウザではなく、Torch の 624MHz プロセッサにあるのではないかということだ。iPhone 4 や Captivate に同じ 624MHz プロセッサを入れたら、たぶんやっつけることができたのではないか。あるいは Torch のプロセッサパワーを高めれば、競合機種に負けず劣らずだったのではないか、と。結論として、BlackBerry のブラウザは大幅に強化され、RIM が次世代ハードウェアをアップグレードすればスピードやパフォーマンスがより強力になる道が開けたのだといえる。あなた自身が機種対決を試みることはないだろうが、BlackBerry ブラウジングはたっぷり楽しめるだろう。

The results? Well… it’s a good news bads new thing. The bad news: in our little test the BlackBerry Torch 9800 couldn’t pull off even one victory against the iPhone 4 and Captivate. The good news is it held in there pretty darn well – close enough that I don’t think you’ll feel hard done. It’s a matter of a few seconds, which is a massive step forward from our old native BlackBerry web browser. Reflecting on the results post shootout, Dieter and I both agreed this is probably an area where the Torch’s 624MHz processor could be the culprit more than the web browser itself. If you put the same 624MHz into the iPhone 4 or Captivate the Torch would probably Torch them. Conversely, if you upped the processing power in the Torch it could probably match or better the competition as well. Final conclusion: it’s a massive upgrade to the BlackBerry web browser and it paves the way for even more speed and performance as we see RIM move up to their next generation of hardware. In the meantime, as long as you’re not doing head to head shootouts, you’ll now enjoy browsing on your BlackBerry a lot.

*     *     *

BlackBerry サイトらしい身びいきも感じられて微笑ましいが、それをおいてもビデオを見る限り Torch 9800 はいい線をいっているように思える。

なかなかやるじゃん・・・

★ →[原文を見る:Original Text

Read Full Post »

Google Chrome
Google の Windows キラー

グーグルが発表したブラウザ Chrome について GigaOM の Om Malik が興味深い意見を述べている。

GigaOM: “Why is Google Releasing a Browser?” by Om Malik: 01 September 2008

     *     *     *

デスクトップでのマイクロソフトの座は揺るがない

何故ブラウザなのかが問題だ。ブラウザを出すことによってグーグルは何を得るのか。ブラウザを出すことについては諸説ある。例えば、マイクロソフトの IE に対する正面きっての挑戦だというのもそのひとつだ。しかし、ことはデスクトップだけの問題ではないと私は考える。何故なら、Mozilla の Firefoxという強力な競争相手があるにも拘らず、マイクロソフトはデスクトップの 75% をしっかり牛耳っている。言い換えれば、マイクロソフトが支配しているので、デスクトップでマイクロソフトを覆すのはむずかしいということだ。

The question is: Why a browser? What does Google get from releasing a browser? There are going to be many theories around the Google Browser — that it is a direct challenge to Microsoft’s IE Browser, for example — but I think it might be more than just the desktop. Why? Because even today, despite strong competition from Mozilla’s Firefox, Microsoft controls about 75 percent of the desktop browser market. In other words, given Microsoft’s control of the desktop, it is hard to dislodge it on the desktop.

     *     *     *

狙いはモバイル・・・

しかしモバイル機器ということになると、マイクロソフトといえども立場は弱い。IE モバイルのマーケットシェアはないも同然だ。Mozilla 同様マイクロソフトも Webkit に追いつこうとしている。ノキア S60 携帯電話、アップル iPhone Safari、それにグーグル Android などの中核をなすレンダリングエンジンが Webkit だからだ。モバイルのウインドウズ OS は未だ開発中だ。グーグルがデスクトップとモバイルの双方でシームレスに使えるブラウザを開発すれば、ブラウザマーケットの相当な部分に食い込むことが可能になる。特に Netbook のような新しく出現しつつある超小型のウェブ端末の分野では、これは大きなチャンスだ。

However, it is vulnerable on mobiles, where IE Mobile has a non-existent market share. Like Mozilla, Microsoft is playing catch-up with Webkit, the core rendering engine for Nokia S60 phones, Apple’s iPhone Safari and Google Android devices. Even a Windows Mobile version is in the works. (Read my Webkit report.) By developing a browser that offers a seamless experience on both mobile and desktop devices, Google can carve out a nice chunk of the browser market for itself. The big opportunity could be especially the emerging class of mobile devices like the Netbooks.

     *     *     *

Android も・・・

Android は携帯電話だけのものではないというウワサが最近聞こえる。軽くて持ち運びやすいモバイル機器であること、グーグル Chrome の狙いは「ウェブアプリケーション」であることなど考えると、グーグルがこのチャンスに賭けるのは十分な理由がある。

In recent months, there have been rumors that Android is going to work on more than just mobile phones. Given the light-weight footprint of these devices and Google Chrome’s focus on “web applications” it would make perfect sense for Google to chase this opportunity.

     *     *     *

OS としてのブラウザ戦争

Mathew Ingram は「グーグルが(Mozilla group もそうだと思うが)ブラウザを OS の一形態と考えていることは明らかだ」と指摘する。私も同意見だ。そして、「OS としてのブラウザ戦争(browser-as-OS warが始まったばかりだ」という John Furrier に主張についてもまた同意する。あなたはどうお考えだろうか。

Mathew Ingram points out, “Google clearly sees the browser as a form of operating system — just as I think the Mozilla group.” I agree, and also I agree with John Furrier’s contention that browser-as-OS war is only beginning. What are your thoughts about this development?

     *     *     *

昨年アップルが Safari For Windows のベータを発表したのは、Chrome のウインドウズ版が先に出るためだったという内輪話も興味深い。

マイクロソフトが 1990 年代に Netscape に対して Internet Explorer をぶっつけたように、また歴史は繰り返すのか・・・

原文を見る

Technorati Tags: , , , , ,

Read Full Post »