> disintegration of innately self-evident core values like "working hard to make a good thing good is good"
Working hard is necessary to make something good, of course. Working "hardcore", where 100-hour weeks are _required_, and only "exceptional" performance is acceptable, is _inhuman_.
I'm saying this as someone who's managed several teams over several years, but also someone who's read the literature: the surest way to get bad performance out of someone is to put that kind of pressure on them, _especially_ long-term. People in that situation get tired and/or sick, can't straight from the anxiety and pressure, and because of all of that that they'll make simple mistakes that take a long time to sort out (because everybody else is in the same situation).
In my experience the best work comes from people who are calm, healthy, and well-rested, _especially_ over the long term. Those well-rested people are the ones who are capable of putting in the discretionary effort to make something good.
> Working "hardcore", where 100-hour weeks are _required_, and only "exceptional" performance is acceptable, is _inhuman_.
this is something you and everyone else read into the email that was simply not written there. out of curiosity, what drives you to take "hardcore" and "this will mean working long hours" just about as exaggeratedly, hyperbolically uncharitably possible? I can't find a valid logical reason for doing this, yet everyone seems to be doing it, and I can't figure it out.
This is literally what Musk did first thing when he stepped into Twitter premises. He told teams to ship a feature in a short timespan or be fired, which required them to work over the weekends and sleep at their desk.
Wattpad is a mobile social app that connects people all over the world with stories that matter to them. It enhances the storytelling experience, and makes it possible for people to be captivated by something they love. We’re proudly based in Toronto, but our reach is global. Every day, millions of people use Wattpad to create and discover stories they can’t find anywhere else.
The Wattpad platform serves over 2 billion requests a day, with millions of users worldwide.
We're hiring for several positions, including our front end web and platform teams.
Our web client is a single-page Javascript app, primarily using Backbone, served by an Express NodeJS server.
Pluto in particular would be a problem, though, because it is a) very small, and b) very far away. In order to get there in a realistic time, your probe has to be going _very quickly_; in order to stay in Pluto orbit, the probe has to be going _very slowly_.
So, unfortunately, to stay in Pluto orbit, either you carry a lot of fuel with you to slow down (which makes launch incredibly difficult, because you need more fuel to accelerate the fuel you need to slow down, and then you need more fuel to accelerate _that_ fuel, and so on), or you wait a long time to get there.
The bigger, closer planets and planetoids, though, will see a lot more exploration as the cost of launch decreases.
Generally the gravity assists act on other planets on the way to the destination. For example, Cassini got assists off of Venus twice, then Earth, then Jupiter on its way to Saturn.
Note: I'm no astrophysicist, and this is just back of the napkin math
Uranus is the physically closest planet to Pluto at the minimum distance of 11AU (about 1,64 billion km). Pluto's escape velocity is about 1,2 km/s (putting the orbital velocity at about 0,7 km/s). So a naive brake on Uranus would need to put the craft such that it brakes down to less than 1 km/s. 1,65 billion km at 1 km/s is about 52 years. Which seems to be a like letting off the gas in a car while going up a hill to break, but then getting to the top and still needing to go 50 miles to your destination. So something else needs to be in place other than just relying on gravity assists/braking.
Or you send some self replicating stuff on the moon, build some factories and solar panels, and build and launch robots from there. We have the technology to do this right now if we are willing to put the money. And if we polish the moon we could beam excess energy to earth.
> Or you send some self replicating stuff on the moon [...]
> We have the technology to do this right now
Do we? Self-replicating robots would be very exciting, even on Earth, but I thought we weren't close to being able to make them. Do you have a citation/link?
Everything except assembly, the motors, and the electronics. It's definitely getting closer but we don't have printers that can actually print themselves just yet.
I can only assume it means creating a large, vigorously reflective surface. Not the whole moon, but presumably making a reflective, concave part large enough to send a focused beam of directed energy.
(NB: this doesn't sound like a good idea to me, or necessarily realistic, I'm just guessing that's what is meant.)
It's impossible to have 'enough' parking spots. Induced demand shows that cars, like goldfish, always grow to fill the space they're given. It's politically difficult process, but just refusing to try to solve this problem (which leads to more New Urbanism-friendly locations) is often the right solution.
I've heard this theory applied to traffic, but not parking.
Because no, it isn't impossible. I've never had a problem finding parking when there's a parking garage nearby. E.g. 5th and mission. Just go to the top open floor, and there's always several spaces waiting for you.
It's just street parking that is difficult. Which makes sense because if you think about it, streets don't provide much parking. Maybe 1 car per shop.
Street parking is difficult to find because it cost less to park on the street, so people cruise around for spots instead of heading to a parking deck.
I just heard a Marketplace segment on this [1] where they talk about on-demand adjustable pricing. Very interesting.
The Parking Is Hell Freakonomics episode is pretty good. In it they estimate that there are something like 800 million parking spaces in the country and recounted a study by Donald Shoup that estimates that up to 30% of traffic in cities are people cruising looking for street parking.
Basically, we don't have a real market for parking in most cities, so people will keep their car parked on the street forever instead of using market forces to induce turnover which is better for the city(revenue) and the nearby businesses(more customers).
A counterexample: Las Vegas. All the casinos on the Strip have big parking garages that are free and don't fill up.
Perhaps it's possible only when the margins of a business are as spectacularly high as those of Vegas casinos, so that the parking facility as a loss leader is still net profitable overall. There's also the invisible hand of capitalism, as casinos compete in the market of convenience: a casino without such a facility will lose market share to those that do.
> Perhaps it's possible only when the margins of a business are as spectacularly high as those of Vegas casinos, so that the parking facility as a loss leader is still net profitable overall. There's also the invisible hand of capitalism, as casinos compete in the market of convenience: a casino without such a facility will lose market share to those that do.
Or land is so cheap because you're in the middle of nowhere.
The paper's basic tenet is that managers, by over-focusing on "poor performers", actually cause their poor performance by interfering with their work and putting them on performance improvement plans. Are there measurable differences between these people and your high performers in terms of output, or are you simply observing that to be so?
And listen to jonstewart. Being a manager is very different from being a programmer. Be humble and introspective, and work on becoming better at your craft.
The whole point of advocating for fewer work days is that we are just as productive in fewer hours. That's why overtime doesn't work long-term; you wear out and do less per unit time.
I think that used to be the whole point, somewhere around one hundred years ago. I thought that now the point is, we're doing mostly bullshit jobs anyway, so how about we all agree to work a bit less and have some time to live our lives?
They don't buy, or they buy something else. If there's one thing that economics has taught us, it's that people will reduce their consumption when prices go up; even water demonstrates price elasticity: http://www.nber.org/papers/w13573.pdf
Having people's sick days deduct from their vacation is an incentive to go to work when you're sick, jeopardizing the health (and productivity) of the team.
A much better solution is vacation days and unlimited sick days, as well as generous work-from-home opportunities for days when you're under the weather but not too sick to work.
The supposition here is that it's very unfair to impose a professional cost on getting sick. I don't see it that way. I see people getting sick because they take lousy care of themselves. They're fat and eat lousy food. Also, they make various idiotic stressful choices like having a 1hr commute, or putting a kid in some germ infested day care.
People who do not make such choices rarely get sick for more than the odd few of days a year. Why should they subsidize poor choices? Not being sick a lot is a reasonable and sensible professional expectation.
I'm not sure it's "very unfair to impose a professional cost on getting sick" but we don't have a way to measure whether people are sick other than self reporting until they are way past infectious, so you're not punishing getting sick but rather reporting that you are sick, and thus encouraging under reporting, which leads to everyone getting sick more.
Not only do you still have the few odd suck days but you might also have Kids that get sick. If you use up all your vacation time then you can't take any sick days
(Note: I used to be employed by Mozilla, and in that capacity I was the owner of Mozilla's image decoders. I've been disconnected from all decisions for almost a year, though.)
The main take-home here is that while Google's numbers all show WebP as being objectively better, the metrics they chose for comparison were relatively bad (i.e., some of them didn't take into account colour or didn't model colour correctly), and once you accounted for that the numbers were not nearly as good a story for WebP; in some cases, JPEG outperformed it.
The facts that (1) WebP was not terribly compelling technically, (2) JPEG is already supported by everything on the web, not to mention devices and mobile phones etc, and (3) there's still headroom to improve JPEG in a backwards-compatible way, meant that WebP was (and, it seems, remains) a non-starter.
Until JPEG supports transparency, it leaves a vast hole where a good lossy alpha enabled format is needed - namely icons. With the high resolution of mobile devices, using PNG for this use case is a huge waste. Regardless of the quality differences, WebP fills a major pain for mobile and web developers. I really think Mozilla should just support it.
I assumed it would switch between the original and the compressed version. Instead it's swapping out the background to demonstrate transparency, which could probably be made more obvious.
Yeah, depending on the image putting a bmp into a zip is actually significantly smaller than a png. Well, bmp has no alpha channel, but just as comment to the size of pngs. pngs even uses the zip algorithm in a way that is supposed to be optimized for images, but apparently it is not. E.g. the tiles here are a lot smaller as bmp in a zip: http://panzi.github.io/mandelbrot/
Ok, it put them into one single zip and can't remember if it was solid or not, so it might be the cross-file compression that makes the major difference here.
BMP have formats which support 1-bit and 8-bit alpha channels http://en.wikipedia.org/wiki/BMP_file_format. Just open any file in Photoshop and save as BMP then click advanced. Not sure of browser support.
If you're seeing BMP+ZIP being smaller than PNG it only means your PNG encoder is poor. This can be easily fixed with a PNG optimizer like Zopfli, AdvPNG or OptiPNG.
One browser is not enough. Image formats have massive network effects — people want to share, save and remix images. You need support the format in image viewers, editors, file browsers, mobile apps, websites.
As an exercise, try having your avatar only in the WebP format and see how useful it'll be.
WebP is mostly handled via transparent proxies - meaning people with proper browsers and Android mobile devices get WebP (large market share), everyone else gets (larger) PNGs.
That way you don't really care either way on the backend.
Saying 'proper browsers' gives away your bias there, since only the Blink WebKit engine supports it (Chrome/New Opera), which is under 20% of the desktop market worldwide.
Chrome has approximately the same worldwide market share as Firefox on the desktop. Both put together are eclipsed by IE. The metrics that disagree with this stat measure 'hits' (aka pre-2000 web metrics) instead of 'visitors'.
Simple 2 or 3 color icons might not win a lot, but there is also a whole genre of photo-realistic icons which would have a lot to gain from WebP like formats.
Google's own marketing materials claim 25-33% improvement at the same quality, so 5x improvement suggests they didn't compare apples to apples.
Comparing formats in a fair way is hard. "Looks almost the same" is a common fallacy — small change in quality can have dramatic change in file size, e.g. JPEG 80 and JPEG 90 look almost the same, but one is 2x larger than the other!
For example lossy WebP doesn't support full color resolution, but JPEG by default does. If you don't correct for that you're telling JPEG to save 4x as much color, and the difference is usually imperceptible, because that's the whole point of chroma subsampling.
Read the doc - the suggested x5 improvement is compared to PNG, which is the only other way to currently solve the problem of an icon with transparent edges (let's leave GIF aside), not compared to JPEG. The gain compared to JPEG was about 50%.
If they compared PNG with lossless WebP the difference would be small (lossless WebP is still using gzip, just with smarter preprocessing).
When you compare with lossy WebP, then the right thing is to use lossy PNG as well.
I can make lossy PNG 4 times smaller than what you get from Photoshop (http://pngmini.com), so that'd make the comparison more fair, and the difference less dramatic.
Best from a compression perspective, perhaps. There's the minor detail of it being patent-encumbered. There's no license pool available yet, so you couldn't pay for it if you wanted to. The proposed terms of the pool that is organizing (with some of the known patent holders refusing to join) would require up to $25mln/year for the video codec. No idea if you'd be able to get a better deal for still-images only.
But is there headroom for JPEG to replace animated gifs? If I look at mobile social apps these days, animated GIFs eat up enormous amounts of data. JPEG doesn't seem to have an answer for this, and no one has yet, it appears, made the <video> element work for this use case.
I really wish people on HN stopped linking to gfycat and linked to mediacrush instead. The former seems like a very scummy "lowest common denominator" type of site, while the latter is open source, allows self-hosting, has deterministic hashes, uses strong https encryption, ...
I looked over mediacru.sh and unless I'm missing something it doesn't serve the same purpose as gfycat. The point of gfycat is to upload a gif, it converts it to webm then it gives you a bit of embed code that will try to use the webm variant but will fall back to the gif when unsupported. I didn't see anything in mediacru.sh's code that would allow gif <-> video conversion, I tried uploading a few gifs on their site as well and didn't get any video options back from the API.
It would be better if the iPhone would play <video> tags without user interaction. I get the reason why they disabled that back when the iPhone first came out, but GIFs use up more bandwidth than videos, so they're actually punishing users.
Disagree. On the consumer side, I care more about auto-playing audio than bandwidth. On the content owner side, I only want my videos to autoplay (in most circumstances) if it were accompanied by the audio. If I didn't care about audio accompaniment I can already use GIF.
Perhaps the iPhone should autoplay videos, but muted until you hit a speaker icon (or something). Either way, forcing everyone to use GIF is horrible because of how inefficient it is.
I'd like a global option and also some simple per site UI.
This is how the click to play in Firefox works, it's nice. One thing I haven't figured out how to do is trust embeds from a site (for example, Youtube and Vimeo both have well behaved embeds, so I'd like to whitelist them, but not many of the third party sites I see them on).
That's only a UI issue. You don't need compression to be horribly inefficient to achieve that :)
For example <img src=vid.mp4> could autoplay looped video without audio, just like GIF, except using tiny fraction of bandwidth and CPU (thanks to HW acceleration) than GIF.
Expanding on Ray's comment above, this is really the compelling use case for WebP: a better container that does it all. Right now we have PNG, GIF and JPEG for three different use cases: animation, transparency and lossy encoding.
I can't easily pick and choose which of these I want, which means that we end up with 20MB GIFs that could easily be 1/5 the size, and crazy hacks to get lossy images working with transparency.
This is particularly painful for HTML5 gaming in my previous experience. For one of my projects that involved a giant, high-res game board with transparency (Nick's online Pai Sho), I ended up manually slicing the board up, converting center pieces to JPEG and leaving the edges in PNG. The images are all pasted together to make the final, seamless experience. What a PITA!
> no one has yet, it appears, made the <video> element work for this use case.
4chan has, and it's significant not only because they have a lot of traffic, but also because their implementation has to be pretty solid -- 4chan users would love nothing more than to troll the administrators by breaking this.
That and 4chan is a big content generator for the internet. Everything further down the line (reddit, imgur, 9gag, tumblr) should support it. Especially tumblr, who can consume over a gig of ram if you scroll down long enough.
>4chan users would love nothing more than to troll the administrators by breaking this
Not really worth it. You'd post something once, then you'd get banned for a week. Unless you have a fleet of proxies or can keep changing ip address somehow, and can keep posting while they try to fix whatever exploit it is you found. Kind of hard to target admins when they're all anonymous, too.
I have a cable internet connection and know the difference between a modem and a router. You'll have to take my word for it that every time I change my router's MAC address, my public IP does as well.
Honestly, animated GIF (like all other image formats) is a terrible format for video-style stuff. It's fine for line art (well, sort of fine, anyways), but if you actually using it for video you really should be using <video>, because it takes into account temporal information. (gfycat is a service based around this already.)
It might be possible to do an APNG-style backwards-compatible animated JPEG, but it'll still be worse at it than video formats will be.
Thanks to the ACID3 test, all modern browsers support animation in SVG and svg in an img tag. Which means you can do extremely small vector based animations, or write an encoder that embeds jpegs and animates them like a film strip. You can have alpha transparency using a mask image via SVG filters. You can get really fancy and animate with deltas. The efficiency you lose by the base64 encoding is regained by gzipping.
Actually SMIL (the declarative way to do animation with SVG, for those who don't know) has always been controversial (as far as I know, IE never passed that part of Acid3), is more or less on the chopping block as far as browsers are concerned, wasn't extensively tested in the original Acid3, and, in any case, was removed from Acid3 as of 2011[1]
It was removed from Acid3 (or at least made optional), letting IE pass the test without implementing it. Furthermore SMIL is fairly complex, performs worse than script animation in today's browsers and (iirc) doesn't play well with CSS animation. I think I've read on the mailing list that there is effort done to harmonise those two in the future.
To review, it would seem that while you have a blog post from ian hickson making a passive reference to deprecating smil. Indeed he followed up by removing the feature from the ACID3 test. But the damage was already done:
evidence of actual standards activity and implementations from as recently as June 2014 show instead an active merging of css animation with svg animation into a single consistent model called "web animation" [1]
the implementation of this merging effort in chrome's blink rendering engine [2], and a rationalisation for this webanimation effort that promotes not a removal of the svg animation features (which are already implemented in everything but IE), but an expansion of their powers, being advocated by both google and mozilla [3]
Just because IE is lagging behind doesn't mean this feature is cut. Just because Ian Hickson says the feature is deprecated doesn't mean that it is, or that browser devs will follow whatever he says.
What it does mean though, is they are attempting to cut the feature's dependence on "SMIL", while retaining the currently implemented features. so I think that whatever works in browsers now, you can more or less rely on that working in future browsers as well. So yes, my suggestion is still useful and it's still awesome. And if you use css animations inside the svg (which totally works) instead of svg-smil animations, you can even get it working in IE10
I see many "big" webm videos on 4chan, much bigger than gifs. (in dimensions, not in bytes) and they are still smaller (in bytes) than the (dimensionally) smaller gifs.
Wouldn't it bring a huge traffic shrink, if every uploaded gif was converted to a, probably, tiny webm?
you can use javascript mpeg1 decoder instead of <VIDEO>
you get auto playing animated mpeg files instead of gif
mpeg is pretty much jpeg stream with bonus I frames
Motion JPEG is arguably even worse than GIF. It's literally just a sequence of JPEG images -- there's no extra compression; 100 frames of MJPEG are 100 times larger than a single image. GIF is a bad format for videos, but at least it can try to be more efficient than this.
Could you conduct a detailed article and publish it please? I think it would be useful for people who are interested in this but don't have the background about JPEG or WEBP internals.
Working hard is necessary to make something good, of course. Working "hardcore", where 100-hour weeks are _required_, and only "exceptional" performance is acceptable, is _inhuman_.
I'm saying this as someone who's managed several teams over several years, but also someone who's read the literature: the surest way to get bad performance out of someone is to put that kind of pressure on them, _especially_ long-term. People in that situation get tired and/or sick, can't straight from the anxiety and pressure, and because of all of that that they'll make simple mistakes that take a long time to sort out (because everybody else is in the same situation).
In my experience the best work comes from people who are calm, healthy, and well-rested, _especially_ over the long term. Those well-rested people are the ones who are capable of putting in the discretionary effort to make something good.