div

There are 2 things being discussed here:

1) people being confused by the back button because they don't realize it will always pop the current view of the navigationstack, which is systemwide.

2) the fact that the back, menu, search and home buttons are dedicated hardware buttons.

Explaining how 1) works does not mean that 2 is not broken. Personally I find 2 to be the interesting discussion.

Seeing how these hardware buttons are being changed to be a dedicated part of the Galaxy Nexus' touchscreen, and how not all vendors actually put all 3 buttons on there, it's not too hard to argue that something about the hardware buttons is at least flawed, if not broken.

Same here, Vista / Chrome as well.

It is very hard to imagine John Gruber being taken somewhere unexpected by using the back button on an Android device.

This is like saying you were taken somewhere unexpected by using the back button in your browser.

Sure, it may not work consistently all the time, but when it doesn't it's always the fault of the website / app that breaks standard behaviour.

Steve Pavlina has blogged extensively about polyphasic sleep:

http://www.stevepavlina.com/blog/2005/10/polyphasic-sleep/

You are unlikely to get comments from people who have actually built large scale web applications with all three of those frameworks, so you'll get a lot of opinion and little fact.

As a second point, all three of those frameworks are solid choices to build a web application with. Selecting one purely for scalability reasons smells like premature optimization.

Unless you know you are going to be hitting truly massive scale, all three frameworks can be plugged into a share-nothing-architecture and made to scale horizontally.

I don't really understand what the author is trying to say. Granted, it's been a while since I used Ubuntu, but as a developer I mainly live in my editor and terminal.

Anything I ever wanted is just an apt-get away and is mostly installed in a sensible way.

Ubuntu simplifying desktop features and changing defaults to be easier for users like my mom sounds like a great thing to happen to Linux.

That stuff is mostly orthogonal to developers who, you know, know how to deviate from the standard configuration and tools.

I'm sure they did, but being connected to the grid is probably necessary for generating the 500KW.

I'm positive about Tesla's future. They had to do a big investment in technology that now seems to be paying of in 2 ways:

- building a sedan that has mass market potential

- selling tech to established car manufacturers: http://venturebeat.com/2011/07/20/tesla-toyota-100m-rav4-dea...

It's a mini version of the Samsung model, and I can see it working well for them.

edit: found a link that's not behind a paywall unless you have Google as a referrer.

We use svn at work too, but pretty much all developers have switched to git-svn.

People used to working with tortoise or versions for mac still use vanilla svn, which is a big reason of why it's kept around.

You may disagree with those views, but if they are predominant among the people who have final say in hiring you, and at what salary, then the advice is good.

The whole point of the article is to force a typical engineer to look at how most of the world perceives him, and work with that.

If you have to talk to another engineer as part of a hiring process, talk all the shop you want. If you're talking to business people, try to talk about the business advantages of what you do.

The programming language or stack does not matter to whoever is hiring you.

The fact that you knew IRIX was a good indicator that you'd be able to pick up Linux.

It's also today a good indicator that you'd be able to pick up Windows if you set your mind to it.

Your advice is solid from an engineer to engineer point of view, but Patio's advice takes an egineer to business perspective.

Dropbox is in the business of enabling stuff, not disabling malicious behaviour (or making it more difficult or whatever).

Specifically, if someone has malicious intent, software is not likely to stop them.

You can't solve people problems with software is a often used mantra.

It's so easy these days to be a raging sexist and play the 'troll' card.

Not everyone wants to go through this kind of battle against an anonymous adversary.

I think she has the right not to have her decision to quit questioned. Just because she was the one being harassed does not mean she is suddenly responsible for bettering women's situation in tech.

Just build something.

If python is your thing, find a tutorial to build a todo list app or a calculator or whatever.

Once you finish that, either build the same thing in a different language / framework if you're not happy with your current tech choice, or build something that's slightly bigger than what you just build.

They can, and it's basically what LLVM does when you turn on ARC for your Objective-C program.

http://stackoverflow.com/questions/6385212/how-does-the-new-...

Curious about how many other cool projects / companies can come out of that line of thought:

"Here's a plain everyday thing that everyone wants to ignore, let's make it a cherished item"

This page should give you the gist: http://www.nest.com/living-with-nest/ just scroll down.

DELETE is idempotent as well.

GET and HEAD are not really "potent" as they don't cause state to change on the server (or at least shouldn't). So I usually prefer saying GET and HEAD are "safe".

The difference between safe and idempotent is:

- using an idempotent verb 0 or 1 times will have a different end state on the server.

- using a safe verb 0 or 1 times will have the same end state on the server.

I find rails in particular to be very easy to just "api all the things" right off the bat. Add in some nice authentication / authorization with something like devise and CanCan and you will be saved from the headache of bolting an api onto your app as an afterthought.

Reading the actual interview, it seems that they're working on this:

> Matias also told me that a new style guide was being prepped for developers with lots of off-the-rack pieces that would make it easier for third-parties to create the same kind of streamlined, beautiful applications I saw in Ice Cream Sandwich.

That short paragraph can mean a lot, here's to hoping that Google bundles this information in a way that is both:

- enjoyable for a developer without much design skills

- easy to point a new designer to so he can build up a rough framework of how to design for Android

Please Google, just don't scatter this info across developer.android.com in that crappy badly thought out tree structure :/

Having versioning information in the headers should be as obvious as having it in the url when you are writing code that interfaces with the rest api.

Url based versioning is only more visible if you are accessing the api through a browser, in which case it's probably fine for the api to return the latest version since humans are pretty good at making sense out of new representations.

I'm not sure I understand the benefit of url partials based routing. A REST api should be easily loadbalanced using a simple round robin setup since no state lives longer than a single request.

Edit: Ok yeah, url partial based routing will allow you to implement v2 as an entirely new system.

What matters is that they have the option of using it. They may not do so today, but tomorrow is a brand new day.

My thoughts exactly. He used the rent from 1 house to cover the mortgages on both his rental and his own house.

A typical mortgage around here is about 1/3rd of your income. So being able to basically have other people pay 2 mortgages for you is _huge_.

He also mentions he bough a bunch of Cisco stock for 7$ which he later got to sell for 30$. That's more than a 300% return, so depending on how much he invested, that can easily amount to a hefty chunk of cash as well.

This lawsuit has nothing to do with the software UI.

This is about the physical design of the iPad being patented. That's why being able to distinguish between a Tab and and iPad from 3 feet away can be seen as somewhat relevant.

This is the European version of the patent: http://www.scribd.com/fullscreen/61944044

I'd never come across his site or anything by his hand before, and feel like I've missed out on a lot.

On the upside, I'm excited at going through all of his archives. I haven't felt inspired like this in quite a while.

Since you are probably not privy to your employers actual financials, there is no point speculating.

Just go ahead and ask. If they tell you there's no money, or that they think they're already paying you enough, try to negotiate a re-evaluation in 3 to 6 months.

Decide for yourself if you can live with not getting a raise. Negotiating directly with the CFO beats negotiating with him through an HR person.

Almost every time I read a story about the two Steves, it feels like their relationship was unbalanced. Woz always comes out as the brilliant engineer who gets played by management to lay golden eggs for nearly free.

I haven't read iWoz, and I doubt Woz himself feels this way about it, but these stories just have a way of coming across that way.

It doesn't feel like this applies here. 6-7 years ago a decision was made to go with stored procedures over using an orm or at least implementing db logic in the application code.

Along with this, they also chose to split the responsibility for code and sql across two teams.

6-7 years ago, plenty of other options were available. In fact, the sharded MySQL solution that they use now was already possible back then.

It sounds more like they made some architectural decisions based on the companies org chart and it came back to bite them in the ass hard.

edit:typos

Even if you have a point buried in your vitriol somewhere, making a throwaway account and delivering it in this kind of way is a new low, _especially_ since you know the guy is still in highschool.