Dec 8 2009

github and submodule weirdness

So I’m not a git or github master by any means. For the most part, I know enough commands to get by and to get myself into trouble every now and then. My experience so far has been good with git and github, but today I ended up banging my head on a wall while I tried to figure out what was going on. Follow me, on this little trip down a rabbit hole. Maybe someone can explain what’s going on here.

First I generate a rails app:

lappy:tmp bsmith$ rails foo

Then I add restful authentication, using the command listed in the install documentation:

lappy:tmp bsmith$ cd foo/
lappy:foo bsmith$ cd vendor/plugins/
lappy:plugins bsmith$ git clone git://github.com/technoweenie/restful-authentication.git restful_authentication
Initialized empty Git repository in /Users/bsmith/tmp/foo/vendor/plugins/restful_authentication/.git/
remote: Counting objects: 1741, done.
remote: Compressing objects: 100% (590/590), done.
remote: Total 1741 (delta 1010), reused 1641 (delta 957)
Receiving objects: 100% (1741/1741), 733.93 KiB | 831 KiB/s, done.
Resolving deltas: 100% (1010/1010), done.

Then I add everything to git:

lappy:plugins bsmith$ cd ../..
lappy:foo bsmith$ git init
Initialized empty Git repository in /Users/bsmith/tmp/foo/.git/
lappy:foo bsmith$ git add .
lappy:foo bsmith$ git commit -m ‘init’
[master (root-commit) f63c7ea] init
43 files changed, 8462 insertions(+), 0 deletions(-)
create mode 100644 README
create mode 100644 Rakefile
…[followed by lots more output]

Then I pushed it to github:

lappy:foo bsmith$ git remote add github git@github.com:benjaminleesmith/submodule_test.git
lappy:foo bsmith$ git push github master
Counting objects: 64, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (56/56), done.
Writing objects: 100% (64/64), 79.32 KiB, done.
Total 64 (delta 10), reused 0 (delta 0)
To git@github.com:benjaminleesmith/submodule_test.git
* [new branch] master -> master

Next, I take a look at the vendor directory that got committed go github:

From screen shots

I assume that the little folder icon with an arrow means that the restful authentication code is being hosted elsewhere… as a submodule maybe? The folder is not clickable, so I can’t see what’s inside… if there’s anything!

So my next step is to pull the project, say for a deployment on another system:

lappy:tmp bsmith$ mkdir bar
lappy:tmp bsmith$ cd bar/
lappy:bar bsmith$ git init
Initialized empty Git repository in /Users/bsmith/tmp/bar/.git/
lappy:bar bsmith$ git pull git://github.com/benjaminleesmith/submodule_test.git
remote: Counting objects: 64, done.
remote: Compressing objects: 100% (56/56), done.
remote: Total 64 (delta 10), reused 0 (delta 0)
Unpacking objects: 100% (64/64), done.
From git://github.com/benjaminleesmith/submodule_test
* branch HEAD -> FETCH_HEAD

Then… I go searching for restful auth in this latest pull…

lappy:bar bsmith$ cd vendor/plugins/
lappy:plugins bsmith$ ls
restful_authentication
lappy:plugins bsmith$ cd restful_authentication/
lappy:restful_authentication bsmith$ ls
lappy:restful_authentication bsmith$

Yikes! The directory is there, but the contents are missing! I don’t know if this is a problem with the way I added restful auth to my local git repo, or if this is an issue with github. I noticed this when a production deployment was failing saying “uninitialized constant User::Authentication (NameError)” as if restful auth was no where to be found.

It seems less than intuitive to say the least. If anyone knows what’s going on here, leave me a comment please! Otherwise, my fix was to clone restful auth, then remove its git directory. This allowed me to push to github exactly what my local copy contained.


Oct 21 2009

flickr gadget for google wave

So I got an invite to Google Wave last week. It was pretty fun to play around with the latest and greatest toy from google, but the novelty quickly wore off. After everyone realized they were using it like a chatroom + wiki, I think we all got bored. When I was first invited, everyone was adding and editing waves… now no one I know is still using it.

ANYWAYS… during the first few hours of being excited about Google Wave, I decided to write a “Gadget” which would embed a Flickr user’s latest images into a Wave. It was super easy to write. Gadgets are basically JavaScript and HTML wrapped in some XML. So whipping up a Rails app that fetched Flickr images via the Flickr API and rendered some HTML to display them was cake. I deployed the Rails app/Gadget to heroku… check it out here: http://flickr-wave.heroku.com/

There seems to be some bugs, for some reason after embedding the Gadget and reloading the wave SOMETIMES it won’t load the Gadget. I don’t know why… and I probably won’t worry about fixing it unless I start getting excited about Google Wave again. Ohh well, check out the source here: http://github.com/benjaminleesmith/Flickr-Wave


Oct 21 2008

adding blackbird javascript logging to your rails project

Blackbird is a nifty JavaScript logger that can be added to any web app. Ever find yourself adding alerts into your JavaScript to get some (foggy) idea of what’s going on? Blackbird makes this kind of debugging much easier.

So how do you get Blackbird working in your Rails app? By following these easy steps:

1. Download the Blackbird zip file.
2. Extract contents of zip file.
3. Copy blackbird.css into public/stylesheets
4. Copy blackbird.js into public/javascripts
5. Copy blackbird_panel.png and blackbird_icon.png to public/images
6. Edit blackbird.css, modify urls to blackbird_panel.png and blackbird_icon.png to contain “/images/” in their path; “url(blackbird_panel.png)” should become “url(/images/blackbird_panel.png)”
7. Include the blackbird Javascript and CSS files in your layout: <%= stylesheet_link_tag 'blackbird' %> and <%= javascript_include_tag 'blackbird' %>
8. Add a button to open the Blackbird console: <input type=”button” onclick=”javascript:log.toggle();” value=”show log”/>
9. ???
10. Profit!
11. Check out the Blackbird website to learn more about using Blackbird.


Sep 14 2007

rails: building urls to static html in public dir

In rails when you create links in your view it’s best to use link_to or url_for tags when creating urls. However, both of these methods take as arguments the controller and/or action to generate a link for. If you’re trying to link to something in the public directory, like a static html file, then there is no controller or action. Instead of hardcoding the link, use compute_public_path:

<%=compute_public_path('file-name-without-extention','parent-dir','extension')%>

So if you’re trying to link to a file public/static_files/foo.html just do:

<%=compute_public_path('foo','static_files','html')%>


Aug 17 2007

getting thickbox, jquery, and prototype to play together nicely

The latest version of the JumpBox admin interface uses ThickBox for its cool visual effects, and prototype for handling AJAX requests. The problem is that ThickBox depends on jQuery, and jQuery and prototype don’t like working together.

Both jQuery and prototype define “$” as an alias in the global namespace. When you try to use the “$” shortcut and both libraries are included, the browser complains. Lucky jQuery gives you a way to override “$” and let prototype use it thus resolving the conflict:

 <html>
 <head>
   <script src="prototype.js"></script>
   <script src="jquery.js"></script>
   <script>
     jQuery.noConflict();
   </script>
 </head>
 <body>
 </html>

After calling jQuery.noConflict(), you can still use jQuery “$” functionality, but you have to call it using “jQuery(‘foo’)” instead of “$(‘foo’)”.

Now that jQuery and prototype can coexists peacefully, how does ThickBox work? Well… out of the box it doesn’t. ThickBox uses the “$” syntax, but expects to use jQuery’s implementation of it. So to get ThickBox to work, you need to replace all instances of “$” with “jQuery” in thickbox.js. Now ThickBox should be using jQuery exclusively, jQuery and prototype won’t conflict over “$”, and everything should work fine and dandy. Note: I’ve only tried this using ThickBox 2.1.1, jQuery 1.1.1, and prototype 1.5.0, but it should work on the latest and greatest versions.


Jun 8 2007

rails: multiple request values with the same name

Let’s say you have a web app that takes input from the user. How about a phone book app for storing phone numbers. And let’s assume that each person in your phone book can have an unlimited number of phone numbers. In the interface you allow the user to fill in as many phone numbers as they’d like by dynamically creating more and more input=’text’ elements. When the user saves, the data that gets posted to the server looks something like:

/phonebook/save?number=5203842233&number=6029130923&number=9283125248

Basically there are multiple parameters that have the same name with different values. Now in Java to get the values of the numbers you would do something like…

request.getParameterList('number');

…to get an Array of Strings, each element containing one of the numbers (NOTE: my Java is rusty and this could be wrong). In rails there is no such getParameterList method. As I currently understand it, rails only sees the first number. So it thinks that number=5203842233 was the only value passed to the server, the other values are ignored. Looking at rail’s logs confirms this:

Parameters: {"controller"=>"phonebook", "action"=>"save", "number"=>"5203842233"}

So how do you get multiple values with the same name out of the request? You add ‘[]‘ to the parameter name (ie <input type=”text” name=”number[]“/>):

/phonebook/save?number[]=5203842233&number[]=6029130923&number[]=9283125248

Now looking at the log file:

Parameters: {"controller"=>"phonebook", "action"=>"save", "number"=>["5203842233","6029130923","9283125248"]}

When retrieving params[:number], you’ll end up with an Array of the numbers instead of just the first.


Jun 7 2007

rails: getting ip address from request

This is useful if you want to log the ip address of the person using your rails app (except when the person is behind a proxy, thanks James!):

request.env['REMOTE_ADDR']

Taken from this ruby thread.


Oct 26 2006

desert code camp

The second Desert Code Camp is coming up this weekend.

“Code Camp is a free, one-day event put on by the local Phoenix community to help promote software development in general. There is no right or wrong language, platform, or technology. If a topic relates in any way to the code that causes a machine to produce a desired result, it’s welcome here.”

The previous code camp was ok, but the sessions were too jammed together. There was no time to meet people and just talk. Everyone kept running from session to session trying to keep up. Some of the sessions were good, while others were a waste of my time.

I’ll be attending again, hopefully they’ve tweaked the schedule enough so it’s no so jam-packed. There aren’t any sessions that are must-attends for me, so I’ll mostly be there to hang out and support the community. If nothing else, at least it’s a free lunch.

Edit: Apparently lunch isn’t free.


Jun 28 2006

missing gems/plugins

The designer of a project I’m working on decided to use the RedCloth ruby gem in the project we’re working on. He installed the gem on his local machine and added “require ‘RedCloth’” to environment.rb. Now, since he installed a gem and ruby gems by default are stored in the ruby installation directory, the source repository did not contain the RedCloth library.

Unforunately I forgot to get the RedCloth gem. So when I updated my project source from SVN the project broke output in development.log. I eventually figured out that I was missing the gem. So I downloaded the gem, then moved the whole RedCloth folder into the vendor/plugins directory of the rails project.

The lack of error messages pointing me to the “require ‘RedCloth’” was annoying to say the least. Maybe the require statement should be moved someplace else? Someplace after the logger has been initialized maybe? I wonder if other error/issues in enviroment.rb will make WEBrick die out too. Maybe you can start WEBrick with some advanced debugging for these kinds of situations? Hmm, I guess I should do a little research…