Joe Coder

Programming Languages I've learned

I was listening to a Hanselminutes and Scott mentioned having learned a dozen or so programming languages (which is probably low for him). Which got me to thinking. Here, in the order I learned them, are the programming languages I've learned.

By "learned" I mean - became at least moderately competent with, wrote real programs in, and used for at least several months. Not just "played with over a weekend."

1. Logo
2. Applesoft BASIC
3. Pascal
4. C++
5. Java
6. VBscript (with classic asp)
7. T-SQL
8. VB
9. C#
10. Javascript

I'm a lightweight among my peers, but that's my story and I'm sticking to it.

It's funny how those first languages hold such a warm spot in my heart. It was with those that I first fell completely in love with programming computers.

I'd do the "tag" thing but those are lame, plus no one reads this blog for it's gripping yearly updates. But if you do manage to see this - what languages have you learned?

How to debug Javascript in Safari

Link: Safari Developer FAQ.

Apple to gain real ground in dev?

One of Microsoft's lasting areas of dominance has been software development. No one, really, has as advanced an infrastructure, toolset, platform, community or as much momentum. But Apple is wisely recognizing this largely unchallenged market and they've got my attention. First they revealed yesterday that they're now shipping some real powerhouse machines with quad Xeon processors and 16GB of RAM if you want it. Then this: Ruby on Rails will ship with OS X 10.5 (Leopard).

That's a big deal. They're starting to appeal to nerds, not just the snobsquad of thick-frame-glasses-black-turtleneck-kenneth-cole-styled designers.

Microsoft and our community ignore the RoR movement, the clean, simple, lighter, standards compliant, "web 2.0-ish" way of doing things at our peril.

It’s been no secret that Apple is held in very high regard by the Rails community. Every single Rails Core contributer is running on Apple and the vast majority of Rails developers are too. (-emphasis mine, src)

Free copy of WinRAR

Special One Day Offer.

Form Validation Quandary

I'm doing form validation, and it seems I have the following (acceptable*) choices.

1. Straight clean Javascript on the client, double-checked by the server on submit.
2. Ajax talking to the server for the validation logic, reporting back to the client, and of course, backed up by the server.

Issues with option 1:
It's nice because: 90%+ of users will likely get their needs met with the client side checking, very quickly. If it fails, the server logic will keep it from running afoul.

It stinks because: I'll have to write validation logic twice. I'll have to do some additional voodoo to make the client-side reporting of the errors work from the server side.

Issues with option 2:
It's nice because: I only have to write my validation logic once. I can use the same logic, in fact, for the double-check on the server when the page submits.

It stinks because: I have to write the AJAX hooks, and I'll still have to find a way of making the client-side reporting of errors work after the submit.

Maybe it's a wash? Maybe if I go with 2 I'll be able to leverage the AJAX for other benefits.

Additional considerations:
This is another of many moments when I'm faced with the option of just not supporting browsers without Javascript enabled. I've come a long way without making that decision, but it's a hard one to avoid. We know it's not a good practice to do so because it alienates some visitors. But the compromise between creating graceful degradation and "getting something out there" is a tough one. 37signals decided long ago that anyone without Javascript was out of luck. They also have a very sophisticated audience, for the most part. I don't imagine they've lost many clients because of that decision. (I'd love to know the numbers). More importantly, they've released product and are making money.

* The built-in asp.net validation controls are too messy.

Microsoft: .Net Beat Java, Who's Next?

Yes, they really have.
But it's not over yet. With comments like this one:

"As we focus on the enterprise segment, we have the ability to drive up our revenue share."

...I worry. I understand that you need to generate revenue for shareholders. And frankly, I don't begrudge you that. Go ahead. Cater to the enterprise.

But... "Who's next?" you ask?

The lightweight RAD-that-doesn't-blow stuff like Django/RoR/PHP. Of course this is selfish on my part. I realize my tiny segment of uber geeks is hardly a market-share worth pursuing. However, we're a barometer and an early warning system. As we go, so goes the industry in the near future.

And comments like this, really don't encourage me:

Moreover, looking beyond J2EE, Microsoft has to deal with issues like AJAX (Asynchronous JavaScript and XML)-style development, as well as lighter-weight frameworks such Ruby on Rails.

Ozzie said Microsoft must create frameworks for different types of development. For instance, in the Web development space Microsoft has ASP.Net, and for AJAX-style development Microsoft has its Atlas tool.

*sigh* - Ozzie, everyone knows you're a genius, but you've obviously never looked at Atlas and you don't understand the crowd that uses (or wants to use) RoR. Atlas is fairly decent at mass-market buzz-lover appeal, and I suppose you'll get some VB6ers to convert over to it and get all excited. But no one in the serious web developer community can take Atlas seriously. It's too abstracted, too black box, too sealed. We don't want more black boxes and heavier frameworks we want (as you said) lighter-weight frameworks.

Why serious web developers can't use Master Pages

ASP.NET 2.0 is a wonderful leap forward from 1.1. Much has improved, and one exciting improvement is Master Pages.

Only Master Pages can't be used by serious web developers.

For today: serious web developers = web developers who wish to observe best coding practices, especially loose coupling and clean separation between layers.

The problem:
Master Pages use a little gremlin called INamingContainer to "help" you. It ensures that no id names on a given page will collide. It does this by kindly renaming your control ids. So if your control id is called "textbox1" - when you use it with master pages, it becomes "ctl00_ContentPlaceHolder1_TextBox1".

And I suppose in some situations, that might be helpful. But in all situations? Come on guys.

The solutions out there range from detecting what that that name is going to be, and dynamically generating your CSS or Javascript, to hard coding what the control will be into your js based on the predictable naming convention. These are completely unacceptable solutions.

The only real solution (short of writing your own control, which I'm pondering), is to skip using Master Pages all together. Which is a serious shame. They had such insanely cool promise.

*sigh*

For more info, read through some of the comments on this post by ScottGu (including our hero's silly suggested workaround) and this article (scroll down to "Name Mangling"). All the suggested solutions are preposterous.

A cool Javascript IDE

As an undying fan of VS's intellisense and other code-helpers, I'm pretty excited about this new tool. Aptana is a very nice looking IDE for JS (any web stuff really, but it seems to shine for JS). There's even YUI (and many other libraries)-specific support. Cool!

YUI Library Release 0.11

Let's all do the happy dance!
Actually, adding the file-upload capability to the Connection Manager might just be enough to garner it some more love from the "L337" JS/Ajax weenies out there. Yahoo! User Interface Blog.

findContainer()

When handling events in the DOM it's often useful to get a reference to the containing element (say, a div) around a certain item. For example: you've got a "hide" link inside some element (the div) and you want to detect the click on the "hide" link, then hide the (div) element.

So... you need a handle on that containing element (the div) so you can hide it.

With this in mind, I created what I'm sure is highly unoriginal, but it works quite well for me. I present: findContainer().

Note: YUD = Yahoo.util.Dom.

function findContainer(el, containerCssClass) { var currentNode = el; while (!YUD.hasClass(currentNode,containerCssClass)); { currentNode = currentNode.parentNode; //failsafe, they went all the way up if (currentNode.parentNode.nodeName == 'HTML') return el; } return currentNode; }

This function takes 2 arguments. The element being acted (probably clicked) upon (the "hide" link in this example) and the css class of the containing element.  It will work it's way up the tree until it runs into an element with the specified class. Once that class is encountered, it returns that element. You can then hide it (or whatever).

You could easily re-purpose this to have it take an element type as the second argument. (e.g. 'DIV' or 'LI') with the same effect. The cssClass method feels more predictable to me.

My Philosophy and Approach

• I hate high level abstraction. "Black Boxes" if you will. ATLAS is one, so is GWT. I don't want to program in binary, but I also don't want a miracle tier. It's important for me me to have (a) control and (b) understanding. Without those, an application quickly devolves into a mess filled with compromises and maintenance headaches. I'm all for frameworks, toolkits, and other RAD resources, but from there up, I want to roll my own.
• I'm a Microsoft guy, and I don't apologize for it. Microsoft has done a stellar job creating development tools. They are fans of the miracle tier, but I completely and fiercely ignore that stuff. (Microsoft has to appeal to the VB6/2-tier crowd, and I grumble and whine and swear it's a complete waste of time and resources, but it's their right. I understand it from a business standpoint.) The .NET framework is a thing of beauty. And Visual Studio is (finally) near perfect. I can't imagine a life without intellisense. Microsoft has created a powerful foundation. ASP.NET + SQL Server are my world. I love how they work and I've hitched my wagon to them.
  
• I'm a harsh Microsoft critic. It used to be they could do no wrong in my eyes, lately (last 2-3 years) they've disappointed me greatly and I'm not shy in talking about it. But, per my previous point, my criticisms come from a place of love. I want them to succeed, their success is mine.
• I'm a javascript noob. I resolved at the beginning of the year (2006) that I would learn it. I've been reading voraciously, applying, eating the learning curve and I'm now currently engaged in a large-ish project that heavily uses it (for me, nothing teaches like the need to do something real with it, now). I'm actually falling in love with javascript. Which is astounding to anyone who has heard me talk about javascript in years past. I hated it with such a festering passion that when I spoke of it, my wife wondered if I used that same mouth to kiss my mother.
• I spent a great deal of time evaluating different javascript frameworks. The frontrunners were (the horridly named) Prototype library and the Yahoo Interface Library (YUI). After fooling around with both, creating junk, reading documentation, reading community opinions, I landed on YUI for my current project. It's not quite as rich or mature as Prototype, but as a traditionalist OOP purist, and formally-trained programmer, its approach appeals to me. Plus it has the backing of Yahoo. Prototype has way more stuff and a much larger community, but it feels a bit too (wait for it) "black box" to me.
• I've brewed my own approach to AJAX that I'll share in another post, but in short: YUI Connection Manager -- post back -- page detects an AJAX request by looking at the querystring -- use normal framework mechanics to construct the HTML response -- spit it back -- Response.End -- innerHTML the response into the appropriate spot. 
• Yes it's possible to be a Microsoft guy, and a javascript/AJAX/Web2.0 guy. Get over it.