|
Munkeymon posted:That reminds me of the time the WinSCP guy fixed a UI bug that I basically developed a workflow around using because I thought it was a feature, so I asked him to turn it into a UI option. Dunno if he ever did, though, since I haven't used it heavily since I got out of LAMP hell. https://xkcd.com/1172/
|
#
?
Jan 10, 2019 17:48
|
|
|
|
| # ? Jun 3, 2024 07:50 |
|
|
ChickenWing posted:Fifth Axiom of API development: all API behaviour, intentional or not, must be supported  E: Jesus loving Christ, has this window really been open 3 hours?
|
|
#
?
Jan 10, 2019 20:51
|
|
|
necrobobsledder posted:In theory, yes. In practice, I’ve normally observed that the team will upgrade at the slightest sign of a fix happening in an internal library while external updates languish for years. necrobobsledder posted:middle managers externalize the maintenance of the core library because they’re too busy shipping features All of this is completely different to $LAST_FRAMEWORK where our internal developers' community wasn't involved at all and it was basically one senior developer (possibly in an ivory tower) working on a framework filled with features that nobody wanted or cared about, and not built on top of an extensible base so it basically bitrotted away. For $FRAMEWORK we've invested from day 1 in having decent documentation that's always up-to-date, release notes that contain upgrade documentation for possibly breaking changes, providing at least biweekly releases (and often more) and organizing community meetings every couple of months, etc. It took a lot of time, but it's worth it imo.
|
|
#
?
Jan 10, 2019 21:31
|
|
|
Is it worthwhile to go to a talk by Uncle Bob?
|
|
#
?
Jan 10, 2019 22:00
|
|
|
[Hi there! I'm looking to hire some people, and I've been told that this is a good place to tell people that. Please accept my apologies and let me know if that's not the case!] Hello! I work at a well-funded, customer-having 50-person company that builds business tools with AI. We're hiring a lot of people over the next year, and I thought I'd spread the word here. The division I run is looking for: Software developers: systems/platform (logic around our AI core, data processing, etc.) , front-end (web interfaces), infrastructure (provisioning, monitoring, security, etc) Software managers: this shouldn't be your first management position. Can also hybridize with IC/coding work in the right circumstances. Product managers: market analysis, running scrums, designing and communicating product processes, coordination of roadmaps with client teams and sales UX designers and researchers: we are building interfaces for our tools, and researching how UX affects things like trust, and helps non-expert people understand biases, probabilistic outcomes, and other less-common aspects of our system Machine learning scientists (relevant masters strongly preferred, but I'd let you make a case if you got relevant experience through another path): research and productization of different AI techniques. We expect to publish ~5 papers this year from a team of 10 people. You should know the math but also how to code it up. Other than as indicated for the MLS position, I don't care if you have a degree or not, and I don't care if you know the technology we use (python, scala, JS, React, scikit, some Rust likely). We're hiring at various levels of seniority in the different positions. For intermediate and senior people we will relo, and we handle visas for anyone. We're located in Toronto. No remote work, sorry. I'm 25 years into my software career and have led products with literal billions of users. This is the most supportive and collaborative culture I've ever experienced, and I'm excited to bring more people into it and help them grow while they help us be more like the company we aspire to be. Hit me with a PM if you want to know more. e: machine learning, not language, oops Subjunctive fucked around with this message at 22:15 on Jan 10, 2019 |
|
#
?
Jan 10, 2019 22:05
|
|
|
The recruiter cold calls are coming from inside the thread 
|
|
#
?
Jan 10, 2019 23:14
|
|
|
Volmarias posted:The recruiter cold calls are coming from inside the thread I can vouch for Subjunctive being rad af and would be lovely to work for/with, so think of it as just goons helping goons out, as y'all have done for me 
|
|
#
?
Jan 10, 2019 23:19
|
|
|
At least I posted it myself my recruiter didn’t want to spend 
|
|
#
?
Jan 10, 2019 23:26
|
|
|
Carbon dioxide posted:Is it worthwhile to go to a talk by Uncle Bob? For the astronomy, sure. For the basic ideas if you're unfamiliar with clean coding principles, sure. To follow his extremely fanatical viewpoint? Please don't.
|
|
#
?
Jan 10, 2019 23:35
|
|
|
Jesus Christ, one of my QA's is thick. He changed some stored credentials, then invoked the service that the credentials are for, and sent out a screenshot of the 401 status code he's getting back, and asking "is this related to the credentials I changed?" Yes... that's how configuring credentials for a 3rd party API works.
|
|
#
?
Jan 10, 2019 23:35
|
|
|
Got a similar thing the other day from a partner. To be vague, their software calls our software's API, and they were seeing errors in let's call it Scenario 3. Scenario 3 was working before they versioned up their code, but neither side has great instrumentation so we hadn't pinned down what the root cause was, fine. Then they sent us an email to the effect of: "We tested Scenario 3 for a different customer and it worked. We were also using a slightly different version of our code. Could this be because you have different versions of your software for different customers?" Yeah you read that right, they changed something, got a different result, and their first thought was that OUR software was different.
|
|
#
?
Jan 11, 2019 00:35
|
|
|
Our biggest client is exactly like that. There are times where we are only deploying updated versions of their custom code to their environments. Then, their custom screens and poo poo don't work right anymore. They start blaming us for changing the software but in reality the only delta in that scenario was their own custom code. Thankfully we don't have a bend over backwards SLA with them so we can tell them its their code, their problem, and gently caress off.
|
|
#
?
Jan 11, 2019 17:14
|
|
|
Che Delilas posted:Yeah you read that right, they changed something, got a different result, and their first thought was that OUR software was different. What sucks is the first time you insist that it's their problem and it turns out that their stuff is fine, and there is a problem on your end, even though you didn't change anything and they did.
|
|
#
?
Jan 11, 2019 17:17
|
|
|
Our company has an API server that can receive status updates from a third party. We're seeing some status updates in the logs, but not all of them. They insist they are sending us all the status updates. What would be the best way to prove them wrong? It is a RESTful API with basic HTTP GET calls for the status updates.
|
|
#
?
Jan 11, 2019 17:54
|
|
|
Polio Vax Scene posted:Our company has an API server that can receive status updates from a third party. Ask for a list of their send GET calls and match it to your own log file. Presume everyone is acting in good faith until proven different. I think they are sending either to the wrong endpoint or counting all requests that do not time out, even if they result in something else than a 2xx response.
|
|
#
?
Jan 11, 2019 18:01
|
|
|
Polio Vax Scene posted:Our company has an API server that can receive status updates from a third party. Implement telemetry so all calls are logged automatically. Something like Application Insights in the Azure world. Also, status updates aren't what GET calls are used for. GET should, well, get things. PUT or PATCH would be more appropriate for status updates.
|
|
#
?
Jan 11, 2019 18:01
|
|
|
Maybe you can use the HTTP server logs. An nginx log for example will show you the originating IP address and the status code of the HTTP request. So you can filter it by your third party's IP address and marry the entry in the HTTP log with the status update in the other log, and if all of the HTTP status codes are good then you can show that every request that the HTTP server handled did in fact go to the API. But like the goon above me said, you'll probably want to add some telemetry poo poo to the API to guard against this client BS in the future.
|
|
#
?
Jan 11, 2019 18:02
|
|
|
My company is trying to hire a "Principal Engineer in Test" which is going to be impossible; nobody is going to want that role. The argument that the upper management folk tried to make was "Amazon and Google have them".....
|
|
#
?
Jan 11, 2019 18:10
|
|
|
Slimy Hog posted:My company is trying to hire a "Principal Engineer in Test" which is going to be impossible; nobody is going to want that role. The argument that the upper management folk tried to make was "Amazon and Google have them"..... Why would nobody want that role? There's plenty of value and people interested in orchestrating test automation and deployment verification.
|
|
#
?
Jan 11, 2019 19:01
|
|
|
The problem you’ll have is that the only people that can qualify for that role are all not wanting to work for your random-rear end company doing the work that a junior SDET should be doing. More or less why I keep quitting jobs where companies hire for a position having no idea what to do with the role because they’re just not in a position to actually use the skills the role would fulfill. No point in hiring an engineer that knows large scale infrastructure when your business doesn’t call for more than like 25 hosts serving a trickle of traffic, but boy is that common.
|
|
#
?
Jan 11, 2019 19:10
|
|
|
New Yorp New Yorp posted:What sucks is the first time you insist that it's their problem and it turns out that their stuff is fine, and there is a problem on your end, even though you didn't change anything and they did. This is absolutely fatal to people's trust and perceptions of your service. One of my projects made it a point to implement a healthy logging framework and public dashboard to prevent exactly this and proactively notify if a failure occurred and why. It was super awesome once we had it up, because the organization came to trust us to point that we hardly ever got misattributed as a cause for an issue. It's also pretty hilarious to pull up a dashboard that has a flashing red "It's SUBCONTRACTORS fault" during a meeting SUBCONTRACTOR initiated with Important People to try to blame you for their problem, and have said Important People turn on the other guy as a result.
|
|
#
?
Jan 11, 2019 19:42
|
|
|
BurntCornMuffin posted:This is absolutely fatal to people's trust and perceptions of your service. One of my projects made it a point to implement a healthy logging framework and public dashboard to prevent exactly this and proactively notify if a failure occurred and why. It was super awesome once we had it up, because the organization came to trust us to point that we hardly ever got misattributed as a cause for an issue. I had a boss who beat this into me. Never say "it's not a problem on our end" unless you've checked and double-checked that it's not a problem on our end, and have ample evidence to defend that statement.
|
|
#
?
Jan 11, 2019 19:51
|
|
|
New Yorp New Yorp posted:What sucks is the first time you insist that it's their problem and it turns out that their stuff is fine, and there is a problem on your end, even though you didn't change anything and they did. Oh trust me I'm an old pro at that trick. In this particular case it's almost certainly that whatever the changes they made, our software should be able to handle it either way, but our solution is brittle enough that it probably can't handle anything but exactly what it expects. But no time to untangle that mess, we have new features to half-build! New Yorp New Yorp posted:I had a boss who beat this into me. Never say "it's not a problem on our end" unless you've checked and double-checked that it's not a problem on our end, and have ample evidence to defend that statement. I usually try to translate this to some variation of "We haven't found anything on our side yet, but we are putting in some additional instrumentation to try and get more detail. In the meantime could you send us <har file/packet capture/query string/any other diagnostic or piece of hard data they haven't bothered sending us yet>?" No blame, no refusal of responsibility, just assurances that we're still on it and steps they can take to help.
|
|
#
?
Jan 11, 2019 20:06
|
|
|
Subjunctive posted:[Hi there! I'm looking to hire some people, and I've been told that this is a good place to tell people that. Please accept my apologies and let me know if that's not the case!] Wouldn't this be better in the newbie thread and the oldie thread?
|
|
#
?
Jan 12, 2019 04:22
|
|
|
Polio Vax Scene posted:Our company has an API server that can receive status updates from a third party. Is the status update content in a request body, or query string, or some other means? Is your caching header correct? If it’s the body then perhaps a proxy or cache on route is responding, since it’s historically valid to assume a GET body has no semantic meaning (see https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962?guccounter=1). You should use another HTTP verb anyway, but definitely don’t rely on GET bodies.
|
|
#
?
Jan 13, 2019 03:04
|
|
|
downout posted:Wouldn't this be better in the newbie thread and the oldie thread? I don’t know the threads very well, but was told this was a good place for it, or I misunderstood someone. I don’t really want to spam it all over CoC, so I dunno.
|
|
#
?
Jan 13, 2019 15:25
|
|
|
Try the Goons For Hire thread: https://forums.somethingawful.com/showthread.php?threadid=3246449
|
|
#
?
Jan 13, 2019 18:04
|
|
|
csammis posted:Try the Goons For Hire thread: https://forums.somethingawful.com/showthread.php?threadid=3246449 Ah, I didn’t see that (possibly because nobody has posted in it for more than a year) — thanks! E: yeah, it’s marked for archival and I can’t post to it. Alas! Subjunctive fucked around with this message at 18:39 on Jan 13, 2019 |
|
#
?
Jan 13, 2019 18:35
|
|
|
Start a new one
|
|
#
?
Jan 13, 2019 18:46
|
|
|
return0 posted:Is the status update content in a request body, or query string, or some other means? Is your caching header correct? Even if the content is outside the body, it's still easy to run into caching problems on this kind of request. Imagine your health check is to make a GET request every minute to https://domain/healthcheck?clientid=123abc&status=ok (empty body, minimal headers, etc). The health check endpoint returns a 200 with an empty body to show that it's accepted the health report. A cache that sits between the two systems is likely to say "oh, you made that request just a minute ago, and all the parameters are exactly the same! Here, let me grab it from the cache for you." It shoots an empty 200 back, and the health check system never sees the request. The solution is to add the Cache-Control: no-store directive to the health check response's headers, although a misconfigured system could potentially ignore that. Switching to POST or PUT is the best long-term option, because even badly configured caches usually understand that they shouldn't be caching responses when a client uses one of the "I am sending you data" verbs. (hot take: HTTP verb semantics are designed for a document management system, don't map well to modern web applications, and the http2 standards people really messed up by not rethinking them)
|
|
#
?
Jan 13, 2019 19:18
|
|
|
That’s what I was alluding to by “Is your caching header correct?” but worth being specific I guess. I agree changing the verb is the right call.
|
|
#
?
Jan 13, 2019 20:03
|
|
|
baquerd posted:Why would nobody want that role? There's plenty of value and people interested in orchestrating test automation and deployment verification. At a large company with complex infrastructure, a large number of systems in need of testing, and a team of automation engineers who know what they're doing, sure I could see it. None of that describes my company.
|
|
#
?
Jan 14, 2019 15:54
|
|
|
Slimy Hog posted:At a large company with complex infrastructure, a large number of systems in need of testing, and a team of automation engineers who know what they're doing, sure I could see it. i thought this placed used to be called microsoft until they scrapped qa
|
|
#
?
Jan 14, 2019 15:57
|
|
|
Qa as a separate department or role is a Bad Idea. We went over this a few times already.
|
|
#
?
Jan 14, 2019 16:28
|
|
|
Keetron posted:Qa as a separate department or role is a Bad Idea. We went over this a few times already. I disagree with this but am fully aware my opinions on the matter is tainted by having a loving useless QA department.
|
|
#
?
Jan 14, 2019 16:40
|
|
|
QA has historically attracted sub-par engineers at the companies I’ve been with but becomes a necessity when you can’t possibly hire enough competent engineers to do development tasks in addition to test.
|
|
#
?
Jan 14, 2019 17:33
|
|
|
Although the reality is frequently different, the ideal to be striving for is that writing tests and testing is owned by the development team. There's no "QA", there's no "SDET", there's just "developers". If there's "no time" to be doing adequate testing, it doesn't mean "we need a separate QA team so the developers can forge ahead writing lovely, broken code that the QA team catches a few weeks later and the developers have to context-switch and fix and delay releases". "No time" to be testing means some combination of these factors: - The team is being overcommitted against their will - The team is estimating poorly - The team isn't adequately baking time to fully validate features into their estimates There's not enough time for developers to adequately test, but there's enough time to go through the "not a bug"/"can't repro" dance with a QA department? Bullshit.
|
|
#
?
Jan 14, 2019 17:48
|
|
|
The QA folks at my company are considered part of the engineering team, but in practice, it's pretty different since there's basically a different manager and chain of command (they do have the same boss once you hit CTO level, but management for QA and development fork under the CTO). Fortunately, we do preach that developer testing time - including any time necessary for unit/integration tests - and QA testing time are all factors of our estimates. There should always be time for testing because if your clients are your beta testers you won't have clients for very long. It's easy to mismanage, but the reality is that the sooner a bug is identified and handled in the SDL, the less it will cost the company in the long run.
|
|
#
?
Jan 14, 2019 18:07
|
|
|
New Yorp New Yorp posted:There's not enough time for developers to adequately test, but there's enough time to go through the "not a bug"/"can't repro" dance with a QA department? Bullshit. The secret to getting enough time to test is to never tell management how much of your total development time is devoted to it. I'm serious. I'm sure there are places where management has an adequate understanding of the importance of testing and how testing or its lack impacts future development time. But I've yet to work in one.
|
|
#
?
Jan 14, 2019 18:40
|
|
|
|
| # ? Jun 3, 2024 07:50 |
|
|
Che Delilas posted:The secret to getting enough time to test is to never tell management how much of your total development time is devoted to it. I'm serious. I'm sure there are places where management has an adequate understanding of the importance of testing and how testing or its lack impacts future development time. But I've yet to work in one. That's why capital-A-Agile has management interacting with "user stories" and "story points" (or whatever your specific implementation of Agile calls those things), not the nitty-gritty "tasks" and "hours per task". The story for implementing frobulation of quxes might have 75% of its time devoted to testing, but the only thing management should care about is that they get it when they were told they'd get it and that it works properly when they get it. The real world doesn't always work like this, of course. But it can.
|
|
#
?
Jan 14, 2019 19:08
|
|