Since I'm doing something similar in an enterprise environment I suggest you to add , to each cron, a dates black-list. I mean a list of dates in which you do not want the job to be executed ( Christmas , Easter etc). Kudos for the clean documentation
I switch from Rails to Django a while ago. On a feature base the two frameworks are equals. I explained it in depth in this video http://vimeo.com/31083901 ( It's in Italian,mf.Du you speak it?! :-) ). Basicaly I turn on django beacuse I prefer Python to Ruby: again the two languages starts from the same assumptions ( Guido also told that ) it's just my personal taste. Also django do things THE WAY I like more. For ex: the configuration is simpler because it uses python files as config an not [name yours]ml. That said in DEVELOPMENT MODE ( production is a total different world ) Django is faster than Rails. The time to running test/ start dev server is not 100% of a developer productivity so I'm not saying that django is more productive than rails. I'm saying that I'm more productive with django than with rails. Use C++, Fortran ,Lisp ,Scala what ever you want: just deliver good software. PLZ
Minor grammar Nazi point (since you mention you are Italian, and might be interested) - "turn on" is either "sexually attracted to" or "suddenly attack", depending on the context. i.e. "She turned me on, the smell of cigarettes is not a turn-on for me, the dog suddenly turned on me and started biting". I've no idea why ...
Design patterns are useful because they improve.. design. I mean application and code design. They model a recognizable structure. You are right: they have been sold as the ace of all trades in CS books and courses and they are not. That lead to the ' factories of factories of metafactories ' situation. Experience and intelligence are the real 'ace of all trades'. On the other side chaos is not good for anyone. Instead having a common lingo to identify code structure and common solutions to local architectural challenges is a good thing.
So, wouldn't it be better to write books on how someone got from a problem to a solution and why the outcome was something that can be described as a factory pattern, rather then the other way around?
I didn't read books on design patterns, but the book from the link structures around what design patterns there are and how they got applied to a problem. It'd be nicer to first have a problem and show why and how a particular pattern is better than, say, a bunch of monolithic lines of code.. So that you can say "oh and by the way, the way we solved that problem falls into the category of factory patterns".
In Italy is even worst. Local Laws are a jibberish with regulations from the roman empire and the Napoleon invasion ( not joking). Build an equity based company requires huge amount of work and capital. But the saddest part is that investors prefer "stock game" on real company investment. We are used to say that a young founder is the son of an old founder. It means that in Italy capital passes as legacy from father to son and never goes to the market, and often when it does is burnt.
At my talk at the Italian RubyDay on continuous integration I received huge critiques for endorsing a Java solution for ruby CI. My point was that Jenkins was far more complete ( at the time of the presentation) of any full ruby stack CI product. This news is a fine Christmas present. This tells me that people clever than me share some of my views
I don't really get the problem though. Java is trivial to learn for anyone. It's not your main product, it's not going to take a massive amount of time for a single plugin. Just write it and be done...
It might be really easy to learn. But after having programmed Ruby for any significant time Java is very unpleasant to program ;)
Also just learning basics to do simple customizations is not enough. If something breaks you will not have a slightest idea how to debug and fix. With a Ruby CI server I can just stick a debugger and walk through the code.
> Think of a ruby dev team and the wish to extend the CI server?
It's not exactly a show stopper as long as they have the sourcecode.
If the team are capable enough to code Ruby and extend the CI server, then they either already know enough Java to do so or can learn it quickly enough to be effective.
Mainly yes.. shouts like " Java sxx" " I hate Java". The most relevant may be to resource usage: Jenkins would require more resources than the production machine in mid sized project. But in a world of commodity HW I'don't think this is a real issue
Actually it's just checking the types at runtime, nothing much 'static' about it. This is pretty much the antithesis of duck typing, in fact. I could see it being useful, but I could also see it leading to confusion for people who expect Python's usual duck-typing behaviour when they pass their own types into a function.
Whoops you subclassed from a type for which this function has a multimethod defined? Gonna do something different.
On the other hand, in non-trivial programs there _are_ certainly occasions when you need to check the type, so using an elegant method like this isn't a bad compromise.
If multimethods were a subset of static typing, then regular methods would be too. Methods are dynamic by definition: the type of the method's target is inspected at runtime and used to dispatch to the correct function entry. In Python, it's explicitly stated because the first argument of all object methods is "self". Multimethods extend this to do dynamic dispatch on all argument types, not just the target object.
Most Python object methods are declared at compile time; this doesn't make method declaration a "subset of static typing". You can add new methods to classes and objects at runtime using Python's reflection and introspection; you can just as easily add new multimethods at runtime using this framework.
Finally, the @decorator(...) syntax at compile time is just syntactic sugar for something like the following:
def _foo(self, arg):
...
foo = decorator()(_foo)
So you can use decorators at runtime whenever you want too.
Though not a Django user, I immediately wished this existed for a number of other frameworks/projects. What a great idea to keep people interested in the project.
