Why care about migrating classic ASP to .Net?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_care_about_migrating_classic_asp_to_net.htm]

Of course we'd all like to use the latest and greatest technology, but sometimes that isn't just handed to us. One example is all the people who know classic ASP, but haven't had the opportunity yet to officially jump to .Net. A practical learning transition for this would be migrating a ASP application to ASP.Net. Even though ASP and VB are over 6 years removed, there are still some benefits to this:

• Good transition to get your foot in the door with .Net.
• Classic ASP apps still uses a lot of marketable technologies - Html, JavaScript, Xml, CSS, and perhaps SQL for the backend), as well as  concepts like client-server and general web development.
• Think of it like instead of getting your business requirements from a product manager, you're getting them from an existing program.
• Working with an existing app will probably give you new ideas (as opposed to writing everything from scratch).
• Seeing how the old technology solved hard problems will give you an appreciation for the new technology.
• You know that if business-sponsors are investing to migrate a classic ASP app (as opposed to just abandoning it), that it likely was a successful and profitable app.
• Focus on the future, not the past: If you're the one who migrated the app, you probably have a future in leading the exciting new .Net version of the app.

It's not ideal for everyone, but there are perks to being on an ASP migration project.

Slow and controlled over fast and uncontrolled.

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/slow_and_controlled_over_fast_and_uncontrolled.htm]

In my personal experience, I notice that most developers would rather user a technique that takes longer (but for which they have complete control over), then a faster techniques (for which they can't really control). They want a slow and controlled shot over a faster, but random, one. For example, they'd rather use

• A cumbersome open-source project (which lets them step through and modify all the code), than a powerful framework that they cannot modify.

• An older technology that they've mastered, than a new one that "sounds" promising.

• Their own code (that they know inside out), than someone else's, or a third-party, that's obscure.

To some degree, this makes sense. Who cares if a technology or component is powerful if you cannot harness that power? The problem is if you cannot control the code, it becomes not just useless, but rather dangerous. The un-intended consequences will kill your schedule. However, good developers need to constantly learn, and tame those powerful, yet still-wild, technologies. For example, a developer may be afraid of regular expressions, and comfortable writing tons of string-parsing code, but ultimately they need to learn regular expressions.

Tool: Microsoft SQL Server Database Publishing Wizard 1.1

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/tool_microsoft_sql_server_database_publishing_wizard_11.htm]

I was experimenting around with some starter kits, and I came across this good, free tool - Microsoft SQL Server Database Publishing Wizard 1.1. Basically, it can write a database schema, and data, to a sql script. I think it has a command line API too!

 

I found this useful when trying to deal with some database in a starter kit that I couldn't access outside of Visual Studio. I wanted to be able to script and extend it. It was in an ASP.Net 2.0 app_data folder. I'm sure there was a way around it, but this approach seemed so much faster for me. I scripted the database, and then re-ran the script in SQL Studio, and changed the asp.net db connection strings to that new database.

Paylocity is Hiring for a Software Engineer (in Chicago)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/paylocity_is_hiring_for_a_software_engineer_in_chicago.htm]

Our software engineering department is hiring again. This is a technical position, we're located in Chicago. You can see the job description here.

• Great Learning Opportunities: Working with cutting-edge .Net development (already migrated to .Net 3.5)
• Work-Life Balance: Local software department - no travel. Dress code is casual. Office hours about 8-5. We have laptops and can do extra work at home.
• Working from home twice a week.
• Job Security: Smaller company (175 people total, 30 in software department), so we're too small to be outsourced, and privately owned (and owner refuses to sell), so we won't be sold.
• Company has been profitable and grown every year (for all 10 years) - even during the IT crash we still grew.
• Interesting work: There are separate IT and Internal development departments. Even within our department there are separate QA and Business Analyst teams. Therefore you can focus on development.
• Great, collaborative team. Average person has maybe 8 - 10 years experience. Team is large enough that you can specialize in areas that interest you (UI, Business Tier, Database, etc...), yet small enough to still get an interesting variety.

If you're interested, just leave a message, or email me directly at tims@paylocity.com.

 

As an aside, Jeff Atwood has a great article on interviewing.

Purist vs. Pragmatist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/purist_vs_pragmatist.htm]

I've seen a lot of different developer personalities over the years. Two main groups, who always seem at odds with each other, are the "purists" and the "pragmatists".

 

Here's a brain-dump based on my personal experience:

• The purist wants to do pure, perfect coding, and never get their hands dirty with un-pure code.

• The pragmatist wants to get the product shipped and make the client happy, but may take hacks and shortcuts to do so.

I see pros & cons to each approach.

 

	Pro	Con
Purist	PRO: Always trying to do it right, wants to avoid hacks that would be costly later on. PERCEPTION: Seen as visionary leaders whose best-practice principles set the entire project on the right path, and spares the team from endless hours of hacks. EXAMPLE: "This is a 3 month project, we're going to take the first week and set up a build server with proper continuous integration". FAVORITE SAYINGS: "We got to do this right" "These are the best-practices" "Look at the rate-of-return"	CON: It is easy to be a purist on paper, or with the easy problems, but the mess of the real world (deadlines, client changes, complex technology, personality differences) means that we often need to make compromises that aren't always perfect. PERCEPTION: Seen as ivory-tower elitists who never actually get the job done because they keep waiting for the perfect component in an un-perfect word. A purist is more talk than action, and because it's easy to talk, purists are always asking for the impossible. If a purist actually had to do it themselves, they'd act like pragmatists. EXAMPLE: "That fileCopy utility (used only for internal development) isn't good enough because it may not handle the new encoding standards in three years, you need to re-write it from scratch." FAVORITE SAYINGS: "My previous project (which did everything perfect) got this right"
Pragmatist	PRO: Focuses on getting the job done so that the company stays in business. PERCEPTION: Seen as the "real workers" in the trenches who get the job done. EXAMPLE: "It'd be nice to have a script that automatically deploys the entire product, but there are some third-party manual GUI configuration steps that we just cannot automate yet" FAVORITE SAYINGS: "Talk is cheap" "It's easier to describe than implement" "Show me a proto-type" "How will you find schedule time for that"	CON: The pragmatist may get so caught up in "just getting it done", that they always take the immediate solution, which is usually not the best long-term solution. PERCEPTION: Seen as desperate hackers who get the current product out only by writing mountains of bad code, for which the purists later spend 10 times the effort to fix. EXAMPLE: "This component is due next week, I'll just copy this code to ten different places because I don't have time to refactor it." FAVORITE SAYINGS: (bad if used as a justification to commit some hack) "We got to get it done" "We don't have time".

 

You could simplify this as the purist is obsessed with the cause (we'll do it right, no matter how long it takes), the pragmatist is obsessed with the effect (we'll ship a product, even if we need to cut corners).

 

Of course, I think the ideal approach is a balance. The very good book, The Pragmatic Programmers, shows many such balanced-techniques. Sometimes, you'll be forced into a hack - but there are still good ways to handle that. It also helps having a team with a range of these personalities so that people can hold each other accountable and bring out the best in one another.

Three year anniversary

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/three_year_anniversary.htm]

Jan 19th is the 3-year anniversary of this blog. I started back in 2005.

Some obligatory stats:

• Total posts - 244
• Total hits - about 715,000 - almost 3/4 of a million
• Total comments - 270
• Most popular blog entry - Multiple Onclick JavaScript Events on a Single Control - 23,600 hits.
• Most difficulty blog entry - Silverlight TruckWars - I spent a good chunk of time writing a Silverlight arcade game.

Some things to note:

• The popular posts are never what I expect. I spend 10 hours writing a detailed post, and it gets little traffic; I spend 5 minutes whipping out a brain-storm, and it gets a thousand hits. Ironic.
• User comments have been great. There have been some discussions on posts, some people who have added useful enhancements to a post, and others who just let you know that they're reading it.

This is also a good time to point out that in the upper right corner of this blog, there's a "Donate" button to the Lupus Foundation of America to help find a cure for lupus. If you've ever been helped by this blog, consider giving even a $1 or $5 donation to help people with Lupus.

Thanks.

Build vs. Compile

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/build_vs_compile.htm]

In the Microsoft development world, I hear a lot of "non-process-oriented" developers intermix the terms "build" and "compile". I can understand why; I used to be that way myself. For example, if I look at even the new VS2008, the "Build" menu will by default just compile your solution. Sure, you can add pre-build and post-build command line calls, but the point is that out-of-the-box, if you just use VS2008 on a small project, it's easy to think that "building" means "to just compile your code".

 

Building is so much more, hence Microsoft shipped MSBuild back in 2005. A full build process may include many steps, of which compilation is just one:

1. Check out source code

2. Run active code-generation

3. Ensure external data stores can be upgraded (i.e. nothing broke the database schema)

4. Compile

5. Run unit tests (ideally with code coverage)

6. Run other tests (performance, stress, functional, etc...)

7. Run static code analysis

8. Create MSI install packages

9. Publish those packages somewhere

10. Publish results to the team (i.e. email/rss feed the build's status)

A lot of developers have CruiseControl running on a dedicated build server, kicking off an MSBuild (or maybe an NAnt) script to run all this.

 

So, the moral is that "Build" != "Compile". Rather, Compile is just a subset of Build.