dmethvin

Aspiring to communicate with developers as well as Apple does is a perverse goal. Microsoft for example has a status page for their browser work [1] just like Google does for Chrome [2]. (The Microsoft page lets people vote for their favorite features, the Chrome one does it via stars on their tickets.) Something like either of those from Github would be great.

[1] https://dev.windows.com/en-us/microsoft-edge/platform/status... [2] https://www.chromestatus.com/features

It can be as simple as a text file that is dropped into the content-free TEXTAREA that currently greets new issue reporters. Try running a big project like jQuery, Angular, or Babel and you'll understand how important a feature like this would be.

So if the current DOM APIs already solve those problems, what changes would you make? As I mentioned, renaming them just makes things harder.

The success of jQuery, React, Angular, etc. makes it mostly unnecessary. There is no need to avoid JavaScript wrappers to the DOM API, and lots of good reasons to have them. External libs are more flexible and fixable than web platform APIs. Very few people need to write directly to the DOM API nowadays and the ones who do don't need more abstractions or a bunch of renamings. Those things generally just complicate the code in frameworks and libraries because they create multiple code paths for years.

As an example, the all-business SAS flight from Houston to Norway was targeted at oil company employees [1]. It couldn't fly 7 days a week because they had to take the plane offline once a week for cleaning/maintenance and there was no other all-business plane to rotate into its place. They stopped the route because the oil price slump reduced travel of oil company employees.

[1] http://thepointsguy.com/2015/10/10-unusual-things-sas-737-tr...

One of the insidious things about debuggers is that they let you be lazy when reasoning about the code you've written. When you don't have a debugger, you need to be more careful about what you do and really understand the complexity of your code, because a misstep when writing the code can take hours to remedy. With a bunch of safety nets at hand, you feel like you can just blow out some code and work it out via the compiler and debugger later.

There's no doubt that better tools have let us be more productive, but in the process we understand the code we write less deeply than we otherwise would, because we are required to spend less time contemplating it.

> Coding is boring, unless… you're building something cool and meaningful.

The problem comes when the people doing the coding don't consider the business goal of the software to be cool and meaningful. To everyone but the programmers, it doesn't matter what tech you use to build the solution if it's not solving an important problem.

So they start writing a web app with Backbone and then move to Angular and finally React without ever have created a viable product, but they feel good because they are using something that other devs feel is the coolest and most meaningful today.

It's understandable that individual files would be slightly larger in aggregate than a single combined file, due to the compression issue that was mentioned. However, since there is no more head-of-line blocking the overhead of an extra few bytes should be negligible compared to elimination of round-trip delays. Also, if you are expecting to serve HTTP1 clients for a while it's a good idea to use a hybrid approach where you combine files, just less aggressively than you may have in the past.

The risk near Galveston would be primarily from hurricanes.

You've grown up in what is probably the best place in the world to ride a bike, which makes your experience enviable but not typical. Here in the car-dominated USA it's a lot more dangerous to ride a bike because we're "sharing" the streets with fast cars that are sometimes inattentive or even aggressive. Plus, the maintenance of the streets themselves sometimes conspire against you, it's easy to lose control on a pothole or slick crosswalk marking. I have had a couple of falls where my head whacked the pavement, and was very glad I was wearing a helmet.

Edit: This video says you're 30 times more likely to be involved in an accident in the US than in the Netherlands: https://www.youtube.com/watch?v=m2THe_10dYs

So the same government that is spending money to prosecute you gets to determine how much money they will spend on a public defender for you? We've covered this ground before: https://news.ycombinator.com/item?id=10177778

...and this is the unspoken truth of advertising. There is no reason for advertisers to reach that majority who cannot or will not pay for whatever is being advertised. However the publishers resent ad blockers because they reduce the pool and that's a bad thing in a world where cost-per-impression is common, or even cost-per-click where inadvertent clicks can make money.

At the bottom of it all though, there need to be enough people who actually do follow through on the call to action in order for the ads to be profitable. In casino parlance these are the "whales" who make all the freeloaders at the buffet worthwhile. In the 1990s the "whales" of the Internet were AOL users, they had that sweet combination of impulsive action and disposable income that advertisers love. I don't know who their target market is today, but it's not me.

This seems like a great approach when the client devices are all friendly and collaborating. What sort of countermeasures do you need when some of them might be malicious attackers?

The programmers writing embedded software in the US aren't being paid all that much in respect or money either. It's not glamorous, you're basically invisible. Given all the money paid in the valley to develop the next Uber for Dogs it's hard for these companies to compete. That's why companies like GE are doing commercials for recruiting [1] but I don't think they hit the target.

[1] https://www.youtube.com/watch?v=OvfU1NpCJQQ

In this particular case, 150-foot skid marks indicate that the driver was trying pretty hard to stop.

No doubt there are accelerator-brake confusions in many of these cases, especially with older drivers. I'm really hesitant to say they all are in that category. Investigators need more "black box" info to see, for example, whether the accelerator and/or brake were being pressed in the seconds before an accident.

This is where a junior developer can really help, even if it's junior in the sense that they are not as familiar with the project as you are. There is no better way to become familiar with the true problems and priorities of a project than to triage bug reports from the people actually using the software. You may be too deep into it to see that.

Don't prioritize based on what is the "fun technical challenge" but instead figure out how you can get users to be happier with what you are building. Also remember that sometimes the answer is code, and quite often it is documentation or a code sample showing the "right" way to do it.

I really like the wireless charging on my Nexus 5 as well. Going back to the cable would be fine with me but I would prefer something that takes a little less effort to insert and I'm always concerned about breaking the connector. I just found a really interesting MagSafe-like connector for the classic micro USB [1], maybe they will make something soon for the new USB3 that the 5X uses.

And before some of you say that MagSafe has patents on this, remember that the magnetic catch for a power cord was used on deep fat fryers YEARS before MagSafe [2].

[1] http://www.dxsoul.com/product/wsken-micro-usb-metal-magnetic...

[2] http://www.cpsc.gov/PageFiles/102855/Fryers-DeepFat.pdf

If the layout isn't "dirty" from a change, then it doesn't need to reflow.

For specifics on which CSS properties affect layout, see csstriggers.com .

This kind of philosophy bothers me:

> “There’s a tax that comes with interoperability and what can be seen as complexity, which is it can actually be an impediment to innovation.”

Yes, it's possible that standards can become too complicated. Rather than refusing to participate, as Apple has done with pointer-related designs, why not join the group and give rational reasons for simplifying the design? Every thing Apple has reinvented here is already supported by W3C Pointer Events as far as I can tell.

Perhaps the gp meant this case?

   something().then(function(){  
      setTimeout(function(){  
        whoops_not_a_function();  
      }, 1000);  
   }).catch(function(){  
      // nope, nothing to catch  
   });

What a great writer, and the article seems well researched. I note that he's got a Kickstarter to go to Antarctica, just chipped in for that.

Flying on Southwest is actually the most pleasant experience that I've had, compared to the other carriers. They allow two free checked bags for example, and their employees are much friendlier and helpful. They give out free beer and wine several days a year (Mother's Day, Father's Day, Southwest's birthday, etc.) There certainly has been a race to the bottom in air travel the past few years, but it doesn't look like Southwest is participating.

On the Windows side, there was a lot of tense discussion between Intel and Microsoft regarding Intel's popular integrated-graphics chipset being shipped at the time of Vista's release. The chipset didn't have hardware DirectX support and shouldn't have been certified, but Intel had promised their customers (like HP) the chipsets were fine and they were not anywhere near the end of the product lifecycles for either the chipset or the PCs. So Microsoft fudged the rules and a bunch of consumer-grade hardware ran like crap on Vista.

The article did say it's less efficient, but you can put twice as many in the same space which supposedly more than makes up for the power deficit. Plus no noise pollution or threat to birds and lower maintenance costs. Obviously a lot of technologies look good at this point, before they are widely deployed and tested, but I wouldn't count it out yet.

These have been around for a few years, I remember seeing a video of the "helmet" inflating. Here's the one I could find, which is a lot more annoying than the one I recall: https://www.youtube.com/watch?v=2tDy4InLcXU

My thought is that you should speak to a lawyer who is experienced in these kind of disputes. Bringing in a lawyer to represent you pretty much burns the bridge but it sounds like you will either want or have to leave anyway. If this is a large company, they do not want to get involved in a protracted dispute, especially if it might become public. This is true regardless of what you have done that might legitimately make them want to get rid of you. Yes, you don't want to ruin your own reputation as an employee for a future employer, but they have much more to lose in most cases.

You would be surprised how far companies will go to avoid outright terminating someone. In past jobs I have been in management and had to deal with people who had anger management problems, drug problems, and sexually harassed co-workers. Despite the documentation for these issues they were given up to 6 months to find other jobs and/or terminated with several months of severance for signing an agreement they wouldn't sue.

A lawyer will generally give you a free consultation and could write a letter on your behalf for a few hundred dollars. If your case seems to have more merit, they may be willing to take it on contingency.

The author may be correct, which is of course the best kind of correct. Yet I have written code for more than 25 years that depends on the behavior exemplified in the `offsetof()` macro referenced there. When writing low-level code it's really handy to know the offset of a member in a struct.

If sweating from the exertion is a problem, you could use something like an electric unicycle. They go up to 25km/h for 20km, can take hills, and are good for the "last mile" problem of getting to/from the train or metro. Judging from the YouTube videos they already seem to be in use around Paris:

https://www.youtube.com/watch?v=mVJAeQbInYg https://www.youtube.com/watch?v=InaqGRYq1z8

The comments in the current jQuery source are pretty good about explaining the strange things that need to be done to work around bugs in browsers. Look for the `// Supports:` comments.