Episode 38 of The SitePoint Podcast is now available! This week your hosts are Stephan Segraves (@ssegraves) and Kevin Yank (@sentience).

SitePoint Podcast的 第38集現已發布！ 本周的主持人是Stephan Segraves( @ssegraves )和Kevin Yank( @sentience )。

下載此劇集 (Download this Episode)

You can also download this episode as a standalone MP3 file. Here’s the link:

您也可以將本集下載為獨立的MP3文件。 這是鏈接：

• SitePoint Podcast #38: A Brain of Cats (MP3, 48.1MB)

  SitePoint播客＃38：貓腦 (MP3，48.1MB)

劇集摘要 (Episode Summary)

Here are the topics covered in this episode:

以下是本集中介紹的主題：

301Works Plans to Save Short URLs

301Works計劃保存短URL

• SitePoint Podcast #24: Those Frames are Ironic (SitePoint)

  SitePoint Podcast＃24：那些框架具有諷刺意味 (SitePoint)

• 301Works.org

  301Works.org

• SHORTURL FEUD: Tr.im Slams Twitter and Bit.ly, Goes Open Source (Mashable)

  簡短內容：Tr.im抨擊Twitter和Bit.ly，成為開源 (可混搭)

• URL shorteners working with Internet Archive for long-term preservation (Internet Archive)

  URL縮短器與Internet存檔一起用于長期保存 (Internet存檔)

• 310Works.org

  310Works.org

Internet Explorer 9: Early Days

Internet Explorer 9：早期

• An Early Look At IE9 for Developers (Microsoft)

  面向開發人員的IE9的早期查看 (Microsoft)

• Channel 9 videos:

  頻道9的視頻：

  • Standards & Interoperability

    標準與互操作性

  • IE9’s New JavaScript Engine

    IE9的新JavaScript引擎

  • GPU-accelerated Graphics in IE9

    IE9中的GPU加速圖形

Proposed Standard for Resource Packages

資源包擬議標準

• Making browsers faster: Resource Packages (Alexander Limi)

  使瀏覽器更快：資源包 (Alexander Limi)

AOL Rebranding

AOL品牌重塑

• New Branding and Logos for AOL (SitePoint)

  AOL (SitePoint)的新品牌和徽標

• Win $800 for redesigning the London 2010 Olympic Logo (SitePoint)

  重新設計倫敦2010年奧運會徽標 (SitePoint) 可獲得800美元的獎勵

• AOL’s New Brand Identity Comes to Life in Animation (AOL)

  AOL的新品牌標識在動畫 (AOL) 中變得栩栩如生

• New Corporate Identity for Melbourne (SitePoint)

  墨爾本的新企業標識 (SitePoint)

• ANZ Bank Rebrand – A Super Regional Bank? (Truly Deeply/Madly)

  澳新銀行更名–超級區域銀行？ (深深地/瘋狂地)

Are iPhone Developers Stupid?

iPhone開發人員是愚蠢的嗎？

• Apple is not evil. iPhone developers are stupid. (QuirksMode)

  蘋果并不邪惡。 iPhone開發人員很愚蠢。 (QuirksMode)

• Airfoil Speakers Touch 1.0.1 Finally Ships (Rogue Amoeba)

  機翼揚聲器Touch 1.0.1最終出貨 (Rogue Amoeba)

• Apple’s Schiller Defends iPhone App Approval Process (Business Week)

  Apple的Schiller捍衛i??Phone的審批流程 (商業周刊)

• Airfoil Speakers Touch 1.0.2 Is Now Available (Rogue Amoeba)

  翼型揚聲器Touch 1.0.2現已上市 (Rogue Amoeba)

• Native iPhone apps vs. Web apps (QuirksMode)

  本機iPhone應用程序與Web應用程序 (QuirksMode)

• iPhone Developers are not arrogant and stupid :) (Dion Almaer)

  iPhone開發人員并不傲慢愚蠢:) (Dion Almaer)

• iPhone Developers Aren’t Stupid, PPK (Faruk Ate?)

  iPhone開發人員不是愚蠢的PPK (Faruk Ate？)

Host Spotlights:

主持人聚光燈：

• Stephan: I Love Charts

  斯蒂芬： 我愛圖表

• Kevin: Support Details

  凱文： 支持詳細信息

顯示成績單 (Show Transcript)

Kevin: November 27th, 2009. The Internet Archive comes to the rescue of short URLs; Microsoft provides a sneak peek at what’s coming in IE9; and AOL gets a new logo … or does it? This is the SitePoint Podcast #38: A Brain of Cats.

凱文(Kevin)： 2009年11月27日。互聯網檔案館開始提供簡短的網址； 微軟對IE9的功能進行了簡要介紹。 AOL得到了一個新徽標…還是？ 這是SitePoint播客38：貓的大腦。

And welcome to another episode of the SitePoint Podcast. We have a shortage of hosts this week, just me and Stephan Segraves joining you today, but luckily, there’s no shortage of stuff to talk about, Stephan. We’ve got 301Works.org, the new AOL logo, some whisperings of what’s coming in Internet Explorer 9 and someone asking if iPhone developers are stupid—all that and more on the show today. But let’s start with the 301Works because it’s something we’ve talked about before way back in podcast 24, right, Stephan?

歡迎收看SitePoint播客的另一集。 本周我們缺少主持人，只有我和Stephan Segraves今天加入您的行列，但幸運的是，Stephan并沒有什么可以談論的東西。 我們已經有了301Works.org，新的AOL徽標，對Internet Explorer 9即將發布的消息的耳語，以及有人問iPhone開發人員是否愚蠢-今天的節目以及所有這些。 但是，讓我們從301Works開始，因為這是我們早在播客24中就已經討論過的，對，斯蒂芬？

Stephan: Yep, we sure did. We talked about what’s going to happen if— tr.im, at the time, had gone away and the URLs had disappeared and 301Works.org has shown up and they have come up with a way, or have come up with a plan, I should say, to bring back the URLs or give us a historical archive of the URLs if something should happen to another URL shortening service.

史蒂芬：是的 ，我們當然做到了。 我們討論了如果tr.im當時消失了，URL消失了，并且301Works.org已經出現并且他們想出了辦法或想出了一個計劃，該怎么辦？應該說，如果另一個URL縮短服務有問題，請帶回URL或為我們提供URL的歷史存檔。

Kevin: So to refresh the memories of our listeners, this all has to do with short URLs that have become popular because of Twitter—because Twitter limits the number of characters you can put in a message—and so the shorter the URL the better. So all these services like trim, like bit.ly, which is the market leader, let you create short URLs that redirect to long URLs. So, yeah, as you say, there’s concern and we saw it with tr.im. It almost shut down and at that time 301Works.org was something that had been dreamed up by bit.ly and trim in its death throes at the time, took a shot at 301Works. They called it “little more than a bit.ly public relations stunt.”

凱文：因此，為了刷新我們的聽眾的回憶，這與因Twitter而流行的短URL有關-因為Twitter限制了您可以在消息中輸入的字符數-因此URL越短越好。 因此，所有這些服務(如trim)(如市場領先者bit.ly )都可以讓您創建重定向到長URL的短URL。 所以，是的，正如您所說，我們一直在關注tr.im。 它幾乎關閉了，那時301Works.org曾被bit.ly夢到，并在其死亡之喉中修剪，在301Works上開槍。 他們稱其為 “不只是一點點公關st頭”。

Stephan: I think they’re just angry about bit.ly being the Twitter’s de facto standard at the time.

斯蒂芬：我認為他們只是對當時成為Twitter的事實上的標準感到生氣。

Kevin: Yeah. I can’t say it was a very classy move. It got me wondering. I wondered if they were right that 301Works really was just a way of bit.ly saying everyone else is ‘fly-by-night’ and if anything goes wrong, we’ll take care of it for you.

凱文：是的。 我不能說這是一個非常經典的舉動。 我很納悶。 我想知道301Works是否確實是對的說法，只是說別人都在“夜間飛行”，如果有什么問題，我們會為您解決。

Stephan: Well, it looks like this is actually moving forward, which is impressive. I mean they’ve got archive, what is it, Archive.org now behind it and they’re coming up with a plan, so I think it looks legitimate that they’re really trying to make this work.

史蒂芬：嗯，看來這實際上正在向前發展，這令人印象深刻。 我的意思是他們已經有了檔案，這是什么，Archive.org現在正在其背后，并且他們正在提出一個計劃，因此我認為他們確實在努力使這項工作看起來是合法的。

Kevin: Maybe it was a public relations stunt at the time but it looks like it has come a long way and if it’s got the support of Archive.org, color me impressed. There’s this announcement on the Archive.org web site saying that the 301Works.org domain and that the responsibility for that has been handed over to Archive.org. So in the case of any URL shortening service that is a member of this working group; in the case that any one of these goes down or goes away or goes out of business, everyone who’s signed on to this has pledged to hand over the keys to their domain to Archive.org and meanwhile, Archive.org is keeping a running archive of all of these short URLs that are being created so that if they ever need to, if any one of these players goes out of business, Archive.org can take over responsibility for that domain and continue redirecting all those URLs for as long as necessary—which is forever, basically. So this is great.

凱文：也許這在當時是個公共關系特技，但看起來已經走了很長一段路，如果得到Archive.org的支持，我的印象會很深刻。 在Archive.org網站上有此公告，稱301Works.org域及其責任已移交給Archive.org。 因此，對于屬于該工作組成員的任何URL縮短服務而言； 如果其中任何一個發生故障，崩潰或倒閉，則每個簽署此協議的人都承諾將其域的密鑰移交給Archive.org，與此同時，Archive.org會保留一個正在運行的存檔創建的所有這些短URL中，以便如果有需要的話，如果其中任何一個播放器停業，Archive.org可以接管該域的職責，并在必要時繼續重定向所有這些URL。 -基本上是永遠的。 所以這很棒。

Stephan: It is good news. It’s really good news. I was looking at the participating companies I don’t see tr.im on the list.

斯蒂芬：這是個好消息。 這真是個好消息。 我當時在看參加名單的公司，但沒有看到tr.im。

Kevin: No.

凱文：不。

Stephan: And so it’s kind of like, “Well, everyone should be participating, why not?”

史蒂芬：所以有點像，“嗯，每個人都應該參加，為什么不參加？”

Kevin: Yeah, and trim at the time said— Well, bit.ly extended an olive branch, as they put it and said, “trim, if you’re going out of business, we’ll take care of you under the 301Works initiative,” and trim said, “Nuts to that. We’re just going to sell our service.” And if memory serves, they couldn’t find anyone willing to pay what it was worth without effectively spamming all the users of the service in return and so they went into business for themselves—or they open sourced it and promised that they would continue funding it for as long as necessary to keep it running. I’m not sure how well that’s working out for them.

凱文：是的，當時修剪說—好吧，按位延伸橄欖枝，就像他們說的那樣：“修剪，如果您要倒閉，我們會在301Works的幫助下照顧您主動，”特里姆說，“這很重要。 我們將出售我們的服務。” 而且，如果有記憶，他們將找不到愿意支付其價值的人，而不會有效地向服務的所有用戶發送垃圾郵件，因此他們會自己做生意—或者他們開源并承諾將繼續提供資金保持運行所需的時間。 我不確定這對他們的效果如何。

Stephan: So that leads to the question of do you think this leads to us being more reliant on the URL shorteners—the services—or do you think we should still do it ourselves because we were having a discussion, should we do it ourselves or should we use a service. I was wondering what you thought about that.

史蒂芬(Stephan)：因此，這就引出了一個問題，您是否認為這導致我們更加依賴URL縮短器(服務)？還是您認為我們還是應該自己做，因為我們正在討論，應該自己進行還是要進行討論？我們應該使用服務嗎？ 我想知道你對此有何想法。

Kevin: Yeah, it’s a good question.

凱文：是的，這是一個很好的問題。

Stephan: I’m kind of like wanting to go back to bit.ly and just use bit.ly for everything now.

史蒂芬：我有點想回到bit.ly，現在就使用bit.ly進行所有操作。

Kevin: I think, technically, the right approach is for people to shorten their own URLs using an open standard like the one that we saw that let you put a <link> tag in your pages saying ‘the short URL to this page is the following’, and that way, everyone’s responsible for maintaining their own URLs, it’s a sharing of the load. If your short URLs stop working, it’s because you fell asleep at the wheel, you didn’t care enough about keeping your content permalinked, but that doesn’t affect the internet as a whole.

凱文：我認為，從技術上講，正確的方法是讓人們使用一種開放標準來縮短自己的URL，就像我們看到的那樣，您可以在頁面中放置<link>標記，說“此頁面的短URL是”，這樣，每個人都有責任維護自己的網址，這是負擔的分擔。 如果您的短網址停止工作，那是因為您睡著了，就沒有在意保持內容永久鏈接了，但是這并沒有影響整個Internet。

Stephan: Gotcha.

斯蒂芬：哥。

Kevin: Unfortunately, on the Web, the best technical solution isn’t always the one that wins out. Sometimes it’s the one that’s the most convenient and so I think people will end up relying on services like bit.ly and the fact that Archive.org is stepping in… You know, Archive.org—this is the business they’re in. They’re in the business of preserving the history of the Web despite the fact that people are lazy and people will let their sites go away and giant sites like GeoCities will shut down because of financial concerns with no thought to the permanent record. So I think if we were all doing the right thing, if everyone chose the right course by history, then there wouldn’t be a need for Archive.org, but I think there is that need and I’m glad they’re there.

凱文：不幸的是，在網絡上，最好的技術解決方案并不總是成功的。 有時這是最方便的一種，所以我認為人們最終將依賴bit.ly這樣的服務，而Archive.org正在介入這一事實……您知道，Archive.org –這是他們所從事的業務。盡管人們很懶惰并且人們會讓他們的站點消失，并且諸如GeoCities之類的巨型站點由于財務方面的考慮而被關閉，但他們卻一直在保留Web的歷史，但他們并沒有想到永久記錄。 因此，我認為如果我們都在做正確的事情，如果每個人都根據歷史選擇了正確的課程，那么就不需要Archive.org，但是我認為有這種需要，我很高興他們在那里。

Stephan: Yeah, I agree.

斯蒂芬：是的，我同意。

Kevin: Interesting though at the very end of the Archive.org announcement, they provide a link to the 301Works web site and it’s a typo–they put a link to 310Works.org. So someone clever jumped on that and put a site up at 310Works.org with some Google ads on it but they were nice enough to actually write on this web site about URL shortening, about why it’s a risky thing and why the 301Works initiative is a good one and they then provide a link to the actual 301Works site. I’m quoting here. They say, “310Works.org is absolutely not the organization that’s needed. In fact, it is a pathetic, confusing, and cheap for-profit-please web site that aims to take advantage of an honest and simple typo. These guys are douches. If however, you really are interested in the longevity of shortened URLs, we suggest you visit 301works.org.” So they have a sense of humor about themselves and that’s great.

凱文：盡管在Archive.org公告的最后，有趣的是，它們提供了到301Works網站的鏈接，這是一個錯別字-他們鏈接到310Works.org 。 因此，有人巧妙地跳了進去，并在310Works.org上放置了一個網站，上面放有一些Google廣告，但是他們很不錯，可以在該網站上實際寫有關URL縮短，為什么這是危險的事情以及為什么301Works計劃是好人，然后他們提供了到實際301Works網站的鏈接。 我在這里引用。 他們說：“ 310Works.org絕對不是所需的組織。 實際上，這是一個可悲，令人困惑且廉價的營利性網站，旨在利用誠實和簡單的錯字。 這些家伙是混蛋。 但是，如果您真的對縮短URL的壽命感興趣，建議您訪問301works.org。” 因此他們對自己有幽默感，這很棒。

Stephan: That was nice of them to give a link.

史蒂芬：很高興給他們一個鏈接。

Kevin: Yeah. Next thing we’re looking at is Internet Explorer 9. We joked about Internet Explorer 9 in my recordings that I did at Web Directions South a couple of months back. One of the attendees there was smart-cracking that was he was really excited about on the web at the moment was Internet Explorer 9, which at the time didn’t even exist. But now Microsoft has come out and provided a sneak peek at what they’re working on for Internet Explorer 9 and what especially interested me in this case is that they’re actually calling it Internet Explorer 9. At this point in the development of IE 7 and IE 8, they said, “Yeah, the marketing people haven’t made a final decision on what it’ll be called so we can’t call it anything other than the next version of Internet Explorer.” So we started calling it IE Next. But it seems like they’ve lightened up or at least they already know that it’s going to be Internet Explorer 9 when they’re done with it, but yeah, here we have on the Internet Explorer blog a look at what’s coming. Stephan, correct me if I’m wrong but you weren’t too impressed by this.

凱文：是的。 接下來要看的是Internet Explorer9。幾個月前，我在Web Directions South的錄音中對Internet Explorer 9開玩笑。 與會者中有一位非常聰明，他當時對Internet感到非常興奮，當時Internet Explorer 9當時還不存在。 但是，現在Microsoft已經出來，并為他們在Internet Explorer 9上的工作提供了一個偷看的機會 ，在這種情況下，我特別感興趣的是他們實際上將其稱為Internet Explorer 9。在7和IE 8中，他們說：“是的，市場營銷人員尚未決定將其稱為什么的最終決定，因此我們只能將其稱為下一版Internet Explorer。” 因此，我們開始將其稱為IE Next。 但是似乎他們已經減輕了負擔，或者至少他們已經知道完成后將是Internet Explorer 9，但是，是的，在Internet Explorer博客上我們可以看到即將發生的事情。 史蒂芬(Stephan)，如果我錯了，請糾正我，但您對此并不太感動。

Stephan: No, I mean I don’t use Internet Explorer to begin with, but the first thing that I saw was the lack of ability to pass the Acid3 Test—just caught my eye—and I’m like oh…

史蒂芬：不，我的意思是說我一開始并不使用Internet Explorer，但是我看到的第一件事是缺乏通過Acid3測試的能力-引起了我的注意-我就像是…

Kevin: Yeah, they’re bragging about the fact that their current internal build has achieved 32 out of 100 on the Acid3 Test.

凱文：是的，他們吹牛說，他們的內部構造在Acid3測試中已經達到100分中的32分。

Stephan: Maybe they just haven’t got around to the other 68, I don’t know.

史蒂芬：也許他們只是還沒有和其他68人交往，我不知道。

Kevin: And I say bragging. I say bragging and that’s a loaded term so I could be seen as accusing them of pounding their chests and saying, “Look how great Internet Explorer is,” and I hate to make that implication but that’s really how a lot of this blog post reads. It’s written in this tone of, “Here are the amazing things that are coming in Internet Explorer 9. We’re going to have better support for the Acid3 Test,” where browsers like Opera now have released a version that passes Acid3, 100 out of 100. “We’re going to have support for CSS rounded corners,” hallelujah!

凱文：我說吹牛。 我說的是吹牛，這是一個滿載的名詞，所以我可以看作是指責他們猛擊他們的胸部，然后說：“看看Internet Explorer有多棒”，我不愿暗示這個含義，但實際上，這是本博文中的許多內容。 它用這樣的語氣寫著：“這是Internet Explorer 9中即將出現的令人驚奇的東西。我們將更好地支持Acid3 Test，其中Opera等瀏覽器現在發布了可通過Acid3(100分)的版本。 100。“我們將為CSS圓角提供支持，” hallelujah！

Stephan: Finally.

史蒂芬：最后。

Kevin: Finally but that’s not impressive. That’s, “Wow, at last, you got around to it!” sort of thing.

凱文：最后，但這并不令人印象深刻。 那就是“哇，終于，你明白了！” 那類的東西。

Stephan: It’s a little bit of cheerleading; I think is what I what I see.

斯蒂芬：有點啦啦隊。 我認為這就是我所看到的。

Kevin: It is a bit of cheerleading and I am wondering if Microsoft feels that they have earned the right to cheerlead their browser, whereas in the Internet Explorer 7 timeframe, that entire release, they were hat in hand. They were, “We’re really sorry. We know we screwed up by stopping development on Internet Explorer. Please take Internet Explorer 7 as a token of our apology in this matter.” IE8, they were kind of like, “Yeah, we’ve addressed the most important issues for developers and this is a big step forward in bringing Internet Explorer closer to the competition and catching up on the stuff that we fell behind on.” I’m not seeing a lot of that contrite tone in what they’re talking about in IE9. They’ve posted three videos on the Channel 9 web site, which is kind of a Microsoft developer outreach community site and their interviews with the engineers that are working on this showing off demos of the stuff; and they’re continually saying throughout the video “it’s very early days”. Its’ clear, this is not the complete feature set or the final performance of what we’re going to see in Internet Explorer 9. I think it’ll be interesting to count the number of times they mention the fact that this is an early build, this is early days, we’re just getting started here—this is just a taste of what’s to come.

凱文(Kevin)：有點拉拉隊，我想知道微軟是否認為他們已經獲得拉拉隊拉拉隊的權利，而在Internet Explorer 7的整個框架中，他們都在手。 他們是，“我們真的很抱歉。 我們知道我們通過停止Internet Explorer上的開發而搞砸了。 在此問題上，請以Internet Explorer 7為我們道歉的標志。” IE8有點像，“是的，我們已經為開發人員解決了最重要的問題，這是使Internet Explorer更接近競爭對手并趕上我們落后的重要一步。” 我在他們在IE9中談論的內容中沒有看到很多con悔的語氣。 他們在Channel 9網站上發布了三個視頻，這是一個Microsoft開發人員外展社區網站，他們對正在從事此工作的工程師的采訪展示了這些東西的演示。 他們在整個視頻中不斷說“現在還很早”。 很明顯，這不是完整的功能集，也不是我們將要在Internet Explorer 9中看到的最終性能。我認為對他們提到這是一個早期事實的次數進行計數會很有趣。構建，這是早期，我們才剛剛開始-這只是對即將發生的事情的了解。

Stephan: Well, I wonder if this is kind of like the positive marketing spin that we’ve seen kind of with Windows 7 where they’re trying to meet the Apple, “We’re positive—we’re doing good things,” standard and they’re not trying to be negative or making up for something that they’ve done wrong in the past. That’s kind of what it comes off to me as. They want to be— “We’re doing something cool. This is new.” They want to be out there and that’s fine as long as their product actually delivers on what they’re promising.

斯蒂芬：嗯，我想知道這是否像我們在Windows 7上看到的積極營銷那樣，他們試圖與蘋果見面，“我們很積極-我們做得很好”。標準，他們并沒有試圖消極或彌補過去做錯的事情。 這就是我的想法。 他們想成為-“我們正在做一些很棒的事情。 這是新的。” 他們希望在那里，只要他們的產品能夠真正兌現他們的承諾就可以了。

Kevin: What they’re promising so far isn’t a lot. They say that Internet Explorer 9 will have JavaScript performance on par with Firefox 3.7. And for those not keeping track, Firefox 3.6 is currently in beta, 3.7 is kind of a next alpha version that’s coming; and one of the biggest things it has in it is an enhanced JavaScript engine. So IE 9 is aiming to match Firefox 3.7’s JavaScript performance and they say that will bring them much closer to the industry leader, Chrome and browsers like…

凱文：到目前為止，他們所承諾的并不多。 他們說Internet Explorer 9將具有與Firefox 3.7相當JavaScript性能。 對于那些不了解的人，Firefox 3.6當前處于beta中，而3.7是即將發布的下一個alpha版本。 它最大的優點之一就是增強JavaScript引擎。 因此IE 9的目標是匹配Firefox 3.7JavaScript性能，他們說這將使它們更接近行業領導者，Chrome和類似的瀏覽器。

Stephan: Safari.

史蒂芬： Safari。

Kevin: Like Safari are also quite fast in the JavaScript stakes. So they’re not aiming to match the leader of the pack, they’re aiming to catch up with the next one.

凱文(Kevin)：像Safari一樣，在JavaScript方面也相當快。 因此，他們的目標不是與之匹敵，而是追趕下一位。

Stephan: The stragglers.

史蒂芬：流浪漢。

Kevin: Yeah, the last of these stragglers. They also say they’re working on passing the Acid3 Test although they’re not making any promises there. They demoed CSS rounded corners and they mentioned that they’ve got a lot of new support for CSS 3 Selectors. So congratulations on all that stuff. We’re eagerly anticipating news of what else is going to be in IE 9. So far we’re nodding along but we’re not that impressed.

凱文：是的，這些游蕩者中的最后一個。 他們還說盡管他們沒有做出任何承諾，但他們正在努力通過Acid3測試。 他們演示了CSS圓角，并提到他們對CSS 3選擇器有了很多新的支持。 所以恭喜所有這些東西。 我們熱切期待IE 9中還會有其他消息。到目前為止，我們一直在點頭，但印象并不深刻。

The other big thing that they mentioned was enhanced rendering performance using Direct2D. So rather than using the slow API that is used to draw buttons and menus and text labels in the Windows user interface—which is GDI—they are moving something closer to the Direct3D, hardware-accelerated 3D rendering engine, only this is a 2D version of that. So they’re going to be using the brains and power of your computer’s graphics processor to smooth out the rendering of fonts and texts and animations within Internet Explorer 9. And I think we’ve seen a lot of similar work from Apple because they rely so much on their Safari rendering engine to provide smooth animations in user interfaces throughout their operating system and to some extent, on the iPhone. That technology is key to Apple’s flagship polish—or Apple’s noted polish in the user experience—and so it’s clear that Microsoft has taken note and they’re trying to bring the same sort of thing to Internet Explorer 9 so that animated web applications will look just as smooth in IE 9 as they do in other browsers. The demo they showed showed just a piece of text slowly getting bigger, and how in IE 8 it kind of gets bigger one whole pixel at a time and therefore it’s kind of a jumpy animation, whereas the Direct2D has sub-pixel rendering and so it’s a very smooth, cinematic experience. It’s all good stuff but I think we agree there’s a lot more work to be done for Internet Explorer to be considered the leader in the market again.

他們提到的另一件大事是使用Direct2D增強了渲染性能。 因此，與其使用用于在Windows用戶界面(即GDI)中繪制按鈕，菜單和文本標簽的慢速API，它們將更接近Direct3D，硬件加速的3D渲染引擎，僅這是2D版本其中。 因此，他們將利用計算機圖形處理器的大腦和力量來平滑Internet Explorer 9中字體，文本和動畫的渲染。而且我認為我們已經從Apple那里看到了許多類似的作品，因為它們依賴在Safari渲染引擎上進行了大量的操作，以在整個操作系統中以及在一定程度上在iPhone上的用戶界面中提供流暢的動畫。 這項技術是Apple旗艦級拋光(或用戶體驗中Apple著名的拋光)的關鍵，因此很明顯，Microsoft已經注意到了這一點，他們正在嘗試將相同的東西引入Internet Explorer 9，以便動畫Web應用程序看起來像在IE 9中就像在其他瀏覽器中一樣流暢。 他們展示的演示僅顯示了一段文本逐漸變大的情況，以及在IE 8中如何一次變大一個完整像素，因此這是一種跳躍的動畫，而Direct2D具有亞像素渲染，因此非常流暢的電影體驗。 這些都是好東西，但我認為我們同意要做更多工作才能使Internet Explorer再次被認為是市場的領導者。

A browser that’s doing more interesting work in advancing the leading edge of web technology is Firefox and there’s this proposal that I caught sight of earlier this week and it’s a proposal for resource packages. This is clearly a proposal that’s supposed to attract the attention of other browser makers and eventually lead to a standard but this is something that’s being implemented in Firefox 3.7 again and they say, “What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site—CSS, JavaScript, images, anything else—in a single HTTP request at the start of the first visit to the page? This is what resource package support in browsers will let you do.”

Firefox在提升Web技術的領先地位方面做得更加有趣，這是我本周早些時候注意到的一項提議 ，它是關于資源包的一項提議 。 顯然，這是一個應該引起其他瀏覽器制造商注意并最終形成標準的提議，但這是在Firefox 3.7中再次實現的提議，他們說：“如果有一種向后兼容的方式來傳輸所有在您第一次訪問該頁面時，在單個HTTP請求中在網站的每個頁面上使用的資源(CSS，JavaScript，圖像或其他任何資源)？ 這就是瀏覽器中資源包支持將使您做到的。”

Stephan, have you ever had to worry about performance issues that come as a result of static things like CSS, JavaScript—all those requests bugging down the browser?

史蒂芬(Stephan)，您是否曾經擔心過諸如CSS，JavaScript之類的靜態事物所導致的性能問題，所有這些請求都困擾著瀏覽器？

Stephan: Oh, yeah. Yeah, I mean sometimes I’ll be sitting there loading something and it will take longer than what I would expect for my high bandwidth connection to load and it’s not even the connection. It’s actually the browser is having trouble parsing it all out really quickly. So it’s a mixed thing. My connection is slow and then my browser is slow, at the same time. I do have that problem and this sounds like a great way to get around that to me. It sounds like its common sense.

斯蒂芬：哦，是的。 是的，我的意思是有時我會坐在那里加載一些東西，這將比我為高帶寬連接加載所需的時間更長，甚至連連接也沒有。 實際上，瀏覽器無法真正快速解析所有內容。 因此，這是一件復雜的事情。 同時，我的連接速度很慢，然后瀏覽器速度也很慢。 我確實有這個問題，這聽起來像是解決該問題的好方法。 聽起來像是常識。

Kevin: For a couple of years now, Yahoo! have really been pushing this agenda that if you want to speed up your sites, you don’t need to focus exclusively on the speed of your PHP page rendering—that a lot of headway can be made just by minimizing the number of files that your browser needs to request to display a page—and that a lot of the waiting time when you’re loading a web page is the browser making its initial connection, and also, browsers tend to put limits on how many things they’ll download at once from a given web site. So if you’ve got 20 files that need to be loaded for your homepage, your typical browser is only going to download, say, four of them at a time and then move on to the next four and then the next four and as a result, that time adds up. And so tools like YSlow—which is a plug-in for Firebug and it spots performance issues that are visible from the client side of your site—they’ve put heavy emphasis on pointing out when you’ve got multiple CSS files, when you’ve got multiple JavaScript files and how these things can be combined into one. And if you really want to take this to extremes, you can do something called CSS Sprites where you try and combine all of the images on your page into a single big image that has them all sort of pasted side by side, and then you use CSS to only display the portion of that master image in each spot on your site so that the browser’s only downloading one image but you’re displaying different parts of it in different parts of your page. I don’t think that’s something your average web site needs to worry about, but if you are a massive media site, if you’re CNN.com or something like that, this kind of work can really make a huge difference to the performance your users see.

凱文：幾年來，雅虎！ 實際上一直在推動這一議程，即如果您想加快站點速度，就不必只專注于PHP頁面呈現的速度-只需減少您的文件數量就可以取得很多進展瀏覽器需要請求顯示一個頁面-加載網頁時，很多等待時間是瀏覽器建立了初始連接，而且，瀏覽器往往會限制它們在以下位置下載的內容一次來自給定的網站。 因此，如果您的首頁需要加載20個文件，則典型的瀏覽器一次只會下載其中四個文件，然后再轉到接下來的四個文件，然后再轉到接下來的四個文件，結果，那段時間加起來了。 因此，諸如YSlow之類的工具(它是Firebug的一個插件，它可以發現從網站客戶端可見的性能問題)，它們特別著重指出當您具有多個CSS文件時，有多個JavaScript文件，以及如何將這些文件合并為一個文件。 而且，如果您確實想將其發揮到極致，則可以執行CSS Sprites，將頁面上的所有圖像合并為一個大圖像，并排粘貼所有這些圖像，然后使用CSS僅在您網站的每個位置顯示該主圖像的一部分，以便瀏覽器僅下載一個圖像，但是您在頁面的不同部分顯示了它的不同部分。 我認為您不必擔心一般的網站，但是如果您是大型媒體網站，如果您是CNN.com或類似的網站，這種工作確實會對性能產生巨大的影響您的用戶可以看到。

And it looks like the person who wrote this proposal had something to do with YouTube because they point out the need, for example, that YouTube is constantly displaying thumbnails of related videos down the side and those dynamically generated thumbnails—it’s a different combination of thumbnails for every page on YouTube and as a result, they can’t do clever things like CSS Sprites in order to save load time.

看起來，撰寫此提案的人與YouTube有某種關系，因為他們指出了這樣的需求，例如YouTube不斷在側面顯示相關視頻的縮略圖和動態生成的縮略圖-這是縮略圖的不同組合因此，對于YouTube上的每個頁面，他們都無法執行CSS Sprites之類的巧妙操作來節省加載時間。

And it’s nice and backwards compatible. The idea is you make a web page just as you would before but then you put a <link> tag again–a magical <link> tag–at the top of your page that says, “Before you start downloading any of the CSS, JavaScript, and images referenced in this page, download this one file first and this file is a ZIP file, which contains as many of these static resources as you can fit in there.” It downloads this one file, it figures out where all of these files are linked from—where they belong in your site—and then as it processes your page and it sees an image that it would load otherwise, it goes, “Oh, I’ve already got that from the resource package. I don’t need to download it again.” And so at an extreme, you can download a whole web page with two HTTP requests: one for the web page and one for the resource package.

它很好并且向后兼容。 這個想法是，您像以前一樣制作網頁，然后在頁面頂部再次放置一個<link>標記(一個神奇的<link>標記)，上面寫著：“在開始下載任何CSS之前， JavaScript和此頁面中引用的圖像，請首先下載該文件，該文件是ZIP文件，其中包含您可以容納的盡可能多的靜態資源。” 它下載了一個文件，找出了所有這些文件的鏈接源(它們在您網站中的位置)，然后在處理您的頁面時，它會看到要加載的圖像，否則，“哦，我已經從資源包中得到了。 我不需要再次下載。” 因此，在極端情況下，您可以下載帶有兩個HTTP請求的整個網頁：一個用于網頁，一個用于資源包。

Stephan: It seems like it’s a great idea, right? I wonder why we haven’t been doing this before. The only thing I wonder about is the ZIP file and security things that. Do you think anything about that or do you think I’m kind of… I was just wondering. We see cross-eyed scripting, things that were people have gone and they’ve gone and done things behind the scenes and that seems like something that if someone figured out a way to put a harmful ZIP file there or change the path for that ZIP file—that we could see something that’s infecting people’s machines, maybe, or browser. I don’t know. I’m just thinking outside the box.

斯蒂芬：看來這是個好主意，對嗎？ 我想知道為什么我們以前沒有這樣做過。 我唯一想知道的就是ZIP文件和安全性。 您對此有任何想法嗎？還是您覺得我有點……我只是想知道。 我們看到了交叉眼的腳本，人們已經走了，他們已經走了，在幕后做了一些事情，如果有人想出了一種在其中放置有害ZIP文件或更改該ZIP路徑的方法，這似乎是一種東西文件-我們可以看到某些東西正在感染人們的機器，也許是瀏覽器。 我不知道。 我只是在跳出框框思考。

Kevin: Yeah. I don’t quite see it because it’s downloading the ZIP file just as it would download any other things, so if you can replace that ZIP file, you can already wreak a whole lot of havoc. It might be a way of compromising a site in a way the developer might not notice right away. I can see that. The developer goes and looks at it as JavaScript file and goes, “Well, looks fine to me. I can’t see anything wrong with my site,” but meanwhile, the hacker has replaced the ZIP file with a version that contains a malicious copy of that JavaScript file. So I could kind to see that but I don’t think it’s a real risk here. The biggest risk I see here—it’s not a security one, and we mentioned it earlier—that I don’t think the technically correct approach always wins on the Web. I suspect this is one of those things that looks great on paper, solves all the problems, but is any real world developer actually going to go to the trouble of creating these resource packages and keeping them up-to-date whenever they make changes to the files on their site?

凱文：是的。 我不太清楚，因為它正在下載ZIP文件，就像下載其他東西一樣，因此，如果您可以替換該ZIP文件，則已經造成了很大的破壞。 這可能是一種以開發人員可能不會立即注意到的方式破壞網站的方法。 我理解了。 開發人員將其視為JavaScript文件，然后說道：“嗯，對我來說很好。 我看不到我的網站有什么問題。”但是與此同時，黑客已將ZIP文件替換為包含該JavaScript文件的惡意副本的版本。 因此，我很樂意看到這一點，但我認為這并不是真正的風險。 我在這里看到的最大風險-這不是安全性，而我們前面已經提到過-我認為技術上正確的方法并不總是在網絡上勝出。 我懷疑這是在紙面上看起來很不錯的東西，可以解決所有問題，但是任何現實世界的開發人員實際上都會麻煩創建這些資源包并在對它們進行更改時保持最新狀態。他們網站上的文件？

Stephan: Well, it seems like it’s a much more compact way of managing a site. To me, it makes sense even if I’m— I’m not a developer, I’m not a CSS developer, but if I was trying to organize my site into a single file, it seems that that makes sense. We already use tools—like I use Coda—and I already use that tool to organize my site. This seems like this would be a great way to just have a plug-in for Coda and package it all up and ZIP it up and upload it–when I’m done editing.

史蒂芬：嗯，看來這是一種管理站點的更為緊湊的方法。 對我來說，即使我不是開發人員，也不是CSS開發人員，這也是有道理的，但是，如果我嘗試將網站組織成一個文件，那似乎是有道理的。 我們已經使用了工具(就像使用Coda一樣)，并且已經使用該工具來組織我的網站。 似乎這是一種很好的方式，只需為Coda擁有一個插件并將其打包并壓縮并上傳即可-當我完成編輯時。

Kevin: Okay, yeah. If the development tools start generating these resource packages automatically, that would be pretty cool, I have to say.

凱文：好的，是的。 我必須說，如果開發工具開始自動生成這些資源包，那將非常酷。

Stephan: I think that’s a long ways off though. I think since we’re still on paper here, first you’ve got to get the browsers to pick it up. Are they going to really want to write the browser to do this?

斯蒂芬：我認為這還有很長的路要走。 我認為，由于我們仍在紙上談兵，因此首先必須讓瀏覽器將其拾起。 他們真的要編寫瀏覽器來做到這一點嗎？

Kevin: Well, Firefox is leading the way. They’re going to put this in and I guess see how it works and it’s nice that it’s backwards compatible. So just for the sake of argument, let’s say every browser implemented it except one—and I’m not pointing any fingers here—it would make the sites a lot faster on the browsers that did support it, and those that didn’t support it would continue to download the static files the normal way. So yeah, it’s good in that way; the backwards compatibility I applaud. I mean if you were able to drop this backwards compatibility issue, you could quickly make this even more effective by just—you know in Internet Explorer when you save a web page, it gives you the option of saving it as a single file like a compiled web page file that contains everything in it?

凱文：好吧，Firefox處于領先地位。 他們將把它放進去，我想看看它是如何工作的，并且它向后兼容是很好的。 因此，僅出于論證的目的，我們可以說每個瀏覽器都實現了它，除了一個(我在這里沒有指責)之外，這將使支持它的瀏覽器和不支持它的瀏覽器的網站速度更快它將繼續以正常方式下載靜態文件。 是的，那樣很好。 向后兼容我鼓掌。 我的意思是，如果您能夠解決這個向后兼容的問題，則可以通過以下方式使此方法更加有效：您在Internet Explorer中知道保存網頁時，可以選擇將其保存為單個文件，例如包含所有內容的已編譯網頁文件？

Stephan: Yeah.

斯蒂芬：是的。

Kevin: You could put up web pages in that format on the web or something open source and similar but right now, this proposal is talking about cutting it to two requests per page for a fully optimized page, but the natural thing to ask is why don’t you just cut it back to one—make it a single file that contains everything—and then you lose that backwards compatibility because older browsers won’t be able to read those single page packages or those single file packages. So yeah, looking forward to seeing this implemented and for tools to start getting on board as well. I think that is a really important point. CSS Sprites, for example, is really a case of taking extreme measures for performance and the reason for that is there are no tools for automating it. It is a labor intensive thing to do.

凱文：您可以將這種格式的網頁放在網絡上或其他類似開放源代碼的網頁上，但是現在，此提案是在談論將其削減到每頁兩個請求，以獲得完全優化的網頁，但是自然要問的是為什么難道您不只是將其切成一個文件-使其包含所有內容的單個文件-然后就失去了向后兼容性，因為較舊的瀏覽器將無法讀取這些單個頁面程序包或單個文件程序包。 是的，我們期待看到這一實現，以及一些工具也將開始使用。 我認為這是非常重要的一點。 例如，CSS Sprites實際上是采取極端措施以提高性能的一種情況，原因是沒有自動化它的工具。 這是一項勞動密集型的工作。

Stephan: Yep and if you can take out the labor part of this, then there’s a little bit of an incentive besides just performance, it’s also organization. So it makes sense.

斯蒂芬：是的 ，如果您能省掉這部分的勞動，那么除了績效以外，還有一點激勵，它也是組織。 所以這很有意義。

Kevin: AOL is re-branding and it seems like they’re re-branding because Time Warner is splitting them off. After absorbing them several years ago—I’m not sure exactly when—AOL has been operating as a part of Time Warner and it’s being split off into its own company. It’s going to be a content company now. They’re no longer focusing on providing internet access or a richer internet experience. They’re focusing on creating content for the Web. Welcome to the club, guys. And they’ve got a new set of logos, a new brand, and the yellow running man is nowhere to be seen.

凱文：美國在線(AOL)正在重塑品牌，似乎是在重塑品牌，因為時代華納正在將它們拆分。 在幾年前吸收了它們(我不確定確切的時間)之后，AOL一直是時代華納的一部分，并且正被拆分成自己的公司。 現在它將成為內容公司。 他們不再專注于提供Internet訪問或更豐富的Internet體驗。 他們專注于為Web創建內容。 大家好，歡迎加入俱樂部。 他們有了一套新的徽標，一個新的品牌，黃色的奔跑者已無處可尋。

Stephan: So does this mean I have to throw away my 4,000 hours? Are those CDs useless now?

斯蒂芬：那這意味著我必須丟掉4000個小時嗎？ 這些CD現在沒用了嗎？

Kevin: Yeah. I think they’ve been useless for awhile just between you and me. The logo is kind of a non-logo. It’s really interesting. It’s not so much a logo as a branding approach. So they’ve got the letters A-O-L and the A is still upper case but the O, L are lower case, Aol. So like a word, “Aol” and you can’t really tell if the L is a capital I or not. So it kind of looks like AoI as well, and then a period, a full stop at the end and that’s the logo—and it’s white. So it this logo appears on a white piece of paper, it’s going to be invisible. The idea is, the logo, the text becomes visible by having it against a colored background, a picture, a dynamic image of some kind and the samples they show on the logo announcement have it against a gold fish, against a hand giving the “Rock!” sign, a swirly sort of blue ink thing, some scribbles of various colors and I can’t even make out with that last one is—it looks like someone’s brain made of cats. Use your imagination. But you weren’t too impressed by this?

凱文：是的。 我認為他們只是在你我之間一陣子沒用了。 徽標是一種非徽標。 真的很有趣 它不是商標，而是商標方法。 所以他們有字母AOL，A仍然是大寫字母，而O，L是小寫，Aol。 因此，就像一個單詞“ Aol”一樣，您實際上無法確定L是否為大寫字母I。 因此，它看起來也像AoI，然后是一段，最后是句號，這就是徽標-它是白色的。 因此，如果此徽標出現在白紙上，它將是不可見的。 想法是，徽標，文字通過在彩色背景，圖片，某種動態圖像上顯示而變得可見，并且在徽標公告上顯示的樣本在金魚上顯示，而在標有“巖！” 標志，一種漩渦狀的藍色墨水，各種顏色的涂鴉，我什至無法分辨出最后一個是-看起來就像是人的大腦是由貓做成的。 動用你的想象力。 但是您對這個印象不是很深刻嗎？

Stephan: No. From my understanding, this is actually done by the same company that did the 2012 London Olympics logo.

斯蒂芬：否。據我了解，這實際上是由與2012年倫敦奧運會徽標相同的公司完成的。

Kevin: Oh dear.

凱文：天哪。

Stephan: Which if you haven’t seen that is also a piece of work, if I do say so myself.

史蒂芬：如果我自己說的話，如果您還沒有看到，那也是一件工作。

Kevin: I’m surprised they’re still getting work.

凱文：我很驚訝他們還在上班。

Stephan: If you haven’t seen this, you have to go see it. It’s like bright pink and purple.

史蒂芬：如果您還沒有看到它，那么您必須去看看它。 就像鮮艷的粉紅色和紫色。

Kevin: I have to say I like this a lot better than the 2012 logo.

凱文：我必須說，我比2012年的徽標要好得多。

Stephan: Oh, yeah. This is better. Maybe that’s how they got the work, I don’t know.

斯蒂芬：哦，是的。 這個更好。 我不知道這就是他們的工作方式。

Kevin: There’s a video version that’s nice and again, they’ve just got that white text but it’s being revealed by interesting videos, paint of two different colors splashing together in the center of the screen to reveal the AOL text that was there all along but it was invisible against the white background. The last one is especially funny—it’s some sort of high impact dance move because it’s a guy standing in the middle and his two friends run up to him and step on his chest and his back as they do a flip in the air at the same time. It’s all very exciting.

凱文：有一個很好的視頻版本 ，他們剛得到了白色文本，但是有趣的視頻正在顯示它們，兩種不同顏色的顏料一起濺在屏幕中央，以顯示始終存在的AOL文本。但是在白色背景下是看不見的。 最后一個特別有趣-這是一種高沖擊力的舞步，因為這是一個男人站在中間，他的兩個朋友向他跑來，踩在他的胸部和背部，因為他們同時在空中翻轉時間。 一切都非常令人興奮。

Stephan: I think the video was really cool. What bothers me is the logos that they’ve shown that are still logos. I mean, they’re not logos. What bothers me is they almost look like they’re print—like they should be on like a newspaper because they’re grainy, it doesn’t look refined, it just kind of looks like this threw some crappy fonts…

斯蒂芬：我認為視頻真的很棒。 讓我感到困擾的是他們所顯示的徽標仍然是徽標。 我的意思是，它們不是徽標。 讓我感到困擾的是，它們幾乎看起來像是印刷品–就像它們應該像報紙一樣放在報紙上，因為它們呈顆粒狀，看上去并不精致，只是看起來像是扔了一些笨拙的字體……

Kevin: Stock photos.

凱文：圖片。

Stephan: …yeah, on a stock photo. But the video is, like you said, is cool. It’s neat, it’s kind of modern. I like that.

斯蒂芬：是的，在圖片上。 但是視頻就像您說的那樣很酷。 它很整潔，有點現代。 我喜歡。

Kevin: A subtle thing that’s going on in the photo versions at the very least I like is that the white Aol text is never completely revealed by the picture that’s behind it. There’s always sort of a piece of the letter A or a piece of the letter L that’s sticking out over the edge of the photo and connecting with the white background and so the text sort of feels like it’s pulling air into the photo. Do you see what I mean? It keeps that connection with the wide open white space?

凱文：至少我喜歡在照片版本中發生的一件微妙的事情，就是白色Aol文字永遠不會被背后的圖片完全顯示出來。 總會有一些字母A或字母L伸出照片的邊緣并與白色背景相連，因此文本的感覺就像是在將空氣吸入照片中。 你明白我的意思嗎？ 它與開放的空白區域保持這種聯系嗎？

Stephan: Yeah. It’s like infinite even though it’s connected. Yeah, I see that.

斯蒂芬：是的。 即使已連接，也像無限一樣。 是的，我明白了。

Kevin: I like it. I’ve seen recent re-brandings, the city of Melbourne, the ANZ Bank—the Australian New Zealand bank down here in Australia—we’ve had a couple of high profile new rebrandings happening and both of those are right up there with the 2012 Olympics. They’re pretty horrendous and I will congratulate AOL for their creativity and for creating something interesting here, but no one seems particularly blown away by this.

凱文：我喜歡。 我已經看到了最近的品牌重塑， 墨爾本市 ， 澳新銀行(ANZ Bank) -澳大利亞在這里的澳大利亞新西蘭銀行-我們已經進行了兩次備受矚目的新品牌重塑，而這兩個品牌都在這里2012年奧運會。 他們非常恐怖，我要祝賀AOL的創造力和在這里創造有趣的東西，但是似乎沒有人特別為此感到震驚。

Stephan: There’s not a lot of fondness for it.

斯蒂芬：對此并沒有太多的愛好。

Kevin: Well, what it lacks is a clear visual brand like something that you’re going to recognize at a great distance driving down the freeway as you see it on a billboard. The brand that they’ve created is a non-brand here. It’s something that you’re going to have to squint and discover anew every time you see it.

凱文：好吧，它缺少的是清晰的視覺品牌，就像您在廣告牌上看到沿著高速公路駛向很長一段距離時會認出來的那樣。 他們創建的品牌在這里是非品牌。 每當您看到它時，都必須斜視一下并重新發現。

Stephan: That’s a good way to put it. Yeah, it’s not like a font that you know right off the bat as AOL or it’s not the bold letters like we used to see with the running man, it’s none of that; so you really got to think about if for a second. When I first saw it I was like, “What kind of one-sentence word is that?”

斯蒂芬：那是個好方法。 是的，它不像是您馬上就知道的AOL字體，也不是像我們以前在奔跑的人身上看到的那種粗體字母，僅此而已。 所以你真的要考慮一下。 當我第一次看到它的時候，我會想：“那是一個單句的單詞？”

Kevin: Yeah.

凱文：是的。

Stephan: What kind of one-word sentence is that, sorry.

史蒂芬：抱歉，這是一個單字的句子。

Kevin: Yeah, exactly, AOL.

凱文：是的，美國在線。

Stephan: AOL.

史蒂芬：美國在線。

Kevin: Or it’s not even AOL. It’s Aol.

凱文：或者甚至不是美國在線。 是Aol

“Are iPhone developers stupid?” asks Peter-Paul Koch. In fact, his initial blog post didn’t even ask it. He just came out and said it. “Apple is not evil. IPhone developers are stupid.” And this has to do with something that we haven’t actually mentioned in the podcast before. It’s been on our radar and that’s the furor surrounding the process that an iPhone developer has to go through to get their application approved for sale in the Apple App Store. Without going over every single example because we’d be here all day, there are many examples of developers who’ve put in months of work in some cases on an app, spent thousands if not millions of dollars in development and preparing their marketing push for launch day and then they put this app to Apple and Apple goes, “Nah. Rejected. Rejected because it will confuse users,” and they’re rarely more specific than that.

“ iPhone開發人員愚蠢嗎？” 彼得·保羅·科赫問。 實際上， 他最初的博客文章甚至都沒有問。 他只是出來說。 “蘋果并不邪惡。 iPhone開發人員很愚蠢。” 這與我們之前在播客中實際上沒有提到的東西有關。 這已經成為我們的關注焦點，而這正是iPhone開發人員在Apple App Store中批準其應用程序銷售所必須經過的過程。 因為我們整天待在這里，所以沒有遍歷每個示例，有很多開發人員在某些情況下花了幾個月的時間在應用程序上花費了數千甚至數百萬美元來開發和準備營銷工作的例子在發布當天，然后他們將這個應用程序發布給了蘋果公司，然后蘋果公司說：“不。 拒絕。 被拒絕，因為它會使用戶感到困惑”，而且他們很少比這更具體。

Stephan: Yeah, it’s pretty bad in my opinion. I’m kind of more on the side of Apple choose to open the store and just monitor it for people who are sending out bad apps or apps that are dangerous to the phone rather than choosing which apps get on the store and which apps don’t. I don’t know. It seems like it’s counter-intuitive.

斯蒂芬：是的，我認為這很糟糕。 對于蘋果，我更愿意選擇開設商店并僅對其進行監視，以便那些發送不良應用程序或對手機有害的應用程序的人，而不是選擇哪些應用程序進入商店以及哪些應用程序不在商店中t。 我不知道。 似乎違反直覺。

Kevin: I’m going to make a big bet here because this thing seemed to be coming to a head. We’re at the point in the past week— did you see the Airfoil debacle?

凱文：我要在這里下大賭注，因為這件事似乎即將到來。 過去一周我們處于關鍵時刻–您看到機翼的崩潰了嗎？

Stephan: I did not.

史蒂芬：我沒有。

Kevin: Well, Airfoil is this application for the Mac and for Windows, but mainly Mac users use it and it’s this app that lets you grab the audio from any application on your computer or all the audio for your computer and transmit it either to another computer running their free Airfoil Speakers application, or to an AirPort Express or an Apple TV and these devices have built-in music streaming capabilities so you can send music from iTunes. Well, Airfoil lets you send it from any application to these devices and they have an application Airfoil Speakers for the iPhone and iPod Touch. This app has been on the App Store for almost a year now if not longer and it just lets you receive this stream of audio from any computer running Airfoil. And no problem, you might think, and the 1.0 application has been very successful for them and Apple approved it and kept it in the App Store and then shortly after they found a few bugs so they wanted to release version 1.0.1.

凱文：好吧， Airfoil是適用于Mac和Windows的此應用程序，但主要是Mac用戶使用它，而該應用程序可讓您從計算機上任何應用程序或計算機上所有音頻中獲取音頻，然后將其傳輸到另一個運行其免費Airfoil Speakers應用程序的計算機，或者運行AirPort Express或Apple TV的計算機，這些設備具有內置的音樂流功能，因此您可以從iTunes發送音樂。 好吧，Airfoil允許您將其從任何應用程序發送到這些設備，并且它們具有適用于iPhone和iPod Touch的應用程序Airfoil Speakers。 這個應用程序已經在App Store上使用了將近一年，甚至更長的時間，它只是讓您從任何運行Airfoil的計算機上接收此音頻流。 And no problem, you might think, and the 1.0 application has been very successful for them and Apple approved it and kept it in the App Store and then shortly after they found a few bugs so they wanted to release version 1.0.1.

Well, what happens is with the App Store, you have to submit updates as a new application to be approved and Apple denied that update. Even though it contained some critical fixes to an application that Apple had previously approved and continued to keep in the App Store after they rejected 1.0.1 and the reason they rejected it is because at a glance, Airfoil Speakers contained images of Apple hardware. So if you were receiving audio from an iMac, it would show a picture of an iMac in the Airfoil Speakers application. But what was happening was that they were using Apple’s own APIs to provide these images. The Airfoil application running on the iMac would say, “I need to send a picture of this computer to the receiving end to let them know what this computer looks like.” And so they ask Mac OS X. They say, “Mac OS X, you’ve got a documented way for me to get a picture of the computer I’m running on, can you give me that picture?” And Mac OS X gives it that picture and they send it to Airfoil Speakers and Airfoil Speakers displays it.

Well, what happens is with the App Store, you have to submit updates as a new application to be approved and Apple denied that update. Even though it contained some critical fixes to an application that Apple had previously approved and continued to keep in the App Store after they rejected 1.0.1 and the reason they rejected it is because at a glance, Airfoil Speakers contained images of Apple hardware. So if you were receiving audio from an iMac, it would show a picture of an iMac in the Airfoil Speakers application. But what was happening was that they were using Apple's own APIs to provide these images. The Airfoil application running on the iMac would say, “I need to send a picture of this computer to the receiving end to let them know what this computer looks like.” And so they ask Mac OS X. They say, “Mac OS X, you've got a documented way for me to get a picture of the computer I'm running on, can you give me that picture?” And Mac OS X gives it that picture and they send it to Airfoil Speakers and Airfoil Speakers displays it.

So this is a feature in Apple’s operating system that Apple provides and yet when Airfoil Speakers used it, Apple rejected that application for the fact that they were using images of Apple hardware–even though they had previously approved a version of the application that did the exact thing, that just had more bugs in the application.

So this is a feature in Apple's operating system that Apple provides and yet when Airfoil Speakers used it, Apple rejected that application for the fact that they were using images of Apple hardware–even though they had previously approved a version of the application that did the exact thing, that just had more bugs in the application.

Stephan: Yeah, it’s backwards. That’s backward.

Stephan: Yeah, it's backwards. That's backward.

Kevin: So like I said, we could talk all day telling these stories—and this is a typical one—but things are coming to a head because in response to this, the company behind Airfoil, which is Rogue Amoeba, they posted a big blog post explaining how they finally got their application approved by stripping out all of the images of Apple hardware or stripping out the code that was displaying those images and they got Apple to approve it six months or something after they originally submitted it to Apple. As a result, they are giving up on iPhone development and there have been a few high profile developers who’ve taken this stance that iPhone development is just too hard because Apple’s draconian App Store approval proces—its black box nature—the fact that you can’t predict reliably whether something you’ve written is going to be approved by Apple or not. The rules are vague and their enforcement is inconsistent.

Kevin: So like I said, we could talk all day telling these stories—and this is a typical one—but things are coming to a head because in response to this, the company behind Airfoil, which is Rogue Amoeba, they posted a big blog post explaining how they finally got their application approved by stripping out all of the images of Apple hardware or stripping out the code that was displaying those images and they got Apple to approve it six months or something after they originally submitted it to Apple. As a result, they are giving up on iPhone development and there have been a few high profile developers who've taken this stance that iPhone development is just too hard because Apple's draconian App Store approval proces—its black box nature—the fact that you can't predict reliably whether something you've written is going to be approved by Apple or not. The rules are vague and their enforcement is inconsistent.

So developers with greater and greater profiles have been walking away from the iPhone platform and Apple started doing something about it. Phil Schiller, one of the big muckety-mucks at Apple was speaking to Business Week this week and said that they’re working on these very problems and in fact, Apple turned around and got in touch with Rogue Amoeba as a result of their blog post and said, “Look, you were right, we were wrong, submit yet another version of your app that brings those icons back, those images of Apple hardware back, and we’ll approve it right away.” And they did. They approved it within 24 hours, within one working day.

So developers with greater and greater profiles have been walking away from the iPhone platform and Apple started doing something about it. Phil Schiller, one of the big muckety-mucks at Apple was speaking to Business Week this week and said that they're working on these very problems and in fact, Apple turned around and got in touch with Rogue Amoeba as a result of their blog post and said, “Look, you were right, we were wrong, submit yet another version of your app that brings those icons back, those images of Apple hardware back, and we'll approve it right away.” 他們做到了。 They approved it within 24 hours, within one working day.

So Apple is doing stuff about this but I don’t think their position can hold. The more people that they concede to as a result of angry blog posts, the more angry blog posts they’re going to get and I’m betting that within 12 months Apple is going to have to lift the restriction on iPhone applications that makes it so that applications can only be installed from the iTunes App Store.

So Apple is doing stuff about this but I don't think their position can hold. The more people that they concede to as a result of angry blog posts, the more angry blog posts they're going to get and I'm betting that within 12 months Apple is going to have to lift the restriction on iPhone applications that makes it so that applications can only be installed from the iTunes App Store.

Stephan: You think so?

Stephan: You think so?

Kevin: I think they’ll continue to keep the App Store closed and requiring Apple approval but if you want to distribute your app another way, just put it up on your web site so that people can click on it in mobile Safari and download it and install it. They actually support this now but they really put strong restrictions on it so it can only be used for beta programs by developers. I think there’s a limit on the number of copies of an application that can be distributed this way using ad hoc distribution but I think they’re going to be forced to open that up.

Kevin: I think they'll continue to keep the App Store closed and requiring Apple approval but if you want to distribute your app another way, just put it up on your web site so that people can click on it in mobile Safari and download it and install it. They actually support this now but they really put strong restrictions on it so it can only be used for beta programs by developers. I think there's a limit on the number of copies of an application that can be distributed this way using ad hoc distribution but I think they're going to be forced to open that up.

Stephan: See, I think I disagree because this is a moneymaker for them. I mean, the App Store, they get a percentage of the pie. So I don’t see them wanting to give that up completely.

Stephan: See, I think I disagree because this is a moneymaker for them. I mean, the App Store, they get a percentage of the pie. So I don't see them wanting to give that up completely.

Kevin: But I think the App Store will continue to be the most convenient way for a developer to make money off of their iPhone app. I think if they want to sell it and they don’t want to go through all of the pain of setting up an ecommerce web site to buy it and trying to get people to come and discover their app… Developers will continue to submit stuff to the App Store because it’s the easiest way to make money on the iPhone platform.

Kevin: But I think the App Store will continue to be the most convenient way for a developer to make money off of their iPhone app. I think if they want to sell it and they don't want to go through all of the pain of setting up an ecommerce web site to buy it and trying to get people to come and discover their app… Developers will continue to submit stuff to the App Store because it's the easiest way to make money on the iPhone platform.

Stephan: Yeah.

斯蒂芬：是的。

Kevin: But if you want to do something that Apple isn’t quite happy with or won’t approve for one reason or the other, I think they will provide that alternative and so Apple will then be justified in saying, “Look, it’s our store, we can put what we want in it and what we don’t want in it and if you’re not happy with our policies, start your own store.”

Kevin: But if you want to do something that Apple isn't quite happy with or won't approve for one reason or the other, I think they will provide that alternative and so Apple will then be justified in saying, “Look, it's our store, we can put what we want in it and what we don't want in it and if you're not happy with our policies, start your own store.”

Stephan: I guess the Apple Store could become an exclusive place for your apps. It could become the target of apps.

Stephan: I guess the Apple Store could become an exclusive place for your apps. It could become the target of apps.

Kevin: It’s the boutique. And finally, Apple could throw away all the fart applications and all the gross-out apps that I think everyone agrees are in poor taste but because there’s no rule-breaking going on in these applications, that Apple can’t deny them.

Kevin: It's the boutique. And finally, Apple could throw away all the fart applications and all the gross-out apps that I think everyone agrees are in poor taste but because there's no rule-breaking going on in these applications, that Apple can't deny them.

Stephan: Yeah. Well, I did see a Cha-Ching app that got rejected because it was too simple. You just hit the button and “Cha-Ching!” That’s all it did and it was rejected. There was a guy who made a video about it.

斯蒂芬：是的。 Well, I did see a Cha-Ching app that got rejected because it was too simple. You just hit the button and “Cha-Ching!” That's all it did and it was rejected. There was a guy who made a video about it.

Kevin: Too simple.

Kevin: Too simple.

Stephan: I’ve never heard that before.

Stephan: I've never heard that before.

Kevin: Wow. During the elections, there were apps that all they did was display the logo of the political party that you supported.

凱文：哇。 During the elections, there were apps that all they did was display the logo of the political party that you supported.

Stephan: Yeah.

斯蒂芬：是的。

Kevin: It was like the image application. That’s all they did is display an image when you started them up.

Kevin: It was like the image application. That's all they did is display an image when you started them up.

Stephan: I think it’s because they don’t have internal standards. I think that they give people some vague rules and these people just interpret them however they want and that’s why you get this disparity. But this article…

Stephan: I think it's because they don't have internal standards. I think that they give people some vague rules and these people just interpret them however they want and that's why you get this disparity. But this article…

Kevin: Anyway…

Kevin: Anyway…

Stephan: Oh sorry. We’ve gone off topic.

Stephan: Oh sorry. We've gone off topic.

Kevin: Way off topic.

Kevin: Way off topic.

Stephan: The article that talks about that the iPhone developers are stupid because they should be taking advantage of the web side of the iPhone and the Safari browser and WebKit and all that, and saying that you should use that instead of it—and you don’t have to worry about the App Store at all. And he actually comes back and he wrote another post, I guess, a follow-up to this kind of saying that he was wrong, whatever, but…

Stephan: The article that talks about that the iPhone developers are stupid because they should be taking advantage of the web side of the iPhone and the Safari browser and WebKit and all that, and saying that you should use that instead of it—and you don't have to worry about the App Store at all. And he actually comes back and he wrote another post , I guess, a follow-up to this kind of saying that he was wrong, whatever, but…

Kevin: So yeah, he said if iPhone developers aren’t happy with the App Store (and why would you be), you should just build the web app because web apps can be icons on the iPhone home screen just like native applications can but they’re not subject to any rules or restrictions whatsoever. If you can build a web site, you can build an application for the iPhone and Apple can’t do anything about it. And that was his initial point—IPhone developers are stupid, they are drinking the Kool-Aid. Apple tells them to build native apps and so they build native apps. Dion Almaer of Palm, previously Mozilla and Faruk Ate?, they both wrote strongly-worded posts saying that, “Yeah, you’re not quite right there, PPK”—Peter-Paul Koch was the author of the original article—the reason people build native apps for their iPhone is that web apps aren’t quite there yet. They don’t provide full access to the hardware features that you get on the phone and they don’t provide the same level of user experience—the sleekness of the experience, the integration in the iPhone platform—all those things aren’t quite as polished in a web apps for the iPhone and the reason someone buys an iPhone is because of the polish. And so if you want to stand out on the iPhone platform, you do it with a native app.

Kevin: So yeah, he said if iPhone developers aren't happy with the App Store (and why would you be), you should just build the web app because web apps can be icons on the iPhone home screen just like native applications can but they're not subject to any rules or restrictions whatsoever. If you can build a web site, you can build an application for the iPhone and Apple can't do anything about it. And that was his initial point—IPhone developers are stupid, they are drinking the Kool-Aid. Apple tells them to build native apps and so they build native apps. Dion Almaer of Palm, previously Mozilla and Faruk Ate? , they both wrote strongly-worded posts saying that, “Yeah, you're not quite right there, PPK”—Peter-Paul Koch was the author of the original article—the reason people build native apps for their iPhone is that web apps aren't quite there yet. They don't provide full access to the hardware features that you get on the phone and they don't provide the same level of user experience—the sleekness of the experience, the integration in the iPhone platform—all those things aren't quite as polished in a web apps for the iPhone and the reason someone buys an iPhone is because of the polish. And so if you want to stand out on the iPhone platform, you do it with a native app.

Stephan: I have to say this. I’ve used the Flickr application on the iPhone and I’ve also used the web site, and the web site’s darn good. I mean the web site is cool. I mean it’s got location awareness and everything—like it can find photos that are around me.

Stephan: I have to say this. I've used the Flickr application on the iPhone and I've also used the web site, and the web site's darn good. I mean the web site is cool. I mean it's got location awareness and everything—like it can find photos that are around me.

Kevin: They did a beautiful job with that web application I have to say.

Kevin: They did a beautiful job with that web application I have to say.

Stephan: Oh, they did. They did. And the app though itself—I think is terrible. It’s slow. It takes forever to load a picture. It takes forever to take a picture. It’s not smooth like what I was expecting it. I use the web app almost exclusively and never use the actual iPhone application.

Stephan: Oh, they did. 他們做到了。 And the app though itself—I think is terrible. It's slow. It takes forever to load a picture. It takes forever to take a picture. It's not smooth like what I was expecting it. I use the web app almost exclusively and never use the actual iPhone application.

Kevin: And it seems like because the application came so late, it seems like Flickr were planning on everyone just using their web app.

Kevin: And it seems like because the application came so late, it seems like Flickr were planning on everyone just using their web app.

Stephan: Yeah.

斯蒂芬：是的。

Kevin: And that’s why it’s so good. And the reason the web app wasn’t quite enough is because it doesn’t provide that integration. You couldn’t— Using a web app, you can’t pick photos from your camera roll on your iPhone and upload them to Flickr—and they needed an application to do that. It looks like they did the minimum necessary to provide that picture but I think you’re right. The right way to view photos on Flickr on your iPhone is to use their mobile app.

Kevin: And that's why it's so good. And the reason the web app wasn't quite enough is because it doesn't provide that integration. You couldn't— Using a web app, you can't pick photos from your camera roll on your iPhone and upload them to Flickr—and they needed an application to do that. It looks like they did the minimum necessary to provide that picture but I think you're right. The right way to view photos on Flickr on your iPhone is to use their mobile app.

Kevin: Facebook did something similar. Facebook’s mobile web site for a long time was a shiny example of a mobile web application looking like a native iPhone app, and in fact, the people behind it released their user interface framework so that other people could do the same sort of tricks. But eventually Facebook built their own native application just because they were able to provide an even sleeker, richer experience.

Kevin: Facebook did something similar. Facebook's mobile web site for a long time was a shiny example of a mobile web application looking like a native iPhone app, and in fact, the people behind it released their user interface framework so that other people could do the same sort of tricks. But eventually Facebook built their own native application just because they were able to provide an even sleeker, richer experience.

Stephan: My opinion on this is that people who build them are just trying to build a simple application to do some data entry or something for a web site that they have—it makes sense to just do a mobile iPhone version, not an app. But I think there’s some applications out there that deserves the application treatment. I’m a plane nerd for those listeners who don’t know. I’m a huge airplane nerd and I downloaded the LiveATC.net app so I could listen to air traffic control near my home airport; and it’s an amazing app. I mean the thing just streams over 3G air traffic control—and I can’t imagine them trying to do that through the mobile API. Just can’t.

Stephan: My opinion on this is that people who build them are just trying to build a simple application to do some data entry or something for a web site that they have—it makes sense to just do a mobile iPhone version, not an app. But I think there's some applications out there that deserves the application treatment. I'm a plane nerd for those listeners who don't know. I'm a huge airplane nerd and I downloaded the LiveATC.net app so I could listen to air traffic control near my home airport; and it's an amazing app. I mean the thing just streams over 3G air traffic control—and I can't imagine them trying to do that through the mobile API. Just can't.

Kevin: So PPK’s follow-up blog posts in response to the criticism he got, he’s basically saying, “I was wrong and yet there are things in my original post that I still think are worthwhile saying,” and this follow-up post I think is a must-read. It really is quite insightful. He’s calmed down and found the nugget of truth that got him angry enough to write the rant that was mostly nonsense. Sorry, PPK.

Kevin: So PPK's follow-up blog posts in response to the criticism he got, he's basically saying, “I was wrong and yet there are things in my original post that I still think are worthwhile saying,” and this follow-up post I think is a must-read. It really is quite insightful. He's calmed down and found the nugget of truth that got him angry enough to write the rant that was mostly nonsense. Sorry, PPK.

The follow-up post says, first of all, one of the really good reasons for building a native app for the App Store is it’s much easier to make money off of a native app than off of a web application. If you want to sell access to your web application that is custom designed for the iPhone, yeah, it’s going to be much easier to get it on to the device because you don’t have to have it approved by Apple, but getting people to find it, providing a convenient way for people to pay for it—compared to the App Store—there’s no competition there. On the iPhone, you click a link on a web page that points to the App Store, it says, “Do you want to install this? It will cost $0.99.” You say “Yes”, you have spent $0.99 and you’re done. The developer gets 70% of that. Doing that with other web application, you’re going to be dealing with PayPal at the simplest and providing that slick experience to install it, and then explaining to them how to get an icon on their home screen from within mobile Safari is a nightmare. So, making money: much easier using the App Store. Then there are all the issues with a device APIs, which is why Flickr ended up writing their own native app because if you want to hook in to certain features of the iPhone, you can’t do that with web apps yet. He says, “Look, that’s going to be solved. If Apple is not working on improving device integration with web apps, they’re fools,” and so he’s willing to bet on that becoming better in time, but right now he concedes it’s not quite there yet and so native apps have the edge.

The follow-up post says, first of all, one of the really good reasons for building a native app for the App Store is it's much easier to make money off of a native app than off of a web application. If you want to sell access to your web application that is custom designed for the iPhone, yeah, it's going to be much easier to get it on to the device because you don't have to have it approved by Apple, but getting people to find it, providing a convenient way for people to pay for it—compared to the App Store—there's no competition there. On the iPhone, you click a link on a web page that points to the App Store, it says, “Do you want to install this? It will cost $0.99.” You say “Yes”, you have spent $0.99 and you're done. The developer gets 70% of that. Doing that with other web application, you're going to be dealing with PayPal at the simplest and providing that slick experience to install it, and then explaining to them how to get an icon on their home screen from within mobile Safari is a nightmare. So, making money: much easier using the App Store. Then there are all the issues with a device APIs, which is why Flickr ended up writing their own native app because if you want to hook in to certain features of the iPhone, you can't do that with web apps yet. He says, “Look, that's going to be solved. If Apple is not working on improving device integration with web apps, they're fools,” and so he's willing to bet on that becoming better in time, but right now he concedes it's not quite there yet and so native apps have the edge.

Interoperability versus user experience is the big one. If your application calls for polish above all else—if your business goals require you to provide the most polished experience possible on a single device, the iPhone—then native apps are the way to go. However, if interoperability is an important thing on your radar, if being able to build an application that will work with little or no modification across lots of different devices—not just the iPhone—and you’re willing to sacrifice a tiny bit of user experience polish to get that interoperability—quadruple your market in exchange for slightly jerkier animations, for example. If that’s a reasonable trade off, then you should be building web apps and sacrificing the user experience polish that you get with the native APIs on the iPhone.

Interoperability versus user experience is the big one. If your application calls for polish above all else—if your business goals require you to provide the most polished experience possible on a single device, the iPhone—then native apps are the way to go. However, if interoperability is an important thing on your radar, if being able to build an application that will work with little or no modification across lots of different devices—not just the iPhone—and you're willing to sacrifice a tiny bit of user experience polish to get that interoperability—quadruple your market in exchange for slightly jerkier animations, for example. If that's a reasonable trade off, then you should be building web apps and sacrificing the user experience polish that you get with the native APIs on the iPhone.

He closes with a discussion of the fact that it’s interesting that the market leaders in the mobile application space, which are Apple and Google—Apple with iPhone, Google with their Android platform—have bet on native apps or at least a custom software development kit with new languages and new frameworks to build applications specifically for their devices. Whereas the market trailers—the Palms, the Microsofts—they’re all betting on open web technologies, whether it’s actually building web sites that display as applications on the phone or in the case of Android, they just built an SDK that requires web developers to use their existing skills to build native apps for the phone. The market trailers are betting on web standards. And it’s clear: whenever you’re behind you bet on openness, you work together because that openness lets you team up against the market leaders and yet they’re not doing a very good job of developer outreach. They’re betting on these technologies that thrive on the web developer community and then they’re not engaging with that community or at least they haven’t been very good at it so far. So he expresses his frustration there. Great article I think. Really insightful on many fronts and I’m glad he backed down from his extreme initial position in order to give us those insights.

He closes with a discussion of the fact that it's interesting that the market leaders in the mobile application space, which are Apple and Google—Apple with iPhone, Google with their Android platform—have bet on native apps or at least a custom software development kit with new languages and new frameworks to build applications specifically for their devices. Whereas the market trailers—the Palms, the Microsofts—they're all betting on open web technologies, whether it's actually building web sites that display as applications on the phone or in the case of Android, they just built an SDK that requires web developers to use their existing skills to build native apps for the phone. The market trailers are betting on web standards. And it's clear: whenever you're behind you bet on openness, you work together because that openness lets you team up against the market leaders and yet they're not doing a very good job of developer outreach. They're betting on these technologies that thrive on the web developer community and then they're not engaging with that community or at least they haven't been very good at it so far. So he expresses his frustration there. Great article I think. Really insightful on many fronts and I'm glad he backed down from his extreme initial position in order to give us those insights.

Let’s close off the show with just a couple of host spotlights this week.

Let's close off the show with just a couple of host spotlights this week.

Stephan: Yeah. So I’ll go first. I’m a big data visualization fan. I love charts–they just fire me up.

斯蒂芬：是的。 So I'll go first. I'm a big data visualization fan. I love charts–they just fire me up.

Kevin: I love them too. The info graphics that you get in newspapers are really, I geek out on those when they’re well-done.

Kevin: I love them too. The info graphics that you get in newspapers are really, I geek out on those when they're well-done.

Stephan: Yeah. So I found this web site, it’s on Tumblr. It’s ilovecharts.tumblr.com. They’ve got a bunch of charts of mixed things. Some of them funny, some of them really cool where we are debt-wise, things like that—just random charts. Some of them may be inappropriate, I don’t know but there’s some really good ones—things from the Washington Post, they’ve collected all of them and put them in one place. So it’s a neat little read, ilovecharts.tumblr.com.

斯蒂芬：是的。 So I found this web site, it's on Tumblr. It's ilovecharts.tumblr.com . They've got a bunch of charts of mixed things. Some of them funny, some of them really cool where we are debt-wise, things like that—just random charts. Some of them may be inappropriate, I don't know but there's some really good ones—things from the Washington Post, they've collected all of them and put them in one place. So it's a neat little read, ilovecharts.tumblr.com.

Kevin: Yeah. I’m just scrolling through here, sorry. I’ve got distracted already. My host spotlight is a site called Support Details and you can find it at supportdetails.com. The tagline on the site is “tech support anger management” and it’s when someone tells you your site isn’t displaying right in their browser and then you inevitably get into that email back and forth where you’re like, “Well, what browser are you using?” “Oh, I’m using Internet Explorer.” “Well, which version of Internet Explorer?” “Oh, IE 8 I think.” “Okay, what version of Windows are you on? What is your screen resolution? Is your browser window maximized or not?” And next thing you know you’ve sent six emails back and forth and then you realize it’s because they have JavaScript disabled in their browser. This site saves you all of that time because if someone tells you they’re having a problem with their site, you just say, “Okay, go to SupportDetails.com, fill in your name, your email address, and my email address, and click ‘send details’ and you get an email with their operating system, their screen resolution, the web browser and version they’re using, the size of their browser window, their IP address, their color depth, whether JavaScript is enabled, whether cookies are enabled, and the version of Flash that they’re using. And this will save so much time! I’m really happy I keep a link to this on my desktop because…

凱文：是的。 I'm just scrolling through here, sorry. I've got distracted already. My host spotlight is a site called Support Details and you can find it at supportdetails.com . The tagline on the site is “tech support anger management” and it's when someone tells you your site isn't displaying right in their browser and then you inevitably get into that email back and forth where you're like, “Well, what browser are you using?” “Oh, I'm using Internet Explorer.” “Well, which version of Internet Explorer?” “Oh, IE 8 I think.” “Okay, what version of Windows are you on? What is your screen resolution? Is your browser window maximized or not?” And next thing you know you've sent six emails back and forth and then you realize it's because they have JavaScript disabled in their browser. This site saves you all of that time because if someone tells you they're having a problem with their site, you just say, “Okay, go to SupportDetails.com, fill in your name, your email address, and my email address, and click 'send details' and you get an email with their operating system, their screen resolution, the web browser and version they're using, the size of their browser window, their IP address, their color depth, whether JavaScript is enabled, whether cookies are enabled, and the version of Flash that they're using. And this will save so much time! I'm really happy I keep a link to this on my desktop because…

Stephan: Sounds useful to me.

Stephan: Sounds useful to me.

Kevin: Great site. If you are ever responsible for trying to figure out why your site isn’t displaying quite right in one obscure browser configuration on the other side of the planet, use supportdetails.com. It’s free and it’s very nicely designed too.

Kevin: Great site. If you are ever responsible for trying to figure out why your site isn't displaying quite right in one obscure browser configuration on the other side of the planet, use supportdetails.com . It's free and it's very nicely designed too.

Our signoffs also will be short this week. Stephan?

Our signoffs also will be short this week. 斯蒂芬？

Stephan: Yep. My name is Stephan Segraves, you can find me on badice.com and my Twitter is @ssegraves.

斯蒂芬：是的 。 My name is Stephan Segraves, you can find me on badice.com and my Twitter is @ssegraves .

Kevin: You can follow me on Twitter @sentience and SitePoint @sitepointdotcom on Twitter. Visit us at https://www.sitepoint.com/podcast for all the new shows and to subscribe using iTunes or whatever podcast listening software you have to get every show automatically.

Kevin: You can follow me on Twitter @sentience and SitePoint @sitepointdotcom on Twitter. Visit us at https://www.sitepoint.com/podcast for all the new shows and to subscribe using iTunes or whatever podcast listening software you have to get every show automatically.

This episode of the SitePoint podcast is produced by Carl Longnecker and I’m Kevin Yank. Thanks for listening. Bye-bye.

This episode of the SitePoint podcast is produced by Carl Longnecker and I'm Kevin Yank. 謝謝收聽。 再見。

Theme music by Mike Mella.

Mike Mella的主題音樂。

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

謝謝收聽！ 歡迎使用下面的評論字段讓我們知道我們的狀況，或者繼續討論。

翻譯自: https://www.sitepoint.com/podcast-38-a-brain-of-cats/

總結

以上是生活随笔為你收集整理的SitePoint播客＃38：猫的大脑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。