Month: March 2010

ByATool.com gets a shiny new tool!

A while back, we put up an offer to write for our blog.  Only one has risen to the top as someone having both the technical know-how and the razor sharp wit required to write on a site such as this.

ByATool.com Readers… Amy.

Amy… ByATool.com Readers.

Amy is a magnificent geek and almost 10 year veteran of server administration and software development. She has worked at IBM, Concurrent Technologies Corporation, and University of Pittsburgh Medical Center. Currently, she is doing custom SharePoint development connected with Team Foundation Server and the ASP.NET MVC framework development using the Entity Framework, C#, and jQuery. She is currently living in Pittsburgh and not happy at all about commuting into a city with 3 rivers because of the many bridges and no serious commuter subway systems… Who plans this stuff?

Welcome Amy!

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…

Child IFrame Page Interacting with Parent Page… Yeah I went there.

Example here.

File this under “Why?” but I wanted to see if a child could talk to a parent and then receive information back from the parent to update itself with. As usual, my lack of intelligent wording probably has you scratching your head… if you do that. Personally I don’t get that expression as when I’m confused I more than likely will grab a jar of peanut butter and start lathering up with it, but to each his own.

So here’s the idea, and this post is only the start.

You have a parent page, Parent.htm, with an iframe and you want the parent to do something and alert the child that something happened. For now, it’s actually really simple.

On the parent I have a method:

  function callMethod(text, methodDelgate) {
    if (methodDelgate != null) {
      methodDelgate(text);
    }
  }

And this simple markup:

  <iframe id="myFrame" src="Child.htm"></iframe>

Wow huh? Well on the child I have this:

  function callParent(text) {
    if (top.callMethod != null) {
	  top.callMethod(text, changeText);
    }
  }

This is easy. If the parent has the method, send the text through and a method to call when finished. What is this method? Well its:

  function changeText(text) {
    jQuery('#returnText').text(text);
  }

Which simply sets the text on some div to show it actually worked.

What happens when I click a button that calls callParent? It talks to the parent, the parent calls the passed in method, and the child updates itself.

Not sure this is rocket science, but there will be more on it as I add in the idea of a dynamically created pop up on the parent being used by the child. Until then, try not to be yourself. You embarrass your mother.