Skip to content

All posts by moore - 48. page

Upgrading projects managed with Cordova CLI

I’d like to preface this post by saying that I’ve upgraded Cordova CLI 5-6 times on one project, but haven’t upgraded after submitting to any marketplace (the app store, etc) or after using plugins. I have, however, done some customization of the app.

Like I mentioned before, Cordova CLI is a moving target. So, you should be prepared to deal with upgrading your toolset. There are two types of updates–minor and major. Major will require more testing since APIs could change.

Just a heads up that 2.9.x is the last stable release of the 2.x codebase and the team has promised to support it for a long time (but not with new features). I have no idea how hard it will be to move a app from 2.9.x to 3.0.x, but I imagine there will be many plugins that won’t move to the new architecture, so I expect 2.9.x to be around for quite a while.

You can see if there is a new release of Cordova CLI by running npm outdated -g cordova.

To update either kind of release major release:

  1. Make sure that all your code is checked in (you are using version control, right)
  2. Move your old project directory to project.2.8.1
  3. Move your ~/.cordova directory to ~/cordova.2.8.1
  4. Checkout your project directory from your version control system
  5. Run npm update -g cordova@2.9.3
  6. Check out your project from source control
  7. cd project
  8. mkdir platforms; mkdir plugins
  9. cordova platforms add [your platforms]
  10. cordova plugins add [your plugins]
  11. continue development

This illustrates why it is so important to keep everything in version control. Because Cordova CLI controls the platforms and plugins directories, you have no idea what is happening in there, so any code or configuration that is in there should not be customized. For one thing, when you change versions of cordova, the cordova.js file that lives under platforms may or may not be changed–that’s why we re-add the platforms.

In my next post, I will discuss what hooks are.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

Placing Cordova CLI projects under version control

If you do software development, you should use version control, and Cordova projects are no different. However, Cordova CLI generates a fair number of derived artifacts which shouldn’t be placed under version control.

The typical Cordova CLI project has at a minimum these directories in the project.

  • www: where your html, css and javascript live
  • merges: platforms specific html, css, javascript
  • .cordova: ‘under the hood’ cordova files and directories, and lifecycle hook scripts
  • platforms: platform specific build directories
  • plugins: downloadable plugins

Based on this Stack Overflow question (which I asked), as well as my experience, the first three directories above should be versioned, and the latter two added to your version control system’s ignore file.

You can, of course, add additional top level directories, and as we continue to explore Cordova CLI, I will show you the directories I have found useful in my development. I don’t think it really matters much which version control system you use–just use one!

In the next post, I will discuss upgrading Cordova CLI, one of the great reasons to keep these directories under version control.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

Installing And Using Cordova CLI

This will be a short post as Kerri Shots has written up fantastic instructions for installing Cordova CLI. You’ll want to read them carefully. These instructions are a tad out of date, and describe installing the tool on MacOS. I was able to use these as a guide and get Cordova CLI running on Linux (specifically CentOS 6.4), but had to make some modifications (mostly just to get the android SDK running on my version of Linux).

There is also a good doc explaining installation and usage of Cordova CLI in the Github repository.

I also tried installing Cordova CLI on Windows 7. I was using cygwin, but wasn’t able to get the emulator started, and just decided to go with Linux in VirtualBox. Apparently there is an open bug about installing Cordova CLI on Windows 7. For what it is worth, Kerri was skeptical about installing Cordova CLI on any Windows as well.

That said, I know that Cordova supports Windows Phone development (which requires Windows), so I imagine that if this isn’t fixed, it will be soon. If you know any resources for installing Cordova CLI on Windows, please let me know or add a comment.

In the next post I’ll discuss version control.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

Alternatives to Cordova CLI

If you are interested in building Cordova applications, Cordova CLI has few competitors. The ones I know about:

  • Homegrown script: I built an ant script to do much of what Cordova CLI does–build packages, run tests, and start emulators. I’m sure you could use any other build tool to do the same. There’s some reverse engineering, and tangling with iOS build tools isn’t much fun.
  • Different code trees: use the Cordova create script to create a project for each platform, and then let the html, css, and javascript evolve differently for each, possibly relying on an IDE to do compilation/building. This may be a viable option if you have hard requirements that each platform’s build can be tested against, or if you don’t care to share code between platforms. Upgrading versions of Cordova may be an issue.

As you can see, there aren’t too many other options for doing Cordova development. If you are interested in forward compatibility, I suspect you’ll choose one of the scripting options (Cordova CLI or a homegrown script); if you just want to get the project done, I think you’d lean towards using an IDE after the project is created–it all depends on how future proof you want the app you are building to be.

In the next post, I will discuss installing Cordova CLI.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

What is Cordova CLI?

I’m planning to write a number of posts documenting my adventures through the new Cordova (aka Phonegap, though there are differences) command line interface, known as Cordova CLI. I am in the midst of working on a Cordova application and have been using Cordova CLI heavily for a while now. My focus has been on the Android platform, though we plan to release to iOS as well, so that will be where the majority, if not all, of my examples are.

These posts only cover cordova cli 2.9. Cordova 3.0 is an overhaul that changes how the core Cordova app is assembled, and therefore has different constraints.

Here’s a list of what I plan to cover:

  • What is Cordova CLI
  • Alternatives to Cordova CLI
  • Installing And Using Cordova CLI
  • Placing Cordova CLI projects under version control
  • Upgrading projects managed with Cordova CLI
  • Hooks and Cordova CLI
  • Configuration management using Cordova CLI
  • Setting up CORS
  • Platform Specific CSS/Javascript with Cordova CLI
  • Platform specific configuration files with Cordova CLI
  • How to set up a new plugin for use with Cordova CLI
  • How to ‘plugman’ify an existing plugin
  • Releasing with Cordova CLI

Cordova CLI is different than the create scripts that have been part of Cordova/Phonegap (hereafter called Cordova for brevity) for a while (though it does use those create scripts). The create scripts only helped you create the project; afterwards you were on your own. Cordova CLI helps you create a project, manage css and javascript resources that differ per platform, develop and test it using both emulators and an in-browser emulator called ‘ripple’, manage plugin dependencies, and build packaged apps suitable for installation on phones and emulators during development. It is a nodejs application that runs on MacOS, Linux, and possibly Windows (see this bug).

Cordova CLI lets you keep the shared html, css, and javascript code in one place, and deploy it to multiple platforms. This is one of the main strengths of Cordova development–one set of logic deployed to multiple mobile platforms.

Be aware that Cordova CLI is early beta software. This is bad because you’ll run into issues; this is good because the software is under active development, and I’ve found the developers to be quite responsive to bug reports. I have occasionally filed a bug one day, and had a fix to download the next.

There are also areas where Cordova CLI has significant deficiencies–luckily they’ve built the software to be flexible enough you can work around it (or, if you can contribute fixes, they are happy to accept help). So, if you plan to use Cordova CLI, make sure you bookmark the issue tracker. Consider joining that jira and submitting bugs, but at the least search it when you run into an issue.

In the next post, I’ll discuss alternatives to Cordova CLI.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

A respectful hiring process

I have been on both sides of the hiring equation.  I’ve been the one dressing up slightly nicer than usual, google mapping directions to a strange place, and nervously arriving ten minutes early. I’ve also been the one doing phone screens, trying to fit interviewing into a packed schedule, providing resumes to other team members for review, and making the call on which of two candidates would serve my organization better. (Thankfully, I haven’t had to fire anyone yet.)

Hiring is not easy, for either party. That’s why I think a respectful hiring process is so important. What are key components of such a process?

From the employers perspective:

  • Be honest. Be as clear as you can about the job and the expectations around the job. Comp is hard to be totally clear about because there’s always a dance around this, but levels of comp can be pretty clearly stated in the job req (entry/junior/mid/senior)–which means you have to do the research for appropriate comp levels to fit your budget.
  • Have compassion. Remember what it is like to be on the other side of that call or table.
  • Keep track of all your applicants in a database (even just a issue tracker). This will allow you to make sure you don’t lose track of anyone (or their documents) and know where everyone is in the process. As a plus, I’ve also mined this database when other openings come up.
  • Set deadlines for yourself, and tell applicants about them. Far too often, once the process starts, communication comes it fits and starts. Setting deadlines forces you to communicate at expected times (even if the communication is just ‘we have to move the previously stated deadlines’, it is still welcome).
  • When an applicant isn’t a good fit (for whatever reason), or the position goes away, tell the applicant as soon as possible.

From the applicant’s perspective:

  • Only apply for jobs that you fit the requirements for, or at least most of them. Applications that clearly meet only one or none of the requirements are a waste of everyone’s time.
  • Be honest.
  • In an interview, when you don’t know, say you don’t know, but also say how you’d try to figure it out.
  • Realize that this isn’t just an interview, it’s a chance to make a connection. I’ve connected people who didn’t quite fit my requirements with other employers, and asked people I’ve interviewed with for technical advice. Treat the interview process as one stroke in a broader picture, rather than a test to be passed.

I’m sure I missed something–any other suggestions to make the hiring process more humane?

Jobs | moore |

Testing time dependent kettle transformations

Testing transformations that depend on the date will often be required when you only want to process new data, or if you want to treat events that happened in the past differently depending on how long ago they occurred.

I have handled the time dimension in one of two ways.

The first is to have a SQL statement that is pulled in via a ‘Get Variables’ step.  This statement is then executed.  For the production job, the statement simply pulls the current date from the database: ‘select curdate()‘ for mysql.  For testing, the statement returns some known date: ‘select str_to_date(‘2012-05-27′,’%Y-%m-%d’)‘ for mysql.

The benefit to this is that you can make this SQL call in your transformation, and everything stays tidily in there.  The disadvantage is that you’re making another database call and mostly just for testing purposes.

The second is just to have a variable that is set previously in the job and is passed in to a transformation as a named parameter.  This date can be pulled from a file (for test), or using the ‘Get System Info’ step, or a database lookup (for production).  The benefit to this is that you aren’t necessarily making another database call and it is more understandable.  I can’t think of any downside, so this is my recommended method.

After this setup is done, you can pivot your test data around the hardcoded test date.  For example, if your data should change state one year after insertion, you can set the date in your input data rows to 364, 365 and 366 days from your test date.  This kind of condition testing ensures that when the logic changes (you should change state two years after insertion), your test will fail, and you will know about the issue before your users do.

This is content from my email newsletter about Pentaho Kettle Testing. To receive similar emails in your inbox, sign up below.

Signup for my infrequent emails about pentaho testing.

Pentaho Data Integration Testing | moore |

Switching wordpress themes…

After many moons (almost 7 years), I switched up my theme to a more modern (thought still stark) one.

Why?

  • The older theme was borked in a couple of ways that I couldn’t be bothered to investigate.
  • I wanted something that was more responsive and a better experience for mobile users (only 6% of my traffic in 2013 is mobile, and I’m hoping to increase that).
  • Sometimes it’s just time for a change.

So, I hope you enjoy the new theme.  Same dorky content, new dorky look!

Blog | moore |

Older versions of Sinon.js don’t work with jquery 2.0

This is a quick hit, hopefully to help someone avoid spending the half day I just did.

The older versions of sinon.js, a helpful javascript testing tool which lets you mock up and stub out objects, do not work with jquery 2.0.  Even though 2.0 is API compatible with the 1.x series, apparently some different stuff happens under the covers.  This is an issue for me because a few months ago, I followed these instructions to set up our testing infrastructure, and used sinon.js version 1.4.2.  That worked fine with jquery 1.8.2, but when I upgraded everything, tests where I mocked up server calls failed–the backbone model’s parse method was never called.

The answer?  Use at least version 1.7.1 of sinon.js.

Dynamic Languages Javascript Testing | moore |