Structured, yes or no?
-
Try something like a Trello task board. If your project is hosted on GitHub, there's a Trello add-in that will allow comments during commits to become tasks. Here's a sample board New Requests Requests being worked Requests being tested Requests completed This will give both of you the ability to see what's in queue and give your friend the structure he needs.
Yeah, it's probably going to be something like that. Done that before and works pretty well.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Think of the addition of structure as simply the next step in your evolution as a developer and businessman. It's inevitable.
The difficult we do right away... ...the impossible takes slightly longer.
I know you're right :sigh: Just have to get it out of my head and into some system or another. Kanban has been mentioned a few times in this thread, probably going to be something like that.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I can see why you wouldn't care if the customer is paying anyway. It's probably a personality thing. Like your colleague, I don't like being yanked around in one direction, then another. I would tell the customer that churn has a cost and suggest that we work together to better determine the requirements in advance. If they didn't want to do that, OK, they're the customer. But not one that I'd gladly take on again.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
I don't like being yanked around in one direction, then another.
I don't see it that way. Obviously, my client doesn't really know where they want to go, or they do, but something changed. I try to support them the best I can and if that means going from one direction, then another, that's fine by me. And sometimes I simply tell them "I want to do that, but I'm also doing that other thing for John, so you should probably get together and work out your priorities and then get back to me." Recently, I had to tell a client "look, two weeks ago you said this thing, which is what I did. Now you say another thing and I have to change it again. We really should prevent this in the future..." But you know, stuff like that happens in business, things change, priorities change, people change. Also, I charge by the hour, so it's all paid time, which greatly helps :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I beg to differ. Money is not the only reason I write code. Another reason is the satisfaction of knowing that people find it useful and are using it. Basically, I'm happy when my client are happy with what they paid for. This is also a good way to ensure repeat business.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
My client is so happy they said they'd prefer to ditch some really large suppliers in favor of me. Unfortunately, that's not really an option right now. I had two projects where a customer really didn't use what I wrote for them and that just sucks (although they did become a repeat customer and are now using another system I wrote and they're now even asking for yet another!). They can be using your software to full satisfaction and still change priorities though.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
It's basically constant changes, shifting priorities, loose deadlines (if at all), etc.
No offense, but I would not want to work with someone like you. That sounds like a lot of unnecessary stress.
Being in a very similar position, I'd agree it can be stressful. But most of the time, it's just "interesting" whilst occasionally "exciting". Unfortunately as two of my clients are in the same industry, their seasonal swings coincide and that makes February and August in particular quite pressured. But because I know that, I can prepare them and get one of them at least thinking a couple of months ahead of the other. What it does mean is that whilst I can usually concentrate on one particular thing for up to a day, I frequently chop and change so there's no chance for boredom to set in. I'm not away from a bit of code for long enough to forget what I'm in the middle of, and frequently a break and a look at something different will allow an answer to some complex problem to just pop into my head, which doesn't happen so easily if you're focussed on it for too long. The only time it gets really confusing is if an end-user phones me up with an issue (which I discourage, as I prefer to work funny hours). Then it can take me a few moments to work out which client is involved and we can be at cross-purposes briefly. Worse, there's one service supplier I liaise with who supplies services to TWO of my clients... :doh:
-
Gerry Schmitz wrote:
then he should be an analyst too
Why? He isn't, he just makes pretty front-end designs (and implements them).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I'd hope that the front-ends aren't just pretty, but functional too. That means understanding how a potential user will use it, what the thought process of the user will be, what the key items of information are etc. If you as project leader need to explain every single aspect of the UI then all they're really doing is choosing a colour scheme and font. I would want a dedicated designer to be doing a lot more than that, like suggesting field sequence, types of controls for various pieces of information, availability of visual cues like icons, mouseovers and graphics etc.. etc.. Ideally a designer should understand the business process, the reason for each item on screen, the users' skill level (familiarity with the interface) etc. and then analyze that to come up with the best solution. So maybe not need to be an analyst in the traditional sense, but certainly more than "just" an artist and HTML/CSS expert.
-
I'd hope that the front-ends aren't just pretty, but functional too. That means understanding how a potential user will use it, what the thought process of the user will be, what the key items of information are etc. If you as project leader need to explain every single aspect of the UI then all they're really doing is choosing a colour scheme and font. I would want a dedicated designer to be doing a lot more than that, like suggesting field sequence, types of controls for various pieces of information, availability of visual cues like icons, mouseovers and graphics etc.. etc.. Ideally a designer should understand the business process, the reason for each item on screen, the users' skill level (familiarity with the interface) etc. and then analyze that to come up with the best solution. So maybe not need to be an analyst in the traditional sense, but certainly more than "just" an artist and HTML/CSS expert.
Yeah, we've had some talks about that. He mainly designs consumer websites, but for this we had to pick function over form a couple of times. He wasn't pleased about that either :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
What are the preferences here?
Most of the places I've worked followed ISO 9001[^] standard which has strict requirements for planning and documentation. There really isn't much of a choice for some people. In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
Randor wrote:
In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
No, that is absolutely not the case. I run a one-person consultancy/development business and it achieved certification[^] at the first attempt in 2007, I believe one of the first 50 such micro-companies to do so in the UK. I passed external audits in 2008 / 2009 as well. Working with the Professional Contractors Group as it was then (now IPSE[^]) we (me and the company!) were given an outline structure for our quality system, plus some (quite a small number) of template documents. I admit it took me quite a long while to get my head around the concept of the system, but it eventually dawned on me that it was just a document change control system. (It was actually hosted on a SubVersion server). The process of working out what the company actually needed was very enlightening and brought about genuine improvements for me and my clients. The initial certification process was tough, as expected. External inspectors went through everything and needed to see evidence that the systems were in continual use. However 90% of the admin "burden" related to managing the limited company, rather than to actually doing any consultancy / development work. By choice I extended parts of the quality system to cover that (around issues like implementations, disaster recovery and backups in particular). I had hoped that having ISO9001 would open up doors to new clients and allow for rate increases. As it happened, shortly after gaining certification I also gained a major client who gave me as much work as I could cope with, and at silly (high) rates. Contact with him brought in many other clients in the same industry and I was turning work away at one point. When it came to renewal of certification I didn't bother; I had dispensed with some parts of the quality system that were adding no demonstrable value, but continue with others to this day. I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff! :-D
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Since beginning my work with legacy code I have appreciated order and structure much, much more. One of the first things I asked for (out of need) was a style guide, which I got (after a fashion), and next was to refactor the code to properly nest so that I could collapse bits that I didn't need to scroll through to get to the bit I needed to work on, which got a solid (and well deserved) 'no'. We have just begun to use sprints and a loose sort of scrum to work through the many updates, and I think it will be very useful in 2 important ways: user story and dod, and documentation. Making clear the definition of done is a huge help to avoiding rabbit trails, and having a product backlog that I can add to means that those trails can be documented for future sprints. Documentation is a thing that has been sorely lacking in our product, so this micro documentation on each task could potentially be pulled together into a cohesive whole. It might be pie-in-the-sky, but I'm the hopeful sort. I also like being able to see the product backlog and the things being worked on in the current sprint. We use asana for the job so it's all shared - we see it all. It makes me see how my little piece of the puzzle will work toward a bigger picture that I can now better see as well. I despise being kept in the dark where vision is concerned. I need to know what we are aiming for to both do my best work toward that vision and feel like my work matters.
-
I think your post is talking about two different things. The first one is process. You don't need guidelines or rules to follow until something bad happens. Then you put something in place to reduce the chances of it happening again, even if working alone. The second one is stability. I would also get annoyed if priorities were constantly changing. It's also not an effective way to work when you often have to drop one thing for another. Returning to where you left off takes time. And if you never return to it, you wasted time on something that wasn't needed. The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
TNCaver wrote:
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
Exactly this. I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" :wtf: I'd just sit there and pretend to be working. Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote:
there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't! However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that. I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I could not agree more. I have a client that doesn't know what he wants until he sees what I have done. AND, any new need that pops up for his business, I have to drop everything and get that done. :omg: Very frustrating. I have to keep an Excel spreadsheet to keep up with what is done and what is not!
ed
-
lmoelleb wrote:
but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool."
I'm really not the only one saying that and I think many people here would agree with me. Actually, I believe one of the writers of the original manifesto said something along the lines of that it was meant to grow more agile, but teams are now stuck in their scrum ways and holy two-week cycles. I think it's so hard to implement correctly because it's based around change and many people don't react to change very well. I've literally been in the situation where we were two days into a sprint when management came in and said, "things changed, we don't need what you're doing now, we need that other thing." And the team was like, bad luck, we're finishing this sprint anyway because that's what we committed to, and then start on the work you need. That's two weeks wasted! Or how about, this story has a very high priority, but we don't know if the business wants the button red or green, so we'll have to refine it further and it'll have to wait for the next sprint. That's not adding value, that's just mindlessly clinging to some process to the point where it does more damage than good. Two distinct teams by the way.
lmoelleb wrote:
Kanban is a known "lighter" alternative, but it might still be too rigid for you.
Kanban is actually fine! Not doing it now since I'm alone most of the time, but a good one for working with that designer. I'm working on growing the team and I definitely need something like that.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Of course many will agree Scrum is too rigid. Everyone who needs something less rigid that what Scrum gives them. Rigid or flexible is a relative measure. Stop treating it like absolute and assume something is "too rigid" or "too flexible" for every situation. It is fine you say "Scrum is too rigid for what I need - or "Scrum is more rigid that what I use". That is very likely to be the case. And if your anecdotes makes you believe "that is how scrum is", then you have no clue what Scrum is. You have seen someone doing something they do not understand and based on this, you now think you understand Scrum is not flexible. Both your anecdotes are 100% clear violation of the agile manifesto. Scrum and other agile methodologies can't fix incompetence... It's been a while (years) since I last abandoned everything in a sprint - but I have of course been in situations where it happens - and you just do it. Basically you remove any story that it no longer makes sense to work on no matter where you are in the sprint - and if that is all of them, then you remove all of them. Once you have no stories left, you have two choices: Start a new sprint, or pull in some stories in the current sprint. Do whatever works best for the team in the situation. If it happens now and then, no big deal. If it happens often, it is a sign Scrum is being applied in the wrong environment. Some more anecdotes to add to yours: Time since we accepted a story even though it was not ready for grooming: 15 days. It was clearly the priority, so the planning was longer than usual as a lot of things had to be discussed. Time since we have accepted a new story into a running already committed sprint: 3 hours.
-
I have had branches waiting for weeks or even months for review and release (this was before scrum), and they do not merge easily by that point - and as you said, going back into that code after such a long time is a churn.
That's despicable. For many years, the products I worked on used a proprietary code repository that dated to about 1980. A group owned each file, and one of its members had to open it for you if you needed to change it. You could work on it privately, but you'd ask for it to be officially opened once your changes were reviewed and you were ready to commit. Once the file was open, you'd commit your changes quickly so that anyone else working on the file could synch with your changes and ask for the file to be opened for their changes. Any significant delay in this process would get escalated to move things along. It worked quite well, though I can see it being a problem in open-source projects where escalation isn't possible.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
That's despicable. For many years, the products I worked on used a proprietary code repository that dated to about 1980. A group owned each file, and one of its members had to open it for you if you needed to change it. You could work on it privately, but you'd ask for it to be officially opened once your changes were reviewed and you were ready to commit. Once the file was open, you'd commit your changes quickly so that anyone else working on the file could synch with your changes and ask for the file to be opened for their changes. Any significant delay in this process would get escalated to move things along. It worked quite well, though I can see it being a problem in open-source projects where escalation isn't possible.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Ours is similar in structure, if not in timing. We each have our own repository with our own branches that we can push to the main repository when ready. They are then reviewed, any repairs made, and then merged with the development master and pushed live by the lead. I 'can' push things live, but only in 'emergency'. Our bottleneck is that we have only one reviewer and he's also an equal part of the dev team. So pushed branches got forgotten. I am hopeful that the sprint/scrum process will eliminate that in future.
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Curious... Have you codified your areas of influence? Are there any limits on what you can arbitrarily change that affects this person? Typically, in these cases, we separate the resources and isolate their dependencies. So, you can have the freedom to change, within a framework agreed upon, so the other person has some solid footing. You clearly brought them in for a reason, and working to leverage that should be the goal. At the same time, I understand where you are coming from. We had someone refactor code (correctly to clean it up), but it impacted ~20 of other projects, a handful of which, were being actively developed. The resulting merges wiped out the value of the changes. Adding real costs to other peoples assignments. Which, to me, simply means... It is about communication and properly splitting areas of control... Put yourself in their shoes, if every day, you woke up, and you were having to rework everything you did for the last couple of days, because they were so "dynamic"... It wouldn't be long, before you would be better off waiting to see what tomorrow will bring...
-
Ours is similar in structure, if not in timing. We each have our own repository with our own branches that we can push to the main repository when ready. They are then reviewed, any repairs made, and then merged with the development master and pushed live by the lead. I 'can' push things live, but only in 'emergency'. Our bottleneck is that we have only one reviewer and he's also an equal part of the dev team. So pushed branches got forgotten. I am hopeful that the sprint/scrum process will eliminate that in future.
The main difference in our processes seems to be that, once you push, there's no need to merge. You've been working off the latest version, so your new version fits right in. Anyone who was working privately on the same file then has to synch with your changes before they can push. This relieves code owners of the task of having to merge incompatible versions.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Of course many will agree Scrum is too rigid. Everyone who needs something less rigid that what Scrum gives them. Rigid or flexible is a relative measure. Stop treating it like absolute and assume something is "too rigid" or "too flexible" for every situation. It is fine you say "Scrum is too rigid for what I need - or "Scrum is more rigid that what I use". That is very likely to be the case. And if your anecdotes makes you believe "that is how scrum is", then you have no clue what Scrum is. You have seen someone doing something they do not understand and based on this, you now think you understand Scrum is not flexible. Both your anecdotes are 100% clear violation of the agile manifesto. Scrum and other agile methodologies can't fix incompetence... It's been a while (years) since I last abandoned everything in a sprint - but I have of course been in situations where it happens - and you just do it. Basically you remove any story that it no longer makes sense to work on no matter where you are in the sprint - and if that is all of them, then you remove all of them. Once you have no stories left, you have two choices: Start a new sprint, or pull in some stories in the current sprint. Do whatever works best for the team in the situation. If it happens now and then, no big deal. If it happens often, it is a sign Scrum is being applied in the wrong environment. Some more anecdotes to add to yours: Time since we accepted a story even though it was not ready for grooming: 15 days. It was clearly the priority, so the planning was longer than usual as a lot of things had to be discussed. Time since we have accepted a new story into a running already committed sprint: 3 hours.
Look, I get what you're saying and we mostly agree with each other. I know scrum, I know what it's supposed to be, and I know how different teams implement it differently. All I'm saying is, I generally don't like the implementation, whether that's because people are incompetent or scrum is too rigid/time-wasting for my tastes is not really the issue. Besides, a big part of scrum is that you involve your clients and that's really the last thing my clients want (and also the last thing I want as my clients know absolutely nothing about software development or even what they want/need). Doing scrum by myself doesn't really make sense and doing scrum with a designer who just gets a bunch of separate assignments also doesn't really make sense (to me, at least). I have one larger customer who has their own IT department where we use a kanban-like approach (although not for everything). So let's agree to agree, or disagree, whatever makes you happy :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Curious... Have you codified your areas of influence? Are there any limits on what you can arbitrarily change that affects this person? Typically, in these cases, we separate the resources and isolate their dependencies. So, you can have the freedom to change, within a framework agreed upon, so the other person has some solid footing. You clearly brought them in for a reason, and working to leverage that should be the goal. At the same time, I understand where you are coming from. We had someone refactor code (correctly to clean it up), but it impacted ~20 of other projects, a handful of which, were being actively developed. The resulting merges wiped out the value of the changes. Adding real costs to other peoples assignments. Which, to me, simply means... It is about communication and properly splitting areas of control... Put yourself in their shoes, if every day, you woke up, and you were having to rework everything you did for the last couple of days, because they were so "dynamic"... It wouldn't be long, before you would be better off waiting to see what tomorrow will bring...
This guy has completely different assignments, most are creating some visual designs without code. As far as code goes, I told him to make a separate branch and do as he must and I'll figure it out later. He's only had to rework his original designs because the customer disagreed with a few minor aspects. And then make some new designs, while still working on old ones, because some priorities changed. Nothing too extreme, I'd say :~
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I could not agree more. I have a client that doesn't know what he wants until he sees what I have done. AND, any new need that pops up for his business, I have to drop everything and get that done. :omg: Very frustrating. I have to keep an Excel spreadsheet to keep up with what is done and what is not!
ed
Yeah, but don't tell them "no!" I'm going for customer satisfaction, they want something and I deliver (well, if it's possible with the means at my disposal, I now have a customer who wants front-row seats for back-row money, that ain't happening). Customers like working with me because I don't have all that red tape, they ask and I deliver. Sometimes not immediately, but always faster than their larger suppliers.
Slow Eddie wrote:
I have to keep an Excel spreadsheet to keep up with what is done and what is not!
I have that too, all teams have that I guess (or a scrum/kanban board).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
