Come Monday I'll be starting the envisioning phase of a 4 month project aimed to enhance the overall user experience in one of our flagship applications. I'm definitely excited about the project not only because there will be some really cool components to build but also because the project will be run using an Agile methodology. For the past several years I've been working on high dollar(long running), complex business apps that followed the Waterfall approach. Each of these projects adhered to the phases of your standard Software Development Life Cycle (SDLC) and at times seemed to drag on in the least exciting phases.
Agile development is definitely different than your traditional waterfall based project, not only from a structure point of view (phases and such) but also in it's principles, which are;
Individuals and interactions over processes and tools
Last week my work brought in a CF consultant from Universal Mind to help evaluate the performance of our flagship application and offer suggestions for improvement. On Tuesday this consultant was set up to give us a presentation on CFMX performance, and like most learning opportunities I attended the session. To my surprise, the consultant was Brandon Purcell... holy sh*t... I have been reading his blog for a few years now and regard him as being a CF rockstar along with the usual names.
Brandon was really cool and dropped some interesting tips on performance, some of which I had never considered before like using <cftransaction> with an isolation level of read_uncommited to speed up SELECT statements. Of course this only applies to queries where the returned results don't have to 110% accurate as the drop in the isolation level will curtail around locks from INSERTs and UPDATEs. I never thought of using <cftransaction> for anything other than managing 'atomic' transactions that included writing to the db.
Another interesting tip that he pointed out was the use of logging run time metrics directly to the screen but using HTML comments to hide them from the users. I think in non-MVC frameworks this would well and never really considered dumping runtimes to the display in a production environment, but I guess it's a quick way to see how well a page is rendering without going through hoops to get that info (in a large corp. environment where not everyone is privy to accessing production logs without waiting for someone else to get them for you).
Brandon had a ton of other great performance tuning tips, most of which I already knew about, but it was still cool to hear it from someone who has been around CF as long as he has. I really need to start going to more conferences and getting involved in some type of Users Group.
Viewed 1377 times
Now that the development and SIT phases of my current project are coming to an end, I've been focusing on preparation for Performance and Load testing. The application that I've been working on was written in Java and runs completely behind the scenes, so using Mercury Loadrunner or some other load testing tool for metrics gathering was out of the question.
The approach that I decided to take was to write a tool in CF that would parse the log files produced by the application (via log4j), aggregate the runtimes for various classes and method and then produce a graph to show average runtime for various components.
The log files that I worked with had timestamps that look like this,
11/30/2007 13:01:59,123 (MM/dd/yyyy hh:mm:ss,zzz where z is milliseconds).
In the course of building my metrics tool, I wrote the following UDF to aid in calculating time differences in milliseconds. ** variables.runDate is set on instantiation of the object that this udf sits in.
A few months ago there was a collaborative effort from the developers at my work to get rid of our then current version control software, PCVS and excruciating Build Test Deploy strategy using Ant and AntHillPro. Although it took many months of convincing and proving out to senior leadership, we were successful in transforming our environment to use Subversion for version control, Maven2 and CruiseControl. The effort in establishing an enterprise ready environment for ourself was large but it was completed and is running smooth.
Although we still have PVCS and AnyHillPro for some existing (legacy) projects the goal is to have all new Java development done with the new tools. Being that, that is the case the new release of my project (Collision Prevention Program) has begun the development stagegate and one of the tasks assigned to me was to get our project ported over to the new environment. So for the past few days I have been slowly getting our project and developer workspaces up to speed so that in another few days the rest of the team can hit the ground running.
There are a few developers (2 to be exact) at my work that have a deep understanding of Maven so it has been critical that I learn as much as I can so that I can assist my team (and others) on questions if those resources are unavailable. As fate would have it, those resources for the most part have been unavailable during my journey to get us ported. I have had some definite headaches in getting everything set up, but in the end they have been resolved and my project and team are entirely set up for the months of development to come.
This experience (like many) has really enforced my confidence an aptitude in picking up new technology. I feel that I'm at a point with Maven and Subversion that I could handle most situations if they arise. I am by far no expert on each matter but I would consider that I have a strong working knowledge of our new environment. Hopefully in the weeksmonths to come I will continue to learn and increase my understanding of the products and processes and if time permits I hope to blog about the experience.
Viewed 1605 times
Last week we had our first Design Patterns study group meeting, we have centered our learning around the book "Head First: Design Patterns" published by O'Reily. We chose this book over Design Patterns: Elements of Reusable Object-Oriented Software written by the Gang of Four (GoF) because we felt the Head First book did just as good of a job of explaining the patterns and object-oriented principles, but is a much easier and more interesting read. I highly recommended this book to anyone (or corporate group) that would like to begin learning Design Patterns or needs a refresher on Object oriented design. read more...
Viewed 1707 times