Get off of my cloud (2)

July 19, 2012

I’m still trying to disentangle myself from the various accounts that I was instructed to set up for the Acquia Drupal course.

My Acquia dev cloud account:

  • Of course, the invoice date I referred to at the end of the previous post wasn’t 7th October 2012, it was 10th July 2012, because we’re in America (oh, no, wait, we’re not). When I log in, my Billing Information page now says the invoice has been sent. I haven’t received anything that looks like an invoice.
  • I did receive an email warning me about scheduled maintenance that would affect “my sites”, despite the fact that they should know I don’t have any sites on their cloud any more.
  • As far as I can tell, there’s no way to delete my Acquia dev cloud account completely.
  • I can’t even remove my credit card details from my account. Going to ‘Payment Settings’ shows one credit card; clicking on ‘Edit’ for that card only gives me an opportunity to add a new card (not even to edit the old one).

Just to reiterate: they are storing my credit card details without giving me any way to update or remove them. I’m pretty sure this contravenes the DPA.

My account with Udemy:

  • I unsubscribed from all the Udemy emails (following the link in the email); once that had been confirmed, I went to my account settings to tick the “don’t send me any email alerts” setting (not sure how that was different from telling them not to send me any emails).
  • When it came to removing the account, there were two options:
    1. to detach the account from my Facebook account, or
    2. to delete the account altogether.

    I detached the account from my Facebook account, and set a password (as my account would be retained with my email address as username).

  • Once this had been done I then deleted the account completely. Thank goodness Udemy actually let me do this.
  • I then went to my Facebook account, checked the Application settings; the Udemy app was still listed as being authorised to interact with my Facebook account. Just to remind you, this app “needed” (wanted):
    • My email address
    • My profile info: description, activities, birthday, education history, interests, likes, location and work history
    • Friends’ profile info: Activities, interests and likes
  • I removed the app & deleted all app activity.

I don’t want to labour the point here, but I shouldn’t have to jump through all these hoops just to detach myself from a one-day training course; I didn’t think I was making that kind of commitment to any of the organisations involved when I signed up for the course. You might ask why it matters if we have unused accounts floating around all over the place, but I believe it does matter: it’s a potential security/privacy risk (though throwaway passwords probably minimise this risk); it’s wasteful (disk space may be cheap but it’s not infinite, and the energy required to run the servers is non-zero); but above all, it’s untidy: it offends my sense of order. I realise this is going to make me sound like some kind of philosophical neat-freak, but I don’t want to clutter up the global information space with stuff that I’m not using.

Enough complaining. I’m going to tidy up my hard drive.

Get off of my cloud

July 12, 2012

A couple of weeks ago I went on a “Drupal for Developers” training course given by Acquia. We were asked to bring laptops on which we had installed all sorts of software to allow us to import the pre-prepared Drupal site that we’d be working on, and there were dire warnings of what would happen if we hadn’t completed the setup before the session (“Please note that if you do not set-up and test your laptop before training, you may be forced to watch along on someone else’s machine so that we can all spend our time training and learning rather than debugging your individual set-up”).

Setting up

Being a conscientious type, I went through the mandated setup, step by step. First, I tried to install their “Dev Desktop” (an all-in-one server-on-your-desktop setup), but it didn’t work on Mac OS 10.5 — the documentation said it did, but I got the following error message:

Problem running post-install step. Installation may not complete correctly.

The error dialog also said that when reporting the errors I should attach two log files; only one of the specified files existed on my system. When I tried to launch the app I got the following error, which confirmed that installation hadn’t completed correctly:

Cannot load dll: @@INSTALL_DIR@@/common/lib/libmysqlclient.dylib

I emailed the trainers for help and they told me that there were “intermittent problems” with the Mac OS 10.5 version of their software. They asked me if I’d mind running their diagnostic script, also supplied with the software install; I tried to do this, but the diagnostic script didn’t work either. After a bit more to-ing and fro-ing of trying to get the script to find the required libraries, they recommended that I install MAMP instead… but the latest version of MAMP didn’t work on Mac OS 10.5 either. Sure, my fault for running an outdated OS, but frustrating nonetheless. I emailed the trainers again to ask if an older version of MAMP would suffice for Drupal 7, but didn’t get a very clear response; in the end, I decided to do the upgrade that I’d been failing to get round to for ages.

Once I’d upgraded to Mac OS 10.6, I installed MAMP, and went on to the next bit of the setup: to sign up for the “Dev Cloud” single-server Drupal hosting that the training company provided. In order to do this I had to give my credit card details and effectively subscribe to a year’s hosting for $165.40, but using a voucher code we’d been given to get 30 days’ worth of this hosting as a free trial. To be fair, the training company did warn us and apologise:

“You will need a credit card to complete this process. We’re sorry about that, but you will not get charged if you delete your cancel your account right after the training. (Or before 30 days is up!)”

but I can’t say I was happy about it. There were various minor annoyances with the sign-up process, too:

  • Filling in the registration form, I missed ‘state/province/region’ (probably assuming that it was only required for US addresses); when the form reloaded it had left in the credit card number (showing last 4 digits only, so it wasn’t valid when resubmitted) but cleared the CCV field and reset the expiry date; it had also unticked the mailing-list opt-out box, which is a pretty sneaky way to try to get the unwary to sign up for spam.
  • The “billing information” section had a mandatory “company name” field, but my personal credit card (which I had to use) isn’t registered to my work address, so I had to enter information which I knew to be false and hope that it didn’t prevent the payment from working.

Once I’d got the hosting set up, I went on to the next stage of the pre-course setup, which was to run through a “Hello Drupal” online course: “It should be pretty quick to do”, the instructions had assured us, so I’d assumed I could do this the day before the course (a day when in fact I was off work having been horribly sick thanks to my dear daughter bringing some kind of stomach bug back from nursery!).

In order to watch the course, I had to sign up for Udemy, an online training site, to watch “Hello Drupal”; this gave me a choice of setting up another account for a thing I probably wouldn’t want to use again, or signing up with my Facebook account. I chose the latter, but the Udemy app demanded rights that it surely shouldn’t need just to let me watch some training videos:

  • access to all my friends’ profiles
  • the right to post on my behalf
  • the right to “access my information at any time”

(Sorry, Facebook friends, if you get spam as a result of this. If it’s any consolation, Udemy are now sending me heaps of marketing emails, too.)

Having registered with Udemy, I discovered that “Hello Drupal” was three hours long; I’m afraid that at this point my conscientiousness was overridden by my utter despair at the prospect of trying to watch three hours of training screencasts when a) I didn’t have 3 free hours left in the day, and b) I just wanted to go back to bed and be ill in peace. I decided that I’d just have to go along early on the day (assuming I was well enough to go at all) and see what I could do.

On the day

On the day, it turned out that I was far from the only person who’d failed to complete the pre-course preparation: over an hour into the training time, we were still trying to get everybody set up. Some people were having trouble installing the software at all; others were having trouble importing the prepared site (not everybody had realised that there were two versions of the zip file, one linked from the middle of the Google Doc with the setup instructions in, the other linked from … I forget where, somewhere else); several people were finding that the prepared site was missing some of its images (a different set of images seemed to be missing from the two zipfiles); the Dev Desktop included drush, but it didn’t get added to the default path on Macs so people assumed it “didn’t work” (cue trying to teach Mac users who never use a CLI how to fix the problem…). As far as I could tell, nobody had watched the “Hello Drupal” screencasts, though that didn’t seem to matter.

There were useful bits in the training, though it all felt a bit rushed — partly because of the difficulties with setup; partly because the two trainers didn’t seem to have decided which bits they were going to demonstrate, let alone who was going to do each section (though to be fair this was the first time they’d given this course in this format); partly, I think, because there was actually just too much material to fit comfortably into one day even if we’d all started and proceeded smoothly. Annoyingly, we barely used the cloud hosting that we’d been told to sign up for (or indeed the version control that we’d been told to install Git for): nothing that we covered in the course couldn’t have been done just as easily on a local install of Drupal. There was a brief section at the end about development and deployment cycles where one of the trainers demonstrated how to use their Dev Desktop and Cloud Hosting to manage the process, but a) they could have demonstrated this without making the rest of us sign up, and b) they could have explained the cycle in general terms since most of us probably won’t be using their hosting (particularly as many of us were University IT people who would be using their college/department’s existing hosting setup).

I’m not talking here about “how to design a good training course”, though. I’m just talking about the bits and pieces, the admin, the places where the fail creeps in.

Setting down

So, a few days after the training, I finally found time to go and cancel my subscription. I started from the confirmation email I’d had originally, the one telling me that I’d signed up for a year’s hosting (with no indication whatsoever that the first 30 days were free):

You can find your invoices on your Billing History page. Invoices appear on the 11th of each month.
Order #: 19893

I clicked on the “Billing History” link, and got a 404. The URL was http://user/0/billing-history — OK, they’d forgotten to include the domain, easily done — so I added to the beginning … and got a 403. Back to the email to try the “Order #” link — this took me to another 403’d page.

When I actually found the page with my subscriptions on, I was pleased to see that there was a clear “Remove this subscription” link below the subscription:

Screenshot showing Acquia dev cloud subscription with 'Remove this subscription' link shown


However, clicking that link took me to a page which said:

For security reasons, Acquia does not currently support automatic cancellation of the janetmck+acquia subscription.

If you would like to remove this subscription, please contact Acquia Support either by email at [their support email address] or phone at [their US phone number] ([phone number] international).

I was sure that my colleague who’d been on the course with me had been able to cancel his subscription without having to email/phone the company directly (and I confirmed this with him by email), so I had another look round. This time I found the “cancel subscription” link, on a smaller hidden menu:

Screenshot showing Acquia dev cloud subscription, with action menu and 'Cancel' link shown.


So I clicked “Cancel subscription”, and this took me to “Step 1 of 2”:

Step 1 of 2

Step 1 of 2?

Clicking ‘Continue’ took me to “Step 2 of 2”: a page asking me to fill in their exit survey in order to cancel my subscription (“Complete this form to cancel your Acquia Cloud account”):

Screenshot showing step 2 of 2 in cancellation process for Acquia dev cloud - the exit survey

Step 2 of 2?

Fair enough; I filled in the survey and submitted it, expecting this to lead to a “thank you” and a confirmation that I’d cancelled… but instead I was bounced back to the Workflow page, except that it now sported an alert saying “Cancelling this Acquia Cloud account will permanently delete all of the sites and data associated with it”. That sounded ominously like the sort of warning you get when you haven’t yet cancelled — after all, giving you that warning when you’d already cancelled wouldn’t be much help, would it? Going back to the Subscriptions page showed my subscription still “Active” with a note beside it saying “Expires 06/20/2013 (50 weeks 5 days left)” — that also didn’t look particularly “cancelled” to me. So I went back to the “Cancel subscription” link, back to step 1, back to step 2 (the survey), and this time noticed that the survey had a note at the top:

Your Dev Cloud cancellation request will be processed shortly. Your site’s data will be preserved for one week. If you change your mind, contact Acquia Support to bring your site back. Thank you for your feedback. We greatly appreciate it.

So my cancellation request had been received, would (hopefully) be processed… but the subscription still showed as “Active”. I tried again to find the “Billing History” or “Order #” pages which should have been linked from the email, to see if I could reassure myself that the order and the having to pay lots of money had been cancelled, and found myself back on the same 403 Access Denied page… but this time with an alert at the top saying “Cancelling this Acquia Cloud account will permanently delete all of the sites and data associated with it.” In other words, they appeared to have just added this warning (which only makes sense to show before cancelling) to the general page template, whether it made any sense in context or not.

I still didn’t know if I’d successfully cancelled my subscription; I set myself a calendar alert to look again in a week (by which time, according to Acquia, my data should have been deleted). Fortunately, I got an email today which confirmed that my subscription “was cancelled successfully”. The email continued chirpily: “We’re sorry to see you go! We’re constantly improving our services, and hope you’ll check back the next time you need expert Drupal services.”

Out of curiosity, I checked back on the site to see if the subscription now showed up as “cancelled” or “removed”. Instead, the page for the individual subscription was an unfriendly 403: “Access denied. You are not authorized to access this page.” The page for the list of subscriptions was more informative: “Unable to display subscription listing. We were unable to find any subscriptions to which you have access. Please contact support, or make sure you are using the correct account.” Also quite unfriendly, but it did reassure me that I’d managed to cancel my subscription… until, that is, I realised that I could now see my Billing History page: “Your first invoice will be issued on 07/10/2012.” I sincerely hope it won’t.

Enough whinging: how would I fix these issues?

  1. Instead of all the complicated pre-course setup, do one of the following:
    1. Trust the trainees: Allow people to do their own local install of the necessary software: make it clear what this needs to do (‘you must be able to run Drupal 7’) rather than dictating what it needs to be (‘install our magic box’), so people can figure out if their not-quite-magic-box solution will do the right thing. Provide a pre-built site that could be imported into a local D7 install, accept that people have different setups, warn people that they won’t be able to have much help debugging their setup during the course, let them sink or swim on the day.
    2. Control everything: Provide laptops with all the software pre-installed and the site ready set up. Some users would have to use an unfamiliar operating system, but the trainers would have the advantage of knowing exactly what setup people were using.
    3. A bit of both: Offer attendees a choice between the two options above.

    Personally I’d go for the third option: allow confident developers/sysadmins to use the tools they’re familiar with, & trust them to sort themselves out; give the less confident, the lazy, the busy, and the people whose laptop fell in the bath two days before the course a ready-rolled system that they can’t mess up as easily (or at least one that you don’t have to learn your way around when they do).

  2. Be clear about prerequisites:
    1. If the “Hello Drupal” course is a true prerequisite, tell people at the earliest possible opportunity that they should work through it before the training, and tell them how long it will take, so they can schedule that in
    2. If it isn’t, make it clear that it’s optional and explain how it might benefit you — is it useful for orienting yourself a bit before the course? For getting up to speed with the terminology? Is it advised for people who’ve never done any Drupal before, but probably not necessary for those who have?
  3. Don’t make people have to give their credit card details to sign up for hosting that they don’t need. I mean, really.
  4. If you’re going to force people to sign up for something that they have to cancel afterwards, make sure the cancellation process is simple and clear. I’d expect it to go something like this:
    1. Find my subscription from the ‘subscriptions’ link/tab under ‘my account’.
    2. Click the ‘cancel’ button/link beside it
    3. “Are you sure you want to cancel?” At this point I should be told very clearly a) what happens to my data once I’ve cancelled, b) what happens to my payments once I’ve cancelled, and perhaps c) what to do if I realise I’ve made a mistake.
    4. Click “Yes, I’m totally sure”.
    5. Receive on-screen confirmation that my cancellation request has been accepted, and an assurance that this will be confirmed by email (for bonus points, tell me what email address that confirmation is going to).
    6. “Please tell us why you’re cancelling.” This is a courtesy. I’m usually happy to do it if I’m only asked one or two questions.

The sad thing is that there was plenty of good material in the actual course, but I came away with an overall impression of a series of irksome processes that didn’t quite work seamlessly: I’m sure that’s not how Acquia wanted to come across in their training, particularly given that the training was so obviously intended to double as an advertisement for their hosting; I’m sure it’s not the impression they wanted to give of Drupal, either. But personally I feel that training should be an opportunity to get away from the contingencies of daily work and concentrate solely on the thing you’re trying to learn: you shouldn’t have to wrestle with “oh, it always gives that error message & we haven’t got time to figure out why”, or “we can’t upgrade that until the next financial year”, or any of the other thousand natural shocks that web development is heir to. That’s why it matters if the admin is a mess.

But perhaps I’m over-optimistic in assuming it’s possible to get away from those things, even for a day. Perhaps, despite everybody’s best efforts, the contingencies always creep in; perhaps we should just treat every new irritation as an opportunity to get better at dealing with irritations.