|
DELETE CASCADE posted:they should make a malloc that, if it fails due to oom, it asks amazon to give the vm more ram, then tries again it's called ecs
|
#
?
Apr 25, 2019 22:25
|
|
|
|
| # ? Dec 5, 2024 22:26 |
|
|
DELETE CASCADE posted:they should make a malloc that, if it fails due to oom, it asks amazon to give the vm more ram, then tries again there've been "remote memory paging systems" since at least the 90s, because it turns out that copying memory over the network + storing it in the ram of the server next door is still faster than writing a spinning disk, lmao mostly academic tho. idk if people actually use them
|
|
#
?
Apr 25, 2019 22:28
|
|
|
it was sorta mindblowing the first time i worked on a system where the network was faster than the disk
|
|
#
?
Apr 25, 2019 23:04
|
|
|
animist posted:there've been "remote memory paging systems" since at least the 90s, because it turns out that copying memory over the network + storing it in the ram of the server next door is still faster than writing a spinning disk, lmao Ok but NVME
|
|
#
?
Apr 26, 2019 00:47
|
|
|
Powerful Two-Hander posted:this is the future that orm developers want orm developers, no orm users, probably
|
|
#
?
Apr 26, 2019 01:01
|
|
|
Why stop there? Why not create a stored proc that would take in, say, the web applications' post request body and parse that to be stored into the correct tables in the database? We can just use one stored proc for all post scenarios as this will reduce maintenance cost. Everybody knows that handling everything on the database level is more optimised than code level. BARE METAL IS BETTER. To make things safer, let's only accept the POST body as an argument into our stored proc once it has been transformed to fit our very own bespoke XML schema. Oh by the way the stored proc only runs on that version of MSSQL that's going to be EOL soon, but I'm sure it can be easily rewritten in an hour.
|
|
#
?
Apr 26, 2019 01:33
|
|
|
floatman posted:Why stop there? Why not create a stored proc that would take in, say, the web applications' post request body and parse that to be stored into the correct tables in the database? http://postgrest.org/en/v5.2/
|
|
#
?
Apr 26, 2019 01:43
|
|
|
https://www.graphile.org/postgraphile/
|
|
#
?
Apr 26, 2019 01:58
|
|
|
HoboMan posted:guy here likes to inert into the db via stored procedures where there is only one augment which is an xml blob of whatever you are updating/inserting. Do you accept user input, and if so, have you tried submitting "foo</column><column>bar"?
|
|
#
?
Apr 26, 2019 02:32
|
|
|
send a bunch of null chars to it and see what happens
|
|
#
?
Apr 26, 2019 02:47
|
|
|
DELETE CASCADE posted:they should make a malloc that, if it fails due to oom, it asks amazon to give the vm more ram, then tries again
|
|
#
?
Apr 26, 2019 03:23
|
|
|
hell yeah
|
|
#
?
Apr 26, 2019 05:08
|
|
|
is there a good generalized guide to writing docs that i could provide most high-school level english writing programmers i work with? i know this is a skill that people need to work on to improve i've been going with saying "who (is this for, made it), what (is it for), how (to build and run it, add features), and why (was this made, what problem does it attempt to solve)" we've only had how to build and run it up until recently
|
|
#
?
Apr 26, 2019 16:00
|
|
|
Share Bear posted:is there a good generalized guide to writing docs that i could provide most high-school level english writing programmers i work with? i know this is a skill that people need to work on to improve i'd be interested in this too, I want to write more docs but I dont really know where to begin and how to structure it, I just wing it
|
|
#
?
Apr 26, 2019 16:02
|
|
|
Zlodo posted:i'd be interested in this too, I want to write more docs but I dont really know where to begin and how to structure it, I just wing it 
|
|
#
?
Apr 26, 2019 16:06
|
|
|
Zlodo posted:i'd be interested in this too, I want to write more docs but I dont really know where to begin and how to structure it, I just wing it i hate my writing more than anything else but i dont know how to change it
|
|
#
?
Apr 26, 2019 17:08
|
|
|
Zlodo posted:i'd be interested in this too, I want to write more docs but I dont really know where to begin and how to structure it, I just wing it i usually do a stream of consciousness style thats impossible to follow, and then someone else steps in and rewrites it so i don't have to.
|
|
#
?
Apr 26, 2019 17:21
|
|
|
i just let somebody attempt to use it while i'm with them, and then i write down all the things as i tell them. if nobody uses it, then no docs no problem
|
|
#
?
Apr 26, 2019 17:37
|
|
|
if you implemented the system it's near impossible to write good documentation for it, since you've used it so many times you've been doing things that is not the way the user will use it.
|
|
#
?
Apr 26, 2019 17:39
|
|
|
seriously how do i REST? i never realized how much i never thought about this with my old job's crappy old webforms project. like there are several screens where we have a list with some bare-bones info and can click on the item to get detail and edit. what to do for the endpoints? do i eager-load all the detail data for the basic list? do i re-use the detail object for the list and just have a bunch of null fields returned from a different endpoint on the controller? or do i make a separate object and controller? the last one seems "correct" but it's the most work HoboMan fucked around with this message at 18:08 on Apr 26, 2019 |
|
#
?
Apr 26, 2019 17:57
|
|
|
Separate object and controller, or service or proxy what ever you want to call it to marshall your REST response into your object. It is the most work but good idea for things beyond the most noddy of projects.
|
|
#
?
Apr 26, 2019 18:30
|
|
|
HoboMan posted:seriously how do i REST? Be a madman and implement the PATCH verb and use json-patch. I've never seen it done correctly, though, except in things like Open Policy Agent. The hardest part about plain forms is that "null" can be a valid value so sending "don't change" can be hard because you need some other model representation for that poo poo.
|
|
#
?
Apr 26, 2019 19:23
|
|
|
gonadic io posted:i just let somebody attempt to use it while i'm with them, and then i write down all the things as i tell them. if nobody uses it, then no docs no problem this plus get people to update the docs (or at least tell you) whenever they get stuck. every first impression is incredibly valuable also: examples. start with the simplest smallest example that could possibly be useful to anybody. then add a couple more
|
|
#
?
Apr 26, 2019 19:23
|
|
|
CRIP EATIN BREAD posted:Be a madman and implement the PATCH verb and use json-patch. I've never seen it done correctly, though, except in things like Open Policy Agent. We did this, even though a REST api is supposed to be idempotent, because our objects can be huge. You're right the intentionally blanking is the hardest part.
|
|
#
?
Apr 26, 2019 19:43
|
|
|
CRIP EATIN BREAD posted:if you implemented the system it's near impossible to write good documentation for it, since you've used it so many times you've been doing things that is not the way the user will use it. not really. do you just start implementing a system without giving any thought to how or if the user will use it?
|
|
#
?
Apr 26, 2019 19:45
|
|
|
oh no, another rest bikeshedding opportunity
|
|
#
?
Apr 26, 2019 20:39
|
|
|
ask 10 programmers about implementing a RESTish api and you'll get back 11 opinions
|
|
#
?
Apr 26, 2019 20:40
|
|
|
Pie Colony posted:not really. do you just start implementing a system without giving any thought to how or if the user will use it? no, but once you've been knee deep in it for a long time you start doing things differently. but honestly i just dont give a poo poo about writing documentation thast some other turd's responsibility
|
|
#
?
Apr 26, 2019 20:55
|
|
|
HoboMan posted:seriously how do i REST? do the last one or you are cursing yourself for later or maybe create a base object for view and extend for edit but you'll probably hit a wall at some point later with that if the objects are complex enough alternative that I do not recommend (but have sort of done) put every single property into its own getter so you can lazy load from the db if you need it later but only do this if you have like 3 properties or you hate your database
|
|
#
?
Apr 26, 2019 22:44
|
|
|
redleader posted:ask tef about implementing a RESTish api and you'll waste 11 hours
|
|
#
?
Apr 26, 2019 23:50
|
|
|
write aspirational documentation at the start of implementation, outlining the ways in which you want your product to be usable that way the people actually using your product later get to figure out for themselves all the ways in which you fell short of your goals
|
|
#
?
Apr 27, 2019 04:41
|
|
|
Share Bear posted:is there a good generalized guide to writing docs that i could provide most high-school level english writing programmers i work with? i know this is a skill that people need to work on to improve Most of what I write ends up being: CRIP EATIN BREAD posted:stream of consciousness style thats impossible to follow But, that's still better than nothing. One big emphasis I'd make is that if there were any points where you struggled or spent a non-trivial amount of time thinking about how to implement something, then you should somehow summarize the problem and some of the reasoning at lead to the implemented solution. Depending on the type of documentation, a good expansion on the above suggestion is: if you took an answer from stack overflow (or other online resource), explain the problem you encountered, then include a link to the SO answer. This is just brain storming, but for teaching others, a nice exercise might be something like having them attempt to document another peer's code, or to try to explain another peer's code after reading the other's documentations. Or, depending on how long the course has lasted, just give them some of their own code from earlier in the course and see if they can remember what the gently caress they were thinking, then see if they can think of some notes that would have helped guide themselves when re-reading their own code. Documentation is about making the life of a developer easier, be it you, a coworker, a stranger looking at open source work, someone reviewing a PR, etc. It should be the calm, helpful narrator guiding you through a cryptic landscape. It need not be perfect, but it should provide enough additional context that the combination of it, plus the thing being documented, helps a reader understand why a thing was written as it was and/or what that thing does.
|
|
#
?
Apr 27, 2019 06:59
|
|
|
reason no. 10004 i am a terrible programmer: i keep putting off writing utility functions because i dont think i will have a need for them until ive written the same goddamn thing a billion times and now that i did write the utility function, i have to replace everything in a hundred files
|
|
#
?
Apr 27, 2019 10:36
|
|
|
Krankenstyle posted:reason no. 10004 i am a terrible programmer: it's a classic
|
|
#
?
Apr 27, 2019 10:52
|
|
|
gonadic io posted:it's a classic and the files are latex 
|
|
#
?
Apr 27, 2019 10:59
|
|
|
Krankenstyle posted:and the files are latex I hear Belize is nice this time of year
|
|
#
?
Apr 27, 2019 11:04
|
|
|
im already packing
|
|
#
?
Apr 27, 2019 11:36
|
|
|
Krankenstyle posted:reason no. 10004 i am a terrible programmer: next level: write the utility functions then forget you did and write another set again later
|
|
#
?
Apr 27, 2019 12:13
|
|
|
on it, chief
|
|
#
?
Apr 27, 2019 15:42
|
|
|
|
| # ? Dec 5, 2024 22:26 |
|
|
Powerful Two-Hander posted:next level: write the utility functions then forget you did and write another set again later im at the "it would be really nice to have a utility function that does X, let's go write it. *writes function* 'Error 42069: you already wrote this function two years ago, dumbass'" level
|
|
#
?
Apr 27, 2019 15:46
|
|
