Amen.
16 karma · joined September 9, 2012
What really helped me is the approach to program API-driven. Don't start with your algorithms but start with what kind of functions you probably need and what would be the easiest way to use them. (In fact this is not so far from this data-centric approach as the most basic functions of APIs are usually function to retrieve or modify data.)
Try to read some good code from one of your favorite open-source projects. At some point some code may catch your attention because it's so simple and elegant. Why is it so elegant? Often because the underlying structures are just simple and made from common-sense. Don't over-engineer stuff, the simpler solution is often superior to the full-featured solution. And often you should ask yourself: do I really need this features currently to show some progresS? Shouldn't I not rather post-pone it?
However, given that at large organizations updates and deployments can easily become political issues, it's a good habit to deploy often. That makes your life easier when trying to deploy new changes because those who are watching or performing the deployments get used to it - and the errors occuring during such deployments.
Samsung may be exceptional, although I doubt their current success is long-term. HTC's success, eventhough it is in absolute numbers smaller than Samsung's, is way larger in relative numbers. Samsung was popular before Android, HTC was when Android was released just a "chinese noname brand".
To illustrate this even more: HTC was founded in 1997, Samsung was founded in 1938.
There a many examples of companies that are able to make lots of money with hypes, but most often after the hype is over, they stop earning that extra money. Even when the current smartphone hype is over, HTC earned something that Samsung already had: brand recognition.
However those numbers are not everything. What counts is whether customers buy products or not. There are plenty of examples of successful mass products that were sold too cheap. For instance Microsoft's X-Box, they sold it much under price. You might list that under marketing costs. Their strategy however paied off, now they are a big player in the game device market.
Of course Google spend lots of money into Android, we don't want to imagine what all this patent crap and marketing costs. Android is however the predominant mobile platform and HTC its biggest vendor. (With reference devices I mean the actual devices that were supposed to be used by developers.)
Samsung is without question in a nice position but they are replacable, they are a big brand and they have a lot to loose. HTC appeared out of nowhere and is now one of the biggest players in the smartphone market. Just ask yourself who the real profit makers are.
Samsung is doing short-term profit. You know why? Because people don't by Samsung devices, they buy Android devices. It's not Apple vs Samsung vs HTC, it's iOS vs Android.
Going back to the actual topic: who cares what processor is inside an Android? Only the CPU manufacturers. The customers and the assemblers just care about software support and performance.
In fact Blackberry is the last survivor of the old cellphone world. (EDIT: And Samsung of course, but they are just copying Apple stuff and get sued for it.)
The only ones having profit from Android are Google and HTC. Google because they created the system and run the App Store. HTC because they manufacture the reference devices and because they are cheaper than the rest.
Wake up mates, open source destroys the old business models.
However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.
I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.
But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.
Great when building but it sucks when debugging and maintaining.
That's also my impression and a reason why MySQL is a great DB for ORM-driven Apps.
However, once you know the steps necessary to setup a postgres server, it's a piece of cake. In fact it's even fun because Postgres is a software that comes in pretty much the same packaging in every version. And I can even top that: with pgAdmin it has a powerful, consistent and stable tool to manage databases. (MySQL seems to be miles away from that)
I think the impression that Postgres is more difficult than MySQL roots in the fact that it's more difficult to install at home. (Why so many installation steps? MySQL is basically just installing the package, changing pw and done?)
I worked around 2 years with Postgres as a developer and I loved it. Very stable, very solid, many features and no surprises.
MySQL on the contrary seems like a toy db, at least when you want to do a lot of relationship stuff with foreign keys etc. It feels really awkward that outer white-spaces have no meaning, there is no boolean type and that the admin tools out there seem to be really immature.
Having to work since nearly two years with MySQL, I find it still painful. If you don't store Petabytes of data and don't use it for a highly frequented website, Postgres is probably your choice.