Silverlight 2.0 Convert Relative Url Paths to Absolute

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

As you've probably heard, Silverlight 2.0 Beta 1 is out. You can get it from Silverlight.Net. And Bill Reiss is starting another great tutorial series on Silverlight games.

 

I see a lot of breaking changes (as documented on MSDN), and I'll blog more about my adventures upgrading. One change is that it seems like you need Absolute urls in a few more places (like for accessing xml files or images). Because I like to think in terms of relative urls, here's an easy utility to convert relative to absolute. It should handle both file paths (file:///aaa) and web (http://aaa).

 

    public static string GetAbsoluteUrl(string strRelativePath)
    {
      if (string.IsNullOrEmpty(strRelativePath))
        return strRelativePath;

      string strFullUrl;
      if (strRelativePath.StartsWith("http:", StringComparison.OrdinalIgnoreCase)
        || strRelativePath.StartsWith("https:", StringComparison.OrdinalIgnoreCase)
        || strRelativePath.StartsWith("file:", StringComparison.OrdinalIgnoreCase)
        )
      {
        //already absolute
        strFullUrl = strRelativePath;
      }
      else
      {
        //relative, need to convert to absolute
        strFullUrl = System.Windows.Application.Current.Host.Source.AbsoluteUri;
        if (strFullUrl.IndexOf("ClientBin") > 0)
          strFullUrl = strFullUrl.Substring(0, strFullUrl.IndexOf("ClientBin")) + strRelativePath;
      }

      return strFullUrl;
    }

 

More to come soon...

 

Coding vs. Configuration

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

Real-world applications need to be configurable. There are lots of reasons an app must be configured - different environment, modify the thresholds, even change what providers are used for a task. There's a big difference between coding, and configuration:

• Coding implies writing the actual logic in some language (C#, VB, Java, Html, JavaScript, CSS, Sql, etc...). Coding, by its nature, can deal with complex logic, and may reside in many files across many directories. Sometimes code needs to be compiled into binaries. There's a lot of room for error here, which is why IDEs (like Visual Studio) provide code debugging, and why the community encourages unit tests and code reviews.

• Configuration implies using knowledge of the domain to tweak the app, after it's been deployed, usually via a small number of config files.

	Coding	Configuration
Requires knowledge of language syntax	Yes (and usually for many languages)	No (syntax is usually just xml. A huge point of configs is that they abstract out syntax).
Requires business domain knowledge	Yes	Yes
Requires re-compiling	Sometimes (C#, Java --> Yes, Html/Sql --> No)	No. Usually just xml or plain text
Number of files	Many - a 10,000 line app, with 50 files, could still just have 1 app.config	Few (usually just 1, or 1 per directory)

 

More and more, the push is to abstract coding into configuration. I believe WCF is big on this - instead of getting bogged down in how to transport data (web services, remoting, FTP, messaging, etc...) you just configure the app as appropriate. We also see this in domain specific languages and code generation. For example, .Net tiers has a big config file, but it makes perfect sense if you understand the concepts of N-Tier architecture. So, you can do a little configuration, and it generates 1000s of lines, which spares you from tons of tedious coding.

Career path from hobbyist to professional

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

Software Engineering is unique in that it offers a gradual path from a hobbyist to a professional. Many professions do not. For example, there's a world of difference between building a dog house vs. a sky-scraper, or giving first aid vs. performing open-heart surgery. To be an authorized civil engineer or doctor, who offers products and services to the public, there are rigorous standards that must be met. It's not just that 10 years of hobbyist experience of building dog houses won't give you the necessary professional experience to design a sky-scraper, it's that federal law won't even allow you to authorize the blue-prints. For example, if memory serves me right, to authorize civil engineering blue prints, you need to first go to an accredited university, then pass a huge "Engineering in Training" exam, then work under the guidance of a professional engineer for 5 years, then pass a second exam. Then, and only then, are you legally even allowed to approve a blue-print.  There is not a gradual path, but rather one with steep cliffs.

 

Software Engineering is totally different. There is a gradual path. You could start doing hobbyist web sites on your personal laptop. You can then continually learn more doing harder projects (perhaps for non-profits, or just for fun). All the while, you can read the same books, go to the same conferences, and use most of the same tools that the professionals use. You could then enter the lower rung of the professional world by getting a low-paying contractor job on a short assignment, publishing in an online journal, or contributing to a popular open-source project. From there, you could jump to larger teams, or do harder projects, and the rest is history.

 

This potential gradual path from hobbyist to professional has pros and cons. It offers great opportunity, because almost anyone who has the mental ability, passion, and a computer can enter the profession.  However, the con is that many developers (doing paid, real-world, work), still treat it like a care-free hobby, as opposed to professional work.

 

What separates a hobbyist from professional? Scott McChonnell's good book, Professional Software Development, offers a lot of good ideas. I think some important traits of a professional include:

1. Having public process that works for a team of developers - i.e. a team build server, team source control, etc...

2. Writing code that works on other people's machines.

3. Writing code that scales, is secure, and maintainable by other people

4. Producing deterministic results

5. Providing schedules and estimates

6. Using industry best practices and design patterns, not just your own personal bag of tricks

7. Referencing official standards, not just "I heard somewhere on some blog"

Of course there's more, but this is a start. The good news is that even as a hobbyist transitions to a professional, they can still pick up things like these. It makes me appreciate Software Engineering as a truly wonderful field.

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.