Change Preorder Text on Storenvy

Happy Nerdcore storefront with swapped text

Storenvy is a great option if you want a free online store.
We've been using it for our geeky fashion business, Happy Nerdcore, for the last several months. It works great, but we had to do a little hax0ring to make it fit out needs.

Storenvy has a cool 'preorder' flag that you can set on inventory. It communicates to the customer that it will take a little longer to ship. We wanted to use this flag to indicate which items in our store were made to order, and hence would take longer to deliver.

Luckily Storenvy lets you add your own CSS to your store, so we hacked in our own text.

  1. Go to Admin Panel -> Storefront -> Theme -> CSS Mode
  2. Tweak this CSS to match your color scheme and desired text /* Update category pages / .product .preorder.flag.status { background-color: #FFF; color: #FFF; / match colors to hide old text / width: 130px; / adjust width to fit new text */ }

    .product .preorder.flag.status:after {
      content: "Made to order"; /* new text */
      position: absolute;
      top: 8px;
      left: 8px;
      right: 0;
      bottom: 0;
      color: #000; /* new text color */
    }
    
    /* Update product detail pages */
    #product .preorder.status {
      background-color: #FFF;
      color: #FFF; /* match colors to hide old text */
      position: relative;
    }
    #product .preorder.status:after {
      content: "Made to order"; /* new text */
      position: absolute;
      top: 8px;
      left: 8px;
      right: 0;
      bottom: 0;
      color: #000; /* new text color */
    }
    
  3. Save, reload, and profit!

Resize Photos on an iPhone Without an App

the iOS crop tool

You took a cool photo of an awesome street vendor hot dog and you want to share it, but you're on 3G and your phone has an 8 megapixel camera. Or worse yet, you took a panorama that's like 60MB.

The iOS photo editor has a crop tool, but no resize tool. You could install an app to resize the image, or you could follow these easy steps:

  1. Open your awesome photo in the photos app.
  2. Take a screen shot by pressing the power and home button at the same time.
  3. Navigate to the screen shot in the photos app.
  4. Crop the iOS user interface and black bars off of the photo.
  5. Share your new, much lower resolution photo. It yields ~250KB square photos and ~100KB panos on my iPhone 6.

This works, but it's terrible

  • The screenshots are PNGs. PNG is a terrible format for photographs.
  • It leaves behind a couple 3MB intermediate images.

But hopefully it gets you out of a pinch!

Jekyll Static Website on Google Cloud Storage

Google Cloud Storage and Jekyll

Years ago, we built websites by hand editing HTML files and FTPing them to our web server. It was painful. Content management systems like WordPress and Joomla! made authoring content easier, but with them came hosting complexity and scaling challenges. Nobody wants their site to go down on its most popular day.

Enter Jekyll. It's like we've come full circle. Jekyll is a framework for generating static HTML sites. It combines the productivity of templating and markdown syntax with the simple hosting of hand edited HTML.

This blog entry goes through setting up yay.dinopacks.com, a Jekyll static website, on Google Cloud Storage. It also covers scripting updates.

Why Google Cloud Storage?

Jekyll outputs HTML, which you can host pretty much anywhere. You could blow the dust off of your WS_FTP CD-ROM and upload it to your ole' web server, but there are much better options these days.

You could use GitHub pages, Firebase Hosting, Divshot, or many others. This blog post isn't meant to be a hosting provider comparison, but here are some cool things about Cloud Storage to keep in mind:

  • Zero configuration consistent, fast delivery from global edge caches
  • Do you have a static website with terabytes of rarely accessed content? Nearline storage could save you a ton of money
  • Scales to really, really huge static websites, like many terabytes
  • Fine grained access control to individual objects
  • Do you upload a lot of video from mobile connections? The REST API has neat features like chunked multipart upload of big objects.

In any case, it doesn't take long to try out a hosting provider. So, evaluate a few, and pick the one that fits your needs best. In the mean time, let's get yay.dinopacks.com up on Cloud Storage.

Steps

Verify your domain and set up DNS

Before we can create a Cloud Storage bucket for yay.dinopacks.com, we need to prove to Google that we own the domain. Do this from Google Webmaster Tools. There are many ways to verify your domain. Here we'll use the DNS method because yay.dinopacks.com is a brand new domain name.

  1. Log into webmaster tools with the same account you plan to use for Cloud Storage.
  2. Click 'Add Property' and type in your domain name.

    add property

  3. Select the 'Alternate methods' tab, 'Domain name provider', and then 'Other'

    select dns

  4. Add the provided TXT record to your domain name and give it a few minutes to update.

  5. Since we're already editing DNS settings, take the opportunity to add a CNAME alias that points to c.storage.googleapis.com

  6. Return to webmaster tools and click 'Verify'.

Set up a static website bucket on Google Cloud Storage

  1. Sign up for Google Cloud Platform, if you haven't already. The form asks for a credit card, but don't sweat it. Cloud Platform won't automatically bill you; the credit card is just verify your identity. Also, new accounts get a $300 free trial. This is plenty of credit to determine if Cloud Storage is right for your project.
  2. Go to the Google Developers Console and click 'Create Project'.
  3. From the project page, use the left side menu to navigate through Storage -> Cloud Storage -> Browser, and click the blue 'Create bucket' button. Name the bucket your domain name. I named mine yay.dinopacks.com.

    Create bucket

  4. Return to the bucket list and click the bucket menu. Edit default object permissions (NOT bucket permissions) and grant allUsers read access. This makes everything we add to the bucket publicly readable by default.

    make public

  5. Click the bucket menu again, but this time select 'Edit website configuration'. Set the 'Main page' to index.html and save.

Your bucket is all set up to serve a website. Time to put some stuff in there.

Initial deployment and test

Use the drag and drop features of the developer console to make the first deployment. This is an easy way to verify that everything is set up correctly.

  1. Build your Jekyll site

    $  jekyll build
    Configuration file: /Users/mimming/yay.dinopacks.com/_config.yml
            Source: /Users/mimming/yay.dinopacks.com
       Destination: /Users/mimming/yay.dinopacks.com/_site
      Generating…
    done.
    Auto-regeneration: disabled. Use --watch to enable.

  2. Browse to your bucket on the developer console and into drag the contents of \_site on to the page.

    drag and drop to deploy

  3. Once the upload finishes, visit the website.

  4. Celebrate a successful initial deployment.

Automate deployments

It's cool that you can drag files on to the bucket browser, but we're real developers. We want something we can automate. This is where scripting uploads with the Cloud SDK comes in handy. We could hack up a quick shell script, or integrate it with a build system like gulp.

Shell Script

  1. Install the Cloud SDK using the instructions for your platform.
  2. Authenticate your SDK

    $ gcloud auth login

  3. Use gsutil to upload your content. It has a bunch of commands, but stick with rsync for now.

    # -m use faster multithreaded uploads
    # -d delete remote files that aren't in the source
    # -r recurse into source subdirectories
    $ gsutil -m rsync -d -r . gs://yay.dinopacks.com

  4. Wrap these commands in a tiny shell script. I call mine deploy.sh

    #!/bin/sh
    jekyll build &&
    gsutil -m rsync -d -r ./_site gs://yay.dinopacks.com

  5. Run deploy.sh, see changes go up to the cloud, and celebrate the upload of another dinosaur picture.

Gulp.js

Some of us are build system hipsters. If you're cringing at the thought of a directory of utility shell scripts, you're probably already using gulp.js to build your Jekyll site. If you're not, you should channel your node.js mojo and check it out.

It turns out that gulp.js plays well with the Cloud SDK. Add a deploy task to your gulpfile.js:

var gulp = require('gulp');

gulp.task('deploy', function() {
  var spawn = require('child_process').spawn;   
  var jekyll = spawn('jekyll', ['build'], {stdio: 'inherit'});

  jekyll.on('exit', function(code) { 
    if(code === 0) {
      require('child_process').spawn('gsutil',  ['-m', 'rsync', '-r', '-d',
'./_site', 'gs://yay.dinopacks.com'], {stdio: 'inherit'});
    } else {
       process.stdout.write("Build failed. Exit code: " + code);
    }
  });
});

Run gulp deploy. See more changes go up. Celebrate a world with even more dinosaur pictures.

Note: The weird callback thing is in there because we're chaining child processes. It tells gulp to wait for Jekyll to exit successfully before attempting to push to Cloud Storage. You can learn more about this pattern in the gulp.js reference docs.

Conclusion

And just like that another dinosaur themed blog is on the Internet, and this one is backed by Cloud Storage. You created a bucket, configured it to serve public web traffic, and uploaded content. Then you crafted some scripts to make publishing updates easier. And, you celebrated dinosaurs a little along the way.

If you have questions or comments, please tweet at me =]

Google Glass and the Twiddler 3

Glass, now with a Twiddler and VimTouch

Update: Greg Priest-Dorman tipped me off about an issue with these instructions. XE12 has a bug that causes keys to repeat if you type quickly. I'm quite slow on my Twiddler, but I was able to reproduce it with this command:

$  adb shell input text "abcdefghijklmnopqrstuvwxyz-0123456789"

Which yields this

repeated keys on XE12

Greg reports that XE8 works well, but downgrading that far is tricky. I'm going to experiment with flashing earlier versions and update this post with my findings.


Voice commands are perfect for commands, but something I've always dreamed of doing on Google Glass is taking notes. The Twiddler 3 seems like the perfect input device, and we all know that the best text input software is Vim.

Getting all of these to work together took a little bit of hacking. This blog entry guides you through the process of pairing Glass with the Twiddler 3, and using it to type your first words into VimTouch on Glass.

Here's a summary of what's involved:

  • Root and downgrade to XE12
  • Disable automatic updates
  • Pair your Twiddler 3
  • Install and run VimTouch

Warning: This tutorial includes steps that will void your Google Glass warranty. Proceed at your own risk. If you accidentally brick your Glass, don't complain to me! :)

Root and downgrade to XE12

Current versions of the Glass operating system such as XE22 do not pair with Bluetooth HID devices like the Twiddler. However, older versions that were based on Android 4.0 Ice Cream Sandwich do play well with them. Before we can pair Glass with the Twiddler we need to downgrade to XE12 and disable automatic system updates.

Download XE12

Why are we downgrading to XE12? Because it was the highest version based on Ice Cream Sandwich. It has the most features and bug fixes included. You can also use XE10 or XE11, if you prefer.

All of the boot loaders and system images for Glass are available from the System and Kernel Downloads page in the official Glass documentation. Scroll down past the warnings and download signed-glass_1-img-947604.zip and boot.img.

glass system image downloads

Root and downgrade

Now the scary part: flash the rooted bootloader and downgrade to XE12. This is the step that voids your warranty and could brick your Glass. It also erases any data on Glass, so download your photos and video before flashing.

The instructions for flashing these images to Glass is on the very same page. Run these commands using the adb and fastboot tools included with the Android SDK. These instructions work best from Linux, so flash from there if possible.

Note If you're flashing from a Mac, Glass might crash after each fastboot flash command. If this happens, take a deep breath, power cycle Glass, and use adb reboot bootloader to get back into fastboot. Proceed to the next image.

# enter fastboot mode 
$ adb reboot bootloader            

# verify Glass is in fastboot
$ fastboot devices 

# acknowledge the warning
$ fastboot oem unlock
# actually unlock the bootloader
$ fastboot oem unlock

# flash the rooted bootloader
$ fastboot flash boot boot.img     

# flash partitions with factory images
$ fastboot flash system system.img
$ fastboot flash recovery recovery.img

# reboot into normal mode
$ fastboot reboot

Your Glass is now running XE12. You should see the XE12 log in screen.

Don't log in yet. You need to disable updates first.

Disable automatic updates

Once you log in, Glass automatically updates to the latest version. You don't want this, so we need to disable updates. Unfortunately, we need adb access to disable updates. You can work around this, but it requires some silly tricks, and an wifi network that you can disable quickly.

  1. Set up a temporary wifi network. I used the portable hotspot feature of my mobile phone.
  2. Use the Glass setup page to log in to your account. Once you're logged in immediately disable your wifi network.
  3. Swipe to Settings -> Device Info. Enable USB debugging (adb).
  4. Delete GlassUpdate.apk to disable automatic updates, and restart Glass.
$ adb root

# delete the automatic update app 
$ adb shell rm /system/app/GlassUpdate.apk

# see if Glass already started updating
$ adb shell ls -al /cache
-rw-r--r-- app_5    app_5     5416530 2015-05-24 23:33 ...glass_1-ota...zip
drwxrwx--- root     root              1969-12-31 16:00 lost+found

# if it is, delete the zip
$ adb shell rm /cache/...glass_1-ota...zip

# reboot to kill any remaining running processes
$ adb reboot

Automatic updates are now disabled. You can add your primary wifi network to Glass.

Note: This is a pretty aggressive way to disable updates. I tried other techniques, like disable com.google.glass.update, but nothing else I tried persisted across restarts. If you figure out a better option, please let me know.

Pair your Twiddler 3 with Glass

Pair the twiddler

The built-in Glass settings software does not know how to pair with Bluetooth HID devices, but HY and PY from the Glass team showed us how to do this in the Hacking Glass session at Google I/O in 2013.

  1. Get your a copy of Settings.apk. You can build it from source or download a binary from a trustworthy source.
  2. Side load Settings.apk and fire off an intent to start it up.

    $ adb install ./Settings.apk
    $ adb shell am start -S com.android.settings/.Settings

  3. Turn on your Twiddler, and reset Bluetooth pairing with the special chord N+S ROOO.

  4. Awkwardly use the touchpad to move around the settings app. Go to Bluetooth, scroll down to the Twiddler, and tap to pair. If you get stuck for some reason, use adb input keyevent to simulate arrow key movement.

Fix the settings card

broken settings card

At this point, you may notice that the settings card is broken. You have two apps that respond to the settings intent, but the intent chooser is broken in XE12. To work around this, you can install an alternative launcher like Mike DiGiovanni's Launchy. Follow these steps to install it.

  1. Check out Launchy. It won't build out of the box. It depends on a bunch of XE16 GDK stuff, which does not work on your XE12 device.
  2. Edit MainActivity.java, and remove all of the code that refers to any class in the com.google.android.glass package.
  3. Build the apk, and side load it on to your Glass.

You can now tap through the Glass main menu to start Launchy, and Launchy can start Glass' default settings app.

Install and run VimTouch

vim on glass

At this point we have a Glass running XE12 with a paired keyboard, but none of the built in software responds to text input from a keyboard. To make your Twiddler useful on Glass, you need a keyboard friendly app. What better app to install than the Android variant of Vim?

Clone VimTouch, build it from source, and install it on your Glass.

It runs great, and you can verify your keyboard input right away. It also shows up in Launchy, so you can start it that way in the future.

Conclusion

Is your Glass still working? Great! You've rooted it, downgraded it, disabled automatic updates, and typed characters into the best text editor in the world. Congrats!

But the story isn't over yet. Launching VimTouch from the touchpad is a little bit clunky, and the Glass home app starts each time Glass wakes up. It's not a useful note taking device yet. We need a way make a sticky text editor that continues across sleep cycles, and a way to launch apps from the Twiddler.

I've worked out solutions for both of these, but they're a story for another blog post. If you're interested in a writeup, please tweet at me.

A faster way to copy your Raspberry Pi SD cards on OS X

A Raspberry Pi with some SD cards

The Raspberry Pi is awesome. One of the reasons that it's awesome is because it's so newbie friendly, and has great docs. For example, it has a great guide on creating an SD card image from OS X.

But, that guide does have one problem. The way they tell you to use the dd tool results in a very slow copy.

Default Instructions

Here's what happened when I followed the instructions to install Raspbian on a cheap SD 16 GB SD card.

mimming@femputer:~$  sudo dd bs=1m if=2015-05-05-raspbian-wheezy.img of=/dev/disk2
Password: correcthorsebatterystaple

3125+0 records in
3125+0 records out
3276800000 bytes transferred in 2903.165983 secs (1128698 bytes/sec)

2903 seconds? That's like 48 minutes. That's almost an hour! But, but, but I want to be hacking sooner than that.

Targeting rdisk

Luckily there's another way! OS X provides /dev/rdisk#. The r stands for raw and provides a more direct interface with the SD card. In this case, more direct = more faster.

mimming@femputer:~$ sudo dd bs=1m if=2015-05-05-raspbian-wheezy.img of=/dev/rdisk2
Password: correcthorsebatterystaple

3125+0 records in
3125+0 records out
3276800000 bytes transferred in 652.856126 secs (5019176 bytes/sec)

The same copy took just over 10 minutes. Not too shabby.

Bigger Chunks

Some Stack Overflow answers indicated that using bigger chunks might speed things up even more. I gave it a try.

mimming@femputer:~$  sudo dd bs=10m if=2015-05-05-raspbian-wheezy.img of=/dev/disk2
Password: correcthorsebatterystaple

312+1 records in
312+1 records out
3276800000 bytes transferred in 653.281030 secs (5015912 bytes/sec)

The result is almost exactly the same. It seems that block size does not matter too much.

A tip about dd progress

While dd is a neat tool, it's hardly verbose. Sometimes it's hard to tell if it's working hard, or if the process is hung (which can happen if your computer goes to sleep).

You can query it for a status update by pressing CTRL + T.

Thanks to that goes to this superuser answer.