Gaining access to these strings from C# is pretty easy however I’m yet to find anywhere explaining it the way I find simplest.

Assuming your resx file is stored in the App_GlobalResources folder, you can basically assign your resource file to a variable in your C# using the following syntax:

using Res = Resources.MyResourceFile

This then gives you the ability to referene the contents of the resource file as properties in your code.

string x = Res.OneOfMyStringNames;

al⋅go⋅rithm [al-guh-rith-uhm]

–noun
a set of rules for solving a problem in a finite number of steps, as for finding the greatest common divisor.

Dictionary.com Unabridged
Based on the Random House Dictionary, © Random House, Inc. 2009.

One of the greatest things I’ve found about the work I do is that concepts from one field often tend to automatically map over to work I do in other contexts. When I first learned about Object Orientated Programming, I started to see the world in terms of objects. I’d look at the TV and think “hmm, the TV has XY and Z properties and these methods exist for doing those things and if event q happens, method k gets fired”.

These things tend to mellow out after a short period of time but it’s hard to learn anything without it becoming part of what you do and how you operate. The more things you learn the more choices you have about what behaviours you exhibit and this leads me to the idea of Algorithmic Thinking.

As programmers, we all know about algorithms and their importance in software engineering but what about in the rest of the world. Since the idea of algorithms isn’t one from programming but one from mathematics, and mathematics being the way in which we model the world around us, it makes sense for us to take our knowledge of algorithms and to begin thinking about other things in a similar way.

One of the great things I love about algorithms is that they’re implementation neutral. That is, the algorithm defines the finite series of steps to follow to get result x but it doesn’t tell you how you should implement those steps. That’s part of being creative and artistic and the more of each of those you are, the more exciting it becomes to figure out new ways of doing lots of different things.

Every now and then I spend a little bit of time thinking completely algorithmically so that I can more easily build up that part of my brain that deals with problem solving. If I have the cook dinner, what algorithm am I going to use? Maybe I’ll come up with three or four different ones and then pick that one that best suits what I want.

Then I get to implement that algorithm and figure out different ways I’m going to go about that. If step one is to get the ingredients out of ther cupboard how am I going to implement that behaviour? Will I simply walk up and get them out? Maybe I’ll climb up a small step ladder to reach? Perhaps I’m going to put some music on and dance my way over to the kitchen? The beauty in this part is that you get to be as creative as you can imagine.

I tend to think of things in terms of puzzles, whether it’s cooking a meal, writing a computer program or simply figuring out what’s going to come next in a movie. Part of my love for being on this planet is our ability as humans to solve puzzles and problems and to always be creating new ways of doing things.

I’m interested in what kinds of fun algorithms people can come up with for every day tasks. Whatcha got?

When I was first introduced to the idea of using user stories in a commercial environment I didn’t really know what they were. I’d seen some other people using them and noticed that they seemed to be a breakdown of what was needed for a given system and then the developers would pick up one story at a time and work on it. “Marvelous!” I thought, but what’s the point?

A brief introduction to user stories

www.agilemodeling.com define User Stories as being:

User stories are one of the primary development artifacts for XP project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP project stakeholders are called customers).

Ron Jeffries Three C’s:

Ron Jeffries of xprogramming.com has identified three many components that make up User Stories:

Card

• Stories are traditionally written on note cards.
• Cards may be annotated with estimates, notes, etc.

Conversation

• Details behind the story come out during conversations with product owner.

Confirmation

• Acceptance tests confirm the story was coded correctly.

Source: XP Magazine 30/08/2001, Ron Jeffries

So what’s the point in all of this?

For those of us who have worked in AGILE environments  before it will seem obvious to say that communication is the key to any succesfull project however for many, this idea can be quite a new concept.

But what is communication? When we talk about communication as a noun (nominalisation) it’s easy to “think” that you’re communicating effectively and as long as “communication” is “done” then you’ve done all that’s required. In my experience, that’s not what really happens and the necessity to de-nominalise the term “communication” is of huge benefit.

Depending on who you’re communicating with determines how you communicate. When working between teams, whether it be between technical teams or between techies and the business, there are certain parts of the communication which are vital:

• A common language that everyone can understand
• Clarity in communication eliminating as many ambiguities and nominalisations as possible
• Flexibility, not only for negotiation but also flexibility in what you say, how you say it, and what your intent is with the things you say.
• Language to experience map-across (re-connecting the words said with the actual experience they describe)
• Clear intent for the communication it’s self (what are we all here for)
• The ability to accurately gather information (ask targeted questions, listen in an information gathering way etc)

These are just a few of the things that I consider necessary for good communication and I’ll be covering many of them in more detail, plus more, in a new series of posts about communication.

User Stories are one step in the bigger picture of communication. By reminding ourselves to discuss things with real people, by chunking information in such a way that it becomes more easily estimatable and trackable and by promoting a transparent work ethic, we all win.

The main reason for this is that each art has it’s own strengths and weaknesses. Some arts are good for distance fighting, some for close range, some are better than others at ground work and some have better defensive maneuvers than others.

For thousands of years there are have been conflicts and debates about which Martial Art is better than which and which one will “kick butt” more than the next. There have been inter-style battles, movies made, battle field conflicts and even Internet flame matches of people trying to prove that their Martial Art is the best.

Now we’ve reached a time where being eclectic is sought after. Where the best of the best are versed in all areas of defense and attack and where battles are no longer about which style you use, but about how good you are compared to the next person.

This is a revolution that’s going to happen in the world of programming and already we’re seeing the idea of the Mixed Language Artist beginning to spread.

When I think back over the last 10 years of programming, even to before I was commercially involved, we find that old “My language is better than your language” debate popping up all over the place. Whether it’s on Internet Forums, Books, Blogs, Webinars or Live training events.

This article signals the end of those times and the beginning of something new. This is the era of the Mixed Language Artist.

What is a Mixed Language Artist?

A mixed language artist is ultimately someone who does what it takes the get the job done. No longer do we developers sit behind our language specific berlin walls in our ivory towers of smuggness. The Mixed Language Artist knows what tools to use to get the job done. Whether that’s using C# and .NET, PHP, Ruby, SQL and even software like Excel.

I recently wrote a post about utilisation in which I talk about the idea of utilising what’s already available to you as a developer before you go about re-inventing the wheel. This is another skill for the true Mixed Language Artist because the ability to take what’s already out there and to use it in a way that fulfils your criteria and saves time, money, skill and sanity are all key components to being a true artist.

So how do you become a Mixed Language Artist?

Being a Mixed Language Artist is not just about programming or programming languages. It’s an attitude that leads you in a direction where the language is just a tool in getting the job done. The cornerstone to all of this is the attitude. It’s about knowing what you want to create, knowing what tools you have available to you, being able to utilise what’s around you and ultimately, it’s about feeling that rush of a job well done.

For thousands of years the Martial Arts developed before Western Society realised the benefits of mixing the strengths of each art together. Today we can make a choice the create a new wave of developers, engineers, craftsmen and architects. This is the time of the Mixed Language Artist.

Usually in the technology world when we talk about utilisation, or more specifically in the software engineering world, we’re usually talking about some form of code re-use. Re-using code in a project is almost a no-brainer but there’s another side to utilisation that’s not so often talked about. This is the type of utilisation I simply call “using what’s out there”.

Now sometimes when we talk about things on a website like this, there’s often the temptation to answer “well of course, duh” but the truth is often different than the behaviour people exhibit. What I refer to as “using what’s out there” is nothing more than going out and finding what’s already out there in the world to fulfil the business requirements or other criterion.

There are two main things I’ve seen as an software engineer that prompted me to write this post. The first thing is the idea that all software must be written in-house because it’s just the way things are. Now sometimes this is a really useful belief and can often lead to some fantastic new and innovative software being created. Other times, and more often than not, this leads to time wasted. I say that because the truth is, if there’s already software or “things” out there in the real world that can fulfil the business requirements and add business value then it makes good sense to utilise those things and spend your time on other tasks that can add even more value to the business. The bottom line is, if what you’re doing is adding less business value than you could be by making your life easier, start making your life easier and offer more value to the business.

The second thing I often see, and this ties in well with the first thing also, is the idea that the technology you use to engineer the things you want, is the most important part of what you do. As software engineers the idea of being eclectic should be nothing new but for even still there are some who will only use specific technologies.  To me this simply doesn’t make sense. To say that C# and .NET are the only tools to use for developing software is like saying that a spanner is better than a screwdriver for everything. I’ve often joined a new company and found them re-writing software from one technology to another simply so they have everything the same. Now I know some people do like to have everything the same and to have all software written in the same language, and the main reason people give for this is that they want to interface each different application with each other. Sometimes it’s useful to take that approach and mostly it’s not.

Once we start to focus more on what being an engineer is all about, and when we work closely with and in the business, it becomes easy to see that the future of our industry is not in the specificity of technology nor is it in the art of being the 0ober-smart developer guy. The future of our industry is in our ability to offer genuine value to the business’ we work with and to utilise what we need to get the results we want.

This blog for example is a demonstration of utilising software that returns the right amount of business value and allows me, the consumer, to post the things I want to post and not spend 2 months developing an in-house blogging system.  Some people would be shocked that a primarily Microsoft based developer would use Wordpress, a PHP based blogging system, to create a website. Again this comes back to the idea of being an engineer and knowing which tools to use for which job.

There are people who say that there is no need to re-invent the wheel. I agree.