2/26/2015

ウェブ閲覧であなたを追跡する11の方法

ウェブ閲覧で個人を追跡するのに使われる方法(SANS Diary)。

# 手法 参考URL
1 クッキー RFC 2965, RFC 6265
2 Flashクッキー (Local Shared Object) https://helpx.adobe.com/flash-player/kb/disable-local-shared-objects-flash.html
3 IPアドレス http://ipleak.net
4 User-Agent
5 ブラウザのフィンガープリント https://panopticlick.eff.org
6 ローカルストレージ (HTML 5にあるクライアントにデータを保存する機能) https://html.spec.whatwg.org/multipage/webstorage.html
7 キャッシュされたコンテンツ (ブラウザがキャッシュするコンテンツ) http://robertheaton.com/2014/01/20/cookieless-user-tracking-for-douchebags/
http://fontfeed.com/archives/google-webfonts-the-spy-inside/
8 Canvasフィンガープリント https://securehomes.esat.kuleuven.be/~gacar/persistent/index.html
9 キャリアが挿入するヘッダ http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/
10 リダイレクト https://www.elie.net/blog/security/tracking-users-that-block-cookies-with-a-http-redirect
11 Cookie Respawning / Syncing (Flashクッキーを使ってクッキーを不滅化させる) https://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab11001.pdf

2/24/2015

パーセンテージは嘘

「◯◯パーセント完了」というのはダメという

この課題、現時点で78%か82%完了していますか? 現在の状況報告を発表するため、プロジェクト計画を更新する必要があります。あなたは何回この手の質問に直面しましたか? それのどこがバカバカしいんでしょうか?

プロジェクトの進捗を把握するのに愚かな方法が存在する理由はたくさんありますが、私はそれらのうち2つに注目します。

第一に、プロジェクトの個々の課題は100あるいは0パーセントのどちらかにすべきです。これは課題が終わっているか終わっていないかという意味です。個々の課題とは異なるどんなものも当てはめてしまうことで、あなたは勝手に推測するのです。それはプロジェクト計画全体には良くないことで、完成した際に初めてカウントすべきです。

第二に、それはステークホルダー(出資者)、スポンサーやマネージャーに、ほとんど完成したと誤解を与えてしまいます。「プロジェクトのスケジュールの90%は、プロジェクトの範囲の90%を終わることに費やされ、その後また残りの10%を完了させるのにエネルギーの90%が費やされる」という格言(*)は、とても一般的なことです。いくつかの課題の中で問題に直面しているチームメンバーは、ほとんど終わったと報告することで、それらを小さく見せようするでしょう。個々の課題に終わった/終わらないを適用しないことで、プロジェクトの遅延をカムフラージュしようとします。不完全なパーセンテージは、まだ一般的ですが、我々すべてが、ほとんどの90%プロジェクトはほとんど0%プロジェクトと大差が無いということを知っています。

(*)90対90の法則

2/23/2015

燃料電池車がうまくいかない理由

なぜ、燃料電池車はうまくいかないのか?」の最初の要点。

まず第一に、燃料電池車は化石燃料と完全電気との間の良い橋渡し(ブリッジ)になると見られている。

  • ガソリンやディーゼルエンジン車でまだ十分に満足できる
  • 水素から取り出せる走行距離は、水素の方がバッテリーよりも良いと見られている
  • 水素燃料電池はバッテリーとほどすぐに消耗しないと考えられている(逆に言うと、バッテリーはとても早く消耗してしまう)
  • 燃料としての水素は、ガソリンやディーゼルからインフラ変更は比較的小さいと見られている
  • 水素はガソリン、ディーゼルあるいは天然ガスよりもクリーンなソリューションと見られている

実際は、

  • ガソリンやディーゼルで十分に満足していない。実際、HFC動力の車で満足することがどれほど難しいか話にならない
  • 車に搭載するのにまだ十分な安全性を持っていない現行技術の水素タンクでは100マイルでさえ走ることはできない
  • 燃料電池は非常に急速に消耗し、再生が難しい
  • 燃料としての水素は、生成やロス少なく流通させることが信じられないくらい難しい

さらに、

  • 水素燃料電池は論理的にも実用的にも効率が悪い
  • 水素の貯蔵はエネルギー的、容量的、重量に関連して効率が悪い
  • HFCは変更に多くの支援システムが必要で、とても複雑で、燃焼あるいは電気のエンジンよりも故障しやすい
  • 流通のためのインフラがない上、大量の水素を生成さえできていない。我々が死に物狂いで構築を始めても、少なくとも20、30年はないだろう
  • 水素は実際かなり作りづらい。結果として最悪のWell-to-wheelの効率となる
  • 大量の水素を得る簡単な方法はガソリンよりもクリーンではない
  • 効率的なHFCは非常に応答時間遅いので、加速のエネルギを蓄えるのに追加システムが更に必要ということを意味している
  • たとえ、HFC動力の車が本質的に電気自動車であったとして、ブレーキ中にエネルギーを再生成したり、スマートグリッドバッファとして使ったりしても、自身の動力源で満たすような恩恵はない
  • バッテリー電気自動車は過去、現在、未来においてあらゆる面で技術開発スピードは上だ

Hacker News

2/21/2015

アカデミー賞の予想

Slashfilmのアカデミー賞の予想。「/」が獲って欲しい。

  • 視覚効果賞: 猿の惑星
  • 編集賞: 6才のボクが、大人になるまで。 / セッションと意見が分かれた
  • 衣裳デザイン賞: グランド・ブタペスト・ホテル
  • メイクアップ&ヘアスタイリング賞: フォックスキャッチャー / ガーディアンズ・オブ・ギャラクシー
  • 撮影賞: バードマン あるいは(無知がもたらす予期せぬ奇跡)
  • 美術賞: グランド・ブタペスト・ホテル
  • 録音賞: アメリカン・スナイパー / セッション
  • 音響編集賞: アメリカン・スナイパー / バードマンとUnbroken
  • 歌曲賞: セルマの"Glory" / レゴ・ムービーの"Everything Is Awesome"
  • 作曲賞: イミテーション・ゲーム / イミテーション・ゲームとグランド・ブタペスト・ホテル
  • 長編ドキュメンタリー映画賞: Citizenfour
  • 外国語映画賞: イーダ
  • 長編アニメ映画賞: ヒックとドラゴン2
  • 脚色賞: イミテーション・ゲーム / セッションとLAヴァイス
  • 脚本賞: グランド・ブタペスト・ホテル / グランド・ブタペスト・ホテル, ナイトクローラー
  • 助演女優賞: パトリシア・アークエット「6才のボク」
  • 助演男優賞: J・K・シモンズ「セッション」
  • 主演女優賞: ジュリアン・ムーア「アリスのままで」/ ロザムンド・パイク
  • 主演男優賞: エディ・レッドメイン「博士と彼女のセオリー」/ マイケル・キートン
  • 監督賞: リチャード・リンクレイター「6才のボク」
  • 作品賞: バードマン あるいは(無知がもたらす予期せぬ奇跡) / 6才のボクが、大人になるまで。

結果は...

  • 視覚効果賞: インターステラー
  • 編集賞: セッション
  • 衣裳デザイン賞: グランド・ブタペスト・ホテル
  • メイクアップ&ヘアスタイリング賞: グランド・ブタペスト・ホテル
  • 撮影賞: バードマン あるいは(無知がもたらす予期せぬ奇跡)
  • 美術賞: グランド・ブタペスト・ホテル
  • 録音賞: アメリカン・スナイパー / セッション
  • 音響編集賞: アメリカン・スナイパー
  • 歌曲賞: セルマの"Glory"
  • 作曲賞: グランド・ブタペスト・ホテル
  • 長編ドキュメンタリー映画賞: Citizenfour
  • 外国語映画賞: イーダ
  • 長編アニメ映画賞: ベイマックス
  • 脚色賞: イミテーション・ゲーム
  • 脚本賞: バードマン あるいは(無知がもたらす予期せぬ奇跡)
  • 助演女優賞: パトリシア・アークエット「6才のボク」
  • 助演男優賞: J・K・シモンズ「セッション」
  • 主演女優賞: ジュリアン・ムーア「アリスのままで」
  • 主演男優賞: エディ・レッドメイン「博士と彼女のセオリー」
  • 監督賞: アレハンドロ・G・イニャリトゥ 「バードマン」
  • 作品賞: バードマン あるいは(無知がもたらす予期せぬ奇跡)

それにしても、主要6部門の受賞作は「6才のボク」以外、日本で未公開。どうにかして欲しいものだ。「アリスのままで」が6月27日公開って、どうなってるんだ...

2/20/2015

RFC 7454 - BGPオペレーションとセキュリティ

BGPルータを運用する上で必要となるセキュリティ対策について書かれたRFC 7454、BCP 194にもなっている。

  • BGPルータをACLで保護
  • BGPセッションを保護(RST攻撃、MITM、TCPストリームの割り込みなど)
    • MD5(RFC 2385)よりもTCP-AO (RFC 5925)を使おう
    • IPsecは十分な検証が必要
    • セッション保護は管理コストが掛かるので、必須ではないが推奨
    • AS外部からのIBGPへの攻撃を防ぐため、Ingress filterをすべき
    • GTSM(RFC 5082)は実行すべき (マルチホップでも有効)
  • プレフィックスフィルタの定義
    • Specificな経路は受け付けない(RIPEではIPv4は/24より、IPv6は/48より長いプレフィックスは広告も受け入れもしない)
    • 全てのピアで自身のプレフィックスをフィルタする
    • IXPのLANプレフィックスは受け入れないこと
    • デフォルト経路(0.0.0.0/0, ::/0)は広告しない、受け入れない
    • フィルタのあり方(ピア先、顧客、上位)
  • BGP経路フラップダンペニングは閾値を調整して使う分には推奨
  • ピアから受け入れる経路数の上限設定は推奨
  • ASパスフィルタの推奨事例: ASリナンバがあった際の対応
  • Next-Hopフィルタ
  • BGP Communityスクラブ
    • 上位ビットの入方向のcommunityはスクラブすべし
    • 受信経路に適用された他のcommunityは削除すべきではない

2/19/2015

MicrosoftはサードパーティCDNに依存

2009年にMicrosoftは数億ドル掛けてソフトウェア、ゲームなどのコンテンツ配信にCDNを構築したが、年々AkamaiやLimelightなどのサードパーティCDNに依存しているという話(StreamingMediaBlog)。

2010年には40%がサードパーティCDNからの配信だったが(2007年には95%だったことを考えれば、自身のCDN構築で大幅ダウンしている)、XboxやWindowsビジネスの成長でトラフィックが年々増え続け、サードパーティCDNに依存するようになり、現在は75%がサードパーティCDNからの配信になっているそうだ。Microsoftは、Akamai、Limelight、Level 3、EdgeCast、ChinaCache、Highwindsを組み合わせて使っており、中でもAkamaiはまだ大きなシェアを持っており、最近はLevel 3やLimelightが伸びているそうだ。

2/17/2015

VPNプロバイダ・トップ10

CRD LABSに、VPNプロバイダのトップ10が出ていた。

# Provider Price
1 HMA (Hide My Ass) $11.52/month
2 Private Internet Access $7/month, $40/year
3 Privatoria $2.5/month, $20/year
4 IP Vanish VPN $10/month, $78/year
5 Cryptostorm $7/month
6 TunnelBear $5/month, $50/year
7 WiTopia VPN $6/month, $50/year
8 Unotelly VPN $5/month
9 Pure VPN $10/month, $50/year
10 Overpay VPN $5/month, $10/month(premium)

2/15/2015

空中浮遊のパフォーマンス :-)

ヨガの修行者と名乗る大道芸人が行う空中浮遊のパフォーマンスには特殊な椅子が使われているだけなのだが、タネが分かっていても楽しい(BoingBoing)。

Mkhz1y8flvdjz813ybwp

Relatively Interesting

2/14/2015

デジタル暗黒時代への備え

インターネットの父、ヴィント・サーフ氏が、今のデジタルフォーマット(ドキュメント、写真など)が将来読めなくなってしまう「デジタル暗黒時代」を警告している(BBC)。数年前から彼は警告して回っているようだが、今のファイル形式が未来でも読めるという保証はなく、最新バージョンでは互換性が無くなり、読めなくなってしまう恐れがある。博物館や美術館でコレクションをデジタル化していても、一度保存したデジタルファイルを新しい形式でわざわざ取り込み直すことは行われないだろう(長いスパンでの保存を考えなければいけないので問題は大きい)。解決策として、コンテンツ、アプリケーション、オペレーティングシステムのX線スナップショットを一緒に保存することを提唱している(デジタルベラム)。

デジタル暗黒時代は以前からある問題で(Wikipedia)、それを避けるためにオープンな標準フォーマットが作られたり、インターネット・アーカイブが設立された。

Hacker News, Slashdot

2/12/2015

Google Chromebook Pixel 2??

Googleの従業員がChromium Issue Trackerに提出したバグレポートにChromebook Pixel 2と思われる写真が一緒に投稿されたそうだ(OMG Chrome)。バグレポートには、この問題は'Samus'というボードに影響すると記載されている。昨年からSamusという名前が登場しており、GoogleのChromebookの新しいボードではないかと言われていた。全てのChromeデバイスにはコンピュータゲームのキャラクターの名前が付けられることから、このSamusはChromeデバイスのボードで間違い無さそうだ(サムスは任天堂のゲーム「メトロイド」の主人公の名前」)。Google I/O 2015でお披露目か?

フォーチューン1000の女性幹部の企業業績

クレディ・スイスが40カ国3000の会社で女性の登用状況を調べた結果、2013年末で経営トップ(CEO)は12.9%、役員登用は12.7%だったそうだ。それで、女性を幹部にした企業の成長はどうかという疑問に対し、Karen Rubin氏はフォーチューン1000で女性がCEOの企業を業績を調べたところ、平均よりも良いとのことだ。

Fortune1000 woman ceo

Hacker News

2/11/2015

Linuxでライブパッチ機能が採用

Linuxカーネルに修正(パッチ)を加えるには再起動が必要になるので、そのまま動かし続けるケースは少なからずあると思う。停止させずにパッチをあてることができるよう、Oracle (kSplice)、Red Hat (kPatch)、SuSE (kGraft)らは、それぞれ独自にライブパッチツールを開発してきた。

LKMLのメールによれば、Linuxカーネル3.20のコードにSuSEのkGraftとRed HatのkPatchをコラボレートしたライブパッチの機能が取り込まれた。今のところ、x86のみの実装で、powerpc、s390、arm向けはすでに作業中とのこと。

Slashdot

2/08/2015

マヨラナはベネズエラで生きていた?

イタリアの物理学者でマヨラナ・フェルミオンの存在を予想したエットーレ・マヨラナ。1938年にシチリア島のパレモアからナポリに向かう船で謎の失踪をし、事故、自殺、誘拐、暗殺、亡命など様々な説はあったが、マヨラナの行方は今も謎のまま...なんと、マヨラナはベネズエラに移住し、1955-1959年は生きていたという(IlFattoQuotidiano)。

Hacker News, WIRED

2/07/2015

電子メールの暗号化ソフトウェアは一人の男に依存している

エドワード・スノーデン氏も使っている電子メールの暗号化ソフト「GPG(Gnu Privacy Guard)」のコアの開発は、ワーナー・コッホ(Werner Koch)氏が行っている。ProPublicaの記事に、その苦労話が掲載されている。一番の苦労はお金集めのようだ。

記事によれば、コッホ氏がGPGの開発を始めたのは1997年、今もドイツの自宅で開発を続けているが、2013年の始めは全てを放棄して、普通の仕事をしていたそうだ。しかし、スノーデン氏のニュースで、「これはやめてしまう場合ではないと気付いた」とのこと。コッホ氏は、バックドアが隠されていないことを示す最良の方法は、ソフトウェアコードをフリーにすることだと確信している。コッホ氏は、今もフルタイムのプログラマを雇うため、お金集めに奮闘しているという。インターネットで使われるセキュリティソフトウェアの多くが十分な融資を得ていないという事実が、ますます問題になってきている中、アメリカではスパイ活動やインテリジェンスに年間500億ドル以上使われているそうだ。セキュリティ活動に掛かる費用は、日本でもかなりの金額が投じられていることだろう。

ProPublicaの記事が掲載された後、Linux Foundationから6万ドル、コッホ氏のウェブサイトの寄付ページは目標の13万7千ドルに達し、さらにFacebookとStripeから1年あたり5万ドルの寄付がこのプロジェクトに寄せられたとのこと。少額ではあっても個人で寄付はできる。ただ、一時的なことではなく継続しなければいけないのだが...

Hacker NewsSlashdotarstechnica

2/05/2015

Netflixが今秋日本に上陸

GIGAOMが、Netflixが今秋日本に進出すると報じている。情報源は、CNBCのリポータJulia Boorstin氏のツイート。いよいよ、黒船来航か?

Cnbc news netflix japan

更新

Netflixが今秋日本でサービスを開始することを正式に発表。すでに日本語のホームページがある。

2/04/2015

RFC 7414 - A Roadmap for Transmission Control Protocol (TCP) Specification Documents

TCP(RFC 793)はその後の拡張で、多くのRFC文書が刊行されているため、こういう文書(RFC 7414)は有難い。BGPの関連文書も同じくらいあるんじゃないかな。BGP版も作って欲しい。

TCPの正確かつ効率的な実装は、インターネットホストにとって不可欠な要素である。TCPは長年にわたり進化してきており、多くの個別の仕様書がTCP標準の一翼を担っている。同時に、TCPへの多くの実験的な修正、情報ノート、事例、他の勧告とともに、RFCとして刊行されている。

初心者への入門書、そしてベテランへは大量の情報を体系化する試みとして、この文書はTCP関連のRFCのロードマップになっている。TCPを定義するRFC文書の短い要約を提供する。これは、スタンダードトラック(標準化過程)の拡張、情報ノート、TCPに関連するベスト・カレント・プラクティスの関連や重要性を実装する人への手引きを提供する。

この文書はRFC 1122の更新ではないし、TCPへの実装すべき必要のある厳密な標準でもない。この文書は、TCPを実装する人、研究者あるいは学生が知っておくべきRFC文書の多くを取り込み、体系化し、要約するための単なる情報のロードマップである。個別のメカニズムや動作についての文書の特定のコメントあるいは分類は、決定版として利用すべきではない。また、この文書の内容だけで、実装の決定に影響を与えてはいけない。

このロードマップにはTCP関連の各RFCの内容の簡単な説明を含んでいる。一部では、概要あるいは簡潔な説明として本文の鍵となる要約文を単純に補っている。加えて、RFC番号の後の文字コードはRFCシリーズのカテゴリーを示す(これらのカテゴリーの説明は、BCP 9を参照)。

S - 標準化過程 (標準化への提唱、標準化への草稿あるいはインターネット標準)

E - 実験的

I - 情報

H - 歴史的

B - ベスト・カレント・プラクティス

U - 不明 (形式上明確ではない)

2/03/2015

Cisco IOS-XRのベースOS

Cisco NCS6000向けのIOS-XRは、ベースOSがQNXではなくLinuxになっている。QNXは32ビットOSなので、このままではスケーラビリティの確保が難しいということで、64ビットに対応したLinuxへの置き換えが進められているようだ。Cisco Live!の資料(PDF)を見ると、今年中にASR9000やXRvのIOX-XRも、Linux(64bit OS)に置き換わっていく計画だ。

PowerPC(RSP/RSP2)向けもLinux化されるのかな?

2/02/2015

OpenSSH 6.8で鍵のローテーション機能追加

OpenSSHの開発者Damien Miller氏が、次期リリースOpenSSH 6.8向けの新しい機能の紹介とコードをcommitしたことをブログに投稿した。新しい機能はSSHプロトコルの拡張で、自動的にクライアントに公開鍵を送る機能と、~/.ssh/known_hosts 内のサーバ鍵を更新する機能である。これらは、時代遅れになったDSAをEd25519 (OpenSSH 6.5で追加) に変更するのを簡単にすることを狙っている。

Hacker NewsSlashdot

2/01/2015

Quineリレー

面白い!! 自分自身を別のプログラムコードで次々とリレー式に出力する「Quine Relay」というプログラム。その数なんと100言語に達した。RubyからScala、Scheme、Scilab、... そして、REXXからRubyへと戻る。以前のQuineリレーは50だったようだが、その倍になった。

68747470733a2f2f7261772e6769746875622e636f6d2f6d616d652f7175696e652d72656c61792f6d61737465722f6c616e67732e706e67

なぜ日本のウェブデザインはそんなに...独特なのか

確かに、楽天やヤフーのウェブページはゴチャゴチャしていてセンスを感じられない。サムネイルで表示させるとよく似ている。ここで書かれたことが理由かは分からないけど...

多くの人々の心の目には、日本は穏やかな禅庭、静かな寺院、優美な茶道の国である。伝統と現代の両方を兼ね備えた日本の建物、本や雑誌は世界中でデザイナーの憧れである。なのに実際には、決してこの種の技能はデジタル製品、特にウェブサイトには移転されなかった。ほとんどが1998年からきているにように見えるのだ。

日本のほとんどのポピュラーサイトの巡ってみると、以下のようなことがわかる(Goo楽天読売新聞ニコニコOKWave@cosmeなどを見て欲しい)。

  • ぎっしりと詰め込まれたテキスト
  • 小さい低品質の画像
  • 数えられないくらいのたくさんのカラム
  • Flashのような古い技術の過度の使用

美しい俳句あるいはミニマルな侘び寂びは無い。なぜこうなのかという理由はたくさんあり、これから私が最も多く見られる理由を説明しようと思う。

言語の違い

文字コンフォート - 表語文字をベースにした言語は数文字で多くの意味を含めることができる。これらの文字が西洋人の目には乱雑でわかりにくく見えるが、実は日本語を話す人は短期間/小さな空間に多くの情報を処理することが容易になるのだ(中国人にも言えることだ)。

強調不足 - 日本語は斜体や大文字を持っておらず、ラテンアルファベットが持つビュジュアルな効果を加える機会を制限されている。多くのデザイナは装飾を加えたり画像テキストを使うことで回避しているが、タイプだけで情報を構造化するために階層的なコントラストを作成するのをより難しくしている。

言語バリア - ウェブやほとんどのプログラミング言語は英語を話す人や欧米の企業向けに設計されている。そのため、大多数のドキュメントや教育リソースも英語で書かれている。翻訳は進んでいるが、新しい技術や流行の適用への遅れにつながっている。

文化の違い

リスク回避 - 一般に日本文化は、リスクを負うような危険あるいは集団の中で目立つようなことをしない。より良い解決策があっても、先例が明白な方法を見て動くことに合わせ、皆がそれに続く。日本のサブカルチャーでも彼ら自身のファッションやルールを守っている。

消費者行動 - 人々は購入を決断する前に、長い説明や技術仕様書によって高い保証を求める。彼らはキャッチーな見出しや可愛い画像では容易に揺さぶられない。「より少ないことは、より豊かなこと」の格言はここでは全く当てはまらないのだ。

広告 - 人々にとって有効なツールとしてよりも、日本の企業はしばしばウェブを派手にメッセージを押し付けるための新手の広告プラットフォームのように見ている。ウェブサイトは、最終的にインタラクティブなツールというよりもパンフレットと類似のより小さなスペースへの情報が最大濃度となるように落ち着く。

都市景観 - 渋谷のような東京の主要なハブの一つを歩いてみて欲しい。絶えず明るいネオン広告、騒がしいパチンコ(ゲームセンター)、騒々しいサラリーマンあるいは学生の集団に翻弄される。通りの同じ無秩序な忙しさがウェブに波及しているように見える。これに加え、日本では異常に高い値段で土地スペースが売られているので、何からなにまで無駄ではなく、同じことでウェブページ上の空白にネガティブなのである。

仕事の役割 - 日本でのジョブサイトを見て欲しい。すると、企業がプラグラムやウェブサイトの運営にIT技術者を雇い入れる時のことを思い出させる「ウェブマスタ」と「ウェブ管理者」のような役割向けの宣伝を相変わらず見るだろう。逆の立場で、クリエイティブな人は自由の創造を求めており、彼らは他の場所に行っているため、大企業の中で簡単に見つけられない。

技術的な違い

モバイル遺産 - 日本はiPhone登場以前は高度に進化した折り畳み携帯でモバイルウェブを利用しており、さらにパソコンよりも大量にあった。当時は、スクリーンが小さく、サイトはこの小さな空間の中に内容を詰め込むよう設計された、今でもそん影響が続いている。

ウェブフォント - 非ラテン言語(中国語、日本語...)のウェブフォントが不足している。各フォントはデザインに数千文字が必要で、極めて高価で、時間が掛かり、ダウンロードにも時間が掛かるためである。これらの理由でデザイナは非標準の書体を表示するプレーンテキストよりも画像を使う傾向にある。

Windows XP & IE 6 - 古いマイクロソフトのソフトウェアを使っている多くの人は急速に減少しているが、まだこれらの古いソフトウェアを使っている人の数はかなりまだいる(特に企業の環境)。もう十分だ。


東京を歩き回ると、私はしばしば未来のビジョンで1980年代に立ち往生した感覚になる。多くの点で、 日本のデザイン景観を特徴づけている矛盾がある。一面には、我々は退屈で大量生産される同じものを大量に作り出している巨大なコングロマリットを持っており、一方では優れた職人が信じられない美と機能を持つものを作るのも知っている。

前向きな意見として、日本でもユニクロ無印良品クックパッド紀伊国屋書店のようなスモーラーデザイン企業が審美的で感じが良く機能的なウェブサイトを作ることを示している。彼らから学んで、すぐに追いついてくれるとよいのだが。

更に興味深い議論がここにある: 1, 2, 3, 4, 5