I usually don’t link much outside of my mains posts but Bruce Schneier, a security expert, wrote an interesting post about the “Cover Your Ass” security measures. Very effective to keep cops in shape. A pretty good blog by the way,
The following charts illustrate the evolution in concentration of carbon dioxid in the atmosphere and the temperature across thousands of years. The data come from verifiable and scientific sources so you can check by yourself if you want.
This first graph shows a record with both carbon dioxide and temperature that illustrates the strong correlation in the evolution of these two parameters (click on the image to zoom in).
This little red arrow in the upper right corner is a bit puzzling. So let’s have a better view of the CO2 level by itself:
In short the maximum amplitude ever observed has doubled in less than 200 years. Basically the difference between the upper part and the lower part of those peeks means several meters of ice on top of a lot of people’s head. I let you imagine what this translates into when it’s a rise of temperature instead of a decrease (the temperature has barely started catching up on the CO2 level). But of course it has nothing to do with human activity.
The U.S.A. are responsible for 24% of the total quantity of CO2 emitted (data of year 2002) with only 4.6% of the world population. By comparison the European Union emits 15% of the total CO2 for 7.5% of the world population (and are working on it) and Japan 5% for 1.94% of the world population (and are working on it).
There are 2 possible ways to react to this:
If you like the third option better it’s not that complicated, just do your homework and vote for someone with the political will to do something. Choose anybody, I don’t care, but choose well (maybe you can avoid those whose campain is heavily financed by major oil companies though).
We’re having some “crystal ball discussions” sometimes at the office, trying to see what the future of Java, Ruby, computer
languages, software and the world in general is going to be. The easy part is the world of course, with no fish in 40 years it’s easy to guess how all that is going to end up. For computing languages however, it’s a bit trickier.
I’m more and more convinced that statically typed languages will come to an end (just like the fish but quicker), replaced by duck typing based languages. There’s been many criticisms of duck typing but usually those voicing them don’t have an extensive experience of development using non statically typed languages or are Java fundamentalists. I haven’t heard anybody developing significantly in Ruby complaining about it not being statically typed. So I’ll spare you the whole argument about safety and compile-time checking because in the end it doesn’t really matter. You can theorize all you want but the pure fact is that static typing is a pain and pain slows us down and doesn’t help us doing things.
So very practically I can think of only one reason that could still make the duck typing alternative less appealing to some: the IDE. But IDEs will eventually catch up, using instrumented interpreters to detect types dynamically for example. There are solutions, even if they don’t cover all situations, 95% is good enough.
Say goodbye to your type definitions, generics and typed annotations (even annotations are statically typed for christ sake!) because I’m pretty sure you won’t see much of them 5 years from now.
I came to think that transitive dependencies are mostly evil. Really. They can be useful sometimes, if you keep them on a
tight leash. But chances are you’re going to shoot yourself in the foot sooner or later using them. First let me illustrate with severals use cases and examples that I’ve experienced first hand.
First example, you have a simple web project and use several libraries. And 3 or 4 of them happen to depend on Xerces as almost the whole word depends on Xerces for some reason. Now you buid a WAR file and your build system is nice enough to put all your dependencies, including transitive ones, in its WEB-INF/lib directory. Nice enough? Think again. You’re going to end up with 3 or 4 different versions of Xerces in there. Which one is going to be selected at runtime? Well, do you want to bet on whether your app server follows alphabetical order or not?
Second example, you’re using XDoclet. Or the Spring Framework. Or any other framework including several modules, some necessary, some optional. All those modules sort of depend on each other. So chances are that by pulling one, you’re going to pull everything. And usually people don’t think much about the way others are going to download their own project outisde of the regular distribution, they just include everything they can think of as their dependencies. And you end up with a lot of garbage that you will never use and beat the record of the biggest software distribution ever built.
Another example. You depend on project A. Project A depends on B. And B depends on C. So far so good. Now it turns out that the repositories containing all these dependencies are mostly a mess. So somebody just comes up and removes the version of C that B depends on. Your build is broken.
A last one. This one would be actually pretty funny if it wasn’t so pathetic. On Apache Ode we have a JBI wrapper to allow deployment in a JBI container. We’re using a Maven plugin from ServiceMix to build Service Assemblies. Now this plugin happens to depend on the whole ServiceMix engine because it also includes tasks to auto deploy and run the server directly. So we end up pulling all the ServiceMix project just for a plugin. Now here is the best part: ServiceMix uses Ode. It’s part of its dependencies. So when we build our stuff for the first time, we end up downloading all ServiceMix plus all OUR stuff that we’re currently building. How crazy is that?
Conclusion
Given all this mess, what’s a build system to do? I think the transitive dependency problem has no solution, there are some techniques that can be used to keep some control but deep down it’s really flawed. Because the dependencies that are right for you can’t be guessed, just like the code you’re writing can’t be all generated.
However I think we’re still going to add it into Raven. Yep, you heard me well. And there are 2 reasons why:
So to give you weapons against chaos, pain and despair (exageration is my friend), I’d like to keep transitivity under control to allow you to opt out at any time. To do that, the transitivity would be toggable, you’d be able to turn it off and then specify everything explicitly. When you choose to do so, as we’re all a bunch of lazy asses, Raven would let you generate a dependency declaration with all the transitiveness you need. You’d then clean it up a bit to fit your needs, adding rationality to an insane accumulation of libraries, and when it’s all pretty, include it in your build.
So any other strong opinion on transitive dependencies? Ideas?
We’ve started working on several improvements and new features to improve your Java builds with Matthew. All of which should come when we’re ready for a 2.0 release of Raven. I’m going to give you a quick overview here and I’ll probably go into some more details and rants in later writeups.
So I haven’t been writing for a while and the main reason is that I’ve been pretty busy. There’s been some book writing (getting closer to being published, I’ve finished most of the content), a lot of Apache ODE development for Intalio and of course Raven. Plus the winter in San Francisco is pretty nice so far, so surfing and swimming is tempting.Skunk Works › Edit — WordPress
Anyway I’m not here to wine about time scarcity, life is too short and all that. This is wasting,
The first big change you will see it that we’re now tied to JRuby. Honestly I would have liked to keep CRuby but there’s no real point when the goal is building Java and this gives space for several optimizations and nice features.
The main optimization is Matthew’s build server that he integrated from JRake. The idea is that you start a VM only once on your machine and then the build is always executd in it. The client just tells the server which task to execute and where and voila! The downside is that you have to keep the server running but it’s fairly small, the upside is that you have absolutely no startup cost when building. And as most tasks directly use Java classes (javac, javadoc, jar, junit and all the jays), the execution is also much faster than if you shell out like Raven used to do.
Another big modification is the use of “channels”. I think that one will deserve its own blog post, I don’t want to summarize too much and confuse you. But in short this simplifies the interactions between your tasks, they will be able to reuse easily the result produced by other tasks (code generation, jar production and all the usual suspects) without you needing to care about it. And making it easy when you really need to care about it.
Yet another goodie brought from JRake by Matthew is multithreaded builds. Your tasks run in parrallel whenever possible. And that saves you time too, especially in this new multicore era with your processors multiplying quicker than a spermatozoid meeting an ovule.
There will also be Ant integration just because rebuilding all the nice tasks that have been built for Ant would take us too much time. I’m not talking about mkdir or ssh here, Ruby offers better alternatives. But for XDoclet, XMLBeans or some VCSs support, it’s a must have. We’ve started with AntBuilder but we may very well end up with Antwrap as its maintainer, Caleb Powell, is a pretty active guy and AntBuilder is dormant.
And that’s not all. Better logging. Much, much better logging. Better JUnit support. Maybe some Continuous Integration integration. And maybe more.
Stay tuned…
Pic from Deborah Lattimore.
Comments(0)