Loading remote modules into AIR application

Well, let me see if I can redeem myself for starting a tech blog and not writing anything in it for 6 months with what I think can be an interesting subject :)

Recently I wanted to load modules into an AIR Application the same way I loaded them into the browser. Sadly for developers that want to accomplish this, there is a slight problem: the module cannot be loaded into the same security sandbox than the app, resulting in a very annoying error: "SWF is not a loadable Module". This happens because...


"due to (...) security restrictions (...), SWF loaded from another domain (...) go in a separate SecurityDomain, which means that it will have its own ApplicationDomain which means it cannot share classes with the main SWF and thus the ModuleManager can’t see the objects in the SWF as Modules." - Adobe Blogs.

So first of all, why would I want to do that if I can:

1. Bundle up the modules into the AIR application and then use the AIR update framework to update everything;
2. or use the standard way of achieving this, which is to download the modules and load them locally, so we have the same security domain.

Well, because:

1. If I have a lot of modules that keep on being constantly updated, the AIR update framework cannot tell if the changes are in one of the modules, or in all of them, so every time I change a line in one I end up downloading the whole bundled application;
2. I have the same application being deployed on the web and desktop, so I don't want to create two loading segments, depending of the client.

So in fact, I really want to use the same mechanics for both AIR and Flex, without using the AIR update framework for the modules. I will always end-up using the update framework for the main application, since there's no other way of updating it, unless I publish a new application manually and tell people to install it. I found Mihai Corlan's tutorial the most helpfull from the ones I've seen, so if you are interested give it a look. In case you're happy to download the modules first and loading them as local files, Adobe also has a guide for that.

So what about a solution?

Luckly, I've read a blog that has the perfect solution for this problem, at least at first sight. Aaron, the blogger,  instead of using the normal combination of ModuleLoader and ModuleInfo, he loads the modules passing in a byte Array resulting from loading the module with the URLLoader and it simply works. You can download the full source code in his blog, since I would just be duplicating and copying this solution. However after some digging me and a friend found why this works and it's in fact documented in the livedocs:

"In AIR, by default the loadBytes() method does not let you load SWF content; it only allows you to load image content. In AIR theloaderContext property of the loadBytes() method has an allowLoadBytesCodeExecution property, which you can set to true to explicitly set allow the application to use loadBytes() to load executable SWF content. The following code shows how to use this feature:"


So everything is ok right?

No! Apart from the obvious problem that you are publishing an AIR application that loads unsigned modules and thus becoming very fragile to man-in-the-middle attacks is the fact that modules loaded this way have full access to the AIR SDK, which means mean people have all your OS available for hacking. Your AIR application might be a twitter client, but if it loads modules this way, you don't have any guarantee it's not doing whatever it wants with your local machine.

So, would I use this solution?

Depends on the application, but even if you trust a signed AIR application, you're still fragile to man-in-the-middle attacks that might inject modules that do the most crazy stuff with access to your OS. So, in the end I would probably let this go and have the hassle of having two loading methods, one for AIR and another for Flex, with signed modules. As tiring as it may be, I'm sure me and the application users are safe.

Still, nice solution in case is you want to pick it up. Cheers for Aaron on this.

Scrum in a nutshell (by myself):

At my current (soon to be previous) company one of my first managers introduced scrum a few years ago. I have to thank him for that because unfortunately a lot of companies in my country do not fully understand the benefits of agile methodologies and if it wasn't for him I would probably know very little about it. When trying to find a job in London, I've noticed during phone and face-to-face interviews that scrum plays a BIG role in the development process. The thing is that in Portugal I see scrum as a "nice-to-have" concept and in the UK I see it as "we-wouldn't-do-nothing-at-all-without-scrum". Well, since I used scrum at my current company I felt quite comfortable when I was interviewed about it.... and how fast did that change!


As a product manager I believed that I fully understood scrum since I knew the roles and responsibilities, I knew the concept of the product backlog, the sprints and the daily stand-up meeting. For me scrum was all about a list of top-level requirements, divided in sprints and we would "talk" about it 10-15 minutes first thing each morning. During the days I was in London, several people in a chair in front of me would ask me something like this:


Recruiter/Tech Lead: Nice, you use scrum! Can you tell me what a user story is?
Me: Humm, user story? I believe I do not fully grasp the concept! (translation: have no idea!)
Recruiter/Tech Lead: Ok, no problem at all! Explain me the concept of velocity then :)
Me: Oh velocity! I am sorry but that is another concept I have not been able to learn while using scrum. (translation: I'm feeling so stupid right now)


Depending on the aggressiveness of the guy the following comment would be:


Nice patronizing recruiter: Lets move on, I believe it was just bad luck on the questions! (yeah right!)
Normal recruiter: Well, we use these concepts a lot, user stories on initial definition and velocity as a very important indicator in terms of planning and development assessment.
Darth Vader recruiter: So you state you understand scrum <sound of the oxygen mask> but you do not know what a user story or velocity is <sound of the oxygen mask>. Do you know where China is on the world Map? Yes? So I guess you would also tell me you are a fluent Mandarin speaker by that fact? <sound of the oxygen mask>.


This leads us to this current post. As soon as I left London I had a to-do list of concepts I needed to give a more detailed look and scrum was the first and one of the few non-flex related. I hope the couple of hours I spent looking further into scrum can help some of you out getting to know a little bit more about the framework and what it offers. All the information I summarize in the following paragraphs are based on a document I strongly recommend you to read if you want full detail on the concepts shown below: http://www.scruminfo.com/downloads/scrum.pdf (merit to the guys at http://scruminfo.com/). I will try to be as accurate as possible in my own understanding of the Scrum framework but the point is to have a more light-weight approach to the process presentation. Please correct me I step on some ground-stone of the concept, but expect a very informal description of all the concepts I try to explain.



Scrum definition: 


Scrum is considered an "agile" process to create a product in the most efficient and fastest way possible by taking into consideration all the classic problems that arise when having different profiles (developer, client, manager), difficulty in defining good planing charts (requirement changes, added features, estimates) and also taking into account factors like the team's skills, location, experience and business logic. I guess that's the bottom line when considering scrum a agile methodology. 

If you don't understand some of the following terms or concepts, just take it easy because they are explained as we go deeper and deeper.


The players:


Product Owner(PO): Usually a customer or a stakeholder which is responsible for setting the product vision, managing ROI, present initial/manage new requirements and their priorite as well as realease planning among others.


Scrum Master (PM): Also known as project manager responsible for ensuring that the team is  correctly following the scrum process, communication between the team are efficient, protect the team from exterior interference and ensure that productivity is not affected. The Scrum master is also responsible for the daily stand-up meeting and to allow the team to self-organize.


Team Member: Can be a developer, architect a tester or other. He is responsible for setting the sprint goal, estimating of requirements, updating work effort, alarm the scrum master of any impediments and of course attending the daily stand-up meeting.


"A scrum team should not exceed 9 people. Small teams are more productive than large teams, one reason is the number of communication paths within a team" - for example, 5 members generate 10 communication paths, 10 members generate 45 paths, assuming that Comm.Paths = [N*(N-1)]/2 where N is the number of team members.


The phases:

1. Pre-game phase (short - the aim is to get approval and begin delivering product):
• Is this a viable plan? Is it worth it? Set-up some numbers, study the problem and figure what the return on investment (ROI);
• Set the Product Vision, create a motivational statement where you state the end-goal, the context, the users, the quality expected and the real life positive return of your work;
• Create a initial backlog, prioritize it, estimate efforts and adjustment factors to achieve it. More on product backlog, estimates and user stories up ahead;
• Choose the sprint lengths, where a sprint is a period of time (usually 4 weeks/20 business days) where we plan out "our work to be done" - user stories;
• Calculate initial velocity, by past experience, prediction or use a small sprint to take a sample. Velocity is updated throughout sprints - more up ahead;
• Calculate project cost and duration. Afterwards we have an estimate that we can present to the product funder/client;
• Do high level architecture and design;
• Identify risks: excellent risk overview at agile101.net;
2. Game phase (takes as long as needed to complete product backlog):
• Do the first sprint planning meeting. These meetings include the Product Owner, Product Manager and Team Members. Sprint meetings are used to set the print goal which should be a loose but objective statement like "Allow users to schedule and edit clinical appointments". With the sprint goal in mind the team picks up Product Backlog Items (PBI) and does what is called "task expansion", e.g., transforming a PBI into a more concrete task that might be analysis, development, testing, design among others. Each task should have a time range between 4 to 16 hours (recommendation) and if its lesser we do task grouping, if its higher we do task splitting. Finally the sprint goal can be adjusted to represent a wider or narrower  objective depending on the hours the initial goal represents on the sprint backlog. Fun fact: and a motivating one, is that hours per day are not 8 but 6 witch in my opinion is much more realistic than assuming that the difference between a human being and a machine is the tissue composition and energy consumption. "No-one is productive for a full day (normally 8 hours) as we take into account personal phone calls, answering emails, meetings and other interruptions.";
• Executing the planned sprint and in contrast with classic project management methodologies the tasks are not allocated to resources by the project manager. Instead the team is responsible for self-management and the tasks are only allocated when some needs to pick something up. From my point of view this is very good for team-building and sense of responsibility, since the structure is saying "we trust you can organize yourselves to accomplish our objective within time";
• Each day the scrum master and team members participate in the daily stand-up meeting that should not take more than 15 minutes and for convenience and practicality should always occur at the same time and place. This meeting promotes global status awareness between members since each one will answer the 3 following questions:
• What have I done since the last meeting?
• What will I try to accomplish until the next meeting?
• What is stopping me from working at full speed (impediments)?
• These are not questions to nail you in any way. This will allow everyone to know what you are up to and more importantly will allow the scrum master to take notes of all the impediments bothering the team so he can properly solve then to maximize team's productivity;
• It's the scrum master responsibility to stick to the product backlog. This is very important in terms of motivation and team concentration. For example, if the client brings a new urgent requirement, good practices say we should give it priority in the product backlog and naturally it will be included in the next sprint. One of the best aspects of scrum in my opinion, it's the commitment and the sense of team goal that is built out of the process. If the scrum master tells the team that the sprint goal is changing with one week remaining that will totally screw up the team's focus and trust in the project management. Only in cases where the impact is completely unavoidable (costs, client damage, project future) we should we change the spring goal;
• If a PBI is not completed even if it's almost done (still lacking tests for example) the item should go back to the product backlog and if priorities are still the same it will most probably end up on the next sprint with a much lesser effort value;
• In the end of each sprint the team will gather to understand what went well, what didn't and how can things change, how is the team's morale and communication. After this retrospective the new sprint is planned and we are also able to see how's the global project duration and cost with the most recent velocity indicator.
3. Post-game phase:
• "The management ends the development process and the product is being prepared for a release. This includes: integration, testing, user documentation, training and marketing material preparation."  in http://www.scrummethodology.org/scrum-phases.html.

User stories, calculating velocity, adjustments and more:


Product Backlog: The product backlog represents the top-level requirements brought up in the initial project definition. The items included should be very broad and non-technical to be understood by every participant. It's a common technique to illustrate Product Backlog Items as user stories.


User Stories: A user story is a very short sentence written in the first person impersonating the the actor (like an use case) , for example:

• As the system I must load scanned images so they are available to the indexing user;
• As the marketing department I want to produce a product brochure to hand-out at our internal conference;

These user stories will be the center of our planning, since when every and each one is accomplished we will have finished our product backlog.


Prioritizing the Product Backlog: Items on the product backlog should have a priority indicator (1-10) where 1 is probably a nice-to-have feature and 10 is business blocker. Items with high priority will naturally fall into initial sprints.


Estimating the Product Backlog: Each item on the product backlog should have a time estimate or a story points estimate. From what I've read people are more comfortable using story points that measure (abstract) size and complexity instead of a concrete time metric. This is supposed to be more maintainable since the complexity and size of an item will much less likely change in contrast with its ideal time. It's also said that human beings are much more prone to do wise complexity/size evaluations than time ones. Planning poker is a fun way to do initial item estimates and you can check it out at http://www.planningpoker.com/ or in the scrum manual;


Adjusting Estimates: Each item estimate is added an adjustment value that takes into account several factors like, complexity, team skills, team location(s), team coherence and communication (if they worked together before) and business know-how. For more detail see Adjust Estimates on the scrum manual for an example and concrete values on all these parameters.


Velocity: Velocity is a very important indicator since it measures team productivity, e.g., what's the our backlog item completion rate. This enables us to tell how much work can we done in each sprint and can be measured in ideal time (hours) or story points. For each velocity value update we get different project duration and cost estimates (makes sense). If I'm traveling from London to Leeds at 50 Miles/hour it will take me X, if I'm traveling at 100 Miles/hour it will take me half the time and the same happens with items on the product backlog (so to say).


Calculating Initial Velocity: Calculating initial velocity is a little bit tricky but I guess its a calculated risk that is mitigated with project evolution and velocity updates based on the completion of product backlog items. We can do this by:

• If the project is similar to a previous project, with comparable team skills and knowledge we can try to figure out an approximate velocity;
• Assume a initial velocity by expanding some tasks based on the product backlog and try to figure out how much work could be done in a sprint;
• Do a smaller initial sprint and get the concrete velocity;

Finally calculating Cost and Duration:

Given a project that we already did all the previous steps, image we came up with these values:

Project remaining (initial) effort: 90 story points;
Initial velocity: 30 story points/per sprint;
How many sprints left: 90/30 = 3 sprints left;
How much does a sprint cost =~ $20.000;


Estimated cost = Money Spent + (Sprints left * Sprint Cost)
Estimated cost = $0 + (3* $20.000) 
Estimated cost = $60.000


In the pre-game phase we would have a value we could take to the funder and stakeholders to approve. Imagine after completing the first sprint we realize our velocity is 40 points/per sprint. 


Project remaining effort: 50 story points;
Velocity: 40 story/ per sprint;
How many sprints left: 50/40 = 1.25 sprints left;
The sprint costs the same (considering simply working hours with full availability);

Estimated cost = Money Spent + (Sprints left * Sprint Cost)
Estimated cost = $20.000 + (1.25* $20.000) 
Estimated cost = $45.000


This would go on and on until the last sprint but you can get the picture.


Last thoughts:

Well this ended-up being a little heavier than I initially planned, but I hate to be cutting off the parts I find interesting. I hope this has helped someone that like me didn't have the full scope on the scrum process. If you found this interesting please read the recommended manual and explore the endless number of sites dedicated to the subject:


http://www.scrummethodology.org/
http://scruminfo.com/
http://agile101.net/
Scrum in 10 minutes (video) (added after Rui's comment)


Now let me get back to my SCJP book :)

Hello

I've been trying to create a blog for some time now in order to share and receive opinions on some challenges using the Flex framework. I have some subjects and concepts I'm kind of eager to share but since those ideas are on the bottom of the chest I will bring you something I'm currently giving some attention (next post).

For what it's worth I would like to convey that while writing in a Blog I seek to fill a learning and sharing platform. I am more interested in strong critics and conflict of ideas since that is probably the fastest and most interesting way to learn. I am here to learn while feeding all of you with ideas and topics for discussion and I hope that can be the way my thoughts are broadcasted over one hundred flex street.