Mark Foster's Blog

Tag: 4stars

  • National Broadband Map Review

    National Broadband Map Review

    The National Telecommunications and Information Administration (NTIA) in collaboration with the FCC has published a series of broadband maps on a new site called National Broadband Map (NBM). These maps show what broadband services are available throughout the United States as well as other interesting broadband data.

    Hit this link and click the “Explorer the Map” option on their main page to see a map of the US with shaded areas where selected broadband services are available. You can click different selections above the map to toggle the various broadband technologies. To see other maps such as advertised versus actual broadband speeds click on the “Show Gallery” option in the lower right hand corner.

    Rochester, NY does pretty well on advertised versus actual although there a few slower than advertised points here and there. Upload performance data is also available. Usually the cable and DSL providers don’t brag much about upload performance likely because in most cases it is lousy compared to download performance. I think upload performance will become more important to the typical internet user than it as in the past now that people are sharing their pictures and video online.

    The NBM site use a variety of open source technologies including:

    • JQuery – My favorite JavaScript library.
    • Modernizr – A JavaScript library to detect browser capabilities.
    • OpenLayers – Provides a JavaScript API to display WFS and WMS GIS layers.
    • GeoServer – A Java based server software that provides WFS and WMS services.

    What is particularly interesting about the site is the developer resources. They provide a series of API’s you can call from your own web applications to use their data. Output formats include XML, JSON, and JSONP implementations. If you want to use the data locally without the APIs you can download it.

    I do have a couple criticisms regarding the maps and ironically, they are bandwidth related. The first is that there are too many tiles returned when viewing the default map of the US. I noticed the map was a little slow to fill in. When I enabled Firebug and clicked on the “Explore the Map” option off the main page, over 500 tiles were pulled down. In fact, Firefox/Firebug became unresponsive. I would expect less than 30 256×256 tiles need to be pulled down for a reasonably sized browser window. I wager there is something goofy going on like a bounding box not set for the area displayed.

    My second criticism is that the site is not using gzip to compress JavaScript files. Modern web applications tend to lay on the JavaScript pretty heavy and this one is no exception. OpenLayers.js is nearly 1MB all by itself. By enabling gzip on sites with large JavaScript files you can significantly improve site performance. This is a good topic for a future post.

    Overall I think the National Broadband Map Site is an excellent resource. It provides very useful data on broadband technologies/speeds, makes this data available via APIs or download, and also demonstrates a variety of open source web application technologies.

    Is it worth the $20 million that contractors were paid to build the map? I would say certainly not at first glance but I would want to hear the whole story before I jump to conclusions. I.e. how much of that $20 million was spent on actual development? I am much more skeptical of the alleged $293 million required to collect the data.

  • Book Review: Joel on Software…

    4 out of 5 stars

    The full book title is actually Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity.

    I felt the title was a bit too long for my blog post title so please excuse abbreviated version. 😉 Other than the title and a few other points which I will cover shortly, I think it is a very good book written by someone who obviously has years of experience in the software industry. The author is Joel Spolsky and the content mostly consists of a series of short essays from his blog at http://www.joelonsoftware.com. Although you can read most of the content on his blog I think it is worth owning the printed book.

    There are some technical sections in the book but it mostly focuses on software development and management in general. This is the kind of advise you would get from an experienced mentor. Of particular interest is the Joel Test. This is a list of 12 yes or no questions regarding things your software team should be doing to produce better code. The more items for which you can answer yes, the higher your team’s score. In my experience, such as it is, this is a pretty good test but there are a couple things I feel that are missing in the case of web application development. More on this shortly.

    Joel talks about five worlds of software development:

    1. Shrinkwrap
    2. Internal
    3. Embedded
    4. Games
    5. Throwaway

    I never really thought about it this way but it makes a lot of sense to do so. Depending on the type of development you are doing you will have wildly different priorities. As an example, Joel points out that embedded software often can never be upgraded so quality requirements are much higher than throwaway software for example, that will only be used once to message an input file. An awareness of the business model you are developing for should help sort your priorities.

    There were a few things in the book I disagreed with. One example is that Joel believes that incentive pay is harmful. I think that managed correctly, it is not. One way to handle this is to simply reward employees privately for going above and beyond. In other words, don’t tell employees you are going to reward them for doing X or you will run into the kind of problems that Joel describes. Instead, just thank them with some reward after the fact and explain that this won’t always be the case so there is no expectation or set formula for them to work around. This will make employees feel more appreciated for going the extra mile and they will likely continue to do so even if there are no guarantee they will be rewarded again. This is kind of a pay it forward incentive.

    I think employee ownership in the company is another good incentive. An individual employee may not have much control over the stock price of the company but it does provide the employee some justification to themselves as to why they should go above and beyond. After all, if you are hiring smart people, they will be smart enough to ask themselves why they are putting in that extra overtime to improve the quality of your product. Unless you are a managing a company that feeds starving children in Africa, smart employees will feel better about working overtime on a weekend if they are benefiting in some remote way and not just making some rich stock holders or owners even richer while their own salary remains flat.

    There are a couple items that I think are missing from the Joel Test that are important for the web application world:

    • Is high availability, reliability, scalability, and performance part of your spec?
    • Do you load test?
    • Do you write automated unit and integration tests?

    High Availability, Reliability, Scalability, and Performance

    I have a little over a year of web application development experience but I have been supporting web applications for well over ten years now and if nothing else I have learned that you need to plan for availability, reliability, scalability and performance:

    • High availability ensures that your web application will be available when your users attempt to access your web application.
    • Reliability specifies how often your web application will work correctly. Just because your application is highly available doesn’t necessarily mean it always works right.
    • Scalability planning ensures that if your site is suddenly Slashdotted you can quickly add capacity or if your user base grows you can shard accounts across multiple database servers. A common bottleneck in web applications is data writes and you can get to a point where no single server will have enough write throughput for a high volume web site. Since this is a bottleneck on the database side, adding application servers is useless. A spec and/or design document needs to include a plan for eventually distributing data across multiple database servers for DB write intensive applications. It is not unheard of for a dot com to re-engineer a good portion of their software base in a big hurry to handle growth. Rushed software updates will likely create disgruntled employees and a poor user experience.
    • Performance indicates how quickly a web application will respond to a request. This should include internet lag time and take in consideration where users will be accessing the site from. If you are going to have a large user base in Australia for a example, it might be a good idea to consider implementing a content delivery network with a point of presence in Australia.

    I think it is important to include very specific numbers for each of these items in the spec because each will strongly determine the level of effort and ultimately cost of a project. As you move closer to 100% availability and reliability, costs will likely go up exponentially for both development time and/or hardware. Scalability planning needs be in the spec so design time can be allocated for it on the project plan. Each incremental improvement will likely require more development time and/or hardware.

    Load Testing

    Load testing is critical to assessing performance bottlenecks in web applications. Your application’s performance may be spectacular with one user but what about 5000 users generating 500 requests a second to your database driven web application? It is good to know before it happens so you can plan accordingly and verify you are actually bottlenecking on over utilized hardware and not a “false bottleneck”. I define a false bottleneck as a situation where none of your server hardware is fully utilized and yet you can’t get any more throughput. This can be caused by a number of things such as a propagation delay, uncompressed images and JavaScript using up all the network bandwidth, or even something like a sleep(2) that someone put in the code for debugging and forgot to remove.

    I believe optimizing your code without load test data can be a time sink. If you are optimizing your code without any data you might spot a Shlemiel the Painter’s Algorithm and then spend six hours fixing it resulting in a few micro seconds of execution time saved. That sounds great but if you had done some load testing and monitored your stats, you might have noticed that table scan on your database server costing you over half a second each transaction that could fixed in 10 minutes with a single create/alter index statement. Load testing helps show your actual bottlenecks versus your perceived ones.

    Automated Unit and Integration Tests

    Automated testing is essential for the same reasons as a daily build… to ensure that no one has broken anything. You can use automated unit and integration testing to do a full regression test of your software every day or even prior to every check-in. Daily builds will just identify if anyone has broken the build while automated testing will tell you if everything stills works like it should.

    Unit tests focus on individual functions or units of code while integration tests verify that your application’s components are all working together per the requirements. A unit test, for example, will tell you if your circleArea() function is returning the correct value for given inputs. An integration test will tell you if data submitted via a form is being stored in the database correctly. Unit tests are good at helping you identify broken units of code at a more granular level while integration tests evaluate the overall functionality of your system as a whole. There are unit testing frameworks to facilitate authoring unit tests for all popular programming languages. In many cases unit testing frameworks can also be effectively implemented to do integration testing as well.

    There is some debate over the line between unit testing and integration testing but I honestly don’t care too much. The ideal goal is that you can execute a single command to do a full regression test of your entire solution. This initially increases your development time but will more than make up for itself over long run if your software is going to be around for a while and have many revisions. I have seen a few projects where fixing one bug introduces another or adding a new feature breaks an existing feature. Automated testing will bring these cases to light quickly before you deploy or get too far down the development cycle.

    Conclusion

    Despite a few things that I disagreed with or omissions I give this book a 4 out of 5 stars. Joel obviously has a lot of experience and I learned a lot. Even if you are an experienced developer you might find some valuable insights from this book.