|
Electrical engineers write a very special kind of code.
|
# ? Mar 31, 2019 17:01 |
|
|
# ? May 28, 2024 08:25 |
|
https://thenewstack.io/which-programming-languages-use-the-least-electricity
|
# ? Mar 31, 2019 17:37 |
|
That's quite the name + content combo
|
# ? Mar 31, 2019 21:10 |
|
It looks like they dont include energy used for compilation?
|
# ? Apr 1, 2019 12:22 |
|
Or time spent developing, debugging, and testing
|
# ? Apr 1, 2019 13:25 |
|
I'm finally being offered a full-time position at my side gig (that was hourly part-time work). It's a 20k pay bump, and the work is a lot more fulfilling. And, most excitedly, if I play my cards right, I can turn in my notice this week and my last day at my current job will be before our next PI Planning meeting. The work rig they want to give me at the new place is a dual-2080 Ti machine (for use with machine learning, of course.) That's also a bonus.
|
# ? Apr 1, 2019 15:02 |
|
leper khan posted:It looks like they dont include energy used for compilation? It's O(1) but the number of times you run the code is O(n)
|
# ? Apr 1, 2019 15:59 |
|
"Announcement: Because nobody can agree on REST standards the company will move towards SOAP, an up to date communication protocol with a proven track record." Apparently this is the idea of a funny April Fools' joke among developers.
|
# ? Apr 1, 2019 17:47 |
It made me laugh
|
|
# ? Apr 1, 2019 18:17 |
|
Carbon dioxide posted:"Announcement: Because nobody can agree on REST standards the company will move towards SOAP, an up to date communication protocol with a proven track record." I honestly thought you were making a sincere statement. Sounds completely plausible.
|
# ? Apr 1, 2019 18:18 |
|
Carbon dioxide posted:"Announcement: Because nobody can agree on REST standards the company will move towards SOAP, an up to date communication protocol with a proven track record." The real joke is that developers would want to plan ahead instead of just sending whatever they feel like today on the wire.
|
# ? Apr 1, 2019 18:34 |
|
Heard at work today: Can our REST library handle XML responses instead of JSON?
|
# ? Apr 2, 2019 11:29 |
|
smackfu posted:Heard at work today: Can our REST library handle XML responses instead of JSON? Of course, if you're lucky you may even get a CDATA, code:
|
# ? Apr 2, 2019 14:34 |
|
smackfu posted:Heard at work today: Can our REST library handle XML responses instead of JSON? Hahah. What's a database? We want you to crawl Grubhub and scrap their site for restaurant data and then put that data into excel sheets which our backsystem will serve to the APP.
|
# ? Apr 2, 2019 14:45 |
|
Gildiss posted:Hahah.
|
# ? Apr 2, 2019 16:34 |
|
Gildiss posted:Hahah. And don't worry, only the entire Marketing department is allowed to edit those excel sheets manually.
|
# ? Apr 2, 2019 19:11 |
|
It is technically legal to use other formats than json in REST, including, yes, XML. As far as I know REST doesn't say anything about the format, only about the meaning of http methods on certain URIs, like POST on someURL/123 creates 123 while PUT does an update (but as I said, nobody can agree on which is supposed to which, there seem to be as many REST 'standards' as there are pages explaining REST).
|
# ? Apr 3, 2019 06:37 |
|
Carbon dioxide posted:It is technically legal to use other formats than json in REST, including, yes, XML. As far as I know REST doesn't say anything about the format, only about the meaning of http methods on certain URIs, like POST on someURL/123 creates 123 while PUT does an update (but as I said, nobody can agree on which is supposed to which, there seem to be as many REST 'standards' as there are pages explaining REST). well like a) rest is a set of constraints on web services, so why would you need a special "rest" client if you have an http client? i imagine something calling itself a client rest library probably exists, but the pm asking about it specifically might indicate a lack of understanding of what rest is supposed to be. b) ideally you should be able to just specify request type in web request and server framework will take care of the xml/json deserialization - however, someone asking if this is possible usually means a maintenance drone or a dinosaur programmer not familiar with web is trying to make a web request from some unholy legacy code, which is scary.
|
# ? Apr 3, 2019 07:11 |
|
Theoretically, a proper REST client would be able to do smart stuff like hypermedia navigation, so it's not just an http client. But... because people (justifiably) don't give a poo poo about HATEOAS, and XML is uncool, REST basically just means "JSON over HTTP" now and we'll have to accept that.
|
# ? Apr 3, 2019 08:17 |
|
Messyass posted:REST basically just means "JSON over HTTP" now and we'll have to accept that. I'll keep stubbornly complaining about people using "REST" when they really mean "HTTP" until I die thank you very much
|
# ? Apr 3, 2019 09:09 |
|
"Relaying a question from our developers: do you intend to complete this integration using traditional SOAP requests or will we be using the newer REST requests?" Translated to English from an actual e-mail in my inbox. A few e-mails later it turned out that the reason he was asking was that whatever framework his developers were using was apparently much faster at handling json than xml so clearly "REST requests" were the better design choice
|
# ? Apr 3, 2019 09:22 |
|
Use SOAP just to annoy them slightly.
|
# ? Apr 3, 2019 11:32 |
|
redleader posted:Use SOAP just to annoy them slightly. Goons don't know how to use SOAP
|
# ? Apr 3, 2019 14:17 |
|
Ive been kicking myself a bit recently for using non-REST endpoints while we put this new functionality together, it feels so weird not to have explicit get-post setups.
|
# ? Apr 3, 2019 14:34 |
|
We switched from REST to graphql a few months ago and it's been pretty good. It's still just JSON over HTTP though.
|
# ? Apr 3, 2019 14:56 |
|
I've seen a few attempts at structuring HTTP APIs to look like REST so that each endpoint represents a resource or a collection of resources. Eventually it always just becomes this weird masturbation over translating actions/procedures into resources (because endpoints can only refer to resources or collections). I've seen people argue for replacing `POST /login` with `POST /login-attempts` because the first is an action not a resource therefore it's not ~~REST~~ therefore it's ugly and can't be used (meanwhile the API isn't REST anyway as REST is basically useless without an AI client but hey whatever)
|
# ? Apr 3, 2019 16:05 |
|
Gildiss posted:Hahah. This reminds me of something I read about The Sims. They had excel sheets that modeled the AI and objects and stuff. The would tune and tweak the game from excel, then their tooling would scrape the spreadsheets to generate the datafiles for the build process. It was horrifying from a maintenance perspective, but kinda cool from the perspective of seeing all the internals represented as graphs and numbers.
|
# ? Apr 3, 2019 16:08 |
|
My Rhythmic Crotch posted:This reminds me of something I read about The Sims. They had excel sheets that modeled the AI and objects and stuff. The would tune and tweak the game from excel, then their tooling would scrape the spreadsheets to generate the datafiles for the build process. It was horrifying from a maintenance perspective, but kinda cool from the perspective of seeing all the internals represented as graphs and numbers. I like the idea on paper though. Seems like starting with hard math for your gameplay stuff is a good idea, especially with something with as much gameplay stuff as the Sims. Now in practice I wouldn't want to try to work that kind of thing into my toolset. Macichne Leainig fucked around with this message at 16:37 on Apr 3, 2019 |
# ? Apr 3, 2019 16:25 |
|
Isnt bespoke tooling for designers standard game dev practice? Sure, the tool isnt usually Excel, but the decision isnt categorically ludicrous, especially given that reading data from a simple spreadsheet isnt that painful.
|
# ? Apr 3, 2019 17:02 |
|
raminasi posted:Isnt bespoke tooling for designers standard game dev practice? Sure, the tool isnt usually Excel, but the decision isnt categorically ludicrous, especially given that reading data from a simple spreadsheet isnt that painful. I'm just imagining making custom annotations in java so that you can deserialize from excel files. Every member of every class having @Element(cell="B23") or something, and having to sync all that poo poo up every time someone makes a change. Barf.
|
# ? Apr 3, 2019 17:29 |
|
And Karen in sales deciding to put some conditional formatting in the excel file or anyone moving things around in it because why not.
|
# ? Apr 3, 2019 17:36 |
|
The appropriate thing to do in that case would be to have a build step that translates the Excel file into something more easily ingested by the program and validates it.
|
# ? Apr 3, 2019 17:40 |
|
I would invert it. If people want to play with the data in excel, add a CSV export feature.
|
# ? Apr 3, 2019 17:44 |
|
We use Excel sheets to generate a ton of repetitive PLC code (think input/output/SCADA mapping etc). Works out pretty drat well for the most part, and reduces the error rate significantly in the process.
|
# ? Apr 3, 2019 18:58 |
|
gently caress it, man, whatever works.
|
# ? Apr 3, 2019 19:51 |
|
What I think you really need to do is some dependency inversion: have the Excel spreadsheet generate the code, not the other way around. I have seen this before Wibla posted:We use Excel sheets to generate a ton of repetitive PLC code (think input/output/SCADA mapping etc). Works out pretty drat well for the most part, and reduces the error rate significantly in the process. Okay I can see this too because that's some annoying crap.
|
# ? Apr 3, 2019 20:20 |
|
Messyass posted:Theoretically, a proper REST client would be able to do smart stuff like hypermedia navigation, so it's not just an http client. An API I had the immense pleasure of pulling data from a while ago didn't really understand any of this, or that there are HTTP Requests Methods other than GET. Need to delete something? GET. Need to upload something? GET. Need to retrieve something? GET. They also didn't really understand that query parameters are a thing, so all options are given as part of the url, without identifier. Some options were optional. I saw an endpoint that had two optional integer values. How does the thing know which one you supplied when your url is https://i.am.terrible/data/1/? Your guess is as good as mine. Also, it didn't return JSON, but CSV. They still called it a REST API. Guess that makes it sound better?
|
# ? Apr 3, 2019 20:26 |
|
Hollow Talk posted:An API I had the immense pleasure of pulling data from a while ago didn't really understand any of this, or that there are HTTP Requests Methods other than GET. Need to delete something? GET. Need to upload something? GET. Need to retrieve something? GET. I always think of this anecdote when people mention side-effects on GET requests
|
# ? Apr 3, 2019 20:42 |
|
sunaurus posted:REST is basically useless without an AI client but hey whatever Succinctly summarising my main problem with REST-inspired APIs.
|
# ? Apr 4, 2019 06:32 |
|
|
# ? May 28, 2024 08:25 |
|
sunaurus posted:REST is basically useless without an AI client AI client?
|
# ? Apr 4, 2019 11:44 |