Evaluation report 2

Here is my evaluation report for assignment 2 (.mov).  Enjoy!

Below is a transcript:

In the second half of the subject we took our initial workshop learnings and put some more context around them, dealing with deployment, scalability, maintenance and configuration management.  In the readings and exercises we put the pieces together, taking the individual technologies and starting to look at how they interface with each other to make web applications.

One of the themes that stood out for me was the fact that although there are many different technologies and solutions out there, but the basic paradigms are the same.  With CORBA and RMI we saw different methods of doing what is essentially the same thing, and with the emergence of XML as a force, we can now abstract out the differences and leverage all kinds of functionality in new ways and contexts.

There is a flip side to this of course.  Security and concurrency issues add layers of complexity to building and maintaining these applicaitons.  And communicating amongst more people requires the better standards of modelling and documentation which UML brings.

As a user experience professional it has been great to get a better perspective on the possibilities for integration and use of existing systems in new ways.  There is sure to be plenty of work in the next few years making these systems work for their users.

Workshop 8

1. The 3 strengths of the Ruby on Rails workshop series:

1. Dealt with the fundamental philosophy of Rails, not just the technical details: As someone who used to do web development, it was refreshing to get some perspective on the underpinnings of Rails such as “Don’t repeat yourself” and “Convention over configuration”.  These kind of philosophies may be embodied in Rails but transcend specific technologies and will without doubt be seen in future platforms for some time to come.
2. Went to an appropriate level of detail: The level of detail was deep enough to get a good working knowledge of Rails without having to spend an inordinate amount of time trying to debug and configure a more complex application.
3. Used a current, commercially viable platform: University courses often lag too far behind what is really happening in industry.  For example, I had to learn C++ at university in the late 90’s when Java would have been far more appropriate.  Rails is current both technically and philosophically current which provides more value for time spent on the subject.

2. The 3 weaknesses of the Ruby on Rails workshop series:

1. Too much time required for the mark’s weighting: Although the level of detail was good, in combination with the readings and exercise questions I found that the time required to stay on top of the subject was disproportionate to the value in weighting that the assignments provided.
2. Actual level of collaboration: Although the subject encouraged a high-level of collaboration, the actual level of collaboration was minimal.  I posted initial “seed” postings to the wiki for others to update – but even though I was within 3 days of the assignment due date there had been no other contribution to either the wiki or the forum regarding workshop 6 or 7.
3. Ambiguity of questions: I found some of the wording of questions a little ambiguous.  Examples of this were question 2 in workshop 2 and part b of question 1 in workshop 5.

3. Aspects that I found most difficult:

Configuring MySQL was actually quite difficult.  Despite the many web searches that I performed, I couldn’t work out whether Locomotive actually came with MySQL server or not.  In the end I resorted to downloading and installing MySQL independently to get my Locomotive stack up and running, but it took a lot of fruitless reading and messing around to do so.  I have a fair background in web development so I was able to muddle my way through, I must admit that I felt for those who didn’t have the same prior knowledge that I have myself.

Working out how to use an IDE was also a little bit tricky.  Again, I have had experience as a developer working with NetBeans and Eclipse so I was able to work it out – but I’m not sure how those without the benefit of this would have faired.

4. Improvements that could be made to the workshop series:

As mentioned in previous questions, a more compressed set of questions may have been better for the subject as a whole.  Preferably, the workshops would have been left mainly unchanged and exercises scaled back or consolidated into the workshops. Also, slightly more detail could have been provided for those with less hands-on experience – particularly relating to finicky things such as setting up MySQL and connecting it to a Rails instance.

5. Other frameworks

I think that the level of detail given to alternative frameworks was appropriate.  I have worked with a number of frameworks including J2EE and as I’ve mentioned already earlier in the post, I think that Rails represents current thinking both technically and philisophically, which gives it extra value and longevity.  Perhaps a little more contrast could be given against Java or .NET given that these platforms represent the majority of the work done in industry.

6. Use of other tools for collaboration

I was part of the managers group and found that collaboration was minimal.  The use of the forum was restricted to posts directly to Ken or announcements of which group students intended to join (managers or developers).  I think that many found the wiki difficult to use and some additional direction on use of the wiki may have been beneficial.  An example of this is the adding of a new page, which took me quite a bit of messing around to figure out – a note on this could have ensured more and earlier use of the wiki.

A minimum required number of posts is a little heavy-handed but might encourage a higher level of use of the wiki.

7. Further comments

All in all I enjoyed the subject – particularly its ‘hands-on’ nature.  The content was current and practical.  I felt that the workload was disproportionate to the marks it represented, but this could be easily corrected by keeping the practical nature of the subject and adjusting the weighting of assignments to exam.

Workshop 7

This is my own contribution for workshop 7 which I used to seed the wiki entry in the manager’s area – I anticipate that this will evolve as the managers collaborate to produce a final entry.

One of the key factors for any discussion about deployment and hosting for a rails application is its inherent “weak coupling to the details of any particular deployment architecture” (Hartl & Prochazka, 2007, p. 505).  This makes the discussion more about management issues – such as what is easiest for us to administer on an ongoing basis and scale up (or down) when required – than technical details about configuration.  Hartl & Prochazka (2007, p. 506) points at that using Mongrel as the application server and deploying to some flavour of Unix are the “two things that everyone agrees on”.  Although they also state that running Apache in front of a single Mongrel process to start will be sufficient for most purposes, I would argue that for a commercial application such as ours, we can’t afford to be caught short.

The hosting solutions available to use are:

• Host it ourselves
• Host it at a managed facility (such as http://www.macquarietelecom.com/) with our own hardware
• Host it at a managed facility on their hardware
• Utilise a cloud computing service (such as Amazon’s EC2)

The OTBS is a new and ambitious venture which could be wildly successful – likewise the uptake may not be as good as we hope.  Because of this, running our rails application on a cloud computing service would provide the essential ability to scale quickly without investing in additional infrastructure.  Engine Yard’s Solo product provides a managed way to utilise Amazon’s EC2 cloud infrastructure http://www.engineyard.com/solo).

Hartl & Prochazka (2007, p. 510) also make the point that scalability doesn’t only extend to concerns around serving pages but also includes considerations around development and deployment.  Being able to have multiple developers working on the system (both in parallel and over time) is essential – as is tight configuration management.  Having previousy worked as a developer I know that Subversion is the gold-standard when it comes to version-control.  This can be used alongside Capistrano which will provide the configuation management and application deployment capabilities required of a production site (as described at http://www.capify.org/).

Hartl, M., Prochazka, A. (2007). Railspace, Building a social networking site with Ruby on Rails. Addison Wesley Professional.

Workshop 6

This is my own contribution for workshop 6 which I used to seed the wiki entry in the manager’s area – I anticipate that this will evolve as the managers collaborate to produce a final entry.

Rails is an excellent candidate for the Online Taxi Booking System due to its flexibility and scalability.

The flexibility it provides both in terms of development and deployment are invaluable to a rapidly evolving web 2.0 application.  In terms of development, Hartl & Prochazka (2007, p. 2) describe the following features that give Rails the edge as a platform: mapping of database tables to objects, automatic conversion of data models into HTML and back and built-in support for automated testing of data models and web pages.  In terms of deployment, Rail’s database-independent creation and alteration of database tables and its weak coupling to its deployment environment will make deploying much easier and less risky.

Rails delivers high-end scalability by using a ’share-nothing’ architecture, allowing application servers to be added to machines and then machines themselves to be added ad nauseum.

To do a small to medium sized project using the Java platform would require a large configuration overhead (Burd, 2008) which will translate into additional dollar cost to the project both initially in development and then of course repeatedly as the platform is maintained and enhanced going forward.

Although Django offers similar leverage to Rails, it is significantly less supported in terms of documentation and press reference material.  It has also been around for less time, which could compromise site maintenance and future development.

In addition to selecting a platform, capacity planning needs to be done along with performance testing and plans for site maintenance and future development.  I would take the approach of being conservative with usage estimates but be prepared to scale up with multiple servers if required based on real usage data.  Running performance tests will allow us to have a realistic view of the performance bottlenecks in the application and a realistic strategy for scaling it up.

Hartl, M., Prochazka, A. (2007). Railspace, Building a social networking site with Ruby on Rails. Addison Wesley Professional.

Burd, B. (2008). Ruby on Rails vs Java: An expert roundtable. Retrieved May 14, 2009, from http://javaboutique.internet.com/reviews/ruby/

Exercise 26

I have chosen XML and Web services as my paradigm to manage and develop integrated systems.  This approach interests me as a user experience professional as much of my work involves consolidating and integrating disparate systems into cohesive interfaces that meet user needs and expectations.

It was a long time ago in web-years when Jakob Nielsen (2000) predicted the death of the browser and operating system to make way for applications and services delivered over the network, but Google’s Chrome browser is a big step forward in creating the powerful client required to work in Nielsen’s new network-centric world (Carpenter, 2008).

I think that web services promises to deliver the kind of reuse and rapid development that object-oriented methods promised. And as an interaction designer, there will plenty of work to be done understanding these services and designing the relevant user interfaces on top of them.  A rudimentary example of this that I have worked on is Toyota Australia’s Dealer Search http://www.toyota.com.au/dealer) that uses an external web service which returns dealers based on distance from location and corresponding maps.  This is integrated as a seamless interface to those using it from the front end but saved developers a significant amount of time and risk by leveraging the existing service.

I have enjoyed skimming the froth from so many varied topics related to e-systems infrastructure development and hope to be involved in designing the next generation of interfaces that bring their potential together!

Nielsen, J. (2000 June 25). The Network is the User Experience. Retrieved May 12, 2009, from http://www.useit.com/alertbox/20000625.html.

Carpenter, P. (2008, September 2). Google Chrome vs Windows: or why Microsoft should be quaking. Retrieved May 12, 2009, from http://www.9xb.com/blog-google-chrome-vs-windows.html

Exercise 25

2. WAP and SMS for airlines and banks

WAP in banking was severly under-utilised as it operated over speeds of 9,600 baud and for its level of use was prohibitively expensive to maintain.  Internet searches for “WAP” and “Banking” bring up many articles from earlier in the decade about banks abandoning WAP services.  SMS however is gaining more popularity by the day.  I was involved in designing Barclaycard’s secure account services site last year and alerts and updates via SMS was one of the key features.

WAP in the airline industry seems to be mostly replaced with sites targeted to the latest generations of full-screen and smartphones.  Features are kept to services required after booking have been made such as check-in and viewing timetables.  This is due to the fact that browsing on a standard cellphone is essentially a linear experience (Nielsen, 2009).  Nielson also goes on to make the point that sites are better of targeting medium-to-higher-end devices as people will only use WAP for the most compelling tasks.  As for banking, SMS is used to great effect for tasks such as check-in (e.g. Singapore Airlines http://www.singaporeair.com/saa/en_UK/content/before/travelfaq/checkin/sms.jsp).  United Airlines offer flight times and delay status via SMS.

As Nielsen (2009) articulates, mobile experiences today are on par in terms of task failure rates with the desktop web of 1998, although much money and thinking is now being invested into these technologies, it will take time for them to be really embraced as mainstream.

Nielsen, J. (2009, February 17). Mobile web 2009 – Desktop web 1998. Retrieved May 12, 2009, from http://www.useit.com/alertbox/mobile-usability.html

Exercise 24

1. Software agents

Software agents come in various types (Software agent, n.d.):

• Intelligent agents: utilise artificial intelligence to adapt and learn.
• Autonomous agents: self-contained and able to make independent decisions based on internal goals and perceived environment.
• Distributed agents: execute as independent threads on distributed processors.
• Multi-agents: collaborate with other agents to achieve a purpose, often utilising distributed artificial intelligence.
• Mobile agents: moves itself to another machine to continue execution there in order to access resources/information in that environment.
• Fuzzy agents: agents that execute fuzzy logic, interacting with the environment through an adaptive rules-base.

2. Artificial intelligence and statistic techniques in software agents

Artificial intelligence adds the following attributes to software agents (Software agents, n.d.):

• The ability to adapt: reconfiguring themselves to the environment.
• The ability to learn: learning through trial-and-error by introspectively analysing behaviour and success or example and generalisation.

Statistical techniques can be used by agents to more accurately interpret events based on what has happened in the past.  Baysian techniques are an example of this (Markoff, 2000).

3. E-commerce activities in which software agents are currently in use.

Software agents can currently be seen in the following activities (Software agents. n.d.):

• Buyer agents/shopper bots: Amazon’s ‘Frequently bought together’ and ‘Customers who bought this item also bought’ are probably some of the most successful and well-known buyer agents.  Ebay also has a similar module revealing what users doing the same search also looked at.
• Saved fields in browsers which fill out forms automatically and learn new values from your behaviour (facilitate e-commerce by making the checkout simpler).
• Newsites such as NewsHub which assemble customised news sites (e-commerce through advertising).

4. Rocky

I failed to get any other response from Rocky than “I don’t understand that”.  I tried various angles from asking more sophisticated question to simply saying “Hi”.  The only exception to this was when the system prompted me with “Try something like: I”.  I interpreted this literally and typed “I” – I got the response “You are empty handed”.

Software agents. (n.d.). Retrieved May 12, 2009, fromhttp://en.wikipedia.org/wiki/Software_agent

Markoff, J. (2000, July 17). Microsoft sees software ‘agent’ as way to avoid distractions. The New York Times. Retrieved May 12, 2009, from http://www.nytimes.com/2000/07/17/business/technology-microsoft-sees-software-agent-as-way-to-avoid-distractions.html?n=Top/Reference/Times%20Topics/Subjects/E/E-Mail&pagewanted=all

Exercise 23

1. Spiders

A spider is a piece of software that browses the web in a methodical, automated manner.  They can be used for a variety of purposes including copying pages for later processing by a search engine, checking for broken links, validating HTML code and harvesting email addresses for SPAM.

2. Meta-search engines

A meta search engine takes keywords and searches a number of search engines simultaneously for results (University of California, 2008).  Some examples include:

• Clusty: searches a number of free search engines and directories (not including Google and Yahoo).
• Dogpile: searches the major search engines and includes sites that have purchased ranking and inclusion.
• SurfWax: Mixes educational, US government and news sources.
• Copernic Agent: Allows you to select from a list of search engines.

3. Getting a site listed and ranked

To get a site listed by a major search engine you need to either manually submit via a tool such as http://www.google.com/addurl.html or ensure that it is linked to by a site that is already listed.  Site rankings are done via continually evolving algorithms but from the work that I have done in search engine optimisation companies, the most important things are well-structured and semantically correct pages that have clear titles and page heading and large amounts of relevant content.  Link reputation also dictates that the more pages of good-ranking that link to you and the more links you have to other pages of good-ranking, the better your own ranking will become.  URLs are also come into play with clear, legible paths relevant to the keywords getting the most favour.

University of California. (2008). Meta-search engines.  Retrived May 11, 2009, from http://www.lib.berkeley.edu/TeachingLib/Guides/Internet/MetaSearch.html

Exercise 22

CRM, B2B and SCM software.

CRM, B2B and SCM software manage different parts of the business and focus on customers, buying/selling to other businesses and the end-to-end delivery process respectively.  Customer relationship management software’s focus is on tracking and organising a business’s relationships with current and prospective customers (Customer relationship management, n.d.).  Business to business e-commerce programs facilitate the buying from and selling to other businesses.  Supply-chain management software assists businesses in planning, sourcing, making, delivering and managing returns (Wailgum, 2008).

Customer relationship management. (n.d.). Retrieved May 11, 2009, fromhttp://en.wikipedia.org/wiki/Customer_relationship_management

Wailgum, T. (2008). Supply chain management definition and solutions. Retrieved May 11, 2009, from http://www.cio.com/article/40940/Supply_Chain_Management_Definition_and_Solutions

Exercise 21

Class diagram for the shopping cart specifications:

Shopping cart diagram