31
down vote
accepted

Both forms are valid. However, for an API, I would recommend the second form. The reason is that it gives you a path for expansion of your API.

For example, if you have an API getUsersInGroup which returns an array of user objects, and later you decide you want to include, say, some aggregate statistics about the users being returned, there's no easy way to do that without breaking existing clients (or including lots of redundant data in each user object). If you use an object, you simply add another field to the object which is silently ignored by clients on a previous version of the API.

In short, try to avoid top-level primitives wherever possible in your API, and you'll find it easier to expand in the future.

interessant, ça a l'air sympa comme job!

TIL : strings command

Instead of using -f or --force developers should use

--force-with-lease

Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.

Good to know because it hurts me so bad:
When doing a put/post request with requests library, if the response is a redirect, request do the request again BUT with GET method...

-,-

My /var/lib/docker folder was non empty (12GB) event after big cleanup (containers, images, volumes..)

It's a known issue with some layers not removed when you do docker rm -f (force)

Solution : service docker stop; rm -rf /var/lib/docker/*; service docker start

:-/

The easiest way is to just convert the text file to utf-8 and pipe that to grep:

iconv -f utf-16 -t utf-8 file.txt | grep query

%{VARNAME}o The contents of VARNAME: header line(s) in the reply.
%{VARNAME}i The contents of VARNAME: header line(s) in the request sent to the server.