C# annoyed me today, so I took revenge.
-
-
the rest of the time it'd "forget" to send the new .js files to the web server
This is why I don't like my maven/ant scripts to be doing deploys. I'd rather set up the deploy tasks someplace with a lot more visibility. I've been using maven for functional test projects and while I like it for dependency management, I don't really like how much I have to configure things to make it run a given subset of tests with some parameters on demand.
-
I truly hate it when words are used to mean different things. It only promotes confusion as people say words and think they understand each other but don't really.
Relevant book:
-
This is why I don't like my maven/ant scripts to be doing deploys. I'd rather set up the deploy tasks someplace with a lot more visibility.
Can you explain what "more visibility" means?
I've never seen "nondeterministic" things with ant (haven't really used maven). Which isn't to say, like any other programming task, that I haven't made mistakes that had consequences that I didn't immediately notice or understand.
-
Something like Jenkins or Bamboo where you have a central location for deploy jobs with detailed logs and notification rules, rather than being tucked away in a seemingly innocent build script in the repo that accidentally runs when you check out and compile.
-
Something like Jenkins or Bamboo
Do they have their own custom stuff? We use TeamCity, which uses the same ant file that I use as a developer (with a different configuration).
-
They're infinitely flexible. For deploys, we're using an SSH task to do an SVN switch on each box, but they can do all kinds of things, or read from a build script if you have it configured that way.
-
I'd rather set up the deploy tasks someplace with a lot more visibility.
I'll typically set up the rules for deploying in a maven profile, but keep things like credentials and so on out of the build (which Jenkins would hold for me by running the rules I've specified). We do the same sort of thing with the full release builds of some of our products because they're packaged as signed executables with an embedded JRE.
Nuget isn't "a thing that's cobbled together", it's been a standard feature shipping with VS for years at this point.
And, again, keeping the dependencies of your project on a server owned by someone else instead of just putting them in your project is a questionable idea to start with.
Typically with Maven you'll set up a “local” repository to hold copies of all the artefacts (libraries, builds, that sort of thing) that you are using, and share that between the build servers and the developers' desktops. For open source stuff, it'll just be in caching mirror mode; only commercial dependencies (plus your own builds) would be directly uploaded into it.
-
The basic problem I had was it was not deterministic in the least. The build would produce a working site about a third of the time-- the rest of the time it'd "forget" to send the new .js files to the web server, or perhaps send the new .js files but "forget" the Java classes. It was an unreliable mess.
Sounds like something's badly misconfigured, probably by having a step attached to the wrong lifecycle stage.
-
For open source stuff, it'll just be in caching mirror mode; only commercial dependencies (plus your own builds) would be directly uploaded into it.
It's more of a mistake to assume an open source project's website will exist (at the same URL!) in perpetuity than it is for a commercial dependency.
The thought that Java people think this solution (set up our own brand new server purely to host dependencies so our auto-fetching build tool can fetch them from our own network!) is more desirable than just checking the fucking dependencies in the fucking repo tells me a lot about how Java people think.
Sounds like something's badly misconfigured, probably by having a step attached to the wrong lifecycle stage.
Right; just like whenever anybody has a complaint with Lotus Notes, the reply is always "it's just misconfigured!"
No I'm sorry, if a BUILD system can be misconfigured in such a way that it's operation is NON-DETERMINISTIC, then it's broken. There should not be any random number generation occurring inside your software build. End of story.
-
It's really hard to even have a discussion with someone THIS ignorant about a product.
You mean, like when you are talking about Linux ?
-
You mean, like when you are talking about Linux ?
Maybe; but at least I've actually used Linux, many, many times. My opinion of Linux isn't based on, "every time I talk to my co-worker who uses Linux he has to restart his computer."
-
The thought that Java people think this solution (set up our own brand new server purely to host dependencies so our auto-fetching build tool can fetch them from our own network!) is more desirable than just checking the fucking dependencies in the fucking repo tells me a lot about how Java people think.
The thought that you think these are two different things tells me a lot about how you refuse to think.
-
The thought that you think these are two different things tells me a lot about how you refuse to think.
They are; one involves setting up TWO repos, one of which uses an entirely different protocol than the other, and is more fragile and less reliable than the other.
It's doing twice as much effort for zero additional benefit.
-
It's doing twice as much effort for zero additional benefit.
Uh huh. Zero. None. Nada. Because the repo you use for your text based source code is also the shiznit for large binaries.
Does it also upset you when a company sets up an email server and an instant messaging server?
-
Uh huh. Zero. None. Nada. Because the repo you use for your text based source code is also the shiznit for large binaries.
That's only because our industry took a dive directly into the moronic Git instead of choosing something better.
Does it also upset you when a company sets up an email server and an instant messaging server?
Yeah, kind of. Even Lotus Notes does IM. What's the point of having two servers to do the job of one?
-
...you're* the reason it takes half an hour to check out some of our repos, aren't you? "We already have a repo for code, let's put our dependencies and image files (pre and post compression, why not) and everything in the same one"
* someone like you
-
Before people switched to Git, nobody had a problem with that. It wasn't even a "thing". If you were using Subversion or TFS, you could check-out just the specific files and folders you needed to do your work, for example, and ignore the binary files if you didn't need them.
It's incredible how quickly this idiot industry will adopt a new technology with a huge flaw, then immediately start seeing that flaw as a "normal thing".
EDIT: besides, we're talking about CODE dependencies, how fucking large could they be? Maybe 5 MB? At most?
EDIT EDIT: wait a minute, Maven has to download the dependencies ANYWAY. And downloads go FASTER on the intranet server. How the fuck could putting the dependencies in the repo itself be slower in this scenario???
-
That's only because our industry took a dive directly into the moronic Git instead of choosing something better.
Like Visual SourceSafe ?
-
Like Visual SourceSafe ?
Ha ha ha, you know what's a hilariously funny joke of laughs and whimsy? Make fun of a Microsoft product that hasn't existed for a decade!
Hey tell us one about Microsoft Bob next, those are a cascade of chuckles!
I should be more of a pathetic weenie and keep a mental database of every stupid, buggy, failed open source project in the last 30 years so I can pull off some of these hilarious gags!
-
Ha ha ha, you know what's a hilariously funny joke of laughs and whimsy? Make fun of a Microsoft product that hasn't existed for a decade!
Technically, not a decade. Last version was 2005, came out January 27, 2006
@blakeyrat said:Hey tell us one about Microsoft Bob next, those are a cascade of chuckles!
Please, don't remind us of the pathetic atrocity that was MS Bob
@blakeyrat said:I should be more of a pathetic weenie
It's hard to believe you could ;)keep a mental database of every stupid, buggy, failed open source project in the last 30 years
If we follow your logic, that would be every open source project
-
Last version was 2005, came out January 27, 2006
:wat.sql:
that does not compute.... unless it's like car models? and even then that's the wrong way around. the 2016 model year starts like septembre of 2015... somewhere around there anyway.
-
Windows 8.1's version number is 6.3. So it's not like MS is super-consistent with this stuff
-
:wat.sql:
that does not compute.... unless it's like car models? and even then that's the wrong way around. the 2016 model year starts like septembre of 2015... somewhere around there anyway.
https://support.microsoft.com/en-us/lifecycle?p1=10433
-
To keep the same version number as Visual Studio 2005, Team Foundation Server 2005, and SQL Server 2005.
-
Windows 8.1's version number is 6.3. So it's not like MS is super-consistent with this stuff
Seeing how people seem to chase the "Most WTF way of determining current Windows version" award, I'm frankly amazed they still update the version numbers.
-
It's really hard to even have a discussion with someone THIS ignorant about a product
I can't talk about VS very much because I don't use it. I am ignorant. However I was correct about what I said: If you want to open two solutions you need to open VS twice. Like I said, it's not really a big deal. You're making a big deal about a passing comment I made about the biggest (still minor) difference between how inter-project dependencies are managed in VS vs Eclipse.
The basic problem I had was it was not deterministic in the least. The build would produce a working site about a third of the time-- the rest of the time it'd "forget" to send the new .js files to the web server, or perhaps send the new .js files but "forget" the Java classes. It was an unreliable mess.
I'm still not able to be helpful here because what I'm going to say here is: I haven't seen that happen. Were you using custom plugins? Everything in Maven is achieved using plugins but the standard ones are pretty mature.
-
Obviously if your co-workers didn't have the "code open already", that means VS doesn't support opening more than one solution at a time. THAT MAKES SENSE.
So I obviously expressed myself poorly and you took the interpretation that's most convenient to your ranting. I should have known better. My most heartfelt apologies. Let me see if I can improve your understanding with a little story.
I go over to the .net guy's desk. He's working in Visual Studio. I ask him about something, he says "I don't have that open, give me a second" and opens another instance of Visual Studio. I say "Why did you do that?" and he says "that code is in a different solution". I say "Haha! Fool! I have Eclipse open all the time, with all my code, all my projects, at the tip of my fingers! Despair at your inferior existence!"
Note: While based on true events, this is a dramatisation. All quotes are paraphrased, not direct quotes.
-
If you want to open two solutions you need to open VS
However... a solution is simply a file that has references to any number of projects; the projects don't know what solution they're in. You can have a solution that's "all my the projects I care about" without disturbing how other people work.
-
I go over to the .net guy's desk. He's working in Visual Studio. I ask him about something, he says "I don't have that open, give me a second" and opens another instance of Visual Studio. I say "Why did you do that?" and he says "that code is in a different solution". I say "Haha! Fool! I have Eclipse open all the time, with all my code, all my projects, at the tip of my fingers! Despair at your inferior existence!"
So you have the code you're working on and loads of totally unrelated stuff open at the same time?
-
So you have the code you're working on and loads of totally unrelated stuff open at the same time?
That depends what you mean by "open". They're in the workspace just like folders you're not interested in right now are visible in Windows Explorer. They aren't "open" in the sense of loaded into memory.
-
So basically an Eclipse workspace is like a VS solution.
-
So basically an Eclipse workspace is like a VS solution.
... similar. Except the projects have the dependency information, not the workspace. Eclipse supports many sets of unrelated project dependencies, not just one monolithic build configuration. Like I said I don't use Visual Studio so I can't properly describe the differences.
It's still not a big deal, I don't know why people are focusing on this.
-
However... a solution is simply a file that has references to any number of projects; the projects don't know what solution they're in. You can have a solution that's "all my the projects I care about" without disturbing how other people work.
That's cool. Does anybody actually do that? The guys here don't. Can you build some or all of your code from there?
-
-
In VS, projects hold dependency information. A solution is nothing but a list of projects.
-
I do it on occasion. Look, you need to realize you working with morons says nothing about the capability of VS.
-
Can you build some or all of your code from there?
Sure. You can tell VS to build everything in the solution, or to just build a project and any projects it depends on.
-
Sure. You can tell VS to build everything in the solution, or to just build a project and any projects it depends on.
Why does your avatar have two hats and two moustaches? Are we already experiencing hat-and-moustache inflation?
-
Why does your avatar have two hats and two moustaches?
A month or two back I started adding the hat and mustache combo that is shown in the lower right as a sort of signature. It has become a way to identify bona-fide Mad Hatter™ Hattings™. The larger hat and centered mustache are part of the actual Hatting™.
-
a sort of signature. It has become a way to identify bona-fide Mad Hatter™ Hattings™.
How are we supposed to verify that this signature is genuine, unless it has a signature of its own?
-
How are we supposed to verify that this signature is genuine, unless it has a signature of its own?
Damm it! You're right! I shall begin signing my signature henceforth!
-
So you have the code you're working on and loads of totally unrelated stuff open at the same time?
Well, I usually leave TDWTF tab open as well...
-
That should be safe as long as you never hit the Build button by mistake.
-
Damm it! You're right! I shall begin signing my signature henceforth!
Or just steganographically PGP-sign it.
-
It amuses me quite a bit that the standard tooling for Java environments is something that so many people dislike, but that everyone who tries to replace it finds that, no, that's really very difficult to do indeed.
I dunno, Gradle seems to be doing a pretty good job... but I haven't had a chance to use it in a real project yet, only in some test projects.
Having said that, it can download dependencies directly from Maven Central, so in a sense it stole one of Maven's best features (automatic dependency downloading) while getting rid of its worst (
pom.xmlfiles).I think Gradle's biggest problem right now is the lack of IDE integration.
Sure, Gradle has an eclipse plugin, which is smart enough to generate the appropriate Eclipse project type based on the other Gradle plugins loaded, but I'm not sure there's anything on the IDE side to auto-resolve dependencies added by Gradle.
This is opposed to Maven, which does have plugins like this. For that matter, Eclipse has shipped with m2e since 2012 which means you can both directly create Maven projects or pull Maven projects from a SCM out of the box (assuming for the latter that you installed the appropriate SCM plugin).
-
(assuming for the latter that you installed the appropriate SCM plugin)
I think the SVN and Git support are pre-installed these days. At least in the edition I downloaded. I guess the popularity of github makes that sensible, and jgit (the Java git implementation) seems to be reasonable in terms of portability.
Or maybe I just added the Git support immediately. I don't remember.
-
It's not particularly hard to use make, it just comes from the 70s and has weird 70s baggage on it
Sounds like Linux
I have Eclipse open all the time, with all my code, all my projects, at the tip of my fingers!
Is that why Eclipse is such a horrible memory hog?
-
Is that why Eclipse is such a horrible memory hog?
Speaking of weird 70s baggage. Buy some more RAM, man!
-
I currently have two instances of VS open, each using less than 200MB of RAM
Amazon.com
