Ubuntu vs LinkedIn

As the full story unfolds, this would definitely qualifies as an adventure, but not one of mine!

For some time it has bothered me that I can't use LinkedIn.

... That is to say, I can't use Ubuntu when running Linux.

Update: that really should read "I can't use LinkedIn when running Linux", but I do like the effect!

Oh! I can go to the site and log in. However, any query based request, and things just go to sleep.

??? I thought that the web was supposed to be platform neutral!!!

It is neutral, in theory, although try accessing a site running asp and see how far you get on a non-windows operating system. To even the score, using a Redmond produced browser will give you problems with clever styling (prior to IE 8, at least), and no visibility for any svg images (the latter being the case of a 400lb gorilla squishing a perfectly good standard that most other browsers support reasonably well.)

But why? Think 'Silverlight'

One day, I hope the penny will drop that having a non-neutral net is in nobody's interest! So, to get back to the LinkedIn issue.

For once, it doesn't appear to have anything to do with Microsoft conspiracy theories. Nobody, at this stage, appears to quite know just what the problem is!

I have no solution, but I admire the problem!

Happily, there does appear to be a workaround: just tweak the network layer so:

sudo ifconfig eth0 mtu 1360

I tried it and ... presto!

So I'm happy for now! However, I'm not sure which I find more mysterious: the problem itself, or the process that produced the workaround (which you can read more about on this forum)

In The Frame III: Creating a Project

Sorry if anyone's been waiting, with baited breath, for this instalment. I had intended to post once a week. However, life intrudes on these plans. So, while I will try and stick to a weekly instalment, there will be no guarantees.

OK We've decided what we want to do. Now, how do we start going about it?
In this post, I will review what happens in the various frameworks when you create a project:

Rails
$ rails Enchant

This runs a script that generates a ruby project framework for your application under the folder named 'Enchant'. This was the name I chose for this project. Feel free to use something else.

Before proceeding to look at the results, I would like to comment that I long ago concluded that Tolkien had some sound advice for programmers: 'Do not meddle in the affairs of wizards! They are subtle and quick to lead you down the garden path before abandoning you behind the compost heap with all the fairies'.

What I mean by that should become clear when I describe the project structure that rails creates:

• Enchant/
• app/
• controllers/
• application.rb
• helpers/
• application_helper.rb
• models/
• views/
• layouts/
• config/
• environments/
• development.rb
• production.rb
• test.rb
• initializers/
• inflections.rb
• mime_types.rb
• boot.rb
• database.yml
• environment.rb
• routes.rb
• db/
• doc/
• API/
• README_FOR_APP
• lib/
• tasks/
• log/
• development.log
• production.log
• server.log
• test.log
• public/
• images/
• javascripts/
• stylesheets/
• 404.html
• 422.html
• 500.html
• dispatch.cgi
• dispatch.rb
• favicon.ico
• index.html
• robots.txt
• script/
• performance/
• process/
• about
• console
• destroy
• generate
• plugin
• runner
• server
• test/
• fixtures/
• functional/
• integration/
• mocks/
• development/
• test/
• unit/
• test_helper.rb
• tmp/
• cache/
• pids/
• sessions/
• sockets/
• vendor/
• actionmailer/
• actionpack/
• activemodel/
• activerecord/
• activeresource/
• activesupport/
• rails/
• railties/
• Rakefile
• README

Hello? Are you still there? I'm not surprised if you found all that a bit daunting. It is a bit of overhead for a simple 'hello world', isn't it?

Of course, you don't actually have to know the ins and outs of *all* these directories before you start doing some work, but it serves to show that Wizards, while thay may do a lot of useful things for you, become less useful when you actually start having to do your own work, and try to figure out what it is that they have actually done for you. (Look up 'Guru' as an anti-pattern). In fact, this tree has even more detail than I have shown, but I think the point is made, even without drilling further down into the depths of the directories, api/, public/, and vendor/.

Anyway, the folders we do need to concentrate on are:

• app/: this is where the bulk of the application code will be placed. It is organised into sub-folders in a fairly intuitive way:
• models/: for classes describing the application data models
• views/: for classes handling the output displays
• controllers/: for classes that handle the action prompts, interrogate the model, and return the appropriate view
• helpers/: for classes that assist at the small-scale
• script/: this contains a lot of useful utility scripts for maintaining and developing the project. You'll see these in use shortly.
• vendor/: for third party software. By 'third party', I would include common code you develop and maintain yourself for use in multiple applications.

Django

By comparison, the structure that Django creates is laughably simple:
$ django Enchant

• Enchant/
  • __init__.py
  • manage.py
  • settings.py
  • urls.py
  • views.py

Whether this naive setup allows for good scaling, or is only good for naive applications, remains to be seen.

Cake

It is not immediately obvious how to set up a Cake project. Certainly, there is no 'Cake' me a baked project command. There does appear to be an underlying assumption that you operate with one cake application per server, so all you have to do is install Cake and get going in the 'apps' directory. The directory structure of cake appears to suggest this, and is similar to the Rails structure. Guess you have to copy the template to where you want it. (Was I grumbling about Wizards earlier?)

Next... Doing something visible.

In the Frame II: Intentions

The Application:
Having announced my ambitions, I had better announce my intentions: what application shall I write?

My trusty Rails reference is Dave Thomas and David Heinemeier Honsson :'Agile Web Programming with Rails', which describes a simple shopping cart application. A little copycattish to do that again, I think.

Instead, since I am going to be developing the application in triplicate, I shall choose something that caters for multi-user interaction: I shall create a conversation whiteboard.

What this will allow is for each version of the application to interact with each other (in theory!).

Important stuff first
What to call it?

Well, it's a chat application with multiple varieties, so a starting point of 'N-chat' leads naturally to calling it:

Enchant

Analysis
How do I imagine it operating?

Starting with a conversation board, a user can select which of several groups they might like to join.
(There might even be a snatch of overheard conversation to help them decide)
On selecting that conversation, the user then sees a number of views*:

• one for what is typed in
• one for the general buzz of conversation
• a few extracted streams, associated with user.
  

Oh yes, they will probably want to be able to leave as well!

There are any number of refinements that can be added to all this, but I think this will be more than enough for a training exercise (especially if muggins here is going to be doing it in triplicate!)

Design
OK, what we have already suggests a number of design issues:

• two main displays: the main listing, and the conversation area
• A database (which isn't strictly necessary for casual chit-chat forums, but which might prove useful for playback. This poses a small problem in that I don't actually have a database that is accessible online...so we may dispense with that. That would be a pity, since ORM is a major support feature of these frameworks)

Tackling the main listing first, it should handle the following use cases:

• view conversations (default)
• create conversation
• join existing conversation

The conversation space should handle the following, at least:

• add to conversation
• update conversation
• leave conversation

In the spirit of Agile programming, we will leave the list at that, and add to it as time and experience suggest.

*You will note a few mixed metaphors going on here, as I try and cram square pegs into round holes, and describe a visual application for what is, traditionally, an aural/oral activity. This isn't an idle observation: I think it's a major issue of chat sessions, which we will not be solving here)

In the Frame I: Ambitions

After a prolonged absence from this motley collection of tidbits, and faced with a prolonged period of inactivity known as 'unemployment', I have decided to embark on a bit of self-education.

The focus of my interest is going to be web frameworks, and I shall be describing my efforts at creating an application.

The trick is, I shall be investigating, not one, but three:

• PHP Cake
• Python's Django
• Ruby on Rails

They all purport to do the same things, and that is:

• Provide a 'Model-View-Controller' (MVC) architecture for your (web) application
• Provide 'Object-Relational Mapping' (ORM) by which your application can talk to its database.

While these are clearly useful and worthy things (after all, a number of people went to the effort of putting these things together, presumably for a reason) I am going to be taking a slightly different tack, and assess their friendliness, both to the seasoned developer, and to the newcomer who has to contemplate the height of the technological 'entry bar' that a proliferation of applications and their associated buzzwords appear to be doing nothing to keep low.

Tall order? Well, as a former supervisor once said to me, 'In order to develop, you need to exceed your comfort zone.' (It's a pity glass wall wielding recruitment agencies haven't heard that, but that's another story I will not dwell on here.)

My intention is that I shall be developing an application (the *same* application) using each of these frameworks, and describing how my attempts are going in these entries. How technical all this will get remains to be seen.

It may launch careers. It may peter out in an ignominious puddle of dazed confusion.

That is the nature of experiment! Finding out what works.