Agile Devin Devin's Experiences with Agile Development

Dr. Seuss on Creativity

“I like nonsense, it wakes up the brain cells. Fantasy is a necessary ingredient in living, it’s a way of looking at life through the wrong end of a telescope. Which is what I do, and that enables you to laugh at life’s realities.”

Why I don’t typically use any browser other than Firefox

I've talked about Internet Browser security briefly before, but I thought it might be best to follow up with a commonsense commentary on why I favor Firefox over other browsers.
On March 18, 2009, TippingPoint's Charlie Miller, for the second year in a row, hacked an Apple OS-X based laptop in mere seconds. The source was an unpatched vulnerability in Apple's browser, Safari. Safari ships pre-installed on every Apple computer just like Microsoft's Internet Explorer is pre-installed on every Windows based computer.
Since then, Apple has released exactly ZERO patches to their browser to address the vulnerability. A similar vulnerability in the Firefox browser was exploited at the same time at the Pwn2Own competition and, in contrast to Safari, Firefox was patched nine days later. Firefox has subsequently had a second security patch release less than a month later for other discovered vulnerabilities.

So why hasn't Apple responded as quickly? It boils down to numbers: development resources and probably that the attack vector of the exploit can actually be used.
For the Safari exploit two things had to happen: the exploit had to be embedded on a Website that people would go to, and then the hackers had to actually get you to go to the site. The later is pretty easy to do because of all the Pavlovian-like responses hackers get through specially crafted emails. Actually installing the crack on a website without being caught is pretty hard to do. Servers have logs. Logs create a fingerprint of who did what to a server. Even if the hacker attempts to erase the logs, there are other ways to "sniff" who came from where to attack the server in the first place. In most cases, in order to get to a server the hacker has to jump through more hoops to remain masked than it is worth it: the risk isn't worth attacking the server.

So back to Apple's "arrogance" (as it has been called by others). Apple doesn't see the risk as being high and they have limited resources. Patches generally take a while to fix when using limited corporate resources. If you dedicate resources to defects and vulnerabilities, then you taking them away from new innovations and making new products.

This is always a problem in closed-source software. In one past project I took over, the software had so many bugs in it, that we had problems turning out a new release with the much-needed critical mission-oriented functionality. All of my resources were too busy addressing software defects. The source of the software defects was poor configuration management and software quality testing practices by the incumbent development firm coupled with a corporate culture by the client that refused to allow the incumbent to swap-out resources that knew how to use automated testing tools... even though the tools were free.

Contrast the limited resources problem with Open Source Software (OSS) with thousands of developers/testers coupled with well managed testing and configuration management practices. The simple statistics are that OSS is only limited by the number of people contributing and the maturity of software development management practices being used.

Number of Apple OSX developers vs. number of Firefox developers. Firefox wins.
What Firefox can't prevent is the risky end-user behavior... but that is another conversation for another time.

IRC Client for OS X

I'm looking for an IRC client for OS X. I've run acros several but I'm not sure which will fit my needs.

Here are the current candidates:

• Colloquy
• Irssix
• Ircle (gotta love that name)
• X-Chat Aqua (A port of the popular Linux IRC client)

I'm leaning toward X-Chat Aqua, but would like to hear other suggestions.

Thoughts?

Disable infrared receiver on Apple computers

I've had this annoyance for a while now and was too lazy to Google it. I have an iPhone docking station, an iPod docking station and my Apple MacBook. All three devices accept signals from the Apple Remote.The only device I wanted to accept signals from the remote control is my iPod since it is powering my speakers.

The solution was easier to fix than I wanted to admit. First, I switched out my iPhone dock for a Griffin Simplifi Dock for iPod and iPhone, Media Card Reader, and USB Hub in One Device (Aluminum).

Next I used this article on TUAW to disable my IR receiver on my MacBook.

Easy as Pie.

Building Scalable Web-Based Applications

Scalable web-based applications has been getting a lot of air-play on social networks like Twitter lately, mostly because Twitter has been overcome by scability issues and the service unreliable. Having an unreliable internet service is embarassing and unacceptable. There is no better way to kill your brand image than to have your viral social media strategy fall flat on its face in front of the whole "instant on" world.

Twitter is over capacity: Importance of Capacity Planning

Having said that, I've had a lot of requests for guidance on how to build scalable web-based applications that can withstand getting Slashdotted. Building a scable web-based application can happen incrementally so you don't have too apply all of the principles below all at once. There is an appropriate implementation roadmap that is appropriate for different types of web-based applications. For example, if your site is proving an web-service API (SOAP service) for other web-services or client applications, you should spend time looking at capacity planning for those services with less emphasis on your own public facing web-site. Anyway... here is my brain dump. There is more where this came from.

Application architecture

• Judicious use of the singleton pattern
• Judicious Use of the Concurrency pattern
• Client side form validation
• Use of AJAX for web-services requests
• Caching of semi-dynamic data (pre-rendering semi-static pages)
• Use of MVC pattern
• Object persistance is separated from the object
• Use of XML and meta-data instead of traditional row/column SQL commands for each data element
• Place SOAP interfaces on a separate cluster of servers (aka application servers)

System architecture

• Use a load-balancer and multiple Web servers
• Separate your web-application into a minimum of four tiers: UI, Application Services, Object Persistance Layer, Database Services
• Use a separate NIC on each server and switch for each tier of the application (e.g. web-page server to application server, application server to object persistence server, and object persistence server to database server)
• Use a load balancer between each tier of of the application (e.g. between web-page servers and application servers, between application servers and object persistence servers, etc.)
• Use an enterprise service bus object persistance service to ensure object concurrency issues are handled across multiple databases
• Use clusters of virtualized servers running across multiple physical servers
• Add performance monitoring services on each virtualized server to monitor memory, network, harddrive and application utilization
• Conduct performance tests to determine if any one object needs more server resources, and move those objects onto thier own virtualized and physical servers

Network architecture

• Use lots of partitioning of data across NICS and Physical Switches (aka switch processors)
• Use firewalls in front of each switch in the top three tiers (UI, Application, and Object Persistence Layers)
• Place network probes between each firewall and load-balancer to monitor utilization and intrusion detection
• Place each application stack, a complete web application, application server and database server, in at least two data centers in two different geographic locations using two different internet data service providers
• Create a private point-to-point network between data centers for transaction load balancing using two different internet date service providers

I know was a lot of technical mumbo-jumbo. Frankly, I haven't met that many web designers, web-developers, or even a lot of software developers that understand everything I've listed. In order to implement the list, it will take more than one skillset from several technology professionals. (Business owners can contact me privately about assessing the maturity of your development staff. You might be surprised.)

If you don't understand it, I am happy to elaborate privately. Understand that this is what I do when I'm not playing drums in a Jazz combo.