If you are playing around with the artificial intelligence and machine learning, have a look at this list of “Top 20 APIs You Should Know In AI and Machine Learning“. These are nicely organized by subject as well:
I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.
It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.
Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.
Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.
Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).
Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.
Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.
When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.
- Read and write support for MongoDB
- Read support for Elasticsearch
- Message queues support via a number of brokers, including Amazon SQS
- Server Push support for HTTP/2
- Full compatibility with OpenAPI v3 (Swagger)
- Automated admin interface and project documentation
- A variety of components from the Symfony framework
I’m pretty sure that I’ll be taking this for a spin in the nearest future!
“Headless CMS: REST vs JSON:API vs GraphQL” is an interesting comparison of the REST, JSON:API, and GraphQL:
In this blog post, we will compare REST, JSON:API and GraphQL. First, we’ll look at an architectural, CMS-agnostic comparison, followed by evaluating some Drupal-specific implementation details.
The cool bit about their documentation is that it covers both how to avoid the issues and how to solve them if they happened.