{ Hi! I'm Mike }
I'm a core developer with The Horde Project and a founding parter of Horde LLC - the company behind the world's most flexible groupware platform. This is my personal blog full of random thoughts about development and life in general.
March 18, 2016

Vagrant Images for Horde Testing

As a developer with the Horde Project, I spend most of my development time plugging away on our bleeding edge code; Code that lives on the master branch of our Git repository. However, debugging our code and testing fixes the stable FRAMEWORK_5_2 branch presents issues. It's currently all but impossible to easily run this branch directly from a Git checkout so it's often necessary to quickly setup a new test environment from our PEAR packages. In fact, even with our master branch, there are a multitude of different configurations, backends, PHP versions etc... that need testing.

For me, I've found the thing that works best for my workflow is utilizing Vagrant images to quickly bring up new VMs with specific configurations for testing. Since I've accumulated a good number of Vagrant images, I thought it would be a good idea to throw them up on my personal GitHub account. These images all create functional Horde installs running with various different backends, and PHP versions.

There are images based on current Git master and images based on current stable. There is even an image that downloads and compiles current PHP master (currently 7.1-dev) for testing. A thank you to both Michael Slusarz for the original vagrant image I based these on, and to Jan Schneider for cleaning up the vagrant configuration.

The images can be found at https://github.com/mrubinsk/horde-dev-vagrant

Final note of warning: These are meant to be throw-away instances for testing and development use. Of course, it wouldn't be too hard to change the configurations to be more appropriate for production use.

March 23, 2011

Personal Roadmap

With the release of the first RCs for Horde 4 and the final release looming less than 2 weeks away, I thought it a great time to start looking ahead at my personal roadmap for Horde 4 development.

The entire Horde team has been pretty much exclusively working on resolving final roadblockers and reworking the release process these last few months. As much fun as it is getting ready for this milestone release, I'm also a bit excited about being able to get back to some projects that have been patiently taking the back seat while the initial Horde 4 release was being prepared.

Some things I'm excited to get back to in the months ahead:

Ansel, the Horde photo gallery application, needs some significant changes to keep up with the recent changes in the Horde_Share library. These *must* be done before Ansel can be released with the next Horde 4 release, so this is likely to be where I focus on immediatley following the release. Additionally, Ansel needs to move away from the Google Maps based geolocation features, and use the new Horde_Map functionality in Horde 4. This would provide the ability to use any number of different mapping backends while changing nothing but a configuration setting. I might even make this a per-gallery setting, so pictures taken while hiking could, theoretically, be placed on a hiking trail maps, while pictures taken while sight seeing could be placed on a traditional map for instance. I'll also hopefully finally get to some of the dozen or so enhancements requests waiting on our ticket tracker!

Hermes is getting an Ajax AND mobile interface (partially sponsored by Alkaloid Networks - thanks Ben!), and I'm pretty excited about working on this. I'd also like to expand on some of our other existing mobile interfaces, like Kronolith and Nag. I also have a bunch of other itch-scratching to do in Nag.

I've been wanting more integration points for our Twitter and Facebook support for a while now. We already have basic clients for these two social networking services, as well as some existing integration such as a Turba driver for Facebook contacts, a TimeObjects driver for Facebook events, birthdays etc... but we really need to add things like auto posting to the user's Twitter/Facebook stream after publishing a new blog post in Jonah, or new photos have been added to an Ansel gallery.

Jonah: I'd like to finally get this application to the point where it can be released. I, along with a number of the other Horde devs, have been using Jonah to power our personal blogs since way before Horde 4 work even started, and it's about time this thing got released. Thanks to Ian Roth for contributing a number of patches on GitHub related to getting it more in-line with Horde 4 code.

Add to these a slew of existing enhancment requests, some articles that are in varoius stages of being complete, the normal bug fixes and support requests that crop up, and some personal coding projects, I'll have enough to fill up my development time for the foreseeable future. Now, all I need is a Horde_Time::create() method to find the time to do all this...

November 25, 2008

The Cocoa Diaries Part I

I've been slowly plugging away at a new iPhoto export plugin for exporting photos to an Ansel server.  This was really my first Cocoa project and my first C related project in quite a number of years.

 I found picking up the basics of objective C  not that difficult, but I was stumped trying to do something that should have been fairly easy.  For this plugin, I am using the Cocoa XML-RPC Framework to manage (surprisingly enough) a xml-rpc connection to the Horde server.  During development, I just had it linked against the framework in my Library/Frameworks directory - which obviously won't work on someone else's machine.  So, time to move the framework into the bundle for the plugin.

I decided I wanted to include the source for the framework in the same project as the plugin. This makes debugging easier and also makes distributed development with other developers easier.  Sure, no problem,  just add the source, add a new framework target, copy files etc... but no dice.  For the life of me, I could not figure out why this would not work. Googled, hacked, googled some more.  Then it hits me - this is a plugin, not a standalone application.  When setting the Installation Path build property for the framework target in Xcode, I was using @application_path and not @loader_path. Duh. 

So, seeing how that particular problem cost me so much time, I thought I'd document this in the hopes it will help someone else avoid the same mistake. Here are the steps required to add the source code for a framework into an existing Xcode project for a plugin. (These are all basically the same steps as an adding it to an application, except for the setting of the Installaion Directory property).

  • Import the framework's source tree using the Import Existing Files command
  • Create a new target for the framework. Obviously, this should be a Cocoa Framework target.
  • Open the Build tab of the Inspector for the framework target, and set the Installation Directory property of the target to be: @loader_path/../Frameworks
  • Open the target for the plugin so you can see the build phases - drag your framework product (not the target) to the Link Binary with Libraries build phase.
  • Add a new Copy Files build phase and drag your framework product to the it. Open an inspector and set the Destination of the build phase to Frameworks.
  • Select the application target, open an inspector and add your framework as a dependency. This will assure that the framework is built before the plugin so that it's available to link against.  This allows you to keep the target of the Xcode project set to your plugin.

Yep, probably all simple stuff for an experienced x coder, and it actually is mostly pretty simple stuff...except for the fact that I forgot that I could not use @application_path as the Installation Directory.

December 22, 2007

phpEnomUpdate - A small command line utility.

¬≠Like many of us, I own a number of domain names.  I also have two servers that run out of my home in addition to a production VPS server located on the other side of the country from where I am. The domain registrar I use provides a 'normal' DNS service combined with a dynamic service that allows you to define any host on your domain as dynamic.  This has worked out well for me, allowing me to integrate my various home machines onto my domain. 

Recently (thanks to a server replacement project - but that's another story) I had to rebuild my main development server and in the process I decided I wanted name based virtual hosting on this box as well.  This presented a problem, as I have a number of domains that would need to be supported on this box. The protocol my provider uses for dynamic DNS updates allows any number of hosts on a domain to be updated at one time, but not mulitple domains (obviously).  I could have either updated the client that I was using (some really rough Perl script), find a better client, or write my own.

The enomupdate script was a poorly written tool that served a basic purpose. Update one domain. Period.  You couldn't even run it with different paramers or configuration files.  I could have modified it, but I'm not as comfortable in Perl as I am in PHP and I thought it a good way to emphisize the fact that PHP is not just a web server language.

The result was phpEnomUpdate.  You specify any number of domains (or zones in DNS-speak) each or which can have any number of hosts.  Each host will be updated to your IP. Now, I can have dev.example.com  dev.anotherexample.com  all point to my dynamic IP with one simple cron entry....and now I can keep my lighttpd server directory nice and neat on my dev box too, with simple name based virtual hosting.

 The script does have a few PEAR requirements and one Horde package (Horde_CLI), but they are very easy to install if they are not already on your system. See the INSTALL file in the download for more information.