How the Internet fried your brain

No army can withstand the strength of an idea whose time has come.
Victor Hugo

Ever imagined a world where original ideas were the norm?

That wasn't too long ago...

Before the Internet

Lets consider a century prior to ours, when everthing was local - stores, services, social interaction and worries.

Back then, all you had to do was make it work where you live. Which is still the case today.

To make ideas work; you need persistence, patience and perseverance to bring that idea to realisation.

L&P - Laziness and Procrastination
Everyone wants more time because they waste it away browsing or socializing away on the internet for hours, reading up on all the latest news and gossip and sitting hours on end infront of a screen.

The easiest product/service to sell nowadays are ones that enable laziness and procrastination. We have proactively dubbed this - consumerism.
 
Take care not to believe by being lazy and procrastinating yourself - you will bring your big idea into the world!

Unique ideas 
To bring your unique idea into fruitition, this is what you'll need to know:

To succeed in life, you need two things: ignorance and confidence.
Mark Twain

So here are a couple of rules:

• Be ignorant but not stupid
• Have confidence but not headstrong
• Be humble but not a pushover
• Have faith and do not doubt

Don't go looking for problems to solve - and definitely don't ask people for ideas. I reckon the only good time to ask people for business/idea advice/feedback is when they are potential or existing customers.

The Big Question
Why do a lot of people fail doing business?

Simply because they aren't working on their idea. Pun implied.

The Challenger: Larger Size Matters

Our biggest challenger, is not ourselves - but our perspectives.

Image from ideachampions.com

Think small

We believe worthy challenges are bigger than us.

You may have heard some people perform better under stressful situations, while others crumble.

The truth is; persistent challenge-seeking causes fear to perpetuate in most people.

We make everything harder than it is. Fear and anxiety are partners; anxiety will woo you over while fear breaks you apart.

We are big, problems are small

We live in a challenging world, we constantly find a need to challenge ourselves because everyone else is doing it.

I believe beauty is in the eye of the beholder - and so is a bad perspective.

We are actually big, problems are really small. It's Occam's razor: simpler explanations are, other things being equal, generally better than more complex ones.

Big problems are made up of little problems

Well that's obvious, we just don't believe it.

So lets try this instead:

Any big change consists of many small changes.

or consider this quote:

"We have not really looked too hard at low priced stocks over the years. Then we started to look for stocks that could gain hundreds, or even thousands of percent, and we found ourselves with small cap penny stocks. ~ William McKinley

The real challenge lies in the preparation of solving these little problems.

And remember, every small change has an effect.

3 reasons to include developers in strategy meetings

I'll aim to keep this short and sweet:

“When you're building your strategy around the user, it changes the business imperatives. This world of Web services really is not about the technology itself, it's about business. The business issues are so much at play that they are really more important than the technology.” Herman Baumann quotes

In the end it's all about the business. Software. Strategy. Customer Support. Sales team. Project Managers. Developers. Techies.

Not a lot of software businesses get this and they opt to exclude developers from strategy meetings.

1. You can't code what you don't know
Programmers need to know the industry, because after all - you can't code what you don't know.

2. Know what works and what doesn't
Programmers, UI and UX designers are generally familiar with the needs of their users and are usually the first to know when something doesn't work the way it's supposed to.

3. We create things others use
In general, over a period of 3 years a developer working at a dev shop will probably gain experience developing up to or over 20 applications that consumers or businesses use. In essence, you could almost equate applications developed to businesses started 1 to 1 - or in this case 20 businesses.

Now, wouldn't it be silly to exclude the developers from strategy meetings?

After all, they are the ones who will be doing the work.

Stop Smoking

Many IT professionals I know, have or are currently smokers.
But sometimes the shoe doesn't fit, especially if you're working in the medical industry.

Last week myself and my wife switched to using TarGuard without reducing the amount of cigarettes we were used to smoking every day.

It is a lot harder for heavy smokers (20+ cigarettes a day) to stop smoking. Well, at least it used to be!

I have found the real cause behind unbearable withdrawal symptoms relating to stopping smoking to be the non-nicotine ingredients in cigarettes.

I was suprised when I first discovered that I was experiencing withdrawal symptoms while using TarGuard and Nicorette to supplement nicotine levels (TarGuard reduces nicotine levels).

At first I thought I was going crazy, but this simply proves a majority of withdrawal symptoms come from the non-nicotine ingredients of cigarettes (tar, cyanide etc.).

It seems to me like smoking hurts the lungs and also numbs them at the same time, so when going without a cigarette for a while - your lungs start hurting again.

Using TarGuard for a week entirely reduced the pressure/pain withdrawal symptoms for me. Currently, I am only using Nicorette (4mg) and swapping to the Nicorette (2mg) later this week before I stop entirely.

Now the only withdrawal symptom remaining is a slight irritability which is easily conquered by staying busy.

If you're a smoker, at the very least consider using TarGuard to reduce the damage of smoking almost entirely to your lungs!

ASP.NET MVC - Extending HtmlHelper

Today, we will be looking at extending the HtmlHelper for ASP.NET MVC in C# using .NET 3.5sp1/4.

Lets look at some introductory basics:
Syntax for creating Extension methods

public static class {extensionclassname}
{
  public static {returntype} {methodName}(this {objectToExtend} {name})
  {
  }
}

So lets say we want to create an input helper, we could do something like this

public static class HtmlHelperExtensions
{
  public static InputHelper<T> Input<t>(this HtmlHelper<T> htmlHelper)
  {
    return new InputHelper(htmlHelper);
  }
}

public class InputHelper<T>
{
  private readonly HtmlHelper<T> _htmlHelper;

  public InputHelper(HtmlHelper<T> htmlHelper)
  {
    _htmlHelper = htmlHelper;
  }
}

Although it's not necessary to create a separate class to hold the methods for the input helper, it is preferred because of separation of concerns (SoC).

Next, we would add the namespace wherein the HtmlHelperExtensions is located to the <namespaces> section under pages < system.web.webPages.razor in the Web.Config located in the Views directory.

To access our input helper, we would call @Html.Input() and from there on custom methods to render a MvcHtmlString (which is a string - already safe for use as razor output - a normal string would be html encoded).

Here is an interesting use case:
Lets say we want to wrap html in a <div class="input"><- html here -></div> without having to manually write out <div class="input">....</div> every time?

This is done pretty easily, lets add a method to our existing InputHelper<T> class:

public MvcHtmlString Wrap(Func<object, HelperResult> htmlToWrap)
{
  var htmlBuilder = new StringBuilder();

  htmlBuilder.Append("<div class='input'>");

  htmlBuilder.Append(htmlToWrap.Invoke(_htmlHelper));

  htmlBuilder.Append("</div>");

  return MvcHtmlString.Create(htmlBuilder.ToString());
}

Here is an example on how to use this method from within a view:
@Html.Input().Wrap(@<text><label for="name" />@Html.TextBox("name")</text>)

The @<text>...</text> being passed to the method can be seen as a view which gets 'compiled' to html. So instead of writing to ouput:
<label for="name" />@Html.TextBox("name")
  using  htmlToWrap.Invoke(_htmlHelper) compiles down to
<label for="name" /><input type="text" id="name" name="name" />

HtmlHelper extensions are miracilious in the sense they can give you extreme refratoring capabilities and can do much more than one expects.

For example, I have written input extensions that simply calls
@Html.Input().TextBoxFor(model => model.MobileNo)
which in turn adds a label and applies mask behavior and validation logic to the element (behavior and validation via unobtrusive data-* attributes that javascript applies).

All in one line of code - and you could do the same!

Learn a new programming language

Recently I came across Ohloh, the open source network. And got me thinking again how many programming languages do I really know.

This short list pretty much sums it up:

• C#/.NET
• T-SQL
• Javascript

And then some HTML, XAML and CSS.

I see myself more of a voyager of the programming seas, having looked upon the lands of:
C/C++, Java, Delphi, Ruby, Python, Haskell, CLisp, Groovy, Dart, PHP, F#, Visual Basic, NASM, Perl

I also came across Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages doing some googling.

Personally I think learning seven programming languages in seven weeks is generally a bad idea.
My lex parsimoniae test is this:
You are proficient with a programming language if and only if you can generate a continuous profit from your efforts.

I have read many articles and discussions regarding which programming languages to learn.
In general, it's a good idea to know at least one of each:

• Domain Specific Language (ex. HTML/CSS)
• Functional Language (ex. Haskell, F#)
• Strongly Typed Language (ex. C#, Java)
• Object-oriented Language (ex. Delphi, PHP, C#)
• Dynamic Language (ex. Groovy, Ruby, Python)

In general I believe it's not how many you know, but rather, how many you can use. All of us learned our first programming language by placing our focus solely upon it.

With the same effort we applied to the first, we should apply to the next.

I believe it's much better to improve on what you know than to be a jack-of-all-trades in languages you will never use.

Gold plating - YAGNI

Here is the short definition of Gold plating per wikipedia: Gold plating in software engineering (or time management in general) refers to continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any). After having met the requirements, the developer works on further enhancing the product, thinking the customer would be delighted to see additional or more polished features, rather than what was asked for or expected. The customer might be disappointed in the results, and the extra effort by the developer might be futile.

Jeff Atwood posted some interesting blog posts too:
The Ultimate Software Gold Plating
Gold Plating

Just in case you are not familiar with the concept of YAGNI: You Ain't Gonna Need It!

For the sake of pants, I'll coin a new term developmestruction:

Developmestruction occurs when a lack of details or developer foresight causes development to become a destructive force towards time and money constraints, as well as posing a succinct threat towards project goals and client patience.

In short: Destructive Gold Plating = Develop-Me-Struction

As stated before, the first childhood signs of a developer causing developmestruction is when planning isn't done appropriately.

The simplest example of this would be:

    As a company you are running seminars - each of these seminars have their own prerequisites in terms of the target audience and some business logic factors.

    Developmestruction approach: Create an entirely dynamic way of adding/creating new seminars via multiple crud and management forms, totally avoiding the problem field at hand.

   YAGNI approach: Hard code the majority of the logic and allow only some logic to be configured.

Got .NET?

Recently, while wetting my feet with a few programming languages (Ruby, Haskell, Common Lisp, Python, C, C++) I came to the realisation - learning a new programming language is hard.

Generally, programming languages are classified into one or more of these categories:

• Object-oriented
• Dynamic
• Functional
• DSL (Domain specific language)

 Some being statically (strongly) typed (ex. C#, VB.NET, Java, C/C++) and some dynamically typed (ex. JavaScript, Ruby, Python, Groovy, Dart). Also, general programming languages (previously mentioned) differ from domains specific languages  - even though some DSL are general programming languages too, for example:

• Microsoft Dynamics implementations
• Nodejs
• SAS
• Objective-C

HTML and CSS are DSL's too! Then again, you get DSL's built upon DSL's (DSSL - Domain-specific specific language?) such as CoffeeScript, Haml and Less.

So, before wandering too far off, I thought it'd be good to share some resources that have helped me conquer the mountain of learning .NET (Not including the MSDN):

• http://www.asp.net/
• http://www.asp.net/mvc
• http://channel9.msdn.com/
• http://channel9.msdn.com/Series/mvcConf
• http://www.pluralsight-training.net/ (Excellent! Well worth the price!)
• http://www.hanselman.com/blog/
• http://omaralzabir.com/
• http://haacked.com/
• http://stevesmithblog.com/ 
• http://karlshifflett.wordpress.com/
• http://weblogs.asp.net/scottgu/
• http://www.codeproject.com/
• http://kentb.blogspot.com/
• http://wpfdisciples.wordpress.com/

and finally

• http://stackoverflow.com/

Here are some interesting reads to pass the time:

• The Daily WTF: Curious Perversions in Information Technology
• Coding Horror: Programming and Human Factors

Perhaps in the future I will expand this list, but for now: Happy Coding!

Programming Gamification

The concept of gamification has been around for a while.
http://en.wikipedia.org/wiki/Gamification
It has spawned a new age of educational training and some programming languages have already put to the test some interactive tutorials.

I first came across a gamified interactive tutorial while studying a functional language (Haskell.org). I found it so addictive, I loaded it up on my Blackberry Torch later the day while I was waiting at an interview. Needless to say, it has a small glitch which is rather bothersome when using a small screen/mobile device - but I don't believe they had users in mind using their mobile phones when designing an interactive programming tutorial ;)


http://tryhaskell.org/

At Try Haskell, they stated: concept and interface blatantly copied from _why's Try Ruby!

At that time I wasn't entirely interested in learning ruby - after all I already had done some python and was more interested in python's and ruby's love-child: Groovy.


At a later stage I eventually did go try Ruby. At this very moment, I haven't finished the entire tutorial but did come across another interesting site: Code School - Learn by Doing whom offer some interesting courses, such as:

• Rails for Zombies
• Rails for Zombies 2
• jQuery Air: First Flight
• Functional HTML5 && CSS3
• Rails Best Practices
• Try Ruby (Same as previously mentioned I think)

Honestly, my interest in gamification started developing after reading some articles of at Jeff Atwood's blog Coding Horror. The article that got me interested was this one: http://www.codinghorror.com/blog/2011/10/the-gamification.html - quite an interesting read!

It gave me an idea of developing a gamified programming challenge type game, ranging from beginner to advanced level. (For those who just finished these try * gamified tutorials who are somewhat acquanted with the programming language).

The game would use the .NET Framework and the game itself focused around hacking and other challenges - with this catch - you would have to write and improve your own library in your language of choice given theory and specifications ingame. Intermediate Language would allow gamers to use C#, Visual Basic.NET, C/C++, IronPython, IronRuby, F# etc. out of the box to implement their libraries - not that it would be impossible to make wrappers for haskell and other programming languages.

Given such, there are somewhat endless possibilities.