|
Jabor posted:Well-structured programs with good separation of concerns also helps avoid unrelated changes from stomping on each other. That's a far-off wish at this point.
|
#
?
Mar 2, 2017 16:12
|
|
|
|
| # ? May 31, 2024 01:47 |
|
|
How far in advance did you know that this major refactoring would be done? Maybe you could mention the extra time it's taking and see about having a policy of developers announcing when they go to make broad changes. Still wouldn't solve every case though.
|
|
#
?
Mar 2, 2017 16:16
|
|
|
Pollyanna posted:How do you reconcile that with tickets being done in parallel that touch the same file but end up having incompatible changes? Our PM/PO is bearing down on us to get stuff like copy changes and CSS fixes up, and my coworker's copy changes ended up wildly changing the structure of the file I was fixing the styling on. poo poo like this happens over and over again and I'm getting really sick of it. The correct approach is to pretend your coworker didn't touch that file and just overwrite it all with your version. (Don't actually do this.)
|
|
#
?
Mar 2, 2017 16:29
|
|
|
But yeah, the only way to avoid merge conflicts is to communicate across the team so people know when other people want to work on the same files. There are tools that can help you resolve merge conflicts when they happen, but they only really do that by allowing you to see the various changes side-by-side and pick "okay, I want this change from $coworker's commit, and this change from my commit, and here where there's a conflict I'll need to rewrite part of the code." If the conflict is really extensive it'll still be a lot of work to resolve, unfortunately.
|
|
#
?
Mar 2, 2017 17:10
|
|
|
Quick C# design question. If I have 4 Boolean values in a database, which will be changed by checkboxes on a form, is it better to - have 1 function to update the database that takes a column name (String) and value as parameters have 4 functions that only take a value as a parameter, one for each column. Is this purely preference, or is there a better practice? EDIT: Nevermind. I'm pretty sure I can't parameterize column names. Seafea fucked around with this message at 17:40 on Mar 2, 2017 |
|
#
?
Mar 2, 2017 17:14
|
|
|
First, from the database perspective, you should update them table-wise. If the values are all columns on the same table, it's both safer (transactionally) and more efficient to update them in a single statement. Second, your first function should take four boolean values as parameters but not the column names. You shouldn't make the caller supply the column names because there's only going to be one right answer for your table structure and if the caller whiffs it (intentionally or accidentally) the wrong thing will happen. Fake edit to answer your edit: even if you could parameterize column names you probably shouldn't for reason #2.
|
|
#
?
Mar 2, 2017 17:44
|
|
|
What is a good way to learn C#? I program in python almost exclusively, though I can stumble around okay in JS, Java, C, and Go.
|
|
|
#
?
Mar 2, 2017 17:47
|
|
|
Eela6 posted:What is a good way to learn C#? I program in python almost exclusively, though I can stumble around okay in JS, Java, C, and Go. Pick a project and dive in. Practice is the best way to learn languages once you already have several under your belt, especially since your prior languages are all also declarative languages (indeed, Java and C# are often compared as two languages trying to do basically the same thing). If you're starved for projects, you could try downloading Unity and making a videogame. Unity uses C# for its programming side.
|
|
#
?
Mar 2, 2017 17:57
|
|
|
This is great advice, but I have health issues that prevent me from typing enough to write much code, so I pretty much have to learn passively. I realize this is unusual and I should have stated it up front. I guess my question really is "is there a great C# book?"
|
|
|
#
?
Mar 2, 2017 18:00
|
|
|
TooMuchAbstraction posted:But yeah, the only way to avoid merge conflicts is to communicate across the team so people know when other people want to work on the same files. Yeah, they should have exchanged work items after finding out during a standup that they were overhauling the same file.
|
|
#
?
Mar 2, 2017 18:08
|
|
|
Pollyanna posted:Is there some kinda special trick to dealing with merge conflicts? I made a bunch of changes to the markup for one of our apps, but my coworker had a ticket to do major markup changes as well and merged it in before mine. Now my stuff conflicts with hers. Is there a way to head off conflicts like these, or are they unavoidable? In addition to the correct suggestions you've received so far: it can help to have relatively small commits. Keep them logical, atomic, etc. of course but several smaller might merge easier than one big.
|
|
#
?
Mar 2, 2017 18:09
|
|
|
Eela6 posted:This is great advice, but I have health issues that prevent me from typing enough to write much code, so I pretty much have to learn passively. What do you want to do with it? Find projects like that (e.g. on GitHub), download, read through, work on issues, add tests, etc.
|
|
#
?
Mar 2, 2017 18:11
|
|
|
Eela6 posted:This is great advice, but I have health issues that prevent me from typing enough to write much code, so I pretty much have to learn passively. I'd argue that if you aren't practicing what you're reading, then you aren't really learning the skills. I recommend looking into alternative ways to get text input into the computer. Obviously I don't know the specifics of your particular health issues and what is/is not feasible, but I encourage you to consider alternative input mechanisms -- differently shaped keyboards, chorded keyboards, foot keyboards, etc. This TED talk even demonstrates a workable speech recognition system for programming.
|
|
#
?
Mar 2, 2017 18:12
|
|
|
Merges at an old company used to be 2 week affairs with critical personnel moved into the same conference room for the majority of it. The most advanced tooling was tkdiff. The first time I saw an interactive git rebase I held back tears.
|
|
#
?
Mar 2, 2017 18:13
|
|
|
JawnV6 posted:Merges at an old company used to be 2 week affairs with critical personnel moved into the same conference room for the majority of it. The most advanced tooling was tkdiff. Holy gently caress I never expected to hear a worse merge story than mine
|
|
#
?
Mar 2, 2017 18:23
|
|
The Laplace Demon posted:What do you want to do with it? Find projects like that (e.g. on GitHub), download, read through, work on issues, add tests, etc. My cousin is learning to code. His schoolinf uses C#. I want to be able to talk to him about it and help him, but my advice will be bad unless I understand C# structure and preferred idioms. I want to help him write good C#, not bad Python.
|
|
|
#
?
Mar 2, 2017 19:32
|
|
|
TooMuchAbstraction posted:But yeah, the only way to avoid merge conflicts is to communicate across the team so people know when other people want to work on the same files. Munkeymon posted:Yeah, they should have exchanged work items after finding out during a standup that they were overhauling the same file. pokeyman posted:In addition to the correct suggestions you've received so far: it can help to have relatively small commits. Keep them logical, atomic, etc. of course but several smaller might merge easier than one big. JawnV6 posted:Merges at an old company used to be 2 week affairs with critical personnel moved into the same conference room for the majority of it. The most advanced tooling was tkdiff. The other option is to have a file checkout system that only allows one person at a time to modify any given file.
|
|
#
?
Mar 3, 2017 03:46
|
|
|
Peristalsis posted:The other option is to have a file checkout system that only allows one person at a time to modify any given file. In other words, you want to remove all parallel development. That's worse that SVN was! At least there you were allowed to make modifications to your local copy of the code! Or am I misunderstanding somehow and you're suggesting something that isn't completely ruinous to any setup more complicated than "one dev, one project"?
|
|
#
?
Mar 3, 2017 04:59
|
|
|
Pollyanna posted:Is there some kinda special trick to dealing with merge conflicts? I made a bunch of changes to the markup for one of our apps, but my coworker had a ticket to do major markup changes as well and merged it in before mine. Now my stuff conflicts with hers. Is there a way to head off conflicts like these, or are they unavoidable? I don't know why this isn't the default but first of all, git config --global merge.conflictstyle diff3 I've seen so many coworkers complain about bad merge conflicts where you just have to go through it in detail and fix it and it takes me like 30 minutes. If the changes are completely conceptually disruptive rather than just forcing you to reapply relatively similar changes then things might be different, of course.
|
|
#
?
Mar 3, 2017 05:05
|
|
|
Eela6 posted:My cousin is learning to code. His schoolinf uses C#. I want to be able to talk to him about it and help him, but my advice will be bad unless I understand C# structure and preferred idioms. I want to help him write good C#, not bad Python. I already know Java but I like the banana book, I think that got recommended here. Feels concise! I think a lot of being good at C# is being real familiar with the .NET library in general though
|
|
#
?
Mar 3, 2017 06:01
|
|
|
Peristalsis posted:The other option is to have a file checkout system that only allows one person at a time to modify any given file. This is where I prove I'm becoming a greybeard by mentioning my time developing with Microsoft's Visual Source Safe. Back in my day, we had to yell over to the next office to tell our coworkers to stop checking out files that I needed to work on right now.
|
|
#
?
Mar 3, 2017 14:53
|
|
|
TooMuchAbstraction posted:In other words, you want to remove all parallel development. That's worse that SVN was! At least there you were allowed to make modifications to your local copy of the code! Or am I misunderstanding somehow and you're suggesting something that isn't completely ruinous to any setup more complicated than "one dev, one project"?  Usually one project consists of multiple files.Back in my Perforce days it would let multiple people edit the same file, but would emit a warning when you opened the file for edit.
|
|
#
?
Mar 3, 2017 15:06
|
|
|
B-Nasty posted:This is where I prove I'm becoming a greybeard by mentioning my time developing with Microsoft's Visual Source Safe. Back in my day, we had to yell over to the next office to tell our coworkers to stop checking out files that I needed to work on right now. At my first job, we had no SCM  At my second job, we had a in-house hand-rolled SCM / build system  At my third job, they'd just transitioned from VSS to TFS and I had had no experience with either. Every time I had to fix a bug in the VSS repo I ended up exclusive locking the entire source tree because I didn't know any better (and VSS makes that really easy). Those inter-office yells were directed at me a lot 
|
|
#
?
Mar 3, 2017 15:07
|
|
|
ToxicFrog posted:
Allowing two or more people to both add a couple lines to a configuration file, for example, is pretty important and, if your team can't figure out how to talk to each other about what they're working on, that means your team/process is broken, not that you need source control to restrict behavior. e: I actually didn't know that Perforce could be set to allow multiple people to edit the same file - it's less bad than I thought!
|
|
#
?
Mar 3, 2017 15:23
|
|
|
At my current job, checking a file in means pushing it to the test server  Fortunately we're being forced by those on high to convert to git, but my boss thinks this is a step backwards and everything is fine
|
|
#
?
Mar 3, 2017 15:24
|
|
|
Our custom source control says "copyright 1994" in the about box. It works about how you'd expect SCM circa 1994 would.
|
|
#
?
Mar 3, 2017 15:29
|
|
|
When I had to work on a project that used VSS I ended up just using a working directory not tracked by it and then just copying the files over when it came time to commit.
|
|
#
?
Mar 4, 2017 00:10
|
|
|
Structured JSON logging with ELK. Yay or nay or any opinions? Going to get serious now about setting up ELK for my app running on Heroku which currently outputs logs in JSON, but it's basically a flip of a switch to convert it to regular logs. There doesn't seem to be a ton of info with regards to ELK and JSON logging...
|
|
#
?
Mar 5, 2017 17:27
|
|
|
Thermopyle posted:Structured JSON logging with ELK. Yay or nay or any opinions? We do it where I'm at for peak of 300k lines / sec with 8 hour retention. Not doing json was double the number of logstash servers from what I remember. You are basically trading a bit of CPU on all the log generation machines for a lot on the logstash server
|
|
#
?
Mar 5, 2017 18:20
|
|
|
For fun, I'm working on implementing the rules of the puzzle game The Witness. If I have a grid comprised of squares, and one or more vertice to vertice paths that partition the grid, how do I best detect the partitions?  EG, in this example there are four partitions. I am okay with a list of positions, but I have a feeling a spare matrix for each partition would work well. This feels like a graph theory problem to me. I've made a cursory look through the big blue book of algorithms and my old combinatorics books but nothing's jumping out at me. Eela6 fucked around with this message at 00:02 on Mar 6, 2017 |
|
|
#
?
Mar 5, 2017 23:58
|
|
|
The grids are never too large so I'd go for something simple like: Set a counter to the total number of tiles (width * height). Perform a basic flood fill starting at the top left tile, checking tile propagation across edges against the path segments. Decrement the tile counter for each tile filled/visited. When the flood fill stops, you've produced a distinct partition (probably storing the partition data in multiple different topological structures - grid, connectivity graph, whatever - to aid the solution checking process). If the tile counter is non-zero then begin a new partition flood fill at the first non-filled tile. If the counter is zero then you've finished.
|
|
#
?
Mar 6, 2017 00:09
|
|
|
That seems like it will work just fine. Thanks!
|
|
|
#
?
Mar 6, 2017 00:12
|
|
|
This is a graph search problem. Make a vertex for each square, add edges between neighbors, and then remove the edges on the path. After that you just have to find the connected components.
|
|
#
?
Mar 6, 2017 02:44
|
|
|
TooMuchAbstraction posted:In other words, you want to remove all parallel development. That's worse that SVN was! At least there you were allowed to make modifications to your local copy of the code! Or am I misunderstanding somehow and you're suggesting something that isn't completely ruinous to any setup more complicated than "one dev, one project"? No, I'm suggesting that one person finish (and commit) their changes to a single file before another person starts theirs. If your project comprises a few, huge files, this approach probably won't work. Also, I liked SVN a lot more than I like git. I know that git allows all kinds of workflows and repository structures, but every project I've worked on that used git (which is all of them at this point), just ended up approximating SVN's basic model - one master branch that everyone eventually merges into. I guess git's easy branching can be nice, but it hardly seems worth the price to be paid in increased complexity. Munkeymon posted:Allowing two or more people to both add a couple lines to a configuration file, for example, is pretty important and, if your team can't figure out how to talk to each other about what they're working on, that means your team/process is broken, not that you need source control to restrict behavior. If they're losing substantial time and effort on fixing merge requests, their process is already broken, and it's possible that a file-checkout approach will, at least, be less broken. If two people each need to add a couple of lines to a config file, one ought to be able to get that done pretty quickly, and commit it for the other to start on without too much drama. I don't understand your comment about source control restricting behavior. That's kind of what source control is there for - to restrict behavior within a framework that allows multiple people to contribute to a single project without unduly interfering with each other. If one of those restrictions needs to be checking files out before using them, that's no less reasonable or valid than any other part of the source control framework. It can be especially difficult to avoid stepping on each others' toes if a project is new, or your team is large and/or geographically dispersed, and you can't just holler over to the guy in the next row to make sure he isn't changing the same part of the same file that you are. The point is to find the workflow that best helps your team get work done, not to do everything informally to prove your team isn't broken.
|
|
#
?
Mar 6, 2017 04:45
|
|
|
How well do you think your paradigm holds up when applied to a project with hundreds of developers?
|
|
#
?
Mar 6, 2017 04:51
|
|
|
Jabor posted:How well do you think your paradigm holds up when applied to a project with hundreds of developers? If you're talking about checking out files, I believe that was the paradigm used at the one job I had with hundreds of developers, at least for the client code. It certainly isn't perfect - I sometimes got calls from other developers who wanted some file I had checked out, and who would try to talk me into sliding their changes into my project rather than waiting for me to finish and release it, but I've yet to see any code-sharing paradigm that is perfect. In the particular post that started this discussion, a developer was complaining that merge conflicts were getting out of hand for their team, and file checkout is one way to prevent a lot of them. Peristalsis fucked around with this message at 05:10 on Mar 6, 2017 |
|
#
?
Mar 6, 2017 05:01
|
|
|
Peristalsis posted:No, I'm suggesting that one person finish (and commit) their changes to a single file before another person starts theirs. If your project comprises a few, huge files, this approach probably won't work. Also, I liked SVN a lot more than I like git. I know that git allows all kinds of workflows and repository structures, but every project I've worked on that used git (which is all of them at this point), just ended up approximating SVN's basic model - one master branch that everyone eventually merges into. I guess git's easy branching can be nice, but it hardly seems worth the price to be paid in increased complexity. The biggest win of git isn't easy branching, though that is pretty awesome. It's that everyone has their own local repository, enabling "commit early, commit often" without loving with other peoples' copies of the code. Which means that if I'm working on a feature, I can check in broken code, check in fixes to code, revert bad changes, etc. all on my local copy and then, when I'm finally done, just check in a single clean commit to the master repo. This is revolutionary for developer workflows -- it gives people the confidence to tackle large projects without forcing them to keep weeks of uncommitted code sitting around on their dev computer, manually reverting things that didn't work out, accidentally reverting files and having to rewrite a long list of changes, and so on. As far as checking out files is concerned -- if you happen to need to modify a file that someone else is also working on, you can either a) wait for them to finish, or b) buckle up and do the merge. Usually merge conflicts are seriously not that big a deal; you ought to be able to resolve most of them in under half an hour. That's almost certainly better than not being able to work on the file until the other guy is done. For those situations where merge conflicts are a big deal, well, that's what communication inside your team is for.
|
|
#
?
Mar 6, 2017 05:07
|
|
|
TooMuchAbstraction posted:The biggest win of git isn't easy branching, though that is pretty awesome. It's that everyone has their own local repository, enabling "commit early, commit often" without loving with other peoples' copies of the code. Which means that if I'm working on a feature, I can check in broken code, check in fixes to code, revert bad changes, etc. all on my local copy and then, when I'm finally done, just check in a single clean commit to the master repo. This is revolutionary for developer workflows -- it gives people the confidence to tackle large projects without forcing them to keep weeks of uncommitted code sitting around on their dev computer, manually reverting things that didn't work out, accidentally reverting files and having to rewrite a long list of changes, and so on. I'm glad it's been revolutionary for you, but it hasn't made as big a difference in my work. Committing locally just hasn't had much impact on my life. If my hard drive crashes, I still lose my changes, even though I've "committed" them locally. I can certainly push my feature branches to remote servers, but then that's not really fundamentally different than if I had just created a new branch to work on in, say, SVN. Maybe git makes this easier than SVN, but that seems more evolutionary than revolutionary. And again, that benefit comes with drawbacks that seldom get mentioned. Admittedly, part of my problems is that I haven't made time to learn git particularly well. Maybe if I drank enough of the kool-aid, I'd become a true believer. But I just want a place to stash and merge my code, not to become an expert at some tedious, peripheral technology. I'd much rather spend my professional development time learning more about programming languages and platforms than learning more about git. I enjoy programming; source control is just something I have to do to enable my work in a professional environment. TooMuchAbstraction posted:As far as checking out files is concerned -- if you happen to need to modify a file that someone else is also working on, you can either a) wait for them to finish, or b) buckle up and do the merge. Usually merge conflicts are seriously not that big a deal; you ought to be able to resolve most of them in under half an hour. That's almost certainly better than not being able to work on the file until the other guy is done. For those situations where merge conflicts are a big deal, well, that's what communication inside your team is for. The question was from someone trying to avoid option b. It's perfectly valid to argue that they shouldn't be doing that, but it's also valid to offer suggestions on how they might accomplish what they want. Whether you like it or not, there are sometimes merge conflicts that are nasty or convoluted to resolve. If that happens a lot for a team, the drawbacks of file locking (which can be mitigated just like the drawbacks of unregulated parallel development can be mitigated) might not seem so bad.
|
|
#
?
Mar 6, 2017 05:35
|
|
|
Another upside: you can work entirely offline if your internet dies or you're on a laptop on a train or etc and still commit things. Hard drive dying isn't really an issue at all since you shouldn't have more than a day or two of commits around locally, but you should probably have more than one commit per day. I make a habit to push and pull at the end of each day, and if my changes are longform and need multiple days work, start a new branch for them.
|
|
#
?
Mar 6, 2017 12:44
|
|
|
|
| # ? May 31, 2024 01:47 |
|
|
Peristalsis posted:If they're losing substantial time and effort on fixing merge requests, their process is already broken, and it's possible that a file-checkout approach will, at least, be less broken. If two people each need to add a couple of lines to a config file, one ought to be able to get that done pretty quickly, and commit it for the other to start on without too much drama. You're right: something about their process is broken. I just assume that using locking source control will just lead to a time being wasted as people wait on each other. No, people can't just hand off single files. If you're not committing fully-functional features to the main branch at a time, you're not going to be able to do CI or automated testing - just because you picked a bad source control tool to try to work around deeper problems. I would spend all my time updating my resume and job hunting if I found myself on that sort of team. quote:I don't understand your comment about source control restricting behavior. That's kind of what source control is there for - to restrict behavior within a framework that allows multiple people to contribute to a single project without unduly interfering with each other. If one of those restrictions needs to be checking files out before using them, that's no less reasonable or valid than any other part of the source control framework. It can be especially difficult to avoid stepping on each others' toes if a project is new, or your team is large and/or geographically dispersed, and you can't just holler over to the guy in the next row to make sure he isn't changing the same part of the same file that you are. The point is to find the workflow that best helps your team get work done, not to do everything informally to prove your team isn't broken. One quibble: you establish a workflow external to source control to do that, so having a flexible source control system is important or else you can't handle some scenarios that might be important for your team/situation. Other than that, yeah, it can be hard to avoid stepping on each others' toes, but the way to fix that is with communication because, as I said above, throwing out feature-complete commits to get around restrictive source control means going without other, very important tools.
|
|
#
?
Mar 6, 2017 15:14
|
|