jrmehle.com

If you had asked me prior to this weekend if I’d planned to stay awake for 30 hours straight, I would have said, “No.” That’s exactly what I did for the F1 Web Challenge and the non-profit I worked with, Resource of the Americas. I was really impressed with the level of quality every site showed.

The Resource Center of the Americas is a non-governmental, 501 (c)(3) organization that informs, educates and organizes to promote human rights, economic justice, democratic participation, and cross cultural understanding in the context of globalization in the Americas.

Jason and Stephanie from the Resource Center joined our team for the challenge. They are the only two employees of the Resource Center and they used to have over 30. They once occupied an entire building of which now they only take up one room in the basement. I was more than happy to contribute to their new website.

The new and improved Resource Center of the Americas website

It goes without saying that time management is crucial. We fell into a pattern of regular little meetings. Everyone would give a synopsis of what they had worked on and what they were going to work on next. This worked fairly well. A lot of times other little pow-wows would break out too. It was fairly interesting just watching all the teams work. There wasn’t a whole lot of mingling and I think the final results from each team showed why. We pushed ourselves.

The Ruby.mn team was great. We spent the first 3-4 hours getting to know what Jason and Stephanie’s needs were and trying to prioritize them into things we could accomplish in 24 hours. Jason was formerly in IT, so he was familiar with things like HTML and SQL. It was immensely helpful to have another geek on the team. Stephanie was also a big help with testing and data entry.

From the word go, Nate and Kim buried their heads in a new design. Kim came up with the stylish new logo. I like that she kept the upside down globe. Nate spent most of the first half of the event putting together what you see above.

We developers had decided on Radiant CMS prior to the event and had explored a few extensions. It seemed most every nonprofit wanted some kind of blog or current events area, a calendar, a way to take donations online, and maybe a couple other specialized features. Our nonprofit holds Spanish classes and sells Spanish books. Something we didn’t expect to do was sell things. I think we came up with a solution that will work now for them and it’s something they can expand into in the future if they want to. It also happened to be the Paypal portion of the site that gave us the most pain. It momentarily took our two of our developers at about 4 in the morning.

This was the only sleep any of our 12 team members had and these guys were only down for about 15 minutes.

Listing of upcoming events were someting we identified as a priority. The Resource Center host’s a coffee hour once a week and also publicizes other community events. My role early on was bringing Flickr integration into Radiant so we could build an image gallery. In addition, they will be able to insert Flickr image into their new event listings. I ran into a bit of trouble when the first extension I chose to use simply refused to pull any images into Radiant. I gave up after a couple hours of manually executing json calls to Flickr. Luckily, I found another extension which used flickr_fu on the back end. It turns out Radiant has page caching built in, so the API hits to Flickr will be minimal.

By early evening, Nate had finished the homepage design and handed it over to me to slice and turn into HTML. He was pretty happy to have me do it as last year, I guess he was forced to do both the design and the HTML. I spent the next 5 hours between Photoshop, Firefox, Textmate, and Terminal. I barely looked up. This is where most of the time disappeared for me. I put on my headphones and just zoned in.

Heads down programming at f1webchallenge.com

I had the shell, header, and navigation done fairly quickly. The main body of the page got fairly complex especially since the backend was evolving as I worked. At about 2AM I had the sidebar area and the 3 content areas at the bottom all finished. After that, I was helping Nate integrate the sub-page templates he designed into the CMS. The tear across the middle of the page came together somewhere between 3-4AM. Andy Atkinson (@webandy), John Reilly (@johnreilly) and I attacked the drop-down menus for the navigation. We were able to come up with a CSS+JS solution that should work in all modern browsers. I was impressed with myself. John ran into some roadblocks with the CSS as I was doing some other work on the homepage and I miraculously was able to hack out the fixes in Firebug in about 10 minutes. The final hours of the challenge were spent mostly cleaning up CSS and styling pages as they were created.

The rest of our team worked on a translation to Spanish module so the whole site could be translated. The Donation system was hooked in and a store was created with integration with Paypal. We weren’t able to deliver a custom mailing list with user management to them because we simply did not have the time. It was a frantic dash at the end, but the team held together well. In the end, District 202, a haven for GLBT teens and their team Praxis won out. Dan Grigsby told me via twitter that the decision was tough, but with the features the winning site had, it would impact real lives the most. There was a private, real time, chat feature and a private Ning social network was integrated to give the members a safe place to hang out online. In the end, I think it was said 2,800 hours of service were put in amounting to roughly $300,000 of free professional quality work.

1 second left

Update: There is a group pool on Flickr containing a ton of photos from the event. My teammate Andy Atkinson also wrote a short synopsis of his experience.

Inspired by my fellow teammate, Justin Grammens, I’ve decided I should say a little about the F1 Web Challenge I am participating in tomorrow.

The F1 Web Challenge is a charity event where teams of developers and designers are paired with a nonprofit and are given 24 hours to build the nonprofit a website. The catch is that pairings aren’t announced before the start of the event and those 24 hours are consecutive. Crazy? Maybe. Fun? Definitely. Worth it? Absolutely.

Last spring I remember seeing some tweets about the event and I thought it was a really cool idea. Having worked for a nonprofit  myself at one point, I knew that they often lack the personnel, funds, and knowhow to pull off a great website themselves. So when the call went out on the local Ruby user’s mailing list, I jumped at the chance and found a spot on the Ruby.mn team.

I’ve been more than impressed with the people on my team. Within weeks of the team forming, we had 2 sponsors; Github and Tightrope Media Systems. Our sponsors really helped push our team up above the rest. With the funds donated by TRMS, we were able to purchase hosting for our team website, hosting for the nonprofit, and team t-shirts. Github provided us with a repository for our team website and the nonprofit. Thanks to Sam Schroeder for talking to Github and thanks to John Reilly for talking to his boss at TRMS.

I couldn’t let John and Sam be the only ones to step up for the team. I assumed the role of t-shirt designer even though I’d never done any t-shirt design before. With some help from one of last year’s team members and some feedback from the group, I was able to put a design together. I was happy with what I was able to come up with and I’m anxious to see how the finished product turned out. At the very least, we’ll look like a team!

It is my plan to tweet, live blog, and take photos throughout the day and night. I’m hoping to make a few posts here tomorrow. Follow me (@jrmehle) and @webchallenge on Twitter. Watch my Flickr stream for photos. FriendFeed aggregates all of the previously mentioned content sources, so that would be a place to watch too. Who knows, I may end up with Ustream account at some point to live-stream the event too. The festivities kick off at 9AM and will run through 9AM on Sunday.

In Part I of the Wysihat tutorial, I went through some simple examples of how to use Wysihat. This time around, I’m going to go through adding a button that prompts for an image URL and inserts the image into the editor. I’ll show how to use CSS to turn the links Wysihat produces into buttons. DecoyMusic launched version 1.1 in early January with a Wyishat-enabled WYSIWYG editor. I’ve encountered several problems which will close out the second half of this series.

As I mentioned in my first tutorial, there are several examples provided in the Wysihat repository. The ‘link selection’ example (found in the examples/ directory) shows you how to go about allowing the user to add links to a piece of selected text. The user first makes a selection, then hits the link button, and is prompted for the URL. The prompt is a standard Javascript prompt, but the code to send the user value back to the editor is up to us. Wysihat doesn’t provide this out of the box. Take a look at that example again. Here is the meat of it.

    var LinkSelection = {
      promptLinkSelection: function() {
        var node = this.selection.getNode();
        if (node.tagName == 'A') {
          if (confirm("Remove link?"))
            this.execCommand('unlink');
        } else {
          var value = prompt("Enter a URL", "http://www.google.com/");
          if (value)
            this.linkSelection(value);
        }
      },
 
      queryLink: function() {
        var node = this.selection.getNode();
        return node ? node.tagName == 'A' : false;
      }
    }
 
    Event.observe(window, 'load', function() {
      var editor = WysiHat.Editor.attach('content');
      var toolbar = new WysiHat.Toolbar(editor);
 
      Object.extend(editor, LinkSelection);
 
      toolbar.addButton(
        { name: 'link', label: "Link" }, function(editor) {
          editor.promptLinkSelection();
      });
    });

We’re using the pseudo-object-oriented nature of Javascript to cram some functionality into LinkSelection which we later on give to an editor through extension. Examine PromptLinkSelection. Ignoring some of the other stuff that is going on there. What it is doing for us is prompting for a value from the user, and then passing it to the linkSelection function of the editor. The rest of the code should look familiar if you read Part I. It sets up the button and adds it to the toolbar. The one exotic looking line is where the prompt function gets added to the editor. All this does is make it trivial to call the PromptLinkSelection function  from a button event further down.

Realize that there’s not much difference between creating a <a> tag on a page and creating an <img> tag. They both minimally take a URL and that’s it. We’ve just gone over how to add a button that prompts for a link. Thus, it’s not too much of a stretch to figure out how to make a button to insert an image. Why not just add the function to LinkSelection? The reasons are clear. I won’t go over it here, but there is bound to be some common code between these two very similar tasks that could be factored out. It’s also helpful to know that Wysihat provides us with an insertImage function.

    var LinkSelection = {
      promptImageURLSelection: function() {
        var node = this.selection.getNode();
        if (node.tagName == 'A') {
          if (confirm("Remove link?"))
            this.execCommand('unlink');
        } else {
          var value = prompt("Enter a URL", "http://www.example.com/images/my_image.png");
          if (value)
            this.insertImage(value);
        }
      }
  }

I’ve removed the irrelevant parts here. When you boil it down, the only difference between this and the link selection example is you call insertImage instead of linkSelection. You can use this idea to further extend the editor to your needs. One thing I intend to do eventually is create an embed media button like the blogging engine Wordpress has.

In my introduction to Wysihat, I showed off the basic editor. At that time, I mentioned it is possible to style the links as buttons and I would show you how later. Now is that time!

Basic Wysihat Form

<div class="editor_toolbar clearfix">
  <a class="button bold" href="#"><span>Bold</span></a>
  <a class="button underline" href="#"><span>Underline</span></a>
  <a class="button italics" href="#"><span>Italic</span></a>
</div>

Take a look at the HTML that is generated for the toolbar. Not surprisingly, the toolbar is a div and has a class of editor_toolbar. Each button has 2 classes: button and it’s name. This allows you to target all buttons with the same style or each button individually.

DecoyMusic.com WYSIWYG Editor

The above screenshot is taken from DecoyMusic.com. This is an example of what you can put together with some CSS. That is the exact same markup as I went over. Let’s take a look at the corresponding CSS. I’m only showing the relevant parts for the editor. I’ll let you explore the clearfix technique as well as how I’ve styled the rest of the page on your own. There would also be a style for each button, but here I’ve only shown bold.

.editor_toolbar {
  background-color:#CCCCCC;
  border-left:1px solid #333333;
  border-right:1px solid #6D6D6D;
  border-top:1px solid #6D6D6D;
  margin-right:1px;
  padding:0.3em;
}
 
.editor_toolbar .button {
 height:16px;
 width:16px;
 overflow:hidden;
 text-indent:-100em;
 cursor:pointer;
 float:left;
 margin-right:0.3em;
 vertical-align:bottom;
}
 
.editor_toolbar .button.bold {
  background:#CCCCCC url(/images/icons/bold.gif) no-repeat scroll 0 0;
}

The toolbar itself is basically a solid block with a background color and a border. I’ve given the bottom and right borders a different color from the other sides so that the editor has a little bit of dimension to it. The next style is where most of the magic happens. The width and height are first set. I’ve used 16 by 16 pixel buttons, so I set mine to 16.

The next two rules are key. They shove the link text that Wysihat inserts by default. You can’t control the contents of the links as they are spit out by Wysihat. A CSS trick to hide text like this is to shove it way off the screen. It’s still in the document, but the stylesheet pushes it so far off the screen, you wouldn’t even see it large resolutions. So, set your overflow to hidden and your text-indent to some very large negative number of ems. The rest of the rules simply add a few nice things like spacing out the buttons and giving us a pointer finger cursor when we hover over the buttons. The final piece is to style each button itself. This is where you specify the button image you want to use. It is actually a background image, but combined with all of the other CSS it behaves as a button.

Keep in mind this is only one way of styling your WYSIWYG buttons. You could also leave the text in place and add some kind of background to give the impression of a button. There are also ways of giving the button hover states which provide feedback for your users.

Wysihat is a somewhat immature project (at release 0.2 at the time of writing). As with early adoption of anything there will be some bugs to deal with. Not to say that it is buggy. The project will mature and gain support; it will get better. You can contribute if you’re a javascript developer. I have no doubts by the time it hits 1.0, 37 Signals and the community will have come up with a fine tool. However, the people that use my site have reported some issues. After initially being loaded, the editor is “locked” and will not allow you to delete text. This is apparently only an issue in Firefox 3. If you first add something, even a space, it’s refreshes itself or something and you can use delete. Do not paste any content copied from a Word document and expect it to look anything like what you copied. It won’t and it’s futile to try to correct it within the editor. I also have one person reporting that the editor hangs and stalls when he is editing a large article. I myself witnessed this on a large piece of content containing several images.

Do I have you thoroughly confused with the title yet? I’ve neglected the blog here since October and that’s mostly because I talk about my day-to-day adventures on Twitter. Something I have decided to do is write some posts that are more technical. I’ve probably learned more about Rails via blogs than I have from any Rails books I read. The topic I’ve chosen for today’s post is something I couldn’t find much material on myself. I hope it helps someone.

First, let’s get something out of the way. WYSIWYG stands for “What you see is what you get.” It’s surprising how often people don’t know what that means. Given that this is supposed to be a “technical” blog post I won’t go into detail about what a WYSIWYG editor is. Let’s assume you know what it is, you’ve tried TinyMCE, FCK-Editor, or others. Let’s also assume you’ve gone through considerable pain attempting to integrate these editors into your site, or styling these editors for your site. It never quite works out right. The editor doesn’t work right when used with AJAX, or the interface and buttons are completely foreign to your layout and design. Sometimes these things can be fixed, but it usually involves a lot of hacking. Leave it to the guys at 37Signals to make it all better.

Wysihat was introduced in October 2008 by Jason Fried on the 37Signals blog, Signal vs. Noise.

WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it.

Normally, I would read that with a skeptical eye, but given that this is 37 Signals, there might actually be something to Wysihat. Wysihat is open source and, hosted on Github. It’s also small. Wysihat weighs in at 20k uncompressed, and a mere 4.8k when delivered gzipped through my Apache server. To be fair, this minuscule size is due to Wysihat’s dependence on Prototype. I’m a Rails developer and Rails defaults to Prototype, so I’m OK with that. It is worth noting that you will need to make sure wysihat.js loads after prototype.js or this won’t work.

Note: If you clone the repository on Github, you’ll quickly notice there is no wysihat.js file anywhere to be found. All you need to do is switch into the directory where you cloned the wysihat repository and run the ‘rake’ command without any arguments. It will build the Javascript in dist/. Of course this is also in the README, but you were so excited to get started you forgot to read that, right?

After all that praise you’d think that all you have to do is add Wysihat source to your page and your forms are suddenly improved with editor goodness. Not quite. Wysihat is intended to be used as unobtrusive Javascript that decorates the text fields of your choice. You have you write the part that initializes the editor and sets up the toolbar with the buttons you need.

Event.observe(window, 'load', function() {
  var editor = WysiHat.Editor.attach('content');
  new WysiHat.Toolbar(editor, {buttonSet: WysiHat.Toolbar.ButtonSets.Basic});
});

In the four lines of Javascript above, The first line simply makes sure the page DOM is set before we do anything like adding an editor to it. Then, we have to initialize the editor. All you have to do is pass in the ID of the text area you want to add the editor to. Here it is saved to a variable so we can then add the default toolbar (bold, italics, underline) to the editor. Without that line, we’d get an editor without buttons. That’s it! However, for your four lines of code, you only get a basic looking editor.

Event.observe(window, 'load', function() {
      var editor = WysiHat.Editor.attach('content');
      var toolbar = new WysiHat.Toolbar(editor);
 
      toolbar.addButton(
        { name: 'bold', label: "Bold" }, function(editor) {
        editor.boldSelection();
      });
 
      toolbar.addButton(
        { name: 'underline', label: "Underline" }, function(editor) {
        editor.underlineSelection();
      });
 
      toolbar.addButton(
        { name: 'italic', label: "Italic" }, function(editor) {
        editor.italicSelection();
      });
});

The above code looks more complex, but it really is not. Again we wait for the DOM to be set, and initialize our editor. Instead of using Wysihat’s basic toolbar, we want to customize our own. Only the editor is passed in to the toolbar init line, leaving us add the buttons.

We use addButton and passing a Hash with the name and label. The name will become a CSS class on the link that gets inserted and the label is the link text. The final argument for addButton is a function inside of which we call another editor method boldSelection(). This does what you would expect and bolds some selected text in the editor.

The underline and italics buttons can be done the same way and there are also existing methods making selected text underlined or italics too. If you take a peek at the Wysihat source around line 65 you’ll see WysiHat.Commands. Below that are all the functions the editor can call for doing other common tasks such as creating lists, links, images, etc.

With what I’ve covered so far, you should be able to add an editor to a page and add any number of buttons using the built-in Wysihat editor functions. All of the code I’ve shown is taken from the examples directory of the project (this is also stated in the README). In Part II of this post, I will show how to write your own custom button functions and how to make the editor not look so boring by adding some simple CSS. Finally, I’ll finish up with some of the problems and pitfalls I’ve found so far using Wysihat in one of my projects.

Update: Part II has been posted!

In my final semester at St. John’s, I was required to take up a research project, give a presentation on the topic, and then write a lengthy paper. Naturally, the topic was also required to be from the field of Computer Science. I knew right away that I wanted to do something with Linux. Through some guidance from my professor, I came to the topic of Free and Open Source Software. One of the first important people I came across in my research was Richard Stallman. So when I discovered a few weeks ago that Stallman was giving a talk at the University of Minnesota, I made sure my calendar was free.

After wandering around the U of M campus for the first time, I managed to find my way to Wiley Hall Room 175 just in time. Stallman took the stage moments later and began what would amount to 2 straight hours of speaking, evangelism, and laughs.

If you aren’t familiar with who Stallman is, well, I’m not surprised. Have you ever heard of the term ‘hacker?’ Stallman was one of the first. Ever heard of GNU, Linux, or Emacs? He either made them himself, or made them possible. If you’re still lost, then maybe you should stop reading here.

RMS began by explaining the four freedoms of free software.

• Freedom 0: The freedom to use software as you wish
• Freedom 1: The freedom to view the source code and modify it as you wish
• Freedom 2: The freedom to distribute copies of the software to others
• Freedom 3: The freedom to make improvements to the program and distribute those modifications to others

These four freedoms all must be true in order to call a piece of software ‘free.’ From there things really went everywhere.  There was much badmouthing of proprietary software and all the problems and hassles it brings. Stallman’s primary message was to refuse to use proprietary software, evangelise free software, and the computing world will become a much better place. Oh and there were a few jabs at the US government, Microsoft, large corporations that I’ll admit I laughed at.

RMS was also endlessly quotable:

“Ms. Clinton… probably mentions freedom more often than I do, but says much less about the substance of it.”

“If you see someone drowning, and there’s no one else around, and it’s not Bush, you have an obligation to save that person.”

“I am St Ignucius of the Church of Emacs.”

“Vi vi vi is the ‘Editor of the Beast’, but using a free implementation of vi is not a sin, it’s a penance.”

I can’t completely agree with Stallman though. It’s tough because I have a lot of respect for the man for what he’s accomplished and the views we share. Free software is great and so is the idea that we all should share and help each other out. However, that view is unrealistic. I think proprietary software has its place in the world too. And the world certainly isn’t as amiable and agreeable as Stallman would like it to be. I’m not about to give up my DVD movies, my Macbook Pro, or playing Warhammer Online, all of which are, run, or use proprietary software.

Most people probably don’t think about the freedoms they give when running proprietary software, but at the same time I think if they did, most would make the same choice. Because of that, Stallman’s vision of a utopia for free software will never exist. Nonetheless, I encourage Stallman and the Free Software Foundation to continue their work. He is exactly the kind of person you want to lead a movement. He’s pure, uncorruptable, and unflinchingly loyal. He’s made it his life’s purpose to bring his vision to reality. If only some of our politicians and world leaders had the same passion and outlook.

One of my favorite Rails sites is Railscasts.com. They’re running a contest right now and below is my entry. They said I didn’t have to mention them, but I like them, so there you go. Now for some Rails tips.

Instead of hacking plugin code directly use the evil twin method.

Nesting resources more than 1 level deep can cause headaches.

Test methods must start with “test”, but making them start with “test_should” is even better.

If your tests are failing for what seems like no good reason, drop your test database and recreate it.

Hyper-sensitive about security? Stop putting your production password in your database.yml file. Instead generate the file during deployment.