Tag: web development

Programmer Playing Cards

I have recently blogged about the Faces of Open Source project. That’s a great initiative. But here’s another one, with a lot more practical approach – Programmer Playing Cards. It is a deck of playing cards, featuring people who influenced the world of computer programming in a variety of ways. Each card has a photo of a person, his or her name, what was the influence, and, as a nice touch, a quote from that person.

Here’s an example with Larry Wall.

More examples as well as instructions on how to get these cards are here.

Twas the Night Before Christmas — A Coder’s Dream

If you are involved with any kind of coding at all, I’m sure you’ll enjoy this remake of the “A Visit from St. Nicholas” poem.

He opened my laptop, and first installed Node
Who knew that old Santa had learned how to code,
His fingers were flying, his typing was quick,
How will I ever, repay ol’ St. Nick

ISO-8601, YYYY, yyyy, and why your year may be wrong

Erica Sadun blog post goes into details of the difference between ‘YYYY’ and ‘yyyy’ when formatting dates. Remember to add a few unit tests to your application to make sure you are using the correct format.

We’ve recently seen this issue at work and it was a pain in the butt to troubleshoot.

Picking the right API Paradigm

There are not many people who I trust on the subject of API design like I do Phil Sturgeon. He has been a prominent speaker both online and at numerous conferences, covering a variety of problems, solutions, and approaches in the API design domain.

In one of his recent blog posts, he shared a diagram (see above) which provides a clear illustration on which API paradigm – REST, GraphQL, or RPC – one should pick for a web application, based on a variety of criteria.

I think this is probably the simplest of all the explanations I’ve seen around.

A Serverless Sequence Diagram

Paul Hammant has a quick and simple blog post illustrating the request-response sequence in the web application on a serverless infrastructure.  I find it quite useful as a reference, when explaining serverless to people who are considering it for the first time.

This stuff and the abandonment of names:ports in the config is a key advance for our industry. It is like a limiting Unix problem has been overcome. While it is still is impossible for two processes on one server to listen on the same port (say port 443), it is now not important as we have a mechanism for efficiently stitching together components (functions) of an application together via the simplest thing – a name. A name that is totally open for my naming creativity (ports were restricted if they were numbered below 1024 and also tied to specific purposes) . We’re also relieved of the problem of having to think of processes now, and whether they’ve crashed and won’t be receiving requests any more. Here’s a really great, but rambling, rant on a bunch of related topics by Smash Company that you should read too as it touches on some of the same things but goes much broader.