Guy kolbis

If you are looking for a flash developer with solid knowledge in .NET, I have the person for you...Contant me at:

kolbis.guy@gmail.com

ניתן להירשם למפגש כאן.

After reading Ryan Stewart post about "Differences Between Silverlight Out of Browser Experience and AIR".

I wanted to add some personal experience and notes.

RAD – Rapid Application Development

Another thing to consider is that silverlight integrates well with wcf and web services, that means that building a client server apps is easier. When I tried using Air, I had to write either HTML file or Flash and in order to communicate with the server I had to use Ajax calles or HTTP get requests. It is possible to achieve, but it is less trivial then building the same app with silverlight OOB.

Silverlight OOB & WPF

OOB for silverlight has its benefits over WPF. For instance, consider users that don't have .NET framework 3.5 installed. In order to run WPF app, they will need to download ~200 MB. This is not an option. So, if you want to deliver a lightweight app to the desktop, it only requires ~5 MB.

OOB – Out Of Browser Winodow

One more thing is the OOB window. With silverlight we have no control over the layout. for instance we cannot change the border, the toolbox and etc. It might sound picky, but it can really annoying...

Air on the other hand allows you to customize the window.

Permissions

With that said, I think that the OOB should have the same permissions as Air. Currently it limits us the developers and the companies to deliver great solutions that interact with the desktop.

We recently started to practice SCRUM at Nana10.

I have the pleasure of working with some amazing people:

Alex Agronik, Izabella Bondarevsky, Tal Sharabi, Udi Haik, Michal Schechter, Nira Niski, Nir Nave, Amitay Tweeto, Ilana Tamir…

We are using an Hybrid of SCRUM and XP, so that we took some practices from XP and implemented them in our SCRUM process.

Here are some pictures to illustrate the process that we are going throw right now:

This picture shows the way we prioritized and estimated product backlog items during the sprint planning.

This picture shows the way we track backlog items and sprint backlog items. We use 3 columns to track them: Not checked out, Checked out and Done. We use this board as a hard copy so it will be visible to everyone. We also keep a soft copy within TFS.

NOTE: You can read more about the Backlog here.

This picture shows the "hard copy" index cards we use to keep track of the product / sprint backlog items.

I will try and keep you guys inform with things that going on here at Nana10…

The IIS Search Engine Optimization (SEO) Toolkit helps Web developers, hosting providers, and Web server administrators to improve their Web site’s relevance in search results by recommending how to make the site content more search engine-friendly.

The IIS SEO Toolkit includes the Site Analysis module, the Robots Exclusion module, and the Sitemaps and Site Indexes module, which let you perform detailed analysis and offer recommendations and editing tools for managing your Robots and Sitemaps files.

With the SEO you can:

• Improve the valume and quality of traffic to your web site from search engines.
• Control how search engines access and display Web content.
• Inform search engines about locations that are available for indexing.
• Analyze you site.

You can download it here.

You can also view this video walkthrough.

Additional Resources

• Using IIS Search Engine Optimization Toolkit
• Using Site Analysis to Crawl a Web Site
• Using Site Analysis Reports
• Using IIS Search Engine Optimization Toolkit
• Using Site Analysis to Crawl a Web Site
• Using Site Analysis Reports
• IIS Search Engine Optimization Toolkit Forum
• Using IIS Site Analysis to Crawl a Web Site
• Using IIS Site Analysis Reports
• Managing Robots.txt and Sitemaps

As some of you may heard, I had the pleasure of attending both the champion’s league semi finals that took place in London: Arsenal VS Manchester United. Chelsea VS Barcelona.

Here are some pics:

View Full Album

Let me know what you think…;-D

When you say that you are done with a task, what do you mean?

Does it mean you completed the code?

Does it mean you created tests for that code and all the tests passed?

Does it mean you integrated the code back to the repository and execute a new build?

Does it mean you had your R&D manager review your code?

The point I am trying to explain is that there are so many definition to the term “done”. So I will ask you again: what do you mean when you say done?”.

In my opinion there is “right” answer, nor there is no “single” answer. The term “done” should have it own meaning within your development team. Here is what I usually do: I gather a definition and make sure that everyone agrees with that (according to the company and the situation in hand). Once I have this definition, I make sure everyone in the team knows it, so when I ask: “Is this task done?”, we will all know what is the meaning behind it.

Although there is no single answer or right answer, I strive to make sure that a coding task is (at least):

1. Well coded.
2. Tested.
3. Reviewed.
4. Integrated.

So, you can create a checklist to enforce the term (as above) or you can create a simple rule: “It is done when the tester say so”.

However, there are exceptions, for instance consider the two:

1. Create a new report.
2. Create a manual for the report.

It is clear that you would give different translation to each. My way to solve that is to add another field to a work task, that allows you to define the “done” term.

That’s it, now I am done ;-)

We all know by now the idea behind work item tracking. You all have heard before the word wit (either Task, Requirement, Bug, Issue, Risk, Story and etc.). Basically you can create those items and store them in a repository. This repository, the team foundation server work item tracking engine, is the backlog.

Definition

This is not “T-H-E definition”, however this is my definition for a backlog. A backlog is the location where we store all the “things” that we need to do during the ALM (Application Lifecycle Management) process. The “things” are translated into a work units, which can be Requirement, Task, Bug and etc. All the wits we create are stored, traced and evaluated within the given development process (SCRUM, XP, CMMI, Waterfall and etc.).

Why?

When you develop software or even hardware, there is one important rule in regarding to Backlog: “You should have one!!!”. There are many reasons why you should keep one, for example: Create a work plan from those wits or create an iteration sprint.

The backlog should always be maintained and updated according to the company needs. If you are practicing “Agile” process development, you should be able to add, remove and update items from the backlog. It is a challenging work, but it is worth it.

How to interact with it?

Basically, I like to think (and this is my preference) that everybody can suggest new work units. only the product manager can accept them and decide whether to add them to the sprint / iteration or to ignore them because they have no ROI or any other value to the company. The developers (dev team) can give estimations and derive new work tasks (activities) out of them and so on and so forth.

Summary

Team Foundation Server supply a very good infrastructure for creating and maintaining backlog. You can easily query those work units, update them, give estimations and derive new activities.