Showing posts with label Ruby On Rails. Show all posts
Showing posts with label Ruby On Rails. Show all posts

Tuesday, 28 August 2012

Railroaded?


(image courtesy of Kino International)
I've just started using Ruby On Rails for developing a pet project.  The reasons for this are multiple:
  1. I want to learn a dynamic language.What better one than Ruby as a starter?  The number of online resources for help is just staggering.
  2. I want to learn techniques from another successful framework. (FubuMVC really opened my eyes to how much better a .net MVC framework should be, so lets widen the scope further)
  3. I simply want to know what all the fuss is about.
 This post is hopefully the first of many, simply observing the nuances, differences in comparison with the .net world and probably an avenue for my frustrations (expletives guaranteed).

 Getting started, I conceded that I would run with the out-of-the-box configuration - I need to learn the Ruby language as well as the framework so I don't want to get bogged down re-configuring it to death before I even get properly up and running.

Out-of-the-box means that Active Record is used for data access. I've never (wittingly) employed the Active Record pattern on any project, but it instantly had me recalling a Chad Myers post  (long, but well worth the read). I didn't agree with everything 100% at the time, and I'm still too green with RoR to make up my mind entirely, but it certainly got me thinking. And if I get nothing else from my RoR exploits then at least I will have been thinking carefully and not just blindly following one single framework.

Saturday, 30 October 2010

Enlighted? Certainly Not At The Flick Of A Switch.

Recently I watched the VSLive presentation on Microsoft's new development technology - Visual Studio LightSwitch - and I was more than a little intrigued (and admittedly a little nervous) at what I was in store for.

Before getting down to technical detail I wanted to mention Microsoft sessions in general.  As I expected from Microsoft, the presentation and the demoes were slick and polished, but I continually can't help but feel I'm being presented to by a couple of marketing guys who have been schooled by techies. I far more enjoy being presented to by an academic than being sold to by a salesman.  Maybe its just me?


OK, so on to LightSwitch.  The main questions I had was: What is it?  and What problem is it trying to solve?

As I say I was intrigued by LightSwitch as I had read some material explaining that LightSwitch was the solution for straightforward CRUD applications (or the CRUD elements of applications at least), that LightSwitch would auto-generate CRUD code.  I have to admit this initially had me excited .
You see, most of the bespoke applications I'm involved in tend to consist of 2 functional aspects:
  1.  the implementation of the specific business domain (i.e. the part of the application specific to support the business process) 
  2. and the maintenance of the supporting data for that business process - the CRUD element.  
Designing and implementing the business domain is the interesting (and dare I say it, creative) part of development process.  The CRUD element tends to be the necessary evil for many applications as it tends to be unimaginative, unchallenging and repetitive. As a developer, anything repetitive I try to automate or design my way round (I usually end up trying to let inheritance and the O-R Mapper take the strain).

Now here was Microsoft apparently releasing a tool to automate this for me.  Sounds good.  However, I still had reservations, namely
  1. Is it easy to integrate the specific, interesting (and sometimes complex) business domain code of your application with the CRUD code auto-generated by LightSwitch?
  2. Integrating and re-using objects is one thing, but is it possible that you can scale such drag & drop solutions?  And what type of architecture am I going to end up with?
Taking these one at a time, Microsoft claim that you can indeed integrate your custom, complex business code easily by generating your  CRUD code, and then simply digging into the C# or VB code generated by it.  Again, sounds good doesn't it? Well, on reflection I'm not so sure as it means you face the same problems that many other code generators create (perhaps T4 templates aside, but thats another blogpost already in the pipeline) in that you have no control over what that code looks like, meaning that your objects may end up in a shape that you don't want, and don't allow you to easily extend.  Then there's the issue of continual refactoring of code.  What happens with LightSwitch when you generate you CRUD code complete with your nice new screens, extend the code by adding some custom business logic, and then discover that you need to regenerate your whole CRUD code again via LightSwitch?  What happens to that expertly written custom business logic that you are so proud of?  Do you have to re-insert it?  Will it still fit?

Moving on to the non-functional questions over flexibility and scalability, again Microsoft claim that LightSwitch allows you to deploy your end solution as a Silverlight app, which definitley gives it reasonable flexibility over the target platform.  The demo also covers how to scale this from being a simple single user executable during development to being a multi-user deployed web app.  Again, the demo makes it look so simple, but I think that is mostly down to the simple demo. In reality, most applications tend to be more complex than that.

All of this aside, the one question that remains unanswered is: who exactly is this product aimed at? Who is going to use it?

The LightSwitch demo host presented a strong case for allowing business users to build their own apps organically, and only when the app graduates from being a single user or department wide app to an enterprise app should us developers get involved.  Traditionally, this has been done using Microsoft Access in its various incarnations, and I've experienced such situations, and I can understand the argument that says the best applications "grow" from this type of root.
So, is this an Access replacement?  Well no, because its a Visual Studio component and business users don't usually have Visual Studio on their standard desktop, but they do have Office, which is why Access had/has such a high adoption rate.
So, then its a developer tool. And here is where that nervous feeling comes from....are Microsoft suggesting .NET developers hand over control of the design and architecture of their enterprise scale software to a code generator?  (Not only that, a code generator that seems to focus on state and not necessarily behaviour at that?!)  Just when we are finally making some headway with .NET being taken as a serious development platform, some innovation, some serious thoughtleaders using the .NET platform and out there being heard, and Microsoft comes back advertising a new way of pointing and clicking your way through your professional career.  I wonder if its too late for me to start learning something like Ruby On Rails?

(thanks to restoreus .org for use of the image)