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 Alexis Midon on Mar 16, 2007
In his last post, Antonio Cangiano gives his personal definition of evangelism:
Bringing to the attention of other programmers innovations that I find, which can make us more productive or help us produce better software. It's a matter of awareness, there is no intention of pushing anything on anyone.
He explains that finding interesting innovations requires to explore new languages and frameworks and that passion for learning is the only motivation.
Now that Ruby has no secret for him, Antonio Cangiano lists the main criteria for selecting a new language to learn. He argues that only functional languages could meet the new concurrency requirements introduced by multiple core/processor architectures. In passing, he points out that Ruby green threading model cannot leverage such architectures.
If we have 2,4 or 16 cores, we better start thinking about how to develop applications that take full advantage of them. Concurrent and parallel programming can be quite tedious and error prone when adopting languages that are not designed for these requirements. Ruby's current lack of native threads is then particularly unfortunate in these scenarios, as it implies that Ruby will take advantage of a single processor only.
Keeping only Erlang and Haskell on his short list, Antonio Cangiano explains his personal choice for Haskell as a new personal challenge and concludes with a "How to get started with Haskell" section.
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Five Key Practices to Agile ALM
A practical guide to choosing the right agile tools
18 agile and lean practices for effective software development governance
Take out the ;jsessionid stuff from the link and it will work.
I'm skipping Ruby and going straight to Haskell!
Well that depends on what you actually want to do!
For example, if you want to create a web app, then you are still better off with Ruby on Rails (as far as I know Haskell is still lacking such web framework).
Two other notes:
1. You can still combine with languages, each for their own strenghts.
2. Ruby also has functional (lambda) support builtin, so you can use a (limited) functional approach within Ruby.
Hi all, I'd like to submit that there is a healthy middle ground making the best use of all of these. We use Erlang/OTP for concurrency and reliability in our AMQP broker implementation: www.rabbitmq.com. We offer clients in other languages such as Java. OTP has awesome power as a commercial messaging broker platform, and people can use whatever languages they like to access the messaging infrastructure over AMQP. And, if you want to see Erlang in action, you can examine the broker code too. Please take a look and get involved! The RabbitMQ FAQ has helpful references on all this as well.
alexis
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.
5 comments
Watch Thread Reply