You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <at...@gmail.com> on 2016/07/30 23:55:07 UTC
GH Repo
Hi guys
as promised I have put together the current state of a streamlines API
including adaptions needed on all the current codebase. This can be found at
https://github.com/atsticks/tamaya-next
The API especially is here:
https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
Short summary of the ideas:
- define *Configuration* by simply providing String get(String key).
- organize configuration as an ordered list of "*ConfigurationProcessor*"
instances aka *processor chain*, which basically are a more generic
combination of PropertySource and PropertyFilter, thus removing the need
for PropertyFilter as well as other heavy decision such as when to
filter. The data access call is simply String get(String key,
ConfigurationProcessorContext context);
- The *ConfigurationProcessorContext* gives access to the remaining
procerssor chain and also helps to reduce boilerplate code in the
implementations.
- The Configuration itself can be created using a *ConfigurationBuilder*,
which basically is a programmatic API to construct the processor chain.
This builder is provided by a *ConfigurationBuilderFactory*.
- The factory also can load the default chain, which is the basic
mechanism we had in place, loading sources, source providers and use their
ordinals for priorization. Nevertheless the factor allows to build up your
own thing, or allows to reproduce the "default" configuration bas calling
factory.loadDefaults().build();
- So the ConfigurationFactory is also the SPI used by the
ConfigurationProvider using the default functionality as described above.
This results in 4 API artifacts and a SPI with another 4 artifacts, which
allow us to do anything we already have with relatively controllable
efforts:
[image: Inline-Bild 1]
Just a few side nodes:
- there is the adapter extension (*tamaya-adapter*), which allows you
give an adapter singleton to adapt configuration to something else. E.g.
this allows us to add functionality for types and defaults:
TypedConfiguration cfg =
ConfigAdapterManager.adapt(TypedConfiguration.class);
ConfigWithDefaults cfg2 =
ConfigAdapterManager.adapt(ConfigWithDefaults.class);
...
- Similarly ConfigProcessor instances can implement Mixin Interfaces
such as Scannable (another module SPI from *tamaya-scannable*) to
provide additional capabilities. This can similalry used to provide access
with getProperties().
I will be now on holidays for 2 weeks. I will be able to answer mails, but
will not have access to a notebook or a computer bigger than my smartphone.
So hangouts work well, coding will be limited ;). Please look at the code
(especially the API and core parts, the modules are not yet fully buildable
;) ).
J Anatole
Suggestion/question: next hangout on Monday evening ?
--
*Anatole Tresch*
PPMC Member Apache Tamaya
JCP Star Spec Lead
*Switzerland, Europe Zurich, GMT+1*
*maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
*Twitter: @atsticks, @tamayaconf*
Re: GH Repo
Posted by Werner Keil <we...@gmail.com>.
Ideally it should do both, but I can't say if something like JBoss/Wildfly
"configuration" (a module that simply helps generate the various XML files)
or Puppet extensions like https://forge.puppet.com/biemond/wildfly
(Multiconf pretty much does the same on top of Kokki instead of Puppet or
Chef) could be easily standardized, too?
There was a dilemma and also discussion on the prior mailing list, if it
should be one or more frameworks. Unlike DeltaSpike or Spring Config Tamaya
has a stronger emphasis on both the "config holder" (Configuration and its
subtypes) and annotations like @Config in Tamaya (Spring calls it
@Configuration)
However the ideas behind Microprofile etc. or also Dropwizard, Spring Boot
and others trying to offer some kind of "Uber JAR", Standalone WAR or
similar means, the "application" or "Java SE" aspects of configuration
should always be there. And have the highest priority. In that sense if a
"Tamaya Microkernel" comes out of the simplification discussion it
certainly can't hurt. And could be a handy alternative for MicroProfile and
its collaborators along the lines of what Spring Config does underneath
Spring Boot.
Regards,
Werner
On Sun, Jul 31, 2016 at 7:52 PM, John D. Ament <jo...@apache.org>
wrote:
> One of the curious things I've always noted with Tamaya was that it tries
> to deal with both the configuration retrieval and configuration creation
> aspects. Realistically, these are two different concerns. Without me
> being able to say that a service is able to do updates, I would expect a
> different set of permissions.
> John
>
> On Sun, Jul 31, 2016 at 12:42 PM Werner Keil <we...@gmail.com>
> wrote:
>
> > First of all ProcessorContext is missing;-|
> >
> > There's a lot of cleaning and even more documenting to do now.
> > The chain and possible combinations of various API elements draws a
> pretty
> > confusing picture. I.E. what possible combinations of
> >
> > - MutableConfiguration
> > - ScannableConfiguration and the newly introduced
> > - TypedConfiguration
> >
> > should there be?;-O
> >
> > The most basic examples all fail, especially because getProperties() no
> > longer exists. Even java.util.Properties had more than one variation of
> > that:
> >
> >
> https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#stringPropertyNames()
> >
> > The statement
> > >Properties whose key or value is not of type String are omitted.
> > sounds a bit weird because like the newly-proposed Configuration
> interface
> > java.util.Properties only returns String values;-)
> >
> > Would be interesting to see it working, also down to at least the most
> > basic examples.
> >
> > Regards,
> >
> > Werner
> >
> >
> >
> > On Sun, Jul 31, 2016 at 4:52 PM, Werner Keil <we...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > How did a "bloated" Tamaya with a total codebase of just under 2MB in
> > > master suddenly become over 20 MB in the "lean" version?;-O
> > >
> > > Also the "code" part (which is what should be sufficient to build the
> > > minimalistic API) does not compile with Maven.
> > >
> > > [ERROR]
> > >
> >
> /C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28]
> > > cannot find symbol
> > > symbol: class ProcessorContext
> > > location: interface org.apache.tamaya.spi.ConfigurationProcessor
> > > [INFO] 1 error
> > >
> > > I'm not sure, if the term "ConfigurationProcessor" for what used to be
> a
> > > "*Source" really sticks. But being able to compile and run it
> especially
> > > with real life use cases (e.g. how the Joda module now works after
> those
> > > changes I'd be happy to start with.
> > >
> > > Regards,
> > >
> > > Werner
> > >
> > >
> > > On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <at...@gmail.com>
> > > wrote:
> > >
> > >> Hi guys
> > >>
> > >> as promised I have put together the current state of a streamlines API
> > >> including adaptions needed on all the current codebase. This can be
> > found at
> > >>
> > >> https://github.com/atsticks/tamaya-next
> > >>
> > >> The API especially is here:
> > >>
> > >>
> > >>
> >
> https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
> > >>
> > >> Short summary of the ideas:
> > >>
> > >> - define *Configuration* by simply providing String get(String
> key).
> > >> - organize configuration as an ordered list of "
> > >> *ConfigurationProcessor*" instances aka *processor chain*, which
> > >> basically are a more generic combination of PropertySource and
> > >> PropertyFilter, thus removing the need for PropertyFilter as well
> as
> > >> other heavy decision such as when to filter. The data access call
> is
> > simply String
> > >> get(String key, ConfigurationProcessorContext context);
> > >> - The *ConfigurationProcessorContext* gives access to the remaining
> > >> procerssor chain and also helps to reduce boilerplate code in the
> > >> implementations.
> > >> - The Configuration itself can be created using a
> > >> *ConfigurationBuilder*, which basically is a programmatic API to
> > >> construct the processor chain. This builder is provided by a
> > >> *ConfigurationBuilderFactory*.
> > >> - The factory also can load the default chain, which is the basic
> > >> mechanism we had in place, loading sources, source providers and
> use
> > their
> > >> ordinals for priorization. Nevertheless the factor allows to build
> > up your
> > >> own thing, or allows to reproduce the "default" configuration bas
> > calling
> > >> factory.loadDefaults().build();
> > >> - So the ConfigurationFactory is also the SPI used by the
> > >> ConfigurationProvider using the default functionality as described
> > >> above.
> > >>
> > >> This results in 4 API artifacts and a SPI with another 4 artifacts,
> > which
> > >> allow us to do anything we already have with relatively controllable
> > >> efforts:
> > >> [image: Inline-Bild 1]
> > >>
> > >>
> > >> Just a few side nodes:
> > >>
> > >>
> > >> - there is the adapter extension (*tamaya-adapter*), which allows
> you
> > >> give an adapter singleton to adapt configuration to something else.
> > E.g.
> > >> this allows us to add functionality for types and defaults:
> > >> TypedConfiguration cfg =
> > >> ConfigAdapterManager.adapt(TypedConfiguration.class);
> > >> ConfigWithDefaults cfg2 =
> > >> ConfigAdapterManager.adapt(ConfigWithDefaults.class);
> > >> ...
> > >> - Similarly ConfigProcessor instances can implement Mixin
> Interfaces
> > >> such as Scannable (another module SPI from *tamaya-scannable*) to
> > >> provide additional capabilities. This can similalry used to provide
> > access
> > >> with getProperties().
> > >>
> > >> I will be now on holidays for 2 weeks. I will be able to answer
> mails,
> > >> but will not have access to a notebook or a computer bigger than my
> > >> smartphone. So hangouts work well, coding will be limited ;). Please
> > look
> > >> at the code (especially the API and core parts, the modules are not
> yet
> > >> fully buildable ;) ).
> > >>
> > >> J Anatole
> > >>
> > >> Suggestion/question: next hangout on Monday evening ?
> > >>
> > >>
> > >> --
> > >> *Anatole Tresch*
> > >> PPMC Member Apache Tamaya
> > >> JCP Star Spec Lead
> > >> *Switzerland, Europe Zurich, GMT+1*
> > >> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/>
> *
> > >> *Twitter: @atsticks, @tamayaconf*
> > >>
> > >>
> > >
> >
>
Re: GH Repo
Posted by "John D. Ament" <jo...@apache.org>.
One of the curious things I've always noted with Tamaya was that it tries
to deal with both the configuration retrieval and configuration creation
aspects. Realistically, these are two different concerns. Without me
being able to say that a service is able to do updates, I would expect a
different set of permissions.
John
On Sun, Jul 31, 2016 at 12:42 PM Werner Keil <we...@gmail.com> wrote:
> First of all ProcessorContext is missing;-|
>
> There's a lot of cleaning and even more documenting to do now.
> The chain and possible combinations of various API elements draws a pretty
> confusing picture. I.E. what possible combinations of
>
> - MutableConfiguration
> - ScannableConfiguration and the newly introduced
> - TypedConfiguration
>
> should there be?;-O
>
> The most basic examples all fail, especially because getProperties() no
> longer exists. Even java.util.Properties had more than one variation of
> that:
>
> https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#stringPropertyNames()
>
> The statement
> >Properties whose key or value is not of type String are omitted.
> sounds a bit weird because like the newly-proposed Configuration interface
> java.util.Properties only returns String values;-)
>
> Would be interesting to see it working, also down to at least the most
> basic examples.
>
> Regards,
>
> Werner
>
>
>
> On Sun, Jul 31, 2016 at 4:52 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Hi,
> >
> > How did a "bloated" Tamaya with a total codebase of just under 2MB in
> > master suddenly become over 20 MB in the "lean" version?;-O
> >
> > Also the "code" part (which is what should be sufficient to build the
> > minimalistic API) does not compile with Maven.
> >
> > [ERROR]
> >
> /C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28]
> > cannot find symbol
> > symbol: class ProcessorContext
> > location: interface org.apache.tamaya.spi.ConfigurationProcessor
> > [INFO] 1 error
> >
> > I'm not sure, if the term "ConfigurationProcessor" for what used to be a
> > "*Source" really sticks. But being able to compile and run it especially
> > with real life use cases (e.g. how the Joda module now works after those
> > changes I'd be happy to start with.
> >
> > Regards,
> >
> > Werner
> >
> >
> > On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <at...@gmail.com>
> > wrote:
> >
> >> Hi guys
> >>
> >> as promised I have put together the current state of a streamlines API
> >> including adaptions needed on all the current codebase. This can be
> found at
> >>
> >> https://github.com/atsticks/tamaya-next
> >>
> >> The API especially is here:
> >>
> >>
> >>
> https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
> >>
> >> Short summary of the ideas:
> >>
> >> - define *Configuration* by simply providing String get(String key).
> >> - organize configuration as an ordered list of "
> >> *ConfigurationProcessor*" instances aka *processor chain*, which
> >> basically are a more generic combination of PropertySource and
> >> PropertyFilter, thus removing the need for PropertyFilter as well as
> >> other heavy decision such as when to filter. The data access call is
> simply String
> >> get(String key, ConfigurationProcessorContext context);
> >> - The *ConfigurationProcessorContext* gives access to the remaining
> >> procerssor chain and also helps to reduce boilerplate code in the
> >> implementations.
> >> - The Configuration itself can be created using a
> >> *ConfigurationBuilder*, which basically is a programmatic API to
> >> construct the processor chain. This builder is provided by a
> >> *ConfigurationBuilderFactory*.
> >> - The factory also can load the default chain, which is the basic
> >> mechanism we had in place, loading sources, source providers and use
> their
> >> ordinals for priorization. Nevertheless the factor allows to build
> up your
> >> own thing, or allows to reproduce the "default" configuration bas
> calling
> >> factory.loadDefaults().build();
> >> - So the ConfigurationFactory is also the SPI used by the
> >> ConfigurationProvider using the default functionality as described
> >> above.
> >>
> >> This results in 4 API artifacts and a SPI with another 4 artifacts,
> which
> >> allow us to do anything we already have with relatively controllable
> >> efforts:
> >> [image: Inline-Bild 1]
> >>
> >>
> >> Just a few side nodes:
> >>
> >>
> >> - there is the adapter extension (*tamaya-adapter*), which allows you
> >> give an adapter singleton to adapt configuration to something else.
> E.g.
> >> this allows us to add functionality for types and defaults:
> >> TypedConfiguration cfg =
> >> ConfigAdapterManager.adapt(TypedConfiguration.class);
> >> ConfigWithDefaults cfg2 =
> >> ConfigAdapterManager.adapt(ConfigWithDefaults.class);
> >> ...
> >> - Similarly ConfigProcessor instances can implement Mixin Interfaces
> >> such as Scannable (another module SPI from *tamaya-scannable*) to
> >> provide additional capabilities. This can similalry used to provide
> access
> >> with getProperties().
> >>
> >> I will be now on holidays for 2 weeks. I will be able to answer mails,
> >> but will not have access to a notebook or a computer bigger than my
> >> smartphone. So hangouts work well, coding will be limited ;). Please
> look
> >> at the code (especially the API and core parts, the modules are not yet
> >> fully buildable ;) ).
> >>
> >> J Anatole
> >>
> >> Suggestion/question: next hangout on Monday evening ?
> >>
> >>
> >> --
> >> *Anatole Tresch*
> >> PPMC Member Apache Tamaya
> >> JCP Star Spec Lead
> >> *Switzerland, Europe Zurich, GMT+1*
> >> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> >> *Twitter: @atsticks, @tamayaconf*
> >>
> >>
> >
>
Re: GH Repo
Posted by Werner Keil <we...@gmail.com>.
First of all ProcessorContext is missing;-|
There's a lot of cleaning and even more documenting to do now.
The chain and possible combinations of various API elements draws a pretty
confusing picture. I.E. what possible combinations of
- MutableConfiguration
- ScannableConfiguration and the newly introduced
- TypedConfiguration
should there be?;-O
The most basic examples all fail, especially because getProperties() no
longer exists. Even java.util.Properties had more than one variation of
that:
https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#stringPropertyNames()
The statement
>Properties whose key or value is not of type String are omitted.
sounds a bit weird because like the newly-proposed Configuration interface
java.util.Properties only returns String values;-)
Would be interesting to see it working, also down to at least the most
basic examples.
Regards,
Werner
On Sun, Jul 31, 2016 at 4:52 PM, Werner Keil <we...@gmail.com> wrote:
> Hi,
>
> How did a "bloated" Tamaya with a total codebase of just under 2MB in
> master suddenly become over 20 MB in the "lean" version?;-O
>
> Also the "code" part (which is what should be sufficient to build the
> minimalistic API) does not compile with Maven.
>
> [ERROR]
> /C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28]
> cannot find symbol
> symbol: class ProcessorContext
> location: interface org.apache.tamaya.spi.ConfigurationProcessor
> [INFO] 1 error
>
> I'm not sure, if the term "ConfigurationProcessor" for what used to be a
> "*Source" really sticks. But being able to compile and run it especially
> with real life use cases (e.g. how the Joda module now works after those
> changes I'd be happy to start with.
>
> Regards,
>
> Werner
>
>
> On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <at...@gmail.com>
> wrote:
>
>> Hi guys
>>
>> as promised I have put together the current state of a streamlines API
>> including adaptions needed on all the current codebase. This can be found at
>>
>> https://github.com/atsticks/tamaya-next
>>
>> The API especially is here:
>>
>>
>> https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
>>
>> Short summary of the ideas:
>>
>> - define *Configuration* by simply providing String get(String key).
>> - organize configuration as an ordered list of "
>> *ConfigurationProcessor*" instances aka *processor chain*, which
>> basically are a more generic combination of PropertySource and
>> PropertyFilter, thus removing the need for PropertyFilter as well as
>> other heavy decision such as when to filter. The data access call is simply String
>> get(String key, ConfigurationProcessorContext context);
>> - The *ConfigurationProcessorContext* gives access to the remaining
>> procerssor chain and also helps to reduce boilerplate code in the
>> implementations.
>> - The Configuration itself can be created using a
>> *ConfigurationBuilder*, which basically is a programmatic API to
>> construct the processor chain. This builder is provided by a
>> *ConfigurationBuilderFactory*.
>> - The factory also can load the default chain, which is the basic
>> mechanism we had in place, loading sources, source providers and use their
>> ordinals for priorization. Nevertheless the factor allows to build up your
>> own thing, or allows to reproduce the "default" configuration bas calling
>> factory.loadDefaults().build();
>> - So the ConfigurationFactory is also the SPI used by the
>> ConfigurationProvider using the default functionality as described
>> above.
>>
>> This results in 4 API artifacts and a SPI with another 4 artifacts, which
>> allow us to do anything we already have with relatively controllable
>> efforts:
>> [image: Inline-Bild 1]
>>
>>
>> Just a few side nodes:
>>
>>
>> - there is the adapter extension (*tamaya-adapter*), which allows you
>> give an adapter singleton to adapt configuration to something else. E.g.
>> this allows us to add functionality for types and defaults:
>> TypedConfiguration cfg =
>> ConfigAdapterManager.adapt(TypedConfiguration.class);
>> ConfigWithDefaults cfg2 =
>> ConfigAdapterManager.adapt(ConfigWithDefaults.class);
>> ...
>> - Similarly ConfigProcessor instances can implement Mixin Interfaces
>> such as Scannable (another module SPI from *tamaya-scannable*) to
>> provide additional capabilities. This can similalry used to provide access
>> with getProperties().
>>
>> I will be now on holidays for 2 weeks. I will be able to answer mails,
>> but will not have access to a notebook or a computer bigger than my
>> smartphone. So hangouts work well, coding will be limited ;). Please look
>> at the code (especially the API and core parts, the modules are not yet
>> fully buildable ;) ).
>>
>> J Anatole
>>
>> Suggestion/question: next hangout on Monday evening ?
>>
>>
>> --
>> *Anatole Tresch*
>> PPMC Member Apache Tamaya
>> JCP Star Spec Lead
>> *Switzerland, Europe Zurich, GMT+1*
>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
>> *Twitter: @atsticks, @tamayaconf*
>>
>>
>
Re: GH Repo
Posted by Werner Keil <we...@gmail.com>.
Hi,
How did a "bloated" Tamaya with a total codebase of just under 2MB in
master suddenly become over 20 MB in the "lean" version?;-O
Also the "code" part (which is what should be sufficient to build the
minimalistic API) does not compile with Maven.
[ERROR]
/C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28]
cannot find symbol
symbol: class ProcessorContext
location: interface org.apache.tamaya.spi.ConfigurationProcessor
[INFO] 1 error
I'm not sure, if the term "ConfigurationProcessor" for what used to be a
"*Source" really sticks. But being able to compile and run it especially
with real life use cases (e.g. how the Joda module now works after those
changes I'd be happy to start with.
Regards,
Werner
On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <at...@gmail.com> wrote:
> Hi guys
>
> as promised I have put together the current state of a streamlines API
> including adaptions needed on all the current codebase. This can be found at
>
> https://github.com/atsticks/tamaya-next
>
> The API especially is here:
>
>
> https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya
>
> Short summary of the ideas:
>
> - define *Configuration* by simply providing String get(String key).
> - organize configuration as an ordered list of "
> *ConfigurationProcessor*" instances aka *processor chain*, which
> basically are a more generic combination of PropertySource and
> PropertyFilter, thus removing the need for PropertyFilter as well as
> other heavy decision such as when to filter. The data access call is simply String
> get(String key, ConfigurationProcessorContext context);
> - The *ConfigurationProcessorContext* gives access to the remaining
> procerssor chain and also helps to reduce boilerplate code in the
> implementations.
> - The Configuration itself can be created using a
> *ConfigurationBuilder*, which basically is a programmatic API to
> construct the processor chain. This builder is provided by a
> *ConfigurationBuilderFactory*.
> - The factory also can load the default chain, which is the basic
> mechanism we had in place, loading sources, source providers and use their
> ordinals for priorization. Nevertheless the factor allows to build up your
> own thing, or allows to reproduce the "default" configuration bas calling
> factory.loadDefaults().build();
> - So the ConfigurationFactory is also the SPI used by the
> ConfigurationProvider using the default functionality as described
> above.
>
> This results in 4 API artifacts and a SPI with another 4 artifacts, which
> allow us to do anything we already have with relatively controllable
> efforts:
> [image: Inline-Bild 1]
>
>
> Just a few side nodes:
>
>
> - there is the adapter extension (*tamaya-adapter*), which allows you
> give an adapter singleton to adapt configuration to something else. E.g.
> this allows us to add functionality for types and defaults:
> TypedConfiguration cfg =
> ConfigAdapterManager.adapt(TypedConfiguration.class);
> ConfigWithDefaults cfg2 =
> ConfigAdapterManager.adapt(ConfigWithDefaults.class);
> ...
> - Similarly ConfigProcessor instances can implement Mixin Interfaces
> such as Scannable (another module SPI from *tamaya-scannable*) to
> provide additional capabilities. This can similalry used to provide access
> with getProperties().
>
> I will be now on holidays for 2 weeks. I will be able to answer mails,
> but will not have access to a notebook or a computer bigger than my
> smartphone. So hangouts work well, coding will be limited ;). Please look
> at the code (especially the API and core parts, the modules are not yet
> fully buildable ;) ).
>
> J Anatole
>
> Suggestion/question: next hangout on Monday evening ?
>
>
> --
> *Anatole Tresch*
> PPMC Member Apache Tamaya
> JCP Star Spec Lead
> *Switzerland, Europe Zurich, GMT+1*
> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> *
> *Twitter: @atsticks, @tamayaconf*
>
>