Thursday, February 25, 2010

SQLA is the new community question-and-answer website devoted to SQL Anywhere that started Beta testing back on November 8, 2009.

SQLA is still in Beta, but it IS ready for more traffic now that The Really Big Obstacle has been overcome: We have backup!

(if anyone wants a copy of the XML dump of all SQLA content, just email me at breck.carter at gmail.com)

So... SQLA is ready for prime time!

Time to invite more people to participate.

But first... it's time for the administrator (that's me) to update the SQLA FAQ to reflect all the wonderful results from the past few weeks of experimentation with SQLA... the StackExchange software REALLY IS SO MUCH BETTER than the best NNTP client-server setup, the best bulletin board software, the best "threaded forum" websites.

Updating the FAQ will take a bit of time, mainly because SQLA is not StackOverflow... SQLA works by a completely different set of rules than StackOverflow.com... mostly FEWER rules, FEWER restrictions, MORE freedom to use the site effectively.

Hard to explain... that's another "to do" item for me, come up with a sales pitch.

In the meantime, if you want to know more about the people behind the StackExchange software that runs SQLA, where it came from, where it's going, this recent podcast from Joel Spolsky answers questions submitted by administrators who operate websites just like SQLA. And there's hundreds of them.

Who doesn't have an hour to listen to Joel Spolsky? Well, maybe you don't, so here are SOME of the high points (there's lots more, including stuff I did not know like the StackExchange software is a separate fork of StackOverflow, and it's StackOverflow going the venture capital route, not StackExchange):

Joel sits down with the Stack Exchange team, who are working on the hosted version of Stack Overflow at the Fog Creek offices in New York City.

Meet the Stack Exchange team -- David Fullerton, Aaron Maenpaa, and Emmett Nicholas.

For Stack Exchange sites that have a smaller community, Stack Exchanges may email users more aggressively, to invite users to answer less trafficked SE questions. Joel proposes that weekly roll-up emails might work well on smaller Stack Exchange sites.

Stack Exchange is a hosted service; it's currently running on 2.5 servers and soon a third.

Joel blogged about Stack Overflow looking for venture capital -- that should not affect Stack Exchange. In any case, even if it did, you can use your own domain name which you take with you, and as mentioned above, you can export all your data. There should be competition, and smart competitors will support the Stack Overflow and Stack Exchange export formats.

Stack Exchange pricing is already at maximum, primarily to reduce demand to a level that the current SE team can support. It can only go down over time! It is definitely our goal to make it easier over time for everyone who wants a Stack Exchange site to have one. We're exploring a lot of possibilities including ad subsidized; it's also possible that larger corporate adoption of Stack Exchange may subsidize the smaller community sites as well.

Right now every Stack Exchange site has its own IIS website (even though they all share the same app pool), but that turns out to be not a great performance model for lots of small sites.

One of the Catch-22s of a Stack Exchange site is that fundamental actions like voting up and creating tags require reputation, but nobody has any reputation on a new site. The Stack Exchange team added a "bootstrap mode" which relaxes a lot of these requirements so you can get your site up and running.

David notes that a smooth admin / owner setup process is essential to the Stack Exchange service model. You also can't have a ghost town -- you need some questions bootstrapped into the system before you even show it to the broader public. This is analogous to the private invitation-only betas we did for Stack Overflow, Super User, and Server Fault.

If you'd like to provide additional feedback to the Stack Exchange team, we encourage you to visit Meta Stack Exchange and help us dogfood our own system.

Thursday, February 18, 2010

Join Sybase's technical experts who will showcase the latest releases of our industry leading development software. All seminars are free and run from 8.30am - 2pm local time (timing may vary slightly by location) with breakfast and lunch included. Each Seminar features a keynote presentation followed by your choice of tracks:

Monday, February 1, 2010

Caution: This is another fluff-piece just like "When did Google become perfect?"... it's not in the same league as deep-thought articles like, for example, those by Glenn Paulley and others... heck, it's not even in the same sport.

But sometimes shallow thinking is called for... like when you're faced with some bizarre computer problem that just won't go away when you wave a dead chicken over the keyboard. That's when "try rebooting" comes in to play.

I remember the first time I had reboot power over a computer... it was the mid-1980s, the computer was an IBM 3270 video controller, and the boss said "try turning it off and on" when all the dumb terminals in the office stopped working properly.

Prior to that, turning off "the computer" was a firing offense... there was a big red OFF button on the wall in the mainframe room, and if you pressed that button you had better be on fire... yourself... with no hope of personal survival.

Then came PCs, and rebooting became a regular ritual performed many times a day... folks didn't think anything of it. "Keep your config.sys and autoexec.bat small" was standard advice so rebooting would be fast. The application development life cycle was described as "edit, compile, test, reboot."

And then, fast forward to 2010, computers are much more reliable, you don't have to reboot every time you change a network setting or perform some other minor task, and once again folks are used to long periods of up-time.

Here's another piece of wisdom: "Don't forget what you already know." What you know is that rebooting is a powerful problem resolution technique, and if you don't have a clue about what's wrong then "try rebooting" should be one of the first things you consider.

Example: Norton Ghost crashes intermittently when doing a high-speed backup across TCP/IP to another computer, or via USB to an external disk drive: "Error EBAB03F1: Insufficient system resources exist to complete the requested service".

Solution: After such a crash try rebooting. Norton Ghost will now work... so far, 100% of the time. It took me months to realize "try rebooting" was the solution, and for more months "try rebooting" has proven to be the only reliable solution. Don't ask me about the CAT6 upgrade, the new router, the endless "system tuning" efforts... wasted time, wasted money.

Here's another example: If you install software using an InstallShield setup.exe, and something doesn't work right afterwards, try rebooting. This applies to SQL Anywhere. It even applies to a SQL Anywhere EBF. Something might have been "in use" when the setup ran and Windows is waiting for a reboot to finish overwriting the old thing with the new thing.

Yes, it's magic. So is waving a dead chicken over the keyboard. So is "try rebooting"... except it doesn't just make you feel better, it sometimes actually works.