The Chicago JavaScript Meetup Group spurred more than 50 of its members to brave harsh weather Thursday night for the group’s fourth free get-together since its founding last October.
Organizer Vlad Didenko led the charge with an in-depth look at Firebug, while assistant organizer Justin Meyer contributed a discussion of Ajax fundamentals.
Read more »
I’m as geeked about jQuery’s 1.3 release as the next developer. But I’m even more excited about the new API browser developed by Remy Sharp and available here.
For as long as I’ve been a jQuery user – going on 18 months now – I’ve been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we’ve got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it’s available as an Adobe AIR app for offline viewing. Sweet!
I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I’ll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery’s API, it’s a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.
jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.
Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous’s FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).
My most recent Pathfinder project calls for a pretty typical Ruby on Rails web application with two interesting additional components: a Facebook application and an iGoogle gadget. Though a Rails Facebook plugin was easy to find, Rails development tools for iGoogle weren’t as thick on the ground.
First, a bit of background: iGoogle, Google’s personalized-homepage service, offers developers two methods of application development:
Because of cross-domain security issues, gadgets that require authentication must be built using the iframe sandbox method. As it turns out, this method’s a lot easier. Instead of building a whole new interface, you can just tart up your existing app with an iGoogle-optimized user interface. Why replicate your existing view logic with a bunch of iGoogle-specific JavaScript when you can just reskin and call it a day?
As it turns out, though, reskinning a Rails app for iGoogle isn’t as simple as it might seem at first glance. I can think of three options. All have drawbacks:
Read more »
http://localhost/~username/ sites go haywire, it’s time to dig into your Apache config files
As Rails pros know, Phusion Passenger allows you to serve multiple Rails apps on the same Apache webserver instance with few configuration or deployment headaches. When you install it in your local Mac dev environment, you can easily work on a bunch of Rails projects simultaneously without having to manually start and stop individual server instances all the time. The OS X Passenger preference pane makes deployment even easier. Just add a project, give it a custom local URL, and point it at a directory. You’re good to go.
But what happens if you’re already using OS X’s built-in Apache webserver to dish up local content such as PHP applications or static HTML? When I first got Passenger up and running, all of my local sites in /Users/<username>/Sites/ stopped working. It took a bunch of digging, but I eventually realized that something in my Apache configuration had gotten messed up during the Passenger installation process. I was missing the configuration file for my OS X user account. OS X generates this file the first time you enable web sharing for any individual user. It’s responsible for mapping your /Sites subdirectory to localhost URLs, so that http://localhost/~<username>/myapplication/ points to /Sites/myapplication/index.html.
If you read one or more of the Pathfinder blogs in our web interface, you may have noticed some tweaks to our navigation and top-level categories. Our goal in making these changes was to help different audiences drill down to the specific content that interests them. Instead of just a few top-level categories, we now boast around 20, though many posts appear in multiple categories. To subscribe via RSS to any specific category – or to our entire feed – just visit our Feeds page.
Rosenfeld Media contacted me after I published my review of Luke Wroblewski’s “Web Form Design: Filling in the Blanks.” They offered Agile Ajax readers 10% off “Web Form Design” or any other purchase at rosenfeldmedia.com. To redeem, simply enter the code PATHFINDER at checkout.
Usability and design guru Luke Wroblewski knows that web forms suck. More importantly, he knows why – and how to make them suck less.
For the past few years, the Yahoo! product design exec has been presenting his ongoing research into the humble HTML form at conferences and on his blog, Functioning Form. I attended Wroblewski’s presentation at An Event Apart Chicago 2007 and came away super-impressed. His persuasive mixture of case studies, existing research and newly commissioned usability studies helped shed light on the patterns and anti-patterns that determine whether users successfully complete your forms or give up in disgust.
All of Wroblewski’s preparation came to fruition earlier this year when he published “Web Form Design: Filling in the Blanks” (Rosenfeld Media). After finally taking the time to read the book cover to cover, I’m mad at myself for waiting so long.
Read more »Welcome to “Ask a UI Guy,” an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today’s topic: strategies for organizing your style rules into reusable components.
CSS doesn’t impose much structure on its practitioners. Individual developers must build their own structure if they wish to escape the trap of poorly organized, inefficient code.
If a project kicks off without a clear shape to its stylesheets, subsequent developers are likely to plop additional styles down wherever is convenient. It’s hard to build reusable components if every style is a one-off tied to an element id. Stylesheets with a strong skeleton and frequent signposts encourage conscientious code that’s easier to maintain.
And let’s face it: CSS tools hasn’t come as far as JavaScript ones. Sure, Firebug can help you track down why element X looks the way it does. But without a clear picture of a project’s overall CSS architecture, it’s hard to alter that element’s style properties with confidence.
Read more »Welcome to “Ask a UI Guy,” an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today’s topic: the deceptive allure and subtle peril of inline styles.
When you’re first cobbling together a new feature or content page, inline styles can seem like a great idea. You’re already editing an ERB, JSP, PHP or ASP template, so why not just write your CSS code in the same file? Throw a few style attributes into your HTML tags, populate them, and voila: instant look-and-feel.
What seems good in theory, however, quickly falls apart in practice. Many seasoned CSS developers employ external stylesheets for even the most roughshod of skunkworks. They do so with a fervor approaching that of TDD adherents carefully writing tests before even thinking about tackling actual code. People have been arguing against the use of inline styles in production code for close to a decade now, but I argue against their use at any stage of a project. Here are some of the reasons why:
Read more »