You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@onami.apache.org by Simone Tripodi <si...@apache.org> on 2013/02/02 13:13:54 UTC
[discuss][configuration] extract the converter(s)?
Hi all guys,
I wonder if it would make sense extracting the converters from
[configuration] in separated modules - my objective is defining all
that modules in a fine granularization in order that users just
include in their application what they really need, and not everything
by default.
So I'd move all converters in a separated branch with sub-module.
Do you have any observation on that?
TIA and have a nice WE,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
I am still convinced that approaching modularization having OSGi in
mind as good example of modularization is the way to go. And we can
still support big packages for users that prefer them.
The (almost) one class module is a special case for the converters stuff.
I will experiment that approach on sandbox so we can evaluate.
TIA, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Feb 4, 2013 at 1:35 AM, Daniel Manzke
<da...@googlemail.com> wrote:
> Splitting it in to much modules, does it hard to find them.
>
> I like to split it into a converter project, but would stop there. Like
> suggested we can later split if we have the need for it.
> it is like guava, commons-codec, ... a library with more than one class. ;)
>
>
> 2013/2/2 Simone Tripodi <si...@apache.org>
>
>> > Usually in such case, I like having a org.onami.converter.all for guys
>> like
>> > me who are lazy (I prefer declaring one module than many) and who dont'
>> care
>> > handling big jars :)
>>
>> this is a very nice suggestion - and not hard to achieve.
>>
>> I am "sandboxing" tonight in order to prepare a more concrete proposal.
>>
>> thanks a lot for the priceless feedbacks!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
Re: [discuss][configuration] extract the converter(s)?
Posted by Daniel Manzke <da...@googlemail.com>.
Splitting it in to much modules, does it hard to find them.
I like to split it into a converter project, but would stop there. Like
suggested we can later split if we have the need for it.
it is like guava, commons-codec, ... a library with more than one class. ;)
2013/2/2 Simone Tripodi <si...@apache.org>
> > Usually in such case, I like having a org.onami.converter.all for guys
> like
> > me who are lazy (I prefer declaring one module than many) and who dont'
> care
> > handling big jars :)
>
> this is a very nice suggestion - and not hard to achieve.
>
> I am "sandboxing" tonight in order to prepare a more concrete proposal.
>
> thanks a lot for the priceless feedbacks!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
--
Viele Grüße/Best Regards
Daniel Manzke
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
> Usually in such case, I like having a org.onami.converter.all for guys like
> me who are lazy (I prefer declaring one module than many) and who dont' care
> handling big jars :)
this is a very nice suggestion - and not hard to achieve.
I am "sandboxing" tonight in order to prepare a more concrete proposal.
thanks a lot for the priceless feedbacks!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [discuss][configuration] extract the converter(s)?
Posted by Eric Charles <er...@apache.org>.
On 02/02/2013 15:35, Simone Tripodi wrote:
> Salut mon ami,
>
>> In the case of converter, where would you stop? a module for date, one for
>> exceptions, one numbers, one for currencies....?
>
> That was my thought indeed :P
>
I just wonder how many modules we will finally have?
Usually in such case, I like having a org.onami.converter.all for guys
like me who are lazy (I prefer declaring one module than many) and who
dont' care handling big jars :)
Thx, Eric
>> dependency, and also with a ConverterRegistry (such as [1]).
>
> we don't have currently such registry since the conversion is
> delegated to the Guice core, we just plug conversters in the binder
> and let Guice do the work.
> The reason why converters were included in the [configuration] module
> was that users can load from properties files and bind values to
> custom types.
>
Not sure if a registry is worth, but we can always let evolve that new
convertion module.
> Thanks!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sat, Feb 2, 2013 at 4:20 PM, Eric Charles <er...@apache.org> wrote:
>> Well, logging split makes perfectly sense (if I use log4j, I don't use
>> logback... for example).
>>
>> Although I am a big fan and pusher for modularity, I have constated that
>> most of developers I met/talk to in real life have tendance to split less
>> than I would do.
>>
>> In the case of converter, where would you stop? a module for date, one for
>> exceptions, one numbers, one for currencies....?
>>
>> I would simply start with a single parent module
>> (org.apache.onami.converter) with a single child module
>> ((org.apache.onami.converter.core) as long as there is no 'heavy' external
>> dependency, and also with a ConverterRegistry (such as [1]).
>>
>> But if you code it, that's all in your hands :)
>>
>> Thx, Eric
>>
>> [1]
>> https://github.com/dhanji/sitebricks/blob/master/sitebricks-converter/src/main/java/com/google/sitebricks/conversion/ConverterRegistry.java
>>
>>
>>
>> On 02/02/2013 14:55, Simone Tripodi wrote:
>>>
>>> just have a look at how the logging module has been organized... I
>>> like the modules granularization here, where users include only the
>>> logger they need, keeping outside what is unneeded.
>>>
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Sat, Feb 2, 2013 at 3:51 PM, Simone Tripodi <si...@apache.org>
>>> wrote:
>>>>
>>>> Salut mon ami!
>>>>
>>>> not only I would move the converters package to a 'TLP'
>>>> org.apache.onami.converters module, I would even split converters in
>>>> different small submodules, so users bring just the converters they
>>>> need.
>>>>
>>>> Let's say someone just needs a DateConverter... which is the sense of
>>>> including all the converters in the application?
>>>> Something suggests me we should take more care about modularization...
>>>> does it make sense?
>>>>
>>>> TIA, all the best!
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>>
>>>> On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <er...@apache.org> wrote:
>>>>>
>>>>> btw, sitebricks for which I have just created a pull-request for
>>>>> validation
>>>>> with bval-guice [1] has a dedicated module for convertion [2].
>>>>>
>>>>> So it confirms convertion deserves a dedicated module.
>>>>>
>>>>> Thx, Eric
>>>>>
>>>>> [1] https://github.com/echarles/sitebricks/tree/validation
>>>>> [2]
>>>>> https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
>>>>>
>>>>>
>>>>>
>>>>> On 02/02/2013 13:27, Eric Charles wrote:
>>>>>>
>>>>>>
>>>>>> Hi Simo,
>>>>>>
>>>>>> Do you mean moving to a toplevel onami module
>>>>>> (org.apache.onami.converters)?
>>>>>>
>>>>>> Just asking to be sure, but it makes sense to me as any other module
>>>>>> potentially need convertion.
>>>>>>
>>>>>> Thx, Eric
>>>>>>
>>>>>>
>>>>>> On 02/02/2013 12:13, Simone Tripodi wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi all guys,
>>>>>>>
>>>>>>> I wonder if it would make sense extracting the converters from
>>>>>>> [configuration] in separated modules - my objective is defining all
>>>>>>> that modules in a fine granularization in order that users just
>>>>>>> include in their application what they really need, and not everything
>>>>>>> by default.
>>>>>>>
>>>>>>> So I'd move all converters in a separated branch with sub-module.
>>>>>>>
>>>>>>> Do you have any observation on that?
>>>>>>> TIA and have a nice WE,
>>>>>>> -Simo
>>>>>>>
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>> http://www.99soft.org/
>>>>>>>
>>>>>
>>
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
Salut mon ami,
> In the case of converter, where would you stop? a module for date, one for
> exceptions, one numbers, one for currencies....?
That was my thought indeed :P
> dependency, and also with a ConverterRegistry (such as [1]).
we don't have currently such registry since the conversion is
delegated to the Guice core, we just plug conversters in the binder
and let Guice do the work.
The reason why converters were included in the [configuration] module
was that users can load from properties files and bind values to
custom types.
Thanks!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 4:20 PM, Eric Charles <er...@apache.org> wrote:
> Well, logging split makes perfectly sense (if I use log4j, I don't use
> logback... for example).
>
> Although I am a big fan and pusher for modularity, I have constated that
> most of developers I met/talk to in real life have tendance to split less
> than I would do.
>
> In the case of converter, where would you stop? a module for date, one for
> exceptions, one numbers, one for currencies....?
>
> I would simply start with a single parent module
> (org.apache.onami.converter) with a single child module
> ((org.apache.onami.converter.core) as long as there is no 'heavy' external
> dependency, and also with a ConverterRegistry (such as [1]).
>
> But if you code it, that's all in your hands :)
>
> Thx, Eric
>
> [1]
> https://github.com/dhanji/sitebricks/blob/master/sitebricks-converter/src/main/java/com/google/sitebricks/conversion/ConverterRegistry.java
>
>
>
> On 02/02/2013 14:55, Simone Tripodi wrote:
>>
>> just have a look at how the logging module has been organized... I
>> like the modules granularization here, where users include only the
>> logger they need, keeping outside what is unneeded.
>>
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sat, Feb 2, 2013 at 3:51 PM, Simone Tripodi <si...@apache.org>
>> wrote:
>>>
>>> Salut mon ami!
>>>
>>> not only I would move the converters package to a 'TLP'
>>> org.apache.onami.converters module, I would even split converters in
>>> different small submodules, so users bring just the converters they
>>> need.
>>>
>>> Let's say someone just needs a DateConverter... which is the sense of
>>> including all the converters in the application?
>>> Something suggests me we should take more care about modularization...
>>> does it make sense?
>>>
>>> TIA, all the best!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <er...@apache.org> wrote:
>>>>
>>>> btw, sitebricks for which I have just created a pull-request for
>>>> validation
>>>> with bval-guice [1] has a dedicated module for convertion [2].
>>>>
>>>> So it confirms convertion deserves a dedicated module.
>>>>
>>>> Thx, Eric
>>>>
>>>> [1] https://github.com/echarles/sitebricks/tree/validation
>>>> [2]
>>>> https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
>>>>
>>>>
>>>>
>>>> On 02/02/2013 13:27, Eric Charles wrote:
>>>>>
>>>>>
>>>>> Hi Simo,
>>>>>
>>>>> Do you mean moving to a toplevel onami module
>>>>> (org.apache.onami.converters)?
>>>>>
>>>>> Just asking to be sure, but it makes sense to me as any other module
>>>>> potentially need convertion.
>>>>>
>>>>> Thx, Eric
>>>>>
>>>>>
>>>>> On 02/02/2013 12:13, Simone Tripodi wrote:
>>>>>>
>>>>>>
>>>>>> Hi all guys,
>>>>>>
>>>>>> I wonder if it would make sense extracting the converters from
>>>>>> [configuration] in separated modules - my objective is defining all
>>>>>> that modules in a fine granularization in order that users just
>>>>>> include in their application what they really need, and not everything
>>>>>> by default.
>>>>>>
>>>>>> So I'd move all converters in a separated branch with sub-module.
>>>>>>
>>>>>> Do you have any observation on that?
>>>>>> TIA and have a nice WE,
>>>>>> -Simo
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>>
>>>>
>
Re: [discuss][configuration] extract the converter(s)?
Posted by Eric Charles <er...@apache.org>.
Well, logging split makes perfectly sense (if I use log4j, I don't use
logback... for example).
Although I am a big fan and pusher for modularity, I have constated that
most of developers I met/talk to in real life have tendance to split
less than I would do.
In the case of converter, where would you stop? a module for date, one
for exceptions, one numbers, one for currencies....?
I would simply start with a single parent module
(org.apache.onami.converter) with a single child module
((org.apache.onami.converter.core) as long as there is no 'heavy'
external dependency, and also with a ConverterRegistry (such as [1]).
But if you code it, that's all in your hands :)
Thx, Eric
[1]
https://github.com/dhanji/sitebricks/blob/master/sitebricks-converter/src/main/java/com/google/sitebricks/conversion/ConverterRegistry.java
On 02/02/2013 14:55, Simone Tripodi wrote:
> just have a look at how the logging module has been organized... I
> like the modules granularization here, where users include only the
> logger they need, keeping outside what is unneeded.
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sat, Feb 2, 2013 at 3:51 PM, Simone Tripodi <si...@apache.org> wrote:
>> Salut mon ami!
>>
>> not only I would move the converters package to a 'TLP'
>> org.apache.onami.converters module, I would even split converters in
>> different small submodules, so users bring just the converters they
>> need.
>>
>> Let's say someone just needs a DateConverter... which is the sense of
>> including all the converters in the application?
>> Something suggests me we should take more care about modularization...
>> does it make sense?
>>
>> TIA, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <er...@apache.org> wrote:
>>> btw, sitebricks for which I have just created a pull-request for validation
>>> with bval-guice [1] has a dedicated module for convertion [2].
>>>
>>> So it confirms convertion deserves a dedicated module.
>>>
>>> Thx, Eric
>>>
>>> [1] https://github.com/echarles/sitebricks/tree/validation
>>> [2] https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
>>>
>>>
>>>
>>> On 02/02/2013 13:27, Eric Charles wrote:
>>>>
>>>> Hi Simo,
>>>>
>>>> Do you mean moving to a toplevel onami module
>>>> (org.apache.onami.converters)?
>>>>
>>>> Just asking to be sure, but it makes sense to me as any other module
>>>> potentially need convertion.
>>>>
>>>> Thx, Eric
>>>>
>>>>
>>>> On 02/02/2013 12:13, Simone Tripodi wrote:
>>>>>
>>>>> Hi all guys,
>>>>>
>>>>> I wonder if it would make sense extracting the converters from
>>>>> [configuration] in separated modules - my objective is defining all
>>>>> that modules in a fine granularization in order that users just
>>>>> include in their application what they really need, and not everything
>>>>> by default.
>>>>>
>>>>> So I'd move all converters in a separated branch with sub-module.
>>>>>
>>>>> Do you have any observation on that?
>>>>> TIA and have a nice WE,
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
just have a look at how the logging module has been organized... I
like the modules granularization here, where users include only the
logger they need, keeping outside what is unneeded.
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 3:51 PM, Simone Tripodi <si...@apache.org> wrote:
> Salut mon ami!
>
> not only I would move the converters package to a 'TLP'
> org.apache.onami.converters module, I would even split converters in
> different small submodules, so users bring just the converters they
> need.
>
> Let's say someone just needs a DateConverter... which is the sense of
> including all the converters in the application?
> Something suggests me we should take more care about modularization...
> does it make sense?
>
> TIA, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <er...@apache.org> wrote:
>> btw, sitebricks for which I have just created a pull-request for validation
>> with bval-guice [1] has a dedicated module for convertion [2].
>>
>> So it confirms convertion deserves a dedicated module.
>>
>> Thx, Eric
>>
>> [1] https://github.com/echarles/sitebricks/tree/validation
>> [2] https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
>>
>>
>>
>> On 02/02/2013 13:27, Eric Charles wrote:
>>>
>>> Hi Simo,
>>>
>>> Do you mean moving to a toplevel onami module
>>> (org.apache.onami.converters)?
>>>
>>> Just asking to be sure, but it makes sense to me as any other module
>>> potentially need convertion.
>>>
>>> Thx, Eric
>>>
>>>
>>> On 02/02/2013 12:13, Simone Tripodi wrote:
>>>>
>>>> Hi all guys,
>>>>
>>>> I wonder if it would make sense extracting the converters from
>>>> [configuration] in separated modules - my objective is defining all
>>>> that modules in a fine granularization in order that users just
>>>> include in their application what they really need, and not everything
>>>> by default.
>>>>
>>>> So I'd move all converters in a separated branch with sub-module.
>>>>
>>>> Do you have any observation on that?
>>>> TIA and have a nice WE,
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
Salut mon ami!
not only I would move the converters package to a 'TLP'
org.apache.onami.converters module, I would even split converters in
different small submodules, so users bring just the converters they
need.
Let's say someone just needs a DateConverter... which is the sense of
including all the converters in the application?
Something suggests me we should take more care about modularization...
does it make sense?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 2, 2013 at 2:30 PM, Eric Charles <er...@apache.org> wrote:
> btw, sitebricks for which I have just created a pull-request for validation
> with bval-guice [1] has a dedicated module for convertion [2].
>
> So it confirms convertion deserves a dedicated module.
>
> Thx, Eric
>
> [1] https://github.com/echarles/sitebricks/tree/validation
> [2] https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
>
>
>
> On 02/02/2013 13:27, Eric Charles wrote:
>>
>> Hi Simo,
>>
>> Do you mean moving to a toplevel onami module
>> (org.apache.onami.converters)?
>>
>> Just asking to be sure, but it makes sense to me as any other module
>> potentially need convertion.
>>
>> Thx, Eric
>>
>>
>> On 02/02/2013 12:13, Simone Tripodi wrote:
>>>
>>> Hi all guys,
>>>
>>> I wonder if it would make sense extracting the converters from
>>> [configuration] in separated modules - my objective is defining all
>>> that modules in a fine granularization in order that users just
>>> include in their application what they really need, and not everything
>>> by default.
>>>
>>> So I'd move all converters in a separated branch with sub-module.
>>>
>>> Do you have any observation on that?
>>> TIA and have a nice WE,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>
Re: [discuss][configuration] extract the converter(s)?
Posted by Simone Tripodi <si...@apache.org>.
> btw, sitebricks for which I have just created a pull-request for validation
> with bval-guice [1] has a dedicated module for convertion [2].
cool stuff, very well done, congrats! :)
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [discuss][configuration] extract the converter(s)?
Posted by Eric Charles <er...@apache.org>.
btw, sitebricks for which I have just created a pull-request for
validation with bval-guice [1] has a dedicated module for convertion [2].
So it confirms convertion deserves a dedicated module.
Thx, Eric
[1] https://github.com/echarles/sitebricks/tree/validation
[2] https://github.com/dhanji/sitebricks/tree/master/sitebricks-converter
On 02/02/2013 13:27, Eric Charles wrote:
> Hi Simo,
>
> Do you mean moving to a toplevel onami module
> (org.apache.onami.converters)?
>
> Just asking to be sure, but it makes sense to me as any other module
> potentially need convertion.
>
> Thx, Eric
>
>
> On 02/02/2013 12:13, Simone Tripodi wrote:
>> Hi all guys,
>>
>> I wonder if it would make sense extracting the converters from
>> [configuration] in separated modules - my objective is defining all
>> that modules in a fine granularization in order that users just
>> include in their application what they really need, and not everything
>> by default.
>>
>> So I'd move all converters in a separated branch with sub-module.
>>
>> Do you have any observation on that?
>> TIA and have a nice WE,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
Re: [discuss][configuration] extract the converter(s)?
Posted by Eric Charles <er...@apache.org>.
Hi Simo,
Do you mean moving to a toplevel onami module (org.apache.onami.converters)?
Just asking to be sure, but it makes sense to me as any other module
potentially need convertion.
Thx, Eric
On 02/02/2013 12:13, Simone Tripodi wrote:
> Hi all guys,
>
> I wonder if it would make sense extracting the converters from
> [configuration] in separated modules - my objective is defining all
> that modules in a fine granularization in order that users just
> include in their application what they really need, and not everything
> by default.
>
> So I'd move all converters in a separated branch with sub-module.
>
> Do you have any observation on that?
> TIA and have a nice WE,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>