Workshop 8 - Ruby on Rails Workshops Report and Evaluation
Topic objectives
Upon the completion of this workshop, developers or managers should be able to:
• Identify and evaluate the Ruby on Rails workshop series
• Think critically and analytically about what you knew before and after the experiences
• Share and post your Report and Evaluation with peers via the subject forum.
Evaluation and Report
Please answer each question in this evaluation section. In your answer, please consider content/topics presented and the technologies and teaching strategies used during the Ruby on Rails Workshops. Results will be collated and used to modify the workshop series.
This form is just a format guide to you evaluation and report. Thank you for your time to complete workshop 8.
1. List what you consider to be the three strengths of Ruby on Rails workshop series
1. Providing in experience in developing / managing the introudtcion a web application was by far the biggest positive for this workshop series.
2. Allowing students to adopt either a developer or IT manager role was a strength, but does require some refining in how this is done. This allowed someone like myself, with limited programming background, to still gain an appreciation of web application development, but also provide some exposure to IT management considerations.
3. Using a Web application that iis relatively easy to learn is a strength. This allows students, irrepsective of their programming background, to get their feet wet and do some programming, however basic.
2. List what you consider to be the three weaknesses of Ruby on Rails workshop series:
1. Some of the questions were either repeated or were quite ambiguos. Some question weren't even phrased as questions, but rather as statements, making it difficult to determine what was being asked. I believe the content needs to be reviewed. Removed the "To Do", "Challenge Questions", "Focus Questions" and hidden questions in the discussion text and replace with clear, unambiguos exercises for each student.
2. I dont believe that there was another coverage on the IT Managers side for role play. Given I was studying this subject as part of an MBA, my main interest is the IT managers part. I would like to see these roles adopted from teh very first workshop, as opposed to introducing at workshop 5.
3. The files for this subject should be provided on a CD as part of the student materials. Not all students have access to high speed broadband. Some people are still on dialup, or 3G type connections with realtively small download limits and expensive charges. For me, I live in an area where I cannot get a broadband port, and I have 3G internet, but connectivity is sporadic. As such, I wasted valuable hours simply trying to download applications, especially Microsoct SQL Server Express 2008.
3. List what aspects of Ruby on Rails workshop series that you found to be most difficult.
For me, the actual programming was the most difficult, even though Ruby on Rails is relatively easy to learn and navigate. I am somewhat lucky that I am IT savy and was able to figure most things out without too much fuss, however some programming, especially in workshops 3 and 4 had me pulling my hair out for a while..
The actual completion of these workshops is quite time consuming. This, on top of the 16 exercises to complete presents quite a full on work load. Given my full time employment, trying to do exercises on a weekly basis in problematic. I wouyld prefer to see two dedicated assignements rather than the requirement for weekly bloggs. By way of example, I spent my entire Easter weekend completing the Workshops alone.
4. List what improvements could be made to the Ruby on Rails workshop series:
As alluded to above, I would like to see the number of Workshops or questions reduced, and the questions themselves made clearer and less Ambiguos. I would also prefer to see this run as a walkthough tutorial rather than an assessed workshop.
5. 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?
I think that the actual web framework used in these workshops was great. Ruby on Rails is easy to use and well documented and there is a raft of information on the internet to help numpties like me when you get stuck. I think a great improvement would be to run this series as a tutorial, where students are wlakedthrough programming. This would help level the playing field in terms of programming experience, or lack thereof. I believe other web frameworks should also be introuduced. From what I have read, Django is also relatively easy to use, but exposes that student to python. Not sure how this would be done, as time seemed pretty compressed just working with Ruby, Perhaps you could offer a choice of a number of workshops for different frameworks.
6. 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.
I think this aspect was a waste of time for the Distance component of this course. It is difficult to organise teams and find suitable time to work with people in order to develop a product such as a deployment or maintenance plan. These should be conducted as individual assignment. By way of example, for me, I have been away with work 4 out of the first 6 weeks of this course, making it impossible to complete any sort of collaborative effort. This may be a great feature for those who have time, but not practical for those who are busy. Whilst I can see what is trying to be achieved in using blogs and wikis and forums, I think it also adds an additional level of complexity to what is an already pretty full on course. I prefer the KISS principle (keep it simple stupid).
7. Further comments to add?
All in all I enjoyed the Workshop series however I do think that the workload was excessive and I had to kiss my social life goodbye whilst completing these workshops. I would like to see them scaled back and simplified somewhat. I think if the ambiguity in a lot of the exercises was removed, this would probably reduced the workload, as I did spent a lot of time actually trying to work out what was being asked (and I'm still not 100% sure that I have actually answered some questions properly!!!). However, all in all, I believe the Workshop series achieved what it set out to, which was to provide students exposure to web application development and management, but there is definitely room for improvement.
Workshop 7 - End of the Line: production site migration and maintenance
Topic objectives
Upon the completion of this workshop, developers or managers should be able to: • Discuss and choose the Rails production deployment configuration; • Identify and evaluate the ways to take move the development site on your computer to the online production site; • Evaluate and devise how to integrate a new Rails site into an existing or future e-commerce structure; • Conclude the development of the OTBS as a Ruby on Rails application; • Think critically and analytically about the policy for site maintenance and further development. • Share your findings with your peers and examine what the other team is doing.
Focus Question
As either a developer or as an IT manager, what are the options available when deploying and maintaining the Ruby on Rails application online?
There are many options available to deploy and maintain the OTBS. The choise of which options are the most appropriate depend on the knowledge and experience of the deployment team. Ruby on Rails has a number of methods for deployment, as does the vast majority of web developement applications.The company may choose to deploy to an in-house hosting setup. This would mean we would have to take into consideration the cost of hosting equipment and associated maintenance, which could include outsourcing. Aternatively, the company could deploy to an external hosting service which would maintain the hosting equipment.
In terms of the technical methods for deploying the OTBS, there are many options available to the deployment team. Phusion Passenger, which is further dicussed below, is the recommended method of deployment however as IT manager, I would take the advice from developers and the deployment team as these personnel would have greater experience and knowledge of which option would be most appropriate. I see my responsibility as an IT manager is to oversee the deployment of the OTBS from a holistic approach. Having said this, I have conducted some basic research on Phusion for my own edification and some findings are presneted below.
Phusion Passenger is a module for the Apache HTTP Server and nginx for deployment of Ruby applications, including those built using the Ruby on Rails framework.At this time, Phusion Passenger is the preferred way to deploy Ruby on Rails applications, having been recommended by the Ruby on Rails authors. In terms of deployment this is only a matter of uploading application files. No Ruby (on Rails)-specific server configuration required.Phusion supports both the industry standard Apache web server and the fast and lightweight Nginx web server. It allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition. There is zero maintenance and no port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible. It is designed for performance, stability and security. Phusion Passenger should never crash Apache even in case of crashing Rails applications. Phusion is well-documented, for both system administrators and developers. Given that this is the method recommended by the creators of Ruby on Rails, it is certainly the method I would be recommending.
Having said this, there is alway more than one way to skin a cat, and other methods of deployment are as follows. Prior to Phusion Rails was mostly deployed using Apache or nginx with either a built-in or standalone proxy against a cluster of mongrels or thins. This setup is still works great, but it's more complicated to setup and administrate than using Passenger. Another consideration is JRuby which brings Rails to the Java Virtual Machine. This means that you can deploy Rails applications on app servers like Glassfish and Jetty. Finally, Capistrano brings deployment automation to Rails whether you're working with a single server or on a cluster of dozens.
It should be noted however that deploying Rails is only the first step. The second, and very crucial, step is monitoring and maintaining the application. There are a number of ways to do this. One way is to install a monitoring tool or third party application such as New Relic RPM. This involves the installation of a very lightweight plugin within the Rails application which provides access to a control panel that is hosted on the New Relic RPM site. This enables the user to be able to spot and prevent all sorts of issues related to the performance of the application. Alternatively users can maintain the Rails application mannually user the rails console.Through the console the user can inspect the Rails internals to undertake various maintenenace tasks such as tracking down a bug, viewing a list of recently updated records, or even updating a user’s information manually.
IT INFRASTRUCTURE MANAGER’S THREAD (BLUE team)
To Do:
What are the hosting solutions?
There are a myriad of hosting solutions available to host the Ruby on Rails application and these are presented below. In addition to these, the deployment team may also consider a Ruby on Rails dedicated host, which has a more intimate knowledge of Ruby on Rails and greater understanding of the supporting software.Deploying the Rails application using Phusion to one of these Rails hosts would be a low risk way to go as potential complications would be minimised. Examples of these dedicated of Ruby on Rails host providers are Rails Machine.com, EngineYard.com and even an Australian host provider Anchor.com.au .
Free web hosting service: offered by different companies with limited services, sometimes supported by advertisements, and often limited when compared to paid hosting.
Shared web hosting service: one's website is placed on the same server as many other sites, ranging from a few to hundreds or thousands. Typically, all domains may share a common pool of server resources, such as RAM and the CPU. The features available with this type of service can be quite extensive. A shared website may be hosted with a reseller.
Reseller web hosting: allows clients to become web hosts themselves. Resellers could function, for individual domains, under any combination of these listed types of hosting, depending on who they are affiliated with as a provider. Resellers' accounts may vary tremendously in size: they may have their own virtual dedicated server to a collocated server. Many resellers provide a nearly identical service to their provider's shared hosting plan and provide the technical support themselves.
Virtual Dedicated Server: also known as a Virtual Private Server (VPS), divides server resources into virtual servers, where resources can be allocated in a way that does not directly reflect the underlying hardware. VPS will often be allocated resources based on a one server to many VPSs relationship, however virtualisation may be done for a number of reasons, including the ability to move a VPS container between servers. The users may have root access to their own virtual space. Customers are sometimes responsible for patching and maintaining the server.
Dedicated hosting service: the user gets his or her own Web server and gains full control over it (root access for Linux/administrator access for Windows); however, the user typically does not own the server. Another type of Dedicated hosting is Self-Managed or Unmanaged. This is usually the least expensive for Dedicated plans. The user has full administrative access to the box, which means the client is responsible for the security and maintenance of his own dedicated box.
Managed hosting service: the user gets his or her own Web server but is not allowed full control over it (root access for Linux/administrator access for Windows); however, they are allowed to manage their data via FTP or other remote management tools. The user is disallowed full control so that the provider can guarantee quality of service by not allowing the user to modify the server or potentially create configuration problems. The user typically does not own the server. The server is leased to the client.
Colocation web hosting service: similar to the dedicated web hosting service, but the user owns the colo server; the hosting company provides physical space that the server takes up and takes care of the server. This is the most powerful and expensive type of web hosting service. In most cases, the colocation provider may provide little to no support directly for their client's machine, providing only the electrical, Internet access, and storage facilities for the server. In most cases for colo, the client would have his own administrator visit the data center on site to do any hardware upgrades or changes.
Cloud Hosting: is a new type of hosting platform that allows customers powerful, scalable and reliable hosting based on clustered load-balanced servers and utility billing. Removing single-point of failures and allowing customers to pay for only what they use versus what they could use.
Clustered hosting: having multiple servers hosting the same content for better resource utilization. Clustered Servers are a perfect solution for high-availability dedicated hosting, or creating a scalable web hosting solution. A cluster may separate web serving from database hosting capability
Grid hosting: this form of distributed hosting is when a server cluster acts like a grid and is composed of multiple nodes.
Home server: usually a single machine placed in a private residence can be used to host one or more web sites from a usually consumer-grade broadband connection. These can be purpose-built machines or more commonly old PCs. Some ISPs actively attempt to block home servers by disallowing incoming requests to TCP port 80 of the user's connection and by refusing to provide static IP addresses. A common way to attain a reliable DNS hostname is by creating an account with a dynamic DNS service. A dynamic DNS service will automatically change the IP address that a URL points to when the IP address changes.
Will our Rails applications run on a cloud computing service in future?
As discussed above, cloud hosting is a new type of hosting platform that allows customers powerful, scalable and reliable hosting based on clustered load-balanced servers and utility billing. This type of hosting removes single-point of failures and allows customers to pay for only what they use versus what they could use. There has been a great deal of hype about the Cloud computing and cloud hosting of late. Essentially cloud hosting is a very scalable, pay-as-you-go architecture. After examining the hosting capacity and scalability of http://www.rackspacecloud.com I believe that cloud computing is a viable option for Ruby on Rails in the future. Currently many Ruby on Rails applications are developed or utilised by small businesses. Cloud computing hosting service provides a relative low price option for a company to run their Rails applications on the Internet without the large overheads of technical staff and equipment. Interestingly, the are already cloud hosting companies which specialise in Ruby On Rails applications, such as Engineyard (http://www.engineyard.com/), funnily enough termed "Rails in the Cloud".
Can we make a deployment and maintenance plan by team consensus?Add your ideas for policy planning and documentation about production site deployment and maintenance solutions.
The development of a deployment plan and maintenance plan are important activities which take time and resources.Sufficient rigour should be applied to developing these plans to help ensure that the deployment and ongoing maintanince of your web application is relaitvely trouble free. As with most Project Management philosophies the development of such plans assists in bringing about the successful completion of specific project goals and objectives by ensuring the everyone is reading from the same sheet of music.Thankfully there is no requirement to reinvent the wheel as there are many resources online which contain guidelines on developing plans, sample plans and actual plans utilsed for the deployment and maintenance of various applications. The information below presents an outline of a deployment plan and maintenance plan that could be used to deploy the OTBS for either in-house hosting or to an external host provider.
Deployment Plan
Deployment planning can reduce project risk by reducing uncertainty in implementation of system products. Documentation of detailed deployment activities contributes to the success of IT systems by establishing and communicating expectations for all aspects of the activities necessary to get a product to production, including necessary resources. In addition, risks are minimized by contingency planning, including withdrawal or back-out procedures to be executed if problems occur during deployment activities. The below are the main headings of a deployment plan. Each heading is relatively self explanatory. This would form the basis of a plan, which is heading forming a section of the plan, with the relevant detail completed for each area.
1. Introduction 1.1 Purpose
1.2 Objectives
1.3 Scope of Work
1.4 Sites/Seats/Locations
1.5 Assumptions
1.6 Issues
1.7 Constraints
1.8 Dependencies
2 Site Information
2.1 Site Diagram
2.2 System Overview
2.3 Site Preparation
2.4 Site Readiness
3 Roles & Responsibilities
3.1 Project Manager
3.2 System Integrator
3.3 Installation Manager
3.4 Chief Technology Officer
3.5 Hardware Installation Engineer
3.6 Software Support Engineer
3.7 Consultants / Subcontractors / Third Parties
3.8 Points of Contact
6 Technical Support
6.1 Help Desk
6.2 Desktop
6.3 Servers
6.4 Network / Voice / Telecommunications
7 Training
7.1 Training
7.1.1 Training Plan
7.1.2 Training Requirements
7.1.3 Audience
7.1.4 End-user Training
7.1.5 Support Staff Training
8 Installation Considerations
8.1 Safety
8.2 Code & Industry Standards
8.3 Installation Planning
8.4 Weather & Productivity
8.5 Installation Site Maintenance
8.6 Installation Records
9 Installation Process
9.1 Preparing
9.1.1 Validation
9.1.2 Scheduling
9.1.3 Reviews
9.1.4 Communication Plan
9.2 Installing
9.2.1 Common Deployment Tasks
9.2.2 Uploading Deployment Files to the Server
9.2.3 Deploying an Application to Servers on the Same Machine
9.2.4 Deploying an Application to Servers on Multiple Machines
9.2.5 Redeploying or Stopping a Deployment
9.2.6 Un-deploying a Deployment Unit
9.2.7 Changing the Order of Deployment
9.2.8 Migrate to New Environment
9.3 Testing
9.3.1 Use Activation
9.4 Site Monitoring
9.4.1 Monitoring for Defects
9.4.2 Sign-off
9.4.3 Customer Satisfaction
10 Transfer to Operations
10.1 Resources
10.2 Procedures
10.3 Expected Areas of Change
10.4 Transition Activities
10.5 Monitoring
10.6 Help Desk
Test the plan: After the plan is completed, test it thoroughly. Verify all deployment strategies and identify any potential issues. Then update the plan based on test results.
Review and accept the plan: The deployment plan should be finalised before OTBS deployment. All project teams should review and accept the contents of the plan before deployment begins.
Maintenance Plan
IT maintenance is a very broad activity often defined as including all work made on a IT system after it becomes operational. This covers the correction of errors, the enhancement, deletion and addition of capabilities, the adaptation to changes in data requirements and operation environments, the improvement of performance, usability, or any other quality attribute.The Maintenance Plan provides Support personnel with the information necessary to maintain an IT system effectively. This document defines the support environment, roles and responsibilities, and scheduled activities essential for support and maintenance, whether OTBS is in-house or outsourced hosting. As per the below, this is the recommended structure and information to be included in a Maintenance Plan. Again, the headings are relatively self explanatory.
1 Executive Summary
1.1 Background
1.2 Objectives
1.3 Scope
1.4 Relationship to Other Plans
2 System Details
2.1 System Organisation
2.2 Details
2.2.1 Security
2.2.2 Points of Contact
2.2.3 Authorized Usage
3 Support Environment
3.1 Equipment Environment
3.1.1 Computer Hardware
3.1.2 Facilities
3.2 Support Software
3.3 Storage Requirements
4 Project Team
4.1 Roles and Responsibilities
4.2 Training
7 Maintenance Procedures
7.1 Consolidated Unit List 7.2 Maintenance Procedure for Software Unit [x] 7.2.1 Description 7.2.2 Conventions 7.2.3 Verification Procedures 7.2.4 Error Conditions 7.3 Maintenance Procedure for Software Unit [x] 7.4 Maintenance Procedure for Software Unit [x]
Administration, scaling, reliability and integration with existing and future services are issues.
Consider all the business options of both in-house deployment and outsourcing as shown by hosting sites like http://www.engineyard.com/
As already stated above, the deployment of the OTBS is only the first step. Once the system is deployed and operational, it is then required to be administered and maintained to ensure ongoing relaibility. Further, ensuring integration with existing and future services are an issue.
Administration and Maintenance
As stated above and to reiterate there are a number of ways to undertake administration and maintenance of the web application one it is deployed. One way is to install a monitoring tool or third party application such as New Relic RPM. This enables the user to be able to spot and prevent all sorts of issues related to the performance of the application. Alternatively users can maintain the Rails application mannually using the rails console.Through the console the user can inspect the Rails internals to undertake various maintenenace tasks such as tracking down a bug, viewing a list of recently updated records, or even updating a user’s information manually.
Scaling
Scaling of the OTBS will probably not be a concern initially, but as the business grows and the website recieves more and more traffic, there may be a requirement to look at scaling options. Based on my brief research there appears to be some discussion and concern about scalability of Rails. While Rails is not the world’s speediest framework, the supposed scalability issues are very unlikely to be a legitimate reason not to use Rails.Rails makes it easy to get your application running without worrying about any of the performance issues If you ignore everything about performance tuning during the development phase, you’ll still have a working application, and from there you can tune as required. There’s little point in tuning for performance before you have something that is successful for a small group of people. And if you focus on building an optimally scalable site and end up late to market as a result, you’ll have achieved nothing.
Rails provides a rich set of caching mechanisms that can dramatically increase the speed of most web applications. You can typically achieve dramatic performance gains by applying page, action, and fragment caching. And for big sites, memcached is a popular solution. In many cases, these solutions largely take Rails out of the picture for the highest-traffic pages.
Integration
A final consideration is integration with existing and future services. Given the current popularity of Ruby on Rails, integration does not present a significant issue and indeed a simple google search on "Ruby on Rail intgration" reveals a large number of site involving Ruby on Rails integratipon testing with various applications. Given the growing popularity of Ruby on Rails, this is likey to continue into the future.
