I have been running into a problem recently with my development over at Type Aloud; some of my column data types differ from MySQL (my development database) and PostgreSQL (my production database). I store two copies of the story in the database: the first is the “human readable” version that uses the Markdown syntax and the second is the HTML version of that syntax so it is easier to fragment cache and display when someone is viewing the chapter. This problem is particularly irritating because when it first happened in MySQL the text was merely truncated, but in PostgreSQL it correctly does not allow the insertion into the table if the text is too long.
For the past couple of days I have been doing some light searching trying to figure out a way to have a RDBMS specific database migration, and I once I did some pecking in the ActiveRecord::Migration class I was able to figure this out pretty easily. I figured that I would share it below since it took me a little while to find it. Now normally I do not believe in migrations being platform specific, but in this case because I wanted to actually have the application work on two types of platforms (in this case, two RDBMS).
class AddLongtextToPostgresql < ActiveRecord::Migration def self.up case ActiveRecord::Base.connection.adapter_name when 'PostgreSQL' execute "CREATE DOMAIN longtext as text" execute "ALTER TABLE chapters ALTER COLUMN html TYPE longtext" execute "ALTER TABLE chapters ALTER COLUMN body TYPE longtext" else puts "This migration is not supported on this platform." end end def self.down end end
When I started doing some serious programming about ten years ago this new buzzword started to get passed around. When I was browsing the isles at Barnes and Noble every other new-age programming book would pop up describing how a service oriented architecture would be the future of software development. How it would bridge the gaps between platform dependent code and allow us to use cheap hardware when necessary to serve enterprise clients (and other services). It promised a more modular approach to programming, encapsulating functionality in a bundled executable called a “service” which had a schema that it responded to, but it via XML, SOAP or some other protocol.
Whenever I dream up a project I tend to use it as a driver for learning a new software library or language. When reading first about the service oriented architecture paradigm the Java programming stack was usually the king of the hill when it came to discussions. Even today, after Oracle purchased Sun and basically started to put nails in the proverbial Java coffin, it still reminds a leader in enterprise service oriented design. I am a C/C++ programming, self taught and currently by trade, but I would be a fool to ignore the advantages that this platform offered. So as any good project manager I read up a lot on Java (at the time) and learned as much as I could about SOA practices.
A few years ago I started attending college for the computer science discipline and Java was the primary language that was being taught everywhere. Although, until some of my later entrepreneurial projects, I heard not a word about SOA practices in any of my programming or software engineering courses. A few years ago the topic of the “Cloud” became all the rage; people were making money off writing books, companies such as Microsoft (and even Sun) were working on Cloud projects to help developers and Amazon started selling specialized hosting geared towards metered bandwidth, CPU and memory usage. I began asking myself: what is different about software in the Cloud?
Well, the truth is, software that is written to be able to take advantage of all the regularly toted features of the Cloud such as being able to elastically adjust your application’s presence on demand, is just the service oriented architecture approach of designing software taken to the limit. The actual truth of the matter is that any piece of software that is designed to be fully “cloud compliant” is most likely some kind of service, be it a web application using the HTTP protocol or a Glassfish Java application stack using XML or SOAP as communication protocol. When designed properly a service oriented platform stack should be able to scale horizontally much more efficiently than it does vertically.
What the is the difference between scaling out vertically and horizontally? When an application scales out vertically this means adding more memory, CPU power, hard-drive space, etc, to an existing system that is servicing clients. Scaling out vertically is merely adding additional computing nodes. This means everything to a distributed architecture; as soon as the node touches the grid it should be servicing clients. But as I said earlier in this essay the idea of SOA practices have existed long before the marketing engine of Salesforce and Amazon have trademarked the word cloud.
The principle of the cloud is the ability to scale out vertically on demand. If your application is about to get hit by a swarm of geeks from Slashdot any normal application running on cheap Linux metal in a data center would likely cripple under the additional CPU, bandwidth and memory requirements put in place by this surge of new clients. An application that is able to be scaled out can elastically grow and shrink on demand, servicing the needs of its client base at any single point in time.
But what does that mean for business? You only pay a metered rate for bandwidth and CPU cycles on the amount that you’re using at any given point in time. Your traffic at 2AM in the morning on a Thursday likely is not anywhere near the traffic that you have at peak Internet browsing hours. Why should you be paying those massive hosting fees when you’re really only using your hardware to the limit about three to four hours a day?
This is the principle behind “the cloud,” and if you couple this with a logical service oriented application design (see: distributed) your business will much more agile and cost effective in both the peak and downtime hours.
One of the features that was omitted from the Type Aloud beta launch earlier this year was the ability to work on unpublished stories and chapters. My testing period in early December showed that the workflow of most of the users was to develop their story in some offline editor such as Word or Pages first, and then pasting in the finished product into the text area making slight modifications when needed for markup.
A few friends brought this to my attention and this afternoon I started cooking up some changes to make it possible to “publish” and “depublish” stories and chapters from the website. Any story that is created first begins in an unpublished state (draft mode) which needs to be explicitly toggled by the owner before it goes live on the site. At any point in time the user has the option to take their story offline making it unpublished again. It should then immediately become unavailable across the site. I am working on making sure that comments and subscriptions correctly disappear when a story becomes unpublished as well.
One good thing is that I do not plan on deleting subscriptions and comments on stories (chapters) when someone decides to depublish a story. This is assuming that the story will eventually come back because it was not deleted. When a story is deleted, the chapters, comments and subscriptions will follow.