I have this general belief that if I haven’t done something in the last 10 years then I can’t claim at having done it before. The reasoning behind such a ruling is based on the idea that within 10 years time you as a person have become someone else entirely: physically; emotionally; and mentally.
This rule does not seek to discredit previous accomplishments but instead free myself from previous incarnations. To allow me to again be a beginner.
I started to scroll through tmux: productive mouse-free development. I thought I would give it a try to help me better manage remote systems by using it locally. And for the most part it has been a pretty awesome tool that yields some results pretty quickly for my investment. So far the only tedious part is the lack of ability to easily scroll back through the history. I can do it, but it is by far not as easy it was simply using Terminal.
Of course, after starting to read the book and starting working with the first few commands I started to hate using Ctrl+B as the prefix key. I immediately stopped reading and started to search for an easier way. What follows is how I mapped my CAPS LOCK key as Ctrl+B.
If you haven’t already done so, gain an extra key and open up your System Preferences > Keyboard > Modifier Keys … and rebind CAPSLOCK to No Action.
62.
Install KeyRemap4MacBook
Open System Preferences > KeyRemap4MackBook > Misc & Uninstall
Several companies are using Github as a source repository solution. Many teams have adopted a great workflow that involves opening a pull request when a feature is complete. Using Github to code review a new feature or fix is awesome . Anything that promotes more communication and review of ones code is awesome.
The process goes something like this:
Reviewing the steps I noted the primary tools used to accomplish them:
What stood out to me was how the final stages of this process stood out. It was then that I sought to remedy that.
With the help of the hub and a little bash I created a single command to allow me to perform a pull request from the command-line.
1 2 3 4 5 6 7 8 9 10 11 | |
Hub’s pull-request command by itself was great when I was working within my own projects but failed to generate the correct pull request targets when I was working on a project that belonged to an organization.
This small change allows me to combine the last two steps of the workflow into a single step as well as bring it more in-line with the other tools in the entire process.
Install hub from brew.
1
| |
Open your .bash_profile or .bashrc and add the following lines:
1 2 3 4 5 6 7 8 9 10 11 | |
Save and exit. Run the source command to use your updated bash commands.
1
| |
Running the pull-request command should launch your GIT_EDITOR or EDITOR to compose the pull request message.
Several introductory tutorials use IRB as a tool to show off Ruby to new developers. I can understand the allure of using IRB:
does not require the user to create a file
immediate feedback for their actions
In my experience, using IRB is fraught with far too much peril to make it a valuable learning tool.
unable to visualize all the code that they have written
navigation in IRB is much harder than in an editor
state of the code is lost when exiting IRB
It is a major boon that the user does not have to create a file to get started. However, it becomes a major pain if the example starts to span multiple lines or requires particular step-by-step code to be completed.
Given that a user will want to learn by re-typing all the code they see in an example, they are likely to make a mistake during the data entry process and because of the poor, console like, interaction provided to the user they will often be unable to use any of the code that follows the mistake.
From a troubleshooting point of view, it is extremely difficult to have the user move back through their command history (Up-Arrow) multiple times to find the issue.
Eventually your examples will have to exist in a file and while it seems like a headache from the start to have the user create a file for them to copy the example or write their code in, it is simply where they are going to end up.
Examples longer than a single line should be written in a file (not IRB).
I do rather enjoy this feature of IRB over using a text file. When a user finishes a line and presses the enter key, they are immediately treated with feedback to the code that they wrote. It’s like chatting with Rainman; able to repeat what you tell it and solve complex math problems quickly.
It is great when it works. It is a great failure when it does not work.
The great failure I am talking about is the first time in an example you ask a new developer to perform any operation that has an opening element and a closing element.
1 2 | |
Instead of getting immediate feedback, the user is treated with what appears to
them as a broken console. They are not even able to exit! Everything they start
type in at this point stops working as it once did. All because they opened a
string with a " and closed it with a '.
This only gets worse when they start to use more of these required starting and ending elements in Arrays, Hashes, Methods, and Blocks.
Limit your IRB examples that use starting-ending elements
I recently had the opportunity to instruct several new developers in the nuances of the Ruby language.
There is a strong emphasis now for developers to test drive their development. Several of the exercises utilized tests as a safety net. Other exercises did have them write code to make tests pass.
Despite what I would call a solid upbringing the students do not immediately reach for their test framework when they start working on new exercises. It just does not feel comfortable trying to write tests when you barely have an understanding of the complexity of the problem and the scope of the language.
To those of us polyglots, now working in our third or fourth language we find it a far easier venture. I think we should think twice before we require, enforce, or guilt new developers writing software to bring with them tests in tow.
Test Driven Development requires a much greater level of mastery and understanding than we often give credit.
When I first started watching the Apple Developer videos, that are available through the iOS Dev Center, I was always amused by the participants at the talks clapping throughout various demonstrations. The presented feature would likely be saving the developers a new heap of time or give them a new tool for their belt. It’s become a bit of a joke over the last few weeks. A fellow developer will be dragging-and-dropping some code object into a storyboard or xib file and I will start clapping. Always amusing when it’s dropping a textfield.
iOS developers, as most other developers, give software away. A few months ago when I started down the path of iOS development I was saddened by the lack of community software in comparison to my experiences with Ruby. Namely I was saddened by the fact that there was no easy way to discover software libraries and tools. I was wrong. They have a community and there are definitely resources to assist with finding iOS software and components. However, it is still hard to integrate software into an existing application. By hard, I mean it’s a fairly manual process of downloading/cloning a repository and then manually importing files into the Xcode project file. Oh, the Xcode project file we will have to talk more.
Developers make terrible testers … and designers and … likely anything other than a developer. In reality I think that most people that attempt to handle more than one concern at a given moment are generally bad at any of the supplementary tasks.
I am not trying to say that I am an exception to this rule, but I will say that when I attempt to test something or put a little design on top of it while I am still in the midst of delivering development aspects I will often times do terrible work. Just awful.
The process I use to get this to work is to deliver on my development tasks. Take a break. Return to the work, rested and ready to test it or do some design for it. If it sounds familiar - it is! It is exactly the strategy that most every instructor has presented to you about writing and editing your own essays.
Of course, there is no hope for you if finishing the work the night before. :)
I came to Ruby by way of Cucumber. Cucumber placed an emphasis on writing tests that described the products behavior. Ideally Product Owners at the helm, authoring your requirements. No good tools were made available to provide documentation for the stakeholders. Out of necessity, I created an extension for YARD. I started to work on another extension for RSpec. I even started playing with integrating Bundler. Through this experimentation I realized how little our documentation tells us as stakeholders, testers, and developers.
Tests are documentation; but they are not in our documentaiton.
So I would like to help champion the continual war to encourage documentation by building tools that make better documentation from what has already been written. In that spirit I built an extension that generates better documentation with the comments made within methods themselves: annotated source code (docco style).
Classification is useful; roles help define responsibilities. However, giving definition to something lends itself also to restriction. And this can be the unnecessary impedance or death of small systems. Within the small development team I work we have often confined ourselves to roles.
Within the company our development efforts are geared towards a particular cause.
When new concerns arise that fall outside the concerns of the individual role or the entire team it is not clear who or how they will be addressed… and often could be lost.
Perhaps it is simply applying a system or a mindset in the military where your rank, in most cases, influences a level of pay and expertise. You are ultimately and at your core a soldier which can be applied to solve problems.
It seems we encapsulate that at the current moment. I am a Software Developer 2.
So maybe it is a cultural shift that the goals of the company ultimately outweigh the goals of the role.