Now flash forward a couple months ago when I went on a painful trek as I tried to find a language that could do more then what C# could handle. Far as I was concerned, I had out grown it. Like VGER (And Spock for that matter) I had outgrown the world of C# and needed something more even though I wasn’t sure what that something was. “It knows only that it needs, Commander. But, like so many of us… it does not know what.”

I thought I could find satisfaction in a new language even though I had failed before at that. I looked into Ruby, Scala, Python (Again), Boo, but something just didn’t take. It wasn’t long before I realized that they are ultimately like C#. Sure some are dynamic, some are intelligently typed, but in the end they were the same. It was just a question of how I liked the language to look, but not how things were done. Meet the new boss, same as the old boss.

It was at that point I decided to just put my shoulder down and start running toward the unknown. Toward a functional language. My first stop was F# and it was surprisingly amazing. I finally found a language that would make me keep up and not the other way around. I put a ton of time into it for 3 months, but stopped. It wasn’t the language itself, the functional design, or performance. It really came down to the half —ed implementation that The good professor Microsoft decided to eh… implement. File structure (Or literally lack thereof) was painful. It’s inability to use the built in MSTest UI was even worse. To add to that, the only way I could get a nice debug enabled testing framework was through Resharper and even then I’d have to run every test in an assembly before it would add it to the suite. Add in it’s failure to work with Entity Framework without a third party library, Power Pack and well FFFFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU…

Ok… So I think you might get that I am a little bit mad about the situation. The reason isn’t that I’m trying to be an -ss but I REALLY LIKED F# AND THINK IT DESERVES BETTER THAN JUST TO BE SOME LAME -SS SIDE PROJECT.

I’ve learned this lesson before though and I just stopped bothering… at least three times until last Tuesday when I really, for really, not joking this time, quit F# for good. Yeah I’m not good at giving up on things.

Annoyed and looking for something to fill my need for functional languages, I decided to go all out. If I’m going to be functional (Programming functional not as in functional alcoholic) I’m doing it the full way. That’s right, I have turned to Lisp… just kidding. I am going full Haskell. Yes that language that is never talked about in name lest it release some demon or some weird looking dude when said three times in front of a mirror. That Haskell. Even before I knew what a functional language was, I had heard of it and was told to never look it in the eye and to keep on walking. I’m not sure why there is so much fear and secrecy around Haskell. I realize that, as the old cliche goes, people fear what they don’t understand, but the fear/hate people had for it seemed irrational. Like it was some kind of invading army hell bent on instilling some sort of dictatorship. I know I’m being a bit hyperbolic but the point is that people treated like it was a personal attack on programming. Like it’s existence was purely for insult and nothing else. Good thing I’m too dumb for my own good and ignored the warnings… it just took me four years to do so. (But in my defense, I hate quitting to a fault so I thought I should ride out the .Net stack.)

Now with this move it caused two problems: I had to take off the .Net training wheels and figure out how to even get Haskell to compile. The other was… How the –ck do I handle database oriented persistence? I mean for C# you have NHibernate, LLBLGEN, Subsonic, that entity thing… you get the point. There’s no shortage of ORMs for the .Net world. Tried to see if there was one for Haskell, but I started really thinking about this. One of the issues I had pondered with functional languages is how do you relate a database to objects if you aren’t really using an object oriented model. It’s quite a conundrum. (I spelled that right the first time.) I mean I’m sure you can force out some kind of object like model if given enough time, but was it really needed? To this I say no! (I think)

One of the concepts I’ve had to learn early on with functional programming is Tuples. Essentially a tuple is stuff bound together.

Could be a key value pair:

(“firstName”,”Sean”)

Could be a list of various strings grouped together:

[("Sean","111 Cool Lane",34),("Andre","111 Stupid Street",33)]

Point is, it’s stuff grouped in a like way. In fact, it has to be grouped in the same way. Take the one above for instance. It is a “list” of (string, string, integer). As long as anything added to it has the same signature, everything is great. If they don’t:

[("Sean", "111 Cool Lane", 34), (1, "111 Stupid Street", 33)]

Well… Kaboom. Now here’s the interesting part (One of many I hope): If you have a list of tuples and you squint real hard, you might mistake them for classes. After all, isn’t that what a class is? A bunch of stuff forced to be represented in a set way? If you think about it, this is basically how dynamic languages like Python or Javascript work. The “class” is just a bunch of key value pairs. You can call a property on an object like this:

something.DoStuff

Or you can do it like this:

something["DoStuff"]

Yes it’s psuedo code and probably not 100% correctly represented, but that’s not the point. The point is that an object can be made of from key value pairs… Basically like the tuples above… and that’s where it gets really interesting.

I started to think about what would it take to represent a user. Say you have a plain user with Id, FirstName, and LastName. Well you could have a class:


public class User
{
public int Id {get; set;}
public string FirstName {get;set;}
public string LastName {get;set;}
}

Or you can have a tuple:

[(("FirstName","Sean"),("LastName","Isawesome"), ("Id", 1))]

Now here’s the funny part: I originally didn’t think the tuple representation was possible due to a possible type conflict. But sometimes in our most idiotic times there can emerge a real idea. The idea is simple:

WHY THE –CK DO WE SPEND SO MUCH TIME FORCING TYPES IF MOST OF THE TIME WE JUST NEED STRINGS!?!!

I know, it sounds odd at first but if you really think about it, does it matter if an Id is an integer? Sure in the database, but outside of it? Here’s a typical MVC round trip:

You take in a json string and turn part of it into an integer. You push that integer to a class (Model or other wise) and then use the class to transport that Id to be used as a string in a sql query or it gets converted to some other database happy type. It then is pulled back out of that database friendly type and pushed into an integer so it can hydrate a user class. Then the id is passed into a model so it can be turned into a string for html or json.

This begs the question:

WHY THE –CK DO WE SPEND SO MUCH TIME FORCING TYPES IF MOST OF THE TIME WE JUST NEED STRINGS!?!!

Think about and I mean really think about it. How often do things typed as integers (Or decimal or date or whatever the –ck you want) get used for anything but to be aimlessly typed and retyped? How often do any numbers get used for anything number related? In the world o’ web development there is very little use for numbers. Sure you might have to sum them up, but doesn’t it seem more logically to start as a string and only type when it’s needed as opposed to type something to anything but a string when all it ever will be used as is a string? It makes no –cking sense. None.

But maybe somewhere you might have to validate that the number falls within a certain range… GREAT! Convert to an integer and check!.

But maybe it has to be a proper date. –CKING GREAT CONVERT AND CHECK!

But, but what about when persisting to a database… THIS IS A GOOD REASON… eh to convert.

If there’s anything I’ve learned from the newfangled ideas of lean and such; it’s that you build only what you need. Don’t over complicate. Don’t over think. Don’t pass go and collect 200$. If there is no reason to type something as an integer, then why would you? Join the revolution. We can win this one or look like complete –sses while trying. I can’t promise which, but I can promise one will happen.

This is just the begining…

Enter Andre and the good ship .Net. Andre has an idea of creating a site for cancer survivors (Completely non shameful plug) and at first I was a little reluctant to go back to .Net. And honestly, if it weren’t for how complicated it is to set up python on a server, I probably wouldn’t have. But being as it is, I decided to take another run at .Net 4.0 and MVC 3.0.

Until that time, there had been something nagging me about Python. It wasn’t the performance since it seemed to work very well. It wasn’t the language syntax. I really like the forced syntax since it helps to keep standards. And I like dynamic languages like a person who likes dynamic languages. The f–k was it?!… Sorry that sentence was uncalled for. I’ll try again What the f–k was it?! I mean the language was built to be easy to use and easy to build with. And honestly, it is. What wasn’t I happy with it? WHY CAN’T I JUST BE HAPPY!?!?!?1117

Well right before I went back to C# for the site, I was sort of dreading the idea of having to work in a semi non dynamic and ridgid language. But it was for a good cause and like a man trapped in a jell-o wall, I would just have to push my way through. (Ok so I’m not exactly Leslie Nielsen here)

Then something magical happened. Maybe not David Bowie Labyrinth like magical, but still some degree of magicness. What was this crazy thing? I actually remembered why I liked programming in the first place. Yes C# isn’t as easy to use as Python. Yes it’s more rigid and demanding. Yes you end up with a ton more classes and flies for that matter. BUT I think that because Python is so easy to use, it stifles imagination and creativity. Everything is so lax and unpunishing in Python that it’s so easy to forget the more intellectually (And I use that word loosely in reference to me) challenging aspects of programming. You don’t need interfaces. Mocking object for unit tests is stupid easy. Hell you can even get away with out really creating many classes. Everything is so d—ned easy.

Yeah I know, I’m nuts. I don’t think there’s any question about that. With that said, I think there is some truth in what I’m saying. If you are just a paycheck programmer, you probably could happily roll with Python as it’s structure is by far easier to work with. If you really enjoy the challenge of creating systems that can be refactored and decouple constantly, it’s kind of boring. Don’t get me wrong, you can still do these to some extent with Python but in reality there’s only so many ways you can improve what you have. Far as I know, that’s by design since Python was created more for fast prototyping and development.

I guess I would compare it to cars. Some people would rather spent more money to get the complete package. You could go and buy the new 2012 Mustang Boss and get it loaded for about 45k OR you can buy a GT and spend less than the 15k price gap on aftermarket parts. They both would end up with great performance and both could have good arguments on which is the better way to go. It just depends on the kind of person you are. Some people like the easy path because it’s most likely the faster path. The others, well the others like the journey to get where they want to get. The old “Life’s a journey, not a destination.” cliche.

Which is better? Well that’s up to you. On one hand have Python that is built for fast production. The other is C# that can provide more self challenge and to some more self enjoyment from the challenge. Not sure which side is right, but I just seem to lean to the latter.

Does that make me a horrible person? No it’s just what I like. However, the drink I thought up that’s made from freshly squeezed celebrities might. (Now with less pulp)

I swear to complete my task to the best of my ability.
I will not settle for good enough to complete a task.
I will admit when I don't know and seek help from those who are more knowledgeable.
I will never obfuscate to ensure my continued employment.
I will prevent future issues by taking care of current ones.

And so on. Now this may not fit with all developers, but I have to think there’s a decent amount of developers that would like to hold this oath as a guideline for development.

“Aye, and if my grandmother had wheels, she’d be a wagon.”

I would have to think that such an oath would work if lives were at stake like they are in medicine. After all, there’s a pretty good indication of failure when a person lives or dies. Programs for the most part are a bit more gray. How many times have you walked into a new job to work on a system that is less than optimal? Then how many times have you asked how the client can stand it and the answer is, “They’re used to it.”

As horrific of a statement that seems to a developer, to the business it’s really not that big of a deal as long as the customer keeps paying. Rewrites and major updates just aren’t going to happen due to the old adage, “If it ain’t broke, don’t try to fix it.” After all, taking time to fix may delay any new features and then could open up a window of opportunity for the competitor. Beyond that, it’s probably a tough sell to the customer. “Sorry we need you to pay more for what you have now because the people we had before working on it weren’t very good. But we seriously have good people this time around! Looooooove youuu.”

So most programs are set in this sort of “Fix it however you can now and we’ll address later” which is the development equivalent of “Don’t call me, I’ll call you.” Of course fixing however it can be fixed only leads to more issues down the road. Around and around the wheels go on the bus.

Because of this unfortunate paradox, I think a little of us dies each time we work on a system. We start to break our oath a bit more every day until the point where we either jump one sinking ship for another or just phone in the code and learn to say, “It’s just work.”

Kind of the overdone cliche about a state representative that sets out to change the world only to end up being accused of snorting cocaine with hookers in Vegas.

I think a good amount of people, and maybe I’m insane (Which I am), want to do it the right way. They want to constantly improve that they’re working with. Problem is, this just doesn’t fit the business mind in the US. (Or other countries, but I can’t speak to that) The US Business culture just isn’t about doing it right, just doing it fast. So systems get built fast, are poorly tested, and covered with layer and layer of “fixes” to the point where it’s so massive that no company will pay to rewrite it. And even if they do, chances are the same attitude that build the mess in the first place will just show up again. Two months after pulling the company off a ledge, you’re ready to get up on that edge.

So how can we solve this? Can it be solved at all? Do any companies get this right and if it does, are they few and far between? Do you have to be in the 90 percentile to get that job?

I have to admit that from time to time I’ve wondered about this. I mean sure you hear of the mystical land of Google or Microsoft, or places built on magical things like TDD and Agile development. But hell, there are only so many jobs and only the top people get them. Does this mean the dream is dead for the unchosen many? Is it possible to bake your oath and eat it too?

Now with that out of the way, I’ll attempt to get to a point.

For the most part, when I was competing (post 1996) the prototypical national champion for weapons (Or forms for that matter) was somewhere between 5-6 to 5-10 and 150 to a buck seventy. As forms became more “flashy”, it was very helpful to be light and compact. (Examples like Jon Valera or Mike Chatr.. Chatura… Chat and later on Steve Terada and the legendary Kim Do) Then there was Dan. Dan was 6’1″ and (sorry Dan ) 240ish. He was about as far from prototypical that one could get… and he still won constantly.

I think the word “talent” gets thrown around a lot without people really knowing what it means. In my ten or so years of competition, I saw a lot of “talent”. There were people that were just plain gifted. It came so easy to them that it was just like breathing, but they weren’t the best. They weren’t the ones taking home National Championships. Why? Because they weren’t persistent.

Dan wasn’t a champion because he was gifted. I’m not sure anyone ever said he was “talented”. Excellent? Yes. Elite? For sure. But “talented”? That’s just an insult. Wait… what? Insult?

You see, I think when people say “talented” what they actually mean is “lucky” or “just born with it”. I think it’s used almost as an excuse by people that don’t want to work for anything. There was nothing “talented” about Dan. He was a hard worker. He was the guy that ran a school, worked another job, and still managed to practice with any free time he had. (Even outside before work) He was the guy that would be training on Saturday and Sunday mornings. (In fact one thing he used to say when we trained on Sunday mornings was “Everyone else you’re competing against is sleeping right now.”) It wasn’t something he was given by some god or genetics. It was pure time, work, and persistence. He never stopped, he never gave up, and he never took it easy. He lived by the mantra of “Second place is first loser.” To call him “talented” is to ignore the countless hours he gave to his training. The weekends of traveling to anywhere from California to Germany. The overwhelming drive it took to keep competing. That is what made Dan elite. That is what made people like John Valera and Steve Terada champions. They were the ones that pushed on where most would fold. In the world of the elite, there are only the persistent. The gifted ones were left far behind.

Now the question you might have right now is: Is this going somewhere? And yes I say. Yes it is.

I think the “talented” frame of mind is too prevalent in world of programming. I think most programmers are too comfortable to just slap “talented” on anyone who excels at programming. Now it’s true, some people are just smarter than others. For every Dan Cousineau in the world, there are five others that fit the prototypical programming mold. However, I’m willing to bet most truly great programmers, “gifted” or not, live to program. They spend a lot of time outside of work programming. When other people are out getting drunk, they are perfecting their craft. They are the ones that push past the fear that most have when moving into new territory and just do it. They persist. They don’t give up. They don’t make excuses. They do.

If you want to be a truly great programmer, or hell even slightly better than average like me, you have to do. You can’t sit around in a pity party going on about how someone else has it better. You can’t make excuses for why other people are excelling. You can’t just blindly slap the “talented” word on someone and console yourself when you see that person getting out of your reach.

Or you can. But just remember that out there, somewhere, there’s a Dan Cousineau busting his a– while you sit around wading in your tears.

The choice is yours.

There’s an old saying in Tennessee — I know it’s in Texas, probably in Tennessee — that says, meet the old boss same as the… meet the boss… New boss is the same. I can’t help but feel like Razor isn’t really a step revolution as it is just an evolution. Sure there are newer features like replacing the <% with a @ and… well hey you can replace the <% with an @.

Ok so maybe I’m being a bit hyperbolic but in all honesty, why not be? Now I know I’ve been hard o… mean to Microsoft in the past but it’s out of respect really. I’ve come to expect Microsoft to really have its ducks in a row. After all, Entity Framework 2 was a huge improvement over 1 and I think it’s safe to say that C# has come a long way. Razor just feels like a half hearted attempt to bridge the gap between the old MVC engine and something like Spark… lovely, lovely Spark oh how you make me so happy.

After using it for a couple months, just not really impressed and the only thing that I would say it has over Spark is intellisense on the front end, and to be honest, that’s not something a good programmer (IE Not me) should rely on and therefore isn’t really a +1 in the win column.

This is at best baby steps. I expect more from a company like Microsoft where smart people are grown in smart people farms. (You know, free range organic smart people. No steroids.)  Average Joe’s like me look to Microsoft to really just shake the ground beneath me and make my life better at work because let’s be honest, it’s painful convincing Microsoft hardened programmers to adopt something like Spark because it’s not Microsoft. (Holy run on sentence.)  I’m tired of seeing cut up HTML. I’m tired of seeing yellow highlights. Is it too much to ask to take the Spark pseudo HTML look and run with it?

This may seem like a petty thing to hit on, and maybe it is. After there were improvements to the MVC viewing engine with the introduction of Razor, I can’t deny this. Maybe I just have too much love for HTML in the first place. But even something in line with Razor (Uses a similar look and feel) such as Pylons for Python is better (In my opinion, which with $3 still can’t buy you coffee) and that’s completely free to use. IE doesn’t require a business to buy a 10k IDE. (Yeah I know there are alternatives that are a lot less but really, how often do you see businesses going the non Visual Studios route?) I want Razor to sell itself to me. (Take that sentence however you want to.) I want it to make me think, “You know what, it’s not perfect but it’s a damned good replacement for X.” (Sort of like Entity Framework 2 did or MSTest even.) I want it to just hit me over the head with a club and drag me home by the hair. Right now I just feel like it’s doing the “yawn to arm around the shoulder” move. You know, skip that thought since I’m not sure I’m really comfortable with the direction I’m taking these analogies.

Point is, I expect more from the mothership. The best thing I found with Razor is the ability to use dynamic models and that’s really more on .Net 4.0 than Razor. (Which is a feature I really, really like despite the confused tone of the dynamic model post.)

I suppose my view is a bit tainted though since I pretty much take a lot things for granted since I have used Spark for over a year and can barely remember the original MVC view engine. I suppose it’s possible if I had gone from the old view engine to Razor I would have a different view. I suppose that I use the word suppose too much.

Here’s an example:

    [RequiresAuthentication]
    public ActionResult ShowBasicInfo()
    {
      IState currentState = ObjectFactory.Create();
      dynamic returnModel = new ExpandoObject();

      returnModel.UserName = currentState.CurrentUser.UserName;

      return View(AccountActions.ShowBasicInfo, returnModel);
    }

As you can see, I created a dynamic class and just added a property to it. Now on the view side:

...
@model dynamic
...
          <label id="showBasicInfoEmail" name="showBasicInfoEmail">@Model.UserName</label>
...

So if that’s all you’re here for, well there you go. Now get out.

Ok so the real point to this post was actually the “should I?” Now with .Net, you really have to adopt a “should I?” attitude on anything that is new otherwise it might come back to bite you in the a–. (Update panels anyone?) Just using something because it looks easier is NOT a reason to do so.

The reason why I originally gravitated toward typed views was I didn’t like all the magic sting junk that came with the View dictionary, or whatever the hell it was called. (I’m too lazy to look it up) Typed views gave a sort of concrete nature much like an interface does to a class. You knew exactly WHAT the view could show based on the model. This is good I still think in an environment where you don’t trust people to code correctly or when a person needs an easy place to look up what the incoming model contains. After all, on the second point I mean, its a lot easier to look at a class to find EXACTLY what the model has than looking at a controller action code. Simple for reference.

With that being said, getting stuck in model hell can happen. After all for every action there is an equal and… wait… there is a model. Yeah you can reuse models to cut that down, but its not too hard to imagine it becoming a model infested nightmare. Sometimes you just have to take the good and the bad, but sometimes you’re able to trust people and just go with what is easier.

Why trust? With Python and it overall dynamic nature, it was easy to see that such a tool put in the wrong hands could be a disaster. Anyone who has worked with JavaScript will know this pain. Python is just a fancy way to annihilate your foot, so the concept of allowing dynamic models only made me shiver like a prostitute on Christmas. Sorry, that wasn’t appropriate. I meant a prostitute on a non religious holiday like Thanksgiving or the Chinese New Year. (Sorry non Christian readers)

On the other hand, when in a small group where you have less time and more to do, it could be used as a compromise as it doesn’t use the hated magic string dictionary thing approach, but still had a class like feel. And on top of that, if you wish to create models later, it would be extremely easy to swap the @model dynamic with whatever class type you need. So in that way, I can almost stop my non stop convulsing that is a natural reaction to doing something I deem bad.

Answer is: I don’t f–king know right now, but I’m going to fly with it and see how I like it.

Side note: One drawback of the dynamic route is the lack of intellisense. That could be a deal killer for some.

NOTE: When I use the word “attribute” I really mean things like properties, fields, methods, ect on a class. Since I am guessing most people reading this come from a C# or Java background, the word “attribute” might be confused with something else. So remember attribute = property/method/field/anything that defines an object.

So as I delve farther and farther into the insanity that is Python, I can feel my mind screaming. Not like “Oh f— I’m being eaten alive” kind of screaming, more like “Don’t open that door! You know the guy with the axe is behind it!” Of course, like any good horror movie character I’m too dumb to know better. So delve I do.

Now I’m what you could consider a classically trained programmer and by that I mean I never programmed before college so I didn’t do much exploration. You know, a Microsoft programmer. With that, I’ve had the ideas of interfaces and class hierarchies complete hammered into my head, so it shouldn’t be any surprise that I’ve tried my best to make Python into c#. After all, that’s what I should be doing. I don’t know any better. DONT JUDGE ME!
It wasn’t until the other day when it just hit me. And I don’t mean slight hit, I mean like I just told Miguel Cabrera I’ve seen better players in Little League. It occurred to me that it’s possible, just possible I might have to change my way of thinking because of one major design difference: dynamic attributes… actually f— it, dynamic everything, but let’s just stick with something simple. In Python something like this:

  someObject = dynamicObject()
  someObject.propertyImJustAddingForTheHellOfIt = 1

Where dynamicObject is nothing but a cheesy class that inherits Object but has nothing on it. (Turns out that if I did someObject = Object() I couldn’t do this since Object by default doesn’t contain the ability to add things dynamically… and this was by design.) So what does this mean? Well it means that anything at anytime could have any attribute. You might be asking why this is such a big deal. Annnnnnd that’s why I’m typing this out so stop asking questions until the end, k?

If any object can have anything on it at anytime, it could be said that types and classes kind of go out the window. Why? Because when it all gets washed away, what really does the work in a program? Methods. Now with C# there is a much stronger enforcement of typing so a method KNOWS that whatever coming in has to be a certain type. This is where object inheritance and interface implementation come in. Because there is such a prerequisite for typing in C#, you have to develop around the object itself and have the methods conform to them. In Python, I question whether this approach is really warranted since with dynamic attributes what really matters is what the method needs. It could be argued in the world of dynamic, the methods actually dictate everything. Since types are basically thrown out the window, what’s the point? Why not just shift all development around methods and their results? It’s kind of an inverse way of looking at things when used to the C# way of doing them.

Method Oriented Programming?

This is something I’m kicking around a bit, but why not base the architecture around methods rather than classes? It would give a much truer sense to the word “Factory”. Instead of worrying about having a class hierarchy, have methods responsible for creating objects on the fly, piecing them together with other methods and such. I would think this could give a program a massive ability to adapt quickly to any given situation if you can add and subtract from objects on the fly since you are not longer concerned with types, just attributes. Does the thing coming in have X attribute? Yes? Great do something. No? Fine don’t do something. (Python has a built in way to check if an object has a certain property) Does it need it to continue? Well call a method to add it to the object. Has the use for it expired? Well just remove it. Taken to an extreme, I could see this being used to construct more self sustainable programs, ones that can makes choices on their own to produce novel outcomes. (Sadly, used like viruses and hacking security systems come to mind, but there has to be more noble uses for this) Sounds like a lot of freedom.

Now I’m not saying you can completely get away from class structure… at least I haven’t gone far enough into this concept to see if it’s possible. However, it should be obvious that it at least allows for a completely different way of thinking that may help solve problems that were seemingly impossible to solve using more rigid languages like C#. Of course, it also lends itself to shooting yourself in the foot. Most likely, this approach would need more overall care since you don’t have things like type safety to cover your a–.
Anyways, this is just preliminary rambling of a child (programmatically speaking… and maturity wise) who is just kicking around ideas that weren’t really there before.

An odd side note, python gives a new… or maybe the correct… meaning to the word “constructor” since because of that highly dynamic nature it’s not unlikely to see something like this:

  __int__(self):
    self.someNewField = "This property now exists"
    self.someNewMethod = someFile.someMethod

Which is actually more like a factory then how say c# uses constructors, which more the most part is like a initialization. The other interesting thing to note is how python treats files and methods. If you declare a method on a file, you can actually import that method as if it were an object itself. This makes the above code even easier to accomplish since you can have a file of just methods that you can “import” and add to an object.

Jettison everything else, then, and lay hold of these things only, few as they are: and remember withal that it is only this present, a moment of time, that a man lives: all the rest either has been or may never be.

These words came from Marcus Aurelius, a roman emperor and among other things a philosopher. This thought was actually a part of a larger idea found throughout his writings in that a person’s life can only be measured in the present as in his mind it is the only thing that can truly be taken away from someone. The past is done and the future isn’t guaranteed.

Great, so what the hell does that have to do with programming? Truth is, it has a lot to do with it.

When it comes to programming, certain people… not going to name any one (Me)… tend to get overwhelmed playing the prediction game. It’s not good enough to see what I’m doing now, but I’m always planning about 8 steps ahead. Problem is, it sounds like a good idea but in reality can create over engineering and paralysis.

What if in the future it needs to be web service based?

What if in the future a user will need multiple addresses?

The question I should be asking is: Will all this What Ifing help anything get done now or will it just make the system overly complex for no good reason? Am I really smart enough to predict where the system will go in the future?

The customer, like the future, is a fickle thing. You can’t predict where a customer might be two months from now. What you do know is where the customer is right now. Just like Marcus wrote “all the rest either has been or may never be.” You can put in 20 extra hours a week creating a massively robust and fluid front end web design only to have the customer decide a year down the road that it needs to be a standalone app. This is something that cannot be predicted. It is the way of the unknown. You can only do best by what you know now.

Are there ways to protect yourself? Sure. Things like abstraction and decoupling can help at least make the change be less painful and overall are good practices anyhow. Things like ORMs can help against database changes (You know when sql server is just “SURPRISE” replaced with oracle), service oriented architecture to hide the underlying data processing, repository pattern, ect ect ect. There are many tools out there to help make it easier when a large chuck of a project is called to change heavily or to be completely redone.

Fact is, things will change and you can’t predict them. The best you can do is create architecture that allows for change rather than creating one that assumes what those changes will be. Live in the now, let the future come as it does. For every step in the future you try to predict, another assumption is laid upon a foundation of assumptions. If any one of those turns out to be false, the whole thing will come crashing down. Don’t spend a lot of time on creating things you can’t prove will ever be needed since in the end you have to get something out at some point. In the real world a working program now is better that a crazy advanced magic one that still isn’t out.

In the DC Comic Green Lantern, Hal Jordan acquires the source of his powers, the power ring, upon the death of Abin Sur. I find this to be one of the more fascinating stories in comic books as it conveys a lesson in life.

Too often in life, and even more so in the IT industry, we are forced to see the end of something: A respected colleague leaving, moving to another position, or sometimes being fired unjustly. Any one of these could seem like a bad thing and I think we as human automatically assume the worse. It’s almost instinctual to assume the worst and work against whomever fills that spot (Whether consciously or not). After all, the loss is great and there’s no way said person could be replaced. Problem is: It’s hard to predict what will happen when the new person arrives.

Sure we have all had that shock of the new person coming in and shaking things up. Abrupt change can cause extreme friction, an unknown, and the unknown is something we as IT people hate. Our job entails building things. It’s difficult to build things without a plan and a set vision. It upsets us to be in a situation of flux. We want stability. For someone to leave is to remove our livelihood. Then the panic comes.

It won’t work. This person doesn’t know what’s going on. This company will never let this happen. These are all things we’ve said in this situation. Maybe it’s because we believe we know the company better than anyone (sometimes that’s true) or maybe it’s because the new idea are contrary to what we think is the way of doing things. Problem is by doing this we’ve proven ourselves to be fools. Why? The one thing about uncertainty is… well it’s uncertain. You can’t know if the change will be good or bad. By taking a stance either way, you’ve falling into the world of assumption… arrogant assumption. No one can predict what will happen, not even you.

Cure? Just keep doing and see where it goes. It’s a hell of a lot less stressful than worrying about it the whole way and you’re still getting paid the same. Try to see the vision of the new person. Try to figure out what he/she is thinking in the long run. You might like what you see once you give it a chance.

Just a final note:

Evolution is full of this principle. The end of the Dinosaurs allowed small mammals to finally come out from the holes in the ground and take their place in history. End of one amazing story and the beginning of another.

So something has come up in days of yore, and it involves HTML.  Now I understand that those four simple letters are enough to give most programmers a rash unseen since being a kid of wearing Wranglers without washing them first.  Seems to me that there is an utter fear of HTML in the programming field and I can understand.  Sure there were times a log time ago when it was simple and people didn’t have to put up with this CSS thing.  Then design got complicated with that now defunct term DHTML.  All of a sudden, HTML design became a tool of the lesser and programmers wanted nothing to do with it.  To complicate matters, things like ASP.Net Webforms made it even more painful to worry about design. and really has so many ways to ignore it because of the 8 million automatic controls.   End result:  The ability to work with and create worthwhile pages became a lost art.

Flash forward to MVC.  To me one of the greatest things about the MVC framework was that it forced me to once again become one with HTML, and to the same extent CSS.  I’ll admit it was painful at first.  I had been able to get away without really having a good understanding of either for so long thanks to WebForms, but no way would this last.  Eventually I started to get pretty comfortable with it and have to admit I’m a far better programmer overall because of it.  How did I pull this off?  97% of the time I don’t use HTML.Helpers and other HTML churning methods.

Now I get that it sounds alien to most people.  After all, things like HTML.EditorFOr coupled with annotations can help with quickly creating pages.  I won’t argue that.  In fact, from a programmer’s stand point it’s probably better and I’m just a minority.  But I’m ok with that.  Why?  Because I like HTML.  I like CSS.  I like seeing both when I open a page in Visual Studios.  What I don’t like is the abomination that HTML helpers and the like create.  I didn’t go to MVC just so I could have even less HTML than I did in WebForms.  In fact, if I didn’t like HTML so much I would have just stayed with WebForms.  When it comes to quick development, WebForms wins hands down.  The switch to MVC wasn’t about speed, it was about doing it right for a change.  It was about getting my hands dirty and really learning web design and javascript.  It was about learning, not about taking the easy route once again. What have I gained from it? I can mock the s–t out of a page with notepad in the time it takes a kid to go through bubble wrap. Yeah, that fast.

I might get blasted for this, but personally a lot “MVC Magic” is just a way for people who are afraid of HTML to feel more comfortable.  That something like:

<% HTML.BeginForm(...) %>

Feels more safe than:

<form id="....  >

And why wouldn’t it? WebForms allowed a much more programmer friendly approach to creating pages, so it makes sense that something like the first example would be championed by programmers. Problem is, it just keeps feeding the issue: programmers don’t know jack about designing web sites.

There is nothing wrong with HTML and CSS. It’s not a difficult concept. Instead of using tools to get around dealing with them, embrace them. Don’t take the easy way out. Don’t get scared and run. Just use them. In fact, here’s an exercise:

Come up with a simple site idea like say a forum and build it completely in HTML, CSS, and Javascript (jQuery, Mootools, ect are still javascript). 100% mock up. If you find that hard or annoying, stuff it and keep going. I swear that the benefits will be astounding.

I’ll give plus points if the page has a possibility to make a lot of money… no reason for that at all…

When I started using MVC, I had some issues on figuring out how to build controllers so that they made sense from a structural point of view. I slightly touched on it but I wanted to show where I progressed to in the vain hope that I can help prevent stumbling on your part.

One thing to be noted is the asynchronous part. I’ve become a firm believer that MVC is pointless without asynchronous operations. Why? Simply put, you can use them or you can come up with some annoying post and redirect for any create, update, or delete operations. If you’re going to do that, you might as well just be institutionalized because you are one masochistic mother f—er. For everyone else in the happy world, go with something like jQuery that makes it real easy to perform said operations.

With the last paragraph in mind, the part I had trouble with the most was figuring out where the actions go. You see, when I started using MVC, I grouped stuff in an ultra simple manor. Say I have a site for handling pictures. Well there would be a view controller that would have anything to do with viewing images and an admin controller that took care of the uploading, changing, deleting, ecting. As you can imagine, this was not what you might call ideal.

Once I got a feeling for MVC and how it worked, I started having things a little more separated but still didn’t feel right. I had actions for viewing a list of images on the image controller no matter if public or admin side which wasn’t really ideal to me since it kind of blurred what was public and what was restricted from a conceptual point of view.

It wasn’t until I started thinking in terms of unit testing that it started to make more sense. If I were creating controllers as if they were classes instead of pages like with WebForms, maybe it would work out better. Seems real profound right? Well it was at the time since I still had WebForms state of mind. All of a sudden, it made way more sense on how the controllers should be set up. In an odd way, the controllers almost became almost business layer like. If I wanted to update an Image, there would be an Update method on the image controller responsible for taking in the changes, validating, and dealing with the entity objects. Everything that had to do strictly with displaying information would be handled by a display controller like the before mentioned Admin controller. So something like:

As you can see, the Admin controller has something to show all users. The User controller has the methods for things like updating, creating, and validation. Basically anything that would change an image is on one controller. Anything for showing it on the main section controller. That is, a controller that embodies an overall concept like say an Admin section of a site or possibly a controller for viewing galleries.

The sequence of events (bad word choice…) would be something like:

Open Admin/UserList/
Admin controller uses User Entity to retrieve list
Admin View shows User List
User clicks delete button/link on Admin View
Javascript/jQuery method invoked to send id to User/Delete
User controller receives id
User controller validates id to make sure it is valid
User controller validates current user to see if allowed to delete
User entity Delete method invoked by User Controller
Result of Delete Method is returned by User Controller (JSon preferably)
Admin View displays the result

Treating controllers like classes (and the use of anonymous actions) allows a very clean separation of actions resulting in a nice logical layout. Beyond this, it also allows for a greater separation between controllers which means its possible to do multiple parts of the entire project in parallel.

Maybe this is just stating the obvious, something I’m pretty good at, but my hope was to give a quick over view of laying out controllers for those who are just starting out.

Now as you can see, it looks like a table, acts like a table, so it must be a table right? Well it isn’t. It’s actually done with divs and styles, something I’ve worked hard on getting right since moving to MVC.

I’m not bagging on the question asked because I’m probably a mutant and the only person that thinks the way I do (and have written below). I just have a philosophy that if you can do it yourself, do it yourself.

For starters, I’m not against new stuff, I think that’s pretty obvious. I’m also not completely against third party stuff seeing as a lot of my newer posts deal with jQuery. I do, however, avoid third party tools I don’t need, namely grid builders or things of that nature. I figure that if I can do it myself, I’ll do it myself. This kind of hits on the debate of using Visual Studios’s drag and drop feature for designing pages or not. Sure it’s easy and for the most part works, but you are really doing yourself a disservice. Why? Because most of the time you can get away with it, it’s those few times that it just won’t do what you want it to do that kill you.

When you use helper tools, you could be cheating yourself out of knowledge

Now I’m not saying that you should develop your own tools for rendering 3d graphs. Some things you just don’t have the time or the ability to create, but when it comes to simple things like markup, do the work. The knowledge you gain from this is substantial. Hell, I used to hate style sheets. I used to hate javascript. Quite frankly, they were a pain in the a– at first. However, taking the road less travelled has given me a new perspective on both. I no longer fear them and in fact would rather just type the markup out myself than trust some third part thing that I can’t fix when something goes wrong. I know that if I have to create a quick mock up that looks like the real deal, I can do that with notepad and a browser. I know that if I have to teach someone how to use style sheets or javascript, I can do that without just telling them to go to some page or to use some random tool. I have confidence in my knowledge.

More time now, less time later.

Now I know in Perfectworld, there is always enough time allotted to doing what needs to be done. In Realworld (Not the stupid MTV show) everyone is running around, heads a blaze. So the biggest excuse to not learn proper markup is that there isn’t time. A company isn’t going to pay you to learn when things need to be done. Well sure, but flash forward a couple months when someone tells you that you have to adjust the grid you didn’t build yourself to add something you have no idea how to add or else the world is going to end. Last thing that person will want to hear is “It can’t be done.” In fact, most business people have some crazy allergic reaction to that phrase that causes them to turn really, really red. It’s weird but happens a lot. At this point you can either:

Laugh and lose your job.

Go on the forums and hope there is a solution.

Die a quick and painful death.

Always expect people to want 20% more than what was originally written. Unless you have one of the best project managers that says the phrase “Work request form” on instinct, you will run into this situation. That’s where doing it yourself comes in real handy. It may have taken you a while to figure it all out, but you will for certain be able to fix the issue quickly.

You never know when you’ll actually have to know how to build things from scratch

Tech Interviews. When looking for a job, you’ll probably run into these. Best way to be prepared for these? Have the real world knowledge. How do you get that? By doing a lot of the work yourself. I have been through interviews where I was given a simulated work item and told to produce code for it on the spot. Some of it had to do with the actual markup needed to display the data. (This was before MVC days, WebForm stuff) The people were far more impressed that I was typing out the mark up than if I had just done drag and drop stuff. Why? Because there is a stigma, fair or not, that drag and drop people are displaced VB Weenies, and the real programmers don’t bother with it. Knowing how to hand code mark up on the spot is far more impressive than using visual tools or completely blanking out because you’ve had to rely on third party software.

At this point I realize I’ve mostly talked about markup, but this whole idea extends to a lot of the programming world. Digging in and forcing yourself to do the work will substantially improve you abilities over time. If you can’t do this at work then find some time on your own to work on a side project to learn. Build your own error handling system. Build your own pager creating method. Build your own Url creating method for MVC. I promise that you will be in a much better position.

Final Note

You could argue that coming to a site like this and using copy/paste is against my spiel. Fact is, I’ve copy and pasted plenty of code to get to where I want to go. Difference between this and third party tools is you can learn from what you copy and paste. Actually I would argue that you have the responsibility to learn about what you are copying before you do anything with it. If you copy AND you take time to understand what you are copying, that can be just as helpful. If nothing else, it’s better than just using some third party method.

You have a comment area that allows a user to view comments. Now this comment area is created using javascript (Read jQuery) only. When a user clicks on some kind of pager, a method is called to get a list of comments and recreate the comment table. Now you would think it would be a good idea to hide the table, recreate it, and then show it. Sounds like a decent way to go. So you try something like this:

  ...

  jQuery(commentTable).hide("slide", { direction: "up" }, 200 );

  ...

  //Get the comments and call a method to build the table.

  ...

  function buildTable(commentList, commentTable)
  {
    ...

    //Take the list and iterate.  Create a row

   ...

     jQuery(commentTable).appendChild(someCreatedDivRowWithAComment)  //BOOM

   ...
  }

Then you run it and bam you get an error saying that basically commentTable doesn’t exist. Now if this were WebForms and you did some kind of visible=”false” you would know that the markup for that table wouldn’t exist. However, in javascript style=”display:none;” doesn’t remove the element from the markup, it just hides it from the viewer. If you look at the source (Provided it’s not dynamically created) you will still see it in the mark up. So what’s the deal?

Well for some reason the creators of jQuery decided that there is a difference between a hidden element and a non hidden element to the point where you have to change your search (the jQuery() method is basically a search that looks for the element within the parenthesis) by adding on a “parameter”.

  jQuery(".someElement:hidden")

So if you do use the hide() method (Or fadeOut for that matter) you have to use the :hidden addon to find the stupid element. This can cause a big problem when things aren’t timed correctly. What does that mean? Well that 200 value I have in the hide method, that’s the time I want it to take to hide the element. Far as I can tell, and I’ve done some testing on this, the element is not :hidden until the animation completes. Which means there are 200 time units where it is not :hidden. Now if the time that it takes to get your comment list and start building the table is less than the time it takes to hide the element you’ve got an issue. Or conversely, if the 200 time units are up and it is now hidden, you’re really screwed because the normal search won’t work. You can try something like this:

   if(jQuery(this).children(".categoryBlockContainer").is(":hidden"))
  {
    categoryBlockContainer = jQuery(this).children(".categoryBlockContainer:hidden");
  }
  else
  {
    categoryBlockContainer = jQuery(this).children(".categoryBlockContainer");
  }

And this works ok most of the time, but you still might run into a situation where it’s still trying to finish the hide animation. Beyond that, it seems kind of asinine to have something like that in the code. It should find the element at all times, hidden or not.

This really kills the whole idea of animation.

Between this and javascript’s bizarre variable scope, I’ve had some thoughts of changing my profession.

I bet that made sense!

Here’s the situation, I have a blog thing I’m working on and it allows for multiple blogs per site. The “splash” page, if you will, looks like this:

And when you click “Newest” it looks like this:

As you can see, Newest brings up a pop out div thing that shows the latest post.

Side note, I was going to have it just show the first X characters of the post as a teaser, but turns out that if there is any broken HTML because of that, IT’S A HUGE PAIN TO FIX. Something like <div> this is something that <di… OH SNAP THE DIV IS BROKEN! ALERT! ALERT! So this was a “solution”.

Originally I had it loading the needed post in it’s respective pop out div and just hiding all of them. Then it would show the post when the Newest “button” was clicked. Then it dawned on me that this might be silly since only one is going to be open at a time. Why send the client a ton of unneeded html? So, I moved on to using jQuery/Json to grab the needed post data when the Newest “button” is clicked. Then I just populate the pop out div with the returned information as it opens… or whenever it gets back to the client. Can’t always assume it will be there immediately. Interweb can be slow at times.

Anyways, this brings up an issue: Am I better off with the first or second solution? Given that all things are equal, it seems like a better idea to have the jQuery solution due to the fact you aren’t sending useless html to the client. This will most definitely help with initial load time for the client. Only problem is, that jQuery method is run every time one of the Newest “buttons” is pressed meaning you could have an infinite amount of requests per person. I suppose this is a matter of gambling really.

Do I go with full html and because I assume the user will look at all the latest posts anyhow and therefore cut down the needed requests?

Do I go with the jQuery method because more often than not, users will not look at all the latest posts OR at least will take some time in between the Newest “button” pressing so that it’s ok there might be a ton of requests over time?

At this point I think the second is the way to go, but it’s most likely situational. Time will tell.

Now this isn’t going to be an Atwood, back patting, I’m so good I know I’m bad kind of post but something has really occurred to me more and more lately. As I’ve gone deeper and deeper into things like Entity Framework, MVC, and jQuery I’ve only been left with the feeling that someone else, somewhere is doing this a lot better. Maybe it’s because my lack of experience with them, maybe it’s just a self depreciating nature thing, but it’s also having access to too many good programmers due to the plethora of them on the internets. Yeah right, that’s a bad thing? Well it kind of is. It’s tough doing anything anymore when you know there are people far better than you doing a far better job. And with the advancement of information sharing, you can’t help but find proof of that. With that comes a certain guilt that you aren’t the top of the food chain and in fact you just might be a programmer the other better people complain about. That’s right, you. Someone at this very moment is straight up banging his/her head against a desk because of something you wrote.

Some would suggest this is the sign of a good programmer. Someone who is never completely happy with his/her performance. F— that, it just plain sucks and makes what can be enjoyable an epic pain in the a–. No one wants to be that guy, you know the one that names every variable with numbers (v1 + v2 = v3) or has one gigantic method that does everything. Problem is, this is all relative. One person’s perfection is another guy’s multi purpose stored procedure that runs 10 different query using a switch and a passed in string. Code perfection is in the eye of the beholder. And by now we all know there are plenty of high end beholders.

What does that mean? You can never win at the game of programming. Read it again. You can never win at the game of programming. That is unless you are beyond a doubt the sharpest bulb in the bunch. For the rest of us chumps, it’s grin and bear it time.

That’s it. That’s the answer. Suck it up. Don’t like that answer? Refer back to the answer. Fact is, you’ll never be perfect and if you were, chances are you wouldn’t be reading this nonsense. You’d be out in the middle of the Gulf of Mexico kicking it back on some island you own. For the rest of us mortals (Or dumb immortals), it’s time to join the Tool Fiesta. Start dancing, drinking, and accepting. I’m not saying that you can’t better yourself. Hell maybe you’ll be one of the top people out there… and optimistically thinking, considering this site, maybe you are (What the hell are you doing here though?). But you aren’t going to be perfect and neither is your code. However, sitting around and worrying about producing perfect code is just sitting around. Have to figure some code is better than no code at all right? Just lie to me.