New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on Nov 26, 2008
From the beginning, the .NET stack had first class support for unmanaged libraries. By using P/Invoke one can access most of the Win32 API and support for COM opens up developers to a wealth of applications and third-party libraries. With recent advancements in the Dynamic Language Runtime, scripts written in Python, Ruby, and JavaScript also come into play.
But are .NET developers actually taking advantage of this? Clint Hill says no.
The work was great and the tools were always getting improved. .NET came out and it was exciting. But after 6 years or so, it was wearing thin. The culture started to get a little crazy. One tenet of this culture (I use tenet loosely) was that all components used had to be derived of .NET materials. Which is to say: If you need a web controls library it has to be a .NET C# library because that is what you’re building your project with. And if that isn’t available, at a cost or free, then build your own.
There are few problems with this, the least of which is that projects got slow and deadlines got pushed. The biggest problem however is the idea that developers began to believe that other technologies were not acceptable. Regardless of how well they solved the problem. Today I find this mentality so disappointing.
Clint made these statements in response to a blog post by the popular author Jeff Atwood. Jeff, along with the equally well-known Joel Spolsky, is currently working on a forum site known as Stack Overflow. When it comes to sanitizing HTML for their site, Jeff turned up his nose at every pre-existing library. His reason, because they weren't written in .NET.
Do I regret spending a solid week building a set of HTML sanitization functions for Stack Overflow? Not even a little. There are plenty of sanitization solutions outside the .NET ecosystem, but precious few for C# or VB.NET. I've contributed the core code back to the community, so future .NET adventurers can use our code as a guidepost (or warning sign, depending on your perspective) on their own journey. They can learn from the simple, proven routine we wrote and continue to use on Stack Overflow every day.
Dare Obasanjo explains why this usually isn't a good idea,
The problem Jeff was trying to solve is how to allow a subset of HTML tags while stripping out all other HTML so as to prevent cross site scripting (XSS) attacks. The problem with Jeff's approach which was pointed out in the comments by many people including Simon Willison is that using regexes to filter HTML input in this way assumes that you will get fairly well-formed HTML. The problem with that approach which many developers have found out the hard way is that you also have to worry about malformed HTML due to the liberal HTML parsing policies of many modern Web browsers. Thus to use this approach you have to pretty much reverse engineer every HTML parsing quirk of common browsers if you don't want to end up storing HTML which looks safe but actually contains an exploit. Thus to utilize this approach Jeff really should have been looking at using a full fledged HTML parser such as SgmlReader or Beautiful Soup instead of regular expressions.
This debate is not just about sanitizing HTML, it goes to the core of the .NET culture. For.NET developers, is it appropriate to use non-.NET libraries in your day to day work?
A Guide to Branching and Merging Patterns
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Agility at scale, become as agile as you can be
Why NoSQL? A primer on Managing the Transition from RDBMS to NoSQL
SCM best practices for multiple processes, releases & distributed teams
If you take a look at stackoverflow, they're using the JQuery javascript library all over the place so I don't think they would qualify as an example of .NET's monoculture.
The platform you develop in has nothing to do with that.
Teebot
If performance might be an critical quality of service requirement than it might not be appropriate to use non-.NET libraries as interop will be needed.
Anyway the default should be that you should not reinvent the wheel and that you should only spent development time on business functionality and writing your own security framework just because it interests you should be done in your free time.
Except for when it isnt a great idea.
The point is, there is no hard and fast role, so stop looking for one. If you constrain yourself to a limited set of technologies then you are limiting yourself. Figure out the implications and weight them against the requirements, and the best answer will come through.
I dont care if you use strictly .NET, or PHP with a Lisp back-end. The technologies are means to an end, not an end in itself.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
3 comments
Watch Thread Reply