|
homercles posted:anything in java seem to get stricken with massive bloat OH GOD, NOT TESTS
|
#
?
Jul 23, 2012 07:52
|
|
|
|
| # ? May 8, 2024 23:41 |
|
|
if only tests didn't run when you deployed and ran applications
|
|
#
?
Jul 23, 2012 08:00
|
|
|
my real problem here is the test bloat. there are far too many for my liking. i want my tests savagely optimized for maximal coverage and minimal bloat. my disk is not some limitless playground for lazy programmers.
|
|
#
?
Jul 23, 2012 08:02
|
|
|
Is Lisp the language that's all about data comparisons, or is that Prolog?
|
|
#
?
Jul 23, 2012 08:03
|
|
|
you're thinking of OCaml
|
|
#
?
Jul 23, 2012 08:03
|
|
|
APL
|
|
#
?
Jul 23, 2012 08:07
|
|
|
J
|
|
#
?
Jul 23, 2012 10:54
|
|
|
i think that outside of node, J is the best language out there. Just like lovely P languages, you have amazing J languages. J for analysis, Java for your web framework, Javascript for your frontend.
|
|
#
?
Jul 23, 2012 10:55
|
|
|
Jython
|
|
#
?
Jul 23, 2012 11:11
|
|
|
multigl posted:I'm loving sentry and raven for python. how did i not know about this 
|
|
#
?
Jul 23, 2012 11:41
|
|
|
rotor posted:no i mean like as soon as the bare bones is there quick time to move on to something else, we'll patch that ugly poo poo later (the ugly poo poo never gets patched) "agile"
|
|
#
?
Jul 23, 2012 12:12
|
|
|
tef posted:(and the whole 10x productivity thing is bunk too)
|
|
#
?
Jul 23, 2012 13:20
|
|
|
rotor posted:my real problem here is the test bloat. there are far too many for my liking. i want my tests savagely optimized for maximal coverage and minimal bloat. my disk is not some limitless playground for lazy programmers. I agree and don't at once. Test bloat is a necessity when you have feature bloat or a poo poo ton of business rules. Tests will have to reflect the state of your software to some extent. If you're working on a complex thing with so many rules they're hard to keep track of, I can't expect your tests not to cover a few of them. I also see it as necessary when doing system testing. Then you have test bloat because many tests cover the same code path a few times -- I can see this being somewhat useful when you test starting from the interface/API (read: never test private methods). Those are mostly useful in TDD scenarios where your tests reflect your spec and do not care about the implementation nearly as much as they care about your code's behaviour. IMO, these tests tend to require very little refactoring unless the app's rule changes at the same time. They'll be more bloated from a setup/teardown perspective, but they're generally easy to reuse. Then you have test bloat, yet again for similar-branch-coverage, but due to input/output corner cases. How does your string parser handle invalid input, specific errors, cases that should succeed only in some cases, counter-examples, and so on. Those are lovely and painful to maintain. This last case is the place where you want newer ideas like property-based testing, some kind of derivative from fuzzy testing. You define properties of your program (a min-heap will always have the root of each sub-tree smaller or equal to all of its children, for example), then ways to build the data required to test your program. The property-based testing tool will then generate thousands of different items respecting the rules you established and pit them against your implementation to figure out if the property still holds. The biggest problem I think I see with tests is that people tend to write them after the fact; then they don't so much represent a test of the original requirements, but a crystallization of the current, likely lovely, implementation. Any attempt to improve the lovely implementation means you have to get tangled with the tests that froze it that way, and there's no fun way to do it. Tests (often written before the fact) that represent some higher-level spec of what the code ought to do tend to be fun to reuse, and be a godsend to refactoring and rewrites.
|
|
#
?
Jul 23, 2012 14:07
|
|
|
i want to learn how to run tests like a motherfucker and get the general ideas but they just havent clicked for me yet
|
|
#
?
Jul 23, 2012 14:12
|
|
|
workplaces that implement methodologies and business processes as a blanket solution to cut dev time and save money rather than try to improve in general are bound to be disappointed. Nobody gives a poo poo about new systems, it'll be ignored it and devs will keep doing whatever they were doing before. Somehow focusing on your people and trying to make their work environment better suited to their needs appears to be more efficient than telling them how to their job. http://alistair.cockburn.us/Characterizing+people+as+non-linear%2c+first-order+components+in+software+development
|
|
#
?
Jul 23, 2012 14:17
|
|
|
lol you said cockburn
|
|
#
?
Jul 23, 2012 14:22
|
|
|
Jonny 290 posted:i want to learn how to run tests like a motherfucker and get the general ideas but they just havent clicked for me yet Three types of code: 1. Throwaway prototype. You're discovering what your application should do. Don't test that poo poo; if you don't know what things should do, it's dumb to crystallize the discovery phase. At some point the prototype you wrote for whatever subsystem you had gave you the properties you wanted. You now understand the problem. If you don't understand your problem and how it should work, you haven't explored it enough and it's bound to turn into poo poo. 2. Production code. You know what code should do and have an idea how it should do it (I hate the Beck-like TDD where you explore with tests. That poo poo sucks). The tests become a spec for you to implement and respect. That's why you want to write test first -- they now force you to think as the user of the code and not give a poo poo about how you have to implement it. That should hopefully give cleaner, consistent interfaces, and force you to avoid all kinds of lovely "maybe this will be needed!" kinds of code. 3. Prototypes that make it to production. I figure this is likely due to tight deadlines. I'm generally a pretty slow programmer, and tend to leave a paper/email trail of my telling people stuff will be late if I need to prototype things. Then my hands are somewhat clean and everyone knew I'd be late. Sometimes you just can't avoid it, though. Production is the prototype, and you have to try and sneak in refactoring in the future or do it commando-style. The rewrite becomes production stuff. Sometimes it just never happens and that code becomes the hairball nobody wants to maintain but you're forced to do it, and then you hate yourself. Note that I firmly believe writing tests first is a good idea, for one reason above all: it's boring as gently caress to write tests after the fact, and I'm bound to poo poo them up, make them low quality, and crappy, just to get done. Testing first at least keeps me awake with some interesting design work and makes writing tests slightly less boring.
|
|
#
?
Jul 23, 2012 14:25
|
|
|
junit works fine for me, but my code is also highly modular and each module isnt that big so its nice. also most modules implement common interfaces so the tests are the same across implementations of the same interface. slf4j for logging. not great but whatever. logging sucks.
|
|
#
?
Jul 23, 2012 14:29
|
|
|
MononcQc posted:Three types of code: my development process usually goes 1 -> 3 -> 2 cause half the time they dont know waht they want but they want it now. so something that works but doesnt have good tests and/or has prototype interface methods/models that ended up not being used makes it into production. then i wait for a bit and see what they actually needed and do a big refactor and bug cleanup.
|
|
#
?
Jul 23, 2012 14:33
|
|
|
Shaggar posted:my development process usually goes 1 -> 3 -> 2 cause half the time they dont know waht they want but they want it now. so something that works but doesnt have good tests and/or has prototype interface methods/models that ended up not being used makes it into production. then i wait for a bit and see what they actually needed and do a big refactor and bug cleanup. Yeah, that does happen a lot when the clients don't know what they want. If you're lucky, that doesn't happen too often. Truth be told I'd guess over 95% of all programmer jobs do it 1 -> 3 -> 2 (with 2 being optional). A few lucky ones can do 1 -> 2 and keep it there.
|
|
#
?
Jul 23, 2012 14:35
|
|
|
gently caress clients, gently caress them in the rear end with a big, splintery wooden dildo, then break it off and beat them to death with the rest of it.
|
|
#
?
Jul 23, 2012 14:38
|
|
|
MononcQc posted:Yeah, that does happen a lot when the clients don't know what they want. If you're lucky, that doesn't happen too often. Truth be told I'd guess over 95% of all programmer jobs do it 1 -> 3 -> 2 (with 2 being optional). A few lucky ones can do 1 -> 2 and keep it there. going 1 -> 2 requires good requirements and project management with realistic timelines. if you can get either of those you're pretty lucky, so i think 1->3->2 is most common with 1->3 being the web "development" standard. its one of the reasons i split everything i do into modules and use SOA. smaller chunks of code are easier to test, maintain, or change without affecting the whole. i have a few "larger" projects that i did a while back that are so gross and need to be redone, but it would require a complete overhaul since everything is so tightly coupled. im never gonna get around to it.
|
|
#
?
Jul 23, 2012 14:43
|
|
|
MononcQc posted:Three types of code: I only know two: legacy code and failures
|
|
#
?
Jul 23, 2012 15:20
|
|
|
tef posted:I only know two: legacy code and failures i heard somebody griping about a "legacy node.js project" in may 2011 lol
|
|
#
?
Jul 23, 2012 15:31
|
|
|
tef posted:I only know two: legacy code and failures supersets/subsets, eh.
|
|
#
?
Jul 23, 2012 15:43
|
|
|
no true rest api
|
|
#
?
Jul 23, 2012 15:54
|
|
|
Panic! At The cisco posted:no true rest api if you meet roy t fielding in the road, kill him
|
|
#
?
Jul 23, 2012 16:05
|
|
|
tef posted:if you meet roy t fielding in the road, kill him He describes himself as "...part Maori, Kiwi, Yank, Irish, Scottish, British, and California beach bum..."
|
|
#
?
Jul 23, 2012 16:08
|
|
|
i hate him for that, but is rest bad or something?
|
|
#
?
Jul 23, 2012 16:10
|
|
|
oh it's terrible
|
|
#
?
Jul 23, 2012 16:19
|
|
|
tef posted:oh it's terrible true for everything about computers at all times
|
|
#
?
Jul 23, 2012 16:47
|
|
|
tinselt0wn posted:i hate him for that, but is rest bad or something? the worst
|
|
#
?
Jul 23, 2012 16:51
|
|
|
tinselt0wn posted:i hate him for that, but is rest bad or something? Shaggar posted:the worst
|
|
#
?
Jul 23, 2012 16:54
|
|
|
Stringent posted:gently caress clients, gently caress them in the rear end with a big, splintery wooden dildo, then break it off and beat them to death with the rest of it. i hear rakuten's nice although rumour has it you need a good TOEIC score these days. ganbatte.
|
|
#
?
Jul 23, 2012 17:12
|
|
|
qntm posted:"agile"
|
|
#
?
Jul 23, 2012 17:38
|
|
|
srsly death to all methodology gurus
|
|
#
?
Jul 23, 2012 17:41
|
|
|
out of curiosity what's agile like in practice? I see numerous job posts with "agile experience a plus," and I'm familiar with what agile's like in theory but what does it actually turn in to?
|
|
#
?
Jul 23, 2012 18:54
|
|
|
a mess
|
|
#
?
Jul 23, 2012 18:55
|
|
|
Pendragon posted:out of curiosity what's agile like in practice? I see numerous job posts with "agile experience a plus," and I'm familiar with what agile's like in theory but what does it actually turn in to? if you've got discipline it works pretty sustainably a friend of mine worked at a firm that used it with a big rails site for about five years just fine
|
|
#
?
Jul 23, 2012 19:01
|
|
|
|
| # ? May 8, 2024 23:41 |
|
|
Pendragon posted:out of curiosity what's agile like in practice? I see numerous job posts with "agile experience a plus," and I'm familiar with what agile's like in theory but what does it actually turn in to?
|
|
#
?
Jul 23, 2012 19:04
|
|