Debugging unobtrusive javascript in jQuery
So if you work for a large enterprise website like I do, where each page loads dozens or hundreds of kilobytes of javascript, it can be hard to figure out exactly what happens when you click that div and something magically happens, due to the wonders of unobtrusive javascript.
Or, to rephrase the question, "I know how to add event handlers to an object -- how do I enumerate what's already been attached?"
And it's pretty easy, but unfortunately it doesn't use a public API. Anyway, try this in Firebug:
$("#the_button").data("events");
If there are any events on that element, they'll be displayed. The only drawback is...you have to know exactly which element the events are attached to, or guess around a bit.
Enjoy!
IE + AJAX + Redirects
So we made an interesting discovery these past days...IE handles some redirects in AJAX really, really badly.
This table explains:
| Redirect URL | ||
|---|---|---|
| To itself | To another page | |
| FF | Redirect 18-20 times | Didn't test |
| IE | Redirect until you close the browser | Redirect 10 times |
(By "redirect to itself" I mean you have some bug in your logic such that page http://example.com/?page=1 will redirect to itself indefinitely.)
Do you like that "redirect until you close the browser" one? Even if you go to a completely different site, the browser will still be making requests to yours.
Moral of the story: be very careful with redirects with AJAX.
Banks and OAuth support
For fun, I decided to ping all of my financial companies (Bank Of America, CapitalOne, Chase, EmigrantDirect, INGDirect, Vanguard) about their plans for OAuth support. I don't know how many of you use the wonderful service known as Mint, but I like it a lot. Unfortunately, a part of me died when I gave them my username/password for my banking sites. And INGDirect is secure enough that Mint can't even interface with them! Sorta cool.
Anyway, here's what the institutions said:
Web server output generation design patterns
There are several styles of content generation that I know of so far...I'm reviewing them because I'm looking to see if there could be something better.
Flat-file
Example: plain ol' PHP
PHP, at its simplest, doesn't have any separation at all -- you can, if you choose, have all the programming/form-processing logic in the same file that renders the output to the browser. While simple, if you're creating a full website, this can be cumbersome and confusing.
phew
Migrated from Slicehost to Rackspace Cloud (which is basically the same company). Should save me $10 a month! Moving databases and service configurations over is a pain, though.
Design pattern/flow for building a website
So here's how I normally do things:
- Do as much of the models as possible in this first pass, skipping validation but including schema stuff
- Stick a couple things into the controllers that I think I'll need
- Build out some of the views, giving them some basic styles
- Revisit the models to add validation, helper methods
- Build out the rest of the views, give them real styles
- Muse about specs, then give up before starting
- Put more stuff into the controllers
- Iterate on random components until you're done
Needless to say, I'm getting to the point where my lack of organization kills my mini-projects before I hit step 4, sometimes even sooner than that. So I'm going to try a slightly more...conventional (or widely suggested, at least) approach:
- Create controllers with just enough information so that your pages will display. No setting variables yet or other logic!
- Fill out the views with as much HTML and fake data as you need. Site have a sign-in page? Leave a link to "force sign-in" the user that simply sets them to an authenticated state. All it should do is set a session variable
- Spec out the models. Don't check for validation yet, just check for core functionality, i.e. there is a User table, the first user has a name of Foo and email of bar@baz.com, etc.
- Fill out your model code so that the specs pass -- this includes migrations with sample data (these can be removed in a later migration).
- Spec out your controllers/views.
- Fill out your controllers/views so they pass specs.
- Do the rest of the little things that need doing, like validation, error messaging, authentication, styling, etc.
- Revel in having finished a project.
Hopefully I'll get further than step 3 this way! I'm going to try to focus more on content/frontend instead of getting bogged down in the backend, and I want to actually write specs.
Any comments/suggestions?
Vostro (1400) + Ubuntu 9.04 + sound issues
Another Ubuntu upgrade, another sound configuration that doesn't work out of the box. This is what I had to do for Ubuntu 8.10, that also worked for this version:
$ sudo vim /etc/init.d/alsa-utils
Around line 364, replace this
[ "$TARGET_CARD" = "all" ] && log_action_end_msg_and_exit "$EXITSTATUS" exit $EXITSTATUS ;; stop) EXITSTATUS=0 TARGET_CARD="$2"
with
[ "$TARGET_CARD" = "all" ] && log_action_end_msg_and_exit "$EXITSTATUS" exit $EXITSTATUS ;; stop) ifconfig wlan0 down ifconfig eth0 down EXITSTATUS=0 TARGET_CARD="$2"
Then restart. In 9.04 I also had to go through my volume control panel and make sure nothing was turned all the way down or muted. I think I had to unmute the master volume and turn PCM Playback (under HDA Intel) up.
Please comment if this helps you!
UPDATE April 29th, 2009: I also had to reinstall flash in order to get sound working in Firefox again.
XSLT is a giant pain
Some of you may be aware that XML+XSLT 1.0 can be rendered directly by modern browsers (even IE6!), which led me to thinking that it may be a good idea to give it a try and see how good or bad it was.
Announcing: Ramastic, a skeleton for Ramaze
This is something I've been working on since slightly before my original call for suggestions a while back. It's not done yet (I'd say it's somewhere around 75% done) but I want to get it out there before I totally lose steam on it. There are a few inline styles I was planning on removing, but haven't gotten around to, so...apologies. If you find it of use, please leave a comment.
And yes, it doesn't look that great. But I'm expecting you to restyle everything anyway and possibly blow away the templates entirely in your instantiation of the skeleton.
Now, without further ado, here are features and screenshots:
Features/requirements
- Built on Bones
- Edge Rack/Innate/Ramaze
- Haml/Sass
- Sequel + sqlite3
- Blueprint CSS
- jQuery, jQuery UI
- OpenID (via RPX)
- RestClient
- Crack
- UUID
- Rack-flash
Screenshots
Repository
Thanks for looking!
Ideas Needed for Mr. Bones skeleton built on Ramaze
If I were to make a skeleton using Mr. Bones that was built on Ramaze, what would people like to see in it? It's for my use first, but the community's use a close second if I can generalize it enough. I was thinking along the lines of openid support, having a decent home page and logged-in-user gateway, appropriate nav-bars, haml+sass, jquery+ui, etc....thoughts? What do you find yourself doing at the beginning of every website project that you'd like to not have to repeat every time you start a project?