Name: How is software engineering different from programming?
Rating: 3.7 (9575 reviews)
Author: mohanarpit

TL;DR notes from articles I read today.

“All software engineers can program, but not all programmers can engineer software.”

As a software engineer, you must understand the problem fully, the limitations of the solutions offered as well as the privacy and security implications.
Sometimes the solution is not writing code but combining existing programs, educating users, or preempting future problems.
Your code must be readable, easily extended, work well with other programs and maintainable, with clear error messages and error logging, backed by solid documentation for easy debugging.
Well-engineered programs will work in many different environments, differently-resourced devices and across time zones, even on limited memory and processing power, backed by a comprehensive test suite.
Find and use good tools to shorten feedback loops, for code static analysis, type safety, to deploy, debug and measure performance

Full post here, 11 mins read

Implementing HATEOAS (hypermedia as the engine of application state) using the available tooling is not easy for a majority of developers. And, for consumers, this may dilute the simplicity of the API. You might want to choose a pragmatic REST approach - adopting most of REST but not all or you might create a remote procedure call (RPC) API. Just call it like it is, rather than getting stuck on the REST claim.
Sometimes, you will need to make concessions based on organizational context rather than best practice, and sometimes there are excellent business and security reasons to heed internal resistance over the purity of design, which does not functionally achieve anything better anyway.
Avoid making a REST “entity” of your customers. It adds complexity and yet no extra value to the consumer, mixes up the data and the security models by requiring the user to identify themselves by URI. This, in turn, results in a brittle interface, and in a ‘fallacy of nested interfaces’ that even a developer finds hard to parse. Instead, model only what you need to model in your API, not other associated things.

Full post here, 8 mins read

Set up authentication to verify user access. You can use devise, which uses Bcrypt, to make it difficult for hackers to compute a password. It can also help recover passwords, register and track sign-ins, lock records, etc.
Use strong parameters to accept data being sent to you from a request, supplying whitelisted values to throw an error if incorrect data comes in.
Add slugs to URLs to identify records in an easy-to-read form without releasing the id of the record.
Protect sensitive data, especially logins and payment pages, by enforcing https through the config file and averting cross-site scripting (XSS) attacks.
Check for active record exceptions and create an exception concern to sit above the application controller to guard against specific exceptions.

Full post here, 3 mins read