I'm feeling a mighty JavaScript kick lately.

What's interesting is that the more C# evolves, the more it starts to resemble JavaScript.  What with anonymous methods, type inference (it even uses var), and the LINQ syntax, my JavaScript juices are flowing.

There are a few things that I never wrapped up with my JavaScript development experience.  I think the most glaring one is JavaScript inheritance.  Some would argue that JavaScript inheritance is purely fluff (see second comment); it's not needed and JavaScript is probably more powerful for not adhering to OOP principles.

I dunno...it seems like one of those things that would be useful for building certain structures and UI elements.

I've been aware of Douglas Crockford's implementations for quite a while now.  I came across it when I first picked up on JSON about a year and a half ago, but I never particularly liked it since it "looked weird".  So today, as I was looking around to see if any alternatives have risen due to the recently revived JavaScript development, I came across a posting on SitePoint.  I rather like the simplicity of it all and it looks like it works, so I'll have to keep that in mind if I need to use it.

As I'm also thinking about writing a major web based rich UI application in the next few months, I've also been looking at some of the JavaScript libraries, toolkits, and frameworks that are out there.  I came across the Dojo Toolkit today and it looks fairly interesting.  I especially like the bind() syntax.  However, the toolkit does seem somewhat incomplete at the moment...I'll have to take a look at it in more detail and see if it has the features I need.  It's currently lacking any demos, which makes it hard to evaluate without a deep dive.

This brings up another interesting issue that has annoyed me with the proliferation of all of these JavaScript and AJAX libraries: instead of pooling talent and building The Best Possible Solution, we have teams going off left and right building 15 different impelementations of the same thing with 15 different design principles and 15 different philosophies.  Now this isn't necessarily a bad thing, as there are times when you would prefer a lighter implementation to a heavier one, for example, but it would make a hell of a lot of sense to have at least a common convention in terms of naming, package layout, and what not.  Ideally, what I'd like to see is some of these development tracks merge so that we may have more complete frameworks/libraries/toolkits.  Have one mega package that comes in mega-lite flavor, you know? 

With so many libraries/frameworks floating around, it makes it difficult to find the exact set that does what you need and if you do, you need to start worrying about whether they'll play nice.

I'll stop, because I'm just ranting now

From my coworker, Igor:

It is too late for me. I had my formula. Man who clean cow's crap all his life afraid mostly that cow will die.

This was his reaction to Paul Graham's essay, How to Do What You Love.  A short excerpt, a few paragraphs, of the excellent essay:

To do something well you have to like it. That idea is not exactly novel. We've got it down to four words: "Do what you love." But it's not enough just to tell people that. Doing what you love is complicated.

The very idea is foreign to what most of us learn as kids. When I was a kid, it seemed as if work and fun were opposites by definition. Life had two states: some of the time adults were making you do things, and that was called work; the rest of the time you could do what you wanted, and that was called playing. Occasionally the things adults made you do were fun, just as, occasionally, playing wasn't-- for example, if you fell and hurt yourself. But except for these few anomalous cases, work was pretty much defined as not-fun.

...

It's hard to find work you love; it must be, if so few do. So don't underestimate this task. And don't feel bad if you haven't succeeded yet. In fact, if you admit to yourself that you're discontented, you're a step ahead of most people, who are still in denial. If you're surrounded by colleagues who claim to enjoy work that you find contemptible, odds are they're lying to themselves. Not necessarily, but probably.

I think this is a must read for anyone between the ages of 16 and 30; it's a revelation to why many of the youth today are mired in apathy and seemingly dragged down by the weight of responsibility.

I don't know if you're familiar with this book, but it is the definitive catalogue on the most common design patterns that are in use in object oriented systems.  You will often hear these four authors referred to as "Gang of Four".

Perhaps the biggest name in this space is one Martin Fowler.  His book, Patterns of Enterprise Application Architecture, is the definitive book on building enterprise class applicaitons (and what that means is open for debate).  This book and the concepts are important as you will find, repeatedly, that many of the projects that come out of Microsoft's Patterns and Practices Group reference patterns that are documented in this book (see the bibliography) section of the Enterprise Library.

Note that both of these books are language agnostic and, instead, cover the concepts that go into building interoperable, maintainable, and reusable code.  In fact, you will find that both of these books and the concepts mapped out within are extremely common in the J2EE world and are only slowly trickling down in the .Net/MS space due to the leadership position that the Patterns and Practices group has taken with the release of Enterprise Library, but more importantly, the birth of .Net.

While I've read through the GoF book, I have not had a chance to delve into the PEAA book yet (it's next on my list of books this year).  And, as I mentioned at lunch, even with a full understanding of these concepts, it's rare that people will come with a full design first.  It's an organic process of building, refactoring, rebuilding, and so on.  You must absolutely have the right type of working environment and leadership to make it work.

One common problem that arises when you read this book is that the concepts in it are fairly useless unless you can get everyone in your team to buy into it.  For that to happen, everyone has to understand the common language.  And for that to happen, everyone will have to have read the books.  Since very few consultants that I've met actually read text on this level (abstract, general principles), it's a rarity to be able to discuss design patterns with other developers and it's simply not worth the effort unless the development team is really looking to learn (I've been in one environment where the GoF book was purchased for every member of the dev team and required reading).  Actually, prior to coming here, my plan was to do a "book of the month" deal with one of my co-workers at [Company A] whereby we'd consume one book a month on software engineering practices (be it architecture, programming philosophy, computer science "classics", or whatever) and discuss on a daily basis (a chapter a night, 30-45 minutes of discussion in the morning).  I think this is really the only way to improve the development practices of an entire organization...you must have people that are willing to learn (and sacrifice time to do so) and you must have leadership that is willing to sponser and encourage such learning. 

In most environments, like [Company B], when consultants are hired, they are not hired to bring in best practices and build reusable code or act as software engineers; there is no concept of fostering better development practices because the leadership cannot see the value in it (indeed, the value is abstract and is only tangible in the future).  In these environments, consultants are viewed as extra hands to write code.  It becomes the decision of the individual consultant as to whether he/she chooses to utilize these design patterns (or any OOP practices at all).  When used in such a way, the power of building reusable code is highly limited as developers are essentially working in isolation until integration (which defeats the purpose going through the trouble of creating reusable software).  In all honesty, you will only see such practices in software development shops, smaller companies that have leaders that buy into these practices and patterns, and places where there has been a "grass roots" movement by developers to improve their skills.  In the large organizations that I've worked with, including [Company C], [Company D], [Company E], and [Company F], only [Company F] had developers that were actively pursuing better development practices.  And even there, only a small group of them (only two that I met) were capable enough to do so.  I briefly worked with one developer at [Company Z] (before we were [Company A]) whom also shared a passion for software engineering practices and design principles.  Unfortunately, he left the company in May/June of last year in what was a very disappointing day for me (it's always upsetting when a company cannot retain top talent like this guy).

In my situation, as I've mentioned, I'm not one to force my views on other developers, especially ones that I've not worked with.  Even beyond that, as I've mentioned, it's a collaborative effort; it's pointless to speak the language of design patterns, abstraction, and building reusable code when no one else understands and no one else has interest in learning it and this culture at [Company B] does not encourage it.

So, that's my take.

For those that aren't familiar, Nate is the "vertically challenged" rookie point gaurd on the New York Knicks basketball team.

Yesterday, this 5 foot, 7 inch human spring won the slam dunk contest in the unlikeliest twist of events.  Just when it looked like Andre Iguodala was about to coast to a victory in the slam dunk contest, Nate pulled out one of the most flawlessly awesome dunks, EVAR. I absolutely exploded off my chair when he performed the dunk with Spud Webb and completed it on the first try.  Absolutely amazing.  Scared the crap out my wife and cats when I started screaming like a mad man.

I think what's more amazing is Nate's physical and mental toughness.  On that first point, the man exerts a ton of energy to be able to be able to propel himself vertically as high as he does against the laws of gravity (I'm not about to bust out the physics equations).  I give the man a great amount of credit for that as he failed to connect, try after try, on several of his dunks.  And yet, there was no quit in his body; there was no way he was going to give up and settle.  You could tell that this man willed his body to do this bidding.  Absolutely amazing.  On the second point, some people would be mentally frazzled by the failure of the first 10 attempts and accept that it was not meant to be.  On the contrary, you could sense that the thought of failure and accepting said failure never crossed Nate's mind; you could see the determination in his eyes, try after try.

Such determination and physical toughness was electrifying to watch.  I was simply captivated by this slam dunk contest.  The very best that I can recall ever having witnessed and one that will be memorable for generations to come, I think.

I know I do.

It's one of a handful of places that I choose to do business with when it comes to purchasing computer parts.  In fact, I only purchase computer parts from online retailers (and have been doing so exclusively for quite a while).  I think, over the past 4-5 years, I've probably spent over $10,000 with Newegg (don't let the wife see that number).

Well, Anandtech has an amazing look at the internals of Newegg and how that processor you ordered on Monday ends up in your hands on Wednesday.

Actually, very few .Net developers that I've worked with know what a typed DataSet is let alone how to create one. It's one of those perplexing things that always baffles me as typed DataSets are not a bad way to make the best of the flexibility of DataSets while still offering design time support and comiple time error checking (to some degree, of course).

At the core of the typed DataSet is an XML schema that describes the types and structure of the DataSet. While typed DataSets are great, if you ever look at the code, it's quite heavy and not necessarily the most optimized structure for over the wire transport. As even the discussion of typed DataSets narrows down the audience of developers that know how to work with schemas to generate a typed DataSet, the concept of generating entire object models using XML schemas is even less understood. Yes, indeed, the XSD.exe tool that ships with Visual Studio.Net can also be used to generate object classes from the same schemas (although they are a bit clumsy to work with).

You may be asking yourself why bother with schemas when you can just create the classes by hand or some other sort of visual code generation tool. Well, for some people (myself included), schemas seem a very natural way to express object models and classes. I mean, after all, the purpose of a schema is to define what an object (typically an XML document) looks like. But certainly, if that was it, it wouldn't really be worth the effort, now would it? For me, there is an added benefit in that it's very easy to define typed collections in schemas. On top of that, the generated classes come with various XML attributes already marked up for you, which is handy if you plan on using the classes as data transfer objects for your web service.

If you're interested, check out the workshop.

Leave comments, questions, and criticisms in the thread.

Just a collection of random info to wrap up the week that was.

• This is the first year I've ever filed my own tax return.  It's also the largest tax return that I've received...hope the IRS isn't coming for me. Did it all online via http://www.turbotax.com/
  
• Every week, when I get back from Connecticut, my cat crawls on my leg and does this silly "floppy cat" act.  He just flops down on my leg and pretends like he's dead or something.  Conclusion: he needs to go on a diet
• Excellent issue of Time this week.  Covered some interesting topics, including science education in America and acceptance commitment therapy (very interesting topic).  It also had an interview with Terrance Howard, the Oscar Nominated actor who starred in Hustle & Flow and Crash:
  

  I want to be the condensation on the glass. I want to be that phenomenon that takes place between hot and cold.

• Grad school is expensive.  But it's worth it for the sake of education, right?
  
• Did I mention that I did my taxes?  I'm elated.

That's all.  I'm working on completing my latest workshop, "Of XML Schemas and Object Models" and I have two more in mind.  I plan on doing a workshop on creating a multi-threaded process status dialog and one on including inline images with CDO with .Net (I get a lot of hits via various search engines on this topic).  I'm also thinking about doing one on using CDO to create MHTML snapshots of web pages...so much stuff to work on, so little time.

I've been doing some WinForms work lately (I'm primarily a WebForms developer) and had a lot of trouble working with the WinForms DataGrid.  Primarily, the DG just seemed very difficult to customize in terms of behavior and look & feel.  Whereas with the WebForms version of the DG, the declarative model and the power of CSS makes it a snap to do these things, the WinForms version just took way too much work.

So after looking around and trying a few open source controls, I finally stumbled on DevAge's SourceGrid3.  I really like it.  It allowed me to do things with a grid that simply were waaaaay too time consuming/difficult with the out of the box WinForms DG, which is just too tied into the DataSet model and doesn't work very well with custom business objects and typed collections.

It does take some time to pick it up, but the MVC design of the library makes the code very clean and extremely flexible.

The Source Pack also comes with a variety of other controls for WinForms development.  Definitely worth a look for any WinForms developers looking for more flexibility in grids.

I came across a very good article by Ian Thomsen on SI.com discussing Shawn Marion's "frustration" towards his role in Phoenix.

Marion is averaging career-highs of 21.4 points and 11.9 rebounds, well on his way to a fifth-straight year of producing at least 19 and 9. Those are enormous numbers for a small forward, yet Marion believes he could do more if asked.

"You can improve anything you want during the summer, but if you don't get to work on it during a game, it just goes away and you go back to doing whatever it is they want you to do,'' says Marion, 27. "That's one thing I don't like. It's frustrating for me because I can do so many other things on the floor and I don't get the opportunity. I'm limited to doing certain things, and that sucks.''

Context must be introduced before this train of thought gets carried away. Is Marion demanding a greater role in the Suns' offense? No. "We're in winning situation,'' says Marion. "You don't get bleep in this league unless you win; I learned that a long time ago. I've been around people who say it's all about them, but they're wrong -- it's a team thing.''

What he's trying to say is that he isn't as impressed with his numbers as everybody else seems to be. He knows they could be gaudier.

"When I'm in the summer, playing pickup and working on my game, I'm working on pick-and-roll, handling the ball, doing all that kind of stuff -- but I don't do that here and it just really goes away,'' he says. "I do everything in the summer. I play '1' [point guard] through '5' [center]. I'm a pretty good passer, but I don't get the assists because I don't have the ball.''

I think I'm in the same boat with Marion, on some level.  Recently, I've just been so frustrated by the type of work that I'm doing at my company.  But it's not just a temporary issue; I just don't see that the company is dynamic and innovative enough to really land the type of contracts that I want to work on.  I've been fortunate that the last 1/2 of the previous year, we were able to have quite a bit of freedom in terms of execution, but if the current project I'm on is any indication, then it's not a good sign.

Understand, that like Marion, it's not really an issue of selfishness; of course I want to help my managers, my sales guys, and my company succeed.  Rather it's the fact that I work hard to become good at what I do.  I'm continually improving my software engineering IQ by consuming information through books, weblogs, magazines, and webcasts.  I make a real effort to refine my technique and learn new technologies.  Like Marion, I'm willing to take a hit for the team (I'm travelling to CT on a weekly basis at the moment, which isn't too pleasant, and doing some grunt work).  But it's frustrating because I know I could do so much more in the right environment. 

It's frustrating because I could help the company even more if the leadership could create/find the right opportunities. It's frustrating because I work on understanding design principles, software engineering practices, new tools, and other aspects of building applications/software, but all of that goes to naught due to the nature of the work I do (heavy in volume, yet light on the factors that interest me).  It's frustrating because I always want to take a step forward in terms of professional development; I don't want to stagnate.

Bah!  Just more bitching and moaning career-wise I guess.