Cloud Computing has arrived. Whether it's the new Windows Azure, Google's AppEngine, Amazon's S3/EC2, or something a little less obvious like the SalesForce platform, you have options available. Unfortunately, they all have one thing in common: none of them really take advantage of a cloud. In every single one of these offerings your app ultimately runs on a single server in a traditional datacenter. All they've done is abstract things away a bit so that you don't need to know which server it is. That's neat, but it's not really what I want from a cloud system.
I've been using the new StackOverflow.com web site a lot. One of the less attractive "features" there is a CAPTCHA that crops up every so often. This CAPTCHA is based off reCaptcha, which is a project that pulls problem text from book scanning projects. It uses words that the scanners couldn't handle for part of the captcha. It's a great concept: if the the legitimate scanners were unable to recognize the word, it's likely that attempted cracks will have the same trouble. Additionally, as a user at least I feel like the annoying captcha has some extra purpose.
One of my personal character traits is that I nitpick my writing. I'll probably edit this blog post at least a dozen times after I post it before I move on (9 or 10 of those edits will fix dumb typos). I therefore hit the StackOverflow captcha fairly often. That's where it happened; I completed a routine edit, received a captcha prompt, and typed what I saw without thinking. Except this time what I typed wasn't exactly what the captcha showed. The captcha had a typo, and I subconsciously entered the word correctly. I realized my "mistake" a moment after I submitted the response, and mentally braced for the rejection. But instead of a rejection, the captcha passed.
Now I have to believe that the captcha requires more than one "opinion" on each snippet before accepting it into the final work. But I wonder, how often does this happen? Could this system actually be correcting spelling or typesetting mistakes in old books via some human psychological phenomon? Probably not: most often the captcha will be entered as shown. But the possibility is at least intriguing.
I've been using SQL Server Management Studio almost since it came out, and before we even had a SQL Server 2005 database for it to talk to. I know a lot of people don't like it, but most of the negatives just didn't apply to me. The two biggest are probably the .Net framework requirements and that it can be very slow. I already had the .Net framework installed, and while it is a little slow to start up the first time after restarting windows, after that it's been fairly responsive.
So I've been watching the SQL Server 2008 launch and patiently waiting for the Express Edition of the management studio to come out. And waiting, and waiting. Every once in a while I'd go back and look for it, only to find the 2005 version instead. Today, I finally found it. I'm still downloading it, so I can't tell you how it does, but here is a partial list of new featuers. And here is a link to try it for yourself. Note that it now requires .Net 3.5 and Windows Installer 4.5.
Unless you're a family member, if you're reading this you've probably already heard about Google Chrome. If you haven't tried it already, it's worth taking a look at. Even in the crowded browser market Google managed to find some things left to do worth doing. Here are my impressions (both good and bad):
- It starts up very fast. I mean, like instantly, especially compared to firefox or IE.
- One of it's touted features is faster javascript, but I really haven't noticed. If you're looking for a good real-world site to use to test the javascript speed I recommend playing around with the WunderMap.
- I really like the New Tab page.
- Mostly sites look like they're supposed to, but I've seen a few rendering glitches. For example, my iGoogle homepage often can't decide whether or not to show a scroll bar for one of the gadgets. It keeps toggling both and forth in an annoying way.
- The bullet symbol is ugly and pixelated.
- It handles the Vox textbox better than Firefox.
- In other browsers when you finish browsing a page you'll probably use the same tab and just go to a bookmark or type a new address in the URL. Using the default option in Chrome, I often want to go to the New Tab page but there's no way to get there in one click without leaving your old tab hanging around. So the instinct is to first close your current tab and then open a new tab. However, if your current tab is the only tab, the entire browser goes away as soon as you click to close the first tab. I finally found out how to fix this by setting it to show a home button in the options. Edit: I found an option to fix this, but it's buried pretty deep.
- It's supposedly very resource intensive. I really don't mind. Browsing is one of the main things I do at the computer. Any system resources you're not using are essentially wasted, so as long as it's willing to play nice if another program needs it, it's welcome to a generous helping of my 2GB of RAM.
- There's no way that I know right now to build extensions or block ads. It looks like it might be doing some ad blocking already, but I'm not sure.
- I really like the way the Ctrl-F find works.
Announcing Ryan James Coehoorn, born 8/8/8 weighing 8lbs 8oz and 22in long at 3:41am.
I'm getting very frustrated with vox's inability to let me search my own blog!
I don't often do this, but I downloaded some really cool software today and I decided to plug it:
http://www.skybound.ca/stylizer/
There's a free version, so it won't cost anything to try it. To understand why it's cool you have to run through the tutorial. Otherwise it looks just like any other grid-based editor out there. The tutorial itself isn't that great, but some of the demonstrated features are pretty cool.
As multi-core CPUs become more and more common, the ability to write quality software that takes advantage of them will become more important. The tools currently available are not adequate to this task. We are seeing a few things emerge to help solve the problem. One good example is the shift back to web applications hosted on a server. Web applications automatically run in parallel; each request can get it's own thread. However, there's still a shortage of simple, effective techiques for building parallel software on the desktop.
I had an idea of one place that where it would be very easy to build a parallel software approach into the programming language, so that developers can take advantage of a multi-core cpu in certain situations without having to do extra work. This idea is obvious enough that it probably isn't new to me, but I don't think I've read about it anywhere else and so I wanted to write it out here.
What I want to do is updated the standard "foreach" loop that's included in most modern programming languages. .Net, java, PHP, Python, and more all have this simple loop. In a for each loop, you specify an operation to be performed on every item in a collection of items. Current implementations of this loop always run in serial. Process one item, and when that one is finished get the next and process it. However, much of the time this could be done in parallel. My idea is that you could bake this concept into a programming language by making a simple change to your loop declaration. For example, take this simple C# loop declaration. Instead of this:
foreach (object Item in MyCollection)
Do this:
forevery (object Item in MyCollection)
Change just one key word and the compiler knows it can use create separate threads for the contents of the loop.
Of course, there are situations where these loops should not be run in parallel. Maybe you need to break early. Or maybe you're building a count as you go. But this should be relatively easy for the programmer to determine, and they can always use the old behavior when needed.
Are there any languages out there that already implement this concept?
I've talked about this before, and I don't want to go over the same issues a second time. However, I recently had a project where I finally spent a few weeks in C#, with no VB work at all. At last, I had a chance to develop a deeper familiarity with C#. Maybe I would learn something new.
The result? C# moves closer to VB.Net in my estimation, but doesn't quite pass it. All of the short-comings when compared to VB.Net still exist in my mind, but now I've had the chance to get a feel for what C# does about them. I can't put my finger on it, but there are little things here and there in C# that make up for a lot of what I complained about before. For example, I still prefer seeing "End If", "End Sub", "End Class", etc to the more ambiguous "}". But now that I've used C# more it's not as big a deal. I like the VB way, but I'm not as handicapped by C# as I was. The gap is still there, but it's not as wide.
The experience did bring one new shorting coming in C# that I didn't write about before. VB.Net supports partial namespaces; C# does not. Let me explain. Imagine you want to read from a file. In .Net, that means using the System.IO namespace. With Visual Basic, System is imported by default and child namespaces are automatically resolved. So, for example, to see if a file exists I can just say something like this:
That won't work in C#. You have to either type out System.IO.File or add a using directive for System.IO at the top of the file. Now the IO namespace this isn't a big deal. You're probably going to use the classes from the namespace a dozen times if you use them once, or it's not a lot to type otherwise. It does pollute your intellisense namespace though, and it starts to become annoying when you also need StringBuilder and have to import System.Text but aren't using anything else from that namespace. Or maybe you need a single Dataset, but nothing else from System.Data. You can quickly accumulate several using directives that only exist to support one class declaration. The point is that the class library heirarchy in .Net is rather flat, and there are a lot of little things you might want that in C# that all require a using directive where VB.Net does not.If IO.File.Exists("foo.bar") Then
So C# doesn't let you use a partial namespace in a declaration. Big deal. Well, this example only illustrates the least of my complaints. The worst things about what I've shown so far are that it leads to a polluted intellisense prompt and that it breaks your flow to have to jump to the top of the page to add the declaration and then jumb back versus simply typing a shorter name. If this was all there was to it I would just keep my mouth shut and deal with it. But there are other, more important manifestations. I'll give two examples.
Say you're working on a project that involves a lot of XML. You'll probably import the System.Xml namespace. In C# you may also need to import one or more of System.Xml.Schema, System.Xml.XPath, System.Xml.Serialization, or System.Xml.Xsl. And now you're using a whole bunch of different classes with no reference in the code for which specific namespace each class came from. In VB.Net you can just preface the class names of classes not directly in the Xml namespace with only the missing child namespace. For example, if I choose not to import System.Xml.Schema but already have System.Xml I can still just say "Schema.XmlSchema" instead of "System.Xml.Schema.XmlSchema".
That sounds a lot like the same complaint I had earlier, and it usually ends up requiring a little more typing than importing all the namespaces once. What's new, though, is that in my opinion this has the potential tomake the code easier to understand. The specific example of "Schema.XmlSchema" is pretty redundant, but there are plenty of cases where having one level of the namespace with the class would add clarity to the declaration. This is especially true for junior developers who may not be totally familiar with the framework. Used correctly, it can provide just a little bit of important context for each of your declarations.
Now for the next example. After all, the Xml namespace is pretty well understood. Also, my XML example wasn't very good; what do we need the extra context for? Fair enough. Let's look at something even more relevant. What if you're working on a project where you want to use a third party library? In this case, being able to see a small amount of context for each class may have a little more value. And what if you've never used this library before?
The SharpZipLib comes to mind as a reasonable example. Imagine your project involved using the library to untar some files. In C# you would import ICSharpCode.SharpZipLib.Tar and then type class names as usuall. However, there is no help from the IDE in finding out what those classes are without re-typing the entire namespace every time. This shows one final reason why partial namespaces are useful. In VB.Net you just import ICSharpCode.SharpZipLib. Now, if you only type "Tar." you get an intellisense list of members of that namespace as soon as you hit the period key. For this reason, I find VB.Net is much easier to work with when learning the ins and outs of a new library.
In summary, I really like VB.Net's ability to use partial namespaces in declarations. There's probably a more official name for the feature, but I don't know it. It might even be something you can just turn on as an option for a project in C#, in which case I hope someone will tell me where to find that option. I think the feature promotes code that is more readable, doesn't break the flow of the programmer as often, keeps your intellisense namespace clearer, and aids in learning new libraries.
I don't know how many times I've seen code similar to the following on programming help forums:
Function MyMethod(ByVal InputParameter() As String) As String()
'Do Stuff here that returns a different string array
End Function
That's okay. We can make that work just fine. I mean, it could be worse; they could have used an ArrayList. But we can do better, too. Now look at this code:
Function MyNewMethod(ByVal InputParameter As IEnumerable(Of String)) As StringCollection
'Do stuff here that returns the string collection
End Function
This code is a drop in replacement for the code above. By that I mean that anywhere you call the first method, you could replace it with the 2nd method and your code will still work. You don't have to change anything else except the type of the variable that accepts the result. So if it works the same, why change? I mean, it takes a little more thought to read it and therefore you could argue it takes more to maintain. What do you gain? The answer is that you've just made the function more useful and flexible.
Let's start with the InputParameter. Perhaps right now you have always have a string array when you call it. But what if later you start working with something like an ArrayList or the generic List(Of String)? Those will both work with that method right now, with no other changes. You can even put Xml or datatables through there with a little work. IEnumerable(Of String) will accept anything that can give you a string in a For Each loop. So just by changing the type I've instantly made the code more powerful.
Now for the return type. I could have used IEnumerable(Of String) here as well. However, in this case that would actually limit the capabilities of the function. You'd lose the ability to look at values by index. What I want to do is expand the capabilities of the function. String() already implies IEnumerable(Of String). However, by moving from the array up to a StringCollection I not only keep that ability but gain the ability to easily add or remove items from the collection. I also get some bonuses like the nice .Contains() and .IndexOf() methods. So again, I've expanded what the function can do, and therefore made it more valuable.
For example, you might now be able to use it somewhere that before would have required a separate (but very similar) function. Or the switch to the new function might save you having to write a for each loop on the return value because of additional capabilities in the collection like the .Contains() method. It will enable you to get the same work done in less code.
One other point is that the new version should perform about the same as the old one. There might be a very small loss, but any difference is likely to be minor relative to other considerations in your code. Certainly falls under the heading of "premature optimization."
In general, we can think of IEnumerable(Of String) as a wider type, and StringCollection as a more powerful type. A good rule of thumb is to accept a wider type for input and return a more powerful type for output. In this way you will make your code more useful, and in the long run that's probably a good thing.
