StringBuilder builder = new StringBuilder();
string newline = "";
foreach (Map.Entry<MyClass.Key,String> entry : data.entrySet())
{
builder.append(newline)
.append(entry.key())
.append(": ")
.append(entry.value());
newline = "\n";
}Today's DailyWTF presented a programming challenge: write a function to multiply two numbers "Russian Peasant"-style. Reading that article, I immediately recognized two things. The first is that the algorithm essentially used a stack to hold completed portions of the calculation and then sums up that stack at the end. The 2nd is that stacks are fundamentally related to recursion. If I could write a stack-based solution I could also write a recursive one as well, and the code for the recursive solution would likely be fairly simple.
Of course, by the time I finished reading the article there were also already 22 comments, most of them solutions, one of them in VB.Net (not very good, imo) and one recursive one in Java, but I want to make it clear that I did not read any of those until after I completed my own implementation. It took less than 5 minutes to write and test the stack-based solution. In the end I discarded the stack as unnecessary and just kept a running total instead. It then required less then 5 additional minutes to adapt this to use recursion. I now had a working function for a grand total of 4 lines of code, and I felt it safe to take a peek at what others had done.
The only thing I added to my code based on the comments was to use bit shifts to multiply and divide by two. In one sense you could say it's cheating to write a multiplication function that uses the multiplication operator in any way, even if you're just multiplying or dividing by two. In this case I'd argue that the actual "Russian Peasents" suffered from the same chicken and egg problem, and so you've still met the spirit of the problem. But clearly the bit shifting is "better" from a standpoint of keeping your function "pure", and so I incorporated that into my code, which you can now see here:
Function multiply(ByVal x As Integer, ByVal y As Integer) As Integer
multiply = IIf(x Mod 2 <> 0, y, 0)
If x > 1 Then multiply += multiply(x >> 1, y << 1)
End Function
Note that this only works for positive integers. To work for negative integers as well you'd need to pull the sign out before making the recursive call. It's not that hard, but this is a puzzle and I felt like adding that code would only detract from the puzzle's solution.
This space has really stagnated this year. And the thing is, it's not the only one. I have so many friends who have abandoned their blogs in the last 6 to 8 months. In fact, I'm going on record right now and calling 2009 the "year the personal blog died."
It's not that blogging isn't worthwhile. It's just that for individuals who don't already have a significant following, services like Twitter, Facebook, and even StackOverflow do it so much better. They completely pre-empt much of the reason many people first begin to blog, and as more users move away from blog sites to alternatives the number of active blogs will shrink. You have to go where the audience is. I see this as a good thing, because those that remain will be much more likely to be actually worth reading. It is a sweeping away the clutter (and it's kind of sad that I appear to also be caught up in it).
That said, there is still a place for this content and I'm not completely abandoning this blog. At very least I want my old content to stay active, but also from time to time I'll have something I want to say that can't be expressed in 140 characters and isn't appropriate for StackOverflow. At those times I'll post it here so I can link it from Twitter and Facebook. And the family web site will continue to receive updates.
It's been a while since I've posted here, so to get caught up here a few of my own posts from StackOverflow that I'm most proud of:
It's been a few days now, so I've had time to think about what this will mean. My interest in Sun lies primarily with MySQL, Java, VirtualBox, and Solaris. As the title indicates, I'm cautiously optimistic.
First I want to consider MySQL. On the one hand, Oracle certainly knows databases. If they choose to they can really take MySQL to the next level. On the other hand, this wouldn't be the first time Oracle has purchased a better and cheaper competitor just to kill it off **cough**Peoplesoft**cough**.
The reason I'm optimistic that they'll do the former here is that MySQL will be a lot harder to just kill off than Peoplesoft. There's a recent open source version available, and they that back. If they try, they'll find that they don't have as much power in that area as they'd hoped. They best they can do is take it closed source and then release a few compelling updates, such that much of the community follows those updates and the open source clone's can't keep up. Only then can they kill it, and even at this point I'll be surprised if there's not still a viable open source-forked clone available.
Now on to Java. Under Sun, Java was starting to fall behind. Oracle relies on Java as the natural language choice for it's database, so it has every motivation to make sure the language stays relevant. That said, it will likely continue to be the same people driving development. I am a little concerned that Oracle will decide it needs to make more money from Java, but not too concerned. After all, there are a number of good open source Java tools available now, so just like MySQL the only way Oracle can really hurt Java is if they innovate at a faster pace than the open source community can emmulate. And that's not necessarily a bad thing.
I'm a little concerned that VirtualBox will cease to be free, and become more like VMWare. There's enough room to move here that Oracle can do what it wants. It's also very possible that Oracle will have no interest in continuing the product and will just turn it over to the community or sell it to someone else.
Finally, Solaris. Solaris is pretty much irrelevant. For Oracle, it gives them a native platform for their database without dependance on anyone else... if they want to go that route. In practice, Solaris is nothing if doesn't take advantage of open source libraries and rely on open source applications. I won't be surprised if Oracle kills Solaris, but I don't think it will matter much if they do. Those who used to use it can easily migrate to linux.
Follow up to this post.
I found this answer on StackOverflow this morning, which shows an even clearer way to concatenate delimited strings. I'm surprised I hadn't thought of this myself. The first part of that answer, while clever, isn't really important to the discussion. It turns a DataReader into an IEnumerable<string>. For my purpose it's better to assume we've already come that far. So given the IEnumerable, all you need is this (shown as an extension method):
public static string JoinWith(this IEnumerable<string> strings, string separator)
{
return String.Join(separator, strings.ToArray());
}Note that it might mean an extra iteration of the enumerable, because you must iterate to produce the array and iterate again to produce the string. It also means you will need the array, where with the other methods you may only ever need produce the completed string. But for many situations the improved clarity is worth it.
Of course the other thing to take away from this is that once you enter the realm of extension methods you could just as easily use them to hide away the (faster) code used in the previous post as well.
Most .Net programmers who need to use JSON can either pull in a third-party library or are using .Net 3.5 and therefore can rely on the built-in JavascriptSerializer . However, I recently found myself needing to turn a .Net DataTable into JavaScript Object Notation without either of those options available.
My first thought was that something must already be out there that I could use. Indeed, there are some really great libraries for this. Unfortunately, my situation is such that I can't pull in a whole library. I needed some purpose-specific code. I did find some specific implementations as well, but I found them all some how lacking and ended up rolling my own. The code itself would take up about 2 printed pages, so I'll content myself with posting the link for now.
Instead, this leaves me space to talk about naming. Notice that I titled the post "DataTable To JSON". If you read the code itself you'll find I actually turned that name around: "JSONHelper.FromDataTable". In the past it's always been more natural for me to think in terms of transforming type 1 to type 2, and names used in my code prior to this reflect that.
However, I recently found this post about naming conventions on StackOverflow, written by no less a personage than site co-founder Joel Spolsky. He makes a very good case for the "Type2FromType1" syntax: namely it puts the return type next to the variable receiving it and the source type next to the parameter accepting it, rather than the complete opposite. I decided to try this for a while, and while it felt awkward at first it's growing on me very quickly.
Today's question: How do I append a newline character for all lines except the last one?
What I really want to talk it about is the subtle difference between clean code and readable code. Take these two samples:
boolean first = true;
StringBuilder builder = new StringBuilder();
for (Map.Entry<MyClass.Key,String> entry : data.entrySet()) {
if (first) {
first = false;
} else {
builder.append("\n"); // Or whatever break you want
}
builder.append(entry.key())
.append(": ")
.append(entry.value());
}Obviously the 2nd snippet shows cleaner code, because there's no messy if/else condition. But is it more readable?
I ask this because although the if/else code is "messy", it's universally understood instantly by almost any developer. On the other hand, you may have to look at the 2nd snippet for a moment to understand how it works. Additionally, the 2nd snippet doesn't declare the delimiter constant until near the end of the block, rather than at the beginning.
Personally I use the latter construct, because the readability difference isn't all large. The pattern just isn't that difficult. But I consider it the lesser of two evils. Also, it shows that it might be possible to cross a line where cleaner code becomes less desirable, even if it works.
This is something I stumbled on a while ago and known how to do in a basic sense. But now thanks to this StackOverflow question I also know what it's called. This will make a huge impact on my ability to use this in the future, as before I couldn't really search google or msdn to get help with it.
SpreadsheetML is just an Xml schema that Excel understands. It's important because it the best way to export Excel data from a web app. In the past your choices were Ole, COM Interop, and HTML tables. Ole never worked reliably, as it depended on a registry setting to know the folder where your document is. COM Interop doesn't scale well and isn't licensed for use with a web server. HTML tables were limited in what they could do: only a single work sheet and no formulas, for example.
SpreadsheetML scales, will work anywhere, and supports nearly all of Excel's features. You can use it when you need to send an Excel file through a text-only medium like e-mail or chat. About the only downside is that it's not supported in Excel 2000 and earlier, though my experience is that it will work on Excel 2000 in a limited way, much the same as using an HTML table.
Today I came across a question about virtualizing web servers and databases. It caught my eye because I'd asked a similar question back in November.
The question got me thinking about scalability. Whatever current woes running a database or any other application in a virtualized server may have now, they will eventually be solved or at least sufficiently mitigated to make it worth the penalty.
At this point we'll start seeing server applications that not only support virtualization, but require it. A virtual server can provide a standard environment that an operating system on traditional hardware doesn't quite match, and allows you to tune the resources available to a server without shutting down the machine. Imagine virtualization software that allows a live transfer of a system from one physical machine to another with no shutdown. This is already happening. What's interesting is where we go from here. I think the next logical step is clustering/load balancing and cloning.
These are features that are available now, but smaller businesses largely ignore. But I think that once all your major applications are on virtual servers, the clustering problem becomes much simpler. The load balancer will be a function of the virtualization software itself. Of course the individual application will have to support it as well, but this will become a core feature of any serious server application, even in the entry level editions. Setting up a cluster will be as simple as clicking a check box and typing in the cluster name. Maybe you won't even need to click the checkbox: you'll just give two or more servers the same dns name and the virtualization software will know what it means.
At this point, a small business with one server can add additional horsepower simply by buying a server (any server), plugging into the network, and telling their current virtual system to clone itself to the new machine. Large businesses can do the same thing.
For a practical example, let's look at the new StackOverflow servers. One database and two smaller web servers. Under what I'm proposing each of those physical servers would carry a database instance and a web instance, each in a three-server cluster. If one goes down, the other two keep chugging happily away. Of course, if the current database server were to go down the site would be hurting.
But to be fair the planning would be different under my proposal, and Jeff probably would have purchased four machines more like the web servers, rather than one database and two web servers. This way he ends up with about the same power for about the same money. Perhaps even more power because he can add more memory cheaply. One server failure isn't a big deal now.
Even more significantly, as Jeff's traffic increases it becomes very easy to scale up the site infrastructure to match. All he needs to do to add a server is drop it in the rack and tell the virtualization software to create a new instance and hook it up. As it is, he's looking at having to do a major overhaul of his infrastructure in about two years.
This blog has been feeling a bit neglected recently. So in an effort to get it going again I'm re-purposing it. I'll still post original content from time to time, but effective immediately this place is now primarily dedicated to highlighting interesting questions I come across at StackOverflow.com. Essentially, I'm leveraging the community there to help me create content here. The important point is that I won't normally just repost a question. If I write about it here it's because I have something to add that may not be as appropriate for the other site.
Coming soon:
