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";
}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:
