Welcome! I'm Lorna Jane Mitchell, a web developer, working particularly with PHP, the LAMP stack and related technologies. My main interests lie in working with open source software and building excellent APIs so that data in one system can be used in another. I'm freelance, so if you want to work with me as a consultant, developer, trainer, writer or evangelist, then let me know.
Need a senior developer? I have years of LAMP experience and love to lend a safe pair of hands to get a team through a tight spot.
I'm mad about APIs! If you'd like some advice with creating yours or integrating with someone else's, then you're in the right place.
Time for better tools or better practice? Time for a new version of PHP? Let me lend a hand to make your transition go smoothly.
I love hubot and use one in a few different places. One thing I do find though is that I often want to edit or evolve those plugins, and it seems somehow unethical to just hardcode my changes into my own repo. Once I figured out how to wire together a forked repo as a submodule, it became much easier to work with hubots with external plugins, so I thought I'd share my recipe for that.
Plugins as Submodules
Git submodules can get messy if you're not totally clear on what is going on. The basic premise is this: there's a git repo in your subdirectory, and the parent directory will notice if things change in there. You need to remember to commit and push on both the main repo and the submodule and then everything will work! The git-scm reference for this has good examples: http://git-scm.com/book/en/v2/Git-Tools-Submodules>http://git-scm.com/book/en/v2/Git-Tools-Submodules
In this case, I've got my own fork of the github notifier plugin which we use in the #joind.in channel on freenode. My fork lives here: https://github.com/lornajane/hubot-github-repo-event-notifier so I go there, and I grap the repo URL.
Then, I add it as a submodule. I've created a directory called
my_modules inside my hubot folder to keep submodules in.
git submodule add my_modules/hubot-github-repo-event-notifier https://github.com/lornajane/hubot-github-repo-event-notifier.git
There are two particular things to notice about this command:
- It is run from the top level of the repo, not the subdirectory
- It uses the https version of the URL - I usually work with SSH for github, but if you're going to push to heroku, the https one makes more sense there
Tell Hubot About The Plugin
To get hubot to "see" this plugin, create a symlink in the
scripts/ directory that points to the script you want to run in your plugin. My command looks like this:
ln -s ../my_modules/hubot-github-repo-event-notifier/index.coffee gh-notifier.coffee
Now when you run hubot, the plugin should load. You can easily test your hubot locally (without having to commit and push to heroku every time) by running
./bin/hubot from the commandline; this starts hubot with the shell adapter and is really hand for the types of commands where you say something and the bot does something. I have a trick for testing webhooks on my local machine that I'll share in a separate blog post but the main thing is, any really basic mistakes like syntax errors will become obvious at this point :)
Submodules to Heroku
There isn't anything special to do here. Make sure that both your main and submodule repositories have changes added, committed and pushed. When you push the main repo to heroku, it knows how to handle the submodules and will plug them in accordingly.
I love that so many of the hubot plugins are packaged via npm but often I want to tweak or evolve them - or even just take advantage of their newest changes without waiting for it to be packaged! The github integration in particular I found was a lot less useful than I expected from any of the plugins I could find, so if you're using hubot and github and you want to try my version, feel free ... the main reason I wanted to work with submodules and hubot is so that I could share what I was working on in case it was useful to anyone else.
I came across a git repo recently that output this message with every operation I did:
Your branch is based on 'origin/master', but the upstream is gone. (use "git branch --unset-upstream" to fixup)
I was delivering a workshop at the time so I kinda snarled at it and carried on with what I was doing, but later I looked up what is happening. This occurs when a branch is tracking a branch that the git repo doesn't have any information about - the branches to be tracked aren't in the local repo metadata.
In my case, it happened because I had created and then cloned an empty repo for training purposes - so
origin/master didn't actually exist yet! I added a quick commit-and-push to my script and hope that I won't be upstaged by this change that came in with git 1.8.5.
Hopefully this post will help someone else to avoid being upstaged or irritated by this as well!
In recent years, the release cycle of PHP has become much shorter. We now have a much more controlled and well-publicised process of releases, and moving between each version is no longer a leap of faith. The newer versions have HUGE performance improvements, great features, and better security, and the software is free to use. Yet we have a very, very long tail of PHP installations on older versions (around 75% on entirely unsupported versions at this point). Many of the companies I talk to think that upgrading will be pointless and painful, but that's not my experience of migrating PHP projects. Here are a few things you might like to think about or be aware of before you make the decisions that "not broken" is good enough for your applications. Continue reading
Daycamp4developers, December 2014
Voices of the Elephpant, October 2014
ZendCon 2014, October 2014
ZendCon 2014, October 2014
ZendCon 2014, October 2014
PHP North West, October 2014