Pretty darn useful collection of best practices, do’s and don’ts for REST API design
I have to admit I only had the faintest idea about extreme programming until I read and understood this well written and terse summary: A Case Against Extreme Programming. One page, all you need to know.
Great stuff by RyanTheComputerGuy: “If Satan was a web developer” and he had a go at forms, the result might look DEVilish like this:
Working in an agile context can feel “babylonian” at times. With everybody using the same terms, implying different things. So these charts might come in handy some time: Scrum VS Kanban VS Lean VS Extreme.
A true trove of inspiration, open anywhere and find inspiration for everyday management work.
Fascinating write up how the Gitlab team avoided a major outage. Featuring expired certificates, high level tools falling short and some good old server admin skills. Loving the depth and detail!
Sweet walkthrough of database models and their evolution: From flat-file, hierarchical, network, relational, noSQL, document, graph, column family to time series and back to NewSQL again: Prisma.io comparing database types.
Good UI is hard. Great UI is harder. UI that does not suck is following these basic rules.
Despite connections getting faster and faster and devices getting stronger and stronger, it appears the web is becoming slower and slower. As sites, apps, media and ads (especially ads) grow ever more ambitious, ever more featureful and sluggishly optimized, browsing turns to an exercise similar to commuting in the midst of rush hour stop-and-go, with every click bringing the browser to a gruding halt. Jake Archibald found a nice angle on the irony behind this, by measuring and analyzing page speeds of Formula 1 racing teams websites.
Equal parts auto-biography and corporate manifesto this book provides an interesting glimpse at what made the worlds hippest company with an ecological conciousness.
Amazingly detailled look behind the scences of a simple web request: How the web works. Great intro for total beginners and great refresher for those in the know.
Video game history in the making John Carmack on the challenges, tradeoffs and solutions incorporated in Quske Worlds network code
Do you need this to: a) Scale, b) deploy, c) rapidly evolve or d) fail independently? Do you need to use e) non-standard technology? Or should this serve as f) façade? Then a microservice might be tge right pattern, else, maybe a monolith would serve you better. Should that be a microservice? great checklist and insights over @ Pivotal
Communication is hard, technical communication is harder, technical communication under pressure is hardest, with these little “communication (design) patterns” it gets a bit easier.
There is clickbait and 10-books-about-bla-you-must-read and then there is this awesome collection of cheatsheets, one-liners and tools.
Superstar biographies, genius interviews and parental anecdotes, might lead us to believe that success or failure in life depend only on us making the perfect choice at the perfect moment. Fortunately they are all wrong.
Total efficiency constrains us. We become super invested in maintaining the status quo because that is where we excel. Innovation is a threat. Change is terrifying. Being perfect at something is dangerous if it’s the only thing you can do.
How an over emphasis on efficiency leads to fragility: Getting ahead while being inefficient.
Some interesting thoughts on early vs late stage projects and pre-mature optimization vs technical debt.
Great primer on microservice architecture basics by Sumit Maingi. Basic problems you’ll encounter and common solutions. Getting these right will already take you a long way.