891 karma · joined May 29, 2018
>>> They ... required no particular expertise to shoot or physical strength to carry. They were also deadlier than the rifles that had come before them, which used relatively large bullets that made a straight passage through the body on impact.
...this article is a cheap hit piece.
Harold Godwinson was a saxon. He's talking about Harald Hadrada, a viking who invaded the North of England just before William The Bastard invaded from the South.
Are tickets taking longer than estimated, or are estimates higher than before?
Do you estimate as a team? You should be part of the estimation process.
If estimation is normal, the you should be finding out the first day that a given ticket is not on track. Get devs to make daily commitments and pay attention to when they are not met. What went wrong?
If you wait until the end of the estimated time and then ask why its not done, you will never get accurate answers. You have to track it more frequently than that.
I don't know. I'm definitely not blaming the film or its maker. But I can't deny that is does kind of awaken a fantasy in me. I have never been involved in any military, but a part of me has always wanted to be transformed like the men in that film.
The thing is, when I imagine being in the story, I don't see myself like Private Pyle or Cowboy. Their stories don't discourage me. So I do wonder if Kubrick missed the mark by making a film that horrified him but actually inspires others. Maybe there's just something wrong with me. Even Platoon has an allure to it. Even Barnes was a hero in some ways. I could be like Barnes without the evil parts.
Apocalypse Now on the other hand, now there's a movie to kill recruitment if ever there was one. There's literally no upside in that movie and very few characters have any redeeming qualities.
My first dev job was over 15 years in bare-metal hosting (RHEL) and this was one of my biggest weaknesses too. I didn't get penalized too badly for it in the end. I even got an interview with a company that specialized in some kind of Kubernetes based product. I didn't get an offer from them but I did get an offer soon after that from a 100% AWS-hosted product company. It probably helped that I had so many years of development experience and had learned the basics of docker and containerization tech generally, so I understood what it can do for you and I was able to talk about that stuff intelligently. I had run into all the usual pitfalls in bare metal devops over the years so I was looking forward to moving to docker/cloud based stuff.
Over a year later I'm still a bit more rusty than most of my coworkers on AWS stuff. But you can pick it up. If you teach yourself how to use containerization (e.g. docker) and get a feel for what the advantages are, what problems it solves, to the point where you can talk convincingly about how you're exited to get a chance to use it, I think you'll come across ok.
Well yeah you could take it to mean that, but in plenty of other places they tell you to draw circles around things, so they must have meant something else here.
> Words sure do have an internal order. e.g. "eesph" is sheep with a jumbled order.
That's the order of the letters
> Draw a line through the two letters that come last in the alphabet
Only one letter can come last in the alphabet.
OK maybe gibberish was harsh lol but they definitely cannot be answered correctly.
>>> Draw a line around..
Lines don't go around things
>>> Draw 3 circles, one inside the other
That only accounts for 2 of them
>>> Print the word vote upside down but in the correct order
One word can't have an order
>>> Draw a line through the two letters that come last in the alphabet
???
It goes on like this.
I think they would also have to show that either the defendant knew that it wasn't true, or was reckless about it. They also have to show that it was likely to be believed as a factual claim, so expressions of opinion or hyperbole are not defamatory. This isn't legal advice, just what I think from years of reading Popehat.
IANAL, but legally that's easy: no. Under US law truth is a solid defence against accusations of defamation. If the statements are true then your intentions don't matter.
I gather from the tone and from the fact that this is even being asked that these people are US-born, or at the very least have had some easy path to permanent residency.
The linked article clearly explains that this is aimed at H1-B workers in the US, and it goes into plenty of detail about what Canada is offering them that the US isn't.
One time I was in a Walmart Supercenter (or whatever it is they call the huge ones) in Michigan. I had been there a few times but I couldn't find the fruit & veg section any more, they seemed to have moved it and put Halloween candy in it's place. After burning 10-15 minutes searching the whole store, I gave up and asked a staff member where they put it. "Oh we got rid of that sorry". It's literally the biggest supermarket in the city and you can't buy an apple or a banana.
There was a fancier place I used to go to in that city, Fresh-something-or-other. The kind that models themselves after Whole Foods. Everything time I went there, they only ever had green bananas. I mean, totally inedible, days away from being ripe. Every time.
It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.
If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details.
If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of GraphQL.
The reason people don't realize this is because sadly most people's idea of a REST API is already just a plain 1-1 mapping from DB tables to JSON objects served over HTTP. If you're doing that, you're already coupling any front ends or other consumers to your data model, so what do you have to lose with GraphQL (other than the complexity of deploying it)?
When REST was coined the goal was to hide as much data model stuff as possible. This is really really important if your backend app needs a high degree of interoperability across organizational boundaries, because data migration is hard! But if your API is consumed only by a small number of components that your organization has total control over, you might not care that much.
Years ago I used to see people implementing crude remote procedure call patterns over HTTP because they thought that's what REST was, and had been told it was better because of reasons. But this wasn't a better way of doing remote procedure calls. It was a much worse way! Now I see people using frameworks that just expose all their DB models as HTTP endpoints because they think that's what REST is and have been told it's better. That isn't really what REST is, and GraphQL might be a better way of doing that if that's what you need.
REST is a bunch of constraints that make interoperability and scalability easy to achieve. Maybe you benefit from those constraints and maybe you don't. But that's what you need to think about before you think about GraphQL.
Personally though I see the opportunity to do the work and define your own career within the company as the biggest opportunity here. If you like what they're doing, figure out what you want in terms of role and responsibility and ask for it. Tell them you want to be the chief of this or the director of that - not just the title but the responsibility too. If they say no, do the work anyway. When they see your level of ability and commitment they'll probably start to worry that you'll seek the role you want elsewhere, and so they'll give it to you.
As far as publishing a spec, I don't know but I'm guessing part of it is a reluctance to commit to anything (which does kind of defeat the purpose of a public API).
Like, for example, only one external interrupt and one timer, which was 8-bit.
I did some reverse engineering on an 80s Porsche engine management computer[1] that used the 8048. The engineers had to get really clever to work with these 2 issues. They used the reset pin as a second pseudo ext interrupt, which works ok but has a few side effects you have to deal with.
The lack of a 16 bit timer was single-handedly responsible for adding massive complexity all over the code. Basically the loops had to be capable of scaling themselves for engine speeds below a certain threshold because otherwise the timer would overflow!
You have to wonder if it was worth what they saved vs just using an 8051, especially considering that this car had 2 engine management computers, and the main one used an 8051!