|
Finster Dexter posted:So, is Maven a package manager and also handles the build process? How does it handle things better than Nuget? pretty much yeah, NuGet is Microsoft's lovely ripoff of Maven afaict
|
#
?
Sep 23, 2016 18:11
|
|
|
|
| # ? Jun 1, 2024 05:34 |
|
|
Finster Dexter posted:So, is Maven a package manager and also handles the build process? How does it handle things better than Nuget? i've never used nuget but i liked it better than any of the perl/python/npm ones that seem to want to gently caress up your system-wide libraries when i had to dick around with solr
|
|
#
?
Sep 23, 2016 18:21
|
|
|
Wheany posted:i follow "ehh, it probably works" driven development same
|
|
#
?
Sep 23, 2016 18:29
|
|
|
fyi the only problem here is you/your team/your org is over-emphasizing intermediate metrics. test coverage is a vaguely okay heuristic but should not be treated as a goal on its own. see also: http://danluu.com/percentile-latency/
|
|
#
?
Sep 23, 2016 18:38
|
|
|
Barnyard Protein posted:we had some contractor code that vacuously wrote unit tests for simple getters and setters like that. i stretched my imagination a bit and could see rationalization for it. if someone were to change the getWeight() implementation to do some conversion rather than return the exact value provided in the constructor, then the test case would catch it. unless that class is part of the public API (which I doubt), gently caress that noise. the point of tests is NOT to detect when something has changed. that's what a diff is for. the point of tests is to detect when something is BROKEN. they exist to protect the design, not the implementation. to use your example, if you add automatic conversion to a dumb getter, but you also remove the now redundant conversions from each call site so that the overall behaviour is unchanged (just with less code duplication), then your tests must not make a loving bleep. if they do, they're not tests, they're useless diffs disguised as tests and should be deleted.
|
|
#
?
Sep 23, 2016 18:39
|
|
|
Finster Dexter posted:So, is Maven a package manager and also handles the build process? How does it handle things better than Nuget? maven is a build tool and part of doing builds is resolving dependencies. in maven you define what your project is and what the output is and what the dependencies are and maven handles the build process to create your output with the given information. your maven project definition does not define any steps to build the project. maven figures that out for you and it can change based on your definitions of what the project is and what outputs you want. Because you are not writing any steps yourself, you never have to debug a build process. If you want to add functionality to maven (ex: deploy a war to tomcat after build) you can add plugins which hook in at different parts of the build. you can also write your own plugins if you need, but I would say 99.99% of needs have already been suited by existing plugins. in MSBuild your csproj defines a set of steps to build the project. Those steps are informed by some other variables lying around, but its still a set of steps. if you want to adjust the build, you adjust the steps. This is the ancient way of doing builds. its how ant and make and all those lovely old build systems do it. procedural builds are very bad because you are basically defining another program that is building your project. this is another set of steps you have to debug and tweak and fix. If you want to reuse those steps you have to drag them from project to project as their own separate dependencies. nuget makes things even worse for a few reasons During a project build in visual studio, there are 2 ways nuget packages can be resolved: 1) Visual Studio runs nuget and puts the resulting packages into your references as if you added them by hand 2) MSBuild runs nuget package restore to bring in packages during the build process. These 2 processes are at complete odds with each other because in the first the dependency resolution is hidden from the build process. MSBuild would have no way of knowing that the packages came from nuget because visual studio did that part. If someone tries to build your project outside of visual studio, like lets say on your tfs build server, poo poo will not work unless you also check in the binaries which is the worst thing in the world. And critically: THIS IS THE DEFAULT NUGET MANAGEMENT MODE IN VISUAL STUDIO. It sucks poo poo. If you forget to change your project to mode 2 before adding any nuget packages, you will end up with binaries in your project that you have to manually exclude from your source control. it sucks. Mode 2 is obviously what you want, but its unknown to most developers because you have to go looking for it. You enable nuget package restore on the project and it tells VS to stop maintaining nuget packages and let MSBuild do it. But still this is not great because nuget sucks at dependency management and also because MSBuild is a procedural build system which sucks. There are a bunch of minor things about nuget that suck, but that's big issue #1 and big issue #2 is that nuget packages can contain powershell scripts that run whenever the package is added to the project. That is absolutely as bad as it sounds. It was designed to make upgrading projects from previous framework versions easier, but because of pain in the rear end nuget issue #3 (cant specify versions/packages when updating packages!!!) what will happen is someone will blindly update an mvc4 project's nuget packages to get an updated version of some other lib (like nlog) but then it will update ALL packages in the project including upgrading mvc4 to mvc5 which will run those upgrade powershells which will make backwards incompatible changes to your msbuild and web.config. Awesome! time to blow out the project and hope my last checkin was recent! With nuget 3 and asp.net/.net core they're moving closer to a declarative project model like in maven. Its not great yet, but its getting there. They've also added UI fixes in visual studio to let you download and update specific packages and versions. It still doesn't default to msbuild nuget package restore mode tho for non .net core projects. Shaggar fucked around with this message at 18:55 on Sep 23, 2016 |
|
#
?
Sep 23, 2016 18:53
|
|
|
maven is so good and I miss it every day.
|
|
#
?
Sep 23, 2016 19:03
|
|
|
Shaggar posted:With nuget 3 and asp.net/.net core they're moving closer to a declarative project model like in maven. Its not great yet, but its getting there. They've also added UI fixes in visual studio to let you download and update specific packages and versions. It still doesn't default to msbuild nuget package restore mode tho for non .net core projects. Well, and while you can specify what version of a package you want to install, you can only specify "lowest" or "highest" in terms of what dependency versions to grab. I've been bitten in both cases. Right now, our projects don't really use anything for package management and we have a bespoke build management system, which isn't bad, but is very opinionated because there is one guy that maintains it and he freaks out when people start talking about things like continuous integration, which is what I've been trying to push for.
|
|
#
?
Sep 23, 2016 19:15
|
|
|
nuget is bad and i had to ream out a team member for clicking Update All in the package manager but really an option that retarded shouldnt exist or be so prominent imo
|
|
#
?
Sep 23, 2016 19:32
|
|
|
Finster Dexter posted:This is Web API? It could be that SSL is not configured for IIS. This article might be helpful: http://www.asp.net/web-api/overview/security/working-with-ssl-in-web-api IIS should be set up correctly. the project did have enable SSL set to false, but swapping that and redeplying still get me a 404 on https and not http
|
|
#
?
Sep 23, 2016 19:32
|
|
|
I love radium
|
|
#
?
Sep 23, 2016 19:34
|
|
|
HoboMan posted:IIS should be set up correctly. the project did have enable SSL set to false, but swapping that and redeplying still get me a 404 on https and not http I accedently deployed my build to live and there's no backups piss
|
|
#
?
Sep 23, 2016 19:49
|
|
|
no wait what i think is wrong isn't actually wrong?? but the app still bombing out???
|
|
#
?
Sep 23, 2016 20:06
|
|
|
gently caress my nuget poo poo is hosed up it what it is. how do i redo this stuff?
|
|
#
?
Sep 23, 2016 20:40
|
|
|
HoboMan posted:fucknugget
|
|
#
?
Sep 23, 2016 20:42
|
|
|
HoboMan posted:gently caress my nuget poo poo is hosed up it what it is. how do i redo this stuff? oh geez... how many nuget packages do you have? can you remove them all and re-add them?
|
|
#
?
Sep 23, 2016 20:50
|
|
|
Finster Dexter posted:oh geez... how many nuget packages do you have? can you remove them all and re-add them? ugggggggggghhhhhhh like 40
|
|
#
?
Sep 23, 2016 20:55
|
|
|
a good place to start is to nuke everything in your packages folder and see what restore packages does
|
|
#
?
Sep 23, 2016 21:05
|
|
|
stop having so many dependencies
|
|
#
?
Sep 23, 2016 21:17
|
|
|
My code is hopelessly co-dependent
|
|
#
?
Sep 23, 2016 21:31
|
|
|
i destroyed everything and added back poo poo until it compiled and it seems to work now. the problem is the app still doesn't.  i'm trying to get monday and tuesday off too, but this being broken is a showstopper. 
|
|
#
?
Sep 23, 2016 21:59
|
|
|
Arcsech posted:find a person who already works for a company you would like to work for and get them to refer you
|
|
#
?
Sep 23, 2016 22:39
|
|
|
Xarn posted:NetBeans is pretty good.
|
|
#
?
Sep 23, 2016 22:46
|
|
|
use Paket instead
|
|
#
?
Sep 23, 2016 23:52
|
|
|
well, the application can now handle more than 8 simultaneous connections per host. it turns out the fact that tomcat was aggressively reapering any application in the pool if it didnt respond for more than 10 seconds (which is normal for this application, fml) was the only thing preventing some horrible out of control cpu eating loop. fortunately, the cpu eating bug dida not occur in a path touched by any of our load tests, so it didnt prevent us from getting into production.
|
|
#
?
Sep 24, 2016 00:17
|
|
|
the second most frustrating thing in programming is a great language with bad tooling. the most frustrating thing in programming is a bad language with great tooling.
|
|
#
?
Sep 24, 2016 02:59
|
|
|
android nuget
|
|
#
?
Sep 24, 2016 03:09
|
|
|
i have a real hard time with tdd because it seems like such a waste of time to write tests for basicc poo poo when the actual basic poo poo would be less lines of code
|
|
#
?
Sep 24, 2016 03:12
|
|
|
Corla Plankun posted:i have a real hard time with tdd because it seems like such a waste of time to write tests for basicc poo poo when the actual basic poo poo would be less lines of code it's just a step designed for you to trip on so a "real" TDD'er can point to that to cluck and blame it for every failure of TDD
|
|
#
?
Sep 24, 2016 03:38
|
|
|
this weekend's project is porting my dos 3D engine's bresenham routine from C to 68k assembly and draw a pentagram on my ST
|
|
#
?
Sep 24, 2016 03:55
|
|
|
Shaggar posted:maven is a build tool and part of doing builds is resolving dependencies. in maven you define what your project is and what the output is and what the dependencies are and maven handles the build process to create your output with the given information. your maven project definition does not define any steps to build the project. maven figures that out for you and it can change based on your definitions of what the project is and what outputs you want. Because you are not writing any steps yourself, you never have to debug a build process. If you want to add functionality to maven (ex: deploy a war to tomcat after build) you can add plugins which hook in at different parts of the build. you can also write your own plugins if you need, but I would say 99.99% of needs have already been suited by existing plugins. this post is 100% true, every word. the worst part is that nuget is a lot better than most of your other options in .net land pre-nuget3/new .net core etc
|
|
#
?
Sep 24, 2016 04:05
|
|
|
yeah shaggar that's a great breakdown. i always heard maven was better but that's the first time i've seen anyone dig into the exact problems with nuget.
|
|
#
?
Sep 24, 2016 04:39
|
|
|
maven owns and lol if you never use it w java
|
|
#
?
Sep 24, 2016 05:39
|
|
|
jynn posted:maven owns and lol if you never use it w java our current project lead insisted on gradle instead, rip he didn't want to use maven because the solution to all maven problems is "copy-paste this 10 line xml snippet you don't understand into your pom", and gradle fixes that by replacing it with "copy-paste this 30 line groovy snippet even its author didn't understand into your build.gradle" gradle is bad, i miss maven
|
|
#
?
Sep 24, 2016 11:01
|
|
|
Luigi Thirty posted:as usual, 1970s ataris have wacky video capabilities that other things of the time couldn't do cool
|
|
#
?
Sep 24, 2016 13:27
|
|
|
pgroce posted:the second most frustrating thing in programming is a great language with bad tooling. bad languages with bad tooling are actually the worst
|
|
#
?
Sep 24, 2016 15:20
|
|
|
Bloody posted:bad languages with bad tooling are actually the worst yeah but they're less likely to show up everywhere making GBS threads up your life. a bad language with good tools is a trojan horse. people will use it for something nonessential and like the tools, then try to use it for something essential for the tools, and before you know it you're writing absurd kludges around fundamental design flaws because someone liked Buttlang's debugger or web framework or whatever. if you're lucky the tooling stays good, but people/companies often lose interest in keeping up stuff like that. meanwhile Buttlang's Eternal Philosopher King or steering committee or whatever will keep on shutting out bad ideas. (usually. java seems like a rare example of a badlang that became not-badlang. otoh, it arguably had a well-designed core that let the language improve over time, and the thing that was most frustrating about it–the performance hit you incur creating and destroying objects, especially at startup–is still with us and will be until the ghost of Bill Joy rises from the grave and beats Larry Ellison in a light saber duel at the end of the universe.) i should probably have said "libraries" or "frameworks" instead of tooling in my lovely dumb joke, they're a worse example of this. otoh, VS gave us the scourge of ASP, so.
|
|
#
?
Sep 24, 2016 15:58
|
|
|
the jvm is performant as gently caress actually, why do you think so many new languages target it. i think somebody recently mentioned that tomcat is faster at serving static content than apache is and i can believe it (mostly because performance is an explicit non-goal for apache, since they're more interested in portability and flexibility) the startup time is complete shite, of course, but that's mostly because oracle jdk/openjdk are only really used to run server applications and Minecraft these days, so i guess nobody really bothered to optimize that. android's pseudo-jvm seems to start up fast enough although i guess that's mostly on account of the whole zygote thing.
|
|
#
?
Sep 24, 2016 16:16
|
|
|
abort Java, confirmed
|
|
#
?
Sep 24, 2016 16:34
|
|
|
|
| # ? Jun 1, 2024 05:34 |
|
|
Soricidus posted:our current project lead insisted on gradle instead, rip this but the group whose code we interact with also insisted on scala our group chose to annoy everyone else by sticking with maven and java instead so maybe the joke is on us
|
|
#
?
Sep 24, 2016 17:08
|
|
