Category Archives: software

Good developers take breaks

Boring PresentationSomething that has become crystal clear since I joined the Spring team is how important it is to take a break. Good code happens when developers take breaks.

Of course there are times when I find myself working solid until 8:00 pm or later. But I try to make that the exception rather than the norm. Most of the time, I’m pulled away by my kids coming home from school. In fact, I’m often annoyed at stopping a minute early.

STTNG_pinballAnd yet I’m astonished at how many perplexing problems I’ve solved by simply stopping, doing something else, and **BAM**, the answer pops into my head. Sometimes within minutes, sometimes the next morning while putting shoes on one of my kids. Those are the moments when I remind myself that developers take breaks. I consider that payoff for having stopped early.

This phenomena is well know. In fact, you’ve probably heard of it. I also so it addressed keenly at a writer’s conference last year. Your subconscious is still working on the problem whether you are or not. Sometimes, when you aren’t actively trying to fix it, your noodle is freed up to look back at what you did, what you’ve read, and other things.

devnexusWhile chatting with a teammate of mine at DevNexus, he expressed that if he hadn’t taken various breaks, gone for walks and thought about the architecture he was designing, the project he was striving to build would never have happened.

HamletReflection is a critical component. My martial instructor often taught “visualize, visualize, visualize.” It’s a mechanism to put your mind on the subject, even when you’re not actively pursuing it.

The key thing is telling yourself to take that break. To pause. To stop and not burn the candle at both ends. If you work that hard, your subconscious will be on the ropes. Those extra ideas that can often succeed when you may have failed all day, may not come at all. It’s a big leap I know, but give it a try.

#opensource is not a charity

clock-with-a-questionLogging onto my laptop this morning, I have already seen two tickets opened by different people clamoring for SOMEONE to address their stackoverflow question. They appeared to want an answer to their question NOW. The humor in all this is that the issue itself is only seven hours old, with the person begging for a response when their question is barely three hours old. Sorry, but open source is not a charity.

gordonBatPhoneIf you have a critical issue, perhaps you should think about paying for support. It’s what other customers need when they want a priority channel. It definitely isn’t free as in no-cost. Something that doesn’t work is opening a ticket with nothing more than a link to your question.

question-not-answeredOpen source has swept the world. If you don’t get onboard to using it, you risk being left in the dust. But too many think that open source is free, free, FREE. That is not the case. Open source means you can access the source code. Optimally, you have the ability to tweak, edit, refine, and possibly send back patches. But nowhere in there is no-cost support.

pivotal-ossIn a company committed to open source, we focus on building relationships with various communities. The Spring Framework has grown hand over fist in adoption and driven much of how the Java community builds apps today. Pivotal Cloud Foundry frequently has other companies sending in people to pair with us. It’s a balancing act when trying to coach users to not assume their question will be answered instantly.

helpingI frequent twitter, github, stackoverflow, and other forums to try and interact with the community. If at all possible, I shoot to push something through. Many times, if we’re talking about a one-line change, it’s even easier. But at the end of the day, I have to draw a line and focus on priorities. This can irk some members not aware of everything I’m working on. That is a natural consequence.

Hopefully, as open source continues to grow, we can also mature people’s expectations between paid and un-paid support. Cheers!

P.S. For a little while longer, there is a coupon code to Learning Spring Boot for 50% off (Python Testing Cookbook as well!)

Banner (LSPT50)

Why software development is not for everyone

Have you ever had gobs of fun hacking away on a computer? Noodled with a piece of code that you discovered in the afternoon, and here it is, 2:00 a.m.? That’s a sign you may be a computer geek. That’s all and good, but the question that may come before you is, do you want to make this your dream job? Your career? Watch out, though. Software development is not for everyone.

mr_potatohead-300x190I fear that some people may be getting into software development because computers are now hip and cool. And the money is good! I remember a time, several years ago, when I saw the corner turn in how computer geeks were no longer the goof bots found in Wargames, but instead, totally righteous dudes.

What was that tip off? A TV ad for liquor which showed “Jim from IT” partying just like everyone else. TV ads are a bellwether for trends, because that write them are constantly polling groups of people to see what will resonate. When IT people had entered the main fray of the party-going crowd and were seen a force to be reckoned with (err…a force to be advertised with), then game over.

The side effect of anything going mainstream is that others, who have no deep seated desire to submit and review pull requests on vacation (for the record, I’ve actually done both at Disney World. Top that!), will still flock to the field since its cool, and there’s money to be made. Am I saying that to get ahead, you must be a workaholic and eschew your family? Not at all. What I’m saying is that computer geeks that are in it for the challenge and not just cuz it’s cool can’t help themselves but do what i just described.

So far, I’ve talked about hacking on bits of code at odd hours in odd places. But here is the real test, the true gambit to see if deep down you really are a totally righteous hacker dude: do you go after the most boring, challenging, mind numbingly difficult problems until the code surrenders its secrets to you?

Do you go after the most boring, challenging, mind numbingly difficult problems until the code surrenders its secrets to you?  –sign of a righteous hacker

I have been working on something for several months that is coming to light in less than two weeks. (Stay tuned!) For MANY hours/days/weeks, every time I tweaked one line of code, I had to restart a microservice. That microservice would take, on average, two minutes to load up its data set from a remote system. Next, I went to another tab and clicked on a button to launch a process, and wait to see if my system detected it and processed it correctly. Got that? Edit one line of code, wait five minutes for the results, then debug the outcome. Rinse and repeat.

aaarrrggghhhAaaarrgggghhh!!!! <— that was my reaction on many days. And my followup was, “thou shalt not defeat me!” My street cred was at stake, and my own internal desire to beat this system into submission were there as well.

Suffice it to say, trudging through this task is not for the faint of heart. Software hobbyists need not apply.

I’ve always hated the expression “9-to-5 coder.” It’s meant to imply people that only work on the clock, and don’t work late hours, etc. In general, I do that as well. At times, I have to alert my family that I’ll be putting in extra hours (especially the month before SpringOne each year), but in general, I have found that working smarter, not harder, and thinking out solutions before slinging code can make things more efficient.

So I prefer to think of developers not based on the hours they work, but rather, are you a hobbyist or a diehard coder? Diehard coders will take the most ruthless problems and dig, dig, dig, dig, and dig until the answer is found. They are willing to take many hits, submit faulty patches, and screw things up big time, because the end game is important. Version control is our tool to save us from screwing things up, not timidity. Are you a hobbyist that fears making a big change? Or are you a diehard hacker ready to show your handy work to others?

I remember this topic coming up when a website popped up offering bounties for people to solve problems. This was rightly criticized as encouraging people to go after easy–to-tackle issues, or selecting issues that carried much public praise, like UI mods. But serious, professional hacks will take some of the most invisible things (like a 300ms slowdown) and go to extreme ends to unearth what’s wrong. Imagine trying to get ANYONE to pick up that issue for a bounty.

If such tasks sound outrageous or tedious, no problem. I understand. You are hobbyist. Nothing wrong there. But if you’re ready to dive into the slimiest mud bath of code, smile. You are rare.

We won’t own our own information until we do

Not a week goes by when I hear some story about people displeased with how their own content has been misused. People gripe that entering stuff into Facebook no longer belongs to them. Other people copy-and-paste such stuff into other places. Things go “viral”.

I chuckle at how so many politicians act like we are still in a pre-YouTube era. They say and do stupid things in front of small crowds. Someone inevitably grabs a clip with their phone, posts it to YouTube, and it blazes across the twittersphere. Or someone makes an accusation or promise, and in minutes, a video interview from fifteen years surfaces and gets re-posted to the interwebs.

The truth is, there should be some sense of ownership of our content. If I post something, somewhere, I understand people’s desire to hold onto it and have the last word. Unless you speak it in front of someone else, and they make an independent copy, it makes sense that you should be able to effectively delete your posting. What you said and the repercussions thereof are your own issue to deal with.

The truth is, we can’t “own” anything we write anywhere unless we can wrap it using encryption technology. Essentially, if every blurb you posted was an encrypted bundle, people would have to come to you to decrypt and read it. Throw away the key, and that blurb is gone forever. For certain avenues, like everything I write on Facebook, I can understand retaining a hold on it. And if someone wanted to copy-and-paste it, it would be really nice is the encryption traveled with it. Copy it 1000 times, as long as the wrapper is in place, and you still control it.

But there in lies the rub. Encryption technology has proven far too difficult for mass consumer adoption. Just now, the web is headed towards moving all web traffic from HTTP to HTTPS to prevent intermediate snooping. This should have happened years ago. But the next big leap would be encrypting all email traffic. With people losing laptops and thumbdrives, lots of security breaches have happened. If ALL email was wrapped in encryption, privacy would be a much stronger concept. But the process of doing that is arduous. Exchanging keys, keeping your private key secure, and then entering passphrases all the time is a hassle.

Take that concept and apply it to every other medium in which you write something. Even this blog entry! It’s safe to say, such a concept won’t come to pass until it becomes effortless to prove on a terminal you are who you say you are, and to lock and unlock keys suitably. Seeing the web move to SSL is a good sign. I just hope we can migrate along these paths faster than we can figure out to integrate stuff together smoother. We must own the pipes and the traffic our data rides along.

Continuous Integration, or What doesn’t kill us makes us stronger /cc @ewolff

I have gotten onboard with using Travis CI for several projects. It is really cool. You can see some badges listed here:

  • Spring Social Ecobee Build Status
  • Issue Aggregator Build Status
  • Drone Aggregator Build Status

(You can go ahead and click the icons to see more)

Having a constant indicator of something passing or failing is incredibly handy. But upon reflection, I remembered having built just such a system over fifteen years ago.

A long time ago, in a cubicle far, far away

Back in the dawn of my career, I wasn’t granted the privilege of coding features. Instead, I wrote tests for other people’s features. This was a time that predated automated testing and developers being on the hook for their own stuff. Instead, test teams were employed to attack the code with a battery of written procedures. To warm me up to the system, I unit tested other people’s stuff. I had cute test cases that would print out the code’s outputs and my own expected outputs. (Why I didn’t make the final link and simply assert those two values being same I’ll never know). But my tactics of having visualize printouts where these two values would appear right next to each other on the console inspired others to do the same. I spotted another tester quickly adopt my technique. First instance of professional flattery I can remember. It goes to show that when you have to do testing all day, you come up with ways to check off the box faster when values match. (Again, no idea why I didn’t let the test compare the values. Newbieness?)

I shared a cubicle with another junior developer. His job was to run handle the CM process. At the time, our application took ten HOURS to build. You heard that right. Thank you ADA. We also used an ancient form of version control. I call it “one dimensional” version control, because there was no such thing as branching off of master. There was a single, monotonic set of version numbers. When people needed to check out a copy of the system, they came to my cube mate to clone the baseline, which was really what people today might call a version snapshot. That’s because copy the entire baseline from a version snapshot and doing a first, clean build, took ten hours. No senior developer’s time was worth it to do that process themselves. (Incidentally, this is the reason features were HUGE and took weeks or months to complete. If it was going to take ten hours to cut a new workspace, might as well cram as much functionality as possible into it, ehh?)

That which you support you may one day take over

The side effect of sharing this cubicle was that i became his backup. So, I learned how to do his job. Perhaps you can see where this is going? I ended up taking over his job. He moved on. Granted, he had graduated from college with a degree in English and truly sought a career as an author. This was just his daytime job. So he took the path of least resistance. I had a different thought process. I strove to speed up everything possible.

One of our processes involved moving up the “stable” version of things. We had a weekly meeting where my manager would review completed features, and essentially give the green light for to move the “master” position of things. FileX.ada would move from version 4 to version 8. FileY.ada would move from version 15 to version 19. You get the idea. Very expensive and subject to MANY errors. I hated this process. So I sought to fix.

My first Continuous Integration system

Being the script junky that I was (still a bit premature for “test-bitten”), I used that spare time of watching ten hour builds spin their wheels to craft some PERL scripts. I knew how the current batch of scripts operated. What if I kicked off the same build process, only automatically at midnight against the “master” snapshot? What if I captured the outputs in a log file? That way, everyday at 10 a.m., I could review the latest build and spot any errors. After a little chat with a sys admin (I was using a SUN box at the time), I crafted my first CRON job.

It took a few iterations of coming in and seeing if my job launched. Translation: I wrote a CRON job and came in the next morning to see if it ran. At all. Failure? Tweak the job and wait until tomorrow. Several days later, I had the job working great. I could peruse the results and alter the format of the output. Now that i was reviewing this daily report, I started to alter its format. There were key things i skimmed through to spot. To make the reading easier, I prefixed them with “!!!!!”. After a few weeks of this fine tuning, I started to filter the report to ONLY look for this tag. Finally, I added the feature that if there were no “!!!!”, then the build was a success.

By the way, this wasn’t running my test suite and verifying the code. I was too green to see that. Instead, this was simply COMPILING the code and seeing if it passed. But once I had this report in place, I crafted some queries to look at who had submitted what today we might call a “pull request”. My scripts would look at the newer versions of the files, create a snapshot copy with those changes, and do the build job. I would see the outcome at 10 a.m. If it passed, my new copy became the new “master” snapshot. If not, I chucked it and instead focused on what broke. I would take this feedback to the relevant parties and let them sort it out.

Manager’s delight

When I presented all of this to my manager, she was delighted! Pretty soon, those weekly integration meeting vanished. I had figured out a way to continuously build the system with the latest changes and upgrade things. I could start the day with running my test suite against a newer version of things. Yee-hah!

The management team extended my time on this project twice. I was clearly kicking butt and taking names in the land of integrating completed features. But I wanted to build the systems myself, not simply maintain what other had done. So the third time they asked for an extension, I turned them down. I moved on to other projects my company was hosting. But I had cut my teeth on what today everyone knows as continuous integration. Picking up skills in CRON jobs, understanding the core mechanics and ramifications of version control and change management, and seeing the benefit of automating the heck out of things had paid me back with dividends throughout my career.

Seeing tools arise that make it easier and easier to seek higher quality in software warms my heart. Create your repo on GitHub,. Link it up to Travis CI and fiddle with a few settings. Have it deploy automatically to production on Cloud Foundry. Plugin a Chat Channel (gitter). It feels like ten years ago, we were working in the stone ages. I just wonder what things will be like ten years from now.

Checking out editors

idea_sublime_atomIf there is something software developers do, it’s get real picky about tools for editing software. That’s why there are strong, almost religious debates about vi vs. emacs. I recently got fed up with TextMate for various reasons, so I decided to investigate more than my usage of vi.

I’ve included a screenshot of all three, side-by-side on my 39″ monitor. You guess which is which.

Sublime Text 3

This one I have found to be pretty neat. It’s fast, snappy, and opening up a project is a single command from my shell: subl /path/to/project

I quickly got moving when I learned there were only two key commands: Cmd-P and Cmd-Shift-P. The first is used to find files. You start typing fragments of a filename, and it quickly narrows your selection. Pick it, and it’s open in no time flat. That nicely matches Java’s one-class-per-file convention. Cmd-Shift-P is the Command Palette, which lists every available command. You then start typing fragments, and your list of commands shrinks. Then you can arrow-down and pick it, or hit the hotkey. Having a single way to find any command or file saves me from going to my trackpad and using the menus.

In the JavaDocs, HTML tags are nicely highlighted. Sometimes the color choices of Java syntax seem a tad awkward. But I rarely alter settings because I always fear either losing them, or going to someone else’s machine and not having them. Perhaps I might be able to stash them in Dropbox and soft link them in?

Another killer feature is the right-hand miniaturized layout of the entire file. Hover over it, and you quickly see where you are.

I’m still pretty new, so I haven’t learned how to open multiple tabs on the same file yet. Nonetheless, this tool is already productive for me!


After spending almost a whole day adding new asciidoctor content, my colleague Roy Clarkson hinted that I should check out Atom. I downloaded it last night and took a peek.

Nicely, Atom has the same keystroke to pull up the Command Palette. This feature sure must be popular. Right off the bat, I noticed the font size was a bit big. While it appealed to fuzzy vision, it was too impractical for the ground I needed to cover. Felt like I was peeking through a tube to see the code. So I pulled up the Command Palette and shrink the font size about five times so it approached the size of Sublime.

Opening the same file in the same project, I noticed that the color palette of syntax highlighting was a bit easier on my eyes. The contrast between bits of code didn’t seem wide enough, while Sublime’s contrast was a bit much.

I read an article pointing out how Atom is built on top of Chrome, JS, and Node, and conveniently comes with the JS toolset. Another article heavily criticized Atom’s shaky foundations which can start to magnify performance issues as you get into bigger projects. I’ve already seen a bit of this when trying to find files. Sublime just seems snappier.


To compare things in full, I switched IDEA to it’s Darkula theme and opened the same file in the same project. A third syntax highlight color palette. Great. This dark-theme on IDEA is softer on the eyes, but some of the color clashes kind of turn me off. I’ve tweeted before that I don’t get it. Yet, at the same time, I use green-on-black for Terminal and totally dig the white/color-on-black of the other editors. Perhaps if I commit to a couple days, I might get into this?

What does IDEA have that the others don’t? IDEA is a full fledged IDE. Pick a function, then find everywhere that it’s used. Editors aren’t designed to do that.

This Command Palette from the editors has encouraged me to learn how to do that in IDEA. Apparently, Shift-Shift is the way to pull “Search Everywhere”. I am trying to do more of this. I have already learned how to find files and classes as well as pull up refactoring toolbars. These are all handy features. But to speed up the action, I need to jump to the command palette. From there, you can see commands as well as learn their hotkeys. More time on the keyboard is the ticket to efficient coding.


So far, IDEA isn’t going anywhere. I need this type of stuff. I just have to keep improving my efficiency at using it. As for an editor, Sublime is ahead of Atom right now. But like my bio says, I’m always looking for the right tool.

GitHub isn’t your CV, and GitHub commits don’t show your talent

I previously wrote about how GitHub isn’t your CV, and went on the even close my LinkedIn profile because of how little value it actually provided.

GitHub’s eye candy

Lately, I noticed people posting things like diagrams of burnout based on a dwindling number of commits to GItHub. Once again, it seems like GitHub likes to invent metrics and measures that seem to me little more than eye candy. Yet I fear managers and engineers using them as hiring metrics.

As my best example of such useless eye candy, I will point out myself. I am a self dubbed editor-at-large for Spring’s Getting Started Guides. The side effect is that if you go check out all the guides, you’ll find my name spread across almost all of them. I can probably claim 80%+ of the commits as well. It makes my GitHub profile look crazy with bursty rates of activity. For a full comparison, compare myself to my colleague Roy Clarkson. GitHub is showing that I have over 2600 commits for the pat year while Roy has 610. I fear that if Roy and I were somehow applying for the same position, someone might use that crazy metric to make a decision!

The truth is, Roy is a project leader for both Spring Mobile and Spring for Android. Roy has tackled countless problems, and being a one-man-band for two projects, has tackled an armada of issues with no one but himself. Passing on him due to a silly metric would be foolish.

The reason I have so many commits under my belt is that I wrote a tiny script that made it easy to roll the guides whenever a new version of Spring Boot comes out. It looks like this:

#!/usr/bin/env python

import os
import re
import sys

if len(sys.argv) < 2:
    print "Usage: %s " % sys.argv[0]

with open(sys.argv[1]) as input:
    with open(sys.argv[1] + ".new", "w") as output:
        content = input.readlines()

        for line in content:
            if "1.1.9.RELEASE" in line:
                output.write(re.sub("1.1.9.RELEASE", "1.1.10.RELEASE", line))

os.rename(sys.argv[1]+".new", sys.argv[1])

That 22-line app has saved me hours upon hours of effort and allowed our guides to stay up-to-date with the latest releases of Spring Boot. It’s the reason that when Phil tweets about a newly released version of Spring Boot, I usually tweet about the guides being updated within the hour. My teammates have come to assume my answer to a given problem is, “I can write a script for that.” And this app is nowhere to be found in my GitHub profile.

All code requires context to be properly evaluated

That is the kind of code and context I would carry into an interview. It shows that I know more than one language. I know that not everything is a Java application. It shows that I also understand the dividends paid in saving engineering time. And it shows that I understand the value of keeping documentation up-to-date.

The unfortunate side effect is that GitHub now shows me with MANY days of having bursts of over 50 commits. The thing is, if you were to hire me, there is no guarantee that I would be knocking out 50 commits on key software components. (Unless I write a script that starts doing document updates the same as I do now.)

Hiring others isn’t easy

I have actually hired people in the past. Long ago, when I received my first promotion, my manager explained that I had reached a level where interviewing candidates would be part of my annual evals. I took that on full steam. I interviewed dozens of people. I quickly learned that the one hidden question to ask yourself is, “would I want to work on the same project, side-by-side, with this person?” As can be expected, not everyone was perfect.

But nothing in a resume or any other publicly visible metric tipped me off about the best nor the worst people that worked directly for me. One person took over the mission critical app I had led for years. He had new ideas I would never have thought up. Another was a copy-and-paste developer that couldn’t seem to learn new lessons. He didn’t last six months. There was no way to know this short of actually working with them for a few months.

People, please don’t pick pre-fabricated metrics and eye candy as your criteria to hire and fire. Use real talent and judgment. And be ready to ask yourself, if this person doesn’t work out, what will be your course of action?

Why github and LinkedIn are not my CV

I recently read a compelling article, “Why github is not your CV“. I was shouting “yes yes yes” as I went through it.

As you may or may not know, I recently closed my LinkedIn account. I was feeling some of the same things the first article expressed. In short, these platforms don’t let you put together a properly edited and polished perspective. Instead, they put together a one-size-fits-all view and try to couple several features that they think work, like building contact lists.

I prefer to use my own blog site as the place to publish my public persona. I spend time on the sidebars showing key things I want people to know. I order things as I see fit. And I move things up and down based on priority. Try that with github or LinkedIn.

The best developers aren’t always found on github

Another critical nugget in that other article is the issue if your company won’t interview someone with no github profile. If having a github profile was a critical component, I would never have made it to the Spring team. I had worked for years at my prior company, polishing skills, and building rock solid apps…for the government. None of my work was staged on github.

Yet I had maintained a mission critical, 24×7 system. This was a system that evolved constantly and had tons of real world issues I had to solve. With a legacy, EOL’d, no books or public forums language. Your ability to contribute to OSS projects should NEVER be the end all/be all of your skill set. If you want to become a team leader for a particular OSS project, your contributions to that project are certainly of value. But the lack of such contributions shouldn’t be viewed as a negative.

As a meet more and more people, and travel more and more places, it is apparent that the universe of software development is infinite. Whether or not someone has contributed to OSS is simply not enough to slap a pre-determined filter on prospects, which is what recruiters are always looking for.

The value of software communities is greater than ever

ch2_fodtAs I continue working on my new book, Learning Spring Boot, I have really noticed the value of communities today compared to when I became a professional software developer back in 1997.

Back then, there were news groups and mailing lists, but not the same indexing of EVERYTHING, no Google Groups (which just made searching/working with news groups MUCH easier), no panacea of discussion forums, and no proliferation of blog sites. These things existed, but you wouldn’t find so many, and so dedicated (like trying to write a query for your trade novel, one of my favorites). And open source hadn’t taken root like it has now. Your prospects of finding an open source project with a thriving community to serve your needs were MUCH less likely.

So how exactly did we survive without such a rich community? Sometimes I’m mystified. Back then, I would comb the book store for help. It also meant I had to hunker down and really go through code myself to figure stuff out. What’s that you say? You think that I’m whining about having to actually WORK back then? I worked then, and I work now. It’s just different.

Today, perhaps there are more people willing to help you get over a hump. Back then, getting help meant walking across my cubicle hallway and asking the right team guru questions. Over time, I would pick up my own set of skills and quirks. And others recognized that. Eventually others would come to me asking for assistance.

Back then, I knew someone that NEVER deleted emails. I didn’t comprehend such a concept. Today, I’m a tried-and-true believer in keeping everything. Knowledge is power, and having my entire history of communication available has been useful. In fact, when I finally moved my personal email off the telco provider I’d used for years, I searched for someone that could handle migrating all that email to my new account.

Today, it seems impossible to develop anything in a vacuum. I tap twitter, discussion forums, and other places. The latest incredibly powerful social tool for interacting, getting feedback, and making substantive progress if GitHub! Git is a powerful tool for version management, but you can’t realize its true value until you work on a community project with forks, issues to discuss things, and ultimately pull requests.

I launched my book writing endeavor by blogging and tweeting what I was up to. On my previous book, I got enough attention that I was able to shift off a tool that had fallen into disuse and pick something better. I even got quotes from project leads into my book.

This time, I attracted the attention of both Dan Allen, the project lead for Asciidoctor, as well as an editor from Packt Publishing. I am building a new Asciidoctor backend for Packt, and this might be the track that makes it mainstream. Dan quickly helped me get going on something that I couldn’t make heads or tails of when I read it by myself. If Packt bites at somehow making this backend an officially accepted medium, the lives of MANY future authors may be made simpler while also improving the content of future titles. (That applies to my own future writings!)

To paraphrase Hugh Williams, Pivotal’s new SVP, skills are fleeting. The knowledge you are using today will probably be totally replaced ten years from now. But what’s critical is judgment, ability to learn, and willingness to interact with others. And nothing serves that better than a strong community.

Stay app – you’re hired!

4K_work_envAs follow up to my previous article, My Software Cheapskate Days Are Behind Me, I’m proud to say I just purchased the Stay app. That app is so frickin’ wicked, it rivals Tweetbot.

I recently bought a 39″ 4K display as my monitor. Whenever I would unplug my laptop and take it elsewhere, all my windows would bunch together. Then when I would reattach after returning, they would be shoved in the corner of my Seiki monitor. I had to manually drag them back into position, resize them the way I had done before, and slowly put things back into order. After doing this for the umpteenth time, I was incredibly annoyed and began to google for a solution.

Someone on Stack Overflow made reference to this app, so I checked it out. The results were amazing. The Stay app uses the Mac’s Universal Access APIs to scan for all windows and sniff out their coordinates and dimensions. It then stuffs them into a database, with a different profile for each display configuration.

Finally, you can configure it to restore window layout every time the configuration changes. This means that when you unplug the big screen, the windows will jump to your alternate layout for just the laptop. Plug it back in, and things jump back to big screen layout. And I can already sense that when I build a 3rd profile at the Nashville JUG for the overheard, Stay will save that as well so I don’t have to rearrange anymore.

Here’s the bonus. You can pick whatever shortcut you want to direct Stay to catalog the positions of all your windows, and when to restore positions. Only when I completely rearrange everything do I tap that function. Most of the time, it stays out of my way, and just does one, simple thing. Put the windows where I had them last. THAT is worth a measly $15.