Thursday, September 24, 2015

Migrating from GitHub to AWS Codecommit

At work, we recently made the move from GitHub to AWS Codecommit for our private repositories. There’s lots of tradeoffs moving to CodeCommit at this time, like the loss of a web UI, wikis, issue tracking, pull requests, etc. But we made the move as part of our company-wide cost saving measures, as we found CodeCommit to be quite a bit cheaper than GitHub (like free, since we fall into the free tier at this point).

So, how did we migrate all of our GitHub repositories at once? Well, we didn’t do it by hand, that’s for sure.

First, we needed to generate a list of all of our GitHub repositories. We used the GitHub API to get the list, which I pushed into a text file, repos.txt:

curl --silent -u $GITHUB_USER:$GITHUB_PASSWD$GITHUB_ORG/repos?per_page=100 -q | grep "\"name\"" | awk -F': "' '{print $2}' | sed -e 's/",//g'

Note: If you have two-factor authentication enabled in GitHub, you’ll need to get a personal API token to use in place of your password. You can generate this token here.

Next, we used a script to loop through all the repositories, clone them locally, create a repository in CodeCommit, and finally push to CodeCommit. You’ll need the aws cli tools installed locally. I used ~/_trash as my local working folder.

cd ~/_trash
while read r; do
  echo $r
  aws codecommit create-repository --repository-name $r --region us-east-1
  git clone --mirror$GITHUB_ORG/$r.git 
  cd $r.git
  git push ssh://$r --all
  git push ssh://$r --tags
  sleep 10
  aws codecommit update-default-branch --repository-name $r --default-branch-name master --region us-east-1
  cd ..
done < ~/dev/utility-scripts/aws/codecommit/repos.txt

We ran through this a few times before pulling the trigger for real. To delete all the repositories in CodeCommit quickly during our testing, we used this script:

while read r; do
  echo $r
  aws codecommit delete-repository --repository-name $r --region us-east-1
done < ~/dev/utility-scripts/aws/codecommit/repos.txt

Once we had all of the repositories moved, we just needed to repoint the origin for our local repositories to CodeCommit. After a few weeks of making sure we had everything, we backed up all of our GitHub repositories one last time using this script, and then we deleted all of our repositories in GitHub.

while read r; do
  echo $r
done < ~/dev/utility-scripts/aws/codecommit/repos.txt

Note your GitHub account or generated token will need to have the delete_repo scope in order to delete a repository.

You can find all the scripts in this Gist.

Tuesday, September 8, 2015

Google OnHub - initial impressions

My Google OnHub was delivered this past weekend. Here's my initial thoughts:

  • Packaging was very nicely done. Hardware these days comes in some really beautiful boxes that are well designed. I'd rate packaging 10/10.
  • There are no instructions in the box. None. It was pretty intuitive to get it out of the box and figure out what to do, but I did hear from a friend that he wasn't sure how to get the outer shell off. He didn't want to break it by pulling or twisting the wrong way.
  • Initial setup using an iPhone 6 with iOS 9 beta failed. After connecting to the setup Wifi network, the Google On app would never find the OnHub. I worked on this for about 45 minutes before giving up and trying the setup on an iOS 8 device. Setup worked perfectly.
  • Once I figured the whole iOS 9 thing out, setup was so simple. Great job on making it painless!
  • Wifi signal strength in our house has had a major upgrade. Corners of the house that were always very weak signal now have full strength connections.
  • Throughput for both wireless and wired clients test out with speeds matching our service from Comcast.
I also like that I do not have to be connected to the local network in order to manage the OnHub. So, when someone at home can't connect, I can open the OnHub app anywhere I am and manage the network (so long as my home Internet connection is up). That's pretty cool!

Friday, August 28, 2015

Updating battery firmware on Phantom 3 intelligent batteries

A few days ago I picked up my first drone, a Phantom 3 Professional. It's so much fun!

Last night I went through the firmware update process, following the instructions from DJI. The instructions were clear enough to get the firmware updated on the aircraft and the controller, but the battery firmware was a bit confusing. Here's the part from the instructions:
The Intelligent Flight Battery is upgraded during the aircraft firmware upgrade process. It is recommended to keep the upgrade package files in your SD card. The upgrade will start automatically after power cycling the aircraft.
I assumed (correctly) that my battery firmware was updated, but I wasn't 100% certain how to upgrade my spare battery firmware. To do that, you need to:

  1. Put the spare battery into the aircraft.
  2. Place the firmware update package in the root of the SD card. You can just leave it there.
  3. With the controller off, turn the battery on. The upgrade process will kick off.
  4. Once you here a long beep, short beep, pause, the upgrade is complete.
Rinse and repeat with all of your spare batteries.

Sunday, June 3, 2012

Powershell AuthorizationManager check failed

While debugging some Powershell scripts today, I started getting an error:

AuthorizationManager check failed.
At C:\Users\pkearne\setupPLT.ps1:6 char:14
+ ./logging.ps1 <<<<
    + CategoryInfo      : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

After some web searching, there seems to be two primary reasons this happens:

  • An empty Powershell profile script
  • WMI service not running

Neither of these cases was true for me. However, the first one pointed me in the right direction. Somehow a script I was calling out to (logging.ps1) had it’s contents removed. Had the file been deleted, the error would have been that the cmdlet, function etc was not recognized. But having the file present but empty gave the misleading error “AuthorizationManager check failed”.

So, if you are getting this error and everything else looks correct, look and see if something similar is causing your problem.

Tuesday, November 29, 2011

Remember, controller classes need to be public

File this one under Duh! I was troubleshooting a routing issue I was having with a portable area in ASP.Net MVC. For some reason I kept getting a 404. The solution was pretty big, so I created two new projects to try and isolate the problem.

I created a new web project and a class library for the portable area. Added my routes to the area, created a new class, renamed the class MyController, wired it all up, and got the same thing.

I installed Glimpse to see what routes were being hit. But Glimpse only works if ASP.Net handles the request, and since it was a 404, I couldn’t see the Glimpse data.

So I installed Phil Haack’s awesome route debugger. The route debugger has a catchall route, so even if the request would result in a 404 it will return you back the debug information. I could see that the route was being hit, but it still 404’ed.

I set breakpoints. I added some logging. Nothing would cause my controller action to get executed.

Then it struck me. Visual Studio by default creates new classes without an access modifier, and when no access modifier is specified, the default is internal. MVC needs controller classes (and the action methods) to be public so they can be constructed via reflection.

using System.Web.Mvc; 
namespace TestArea.Controllers
   public class MyController : Controller
       public ActionResult Index()
          return View();

The really sad part is I just helped a colleague solve the exact same problem the week before.

I don’t know why Visual Studio defaults to not putting a access modifier on new classes. I always prefer to be explicit with such things.

Thursday, May 12, 2011

VerificationException: Operation could destabilize the runtime

I came across this exception this morning while playing with RavenDB. A quick search shows several people have seen this exception but not a lot of solutions.

I’m not sure why, but this exception in my case was related to IntelliTrace. I turned IntelliTrace off and the exception went away. Weird.

BTW - this isn’t related to RavenDB. According to this post, the issue is a bug in IntelliTrace.

Tuesday, May 10, 2011

VB6 and .Net Interop Fun

A friend of a friend asked me to help with a project. He is a VB6 developer. Still. But he needed to incorporate a .Net component into the VB6 application in an easy way. So I’ve been helping him out, building up a .Net control using the Microsoft Interop Toolkit. It’s a free add-in to Visual Studio that takes away a lot of the complexities in building COM interop components in .Net.

I learned something painfully recently while helping out:

If your .Net control throws an exception, VB6 will report that to you as an “out of memory” error.

That’s it - no details, call stack, or anything else about the actual exception. Misleading and frustrating. Not that I would expect VB6 to give me the call stack from .Net, but “out of memory” is not only unhelpful but it is disinformation.

I should have remebered this one. We were getting the “out of memory” error in VB6 in design mode and couldn’t figure out what the problem was. The error popped up immediately when opening the form designer in VB6. After much trouble trying to get VB6 to actually tell us what the problem is (we never got any information out of it, even after enhanced interrogation using WinDbg), it was real simple - we had a bug in a property setter. When the control was instantiated, VB6 was calling the setter, getting the exception, and then barfing with the incredibly unhelpful error message.

My friends will inevitably laugh and make fun of me for playing with VB6 still. That’s fine. I’ve found the experience has led me to develop additional skills and learn more about .Net development along the way.