Having related emails batched and then providing easy ways to pin, snooze or mark done is so useful. Clicking the "sweep" button (Mark All As Read) after prioritizing the email you care about is such a satisfying feeling. I'm not quite at inbox zero yet, but definitely feel like it is now actually possible with a bit more work on my end.
Hi everyone, Chris, the founder of imgix here. We are just beginning to talk about what we are going to be rolling out over the next few months, so I wrote this piece about how and why we are moving in the directions we are moving, with a focus on explaining things from the developer perspective. There will be plenty more to follow so stay tuned. For the moment, I am happy to fill in any details that I can.
Keynote is actually a surprisingly good tool for building diagrams once you learn the interface and features. I use it for all of our architecture diagrams and for generating printable posters of such to hang in our office. I have tried nearly everything else, but unless you need semantics native to your diagram, Keynote is (oddly, I know) the best I have found.
You should check out the Whitebox Software Defined Radio Project. It is a hacker friendly software defined radio started by my friend Chris, a former lead engineer from Google/YouTube and the former VP of technology at Adly. http://radio.testa.co
We would be happy to help at imgix. We currently process tens of millions of images per day, including large images like yours. Feel free to contact me at chris (at) imgix (dot) com. Link: http://www.imgix.com
We used the existing image requests as a baseline. So the numbers we are reporting are specifically for the images that are being served in established formats (e.g. PNG and JPEG) measured against their equivalent requested WebP and JPEG XR variants. We then measured the percentiles of savings for these images. 98% of images in our test customer base saw a 18-74% improvement in compression per image, with an average of 41% savings per image. The data itself is a deduplicated set of hundreds of millions of image requests across several test customers. The one piece of data we should also report is the aggregate total savings per customer across all of their image requests. I will look into calculating that data point.
We deliver images out of a CDN where we already have handled the proper request normalization. There is no support cost to implementing content negotiation in this case unless you want to put us behind a proxy. At that point, we can work with you to vary correctly without incurring the complexity you are focusing on.
Founder of imgix here. The comparison image is just meant to be moderately informative. We will be following up with a detailed performance outline as more data comes in. You can compare the progressive JPEG image against the WebP or JPEG XR to get a sample of what the ratios might be for a standard JPEG. Besides, a surprising number of websites still serve wildly uncompressed and unoptimized imagery. We help websites that are serving uncompressed JPEG and PNGs all of the time.
Furthermore, what should be understood (and I will clarify in the post) is that apart from the example image, which is designed to show the comparative compression ratios of the file formats, the data we report is based on the images that these companies are ALREADY serving. We analyzed our logs for what the image size is that they are currently serving as JPEGs and PNGS at the same size and simply enabled content negotiation for those same sized images.
With regards to the Vary header. You are right that the cache fragmentation of varying by Accept or User Agent would be extreme. This is why we do not do this. Instead, we perform normalization on the request and generate a specific "content ID" that takes into account any number of input signals that should be normalized and varied on. We can expose this as a separate header to folks who want to Vary on if folks want it. Finally, if you are serving directly out of us, none of this really matters. There is no web server involved. We handle all of the hard work on our end.
I disagree that content negotiation is the wrong approach though. The fragmentation we see across all of the input signals (e.g. format support, device pixel ratio, user agent, etc) is already so extreme that the best answer is to serve dynamic responses for images. If you want to stay within in the browser prefetch stage, which is critical for front-end performance, you have to make decisions about the content you want to serve at the server. This means potentially serving variant content under a single URL. We serve targeted responses for text content all the time across the web. It is not clear from your argument as to why this same treatment should not apply to imagery.
Having OS X in our stack allows us to tackle a lot of use cases that come out of the prototypical design process. Format support, color profiles, color space conversion, typography, etc. are all mastered in OS X, but lacking in other operating systems. Apple has had the best imaging scientists in the world working for the last 30 years on getting these features right. We want to be able to leverage that expertise, whenever it makes sense, to produce the highest quality image. In this case, the consequence of that decision means racking Macs.
Agreed. They should definitely lock it down for their internal use (and eventually provide a public API). I would imagine that in a young company that is moving fast, there is a high potential to overreact or to appear to because of canned responses.
I highly doubt this has anything to do with stifling innovation. Given Snapchat's popularity, it would make a lot more sense that they are trying to restrict 3rd party access to cut down on spam. Nothing will be more destructive to their service than bots churning out huge amounts of spam, undermining the trust they have built with their users.
Snapchat was likely trying to value itself in comparative terms to Instagram. Instagram was a threat because it had both the meteorically rising product AND the engineering team capable of scaling ahead of that growth. I think Facebook created Poke not to compete directly, but as a response to the comparison to Instagram. Facebook "coded Snapchat in a weekend", literally.
We cache aggressively, at multiple levels, and manage the dependencies between caches. In the overwhelming amount of cases, we are serving straight out of SSD caches. The on-the-fly work only happens if the image does not already exist.
You are not wrong. And we were very well aware of this. However, we found the reality of the problem being solved is much more about network latency, routing, and caching than actual graphics processing throughput. Our pain points have been very different than what you are prescribing as a better course of action.
They do a fair enough job for what we needed. Really, it was more about what we could get quickly, with a certain expectation of consistency, just to get us moving forward.
Actually, to be fair, I did not mean to imply that anyone was "bragging". People may have been celebratory, and justifiably so, but I never felt anyone in particular was bragging.
I really like only using AJAX for content that is conditional. For instance, a comment form that opens up only when a user clicks on it. If they never go to add a comment, the AJAX request is never made. Anything that is actually going to be displayed immediately on the page should be loaded as soon as possible as there are major performance gains in letting the preprocessors do their work properly.
I'll rework the wording. Also, it wasn't that the videos were necessarily taking 20 minutes to load. That was simply projections based on the numbers we were seeing at the time. There was not enough data of people actually waiting for 20 minutes to watch something, at least in the small subset of data we pulled at the time.
I went through YC as a solo, first-time founder and I would not recommend it to anyone. Despite working the hardest I have ever worked in my life, I barely made it through Demo Day, and my Demo Day presentation was not exactly riveting. Furthermore, after Demo Day, you still have to continue building the business.
Solo, first-time founders will undoubtedly lack the emotional support systems necessary to give them even a baseline sense of sanity and the mental clarity to persevere. They are far more likely to make stupid and irrational decisions. It was not until I found a cofounder, long after YC, that our company began to behave even remotely like a normal company.
Having a cofounder to share the load with has unforeseen compounding value that one does not have the awareness of to offset in their first company. Maybe in a second or third company you can pull it off by planning around the repercussions of being a solo founder. Unfortunately, without previous experience, you will have no idea how to do that.
We actually talked to some Safari engineers about this and the response was that image-sets were the way forward. I am not sure I agree. The key argument was that the accepts header puts the burden entirely on the server and does not account for multi-resolution environments, such as multiple monitor setups. Content moving from one device/monitor to another could make use of image-sets to load in the appropriate image for its display.
The device pixel ratio is simply the conversion ratio between device pixels and css pixels. It is on the device makers to determine how to interpolate image data into CSS pixels in the browser. There are many devices that have non-integer based DPRs. From what I recall, earlier devices even have DPRs of 0.75
I loved Tim's (approximate) celebration quote: "I don't want to say this is the end of the game publishing as we know it...... I'm sure a few games will still need publishers." Classic.
As someone who was rejected by Google the first time, and hired the second time through, I went through a similar range of emotions during that first rejection. (I did not have an Ivy league education and only had a 3.2 GPA)
It was only after I was later hired into Google that I learned from my original recruiter that I had actually done quite well in my first interview process. What I did not know at the time of my rejection letter was that they had narrowed down their pool of potential applicants to about 1200 resumes for three open positions they were looking to fill. Apparently, I made it into the last round of 10-12 applicants and just did not have the experience level with the specific tools for the job as others did. Thus, I received the same rejection letter the other 1196 people received, and never even knew I did as well as I did.
My advice would be to just stay in contact and keep Google updated anytime you have something new added to your resume or skill set. Based on what you have described, it actually sounds like you might have done pretty well. There are too many factors going on behind the scenes to say one way or another why you did not make it through this time.
Entrepreneur logic and VC logic are very different, so try to see it from their side. First off, not all of the VCs will get in on Pinwheel, and may be looking for something similar to invest in. Secondly, competition in a space simply validates the space and the companies in it.
Is there any historical evidence that a meteoric rise in traffic, of this magnitude, has translated into a long term success? I am not making any prediction on Google+'s future; I am just interested if there are examples that I am not able to recall.
Facebook, Twitter, and Foursquare had to earn their traffic along the way. The evolutionary process of going from 100K users to 750M users must be an important component in their success.
If these statistics for Google+ are correct, they seem to be leap-frogging the entire process that happens when growing your user base from nothing to something. I cannot decide if this is a benefit or a detriment to the eventual success of the product. I would love to hear examples or counter-examples of this.
I've often wondered this myself when designing login forms, but doesn't identifying which field failed expose a security issue? A malicious user could use the feedback to determine if accounts exist or not. This seems like a concern to me.
These ads seem to have been engineered from the start to stir up controversy, which in turn will generate more mentions of Groupon in the news cycle and on the web. While I can appreciate the perspective that any press is good press, marginalizing these very real issues in the world to hock your product is just wrong and soulless. They could have easily invented hilarious fictitious issues and achieved a far less offensive message.