Archives

Archives / 2007 / January
  • My New Blackjack

    I recently purchased the Samsung Blackjack when the joystick on my Cingular 2125 phone died and I'm pretty happy with it. The screen is pretty nice, as is the QWERTY keyboard. The numbers (i.e. dialing a phone number) take a little getting used to. It's extremely hard to dial by touch. But all in all the phone is much zippier (read: faster) than the 2125 and due to the fact that it's much thinner than the 2125 the Blackjack actually feels smaller in my pocket.


    I know what you're thinking - why didn't I wait until the iPhone came out? Well, that doesn't get released for six months, and I was a little disappointed about three things in particular: 1) only 8 gigs. Very low for a guy who travels all the time and wants lots of TV shows and movies to watch. If it maybe had 16 or 24 gigs I could get by without the 80 gigs that the video iPod currently has, but 8 is just too little.  2) No 3G (yet). Why this wasn't put in I have no idea. 3) No developer support. I was really anxious for this particular ability. Don't misunderstand - I love what Apple has done and I do absolutely want one. I'm just going to wait for the next model since they're so expensive.  


    Any-hoo, back to my Blackjack. Something very cool that I stumbled upon was David Ciccone's narrative, which taught me how easy it was to use my Blackjack as a high-speed internet connection (3G) for my MacBook Pro when there's no WiFi around (or I'm in a place that only offers pay-as-you-go WiFi).


    One thing I did notice, however, is that there doesn't appear to be any way to save an email attachment to the phone's file system. I emailed myself a JPG file to use as a background, and all I could do was view the image - I couldn't save it. I had to use my Mac to "beam" the image to my phone using Bluetooth. I'm trying to discover if I just can't figure out how to save an email attachment or if there really is no way to do it that's built in to WM5. If the later is true, doesn't that seem like an enormous oversight?


    Also, I can't seem to find an easy way to get to the Bluetooth setting so I can turn it on and off without having to click Start -> Up -> Settings -> Connections -> Bluetooth -> Bluetooth -> Turn Bluetooth On? I'd love to assign it to a speed dial or a soft key, but I can't figure out how to do it. 


    Does anyone know of a way to (correct me if I'm using the wrong term here) unlock the phone so I can remove a bunch of the Cingular crap that's on there? Most pressing is my desire to remove their startup and shutdown "splash" screens. You see, Cingular has decided (for reasons beyond my comprehension) to add sound to these now. So if you're in a movie theater or it's late at night and you want to shut off your phone, you have no choice but to listen to their sound effect. In addition, I KNOW that I have Cingular. There's no need to advertise it to me each and every time I turn on or off the phone for no apparent reason. I pay the bill every month. So these animated startup and shutdown screens are annoying to me.


    There's also this app on the Connections menu called "Wireless Manager", but when I go in there all I can do is turn the bluetooth or phone wireless on or off. Why would this app exist if I can do that from the Connections menu directly? Is it an app just to have another app?

    Read more...

  • Shaking Things Up: Scrum, Agile, and TDD

    In mid September I started working as a vendor for Microsoft. The majority of my time involves coding. Prior to September I had only a vague idea of what scrum and test-driven development were. Scrum aside, I just couldn't understand why anyone would want to spend time writing all these tests and THEN code their application. My philosophy was, "Let me get some code together that needs to be tested. THEN I'll write the tests." Of course, as you've probably already guessed, the tests were seldom written. 


    I've learned a great deal since that September day, and I continue to do so. The entire project I'm on follows agile methodologies, uses scrum, and is coded by way of test-driven development. It was a shock to my system. Not all software development at Microsoft is handled this way, incidentally. I consider myself one of the lucky ones to be exposed to it.


    I come from the "old school" way of thinking. That is, project managers and business analysts would spend months and months (if not years) writing up specifications and project plans. More frequently than not, no development was done until the business owners signed off on these specifications. In addition, because very little (if anything) functional was put in front of the stake-holders during this entire time, the specifications were frequently revised and edited many times, to the point where they were often vaguely identifiable from their originals. 


    This is the type of management approach that caused the project at my last employer to fail. The client demanded that full specifications be completed as one of the requisites of my employer getting paid. The development team would start to implement as much as we could due to pending deadlines - only to find obvious holes or errors in the logic once we put usable features in front of the people in the middle of writing the specs. We were literally developing to a moving target. One of the systems, a workflow API, was redesigned four times because the requirements kept changing as we delivered what was documented. So we were faced with pending deadlines to deliver functional specifications for several modules as well as pending deadlines for development - in parallel. You do the math. Because the director had staffed up so much to get all these specifications done (for a while there were 15 people on the PM team), and because it took almost a year, the money ran out.  


    Now, with that in mind, imagine a methodology whereby you could put useful functionality in the hands of the stake-holders on a regular basis (perhaps monthly) right from the start. Each month you deliver functionality, and you get instant feedback on that delivered functionality so you can make it better the next month while you're continuing to build the system. By stake-holders, I mean the actual client - the people you're building the system for, not the project managers or business analysts caught in the middle who are trying to gather requirements. 


    This doesn't solve the problem of some clients requiring large functional specification documents, but it does offer at least one potential change to the way they're written: the functional specification can be written AFTER the majority of functionality has been developed and delivered. This is a huge step toward an accurate specification and it also drastically reduces the amount of time it takes to write the document. In addition, every month the development team is getting direct input to keep the application's business usefulness on track. Granted, there are cases in which business owners will not release budgetary dollars for development until these specifications are signed off, but that is a case for another blog entry.


    When I was reading about scrum and agile methodologies I found myself approaching it with skepticism. I was so used to spending the time to create complete logical and physical models before a line of code was written that I just couldn't understand how anyone could possibly set all that aside and only code what was required for that particular month. It only took about two months for me to truly see how this new approach works so much better for everyone right from the start. The hardest part is often convincing the die-hard old-schoolers that it's time for a change.


    With the help of Doug Seven, Brad Wilson, and Scott Densmore I am also now a big proponent of test-driven development. For those who are unfamiliar, here is a simple example.


    I was asked to create new methods on a class, and these methods would allow someone to add and delete a shortcut from one group to or from another.

     

    With test-driven development, you write your test first, then you write just enough code to make the test pass. The theory is that you could spend hours, weeks, or months trying to account for every possible (real and theoretical) scenario as you design an object model or database. Instead of spending so much time on that, you write some tests that validate the one immediate goal you have.


    To fulfill the requirement given to me, the first thing I typed was the following code:

     

            [TestMethod]

            public void AddShortCutWithTwoExistingIdsReturnsTrue()

            {

                Guid toGroupId = new Guid("{45722B64-0354-4ed4-A813-1BD67926EAA0}");

                Guid foreignGroupId = new Guid("{F4B729C4-B922-42bc-BED9-C70D9F0A8C36}");

                bool result;

     

                result = disco.AddShortcut(toGroupId, foreignGroupId);

     

                Assert.IsTrue(result, "AddShortcut failed.");

            }

     

            // AddShortcutWithNonExistentToGroupIdThrows

            // AddShortcutWithInvalidToGroupIdThrows

            // AddShortcutWithInvalidForeignGroupIdThrows

            // AddShortcutWithNonExistentForeignGroupIdThrows

            // DeleteShortcutWithNonExistentFromGroupIdThrows

            // DeleteShortcutWithInvalidFromGroupIdThrows

            // DeleteShortcutWithNonExistentForeignGroupIdThrows

            // DeleteShortcutWithInvalidForeignGroupIdThrows

            // DeleteShortcutWithTwoValidIdsReturnsTrue

    I came up with 10 unit tests, all of which validate 2 little methods – AddShortcut and DeleteShortcut. Now it’s my job to write one test, as I did above, and then write just enough code to get that test to pass. The following is actually too much (all I needed was a method that returned true, but I thought that would be too simple for this example):

     

            public bool AddShortcut(Guid toGroupId, Guid foreignGroupId)

            {

                if (toGroupId == new Guid("{45722B64-0354-4ed4-A813-1BD67926EAA0}") &&

                    foreignGroupId == new Guid("{F4B729C4-B922-42bc-BED9-C70D9F0A8C36}"))

                {

                    return true;

                }

     

                return false;

            }

     

    Note the hard-coded Guids. That is because I don’t need any more code in order to make the test pass. As I write the other 9 tests, my code will look more and more like you’d be used to, but before I would have spent possibly an hour thinking about how I wanted to implement these two methods. Instead, in one hour I have all my code written, and there are at least 10 unit tests that validate that the code works the way it should.


    A side effect of this test-driven development is a specification for my method - in code. In other words, someone who needed to write a spec could examine my tests and gain a huge amount of information to accurately document what this particular method of the class does. 


    Now consider the effect on the project if every developer did this, especially in a scrum / agile environment. We have just a couple dozen classes in our project and well over 300 unit tests. I can now feel much more confident in updating my code (or adding new code) because I have the ability to run all unit tests that were written by all developers on the project to insure I haven't made any breaking changes.


    Thanks to my new team of mentors for teaching me this. It's funny how in just a couple of months I'm at a point now where I shutter to think of writing code without having a test that I'm trying to satisfy first!

    Read more...