Yet another multicolumn layout - rocks!

20 August, 2007

One chasm between traditional desktop application development and web application development is layout/forms design. It's my constant pain point "I just want a 2 column layout, with a data table in the middle" - many hours later you're still tearing your hair out trying to get it working. It should not be this way (and that's just for prototyping). To get a production tested basic grid/column based layout, that looks reasonable across all browsers and is flexible enough to grow as the app grows - well we all know how much a top notch HTML/CSS wizard is going to cost us right ? Why for every project the same ground of IE hacks and cross browser issues are solved over and over again ? This is half the reason that a sandbox environment like AIR is very appealing - don't deal with it, just get your users to use a standard environment. Enter from stage left, in the why hasn't anyone thought about it before category, are two CSS frameworks that I happened upon on Friday. One called Blueprint which is getting a bit of attention, and one with the rather confusing name of YAML. After seeing all of the examples of YAML, and reviewing the documentation I thought what the heck lets give this a go. YAML is designed for 'standard' column based layouts. It essentially says 'create your main div structure this way, in a predefined page/top nav/nav/main body/footer layout. Then within your main body div, you have options for creating 1-3 columns, and then sub columns within those columns. Whilst I haven't tested the limits, I'm sure so long as it fits within a grid you could use YAML to create it. It's not designed for your highly creative CSS award winning page with umpteem divs all over it - however that audience wouldn't be reading this blog. But for your standard store/blog/cms/other application I can see a huge head start in having the CSS pain removed from your desk. So I put the theory to the test - 4 hours later, I had a couple of layouts running and working across IE 6, IE 7, Firefox, Safari... un-fricking-believable. About 30mins of that 4 hours was the actual job of getting the css setup with the basic grid structure - the rest, playing about with colours, table styles, and creating actual views. I abhor front end CSS work and this abstracted away all of the pain, leaving me just to get on with the job. I'm not going to attempt to write a how-to or tutorial, as the original docs are so good I'll leave well enough alone - the only caveat is don't just blindly copy and paste, make sure you skim read the docs, you need to know where to put the appropriate patch files etc. But wait there's more ! Does the thought of manually constructing even your basic div structure seem a little off putting to you. Dirk Jesse (YAML's wizard) has a browser based builder for constructing your layout and outputting the CSS. Very nice indeed !. Just jump to his site and check it out. So you can expect to see some XChain screenshots gracing this site shortly.

Read More

XChain is now running on rSpec

10 August, 2007

Whilst I wait to sort out the UI issues I'm building up the specs' for XChain. I'm using RSpec, so it's a lot more 'self documenting' about what you can expect the application to do. Starting on a fresh project, it's immensely enjoyable to get into the spec -> code -> test -> repeat cycle. If you're at all hesitant about getting into them feel free to go browse the source of my specs. I only spent a little time on it last night but already starting to see progress - a lot of the schema is getting cleaned up as a result of the specs. Here's the doc out put so far (which is about a fraction of what the finished specs will look like !).

Order when creating a new order
- should be able to instantiate
- should default to draft status
- should be able to prefill an address
- should have a default price type matching customer price type
- should calculate return 0 dollars
- should throw an error that it doesn't have line items
- should be able to be edited
- should be able to have an order line added

Order when finding existing order
- should have id = 1
- should have a purchase order number
- should have 3 order lines
- should have a billing address
- should have a customer

To get the specs running. 1. Grab a latest copy of xchain from subversion http://xchain.googlecode.com/svn/trunk/. 2. Dump all databases, then create, and run migrations. 3. Install rpsec using instructions from here 4. Run rake rspec 5. You should (at time of writing) get 13 examples with 1 failure (to work on!) By the end of the weekend there should be a healthy amount of specs in there and fair portion of the model structure of orders, pricing, customer management done. Heres a sample chunk of code

require File.dirname(__FILE__) + '/../spec_helper'


describe Order, "when creating a new order" do
  fixtures :orders, :order_lines, :customers, :addresses, :addressables, :products

  it "should be able to instantiate" do
    @order = Order.new
  end

  it "should default to draft status" do
    @order = Order.new
    @order.order_status_id.should == 10
  end

  it "should be able to prefill an address" do
    @customer = Customer.find(1)
    @order = Order.new
    @order.should respond_to(:prefill_address)
    @order.prefill_address(Customer.find(1))
    @order.billing_address.should eql(@customer.addresses.default_billing.address)
    @order.billing_city.should eql(@customer.addresses.default_billing.city)
    @order.billing_postcode.should eql(@customer.addresses.default_billing.postcode)
    @order.shipping_address.should eql(@customer.addresses.default_shipping.address)
    @order.shipping_city.should eql(@customer.addresses.default_shipping.city)
    @order.shipping_postcode.should eql(@customer.addresses.default_shipping.postcode)
  end
end

If you want an introduction on rspec follow your nose to either the rpsec docs (which are fairly self explanatory) or if you're the visual sort the head on over to http://peepcode.com/products/rspec-basics for a screencast (disclaimer, haven't watched it, but judging on Peepcode's previous efforts it should be good).

Read More

Flex vs HTML vs Time

08 August, 2007

The old simple triangle of time vs features vs quality has reared it's ugly head again. After one particularly unproductive weekend I've made the decision to place a hold on the Flex interface for XChain, in favour of a raw HTML interface, sprinkled with AJAX. I personally hate the decision, being enamored with Flex, I don't want to make it, but I look at the forward progress I've made in the past couple of weeks and it's been more or less stationary. I'm not trying to deliver the 'richest' interface possible, I'm going to deliver a working application. What impacts my client most, is that they can get their job done. Granted I am learning Flex, and grappling with the Cairngorm/No Cairngorm decision. I decided to go ahead with Cairngorm, particularly after reading the usual tales of woe 'i decided not to use it, now I've rebuild my app and am using it..'. However holy sh-t do you have to produce a lot of code to get things done, okay there are code generators out there, but still. For a pet project this blows out the window the time required to do the job. Sure if this was a 40hr work week project I'd be writing a completely different post right now. This makes me appreciate the elegant nature of Ruby and Rails™ so much more. It just gets out of your way and lets you get on with producing productive code. In just one hour I can do so much more. Firing up textmate I feel instantly at home. Is this a language familiarity thing, or a complexity problem, or am I using the right tool for the right job, within the given constraints, (probably not). I had a big discussion about it with a colleague at work, and it always boils down to trade-offs and compromises, there's no one magic silver bullet (unfortunately). Rails is fantastic at backend work, and helps some with front end work, Flex has some great time savers, rich interface components like datagrid which are cake to wire up and get working - but then you're spending a tonne of time on event and ui management. Where is the happy median ? Something like a super rich js framework ? What am I sorely missing from flex in going 'back' to HTML ? - Rich components - Consistent styling - Reduced network traffic A random thought floating through my mind is to publish it in AIR, that way I can still use an HTML interface hooked up to my back end, but a few extra features that might be very useful (drag n drop support, offline storage). More to investigate.. Grumpy but moving forward.

Read More

Open Source Rails & Flex eCommerce Application

17 July, 2007

[Announcement] Rowan Hick Consulting, Canada and Ron Hanley of Fastmount LTD, New Zealand are pleased to annouce that their new Rails/Flex/MySQL eCommerce application will be released to the community under an Open Source license. The application, is a successor to a PHP/MySQL based application developed by Rowan Hick and James McGlinn of Nerdsinc Ltd New Zealand.

After nearly 2 years in production, with the advent of Rails, Flex, and the rapidly growing business needs of Fastmount, the current application no longer meets the business needs of Fastmount. We made the decision early this year to re-write a new application and have been developing requirements for the application as well as evaluating technologies. The application is a business to business eCommerce system. Allowing a marine manufacturing company in New Zealand to service it's agents, distributors and customers world wide. The existing application facilitates order management from creation through to shipping tracking, along with customer management and some reporting elements. Why are we open sourcing ? We made the conscious decision that we don't want to sell the application, as such being closed and proprietary we gain no extra business value by keeping it internal (this doesn't preclude the possibility of a hosted version being provided down the road). The application contains no proprietary information to Fastmount Ltd so there is no harm by open sourcing it. Having done a number of eCommerce solutions, the problems faced and solutions tend to be very similar regardless of domain. Thus the app's tend to look very similar. Why reinvent the wheel, over and over again? My personal vision is that a vibrant community will flourish around the application. If it can become an option for people when putting together an eCommerce solution then I would be ecstatic. Currently I haven't seen an active Rails based open source eCommerce engine out there so there's hope that this may become one of many possible standard 'engines' for people to use. Through our background in the widget ordering domain - solving business problems beyond the simple shopping cart such as; multiple price catalogues, multiple currencies, product/ package combination, agents, sales by regions etc - this may help to be a learning tool for those who aren't familiar with the problems at hand, introducing real world solutions beyond your standard learning materials and tutorials. Also by opening it up, and allowing public scrutiny will likely ensure that a higher standard of coding is reached within the application - there's nothing like judgement from your peers to keep those nasty kludges out of the codebase. Why Flex ? Flex, does at first glance seem to be an odd coupling with Rails in terms of philosophical approach. However as a business tool, this application needs to work perfectly, regardless of browser incompatibilities. In my own opinion, the time saved by not having to deal with these issues, along the extra interface richness granted by Flex, warrants the extra upfront time in creating the Flex interface. What should be noted here is this application is more of a business to business, rather than business to consumer type system - thus we can expect less casual browsing/ordering as in the case of a product catalog/ecommerce app versus a very defined business process for ordering. Having said all this, whilst the app has a Flex front end by using some Rails niceties there will be no stopping anyone developing an HTML front end for the app (infact the app will already have some front end work in HTML), so the core Rails application will become the engine and any various front end(s) that may appear can be bolted on. We're using a REST based approach to facilitate this. Roadmap Current Status: Initial development of Order management stories; Creating, editing, listing orders and customers. Evaluating implementing microframeworks for the Flex front end (Cairngorm or Model Glue Flex). Evaluating communication methods (HTTPService, WebOrb, RubyAMF). Release 1: Production ready system - Revamp of existing system in Rails and Flex, all existing user stories maintained. Streamlined order entry system, customer management, order payment processing (via ActiveMerchant), shipment tracking (via UPS). Release 2: Customer Relationship Management enhancements Release 3: Inventory Management, manufacturing enhancements. Community Release The application will be released to the community under an Open Source license (license to be decided), the only caveat from our production system will be licensed assets (such as icons) stripped out for community release with placeholders for people to find their own. I haven't as yet investigated a trac (or trac like system) that's impervious to spam, so for any community members that have any ideas reading this post feel free to drop us a comment. This will likely happen in the next month. Community Contributions We will welcome contributions and commit back into the core, so long as they don't negatively impact core functionality. Process as yet undecided. To ensure fair attribution - the credits page of the app will include your name as a contributor. Whatever license is decided upon will require that any modifications are publicly available as open source. Share and share alike principles. The Name? Undecided - if you want to throw out an idea feel free! Keep Informed All announcements will be made here on this blog. Keep informed, keep your RSS readers locked to http://feeds.feedburner.com/rowanhick In closing I'm personally very excited about providing this to the community and hope good things will come out of it.

Read More