bengoodger

I've seen this argument repeated ad nauseum over the past 15-20 years. I think it depends on what you want.

Yes to some having consistent elements of UI make some users feel very happy about using your software. Most probably won't be able to articulate why, they'll just feel a bit happier.

I don't think there's an absolute in this discussion though. The web has proven that people value having access to more capability more highly than how well every aspect of that capability works. You could view the lack of integration as a weakness of the web, but for me it reads as flexibility/empowerment for the developer. It's possible to view developer empowerment as a negative, but in the case of the web it's enabled it to tackle some interesting use cases that you might miss if you stick to the rules too zealously.

BTW, I think it's possible to build crappy UI natively too. It's a mindset thing. The web isn't native on any platform yet there are some web apps with great UI. There are also some non-native client apps (like Chrome) that I think (admitting my bias in Chrome's case) do a pretty good job.

As someone with a lot of these pricy adult sets I find the presentation in this article weird. Lego described as a "victim" of aging consumers etc. vs. this being a deliberate calculated strategy by Lego to go after the adult/hobbyist/collectors market. It's actually the latter, and the result of a deliberate effort to turn the company around from near disaster early in the 2000s. There have been several good articles written about this. I have no problems paying for the big sets. If you don't like that, buy the smaller sets, they're just as much fun as they were when you were a kid.

When I moved here ~12 years ago one of the things that surprised me the most was how comfortable companies were at flat out deceptive marketing. The lesson I learned very quickly was to assume any claim made on any package by any company was unsubstantiated and usually a lie.

What I took away from this is that as a consumer you have to be very engaged in evaluating your food choices. Unfortunately most people aren't, it seems. I continue to be surprised by how many otherwise intelligent people fall for claims of "low fat", "sugar free", "high calcium", "organic", "natural", "gluten free", "kale", other fads etc.

The other thing I learned is if you want to be a low-information consumer, there are far better countries in the world for you to live than the US, places where the government takes a stronger hand in enforcing population health and consumer protection. If you live in this country, you had better be smart and look out for yourself, because the companies and the government not only don't care, they are actively trying to screw you.

This is a great book. I had the good fortune of working with Karl and a couple of the other Subversion founders (Fitz and Ben) early in the Chrome project at Google. This book served as an invaluable resource for the team to learn about open source development as we established the Chromium project.

Having just raised the ceiling in my house, there are a variety of things.

Taller walls tend to come with taller windows. Not just more glass... sometimes whole extra windows (transoms) which cost almost as much as the much larger ones below. Taller cabinets or soffit details to receive them. More elaborate trim work. etc.

For a flipper or a production builder every dollar is saved because it adds up in the end. If there's a high ceiling it's because it's been determined to command a good profit.

Furthermore, Chromium's now spent the vast majority of its life developed in the open. You would probably find today's code unrecognizable if you traveled through time from 2008.

Good luck waiting out the gold rush, it's been a part of the California way of life for more than a hundred and fifty years.

The lemon law is not quite as cut and dried as the author of this article states. If you're not happy with your car you should not make this judgment for yourself. Consult an attorney.

You can be outside the 18k miles but if the problems began inside the first 18k miles, you qualify. I have personally had a car bought back a couple of months ago. After rejecting the manufacturers' initial offer of monetary compensation and sending a letter to the company on attorney letterhead, the mfr immediately folded and offered to buy it back for the full amount required by the CA lemon law.

You're right that traditionally Control4 has not been hardwired - but note they're moving into panelized lighting control now, and my assumption was that system would only be controllable from their frontends unless you reverse engineered the protocol.

It will be interesting to see how much of this relies on the presence of existing hard wired systems, many of which are controllable over the network (e.g. Lutron, many security systems, etc). Writing to other peoples' APIs has not typically been Apple's strong suit. At the same time, wired-in infrastructure in a home is nothing like as disposable as the consumer technology Apple focuses on. There is no way I would want a closed system baked into my house. Hard-wired infrastructure is something you're stuck with for decades.

Relevant to me as I'm in the rough-in phase of a whole-home remodel project. I struggled a lot with what level of control to use, before settling on a minimal Lutron system for some areas of the house, comfortable in the knowledge that if I get tired of the Lutron interface, I can create my own & poke it over the network. I understand most people aren't interested in this level of control, but they might be concerned when their interface becomes dated in 5 years and can't be replaced due to an incompatibility with the hard-wired infrastructure. I see this as a downside of closed systems like Control4.

I used to be more religious about this sort of thing... but the religion falls apart even on OS X when you realize that even WebKit implements its own copy of the native controls that can appear in web content - so that they can be transformed and animated using CSS.

This is nothing like XUL. It's just some abstraction layers written in C++. The hygiene from the Chromium side is that it allows us to share some code with abstractions we already have for the web platform.

Chrome UI on Windows, ChromeOS and soon Linux are comprised of a few layers:

Views (widget toolkit abstraction) - tabs, buttons, textfields, etc. Aura (window/"native widget" abstraction, event dispatching, what most code at layers above would consider to be the XWindow, except the XWindow is abstracted (and there is only one XWindow per top level browser window)) CC - (Chrome Compositor, also used for web content.)

They're all in native code since being able to drop down to the metal (& grab the app's toplevel XWindow) is often useful when building a desktop UI. HTML/JS/CSS binding to CC is limited to Blink.

The easiest way to try the ChromeOS UI on another platform is currently on Windows 8, where if your regular Chrome build is set as the default browser it will run the ChromeOS desktop environment/window manager in Metro mode (you have to close all the desktop windows for this to work).

Likely way more work than you're interested in but on Linux:

Follow most of the steps on this page: https://code.google.com/p/chromium/wiki/LinuxBuildInstructio... then:

  export GYP_DEFINES=chromeos=1
  gclient runhooks
  ninja -C out/Release chrome   # May take a while!
  ./out/Release/chrome

... this produces a build of Chrome very similar to the one run in ChromeOS (we use it for 99% of UI development & testing on our Linux workstations). You can run this and get a feel for the desktop environment, window manager, etc. Similar steps will work on Windows but with use_aura=1 defined in GYP_DEFINES, and chrome run with --open-ash on the command line.

It's a single product, composed of multiple projects/targets building different dlls/executables. That was my understanding of the point of a "solution" (vs the old days of VC6 when there were only projects and workspaces). Anyway, it used to work back in the days when most of Chrome's code came from WebKit. Now we're many times bigger. It's clear MSVS' project UI is not intended for building projects of this scale. I'm assuming Microsoft doesn't use this UI to develop windows, or office, so it's not surprising this case isn't supported.

Chromium is an extreme case of this. When we started we wanted to live the VS way of life (IDE tools and the like), so we had a Chrome.sln and various projects. Eventually it became too much. It would take minutes to load the sln, and woe to you if you synced your source tree while msvs was open, as you'd receive a neverending slew of modal prompts asking you to reload each of hundreds of projects. I think we still have a msvs build, but most developers use ninja on Windows, and just use msvs for debugging. The sad fact is that addons like Visual Assist X provide many of the benefits of the IDE without requiring projects to be loaded.

Desktop window manager integration seems to always be tricky. I've personally sunk months of my life in getting a variety of custom window frames to work "well enough" on various Windows flavors (for Chrome on XP, Vista, 7 and newer). I think part of the benefit of these new mobile platforms is their simplicity - there is less going on outside the app's control at any given point in time, so there's less to worry about.

(On Windows, there are several ways to achieve a "custom-ish" frame, but only if you really study the window manager-app interaction and think about the problem as if you were the window manager can you come close to doing a proper job of it... handling the right messages (some of which are undocumented and only discovered via using spy tools), responding in the correct way etc.)

"Culturalism" aside, the additional CVR transcript the OP gripes about Gladwell omitting does little to support his claim.

Gladwell's segment: FO: "Don't you think it rains more? [..]" Omitted: FO: "Captain, Guam condition is no good."

Yeah the omitted section is much stronger. But it's wrong to argue that it's direct enough, because it's still not as strong as the FO saying something like:

"I think the conditions aren't good enough for VFR. I think we should change our strategy."

Some of the pilot interviews after OZ214 have stated many airlines have a "no-fault go-around" policy. If anyone in the cockpit has any discomfort with the approach, the rule is that you go around, and make everyone comfortable, with no fault to anyone. This is an environment in which a pilot could be more confident making a direct statement like the one I suggest above.

I don't necessarily believe this is a cultural thing though, just a good idea that airlines should implement.

It's not limited to Java. We have a rule in Chromium where if your class name contains the same word twice you have to do a shot.

This is optimizing for the wrong thing (developer convenience vs. user experience). People like using tabs in their browser more than windows.

This also ignores the other important benefit of mparch: sandboxing. The browser needs some elevated access but the page content does not.

Observation by police officers? I already see plenty of people texting while driving. The first hint is that they're driving like they're not paying attention. When you pull up alongside them you see them glancing down repetitively.

Also, the penalty fines are a joke. I think in CA at least they were very low, especially considering IMO distracted driving is way more dangerous than other simpler measures like speeding.

IMO only when this is treated like DUI will it be taken more seriously. It sounds radical, but the activity is easily avoidable, seriously diminishes your focus and can have horrible consequences.

The Herald is in no way the "Fox News of New Zealand." It's Auckland's major newspaper. I don't find the reporting more or less dense than most other msm tech coverage frankly. I lived in NZ for 20 years, and don't remember any news sources there being quite as ridiculous as Fox.

The comparison is misleading. I'd wager few new MB S sell for $70-80k. A better comparison in performance, price, equipment and size would be the mid-size equivalents, e.g. E-class, 5-series (GT?), A7. It's possible the Model S has sold more than the 5-series GT and A7, but mostly because the market has a hard time understanding hatchbacks.

BTW you can see the remnants of the code that supported this feature for popups still in use for things like HTTP Basic Auth dialogs: http://www.pagetutor.com/keeper/http_authentication/index.ht...

The feature went through several iterations. Originally, popups were just shown with their requested size anywhere within the browser window. The idea was that a page could only damage itself by opening popups and not interfere with your window manager state.

This was deemed ineffective (sites knowingly do stuff to themselves like this all the time - e.g. overlay divs), so we auto-positioned them at the bottom right and hoped you figure out that their titlebars were stacked down there and would drag them up.

Then we made them detach immediately when you clicked them.

Then we got the feedback evmar mentions and we just did the boring thing. Personally I find it less discoverable now (and am constantly missing popups) but non-user-gesture generated popups seem relatively rare on the web these days compared to more annoying stuff.

I've only written a small amount of dart so far, but speaking as as a cranky C++ developer with not much recent experience with web development, having a thicker standard library is very useful. Specifically the platform has grown so much over the years it's hard as a newcomer to discover the well lit path. With dart:html for example, it's much more straightforward - they have done a lot of work simplifying the very broad set of DOM APIs. I understand there are various JS libraries that provide this, but as a newbie which one do I pick?

It depends what you're interested in.

"Market vs. Usage share" is a debate that rages every time these numbers come out. It's really apples and oranges. For me, market share is an interesting piece of trivia and usage share is a snapshot of the zeitgeist of more heavily engaged users. Which one matters most to you as a developer?

I don't believe communities in SV would sign onto this.

One important reason is the lack of core infrastructure like a centrally planned transit system. The thing to remember about the bay area is that it's not one city like NYC. It's a number of smaller cities and counties each with their own local governments, rules and constituencies. See San Mateo and other counties opting out of BART. Another example are various communities with maximum density regulations.

This is the kind of thing where you need a strong central hand to force these issues if you want your community to scale, but it's not clear that any local community would cede that power.

There's definitely a mindset on Chrome that:

- any feature, no matter how small, has some cost (code size, testing, cognitive complexity, etc), and frequently contributes in some way to making the product and/or other development slower. - as a developer, user, product manager etc, it's up to you to figure out how to convince other people your change is a good idea, and how your change will be maintained going forward, if you have to switch projects for instance.

We have a long history on the Chrome team of deleting code that was only relevant to one or two developers and those developers moved onto something else. It's the only way to stay sane at our scale, frankly, and we don't even do it as much as we should.

I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team.

I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is.

A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app.

One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.

I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day.

[1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org