|
just use spanner for everything it's cool
|
#
¿
Jul 21, 2018 20:26
|
|
|
|
| # ¿ Apr 25, 2024 13:00 |
|
|
jit bull transpile posted:It's more complex than that unfortunately. There's *layers of abstraction * involved and we have to have the pipeline fail when data is invalid so it can be cleaned. We can't quietly drop bad data. A pain when doing tests but necessary for production. Can you add a step before pipeline failure to count all the garbage data and generate some kind of report? then give it to whomever and tell them you can't accept their data unless it passes this validation
|
|
#
¿
Aug 8, 2018 14:37
|
|
|
Triglav posted:i wanna write terrible programs for money that go fast and dont use a lot of ram I usually interpret "c/c++" as "c++ but used really badly in a c-like way"
|
|
#
¿
Aug 15, 2018 19:48
|
|
|
There's something I've run into a few times in slightly different forms, and I'm wondering if there's a name for it or common pattern for handing it. basically, there's some data at rest. A serving job loads some of that data and validates it in order to handle a request. Separately, there is code that loads all of the data and validates some of the same invariants. Conceptually it seems like a really good idea for the code that validates stuff to be completely shared. In practice, I have never seen it works out that way. Often, the serving job possesses additional context or privileges necessary for certain checks. Or perhaps the validation job is able to perform more checks because it operates on all the data rather than a subset. Or maybe in one context the data is in text form and you want line numbers + human actionable messages for every single issue, but in the other context the data is in a serialized binary format and you only want to know good/bad and fail quickly. So have y'all run into stuff like this? What kind of things do you consider when working on this problem?
|
|
#
¿
Sep 4, 2018 18:10
|
|
|
comedyblissoption posted:is there something better than git's distributed immutable dag for programming source control piper b*tch
|
|
#
¿
Sep 5, 2018 04:24
|
|
|
cinci zoo sniper posted:aws docs seemed ok but that was much earlier and i was doing much simpler things (also was way more clueless than now if that sounds believable to you) I wrote some bad docs for the gcp product I work on but my team has a tech writer now, so they should be getting better. I like the parts of gcp I've used on my gently caress around / learn stuff projects. right now it uses gcp dns, load balancer, cdn, and cloud storage. GCLB recently added 'automatically managed https certificates' which is nice because now I don't have to run a bunch of letsencrypt commands every couple months. I'm confident https://www.goatse.gop could efficiently handle millions of users if it ever needed to (it won't). Cloud shell is also really convenient, and I've enjoyed loving with cloud build and kubernetes engine.
|
|
#
¿
Nov 15, 2018 12:59
|
|
|
MrMoo posted:Working with Boost.ASIO and Boost.Beast this week. Yesterday I get a TLS server up and running and today HTTPS, I'm getting the distinct impression the API is worse than Perl in number of permutations of doing the same thing. Every example and usage is annoyingly different. Asio is a piss template hell api. I'm sure it's very efficient and zero-overhead or whatever but the code you have to write to make things work is loving incomprehensible to anyone who hasn't spent hours studying the docs. I am not an asio expert, but one option to simplify things: figure out exactly what concurrency model you want to use, and just bake that into your code everywhere. Don't try to make things too flexible. Ie: if you're going to spawn a coroutine for every incoming connection, you're gonna need to plumb a yield_context& parameter through hella functions and you should just live with that. Once you've got the hang of asio, beast's http stuff feels straightforward but barebones. It's like, here's a struct with a field for each part of the http request. beast will serialize it on the wire for you. Go look at the RFC if you want to know how the connection-token and keep-alive header should be handled by your code.
|
|
#
¿
Nov 28, 2018 05:49
|
|
|
because my brain is broken and I enjoy writing c++ for regular everyday tasks
|
|
#
¿
Dec 10, 2018 17:49
|
|
|
90% of the time when I'm writing a regex it's because a tool I'm using accepts them for filtering or find/replace, and I'm writing ".*something.*" or whatever. Imo this level of regex ability is important for everyone to learn. If a regex isn't immediately understandable or pulled directly from an RFC, I'm probably pushing back hard in code review.
|
|
#
¿
Dec 12, 2018 02:16
|
|
|
the bazel equivalent is a data dependency https://docs.bazel.build/versions/master/build-ref.html#data This probably isn't helpful for cmake, but maybe it'll point you to some new search terms or find a project with both bazel and cmake configured and copy them.
|
|
#
¿
Dec 12, 2018 03:32
|
|
|
redleader posted:so how do goog handle storage (+ dbs, although i appreciate that dbs at goog are probably of a different scale) if k8s sucks at it you just put everything in spanner. how does spanner handle storage? very carefully if you work with bigass blobs of unstructured data, you might put them in google cloud storage or maybe an older system built directly on colossus. idk I don't work with that kind of data.
|
|
#
¿
Dec 14, 2018 11:10
|
|
|
hackbunny posted:as usual, herb sutter to the rescue with a proposal to steal features from other languages (in this case, Swift). incidentally, it also explains the issues with c++ exceptions much better than I have this is cool and well written and I hope to use it some day. At work, we heavily use error propagating macros like the paper describes. eg. RETURN_IF_ERROR(DoFoo()) << "DoFoo() failed handling " << request.DebugString(); as you can see, they also have a relatively convenient way to append debugging detail as an error propagates the layers of the stack between the 'throw' and the 'catch'. how can/should a programmer add this kind of detail in the exception world of that paper? A try-catch that just appends detail and re-throws sounds unwieldy to me, but that could be because I've been living in an exceptionless world for so long.
|
|
#
¿
Jan 16, 2019 17:34
|
|
|
I like bazel a lot
|
|
#
¿
Feb 2, 2019 02:55
|
|
|
ratbert90 posted:I just learned of the Bazel build system and I am truly and utterly horrified by it. it works great inside Google where there are whole teams for managing different toolchains. also I like it for my personal garbage because it's what I'm used to and I never need to cross compile anything anyway. What do you mean by the protobuf part though? i've never had to use a protobuf to configure anything
|
|
#
¿
May 3, 2019 17:23
|
|
|
ratbert90 posted:I thought the config files were derived from protobufs? https://docs.bazel.build/versions/master/skylark/language.html Yeah I agree the docs are frequently outdated in frustrating ways. It's also changing fast enough right now that a build I set up like 6 months ago straight up doesn't work today because the config language was revised / some syntax was deprecated.
|
|
#
¿
May 4, 2019 03:22
|
|
|
I'm not familiar with rust, and I feel like I'm missing something. what's the difference between this and like a std::optional<T>? Does this avoid the runtime cost of keeping track of whether there's a value or something?
|
|
#
¿
Jul 5, 2019 02:41
|
|
|
ctps: yesterday I fixed a race condition by reordering members in a c++ class. initializing the first member started a thread that touched the other members. that thread raced with with the initialization of the other members. solution: make the thread member the last member of the class. C++ is a really dumb language sometimes.
|
|
#
¿
Jan 16, 2020 10:52
|
|
|
DuckConference posted:
I see/use that comment syntax at work sometimes. It's a clang-tidy linter check iirc. if you write /*fart=*/ and 'fart' isn't the name of that parameter then you'll get warnings/errors. Useful for avoiding passing arguments of the same type in the wrong order and such. IMO, if callsites aren't readable without those comments, it may be time to refactor. like if the function signature is void(int, int, int, int, int) then nobody is gonna get that right. Also agree that giving those constants names would help in your case.
|
|
#
¿
Jan 29, 2020 09:34
|
|
|
this makes more sense in the context that internally google uses a monorepo where 'library version' isn't a concept so nobody at google has any idea how this supposed to work.
|
|
#
¿
Mar 3, 2020 01:19
|
|
|
bazel is a really good build system if one of these applies to you: * You don't depend on any external libraries * The external libraries you depend on already use bazel. * You have teams of people maintaining bazel build configs for all your dependencies
|
|
#
¿
Apr 28, 2020 19:12
|
|
|
Spazmo posted:fuckers were so indoctrinated by borg and blaze and the monorepo and the rest of it that they have no idea how to get anything done without first reinventing those wheels. this is me and it sucks. every time I start a new fuckaround personal project I spend like two hours setting up the perfectly hermetic reproducible build and thinking about kubernetes and then I log the gently caress off having accomplished nothing of value and never touch it again.
|
|
#
¿
Oct 9, 2020 03:41
|
|
|
my recent pet peeve is when a function starts out clean. like it has one or two input parameters and returns a value. nice later, someone adds another parameter like like "bool do_slightly_different_thing" or "also_do_other_thing." mayyybe this is reasonable. repeat 1-3 more times. now the function is 10x harder to understand and annoying to refactor because it's called in multiple places for only tangentially related purposes. is there a pithy phrase for this problem?
|
|
#
¿
Oct 27, 2020 01:38
|
|
|
I work on a product that is implemented in C++. We rarely define new C++ (non-rpc) interfaces. I've kinda groomed our test strategy for "unit tests" to be like: * Wherever possible, use real implementations. * When required, use fakes/mocks (generally for the remote services we depends on) * Rarely mock anything else. It's going pretty OK for us! Hope this helps
|
|
#
¿
Jun 11, 2021 17:22
|
|
|
pointsofdata posted:When you see some code you don't like do you: If I really don't like some code, I'll change it myself and send the code review to the original author with a description like "I think this change has has advantages X, Y, and Z. The behavior is mostly the same except for case W. Am I overlooking anything about the original implementation?" where xyz are like "reduces complexity", or "improves readability" or "more consistent with the rest of our codebase". Sometimes it's a knowledge-sharing thing like "hey have you seen this new C++20 feature? You can use a ranged-for loop now" I send this kind of thing pretty often. I like to think I'm helping / mentoring, but I do worry about looking like a code dictator or something.
|
|
#
¿
Jun 17, 2021 04:48
|
|
|
abigserve posted:the future of on-prem is the poo poo like Azure on-prem DC (whatever it's called) where it's literally the Azure product suite, interface, etc, except it's delivered as a big rack you plug into your data centre. AWS has a similar thing too. how does this work maintenance-wise? like, who debugs / fixes things when something goes wrong with a piece of software running in that big opaque rack? Does an azure eng just remote in whenever necessary and people are OK with that?
|
|
#
¿
Aug 17, 2021 12:16
|
|
|
I'm late for yaml-chat, but every time I've used yaml for anything it's because some other team we have to work with requires it. and every single time it's like yaml, but one string is named "query" and it's where you put a giant sql query. or yaml, but with string named "command" and that's where you put a bash script. etc and it's like cool, now my ide can't display or properly auto-format this query/script and none of our automated tooling can maintain it, thanks. also the syntax is poo poo and I hate it
|
|
#
¿
Sep 1, 2021 02:52
|
|
|
hermetic - start an environment with whatever changes you want whenever you want. Some dependencies are faked. Dev - pushed from head hourly. Staging - promoted from dev daily (if dev tests pass). Prod - promoted weekly from staging (if staging tests pass). It's not perfect, but I'm happy. Having entire teams creating release automation systems is one of the nice things about working at a giant company.
|
|
#
¿
Mar 14, 2022 13:11
|
|
|
|
| # ¿ Apr 25, 2024 13:00 |
|
|
wish we could just never launch new features. whenever something goes wrong it's always triggered by a customer using an awkward combination of features that never actually got tested because exhaustively testing every feature with every other feature has become infeasible due to the combinatorial explosion of terrible code we wrote every product should just do one thing, and then never change in any meaningful way, except insofar as it allows me to get paid for refactoring code to be prettier
|
|
#
¿
Aug 20, 2022 07:53
|
|