Monday, July 20, 2009

Evaluation Report

My final summary and elevator pitch is contained at Elevator Pitch 2.

The transcript of the report is as follows:

As our journey investigating the issues surrounding Business Application development draws to a close it is time to reflect on what we have seen and experienced.

The topic series and related exercises has delved briefly into areas such as e-commerce, distributed systems, database and application servers, system security, system design and mobile computing.

The workshop series required the development of an Online Taxi Booking System using the Ruby on Rails framework as a design platform. It introduced the MVC design pattern and DRY principle and pushed the convention over configuration mantra espoused by the Ruby community. At times major frustration and gnashing of teeth ensued, but it all came good in the end.

These topics and workshop series have all added a little to the total understanding required to develop a Business Application in today’s rapidly changing online environment.

Progress along this journey has been detailed in our blog which has proved both useful and enlightening.

Sunday, July 19, 2009

Workshop 7: End of the Line (Part 2)

Well it appears that I was wrong. I have managed to produce an application that integrates booking a cab with an authentication mechanism. However even though I have successfully melded these 2 attributes together the sum of the parts still does not make an appropriate production application.

In order for this application to be production ready a large number of enhancements would need to be developed. This would include the following:

  • save bookings to database
  • allow retrieval of previous bookings so user can review booking history
  • allow for payments
  • have comprehensive test suite
  • etc

Deployment

According to (Hartl, chapter 17) Mongrel is suitable to use as a webserver for Production use with a ROR application. Currently, there are only two things that everyone seems to agree on: Use Mongrel as the Rails application server, and deploy to some flavor of Unix (most commonly Linux). The rest is up to you. One option is to use a shared host. Because of the explosive growth of Rails, there are now many shared host options, and a web search for "Rails shared host" provides a cornucopia of possibilities. If you're deploying to your own server, they recommend running Apache in front of a single Mongrel process to start.

After locating the server, to deploy you need to do the following:
  1. Create the production database
  2. specify the production database details in the database.yml file
  3. migrate the application to production
    rake db:migrate RAILS_ENV=production

(Hartl, ch17) recommends the following to set up a production Rails application:

  • Linux/Apache/Mongrel for deployment
  • Caching mod_proxy_balance and shared nothing and for scaling
  • Subversion or darcs for version control
  • Capistrano for automated deployment and rollback

References
Hartl, M & Prochazka, A (2008). RailsSpace: Building a Social Networking Website with Ruby on Rails, Pearson Education

Workshop 6/7: Application Success

The following screenshots define the application that I developed today after reading RailsSpace and developing as I read:
The home page:

The about page:

The help page:

The login page:

The user hub once logged in:

Choosing to book a taxi:

The user selections from the booking screen. This is where more work would need to be done in a production environment or working application. A booking record would need to be written at this point and the user notified of thir booking number.

If the user selects Boioking History from the hub screen then all booking for the current user should be displayed.

If the user selects the logout option then they get sent here:

The following shows the user registration screen:

Here we see that we have form validation enabled:

This shows a succesfully registered user, has the same effect as a user logging in:

Workshop 6/7: Integrating RailsSpace with OTBS

I have got the RailsSpace application to the point where it should be really easy to integrate what i had done previously with the OTBS.With that in mind
  1. I created a vehicle controller
    ruby script/generate controller Vehicle cabtype bookcab
  2. modified the bookcab.html.erb to look like we did in Workshop 4
  3. Changed the link in the application.html.erb file to point to the vehicle bookcab form


    Unfortunately when you choose the link I get the following error message:

    I would love to continue investigating the issue, but unfortunately I have now developed a visual migraine, and looking at the computer screen is akin to looking at a kalaidescope.
  4. Pregnant pause for 2 hours .....

  5. Well I have my application working. Yee haa! The comment from Karen helped in the end. The error about the unknown route was purely because I had not restarted the server after creating the vehicle controller.
  6. I have managed to integrate the RailsSpace application with the OTBS application we have been developing. See my next post for application details.

Workshop 6/7: Developing RailsSpace

The following are the steps I have taken to develop the RailsSpace application:
  1. ruby script/generate controller Site index about help
  2. Here is where we learn how do undo things.
    ruby script/destroy controller
  3. Change the root mapping in the routes.rb file
    map.connect '', :controller => "site"
  4. Then to ensure that the default routing works we need to remove the public/index.html page.
  5. Modify the pages defined when we created the Site controller (index, about and help)
  6. Modify layouts.
  7. Add navigation and the site looks like:

  8. Add css and the site now looks like

  9. Well now we want to create a user so we need a database. I have create a mysql database called railsspace.
  10. Generate the user model
    ruby script/generate model User
  11. create the user in the database
    rake db:migrate
  12. learn here that we can roll back the database migration by using the command;
    rake db:migrate VERSION=0
  13. Add validation to the user model.
  14. Testing the validation gives the following output
  15. Add magic columns to the model
    ruby script/generate migration AddUserTimestamps
  16. Add user controller to enable us to register users
    ruby script/generate controller User index register
  17. At this point I got a hosting error within APTANA studio that says I couldnt have 2 application using the same host. I have gotten this error before and the only solution I could find was to close and restart APTANA. This worked.
  18. So I now have the following nicely rendered registration page:
  19. Add debugging info so that we can debug easily. Gee I wish I had seen this before. Very nice!!
  20. Continuing on we deal with what happens if a user registers successfully.The following screenshot shows this taking place:
  21. Add the link to the registration page in the application.html.erb file
  22. Add a helper function to reduce ugly code and then review documentation
    rake doc:app
    and then view doc/app/index.html
  23. Clean up the database
    rake db:migrate VERSION=0
    This will clean the database

    rake db:migrate
    This will rebuild the database

  24. I would love to investigate the testing functionality within ROR but due to time constraints I am going to bypass this section. (Here is hoping that this decision doesnt come back to bite me.)
  25. I am now back to where I started the RailsSpace review earlier today. ie I have now created the session
  26. Modify the user_controller so that registered users are automatically logged in.
  27. Change the application.html so that if we are developing we can see what the session variable contains as well. Add some javascript to display individual debug options seperately as required.
  28. Lets add a login template and link the main application screen accordingly.
  29. We can now add a logout page as well and modify the code so that the appropriate menu items appear dependent upon the logged in condition.
  30. Now lets create a protected page
    I added the code "the stupid way" as the book says inside the controller and verified that it worked.
  31. Add nice URL forwarding to protected pages, once user is authorised, by utilising the properties of the request.request.uri
  32. At this point we are all about looking at code refactoring

Workshop 6/7: Reading RailsSpace

Well I think that I made another mistake in developing my application. I didnt read the railsspace text sufficiently. I relied on the learningrails podcats/screencast series to develop the login module. As you will have noticed reading my blog this was in no way successful.

I am currently reading section 6 of RailSpace and it looks like it shows what i should have done to get the login process to work. It is actually debateable at this point as to what i would need to do to get the OTBS to work and utilise the login functionality correctly. It could be that if I implement the session logging capabilities in Section 6 of RailsSpace, that i may actually get a functioning application. But on the other hand, I may find that I am being led up yet another garden path.

In order to investigate whether RailsSpace would in fact revive my application I would be inclined to once again rebuild my OTBS application from the ground up. This goes entirely against the principles espoused by the rails community of DRY or dont repeat yourself (did I actually just break that rule by spelling out the DRY definition?). But considering I am between a rock and a hard place in terms of a functioning application, I feel that this is sctually the best method.

Concurrently with starting with a completely fresh application, I would implement a source code control systems to ensure that I was able to backtrack if and when the need arose.

Well I have just created a new rails application, to see if the logging mechanism within RailsSpace will actually work for me. Following on from the steps is section 6:

  1. Run rake db:sessions:create
  2. This was successful
  3. In config/environment.rb, uncomment the line:config.action_controller.session_store = :active_record_store
  4. Well here was my first problem. There was no such line in the file. So I copied the line from RailsSpace into the file.
  5. Run rake db:migrate
  6. Well this bit worked fine.
  7. Its at this point that I realise that we need to go back to the beginning of the book and actually build an application, because there is currently nothing in this one. So its back to the start of Chapter 2.

Workshop 6/7: My final application

Below are screenshots of my application as it stands:
  1. This shows the main page when you first start the application.
  2. If I click on Log Out the following screen appears:

    This would seem to imply that the user has been logged out. Howver if I simply click on Book Cab

  3. This is the screen that display when the user selects Book Cab. Irrespective of the user being logged in or not.


  4. This is the screen I get if I try to login from the login screen without a valid user being specified.
    This actually implies to me that the session management is working correctly, but I am not getting the expected results throughout the application.

Workshop 6/7: Login Headache

You may have read my rant on the developer forum about ROR giving me a headache. Well here is my expanation of my issue. I have followed the learningrails webcast series for developing web applications, and you may notice that the css that I have used in my OTBS comes straight from them. In webcast 10 and 11 they develop or introduce the sessions controller and include the AuthenticatedSystem. My problem arises from the fact that no matter what i seem to do the authentication controller seems to think I am logged in. Below is a screen shot of my application.html.erb file: Unless I have completely got it wrong, the "logged_in?" is not getting changed, and the session is staying live (so to speak), which really makes it impossible to test my application correctly. If the user is not logged in I dont want them to be able to book a cab. Unfortunately, I always seem to be logged in. So to reiterate what I said on the developer forum(on 8th July):
I am definitely starting to loath the whole Ruby on Rails experience. I have been endeavouring to get something as simple as sessions to work. I am either connected or not. Well that all sounds good. Except for the fact that I am connected when I shouldnt be. Following the learningrails screencasts, I add authentication to the application. I add the before_filter to all the relevant controllers. However when I logout, i stay logged in. AAAARRRRGGHHHH!!!!
The thing that has stood out for me with Ruby, that they said ad nauseum on the learningrails webcast series, developing with Ruby is MORE FUN. Well in my experience NOT is actually more the case. It is more infuriating than anything else I have ever had to program. When it works it is good. When it doesnt my only response is AAAARRRRGGHHHH!!!!

Workshop 7: End of the Line

To deploy an application to production, it must be production ready. Well in successful project world anyway. I have raised some issues in the forums about where we have gone with the OTBS and especially the failings that affected my development process.

My system is far from and never will reach a production ready stage. The reasons for this are many and include the following:

  • lack of source code control
  • lack of testing methodology
  • no interface/linkage for payment mechanisms
  • what is the process that happens after a taxi is booked?

One of the problems that we have endured as developers is lack of a project plan. Reviewing the Workshop material, these are issues that were to be addressed by the blue team in Workshop 5. I am not sure of their progress but they have failed from a project management perspective in that they have not managed user expectations on this project.

It is at moments such as now when upon reflection I feel that I maybe should have chosen the other route and joined the blue team. The questions that have been tormenting me over the last few weeks are exactly the questions posed by Ken for the Managers thread (ie the blue team), but due to time constraints there is no way that these can now be achieved.

But even going down that path we are still in the situation of not having a project manager to set the project on track and to bring it to a successful conclusion.

Maybe it is worth thinking about for future versions of this subject to involve the project management subjects in a combined assignment across subject boundaries?

Monday, July 6, 2009

Workshop 5/6: More Taxi booking system - followup

Must give thanks to Karen's comment. Even though what she said to do was what I had done, the fact that she commented actually triggered the correct outcome for me.

I have got the BookCab form integrated with my OTBS. In order to do this I had to do the following

  1. Move the bookcab method into the VehicleController
  2. Move the bookcab.html.erb file into the views\vehicle\ directory
  3. Change the form action to form_action ="cabtype" instead of "vehicle/cabtype"
  4. modify my application.html.erb file so that the 'Book Cab' link pointed to the correct controller and action.

On the face of it it looks like the variable scope is confined to the MVC that is of interest. In this case it was the cab booking variables in the bookcab view being transferred to the cabtype view.

My next step now is to introduce a login mechanism and enable passenger information to be collected.

Sunday, July 5, 2009

Workshop 5/6: More Taxi booking system

I have just been having a lot of fun.

I thought I would go back into the Taxi Booking system, to improve the look of the site and to look at adding login functionality. This would involve utilising what we had developed in workshop 4 with the changes in workshop 5.

I also wanted to change how I had dealt with the protect_from_forgery error that we all got in workshop 5. I simply hashed out the line, and so everything worked.

Well the idea started out as a good one. Unfortunately, I managed to break everything, so that nothing worked. I changed the routes file so that there were no recognised routes.

Scratching my head for half an hour ensued, until I realised that I had in actual fact hashed out all the route info in the routing file. So message actually made sense. With that sorted out and the taxi details showing again I decided to press on.

My Online Taxi Booking System now looks like

Unfortunately the information doesn't came across as you can see by the following:

I am beating my head against a brick wall at the moment. Possibly mind gone blank syndrome. I definitely need to get back to RailsSpace, for another installment, which might clear things up a bit. In the meantime, I close this blog post with a screenshot of my pages_controller and file structure

You may notice that the Vehicle Controller is empty. I was getting some routing issues and so just moved the code into the pages controller. I am definitely thinking this was the wrong way to go. But that is where it is at the moment.

Update

Well after posting this blog, I had a slight rethink and put the Cabtype method back into the vehicle controller. The views all seem to work, and the cabtype view does get displayed after submitting the booking form. Alas the variables are not being initialised, so the cabtype view is not displaying the selected information. Any ideas anyone?

Wednesday, July 1, 2009

CSS and Ruby

I have just come across this Ruby gem which could be very useful for you all.
http://lesscss.org/
Less is Leaner css. Less extends css by adding: variables, mixins, operations and nested rules.
If you use css then this could be useful.

Tuesday, June 30, 2009

Web 2 communities in action

Mythbuster Adam Savage fights $11,000 AT&T bill with Twitter army Have a look at the following commentry on Computerworld blog: http://blogs.computerworld.com/mythbuster_adam_savage_fights_11_000_at_t_bill_with_twitter_army?source=CTWNLE_nlt_dailyam_2009-06-29

Monday, June 29, 2009

Some very helpful Ruby tomes

I have just going through Workshop 6 and the Topic reading: (Hartl)

This made mention of David Hannermeir Hansens 15 minute blog development presentation. http://media.rubyonrails.org/video/rails_take2_with_sound.mov in the introduction. I watched this (i suspect that Craig had recommended this earlier) and wish that I had seen this earlier in the subject.

Having watched the demonstration, I read (Collingbourne)

I now feel that I have a much better grasp of ROR, because of these references. I have gotten back into the first few chapters of (Hartl) and really wish that this had been recommended prior to Workshop 1. It goes through a nice seemingly simple step by step process for setting up rails, and actually specifies requirements. There is a distinct chance that maybe hindsight is playing a part in my thinking, remembering back to the number of lost hours trying to get a working setup.

However, what really got me to put this missive together was a single line in (Hartl, s2.2.1)

In case you ever need to undo the work done by generate, you can use ruby script/destroy controller . That's certainly a lot easier than deleting a bunch of files by hand.
which clarified in my mind where I had been going wrong in my attempts at building the OTBS. i may well have seen this before, but I don't remember seeing this in the same section as talking about generating the controller. But then again, this may well be hindsight in action.


References
Collingbourne, H (2008)"The Little Book of Ruby"
Hartl, M & Prochazka, A, (2008). RailsSpace: Building a Social Networking Website with Ruby on Rails, Pearson Education

Friday, June 26, 2009

Tuesday, June 23, 2009

Workshop 8: Ruby on Rails Workshops Report and Evaluation

  1. List what you consider to be the three strengths of Ruby on Rails workshop series
    1. Ruby is probably a language that once you "get it" it all falls in to place. The MVC and convention over configuration means that you dont have to go looking in obscure places to find the answers to error situations. It means that application maintenance should be made simpler.
    2. Exposure to the Ruby way of doing things.
    3. ?? Due to the frustration experienced with development and the lack of overall workshop focus I find it very difficult to find anything that would qualify as a strength. Although it is feasible that I could use my experiences in the workshops as a reason not to use Rails as an application development environment

  2. List what you consider to be the three weaknesses of Ruby on Rails workshop series:
    1. There was a distinct lack of focus throughout the workshop series. It seemed to be heading in a certain direction for the first 4 workshops, but then at workshop 5 a complete change in tack occurred. The first 4 workshops should be removed. If you start with workshop 5 and go through the RailsSpace book and develop the OTBS application in conjunction.
    2. The development of the OTBS did not seem to have any real relevance to the rest of the subject matter. The Workshops should be redefined so that the development of the application corresponds to the learning outcomes being investigated in the topics.
    3. Their was little scope for collaboration with other students within the workshops. As I mentioned in an earlier blog their is scope to include a project manager from a project management subject to cross pollinate the learning outcomes for students, and to improve the collaboration aspect.

  3. List what aspects of Ruby on Rails workshop series that you found to be most difficult.
  4. Getting Ruby installed and operational. I found it hard to find any useful installation information initially. I am sure that there is lots of documentation in existence, but asking the right question proved to be difficult. Also the fact that i was trying to install in a windows environment proved frustrating. I resorted to creating a Windows XP VM to host my APTANA development environment. Once the software infrastructure was in place everything was OK.

  5. List what improvements could be made to the Ruby on Rails workshop series:
  6. The workshop series should be redesigned so that:

    • A VM should be developed so that all students start off on the same foot.
    • The references to other frameworks could be removed.
    • All the students have a programming background(?), and as such do we really need to compare looping structures or suyntax of different languages?
    • It has a defined goal with some KPIs that need to be met as students progress.
    • The workshop content should involve aspects of the topic being examined to more closely tie in with the subject objectives.
    • their should be more of a project managed feel about the workshops so that we dont miss our targets

    Free response and reflective questions:
  7. Reflect on your experiences with the other Web framework used in this subject: Was it effective? How can it be improved? Should other Web frameworks be used as well or instead of Ruby on Rails?
  8. My immediate response to this question is what other frameworks? Did we actually use another framework. And if we did when? If this is referring to the few questions that were used in php, then I think it is simply irrelevant.

    The experince could definitely be improved if a virtual machine was provided that had the framework already set up. I dont think that anything of real value is learnt by all students being in the dark and having to install and test various servers and hope that everything works. Everyones machine is different, and so they all have to spend a large block of time getting up and running. A VM would solve this problem by everyone starting off on the front foot.

  9. Did the Developer’s or IT managers Team that you joined after workshop 4 have a preference towards using other tools to facilitate collaboration? Comment on the differences between these use of the sub-forum or Interact wiki tools from your experiences in this subject.
  10. There was little if any collaboration. This is primarily due to the time constraints imposed by the topic Q&A and the workshops. There is simply not enough time to get through the volume of work expected, and collaborate as well.

    The forums were the best spot for eliciting information from other students if required.

  11. Further comments to add?
  12. It may not necessarily seem that I enjoyed the Workshop series. This is not actually the case. I did find that developing in Ruby was enjoyable to a point. However this was generally overbalanced by the frustration felt when things didnt work out correctly. Learning a new language and development paradigm is an experience to be savoured. But it is very easy to be turned off and things to sour when brick walls seemingly appear. The DRY principle is espoused by the Rails community, but that is probably what I failed at the most. I think that my final tally for creating the Online Taxi Booking System was probably somewhere upward of 20. That is I started from scratch in excess of 20 times.

Workshop 7: End of the Line: production site migration and maintenance

To Do: Developers conclude their work with the OTBS and look at the options for deployment of the site. Examine the various platforms/software tools used for deployment such as UNIX environment suggested in the Discussion Notes, Mongrel or Mongrel cluster, Nginx, Subversion or Capistrano (during development stage), JRuby in the Java environment. Which way? The choice is up to you as this workshop present just one option and you may like to use another, such as deploying the OTBS in a .NET or J2EE environment Can you get the OTBS Running in production mode as a minimal production server? Share your success by posting progress comments and links etc to the Developers sub-forum site that has been set up for the Red team.

Workshop 6: Enjoying the Ride: Web framework alternatives, scalability and flexibility

Upon the completion of this workshop, developers or managers should be able to:
  • Discuss and analyse the latest Web framework technologies based upon experiences so far with Ruby on Rails
  • Identify and evaluate challenges and opportunities concerning the use of the latest Web 2.0 technologies and to ‘benchmark’ (compare) other alternatives
  • Discuss and evaluate current Ruby on Rails framework and the alternative emerging technologies.
  • Evaluate and devise scalability, flexibility, capacity planning and performance testing strategies for conducting e-commerce.
  • Deploy Web 2.0 or later technology in their business environments such as the ideas and methods of the ‘RailsSpace’ approach to the OTBS
  • Think critically and analytically when exposed to new technologies.
  • Share your findings with your peers and examine what the other team is doing.
Developers may continue to build upon work with the OTBS using the topic reading to help with user registration and advanced login features from Hartl et al (2008).
  • generate a controller and an action by adding a method(s) to a controller
  • create a view template for each action and to link to actions from views
  • use AJAX to improve the user experience
Share your success by posting progress comments and links etc to the Developers sub-forum site that has been set up for the Red team.

Workshop 5: Part C: Screen layouts and forms processing with text fields, check boxes, radio buttons and multiple list controls

  1. Create a new application called cabs in the same projects directory to demonstrate the use of an active view. > rails cabs > cd cabs
  2. Complete
  3. Create a controller called Vehicle in cabs\app\controllers cabs> ruby script/generate controller Vehicle
  4. Complete
  5. Add an action to vehicle_controller.rb as the method called cabtype class VehicleController< ApplicationController def cabtype end end
  6. Complete
  7. Add a view template - cabs\app\views\vehicle\cabtype.rhtml We will edit this view in later steps but you may like to add your own test HTML code to the view at this stage.
  8. Complete
  9. Save the view and restart the Web server and navigate to http://localhost:3000/cabs/cabtype
  10. Navigated to http://127.0.0.1:3004/vehicle/cabtype
  11. Create a file in the public directory - \cabs\public called input.html
  12. Done this
  13. Edit the vehicle_controller.rb here is a start. The data in each form element in the Rails application can be accessed via its name and a hash called params class VehicleController< ApplicationController def cabtype @data1 = params[:text1] @data2 = params[:check1] @data3 = params[:radios1] @data4 = params[:building1] end end
  14. Done this
  15. Edit the view template cabtype.rhtml
  16. Done this
  17. Start the Web server and go to the opening page of this application at http://localhost:3000/input.html
  18. Did this and had a horrible looking screen. If you just do a cut and paste from a word file the quotes play up just a little bit. This leads to a horrible looking screen rendering. Having done this Craigs mention of this problem comes to light. Should have been a touch more careful, and validated what i copied a bit more. But lesson hopefully learnt. Took but a matter of moments to rectify and have the screen render nicely.
  19. Submit the forms data. What do you find?
  20. I get a rather horrible screen that screams ActionController::InvalidAuthenticityToken at me. This is obviously security related. Looked in Application Controller and noticed the second line "protect_from_forgery".
    Hashed this out.
    Kept getting response, No route matches "/cabtype" with {:method=>:post}
    This led me to change the Submit action on the input form to "vehicle/cabtype"
    Unfortunately this still did not work. After a few minutes of scratching my head I did the brute force approach and recreated the project. Here was the whole COC conversation that happened on the forums all over again. But brute force worked.

Workshop 5:Part B: The active view: passing data from an action too a view

  1. Create a new application called scenery in the same projects directory to demonstrate the use of an active view. > rails scenery > cd scenery
  2. Complete
  3. Create a controller called Demo in scenery\app\controllers scenery> ruby script/generate controller Demo
  4. Complete

  5. Add an action to demo_controller.rb as the method called rubycobe class DemoController< ApplicationController def rubycode end end
  6. Complete
  7. Add a view template - scenery\app\views\demo\rubycode.rhtml We will edit this view in later steps but you may like to add your own test HTML code to the view at this stage.
  8. Complete
  9. Save and restart the Web server and navigate to http://localhost:3000/scenery/rubycode
  10. If I was to follow the script blindly then one of two things will happen here.
    • I have made a mistake or
    • the workshop script is wrong

    If I navigate to the url
    ../scenery/rubycode
    I get the error Routing Error.
    However if I do the logical thing and navigate to
    ../demo/rubycode
    then I get my expected page returned.
  11. Use the Time.now example to pass data from an action to a view.

  12. Modify and save the rubycode action with a value for the time instance variable in the DemoController class in app\controllers\demo_controller.rb class DemoController< ApplicationController def rubycode @time_now = Time.now end end
  13. Done that
  14. Then modify and save the corresponding view template in \app\views\demo\rubycode.rhtml by adding a call by reference to the action’s instance variable: <_br> The time is <_%= @time.now %_> <_br>
  15. Obviously this piece of code is wrong. We should be using the variable defined in the controller @time_now
  16. Restart the Web server and navigate the browser to http://localhost:3000/demo/rubycode Data has been passed from the action to the view as it is done with SQL requests. The instance variables of a Ruby class are available to view templates by referencing the action’s instance variables by name in the view .rhtml template.
  17. The output and the code files are shown below