Omar AL Zabir blog on ASP.NET Ajax and .NET 3.5 : misc

How to convince developers and management to use automated unit test for AJAX websites

omar — Mon, 27 Oct 2008 14:00:24 GMT

Everyone agrees that unit testing is a good thing, we should all write unit tests. We read articles and blogs to keep us up-to-date on what’s going on in the unit test world so that we can sound cool talking to peers at lunch. But when we really sit down and try to write unit tests ourselves – “Naaah, this is waste of time, let’s ask my QA to test it; that’s much more reliable and guaranteed way to test this. What’s the point testing these functions when there are so many other functions that we should unit test first?” Had such moment yourself or with someone else? Read on.

I had a conversation with our development lead Mike (using a highly generic name since my last post caused some trouble), who runs “the show” in our engineering team. As usual there was reservation in introducing unit test to regular development schedule. Mike also had valid points about lack of powerful tools for doing unit test on AJAX websites. He also had confusion on ‘what’ and ‘how’ to unit test our code so that we aren’t just testing database failures but real user actions that executes both business and rendering logics. So, the discussion has a lot of useful information, that will help you take the right decision when you want to sell unit test to your ASP.NET and/or AJAX development team and finally to higher management so that you can buy enough time for the effort.

Friday, Jan 2007 – hallway
Omar: Hey Mike, we need to start doing unit testing at least on our web services. We are wasting way too much time on manual QA. Since we are an AJAX shop, unit testing all our web services should give us pretty well coverage.

Mike: Sure, that sounds fun. I will do some feasibility check and see how can we chip this in into our next sprint.

Friday, Feb 2007 – washroom
Omar: Hey Mike, let’s start doing unit tests. I haven’t seen any tests last month. Can we start from this sprint?

Mike: Sure, we can surely start from this sprint. Let me find out which tool is the right one for us.

Friday, March 2007 – meeting room
Omar: Hey Mike, haven’t seen any unit tests in the solution so far. Let’s seriously start writing unit tests. Did you make any plan how you want to start unit testing the webservices?

Mike: Yeah, I did some digging around and found some tools. But most of them are for non-AJAX sites where you can programmatically hit a URL or programmatically do HTTP POST on a URL. You can also record button clicks and form posts from the browser. There’s Visual Studio’s Web Test, which does pretty good job recording regular ASP.NET site, but poor on AJAX sites. Moreover, you need to buy Team Suite edition to get that Web Test feature. Besides, recording tests and playing them back really does not help us because all those tests contain hard coded data. We can’t repeat a particular step many times with random data, at least not using any off-the-shelf tools. We need to test things carefully and systematically using random data set and sometimes use real data from database. For example, a common scenario is loading 100 random user accounts from database and programmatically log those users into their portal and test whether the portal shows those users’ personalized data. All these need to be done from AJAX, without using any browser redirect or form post, because there’s one page that allows user to login using Ajax call and then dynamically renders the portal on the same page after successful login. The UI is rendered by Javascript, so only a real browser can render it and we have to test the output looking at the browser.

Omar: I see, so you can’t use Visual Studio Web Test to run unit tests on a browser because it does not let you access the html that browser renders. You can only test the html that’s returned by webserver. As we are AJAX website, most of our stuffs are done by Javascripts – they call Webservice and they render the UI. Hmm, thinking how we can do this using VS. We can at least hit the webservices and see if they are returning the right JSON. This way we can pretty much test the entire webservice, business and data access layer. But it does not really replace the need for manual QA since there’s a lot of rendering logic in Javascript.

Mike: Now there’s a new project called Watin that seems promising. You can write C# code to instruct a browser to do stuffs like click on a button, run some javascript and then you can check what the browser rendered in its DOM and run your tests. But still, it’s in its infancy. So, there’s really no good tool for unit testing AJAX sites. Let’s stick to manual QA, which is proven to be more accurate than anything developers can come up with. We can handover a set of data to QA and ask them to enter and check the result.

Omar: We definitely need to figure out ways to reduce our dependency on manual QA. It simply does not scale. Every sprint, we have to freeze code and then hand over to QA. They run their gigantic test scripts for a whole day. Then next day, we get bug reports to fix. If there’s severe regression bug we have to either cancel sprint or work whole night to fix it and run overnight QA to meet deployment date. For last one year, every sprint we ended up having some bug that made dev and QA work over night. We have to empower our developers with automated unit test tool so that they can run the whole regression test script automatically.

Mike: You are talking about a very long project then. Writing so many unit tests for complete regression test is going to be more than a month long project. We have to find the right set of tool, plan what areas to unit test and how, then engage both dev and QA to work together and prepare the right tests. And then we have to keep the test suite up-to-date after every sprint to catch the new bugs and features.

Omar: Yes, this is certainly a complex project. We have to get to a stage that can empower a developer to run automated unit tests and not ask QA to test every task for regression bugs. In fact, we should have automated build that runs all unit tests and does the regression test for us automatically after every checkin.

Mike: We have automated build and deploy. So, that’s done. We need to add automated unit test to it. Seriously, given our product size, this is absolutely impossible to engage in writing so many unit tests so that we can do the entire regression test automatically. It’s not worth the time and money. Our QA team is doing fine. They can take one day leave after deployment when they do overnight work.

Omar: Actually QA team is at the edge of quitting. They seem to have endless work load. After deployment, they have to do manual regression test on production site to ensure nothing broke on production. While they are at it, they have to participate in sprint initiation meetings and write test plans. When they are about to complete that, devs checkin stuffs and ask for regression test of different modules. Before they can finish that , we reach code freeze and they have to finish all those task level tests as well as the entire regression test. So, they end up working round-the-clock several days every sprint. They simply can’t take it anymore.

Mike: How is it different than our life? After spending sleepless night on the deployment date, next day we have to attend 8 hours long sprint planning meeting. Then we have to immediately start working on the tasks from the next day and have to reach code-freeze within a week. Then QA comes up with so many bugs at the last moment. We have to work round-the-clock last 3 days of sprint to get those bugs fixed. Then after a nerve wrecking deployment day, we have to stay up at night to wait for QA to report any critical bug and fix it immediately on production. We are at the brink of destruction as well.

Omar: That’s understood. The whole team is surely getting pushed to their limit. So, that’s why we urgently need automated test so that it addresses the problems of both dev and QA team. Dev will get tests done at a faster rate so that they don’t get bug reports at the very end and then work over-night to fix them. Similarly, we offload QA team’s continuous overwork by letting the system do the bulk of their test.

Mike: This is going to kill the team for sure. We have so many product features and bug fixes to do every sprint. Now, if we ask everyone to start writing unit tests for every task they do, it’s a lot of burden. We can’t do both at the same time.

Omar: Agree. We have to cut down product features or bug fixes. We have to make room in every sprint to write unit tests.

Mike: Good luck with that. Let’s see how you convince product team.

Omar: First let me convince you. Are you convinced that we should do it.

Mike: Not yet. I don’t really see its fruit in near future, even after two months. There’s so many features we have to do and so many customers to ship to, we just can’t do enough unit tests that will really shed off QA load. It’ll just be a distraction and delay in every sprint, heck, in every task.

Omar: Let me show you a graph which I believe is going to make an impact:

So, you see the more automates test we write, the less time spent on Manual QA. That time can be spent on doing new tests or task level tests and increase quality of every new feature shipped and drastically reduce new bugs shipped to production. Thus we get less and less bugs after every successful sprint.

Mike: Ya, I get it, you don’t need to convince me for this. But I don’t see the benefit from overall gain perspective. Are we shipping better product faster over next two months? We aren’t. We are shipping less features and bug fixes by spending a lot of time on writing unit tests that has no impact on end-user.

Omar: Let me see if your assumption is correct:

You see here, the more automated tests kick in, the more time QA can spend on new features or new bugs. I agree that the speed of testing new features/bugs decrease first one or two sprints, but then they gradually get picked up and get even better. In the beginning, there’s a big overhead of getting started with automated test. But as sprints go by, the number of unit tests to write gradually gets stable and soon it becomes proportional to new features/bugs. No more time spent on writing tests for old stuff. So, the number of unit tests you write after four sprints is exactly what needed for the new tasks you did on that sprint.

Mike: Let’s see what if we just don’t do any automated test and keep things manual. How does the graph look like?

Omar: The future looks quite gloomy. We will be spending so much time on regression test as we keep adding stuffs to the product that at some point QA will end up doing regression test full time. They will not spend time on new features and we will end up having a lot more new bugs slipped from QA to production due to lack of attention from QA.

Mike: OK, how do we start?

Omar: First step is to get the regression tests done so that we can get rid of that 24 hour long marathon QA period end of every sprint. Moreover, I see too many devs asking QA to do regression test here and there after they commit some tasks. So, QA is always doing regression tests from the beginning to the end of each sprint. They should only test new things for which automated test is not yet written and let the automated test do the existing tests.

Mike: This will be hard to sell to management. We are going to say “Look for next one month, we will be half productive because we want to spend time automating our QA process so that from second month, we can do tests automatically and QA can have more free time.”

Omar: No, we say it like this, “We are going to spend 50% of our time automating QA for next oen month so that QA can spend 50% more time on testing new features. This will prevent 50% new bugs from occurring every sprint. This will give developers 50% more time to build new features after one month.” We show them this graph:

Mike: Seems like this will sell. But for first couple of sprints, we will be so dead slow that some of us might get fired. Think about it, from management point of view, the development team has suddenly become half productive. They aren’t building only few new features and bugs are not getting fixed as fast rate. Customer are screaming, investors asking for money back. It’s going to get really dirty. Do you want to take this risk?

Omar: I can see that this decision is a very hard decision to take. I know what CEO will say, “We need to be double productive from tomorrow, otherwise we might as well pack our bags and go home. Tell me something that will make us double productive from tomorrow, not half productive.” But you can see what will happen after couple of months. Situation will be so bad that doing this after couple of months will be out of question. We won’t be in a position to even propose this. Now, at least we can argue and they still have the mind to listen to long term ideas. But in future, when our QA team is doing full time regression test, new buggy features going to production, ratio of new bugs increasing after every release, more customers screaming, half baked features running on the production – we might have to shut down the company to save our life.

Mike: We should have started doing automated tests from day one.

Omar: Yes, unfortunately we haven’t and the more we delay, the harder it is going to get. I am sure we will write automated tests from day one in our next project, but we have to rescue this project.

Mike: OK, I am sold. How do we start? We surely need to unit test the business and data access layer. Do we start writing unit test for every function in DAL and Business layer?

Omar: Writing unit test for DAL seems pointless to me. Remember, we have very little time. We will get max two sprints to automate unit tests. After that, we won’t get the luxury to spend half of our time writing unit tests. We will have to go back to our feature and bug fix mode. So, let’s spend the time wisely. How about we only test the business layer function?

Mike: So, we test functions like CreateCustomer, EditCustomer, DeleteCustomer, AddNewOrder in business layer?

Omar: Is that the final layer in business layer? Is there another high level layer that aggregates such CRUD like functions?

Mike: For many areas, it’s like CRUD, a dumb wrapper on DAL with some minor validation and exception handling. But there are places where there are complex functions that do a lot of different DAL call. For example, UpdateCustomerBalance – that calls a lot of DAL classes to figure out customer’s current balance.

Omar: Does webservices call multiple business classes? Do they act like another level that aggregates business layer?

Mike: Yes, webservices are called mostly from user actions and they generally call multiple business layer classes to get the job done.

Omar: Where’s the caching done?

Mike: Webservice layer.

Omar: That sounds like a good place to start unit testing. We will write small number of unit tests and still test majority of business layer and data access classes and we ensure validation, caching, exception handling code are working fine.

Mike: But there are other tools and services that call the business layer. For example, we have a windows service running that directly calls the business layer.

Omar: Can we refactor it to call webservices instead?

Mike: No, that’ll be like creating 10 more webservices. A lot more development effort.

Omar: OK, let’s write unit tests for those business layer classes separately then. I suppose there will be some overlap. Some webservice call will test those business classes as well. But that’s fine. We *should be* unit testing from business layer. But we don’t have time, so we are starting from one level up. Webservices aren’t really “unit” but you have to do what you have to do. At least testing webservices will give us guarantee that we covered all user actions under unit test.

Mike: Yes, testing webservices will at least ensure user actions are tested. The background windows service is not much of our headache. Now how do we test presentation logic? We have ASP.NET pages and there’s all those Javascript rendering code.

Omar: Let’s use Watin for that.

Mike: How to make that part of a unit test suite?

Omar: Watin integrates nicely with NUnit, mbUnit. mbUnit is pretty good. I used it before. It has more test attributes and Assert functions than NUnit.

Mike: OK, so how do we unit test UI? A test function will click on Login link, fill up the email, password box and click “OK”. Then wait for one sec and then see if Javascript has rendered the UI correctly?

Omar: Something like that. We can discuss later exactly how we test it. But how do you test if UI is rendered correctly?

Mike: We check from browser’s DOM for user’s data like name, email, balance etc are available in browser’s HTML.

Omar: Does that really test presentation logic? What if the data is misplaced? What if due to CSS error, it does not render correctly.

Mike: Well, there’s really no way to figure it out if things are rendered correctly. We can ask the QA guys to keep watching the UI while Watin runs the tests on the browser. You can see on the browser what Watin is doing.

Omar: OK, that’s one way and certainly faster than QA doing the whole step. But can it be done automatically like matching browser’s screen with some screenshot?

Mike: Yeah, we need AI for that.

Omar: Seriously, can we write a simple UI capture and comparison tool? Say we take a screenshot of correct output and then clear up some areas which can vary. Then Watin runs the test, it takes the screenshot of current browser’s view and then matches with some screenshot? Here’s the idea:

Say this is a template screenshot that we want to match with the browser. We are testing Google’s search result page to ensure the page always returns a particular result when we provide some predefined query. So, when Watin runs the test and takes browser to Google search result page, it takes a screenshot and ignores whatever is on those gray area. Then it does a pixel by pixel match on the rest of the template. So, no matter what the search query is and no matter what ad Google serves on top of results, as long as the first result is the one we are looking for, test passes.

Mike: As I said, this is AI stuff. Some highly sophisticated being will be matching two screenshots to say, Yah, they more or less match, test pass.

Omar: I think a pretty dumb bitmap matching will work in many cases. Just an idea, think about it. This way we can test if CSS is giving us pixel perfect result. QA takes a screenshot of expected output and then let the automated test to match with browser’s actual output.

Mike: OK, all good ideas. Let’s see how much we can do. We will be starting from webservice unit testing. Then we will gradually move to Watin based testing. Now it’s time to sell this proposal to product team and then to management team.

Omar: Yep, at least get the webservices tested, that will catch a lot of bugs before QA spends time on testing. Goal is to get as much testing done by developers, really fast, automatically then letting QA spend time on them. Also we can run those webservice unit tests in a load test suite and load test the entire webservice layer. That’ll give us guaranty our code is production quality and it can survive the high traffic.

Mike: Understood, see ya.

. . .

March 2008, Friday - The Code Freeze Day

Omar: Hey Mike, how are we doing this sprint?

Mike: Pretty good. 3672 unit tests out of 3842 passed. We know why some of them failed. We can get them fixed pretty soon and run the complete regression tests once during lunch and once before we leave. QA has completed testing new features pretty well yesterday and they can check again today. We got some of the new features covered by unit tests as well. Rest we can finish next sprint, no worries.

Omar: Excellent. Enjoy your weekend. See you on Monday.

------------------------------

Tips and tricks to rescue overdue projects

omar — Mon, 20 Oct 2008 18:08:34 GMT

One of my friends, who runs his own offshore development shop, was having nightmare situation with one of his customers. He's way overdue on a release, the customer is screaming everyday, he's paying his team from his own pocket, customer is sending an ever increasing list of changes and so on. Here's how we discussed some ideas to get out of such a situation and make sure it does not repeat in future:

Kabir: Hey, can you help me? My customer is making us work for free for extra two months to fix bugs from our last delivery. We did what he said. But after he saw the output, he came up with hundred changes, which he somehow presents as bugs or missing features and make them look like they are all our fault and making us work for last two months for free. He is sending new changes every week. We have no idea when we will complete the iteration.

Omar: I see. Did you get a signed list of requirements from customer before you started the development?

Kabir: Of course, I did. He sent us a word document explaining what he wants and we sent him a task breakup with hour estimates and total duration of three months. Now after three months when we showed him the product, he said, it's no where close to what he had expected. Then he sent a gigantic list of things to change.

Omar: All of those are bugs?

Kabir: Of course not. Most of them are new features.

Omar: Then why don't you say those are new features? You have the original word document to prove. Just ask him to show where in the word document did he said X needs to be done?

Kabir: Well..., he's tricky. He somehow makes things look like it is obvious that X needs to be done and he's not going to accept a requirement as done until X is done. For example, he said there must be a complete login form in the homepage. So, we did a typical login form with user name, password and OK, Cancel button. Now he says where's the email verification thing? We said, you did not ask for it. He said, "this is obvious, every login form has a forgot password and email verification; I said *complete* login form, not half-baked login form". So, you see, we can't really argue to keep our image. Then, we did the login form exactly how he said. Now he says, where the client side validations of proper email address, username length, password confirmation? We said, you never asked for it! He says, "come on, every single website nowadays has AJAX enabled client side validation, do I have to tell you every single thing? Aren't you guys smart enough to figure this out? You are already doing this for the third time, can't you do it really well this time?"

Omar: OK, stop. I see what's your problem. Some customer will always try to make you work more for less money. They will try to squeeze out every bit of development they can for their bucks. So, you have to be extra careful on how much you commit to them and make sure they cannot chip in more requirements while development is going on or when you deliver a version. Mockups are one good way to make sure things are crystal clear between you and customer. Did you not show him mockups of the features that you will be building and make him sign those mockups?

Kabir: Yes, I made some mockups. But they were simple mockups. I did not show the validations or all those side jobs like sending verification emails.

Omar: Did you run those mockups through your engineers? They could have told you about those details.

Kabir: No, I did not because developers don't work on the project until I get a signoff from client. So, I prepare all the mockups myself to save cost.

Omar: So, this is the first problem. The mockups were as ambiguous as the customer's word document. Basically the mockups just reflected the sentences in word document. Mockups did not really show all possible navigations (ok, cancel, forgot, signup), system messages, system actions behind the scene, workflows etc. Are you getting what I am saying?

Kabir: Yes. Come on, I am not a developer. I can't think of every single details. That's what developers do when they start working on it.

Omar: But you provide estimates based on your mockups right? So, if mockup shows there's only a simple login form and change password link, you charge 5 hours for it. But then when you realize you have to send email for change password, email needs to contain a tokenized URL, that URL needs to show a change password form, where you need to validate using CAPTCHA etc, it becomes 20 hours of work. Right?

Kabir: Well yes. Generally I multiply all estimates by 1.5 just to be safe. But things have gone 3X to 10X off original estimate.

Omar: Yes, I just gave you an example how a login form estimate can go 4X off when the mockup is not run through an engineer and the important issues are not addressed.

Kabir: So, you are saying I have to prepare all mockup with an engineer?

Omar: In general, yes, since you aren't good enough to figure those out yourself; no offence. You will get good enough after you build couple of products and get your a** kicked couple of times, like mine. Mine got kicked about 17 times. After that it became so hard that when I sit on it, I produce really good mockups. After some more kicks, I hope to get 100% perfect in my mockups.

Kabir: Ok, so the process is, I get word doc from customer. I produce mockups from it. Then I run them through engineers to add more details to them. Then after review with customer, I run them through engineers again to estimate. Then I ask customer to sign-off on the mockups and the estimate, correct?

Omar: Well, first let me say, you don't do a three month long iteration since you are far away from your customer. You do short two weeks sprints. Do you know SCRUM?

Kabir: Yes, one of our team does it.

Omar: I assume the team that got their a** kicked don't do it?

Kabir: right, they don't.

Omar: OK, then first you start doing SCRUM. I won't teach you details. You can study about SCRUM online. Now, you collect 'user stories' from customer. If customer does not give you user stories, just vague paras of requirements, you break the requirements into small user stories. Understood?

Kabir: No, give example.

Omar: OK, say customer wants a *complete* login form. You break it into couple of stories like:

User clicks on "login" link from homepage so that user can login to the system
- User enters username (min 5, max 255 chars, only alphanumeric) in the username text field
- User enters password (min 5, max 50 chars, only alphanumeric) in the password field
- User clicks on "OK" button after entering username and password.
- System validates username and password and shows the secure portal if credential is valid and user has permission to login and account is not locked.

Understood what user stories are?

Kabir: Yes, but you are missing all the validations that we also overlooked and now we are working two months for free. This “user stories” do not help at all.

Omar: Hold on, you just saw basic steps of a user story. Now you describe each user story with the following:

All possible inputs of user and their valid format
All possible system generated messages for invalid input
All possible alternate navigation from the main user story. For example, while entering password, user can click on a help icon so that user can see what kind of passwords are allowed.

Got it?

Kabir: Now it's starting to make sense. Then what? Show these user stories to customers?

Omar: No, show them to your lead engineer who has enough experience to identify if you missed something. Your Engr should point out all the alternative system actions at least.

Kabir: What if my Engr can't figure them out? What if he's just as dumb as me?

Omar: Fire him. Get a pay cut for yourself.

Kabir: Seriously, what do I do if that's the case?

Omar: Your engineers will *always* come up with issues with your mockups. You should always use another pair of eyes to verify your mockups and add more details to it. You aren't the only smart guy in the world you know?

Kabir: I thought I was, ok. What's next?

Omar: File those user stories in your issue tracking system in some special category. Say "User Stories" category. What do you use for your issue tracking system?

Kabir: Flyspray

Omar: Good enough. Create a new project in Filespray named "User Stories". File tasks for user stories. Each story, one task. Attach the mockup to the tasks. Then create one account for your customer so that customer can login and see the user stories, make comments, suggest changes etc. You will get the conversation with your customer recorded as comments in the task. This comes handy for engineers and for resolving dispute later on. Moreover, get your customer to prioritize the tasks properly. Understood?

Kabir: I don't think customer will go through that trouble. Customer will ask for some word document that has all the user stories and she will write in the document what are the changes. I will have to reflect them in Flyspray. Is it really necessary to file user stories in Flysrpay? Can't I just maintain one word doc with customer?

Omar: Absolutely not. Word documents suffer from versioning problem. You have one version, your customer has another version, your engineers have another version. it becomes a nightmare to move around with word docs which has many user stories in it and keep them in sync all the time. Moreover, referencing a particular use case also becomes a problem. Say at later stage of the project, there's a bug which needs to refer to User Story #123. You will have to say User Story #123 in \\centralserver\fileshare\user stories1.doc. Now if \\centralserver dies, or you put it somewhere else, all these references are gone. Don't go for word doc. Keep everything on the web that you can refer to it using a URL or small number. Another problem is numbering stories in Word Doc. Word won't produce unique ID for you. You will end up with duplicate user story numbers. If you use Flyspray, it's will generate unique ID for you.

Kabir: OK, let me see how I convince my customer to use Flyspray.

Omar: Yes, you should. If Flyspray is hard for customers, use some simple issue tracking system that's a no-brainer for non-engineers. Some fancy AJAX based todolist site will be good enough if it has picture attachment feature and auto task number feature.

Kabir: OK, I will find such a website. So, I got the user stories done. Now I show them to customer, review, make changes. Finally I get customer to sign off on User story #X to #Y for a two weeks sprint. Then what happens?

Omar: On your first day of sprint, you do a sprint planning meeting where you present those user stories to your engineers and ask them to break each story into small tasks and estimate each task. Make sure no engineer put 1 day or 2 day for any task. Break them into even smaller tasks like 4 hours of tasks. This will force your engineers to give enough thought into the stories and identify possible problems upfront. Generally when someone says this is going to take a day or two, s/he has no idea how to do it. S/he has not thought about the steps need to be done to complete that task. Your are getting an estimate that's either overestimated or underestimated. Forcing an engineer to allocate tasks in less than 4 hours slot makes an engineer think about the steps carefully.

Kabir: If engineers do this level of estimate, they will think about each task for at least an hour. This is going to take days to finish estimating so many tasks. How do you do it in a day?

Omar: We do 4 hours Planning meeting where Product Owner explains the stories to engineers and then after 30 mins break, another 4 hours meeting where engineers pickup stories and breaks them into tasks and estimate on-the-fly. This 4 hours deadline is strictly maintained. If Product team cannot explain the tasks for a sprint in 4 hours, we don't do the tasks in the sprint. If the tasks are so complex or there are so many tasks that they cannot be explained in 4 hours, engineers unlikely to do them within one/two week long sprint. Similarly if engineers cannot estimate the tasks in their 4 hours slot, the tasks are just too complex to estimate and thus have high probability of not getting done in the sprint. So, we drop them as well.

Kabir: This is impossible! No one's going to attend 8 hours meeting on a day. Besides, telling them to estimate a task on the spot is super inefficient. They won't produce more than 60% correct estimates. They will give some lump sum estimate and then go away.

Omar: Incorrect, if engineers cannot make estimates of a task in 10 to 20 minutes, they don't have the capability of estimating at all. If your engineers are habituated to take a task from you for estimating and then go to their office, talk to their friends on the phone, drink soda, walk around, gossip with colleagues and end of the day if they have the mood to sit and think about the estimate then open a new mail, write some numbers and email it to you; they better learn to do this on-demand, when requested, within time constraint. It's a discipline that they need to learn and implement in their life. Estimates are something they do from the moment they wake up to the moment they go to sleep. Besides, the planning meeting is the best place to estimate tasks - all engineers are there, product team is there, your architects should be there, QA team is there. It's easy to ask questions, get ideas and helps from others.

Kabir: I have engineers who just can't do well under pressure. They need some undisturbed moment, where they can sit and think about tasks without anyone staring at them.

Omar: Train them to learn how to keep their head cool and do their job in the midst of attention. Anyway, let's stop talking about these auxiliary issues and talk about the most important issues. Where were we?

Kabir:About dropping tasks, I already negotiated with customer that we are going to do story A, B, C in this sprint. Now after the sprint planning meetings, engineers say they can't do B. Problem is I have already committed to deliver A, B, and C to customer within 2 weeks and sent him the invoice. How do I handle this?

Omar: How do you commit when you don't know how long A, B, and C are going to take?

Kabir: Customer tells me to do A, B, C within two weeks. And after doing some preliminary discussion with engineers, I commit to customer and then do the sprint planning meeting. I can’t wait until the sprint meeting is done and developers have given me estimates of all the tasks.

Omar: Wrong. You commit to customer after the sprint planning meeting is done. Before that, you give customer just a list of things that you believe you can try to do in following two weeks. Tell customer that you will be able to confirm after the sprint planning meeting. The time to do a sprint meeting is only 8 hours = a day. So, end of the day, you have some concrete stuff to commit to customer. From your model where you give engineers days to estimate, it won’t work. You have to finish planning within a day and end of the day, commit to customer.

Kabir: What if customer does not agree? What if he says, "I must get A, B and C in two weeks, otherwise I am going somewhere else?"

Omar: This is a hard situation. I am tempted to say that you tell your customer, "Go away!", but in reality you can't. You have to negotiate and come to a mutual agreement. You cannot just obey customer and say "Yes Mi Lord, we will do whatever you say" because you clearly cannot do it. The fact is, end of the sprint, you *will* get only A and C done and B not done. Then customer will Fedex you his shoes so that you can ask someone to kick you with it.

Kabir: Correct, so what do I do?

Omar: There are tricky solutions and non-tricky honest solutions to this. Tricky solution is, say you engaged 5 engineers in the project who can get A and C done in time. But you realize you need another engineer to do B, otherwise there's no way you can finish A, B and C in two weeks. So, you invoice customer with 6 engineers and get A, B and C done. Now customer may not agree with you paying for the 6th engineer. Then you do a clever trick. You engage the 6th engineer free of cost in this sprint. Don't tell customer that there's an extra head working in the project. Or you can tell customer that out of good will, you want to engage another engineer free of cost to make sure customer gets a timely delivery. This boosts your image. Later on, when you get a sprint that's more or less relaxed and 4 engineers can do the job, you secretly engage one engineer to some other project but still charge for 5 engineers to your customer. This way you cover the cost for the 6th engineer that you secretly engaged earlier sprint. This is dirty. But when you have so hard a** customer who's forcing you "what", "when" and "how" all at the same time and not open to negotiation, you have no choice but to do these dirty tricks. You can also add extra one hour to every task for every engineer in a sprint or add some vague tasks like "Refactor User object to allow robust login". This way you will get quite some amount of extra hours that will compensate for the hidden free engineer that you engage. You get the idea right?

Kabir: Ingenious! And what's the honest and clear way to do these?

Omar: You negotiate with customer. You tell your customer that he or she can only have any two choices from Money-Scope-Time. This is called the project management triangle. Do you know about this?

Kabir: Googling...

Omar: Read this article:

http://office.microsoft.com/en-us/project/HA010211801033.aspx

It shows a triangle like this:

So, your customer can specify any two. If customer specifies Scope and Time ("what" and "when"), then customer must be flexible on Money or "how" you do it within those two constraints. If customer specifies Money and Scope, then you are free to decide on time. You engage lower resource and take more time to get things done. Got the idea?

Kabir: Yes, understood. Nice, I can show this to customer and educate him. Is there any book for the evil tricks that you just gave me?

Omar: No, I might write one soon. I will name it "Customers are evil, so be you".

Raisul: Hey, I have fixed people engaged in a project. I can't change the number of people sprint-to-sprint to compensate for change in money. So, the triangle does not work for me. What do I do here?

Omar: Right. I also made a slightly different version of it. Here's my take:

This is for situation where you have fixed resource engaged for a particular customer. In that case, you cannot reduce people on-demand because you cannot reassign them. Such a case requires different strategy. If customer forces you Quality and Time, customer must be willing to sacrifice Quantity. Customer cannot say, produce perfect login form in 2 weeks and add cool ajax effects to it. Customer has to sacrifice cool ajax effects, or sacrifice *perfection* of login form, or sacrifice number of days.

From the above two triangles, which one's more appropriate for you?

Kabir: Second one because customer hires 5 engineers from me. I cannot take one away and engage in a different project. Well, not openly of course.

Omar: OK, sounds fair. What else do you need from me?

Kabir: Let me think about all these. This is definitely worth thinking. I have to figure out whether to play fair or play clever. End of the day, I need to produce great product, so that, I get good recommendation and future projects from customer. So, I need to do whatever it takes. It's hard to run an offshore dev shop where we kinda have to work like slaves and like a bunch of zombies mumble every 10 mins - "Customer is always right". You are very lucky to have your own company.

Omar: I had two offshore dev shops before Pageflakes. I know how it feels. Wish you good luck. I have seen your product, you guys are building a great ASP.NET MVC+jQuery application. Release it. It's worth showcasing.

Raisul: Thank you very much. See ya...

(End of chat)

This is the diagram my friend produced, which shows the steps to do before a sprint is started:

Handy for Product Managers. Enlightening for developers.

An Agile Developer's workflow when SCRUM is used

omar — Sat, 11 Oct 2008 07:21:00 GMT

If you are planning to start SCRUM at your company, you might need to train developers and QA to get into the mindset of an Agile developer. SCRUM is only successful when the developers and QA get into the habit of following the principles of SCRUM by heart. So, sometimes you need to offer training or do trial sprints to give some room to your developers how to get used to the working fashion of SCRUM. Giving them a handy workflow diagram that shows how they should work helps soothe the steep learning curve required for non-super star developers. I made such a workflow while I was teaching SCRUM at my friend's company. The following diagram was printed and hung over the desk of each and every developer to help them grasp the culture of SCRUM quickly:

We use Flyspray for issue tracking, so you will see the mention of it frequently.

You will see the step to "Update Sprint backlog with remaining hours" is missing. This is done kinda verbally and scrum master (sometimes same person who is the product owner) keeps track of it.

Hope you find this useful.

ASP.NET website Continuous Integration+Deployment using CruiseControl.NET, Subversion, MSBuild and Robocopy

omar — Mon, 06 Oct 2008 06:59:00 GMT

You can setup continuous integration and automated deployment for your web application using CruiseControl.NET, Subversion, MSBuild and Robocopy. I will show you how you can automatically build the entire solution, email build report to developers and QA, deploy latest code in IIS all using CruiseControl.NET every N minutes.

First get the following:

CruiseControl.NET
Subversion (install the command line tools and add the Subversion bin path to PATH environment variable)
Robocopy (Windows Vista/2008 has it built-in, here's the link for Windows 2003)
Install .NET Framework. You need it for MSBuild.

You will learn how I have configured Continuous Integration and Deployment for my open source AJAX Portal project www.Dropthings.com. The code is hosted at CodePlex. When some developer makes a commit, CruiseControl downloads the latest code, builds the entire solution, emails build report and then deploys the latest web site to IIS 6.0.

After installing CruiseControl.NET, go to Programs -> Cruise Control -> CruiseControl.NET Config.

Now keep copying and pasting the following XML blocks and make sure you understand each block and make necessary changes:

<cruisecontrol>
    <project name="Dropthings" queue="DropthingsQueue" queuePriority="1">
        <!-- 
        Path to the trunk folder where the full solution starts from. This is where
        subversion checkout and incremental update is performed 
        -->
        <workingDirectory>d:\cc\dropthings\code\trunk\</workingDirectory>
        <!-- Some path where CCNet writes its logs and stuffs. It can be outside the log folder -->
        <artifactDirectory>d:\cc\dropthings\artifact\</artifactDirectory>
        <category>Dropthings</category>
        <!-- CCNet installs a web dashboard. Enter the URL of that dashboard here -->
        <webURL>http://localhost/ccnet/</webURL>
        <modificationDelaySeconds>60</modificationDelaySeconds>
        <labeller type="defaultlabeller">
            <prefix>0.1.</prefix>
            <incrementOnFailure>true</incrementOnFailure>
            <labelFormat>000</labelFormat>
        </labeller>
        <state type="state" directory="State" />

First change the working directory. It needs to be the path of the folder where you will have the solution downloaded. I generally create folder structure like this:

D:\CC - Root for all CC.NET enabled projects
- \ProjectName - Root project folder
  - \Code - Code folder where code is downloaded from subversion
  - \Artifact - CC.NET generates a lot of stuff. All goes here.

Next comes the Subversion integration block:

<sourcecontrol type="svn">
    <!-- Subversion trunk repository to keep checking for latest code -->
    <trunkUrl>http://localhost:8081/tfs02.codeplex.com/dropthings/trunk</trunkUrl>
    <workingDirectory></workingDirectory>
    <username>***** SUBVERSION USER NAME *****</username>
    <password>***** SUBVERSION PATH *****</password>
</sourcecontrol>

Here specify the subversion location where you want to download code to the working folder. You should download the entire solution because you will be building the entire solution using MSBuild soon.

I left <workingDirectory> empty. This means whatever is specified earlier in the <workingDirectory> is used. Otherwise you can put some relative folder path here or any absolute folder.

Now we start building the tasks that CC.NET executes - Build, Email, and Deploy.

<tasks>
    <artifactcleanup   cleanUpMethod="KeepLastXBuilds"   cleanUpValue="5" />
    <modificationWriter>
        <filename>mods.xml</filename>
        <path></path>
    </modificationWriter>
  
    <!-- MSBuild task to build a .msbuild file that basically builds a .sln file -->
    <msbuild>
        <executable>C:\windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe</executable>
        <workingDirectory></workingDirectory>
        <projectFile>Dropthings.msbuild</projectFile>
        <targets>Build</targets>
        <timeout>300</timeout>
        <logger>C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
    </msbuild>

This block first says, keep artifacts for last 5 build and remove olders. Artifacts are like build reports, logs etc. You can increase the value for longer history.

Then the most important <msbuild> task. The executable path is to the MSBuild.exe. I am using .NET 3.5 Framework 64bit edition. You might have .NET 2.0 and 32bit version. So, set the right path here for the MSbuild.exe.

<projectFile> maps to a MSBuild file. It's a skeleton MSBuild file which basically says build this Visual Studio solution file. Here's how the msbuild file looks like:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Build"> 
    <!-- Rebuild entire solution -->
    <MSBuild Projects="Dropthings.sln" Targets="Rebuild" />
  </Target>
</Project>

The Dropthings.msbuild and Dropthings.sln file exists in the same trunk folder. This file says - build Dropthings.sln and do a rebuild.

Now you got the build done. Next is to deploy it. You will be using robocopy to copy files from the code folder to a destination folder which is mapped in IIS to a website. Robocopy will do a synchronization of the directories. It will add new files, overwrite old files and removes files from destination folder which no longer exists in the source folder.

Before you can deploy, you need to stop the website or restart IIS. Otherwise some files may be in use and you will not be able to delete or overwrite the files. Here's how to stop IIS using the iisreset command line tool:

<!-- 
Stop IIS before copying over the latest web project files so that there's no write lock and IIS does not
start restarting the site half way through
-->
<exec>
    <executable>iisreset</executable>
    <buildArgs>/stop</buildArgs>
</exec>

If you do not want to stop the entire IIS, instead just stop a website and recycle an application pool, you can use the iisweb.vbs script for stopping a website and iisapp.vbs script for recycling application pool. Here's an example:

<exec>
    <executable>iisweb</executable>
    <buildArgs>/stop "Dropthings"</buildArgs>
</exec>
 
<exec>
    <executable>iisapp</executable>
    <buildArgs> /a "Dropthings" /r</buildArgs>
</exec>

You need to first register cscript as the default script runtime. In order to do this, go to command line and enter iisweb. It will tell you that it cannot use wscript to run this script and it needs to make cscript default. Let it make cscript as default.

Now the time to do the deployment of latest web site files. The following task launches robocopy to do the deployment:

<!--
Sync the web project folder with the deployment folder. The deployment folder is where IIS
is mapped to serve the site. The deployment folder is at the buildArgs node. The robocopy 
utility does an exact sync, adding new files, updating old files, deleting files that no longer
exist.
-->
<exec>
    <!--<executable>C:\Program Files (x86)\Windows Resource Kits\Tools\robocopy.exe</executable>-->
    <executable>robocopy.exe</executable>
    <baseDirectory>Dropthings\</baseDirectory>
    <buildArgs>.\ d:\cc\Dropthings\Deploy *.* /E /XA:H /PURGE /XO /XD ".svn" /NDL /NC /NS /NP</buildArgs>
    <buildTimeoutSeconds>60</buildTimeoutSeconds>
    <successExitCodes>1,0</successExitCodes>
</exec>

First you need to correct the robocopy.exe path. For Windows Vista/Windows 2008, keep it as it is. For Windows 2003, you need to specify the full path. You also need to remove the (x86) from the path if you have 32bit OS.

Next is the <baseDirectory>. This is relative to the working directory. It's the path of the website folder. Dropthings website folder is located under the Dropthings folder under trunk. So, I have specified Dropthings\ as the subfolder where the website files are located. You need to specify your project's website folder's relative path here form the <workingDirectory>.

Next change the path in the <buildArgs> node. First one is the source ".\" which you keep as it is. It means copy files from the baseDirectory. Next is the absolute path to the deployment folder where the web site is mapped in IIS. You can use both relative or absolute path here. While using relative path, just keep in mind the robocopy is running from the <workingDirectory>\<baseDirectory> folder.

After the path keep the *.* and the remaining flags intact. The flags mean:

Copy all subdirectories /E
Copy hidded files /XA:H
Do not copy old files /XO
Exclude .svn directory while copying files /XD ".svn"
Do not show list of files and directories being copie /NDL, /NC, /NP

After the deployment, you need to turn IIS back on or start the website that you stopped:

<!-- Turn IIS back on -->
<exec>
    <executable>iisreset</executable>
    <buildArgs>/start</buildArgs>
</exec>
 
<!--
<exec>
    <executable>iisweb</executable>
    <buildArgs>/start "Dropthings"</buildArgs>
</exec>            
-->

Now we got the build and deployment done. Next is to email a nice report to developers and QA. If build succeeds, email both developers and QA so that they can check out the latest build. But if build fails, email only developers.

<publishers>
    <rss/>
    <xmllogger />
    <statistics />
 
    <!-- Email build report to development and QA team -->
    <email from="admin@yourcompany.com" mailhost="localhost" mailport="25" includeDetails="TRUE"
           mailhostUsername="" mailhostPassword="" useSSL="FALSE">
 
        <users>
            <user name="Developer1" group="devs" address="dev1@yourcompany.com"/>
            <user name="Developer2" group="devs" address="dev2@yourcompany.com"/>
            <user name="Developer3" group="devs" address="dev3@yourcompany.com"/>
            
            <user name="QA1" group="qa" address="qa1@yourcompany.com"/>
            <user name="QA2" group="qa" address="qa2@yourcompany.com"/>
            <user name="QA3" group="qa" address="qa3@yourcompany.com"/>                    
            
        </users>
 
        <groups>
            <group name="devs" notification="Always"/>
            <group name="qa" notification="Success"/>
        </groups>
 
        <converters>
            <!--<regexConverter find="$" replace="@dropthings.com" />-->
        </converters>
 
        <modifierNotificationTypes>
            <NotificationType>Always</NotificationType>
        </modifierNotificationTypes>
 
    </email>
    <modificationHistory  onlyLogWhenChangesFound="true" />
</publishers>

First you need to change the <email> tab where you specify the from address, mail server name, and optionally a user account for the email address that you need to use to send out emails.

Then edit the <users> node and put your developers and QA.

That's it! You got the configuration file done. Next step is to launch the CruiseControl.NET from Programs -> CruiseControl.NET -> CruiseControl.NET. It will launch a process that will execute the tasks according to the configuration. On Windows Vista, you will have to run it with Administrative privilege.

There's also a Windows Service that gets installed. It's named CruiseControl.NET. You can start the service as well on a server and go to sleep. It will do continuous integration and automated deployment for you.

There's also a web based Dashboard that you can use to force a build or stop a build or see detail build reports.

You can create multiple projects. You can have one project to build trunk code only, but do no deployment. Then you can create another project to build, deploy some branch that's ready for production. You can create another project to build and deploy on QA server and so on.

Here's the full configuration file that you can use as your baseline.

Using multiple broadband connections without using any special router or software

omar — Sun, 05 Oct 2008 10:29:18 GMT

I have two broadband connections. One cheap connection, which I mostly use for browsing and downloading. Another very expensive connection that I use for voice chat, remote desktop connection etc. Now, using these two connections at the same time required two computers before. But I figured out a way to use both connections at the same time using the same computer. Here's how:

Connect the cheap internet connection that is used mostly for non-critical purpose like downloading, browsing to a wireless router.

Connect the expensive connection that is used for network latency sensitive work like Voice Conference, Remote Desktop directly via LAN.

When you want to establish a critical connection like starting voice conf app (Skype) or remote desktop client, momentarily disconnect the wireless. This will make your LAN connection the only available internet. So, all the new connections will be established over the LAN. Now you can start Skype and initiate a voice conference or use Remote Desktop client and connect to a computer. The connection will be established over LAN.

Now turn on wireless. Wireless will now become the first preference for Windows to go to internet. So, now you can start Outlook, browser etc and they will be using the wireless internet connection. During this time, Skype and Terminal Client is still connected over the LAN connection. As they use persisted connection, they keep using the LAN connection and do not switch to the wireless.

This way you get to use two broadband connections simultaneously.

Here you see I have data transfer going on through two different connection. The bottom one is the LAN which is maintaining a continuous voice data stream. The upper one is the wireless connection that sometimes consumes bandwidth when I browse.

Using Sysinternal's TCPView, I can see some connection is going through LAN and some through Belkin router. The selected ones - the terminal client and the MSN Messenger is using LAN where the Internet Explorer and Outlook is working over Wireless connection.

Desktop RSS Feed Aggregator client with Outlook Integration

omar — Tue, 05 Feb 2008 13:10:00 GMT

Back in 2005, I built an open source RSS Feed Aggregator Desktop client which has been quite popular since its release. It has 48,672 downloads so far. From the activity I see on sourceforge statistics, it's being used about 20,000 times per day.

http://rssfeederdotnet.sourceforge.net/

What is RSS Feeder.NET

RSS Feeder.NET is a free open source desktop RSS feed aggregator which downloads feeds from web sources and stores locally for offline viewing, searching and processing. It is also a rich blogging tool which you can use to blog to variety of blog engines including WordPress, B2Evolution, .Text, Community Server etc. You can be fully MS Outlook® dependent or can run fully standalone. You can also use both at the same time whichever you find comfortable to work with. It does not increase Outlook load time, nor does it make Outlook slow frequently or prevent from closing properly. It is a Smart Client that makes best use of both Local Resource and Distributed Web Information sources.

Download Installer ver 3.3 (Nov 10, 2005)

Download Source Code ver 3.3 (Nov 10, 2005)

Here’s an Article which explains how it is developed:
A RSS Feed Aggregator & Blog Smart Client

Features:

Newspaper mode. You can read feeds in a more readable newspaper mode called “Blogpaper”
Auto Discovery. Drag any hyper link and I will find out whether there is any RSS Feed in that page
Outlook integration. You can store feeds in Outlook folders
Blogging. It provides you a Outlook 2003 style convenient workspace to manage your blog accounts and write rich posts
Blog from Outlook. You can specify an Outlook folder for a weblog account. All the posts from that folder is automatically posted to the weblog during synchronization. You can write posts as HTML using Word editor. Post content (HTML markup) is cleaned rigorously before posting to the weblog.
Outlook View. It uses a customized view to present a more readable list of feeds in Outlook Folders. The standard Post view is not easy to browse through quickly. The view puts the subject first in bold and an excerpt of the post under the subject.
Optimized Startup. You can safely put RSS Feeder at startup and it won’t make your Windows® start slower. A clever lazy loading process puts no effort on Windows® during startup instead starts the app when Windows® has finally regained its strength after the long boot up struggle.
Newsgator Import. Newsgator users can use RSS Feeder to import all the subscriptions and seamlessly replace Newsgator without any modification to Outlook folder locations.

Browse Mode

Blogpaper mode

Outlook 2003 View

Tray Application

Blog Module

Live OneCare - don't try this at home

omar — Fri, 16 Mar 2007 08:56:43 GMT

I honestly and sincerely tried to use Windows Live OneCare for a month. It made my computer crawl to death, I still insisted on using it. It made Visual Studio Build process 5x slower, I still kept it on. It made my every day email check at least 40 mins longer than before, I still stubbornly kept using it for my sincere love for Microsoft Products. But no more. I had enough of it. This is the most crap product Microsoft has ever released and will ever release (I bet, otherwise I am switching to Linux/Java platform). I am so shockingly surprised how Microsoft can produce such a low quality mass consumer product, release it and keep shouting every where about its praise. If you go to Microsoft forums, you will be surprised how badly everyone has rejected this product. If Microsoft is really honest about their products, they should have withdrawn OneCare from the market after so much negative feedback.

Here are some of the major problems I have faced:

I had to spend at least 30 to 40 mins more in Outlook 2007 since I installed it. Every single click, swtching folders, downloading emails was so slow that it felt like I am using a 386 PC.
Almost whole day whenever I look at CPU meter, it shows MsMpEng is taking 50% CPU. I have dual core, so it's occupying one core at 100%.
Visual Studio build was like hell. I can make a cup of tea, drink it, chat with my friends while my solution builds.
It will not cancel Virus scan no matter how many times I tell it to stop. It will again start within a minute. There is simply no way to return to workable condition until you disable the Virus & Spyware scanning feature.
Every morning, I tried to tolerate it for an hour or so, then I disable the Virus & Spyware scanning and go back to normal working mode. OneCare leaves no room for anyone to work on PC when it's installed.

Every single person I have seen so far installing OneCare, has gone back to some other product. There was not a single person who could continue with it. So, unless Microsoft makes major fix in this product and releases it under a different name, I will never use it. I strongly suggest you also never use it.

MVP Award

omar — Sat, 04 Nov 2006 05:04:13 GMT

I have been awarded MVP Award 2007 on Visual C# again. This is my second year. This time the gifts are realy nice. This program is getting better and better every year. The level of support and appreciation MVPs receive from Microsoft by this award is phenomenal. Free MSDN Universal Susbcription, Visual Studio Team System, TechEd 2006 DVDs, woohoo!

You might be thinking, you did nothing for the community! How come you get this award?

Here's what I did:

Ajax Series

ASP.NET 2.0 Series

You say, "Huh, big deal, I can write such simple artlcles everyday". Then read this:

StickOut - .NET 2.0, VSTS, Outlook Addin, MS Word/Excel integration

My university life

omar — Sun, 24 Sep 2006 17:40:00 GMT

When I was in univerisity, from day 1 at my first semester, I looked for oppotunities not to attend classes or do homeworks instead go and work at my office more. Attending classes, taking class tests, collecting lecture notes, paying dues in long queues, doing course registration all seemed like a waste of my valuable time. I could do so many things if I were not doing those things. So, I was thinking about automating all these so that I can do them over the web from my office or home and thus save going to university. This resulted in a state-of-the-art web based, smart client powered univerisity automation and collaboration system which now runs at my univeristy web site www.aiub.edu.

It created a lot of buzz in the country because it was the first ever complete implementation of such a system not only in Bangladesh but also in many other countries. You will hardly find such feature rich automated system in Universites in US, Europe or Australia. We got so many proposals from famous universities in US who wanted to buy this project. This project was also praised in many daily newspapers. There's a recent review published in a daily which suddenly brought back old memories and made it to this post:

http://www.thedailystar.net/campus/2006/09/04/acad...

It was also the first ever .NET project completed in my country.

Here's what a student sees when logged in:

Here's details of a course:

Blogging Tools

omar — Tue, 15 Aug 2006 10:41:08 GMT

Today I am trying to use Windows Live Writer Beta. Previously I have tried using One Note 2007, MS Word 2007, InfoPath template. None of these were good enough. Although MS Word 2007 is really good for writing and quick publishing, but it generates bloated html, makes you page heavy and also codes look horrible. None of these have the feature to upload pictures with post. So, you have to go to the blog website, upload pictures and then edit the post using the web editor and insert pictures in it. If you do all these from the web, then the desktop blogging experience does not improve at all.

Now Windows Live Writer seems to have solved all these problems. Let's try publishing a picture:

It's a pretty interesting picture. For last one week, our servers running Pageflakes were almost dying with super high CPU and IO usage. Here you see a 64bit Dual Core Dual Xeon DELL server is at its knees. We finally resolved the problem last night. It was a near death experience for us. I will soon write about it. I tried a long time to put some picture. Did not find any. So, just testing with this.

Let's try the Google Map embedding. This is my country and Dhaka is the city where I live.

Let's try some codes from Visual Studio:

    [WebMethod]

    [WebOperationAttribute(true, ResponseFormatMode.Json, false)]

    public int GetPageVersionNo(int pageId)

        using (TheFacade facade = new TheFacade())

            return facade.ThePageflakes.GetPageVersionNo(pageId, Profile.UserName);

OK, here's a catch. You cannot paste html to this editor. You need to switch to Html View in order to paste the html. But this is much better than going to web editor and doing it.

So, far it really felt the best editing experiencing. Going to publish it now. Hope it works...

Blogging from InfoPath

omar — Thu, 10 Aug 2006 15:10:10 GMT

I'm trying to Blog from InfoPath. There's a fantastic InfoPath template available here:

http://gqwu.members.winisp.net/blogeditor/

I have tried Word 2007's new blogging feature. It works fine for posts without code. But if you insert code, the code looks super horrible when the blog gets published. Even the "Copy as HTML" can't give you good output. Also no image upload support.

I am thinking what if there was a nice addin for MS Word which can make a document publish as blog by automatically uploading pictures in it and nicely formatting code blocks, it could make us so productive. Mankind has invented so many great tools, but a really good Blogging tool that works for all is still missing.

Mac OSX vs. Windows Vista

omar — Mon, 07 Aug 2006 16:59:00 GMT

Today we purchased an iMac (Intel Dual Core) in order to test Safari 2.0 support for Pageflakes. My first impression, I am totally blown away by its performance. The UI is unbelievable well done and the visual effects you see are 10 years ahead of time. I was comparing OS features of Mac OS X 10.4.X.X with Windows Vista. To be honest, I am suffering from inferiority complex now. Windows Vista is so lame compared to Mac OS X. Vista copied all OS X's concepts for which at least I feel ashamed whether Microsoft feels or not. But it did not make anything better after copying. Normally Microsoft copies others ideas and makes them really better in all possible ways. But Mac OS X is so seriously better than any other OS. The widgets you see with the OS X are mind blowing. Vista side bar goes nowhere near to it. Also the concept of switching to regular mode and widget mode is by far the best idea. We normally don't want to occupy desktop space with widgets. That's why in OS X, the whole screen switches to widget view when you press middle button.

OSX kernel is made from Unix. So, it's seriously powerful and stable. The command line tools are very feature rich. Those who love *nix command line, will feel at home in OSX. Vista still offers those poor command line tools from Windows XP/2003. Nothing improved much.

If somehow OSX can run Windows apps like Visual Studio, MS Word etc, I will undoubtedly switch to OSX. Even Windows Vista won't be able to compromise me.

Best of all, you can buy an iMac with Intel Processor and use dual boot to run both Windows and Mac OSX. So, when you work, boot on Windows. When you want to have fun, go to OSX.

Testing blogging from Word 2007

omar — Sun, 06 Aug 2006 16:09:59 GMT

Does it work? Looks like it does. I can now blog directly from MS Word! Amazing new feature!

But beware about the configuration. I pulled out my hair trying to configure the Community Server configuration with MS Word. But nothing work and I repeatedly got the endless dialog box for user name and password which cannot be canceled but to terminate the process. Interestingly, everything started working after couple days.

New Model-Driven RAD Tool Generates up to 95% of a Custom Application

omar — Fri, 04 Nov 2005 13:46:00 GMT

Model-Driven Development is a hot topic in the developer community, but many still don't know how to make it work in real-life projects. By offering developers built-in guidance, tangible architect makes Model-Driven Development finally accessible to everyone. I have been working on a new custom UML designer for making the design process a lot easier than using generic UML designer. It will be released soon. Check out the cool app: