I think if there was a rigid spec, it would work against one of the points made early on in this doc (which I think is worth taking note of):
> Rule #1 is: Write them in whatever form makes the most sense for the particular project.
This is an unsatisfying rule, but I think it's important because each team/problem space/etc. is different and too strict of rules can often lead to documents that may end up being shallow.
However this admittedly doesn't help with this other problem you brought up:
> Also, when design changes - these docs need to be updated.
... but that may be okay given a shared understanding of what the goal of said document is. If the goal is to gain consensus around an implementation (as opposed to it being a living document), the document may have served its purpose by the time that consensus is reached, even if later on the design changes. If the goal is to have living documentation of a system, then maybe the rough format specified in this article isn't correct.
One term I've heard for design documents is that they end up being a piece in a "Decision Log", which has helped me feel less bad if the document falls out of date. These documents end up being more point-in-time representations of the collective understanding/opinions of how a specific project/system was being thought of, and that has its own advantages even if it falls out of sync.
Despite there being a whole bunch of implementations out there, I had also written one a while ago: https://github.com/thebrokencube/yahnes . It does need some updating, but seems to work well enough for my use (plus, I just wanted to scratch my own itch).
Probably best to sort of consolidate some of these into a few really good ones, but we'll see.
That's definitely a legitimate model. At least my experience with Lyft was that you could either tip or review, and I don't remember seeing an option to set a tip percentage. Definitely agree that tipping is awkward though, I kind of wish so many people didn't need to rely on them to make livable wages.
> “But this is an elective service and our culture is taught to tip for elective services. And yet HQ doesn’t want to offend or dissuade customers by making the ability to tip more prominently featured for fear they may end up going to Uber. And so no drivers get tipped even when a passenger would like to give one. Maybe that’s more likely what’s bringing down morale.”
I never used Lyft or Uber until last week, and this was the most surprising part. I was trying to figure out how to tip the driver, and tbh I don't think I was able to figure it out. I ended up tipping them after the fact through the emails they send you, but it was very surprising as to how ambiguous that part of the user experience is.
With Lyft and Uber starting to take off a bit in my city, I was going to recommend it to some friends to make some extra cash. I don't think I'll continue to give this recommendation anymore though, if tipping is discouraged/hidden.
My suspicion is that the author was trying to distinguish total order of events vs. partial order of events. I feel like the reason vector clocks and the like were created was to deal with the fact that real-time is problematic in distributed system. There is some response from the author though on this question: http://www.bailis.org/blog/linearizability-versus-serializab...
I tend to agree with you. I find that certain people I know who are extroverts always seem happy, but you spend enough time with them and get to know them, it's more or less a facade and they're not any more or less happy than others. Just like anything else I don't believe this to be universal, but it may be more common than advertised.
Quality control, and speed. This may not be as big of a problem as it used to be a few years ago, but private trackers give you quite a bit more assurance that what you're downloading is what is advertised. Also, since to be part of a private tracker you have to maintain the ratio, many users set up seedboxes and just leave their torrents on, while this doesn't seem to happen quite as much on public trackers.
Normally if you follow a low-carb diet, you get your fiber from greens. I believe the statement was targeted more towards carbs like bread, pasta, rice, etc.
Why not just for amusement? Or to just see what interesting things people have come up with? Why does everything have to be "only towards this goal", what happened to just doing things just for curiosity's sake?
Do you have any suggestions on creating these contracts? Mainly, is it necessary to lawyer up before even starting to make sure your contract is bullet proof?
I actually wasn't aware of that, but it makes a lot of sense and aligns with my experiences with depression/suicide a lot. The times I've felt suicidal were all when I was picking myself up and put myself out there and it crashed and burned horribly (in my mind at least; in reality it was just a small setback). Now that you mention it, my worst was actually when I just didn't care about anything, and when I had suicidal tendencies I was trying to get better and had just hit some small speed bumps that I felt were insurmountable in the heat of the moment.
> Imagine that the only reason that you didn't kill yourself in order to end this interminable torment is because you figured you'd fuck even that up and just end up a quadriplegic, and then be truly screwed, since you'd never be able to end your eternal misery then.
Oh man. This struck way too close to home, as it is was the biggest reason I didn't actually go through with suicide when I was at the darkest point in life. That feeling that you can't do anything right, even ending your already frail and delicate life: I don't know of many things more disheartening than that.
Your description of how it feels to be suicidal is very well written and probably the most accurate summary I have read in this regards.
There's a meme with a character called "Dolan" (http://knowyourmeme.com/memes/dolan) which is pretty popular for reasons that probably no one can explain.
I can't agree more. I came in thinking it was going to be fairly easy to pick up, but it seems like I spend most of my time just looking up how to do things "the Rails way" (not that that's a bad thing persay, but you definitely feel like you're doing nothing sometimes).
Anyways, I found Agile Web Development with Rails (4th Edition):
to be fairly useful if you don't mind buying a book. Plus, the ebook gets updated fairly frequently with erratas and stuff, as per usual with the PragProg team.
Yea I mean, I feel like when people say "google it", they're conveying that you should search the internet/research about it, not necessarily use Google for it.
I'm sorry if this is a stupid question... but what's wrong with "googling it"? I can see the flipside to most of the points made, but I don't understand this one.
> Rule #1 is: Write them in whatever form makes the most sense for the particular project.
This is an unsatisfying rule, but I think it's important because each team/problem space/etc. is different and too strict of rules can often lead to documents that may end up being shallow.
However this admittedly doesn't help with this other problem you brought up:
> Also, when design changes - these docs need to be updated.
... but that may be okay given a shared understanding of what the goal of said document is. If the goal is to gain consensus around an implementation (as opposed to it being a living document), the document may have served its purpose by the time that consensus is reached, even if later on the design changes. If the goal is to have living documentation of a system, then maybe the rough format specified in this article isn't correct.
One term I've heard for design documents is that they end up being a piece in a "Decision Log", which has helped me feel less bad if the document falls out of date. These documents end up being more point-in-time representations of the collective understanding/opinions of how a specific project/system was being thought of, and that has its own advantages even if it falls out of sync.