The last day or two somebody found the blog and started spamming the comments section. All the emails for comment approval started to become a distraction. So this morning I’ve enabled reCAPTCHA on LinuxGems.
There is a reCAPTCHA plugin for wordpress that makes the captchas a snap to set up. It probably took about 5 minutes including signing up at recaptcha.net.
If you’re not familiar with reCAPTCHA, they are a bit different from some of the other captchas out there. reCAPTCHA uses a pair of words. One of which is a known word and one of which is a word that failed OCR. To pass the captcha test the user has to get the known word right.
The second word, the one that failed OCR, is actually text from older literature that needs digitizing. So using reCAPTCHA is a bit of a public service. When a statistically significant group of people put the same value for a given word then reCAPTCHA knows that they have figured out what the word was.
I noticed today that the jQuery UI folks have gone about correcting the problems with the 1.6 release candidates. They’ve chosen to tie UI version 1.6 to jQuery 1.2 and create a new UI 1.7 to work with jQuery 1.3. I think this is a great idea. Between the CSS changes in the new UI version and the UI tools that were already leveraging new jQuery 1.3 functionallity it was obvious that 1.6 would not work in both jQuery 1.2.6 and 1.3.
I notice tonight that the UI homepage shows jQuery 1.3 next to UI 1.6rc6 and jQuery 1.2.6 next to UI 1.5.3. It would have been nice if the renumbered 1.6rc6 to 1.7rc1, but I’m at least glad that the site makes it clear what will work with what.
Over at Human Services HQ we’ve stabilized around jQuery 1.3, jQuery UI 1.6rc6, a third party autocomplete, and thickbox. The only change I had to make to get jQuery UI to allow a calendar inside the thickbox was to add a z-index to the calendar div. Since then it has been smooth sailing.
A lot of pain recently with jQuery UI. They are transitioning to a major new version: 1.6. First, off there is no official jQuery UI release for compatibility with jQuery 1.3. That’s fine, jQuery 1.3 is very new. It would have been nice if they could have released a UI version at the same time, but that’s their prerrogative. Normally I would have just waited for things to settle down anyway.
Unfortunately, one of my projects had the distinction of being one of the few production sites running a jQuery UI 1.6 release candidate. We needed it to fix a problem with the jQuery UI 1.5.3 sortable. It had a bug with nesting inside of a scrollable div that has been fixed in jQuery UI 1.6. So we’ve been watching 1.6 move towards a full release and it has been a bit painful.
We needed to add an autocomplete control to our site. So we looked into it and were horrified to learn that there are basically 4 different versions, all inter-related, all with terrible documentation. What’s worse some of the UI 1.6 release candidates included an autocomplete with a different API convention, but now in 1.6rc6 that autocomplete is gone. I found this out the hard way because generating an earlier rc my page magically broke. It turned out that if you downloaded the complete rc you got the autocomplete. If you built one there was no option for the autocomplete, and they would leave it out.
After I got that fixed I discovered that merely using the new JS wasn’t going to work as jQuery 1.6 needs new corresponding 1.6 css. So now I have to roll a new theme.
Now that I’ve worked with jQuery I refuse to work without it so I’ll have to ride this out, but it has been a painful week for me to see jQuery UI folks stumbling.
End result will hopefully be this:
a third party autocomplete (I can’t remember which of the 4, we’re using.)
Update:The above mentioned combination is working for the most part. Now we’re having a problem where the popup for the date control is showing up behind a thickbox control we’re using. Hopefully I can find a CSS fix to make it work.
When I started my latest project a friend of mine asked me to look into using jQuery. I had played with MooTools a couple years ago and was mildly impressed, and I figured jQuery would be more of the same.
Boy was I wrong! For what I’m doing jQuery is way better than
MooTools is basically two things:
- A set of really nice UI widgets
jQuery is similar, but the approach is a lot different:
- A tool for grabbing a collection of DOM elements.
- A mechanism for manipulating the collection once you grab it.
- And if you use jQuery UI, a set of really nice UI widgets
The core of jQuery is a simple CSS-like syntax for grabbing a collection DOM elements from the page. It turns out that the ability to grab the DOM elements you need is actually a disproportionately large part of building a modern web app. Don’t believe me? Say you need to output a formatted table with even lines colored differently than odd lines. Tradionally, this would mean crafting a CSS class named “even” and then writing server side code to determine if we were outputting an odd row or an even row. If it is an even row then we would add a class=”even” to the tr tag. This would all be done inside of a big loop outputting the table rows.
$('table > tr:even').addClass('even')
Boom! No need to write any server side code just to add a CSS class to alternate the background color of a row.
It’s hard to believe this blog has running for 6 years. (Sort of.) Posts have been few and far between because the most recent version of the site was cobbled together using 3 php scripts I threw together in a couple of hours one afternoon. Adding new articles involved manual database work, which is why things have been so slow since we came back online in ’07. But no more!
Recently, I installed WordPress for a client of my consulting business and I learned just how easy WordPress is to work with. And, even better, it does pretty much exactly what I want my blog software to do. Without some of the extra fluff that other software includes.
So here is to ’09 and the hope of regenerating some of the traffic that this blog used to generate before I started neglecting it. I’ve imported all the old articles (mostly for posterity at this point). Check back for new articles soon.
This one classifies as one of the less useful LinuxGems we’ve captured to date, but it gets huge bonus points for being so cool. As it turns out the kernel will dump some of its state variables directly to the terminal any time you hit the correct key combo.This ones easy. Just switch to an actual kernel terminal. If are in X and you haven’t mucked with to much of your setup you can just hit Ctrl-Alt-F1. If your not in X then you are ready.
The secret keystrokes are:
- Shift-Scroll Lock = For memory allocation information
- Ctrl-Scroll Lock = For kernel state info. I don’t actually know, but this looks like a call trace for the last couple of process to get CPU time.
BTW, if you need to switch back to X it is usually Ctrl-Alt-F7.