RSS

Tag Archives: Documentation

Web API Design Part Ten: Management

20 Dec

Episode 96

It’s been a while, but I’m back with the next installment of API design series. Today we will step away a bit from technicalities and jump into the business perspective. After all, API is a product and needs to be treated as such. As we discussed one year ago in the first chapter of our journey, API is for developers as a graphical user interface is to regular software users. It’s a gateway to business value. And there are quite a lot of issues going around the product to think about and to be aware of.

digital-arts1.png

Image by Cosmic Net Studios

API management is a process of creating, publishing, enforcing usage policies, taking care of subscribers, analyzing the traffic and monetizing our product. API is as successful as developers who build upon it. Much of API management effort is directed towards empowering developers that use the API and simplify their work as much as possible. Some aspects of API management are more technical than others and with the rise of API management platforms this tendency increases, as more features are delegated to the platform. We will focus on Read the rest of this entry »

 
1 Comment

Posted by on December 20, 2018 in API, Technology

 

Tags: , ,

Good commit message

22 Sep

Episode 36

Last time we talked about version control, so let’s elaborate a bit on that. One of the aspects of using version control is the possibility of commenting on changes you do in the code. Actually, it shouldn’t be only the possibility, it should be a necessity.

The Template

Git documentation provides a standard template and guidelines for commit message, let’s have a look.

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72 characters or so.  In some contexts, the first line is treated as the subject of an email and the rest of the text as the body.  The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run thetwo together.

Write your commit message in the imperative: “Fix bug” and not “Fixed bug” or “Fixes bug.”  This convention matches up with commit messages generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

– Bullet points are okay, too

– Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here

The News

The most important question to be answered by the commit message, is Read the rest of this entry »

 
1 Comment

Posted by on September 22, 2016 in Misc, Technology

 

Tags: , , ,