Shady Acres

To paraphrase the immortal words of Cookie Monster, “networking is an always thing.” There’s no secret formula that, when applied, creates an awesome network for you. Like any other process, it takes a lot of small steps, and there are many tools you should use.

One opportunity which I find that far too few people use applies to lecture settings. Far too often, when some visitor—often a subject matter expert—comes to give a presentation about whatever topic, people tend to sit together with friends in the back of the room. If you’re attending this talk, it’s because the guy speaking has something to share with you, and you probably would stand to benefit from talking to him. Sitting up front means the guy/girl speaking will see your face more, and may increase the likelihood that you’ll get to talk face-to-face after the lecture, particularly if the person is going to get quickly mobbed. Most of all, though, if you sit up front you’ll be noticed as That Guy Who Sits Up Front. That can mark you as an interested person, which can be good all around.

Is this a very minor suggestion? Yes. However, this requires zero effort on your part. Give it a shot; it may help you end up meeting someone. I’d love to hear your other simple networking tips in the comments!

I recently had to quickly familiarize myself with the R statistical computing language for a new job. Being a veteran of the “learn new languages and immediately forget them” school of thinking, I wanted to make sure that this one stuck.

For R, the problem definitely isn’t a shortage of learning material; there are literally hundreds of online tutorials on how to use it. There are entire books that are devoted to individual components of the language. The problem is that, to steal a phrase from some dead Latin-speaking person, “reading doth not a programmer make.” To really become an expert programmer one simply has to program. The best way to do this is to have a project that you’re going to complete in the new language; by going through the planning, coding, and debugging phases, you’ll experience the nuances of the new environment; novel design patterns, different coding conventions, and all those subtle ways that a new language can excite and infuriate you. After you do that first project, you really don’t know that much—after all, you’ve only finished a single project—but you’re familiar enough that you could probably adapt to a new project quickly, and your subsequent questions will be less “what’s the def statement mean?” and more “why did you use design pattern A instead of B in this function?”.

The downside to the “do a medium-sized project” approach is that it may take more time than you have; in my case, I needed to learn a new language in about a week, while working on other projects. At most, I was able to dedicate two hours a day to learning the new language. I spent a good deal of time going through code from previous projects others on my team had written, but I found that it had similar retention to reading; simply reading through code, while helpful for seeing design patterns, is not enough for learning a new language.

For this project, a different approach was needed, and one that has been in use by teachers since time immemorial. A google search for the term “Introduction to R course” unearthed this website, which contained numerous homework assignments meant for the students. The assignments turned out to be written pretty well; each assignment contained what was, in effect, two small analysis projects. The homeworks, in effect, proved a good proxy for my “medium-sized projects” which I needed to learn the R; after completing them, I was by no means an expert, but I was able to converse intelligently about the language, and I was ready to begin really getting into the meat of the language. I had, in effect, progressed beyond the “beginner” phase, which was what I had been hoping to accomplish.¹

There are two specific lessons I learned from this. From the standpoint of a student, the best way to learn a new language is to use it. How you use it during the learning phase is not as important—it’s far more important that you simply get real-world experience writing scripts and programs, so you have the necessary exposure to the language. From the standpoint of the teacher, though, the take-home is different; the best homeworks are the ones that get the student to use the language. Even better, have the student use the language for different purposes, to expose them to the many different facets of the language. A well-written homework assignment greatly enhances the overall learning experience.

1. Note that this is how Schaum’s outlines, an excellent teaching supplement, are structured. Each lesson has a few—often very few—pages about the material, and then many, many pages of review problems. This is a tried and true technique. ↩

It seems to be a well-accepted fact that public key authentication provides significantly more security than password-based authentication [1][2][3][4]. Unfortunately, for most people, every time we want to set up public key access for a particular server (which occurs pretty rarely), we do the following:

1. Google “set up SSH key access”
2. Follow the steps, including:
   1. Typing yes to some scary question about a Man-in-the-middle attack
   2. Sending keys back and forth, hopefully using something more secure than FTP

How hard could it be to put a good UI on all this to make it simple? Most of it is very simple; all the work would be in the UI.

In that vein, this post is a call to the general developer community, requesting a simple app for setting up keys. The app I’m envisioning would broadly follow this “spec”:

1. It should only require the remote server URL and login credentials as input
2. Running the program should:
   1. run the ssh-keygen command
   2. put files where they belong
   3. ideally, figure out what the appropriate host key is for the server¹
   4. copy the appropriate files to the remote server
   5. tell me when I’m done

I’d pay for it.

1. If that’s even possible. I have no idea. ↩

Dear Tumblr -

I love your service. You guys rock. You’ve made my blogging experience simple and professional-looking. I’m honestly glad that I’ve chosen to blog with you guys, and I’m only looking forward to all the nifty features you add as the service continues grow.

However, there’s one thing which you don’t have, which is making my Tumblr blog less important to my personal and professional life than it should be. I can demonstrate what you’re missing with a simple screenshot:

Note that my LinkedIn profile is way up there, exactly where I want it. I want people searching my name to see that immediately. Same for Google+, and same for Twitter. When someone does a search for me, I want them to find these sites.

I want you to pay special attention to the slideshare link you see in the search results. I have never used their site. I registered that username back when I did those sorts of things for kicks. It’s a testament to their awesome white-hat SEO techniques that their site is so prominent in a search for my name. In fact, because of their having done such an excellent job in promoting their site in connection with my name, I’m going to be adding some of my presentations to their site. Given that that someone who looks for me will see their site, why wouldn’t I use the free advertising they’re handing me?

To that end, I would like to request—scratch that, to beg—that you let me add my full name to your site, and that you let the engines properly index it. Note the bottom of the front page for that search:

You guys are on the front page. This isn’t an SEO problem; you guys, apparently, are doing fine in that regards. However, that page is only listed because I prominently list my name on the side of the blog. Aside from not looking as offical (“Eliezer Kanal | LinkedIn”, “Eliezer Kanal - Google+”), you lose out on the free advertising… your name is only present in the URL, so no one knows that I’m blogging using your awesome blog engine. It doesn’t have the same oomph to it. I want my postings on Tumblr to be part of my online portfolio, and by letting my blog be directly linked to my name you can not only help me, but make your site that much more prominent as well.

Sincerely,
Eliezer Kanal

p.s. - if someone at Github happens to see this as well, /Tumblr/Github/g.

You’re reading Part Four of the “Learn Git progressively” four-part tutorial.

1. Basics - Setup, init, add, and commit
2. Daily usage - status, diff & difftool, and log
3. Branching & Merging - branch, checkout, and merge
4. Collaborative coding - remote and Github.com

This is a follow-up to my previous post, Learn Git progressively - Day 3. I suggest reading that post before continuing here.

By now you know how to use enough of Git that you’ll probably be able to manage any project you work on using Git. However, the core strength of Git lies in it’s ability to make collaborative coding—-coding with a team—-a complete breeze. Sharing code and projects using Git is very easy, and websites like GitHub and BitBucket have made it not only easy, but outright enjoyable. We’ll discuss collaborative coding using Git below.

In addition to collaborative coding, there are a few features in Git that aren’t essential, but will make your experience with Git smoother and more pleasant. We’ll discuss a few of those at the end of our final tutorial.

By now you’re familiar with the concept of a Git repository. It’s where all the details of your files—-commit histories, log notes, branches, deleted files—-are stored on your computer. What we haven’t discussed up until now is that Git is designed so that this entire repository can be very easily shared with other individuals. In this way, you not only share your code with other members of your team, but you can share your commit logs, your code diffs, and even your branches with others. Even better, you can set up a single repository that everyone can access, and in doing that you can all view each other’s changes, branches, commit logs, and other repository details, making code sharing extremely simple.

The setup I just described is a brief summary of git remote. A remote is a connection between the repository you’ve been storing your code in and another repository elsewhere which will act as a central server¹. Typically, this will be on some company server or a website like GitHub (more on that later). In fact, in many cases, your first interaction with a new Git project will involve interfacing with this remote, using the git clone <url> command:

#
# Clone eykanal's "notestack" repository from github.com
#

$ git clone git@github.com:eykanal/notestack.git
Cloning into notestack...
remote: Counting objects: 857, done.
remote: Compressing objects: 100% (359/359), done.
remote: Total 857 (delta 459), reused 847 (delta 449)
Receiving objects: 100% (857/857), 1.55 MiB | 1.62 MiB/s, done.
Resolving deltas: 100% (459/459), done.

(None of that output is important; it’s just there to make your boss think you’re doing real work. It’s always better to have resolved your deltas than to not have resolved your deltas, I say.) This function tells git that it should create a local copy of the git repository on your computer. When you run this command, Git will download the entire repository on your computer, so that you have access to all the commit logs on the master branch.

Note that this only pulls the master branch. If you want to pull a When you download, or “clone”, a branch to your machine, Git will remember where the URL from where you retrieved the code originally, and it will assign it a name. This name by default is “origin”. You use this name to download an updates to the codebase,

$ git pull origin

to download additional branches,

$ git pull origin <remote branch name other than "master">

and when uploading your changes,

$ git push origin <branch you want to push>

There’s one more detail about remotes which may cause confusion from SVN veterans. When you typed git clone <url>, you created a local repository. You will be able to interact with that repository the way you interact with any other Git repository; you’ll make commits, you can roll back changes, you can create and merge branches, etc. When you’re done and you want to push your changes to the remote repository, you will be pushing all your changes—-i.e., your entire commit history—-to the remote. In other words, you download a repository with it’s history, and when you upload changes, you’re simply uploading the same repository with a bit more history attached; i.e., the changes you’ve added.

For those occasions where you didn’t originally download code from a remote, remotes are pretty simple to set up. You will be provided with a repository URL, which will often (but not always) look like a typical URL. You can add the remote repository by typing

git remote add <url> <remote name>

Once the remote is present, you can download and upload using the remote name you specified as described above.

The ability to work with remotes makes Git an excellent tool for collaborative coding. However, Github.com² has turned Git from a useful tool to the tool that many current open-source projects use to share their open-source projects. Between the very slick interface and the useful project management tools, you will find yourself wanting to store your projects on Github.

Note: Github.com is an awesome website, where some of the most interesting and popular Open Source projects are shared and collaboratively edited by hundreds of developers. However, a free account on Github does not come with any private repositories. This means that any code you publish to Github using a free account can be seen—-and downloaded by—-anyone on the internet. I’m demonstrating remotes using Github because of it’s immense popularity, but if you are working on a commercial project, DO NOT put it in a public GitHub repository. Note that BitBucket, another popular collaborative coding site, does offer a free account with unlimited private Git repositories.

The initial setting up of Github access takes a little bit of work, but it’s very well documented at the Git help center. You’ll want to check out the section titled “Set up SSH access”. Go ahead and do that and then come back here. Here’s the link again: Git help center.

The easiest way to move your project to Github is to follow the following three steps.

1. Log in to the site.
2. Click on the “New repository” link on the right hand side of the page. Alternatively, you can just follow this link. Give the project a name and a description.
3. The instructions as to what to do next will be printed right in front of you. (Didn’t I tell you that Github is easy to use?) If you are starting a new project, follow the “Next steps:” instructions; if you have an existing project, follow the “Existing Git Repo?” instructions.

Congrats; you’re now a full-fledged member of the DCVS revolution.

While on Github, you’ll want to search and check out other people’s code. If you see something interesting that you want to contribute to, click on the “Fork” link. This creates a copy of his project (think git clone) that you have full ownership of. You can download the copy, you can edit the copy, compile it, upload it, and (if the license permits) ship products with it. If you make some awesome changes that you think the original developer would love to add to the original code, you can simply submit your code back to him via a “pull request”; this takes all your changes and sends them back to the original author with the note “please incorporate this into your codebase.” You can do this with bug fixes, feature requests, etc. Again, the Github.com help site has a useful page describing of how to use this feature.

You’ve now familiarized yourself with one of the most capable versioning systems available today. Well done! Now go out there and code something awesome!

1. Technically, remotes don’t have to work as central repositories; you can have a network of individual computers all connected to each other via remotes, with no central server. However, this sort of setup is very uncommon in practice. ↩

2. And Bitbucket.com as well, but as most projects are housed on Github we’ll be focusing exclusively on that. Bitbucket does have many compelling features, though, including some that Github doesn’t offer, and I recommend you compare feature sets to see which is best for you. ↩