When I first started with this WordPress blog, I installed the Custom Content Type Manager (CCTM) plugin to help me manage custom content types. Although this has been perfectly adequate for my needs, I’ve been looking to migrate over to the Pods plugin for a while now, if only because it seems to offer a bunch of additional features (relationships, a REST API…) and a nicer interface. And recently, when CCTM appeared to have crashed on me for a couple of days (turned out to be a stale cache), I decided to take the plunge.

My blog uses three custom content types: Books, Articles and Presentations. Pods’ documentation is extensive, but it didn’t cover my key problem: transferring control of these existing content types, hitherto managed by CCTM, over to Pods without either corrupting my data or having to spend time exporting and re-importing my posts.

After a few false starts (and database restores), I finally hit upon a simple process to transfer control of my custom content types from CCTM to Pods. At the end of the process, I was able to remove the CCTM plugin and view and manage all my custom content through the Pods interface.

In case you ever need to do this, here are the steps I performed. The steps here reference a Book content type, and you’ll need to repeat the process for each of your custom types:

1. Backup the WordPress database.
2. Install and activate the Pods plugin.
3. Log in to your MySQL database using the CLI and run the following SQL query to rename posts of type book to a (temporary) new identifier. This step is necessary to avoid a name collision with Pods.

   UPDATE wp_posts SET post_type='unspec' WHERE post_type='book';

   

4. From the CCTM plugin administration page, make a list of the fields attached to the Book content type and then deactivate it. The process should affect 0 posts (because the database no longer has any records with the book identifier).
   
5. From the Pods plugin administration page, clear the Pods cache.
6. Create a new Book pod.
   
7. Add fields to the new Book pod, ensuring that the field names are identical to those originally attached to the Book content type in CCTM. It’s important to ensure the field names match exactly, as otherwise you might lose some of your custom metadata.
8. Save the new Book pod.
9. Log back in to your MySQL database using the CLI and run the following SQL query to change your posts back to type book.

   UPDATE wp_posts SET post_type='book' WHERE post_type='unspec';

   

10. Check the list of Books in the Pods administration interface. You should see that the Pods plugin now recognizes all your Books, and you can use the Pods administration interface to add, modify and delete Book posts.

Once you complete transferring control of your CCTM content types to Pods, you can simply deactivate and uninstall the CCTM plugin. All your previous custom content can now be managed through the Pods interface.

Many, many years ago, I wrote an article about building a timesheet system to track and analyze work hours with PHP 4.x. It was a fairly useful little application, one that I ended up using quite a bit in my daily work as a consultant. As my requirements increased, I moved on to other project management systems…but I always had a soft spot for this, the one I used with my first few clients.

Fast-forward to 2018 and it occurred to me that it might be fun to go back and visit the Boss, the Customer and the Lazy Programmer and try to rebuild my original application, but with a modern spin: using a micro-framework with the latest version of PHP, scalable cloud-based data storage and PaaS infrastructure.

The application was fun to build and the result is a modern, lightweight and mobile-optimized evolution of my 2001 design. Essentially, the tool allows busy professionals (like lawyers and accountants) to define to define one or more projects, each representing a customer job and enter, on an ongoing basis, the hours worked on each project. Data is stored online, and users can view or export a report of hours worked per project at any time.

Here is a screenshot of the data entry screen:

And here’s another of the reporting screen:

As you can see, the entire application is mobile friendly, enabling users to enter data and view reports even when on the move (perfect for professionals who don’t have a fixed office or place of work). Behind the scenes, the application uses MySQL for data storage, Bootstrap for the mobile-optimized interface, the Slim PHP micro-framework for request processing, and the IBM Cloud CloudFoundry platform to deploy and scale.

If you’re looking for a lightweight time tracking tool for your projects, fork the code on GitHub and use it for your own business. If you’re interested in finding out how to deploy or customize the application, read my IBM Developer article for the full details.

Continuous delivery is pretty awesome. There’s no fiddling about manually packaging or transferring code; instead, your code is automatically packaged and deployed on an ongoing basis, and you can see (and test) the results within a few minutes of making a change.

Up until recently, if you were using Bluemix, you needed to rely on external or third-party services coupled with various custom scripts to implement continuous delivery for your Bluemix applications. To make things easier, a Bluemix Continuous Delivery service was recently introduced, which comes tightly integrated with Bluemix out of the box and which provides a secure, automated way to build, test, and deploy your Bluemix applications.

I recently had an opportunity to try the new Bluemix Continuous Delivery service with a PHP application on GitHub. In my usage scenario, I wanted my target Bluemix deployment to always reflect the latest “tests passed” version of the PHP application’s dev-master branch.

The basic process I settled on was:

• Each time a pull request is created in the GitHub source repository, the source code will be automatically tested by Travis CI with PHPUnit to ensure all unit tests pass.
• If the unit tests pass, the pull request will be manually or automatically merged into the repository’s development branch. This merge will automatically trigger a new deployment of the application on Bluemix using a Bluemix Continuous Delivery toolchain.
• If the unit tests fail, the pull request will not be merged and the current deployment on Bluemix will remain unaffected.

Here’s what the process looks like:

Sounds interesting? To find out how to do the same for your Bluemix applications, read my IBM developerWorks article which has a complete walkthrough of the steps.

I’ll be speaking at the IBM Bluemix Dubai user group meeting next week.

• Using PHP with IBM Bluemix (Mon Aug 28 2017 at 19:00)
  This session covers the basics of developing and deploying PHP applications on IBM Bluemix. It will be based heavily on my experiences working with different IBM Bluemix services, which I’ve also described in various articles. It will include a hands-on coding demonstration that you can follow along with on your laptop.

If you’re in Dubai next weekend, please drop by, grab a cup of coffee and say hello!

Update: Slides are now available, as are photos of the event.

I’ll be speaking at the IBM Cloud user group meeting in two days.

• Using PHP with IBM Bluemix (Sat Jul 29 2017 at 10:00)
  This session covers the basics of developing and deploying PHP applications on IBM Bluemix. It will be based heavily on my experiences working with different IBM Bluemix services, which I’ve also described in various articles. It will include a hands-on coding demonstration that you can follow along with on your laptop.

If you’re in Mumbai over the weekend, please drop by, grab a cup of coffee and say hello!

Update: Slides are now available.

If you work as an independent recruiter or an in-house HR manager, you’re probably inundated with CVs from aspiring job candidates. You’re also probably collecting data from other sources: social media, LinkedIn profiles and your own interview notes. And the more data you collect, the harder it becomes to spot the right candidate for a particular requirement.

If that sounds familiar to you, relax. There are better ways of matching job candidates with business needs, especially if you let technology help you. Close your eyes and imagine an application that lets you upload all those CVs and notes, scans and indexes them, and gives you a way to search them using skill keywords like “PHP” or “aerospace engineer”.

Sounds good? I thought so too. That’s why I recently built a mobile-optimized app for CV indexing and search, which does everything I just said above.

It’s built using PHP and tightly integrated with both Searchly (for fast data indexing and search) and Bluemix Object Storage (for CV upload and download). Try out the demo on Bluemix, get the code from GitHub and read all about it in my developerWorks article.

At the end of every month, I sit down for a couple of hours to create and send out invoices to my customers. Up until very recently, this involved opening up an invoice template in a word processor, entering the date and invoice number, adding up the hours worked, and calculating the total and any taxes. I’d then export each invoice as a PDF and email it out. As if that wasn’t bad enough, at the end of each accounting year, I had to review a directory full of PDF files to calculate how much I’d earned, if any invoices were unpaid, and how many projects I’d completed.

Sounds tedious? It was.

A few months ago, I decided I needed a better, less annoying approach. I decided to create a Web-based invoice generator, one that would need only the minimum necessary information from me and would take care of everything else (including generation, delivery and reporting). Since the plan was to eventually release it as an open source project for anyone to use and since every firm has its own invoice format, easy customization of the invoices was also a key design factor.

It didn’t take long to come up with a working prototype and go from there to the finished product. The final version of the application asks for basic invoice details (which customer, what was purchased, for how much) and then created a PDF invoice by merging this input with an HTML template. The template is fully customizable (so long as you know HTML, you can add your own logo, fonts, colours and layout) and the final invoice is saved online, sent to the customer via email and can be exported as a PDF file on demand. Oh, and it’s fully mobile-optimized too, so you can bill a customer with just a few keystrokes even if you’re travelling…

Here’s a sample invoice:

To make reporting and management easier, I wrapped a couple of views around the information in the database:

I used a bunch of different tools to create this application:

• PHP with Silex for the framework
• Bootstrap for the mobile-optimized interface
• mPDF for PDF invoice generation
• Bluemix’s Object Storage service for secure invoice file storage
• Bluemix’s ClearDB MySQL Database service for invoice metadata
• SendGrid for cloud-based email delivery

If you’re looking for a better way to do invoices, try the live demo or fork the code on Github and use it for your own business. If you’re interested in finding out how to deploy or customize the application, read my developerWorks article for the full details.

Ever seen an injured stray on the side of the road and wished you could help, but didn’t know who to call? A couple of months ago, I started thinking about how technology could help address this problem. I began to imagine a mobile application which anyone could use to quickly report injured or ill strays to a central database, including photos and GPS locations. This information could then be used by rescue agencies dedicated to stray assistance.

The more I thought about it, the more viable it seemed. After a few experiments, I had the basic user interface ready and a MongoDB database provisioned to receive user reports (with GPS coordinates automatically included). I added an option for users to attach photos from their device cameras to their reports, and hooked it all up to the Google Maps API so that every report could be correlated with a visual map location. A few minutes later, and it was live on Bluemix.

Here’s what the reporting form looks like:

And here’s an example report cross-referenced with Google Map data. This additional information makes it easier to locate the animal being reported.

Try the prototype out, or fork the code on Github and use it for your own neighbourhood or city. If you’re interested in finding out more, read my developerWorks article, which walks you through all the technical details.

Like most people, I send and receive a lot of documents over email, and the vast majority of those are in PDF format. Over the last few months, I’ve been playing with the idea of moving all these documents into a single location and building an application to automatically index them. This would not only make it easier to find a specific one quickly, but also simplify backing things ups.

Fast forward to last week, and I was reading about some of the Watson services in IBM Bluemix. It occurred to me that it would be fairly easy to combine the Watson Document Conversion service with the AlchemyAPI Keyword Extraction service to automatically turn PDFs into text and then extract keywords from them. I could store the keywords in a database and wrap a search interface around it to create a fairly neat little PDF storage/search application.

As it turned out, it worked exactly as I’d thought it would. A few hours of coding and I had the skeleton of a working application. A few more hours to hook it up with a couple of data stores (MongoDB for the keywords, a Swift object store for the actual PDFs) and add a pretty GUI, and my application was live on Bluemix.

The final version lets users select and upload PDF documents from their computer. As each document is uploaded, it is automatically and intelligently scanned for keywords and those keywords are extracted and stored in a database. Users can later search by keyword to quickly identify and download documents relevant to their needs. Needless to say, it’s all mobile-optimized, so you can get to your documents from both your smartphone and your desktop computer.

Here’s an example of what it looks like in action:

Try the prototype out, or fork the code on Github. If you’re interested in finding out more, read my developerWorks article, which walks you through all the technical details.

I’ve been looking for an excuse to play with MongoLab’s DBaaS for a while…so when I had to choose a database for my latest IBM Bluemix application, MongoDB was first on my list. I like the idea of a document-oriented database as an alternative to the traditional RDBMS, and I was keen to try this in a real-world context.

As it turned out, MongoDB’s document-oriented structure was a great fit for my idea of a fast, searchable, color-coded notepad in the cloud. Each “note” is modeled as a document in a MongoDB collection, and full-text searches across the documents in the collection are extremely efficient. Thanks to MongoLab’s browser-based management, it was also very easy to configure and connect the MongoDB database to the PHP application running on Bluemix.

The end result is a low-overhead mobile Web application that lets you store, categorize and search free-form text notes in the cloud. Check it out on Github, or read more in this IBM developerWorks article.