How to give sudo privileges

First, you must be logged in as root. Then, open up the sudoers file (I use nano because I'm lazy. vi is the editor of choice of people that prefer overkill when adding a single line of text):

# nano /etc/sudoers

Here's an example of a simple /etc/sudoers file that will give "justin" access to all root commands.

# User privilege specification
root ALL=(ALL) ALL
justin ALL=(ALL) ALL

That's sudo access in its entirety. For more detailed instruction, try http://www.gratisoft.us/sudo/

How to move records between mysql databases

Moving a db record from on database to the same table in another database is simple:


REPLACE INTO new_database.tableName SELECT * FROM old_database.tableName


If you need to get a bit more complex and extract only certain records from one table and move them to another database:


REPLACE INTO new_database.tableName
SELECT * FROM old_database.tableName WHERE id in (1,33,223,555 ...)


Or, you can do a subselect, to get child records from a foreign key


REPLACE INTO new_database.tableName
SELECT * FROM old_database.tableName WHERE your_foreign_key_column in (1,33,223,555 ...)


One level deeper


REPLACE INTO new_database.tableName
SELECT * FROM old_database.tableName WHERE your_foreign_key_column in
(SELECT id FROM old_database.foreign_tableName WHERE id=222)


I think I had one of those, actually

There's important, and then there's Important

At our dev meeting last week, we decided to talk about the goals for Q2. Yes, it's already Q2 and yes, you generally have your quarterly goals set out before you actually start on the quarter. But code happens, and late goals are better than no goals at all.

We started brainstorming specific goals for the quarter. There were the usual suspects: refactor the ageing DAO layer, maybe replace the error handler that catches exceptions, then throws them into a black hole without any further reporting, and a team building exercise to San Francisco.

There were also a couple a touchy-feely issues: perhaps we should develop a development team mission statement that clearly identifies who we are, how we code, and why we code. Perhaps we should document the sprawling database, and the actually get the meaning of the more obscure column names (the meaning p_has_itern_pparker just isn't jumping out at us).

After we brainstormed a list, we divided them into the four quadrants made so famous by the book The Seven Habits of Highly Effective People (None Of Which Are In This Room Apparently). Each goal was either in the first quadrant (Important and Urgent), the second quadrant (Important, Not Urgent), the third quadrant (Urgent, Not Important) or the fourth quadrant (Not Urgent of Important).

As it turns out, every single task related to improving code, fixing bugs was considered either Important and Urgent, or just Important. Everything else was considered Unimportant.

I think this is the biggest trap development teams fall into. If it isn't a measurable improvement to the code base, then it isn't as important. That's why so few development teams have anything more than just an organized task management system.

This is why Red Mine is so popular these days. It excels at managing tasks, and, even more important, excels at managing busywork.  Exhibit A: the wiki. I have yet to find a Red Mine wiki that wasn't built like a slum in Rio. Navigating a Red Mine wiki is a lot like trying to trace the Amazon back to its source. Some links take you down rabbit holes. Some links take you to a suddenly unexpected table of contents. The only thing Red Mine seems to guarantee is that it will capture your information forever, and hide it from everyone else, lest they try to actually understand it or, worse, fix it.

How many dev teams have organised architectural documents? Few. How many have several dozen incomplete pages, littered with printouts of sql statements, and half-finished tables describing what the columns do? A few more. How many have nothing? The rest.

How many dev teams have mission statements, or at least a organised -- there's that word again -- statement of why the dev team adheres to a set of common principles? Practically none. Is it necessary? Of course. You may be able to function with it, but you're highly unlikely to function at an elite level without it.

If the only thing important is reducing the bug count, improving the code execution, and completing your tasks, the dev team is nothing that an artificially intelligent code writing routing (patent pending) couldn't do. Thank god we don't have artificially intelligent code writing systems. But we do have overseas developers, and they work for a third of what you cost. You better be three times as productive if your only a code monkey.

In the end, it was decided that the number one priority of the team, for the entire quarter, was to reduct the time it takes to enter a ticket in Red Mine, and move the status from New all the way through to Complete. So there you have it. We have our priorities in complete order.

Wrap all your sensitive computer equipment in bubble wrap!

Solar activity is expected to peak around 2013, and many scientists are warning that we could be in for a hell of a time. Most solar flares cause minor or no problems with satellites and power grids. But a major storm could be disastrous.

Like the Carrington Event.

Back in 1859, there were no satellites or delicate chip technologies to wring their hands in angst about. So what could a solar storm do? On September 1, as viewed and reported by Richard Carrington, it did a lot more than you might think.  Telegraph offices across the world got whacked by the flare. Some telegraph operators even reported electric shocks and, in multiple cases, claim paper caught fire.

Now the NRC says that a similar solar storm could cause up to $2 trillion dollars in damage. In a best case scenario. Some scientists are giving better than even odds that a Carrington Event type of storm is going to occur. If it does, you better hope you're wearing rubber soles. And stay away from telegraph offices.