Development and Concern for the Present
- Sean
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
- Sean
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
- Sean
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...
ASP.Net MVC: Quick Overview of Controller Structure
- Sean
Wow, that's a mouthful far as titles go, but couldn't think of a better way to say it. Now what I'm about to go through is the "system" I have found that works pretty well when it comes to structuring controllers knowing that there will be asynchronous operations. Why is that a big deal? Well where you put certain methods can depend on which controller actually owns the action.
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.
Do It Yourself
- Sean
A question came up about an earlier post on how I construct my grids shown in a few examples.
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.
jQuery, Hidden Elements, and Why At Times I Hate It
- Sean
So this is your situation, or at least it might be someday if you use jQuery:
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.
To Async or Not To Async… That is the ReWritten Cliche Quote.
- Sean
One of the things I've been wondering as a of late, besides why Micheal Bay still is allowed to make movies... and no money is NOT and excuse, is whether it's better to just load and entire page and hide/show stuff on some click OR only load what's shown and have said click handle loading the stuff through Asynchronous Calls and Json.
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.
What I Hate About Programming
- Sean
Lately I have been screwing around with creating a blog framework using MVC and jQuery, the former being more troublesome from a design stand point. For example, The use of controllers and actions can cause a great deal of second guessing. Do I put all the admin view attached actions, like one for viewing a list of posts to select and edit, on an Admin controller? Do I have a Post Admin Controller and a Comment Admin Controller? Should anything having to do with Posts be on one Post controller and just seperate the actions based on attributes? (As in MustBeAdminAttribute as opposed to MustBeLoggedIn) After all controllers are about grouping things, but how the h--- should they be grouped? Of course, that's a sort of gray area an subject to debate. The problem is I can't help but think not matter what, I'm making the wrong choice. Why? Mostly because I know I'm not a super programmer.
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.
Did Postback ruin the “web”?
- Sean
If you've been reading my drivel as of late, you'll know that I have moved full steam ahead with MVC, for better or for worse, 'till death do us part... or until MVC catches me shacking up with a much younger framework and sues me for everything I own. Either outcome, I going with it for a while. Why? Well I could name a couple reasons but the main thing I just like how easy it is to use jQuery with it do to how "RESTful" is it. Silly, I know.
Well I have put out some things about certain catches with MVC and it started to make me wonder about why I'm having so much trouble with certain aspects of the framework. It isn't the modularity. I really like the controller concept. It isn't the attributes instead of base pages to take on certain repeated checks (Say if the user is logged in), it fact I've embraced them. No the problem lies in the last few years of my short but uneventful programming career.
In the beginning there was ASP
I've admitted before, or at least I think I have, that I've only been doing this for about 7 years. I wasn't the kid that started programming on an Apple II (E, C, GS, you can take your pick. Had them all growing up), I didn't find programming those mini computers (You know the ones that basically had a strip of plastic that served as a monitor) all that much fun, and I surely didn't sit around in my youth trying to hack into anything put in front of me. I just wasn't that guy. In fact I didn't start programming until around 2000 or so, the hey day of ASP. Now at that point in time, what a page could do was pretty limited. You could show tables, you could click links, you could post data to save. It wasn't pretty but it got the job done. For the most part, web programming was just a step up from kiddie scripting and a small step down from VB Weenies. Fact was, it wasn't very complex and site design reflected this. Sure there were a few that could push the limits, but the limits were pretty low.
You can cut a tin can with it.
ASP.Net... or at the time ".Net". .Net was this almost mythical name that seemed to be used for everything from solving the complex page dilemma to removing that nasty "cranberry" stain from your expensive sheets that you can only buy in Sante Fe. At first people were sceptical, and why not be? Microsoft was pushing it as the universal key and at the time that seemed pretty impossible. Then people started using it. Sure it was messy at first. A lot of the people from the ASP walk of life either had forgotten how to program in forms or just never really learned. (Yours truly) Now all of a sudden there was a separation of mark up and code, and some crazy thing called post back, and wow what the hell are events? Classes? Double You Tee Eff? It was like this wave of excitement that web programming had grown up and it was the real deal. And it didn't stop there.
Give a man an inch...
Well it didn't take long for the over ambitious (IE Sales people) to start pushing the envelope of what could be done. Every time we reached what we thought to be a summit, someone would see if we could climb the next mountain... that happened to be twice as tall. After all it should be safe to assume that if you can make it up 10k feet, then 20k shouldn't be that much harder right? All of a sudden "Can you do this?" had turned into "What I want is this" and for the most part it was possible. (Though ugly at first)
I want a page with data that I can edit.
-We can do that.
But I don't want to be taken to another page
-We con do that
And I want it update when I save something without leaving the page
-We can do that
And I want it to seamlessly incorporate a bunch of different information from a million places and have it handle each part of the page differently but also have it handle all of this without leaving the page... and I want it done in two weeks.
-We can do that.
Of course this incredible feeling didn't really allow us to think about the cost of all of this. Things like Viewstate, Session, gigantic pages with a bountiful of html, inability for smart phones to browse or at least load quickly, ect ect ect. It didn't matter, because we were able to give the customer what the customer wanted: A Winforms program without the installation process. And over time, this has allowed pages to be so complex in structure that it you really couldn't tell it was a web site if it weren't for the browser.
Just because we can do a thing doesn't mean we must... do that thing.
WebForms, as the cool kids cal them now, opened up a whole can of worms. They made it easy to create incredible complex pages with relative ease. And to do so they bent the "rules" of the web to allow for greater ease of development, at least that's what you hear from MVC proponents (And REST people). MVC brings us back to the time when programming didn't pervert the system, and at it's core it isn't pretty. Taken just as is, with the tools that the MVC framework has, the complex Web Forms we grew accustomed to are just not possible without a ridiculous amount of work. Heck a simple button press becomes much more complex in order to mimic a Web Forms post back. And that's the problem... I'm trying to emulate something that MVC wasn't built for and in a way could be argued that the web wasn't built for: The post back. The Post Back is one of the key parts of Web Forms that allowed for so much and it really isn't in MVC. I mean it could be. You could load up all the page/view functionality onto one gigantic controller but that kind of breaks one of the strengths of MVC: Modularity. Fact is, that little guy helped shape the way we think of site design and programming. (Not to mention viewstate but whatever) It allowed for so much to be done with so little effort. It gave us a bridge to winforms. For right or wrong, it gave us a solution and it also reprogrammed our future ideas.
Who has time for principal?
When conversing with other people about MVC, I had stated the whole "It's the way the web was intended" line (Which personally I really don't subscribe to because in a way I don't care) and someone rebuked, "If it gets people what they want, then who's to say what's right for the web?" And I have to agree with him on that. I mean, it's not like there's life on the line here. If I move to MVC purity there will still be hunger, still be war, still be movies made by those idiots that brought you films like "Meet the Spartans" and "Disaster Movie". (Although if Microsoft could solve that problem with MVC, I don't think we'd have Web Forms anymore. Get on it Microsoft...) In the end, isn't that what matters? Getting things done?
The beat marches on
So where do I go from here? If anything, I think the 800 gorilla is that I have to start designing web sites in a new way. Have to unlearn all of the things I got from WebForms and take myself back to the day when things were more simple. Even with advances with Asynchronous Calls, I still have to develop a completely different state of mind. Is this a bad thing? Time will tell. It's possible that this is a fool's errand but it's also possible that use of MVC will bring forth sites with better structure and more reasonable functionality. After all it's possible that post back derailed good site design.
Let it be noted
Before the comments about [Insert Javascript Library] start to pile in... HAHA comments on this site... Ok let's pretend I get comments and the would be comments about [Insert Javascript Library]/Asynchronous calls(Let's just call it JLA for short) calls, right or wrong I see JLA as a work around. It's a way to allow for the complexity of said Web Forms without changing the MVC framework or relying postbacks. But even with those you still have a lot of unfun code that barely makes up for the loss.
Modern Programming: Anti-Evolution?
- Sean
For a moment let's just not bother arguing the merits of evolution versus whatever, and look at one of the basic ideas behind it.
Every one's heard the cliche phrase of "the strong will survive". Most likely it's been in some movie you watched, some coach spouted it out, maybe you hear it from some business "guru". Doesn't matter. (Although there is actually a lot more since it's not the just being strong but the best suited for the current environment ect, but let's just play Sesame Street evolution.) Let's go by the overall idea that those that have traits that are against survival will be removed... ie the weak.
The best code I've ever written was someone else's.
Whenever you do something new, you run into problems mostly due to lack of knowledge. In the programming world, this is an everyday occurence provided you're actually trying to learn. Can't figure out how to make something work? Well just go search for it. No matter how new something is, most likely there are already people answering questions about it on a forum, posting it on a blog, or probably some site that is dedicated to it (Say like MSDN) that will give you an idea of what to do. That's the beauty of programming today. But what about 20-30 years ago? What happened when you just plain didn't have instant answers or dare I say it? No Stackoverflow. Well some people would be just fine. Those people would just plow through and figure it all out. They would go through whatever written specs there are on... paper... and get it done. They are the people who already have posts about it in their blogs now days before you even asked about it. These are the real programmers. Problem is, for every one of those there are probably 10 people who take what they have and run with it. Then for everyone of those there are 10 who barely understand it, just copy/paste, and post it somewhere. And for every one of those, there are ten that take that code and use it. And guess what? Most likely all those people still have a job. All of them.
The herd isn't thinning
The question now is: How bad is this? Basically with the wealth of information out there, even the worst of programmers can keep a job that no way in hell they would have held 20-30 years ago. (How can I guess that? Because even 7 years ago when I first started really programming it was difficult to find things and that was with search engines.) With the demand for programmers being so high in so many places, businesses are almost forced to take on people who have just barely (Due to said search engines/copy and paste) made it because hey at least the person has prior work, so he/she must be good right? So the cycle continues, but in the long run most likely it continues in a direction contrary to evolution. Because remember, by my completely accurate and undebatable numbers, there are 1000 bad to every excellent. By that idea, and since the bad aren't being removed, the amount of bad code out there is growing at an incredible rate and it's being learned by new people. People who may not be bad but will be eventually due to the amount of horrible stuff out there. The bad are breeding bad, and it isn't being stopped. At some slippery sloped point you have to wonder if there will only be mostly bad to learn from.
Those that are most capable of surviving in the present conditions will be chosen
So the whole "only the strong will survive" isn't exactly the whole story. It's not just strong but whoever is best suited for the environment. When we think of strong, we think most rugged, toughest, most able to surive encounters. However, in the evolutionary sense this isn't true. If it were, all dinosaurs would have been like this almost mythical bad boy. Problem is things like food availabilty, ability to avoid predators, hell even resistance to sun exposure can all factor into what is really "strong". The point is, those who are chosen are best for the environment they live in. Now lets take the 1000 bad coders to every 1 excellent one. With that in mind, most environments entered into are going to be suitable to which group? The bad ones. A lot of us have seen this. Started work at a company that the code was just dreadful but the 3 guys that have been there for years and the one dude that was hired in a week before you are all happy as a pig in... well anything. We try to change things. We try to move things forward, but in the end we get burned out and leave. Guess who replaces you? The guy who works well with the other four. In fact, this is another part of evolution is that if two groups of the same animal are split by something, say a new river, the two might in fact eventually become incompatible. Think about it, a company that has strong programmers and weak ones that becomes taken over by the weak will eventually spawn a whole new type of programmer and programming shop that it completely alien to a decent programmer and would allow itself to continue unstopped. At some point, slipery slope full on, there may end up being way more bad companies then good and the good programmers may get weeded out.
How do I know if I'm the strong?
Fact is, you probably can't. Some people know it because they work for high end companies like Google and Microsoft. The rest of us mortals don't. I think that is why this career has frustrated me at times actually. I can't really be proud of what I've done because I've never been fired for bad code. I've never been released for writing bad programs. Hell I've never even been pulled into an office. You would think that means I'm doing something right except I've never known anyone who has. And I've had about 8 jobs over 7 years(All due to contract work or companies going under... Let me tell you, I've was on a streak of joining failing companies for a while), so I have my feel for bad code and bad coders. None of them were fired or let go because of bad code. And companies keep hiring in bad people so I'd have to believe that even if someone was let go, that person would find another job eventually. Hell, go to somewhere like Chicago, and you practically have to shoot someone to get fired because companies need people so badly.
Better than being dead.
So maybe its a good thing. Since after all I still have a job, I still get paid well, I still have some security. But in the long run, is this a good thing? Can programming as a whole grow as this situation continues? Everyday it gets easier and easier to be a programmer. I can't imagine that's going to change. With tools like jQuery, StackOverflow, Google, and any other way to help people with kid's gloves, it's hard to think that things are going in the right direction.
Last note
While writing this I couldn't help but realize that this my be riddled with hypocrisy. After all, how do I know if I'm not one of the bad people? Sad thing is I don't.
What about you?
Categories
Recent Posts
- WPF: Inherit Style From Style. BasedOn Is Your Friend
- WPF: Hide Built in Header Bar For an Open Window
- Spark View Engine, ASP.Net MVC, and You
- ByATool.com Is Looking For Writers
Reviews
Random Quote
Meghan: I want to punch her in the ovaries right now
