September 19th, 2008
Most developers know the term DRY, don’t repeat yourself. To code monkeys, it is second nature. What’s funny is it can be applied to everything, not just coding. Most developers don’t get this.
Today, one of my team leads did a tech talk for his team. The talk was an intro to MVC, specific to their project. It was awesome. You might be thinking, MVC is second nature to me. I have been using MVC for years. Any noob should know what MVC is. That’s not true.
At Mailtrust, the vast majority of our developers come from the coolest school across the street, Virginia Tech. Many of them didn’t learn MVC in school. Even if they did, they have never used it in an enterprise environment working in a team.
Camtasia to the rescue. For this tech talk, we did our first screencast recording. Now we have a reusable, applicable, and awesome training tool. The next time someone asks what MVC is, they won’t get the 5 minute high level talk that leaves them more lost than before. They get an hour long presentation, with full demo and discussion. Sweet. No more repeat training sessions.
Software | 
No Comments »
September 11th, 2008
Software | 1 Comment »
September 8th, 2008
I was thinking about product backlogs today, and I realized that they represent an interesting paradigm. In short, they equate features to a checklist. Once it is done, it is marked off. Completed. Done. Finito.
In reality, this isn’t true at all. A feature is a commitment to your users. For every feature, the initial cost is usually design, development, testing, documentation, and support. What’s funny, is every single one of those is a continuing cost that usually gets overlooked. For every feature, there are bugs that developers need to fix, testers need to verify, and writers need to document. For every design, there is usability testing that reveals flaws. For every feature, there is support.
To succeed, I think there are really two choices. One, eliminate as much continuing cost from each feature as possible. This can be accomplished by reducing uncertainty. Unit tests, functional tests, usability tests, continuous integration, and multiple testing environments all reduce this uncertainty. Unfortunately, this slows your turnaround time down unless you can hire at a rate greater than your continuing cost, which is hard.
Or you can implement less features. This means every feature you implement has to be super important and you can spend a lot of time making it awesome. What’s funny is you now have time to do all the things necessary to build a feature with a very low continuing cost. The obvious downside is, you may not be able to compete because your competitor has everything you don’t.
What’s better? I honestly don’t know. What I do know is every feature should be thought of this way and not as a checklist item. Then skipping that useless unit or functional test doesn’t seem as appealing.
Software | No Comments »
August 11th, 2008
I downloaded Amazon’s Unbox this weekend to watch some BSG (yes I am a nerd). Unbox is Amazon’s video download service. I say service because it is much more than just another download. Amazon allows me to re-download videos or transfer them to multiple machines. Obviously, the Unbox player doesn’t allow burning to DVD, but I am over my purist-open-world days.
As with any service, there is room for vast improvements. The software is slow and buggy, but not bad enough to piss me off, which means it is still very usable. Also, the software only works on Windows XP or Vista, which is annoying for me because I run Ubuntu and Windows. In the future, software for linux that could be integrated with MythTV would be stellar-sweet. (Something tells me the suits are worried about the ability to rip the videos easier in linux).
All things considered, it is exactly what I wanted when my craving for season 4 of BSG got the best of me. I can’t compare it to similar services, but it is worth trying if you don’t care to hook your laptop up to your TV and pay $1.89 an episode.
Linux, MythTV, Software | 1 Comment »
July 26th, 2008
Every developer has heard the phrase document your code. The reason this is important is the functionality is now coupled with a description of how it works. Now a future developer can load up a single source of information and understand the functionality. But, more importantly, the odds of the documentation staying updated are higher because of this coupling. The same can’t be said for a standalone document.
Well, shouldn’t the same be true for documents, specifically those that describe some sort of process? For example, a document describing the steps to setup an IIS web server for a particular application is perfect to convert to an automated script. So, today, I started on a simple script to setup IIS compression using MSBuild.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Types -->
<PropertyGroup>
<adsutilPath>C:\inetpub\AdminScripts\adsutil.vbs</adsutilPath>
<cscriptPath>cscript</cscriptPath>
<StaticFilesToCompress>html htm js txt</StaticFilesToCompress>
<DynamicFilesToCompress>aspx asp dll exe axd</DynamicFilesToCompress>
</PropertyGroup>
<Target Name="IisCompression">
<Message Text="Turn on static and dynamic compression for all of IIS." Importance="high" />
<!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true -->
<Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoStaticCompression true" />
<Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoDynamicCompression true " />
<Message Text="Select files to compress for static and dyanamic compression." Importance="high" />
<!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true -->
<Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcFileExtensions $(StaticFilesToCompress)" />
<Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcFileExtensions $(StaticFilesToCompress)" />
<Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcScriptFileExtensions $(DynamicFilesToCompress)" />
<Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcScriptFileExtensions $(DynamicFilesToCompress)"/>
</Target>
</Project> |
Not only does this script automate the process, but it serves as a living document for the process. By doing this, the documented process is now coupled to the task itself.
The next step to coding processes is coding tasks that can’t be automated. For example, during a deployment, if some sort of fatal error occurs, the next task might be to call your boss and clean up your resume. Why not code a message in the deploy script to give you the list of people and phone numbers to call in case of an emergency, then load up your resume in Word? Again, the documented process is now coupled with the task itself.
Obviously, this article grows out of my dislike of documentation. I dislike it, not because it isn’t useful, but because it takes a lot of time and, in my personal experience, isn’t used very often. By integrating the documentation with the task itself, I think we gain more value from it.
Programming, Software | 1 Comment »
