Open Source
Free as in Free Beer too.
LAMP: Linux, Apache, MySQL and PHP. A pretty nice combination of technologies for easily building interactive and Database-backed Websites. I love the concept, its one that Microsoft didn't really captialize on with .NET 1.x. Sure, you had Windows as the OS, not free, but affordable for businesses. You also have IIS which is easy enough to configure and has improved considerable with the introduction of IIS6. And, yes, ASP.NET 1.x was most certainly a great web applicaiton platform. But where was the bit that that competed with MySQL? Well, that was MSDE. Enough said. Little wonder why there's been a lot of interest in SQL Server 2005 Express Edition.
But something about that offering just didn't make out the gate in time. Namely:
- Like the MSDE story, there wasn't a free GUI for working with yet. For better or worse, XM didn't make it, and SSMSEE wasn't ready at RTM. I'm glad they didn't hold up for it, but its still somewhat holding the ASP.NET 2.0 platform for going head-to-head with LAMP, IMHO.
- Towards the end of the development cycle of SQL Server 2005, the SQL Team decided that Express Edition really should support Reporting Services and Full-Text search. However, that decision was really made too late in the cycle to include them in the RTM. Microsoft said these features would be available with SP1.
And so they are. Mission almost accomplished. It turns out that a CTP version of SSMSEE is now available at [0], so you can start getting a feel for how tool will help you write great applications. Books On-Line has also been updated to reflect the changes in it. You can download that from [1]. You also download the first CTP for Express Edition with Advanced Services from [2].
I believe the March 2006 CTP version of SQL Server 2005 will show as 9.0.2040.0. Don't worry, it still runs with .NET FX 2.0.50727.42.
[0]: http://www.microsoft.com/downloads/details.aspx?familyid=82afbd59-57a4-455e-a2d6-1d4c98d40f6e&displaylang=en
[1]: http://www.microsoft.com/downloads/thankyou.aspx?familyId=19db0b42-a5b2-456f-9c5c-f295cdd58d7a&displayLang=en&oRef=http%3a%2f%2fwww.microsoft.com%2fsql%2fctp_sp1.mspx
[2]: http://www.microsoft.com/downloads/details.aspx?familyid=57856cdd-da9b-4ad0-9a8a-f193ae8410ad&displaylang=en
Oh, did I mention that if you want to win yourself $10,000 in the Made In Express contest, you can? Sounds like a heck of an opportunity for somebody not only write some really cool code but also put some green in bank.
Just in case you live under a rock (like I seem to have been doing recently), my DevelopMentor cohort Niels Berglund has shipped updated versions of his custom SqlClr Project and his GUI for Service Broker. Go check 'em out.
Sorry, I couldn't resist. And if you're a Perl Monger like me, you shouldn't either. SQL Server MVP Erland Sommarskog has just spun out MSSQL::OlleDB, a mod for working with MSSQL Server using OLE-DB (thus the name). There's a ton of documentation provided too, with examples.
Enjoy!
Yep, you can do that. Angel Saenz-Badillos has the details over here.
Spiffy!
Jeff Brand pretty much nails it dead on, at least as far as I'm concerned, on the OSDL offering to help explore Microsoft's porting of Office to Linux. More fluff than stuff indeed.
http://www.slickthought.net/bloglink.aspx?f78ca6a0-c59b-4fd7-955e-3191b1c1028b
That said, I wonder how Jeff would feel about the OSDL pushing for a comparsion of SharpDevelop and Mono vs. Visual Studio 2003? It might open a lot of eyes and its kind of too bad they haven't done it yet.
And if you wonder why, look at MonoDevelop. That'll be sweet. If it ever gets done.
I'm finally back to having fun, which for me means writing code. Went
to work at 3AM to tackle today's assignment: put together some scripts
to simplify the backup and restore process for a SQL Server database.
Since changing jobs, its seemed like ages since I've been so enthralled
with a problem that I'll bounced out of bed that early.
Being all about SQL Server 2005, I started by efforts in earnest and wrote many of backups and restores like this:
backup log @dbname
to disk = @logFileName
with checksum,stop_on_error...
restore database @dbName
from disk = @lastBackupName
with checksum,stop_on_error...
So you may be saying to yourself, self, what do CHECKSUM and STOP_ON_ERROR mean? Ah, these are new additions for SQL Server 2005 designed to make the backup and restore process a bit more reliable.
CHECKSUM looks at pages being backed up and validates them. It then
rolls these checksums into a checksum for the whole file for a
backup. If used with a restore, the checksums are compared after
operation as a validation of the restore. Page checksums are also
validated on restore. Of course, both the backup and the restore have
to be done with this option for that magic to full work. But when it
does work, you can pretty darned sure you have a high-fidelity restore
of that backup.
STOP_ON_ERROR does that it implies: when the first error occurs during
a backup or restore, that operation halts and throws an error. The
counterpoint to this option is CONTINUE_ON_ERROR. Note that
STOP_ON_ERROR is the default for both backups and restores (the duh
factor should be high on that,) and its pretty obvious what this means
during a restore. But there's some interesting interplay between
CHECKSUM and STOP_ON_ERROR for backups. If both of these options are
set for a given backup command, a backup will abort if and when a torn
page is detected or if a page checksum goes Pear-shapped for some
reason.
The practical upshot of this is that if you a database that's going bad
you, using the combination of CHECKSUM and STOP_ON_ERROR might save
from thinking you have a good backup when, in fact, you might not. And
it aborts the process strongly enough that you can capture it as an
event to go have an operator or DBA go look at to see what repairs they
can make before bigger problems come up to bite you.
Just be careful with this though, because the default for a backup is
to NOT compute these checksums -- you have to explicitly tell it to.
Also, there's no such thing as a free lunch -- computing these checksum
takes a bit longer for the backups. Be prepared for that.
And sure, 3AM is a bit early even for me to attack a task like this.
But then, I like being "back up" early in the morning... (sorry, I
couldn't help myself...)
As an Database geek, I've faced one problem over and over and over
again: How do I store Office Suite documents in a database in a useable
way. And by usable, I mean in such a way that I can easily query their
contents and reshape them into smaller chunks of knowledge. One of my
favorite examples of this is importing Word documents representing some
knowledge capture and needing to extract out their abstracts. The idea
is the abstract should give users enough information about the document
to decide if reading the whole document is likely to help them solve
the problem at hand. Of course, there's a number of ways of doing this,
but none of them really strike me as very user friendly. For example,
suppose you use some ASP.NET website to allow users to upload documents
and search them. You could, for example, require the user to enter (or
more likely, copy and paste) the abstract into a textbox and save that
as field in some database field. Then you could use either matching or
full-text searches on that column (or even the whole text of a
document, if you like) and render a list of results.
As the user of such a system, though, I'd prefer to just submit the
document and let some logic find the abstract and do what it needs to
with it. In other words, make me do as little as possible!
With the combination of Office 2003 and SQL Server 2005, I've cobbled
together workable solution. In the Word document template, I have a
style called "abstract" that users can apply to a section of document.
Users can then save their inherited documents as XML documents, which
they in turn upload. The upload is (of course) to a SQL Server 2005
instance. The document itself is saved to an XML typed column. That
allows me to use XQuery on those documents to pull out the abstract and
use that as I like. I demonstrated some of this at Code Camp II in
Boston last year.
Pretty cool, right? Kind of. There's a problem, though.
More correctly, its that Word 2003 wants to save, by default, to "Word Format" (a newer flavor of RTF, in a sense) instead of XML, and sometimes even the best users forget that they need
to save in XML instead of Word Native format or even older standard RTF
format. Naturally, my uploading page barks that the uploaded file isn't
XML and asks them go re-save. Fine, other than it irritates the user,
duplicates work and so on. But I don't have a good way around that
today.
But with Office.Next, it appears I will. Why? John Durant points us at the announcement of XML as the new native format for Word, Excel and FINALLY PowerPoint.
John said: "It's a watershed moment for Office programmability." True, but this goes way beyond programmability, I think. Its potentially just as much as a watershed for Knowledge Management Systems. Sure, we've had this ability with OpenOffice for a while, but I, for one, and glad to Microsoft -- which really owns the IW productivity suite space -- make this move.
Looks like I'll be shuffling my TechEd 2005 schedule around a bit...
I'm getting cranky today because I'm trying figure out the behavior of some code that's NIH but I have to support. I'm not having much luck because I can't reproduce the root error that's causing my error handling stuff to work right. Starting to get frustrated, I decided to take an actual lunch break and do something refreshing: read.
And what was at the top of my reading stack?
Test-Driven Development in Microsoft.NET.
Wow, I'm thinking reading the section on "Simple Design." If there is a trick to writing sustainable code -- and I'm not saying that there is -- this section just laid it out wonderfully, with my paraphrasing:
- Write code so that's appropriate to the folks who will be following behind you. Writing code that only can maintain isn't maintainable. Writing "guru code" only works for organzations that have them. Good Code isn't Moon in a Dewdrop, it should be Zen Mind, Beginners Mind.
- Write code that passes all the tests -- and have tests that "pass" when the code "fails as expected."
- Write code that communicates everything it needs to. That's much harder than it sounds because, as developers, we tend to assume a lot about what a person looking at the code knows about both the problem and technology domains. That's a problem for sustainable designs because the problem domain is much harder to grasp, and because of that, its much harder to document well. But frequently, mapping problem domain concepts to the code is only way to understand why somebody wrote what they did.
- Write the smallest amount of "decorative code" possible, ideally none. The book actually says "the smallest number of classes and methods" but I think it applies more generally. I'm bad at this because I tend to like to build code today anticipating future uses. But there's a different problem too: code that's written in a more complex way than the problem domain justifies. I recently got (rightfully) dinged in a code review for using an Interface pattern to a problem when its likely that we'll never really need more than just way to do the work at hand. That's a practice because it introduces unjustified complexity into understanding the code for the sake of making it fancier. Of course, if you don't push on things, you never learn them. Hard to decide how to balance that. On the database design side its very easy to go the extreme version of this with normalization. I can't tell you how many designs I've been part of that were either so overly normalized that they became nightmares to work with or so poorly normalized that they couldn't be sustained. Non-sustainable database designs create way more hard and expensive problems than they solve, of course. That said, code that seems decorative but actually helps the total appropriateness of the code is blessed indeed!
Now if more folks would just do that as opposed to "Just Glue It." Jeesh!
Speaking of TDD, Sam points us at TestDriven.net who offers a Studio add making it easier to actually use Nunit. Thanks!
I now resume my irrregular programming...
Lots of stuff to talk about from the Blogsphere but just one quick personal thing to talk about first: I had a really good talk with fellow SQL Server Geek and Omahan Luke Schollmeyer today. I had very similar conversation with Janell tonight. Not similar in content, but similar in my response to them: as long as you don't give up, as long as you remain confident that you will succeed and as long as you practice, practice and practice some more, you will succeed. I've long believed that people don't fail at tasks as much as they fail to stay committed to doing them. As Dogen-Zenji teaches: "Do not think you will necessarily be aware of your own enlightenment."
My day started off on a really good note when Hilary Cotter messaged me that he has finally started a blog -- and he comes out swinging for the fences with an amazingly deep and well written dive down into at MSN Search. And just in case you're wondering WTF "hapax legomena" means and why it is important, go here.
Duncan McAlynn (the artist formerly known as Larry Duncan) notes this spiffy little tool for MOM that enables alerting admins about password changes. And you should care why? Think about what happen if somebody decided to hack your domain and start locking the admins out. If somebody changes the password on a service-supporting account and you'll get it.
Mat Stephen from the UK posts about SQL Server having Sudden Death Syndrome on SMP Boxes and the non-obvious reasons it happens. Folks, remember the rule of thumb: one drive spindle minimum per CPU for production SQL Server setups, okay?
Somebody in the SQL Server 2005 newsgroup posted about installing it. Installing it? Humm, guess I never gave that much thought until I went looking around about it. You don't install it at all, apparently, it just works if deploy it as part of your app, according to Frank Prengel.
Last year I had a great time working with Matt Payne getting Axis and ASMX working together securely. My how times have changed since then, at least looking briefly at this demo of soap on TCP raw socket, from Simon Guest.
I am getting way more feedback about "Just Glue It" than I expected, and it seems like I may have hit a few nerves along the way.
Sleep Well.
EricNick notes the lack of Java-like Frameworks in the .NET environment here while Jeff Brand chimes in on it here. They are both correct -- at least from one point of view -- about the combination of the a "get it out the door" mentality and "if we wait, they'll build it" having created some dismotivation in the majority to invent new frameworks around .NET. Sure, companies like Avanade have, and the Enterprise Library goes there, but on the whole, I just don't see that kind of innovation in .NET environment either. why?
I believe we don't see as much "big picture stuff" getting done with .Net is that the traditional mindset of the MS developer who grew up in the ActiveX/COM era where MS told us to "glue components and controls together to get stuff "out the door" whlist today waiting for "MS to get it done" tomrrow.
We can call that the "Just Glue It" attitude.
While today's .NET control/component seems pretty strong and loaded with stuff to use, I always get the sense from ISVs that they are waiting for the next shoe to drop since in the next release of .NET, where hey, its built in! Doubt me? Well, I probably wouldn't have needed to buy the Rebex FTP stuff if I would have had Whidbey six months ago. In effect, Microsoft discourages companies from creating anything massive like a framework when, in a few months, there'll be something that's 80% to 90% as complete free in the .NET framework. At a Macro-level, its a zero-sum game. At a Micro-level, a huge risk for folks to take. "Just Glue It" is the optimal economic model for them to take then.
Right or wrong, I think the Microsoft's approach has a lot of "we glue services" thinking in it too. That's not bad on the whole, but I can understand why companies aren't willing to invest man-decades and millions of dollars; and why "communities" of developers don't plunge more of their efforts into inventing things as cool Hiberate, Axis and so on. Why when we'll be able to "just glue it" later on?
On the bright side, the .NET folks seem to have latched on the tools that Open Sources offers to our advantage. Stuff like NUnit and Saxon.NET come to mind. Stuff like Mono and IKVM.NET give me hope that we'll eventually find compatabile technologic and economic models that allow "just glue it" and the "fill-in-the-holes-with-frameworks" approaches to co-exist peacefully.
At least its a start.
Looks like its going to be a busy month for the IT Communities in the Greater Omaha area:
- First up is OLUG's monthly meeting on the 1st. The topic of discussion? Asterisk!
- Omaha SPIN should be having a meeting on the 15th, but I've not heard a topic yet.
- NebraskaCERT CyberSecurityForum will be meeting on the 16th for breakfast and a general disucssion of Security Trends.
- Bummer! The Omaha Macromedia group is having the renowned Kevin Towes come speak about Flash Communication Server on the 17th. Not that this is a bad thing but...
- Also on the 17th, the Greater Omaha SQL Server's Users Group will be meeting. Group Co-Founder and SQL Guru Luke Schollmeyer will be talking about the T-SQL enhancements in SQL Server 2005.
- Monday the 21st, the Omaha Java User's Group will having a presentation by Dave Burchell about the PayPal API.
- Thursday the 24th is a .NET-DoubleStack. In the afternoon Mike Benkovich will be visiting town to present the quarterly MSDN event. Following that, FunWith.NET should be meeting at Creighton West. This session will be a bit different -- it's show and tell night!
- Bummer! That's the same night that the Omaha PerlMongers meet up.
I was reading this morning about Microsoft's decision to finally open the Office XML standards (more on this latter) when I went down a rabbit trail about open OpenOffice. Now, understand this, I use both OpenOffice and Microsoft Office System and like them about equally as a user. From a development POV, I've found OpenOffice more difficult to work with, but that's likely my own shortcoming for not having done was much with it. But one of the reasons that I like OpenOffice is that it works pretty well platform to platform for the stuff I care about: composing text doucments and doing spreadsheets. Presentations? Well, not so much, but virtually everybody calls them "PowerPoints" anyway since that's the format they expect.
Back to the rabbit trail. It seems that the folks developing OpenOffice on the Mac are content have their product seens as something advanced -- or as they put it -- "This build is meant for the Darwin community and Unix-savvy MacOS X user community and forming a platform for us to build the Quartz and Aqua tracks for the traditional Mac user" -- rather than something for the everyday citizen of MacTopia. I guess that's okay and understandable since they also go on to talk about how certain engineering challenges have gotten in their way of having a version that works with the Native GUI engines for OS X. I understand their decisions technically. And now I can feel okay about using it on a Mac as long as I can make X11 work. Oh. Well, okay, that's been harder for me in past than I like, but its probably better now, right?
The discussion also talks about some policitical battles that the team is facing with the Mac port, and that Sun's own licensing of OpenOffice(second to the last paragraph) is a significant roadblock to moving the Mac port forward. Now that does bother because of the mixed message it sends. However, I'm having a hard time finding any substanative discussion of what the problem is and how it limits folks ability to do work. I'd really like to understand that becore I invest any time contributing any bits to the project. Hopefully somebody who knows will see this and point me at it.