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";
}6 posts tagged “stackoverflow”
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:
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.
