As previously announced, Codaset officially left beta and launched late last night. Apart from a few issues with the new caching of pages, everything went quite smoothly, and I was very happy with how it all went.

As I already talked about the pricing model in my previous post, there is not much more to tell you really. This release doesn't include any new features, but does include a ton of under the hood changes and fixes. Most you won't notice, but one you should, and that is caching. You should notice that the site in general is much faster, and I hope to improve that even further in the future.

So there are three distinct items that I have already started work on, and should be released sometime this month. They are Paypal payments, Groups, and the API. I'll be talking more about them in future posts.

But for now, I want to thank you all for your continued support, and hope you enjoy this release and those to come. If you have any questions or issues, please let me know.

Enjoy!

OK, we are finally here! All the pieces have fallen into place, albeit a little slowly, but I am excited to announce that Codaset will leave beta and launch officially this coming Monday March 1st.

This basically means that Codaset will start charging for some of its services, so I wanted to tell you more about the business model that I have chosen and how much you will be paying for your private projects hosted with us.

So as you may have read, I decided on an all new type of business model for code hosting industry. Usually, you pay host your code with a service, and they charge you on a monthly basis, based on a set of fixed pricing plans, and each pricing plan would include a fixed or maximum number of projects and/or disk space that you can use before you have to upgrade to the next plan and pay more. I've never been a fan of this, as it can mean you having upgrade to a more expensive plan, when all you need is one extra project, or a little more space. It's not exactly a relative system.

Codaset will operate a little differently on a "pay as you go" basis. Meaning you will only pay what for what you use. A few important points before I go further...

• Public or open source projects on Codaset will ALWAYS be 100% free - for life!
• Each of these public projects will include 200 MB of disk space. This will be monitored, but I don't plan on setting this as a hard limit. So don't worry if you exceed that. If you need more, just let us know, and we'll get you some more.
• Your first private or semi-private project will also be completely free - for life!

How's that for starters?

Once you exceed one private or semi-private project, monthly payments will be due. Even though Codaset's business model is based on a "pay as you go" system, I realized that charging customers credit cards for a dollar here and 50 cents there would not be cost effective for either side. Mostly for me to be honest, as I have banking charges to pay for each and every transaction. Which is why there will be a monthly minimum of $5 when you have more than one private or semi-private project.

So you can create your first private or semi-private project for free. Then when you create your second, an immediate payment of $5 will be due. That payment will be due every month thereafter for as long as you have more than one private or semi-private project.

This monthly minimum will allow you to create up to a total of six private or semi-private projects, and you will never pay more than $5 for those. However, once you create more than six private or semi-private projects, the "pay as you go" pricing will kick into place as follows...

• Each private or semi-private project will be charged at $0.04 per day.
• This pricing will only apply for each project above your first six.
• "Pay as you go" pricing is pro-rata based. So if you create a project and then delete it the next day, you will only pay $0.04.
• As with public projects, each private or semi-private project will also include 200 MB of disk space.

So as an example; if Bob has six private projects, he will pay $5 per month. He then creates another, which will be his seventh private or semi-private project. This seventh project will cost him $0.04 per day. So a month later, he will pay $5 plus $1.20 ($0.04 x 30 days). Costing him a total of $6.20 for 7 private projects. Not bad hey?

I know this may seem a touch confusing at first, but really it isn't. The best thing about it, is that you will pay for what you use. Just remember...

• First private or semi-private project is free.
• You can then create up to five more, making a total of six private or semi-private projects for only $5 per month.
• Every private or semi-private project thereafter will cost you only $0.04 per day (around $1.20 per month)

For all you early adopters who have several private projects already, I thank you! Any private or semi-private projects that have been created up until Wednesday February 24th, will be given six free private or semi-private projects for free. So usually, you would get one for free. But you guys are special, so I'm giving you six.

I really think this is a great way to host your software projects and code, and a very inexpensive one at that. You can try Codaset with no commitment or payments, and can do so for as long as you want. Then when you are ready, just pay for what you use. Create and delete projects as you wish, and your monthly payment will adjust accordingly.

So I really hope you like this new way of software project hosting, just like I hope you like Codaset and the new features it provides you as developers. I'm really excited about finally letting my baby loose into the world and would love to know your thoughts on the pricing and any thing else. Just leave your comments in reply to this post. I'll be posting again on Monday with full details of the launch.

Thanks again, and enjoy!

Before I start on the real subject of this post, I just want to keep you all up to date on where we are with the Codaset beta. The code is written, and the "pay" branch is now sitting quietly waiting to be unleashed on the world. It also contains a few small goodies, and a whole bunch of bug fixes. It's even been deployed and tested on staging server, and works great. But unfortunately, I am waiting on my bank to complete the last bit of red tape before Codaset can launch, and accept US Dollar payments online. But once I get that go ahead, we will be good to go. But this should only be a matter of a few days.

So onto the real reason for this post...

Codaset will have a complete invoicing system (which is already complete), and will allow you to view any and all of your past and present invoices. I recognized a need for a way to download and save invoices to your local computer, and in a format that is easily accessible. PDF was the best answer to this. So what I needed was a way to easily convert an existing HTML page into a PDF document.

I had already heard of the Prawn library and the Rails plugin that it supports. But Prawn doesn't actually provide a simple way to convert HTML to PDF on the fly. So I found PrinceXML.

Prince is a computer program that converts XML and HTML into PDF documents. Prince can read many XML formats, including XHTML and SVG. Prince formats documents according to style sheets written in CSS.

Now that sounds exactly what I am looking for! A way to convert an existing HTML page into a PDF document, with very little effort. And lo and behold it already has a Rails plugin called Princely. So after installing Prince and the Princely plugin,, I was able to modify my InvoiceController#show action like so:

def show
  @invoice = @user.invoices.find params[:id]
  respond_to do |wants|
    wants.html
    wants.pdf do
      render :pdf => "Codaset Invoice ##{@invoice.id}",
                 :stylesheets => ['screen', 'base', 'application', 'princely'],
                 :layout => "application"
    end
  end
end

And that is it! I can now download any invoice, by appending .pdf to the end of my Invoice show URL, and an identical PDF version of the HTML invoice is generated and sent for download to me.

The only bit of formatting I had to modify was to set the page margin and padding, which I did in a new CSS file:

@page {
  margin: 20pt;
  padding: 10pt 5pt;
}

So if need to generate PDF versions of your HTML pages, I definately recommend PrinceXML.

The Codaset blog has been a little busy as of late, what with my posts about the future business plans, and pricing discussions. This is all well and good, but it seems that a few of you lost interest after having left a comment, but still kept receiving email notifications of new comments for each blog post that you commented on. Needless to say, this was annoying and frustrating for those of you who no longer wanted to receive notification of new comments.

So I spent the last few days improving the commenting system in Codaset, and added support for managing your email notifications for comments and tickets. If you don't want to receive any more emails about new comments to a particular ticket, or blog post, or code review, then you can click the link in one of the emails to "unwatch" the item. Or you can go to the item in question on the site, and click the appropriate link.

You can come back at any time, and resubscribe to the comment thread, or start watching any ticket, even if you are not a part of the conversation.

This is a great way to keep up to date with anything that involves user participation, and lets you quickly and easily start and/or stop watching any blog post, ticket or code review.

Hope you like it, as this will be the last new feature before Codaset leaves beta, which I hope will be the start of next week.

So while working on the payment system for Codaset, I wanted to provide a little future-proofing in the form of allowing more than one method of payment. Only credit and debit cards will be supported at first, but I would like to allow payments via other methods later down the line, such as Paypal, etc. But I came across an issue that related to the fact that the database fields that would be required for credit card and paypal payments, would not be the same.

For example, for credit card payments, I would need the following fields in my payment_methods table:

create_table :payment_methods do |t|
  t.integer :user_id
  t.string :card_number, :card_holder
  t.date :start_date, :end_date
end

But for Paypal payments, I wouldn't need any of the above fields:

create_table :payment_methods do |t|
  t.integer :user_id
  t.string :paypal_email
end

Now I could simply create all these fields in one table, and that would work fine, but not so elegant. I wanted a nice easy way to create and save any fields without having to create a database table column for each one. If more payment methods come along, I don't want to have to modify the database schema, by adding more columns.

So I came up with a nice little Rails plugin that lets me do exactly that.

Introducing Dynamic Attributes

Dynamic Attributes is a Rails plugin that lets you create dynamic attributes on any ActiveRecord model, and saves them in a schema-less fashion within a single table column. I can now save a model attribute in the usual Rails way, using any of its getters and setters, without having to actually create a table column for each attribute. And I also don't want to create a new record for each new attribute.

All I need is a single extra column in my PaymentMethod table called dynamic_attributes, and tell my model that it has dynamic attributes:

PaymentMethod < ActiveRecord::Base
  has_dynamic_attributes
end

I don't even need to tell the model the names of my dynamic attributes, and I can of course mix my dynamic attributes with normal attributes.

So now I can create a new PaymentMethod record with two dynamic attributes: card_holder and card_number:

@payment_method = PaymentMethod.new :card_holder => 'Joel Moss', :card_number => '4111111111111111'
@payment_method.save

And I can call any of those dynamic attributes just like any other model attribute:

@payment_method.card_holder
=> 'Joel Moss'

@payment_method.card_number
=> '4111111111111111'

And that is pretty much it! All my dynamic attributes are indeed dynamic, and are saved in one single database column as a YAML hash. If I want to get a hash of all my dynamic attributes, I can do this:

@payment_method.dynamic_attributes
=> { :card_holder => 'Joel Moss', :card_number => '4111111111111111' }

The plugin also supports defined dynamic attributes to prevent just any old attributes being created, and you can also specify a custom database column name to save your dynamic attributes in. Read the ReadMe for more info on that, and full details of how to use the plugin with your Rails apps.

You can checkout the source on Codaset at http://codaset.com/joelmoss/dynamic-attributes. Please play with it, and let me know your thoughts. And please feel free to fork the source; your contributions are most welcome.