Category Archives: Programming

Enable Two-Factor Auth in GitHub

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.

Git branching

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 pull
git merge x --no-ff
git push

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.

Why you should participate in Stack Overflow

If you’re reading this blog, you’re probably a programmer and you probably use Stack Overflow daily. It launched back in 2008 and I’ve been using it, sometimes without knowing it for these past few years. This year, I decided to consciously contribute back to Stack Overflow and also try to rack up 1000 reputation points, aka rep. As of this writing, I’m up to 2,106 rep and very happy about my experience contributing. So… why should you participate on Stack Overflow and what tips can I offer on how to do that?

Save the programmer, save the world (or Why you should participate)

Stack Overflow (SO) shows up frequently in Google searches. Google any Android exception or iOS error message and you’ll get at least one SO hit, if not several. It is the programming world’s equivalent to Wikipedia, being somewhat of a canonical resource for programming questions and answers.

Programmers seem to turn to SO first nowadays, even before asking other programmers or consulting documentation. Why is that? Well my theory is that we don’t want to interrupt other people and documentation can be hard to parse. On the other hand, a lot of times you can find either working code or good pseudo-code in an SO answer. If you think this is just my opinion, consider that SO has 15,000,000+ software developers visiting every month.

SO is also a great case study in gamification. Most programmers I know are avid game players (both board and video), so incentivizing us to contribute by rewarding us with points is a natural fit with our brains. SO has tuned this game mechanic over the years to encourage good questions, great answers and discourage spam, which is the natural enemy of any online community. I confess that some nights I would stay up later than I would so I could try to answer just one more question, which might lead to a few more rep.

Stack Overflow icon

Those are the obvious reasons, but there are deeper, more meaningful ones to contribute to Stack Overflow:

SO is good for your resume. Before I interview a potential programmer to join my team, I always check their SO profile, not just to see how much rep, which is a rough measure of how much they participate and how valued their contributions are, but to see how well they communicate. Programmers don’t just write code, but they also have to discuss potential problems, solutions, relay their progress, etc. Reading someone’s set of SO answers is a proxy for that. In past years, I would have said that I would go to read their technical blog, but those are sadly in decline due to a combination of SO, Twitter, Google+, App.net, etc.

You will learn as a consequence of answering questions. Even if you already know it, having to communicate an answer clearly to someone else will ingrain that knowledge into your brain further. Sometimes it is good to find a question that has interested you before that you can do a bit of research into and you’ll satisfy your curiosity while answering someone’s question.

“I play the Stack Exchange game happily alongside everyone else, collecting reputation and badges and rank and upvotes, and I am proud to do so, because I believe it ultimately helps me become more knowledgeable and a better communicator while also improving the very fabric of the web for everyone. I hope you feel the same way.”
- Jeff Atwood in The Gamification

Best of all, you will be helping people. We exist in a larger community of programmers and I think it is a good policy to help others when you can. Whether you subscribe to The Golden Rule, you should consider that if you use open source, if you rely on the answers in Stack Overflow, that it took someone willing to help to write those things that you use when you write your own apps.

Now the hard part… (or Tips on participating)

When you first register with Stack Overflow, you’ll start out with 1 rep. Which means that the only thing you can really do is ask a question or answer one. You can suggest edits too. I would suggest starting out by asking a good question, including what you have tried and any relevant code. That’s probably the easiest way to get started and you’ll get 5 points every time someone votes your question up. Voting a question up means that it is well worded and usually meaningful to the voter.

If you ask a question, make sure to check back and accept the best answer that you get. You will reward the answerer and you’ll get an additional 2 points yourself. Note that your accept rate is tracked and if you ask too many questions without accepting, people may stop answering your questions, since that is a sign that you’re not being a good member of the community.

Another way to participate is to share your knowledge by answering questions. That’s what I have been doing, since I’ve learned a thing or two over my 18 year programming career. (I feel old now.) In any case, I think everyone has some expertise to share and that’s how we all learn as a community: I share what I know, you share what you know, we both get better.

Make sure you answer questions thoroughly. Don’t just do a quick link to a blog post. Code is probably the best. If you do include code, make sure it compiles and works correctly. Include screenshots if it is relevant, for example if someone is asking how to change the background of an action bar, show a screenshot with a multi-colored action bar. Learn the right markup, which is in Markdown or use the toolbar to format your answer to properly insert hyperlinks, quote the question, quote documentation, etc.

Multi-color action bar

Once you get up to 15 rep, which shouldn’t take too long, then start to vote up questions and answers. This will help others figure out which answer is better than the others if there are multiple answers to a question. It also helps figure out which questions are popular.

Fill out your profile and include an avatar. I greatly prefer answering people’s questions that have a face to them, not just some randomly generated artwork. Include your qualifications and this might also help people judge whether you are credible or not, especially when you are first starting out.

Be persistent. Ultimately, you’re dealing with other people who have their own schedules. Just because you ask a question, it doesn’t mean that people are going to answer it right away. If you really want it answered and haven’t had any takers yet, then share the link to it on App.Net or Google+ or Twitter. Conversely, just because you answer a question, it does not mean that the system will automatically recognize your contribution and award you 15 points. The person asking the question has to do that and they may have some follow-up comments. Sometimes you just have to wait. Sometimes you will never get rewarded and that’s alright – you still have contributed to the community. And who knows – weeks, months or years later, someone might come across your question because they have it themselves or appreciate the answer that you gave and upvote you, sending a few more rep your way.

dim – visualize your Git diff in TextMate

I use git as my primary version control system and one nice alias that I have in my ~/.bash_profile is “dim”. When I type in “dim”, I see my Git diff within TextMate which makes it easy to see what I’m about to commit.

Here’s the entire source:
alias dim="git diff | mate"

It should automatically pick the “Diff” language for you, but if not, then just pick it from the chooser at the bottom of the window to get the nice highlighting where deleted lines are in red, added lines are in green and markers are in blue.

C4[3] Blitz Talks and MacRuby

I just came back from C4[3] – an Independent Mac and iPhone Developer Conference in Chicago. Wolf and Victoria host it and I saw Daniel Jalkut helping out along with a few other folks. In case you’re not hip to the zero numbering scheme, this is actually the 4th iteration of the conference. I went last year to C4[2] and this year was even better in my opinion.

There’s too many things to write about so I’ll just focus on two things that stick out in my mind: Blitz Talks and MacRuby.

I go to NSCoderNightDC and we have a nice core group of Mac and iPhone Devs who show up every week and eat Strawberry Napoleons. We also code and talk about design. Well 3 of the guys proposed Blitz Talks and got accepted.

Rob hit it out of the park with his Briefs iPhone prototyping tool. Jose actually created a Brief on the way from the airport to the hotel. He was kinda nervous beforehand in the hotel room but he practiced his presentation a few times on me and was really well prepared. His slides were top-notch but I think the idea is what really captivates people. I’m personally a big fan of fake-powered prototypes – prototypes powered by objects that return canned responses, but I’m definitely going to try out Briefs on upcoming iPhone engagements.

Jose did well with his presentation about the different types of contexts that an iPhone user would use different apps in. I’ve seen him give this talk before so it was interesting to see how he pared it down to fit in the much tighter 5 minute time frame.

Mark gave an interesting talk about how to do video right for Mac and iPhone screencasts and demos. I have a lot to learn about this and I’m hoping to work with Mark on a screencast sometime in the near future for Webnote.

There were many other Blitz Talks and I think they really were a nice Change of Pace that I haven’t seen in other conferences. Wolf amped it up even further by providing an animated radar / pie that kept filling up as the talk progressed.

MacRuby was the other big surprise for me. I had been tracking RubyCocoa and had seen the early MacRuby demo at RubyConf 2007. I’m a former Smalltalker and current Rubyist. I do all my automated build processes in Ruby and I’ve also created various non-Rails Ruby server-side components for clients. Plus I did Ruby on Rails for a few years. So I’ve been wanting to make Mac apps with Ruby, except one thing kept holding me back: I don’t want to show everyone my source.

Obfuscation is not a problem with server-side Ruby. The users only see what you expose via the web or other ports. They only see what’s rendered to them or the API that you expose.

Client-side Ruby is another world altogether. Users learn that they can peek inside application packages and if you’re writing Ruby, they can see your source. I’ve asked this question at WWDCs in the past and the answer was usually that its not a big deal and that you should just keep innovating. But we don’t just leave our Objective-C sources lying around, do we?

MacRuby will soon solve that, or I hope it will, with his AOT (Ahead Of Time) compiler. Or as it is known in the C/C++/Objective-C world: a compiler. LOL. So with the AOT, we will be able to write Cocoa apps in Ruby, compile them and run them on Mac. (And maybe iPhone – the jury is still out on that.) Which means that people can’t just look at your Ruby source. Even better, there is the HotCocoa project which provides useful macros / shortcuts for common Cocoa idioms.

Why use Ruby to write Cocoa apps? Ruby can be more concise, there are more libraries to choose from and the testing/mocking frameworks are better. On the other hand, the debugging story is still hazy.

I’ll be trying out MacRuby soon and I’ll post what I find. They’re currently at 0.4 with a 0.5 on the horizon, with nightlies for Snow Leopard available and the latest source available in both Subversion and Git.

Getting Sparkle from source (using bzr as compared with svn and git)

A few notes about getting Sparkle, the widely used framework for updating Mac OS X apps, from source:

1. Get a branch. This is similar to “svn checkout” or “git clone”.
bzr branch lp:sparkle

I admit it is kind of cool to have such a short name here like “lp:sparkle” due to bzr’s integration with Launchpad, which is sort of like SourceForge or GitHub.

2. Later on, you might need to get the latest version. This is similar to “svn update” or “git pull”.
bzr pull

3. To make sure you have the latest, you can check what version you have. This is similar to “svn info”. The closest to this in git is “git log –max-count=1″
bzr version-info

You can compare that version to the latest one in the main Sparkle branch.

I’ve been busy

It has been a few months since I’ve blogged here and where have I been? Short answer is that I, Luis de la Rosa, have been busy. I’ll get into the details over the next series of posts.

In terms of programming, I’ve been mostly doing Objective-C the past few months. I’m still doing Ruby on Rails, but Cocoa and Cocoa Touch are my main focuses. I actually did get paid to do some Erlang as well. Finally I joined an open source project that I’ve used on most of my iPhone projects. So there’s lots to talk about in the near future.

NSCoderNightDC is going to be studying iPhone SDK Development

NSCoderNight DC is going to be switching gears tonight and starting to study the new Beta Book from the Pragmatic Programmers titled iPhone SDK Development. Why the switch? Because the NDA has been lifted.

It is the first book of its kind that I know of. I ran into one of the authors, Marcel – who I also knew and respected from the Rails world, at C4[2] and he told me about the book.

So if you are in the Washington DC area and interested in learning about iPhone development, we’ll be having weekly meetings starting at 7pm every Tuesday at:
La Madeleine – Bethesda, MD
7607 Old Georgetown Rd
Bethesda, MD 20814
(301) 215-9139‎

More detailed driving / parking directions to La Madeleine – Bethesda, MD

See you there!

10 Things I Learned from C4[2]

I went to C4[2] last month. For the uninitiated, C4[2] is the third (yes we count from zero) conference of its kind, a conference for independent-minded Mac and now iPhone developers, held annually in Chicago, Illinois. It is run by Jonathan “Wolf” Rentzsch, who is an independent Mac / WebObjects consultant.

It was a great gathering and I look forward to going to C4[3] if I have the opportunity. So I thought I’d share my top 10 things that I learned at the conference:

1. Getting like-minded developers together at one place generates a lot of energy, enthusiasm and knowledge sharing.

I think it’d be great if we could replicate what has been happening in the Ruby community and start to have Regional Objective-C conferences. This has started to happen with the iPhone Dev Camps already, but it’d be great to have combined Mac / iPhone Regional conferences, so devs that can’t afford to travel to Chicago and San Francisco can still get involved and interact with each other in Washington D.C., New York, Seattle, Denver, and wherever else we all are.

2. iPhone development has really come into its own, but its knowledge continues to be restrained by the NDA.

We started off with a presentation by Craig Hockenberry of how iPhone has changed the way humans interact with computers in much the same way the mouse did. We ended with a programming contest called Iron Coder (a play off of Iron Chef) which traditionally has been with Mac OS X APIs but this time was on iPhone with an iPhone API. I finally participated (after helping with past Iron Coders by providing licenses of WebnoteHappy as prizes), collaborating with Joe Pezzillo to produce CoreParanoia and also contributed a tiny bit to Jose Vazquez‘s 2nd place Tipster.

The rest of the presentations were not iPhone focused, but there were mentions of it throughout. And it seemed like having an iPhone was part of the requirements for attendance. I personally got a live demo from Tim Burks of his iPhone app Masyu which is a pretty fun puzzle game.

The problem however was that the NDA on iPhone development stifled a lot of the conversation. This generated a lot of complaints and even a t-shirt that rebelled against it.

3. Security is scary, but not as scary as not succeeding.

There was a wild presentation on security that said: don’t pretend to be a security expert. Stick to using the Keychain or bcrypt for passwords, use openssl or gpg. Don’t use installers or open up listeners on ports. Don’t write directly into the DOM. But all of that doesn’t matter if your business doesn’t succeed if you don’t have a nice looking application and it is unstable or slow. Also, filter user-supplied content and write a fuzzer for the content you accept. Make sure you have a security contact, use a crash reporter, and use auto-update securely. Finally, turn off Java in your web browser to prevent against some of the newer, crazier attacks like GIFAR.

4. Mac users really care about user experience (as if you already didn’t know that.)

To reiterate what we all sort of know but sometimes overlook since we are so deep in our code, Mike Lee presented “Pimp My App.” The basics: Use real artists, don’t skimp on your art budget, watch real users use your app, solve a specific problem, and cut as many features as you can.

He also offered some iPhone specific UI tips: start as fast you can, the start-up screen should not be used as a splash screen but more like the real app, restore the state of your app instead of just restarting, don’t block the UI, and think about the user’s first experience carefully.

5. Contractors / consultants are Indies too.

I’ve made applications and I’ve done consulting. Both qualify you to be an Indie, meaning independent from another company. There was a presentation by Andy Finnell on this and it mostly reiterated what I knew but it was nice to hear it from someone else. Basically: make sure you have good contracts, these will help you get paid properly and avoid constraints your future development. I’d add to this that if you can be choosy, it is good to figure out what kind of clients you want to work for and what kind of projects you want to work on and then only choose those to work on, even if it means taking some time off between projects.

6. Pricing sends a message

Rich Siegel of Bare Bones gave a presentation on lessons learned over his career. One of the key ones is that pricing: is a marketing message and shows how you feel about your product. It also needs to consider how much your overall costs are. It also positions you among competitors. That being said, your product / service definitely needs to be differentiated to justify a premium.

7. Warnings should be fixed

This is probably also a no-brainer but I’ve been at a few companies / projects where warnings are tolerated. Mentioned by both Rich and Mike, warnings can be the cause of run-time errors down the road. Its best to generate the most warnings possible and fix them as they come up. You may find it also advantageous to treat warnings as errors, but either way way, fix them.

8. Mac programmers really care about fonts

Minor but revealing tidbit: the fonts at C4 are carefully chosen. Compared to other conferences I have been to, I think this shows that Mac programmers care about design more than other programmers.

9. Twitter is the preferred method of communication in the Mac / iPhone developer community

When I wanted to see what was going on and what people were thinking, I checked Twitter. At other conferences, sometimes we would have IRC back-channels. Using twitter makes the back-channels more open. Also, we voted for Iron Coder via Twitter.

10. Do the simplest thing possible

Mentioned by Craig, Buzz Andersen, and Mike, doing the simplest thing possible, getting feedback and then iterating on that is a good technique when developing products. I knew this before, but many of us are perfectionists and so we have to keep reminding ourselves of this in order to combat the tendency to either add more features or to keep trying to perfect a certain specific part of our app.