A Developer’s Guide To Upgrading To OS X Mavericks
I’ll admit I liked the sound of free with the latest release of OS X Mavericks. What I didn’t like was thinking about the headache from my last upgrade of the OS. Hopefully this will numb the pain. I use homebrew to manage my system packages, so if you don’t, you might as well stop reading this and light your computer on fire for having to deal with all the conflicting installs you’ve done.
Open up App Store and search for XCode… then wait an hour while it installs
Install command-line tools for X-Code
Just for fun, the command line tools for XCode have been removed from the Download section of the UI… so you have to run:
Upgrade GCC, Because Apple’s Sucks
brew install apple-gcc42
Several libraries and gems we use depend on Java. Luckily Apple makes this nice and easy to install *sarcasm*. After scouring the web, I found a nice packaged installer: http://support.apple.com/kb/DL1572?viewlocale=en_US.
I just imagine that there is a Tsunami of updates for pretty much all packages. First I updated homebrew itself:
cd /usr/local/Cellar git reset --hard git pull cd ~
Now that homebrew is the latest and greatest, I updated my brews
I also checked to make sure homebrew wasn’t missing anything, and turns out I had to install some packages it listed:
You’ll also want to check on the health of your brews, and fix anything it suggests:
Re-Install X11 and QT
In order to get our automated test suite working, we need QT working, and for that we need X11. Installing the latest release worked for me. Just visit: http://xquartz.macosforge.org/landing/ and download and install the latest release. At the time of this writing, 2.7.4 worked for me. Once that is installed, I upgraded QT:
brew upgrade qt
EDIT: Having issues upgrading QT? After attempting to upgrade on another machine I ran into errors compiling the source. This is a known issue with the latest Mavericks. For the latest fix and updates to this, reference: https://github.com/mxcl/homebrew/pull/23793
brew uninstall qt brew install -v https://raw.github.com/cliffrowley/homebrew/patched_qt/Library/Formula/qt.rb --HEAD
…wait an hour…
I upgraded my RVM to the latest release just in case they fixed things for Mavericks:
rvm get head
After upgrading to Mavericks, my previously installed Postgres was having some serious issues. I had to re-install it in order to get it working with my rails apps. First thing I had to do was remove the existing postgres:
brew uninstall postgresql postgresql92
Before you re-install, make sure you uninstall all your existing pg gems so that it can use the new sources in the next step:
gem uninstall pg
Now install postgres (I’m using 9.2 as it’s what is needed for a project I’m on).
brew install postgresql92
I had to manually link the startup scripts:
ln -sfv /usr/local/opt/postgresql92/*.plist ~/Library/LaunchAgents
Now install the pg gem again
gem install pg
After all that, there was just one gem that needed an update (probably due to the QT updates). If you run into issues with any of your gems, just try updating them or uninstalling/reinstalling. For me it was just:
gem update capybara-webkit
We use tmux and tmuxinator as our editor/console combo. I’ve had to upgrade tmux since the writing of this post.
brew upgrade tmux gem update tmuxinator
After ALL of that I was good to go with minimal issues. Hope this helped.
Business Growth Advice from a Computer Hacker
I have a secret to tell you. My name is Nick and I’m a computer hacker.
But don’t worry, I use my powers only for good.
One day when I was in high school it started to snow. By mid-morning, several inches had accumulated, but the school still hadn’t announced an early dismissal.
Whispers started and everyone wondered eagerly…
Are they going to call it?
When are they going to make the announcement?
What time will they let us out?
On this day, like most days, I could be found in the computer lab. But this morning, the anticipation of getting out early was too much. I grew impatient. They have to let us out with the snow on the ground, don’t they? Don’t they?!
Time ticked by slowly. 9 o’clock … 9:05 … 9:10. And with all of the maturity and impatience of a teenager (who knew too much for his own good!), I made the call. If the school wasn’t going to make the announcement, I will! Maybe some encouragement would help them do what all of the other schools were already doing. How could this possibly go wrong?!
See, I’d throughly explored the school’s website in my own time. And through my curiosity, I discovered a way I could modify the district calendar without needing to authenticate. I had the power to change the calendar shown on the school’s website, so I would change it to announce an early dismissal. And that’s exactly what I did.
Within what felt like 8.3 seconds of making the change and showing the lab technician, the entire school knew.
"We’re getting out early today, it’s on the website!"
"We’re going home early! I need to call my mom!"
"Early dismissal.. yay!!"
And we waited.
The lesson I learned on that day was the start of a bigger concept that would echo back to me again and again in different ways across the years. I learned that if you really want to accomplish something, be it an early dismissal or growing a business, you can’t do it by hacking the system.
A business and a computer program are similar in more ways than you might think. They’re both structured ways of accomplishing a task.
I can hack a computer program to make it behave outside the rules in very specific circumstances. But despite repeated attempts, I’ve learned you can’t hack a business the same way. It is possible, but hacking a business is done in a different way.
To hack a business, you do it by hacking “people” and not the business itself.
See, a business is made from the people (and relationships) that run it. If you really want to hack your way to greater profits, then you need to understand human psychology. You need to understand human behavior and motivations. And you need to take what you learn and use it to approach all of your interactions with a new strategic outlook.
Are your interactions with your customers strategic?
What about your website or your pricing?
Can you identify the strategies I’m using right now on you as you read this? (Yes, I’m “hacking” you right now. Can you spot it?)
How much more could you do if you understood how to use the power of human psychology to your benefit?
It was mid-afternoon by the time I was called to the office, and I hadn’t a clue why. I knew the computer systems better than the district techs themselves, so I was sure I was safe. I thought they just wanted me to look into what had happened to see if I could provide any advice on how the early dismissal may have found its way onto the calendar.
Gary, the new district tech they hired that year, was there and him and I had already grown to be friends. But I saw the papers in his hand and I instantly knew the mistake I’d made. I was using the “private” network that allowed unrestricted access to the network… while logged in to my own account. How could I be so careless!
He began to speak and I already knew what was coming. I was so nervous, my legs went numb. Oh…. crap. I cut Gary off and the words exploded out of my mouth, “It was me! I hacked the website!”
And the school’s vice principal had to hide the grin from his face. He was proud of what I’d done. It was clever. It was “awesome”, but there’s no way he could let me know. I will never forget the look in his eye, simultaneously “Atta boy!” and “You’re in trouble!”
I received my first and only suspension that day, and I’m still proud of it to this day: “Nicholas altered the district website and announced an early dismissal”. I can think of no better reason to get a mark on my permanent record.
We never did get out early that day.
P.S. I would like to apologize to everyone who wrecked their car that day.
How to be a responsible businessman: Bill clearly.
The way you bill for your service can have a big impact on how your customers think of you. Let me give you an example.
I don’t talk to my lawyer nearly as much as I should. Do you know why?
It’s because I know that every time I talk to him and even start to mention a new idea, I know the clock is going to start running and I’m going to get a bill.
Even if I’m wrong about this, he’s losing out on potential business from me because my relationship with him isn’t clear.
It’s your job to make sure your customers aren’t afraid to talk to you.
As a customer, it can be difficult to know what makes the difference between billable work and non-billable work, so you should make this as clear as possible. As soon as you start talking to a new customer, outline your billing method.
But don’t expect your customer to remember or understand until later.
You should provide a PDF or page on your website that’s like a cheatsheet for when your customer will expect a bill.
Send this PDF to your customer every time you “get back in touch” (if you’ve made the mistake of letting the relationship grow cold) so they don’t have any surprises about talking to you.
This is important because the trust you build with your customer is far more important than the money you make today. With greater trust, you’ll gain exposure to greater opportunities. And with greater opportunities, your earning potential is practically unlimited.
The world is abound with opportunity. If you want it, take it.
Quality is not enough.
A few months ago, I discovered that I’ve been running my business mostly by accident. Are you making the same mistakes as I did?
I would rely on word-of-mouth to get new business and occasionally run some poorly thought out ads. I thought “If we do good work, people will come to us”. That’s only partly true. Sadly, quality is not the only ingredient necessary for success.
The quality of the work we do is important, but you know what putting quality above all else leads to? Shiny products in an empty void. Constant stress and none of why I got into business in the first place. To be free.
The world doesn’t owe me a damn thing. Even if we do great work.
Want to know what I figured out?
Businesses are run by guys like you and me. We buy something when it is worth more than it costs. If you help me know how much something is worth, I’m willing to pay more for it. Screw competition. Screw everything else. Make it easy for me to know why buying from you is a good idea. Put me first.
I want to work with the guy who understands how much is product is worth to me, even if he costs more. I am busy as hell and I don’t want to spend forever and a day making sure I optimize things I don’t understand. I need to focus on my things and try to enjoy my life.
Look, I don’t know how you do what you do. All I really care about is what it does for me. In the end, if what you provide doesn’t make me more money than it costs, I won’t buy it. I don’t give a damn about your costs, your causes, or anything else that doesn’t make a difference for me. I have my own things to worry about.
If you want to increase your sales, it starts by knowing your worth. Can you measure how much your product or service is worth to someone like me?
If not, why the hell not?
I want to see you kick ass. You can do it.
I’ve got faith in you,
P.S. If you like this and would like to read more like this, subscribe to my newsletter: Business Tech Secrets
A flexible git workflow for teams.
We use a simple development model for our projects that’s lightweight enough to stay out of the way and flexible enough to handle real world usage.
Git is distributed source control
Git is the version control system of our choice. Each developer has a copy of the complete history of the project on his machine which reduces the likelihood of loss and its other features support the workflow we’ve designed.
Github provides great tools for code reviews through something they call “pull requests”. Github has the largest code collaboration network in the world and that means their tools have been refined through real usage. We’ve tried alternatives, but github is second to none.
One true master
With a few exceptions, our projects have a single branch of code from which the entire team will work. We don’t bother with maintaining different branches for different purposes because in practice (even in apps with > 20k monthly active users) you just don’t need different branches.
Instead, the whole team will remain focused on keeping the master branch stable for the rest of the team. With only one branch to maintain, it’s easy to treat it with the respect it deserves.
All of our work is built with automated testing, so that means all of the tests in the master branch must pass at all times.
Small Feature branches
Every feature, no matter how tiny, is developed in a branch off of master dedicated to that feature. This allows the developer to focus on developing the feature in isolation without concern to what’s happening with the rest of the project.
There are few rules or restrictions on how each developer works inside his own feature branch. He can commit changes as often, or as infrequently as he likes. As long as the feature has been defined to be small enough, it does not matter.
Each feature branch is named after the feature being developed and starts with the initials of the developer or developers who “own” the branch. As an example, if I need to update the homepage, my branch would be called `nh-update-homepage`.
We’re a small team, but we believe strongly in the value of code reviews. All of our feature branches are reviewed by at least one other member of the team before code is approved to be merged to master.
We use github pull requests to review the changes between the master branch and the feature branch. This way, only the changes made by the developer will be reviewed and changes can be made to prepare the code for delivery.
Github’s pull requests allow us to leave comments for each other, share knowledge of the work being done and have a great conversation on the code that will be available for us to review in the future. (Yes, we’ve gone back to our work later to determine why decisions are made. Documenting those in a pull request allows us to understand the decisions again quickly.)
After a branch is reviewed, the developer(s) who approve the request leave a comment saying ‘LGTM’ (Stands for Looks Good To Me) to confirm the code has been reviewed and allow future discussion.
Squash Merge with link to pull request
We don’t keep old feature branches and we don’t care how each feature branch was developed. A month from now, we’ll care only about the features that have been added, so we discard the details of how each feature branch was made.
We do this by creating a new commit on the master branch that represents all of the commits in a feature branch through a technique known as “Squash Merging”. This allows us to have every commit from a feature branched rolled up into a single new commit.
Inside the commit comment for the squashed merge commit we’ll include some text that Github recognizes to link/close the associated pull request. (Example: “Closes #38”) This allows us to review the discussion on each feature if we need to review in the future.
As another bonus, the squash merge means that the history of the project remains clean. Each commit in the master branch represents an entire feature after review, so if we do a “git blame” to see when a line of code was changed, we’re able to see the full context of the change, not see that it was changed because of a typo fix.
After the merge to master, the feature branch is removed and will never be needed again.
What about features that are too big for a branch?
Sometimes a feature is too big to be part of a small branch, but cannot be released to users until all of the associated tasks are complete. To handle this, we use rollout to include the feature being developed into the master branch but leave the new functionality disabled until complete.
This allows other developers to work with the new functionality without displaying it to users. Sometimes we’ll have both old and new code in the project at the same time which means we will go back and remove the old code after the new feature is enabled. This adds a small amount of overhead, but eliminates the headache of managing multiple long running branches just to support the addition of new features. It also maintains a clear view of the actual state of the project for all developers.
How do we follow this process?
While we can do every one of the steps above by hand. We’ve developed a tool called Git Reflow that automates much of this process to make sure we follow every step every time.
Here’s how it works:
git reflow start nh-branch-name to start a feature branch.
git reflow review to review a feature branch.
git reflow deliver when finished to deliver a feature branch to master.
Keep your bullshit filter on high. Technology isn’t everything.
If you pay attention to what you hear on the news and see on the internet, it can feel like “game over”. Nerds like me have won and if you want to “make it”, it seems you have to be one of them or befriend one.
I might be a nerd, but I can tell you that the media has it wrong. The world is much much bigger than Facebook and iPhones. There’s real work that needs to be done and Facebook has little to no impact on real business. (How about you “like” a hard day of work? What, no takers?)
A large number of companies are trying to capitalize on all of the attention that the tech industry is getting. They’ll tell you things like:
- "You need to have a Facebook page"
- "Your business needs to be active on Twitter and YouTube"
- "If you get more likes on Facebook, your business will make more money"
I’ll be honest with you. Some of these companies are trying to capitalize on the fear, uncertainty, and doubt you have around this. Heck, many of them even believe it themselves, so in their mind, they’re actually making a difference. But seriously, what does a Facebook “like” have to do with the revenue you need to run your business?
If it looks like bullshit and smells like bullshit… well, you know the rest.
It comes down to this. If someone makes you an offer and they can’t provide a direct connection between the goal (more customers, more profit) and the solution they provide, then don’t do it, no matter how convincing it might sound.
The last thing you need to do with your business is make an “investment” in technology that you don’t understand.
Because, you know what works in your business?
There’s nothing that will replace the connections you’ve made with your customers and your vendors. No tool, online service, or gimmick will ever replace the human aspect of what makes your business yours.
If someone comes to you to try and sell you something and can’t make a direct connection to the results, or can’t offer proof of the real results their work has done in the past, then give it a pass. Your time and money is too important to chase meaningless metrics.
Keep your bullshit filter high.
Until next time,
P.S. After all of this, yes, I admit, there is some benefit you can get through proper execution on Facebook or YouTube or Twitter. Just be smart about it and trust your gut.
Are you looking to reduce the amount of bullshit in your life? Are you sick of technology guys who feed you lines, but don’t deliver results? Let’s talk about how I can help.
If you don’t update your Rails 2.3 app, you are in danger. Here’s what will happen.
You may have been contacted recently about upgrading your Ruby on Rails application. It is very important that you do not ignore these emails.
With the release of version 4.0 of Ruby on Rails, your application, running on a version less than 3.0 will no longer receive any security updates.
If you take no action, the following things are going to happen to you. It is not a question of if, but only a matter of when. Here’s what you can expect to happen if you ignore the emails you received.
Your data will be compromised.
Everything that has ever been entered into your application, either by you or your customers will become compromised. Meaning, someone who you don’t know and who may have dishonorable intent will have complete access to your data. What they choose to do with it could have serious impact on your business.
Your application could be modified without your permission.
If gaining access to your data isn’t bad enough, the type of access that will, at some point, be gained to your application will allow someone who you don’t know to make changes to the way your application runs.
If you think about your application as a machine that performs business tasks for you, this means that someone will be able to get inside and change the way your business works, while it is running, and you would have no idea until for example, your credit card payments go to some one else’s bank account.
Your insurance will not cover the damages.
Your insurance, and the insurance of the technical team that built your application (You did work with an insured team, didn’t you?) will not cover the damages when someone gains access.
Sure, you can file a claim, but your insurance company will quickly discover that the damages you’ve received are due to a lack of maintenance, which in most policies is explicitly not covered. This is a preventable risk and it is entirely your responsibility to make sure it is addressed.
You will find out how much your application is worth to you.
If you rely on your application for any business purpose, you will find out the hard way how much it is worth to your business. You will have no protection against the losses and your business insurance will not cover the damages.
Your losses will provide, in very direct terms, a measurement of how important your application is to your business. It’s probably worth a lot more than you think.
What can you about this:
Patrick McKenzie has done a great job covering the options available to you in his blog post titled “If Your Business Uses Rails 2.3 You Need To Move To A Supported Option ASAP”.
In summary, you have a few options:
- Do nothing and face the consequences listed above.
- Turn off your application and pay nothing.
- Rewrite your application to use a supported version of Ruby on Rails (Recommended, but expensive.)
- Use a commercially supported version of Rails 2.3 and setup a maintenance plan with a software development team. (Less expensive. May be the right choice if you no longer plan to change your app.)
Remember, if you choose to do nothing, you will face consequences.
Your days of not testing your software are limited.
In the beginning, it didn’t seem like a bad idea.
You didn’t know exactly what you were building or if your product was going to survive. No one can blame you for doing what you did. I mean, writing tests makes everything take more time, doesn’t it?
"We’re good programmers", you thought, "we’ll come back to add tests later. Right now, progress is more important."
Now, those crazy early days are behind you. You have a better idea of what you’re doing and your team has grown. The needs of your product have changed, but “later” never came. Will it ever?
With each passing day, you stay convinced that it’s not the right time for tests. Problems appear. Some problems re-appear. That amazing progress you had in the beginning is slowing down.
"This is all normal.", you tell yourself, "This is how software projects go."
Now, the knowledge and finesse required to work with your app is locked up inside the heads of you and your team. The time required to train new employees is growing. Quality is getting harder to maintain. You’re feeling stress, and a growing amount of uncertainty.
The real owners, your client or investors, don’t need to know how it all works, but they need to know the risks that your decisions are bringing them. They need to know about the uncertainty you feel, but in the best way possible.
- What happens if one of your core team members leaves?
- How will you maintain the project in the long run?
- How can you make deeper changes (like updating dependencies, which you’ll need to do to remain secure)?
Saying to yourself “We’ll deal with it when we need to” may have worked in the beginning, but with some real progress behind you, it’s no longer a viable option. You’re responsible for the future of this project now. You need to have a plan, because “go out of business” is always an option and it’s looking for ways to find you.
Now, I’m not suggesting that testing is the answer for everything, but the teams that understand its value benefit by being able to prove their product works and provide the owners a better asset for their investment. New developers can be added easily, and the whole team can work together more effectively. Uncertainty shrinks, at least in the context of the technical needs.
So, you can keep telling yourself “We’re used to doing it this way”, or you can do the responsible thing and get ahead before your client or investors wise up to the sort of risks you’re taking without tests. It’s up to you.
Protip: Always leave a failing test.
Mornings can be rough. To make them a little easier, leave yourself a failing test if your work isn’t finished. When you come back to the project, it makes it much easier to understand where you were and figure out what you still need to do.
As a developer, setting expectations is the single most important part of your job.
As a software developer, your job consists of far more than just typing code into an editor. Here are some of your responsibilities:
- Provide estimates on how long tasks will take
- Understand the function of software you did not write
- Solve complicated problems simply
- Break large problems into smaller tasks
- Modify code for clarity or to better suit changing requirements (Refactoring)
- Identify and solve bugs
- Coordinate all of the above with others
If you interact directly with the users of your software, there’s even more on your plate:
- Translate requirements from users into a plan for working software.
- Provide summaries of complicated software in a simplified manner that the users can understand.
- Provide hopefully accurate estimates for work filled with unknowns
But beyond all of the responsibilities above, your most important job is to set expectations with the ones who pay you for your time (your “customers”).
Setting expectations means establishing a plan for how your work will proceed. It means identifying risks ahead of time and expressing those risks or unknowns to your customers so you both can avoid surprises down the line. It means establishing rules for how you’ll need to interact to make sure you can create the best work possible.
When done correctly, setting expectations can make the difference between burning out and enjoying the work you do for years.
As a developer, you are a craftsman who wields the tools necessary to create. You cannot allow expectations on your work to be set for you; to do so would be to put at risk the very heart of your creation. Your code is your work, you need to own the process of its creation as well.
If you allow your customers to set your expectations, here’s what could happen:
- Your customer will make decisions for how long something “should” take, which limits your ability to meet requirements well.
- Your customer will get frustrated when work does not proceed according to a schedule that does not consider the full scope of work.
- Your customer’s expectations will force you to produce work of a quality you cannot be proud of, which can have a lasting impact.
While in an ideal world, your customers will respect all the expectations you set every time, in reality, setting expectations is more of a conversation you’ll need to have to determine what’s possible.
Just remember, you are the one who wields the tools. When it comes to how those tools are applied, you are responsible for setting expectations. It’s your work, own it!