This might be the appropriate place to mention the venerable Unix Power Tools.
It goes through most of the common Unix commands (including Bash, but also sort, uniq, awk, sed, etc.). It teaches you about redirection and piping, customizing your shell prompt, xterms, X, remote X, Unix file times and permissions, find/exec, diff, head/tail, grep, vi, emacs, jobs, cron, time, regexes, sed, bash scripting, tar, rcs/cvs, perl/python,/dev, symlinks, tty's, ssh, users/groups.
In short, everything you ought to know before opening a root shell.
People are divided up into all sorts of races/subraces/cultures/subcultures. As humanity has developed people have "specialized" into straight hair/curly hair/kinky hair, big/small noses, different colors, etc. But all evidence available so far seems to indicate a common genetic (and now linguistic) origin of man.
Hopefully, we'll be able to get our act together and stop blowing each other up (and also unite against a common enemy - government/power elites).
1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.
4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP
5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.
6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.
7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).
8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.
9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.
(I assume we're using "corporation" as shorthand for "large corporation", otherwise many self-employeed people will also be counted in "corporations".)
There's a difference between a feature which has been tuned for decades, and a feature tacked on by a dev team which doesn't really even think they are necessary.
It's like a compiler which said, "Well, no one really uses STL, so we don't really need to implement it." Even if they come up with an implementation years later, it's a level of trust issue.
That's different from Mozilla/tabs in 2 ways: 1) FF simply did not have tabs. They didn't actively dismiss them as unneeded, like Monty did with FKs. 2) FF is just consumer software. If it crashes, whatever, reload it. Database servers are a different thing.
The fact that Monty would even say something like that shows a fundamental disconnect in philosophy.
I'd be just as wary of accepting promises of "bank-grade" software from MySQL as I would be of a rapid application stack from Oracle (proper).
Maybe. But that's basically what I'm talking about.
When you delete a row in one table, how can you know you're not leaving orphans? Or, on the other hand, how can you ensure you're not deleting related records of a row in another table? FKs.
Databases which have advanced functionality also have the ability run as fast as they need to (i.e., as fast as they can without risking data). And we're talking about people's bank accounts, not status updates.
1) I'm referring to the general attitude which MySQL and fans used to have of "who needs foreign keys" back when it didn't have them.
2) FKs are only enforced with InnoDB tables, which people who are using MySQL for the speed don't use. Sure, you could use them, but why use MySQL then?
MySQL is great for general web purposes. I'd say MongoDB is fine for much web data, and it makes MySQL look like a fuddy-duddy. But not for banks.
AFAIK, Google doesn't replace their servers. If it fails, it fails. Hence the viability of this scheme.
This isn't for co-loc type data centers where you're buying a $20000 dream machine and lovingly installing it in a cage, and coming by to visit it once in a while with gifts (RAM, HDD) in hand.
It's for set it and forget it cloud-based, commodity data centers.
Excellent brainstorming... Farmville servers will replace nuclear plants for the purpose of boiling water to spin turbines. Ingenious. (Saying this half sarcastically, yet some marketroid will actually run with it.)
Rant on, bro. I'm with you. We predict this bubble is going to burst. We wouldn't care if this bubble were to burst. We probably might even want this bubble to burst.
Yet, we might have to face the awful reality of it not bursting (in any reasonable time period). Then it's our brains which will be bursting.
Slashdot Mirror
Even if they can't monetize it in the short term, OpenOffice is admitted (if in private) by MS to be a threat.
MS Office is the way that Microsoft enforces it's synergy/monopoly in the "enterprise": office apps + server apps.
Oracle needs to have a counterstory to MS Office easily accessing SQL Server data. It's not enough to just focus on Oracle DB.
This might be the appropriate place to mention the venerable Unix Power Tools.
It goes through most of the common Unix commands (including Bash, but also sort, uniq, awk, sed, etc.). It teaches you about redirection and piping, customizing your shell prompt, xterms, X, remote X, Unix file times and permissions, find/exec, diff, head/tail, grep, vi, emacs, jobs, cron, time, regexes, sed, bash scripting, tar, rcs/cvs, perl/python, /dev, symlinks, tty's, ssh, users/groups.
In short, everything you ought to know before opening a root shell.
It's written in a funny/witty (for geeks) manner.
Just going out on a limb here, but I don't suppose they use distilled water for the steam, do they?
What about dissolved minerals? Don't they gum up the works after a while?
And oxidation?
It's awesome that they are (apparently) directly generating electricity. Much better than the quaint method of boiling water to turn turbines.
OK, this'll sound corny, but here goes:
People are divided up into all sorts of races/subraces/cultures/subcultures. As humanity has developed people have "specialized" into straight hair/curly hair/kinky hair, big/small noses, different colors, etc. But all evidence available so far seems to indicate a common genetic (and now linguistic) origin of man.
Hopefully, we'll be able to get our act together and stop blowing each other up (and also unite against a common enemy - government/power elites).
>This makes me want to find a new continent and set up a country where the citizens are free
Sealand
This is really strange that they're coming up with good stuff like this right before going away.
Sorry, just deferring to the new "received wisdom".
I mean, it was just a few years ago that using svn meant you're trying new things (in place of CVS).
By the way, have you had any problems with git? Also see discussion above. I haven't waded into the waters yet.
It won't work without a forward slash. Forward slashes counteract radiactivity:
rm -rf / radioactivity
on how exactly they were going to remove radioactivity with a shell, and if so, which one ?
Might one downside be that no single repository has the full history of all possible paths that all devs took, and failed/not ready experiments?
Might not matter in free/open source dev, but it could for a company that wants a record of what approaches have already been tried.
Also, any "gotchas" for folks coming from the venerable cvs/svn background?
1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.
2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.
3. Use Google Docs and Slideshare to share documents.
4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP
5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.
6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.
7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).
8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.
9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.
10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.
Isn't having the whole repository, including all past changes, cached on your local machine, a drag? As opposed to svn?
Small to medium companies provide more jobs than corporations.
http://www.census.gov/epcd/www/smallbus.html
(I assume we're using "corporation" as shorthand for "large corporation", otherwise many self-employeed people will also be counted in "corporations".)
There's a difference between a feature which has been tuned for decades, and a feature tacked on by a dev team which doesn't really even think they are necessary.
It's like a compiler which said, "Well, no one really uses STL, so we don't really need to implement it." Even if they come up with an implementation years later, it's a level of trust issue.
That's different from Mozilla/tabs in 2 ways: 1) FF simply did not have tabs. They didn't actively dismiss them as unneeded, like Monty did with FKs. 2) FF is just consumer software. If it crashes, whatever, reload it. Database servers are a different thing.
The fact that Monty would even say something like that shows a fundamental disconnect in philosophy.
I'd be just as wary of accepting promises of "bank-grade" software from MySQL as I would be of a rapid application stack from Oracle (proper).
Maybe. But that's basically what I'm talking about.
When you delete a row in one table, how can you know you're not leaving orphans? Or, on the other hand, how can you ensure you're not deleting related records of a row in another table? FKs.
Databases which have advanced functionality also have the ability run as fast as they need to (i.e., as fast as they can without risking data). And we're talking about people's bank accounts, not status updates.
Yeah, C# did the same thing too. E.g., super -> base.
As far as I'm concerned, if you're making a new language, just keep the old C/C# syntax, and try to reuse as many keywords as possible.
Wha?
The only thing the actual article mentions about hard drives is: "applying a coating to hard drives".
Applying a coating is hardly the same thing as encapsulating, and others have pointed out that hard drives aren't air-tight.
Granted, I later saw something about hard drives in the a page off the home page of the company doing this, but that page is not "the article".
When is someone going to propose a 3 strikes law for government agencies (FBI, local police, state troopers, DEA, whatever)?
3 instances of violating citizens' constitutional rights or rights to privacy of electronic data (email), and they're disconnected from the Internet.
That should put the "3 strikes" nonsense into context.
Yes, it does do foreign keys, but:
1) I'm referring to the general attitude which MySQL and fans used to have of "who needs foreign keys" back when it didn't have them.
2) FKs are only enforced with InnoDB tables, which people who are using MySQL for the speed don't use. Sure, you could use them, but why use MySQL then?
MySQL is great for general web purposes. I'd say MongoDB is fine for much web data, and it makes MySQL look like a fuddy-duddy. But not for banks.
You don't do maintenance. This is for when you have hundreds of servers of the same kind. If it fails, you start up another in its place.
AFAIK, Google doesn't replace their servers. If it fails, it fails. Hence the viability of this scheme.
This isn't for co-loc type data centers where you're buying a $20000 dream machine and lovingly installing it in a cage, and coming by to visit it once in a while with gifts (RAM, HDD) in hand.
It's for set it and forget it cloud-based, commodity data centers.
It's quite interesting that your link mentions mineral oil as irritant to skin, yet it's sold as "baby oil".
Excellent brainstorming ... Farmville servers will replace nuclear plants for the purpose of boiling water to spin turbines. Ingenious. (Saying this half sarcastically, yet some marketroid will actually run with it.)
Rant on, bro. I'm with you. We predict this bubble is going to burst. We wouldn't care if this bubble were to burst. We probably might even want this bubble to burst.
Yet, we might have to face the awful reality of it not bursting (in any reasonable time period). Then it's our brains which will be bursting.