|
HardDisk posted:Yeah, he's forgetting the 4+ GBs of RAM. Wow, a computer with 4 whole gigabytes?? Volmarias posted:My job is unironically wonderful except that it's way more process heavy than it usually is, despite us wanting to have an agile methodology. In my experience "process heavy" and "agile methodology" are in no way at odds with each other.
|
#
¿
Nov 25, 2015 17:38
|
|
|
|
| # ¿ Apr 27, 2024 11:11 |
|
|
Axiem posted:The easiest pieces of code to reason about are idempotent functions. That is, functions that take a set of input and return a set of output, and every time you send the same input in, you get the same output out, without relying on anything except what's in the input set, and without modifying anything outside of its scope. (Side note: these functions are also the easiest to unit test, because each test is given-input-return-output?) This is not quite what idempotent means. Idempotent functions can still have side effects, as long as the outcome is the same if called once or many times. "Set global variable foo to x" is idempotent; "add x to global variable foo" is not.
|
|
#
¿
Nov 27, 2015 06:40
|
|
|
sarehu posted:Not quite? More like, not at all. Well, okay, yeah. I was giving the benefit of the doubt and assuming he intended to mean not the definition in mathematics and functional programming, where f(f(x)) = f(x), but the frequently used other meaning that an operation is repeatable without further changing the state of a system, and a pure function is trivially idempotent in that sense because it has no side effects.
|
|
#
¿
Nov 27, 2015 19:08
|
|
|
DigitalRaven posted:Easier to set up your own remote that auto-pushes to live whenever someone pushes to it. That way changes go live immediately and you only need one pull as part of the build for the production box, so it's more robust when you nuke and rebuild. Production box, singular? Sounds like a pet. How does this scale to multiple potentially short lived servers that are autoscaled? Or does production box mean some sort of deployment coordinator?
|
|
#
¿
Nov 28, 2015 17:39
|
|
|
NightGyr posted:In a reasonably designed code base, the global state will be something like "log this statement" or "write to the database" or "increment a counter" - something more abstract than a raw global and easier to reason about. But it's still important to remember that these constitute global state, even if they're not your classic global variables. To be honest I am not totally sure why this quoted my post; I wasn't making a comment about global state, really, just clarifying what idempotent means in that context.
|
|
#
¿
Nov 30, 2015 03:41
|
|
|
0zzyRocks posted:Software deployment packages like Capistrano can deploy to multiple servers simultaneously. I am aware of that, but that is not the suggestion that my post was in response to.
|
|
#
¿
Dec 2, 2015 04:58
|
|
|
Finster Dexter posted:tbh, yesterday was the first time I've ever needed to know Big O, professionally. And that was because it was a job interview. You really should, it is rather important.
|
|
#
¿
Feb 2, 2016 16:27
|
|
|
Volmarias posted:TDWTF is littered with examples of terrible developers looking for a row in a table by doing SELECT * and then iterating over the results. Even if the database responded instantaneously, it's still an O(n) vs O(1) operation. As your data sizes get larger and larger, having a grasp on the complexity of your queries and your critical sections can have outsized results. I think he was just referring to the part about being asked to estimate the approximate latency, not the time complexity. But yes, you've highlighted quite nicely why I cringe every time someone claims that "big O" is something they'll likely never need to know or think about in the work place.
|
|
#
¿
Feb 3, 2016 16:05
|
|
|
Axiem posted:It's also really great for learning about things from the other person. I feel like I learn a lot more sitting there being able to ask "why do you want to do it that way?" as we're writing it than tracking someone down to ask questions when they're no longer thinking about it. For me, that happens in code review
|
|
#
¿
Apr 17, 2016 16:41
|
|
|
Axiem posted:Yes, but there's nothing quite like "Hey, can I try writing this [thing to interface with framework they're familiar with and you're not]?" when it comes to getting some hands-on experience and learning a framework. I've never worked anywhere that pairing was done regularly as a matter of course, so I won't pass judgment on the practice entirely without too much direct experience. But I certainly don't see it as an acceptable substitute for code review: in particular because very often code is reviewed by more than one person. I might be making a change that affects two different areas, so I'll have it reviewed by domain experts in those two areas, and also share it with a more junior engineer so that they can learn from it.
|
|
#
¿
Apr 18, 2016 03:58
|
|
|
Bongo Bill posted:Correct pair programming can be understood as "inline review," but it's clear that this comparison only extends as far as informal code reviews, not the formal kind. Yeah, my point was mainly that there is often benefit in having more than just two people look at the code
|
|
#
¿
Apr 18, 2016 04:21
|
|
|
On the other end of the spectrum, I've seen some pretty terrifying things that resulted from developers using ORMs to indirectly define or modify schemas without someone around to nanny them.
|
|
#
¿
Jun 2, 2016 15:35
|
|
|
Vulture Culture posted:This is why not doing code review makes baby Jesus cry. You're making an assumption that there was no code review, rather than several people being oblivious to the underlying implications of their ORM usage.
|
|
#
¿
Jun 2, 2016 18:38
|
|
|
Vulture Culture posted:I was responding specifically to the "without someone around to nanny them" part, which is something to which code review is exceptionally well-suited. But if your entire development team has no idea what they're doing, you need to do something else I guess? Yeah, code review is the solution, but the who is an important part. I was just highlighting the opposite extreme from having a DBA micromanaging everything: where there is nobody taking ownership over such things and you just have one web dev reviewing another web dev's changes. Where I'm at now we ensure that any change that touches database schemas is reviewed and approved by the folks that maintain said databases. It's not some onerous approval process, just making sure that people with expertise and responsibility in a particular area are consulted.
|
|
#
¿
Jun 3, 2016 03:35
|
|
|
KoRMaK posted:I dont even know what the gently caress this poo poo means. Descriptive names? You mean the name I gave them, like "first_name" or "my_butts_measurement"? Physical data model vs logical data model? What the hell is the difference? I'll take some guesses. Logical vs physical data model I would interpret as the high level meaning of the columns (e.g. this is a unique/opaque identifier, this stores a user-provided description string) vs roughly or specifically the SQL schema (e.g. this will be an autoincrementing unsigned 64 bit integer, this will be a varchar(255) with utf8 character encoding) As for why the DBA cares about the purpose of the columns, I'd imagine that's so that they can gauge/verify various aspects of tuning and provisioning that are relevant to them (as well as sanity checking): it is helpful to know how you anticipate the dataset growing, how it will be accessed, etc. To be sure, the DBA scenario smackfu laid out sounds unpleasant, but it's not unreasonable for the folks managing the databases to be involved and have input on how those databases are used. In fact, it's better not to just have devs throw a schema over the wall at the DBAs; in my understanding of the horribly overloaded term devops (please please please don't let this start an argument about what devops is), you *want* that involvement.
|
|
#
¿
Jun 7, 2016 15:28
|
|
|
KoRMaK posted:It seems so benign but there are tons of these things scattered across ruby and rails well, started off right anyway.
|
|
#
¿
Jul 1, 2016 17:16
|
|
|
Pollyanna posted:It kinda seems like most products that companies (startups, corporations, the whole gamut) need pretty much just boil down to REST-y CRUD apps. For customer-facing services, anyway. A lot of the interesting problems are either already solved via plugins and gems, or require some crazy Ph.D level work to solve. There is far more of a spectrum than you think. And plenty of hard and interesting problems that don't require PhD level work.
|
|
#
¿
Jul 2, 2016 22:36
|
|
|
For us, weekends are peak traffic. The good thing about that is that planned outages or maintenances are during work hours... The bad (for those of us on call) is that unplanned ones are usually at 5AM on Sundays.
|
|
#
¿
Jul 3, 2016 14:53
|
|
|
Munkeymon posted:git hasn't been around and in widespread use for that long that you can expect everyone to just know how to use it, so if your job listing doesn't have git under must-know, then that's not a very fair question unless part of the process is letting them figure it out themselves with access to google. Not just git, but specifically GitHub.
|
|
#
¿
Jul 8, 2016 16:21
|
|
|
Vulture Culture posted:I'm about to give up on vim after the thirtieth time this year a script didn't work because it had a random "i" or "a" somewhere in it This is hilarious, but I suspect not for the same reason as you might think.
|
|
#
¿
Jul 29, 2016 03:28
|
|
|
Iverron posted:So we're apparently doing a "DiSC Assessment" course as an office next week (devs, designers, social media, etc). After some preliminary googling this appears to be the same Myers Briggs psuedoscience bullshit I've dealt with in far more corporate-y environments. I just did one of those last week (just most of a single day, I hope yours isn't an entire week...). FWIW I found it actually fairly valuable: more actionable and useful than Meyers Briggs "surprise, you're an introvert" poo poo. Try to go into it with an open mind; maybe you will find it was bullshit and I'm a sucker, but maybe not.
|
|
#
¿
Jul 30, 2016 05:02
|
|
|
Both of you, stop. Stop. Step away from the computer. Also, never use Ruby, especially not Rails
|
|
#
¿
Aug 19, 2016 02:40
|
|
|
It's one thing to use reflection for that sort of thing, to dynamically load an instance of some class at runtime meant to implement some interface, and then use it as an instance of said interface throughout your code. It's another entirely to use reflection in your code to inspect an object of some unknown type to find fields/methods/etc and use them.
|
|
#
¿
Aug 19, 2016 18:35
|
|
|
necrobobsledder posted:There is definitely a connotation difference - an architect will almost certainly hold seniority over an otherwise equal engineer. However, companies have upped the arms race on titles with more modern terms like "Senior Member of Technical Staff" and "Lead * Engineer" which could supersede an architect potentially. I'm generally inclined to think a company that is a sales culture means an "architect" is probably in sales based upon my experience in such companies. And this is why you don't try to generalize job titles too much between companies. When I was at Oracle years ago, Member of Technical Staff was the second individual contributor role, above super-entry level position that a new college grad from a good school would skip completely. Senior MTS was my position, and the guy who had been there for 20+ years and was on the company wide architecture review board was a Senior Architect, the highest individual contributor role in the company.
|
|
#
¿
Sep 18, 2016 18:01
|
|
|
ratbert90 posted:My company only asks for a year contract if they help you move. Recruiters are part of the game and sure as gently caress don't fall on the employees. Having to pay back your relocation bonus on a prorated basis is pretty normal; recruitment fees, not so much.
|
|
#
¿
Nov 3, 2016 03:34
|
|
|
Vulture Culture posted:Anecdotally, having fewer rules seems to make it easier to do it wrong, because you not only need to exercise discipline, you also need good judgment. You can't rely on someone else's canned process to save you. I love the (perhaps unintentional and unfair) implication that you actually can rely on scrum to do this for you
|
|
#
¿
Jan 2, 2017 16:59
|
|
|
Also, scaling problems, for example. Maybe not a bug, but also not a user story? But running into a scaling issue doesn't mean the story for the feature that is no longer scaling was done "wrong" since it may have been an entirely correct and reasonable approach to the problem when originally built. Unless you're of the opinion that tech debt is never worth incurring and everything should be built to scale as much as it'll ever possibly have to from step 1.
|
|
#
¿
Jan 5, 2017 05:37
|
|
|
Khisanth Magus posted:That is basically what it has been in my experience. Run the meetings, and do the burn down chart, that is pretty much it. How the gently caress is that an entire job?
|
|
#
¿
Mar 1, 2017 04:58
|
|
|
My biggest issue with these discussions is the sometimes implicit assumption that the stronger the workers rights, the better: in that there is rarely an argument explaining why the specific level of rights being advocated is the right level. Would a requirement of 1 year advance notice to let someone go be better than 3 months? If not, is 3 months the right number? More? Less?
|
|
#
¿
Mar 23, 2017 03:52
|
|
|
Your last point is totally incongruous with the first two paragraphs in your post to me. The BDD tests should not be technical in nature, and the PMs should be involved from the get go? Ok, sure. Unit tests and domain model tests, not API or UI tests? How is that not the opposite of what you just said?
|
|
#
¿
Apr 28, 2017 15:01
|
|
|
Cucumber is pretty stupid, IMO, with the disclaimer that the only time I used it was on a team with only developers so it made especially no sense. Someone writes the test as plain text, and then someone else has to write the logic of the actual tests anyway, and then also an extra layer of regular expressions to map the text to the tests. I would dispute that "developers love it," on that basis. The silliest thing is that it requires that each line start with one of those 5 or so words, but they have absolutely no impact on the test whatsoever; it's a totally arbitrary limitation on what text you can write.
|
|
#
¿
Apr 28, 2017 21:39
|
|
|
Plorkyeran posted:I have never seen an example of how Cucumber could be used that wasn't blatantly insane and useless which always makes me assume that I'm just misunderstanding it, but then I read yet another blog post that assumes that the actual implementation of the tests is just magicked into existence... Yeah, I have trouble picturing it being worthwhile in any circumstance, but in particular it blew my mind to see it in use at a startup of like 6 people, all developers. If there is ever any value in it, it's certainly not to be found there.
|
|
#
¿
Apr 29, 2017 00:41
|
|
|
So in that case it seems like the real value is in the fact that the stakeholder actually formally wrote poo poo down and both parties can be held to that. The fact that those words get passed through a regex and run as tests is at some level immaterial, at least to the stakeholder, right? Like the same thing from a development standpoint could be accomplished by writing tests to verify that same behavior in whatever way suits the devs, and then if there is a conflict it can be resolved by actually verifying the behavior. After all, the tests could be broken: why should the guy assume the tests are implemented correctly if he doesn't think the rest of it is?
|
|
#
¿
Apr 29, 2017 06:06
|
|
|
geeves posted:This was after I did a test interview at Uber in which the interviewer said, "I can't believe you can't do this." Well, to be fair, gently caress Uber
|
|
#
¿
Jun 11, 2017 03:53
|
|
|
Pollyanna posted:I don't really get why Ruby/Rails has such a bad reputation around here. From what I've seen of discussion here, I'm supposed to avoid it, but I don't see a major difference between it and other MVC frameworks. My thoughts, having spent the last 4 years or so working with a combination of a (now ~8 year old) Rails monolith and a bunch of Scala services: Rails is not "dead", as far as I can tell, based on the number of recruiters I get hounding me about Rails jobs. It is not the next hot new thing, and it might not be growing, but it is definitely not dead. The main issue with it from my perspective has already been mentioned: in a large project, the tools, idioms, and features make it very easy to build a very hard to maintain and debug monolithic application. Their thing, "convention over configuration?" When initially writing a new app, I suppose it must be nice, but when working with a large existing application it becomes "magic over clarity." There are signs that some of the Rails community has learned from this, but I'm not totally convinced. One problem I see frequently with it, at least compared with my Scala work (and this may not be an issue all that broadly) is that the concurrency primitives are not great; for a smaller CRUD app this may be fine, but for our larger application that might issue queries to a few different databases and send requests to a number of internal and external services to serve a single page, it is rough. Finally, I much prefer working with a language with a type system like Scala, but I'll grant personal preference there to a extent. I could go on, but I don't have time at the moment. In short: I despise it and do all that I can to pare down our monolith and make it easier to work with, and would prefer not to take another job working with Rails. But I don't think it is at all crazy in the short term for people to continue working with it.
|
|
#
¿
Jun 30, 2017 16:38
|
|
|
sarehu posted:ACID isn't applicable if you don't have transactions. You've just got the D to worry about. Depending on how you're using it, and what definition you're operating under, you may have to worry about C. For example, if I recall correctly, with Elasticsearch, read after write consistency: if you write a document, it should be available in the document store right away but won't necessarily be indexed fully yet. There's a configurable flush interval, not sure what the default is but I think it is several seconds at least.
|
|
#
¿
Jul 1, 2017 01:55
|
|
|
Yes. I've spent most of the last 4 years doing exactly that, though I've been doing more of the "building services" part than the containerization part. I'd be happy to answer specific questions, but perhaps you might find this helpful (written by a coworker): https://medium.com/strava-engineering/mesos-at-strava-5ac98d00dacf
|
|
#
¿
Sep 14, 2017 03:31
|
|
|
Volmarias posted:Notifications come in to your phone if someone @ mentioned you. You have to remember to turn that off, then remember to turn it back on when you're "back". Or just leave it off permanently, like I did. Too many goddamn distractions.
|
|
#
¿
Oct 6, 2017 15:30
|
|
|
geeves posted:For the love of god this. I hate people who use their iPhone headphones and the mic scratches on their hoodie or whatever the entire meeting. Real problem there is that they aren't muting themselves when not speaking.
|
|
#
¿
Oct 28, 2017 17:22
|
|
|
|
| # ¿ Apr 27, 2024 11:11 |
|
|
I have full production database access, but not directly via my machine (have to go through a DMZ). I am also in an oncall rotation of ~8 people responsible for responding to and resolving (with delegation if necessary) any and all production issues.
|
|
#
¿
Nov 8, 2017 03:59
|
|