DaedTech

Stories about Software

By

Getting a Card’s Info From Trello

One of my absolute favorite all time tools is Trello, which is essentially a web application that digitizes the kanban board.  As a Trello user, you have one or more boards, and each board can have one or more columns.  In each column, there are cards.  And, like a live kanban board, you can move the cards around between columns.

Trello is good enough to expose a RESTful API so that I can interact easily with it.  I’m not going to go into a lot of detail on the particulars of the REST style of architecture here, as that’s not my main purpose.  But I will offer the useful way of thinking about REST that it’s an idea of pairing identified resources with actions — specifically, HTTP actions.  Or, more simply, it’s the idea of pairing nouns and verbs.  And so, figuring out who the members of the Beatles were might involve making a GET request to http://somesite/music/beatles while adding myself to the Beatles might mean issuing a PUT request to http://somesite/music/beatles with a JSON payload containing my name.  Pretty awesome, huh?  I’ve always wanted to be a Beatle.

Alright, so let’s use this REST API from Trello to get a card out.  Trello offers a “getting started” tutorial, and that got the job done for me, but I think it could be explained more simply.  They’re aiming to get you started writing applications that interoperate in rich ways with their web application, but I’m just interested, for now, in getting back “toothbrush.”

To understand what I mean, take a look at the screenshot below from one of my Trello boards, “Packing.”  I use this board when preparing for trips.  I populate the “pack” column with stuff to put in my suitcase, “non-suitcase” with stuff like my laptop and Kindle, and “To Do” with things like “set the thermostat” or “water the plants.”  What I want to do here is thus dead simple.  I want to get ahold of that toothbrush card via their API.  That’s it.

image01

To do this, you need to be logged in to Trello and, obviously, you’re not going to have my toothbrush card, but you can create your own board and card to follow along.  Do that now, if you like.

Once you’ve identified a card for which to do this, you’re going to need three things: the id of the card, an “application key,” and a “token.”  What you’re not going to need is to open Visual Studio or any other IDE, nor will you need to figure out some kind of REST client to build your request.  You’ll do just fine with your browser, as-is.  We’ll get to the REST clients and IDEs in future posts.

What was initially confusing when you’re reading their “getting started” page is why you need a key and a token.  Well, the key is for you as a Trello developer, whereas the token is your way of authorizing calls to your non-public boards (and most boards aren’t public).  To make it easier to understand, I could use my developer key to query Trello’s public development board and I could also use it to access Ringo Starr’s private boards if Ringo Starr issued me a token allowing this.  So when it comes to querying my own board, I need a developer key, and I also need to grant myself permission with a token.

Make sense?  Good.

Now, to get down to business.  Navigate to the trello app-key page while logged in and you’ll be granted your key at the top.  That’s the easy part.  To grant yourself a token, you’re going to need to work.  Scroll down to the bottom and click on the link that says “Click here to request a token to be used in the example.”

image00

Once you click that, you’ll get a pop-up requesting permission to grant the application access to use your account.  Hopefully this drives home the idea of a token.  In general, if you want anything to be able to interact with your Trello account, you have to give it permission via this token.  Once you’ve done that for your own account, it’s time to rock and roll.  Now all you need is the ID of the card that you’ve created, which you can get just by clicking on the card through the application, like so.

image02

With that id in hand, type the following into your URL bar making appropriate substitutions for the placeholders that are colored orange:

https://api.trello.com/1/cards/cardId/?key=YourKeyId&token=YourTokenId

You should see a bunch of JSON in your browser, outlining the attributes of this card.

image03

And that’s it.  Without code, IDE or tools beyond the browser, you’ve successfully used Trello’s API.  

This was a post that I originally wrote for Infragistics, and you can find it here.  Check out their site for the rest of the posts in this series, where I actually go through building a page using IgniteUI and the Trello API to build a little, client side utility that shows you cards and their due dates.

By

Don’t Learn to Code — Learn to Automate

Does anyone remember a few years ago, when the mayor of New York decided to learn to program? It was a heady time, because it wasn’t just him. I remember these surreal commercials where Miami Heat forward Chris Bosh was encouraging children to learn to code for the good of humanity or something. There was this sudden, overwhelming sentiment that humanity should abandon the folly of any non-programming pursuit and learn them some Ruby or whatever. Andy Warhol, were he alive in 2012, no doubt would have said, “in the future, everyone will write code for 15 minutes.”

Jeff Atwood wrote an interesting rebuttal to this zeitgeist, entitled, “Please Don’t Learn to Code.” The covers a good bit of ground and makes some interesting points, but the overarching thesis seems to be, “avoid thinking of writing code as the goal and learn to solve problems.” I think this is an excellent, philosophical point, but I’d like to add a bit of nuance.

I’ve written in the past about how important I think that it is to be a problem solver, to the point where I wrote a post about liking the title “problem solver.” So please don’t think I disagree with his take that a lot of programmers get too hung up with the particulars of code. I don’t — I think that’s a very common issue. But, at the same time, I think the mayor of New York and Chris Bosh and others have a point that Jeff doesn’t really address, per se. Specifically, the world is getting dramatically more technical, which means that a lot of pursuits are being automated out of existence, while other pursuits require an increasing degree of technical savvy. My fiancee, a professional copy editor, is finding aspects of her job to be easier if she knows a bit of HTML and CSS.

So while I wince alongside Jeff at the thought of people randomly learning programming languages because they think it’ll make them rich or because they want to be a person that writes lots of code, I don’t think we can simply say, “stay out unless you’re serious and willing to spend years getting good.” The rapidly evolving technical landscape has created this black hole of technical savvy that’s sucking in even people well past the event horizon.

The advice that I’d offer on this subject creates a pretty fine distinction. I don’t think that everyone needs to learn to code by any stretch. What I think that everyone needs to start learning about and understanding is how to automate. Or, if not how to do it themselves, at least how to recognize things that could be automated and have meaningful discussions about whether the effort is worth it or not. Read More

By

Improving Your Craft with Static Analysis

These days, I make part of my living doing what’s called “software craftsmanship coaching.”  Loosely described, this means that I spend time with teams, helping them develop and sustain ways to write cleaner code.  It involves introduction to things like the SOLID Principles, design patterns, DRY code, pair programming, and, of course, automated testing and test driven development (TDD).  I’ve spent a lot of time contemplating these subjects and their economic value to organizations, even up to the point of creating a course for Pluralsight.com about this very thing.  And through this contemplation, I’ve come to realize that TDD is an extraordinarily nuanced practice, both in terms of advantages offered and challenges presented.

This post is not about TDD, so what I’d like to do is zoom in on one particular benefit offered by the practice.  It’s a benefit that tends to be overlooked beside the regression suite that it generates and the loosely coupled design that it encourages.  But one of the important things that TDD does is to provide a very tight, automated feedback loop.  Consider what generally happens if you’re working on a web application and you want to evaluate the effects of your most recent changes to the code base.  You build the code and then run it, and running it is generally accomplished by deploying it to some local version of a web server and then starting the web server.  Once the web server and your web application are running, you then engage the GUI and navigate to wherever it is that will trigger your code to be run.  Only at this point do you get feedback about what you’ve done.  TDD short-circuits this process by requiring only build and execution of a test suite.

Of course, TDD isn’t the only way to create a tight feedback loop, but it is a well recognized one.  And it’s also one that tends to spoil you.  After becoming used to TDD, it’s hard to go back to waiting for long cycle times between writing code and seeing the results.  In fact, it tends to go the other way and you find yourself chasing other means of obtaining fast, automated feedback.  It was this exact dynamic that got me hooked on the idea of static code analysis.  If I could get quick feedback from unit tests about whether my code worked, why couldn’t I get feedback about whether it was well written?
ReducedDebuggingTime

Read More

By

A Rider to the Law of Demeter

In case you were wondering who is responsible for the bounty provided by harvests each year, the answer is the goddess Demeter. In the age of global transport, harvests have stabilized somewhat, but that wasn’t always the case. There was a time when Hades, the God of the Underworld, captured Demeter’s daughter, Persephone, and held her prisoner. A desperate Demeter responded to this calamity as any parent would, by quitting her job and committing herself to a rescue effort. Trouble for the world was that Demeter being absent at her post led to widespread famine, prompting Zeus to intervene and some sort of compromise to be reached. And so, it stands to reason that a principle of software development discouraging the use of statements like Hotel.Rooms[123].Bathroom.Sink was named for her.

Demeter
Read More

By

What Is a Best Practice in Software Development?

(Editorial Note: Hello, Code Project, folks and thanks for stopping by! I’m really excited about the buzz around this post, but an unintended consequence of the sudden popularity is that so many people have signed up that I’ve run out of Pluralsight trial cards. Please still feel free to sign up for the mailing list, but understand that it may be a week or so before I can get you a signup code for the 30 day trial. I will definitely send it out to you, though, when I get more. If you’d like to sign up for a 10 day trial, here is a link to the signup that’s also under my courses on the right.)

A while ago, I released a course on Pluralsight entitled, “Making the Business Case for Best Practices.”  (If you want to check it out, but don’t have a Pluralsight account, sign up for my mailing list in the side bar to the right and I’ll send you a free 30 day subscription).  There was an element of tongue-in-cheek to the title, which might not necessarily have been the best idea in a medium where my profitability is tied to maximizing the attractiveness of the title.  But, life is more fun if you’re smiling.

Anyway, the reason it was a bit tongue in cheek is that I find the term “best practice” to be spurious in many contexts.  At best, it’s vague, subjective, and highly context dependent.  The aim of the course was, essentially, to say, “hey, if you think that your team should be adopting practice X, you’d better figure out how to make a dollars and cents case for it to management — ‘best’ practices are the ones that are profitable.”  So, I thought I’d offer up a transcript from the introductory module of the course, in which I go into more detail about this term.  The first module, in fact, is called “What is a ‘Best Practice’ Anyway?”

Best Practice: The Ideal, Real and Cynical

The first definition that I’ll offer for “best practice” is what one might describe as the “official” version, but I’ll refer to it as the “ideal version.”  Wikipedia defines it as, “method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.”  In other words, a “best practice” is a practice that has been somehow empirically proven to be the best.  As an example, if there were three possible ways to prepare chicken: serve it raw, serve it rare, and serve it fully cooked, fully cooked would emerge as a best practice as measured by the number of incidents of death and illness.  The reason that I call this definition “ideal” is that it implies that there is clearly a single best way to do something, and real life is rarely that neat.  Take the chicken example.  Cooked is better than undercooked, but there is no shortage of ways to fully cook a chicken – you can grill it, broil it, bake it, fry it, etc.  Is one of these somehow empirically “best” or does it become a matter of preference and opinion?

Barbecue

Read More