Next up: Stop messing around with GreaseMonkey and learn how to write Safari Extensions.

It turns out to be fairly simple, because you just have to split your userscript into two parts: The first one is the userscript that the user adds to his browser and which just loads the second part, namely a javascript file that gets integrated into the webpage and which contains the real functionality.

myapp.user.js

This is the userscript that you offer to download/add to the browser: It just integrates the real userscript from the server, so that the users do not have to update their userscripts and it also disables the userscript functionality in case your server is not available. The latter can be seen as a bug or a feature (depends on your use case), but for codeshelver.com this is a feature, because if the server is down you are not able to shelve repositories anyway

(function() {
  //
  var script = document.createElement('script');
  script.src = 'http://myapp.com/userscript.js';
  script.type = 'text/javascript';
  document.getElementsByTagName('head')[0].appendChild(script);
})();

userscript.js

Here goes the real functionality

var Userscript = {
  init: function() {
    alert("Hello :)");
  }
};
Userscript.init();

As I said this is pretty straight forward, so go ahead and enhance the web!

I had the idea for this project on my mind for some time, but didn’t get around to realizing it because I lacked the motivation to build it with the common stack of technologies. A few weeks ago I started to play with NodeJS and tried to come up with something that was beyond the Hello World examples so I stumbled upon ExpressJS, which could be described as the Sinatra of NodeJS. And so I had my use case for trying out some new technologies to which I also added GreaseMonkey and CouchDB to make it more buzzwordy.

All in all it was fairly easy to develop the app as I just had to knit some good libraries together like express, node-couchdb and nodejs-autorestart which I’m currently using to make the deployment a little easier. Talking about deployment: I had some problems figuring out how to do it the best way, everyone seems to be using Ubuntu’s Upstart and Monit for deploying NodeJS apps. I’d prefer a more generic solution, but I haven’t found a really satisfying way yet, so I’m just killing and restarting the processes.

There are some features in the pipeline that I’d like to add once some more people are using the service and I gather more data, which would offer the possibility to evaluate things like trending and interesting repositories. Now that ExpressJS 1.0 is around the corner I’ll migrate the app and will most likely use CoffeeScript for that, because it looks very promising and easy to integrate – it will also give me one more buzzword up my sleeve

Please go ahead and try Codeshelver, let me know what you think and leave comments and feedback here!

UPDATE: Here is a gist that looks like there is a more hassle-free way to do the installation, please try it first and see the rest of this tutorial as a reference point if the gist does not work out for you.

I usually keep my source installs at /usr/local/src/, your milage may vary, adjust the steps accordingly.

Installing the dependencies

First of we got to install the dependencies for Erland and CouchDB:

$ sudo apt-get install -y automake autoconf libtool help2man
$ sudo apt-get install -y build-essential erlang libicu-dev
$ sudo apt-get install -y libmozjs-dev libcurl4-openssl-dev
$ sudo apt-get install -y openssl libssl-dev

Installing Erlang

Download and unpack the current Erlang version, in my case it’s R14A:

$ cd /usr/local/src
$ wget http://www.erlang.org/download/otp_src_R14A.tar.gz
$ tar xzf otp_src_R14A.tar.gz
$ cd otp_src_R14A

Maybe you would like to see the config options and need to checkout which openssl should be used:

$ ./configure -h
$ which openssl
/usr/bin/openssl
$ ./configure --with-ssl=/usr/include/openssl/
$ make
$ sudo make install

Once you installed Erlang, check whether its cryptography library (OpenSSL) are functioning correctly.

$ erl
Erlang R14A (erts-5.8) …
 
Eshell V5.8  (abort with ^G)
1> crypto:start().
ok
2> q().
ok

Installing CouchDB

Download and unpack the current CouchDB version, in my case it’s 1.0:

$ cd /usr/local/src
$ wget http://apache.linux-mirror.org/couchdb/1.0.0/apache-couchdb-1.0.0.tar.gz
$ tar xzf apache-couchdb-1.0.0.tar.gz
$ cd apache-couchdb-1.0.0

Here you might like to see the config options to and export some of the variables:

$ ./configure -h
$ export ERL=/usr/local/bin/erl
$ export ERLC=/usr/local/bin/erlc
$ ./configure --with-erlang=/usr/local/lib/erlang/usr/include/ 
$ make
$ sudo make install

For security reasons it makes sense to have a separate couchdb user that runs the process, go ahead and create it:

$ sudo adduser --system \
        --home /usr/local/var/lib/couchdb --no-create-home \
        --shell /bin/bash \
        --group --gecos "CouchDB" couchdb

You will also have to give this user access to some directories:

$ sudo chown -R couchdb:couchdb /usr/local/etc/couchdb
$ sudo chown -R couchdb:couchdb /usr/local/var/lib/couchdb
$ sudo chown -R couchdb:couchdb /usr/local/var/log/couchdb
$ sudo chown -R couchdb:couchdb /usr/local/var/run/couchdb

… and change the permissions for the directories:

$ chmod -R 0770 /usr/local/etc/couchdb
$ chmod -R 0770 /usr/local/var/lib/couchdb
$ chmod -R 0770 /usr/local/var/log/couchdb
$ chmod -R 0770 /usr/local/var/run/couchdb

After that, verify that it finally works:

$ couchdb
Apache CouchDB is running as process …, time to relax.
$ curl -X GET http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"1.0.0"}
$ /usr/local/etc/init.d/couchdb start
 * Starting database server couchdb
   ...done.

Caveats

If CouchDB does not work and it does not write into the log it is likely a permission problem, see if the couchdb directories belong to the couchdb user and that the permissions are set correctly.

Another thing that occured to me was an error that resulted from still having leftovers from previous installations at /usr/lib/couchdb/erlang/lib. Older version, especially of mochiweb-r97 or couchdb can lead to “Bad Request” errors, so clean up the erlang lib directory.

After spending the first months completely involved in some iPhone projects and consulting and not doing anything web development related I decided to not take on new iPhone/iPad client projects. There are some reasons for that – first and foremost: Right now the web and mobile market are moving really fast and I just can’t (and don’t want to) find the time to stay up to date with both worlds (it’s appeasing that I’m not the only one who thinks like that ) There is so much exciting stuff happening in the Rails, JavaScript and HTML5 realm that I don’t want to miss and I really missed working in teams, because most of the iPhone gigs were just me on the development side. Another point is that I don’t like the lock in way Apple seems to be pursuing, but this is more of a personal issue. I’d really like to get the personal impression from those of you who are also doing iOS development, maybe it’s just me but I talked to some people who seamed to have similar opinions.

So what happened after making this decision? Something that seems logical looking at it retrospectively: I joined the guys over at Railslove and worked with them on a World Cup prediction game (I’m sorry but I just don’t know how to translate “Tippspiel” – btw: why not join the Coworking Cup? Invitation token is “weworkunited”). We had a very productive time and lots of fun together so we concluded it might be a good idea to work on some more projects and this assumption did not fail to deliver. We are working on some pretty exciting projects and if you are interested in joining Railslove just contact them.

Okay, that’s the past and the present – what about the future? I don’t know, but if it turns out to be as exciting, informative and funny as the first six month it will be awesome! Two weeks ago I’ve been at the RailsWayCon (you might want to read Jan’s recap) and met a lot of the nice folks from the European Ruby/Rails Community. I’m also really looking forward for some more conferences and events this year, like RailsCamp, JSConf EU and RailsRumble to name a few – I hope we’ll see each other there!

Wir schreiben heute Tag 4 nach Livegang im App Store und der Disser hat sich bis ganz nach oben an Position 1 der meistverkauften Apps in Deutschland gepöbelt. Der helle Wahnsinn, vor allem weil es so schnell ging – was aber wiederum der sehr Marketingarbeit der zwei Jungs aus Köln zu verdanken ist: Rund um den Disser wurde vor dem Livegang ein umfassendes Gesamtpaket inklusive Website, Projektblog, Facebook Fan-Page, Marketing-Video und Pressematerial geschnürt, so dass die App nicht nur auf dem iPhone stattfindet. Schnell trudelten die ersten sehr guten Rezensionen und Video-Reviews ein: So schreibt beispielsweise iPhone-Junkie Carsten Scheibe im Stern.de Blog: “Der Disser ist eine überaus professionell umgesetzte Fun-App, die auf jedes iPhone und auf jeden iPod touch gehört.”

Auch das Feedback der Nutzer im App Store und auf der Website sind super: Viele wollen den Wortschatz des Dissers erweitert sehen und schlagen selbst neue Wörter vor, so dass sich ein sehr kuriose und amüsante Liste von Vorschlägen ansammelt, die wir möglichst schnell mit einem neuen Update herausgeben werden. Wir sind gespannt auf die nächsten Tage, freuen uns über weitere Reviews und Vorschläge und bedanken uns bei allen Nutzern für’s Herunterladen der App – sowas macht echt Spaß!

gem "mongo_mapper", :git => 'http://github.com/merbjedi/mongomapper.git', :branch => 'rails3'

And while you are at it, add this line to include some handy generators for Rails 3, including one for MongoMapper models:

gem "rails3-generators"

To use the generator set the orm config in your config/application.rb to :mongomapper

config.generators do |g|
      g.orm :mongomapper
      …
end

… and you are good to go!

btw: If you are like me and you prefer to have some kind of GUI for quick database lookups, check out MongoHub. It is in a very early stage of development, but at least you get to see your databases and documents.

Besonderer Wert wurde auf eine intuitive Benutzung der Anwendung gelegt. Um dies zu erreichen wurde auf die aus dem allgemeinen iPhone-Kontext bekannte Gesten und Aktionen (bspw. Pinch/Zoom, Drag and Drop, Scrolling, etc. ) zurückgegriffen und einfache Interaktionsmuster benutzt. Es gibt bereits Erweiterungspläne für kommende Versionen: So ist insbesondere eine iPad-Variante angedacht, da die größere Bildschirmfläche natürlich mehr Platz für eine komfortable und detailreiche Planung bietet. Noch etwas zum technischen Hintergrund: Das Projekt wurde mit Xcode und CocoaTouch-Standardtechnologien wie UIKit, CoreGraphics und CoreAnimation innerhalb von vier Wochen realisiert und hatte insgesamt einen Arbeitsaufwand von ca. 40 Stunden. Weitere Projektdetails und Informationen plane ich in naher Zukunft in einer kurzen Fallstudie zu veröffentlichen.

Alright, so where am I heading? A new focus will be iPhone/Cocoa app development and I’ll keep on working with Ruby on Rails – I’m really looking forward to all the great enhancements planned for Rails 3.0 and I just love doing web development, so that I won’t burn all the bridges

The bootstrapping went pretty well so far, I joined a really nice coworking environment and got an office at the infamous Abfertigung. As far as I can tell I’ll be surrounded by a bunch of very nice, creative and innovative people. Furthermore it’s good to know that I can, but don’t have to work from home – that makes meeting clients and finding quiet hours to get work done (I’m lookin’ atcha, Lotta) a lot easier

Hopefully I’ll find the time during the next weeks to write about some of the aspects of becoming a freelancer as I know some of you are interested in that and I’d like to take you along on that journey. I think it will be a pretty interesting time and I’ll learn tons about myself, meet nice and interesting people (including clients ) and most important of all: still have the time to enjoy my family… we shall see

In this little tutorial I’ll explain how to sync the data with Dropbox and I’m using Socialite as an example. It basically works like this for any app that stores its data in an Application Support folder, but Socialite requires some extra steps people are frequently asking about, so here we go:

1. Go to your Dropbox folder and create a new folder called Synced Application Support (or whatever you like)
2. Quit any running instance of the application you would like to sync (in this case Socialite).
3. Got to your ~/Library/Application Support and move the Socialite folder into the Dropbox folder you just created (Synced Application Support)
4. Open your Terminal.app and symlink the moved folder:
   $ ln -s ~/Dropbox/Synced\ Application\ Support/Socialite/ ~/Library/Application\ Support/Socialite
5. Start the app and see if it worked

After this five steps you should be up and running with most of your apps (syncing Things is as easy as that). Unfortunately Socialite requires some extra steps if you are using Twitter (and who isn’t these days), because it keeps the OAuth authentication tokens in the keychain, so that you need to sync them too. Fortunately this isn’t a big deal, because now you know how to sync your data, so go ahead and…

1. Quit Socialite
2. Open your Keychain and create a new keychain called Socialite and save it within your Synced Application Support/Socialite folder
3. Right click the new Socialite keychain, edit the settings and uncheck the checkboxes so that you won’t be bothered with authentication request every now and then
4. Use the search bar at the upper right corner to search for twitter.com and move all items used by Socialite to the new Socialite keychain
5. Start Socialite and see if your Twitter services are still working – if not: Delete all items in your Socialite keychain, remove the Twitter services from Socialite, restart Socialite, add them again and move the freshly created twitter.com items in your Login keychain to the Socialite keychain.

Okay, that’s it, I hope it’s helpful to some of you and I also hope that someday syncing will be baked into Socialite, though Realmac Software currenty doesn’t have any plans for implementing that.

Die WebTechCon war sehr gut organisiert, die Unterbringung, Essen und Atmosphäre top. Unterm Strich eine sehr nette Konferenz die Spaß gemacht hat und auf der ich viele nette Leute getroffen hab – unter anderem habe ich endlich auch mal den Rest der Railslove Gang persönlich kennen gelernt. Fazit: Vielen Dank, gerne wieder!

Problem

Most applications that deal with users registered on a backend (like webapps) are likely to verify
the user credentials. This recipe explains how to extract the authentication functionality that
handles the workflow of prompting the user for credentials and verifying them at the backend.

Solution

A separate (Modal View) Controller that acts as the apps AuthenticationController and gets called by other controllers. This controller encapsulates the authentication logic so that it is cleanly separated from the rest of the app. The provided code is compatible for all iPhone OS from 2.0 on.

The code for this recipe is available on GitHub and it contains an example app that features authentication with the Twitter API (HTTP Basic Auth, keepin’ it simple) along with explanatory notes in the README.

The solution to this is pretty simple, but I spent some time searching for it: Open your Project Info (double click the project icon) and adjust the build settings. You need to set the Base SDK to something prior to OS 3.0.

Having done that, the build options for older versions reappear. I hope this little trick saves some of your time

Happy beta testing and quick app approvals to all of you!

- (void)viewDidLoad {
   [super viewDidLoad];
   gravatarLoader = [[GravatarLoader alloc] initWithTarget:self andHandle:@selector(setGravatarImage:)];
   [gravatarLoader loadEmail:@"your@email.com" withSize:50];
}

The gravatarLoader needs to be an instance variable of the class that’s using it as it loads the Gravatar asynchronously. You initialize the GravatarLoader with a target object and a selector. The selector works as request handle and gets passed an UIImage when the Gravatar is loaded. After initializing it you can load the image with the email address and the square size.

Download the GravatarLoader source.