I have the opportunity to do a good amount of interviewing, and it lets me see many ways that developers promote themselves:

• Years of experience

• Work at a prestigious company

• Professional awards

• Certifications

• Academic degrees (bachelors, masters)

• Attended training classes

• Buzzwords

• Job title ("Extra Super Senior Technical Specialist Level 3++, with Honors")

• "I've read every tutorial on w3schools"

• Various activities on their last job

At the end of the day, these are all good, but people who have these still fail simple coding questions. They can talk a good talk, pass multiple choice tests, but struggle when trying to write 10 lines of C# on a whiteboard. Perhaps the #1 indicator of a good developer is that they build their own personal coding projects - from scratch. Not just configure some buzzword package, but actually write, compile, deploy, maintain, and improve their own personal pet project. For example, many of the best developers I know are those who got started by writing their own computer games. I think this actually makes sense for a lot of reasons.

• Good practice - If you're asked to write code in an interview, what better way to practice than by writing code on your own?

• Emotional attachment - You have a vested interest in your own pet projects, and a vested interest in their success. Therefore, you'll inevitably be more eager to learn and understand the coding techniques involved, as opposed to some "boring project for work."

• Small and flexible - A pet project is small, so it's flexible and easy to change - you're not constantly dragging around years of legacy code.

• Easier to try new things - You're more likely to try new things for your own project, than risk screwing up the company's flagship product.

• You see the big picture - You see your own project end-to-end, in its full context, as opposed to just a small niche of a much larger product.

• Lets you focus - A small project, of your own interest, lets you focus on just the specific tech you want, as opposed to writing thousands of lines of redundant or plumbing code for work. It's often a minimalist example of a some interesting technology, because once it gets bloated, it stops being interesting, and the developer stops working on that hobby project, and moves onto another one.

• Shows motivation - Someone who invests the energy to write their own application, off the clock, is probably motivated to learn new technology and tricks for their work project.

There are tons of fun, pet projects you could build. And with free open-source hosting with places like CodePlex, you can easily share that code with others. If anyone has experienced a better way to learn coding, I'm all ears.

Structured programming languages, like C#, provide a try-catch ability to wrap an entire block of code, and catch if anything goes wrong. This can massively simplify error checking, especially when calling external components. However, like any good thing, it can also be abused. During interviews, or rushing out code, many developers resort to using try-catch as a quick way of doing error checking, but there's a catch (excuse the pun). For example, consider this trivial method to sum up an array of integers:

    public static int GetSum(int[] aInt)
    {
      int intSum = 0;
      foreach (int i in aInt)
      {
          intSum += i;
      }
      return intSum;
    }

You can crash this code, such as by passing in null for the int array.  To blindly wrap a simple method with try catch, just to catch normal logic errors like null variables or indexOutOfRange, has problems.

• For performance, Try-catch is enormously expensive compared to an if-then check. It could be hundreds of times slower. So it's bad design to use a try-catch for something trivial when an in-then will do just file, like checking if a variable is null.

• What will you do in the catch statement? Some devs may say "I'll log my exception info here" - but what info is that... that the developer didn't bother to do basic error checking?

• It makes the usability worse. Perhaps instead of re-throwing an exception, or logging and going to the global error page, the method could have used an if-then to return a sentinel value instead. For example, perhaps a string manipulation method could just return the original value (or null) if the input parameters were invalid.

• It loses context. Say your code catches a null exception - that thrown exception doesn't tell you what variable was null. You've lost context and information with which to fix the code. Using an in-then would have given you full access to all the local variables and their context.

• It makes all exceptions equal - a null or indexOutOfRange exception (things that are easy to catch with if-thens) are put on the same level as a critical outOfMemory error - i.e. both trigger the catch block. This in turn can distract the maintenance team, who gets swamped with tons of exceptions, most of them preventable.

• Perhaps worst of all, it implies that the developer isn't thinking about how their method can fail. Rather than understanding the code and what it does, they just wrap it all in a try-catch, and move on. This means they could have not coded for valid use cases.

Try-catch has obvious benefits, but it has limitations and consequences too. There are times when it's much more beneficial to explicitly catch the error conditions with an if-then instead.

I migrated Silverlight TruckWars to the SL Beta 2. I started working on TruckWars as a way to learn Silverlight back in the Alpha last year. Being a Microsoft product, there have been two more betas (with plenty of breaking changes), but I've finally migrated it.

Things of note - Beta 1 started supporting buttons, which obviously simplified things. For example, it helped me remove keyboard input. It also had some subtle changes that affected the gameplay. Also, there still is no dropdown. Before I was using an HTML dropdown to select the levels. Rather than jump through hoops, I just ceded the dropdown part until the next release.

Because the code has been migrated from an alpha, to a beta, to another beta, it's becoming pretty screwy. Not the best, most agile code out there, but good for a demo of what cool stuff Silverlight can do. You can play it here.

The first LCNUG meeting occurred this past Thur, June 26. It went well - about a dozen (very talented) people. Scott Seely presented on Windows Workflow Foundation, which you can download from the website. The small number of attendees (as compared to the hundred who normally attend larger groups) allowed more community interaction and networking. Overall, a good success for the kickoff meeting of a new group. I'm proud that Paylocity can help sponsor this.

A minimalist code sample is a snippet that demonstrates a specific purpose, requires no extra context, yet can still run. For example, doFactory.com explains design patterns with a "real-world" sample, and a "structural" (i.e. minimalist) sample. Because it abstracts out the context, the minimalist sample has several benefits:

• Easier to apply: It is easier to apply to different contexts - such as new projects.

• Easier to remember: It is much smaller (no context means less code), therefore it's easier to remember what the code was about. For example, I have a folder essentially called "LearningSnippets", where I categorize different coding tricks. By keeping all the snippets small, they're fast for me to physically load, "mentally load", and then run. The last thing I want is to dig through some 2000 line project, scratching my head, thinking "how did I do that sorting algorithm?"

• Easier to learn: It's easier to learn new concepts. Removing the irrelevant context means there's less to get distracted by, so you can focus on the specific concept that you care about.

• Easier to show others: It is easier to show to others, such as a newsgroup, where other developers don't care about the business context. I sigh when I see some poor guy post a 5 page code question on a forum, because few people will sift through all that.

• Easier to enhance: It can be much easier to enhance because the code is not constrained by some rigid business context.

• It is a courtesy to others: If you just care about a 3-line algorithm, it would be long-winded of me to hide that behind hundred of lines of business context and plumbing.

In .Net, many errors come down to a few bad lines of code - you've got the wrong method, a bad input parameter, or some syntax error. It becomes very convenient when working with others, or learning new concepts, to be able to isolate code down to the minimalist sample.

I got very bad marks in grammar during middle school. It wasn't until after I graduated public school that I cared about writing, and hence grammar. Now, I find it quite fascinating, so I was interested to read about a CodePlex project - SharpNLP. In their own words:

SharpNLP is a collection of natural language processing tools written in C#. Currently it provides the following NLP tools:

• a sentence splitter

• a tokenizer

• a part-of-speech tagger

• a chunker (used to "find non-recursive syntactic annotations such as noun phrase chunks")

• a parser

• a name finder

• a coreference tool

• an interface to the WordNet lexical database

So, you could type in a paragraph, and it parses that out into the different sentences, and then different words and parts of speech. Of course, I began to think if maybe this could be extended to be like the FxCop of technical articles. For example, according to the Microsoft Manual of Style for Technical Publications, the rules to merely capitalize a sub-title are non-trivial - there are 10 rules and it takes a full page to explain them. I wonder in theory if you could have a NLP (Natural Language Processing) tool run through a subtitle (as an input string), and apply the rules, much like you can parse a arithmetic expression for correct syntax. I was starting to toy around with it, but it seemed to quickly get difficult, so maybe I look at it another day.

In the meantime, if you're interested in NLP, check out SharpNLP.

Talking with another developer the other day, we began discussing if software engineering is really a young person's profession (we've both been doing this for a while, have families, and aren't jumping to do the 70-hour weeks of boring features with boring technologies). Given the rapid turnout of new technologies, pressure from out-sourcing, and demanding projects, one might view the software world as incompatible with an older person, especially someone with a family who didn't want to spend 70 hour weeks at work.

I'm an optimist here, and I think that no -software engineering is certainly not just "a young person's profession". There's a lot of advantages that older developers have, they:

• Have more experience, so they usually have better intuition and a broader understanding with which to learn new technologies. For example, someone who already knew J2EE would pick up .Net much more quickly than someone with no computer background.

• Have more understanding of the purpose of technology. They've seen lots of business applications, so they know what they're trying to do.

• Have a wider stash of reusable tools and source code to work with

• Can be wiser about what they invest in learning

• Have deeper knowledge. New technology is often built on top of old technology. I've seen lots of young "copy and paste" developers become paralyzed when their program does anything abnormal - like throw a COM exception or accidently encode files in an unexpected format - whereas the older devs have been around and know how to handle that.

While new technologies do come out frequently, there are also many older technologies and concepts that still form the backbone of enterprise apps. Html, JavaScript, Xml, CSS, Sql, code generation, automation, and object oriented languages like C++ and Java,  have all been around since the 90's. A senior developer who already knows these technologies can focus on learning just the new stuff, whereas a young developer still needs to come up to speed on these basics.

Of course, I wouldn't say that older developers are necessarily better, but rather give everyone their chance. There's a lot to look forward to in software engineering, for both old and young developers.

We've all heard of the dreaded downward spiral, where you're behind schedule with lots of bugs, so you cut corners and rush sloppy work, only to create more bugs and get further behind. Some folks seem to think this is just a right of passage for computer programming, but it doesn't have to be that way. Just like there's a downward spiral, there's also an upward spiral, where you do good process and coding upfront, which saves you time, with which you can further improve your tools and process.

I'm a big fan of the upward spiral. The best way I see to jump on the upward spiral is to focus your resources on things that last, and avoid spending your resources on things that don't. For example, there's no benefit to you to waste hundreds of hours writing data-access plumbing code. You learn nothing new, you're probably not energized by it, and everyone around you likely just takes plumbing for granted. Things that "last" include your personal and technical knowledge, tools, helper classes, and any other thing that you can take with you to the next project or feature. Things that "don't last" are tedious bug fixes, plumbing code, obsolete technologies, and pointless trivia. These things help with the immediate task, but then are (usually) useless afterwards.

Practical ways to spend your resources on things that last:

• If you're developing on your own time, if at all possible, focus on learning new technology and techniques that you find interesting - as opposed to just plugging on a boring feature because it might impress your boss. Knowing the new techniques will let you develop much faster later, which will both permanently enhance your developing skills, and impress your boss.

• Try to learn something new each day. Usually if you're working for 8 hours, you can squeeze in a half-hour of experiments that relate to that work. Learning something new each day will quickly add up. Ideally, a developer could happily answer the question "what did you learn today?"

• Actively pursue features that will teach you something. All else being equal, a good boss will want to give you features you're interested in because they know that you'll then be motivated to do a better job of it. So, aggressively show interest in the features that give you learning opportunities. Consider even investing your own personal time to prepare for it. If you invest two hours on the weekend to understand enough of the background to be qualified on a feature, which then lets you spend two weeks actually programming it hands on, that's a great investment.

I understand that sometimes your current project forces you into a rut, and you're just trying to survive. I still remember several 70 hr/week projects when I used to do consulting.  But it's always good to keep your eye on the prize - even if right now sucks, at least be aware of that in order to strive for something better.

An intellectually grueling field like software engineering will attract a lot of smart people. It also attracts smart alecks too. There's a big difference.

No one likes smart alecks. I don't have a cure, but here's some ways I've found to deal with them:

• Encourage them to funnel their efforts into something good. For example, saying things like "That's an interesting idea, why don't you try building it?" or "That's interesting trivia, but do you see anything with a higher rate-of-return to focus on?"

• Don't be intimidated - smart alecks often try to intimidate others with big buzzwords or obscure trivia. But you can cut through the buzzwords by asking them to explain it in plain English. Smart alecks are dangerous to a project, so good developers have an obligation to defend the project against the smart aleck's ego.

• Put the smart aleck in their place, perhaps using a standard pass-or-fail approach with agreed-upon rules. For example, you may say "if your idea is right, then this C# method should not compile, are we agreed?" Nothing like having the compiler itself crush a smart aleck's ego.

• Fire them. It can be tough, but if they're writing bad code, while constantly distracting others with false alarms via pointless trivia and argumentative questions, they may just be "not a good fit" for the company.

There's a saying, "If you have to tell someone you're a lady, then you aren't one." Likewise, smart people don't need to try impressing or convincing others that they're smart, usually people just recognize it as a side affect of the value they add.

I remember when job-hunting back in college, lots of business majors would tell me "It's not what you know, it's who you know." Some kids even used it as an excuse to avoid studying in order to go to parties instead ("Why waste time studying pointless knowledge when what really matters is having a strong social network?"). While there is some merit to the idea - i.e. you do want to build your network - this paradigm doesn't apply well to skilled labor that can be objectively measured, like software engineering.

If a job doesn't require much skill, such that there are tons of qualified candidates, then of course personally knowing the hiring manager is a competitive edge. From their perspective, if all else is equal, hiring a known acquaintance mitigates risk. But, if a job does require a lot of skill, such that recruiters are actively competing to find that top talent, then they will beat a path to your door. In software engineering, if you have the knowledge, then people will want to know you. It's a two-way street: developers what to be employed, and companies want the best employees.

I think of it like talent in the NBA - some players just play better than others (I believe all people are equal, they just some have different skills). That's why scouts are running all over the nation, constantly trying to woo the top free-agents. If you're the top NBA draft pick, even if you don't know anyone yet, scouts are going to want to know you.

Sure, I understand that cronyism and nepotism exist, but in software engineering, such corruption would put that recruiter at a serious competitive disadvantage. Worst case, I'd expect that a corrupt manager's greed would trump their cronyism, and they'd hire the best talent. Anything else would essentially be throwing away money.

We all want faster machines. Slow machines, especially ones that freeze up, constantly interrupt one's thought process and can pull them out of the zone. It's not just the extra 20 minutes spread throughout the day, it's also all the time lost to re-focus yourself after waiting for a long process. I'm no machine performance expert, but here are tips I've learned.

1. Run Defrag.

You can run this via the command line, such that you hook it up to a weekly script. This MSDN explains: "Disk fragmentation slows the overall performance of your system. When files are fragmented, the computer must search the hard disk when the file is opened to piece it back together. The response time can be significantly longer."

defrag c:\ /v /f

2. Clean up your hard drive.

A crowded hard drive makes your machine run slower - there's just less wiggle room for the operating system. I've heard some suggest that you should have at least 25% free. You'll need two big things for this: (A) a backup drive for offloading infrequently used files, and (B) a tool to find obsolete files. One good, free, tool is CCleaner, which detects most of the common spots for dead-weight files. Another tool, SequoiaView, shows all files sizes in a treemap graph so that you can easily see which files are taking up space.

3. Clean out your registry

If you're continually installing and uninstalling programs, your registry may get bloated, causing big slowdowns. Modifying your registry is dangerous and could irreparably corrupt your entire machine (i.e. back up your registry and machine data first). But, given the potential performance gain, it's still worth doing some easy changes. While there are several commercial  registry cleaner products out there, CCleaner is free and works well - it plays it safe and only removes the obvious registry errors. CCLeaner has a feature to clean out much of the garbage from your registry.

4. Adjust your UI settings

Windows XP (I haven't touched Vista yet) lets you choose the balance between "pretty UI" vs. "fast UI". The idea is that pretty graphics (shading, rounded corners, transitions, etc...) take extra resources to render. If you're a developer who wants speed and doesn't care about gradient-shaded window panels, you can turn that stuff off: In "My Computer > Advanced > Performance Options", adjust for "best performance." This will make everything look like old, grey, boxes - but it will be faster.

5. Kill or Block certain "hog" processes and system startup apps

Background services are a big culprit for hogging resources, because these services could always be running. Skim through your Window Services to make sure that all the currently running (or automatic ones) are ok. If a service doesn't sound familiar, ask your IT department if you can kill it. In addition to services, applications that automatically start up when the machine turns on can make for a slow system startup. CCLeaner has an option for this as well, where you can explicitly block unwanted apps from automatically starting up.

6. Avoid running too many programs at once

This is pretty obvious. Under Task Manager, the Performance and Processes tabs can show you your CPU, Commit Charge, and stuff like that.

7. Uninstall the programs you don't need

The more stuff on your machine, the slower it will run. For example, if you no longer develop with VS 2003, remove it. This is also a good reason to avoid installing all those games on your poor, overworked PC. (But if your laptop requires a certain game on it to function, that may be understandable)

8. Use batch scripts to turn off processes when you don't want them

Sometimes you need that heavy service running in the background, but sometimes you don't. For example, SQL Server can take a lot of resources. Consider having a batch script that starts it up and shuts it down - not just opening and closing SQL Studio, but stopping the actual service. You can use the "net" command in a batch script to start and stop services:

net start "SQL Server (SQLSERVER2005)"
net start "Distributed Transaction Coordinator"
 

net stop "SQL Server (SQLSERVER2005)"
net stop "Distributed Transaction Coordinator"

9. Startup script

I try to avoid re-booting my machine because I loose all my sessions - open windows, loaded files, running applications, etc... One thing that slightly eases the pain is having a batch script (clickable from my desktop) that re-opens all my standard stuff, like NotePad, Browsers, Cmd, and Windows Explorer. I don't necessary want this as part of my startup, but it saves me a minute to just click the batch and have several applications all re-open themselves.

10. Run Disk Cleanup

Sometimes your machine may run slow because of a bad disk. Consider running Disk Cleanup. This MSDN article describes more (it also mentions freeing up disk space and defragmenting).

Other ideas

There's always more you can do. I found these other articles to be informative reads:

• Why is My Computer Running So Slow ?

• Top 10 Causes of a Slow or Freezing PC

• Or, just google for more ideas

I've seen that there seems to be two different views of what "process" means, I'll refer to them as the "pro" and the "con":

• Pro - Steps to help save time and reduce tedious and error prone tasks. Examples include: continuous integration, automated unit testing, and code generation.

• Con - Red tape, bureaucracy, and damaging politics - something that exists so that ivory-tower-folk can feel important. Examples include: wasting hours to reformat a private word doc so it meets "standards", or manually going through all your (perfectly functional, production) code to switch the naming convention from Pascal to Camel case.

I've seen projects where someone, with good intentions insists that "we need to improve our process", while others, also with good intentions, just cringe. The problem is that even though they're using the same words, they still mean different things. Obviously any good project should avoid the bad and emphasize the good.

With this, I offer several criteria that a good process should meet:

• As a complete package, it should make life simpler. It should solve a specific problem that the team agrees needs solving. (run your tests, manage your source control, etc...)

• It must always functionally work, from end-to-end. Process that produces bad output will just cause you bigger problems. It is better to have a slower process that works, then a faster process that randomly fails.

• It should have public results so that everyone can see what happened

• It should be publically documented, such as on a team wiki, so that others can understand it (as opposed to always bugging you for questions)

• It should be easy to maintain (automated [perhaps with MSBuild], machine-independent, abstract out variables like pathNames to a config, etc...)

• It should be easy to setup. Process that is a pain to install (perhaps requiring third party components that you don't have licenses for) will eventually just be ignored.

There's probably more criteria, but a process that fulfills all these is off to a very good start.

It's much easier to be reactive than proactive. A reactive person looks at what already happened and tries to make sense out of it - they're always playing catch-up. A proactive person needs to understand the rules beforehand so well that they can anticipate the possible scenarios that may happen.

This is why so many developers are re-active learners. For example, they'll first be given a problem or coding task, then they'll google to figure out the syntax, concepts, and usually code with trial and error until it appears to work (i.e. "coding by coincidence"). It's a very re-active approach, and it suffices for an average programmer.

The problem is that a re-active learner will always be a re-active problem solver because before you can solve the problem, you need to first understand it. This means you need to learn the concepts involved. Furthermore, if you haven't learned the concepts yet, you can't know how the system will react, which means it will likely react in ways you didn't intend. For example, a developer who never learned about concurrency or scalability will be in for a big surprise when their procedures start running in production with multiple users. Such an error can sound very cryptic, especially if "it works on my machine", but randomly fails in production. Instead of designing their code proactively to deal with the problem (where such a solution would be much cheaper), they'll have to try to reactively first learn what happened, and then hope that it's still solvable.

Therefore, a good long-term approach is to not just reactively google coding questions as you come across them, but to also proactively read the actual books and language specifications themselves. That way, you know before hand what to expect from the technology, without waiting for it to do something intentional - when learning the solution may be too late.

Many developers are so pressured by demanding schedules that their goal is just to "get the job done", by which they mean "it functionally works." While this is a great first step, professional programming requires more, such as:

• Maintainability

• Performance

• Scalability

• Security

• Testability

As you go from a hobbyist toy to an enterprise app, these criteria become self-evident. They're buzzwords that everyone has heard, but surprisingly few seem to put into practice. Interesting questions to ask yourself (or someone you need to interview):

• Maintainability - Have you ever had to write code that will be maintained by other people? How did you code differently to make it more maintainable?

• Performance - Have you ever had to write code that was performance critical? How did you ensure that that code was fast enough?

• Scalability - Have you even had to write code that was used by more than 1 million users? What might you do differently to ensure the code handled that?

• Security - Have you ever had to write code that protected secure data and you knew someone would try hacking it? How did you make it secure?

• Testability - How would you ensure that your code could be tested?

Of course some of these, like performance tuning, may take more time. But that goes with the territory of large-scale apps.

In general, I come across two kinds of programmers - those that just worry about functionally "getting it done", and those that look beyond functionality. It seems the first group digresses into boring copy and paste work, whereas the second is constantly on an adventure doing new, fun things. The beauty is that there's nothing that stops someone from jumping into the second group. You can read about all the techniques online, use open-source tools, and often it's even faster. For example, anyone could use NUnit, or MSTest to write unit tests to help their testing, or read about Refactoring or design patterns for more maintainable code.

I hear it a lot from developers - "I know the concepts, but just not the syntax." The thinking seems to be:

1. There's too much out there and I can't know it all

2. The concepts are what really matter

3. The syntax is just trivial stuff that I can look up.

Therefore, the idea is that the developer knows the important stuff (concepts), and shouldn't be blamed for not knowing the unimportant stuff (syntax). Fair enough as long as you know enough syntax to get the job done. However, more often than not, I see developers who continually shrink the first category and enlarge the second. For example, I've seen developers refer to standard concepts for which they're heard the buzzword but don't understand (OOP, exception handling, n-tier architecture, client-server models, design patterns, etc..) as "syntax". Some people think this is a smart way to avoid saying "I don't know." The problem is that these things are not syntax - syntax is language specific details for a single implementation. For example, various languages can each have their own syntax to create comments. The concept is "creating a comment in code", the syntax is what you actually type to do it (such as // or /* ... */ in C#).

A general rule is that concepts transcend any one language. For example, C++, Java, and C# all use OOP, so questions like "What is an abstract class" or "What is polymorphism" are conceptual questions - they have nothing to do with syntax. Likewise, all these xml config files (like the ASP.Net web.config, or even MSBuild) have little to do with syntax - the whole point of making them in xml is to bypass any syntax problems. Rather, they're about "do you understand the problem space?" If you know the concepts to tune a web application, ASP.Net's web.config suddenly makes a lot more sense.

I realize at the end of the day, implementation requires us to know the syntax. In fact, many developers can copy and paste chunks of code without even knowing that conceptually is going on. To such a developer, everything is effectively syntax. However, there's always the benefit of being able to step back and differentiate between the two.

There are APIs in Silverlight that make it relatively easy to roundtrip an object from a JSON string and back. Here are two wrapper methods.

These use the assemblies System.IO and System.ServiceModel.Web (which contains the necessary namespace System.Runtime.Serialization.Json). It also uses the two static utility methods I blogged about to roundtrip from a MemoryStream and back (GetMemoryStreamFromString and GetStringFromMemoryStream).

    public static T ConvertFromJSON<T>(string strJSON)
    {
      System.Runtime.Serialization.Json.DataContractJsonSerializer d =
          new System.Runtime.Serialization.Json.DataContractJsonSerializer(typeof(T));

      MemoryStream m = GetMemoryStreamFromString(strJSON);
      T obj = (T)d.ReadObject(m);

      return obj;
    }

    public static string ConvertToJSON<T>(T obj)
    {
      System.Runtime.Serialization.Json.DataContractJsonSerializer d =
          new System.Runtime.Serialization.Json.DataContractJsonSerializer(typeof(T));

      MemoryStream m = new MemoryStream();
      d.WriteObject(m, obj);
      string strJSON = GetStringFromMemoryStream(m);

      return strJSON;
    }

I assume that the code is self-explanatory. Perhaps the only note is that it uses Generics to dynamically set the return type. You could also optimize the methods for performance by instantiating the DataContractJsonSerializer once, and making these utility methods, as opposed to static methods that re-create it every time.

I think that Silverlight is great, and is far more than a buzzword. I see it offering several big benefits:

1. Graphical API -  Silverlight lets you draw and animate vector graphics. For example, you could easily do a graph. ASP.Net had ways to handle this, but they were slow and cumbersome (for example, use GDI+ to create the image on your server, and then load it up).
2. Programming a compiled language (like C#) on the client - This is just awesome. Whether you've written an entire physics engine that you're running on the client, or just doing complex validation, the ability to code difficult logic in a first class language like C#, as opposed to a brittle scripting language, is invaluable.
3. Rich object and event model - no more postbacks, easy to add controls, etc... - You could modify the DOM using JS, but it's so much easier to do this with Silverlight. For example, try dynamically adding an entire complex UserControl with JavaScript - it's doable, but hard. It's one line in silverlight.
4. Cross-browser compliant - Silverlight just works on the main browsers (IE, Firefox, etc...). No more pulling your hair out because you forgot to check some DOM method nuance.
5. UI rendered through xaml - Silverlight lets you create your "Form" via a markup language, somewhat like Html, but much cleaner. I think this is a cleaner style than creating it via the codeBehind (like WinForms).

How does Silverlight doe this? In one sense, it "cheats" by requiring a small download (kind of like a flash player). So, Silverlight isn't just like Ajax, which plays by the rules of the web but just stretches them by leveraging the XmlHttpRequest object, but rather Silverlight plays a whole new game.

    var Enum_Colors =
    {
      Red:0,
      Blue:1,
      Green:2,
      Yellow:3
    };
   
    function DoStuff()
    {
      TestEnum(Enum_Colors.Green);
    }

    function DoError()
    {
      TestEnum(Enum_Colors.Unknown); //Bad
    }
    function TestEnum(objColorEnum)
    {
      var str;
      switch(objColorEnum)
      {
        case Enum_Colors.Red:
          str = "red";
          break;
        case Enum_Colors.Blue:
          str = "blue";
          break;
        case Enum_Colors.Green:
          str = "green";
          break;
        case Enum_Colors.Yellow:
          str = "yellow";
          break;
        default:
          str = "none";
          break;
      }
     
      alert("The enum passed in is: " + str);
    }

 Thanks to VS2008, you at least get JS intellisence on the "Enum_Colors" object, so that's better than just typing in error-prone literal strings.

A stream in .Net is a sequence of bytes. There are several types of streams. A common one is the MemoryStream which uses memory for its storage (as opposed to a file system, or something else). Several readers and writers require a stream as an input parameter, and you'll find that sometimes you'll just want to be able to easily convert from a string to a MemoryStream and back. Here are two easy utility methods to do that:

    public static string GetStringFromMemoryStream(MemoryStream m)
    {
      if (m == null || m.Length == 0)
        return null;

      m.Flush();
      m.Position = 0;
      StreamReader sr = new StreamReader(m);
      string s = sr.ReadToEnd();

      return s;
    }

    public static MemoryStream GetMemoryStreamFromString(string s)
    {
      if (s == null || s.Length == 0)
        return null;

      MemoryStream m = new MemoryStream();
      StreamWriter sw = new StreamWriter(m);
      sw.Write(s);
      sw.Flush();

      return m;
    }

We can easily test these with a round-trip method. Note that ideally we'd have one test for each specific method, but this is just for demo purposes:

    [TestMethod]
    public void Convert_RoundTrip()
    {
      string s1 = "Hello World!";
      MemoryStream m = GetMemoryStreamFromString(s1);

      Assert.AreEqual(12, m.Length);

      string s2 = GetStringFromMemoryStream(m);

      Assert.AreEqual(s1, s2);
    }

I don't like re-starting my machine because I need to re-open all the misc windows and files I have loaded. However, because I still need to reboot, I wrote a simple script to open common programs and files for me.

REM: Open Windows Explorer

start explorer
start explorer

REM: Open NotePad

start notepad
start notepad "C:\MyDocuments\temp.txt"

REM: Open the DOS command window, default to a certain folder

start cmd "/Kcd C:\Utils\MyTasks"

REM: Open Internet Explorer

start /B /D"C:\Program Files\Internet Explorer" iexplore.exe

REM: Open a Visual Studio solution

start /B /D"C:\MySolutions\StandardFiles" StandardFiles.sln

This opens five main things:

• Windows Explorer

• Notepad - a blank version, and one that stores a simple scratchpad of notes. You could also open other scratchpads.

• Internet Explorer (could just as easily be firefox). There are also ways to pre-populate the tabs.

• Cmd window - I set it to a directory that has a bunch of misc scripts (using the "/K" switch to call the CD command)

• Visual Studio - In this case I open a solution folder with a bunch of misc xml files that I use.

Of course you can add other programs to the list too.

Lastly, I made a shortcut of this batch script on my desktop, so I just click it when Windows loads up. (You could probably automate the startup tasks if you want).