hammerdr
Caviar is growing and we need excellent engineers to help bring great food everywhere. We are building a food ordering platform that enables the best restaurants to serve food through delivery and pickup, and that's just the beginning.
We have a number of roles that we think you'd be great for. We have need for engineers that are looking to make an impact on a fast growing product, to take ownership of existing and new products, to redefine Caviar architecture and execute on it, and to work with us to unlock that next step-function product or feature.
Caviar is hugely impactful to Square. Take a look at the 2017Q1 Shareholder Letter (https://s21.q4cdn.com/114365585/files/doc_financials/2017/Sq...) and see how much we are featured. We're growing fast and need you to help continue that growth.
# Before abolishing time zones
I want to call my Uncle Steve in Melbourne. What time is it there?
Google tells me it is currently 4:25am there.
It's probably best not to call right now.
# After abolishing time zones I want to call my Uncle Steve in Melbourne. What time is it there?
Google shows me a daylight map (First result https://www.timeanddate.com/worldclock/sunearth.html)
It's probably best not to call right now.
We are just used to the insanity that is timezones. Of course, I say this because I have to deal with time and timezones every day at work and bugs are always prevalent. Each DST switch there are new bugs we find; every time we change our core date and time code there are bugs. Just painful.In the end, we'd build new tools and intuitions around time. People would adapt and my life would be measurably better (though not completely solved; scheduling anything across a date boundary is odd. No one thinks of 1am as "tomorrow" but instead as "later tonight").
There have been some efforts to rectify that through quotas, though from anecdotes of colleagues it sounds like it hasn't really been solved (e.g. no proper support system leads to disproportionate dropout rates)
https://www.quora.com/Do-you-think-Scheduled-Castes-SC-Sched...
Can someone explain why there is an extra Ok(...) in this? (I want to call it a function, but I'm not even familiar enough with Rust to be sure that it is a function).
Is it something that could be removed? Right now it just looks like boilerplate.
Edit: Thanks everyone! Ok is similar to a Right or Success of a Either/Result type of object.
I also recognized that it has took me a lot of time and a lot of effort to get to a point where I recognize it. 10 years ago, many of the things that would set off the "Hey; that does seem right" alarm bell would be unconsciously ignored and taken at face value.
If I may presume, I'm going to suggest that your experience may be because you're more 'attuned' to racism than you are to sexism. For me, at least, it takes effort and willful learning to come to better grips with sexism, racism, ageism, etc. It's hard work!
But, saying that idempotency is hard and thus we should build features to get around it.. that seems wrong to me. The web is inherently a distributed system and you're going to have concurrent requests and weird edge cases that arise in those situations. The right way to handle that isn't to bandaid it with disabling client side behavior. That just hides to problem. Your server is the place to handle it.[1]
And, it really isn't that hard either. It's just a couple extra validations on your input before you do a write. There are places where it is more difficult but still not overly complicated to implement.
[1] Dogmatism alert. Of course, there are exceptions to everything that's a 'best practice'. Here, I'm just talking about disabling double-click as a general solution for the web to a concurrency problem.
Docker ecosystem: swarm and/or compose
Mesos ecosystem: Chronos, Aurora, Marathon
CoreOS ecosystem: fleet
Hashicorp: Terraform
Amazon Container Service: works with the above, will likely build their own simple one in the near future
This is less about embedding images and about managing/"scheduling" them
Edit: Zikes mentioned Kubernetes, as well.
You probably even "called your shot" and make guesses about what would be successful before you even approached the problem.
Then you wrote a test and saw whether your guess was right or not. If not, then you misunderstood something and you dug deeper.
Software, in some ways, in simulated science.
I think a possible difference is that asking someone to share their experience directly invokes some kind of entitlement on the part of the asker.
But, I don't think that there is anything wrong with amplifying the messages of those underrepresented [1]. Many people with true experience are talking, but have trouble getting that message heard.
[1] With their permission. Don't shuttle around someone's personal story without permission. It can be damaging in ways that you're not aware.
I was specifically speaking about people that pontificate about things they have no legitimate claim to have experienced. Being a Latin@ in the United States doesn't legitimize your claim to speak about rural peasants of Mexico (though, if your family has roots there you may have lingering first hand accounts that can color the discussion more than those without).
In fact, historians are one of the people I would consider a source, especially if their words are born from the interactions and studies done from interacting with real people. They make it their life's work to understanding the situation in which people live.
Also, everyone makes mistakes and/or embellishments. I make mistakes. People in their own experiences get caught up in those experiences instead of the truth. Historians get caught up in their own narrative of truthiness instead of truth. Skepticism and an open mind are great tools toward enlightenment.
So, yeah, sometimes white men can be more legitimate than others in their viewpoints. But far too often the voices of the privileged and uninformed drown out the voices of experience and truth. That's the tragedy.
"But what can I do as a white man/white women/generally privileged person?" - Amplify. Your voice unjustly carries more weight than that of other people. If you can be the "Retweeters" of Social Justice, you'll be doing a lot of good. Just be sure to retweet the people with firsthand knowledge.
Also, why do medical examiners often conflict when looking at the evidence? Is it open that much to interpretation? Are the primary medical examiners motivated in the wrong ways somehow? Or are the alternative opinions coming from quacks?
I realize you may not know all these answers, so I apologize for lobbing them all at you. It is hard to get genuinely balanced knowledge in these things and I want to be as informed as possible.
I have no idea if this is true, but it may be that a community of neighbors that knew Alex well would have been less likely to call the cops, to give the police more information about his mental state, etc. and that those measures would have saved his life.
"Class warfare" is an apt term. Wealth is only a part of it.. this is the Old San Francisco (Hippie/Transient/Outcast) class and the New San Francisco (Techie) class. I'm a part of the latter (and live on the edge of the Mission and Bernal Heights). I'm part of the problem. But, I think I can also be a part of the solution.
There was a group dedicated to solving these problems called EngageSF. They met and discussed at local mission restaurants. I can't seem to find any information on them now, though. http://missionlocal.org/2014/02/new-and-old-residents-engage...
They also approved of screenhero (I can guess why, but it would be a guess).
They have not approved of slack, hipchat, etc. for client-related communications because they are nervous about having that much liability not under our control. It also makes it difficult for our contracts team that would then be required to explain that client data could now be in either Google Apps or Slack.
I would say that these decisions are going to be SOP for a consultancy of a certain size.
I don't necessary agree with all of these decisions, but I understand and try to empathize with the other parties that would be inconvenienced.
Edit:
I think what happened is that screenhero got a verbal and passionate following within our consultancy that the decision to use screenhero was 'encouraged' into being adopted. We started using it under-the-radar when it was free and when it became paid, the organization realized how many people were using it successfully. It was a ground up effort.
It makes me sad that a tool we found so useful across our organization (which you can see above is incredibly fragmented) is being made inaccessible. I know you're trying to do right by your users and we're just a weird edge case, so no bad feelings. Just wish it were not so :(
Unfortunately, due to other concerns about paying for Slack[1], we probably will not be able to continue to use it. We'll be a once-happy customer that falls victim to this acquisition. It leaves a bad taste in my mouth :(
[1] It is expensive especially at our scale, we already pay for a couple chatroom-type/irc-like services, and the big one: long-lasting offsite chat logs present a difficult hurdle in client negotiations, a headache we just do not need
http://www.businessinsider.com/the-15-wealthiest-people-in-f...
(Note: everyone there is a white old dude, other than the two women, who inherited the money from white old dudes)
Additionally, I can think of countless examples of "slow starters" that didn't really get good at something until there was something that caught that person's interest.
At best, this is a flawed metric with many nuances to consider. So many that you could probably make the same determination by removing age from the application.*
* If you want to collect demographic data, you can just ask for it in the submission form but not show it in reviews.
That's a pretty good breakdown of the route. One of them completed pitch 15 yesterday and today were mapping out pitch 16 / continuing pitch 15. There's contention over whether 15 or 16 is more difficult :)
Pitch 16 is the dyno pitch (video of him dyno-ing: http://vimeo.com/80908548) though it sounds like they might be doing a workaround to not have to do the dyno (they think its hard to do consistently.. for obvious reasons).
http://instagram.com/p/xb6x5Oj5dz - a picture of how high and exposed they are on El Cap.
And, more information just if you're still wanting to listen to a climbing nerd.
Free climbing means that they climb without "aid" - e.g. nothing is pulling them up the wall but themselves. They still use ropes and other devices for protection.
Pitch is a "section" like the article says, but you have to climb between these sections before you get any rest. Otherwise, you have to stayed glued to the wall on your own power. Once you get there, you set up camp and wait for the other person to climb up to you. Up you go the next pitch, etc. etc.
Dyno is a move that requires a person to leave solid contact with the wall and move to another place. This is usually seen as a leap from one hand hold to the next hand hold.
Traverse is a lateral, not upward movement.
Yosemite is one of the world's premiere Big Wall locations. To do this in this place is iconic.
Climbing can be very much like (a very physical) puzzle game. Especially for long climbs. You need the right gear, the right moves, the right body position, etc. in order to keep going. It's both mentally and physically taxing.
New suggestion, though. You should spend your time in school learning how to remove your prejudice. It's pretty bad, and will hold you back more than not learning a particular language will.
P.S. Just to be clear, I was bothered by your ageism.
So with docker-machine binary on the path, "docker machine" would just delegate to that.
Similarly, if I had a docker-flynn binary, "docker flynn" would just magically work.
This means that the main binary is composable from multiple parts and its easy to write plugins for other systems.
It really isn't "significant" -- it's just stringing together docker containers and the Google Cloud as a demonstration of how quickly someone can deploy a Go service. It's like the old Rails scaffold.
Like Rails scaffold, this isn't enough on its own. There's many concerns for putting something on the open web and making it ready for production use. But what is really slick about this is that it shows how low the barrier of entry is to containerizing and deploying apps very, very quickly.
Google Cloud is just one example. dotCloud, tutum, orchardup, and others are out there. I'm sure a self-hosted, possibility open source, solution will be on the way a la openstack.
The benefit of containers over clouds are widely documented--but as a developer it means FAST phoenix servers that mean I can iterate on deployment orchestration, configuration management, etc.