Metabase: An Easy Query Builder For Your RDBMS

If you have a relational database as the primary datastore for your application, and you want to easily allow non technical folks to build reports against data in that database, I highly recommend evaluating metabase. This open source query builder is dead simple to install (takes about one minute on a free heroku dyno). You can create individual users, and they all get access to an easy to use interface so they can look at data in your tables. All the nomenclature is non technical, nary a select, group by or from clause to be seen. It’s written in java, but you don’t have to know java to run it.

We haven’t used this for long, so I can’t talk much about the warts, but I was referred to this by someone else who had great success in using it in their organization. The only downside that I’ve seen so far is that joins are not supported, so you end up having to create views if your database is normalized. More on that decision.


Absence of evidence is not evidence of absence

I am on a mailing list of engineering leaders and someone mentioned that they have found Github to be a very good indicator of whether a candidate is a good choice for them.

Of course, every company will emphasize different aspects of software development–for some technical expertise is more important than communication, while others have that ranking flipped. Some may emphasize ability to work in large teams, while others may prefer folks who are self driven.

But I see a fair bit of emphasis on Github profiles, which makes sense–you can actually look at the code someone has written, and how they developed it.

But here are some reasons why someone might not have a stellar Github profile.  They might:

  • prefer to use bitbucket so their code is private
  • have a restrictive employment contract
  • not want to program when they go home
  • want to learn about software by experimenting on their local computer
  • learn about other aspects of software development by reading rather than doing
  • focus on answering questions on Stackoverflow
  • not have time to have anything on their profile due to other commitments

If someone has a great GH profile, that’s probably an indicator they are a good developer. But if they don’t (full disclosure, mine is kinda weak), that’s no indicator of anything other than that they haven’t made it a priority.


Do you need a mobile app? Probably not

This post from the folks at 18F does a great job of covering why you should default to a responsive web site rather than a native mobile app. While tools like cordova and react native decrease the effort required to build a native application, the ongoing maintenance costs shouldn’t be underestimated.  It is easier to outline the reasons why you should build a mobile application, because there are far more reasons why you should not. From the post I mentioned above:

  • extreme bandwidth constraints or offline operation
  • heavy use of sensors that are not web standards
  • third party interactions

I’d add:

  • branding needs, where you have a compelling application and expect to be be installed on the user’s home screen. Expect to spend $$$ on marketing the app
  • extreme performance. This might be graphics/video, battery or network performance

and, via twitterSara Bates added:

  • push notifications, (if used wisely)

If your application doesn’t meet these criteria, I’d think long and hard about launching with a native mobile application, and think about what you could do for your business with the extra budget.

You can likely prototype your app with a responsive website and then build a native mobile app when you know more and/or have user feedback. This can be a great way to economize, because you can leverage outsourced mobile app teams and point them at the prototype as a living requirements document.


When do you earn your pay?

I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.

However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:

  • When I face a problem that you’ve never faced before and have no idea how to tackle it (like setting up recurring bookings over daylight savings time changes).
  • When I ship a bug that costs your customers money and I have to analyze how much money was lost and a game plan to fix the bug and get them their money. Then I need to contact the customers to apologize as well as let them know what the plan is.
  • When I realize I’ve chosen the wrong implementation for a component.
  • When I realize I’ve made an architectural decision which made sense in the moment but will have maintenance and performance costs down the line.
  • When the system crashes and I know the reason, but I haven’t figured out a way to replicate it or to fix the issue.
  • When a system is slow and I am unsure where to start looking.
  • When someone on my team isn’t working out and I need to let them go.
  • When I watch a user navigate around your system and totally miss features that will make their lives much easier.
  • When I join a new project/company/team and walk into an existing system of software and personalities about which I have very little clue. And yet I want to be effective and move things forward, but need to be patient.
  • When I argue with someone about the best way forward, and then my path isn’t chosen, and I have to support the plan that was chosen.
  • When I argue with someone about the best way forward, and then my path is chosen, and I have to work with people who disagreed and may not fully support the new plan.
  • When I am at the end of a project and I just want the damn thing done, and yet I have to maintain the same level of attention to detail that I had at the beginning when the idea was all new fresh and exciting.

You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.


Speed up development by catching your mail locally

Have you ever been developing some kind of application that sends email? You need to test how the email looks, so you have to have access to an external SMTP server and you have to configure your application to use that. You can definitely set up sendgrid or another MTA to send email from your local computer and then use a real email address as your target. However, then to develop this portion of the application you need to be online.

Another option that I’ve found is the Mailcatcher gem. This is a small ruby program that you can easily configure as your SMTP endpoint. Then when your development environment sends mail, mailcatcher catches it. Then you can visit a URL on your local computer and view received emails. As soon as mailcatcher shuts down, the emails are lost, however.

Even though this is a ruby gem, you can use the app with different languages–as long as it you can configure the application to point to an SMTP server, you’re good (in the readme, there are examples for Django and PHP).

One note about it being a gem. Don’t put it in your Gemfile if you are building a rails app, because of possible conflicts. This means that if you manage your ruby environments via rvm you’ll need to re-install mailcatcher every time you change your ruby version.

Bonus: mailcatcher even has an API so you can use it in your integration test environment to verify that certain actions in your application caused certain emails to be sent.


How Trello Wowed Me By Handling An Edge Case

We are using Trello for our product development planning at The Food Corridor. Previously we were using Pivotal Tracker, which I chose, but a new team came on to help us and they were more comfortable with Trello. I may do a compare and contrast of these tools in the future, but for now I wanted to celebrate the beauty of a well designed piece of software.

I don’t mean how Trello looks, though it certainly looks pretty. I mean how they handle UX edge cases. I ran into one the other day, and it blew my mind that Trello acted as I had hoped.

Here’s the situation. We use the Trello numeric card ID along with this git hook:

#!/bin/sh

# from http://stackoverflow.com/a/16061192/203619

if story_id=`git branch |grep '*'|sed 's/.*-//'`
then
    echo "[#$story_id]" >> "$1"
fi

To help tie commits to stories. If someone is working on a story with the id 123, they work on a feature branch called add-new-feature-123. When committing, they may write a message like: “Updated the message to the end user when they save”, and this hook will automatically add “[#123]” onto that commit message.

When someone is looking at the code six months or two years from now, they will be able to look up that story and get context about why the message was changed beyond what was in the commit log.

We were cleaning up old releases in Trello and had moved all the released stories to another board. However, I noticed that the cards were renumbered when they were moved to that board. Whoops! That meant that the commit messages wouldn’t be useful in looking up the cards. I had discussions with the product manager and we decided to keep all future releases on the same board to maintain the numbers–we’d just archive them (it’s worth noting that when you search for 123 and the card is archived, the search won’t return the card unless you add the is:archived search operator to your query).

However, I was ready to write off the cards that had been moved to the other board. What were the chances that if I moved the cards back to the original board, the card numbers would be maintained? I gave it a try just to see.

Trello did the right thing! The cards, when moved back to the original board, assumed their original numeric ID.

I am very impressed, as I imagine there are a very small portion of Trello users who care about this behavior. As someone who doesn’t really care about design but does care about user experience, that is an example of attention to detail that I wanted to call out and praise.


Own your online identity

This post from Fred Wilson echoes a lot of my thoughts. Whether you are posting to twitter, instagram, facebook, Medium, HuffPost, or anything else, it’s always worth remembering that you are leveraging someone else’s platform. That means you are renting it, not owning it. So, you are at the mercy of the platform. Whether in terms of content lifespan, deep linking or even just how your content is presented, you only have as much control as they allow.

That doesn’t mean there isn’t value in these platforms. There is tremendous value because they aggregate eyeballs, have excellent user interfaces and often host your content for free. Just be aware of the price you are paying (TANSTAAFL).

And always maintain a presence that you own if you care about your content. Repost all your content on your own site, so that even if the third party site goes away, you still have your work.  (If that’s not possible, print a PDF and save it in Google Drive, at a minimum.)

It’s not hard to buy a domain and set up a free google site (I wrote up instructions). You can use WordPress.com with your own domain for only a few dollars a month. Even if it isn’t as trafficked or as beautiful as a Facebook note, you control it. Once you’ve seen a few platforms rise and fall and/or change their business plan, you’ll be happy you used them for their leverage, but maintained as much control of your content as you could.





© Moore Consulting, 2003-2017 +