Is there any reason they can't just go back to Google? I thought they only switched to Yahoo because the contract was up and Yahoo offered a deal they couldn't walk away from.
92 people per day isn't "uncommon". It might be statistically improbable, but that's not what uncommon means. It's a regular, daily occurrence for 92 real human lives every day.
This is the first fatality collision after 130 million miles of tesla's autopilot, so it's already above that bar.
Additionally, 92 people are killed in fatal car accidents in the US every day. So it's not as though this is some uncommon occurrence that autonomous vehicles would be unlikely to improve.
So all they determined was everyone already has the top installed (and often pre-installed) apps already installed? What a surprise.
Also I would love to install more apps but to do so I have to clear space on my phone, and the apps I already have are slowing my phone down and eating my battery. For me it's always a matter of resources.
Yeah and I like how he goes in on 'Agile Gurus' and then at the end of the article plugs his continuous delivery conference like it isn't the exact same thing in a different hat.
I assume when referring to PSD-driven development you mean to say the process of having a designer design a non-responsive, static mockup which is delivered the the front end dev team? I think this is important to clarify because a lot of people tout Sketch as being the answer despite it having the exact same pitfalls and issues Photoshop does.
Check out this demonstration. I really think this is going to be the next big step forwards for designers. I don't think they need to fully understand CSS, the box model, flexbox, the dom, inheritance, etc to deliver effective designs. They just need to be forced to follow these limitations of these things within the design tool itself.
I think the idea is to make every change the designer makes reflect a nearly identical change that the frontend devs are going to have to also make. For example, text color inheritance is a notoriously hard thing for a designer to grasp. If that was handled automatically for them, they are going to out of necessity, create a more code friendly color inheritance hierachy in their designs.
This problem is the bane of my existence as a css/html guy. However I don't believe the core problem is what you suggest. Forcing designers to just work within wireframes isn't going to work. Assets and wireframes is only a small part of what a designer does when creating a good user experience.
I think the solution is going to lie somewhere inbetween, with designers needing to expand their knowledge and working within tools that are based on how CSS and HTML actually function instead of a program that allows you to just place boxes wherever you want and hope its easy to code.
I've been following what these guys are doing over at BoxBox, they are onto something big I think. https://keminglabs.com/boxbox/
Generally newly created, but not necessarily. In 'The Lean Startup' by Eric Ries one of the primary examples is based around Intuit, which is a large publicly traded company.
Not surprised at all, there hasn't been any updates or improvements in awhile, especially for the desktop app, it's nearly unuseable with its current bugs. Seemed like Dropbox never put enough resources into it for it to really get off the ground.
I've switched to airmail for the time being, but I'm definitely going to miss snoozing emails to specific dates.
Well I think its an out of sight, out of mind kind of thing. Something commented out is generally something you know you'll want to be referencing again. Coming back to something in the future you/your teammates might not even remember/realize that the deleted code was ever there.
The methodology gives you the tools to have control over the cascade. You cannot avoid it entirely.
Edit: Also the point I was getting at was that cascade is a useful and powerful tool, just as the methodologies for controlling it are. We will also soon have a property that will eliminate the cascade entirely... all:unset;
I just think the problems and solutions listed in the talk are either non-problems or are things that could be solved in superior ways. And that it introduces more problems and limitations than it solves.
For many reasons, namely that we've already solved most of these "problems" years ago with simple concepts like OOCSS, SMACSS, and BEM. I suggest taking a look at this rebuttal.
http://keithjgrant.com/posts/against-css-in-js.html
The reasons people are running into problems with global css scope is because they don't understand the basics of how to write effective and maintainable CSS. Seems like many front end devs nowadays grew up with css hand-holding libraries like bootstrap, and can't seem to wrap their heads around completely necessary things like taking account for CSS specificity and how the cascade works and how to use it to your advantage.
If you can select to copy its no different than a screen reader. There's is 0 usefulness to this, and it's embarrassing that it's on the front page of hacker news right now.