Cross-posted from my Extensible blog. This is a post about re-engaging with the Ext JS development community with some of the projects I’m currently working on.

Yes, I’ve been pretty well absent from the Ext JS community lately.  For a while, actually, thanks for asking.  If you noticed my absence, then you probably already know who I am and maybe even a bit about my background.  If you did not notice (shame on you!) let me give a few details, if you’re interested.

A Little Background

Waaay back in the fall of 2006 I met up with Jack Slocum over the internets.  At the time he was working on his YUI-Ext components (extensions to Yahoo’s at-the-time nascent JS framework) and I was doing some contract web app development and was looking around for a framework to use (again).  I ran across YUI-Ext and thought it was just awesome stuff, especially coming from some random, lone dude out in cyberspace.  I pulled down the code, sent a few patches back to Jack which he liked and we started talking.

Before you know it, by March of 2007, Ext JS (both the 1.0 framework and the company behind it) was officially born.  In those days it was literally just Jack and me — it was a crazy amount of work, but fun and a very interesting time.  As you probably know (since you’re reading this) Ext JS took off and continues to do quite well as one of the premiere web app development frameworks available.  All of that sounds great, right?  Then you’re probably asking…

“So Why Did You Leave?”

Well, in startup companies, as in life, things can get pretty interesting.  Things change (constantly), situations change, people change… none of which is good or bad necessarily, it just is what it is.  As the company grew, it simply got to a point where I didn’t fit quite as well into what was going on as I had in the beginning.  That, combined with the fact that my wife and I were going to have a baby in early 2009 (which did not gel very well with my 16-hour work days at the time) meant that something had to change.

I left Ext JS in October of 2008 on amicable terms.  At the time I was pretty burned out (and the baby was due shortly) so I literally switched off my brain for about 6 months and worked on the house, outfitted the nursery, read a bunch of baby books, watched movies… basically anything that did not involve writing code.

Fast Forward to July 2010

My daughter is now a happy (well, mostly) and healthy 17-month-old toddler.  Wow, let me let that sink in for a sec…

I finally switched my brain back on sometime during last year and have slowly been ramping a few projects up.  Even back when I left Ext JS officially, I always planned to return actively to the community at some point, when the time was right for me.

It just so happened that I had been working on some calendar components already when I heard that the Ext team was also thinking about doing something similar. I got back in touch with the current team (now rebranded as Sencha) and ended up working with them to contribute my components as a sample calendar application to the Ext JS 3.3 release (currently in beta as of this writing).

I’m still improving and adding features to those same components and will be releasing a more advanced version independently in the coming months (with Sencha’s full blessing).  Contributing something back to the framework has been a great way for me to jump back into the Ext JS game with both feet.  My plan for Extensible is to continue pushing out interesting and useful components for Ext, as well as other resources like tutorials and other tools, so keep an eye out here if that sounds interesting to you.

All of this is a really long-winded way for me to get to my real point, which is simply… It’s great to be back!  I can’t wait to start building some cool stuff (again).

–Brian

“.objc_class_name_AVAudioPlayer”, referenced from:
literal-pointer@__OBJC@__cls_refs@AVAudioPlayer in PhoneViewController.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I mean, seriously.  What is that supposed to mean?  Now, since I had just added some new code for playing a sound in my iPhone application, it was pretty obvious that was the cause, but the error message gave me no clue as to what the actual problem was.  Here is the line of code that caused the error:

Pretty straightforward, and copied directly from an Apple sample app. Turns out that even though I was properly importing the AVFoundation framework (required for working with audio/video) in my code, e.g.:

…I had not created a project reference to that library.  You do that by right-clicking on the Frameworks folder in the Groups & Files pane in Xcode and choosing “Add… Existing Frameworks…” then selecting the framework(s) you need.

Again, very simple and only something that would trip up a complete n00b like me.  I don’t mind a learning curve, but more-helpful error messages would sure make it quicker to overcome these types of issues.

It was easy enough to figure out the problem through a little Googling, but it took me a while to discover how to actually solve it, at least running on the iPhone simulator. Of course, it makes sense once you figure it out… all you have to do is delete the app from the simulator, the same exact way you delete apps off of a physical iPhone — click and hold the icon until it switches into jiggling edit mode, then click the X button to delete it. So simple, yet maybe not so obvious.  You would logically think that this is something Xcode would do for you, or at least give you the option.

After doing that I was able to simply recompile and run my project with no problem. I like Objective-C so far, but the errors you have to figure out while working through the learning cycle have often been a bit more cryptic than I’m used to from other environments…

EDIT: Well, it seems that another error, Can’t find model for source store, is also solved by the same method of deleting the app from the simulator. I have no idea what caused it though…

Well, apparently they have! And it’s actually been available since version 2.7.0., but it does not appear to be very well publicized (and many custom themes, like the one I’m using, have not been updated to use the new function). Googling for the phrase “wordpress highlight author comments” leads to lots of methods for doing this the old-school ways of modifying template code, or installing special WordPress plugins to achieve comment highlighting. Luckily, I stumbled across this page from the WordPress documentation website that describes the comment_class() function, which automatically outputs a set of CSS class names that provide for just about any comment theming you would need.

If you are using a theme that has not been updated (but you are running WordPress 2.7+), you can modify one line in comments.php like I did so that it will call the new function. Find the loop that outputs the comment blocks, and modify the opening <li> tag code to match this:

The key is the comment_class() function (which should be defined in the file wp-includes/comment-template.php if your WordPress version is current). This function is called on each iteration, which will give you an extremely useful list of CSS classes in your HTML output. Here’s an example of the output for a comment I wrote:

Wow, that’s a lot of useful classes! The class I’m looking for is bypostauthor, which indicates that it’s a comment I wrote. You could also choose comment-author-admin instead, for a blog by mutliple authors if you wanted any admin of the blog to be highlighted. They’ve even included classes for thread depth, if you’ve configured nested comments — too cool!

While I’m here, I’ll also add a separate style for odd and even rows to get alternating row colors. Doing all of this is simple now, just a few basic CSS rules added to the theme’s main stylesheet:

Note that the bypostauthor rule must come after the even rule in the CSS file (in my example at least). Since they both change the same attribute (background color) the second rule will always take precedence when they both apply (i.e., when one of my comments is an even row). I want any comment by me to always show up with the same color regardless of the odd/even rule.

So there you go — nice and simple, much better than the old days. Thanks, WordPress!

I randomly ran across it again and decided to check it out, but was immediately met with this inane “error” message upon loading the home page:

Normally these types of messages are more geared toward viewers with low resolutions who may not be able to see the full width of a site.  Still terrible from a UI perspective to hammer your user with an alert, but at least (arguably) reasonable from a logical point of view if your layout will be visually truncated.  But warning me that my resolution (as opposed to my browser window) is too big?  That’s a new one to me. Sure enough, here is the code from their script:

WTF? So the recommendation is not that I resize my browser (which would be bad enough, although it is commonly done), but I’m expected to go into my computer’s settings and reduce the screen resolution for my entire operating system so that I can “best view” their (kinda crappy-looking, by the way) site? And that is crucial enough to stop me dead in my tracks on the home page of the site during my very first experience as a user of their site?

Note to the site author: I’m doing OK with my 2560×1600 resolution, and am able to view your site just fine, in all its glory. In fact, I am able to view more than one site at a time, one of the perks of having a resolution larger than 1024×768. You should try it sometime

I just freshly installed WordPress 2.9.1 and found a nice clean theme called Clean Home (version 1.2 at the time of install).  I’ll probably change it up later, but for now, it’s a nice simple clean slate to start off with.  After getting the basic site set up I decided to compare across my typical suite of testing browsers that I always use to verify web pages I’m working on (Safari, FF and Chrome on Mac, and FF, IE, Chrome and Opera on Windows).  I was primarily comparing the font rendering to see if I wanted to tweak anything, when I noticed that my non-blog pages (like the About page) had a weird rendering issue only in Firefox (both Mac and Win).  Basically, there was a post slug (title, date, author, category, etc.) that was not supposed to be there since they only show up within the blog section of the site.  Also, there was a --> displayed at the end of the slug, the telltale sign that an HTML comment tag did not get closed properly.  But this code is generated from a template on the server, so it’s exactly the same in all browsers (and works fine in everything BUT Firefox).  So what gives?

I examined the page source (found in page.php) and saw this right after the start of the <div class="post"> block:

A big block of HTML — the page title and post slug section — are commented out (but still available to tinkerers like me, which I appreciate).  I have never run across the case where having a double-hyphen inside a comment would cause a problem, but being the genius hacker that I am, my first instinct was to remove that and refresh the page — voilà, no more post slug in FF.  The block of HTML is now properly commented out.

Out of curiosity I Googled this just to check my sanity, and sure enough, it’s a well-known “bug that’s not a bug” with versions of Firefox going back many years.  Basically, the HTML spec (up until version 5) allows whitespace between the -- and the > of a closing comment tag (although interestingly, not in an opening comment tag), and Firefox is apparently the only browser that actually enforces that rule.  I found a great write-up on this issue from a blogger who tried unsuccessfully to report this “bug” to Mozilla — if you are a web developer you’ll definitely appreciate it.

Anyway, problem solved and blog officially kicked off, all in one post!