I've had successes and failures working four years remotely, so that's my disclaimer. But the key for me has been to have a dedicated space with a dedicated computer for work. If it's easy to work on the couch you'll do it, so try to never work outside your area (if you can). Only work in your work area.
Also, protect your personal time. Do simple things, like mark out your lunch time on your calendar and don't let meetings creep into it—you'll be surprised how much this can help. Stop work at a time like 5pm and propose alternate times when people schedule things after it. People are usually open to moving meetings and may have not considered your stop time. Time zones make this harder as it's hard to keep track of when lunch is for people. Meetings during personal times should be exceptions.
Try to keep work things off your phone, though that's easier said than done with things like Slack or email. They make it too easy to work without feeling like you're working. I'm failing here currently :)
These above are all things you can do as an individual. But I think the success will also depend on your team. If you are the only remote person, it will be harder than if everyone is distributed. You'll need to ask people to write more and act like everyone is remote because you'll miss out. I've found that if you're the only remote person, it helps if your team works from home a day or two a week so they have to work remotely.
To summarize, set clear boundaries and expectations with yourself and your team with how and when you work and try to move your team to be remote-first.
The difference is that I am not proposing a Turing complete config language, but rather proposing to build configurations with plain old JavaScript (or whatever language you want). I think a good read about this thinking is by Martin Fowler on Language Oriented Programming [0], specially the section about internal DSLs.
Another interesting read is around the configuration complexity clock [1], in that over time we move from hard coding things to building configurations to coming full circle and hard coding things again. I like to think internal DSLs closes that loop well.
I wrote a little library for building DSLs in JavaScript [0] because of this very issue—JSON is not good for this kind of stuff. I want to be able to create small DSLs to solve problems rather than squeezing the language into a JSON format. I want the full power of a language AND the ability to serialize the semantics to send over the wire. Maybe we'll move toward that one day.
I made my own little language called Geneva [0] for similar ideas but it acts as code and can be parsed as JSON. I also came up with a spec for doing this for HTML [1] (but no code to do this yet).
You might find it useful to spend some time looking into the hypermedia constraint of REST itself (i.e. hypermedia as the engine of application state). The point of REST is to represent state machines by including hypermedia links in the responses of the API. Those links describe the state transitions a client may invoke in a given state.
Instead then of mapping CRUD operations to HTTP, you would map your application semantics to HTTP methods via link relations. Link relations let you go as far past CRUD as you would like to go depending on your domain and allow you to describe your states and state machine.
I always think a good way to think about a hypermedia state machine is in the context of HTML. Consider a todo app example. You might enter the application and get an empty list of todo items. If you have permissions to add a todo, you might have a "create todo" HTML form. Once you use that form, that todo has a new form called "mark complete." Once invoked, that todo has new transitions called "mark incomplete" or "archive." Once archived, you might see a new form for "unarchive." All of this captures the state machine and transitions in the REST API itself using domain-specific semantics.
Of course, there are other ways of solving this problem, but REST with hypermedia is a great way to work with state machines. There are lots of hypermedia JSON formats out there if you're interested in exploring (e.g. HAL, Siren, Collection+JSON, etc.).
True. I would consider a continuous stream like that to not be helpful change management. But if you have to have continuous breaking changes like that, you would want clean cuts. My point is, find ways to evolve your API without breaking things.
I think you are right here. It takes two to tango, and if the clients are tightly coupled to the API, the best intentions for evolving slowly will fail. :)
That's true. However, I think this falls under YAGNI [0]. If you happen to get to a point where you have to change your an entire API rather than evolve what you have, you should consider it a new, separate API rather than instruct all client developers to plan for it up front. Plan for evolvability and handling changing requirements up front.
I personally like to think about managing change well rather than versioning an entire API. In this, API designers provide instructions on how APIs will evolve over time, how features will be deprecated, and how this process will be communicated to API consumers. Change management also includes recommendations for client developers on how to evolve along with the API and build clients that don't fail when something as small as a JSON property is absent or added. You don't necessarily need version numbers to do this.
An API version says to me that one day the entire API may introduce a major change that is separate from the current API. If you plan to never introduce a major change like this, you may not need a "/v1" in the URL.
Kudos to the author for putting together a nice article :)
Just to note, I'm seven days post-op on this procedure :) And while I did not take any meds, I was happy to be sitting in bed with an ice pack watching March Madness. So there was definitely discomfort.
Just to add, I don't want my comments to scare any males considering the option. If you are at the time in life to stop having children, and you have no condition preventing the procedure, it's really the best option and will more than likely not have any issues. It sometimes doesn't even require pain medication.
Just to note, vasectomies are no walk in the park, and should be treated as final rather than a simple contraception option (though they can be reversed, just not easily).
While you can go back to day-to-date activities after a few days, there is still extra time to heal fully. Pain can hang around for a long time in some cases—even years. Infection is also a big concern, so take it should be taken very seriously.
With all of that said, a vasectomy is a much better and simpler option than female sterilization for a majority of people and has a high success rate.
Total guess, but they may mean request bodies instead of response since GET and DELETE normally don't have request bodies.
However, I'm not sure there is a definitive answer on if that's true from an HTTP perspective. I also couldn't find it in a skimming of the OpenAPI 3.0 spec.
In the end, REST [1] itself does not prescribe either condition and the HTTP 1.1 [2] spec doesn't either.
> A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors.
In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting.
lodash.get(someObject, 'path.to.a.property')
If the path isn't there, the lodash.get returns undefined. This is much nicer than getting the error "Cannot read property 'to' of undefined" when "path" isn't there.
Also, protect your personal time. Do simple things, like mark out your lunch time on your calendar and don't let meetings creep into it—you'll be surprised how much this can help. Stop work at a time like 5pm and propose alternate times when people schedule things after it. People are usually open to moving meetings and may have not considered your stop time. Time zones make this harder as it's hard to keep track of when lunch is for people. Meetings during personal times should be exceptions.
Try to keep work things off your phone, though that's easier said than done with things like Slack or email. They make it too easy to work without feeling like you're working. I'm failing here currently :)
These above are all things you can do as an individual. But I think the success will also depend on your team. If you are the only remote person, it will be harder than if everyone is distributed. You'll need to ask people to write more and act like everyone is remote because you'll miss out. I've found that if you're the only remote person, it helps if your team works from home a day or two a week so they have to work remotely.
To summarize, set clear boundaries and expectations with yourself and your team with how and when you work and try to move your team to be remote-first.