October 12th, 2008
After months of development, one of your developers refactors a piece of code to be much better than before. In many cases, you end up with code that is no longer in use. Some people say Keep it around in case I need it but I say Delete it
At first, this may seem counter-intuitive. Isn’t this gong to cause more work in case you do need that function? No. Delete it. Don’t think twice. Here is why.
Unused code isn’t being tested. Used code is tested everyday, by your users if nothing else. The last thing you want is a developer to use code that might be completely wrong.
It reduces your code base. The less code you have, the less probability for problems exist. The less code you have, the easier it is to learn the code base.
Lastly, your developers should be learning everyday. If given a second chance, many developers would develop the same function completely differently a year apart. They would code a better function, that is more thoroughly tested and uses best practices.
So, don’t worry about it. Delete it.
Programming | 
No Comments »
October 7th, 2008
Today Mailtrust held its first all-day development conference. In my opinion, it was awesome. Not because it was great, but because it wasn’t bad. Like any first-time, there are a ton of things we can do better for future conferences, but the goal of spreading knowledge throughout the development environment was met.
When I first started coding in VB6 on Webmail.us’s corporate website, I never imagined the day I would help organize a conference for all their developers (PS – That is the corporate website when I started found via archive.org. You have to check it out). Then, communicating a new concept was as simple as turning around in your chair or waiting till everyone met up for dinner and drinks after work. With the growth of the company, communication isn’t as easy.
Our goal was to spread knowledge to everyone, and even more specifically the new people. One of the key topics today was on MySQL, a topic some of us can talk about for hours. Too often, we take that knowledge for granted. Not everyone has had as much experience with MySQL, especially hires right out of college. Getting everyone on the same page with certain topics was the goal today. Hopefully screen casts of the talks can help future hires ramp up faster as well.
But, there are always things we can improve upon. Here a list of 5 things that we can do better for next time:
- Plan the setup better. Make sure everyones files are on the presentation machine, and have breaks setup so there aren’t lulls between talks.
- Don’t rely on the internet. Holiday Inn’s free wifi isn’t geared towards 30 developers.
- Don’t eat mexican for lunch. It is delicious, but takes away from the second half of the conference if you know what I mean.
- Give every speaker enough time, and push them to fill it but not go over.
- Lastly, I would like to figure out how to go more in depth with some of the topics. Maybe have different tracks so people can choose? We might need 30 more developers before this is feasible though
Thanks to Lindsey, Matt, and Kevin for making it all happen.
Programming | No Comments »
August 7th, 2008
Today I found some odd behavior when working with LINQ. It is hard to describe, so here is the code.
public void Foo(IEnumerable<string> strings)
{
IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s));
foreach(string str in stringsInDb)
{
//Where clause in LINQ is actually executed
}
foreach(string str in stringsInDb)
{
//Where clause in LINQ is actually executed AGAIN
}
}Luckily, some unit tests detected this behavior. It actually isn’t surprising when you think about it though. The proper thing to do for this case is actually call ToList() after the Where().
IEnumberable<string> stringsInDb = strings.Where(s => this.QueryTheDbAndTakeALongTime(s)).ToList();
Don’t let this behavior bite you.
.NET, Programming | 3 Comments »
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 »
