I mentioned a few weeks ago that I had been interviewed by the BBC about Betaville. I was wondering if - and when - anything would come of it until yesterday when I was told that it was featured in the BBC Technology section. I’m incredibly humbled that people are not only taking the work we did seriously, but that it is empowering people to be proactive in changing the world around them.</p>
I ran into a [potential] problem recently when migrating an application from when repository to another. I was only switching repo’s because my PaaS provider, as they all do, creates templated application structures for all new applications. Even though the original application’s repository is gone, its history is still valuable to me. Luckily, this can be fixed relatively easily with a little git magic!
After the merge operation, you may find that a few of the files included in the application template have some conflicts. You can simply resolve these by copying over the originals and committing the merge. Your other option is to merge using the theirs strategy option by including “-Xtheirs” in your merge command:
Occasionally in the WordPress world you come across plugins that just aren’t tidy. One of the nasty things that can happen is that your wp_options table gets filled with transient entries that are never garbage collected after their expiration. If you have a relatively high traffic site, like jMonkeyEngine, this will slow down your site to a crawl especially if new entries are being made on every page view (not naming names but the appropriate developers know the issues if they check their forums).
That said, there’s a pretty easy way to just get rid of all the transient entries in your table regardless of expiration.
Run this if you notice your wp_options table is becoming bloated, or better still, deactivate the suspect plugin.
I was contacted last week by someone from BBC to be interviewed about my work on Betaville. We arranged an interview over Skype for this morning. I had a blast getting to talk about such a great project and look forward to seeing the press coverage.
My thanks to Nastaran for getting in touch and conducting the interview!
I’ve long been intrigued by OpenSift’s automatic scaling option. Unfortunately, it was out of my reach until Postgres support for scaling was introduced in a recent update. With the path mostly clear (cron is still unavailable unfortunately) I decided to give it a whirl.
Nothing I’ve read has given the impression that I could simply modify the current application using rhc to take advantage of scaling so i made a new scaled application.
rhc app create -a MyApp -t jbossas-7 -s
The “-s” flag tells the broker to create a scaled application. The configuration here is a bit different as rather than a public facing jboss cartridge you instead have haproxy sending requests to however many workers crankcase decides that it needs to have spooled up.
Now the part I was dreading. A new application template to pull from OpenShift and migrate my code in to. Expecting disaster, I added my original repository as a remote in the new one, performed a git fetch operation into the new application template, and merged the master branch. Aside from a few easy conflicts in my index page, readme, and jboss configuration (my original app predated Java 7 compatibility) the merge operation was successful and I was glad to be able to keep my original code base with history. Seriously, git is a phenomenal tool.
Similarly, OpenShift brought it to the party and picked up where git left off. I pushed to my new repository and it worked. I was expecting kinks with the JNDI since the Postgres support in scaling was brand new. Nope, everything works.