Kyle Cordes

Today I looked for a way to import issues (including history) from Github Issues to JIRA. I was delighted and disappointed to find at least three different implementations of a Github Issues to JIRA-CSV exporter – all honestly described as rough one-off efforts.

It seems  likely that I’ll adapt (add minor improvements to) one of the above to yield another solution for this, and perhaps publish it here, so there will then be at least four choices for the next person to find. It seems a lot of small problems end up in this condition. Is that what meet users’ needs best? Certainly not. Hopefully Atlassian will step in eventually with a broad, well-tested set of issue importers for JIRA. JIRA seems to be a market leader, this is an opportunity to step up and earn that role.

Tags: JIRA

Application Deadline: May 15, 2012.

It’s almost time for our Summer 2012 internship program. You might want to look back to our 2011 program, or our inspiration, the Fog Creek program. Interns at Oasis Digital work on serious, complex projects, though the work is generally exploratory in nature (rather than part of our enterprise development work for customers). Interns write software, test software, write about software, etc. The purpose of the work is to educate and enlighten the interns, and also create something useful to Oasis Digital and its customers.

Who?

We plan to hire two or three student interns.

Unlike some programs, ours is for high school students, or recent graduates about to enter college.

How Long?

The work will last about 10 weeks, from the first week of June through early August. Interns should expect to work around 30 hrs per week, though only a small portion of that will be on-site in-person. Other than a few fixed meetings per week, your schedule will be flexible.

We can adjust the dates if needed, to accomodate college start dates, family vacations, and so on.

Where?

Interns will meet at the Oasis Digital office two or three times each week. Our office is in Chesterfield, MO; the address on our company web site needs to be updated. Therefore, interns must live in the St. Louis metro area and have transportation available.

At these office sessions, we’ll all work together, and interns will learn from various Oasis Digital developers. Outside of that, interns will work alone, and meet to work together, for a total of around 30 hours per week.

Does it Pay?

Yes, these are paid internships. Each intern will earn about $2200 for a full summer of work.

In additional, our meetings will be scheduled to include a company-paid lunch a couple of times each week.

What Will We Build?

The project for this summer will be a workflow management system, with web and mobile-app (smartphone, tablet) interfaces.

Interns (with help from Oasis Digital staff) will create an end-to-end system:

1. Database Schema
2. Server / backend services
3. Web client application
4. Mobile (native or HTML5) app
5. Tablet (native or HTML5) app
6. Document and deploy all of the above

The schedule goal is to develop an extremely simple version of the above, and “ship” it in working condition, halfway through the summer. Then with the rest of the summer, add interesting features, platforms, polish, etc. GPS, mapping, photo support, multitouch clever interfaces, anything is possible.

More importantly than what we will build, is what everyone will learn. Expect to learn more in this summer than you would in many classes.

What Language?

The exact toolset will be worked out by the interns, and may include:

• JavaScript
• Node
• JQuery and similar libraries
• Java
• Clojure
• Git / Github
• HTML (including HTML5)
• PostgreSQL or MySQL
• Linux, Windows, OSX
• iOS, Android
• Various other open source tools and libraries

Requirements

• Excellent command of written and spoken English
• Currently enrolled in high school, or just graduated.
• Top grades or a track record of success
• Permanent legal right to work in the United States
• Great (for your age) computer programming skills
• Live in the St. Louis MO metro area
• A computer available to work on, when you’re not at the office

How Do I Apply?

Apply via our job application page, not by email or phone. This is the same mechanism we use for hiring non-interns, so it is perhaps overly complex; we expect intern applicants to have a short, one-page resume listing interests and personal projects, not professional work.

Please apply by May 15, 2012. 

Here is the first, in hopefully a series, of posts about basic software design. Though not nearly as sexy as a location-based mobile social network with behavioral profiling for ad optimization (probably a real thing), doing basic software design well is one of our “secrets” at Oasis Digital. So here goes.

Today’s topic is how numbers should be formatted for tabular display. This comes up quite frequently in data-centric applications. For an example, consider this mockup of a working-hours-per-person display screen, example 1:

It looks quite nice with the numbers formatted trivially as whole numbers. What if someone worked 4.56 hours, though? How would that appear? To accomodate that possibility, you might always show two digits to the right of the decimal point like so, example 2:

… which is OK, but not great – all those extra zeros distract the viewer from the essence of the data. One thing you should never do, though, is something like this:

This is horrible. If you feel tempted to write software that displays data like this intentionally, please step away from the computer now. This breaks the rules of writing numbers that we all learned in primary school, probably before the age of 10: always line up the decimal point. Instead, for that particular set of numbers, the is reasonable:

So is the answer to always display as many decimal digits as the data could possibly have? Perhaps, but only if you are unable to dynamically change the format based on the contents of the data. Examples 2 and 4 show a safe but unimpressive approach.

If you have the tools and skills to create a high quality solution, aim higher: dynamically choose the right number of decimal digits, to fit the specific data in question, then apply that same format uniformly to all the numbers. The output will therefore look like #1 if the data permits, and like #4 if the data requires it, but will not needlessly fill a column with 0s as in #3. This is more work, but is a more polished, professional result.

Tags: basics, commentary

I’ve done a fair amount of pair programming over the years. My “Ward Number” is 1, if anyone recognizes the reference. But we pair only occasionally at Oasis Digital. Like Jeff Atwood, we don’t live the pair programming lifestyle. For our particular mix of people and problem spaces, we’ve found the sufficient amount of pairing is roughly a couple of times per week, a couple hours at a time. We’re a partially distributed team, so this often occurs via screen-sharing tools instead of at the same desk.

However, we do something perhaps even more “extreme” than pair programming: we spend a few hours every week programming in larger groups, sometimes as many as three of us in person and a couple more remotely. Why would anyone do that?

• To attack particularly hard problems
• To resolve important detailed design issues
• To share our programming style and culture
• To freshen old skills
• To build new skills
• To efficiently pass knowledge 1->N, rather than 1->1

I don’t quite know what to call this. Group programming? Cluster programming? N-tuple programming?

Regardless, we encounter an unavoidable issue: it is not pleasant for several people to cram in front of a PC monitor, even a large one, closely enough to read it. We’d rather spread out, particularly for sessions lasting a couple of hours straight.

In the past at other firms I’ve solved this by working in a conference room with a projector. This doesn’t work very well. Most projectors have a maximum native resolution of 1024×768, or occasionally a bit higher, and those with reasonably high resolution are quite expensive. The reward for spending that money is continuous fan noise and an exhaust heat plume blowing on someone sitting on the unlucky side of the table.

This time we went a different direction: our group programming lair features:

• 40-inch LED-LCD HDTV, with a native resolution of 1920×1080, which generates no noise or heat, at less cost than a mediocre projector
• A dedicated computer, so noone’e development laptop is occupied
• wireless keyboard and mouse can be easily passed around
• Speakers and a standalone mic, for very clear Skype audio
• Nearby tables to accomodate everyone’s laptops, with 22/23 inch extra displays available

It isn’t pretty:

It is very effective. We can comfortably work together in this area for hours, easily reading the screen from 6-8 feet away. (As I write this, I note that the room needs better chairs, a less beige color scheme, a printer that isn’t older than my teenager, and more Apple hardware.)

This approach isn’t for everyone; it requires a willingness to move furniture and buy non-standard equipment. I’d love to hear from anyone else doing something similar. In particular, I wonder how it compares to Pivotal’s setup.

Tags: code-review, pair-programming

If you haven’t already done so, now would be a good time
to watch Steve Jobs’ 2005 Stanford commencement address.

On Thursday (May 26, 2011), I presented at the St. Louis Mobile Dev group, on cross-mobile-platform development with Lua. There are various ways to do this (including rolling your own), but for simplicity I used Ansca’s Corona product. The talk was somewhat impromptu, so I didn’t record audio or video. The slides are available:

Tags: lua