A few weeks later, a buddy and I took this to its logical conclusion.

But even with novelty projects, there are things to be learned, and this project has exposed me to npm modules I probably otherwise never would have used. I’m going to go over a few of the architectural highlights (npm and not) in no particular order.

Startup

After you npm install lefnire, typing lefnire runs him.

If you said, “ASCII art?” you would be correct. This was a friend’s idea, and it’s become a staple of the application.

API integration with the superagent and github modules

Currently, lefnire.js is lightly integrated with the HabitRPG and GitHub APIs. The HabitRPG API integration uses straight superagent requests. The GitHub API calls use github.

When you say something containing “habit down,” he makes an API call to https://habitrpg.com/api/v1/status to check.

When you ask him by his IRC name (I’ll be getting to IRC stuff in a second), he queries the GitHub API to find out the number of issues labeled “critical” for HabitRPG on GitHub.

IRC integration with the node-irc module

What would an automaton be without being able to log on to IRC and interact? lefnire.js uses node-irc to accomplish this. The library is pretty robust and follows Node.js patterns well. This is a fantastic example of an application that thrives on asynchronous execution. When you ask him if “habit is down,” and it is, that thread of execution will block. However, it won’t stop the bot from responding, thanks to the event listener model implemented by node-irc.

Mood and the Sentimental module

Another interesting feature is a rudimentary implementation of mood, which is basically just a number between 0 and 30 (0′s the best). This doesn’t do too much yet. It affects his behavior a little bit. The number of GitHub criticals is the baseline metric.

This is then adjusted up or down by how positive or negative Sentimental analyzes the up to the 30 most recent GitHub Events from lefnire to be. This is mostly issue comments, pull requests comments, and commit messages.

When lefnire is in-channel, it also adjusts mood based on Sentimental text analysis of what he says.

No database yet, so everything except what I can retrieve again through API calls is lost if I ctrl-C the bot and stop it.

Wrap-up

Those are the main highlights of the current implementation. A lot of things are planned. I doubt anyone would want to contribute to this, but I’d certainly be excited to receive some pull requests.

GitHub repository: http://github.com/litenull/lefnire.js

For anyone still getting burned by this bug (or for that matter getting burned by using Node Clone on nodes with field collections), first apply my previous patch (or bderubinat’s, but I haven’t tested that one). That will stop further damage.

To repair your previous entries and ensure that, for example, removing a field collection entry doesn’t remove it from other nodes from which you didn’t want it removed, you can implement this script I’ve detailed in a gist: https://gist.github.com/wizonesolutions/5567549

It will give new item_ids to field collection items that it detects as appearing more than once. All my testing has indicated this is safe, but if not, please leave a comment on the gist. I hope this helps someone.

Thanks to Project Ricochet for sponsoring my time on this.

Normally, you have to install Internationalization Variables (i18n_variable) and separately configure the options for these pages per-language. This module saves you time and automatically sends visitors to the correct page. Should you decide to use specific language versions with i18n_variable, this module will respect that configuration and not interfere.

All you have to do is enable the module for it to start working. No configuration required. Disable it to turn off the functionality.

Install it from the project page.

Thanks to Project Ricochet for sponsoring this work.

The README file explains in good detail how to use it.

Come on, just tell me how to use it

OK, here’s the quick version (you need NPM installed, which you get with Node.js):

npm install -g habitrpg-todo-sync

habitsync

It will tell you what to do from there.

Full synchronization

You might be interested in running

habitsync -a

to do a full synchronization of your tasks. By default, it only retrieves the last week of them.

Don’t synchronize everything

You may not want to get all your tasks. habitrpg-todo-sync can make use of Remember the Milk’s advanced search interface (ever tried typing something like addedWithin: 1 week ago in their search box?). Here’s how:

habitsync –filter=”list:Name of Your List”

You can do anything you can do with their interface.

And you can combine command-line options:

habitsync -a –filter=”list:Smart List You Want To Sync”

Run on a schedule

You can run it manually or add it to cron. I have this in my crontab, which runs it every hour against beta.habitrpg.com (which is often more likely to be working). To put it in yours, you generally run

crontab -e

and then add the following line:

# min hour mday month wday command
*/60 * * * * /usr/local/bin/habitsync -qB

You can separate each argument with spaces or tabs, and you don’t need the first line. I just included it for completeness.

It doesn’t do what I want.

Tell me! I really want to hear back from users of it. When I don’t, I assume nobody cares, and I improve it much more slowly. Report issues on GitHub.

The camp’s pitch is: “A one-day conference focused on the Drupal CMS. Come along and learn more about Drupal and the web, and have a great day in Gothenburg in late Spring.”

Sessions are here: http://summer2013.drupalcamp.se/program/sessions

As with most DrupalCamp sites, volunteer work lies behind the site you see. A lot of people contributed really great work. Fantastic designs and solid development resulted in the site you see today. I was also involved, mostly behind the scenes. I helped with server administration, Git coordination, transferring the site to another server, and mostly with coordinating the web team’s efforts. It was the first time I had spent as much time helping organize a DrupalCamp (and I’ve been to quite a few; I’ve even volunteered at a couple).

If you’re in Europe or in the area, I encourage you to check it out. You can follow them on Twitter at @DrupalGBG.

Google Translate is getting better and better

Anti-video readers: Keep reading.

This morning I ran into an issue with my Vagrant upgrade (I went from 1.0.7 to 1.2.1) that took me a few hours to figure out. I did, however, solve it in the end and thought it’d be useful to share how. It’s an easy fix.

First, the error I was getting was:

The box ‘boxname’ could not be found.

(where boxname was the actual name of the box, e.g. precise32)

The box did show up when I ran vagrant box list, so I knew that it should have been working.

After trying an assortment of things, including converting my Vagrantfile configuration to the version 2 format and trying to use the box in a fresh directory and with a fresh Vagrantfile, I decided to try re-adding the precise32 box that Vagrant provides. I did that, and then typed vagrant init precise32d. (I had called it precise32d.) This worked fine. I deduced that there must have been some change in the box itself. So I fired up DiffMerge.

DiffMerge told me that there weren’t any files it could compare. This, I discovered, was because everything in the new box I had downloaded was under a virtualbox directory. A-ha! I was on to something. I looked in that directory and saw these files:

Vagrantfile box.ovf box-disk1.vmdk metadata.json

Wait, metadata.json? That wasn’t in my existing box’s folder at all! What could be in there, I wondered?

$ cat virtualbox/metadata.json

{“provider”:”virtualbox”}

Ah. So it’s relying on this to figure out the provider, since Vagrant 1.1+ has the concept of providers other than VirtualBox. That explained a lot. The simplest fix is just as you may suppose:

To eliminate the potential for human error, we’ll use an existing metadata.json file. Run:

$ vagrant box add precise32 http://files.vagrantup.com/precise32.box

Wait for it to download and be added.

Then,

$ cd ~/.vagrant.d/boxes/yourbox

$ mkdir virtualbox

$ mv * virtualbox (or you can specify all the filenames manually)

$ cp ../precise32d/virtualbox/metadata.json virtualbox

You should now be able to vagrant up any projects that are relying on your pre-upgrade box. And they should work just as well as they did before!

Some notes:

• I assume your boxes are VirtualBox VMs. If they’re not, then you probably wouldn’t have this issue anyway.
• Don’t type the $ marks. That’s just to show you type the command in a terminal.

If you manage your keys at all, you can immediately see the allure here.

The configuration is ridiculously easy. Put this in your $HOME/.ssh/config file* (Windows users, check PuTTY settings; it can probably do this too).

Host <hostname>

ForwardAgent yes

You can, of course, combine this with other options such as HostName and User.

I tested it with Fill PDF Service:

Host fps

HostName fillpdf-service.com

User myusername

ForwardAgent yes

ssh fps
cd /path/to/my/web/root
git pull

(The Git repository is password-protected, and my Git setup uses SSH for authentication by default.)

I got back: Already up to date.

I used to be prompted for my password, but that’s yesterday’s news…quite literally.

Extra tip: If no one else uses your computer, you can put ForwardAgent yes on its own line. This will forward your agent to all servers you connect to. I’m not an SSH expert, but as far as I know, ssh-agent is designed to be extremely secure. The main risk is if someone is using your computer directly, but that applies to most things. SSH Agent sessions are restricted to the current user session via environment variables (so no one can simply switch to you on a server to get access).

It blew me away how easy it is to get this going. 2013 is the year of SSH agent forwarding for me. Hope this helps!

* If the file doesn’t exist, create it. Make sure the permissions on the .ssh directory are 600 (drwx——).

Rates on new work will generally be consistent with the Norwegian economy, so that is something to keep in mind when evaluating my services.

Looking forward to seeing how this new chapter unfolds!

Norwegian speakers only beyond this point:

Kjære norskspråkelig menneske ,

Jeg snakker norsk, så bare ta kontakt direkte på norsk hvis du har behov for tjenestene mine. Jeg kommer ikke til å skrive så mye på norsk på denne bloggen. Jeg vil heller ha en helnorsk side enn å blande språkene. På Twitter kan du sende tviter til @wizoneno eller @wizonesolutions.

Overview

I’ve been trying to stick strictly to a rebase workflow in Git, rather than using git merge.

This has not been without it perils.

However, I’ve found a workflow that works for me as an individual developer using my own feature branch that I push to a remote. Do not use the following workflow for other situations unless you know what you’re doing.

“Why are you doing this?” and such

The problem: After rebasing using the mainline as a base (git rebase master) you can no longer push the rebased branch to a remote since it won’t fast-forward anymore.

Why would you push it to a remote? Because you have untracked/dirty files that need to stay that way locally. In my case, my Drupal settings.php is in the repository – don’t blame me, I don’t control the client’s internal processes – and it must stay dirty for my local site to function. Rebasing is much easier when you don’t have to worry about such files, though, so I keep a second clone of the repository that I use for rebasing.

Pushing my changes from the dirty repository works fine, naturally, since I don’t rebase there.

But once I rebase in the clean repository, how do I push those changes back to the dirty one without causing a merge?

It actually only takes a few commands, and it is pretty safe as long as everything you want to commit to your feature branch is already committed.

The good part (commands!)

This is what I do:

cd /path/to/clean/repository/clone

git pull (remember, I don’t work on this repository, so it will always fast-forward)

git checkout featurebranch

git rebase master

(fix any conflicts and complete the rebase)

git push -f origin featurebranch (this overwrites the remote with what I now have)

cd /path/to/dirty/repository/clone

git checkout master

git branch -D featurebranch (this deletes the local featurebranch branch)

git checkout featurebranch (you may have to use git checkout -b featurebranch origin/featurebranch – I don’t know what differentiates if you have to or not)

Explanation and conclusion

So basically, I’m recreating the local branch from the remote branch. Then I continue developing and rinse/repeat when I need to integrate changes from the mainline or when I’m done with my feature and want to make sure it will fast-forward into the mainline. I finally developed this workflow after finding I always had to merge my feature branch into the mainline in the end; it would never fast-forward. This is because I was running git rebase origin/featurebranch from within the feature branch, since then it would let me push. This basically defeated the purpose of rebasing since it would rebase the new commits from the mainline on top of mine. I wanted mine on top of the new mainline commits.

Hope this helps some poor soul out there who’s in the same boat I was.

So, this is a bit of a departure from my usual type of post, but it’s still DevOps-related (an area I’m increasingly getting into), and people are probably searching for this.

My experience with this error

I had to send in my Windows laptop for warranty repair, and I was running a couple work-critical VirtualBox virtual machines (“VMs”) on it. I use Vagrant to run them without a GUI, and moving them was easy. I used vagrant package, copied over the project files, and ran vagrant up on the destination machine. This was not the issue.

I got this error when I suspended the virtual machines, then tried to resume them

So for some reason the VMs started up without issue. However, upon suspend and resume, I started getting the titular error. I searched for it on the Internet and found a VirtualBox forum which linked to a bug report which suggested editing the .vbox file. This is in <home directory>/VirtualBox VMs/<name of VM> and is named after the VM as well. It ends in .vbox.

Now, before you edit it, make sure you:

1. Suspend or shut down all running VMs
2. Close VirtualBox

If you don’t, this won’t work because VirtualBox will use the previous configuration anyway.

OK, so open up the .vbox file. Search for SharedFolders. You will see something like:

<SharedFolders>
<SharedFolder blah blah blah />
</SharedFolders>

Anywhere in the file you see that, change it simply to:

<SharedFolders/>

and save the file.

Now open VirtualBox and try resuming the afflicted VM again.  It should work. If it doesn’t, go check the .vbox file and make sure VirtualBox didn’t change it back. If it did…then make sure you followed the two preparatory steps above. I’m speaking from experience here. You can’t skip those.

And you’ll be good!

Update (7/17/2012): If you have several VMs that you run together, sometimes one of them will resume while the others fail with this error. If you resume that one, you may be able to subsequently resume the others. Not sure why this happens since the VM in question didn’t have any VirtualBox shared folders (not even in the XML), though some were using NFS. Perhaps it was internal-network related. Just noting this here since it happened.