Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expected arrival times for Apple products

arrival.io

Post reply on HN
Print view View original

81–90 of 123 posts

Re: Expected arrival times for Apple products

#81

Post by ward »

anti-pattern wrote: post #27
signed0 wrote: post #13

The text is cut off on http://arrival.io/macbook-pro . http://imgur.com/sBWlJ09

Hmm, what OS, browser, and version are you on?

Most likely has to do with not having the font you are expecting (Myriad Pro), as well as different defaults in size in browsers. My sans-serif font that you are falling back to is Droid Sans at 15 font size. The fixed width of the svg you are working with is making the whole area you are trying to fit things in to be too small.

In short: Lack of responsive web design

Re: Expected arrival times for Apple products

#82

Post by ward »

anti-pattern wrote: post #77
Domenic_S wrote: post #19

Firefox 19/mac, progress bars don't display.

Yeah, for some reason Firefox won't show the gradient. Not sure why. In the meantime I made it so it would fallback to a solid color.

jgraham explains it in this comment http://news.ycombinator.com/item?id=5307583

Re: Expected arrival times for Apple products

#83

Post by anti-pattern »

jgraham wrote: post #59
whatshisface wrote: post #43

Earlier quoted context omitted.

"This page is best viewed with Google Explorer" It looks like the page is doing something funny with javascript to render the bars, why not just use good old css?

The problem is that the site is using SVG paint servers to provide a gradient for the progress rect. The gradient is specified in a SVG def element with id barGradient in the HTML file. So far so good. The problem arises because the fill rule is written as "fill: url(#barGradient)" and is placed in an external CSS file. In this case the fragment should be resolved against the stylesheet URL, not the HTML document URL…

Ah, that makes sense. Thanks for explaining it! This was my first time using SVG. So, what is the best solution? Defining SVG styles in a style tag?

Re: Expected arrival times for Apple products

#84

Post by wmf »

rdl wrote: post #71

What I would find useful is seeing the things blocking each update. E.g. Mac Pro waiting on new Xeon CPUs from Intel, new iPad basically not enough time since last release, EOL for iPod classic, etc.

Maybe "days between processor release and Mac release" would be a useful metric, considering that Intel leaks/announces their release dates months in advance.

Re: Expected arrival times for Apple products

#85

Post by tobyjsullivan »

ricardobeat wrote: post #16

Is this just scraping http://buyersguide.macrumors.com/ ?

If any scraping was involved in the production of this site, it was viciously over-engineered. These are static values that only need to be updated manually once after each Apple announcement...

Edit: And before anyone says that everything should be automated, keep in mind that scrapers will break far more often than you'll ever have to update these numbers.

Re: Expected arrival times for Apple products

#86

Post by tolmasky »

nwh wrote: post #20
simonsarris wrote: post #15

This is a great idea, and is especially pertinent to Mac fans who care about the hardware they are using. Since Apple does not discount old hardware (even with 2-3 year old video cards, they charge the same amount as a brand new updated mac the very next week[1]), people buying a Macbook pro at the wrong end of the timeline can get totally shafted on equipment, especially from a price-per-performance view. That feels…

If you want truly awful bang-for-buck, try the Mac Pro, it's hilariously overpriced for such an old machine. The CPU had to be swapped out because Intel stopped making the original ones.

On gazelle my Mac Pro (which is basically identical to the top of the line one you can buy now), gets you about ~$550. In other words, no one should be buying this thing new.

Re: Expected arrival times for Apple products

#87

Post by ZoFreX »

anti-pattern wrote: post #68
badgar wrote: post #56

Earlier quoted context omitted.

Might I ask why you built your own, knowing there was an almost identical offering in place for years? For example, did your different choice of releases cause a statistically significant shift in arrival times? I imagine you've done analysis comparing your approach to theirs.

I built my own because their design, and I mean literally the way they visualize the data, isn't very good. Or rather, it's not as good as it could be. They even updated the design a year or two ago and all they did was give it a coat of paint, rather than rethinking how to best visualize the data.

> I built my own because their design, and I mean literally the way they visualize the data, isn't very good. Or rather, it's not as good as it could be.

I love your approach :) it's very helpful!

Re: Expected arrival times for Apple products

#88

Post by anti-pattern »

tobyjsullivan wrote: post #85
ricardobeat wrote: post #16

Is this just scraping http://buyersguide.macrumors.com/ ?

If any scraping was involved in the production of this site, it was viciously over-engineered. These are static values that only need to be updated manually once after each Apple announcement... Edit: And before anyone says that everything should be automated, keep in mind that scrapers will break far more often than you'll ever have to update these numbers.

They probably meant whether or not I "took" the information from somewhere else. But yeah, actually scraping the information would have been ridiculous. It's all just in a static YAML file.
Post reply on HN