Category: Pontification

Why are things made so complicated in web design?

Ever since Linq came out over 3? years ago (Earliest post about it that i have was from June 25 2008) I’ve been madly using it as much as I possibly could. I didn’t find it to be just some kind of syntactical sugar, or at least I learned it wasn’t eventually. Which? I don’t remember and really it doesn’t matter. Point is I’ve been a huge proponent of it and the various fun that came with. (Func, Action, anonymous types, ect) Now I had heard that it was based on functional programming but I had no real idea what that meant. It was just some kind of programming cultists and people with tin foil hats use. Let’s be honest, in the “Beer league” of programming, there was no respect for it.

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…

I Have Found Python and… Well I’m Bored.

A while back I wrote a little ditty on python (Not sure if that’s the correct usage of ditty but when have I ever showed a need to use words correctly?) and at the time I was wowed by how easy it was to develop with Python and (“Wish I were getting money for this plug” plug) Pycharm. Sites were so much easier to create using the Pyramids engine. Everything was wonderful.

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)

Has the Programmer Dream Died?

I realize that developers don’t have a Hippocratic Oath but I figure if it did exist would follow in the same footsteps. 

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?

Talent Versus Persistence

Let me tell you about my one time mentor Dan, and no Dan isn’t a fictional character to make a point. Dan (Cousineau) is a multi time NASKA national champion, quite a few gold medals in world competition, not to mention an accomplished BJJ practitioner. I had the pleasure of being one of his students for many years and being able to compete for the Dragon Karate Team.

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.

MVC 3, Razor, and My 1 Cent

So a while back I decided I would jump right into MVC 3 to see what’s new. Now the first plan I had was to still use my bestest friend ever, Spark. After some thought (Very little as thinking is too resource intensive) I decided I would take on Razor with it. Why not? It’s probably going to be the new default standard engine so I better get a feel for it.

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.

ASP.Net MVC 2/C# 4… Dynamic Model and Should You Use It?

So there’s a new sheriff in town and its name is dynamic. Actually, its not really that new and that’s a horribly misused cliche. My lack of literary genius aside, I’ve been looking for a reason to use dynamic. Then it came to me: Models. Now the only reason why I started down that path was the use of Python where pretty much anything is dynamic. In using python, I got used to not embracing the rigidity of classes for models and adopted a more “Oh what the f–k” attitude. Back in the .net world though, I was using typed views. Then I readopted the “Oh what the f–k” attitude and applied it to .net mvc.

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.

Python… DOUBLE TEE EFF Exclamation mark one one

Fair Warning: This is all conjecture and idiocy… possible more the latter than the former. With that in mind, this is more of a flow of thought than any kind of organized scientific paper… thing.

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.

Development and Concern for the Present

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.

The Abin Sur Principle

The end of one great story can spark the beginning of another.

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.

Just Use Html: Why MVC Can Be A Good Thing

Just a fair warning, this isn’t intended on being taken as truth, but if you’ve been here before you should already know that.  If you haven’t and you can’t figure that out from the url alone, you’re probably are confused by addition so oh well.

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…