131–140 of 168 posts
Maven just works and if you stay within it's intent, it does it's job. We use Maven with Bamboo for continuous integration and it just works. We play with the idea to move to Gradle b/c it's more powerful, but the effort is non trivial and the real benefits - beside the 'but it's programmable' - not clear.
After 3 years of SBT for Scala development, which plainly does not work, b/c SBT developers do not like simplicity (the irony!) and are more interested in doing cool stuff than stuff that works, I'm only a small push away from going back to Maven/Zinc, that favors 'just works and you can't shoot yourself in the knee with an arrow' over 'powerful'.
It's hard to be wrong when you claim that you either eventually hate or stop using a software tool. I can't think of many tools that escape this simple truth.
Also, you would be surprised just how much "Java" programming you can do with a decent XML editor. IDE's are overrated.
Earlier quoted context omitted.
IMHO, it is XML.
XML is a great language since it has the power of schemas and DTDs. It makes it easy to validate the data you expect in each of the fields. And fuck am I tired of hearing about how saving 10% of your keystrokes during authorship is such a great thing. Most of the time spent on software in in maintenance, so you want better readability than terseness. coffeescript, yaml, etc... are far inferior solutions for most of t…
Quite the opposite. XML Schema is an awful mess - it's not even representable in XML; it's not a good language for expressing validation constraints, it's neither simple enough to be easy, nor powerful enough to express all your requirements. And the need to support schema leads to DTDs and namespaces, which are responsible for most of the screwups of using XML in the real world.
If XML were just tags, parsers didn't try to connect to the internet to validate everything, and tools didn't bother with namespaces, it would be usable enough that we probably wouldn't have needed to invent JSON.
This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going ba…
Is switching tools really so catastrophic? I have emacs keybindings burned into my muscle memory but just about every tool I use supports them. But if I'd insisted on sticking with Emacs instead of moving in the mainstream (Xcode & IntelliJ for mobile) I would have ultimately been much less productive than I've been after spending a week getting my head around more specialized tools.
Best of both worlds
Earlier quoted context omitted.
> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring. You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio. Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwd…
I think much of Java programming we are talking of today is basically using the IDE. Opening a file and reading from it takes tens of lines in Java, and that's just a trivial task. Stuff like that is better left auto generated. You don't learn Java these days, you just learn eclipse. Much of the magic is happening in auto complete. I am not sure who picks up a book to learn java these days.
Some of the bad Java is because of missing abstractions, most of it is because of badly designed api.
http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-apis.h...
For your particular example, the api has been better since Java 5.
import java.util.Scanner;
import java.io.*;
public class ScannerTest {
public static void main(String[] args) throws FileNotFoundException {
Scanner in = new Scanner(new File("some_file"));
while (in.hasNextLine()) {
System.out.println(in.nextLine());
}
}
}
I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface...
> I am not sure who picks up a book to learn java these days.
It was some time ago(about 8 years ago), but I learned Java from a book(multiple books; I liked Core Java best http://www.amazon.com/Core-Java-Volume-I-Fundamentals-Editio...)
Also, what good would eclipse do to someone who doesn't know what to write? Consider my example above. Unless you know how to read a file, how can eclipse generate the code for you?
Or consider generics. How will eclipse help you understand what does > mean? Eclipse is an aide. Unless you understand the language well, it doesn't help.
Earlier quoted context omitted.
You can like maven or hate it, but why can't it be a bit simpler? e.g. take this selenium install instructions ( http://seleniumhq.org/docs/03_webdriver.jsp ) Ruby: gem install selenium-webdriver Java (with Maven): 4.0.0 MySel20Proj MySel20Proj 1.0 org.seleniumhq.selenium selenium-java 2.28.0 com.opera operadriver com.opera operadriver 1.1 org.seleniumhq.selenium selenium-remote-driver Then run mvn clean install
Sounds like they've cocked up the jars they've produced; you should never have to use exclusions, and it's possible to have a dependency that can be satisfied multiple ways with a default, so you shouldn't need to choose the driver separately if you don't want to. Much of that xml file is what already exists for your project. So the fair comparison is with the section: org.seleniumhq.selenium selenium-java 2.28.0 So:…
Maven becomes brilliant when you start dealing with a large number of modules and profiles, and becomes more tedious when you pass a certain complexity threshold, usually when you have multiple layers of compile-time code generation going on top of each other.
"These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson, composable build tools scale (in time, complexity, and usefulness) better than contextual ones." And then the person that wrote them leaves and we're fucked. If maven doesn't do what you need to do, then chances are you don't need to…
If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly. Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable: - submitting code to a code review site like Gerrit. - generating code (for example, a parsed SNMP MIB that you want as a Jav…
- code coverage / findbugs etc. are better done using something like Sonar. Again, this works just fine for us. You can also set up Sonar & Jenkins on your desktop in minutes and have a working analysis suite + web interface without centralising your builds.
And I assert that you're wrong on the IDE integration - Intellij appears to shell out to Maven for some things, but M2E in Eclipse is a completely different beast (and has some rough edges as a result, but can work well).
This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years. After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool. Reflecting on my history with a UNIX shell going ba…