|
jesus fuckling christ rename this source control management megathread and stick it in the comics forum or branch it off hurr hurr
Seaside Loafer fucked around with this message at 06:35 on Jan 18, 2015 |
#
?
Jan 18, 2015 06:32
|
|
|
|
| # ? May 9, 2024 23:59 |
|
|
Seaside Loafer posted:jesus fuckling christ rename this source control management megathread and stick it in the comics forum or branch it off hurr hurr sorry, is the talking about source control in the programming thread bothering you? we have cat threads and current job status threads, perhaps you'd be more interested in those.
|
|
#
?
Jan 18, 2015 06:39
|
|
|
svn is fine it will at least not lose your source code or corrupt its own database
|
|
#
?
Jan 18, 2015 06:39
|
|
|
I remember someone in yospos irc coming in and was like "I accidentally deleted my local git repo, I haven't pushed for a week" the other cool thing about git is that it assumed all dev boxes are backed up, because people tend to sit on changes before they push, because they have to craft their commits to tell a software story or some poo poo
|
|
#
?
Jan 18, 2015 06:43
|
|
|
rotor posted:the other cool thing about git is that it assumed all dev boxes are backed up, because people tend to sit on changes before they push, because they have to craft their commits to tell a software story or some poo poo a coworker got burned by this last week when his dev vm poo poo the bed lol
|
|
#
?
Jan 18, 2015 06:54
|
|
|
rotor posted:sorry, is the talking about source control in the programming thread bothering you?
|
|
#
?
Jan 18, 2015 06:55
|
|
|
Seaside Loafer posted:yes its very very boring and isnt about about programming and has been going on for endless pages it is about programming though
|
|
#
?
Jan 18, 2015 06:56
|
|
|
rotor posted:it is about programming though
|
|
#
?
Jan 18, 2015 07:08
|
|
|
Seaside Loafer posted:well it isnt is it, its about source control managment which are not the same things they're related topics and as such are Just Fine for discussion
|
|
#
?
Jan 18, 2015 07:09
|
|
|
rotor posted:I remember someone in yospos irc coming in and was like "I accidentally deleted my local git repo, I haven't pushed for a week" it's almost as if workflow is more important than the tool
|
|
#
?
Jan 18, 2015 07:13
|
|
|
whatever floats your boat man but I would suggest some actual programming natter would be much more interesting than endless repitition of source control method a is better than source control method b
|
|
#
?
Jan 18, 2015 07:17
|
|
|
Seaside Loafer posted:whatever floats your boat man but I would suggest some actual programming natter would be much more interesting than endless repitition of source control method a is better than source control method b Okay, spaces or tabs?
|
|
#
?
Jan 18, 2015 07:18
|
|
|
Seaside Loafer posted:whatever floats your boat man but I would suggest some actual programming natter would be much more interesting than endless repitition of source control method a is better than source control method b don't let me stop you, go ahead and talk about programming.
|
|
#
?
Jan 18, 2015 07:19
|
|
|
rotor posted:don't let me stop you, go ahead and talk about programming.
|
|
#
?
Jan 18, 2015 07:22
|
|
|
Seaside Loafer posted:I suggested a topic a few pages back in an attempt to divert, whats your response to it? Id be interested. lol
|
|
#
?
Jan 18, 2015 07:24
|
|
|
Seaside Loafer posted:I suggested a topic a few pages back in an attempt to divert, whats your response to it? Id be interested. a miserable little pile of secrets lol
|
|
#
?
Jan 18, 2015 07:26
|
|
|
Seaside Loafer posted:I suggested a topic a few pages back in an attempt to divert, whats your response to it? Id be interested. imho animal-to-computer UI is coming up
|
|
#
?
Jan 18, 2015 07:31
|
|
|
Seaside Loafer posted:I suggested a topic a few pages back in an attempt to divert, whats your response to it? Id be interested. my response is "shut the gently caress up and stop bothering me"
|
|
#
?
Jan 18, 2015 07:35
|
|
|
we've covered source control so I guess the next thing terrible programmers usually talk about is booze. I generally like wine but I'll do beer or nihonshu occasionally.
|
|
#
?
Jan 18, 2015 07:41
|
|
|
vodka or dry gin
|
|
#
?
Jan 18, 2015 08:22
|
|
|
Stringent posted:we've covered source control so I guess the next thing terrible programmers usually talk about is booze. git ui makes more sense if you are loving plastered I like dvcs but I do not understand how git came out the winner
|
|
#
?
Jan 18, 2015 08:25
|
|
|
Notorious b.s.d. posted:git ui makes more sense if you are loving plastered everyone tells me hg is good. I dont really have a thing against dvcs, but i sure do have a thing against git
|
|
#
?
Jan 18, 2015 08:28
|
|
|
Notorious b.s.d. posted:git ui makes more sense if you are loving plastered git's ui is bad but everything else is slow as gently caress
|
|
#
?
Jan 18, 2015 08:55
|
|
|
i don't care about your source control but i do care about your vodka and gin, please post more about those
|
|
#
?
Jan 18, 2015 09:13
|
|
|
Notorious b.s.d. posted:I like dvcs but I do not understand how git came out the winner linus worship
|
|
#
?
Jan 18, 2015 09:29
|
|
|
Stringent posted:we've covered source control so I guess the next thing terrible programmers usually talk about is booze. what the heck is nihonshu? i bet its not as good as scotch or beer though
|
|
#
?
Jan 18, 2015 09:34
|
|
|
Notorious b.s.d. posted:git ui makes more sense if you are loving plastered it's true
|
|
#
?
Jan 18, 2015 10:06
|
|
|
i have a terrible programmer question: how do you do dependency injection right? i get the concept and how it makes unit testing easier, but on the projects i've worked on it always ends up with at least one of two problems: - all your code ends up unnecessarily tied to a specific injection container - your outermost layer ends up being a gigantic mess of instantiating and connecting every object in the program, maybe in xml for good measure like 90% of the time we don't have any alternative implementations and only want to switch it out for our unit tests, so it doesn't feel right to just pass it up until your main code has to care about a helper class to a helper class to a helper class, but that's the logical conclusion from the introductory texts i've read
|
|
#
?
Jan 18, 2015 10:13
|
|
|
suffix posted:i have a terrible programmer question: how do you do dependency injection right? hmm, i dont know. sorry.
|
|
#
?
Jan 18, 2015 10:26
|
|
|
suffix posted:i have a terrible programmer question: how do you do dependency injection right? Lol OO
|
|
#
?
Jan 18, 2015 10:48
|
|
|
i don't even know how you'd test an io thing in haskell
|
|
#
?
Jan 18, 2015 11:16
|
|
|
suffix posted:i don't even know how you'd test an io thing in haskell Same as how you test anything else: the quickcheck library. I'm on my phone but if somebody could be bothered to paste some examples in this thread I'd be grateful. gonadic io fucked around with this message at 12:13 on Jan 18, 2015 |
|
#
?
Jan 18, 2015 11:20
|
|
|
suffix posted:i have a terrible programmer question: how do you do dependency injection right? Guice (and presumably other "magical" DI frameworks, though Guice is the only one I'm familiar with) are really cool when you have the discipline to avoid shooting yourself in the foot with them. They make it really easy to shoot yourself in the foot, but if you can avoid that they're all good. Basic rules are to avoid everything "clever" that the framework lets you do, only inject concrete classes, avoid scopes except for maybe singletons, don't use annotated injections to get multiple different things of the same type. Then it's basically just a way to instantiate objects without needing to know what their dependencies are (which is the whole point of a DI container rather than doing manual DI), while still being able to bind everything to mock instances etc. in your tests. Once you've wrapped your head around it enough to avoid making write-only spaghetti code, you can identify situations where a "clever" feature makes something less painful and won't make you regret it when you have to debug things later. If you're doing it right then the only code that's actually tied to a specific injection container is the top-level stuff that configures bindings (which you won't have many of if you follow the basic rule and only inject concrete classes) and requests an instance of whatever object is the root of your object graph. Everything else just has an annotation that says it should be DIed and wouldn't need any changes if you switched to a different container for whatever reason.
|
|
#
?
Jan 18, 2015 11:55
|
|
|
suffix posted:i have a terrible programmer question: how do you do dependency injection right? Get The Art of Unit Testing, and use the most "I can't believe I didn't think of this"-thing which is use inheritance and make TestableFoo which overrides a stuff like GetDate(). Or you could use a DI-framework that maps stuff according to conventions
|
|
#
?
Jan 18, 2015 13:34
|
|
|
Jabor posted:Guice (and presumably other "magical" DI frameworks, though Guice is the only one I'm familiar with) are really cool when you have the discipline to avoid shooting yourself in the foot with them. They make it really easy to shoot yourself in the foot, but if you can avoid that they're all good. to me this kinda sounds like 'don't do DI'. mainly because you can make any unwieldy thing work with discipline see also gonadic io posted:Lol OO
|
|
#
?
Jan 18, 2015 14:09
|
|
|
gonadic io posted:Lol OO
|
|
#
?
Jan 18, 2015 14:36
|
|
|
gonadic io posted:Same as how you test anything else: the quickcheck library. I'm on my phone but if somebody could be bothered to paste some examples in this thread I'd be grateful. The quickcheck library wouldn't be much help unless you can figure out a property of your IO system you want to see, or find an alternative function (a model) to compare your implementation to. Otherwise you'll be generating random-but-guided data and test cases, but you have no guarantee that your tests are relevant in any way.
|
|
#
?
Jan 18, 2015 15:13
|
|
|
rotor posted:they're related topics and as such are Just Fine for discussion yes. Seaside Loafer posted:well it isnt is it, its about source control managment which are not the same things why can't you all talk about something more interesting to me?
|
|
#
?
Jan 18, 2015 17:42
|
|
|
quote:i get the concept and how it makes unit testing easier, but on the projects i've worked on it always ends up with at least one of two problems: what you should be aiming for is not good di, but explicit state and loose coupling. these do not come from using di, but a di framework makes them easier to do. you can skip the xml/injectors, and just make the plumbing explicit sometimes. it doesn't hurt to pass in the dependencies by hand some times. you may find that you do not need that much di to get a benefit from it, but the interfaces between components matter much more than how you assemble them. suffix posted:i have a terrible programmer question: how do you do dependency injection right? how to do di right is not a good question, as the answer is: *it depends*. large projects obviously benefit, small ones don't. much of the advice depends on the famework, language, and platform. when to do di, and where to do di are better questions, although the answers are still kinda handwavey. when and where is easier if your codebase is layered. i tend to go for something vaguely like this libraries -- modules -- components -- frameworks libraries at the bottom are just utilities, often wrappers around third party or platform apis. very little internal state and very little dependencies. modules atop add policy and workflow, like how requests is built atop urllib3. this is sorta where you put logic around the simpler parts, and glue bits together to make a useable api for common tasks. these two are generally where the reusable parts of a project live. a component is where the business logic in an application or service lives, and the framework is the thin layer of glue that holds these components together. business logic, although finely interwoven, is not necessarily a gordian knot for you to cut into components. if you can’t replace a component easily, it might not be worth splitting out in the first place — it isn’t hiding enough from the rest of the system. instead of asking how do i do good DI, we're asking: how do i decompose an application into components, how should they depend on each other, and what the interfaces between them should be. now you have three problems, etc. on decomposition, to rephrase D. Parnas’ excellent advice: A component exists to hide a hard decision from other components in the system, or to hide a decision likely to change. similarly, part of the layering above is to hide things: components hide business logic from each other, modules should hide implementation, libraries should hide workflow, and the framework should hide all the wires holding it all together. on dependencies: libraries shouldn't have many, and explicitly passed each time. modules can depend on libraries, and so on. as for designing the interfaces: well that's just hard, good luck bub. once you've split your code up like this it's easier to see where di should go, and when it should happen: in the framework and components. the libraries and modules can probably make do with plain old explicit dependencies. this also answers the question: how much di should I do—enough to glue the larger components in your system together. quote:it doesn't feel right to just pass it up until your main code has to care about a helper class to a helper class to a helper class, but that's the logical conclusion from the introductory texts i've read you have come to a world called car extends vehicle *whipcrack*. the introductory texts are usually a toy example wired to show off the library or technique. the problem with our introductory texts is that they are full of examples no-one should follow.
|
|
#
?
Jan 18, 2015 18:21
|
|
|
|
| # ? May 9, 2024 23:59 |
|
|
on the other hand if you're just using it for unit testing there is probably some classloader hack that will fix this for you.
|
|
#
?
Jan 18, 2015 18:22
|
|