I agree that Rails is a fad. But touting PHP as better is... odd.

Never said PHP was good.
But PHP *is* better - in more ways than one. If anything, PHPs badness is its advantage.

Rails and the Ruby team try to do everthing right - that's why they get stuck in layer and layers of package management, mandatory deployment automation, to many options, crummy documentation and constant breakage, dependancy hell, etc.

It takes minutes to get to real work on the app layer in PHP, days in Rails/Ruby. I can download the newest Zip of Wordpress and have a site running in 30 minutes. Yes, WPs architecture is bizar and beyond sanity, its ERD is a crime against humanity, but it works! Same with Joomla, Drupal and the lot. ... Not seeing anything of that magnitude coming out of the Rails community, not in the past, not in the future.

Yet the PHP people had Frameworks up and running in no time. CakePHP is an official Rails clone in PHP - and by now way more stable and consistent. Symfony, Zend and Flow are all three Frameworks that tout the newest and bravest of programming paradigms and just as easy to deploy and set up as any old PHP WebCMS. Meantime Rails is still navel-gazing. I doubt it will maintain its critical mass. If anything JavaScript all-over (Client- and Serverside) is coming with Node.js. If anything, that will touple the PHP reign - allthough I'm not holding my breath on that one - for one, Node.js is callback hell for large non-trivial applications.

David Heinemeier Hansson was sick of PHP, found Ruby, and invented Rails in 2004. No mention is made of him toying with Python. I think that if he had found Python that he would have liked it just as much. Django had not come out though.

I guess that he did the best he could with what he had, but I wonder if he would he would have just switched from PHP to Django had he started five years later.

The Rails crew knows the Django crew and vice-versa from the very beginning. They're basically drinking-buddies.
Rails simply was the favourite scripting language inside 37 Signals (DHHs favourite PL to be percise), so they developed their internal Basecamp Tool with it.
And built Rails as a foundation for that.

Basecamp became so popular with 37 Signals customers, they decided to turn it into a service.

Rails never had 'steam'. (I supose you mean something else than that digi-distro-channel by Valve)

Rails was and is a fad - plain and simple.

Every haphazard PHP project runs circles around it - for the simple fact that deploying PHP is dead simple, whereas with Rails it's a major PITA. Rails was discovered and hijacked/promoted by the Java community - and while they were all happy and gleeful about the lightweight convention-over-configuration approach they didn't know until then - the Rails & Ruby community bloated Rails beyond repair big-time-Java-style with libs, extensions, mandatory deployment systems that only a very small minority really needs, etc. Rails ran into walls in the real world and the abysmal arrogance of its community scared n00bs away.

The truth is, nobody needs rails. PHP and its big frameworks are faster and easyer to develop for, both PHPs and Pythons communities are way more n00by friendly and for people who need something big, easy and scalable there's projects like Plone (Python) or Typo3 Neos (PHP) for massive non-trivial installments, each with hundreds of active developers to back them.

The only thing that Rails had going for it was a website that didn't look like shit - back in a time when most FOSS websites mostly *did* look like shit - and the brand-new concept of screencasts to show of scaffolding and code-generation. That has changed thankfully, throughout the FOSS community. Scaffolding - definitely not a first with Rails - is now well know as a concept and commonplace. And the FOSS projects are finally aware that marketing, including websites that don't suck, is important. That's the overall improvement that Rails brought along.

But right now Rails as a FW is way to bloated, unwieldy and buggy to be of any use for a web-project beyond enthusiasts fiddling with it. I have yet to get a Rails environment running on my laptop for local development. With PHP its download MAMP, XAMPP or "apt-get install mod-php" and start progging.

So, yeah, no steam, only hot air.
And, yes, from what I can tell, the hypes been over since about 2 years.

My 2 cents.

In private powered transport, cars aren't the most expesive element anymore. Unjamed roads and especially parking space are. In Europe at least.

So, yes, if we'd all take a step back and turn on our brain, no one would want to own a car, they'd rather own the right to use a reservationable parking space. Cars would be used on-demand.As they are in the car-sharing offerings poping up all over Europe - even in Germany! German automotive manufacturers actually are scratching their heads, because there is a whole generation growing up in Germany just now that simply isn't interested in buying cars.

Our cities are absolutely packed with them. ... Germans spend 4.7 Billion man-hours per year in traffic jams.
So, yes, there are tons of insentives to move the burden of ownership somewhere else, away from the private owner.

There's probably some truth to that.
Three possible explainations:

1) I could imagine that overall presence of higher education is more dense in Europe than in the US.

2) Right now, life in general probalby sucks more in the US than in central/western Europe, hence the need for more distraction.

3) The US is used to quick sensations in media due to their TV history. In Europe the viewing habits are more ... 'sophisticated' ... although they have degenerated massively since the 80ies. Even prime news today is unbearably stupid and dumbed-down compared to two decades ago.

Small? Specialize and get billing, taxes, legal and ERP covered. Legal and taxes are other people, billing an ERP can be done with online tools like FreshBooks or small to midsized softwarepackages like Lexware.

What practices you need is up to you - especially if you code alone.
It also depends on the code you write. If it's just custom ABAP scripting for a handful of clients at a time, point and click testing and a few manually checked testpositions ought to be enough.
If you want to deliver software to a wide range of customers, perhaps even online, with demo-versions and stuff you *have* to have your pipeline standing, even and especially if you are alone. You want to be able to compile and deploy a hotfix wih a mouseclick.

Ask yourself: if the worst possible szenario happens with my software, will I be able to fix it inmediatel? If the answer is yes, with a few night-shifts and my leet Google searching skill I ought to manage somehow - that's OK. If the answer is no, compiling for XYZ takes days of time each time around - then you're doing it wrong and need to automate your process (more).

As for the business itself: Specialize in a field and a subset of that. There is no other way you can keep up with the big boys as a small shop. ERP, Web, Embedded, DB, etc. They all have their ups and downs and each have countless subcategories you can specialize in. Do it! Do not look left or right, unless you don't have any customers in the current field.

Good luck!

You people talk about terraforming mars or venus as if that were so easy.

Newsflash: Mars and Venus are very far away. Like, I mean, enormously freaking huge distances.

It took rosetta 10 years to rendevous with a comet that's basically crossing through earths nearest neighborhood. And that was a satellite the size of a car. And it did not have to transport and sustain humans and their life-requirements.

Until significant advancemens in getting stuff to orbit, massive advancements in material and propulsion technology and massive advancements in synthesizing materials, food, air and water have come by, we're pretty much stuck on this planet. If these advancements don't come, then we're stuck here for ever. We might aswell learn to behave that way.

Bottom line:
If humanity is to dumb to stop itself from killing itself on this planet, it has nothing lost on some other planet. That's my opinion anyway.

If we're talking about the kind of hacks you'd normaly think of when thinking of cars that would probably be some 2-3 decade old ex-soviet military car. In a pinch you can repair those with a paperclip. Some of them also have awesome features. I've heard of a transporter that can deflate and inflate its tires... while driving! They used that feature to adjust the tires to the ground the transporter would pass over. More traction in snow and sand and stuff like that.

An old us-army jeep probably is pretty hackable aswell. As goes for dune-buggies and other kit-cars.

As for hackable electronics in cars - I'd rather add those myself.

It's not that there are not enough viable alternatives to Overlord Google.

This is a spider.

Awesome specs, looks good, cheap price. This is trés cool. I have been toying around with the idea of getting a Huawei or Asus Cheapo Tablet as a new one, but I think I'll wait until this ones out and take a look at it. Like the Jolla Phone too - but my HTC Desire HD is still holding up, so I'll pass for now.

Systemd appears to me like the Dolphin of init. Dolphin had the clear mission: To be simple to use. They were willing to ditch the superiour Konqueror for it. OK, if for them one mission statement weighs enough to justify that, go right ahead. I think I'd still prefer Konqueror allthough I couldn't say if I'd be bothered to install it if presented with Dolphin as a default. Same with Systemd vs. init.

I personally am not sure if this thing turns out well. It all comes down to how good the systemd camp is at offering incentives to move to it and how well they develop. If the entire thing in the end turns out better than init and has less problems the bickering will stop. If not, Debian will switch back eventually and the systemd camp will be burnt for a long time.

Errrm, what does *she* want to do? Make a 3D thingie fly around and shoot hearts at ponies with it? Then Unity 3D is the way to go. Blender will be more useful to her aswell. There are courses for that. Does she want to draw cool graphics? That's easy: Processing. Does she want to build her own robot? Arduino. ... And so on.

Teaching her Eclipse sounds more like torture to me. But then again, maybe you have a fledgling business programmer here - who knows?

At the age of nine focussing on a neat useful interpreted PL probably is the best. Python, C# (Unity 3D) or Processing (Processing and Arduino) are good choices. JavaScript and Chromeexperiments if she's into stuff that comes out of the Intarweb.

I like the fact that your daughter is into this sort of thing. I wish the mother of mine had supported me more/not prevented me in trying to introduce my daughter to programming. All the best to both of you.

My understanding is that it is still just HTML, but the way some people describe it, it sounds like the second coming of C.

It is the next coming of C.

The moment the portable devices became web capable - and the web back then already was where most people spent their time when computing - was when the iPhone was introduced. A full-blown non-sucking modern browser on a fully mobile pocket device that the entire world wanted. That was a first. And Steve Jobs said: No,it won't run flash or any other VM. Period.

This eventually killed Flash and pushed *everyone* in the rich client field back to Ajax, HTML and CSS. At the same time browsers became more performant, Google open sourced their acqired V8 engine and moved every thinkable app into the cloud.

FFW to today, 7 years Anno iPhone, and we have a bazillion online devices (classic Desktops, laptops, netbooks/ultrabooks, tablets and smartphones) with nothing but am HTML5 browser that runs JavaScript in common. Google will defend the(ir) web with all their might and they plan to bring the second half of humanity online - with the help of Huawei, Xiaoming and friends. And they're already doing it with a notable pace.
And the devices doing this are so powerfull, they'd run circles around an 80ies liquid nitro cooled Supercomputer. Hence rich clients in pure open standard web technologies is where *everything* that matters in utility and end-user computing today happens. That's a simple fact. Performance be damned, we have 4-8 cores running at 1.x Ghz on even the cheapest of mobile devices. So, yeah, every advancement in the field is a big deal. Web Components, for instance, are a huge step forward. (Google for "Polymer")

And why are web based rich client apps such a big deal, you ask?

From the top of my head:
No deployment, continuous integration, port 80 is always open, no fussing with customers inhouse IT, runs on everything that runs on electricity and has a screen with zero porting. And probably then some reasons.

(Sidenote: That's why we today even have tons of SCADA equipment that runs mission-critical stuff accesible to every highschool kid who can dig up the default password.)

Bottom line:
You got it just right: The web and HTML5 centric frontends actually are the next coming of C.

Good UI & UX design is hard. Really hard. It's one thing doing a cleanroom design of UX, an entirely other doing it for real life and various screen-sizes - preferably responsive. It's like with the code itself. In dev it will run and work, but beware of post-deployment if you haven't tested your stuff in every possible situation. I did tons of this stuff with Flash back in the day, and even with Flashs superiour visual & direct manupilation workplace and solid cross-plattform compatilibilty it was hard. I remember doing the UI for a flash-based MMO at a gamepublisher some years ago. We worked for months just to get the pageflow of character configuration and setup right. Video-based UX testing with usergroups and all. We'd discuss how and why the rail of a slider would look like X and not like Y.
Now, with HTML5, CSS and JS and all the screen sizes and mouse vs. tough it's by orders of magnitude harder.

It does not get that much easyer when you go native with Android or iOS SDK. You're app and your workflow will always have something significant that a good UI designer would like to highlight or help out in being intuitively usable - without destroying the page- and workflow the user is used to with other applications. It's a really tough job and each and every time it's like jumping off a cliff and not knowing if the parachute will deploy.

I'm one of the rare cases that's actually reasonably good at both - I have various diplomas in art and design and 28 years of programming experience, but I honestly couldn't tell which is harder. Basically both require very hard work if you want to do it well. Good UI is also where shitty backends are exposed. If the backend can't deliver what the user needs, no UX in the world will fix it. A significant portion of the logic is having the computer do what the enduser needs, fast and efficient. If UX and backend development don't work together or one of them doesn't understand the needs of the other, it almost instantly shows in a project. That's the classic difference between Apple and MS, btw. Steve Jobs basically nailed it in this rare direct comparsion comment.

Bottom line: The apps shown in this rundown on lollypop are the best you can get with boilerplate UX. The article basically is right, good UX looks different.