I am trying to move to your set-up, from my Web 3.0 fanciness.

The 1984 Mac was my first computer, with all its GUI wizardry. I got into programming from the top down, HTML first, then PHP and SQL. My strength is user interface design (although I'm mastering databases more and more and loving it).

The command line is text. But what you forget is that most GUI's are also text, just with a fancy box around it.

The GUI's for n00bs, the command line for l33ts. Seriously. The whole attraction of the GUI is that you can discover how it works by clicking around, by reading the menu choices, etc. You can't do that with the command line. Your chances of happening upon the right command by trying different key combinations are practically zero. There's simply no substitute for reading --- either the man page or googling it.

But the advantage of the command line is that, once you've learned it, you work faster. You have great power at your fingertips. Chances are you can do more things, faster, than even a power user of a GUI.

To ram home the idea that I was not predisposed to favor the command line, before I even did HTML I was into graphic arts. My college major was film production. But I can draw a parallel between the command line and professional cameras. At first blush, professional video equipment is a step back. It's bulkier, with fewer niceties. There is no professional camera with autofocus. They all prefer manual-focus lenses. Why? Because after a few weeks of practice you can manually focus faster and more accurately (and more artistically) than any autofocus system.

This is kind of a bad example because digital photography has made everyone, even professionals, buy new equipment. But back, say, in the 90's, when your choices were film or film, professional photographers often held onto --- and preferred --- a Hasselblad from the 1960s. Little more than a box that pulled film. But it did it reliably and simply, and everyone knows that the difference is in the operator (and great lenses don't hurt, manual focus of course).

While I like science fiction, I don't like this law:

1. Onerous, cluttersome. The United States has too many laws. Do politicians feel insignificant if they don't make them? Maybe they need to adopt the mindset of good programmers and take pleasure in refactoring the legal code down to a smaller, more elegant set.

2. Counterproductive. As said by others, making people read something has no guarantee of making them like it. In fact, they'll like it less. If he were really clever, he would outlaw science fiction. Then teens would want to read it.

3. Defiling. Art does not exist to advance the industrial usefulness of its citizens. It cheapens a culture if art is appreciated for things like like better factories, cars, and drugs. Hey, this does sound like 1984!

While it would be bad to have many standards (like HTML, MS-ML, ORACLE-ML, etc.) it's good to have many implementations of that standard (WebKit, Gecko, Blink).

The ability to "delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat" is justification alone to fork the project. Another good reason from the blog is the fragile workarounds for old APIs:

Our current networking code in WebKit is limited by old Mac WebKit API obligations which cannot be changed. Chromium has worked around some of these limitations over the years, but these work-arounds have proven fragile and have long been a source of bugs.

I think Google invented GMail, Calendar, and even Chromebooks for its own employees, to simplify its own IT and also to lean less on competitors like Microsoft.

Now that they can sell it to the rest of the world, great, but if those products never made any money, they still would be saving Google money or at least headaches. My company uses Microsoft Office and I daily envy users of Google Apps for email, chat, etc.

From the summary:

Vocational schools and training programs are unpopular because they suffer from a low statue of for people from unsuccessful, poor, or peasant backgrounds.

Can anyone tell me what this sentence means?

Until you work with . . . you have no basis for . . .

If someone else goes through something and writes about it, and I read it, is that really no basis for me to believe what they believe?

If so, then why did you bother to tell me about how it was for you?

Jobs got engineers to do really good work. That was his contribution to society.

He lacked the technical interest to make anything on his own. No product from Apple ever could be called new. But then again I believe the same applies to any product from any company. The distinguishing characteristic of Apple and reason for its success was not creativity but flawless execution. And again, the same could be said for Google and most successful people or companies.

Again, the reason for Apple's success was flawless execution. This execution was by the hands of the engineers, not Jobs. However, Jobs was the one who gave them the room --- and whip --- to do it.

Almost every day.

But we are a team of two, working on a private company intranet.

I suggest you read Getting Real.

Programmers avoid writing documentation, because documentation is hard. They just got done working, working to write the program, and that was hard work. Now it is time to do the job all over again, in a different language: English. Someone may say the program was harder. I say, only slightly.

As many have said before, good documentation summarizes not only what the program does, but why. The why part is new. You didn't have to program the why part, just the what part. The computer doesn't care why. So you didn't have to tell it. But the why part helps humans hoping to understand your program immensely. Maybe because once they know your intention, they can guess your method, and so the program reads faster.

Anyway, that's why writing can be hard, even though you just wrote the program. Writing is hard because before you can write clearly about something, you first have to think clearly about it. And while writing the program, much of what and why you were programming was half-known to your mind, the rest in your gut or subconcious.

As stated in one of the highest-rated books about writing, On Writing Well, by William Zinsser:

Thinking clearly is a conscious act that writers must force on themselves, as if they were working on any other project that requires logic: making a shopping list or doing an algebra problem. Good writing doesn't come naturally, though most people seem to think it does. Professional writers are constantly bearded by people who say they'd like to "try a little writing sometime" --- meaning when they retire from their real profession, like insurance or real estate, which is hard. Or they say, "I could write a book about that." I doubt it.

Writing is hard work. A clear sentence is no accident. Very few sentences come out right the first time, or even the third time. Remember this in moments of despair. If you find that writing is hard, it's because it is hard.

Let the reader be warned that the two articles linked to from the summary are a gushing review by a Mozilla employee and an interview with the Mozilla CTO.

Even so, how many operating systems announced lately are saying that their API is basically HTML, CSS, or JavaScript? Google Chrome OS, Tizen, node.js, Blackberry 10 (sort of at least?), Windows 8 Metro, and now Firefox OS.

DISCLAIMER: I am a web programmer. (And right now, I'm happy to be one.)

Standard response to the myriad complaints about having to use JavaScript: JavaScript, as a language, is nice. Its history is tainted by incomplete browser implementations, namely Microsoft's. Also, its low level of entry flooded the web with really bad examples. If you really want to learn JavaScript, read JavaScript: The Definitive Guide or JavaScript: The Good Parts.

Yes, "post-PC world" is true only for the world of consumer computing, not professional computing.

In the beginning, all computers were professional. Nobody used a computer for fun (unless you thought programming was fun).

Then, in the PC explosion in the 80s, computers became fun for everyone --- but still in a handicapped way. You had to sit at a desk and use a keyboard and mouse to have that fun.

Now, you can easily plop on the couch or sit in a cafe or just step outside on break.

But yeah, forcing programmers, accountants, and scientists to use phones and tablets would be a step backward for them.

To me, JSON very interesting. I don't know how exactly I'll use it, but it combines all that's great about PostgreSQL with some of what was interesting about CouchDB and other projects like it.

Mainly, one-to-many relationships may be easier. Usually, they are two separate select statements. For example, one to get the article, another to get the comments. Then you patch it all together in PHP, or whatever middle language you're using. With JSON support, that could be a single SELECT, crammed up in JSON, which you then uncram with a single json_decode function call in PHP, which would yield nice nested arrays.

PostgreSQL replication is new (revision 9.1) so there may be little out there (Yes, there was replication, but with additional software, like Slony).

I'm in the weird position of having used PostgreSQL mainly --- for seven years, writing dozens of applications --- but never MySQL. I've also used --- out of necessity only --- Microsoft SQL, Oracle, and Ingres, and PostgreSQL is much better. Just from a programming point of view, the syntax is, in my mind, simpler yet more powerful --- more ANSI-SQL-compliant, too, I've heard.

Anyway, the point is, I've never used anything I like more. I adore PostgreSQL. It's so powerful. So many useful datatypes, functions, syntax. Not to mention it's ACIDity.

To your question, though --- are there any good books to help a MySQLite move to PostgreSQL? Not that I've come across. But then again, I haven't found any good PostgreSQL books --- or even, for that matter, very well-written SQL books, period. They all are stupefyingly boring --- but I got what I could out of them.

Actually, PostgreSQL's documentation is not that bad. In particular, try sections I, II, V, VI, and III, in that order. Skip anything that bores you at first. You can always come back. Honestly, there can't be that much of a learning curve for you, coming from MySQL.