Daniel

I taught myself git to reasonable depth, including principles, command line usage, a graphical clients, and different server side repo management. I have mastered day-to-day usage and learned some things the hard way by saving myself from a few pickles (or (not) using git in such a way that I could not save myself). Through all of this, I have a passion for using git, choosing appropriate strategies, and convincing less experienced developers (and even more experienced developers who are resistant to git) of the power and value of using git. Basically, I'm like the guy in the alt-text here http://m.xkcd.com/1597/ I confess I don't commit or push quite often enough myself, and I sometimes forget to pull...

I like to keep this platform agnostic, and the bourne shell (or a mostly-backwards compatible derivatives) is available just about everywhere, so I started scripting utility bits of code to help me automate some of my work a few years ago. As tends to happen, the complexity of the things I wanted to do grew slightly ahead of my capabilities, and I kept having to learn more new things and practice to achieve what I wanted to. Besides for familiarity with the shell syntax and builtins, I include an understanding of the non-built in, but common utilities in the ability to script the shell. I tend to stick to the bourne shell, and use a few Bash features when necessary, but at a certain point, one has to say that maybe this isn't the tool for the job, so I don't believe in straying very far from core shell and I am not personally interested in learning the less compatible/more powerful variants.

I spent several months working on Android applications full time and some time on and off since then. I am currently improving my skills, and I think learning through teaching is a good method (which is not to say that I have no knowledge to impart. I am still familiar with the language and the basic structures, patterns, and tools of Android development).

My bread and butter has been in iOS applications for a number of years now, and most of that was in Objective-C, starting just after ARC was introduced. I worked both alone and on a large team, on simple and complex applications, and I have a good understanding of how the language works and the best practices for designing in it, as well as a good understanding of the Cocoa and Foundation frameworks.

I configured a Jenkins build server at work to build, test, and distribute/submit iOS applications automatically. I also had to keep the build server up to date, and make it as easy as possible to add new jobs and start or stop the server. Because Jenkins is not really built with iOS in mind (and iOS has some pretty unique pain points itself), and the plugins that Jenkins does have for iOS are not so great, this got me up to speed quite quickly with Jenkins and the various ways to use it.

Most of my studying and professional work has been with Object Oriented frameworks and patterns, and I have a strong knowledge of some ways that it can be done right, as well as many of the ways it can be done wrong.

iOS applications have been the major part of most of my professional career, so I know my way around the frameworks, the tools, the languages, the patterns, the development and release cycle and so on about as well as I think I could or would like to.