Your Ad Here

Archive for the 'Code' Category

Clearing Form Fields with JQuery

Published
by
Phil Crissman
on May 9, 2008
in Code
. Comments

I used a little jQuery last night to clear some form fields. The basic idea was, there were a couple text inputs in the form for first and last name; rather than label the fields, I made the value of each form to be initially “First” and “Last” respectively.

Then I was requested to make it so that when the field was clicked on, the word “First” or “Last” (respectively) would disappear, so that you could then proceed to enter a value without needing to highlight and delete the existing value of the text field.

It turns out that with jQuery, this is simple enough; let’s assume your field has the class “clearme”:
Continue reading ‘Clearing Form Fields with JQuery’

Conditionals in Io

Published
by
Phil Crissman
on May 2, 2008
in Code and Linux
. 2 Comments

Was playing a little with Io. I like one of the options for the conditional if; you can basically just pass “if” three arguments; a statement, something to do if it’s true, and something to do if it’s false.

So you can do simply:


Io> a := 3
==> 3
Io> if(a%2==0, writeln("a is even"), writeln("a is odd"))
a is odd
==> nil

I know, in ruby you could just do a%2==0?"a is even":"a is odd", and similar in other languages. I do like the idea of if looking like a function to which I’m passing arguments, though. Just seems intuitive, somehow.

Twitter off the Rails? And, so what?

Published
by
Phil Crissman
on May 2, 2008
in Code
. 5 Comments

There’s a rumor flying around that Twitter is going to abandon Rails, so obviously this calls for us to stop and ruminate without making even the barest efforts to confirm or deny said rumor. Facts may be added, like a garnish, to later blog posts, like Parmesan cheese to your spaghetti.

For example, Evan Williams says that Twitter has no plans to abandon RoR. Hm. I guess that ought to just stop this particular line of musing right out of the gate.

Never mind. Let’s talk about it anyways.
Continue reading ‘Twitter off the Rails? And, so what?’

Frameworks Are Like Sonnets

Published
by
Phil Crissman
on April 29, 2008
in Code
. 9 Comments

Yesterday evening Ruby on Rails came up while talking to my mom, and I decided to try to explain what a framework was. I wound up comparing a framework to a sonnet.

If you’re writing a poem, and you decide to write a sonnet, you have a lot of little things decided for you right away. You now know the length of the poem, and the general structure. You know how long each line will be, and you even have some criteria for the content (iambic pentameter and a certain rhyming scheme). Other than that, you can do whatever you want.

It’s by no means a direct analogy, but because my mom knows what a sonnet is, the concept of a framework made sense to her right away.

I may have overreached just a little to use sonnets as the example. Maybe frameworks are more like limericks. Same idea, though.

Detecting Palindromes With Python, Revisited

Published
by
Phil Crissman
on April 22, 2008
in Code and Python
. 3 Comments

I know this is first year computer science stuff, but it can be fun to play with.

Suppose you want a simple, general purpose function to find palindromes. Here’s what I came up with; we’ll name it “ispal.py”:

#!/usr/bin/python
import sys
import re
q = sys.argv[1]
q = re.sub(”(\s+|’|\.|\,|\!|\?|\:|\;)”, “”, q).lower()
print q==q[::-1]

Line by line, it’s pretty simple.
Continue reading ‘Detecting Palindromes With Python, Revisited’

What’s Wrong With Whitespace?

Published
by
Phil Crissman
on December 3, 2007
in Asides and Code
. 2 Comments

More and more I’m seeing people disparage Python over the whitespace issue. What’s most disconcerting is when the same group embraces YAML, Haml, and Sass, because for some reason it’s okay if they have significant whitespace.

I don’t buy it. Yes, when you’re new to it, it’s frustrating to have bugs that are only the result of whitespace, or lack thereof. But if you’re new to a language, syntax errors are just something you learn by making them; I daresay that everyone learned to end lines with a semi-colon in [insert appropriate language here] just by forgetting it a few times.

On top of that, I’ve yet to see anyone who doesn’t prefer clear, well indented code, to sloppy hard-to-read code.

I like to use a variety of languages, and even though Python’s not something I use very much right now, I fully expect to use it in the future, and would do so happily. It’s a great language.

So what’s the big deal with whitespace?

(I almost called this post “All Whitespace Is Significant”, planning to point out you at least need to put a single space between tokens so that your code can be parsed, but I figured the flames telling me I didn’t understand “significant whitespace” wouldn’t be worth it… ;) )

Perl On Rails; everything on Rails?

Published
by
Phil Crissman
on December 1, 2007
in Code and www
. 1 Comment

The BBC Interactive department writes about how they’re using what amounts to Perl On Rails.

For a short while, Rails seemed like it might be a lot of hype over something new, for the sake of something new. Then it started to seem like it might be a bit of a fad, then it became clear that it was a Good Thing that Many People wanted to use. Now I’m thinking we’ll look back on development in this first decade of the 21st century, and Rails will be among the highlights that looms the largest.

I suppose when we start porting Rails to other languages and environments, continuing to call it “Rails” is more of a convenience than anything else. We could just say “Rails-like code generation and MVC” and I think that, for the most part, we’d be saying the same thing. Not all the following are deliberate “Rails Clones” per se, but we have:

  • Django: Of all the alternatives to Ruby on Rails, this seems the most popular. Uses Python, a popular language with hackers and early adopters.
  • TurboGears: Another Python project. I haven’t heard much about this one, but it seems to still be active.
  • PHP On Trax: As the name suggests, this seems to be a deliberate port of Rails to PHP. Seeing the traction that PHP has, this is worth looking into. If you wind up in an environment where PHP is the prescribed platform, this might be a good framework.
  • Symfony: Not a Rails clone (I don’t think), but it advertises as having “simple templating and helpers, smart URLs, scaffolding, object model and MVC separation, and Ajax support”, so I’d say it seems to fall into the same family of modern frameworks. Also PHP.
  • Junction is apparently Rails for… Javascript? I know very little about this, so you’d best just follow the link if you’re interested.
  • Steve Yegge’s Port of Rails to Javascript: I don’t know if this project has a name, or if it’s available outside of Google, but this made some headlines awhile back.
  • Groovy on Grails: Yes, couldn’t forget Groovy on Grails. Groovy is a scripting language based on Ruby that runs on the Java Runtime Environment. Grails is… Rails for Groovy. If I’ve oversimplified this description, feel free to correct me in the comments.
  • JRuby On Rails: I don’t thinks there’s an official site for this; my understanding is that JRuby is compatible enough with Ruby that Rails is essentially still Rails… just running on JRuby instead.

And, of course, the aforementioned Perl on Rails. Wow! Quite a list, and I’m sure I missed some frameworks, both Rails-inspired and otherwise. I’m not interested in listing all frameworks, though, but specifically those with Rails-like features.

So, yes. Whether people choose Ruby or not, it seems pretty clear that Rails-like frameworks have caught on in a big way. Suits me fine; the more I learn about the framework, the more I like it, and it’s great to know that similar frameworks exist should I have the need to use an alternate language.

Can We Unify Our Feed Formats?

Published
by
Phil Crissman
on November 26, 2007
in Code and www
. 3 Comments

Thinking about Feeds.

So we have XML, generally. We have RSS 0.91, 1.0, 2.0, we have Atom. Of the aforementioned, I’m currently partial to Atom. This is just after a cursory comparison of the different formats, I could certainly bear to look deeper into them…

However… they are all feeds designed to do pretty much the same thing. That is, they’re similar enough, it ought to be fairly easy to choose one format, and then parse other formats and then re-publish them into the One True Feed Format.

There are challenges with the above approach. Some formats include elements or attributes which don’t have a corresponding equivalent in another format. These could be filled in with default values so as not to lose data.

Still, the problem is: what One True Format do we transform it into? Feed formats don’t seem to inspire quite as heated debates as, say, text editors (vi! emacs!) or operating systems (Linux, various flavours of BSD… let’s not even mention Microsoft), or even Linux package management systems (RPM, deb, portage, etc.). That said, choosing One True Format is certain to tick somebody off, no matter which is chosen.

So, why not sidestep that altogether, and turn all our feeds into YAML? Specifically, into YAML that is also valid JSON?

It could be that this is an idea that was contemplated by souls wiser than I, and already abandoned. Perhaps it’s not easily implemented. Maybe nobody’s interested.

So forget YAML for a moment (though the idea still appeals to me). Standardizing on a single feed type still makes sense. At the same time… I don’t think it’s likely in the near future.

Why?

  • Too many Very Large services have already chosen different formats and don’t seem likely to change. Blogger, IIRC, uses Atom. I believe Six Apart uses RDF, which would be RSS 1.0. Other services support multiple formats, or 2.0, or 0.91.
  • Supporting different formats is fairly low overhead. It takes a little time, but it’s not an extremely difficult prospect for a feed aggregator to add a parser for a different format. They’re all XML. Many features are in common. One person working alone could create parsers for all the various formats in comparatively short order.

In short… it’s just too easy to allow people to keep using their favorite format, and to just parse all of them if we’re building a feed reader. Nobody gets worked up about it, there is no Grand Debate or Holy Feed Crusade.

My own answer to the question asked in the headline? No, probably not. Not any time soon.

OpenID Is For the User, Not the Developer

Published
by
Phil Crissman
on October 14, 2007
in Code and www
. 5 Comments

I’m in the primordial stage of building a site which requires authentication, and I decided it was high time I dug into OpenID. At first I was thinking that this would be a way to avoid creating a native user authentication system — yay, less work, right?

Not necessarily. Not everyone will want to use OpenID; you don’t want to be turning away potential users who are confused or put off by an OpenID login. Conventional wisdom, therefore, is that you still have your own authentication system which people can sign up for, and not force people to understand/use OpenID.

As a developer then, you are suddenly faced with the prospect of implementing both your own user/password table and authentication, and allowing interested users to use their OpenID, if they elect to do so. Wait — we just went from less work to more work — why in the world would anyone want to do that?

The answer is simple, and, if you step out of your developer shoes, is obvious: the convenience of OpenID isn’t for you (the website developer) — it’s for your users.

No, using OpenID doesn’t make your web application simpler to design and code. But, for those users who are or will be using OpenID, it makes authentication a lot easier for them. That’s the idea.

And it’s a good idea (though Tim Bray had some interesting objections to OpenID… I’m not sure if these have been resolved since he wrote this).

For those who are using OpenID, allowing it on your site is basically a way of saying that you care about making their user experience more convenient. I find it hard to argue against that logic.

Displaying a Gmail ATOM Feed In Google Reader

Published
by
Phil Crissman
on October 5, 2007
in Code and GTD & Productivity
. Comments

So, not too long back, I thought I’d solve the “bacn” issue by having my notification emails automatically labelled “bacn” in Gmail, and then automatically archived. Trouble is, I’d then need to remember to check that label from time to time, so that I wouldn’t miss something I might actually want to know (ie, a Basecamp project has a new note, etc).

The obvious solution seemed to be an RSS feed; GMail does automatically supply feeds of all your mail, or of just one label; perfect!

It turns out, not so perfect. Because your email is, for obvious reasons, secure, getting at the feed requires authentication. Well, I’ve been using Google Reader (for so long that I really don’t want to bother switching), and Google Reader does not support authentication for feeds.

That’s right: Google’s RSS reader can’t read Gmail’s own feeds.

So, I finally got sick of reading my bacn label from time to time, and set up Magpie RSS in a directory on another server.
Continue reading ‘Displaying a Gmail ATOM Feed In Google Reader’