My source code is really valuable to me. So I like to secure it as much as possible. GitHub does a good job of securing things on their end. I use SSH to pull and push my code so that it is securely transmitted over the network to my computer.
However, there is still a potential problem with having a single password to log in to the GitHub website. That log in also allows access to your code. If someone wanted to pull from one of my repositories, they would have to have my SSH private key (and password) which is on my computer. If they somehow figured out my password, they could just log in from anywhere. How can I stop that from happening? Obviously, generating a random, unique password using a password generator like 1Password will help. But that isn’t enough, since someone could stand behind you and watch you type it in on your computer or phone, then later impersonate you.
What I need is Two Factor Authentication. This makes it so that an attacker needs both my password AND a physical device (i.e. the phone I carry around.) That device either receives an SMS with a code or has a synchronized authenticator app that generates a code that I enter in my password. It is easy to enable this on GitHub and I recommend that everyone do so.
To enable Two Factor Auth, follow the instructions at: https://help.github.com/articles/about-two-factor-authentication
Note that for ongoing authentication, I personally use Google Authenticator but others like to use Authy. You can also use SMS to get your codes if you prefer.
I have my backup recovery codes stored away in case of emergency. These are useful if you lose your device – you have to make sure these are also kept secure.
If you’re in the Washington DC area, please come to my talk about Developing for Google Glass at DevIgnition. I’ve only got 30 minutes, so it will be a whirlwind tour but it should be enough to get you started on the premiere platform of the Wearable Generation(TM).
Also, I wrote up a blog post on the savvy apps blog discussing my initial thoughts on the GDK.
UPDATE: The slides are available in the Glass section of my blog.
If you make iOS apps, sometimes it is helpful to verify that the archive you made via Xcode has what you expected inside of it. Lagunitas is a tool to help you do that, courtesy of @soffes.
I just tried it out and it works great. Here are some usage notes:
I use rvm so I have a nice Ruby 2.0 environment on Mountain Lion, so I installed the Ruby Gem for Lagunitas like so:
rvm use 2.0
gem install lagunitas
After that, I changed to the directory that had an IPA I was interested in.
I fired up irb:
Once in irb, I required (which is like an import) lagnuitas and tried to inspect the app inside the IPA:
ipa = Lagunitas::IPA.new("myAwesome.ipa")
app = ipa.app
I was confronted with this error message:
NameError: uninitialized constant Lagunitas::IPA::SecureRandom
And so I guessed at the right require:
Voila – that fixed it and everything went well after that:
app = ipa.app
=> #<Lagunitas::App:0x007ff002905570 @path="tmp/lagunitas-e5c477f91f8777d76f2c9e79ececd358/Payload/myAwesome.app">
Time flies. We’re having our fifth iOSDevCampDC already! Well, technically it was iPhoneDevCampDC, then iPadDevCampDC, then iOSDevCampDC after that. The 2013 version is happening this Saturday, August 24 at Viget Labs. I have to give a lot of thanks to Viget since they’ve hosted us 4 out of the 5 years!
We sold out again this year. Something we’re trying is to not have any sponsors to simplify things a bit. We’ve appreciated all the sponsors we’ve had over the years, but inspired somewhat by iOS 7, we’re trying to make things simpler and flatter. The website (iosdevcampdc.com) is another thing that is a bit different – we’re going with a one page design this year to see how that goes.
Well – I’ll see everyone who got a ticket on Saturday. Feel free to say hi. Hopefully it will be our best one yet!
Sometimes the Android Emulator that you just started up does not show in the Devices list in the DDMS Perspective of Eclipse. If that happens to you (like it just happened to me), then do the following in your command line to get it to show up:
You should see this output:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Then your Emulator instance should show up in the Devices list.
I’m not exactly sure why this happens, but it has to do with adb (the Android Debug Bridge) going into a bad state. The kill-server/start-server combo serves to reboot it and back into a good state.
Good news! I’ll be giving this talk again at AnDevCon San Francisco in November. I’ll be updating it based on questions I received in Boston, recent developments from Google and Intel. Also there are some things that I wanted to include in the original that I’ll be adding. Come check it out live in San Francisco!
Two weeks from now, on May 31st, from 2:00 PM to 3:15 PM, I will be giving a talk about the Android Emulator at AnDevCon Boston. It is titled “Becoming More Effective with the Android Emulator”, but in order to spice things up a bit, I’m going to give a it a MythBusters-style twist. The subtitle is “Android Emulator Myths…Busted!”
I’ve really fallen in love with the Android Emulator as part of my Android development workflow. I find it a lot easier to work with than switching over to a device, especially with the advancements that have been made in the past year or so. So I really want to share my insights in how to make it work well for everyone. I’m hoping it encourages more people to discover how useful the Emulator is as a tool in the Android toolbox and use it more regularly.
If you want to attend a pure 100% Android development conference, definitely check out AnDevCon. I’ve been to the previous two events and really enjoyed all the content as well as meeting more of the Android community in person. Also, if you use code “DELAROSA”, you should get an additional $200 off the registration.
Hope to see you there!
Here’s a paraphrased quote from the Q&A session after the What’s New in Android Tools session at Google I/O 2013:
We will continue to support Eclipse. We are focusing on the Android Studio to get that up to speed. We will be changing the build system of ADT (Android Developer Tools) in Eclipse to use Gradle (from Ant.)
– Xavier Ducrohet, Android Developer Tools Team
Here’s my quick notes on a git workflow to create a branch, merge and clean up:
Create a branch named “x”:
git checkout -b x
git branch x
git push origin x
git push -u origin x
git checkout x
git push --set-upstream origin x
Merge a branch “x” back into master:
git checkout master
git merge x --no-ff
Note that this creates a merge commit to make it easier to find where branches are merged into master.
Clean up branch “x”:
git branch -d x
git push --delete origin x
Update [2013-05-15]: Used the “-u” option with git push so we have one less line when creating a branch. Thanks to @jdriscoll for that tip.
Update [2013-07-11]: Used the “-b” option with git checkout so we have one less line when creating a branch. Thanks to @bobz44 for that tip.
I’ve been starting to use calabash-android, which is a way to run cucumber tests on Android. It requires Ruby Gems and Xcode Command Line Tools on Mac, which installed fine. However, when I ran the first sample test, then I noticed the app did not start. I looked at the output and saw that this error showed up:
App did not start (RuntimeError)
I looked around for the solution and did not find, so I tried a few things. It turns out to be an easy fix. In your Android app’s manifest, aka AndroidManifest.xml, include the line:
<uses-permission android:name="android.permission.INTERNET" />
inside of the manifest tag, after your application tag.
Why does this work? The reason is because Calabash-Android (and Cucumber in general) uses HTTP to communicate between the host computer and the target application. Since Android apps do not have permission to communicate via HTTP by default, the test fails to start.