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

Workshop 5: Part A: Viewing the action

  1. Create the Rails application framework in the projects folder: C:\InstantRails\...\projects\>rails animals

  2. Complete
  3. Running the application on localhost:3000 using the WeBrick ruby server (or Mongrel as alternative) and access via Web browser at http://localhost:3000/

  4. Create the controller to make the application do an action. This is under the controller-action/model-view structure. Stop the WEBrick server each time you edit Ruby classes and then re-start or refresh the views you are testing. Use the Ruby command below: >ruby script/generate controller Mammal The mammal_controller.rb contains just a bare class description: class MammalController< ApplicationController end and the ApplicationController class inherits from ActionController::Base class in the ActionController module under Rails.

  5. Complete
  6. Test the controller by starting the WEBrick server and navaigatibng the browser to http://localhost:3000/mammal Note how the controller name is appended to the end of the URL and that no action resulted because there are no controller methods.

  7. I get the following:
    Routing Error No route matches "/mammals" with {:method=>:get}
    I think this is simply because I coulnt follow instructions and typed /mammals rather than /mammal.
  8. Create an action by editing and saving the mammal_controller.rb class in projects\animals\app\controllers using your text editor to add the method below: class MammalController< ApplicationController def breathe end end

  9. Complete
  10. Start the WEBrick server and browse at http://localhost:3000/mammals/breathe where you will get a “missing template” message since it is missing a view for the breathe method. Rails is trying to connect the breathe method action of the mammal controller to a view, by using the action’s name – breathe. This view template is created as breathe.rhtml and stored in the \projects\animals\views\mammal directory.

  11. Create and save a view in that directory by using a text editor to create a view called breathe.rhtml <_html> <_head> <_title>Breathe Easy <_body>Inhale and Exhale Restart the WEBrick serve r and browse again at http://localhost:3000/mammals/breathe

  12. Browsed to ../mammal/ and got the following message
    Unknown action No action responded to index. Actions: breathe
    So added the action /mammal/breathe and got the expected result.
  13. Try Ruby code and HTML in the action view by using the <%....%> wrapper around the inserted Ruby code. Here are some snippets to try from workshop 4:
    5 + 6 =<%= 5 + 6 %>

    =<% 4.times do %> Inhale Exhale
    <%end%>
    Time is <%=Time.now %>
    The output of this little exercise is

    NOTE: in practise you normally perform calculations in the action (method) and pass the results to the view.