You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2015/04/16 22:30:17 UTC
bol.com Hackathon
Hello,
As I might have mentioned before, we internally use a slightly enhanced
version of Apache DeviceMap at bol.com. Tomorrow there will be an all day
long in-company Hackathon. There I plan to build a website
whatismyuseragent.nl, where visitors are displayed the list of attributes
returned by Apache DeviceMap. Further, they will be able to submit their
enhancements by just updating the displayed values and hitting enter. The
submission will end up as a GitHub issue. While the visuals still suck (the
design is on the way), mechanics are more or less complete and the source
code is accessible at https://github.com/vy/what-is-my-user-agent address.
I believe this will bring some visibility to the project and have a
potential to improve the DDR data. (Would Apache DM be willing to host such
an application officially and connect it to their own JIRA system?)
Within the project, I had employed the following mechanics that I also want
to incorporate into Apache DeviceMap:
1. In addition to a *DeviceAttributes*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java>
class consisting of a generic *Map<String,String>* field (as is the case
for DM), I also implemented a *ApacheDeviceAttributes*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java>
subclass such that all known device attributes (manually collected from DDR
sources) are represented as fields. This allows the programmer to replace
*if (attrs.containsKey("ajaxSupportJavaScript")) {
boolean ajaxSupportJavaScript =
Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
like boilerplate with an
*Optional<Boolean> ajaxSupportJavaScript*.
*Optional<T>* introduces a Java 8 dependency. Hence, we might want to
replace it with a custom *Attribute<T>* class. But the attributes as a
statically typed class field still holds its type-safe promise, I believe.
2. Used enums for representing attributes with a fixed set of values, that
is, *DeviceOs*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java>,
*InputDevice*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java>,
and *MobileBrowser*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java>.
(Values are collected from DDR.)
3. Added a *DeviceType*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java>
class for classifying a User-Agent into the following categories:
- Mini: head up displays, smart watches, -3”, minimal controls
- Mobile: smart phone, phablet, -6”, game device, touch enabled
- Tablet: touch enabled, 7”-13”
- E-Reader: greyscale, e-Ink, fixed fonts, -10”
- Desktop: PC, laptop, notebook mouse/keyboard, 11”-
- TV: smart TV, set top box, streaming device, 40”-
- Maxi: cinema, tv walls, 100”-, minimal controls
- SEO Agent: search bots
This is a work in progress and as of now, only Mobile, Tablet, Desktop, and
SEO Agent options are supported.
4. Introduced a two-phased parsing pipeline to determine the *DeviceType*.
One that depends on the User-Agent (for instance, you can easily
differentiate a Googlebot without the need for DM attribute extraction to
kick in), and another one that depends on both the User-Agent and extracted
attributes.
5. Enriched the bot database using *BuilderDataSourcePatch.xml*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml>
file. (Actually, I had already submitted the very same bots as a JIRA
issue, but had no effect so far.)
6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
<https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46>
rather than a *DeviceType.SEO_AGENT*. This is of crucial importance, since
Googlebot Mobile needs to spider the website and determine whether it is
mobile-friendly or not, which has a direct impact in the Google rankings.
We can directly implement some of these changes in the existing code base,
and some will preferably require a new (and probably backward incompatible)
API. Maybe this will also be a good motivation for a separate 2.0 version
as Reza recommended. (I hope I got Reza's intention after long
discussions.) Put another way, or as Werner said there is no harm in
maintaining two separate drivers/DDRs. Ideas?
Best.
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
OK, will check on the form Bertrand mentioned. If there's a minimun length
there or your choice was already taken, I'll let you know.
Otherwise CC (on a thread we already had for this process) the list with
feedback.
Werner
On Mon, Apr 20, 2015 at 8:23 PM, Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hello Werner,
>
> The Hackathon went well, but I need to confess that I worked on an Elastic
> Search project mostly -- I thought that the DM-related project I shared is
> almost complete, just missing a decent hosting and design. Nevertheless,
> for a couple of days I will be working on it in the weekends. Coming back
> to your comments...
>
> Java 8 is not an issue. I agree that we need to support *even* Java 6,
> unfortunately.
> For Lombok, I will definitely miss it but I can live without it.
>
> I really support the idea of having an Optional<T> type instead of exposing
> a null to the client. If we would implement our own Optional, since the
> user will be just consuming an immutable data structure, it will not
> interfere with Java 8's or Guava's Optionals. Maybe we can even rename it
> to OptionalAttribute<T> or something else. But my 2 cents are 1) employing
> Optionals and 2) introducing properly typed (using
> enum/int/string/float/etc.) class fields in addition to a raw
> Map<String,String>.
>
> And "vy" is fine for username.
>
> On Mon, Apr 20, 2015 at 5:37 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Volkan,
> >
> > How did your hackathon go?
> >
> > To progress with the already approved committer role (and you also
> pointed
> > out here e.g. under 5., that some patches and fixes you offered were not
> > followed-up for reasons we we know from other threads)
> >
> > A lot of the GitHub project sounds exciting and as long as you're the
> sole
> > contributor or hold all IP you'd be able to contribute appropriate
> > improvements to DeviceMap. Maybe already advanced enough for a 2.x
> > branch;-)
> >
> > About the Java 8 dependency, that's up to what others think. I know Java
> 7
> > and even 6 is still widely used, so despite Oracle and some JUGs heavily
> > pushing for everyone to use only SE 8 now, reality looks different here,
> > too, and "legacy" doesn't always just vanish even if a new version or two
> > are available and may even work better for some cases.
> >
> > The other dependencies, we discussed Lombok earlier, I can't say if it
> > makes sense, but unless there is a complete license no-go with Apache for
> > some reason, either of them could be fine. Guava inspired Java 8 a lot,
> > e.g. Optional etc. existed there before (so one could use
> > com.google.common.base.Optional
> > in a Java 6/7 version of the same code and in a Java 8 branch stick to
> the
> > SE 8 native one java.util.Optional)
> >
> >
> > What is the preferred Apache user name you would like to use?
> > Just "vy" like on GitHub, if there's no minimal length, it might work,
> > otherwise what do you prefer?
> >
> > Thanks,
> > Werner
> >
> >
> >
> > On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <volkan.yazici@gmail.com
> >
> > wrote:
> >
> > > Hello,
> > >
> > > As I might have mentioned before, we internally use a slightly enhanced
> > > version of Apache DeviceMap at bol.com. Tomorrow there will be an all
> > day
> > > long in-company Hackathon. There I plan to build a website
> > > whatismyuseragent.nl, where visitors are displayed the list of
> > attributes
> > > returned by Apache DeviceMap. Further, they will be able to submit
> their
> > > enhancements by just updating the displayed values and hitting enter.
> The
> > > submission will end up as a GitHub issue. While the visuals still suck
> > (the
> > > design is on the way), mechanics are more or less complete and the
> source
> > > code is accessible at https://github.com/vy/what-is-my-user-agent
> > address.
> > > I believe this will bring some visibility to the project and have a
> > > potential to improve the DDR data. (Would Apache DM be willing to host
> > such
> > > an application officially and connect it to their own JIRA system?)
> > >
> > > Within the project, I had employed the following mechanics that I also
> > want
> > > to incorporate into Apache DeviceMap:
> > >
> > > 1. In addition to a *DeviceAttributes*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> > > >
> > > class consisting of a generic *Map<String,String>* field (as is the
> case
> > > for DM), I also implemented a *ApacheDeviceAttributes*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> > > >
> > > subclass such that all known device attributes (manually collected from
> > DDR
> > > sources) are represented as fields. This allows the programmer to
> replace
> > >
> > >
> > >
> > >
> > >
> > >
> > > *if (attrs.containsKey("ajaxSupportJavaScript")) {
> > > boolean ajaxSupportJavaScript =
> > > Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> > > like boilerplate with an
> > >
> > > *Optional<Boolean> ajaxSupportJavaScript*.
> > >
> > > *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> > > replace it with a custom *Attribute<T>* class. But the attributes as a
> > > statically typed class field still holds its type-safe promise, I
> > believe.
> > >
> > > 2. Used enums for representing attributes with a fixed set of values,
> > that
> > > is, *DeviceOs*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> > > >,
> > > *InputDevice*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> > > >,
> > > and *MobileBrowser*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> > > >.
> > > (Values are collected from DDR.)
> > >
> > > 3. Added a *DeviceType*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> > > >
> > > class for classifying a User-Agent into the following categories:
> > >
> > > - Mini: head up displays, smart watches, -3”, minimal controls
> > > - Mobile: smart phone, phablet, -6”, game device, touch enabled
> > > - Tablet: touch enabled, 7”-13”
> > > - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> > > - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> > > - TV: smart TV, set top box, streaming device, 40”-
> > > - Maxi: cinema, tv walls, 100”-, minimal controls
> > > - SEO Agent: search bots
> > >
> > > This is a work in progress and as of now, only Mobile, Tablet, Desktop,
> > and
> > > SEO Agent options are supported.
> > >
> > > 4. Introduced a two-phased parsing pipeline to determine the
> > *DeviceType*.
> > > One that depends on the User-Agent (for instance, you can easily
> > > differentiate a Googlebot without the need for DM attribute extraction
> to
> > > kick in), and another one that depends on both the User-Agent and
> > extracted
> > > attributes.
> > >
> > > 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> > > >
> > > file. (Actually, I had already submitted the very same bots as a JIRA
> > > issue, but had no effect so far.)
> > >
> > > 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> > > >
> > > rather than a *DeviceType.SEO_AGENT*. This is of crucial importance,
> > since
> > > Googlebot Mobile needs to spider the website and determine whether it
> is
> > > mobile-friendly or not, which has a direct impact in the Google
> rankings.
> > >
> > > We can directly implement some of these changes in the existing code
> > base,
> > > and some will preferably require a new (and probably backward
> > incompatible)
> > > API. Maybe this will also be a good motivation for a separate 2.0
> version
> > > as Reza recommended. (I hope I got Reza's intention after long
> > > discussions.) Put another way, or as Werner said there is no harm in
> > > maintaining two separate drivers/DDRs. Ideas?
> > >
> > > Best.
> > >
> >
>
Re: bol.com Hackathon
Posted by Volkan Yazıcı <vo...@gmail.com>.
Using something in the line of attributes.getBoolean("isBot") is also fine.
But my experience with "isBot" like string literals is that it is not
possible to detect some bugs at compile time where type-safety provides
this to you for free. Say you mis-typed "isBot", or isBot returns a string
instead of a boolean, etc. then you need to wait for a runtime crash to
figure that out.
On Tue, Apr 21, 2015 at 2:06 AM, Werner Keil <we...@gmail.com> wrote:
> Leaving the Java 8 or Guava aspects aside, should you (like at least the
> last 1 or 2 messages by Reza also suggest) consider a W3C compliant
> interface to the outside world from some of these classes, the attribute
> storage is effectively not really that different from the W3C interfaces.
>
> public boolean getBoolean(String key) { return Boolean.
> parseBoolean(attributes.get(key)); }has enough similarity to
>
> http://www.w3.org/TR/DDR-Simple-API/javadoc/org/w3c/ddr/simple/PropertyValue.html#getBoolean()
> Except the property value is a "Value Object" and the getter happens
> before, but depending on how you implement it, you'd also find a map or a
> map of maps.
>
> Werner
>
> On Mon, Apr 20, 2015 at 8:23 PM, Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > Hello Werner,
> >
> > The Hackathon went well, but I need to confess that I worked on an
> Elastic
> > Search project mostly -- I thought that the DM-related project I shared
> is
> > almost complete, just missing a decent hosting and design. Nevertheless,
> > for a couple of days I will be working on it in the weekends. Coming back
> > to your comments...
> >
> > Java 8 is not an issue. I agree that we need to support *even* Java 6,
> > unfortunately.
> > For Lombok, I will definitely miss it but I can live without it.
> >
> > I really support the idea of having an Optional<T> type instead of
> exposing
> > a null to the client. If we would implement our own Optional, since the
> > user will be just consuming an immutable data structure, it will not
> > interfere with Java 8's or Guava's Optionals. Maybe we can even rename it
> > to OptionalAttribute<T> or something else. But my 2 cents are 1)
> employing
> > Optionals and 2) introducing properly typed (using
> > enum/int/string/float/etc.) class fields in addition to a raw
> > Map<String,String>.
> >
> > And "vy" is fine for username.
> >
> > On Mon, Apr 20, 2015 at 5:37 PM, Werner Keil <we...@gmail.com>
> > wrote:
> >
> > > Volkan,
> > >
> > > How did your hackathon go?
> > >
> > > To progress with the already approved committer role (and you also
> > pointed
> > > out here e.g. under 5., that some patches and fixes you offered were
> not
> > > followed-up for reasons we we know from other threads)
> > >
> > > A lot of the GitHub project sounds exciting and as long as you're the
> > sole
> > > contributor or hold all IP you'd be able to contribute appropriate
> > > improvements to DeviceMap. Maybe already advanced enough for a 2.x
> > > branch;-)
> > >
> > > About the Java 8 dependency, that's up to what others think. I know
> Java
> > 7
> > > and even 6 is still widely used, so despite Oracle and some JUGs
> heavily
> > > pushing for everyone to use only SE 8 now, reality looks different
> here,
> > > too, and "legacy" doesn't always just vanish even if a new version or
> two
> > > are available and may even work better for some cases.
> > >
> > > The other dependencies, we discussed Lombok earlier, I can't say if it
> > > makes sense, but unless there is a complete license no-go with Apache
> for
> > > some reason, either of them could be fine. Guava inspired Java 8 a lot,
> > > e.g. Optional etc. existed there before (so one could use
> > > com.google.common.base.Optional
> > > in a Java 6/7 version of the same code and in a Java 8 branch stick to
> > the
> > > SE 8 native one java.util.Optional)
> > >
> > >
> > > What is the preferred Apache user name you would like to use?
> > > Just "vy" like on GitHub, if there's no minimal length, it might work,
> > > otherwise what do you prefer?
> > >
> > > Thanks,
> > > Werner
> > >
> > >
> > >
> > > On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <
> volkan.yazici@gmail.com
> > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > As I might have mentioned before, we internally use a slightly
> enhanced
> > > > version of Apache DeviceMap at bol.com. Tomorrow there will be an
> all
> > > day
> > > > long in-company Hackathon. There I plan to build a website
> > > > whatismyuseragent.nl, where visitors are displayed the list of
> > > attributes
> > > > returned by Apache DeviceMap. Further, they will be able to submit
> > their
> > > > enhancements by just updating the displayed values and hitting enter.
> > The
> > > > submission will end up as a GitHub issue. While the visuals still
> suck
> > > (the
> > > > design is on the way), mechanics are more or less complete and the
> > source
> > > > code is accessible at https://github.com/vy/what-is-my-user-agent
> > > address.
> > > > I believe this will bring some visibility to the project and have a
> > > > potential to improve the DDR data. (Would Apache DM be willing to
> host
> > > such
> > > > an application officially and connect it to their own JIRA system?)
> > > >
> > > > Within the project, I had employed the following mechanics that I
> also
> > > want
> > > > to incorporate into Apache DeviceMap:
> > > >
> > > > 1. In addition to a *DeviceAttributes*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> > > > >
> > > > class consisting of a generic *Map<String,String>* field (as is the
> > case
> > > > for DM), I also implemented a *ApacheDeviceAttributes*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> > > > >
> > > > subclass such that all known device attributes (manually collected
> from
> > > DDR
> > > > sources) are represented as fields. This allows the programmer to
> > replace
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *if (attrs.containsKey("ajaxSupportJavaScript")) {
> > > > boolean ajaxSupportJavaScript =
> > > > Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> > > > like boilerplate with an
> > > >
> > > > *Optional<Boolean> ajaxSupportJavaScript*.
> > > >
> > > > *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> > > > replace it with a custom *Attribute<T>* class. But the attributes as
> a
> > > > statically typed class field still holds its type-safe promise, I
> > > believe.
> > > >
> > > > 2. Used enums for representing attributes with a fixed set of values,
> > > that
> > > > is, *DeviceOs*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> > > > >,
> > > > *InputDevice*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> > > > >,
> > > > and *MobileBrowser*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> > > > >.
> > > > (Values are collected from DDR.)
> > > >
> > > > 3. Added a *DeviceType*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> > > > >
> > > > class for classifying a User-Agent into the following categories:
> > > >
> > > > - Mini: head up displays, smart watches, -3”, minimal controls
> > > > - Mobile: smart phone, phablet, -6”, game device, touch enabled
> > > > - Tablet: touch enabled, 7”-13”
> > > > - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> > > > - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> > > > - TV: smart TV, set top box, streaming device, 40”-
> > > > - Maxi: cinema, tv walls, 100”-, minimal controls
> > > > - SEO Agent: search bots
> > > >
> > > > This is a work in progress and as of now, only Mobile, Tablet,
> Desktop,
> > > and
> > > > SEO Agent options are supported.
> > > >
> > > > 4. Introduced a two-phased parsing pipeline to determine the
> > > *DeviceType*.
> > > > One that depends on the User-Agent (for instance, you can easily
> > > > differentiate a Googlebot without the need for DM attribute
> extraction
> > to
> > > > kick in), and another one that depends on both the User-Agent and
> > > extracted
> > > > attributes.
> > > >
> > > > 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> > > > >
> > > > file. (Actually, I had already submitted the very same bots as a JIRA
> > > > issue, but had no effect so far.)
> > > >
> > > > 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> > > > <
> > > >
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> > > > >
> > > > rather than a *DeviceType.SEO_AGENT*. This is of crucial importance,
> > > since
> > > > Googlebot Mobile needs to spider the website and determine whether it
> > is
> > > > mobile-friendly or not, which has a direct impact in the Google
> > rankings.
> > > >
> > > > We can directly implement some of these changes in the existing code
> > > base,
> > > > and some will preferably require a new (and probably backward
> > > incompatible)
> > > > API. Maybe this will also be a good motivation for a separate 2.0
> > version
> > > > as Reza recommended. (I hope I got Reza's intention after long
> > > > discussions.) Put another way, or as Werner said there is no harm in
> > > > maintaining two separate drivers/DDRs. Ideas?
> > > >
> > > > Best.
> > > >
> > >
> >
>
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
Leaving the Java 8 or Guava aspects aside, should you (like at least the
last 1 or 2 messages by Reza also suggest) consider a W3C compliant
interface to the outside world from some of these classes, the attribute
storage is effectively not really that different from the W3C interfaces.
public boolean getBoolean(String key) { return Boolean.
parseBoolean(attributes.get(key)); }has enough similarity to
http://www.w3.org/TR/DDR-Simple-API/javadoc/org/w3c/ddr/simple/PropertyValue.html#getBoolean()
Except the property value is a "Value Object" and the getter happens
before, but depending on how you implement it, you'd also find a map or a
map of maps.
Werner
On Mon, Apr 20, 2015 at 8:23 PM, Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hello Werner,
>
> The Hackathon went well, but I need to confess that I worked on an Elastic
> Search project mostly -- I thought that the DM-related project I shared is
> almost complete, just missing a decent hosting and design. Nevertheless,
> for a couple of days I will be working on it in the weekends. Coming back
> to your comments...
>
> Java 8 is not an issue. I agree that we need to support *even* Java 6,
> unfortunately.
> For Lombok, I will definitely miss it but I can live without it.
>
> I really support the idea of having an Optional<T> type instead of exposing
> a null to the client. If we would implement our own Optional, since the
> user will be just consuming an immutable data structure, it will not
> interfere with Java 8's or Guava's Optionals. Maybe we can even rename it
> to OptionalAttribute<T> or something else. But my 2 cents are 1) employing
> Optionals and 2) introducing properly typed (using
> enum/int/string/float/etc.) class fields in addition to a raw
> Map<String,String>.
>
> And "vy" is fine for username.
>
> On Mon, Apr 20, 2015 at 5:37 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Volkan,
> >
> > How did your hackathon go?
> >
> > To progress with the already approved committer role (and you also
> pointed
> > out here e.g. under 5., that some patches and fixes you offered were not
> > followed-up for reasons we we know from other threads)
> >
> > A lot of the GitHub project sounds exciting and as long as you're the
> sole
> > contributor or hold all IP you'd be able to contribute appropriate
> > improvements to DeviceMap. Maybe already advanced enough for a 2.x
> > branch;-)
> >
> > About the Java 8 dependency, that's up to what others think. I know Java
> 7
> > and even 6 is still widely used, so despite Oracle and some JUGs heavily
> > pushing for everyone to use only SE 8 now, reality looks different here,
> > too, and "legacy" doesn't always just vanish even if a new version or two
> > are available and may even work better for some cases.
> >
> > The other dependencies, we discussed Lombok earlier, I can't say if it
> > makes sense, but unless there is a complete license no-go with Apache for
> > some reason, either of them could be fine. Guava inspired Java 8 a lot,
> > e.g. Optional etc. existed there before (so one could use
> > com.google.common.base.Optional
> > in a Java 6/7 version of the same code and in a Java 8 branch stick to
> the
> > SE 8 native one java.util.Optional)
> >
> >
> > What is the preferred Apache user name you would like to use?
> > Just "vy" like on GitHub, if there's no minimal length, it might work,
> > otherwise what do you prefer?
> >
> > Thanks,
> > Werner
> >
> >
> >
> > On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <volkan.yazici@gmail.com
> >
> > wrote:
> >
> > > Hello,
> > >
> > > As I might have mentioned before, we internally use a slightly enhanced
> > > version of Apache DeviceMap at bol.com. Tomorrow there will be an all
> > day
> > > long in-company Hackathon. There I plan to build a website
> > > whatismyuseragent.nl, where visitors are displayed the list of
> > attributes
> > > returned by Apache DeviceMap. Further, they will be able to submit
> their
> > > enhancements by just updating the displayed values and hitting enter.
> The
> > > submission will end up as a GitHub issue. While the visuals still suck
> > (the
> > > design is on the way), mechanics are more or less complete and the
> source
> > > code is accessible at https://github.com/vy/what-is-my-user-agent
> > address.
> > > I believe this will bring some visibility to the project and have a
> > > potential to improve the DDR data. (Would Apache DM be willing to host
> > such
> > > an application officially and connect it to their own JIRA system?)
> > >
> > > Within the project, I had employed the following mechanics that I also
> > want
> > > to incorporate into Apache DeviceMap:
> > >
> > > 1. In addition to a *DeviceAttributes*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> > > >
> > > class consisting of a generic *Map<String,String>* field (as is the
> case
> > > for DM), I also implemented a *ApacheDeviceAttributes*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> > > >
> > > subclass such that all known device attributes (manually collected from
> > DDR
> > > sources) are represented as fields. This allows the programmer to
> replace
> > >
> > >
> > >
> > >
> > >
> > >
> > > *if (attrs.containsKey("ajaxSupportJavaScript")) {
> > > boolean ajaxSupportJavaScript =
> > > Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> > > like boilerplate with an
> > >
> > > *Optional<Boolean> ajaxSupportJavaScript*.
> > >
> > > *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> > > replace it with a custom *Attribute<T>* class. But the attributes as a
> > > statically typed class field still holds its type-safe promise, I
> > believe.
> > >
> > > 2. Used enums for representing attributes with a fixed set of values,
> > that
> > > is, *DeviceOs*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> > > >,
> > > *InputDevice*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> > > >,
> > > and *MobileBrowser*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> > > >.
> > > (Values are collected from DDR.)
> > >
> > > 3. Added a *DeviceType*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> > > >
> > > class for classifying a User-Agent into the following categories:
> > >
> > > - Mini: head up displays, smart watches, -3”, minimal controls
> > > - Mobile: smart phone, phablet, -6”, game device, touch enabled
> > > - Tablet: touch enabled, 7”-13”
> > > - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> > > - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> > > - TV: smart TV, set top box, streaming device, 40”-
> > > - Maxi: cinema, tv walls, 100”-, minimal controls
> > > - SEO Agent: search bots
> > >
> > > This is a work in progress and as of now, only Mobile, Tablet, Desktop,
> > and
> > > SEO Agent options are supported.
> > >
> > > 4. Introduced a two-phased parsing pipeline to determine the
> > *DeviceType*.
> > > One that depends on the User-Agent (for instance, you can easily
> > > differentiate a Googlebot without the need for DM attribute extraction
> to
> > > kick in), and another one that depends on both the User-Agent and
> > extracted
> > > attributes.
> > >
> > > 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> > > >
> > > file. (Actually, I had already submitted the very same bots as a JIRA
> > > issue, but had no effect so far.)
> > >
> > > 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> > > <
> > >
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> > > >
> > > rather than a *DeviceType.SEO_AGENT*. This is of crucial importance,
> > since
> > > Googlebot Mobile needs to spider the website and determine whether it
> is
> > > mobile-friendly or not, which has a direct impact in the Google
> rankings.
> > >
> > > We can directly implement some of these changes in the existing code
> > base,
> > > and some will preferably require a new (and probably backward
> > incompatible)
> > > API. Maybe this will also be a good motivation for a separate 2.0
> version
> > > as Reza recommended. (I hope I got Reza's intention after long
> > > discussions.) Put another way, or as Werner said there is no harm in
> > > maintaining two separate drivers/DDRs. Ideas?
> > >
> > > Best.
> > >
> >
>
Re: bol.com Hackathon
Posted by Volkan Yazıcı <vo...@gmail.com>.
Hello Werner,
The Hackathon went well, but I need to confess that I worked on an Elastic
Search project mostly -- I thought that the DM-related project I shared is
almost complete, just missing a decent hosting and design. Nevertheless,
for a couple of days I will be working on it in the weekends. Coming back
to your comments...
Java 8 is not an issue. I agree that we need to support *even* Java 6,
unfortunately.
For Lombok, I will definitely miss it but I can live without it.
I really support the idea of having an Optional<T> type instead of exposing
a null to the client. If we would implement our own Optional, since the
user will be just consuming an immutable data structure, it will not
interfere with Java 8's or Guava's Optionals. Maybe we can even rename it
to OptionalAttribute<T> or something else. But my 2 cents are 1) employing
Optionals and 2) introducing properly typed (using
enum/int/string/float/etc.) class fields in addition to a raw
Map<String,String>.
And "vy" is fine for username.
On Mon, Apr 20, 2015 at 5:37 PM, Werner Keil <we...@gmail.com> wrote:
> Volkan,
>
> How did your hackathon go?
>
> To progress with the already approved committer role (and you also pointed
> out here e.g. under 5., that some patches and fixes you offered were not
> followed-up for reasons we we know from other threads)
>
> A lot of the GitHub project sounds exciting and as long as you're the sole
> contributor or hold all IP you'd be able to contribute appropriate
> improvements to DeviceMap. Maybe already advanced enough for a 2.x
> branch;-)
>
> About the Java 8 dependency, that's up to what others think. I know Java 7
> and even 6 is still widely used, so despite Oracle and some JUGs heavily
> pushing for everyone to use only SE 8 now, reality looks different here,
> too, and "legacy" doesn't always just vanish even if a new version or two
> are available and may even work better for some cases.
>
> The other dependencies, we discussed Lombok earlier, I can't say if it
> makes sense, but unless there is a complete license no-go with Apache for
> some reason, either of them could be fine. Guava inspired Java 8 a lot,
> e.g. Optional etc. existed there before (so one could use
> com.google.common.base.Optional
> in a Java 6/7 version of the same code and in a Java 8 branch stick to the
> SE 8 native one java.util.Optional)
>
>
> What is the preferred Apache user name you would like to use?
> Just "vy" like on GitHub, if there's no minimal length, it might work,
> otherwise what do you prefer?
>
> Thanks,
> Werner
>
>
>
> On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > Hello,
> >
> > As I might have mentioned before, we internally use a slightly enhanced
> > version of Apache DeviceMap at bol.com. Tomorrow there will be an all
> day
> > long in-company Hackathon. There I plan to build a website
> > whatismyuseragent.nl, where visitors are displayed the list of
> attributes
> > returned by Apache DeviceMap. Further, they will be able to submit their
> > enhancements by just updating the displayed values and hitting enter. The
> > submission will end up as a GitHub issue. While the visuals still suck
> (the
> > design is on the way), mechanics are more or less complete and the source
> > code is accessible at https://github.com/vy/what-is-my-user-agent
> address.
> > I believe this will bring some visibility to the project and have a
> > potential to improve the DDR data. (Would Apache DM be willing to host
> such
> > an application officially and connect it to their own JIRA system?)
> >
> > Within the project, I had employed the following mechanics that I also
> want
> > to incorporate into Apache DeviceMap:
> >
> > 1. In addition to a *DeviceAttributes*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> > >
> > class consisting of a generic *Map<String,String>* field (as is the case
> > for DM), I also implemented a *ApacheDeviceAttributes*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> > >
> > subclass such that all known device attributes (manually collected from
> DDR
> > sources) are represented as fields. This allows the programmer to replace
> >
> >
> >
> >
> >
> >
> > *if (attrs.containsKey("ajaxSupportJavaScript")) {
> > boolean ajaxSupportJavaScript =
> > Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> > like boilerplate with an
> >
> > *Optional<Boolean> ajaxSupportJavaScript*.
> >
> > *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> > replace it with a custom *Attribute<T>* class. But the attributes as a
> > statically typed class field still holds its type-safe promise, I
> believe.
> >
> > 2. Used enums for representing attributes with a fixed set of values,
> that
> > is, *DeviceOs*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> > >,
> > *InputDevice*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> > >,
> > and *MobileBrowser*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> > >.
> > (Values are collected from DDR.)
> >
> > 3. Added a *DeviceType*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> > >
> > class for classifying a User-Agent into the following categories:
> >
> > - Mini: head up displays, smart watches, -3”, minimal controls
> > - Mobile: smart phone, phablet, -6”, game device, touch enabled
> > - Tablet: touch enabled, 7”-13”
> > - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> > - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> > - TV: smart TV, set top box, streaming device, 40”-
> > - Maxi: cinema, tv walls, 100”-, minimal controls
> > - SEO Agent: search bots
> >
> > This is a work in progress and as of now, only Mobile, Tablet, Desktop,
> and
> > SEO Agent options are supported.
> >
> > 4. Introduced a two-phased parsing pipeline to determine the
> *DeviceType*.
> > One that depends on the User-Agent (for instance, you can easily
> > differentiate a Googlebot without the need for DM attribute extraction to
> > kick in), and another one that depends on both the User-Agent and
> extracted
> > attributes.
> >
> > 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> > >
> > file. (Actually, I had already submitted the very same bots as a JIRA
> > issue, but had no effect so far.)
> >
> > 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> > <
> >
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> > >
> > rather than a *DeviceType.SEO_AGENT*. This is of crucial importance,
> since
> > Googlebot Mobile needs to spider the website and determine whether it is
> > mobile-friendly or not, which has a direct impact in the Google rankings.
> >
> > We can directly implement some of these changes in the existing code
> base,
> > and some will preferably require a new (and probably backward
> incompatible)
> > API. Maybe this will also be a good motivation for a separate 2.0 version
> > as Reza recommended. (I hope I got Reza's intention after long
> > discussions.) Put another way, or as Werner said there is no harm in
> > maintaining two separate drivers/DDRs. Ideas?
> >
> > Best.
> >
>
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
Volkan,
How did your hackathon go?
To progress with the already approved committer role (and you also pointed
out here e.g. under 5., that some patches and fixes you offered were not
followed-up for reasons we we know from other threads)
A lot of the GitHub project sounds exciting and as long as you're the sole
contributor or hold all IP you'd be able to contribute appropriate
improvements to DeviceMap. Maybe already advanced enough for a 2.x branch;-)
About the Java 8 dependency, that's up to what others think. I know Java 7
and even 6 is still widely used, so despite Oracle and some JUGs heavily
pushing for everyone to use only SE 8 now, reality looks different here,
too, and "legacy" doesn't always just vanish even if a new version or two
are available and may even work better for some cases.
The other dependencies, we discussed Lombok earlier, I can't say if it
makes sense, but unless there is a complete license no-go with Apache for
some reason, either of them could be fine. Guava inspired Java 8 a lot,
e.g. Optional etc. existed there before (so one could use
com.google.common.base.Optional
in a Java 6/7 version of the same code and in a Java 8 branch stick to the
SE 8 native one java.util.Optional)
What is the preferred Apache user name you would like to use?
Just "vy" like on GitHub, if there's no minimal length, it might work,
otherwise what do you prefer?
Thanks,
Werner
On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hello,
>
> As I might have mentioned before, we internally use a slightly enhanced
> version of Apache DeviceMap at bol.com. Tomorrow there will be an all day
> long in-company Hackathon. There I plan to build a website
> whatismyuseragent.nl, where visitors are displayed the list of attributes
> returned by Apache DeviceMap. Further, they will be able to submit their
> enhancements by just updating the displayed values and hitting enter. The
> submission will end up as a GitHub issue. While the visuals still suck (the
> design is on the way), mechanics are more or less complete and the source
> code is accessible at https://github.com/vy/what-is-my-user-agent address.
> I believe this will bring some visibility to the project and have a
> potential to improve the DDR data. (Would Apache DM be willing to host such
> an application officially and connect it to their own JIRA system?)
>
> Within the project, I had employed the following mechanics that I also want
> to incorporate into Apache DeviceMap:
>
> 1. In addition to a *DeviceAttributes*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> >
> class consisting of a generic *Map<String,String>* field (as is the case
> for DM), I also implemented a *ApacheDeviceAttributes*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> >
> subclass such that all known device attributes (manually collected from DDR
> sources) are represented as fields. This allows the programmer to replace
>
>
>
>
>
>
> *if (attrs.containsKey("ajaxSupportJavaScript")) {
> boolean ajaxSupportJavaScript =
> Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> like boilerplate with an
>
> *Optional<Boolean> ajaxSupportJavaScript*.
>
> *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> replace it with a custom *Attribute<T>* class. But the attributes as a
> statically typed class field still holds its type-safe promise, I believe.
>
> 2. Used enums for representing attributes with a fixed set of values, that
> is, *DeviceOs*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> >,
> *InputDevice*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> >,
> and *MobileBrowser*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> >.
> (Values are collected from DDR.)
>
> 3. Added a *DeviceType*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> >
> class for classifying a User-Agent into the following categories:
>
> - Mini: head up displays, smart watches, -3”, minimal controls
> - Mobile: smart phone, phablet, -6”, game device, touch enabled
> - Tablet: touch enabled, 7”-13”
> - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> - TV: smart TV, set top box, streaming device, 40”-
> - Maxi: cinema, tv walls, 100”-, minimal controls
> - SEO Agent: search bots
>
> This is a work in progress and as of now, only Mobile, Tablet, Desktop, and
> SEO Agent options are supported.
>
> 4. Introduced a two-phased parsing pipeline to determine the *DeviceType*.
> One that depends on the User-Agent (for instance, you can easily
> differentiate a Googlebot without the need for DM attribute extraction to
> kick in), and another one that depends on both the User-Agent and extracted
> attributes.
>
> 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> >
> file. (Actually, I had already submitted the very same bots as a JIRA
> issue, but had no effect so far.)
>
> 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> >
> rather than a *DeviceType.SEO_AGENT*. This is of crucial importance, since
> Googlebot Mobile needs to spider the website and determine whether it is
> mobile-friendly or not, which has a direct impact in the Google rankings.
>
> We can directly implement some of these changes in the existing code base,
> and some will preferably require a new (and probably backward incompatible)
> API. Maybe this will also be a good motivation for a separate 2.0 version
> as Reza recommended. (I hope I got Reza's intention after long
> discussions.) Put another way, or as Werner said there is no harm in
> maintaining two separate drivers/DDRs. Ideas?
>
> Best.
>
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
Sounds great.
Several of the points could be good in a place where we gather
brainstorming or a "2.0 Roadmap".
If you haven't got a Wiki account, that (similar to JIRA) should be
self-hosting, so you don't have to wait for an Apache account being
generated (which may take up to a few weeks according to the committer info)
I am not sure, if Reza will continue to help with DeviceMap, but either way
it is good to have more hands and people who bring in fresh ideas.
One of the corporate vendors 52DegreesMobi follows me on Twitter with at
least one account. Some of their tweets hint, Smart TV among other devices
are currently being added, so what you highlight in 3.) scratches a similar
"itch" or need by the community.
All the Best for the Hackathon.
Werner
On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
wrote:
> Hello,
>
> As I might have mentioned before, we internally use a slightly enhanced
> version of Apache DeviceMap at bol.com. Tomorrow there will be an all day
> long in-company Hackathon. There I plan to build a website
> whatismyuseragent.nl, where visitors are displayed the list of attributes
> returned by Apache DeviceMap. Further, they will be able to submit their
> enhancements by just updating the displayed values and hitting enter. The
> submission will end up as a GitHub issue. While the visuals still suck (the
> design is on the way), mechanics are more or less complete and the source
> code is accessible at https://github.com/vy/what-is-my-user-agent address.
> I believe this will bring some visibility to the project and have a
> potential to improve the DDR data. (Would Apache DM be willing to host such
> an application officially and connect it to their own JIRA system?)
>
> Within the project, I had employed the following mechanics that I also want
> to incorporate into Apache DeviceMap:
>
> 1. In addition to a *DeviceAttributes*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceAttributes.java
> >
> class consisting of a generic *Map<String,String>* field (as is the case
> for DM), I also implemented a *ApacheDeviceAttributes*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/apache/ApacheDeviceAttributes.java
> >
> subclass such that all known device attributes (manually collected from DDR
> sources) are represented as fields. This allows the programmer to replace
>
>
>
>
>
>
> *if (attrs.containsKey("ajaxSupportJavaScript")) {
> boolean ajaxSupportJavaScript =
> Boolean.parseBoolean(attrs.get("ajaxSupportJavaScript")); ...}*
> like boilerplate with an
>
> *Optional<Boolean> ajaxSupportJavaScript*.
>
> *Optional<T>* introduces a Java 8 dependency. Hence, we might want to
> replace it with a custom *Attribute<T>* class. But the attributes as a
> statically typed class field still holds its type-safe promise, I believe.
>
> 2. Used enums for representing attributes with a fixed set of values, that
> is, *DeviceOs*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/DeviceOs.java
> >,
> *InputDevice*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/InputDevice.java
> >,
> and *MobileBrowser*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/attribute/MobileBrowser.java
> >.
> (Values are collected from DDR.)
>
> 3. Added a *DeviceType*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceType.java
> >
> class for classifying a User-Agent into the following categories:
>
> - Mini: head up displays, smart watches, -3”, minimal controls
> - Mobile: smart phone, phablet, -6”, game device, touch enabled
> - Tablet: touch enabled, 7”-13”
> - E-Reader: greyscale, e-Ink, fixed fonts, -10”
> - Desktop: PC, laptop, notebook mouse/keyboard, 11”-
> - TV: smart TV, set top box, streaming device, 40”-
> - Maxi: cinema, tv walls, 100”-, minimal controls
> - SEO Agent: search bots
>
> This is a work in progress and as of now, only Mobile, Tablet, Desktop, and
> SEO Agent options are supported.
>
> 4. Introduced a two-phased parsing pipeline to determine the *DeviceType*.
> One that depends on the User-Agent (for instance, you can easily
> differentiate a Googlebot without the need for DM attribute extraction to
> kick in), and another one that depends on both the User-Agent and extracted
> attributes.
>
> 5. Enriched the bot database using *BuilderDataSourcePatch.xml*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/resources/com/vlkan/whatismyuseragent/devicemap/apache/devicedata/BuilderDataSourcePatch.xml
> >
> file. (Actually, I had already submitted the very same bots as a JIRA
> issue, but had no effect so far.)
>
> 6. Treated Googlebot Mobile as a *DeviceType.MOBILE*
> <
> https://github.com/vy/what-is-my-user-agent/blob/master/src/main/java/com/vlkan/whatismyuseragent/devicemap/DeviceProfilerService.java#L46
> >
> rather than a *DeviceType.SEO_AGENT*. This is of crucial importance, since
> Googlebot Mobile needs to spider the website and determine whether it is
> mobile-friendly or not, which has a direct impact in the Google rankings.
>
> We can directly implement some of these changes in the existing code base,
> and some will preferably require a new (and probably backward incompatible)
> API. Maybe this will also be a good motivation for a separate 2.0 version
> as Reza recommended. (I hope I got Reza's intention after long
> discussions.) Put another way, or as Werner said there is no harm in
> maintaining two separate drivers/DDRs. Ideas?
>
> Best.
>
Re: bol.com Hackathon
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Apr 21, 2015 at 1:17 PM, venkata kiran surapaneni
<sv...@gmail.com> wrote:
> ...I meant pursuing of the email-JIRA integration proposed before. Sorry, for
> not being clear on that....
Ah ok, so as I said earlier https://issues.apache.org is shared
between many Apache projects so it's unlikely that a setup that's
specific to this project would be accepted.
The best is to start by defining the use cases and requirements (at
http://wiki.apache.org/devicemap/ maybe) for what you want to achieve,
and we can then discuss possible solutions.
(and starting new email threads for new topics here would help make
sense of things of course ;-)
-Bertrand
Re: bol.com Hackathon
Posted by venkata kiran surapaneni <sv...@gmail.com>.
I meant pursuing of the email-JIRA integration proposed before. Sorry, for
not being clear on that.
On Tue, Apr 21, 2015 at 1:01 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Mon, Apr 20, 2015 at 8:37 PM, venkata kiran surapaneni
> <sv...@gmail.com> wrote:
> > ...If the team is in agreement if this works, and Bertrand(I didn't sign
> ICLA,
> > but I can do it.) suggests if this can pursued with Apache INFRA team, we
> > can take this way....
>
> I have no idea what you mean by "this can be pursued" above.
>
> Filing the https://www.apache.org/licenses/icla.txt is good if you
> intend to contribute extensively to an Apache project, and it is
> required if a project decides to elect you as a committer. The Apache
> infra team is not involved in the iCLA process.
>
> -Bertrand
>
--
Thanks & Regards,
-Kiran
Re: bol.com Hackathon
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 20, 2015 at 8:37 PM, venkata kiran surapaneni
<sv...@gmail.com> wrote:
> ...If the team is in agreement if this works, and Bertrand(I didn't sign ICLA,
> but I can do it.) suggests if this can pursued with Apache INFRA team, we
> can take this way....
I have no idea what you mean by "this can be pursued" above.
Filing the https://www.apache.org/licenses/icla.txt is good if you
intend to contribute extensively to an Apache project, and it is
required if a project decides to elect you as a committer. The Apache
infra team is not involved in the iCLA process.
-Bertrand
Re: bol.com Hackathon
Posted by venkata kiran surapaneni <sv...@gmail.com>.
If the team is in agreement if this works, and Bertrand(I didn't sign ICLA,
but I can do it.) suggests if this can pursued with Apache INFRA team, we
can take this way.
Thanks,
--Kiran
On Mon, Apr 20, 2015 at 10:34 PM, Werner Keil <we...@gmail.com> wrote:
> Venkat,
>
> This sounds like a good idea. Again, have to go back at least into the
> "incubator" phase of the mailing list (before
> http://mail-archives.apache.org/mod_mbox/#devicemap) in the incubator
> archive http://mail-archives.apache.org/mod_mbox/incubator-devicemap-dev/
> you'll find one or the other thread (I recall one that Eberhard mentioned 2
> years ago, I guess it wasn't the only one in that direction as Stefano and
> I also had a meeting with people behind Mobile RichFaces in Prague around
> the same time)
>
> We know, Volkan signed the ICLA (archives also show when;-) but what about
> you? If it's simple exchange with the infra team, maybe that works without,
> I guess Bertrand knows best if you needed to become a committer or not for
> this kind of help...?
>
> Thanks,
> Werner
>
> On Mon, Apr 20, 2015 at 6:53 PM, venkata kiran surapaneni <
> svkirans@gmail.com> wrote:
>
> > In our company, clients can send emails to a certain email id and JIRA
> will
> > create tickets/issues for all those emails directly. All the further
> > replies to that email will be updated automatically in JIRA also. May be
> > Apache Infra team can advice us if some thing similar can be done ?
> >
> > On Fri, Apr 17, 2015 at 2:08 PM, Bertrand Delacretaz <
> > bdelacretaz@apache.org
> > > wrote:
> >
> > > Hi,
> > >
> > > On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <
> volkan.yazici@gmail.com
> > >
> > > wrote:
> > > > ...Would Apache DM be willing to host such
> > > > an application officially and connect it to their own JIRA system...
> > >
> > > We already have a VM at http://devicemap-vm.apache.org/ where we could
> > > run such an app.
> > >
> > > Connecting to JIRA directly might be trick as
> > > https://issues.apache.org/jira is shared between many Apache projects,
> > > so I suppose the ASF infra team might be careful about additional
> > > plugins or ingress points.
> > >
> > > However, there's certainly a way to collect data from such apps
> > > automatically, sending emails to a specific list, committing to an
> > > external github repo...there's many options.
> > >
> > > -Bertrand
> > >
> >
> >
> >
> > --
> > Thanks & Regards,
> > -Kiran
> >
>
--
Thanks & Regards,
-Kiran
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
Venkat,
This sounds like a good idea. Again, have to go back at least into the
"incubator" phase of the mailing list (before
http://mail-archives.apache.org/mod_mbox/#devicemap) in the incubator
archive http://mail-archives.apache.org/mod_mbox/incubator-devicemap-dev/
you'll find one or the other thread (I recall one that Eberhard mentioned 2
years ago, I guess it wasn't the only one in that direction as Stefano and
I also had a meeting with people behind Mobile RichFaces in Prague around
the same time)
We know, Volkan signed the ICLA (archives also show when;-) but what about
you? If it's simple exchange with the infra team, maybe that works without,
I guess Bertrand knows best if you needed to become a committer or not for
this kind of help...?
Thanks,
Werner
On Mon, Apr 20, 2015 at 6:53 PM, venkata kiran surapaneni <
svkirans@gmail.com> wrote:
> In our company, clients can send emails to a certain email id and JIRA will
> create tickets/issues for all those emails directly. All the further
> replies to that email will be updated automatically in JIRA also. May be
> Apache Infra team can advice us if some thing similar can be done ?
>
> On Fri, Apr 17, 2015 at 2:08 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > Hi,
> >
> > On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <volkan.yazici@gmail.com
> >
> > wrote:
> > > ...Would Apache DM be willing to host such
> > > an application officially and connect it to their own JIRA system...
> >
> > We already have a VM at http://devicemap-vm.apache.org/ where we could
> > run such an app.
> >
> > Connecting to JIRA directly might be trick as
> > https://issues.apache.org/jira is shared between many Apache projects,
> > so I suppose the ASF infra team might be careful about additional
> > plugins or ingress points.
> >
> > However, there's certainly a way to collect data from such apps
> > automatically, sending emails to a specific list, committing to an
> > external github repo...there's many options.
> >
> > -Bertrand
> >
>
>
>
> --
> Thanks & Regards,
> -Kiran
>
Re: bol.com Hackathon
Posted by Gaurav Pruthi <ga...@gmail.com>.
WTH kiran.
On 4/20/15, venkata kiran surapaneni <sv...@gmail.com> wrote:
> In our company, clients can send emails to a certain email id and JIRA will
> create tickets/issues for all those emails directly. All the further
> replies to that email will be updated automatically in JIRA also. May be
> Apache Infra team can advice us if some thing similar can be done ?
>
> On Fri, Apr 17, 2015 at 2:08 PM, Bertrand Delacretaz
> <bdelacretaz@apache.org
>> wrote:
>
>> Hi,
>>
>> On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>> > ...Would Apache DM be willing to host such
>> > an application officially and connect it to their own JIRA system...
>>
>> We already have a VM at http://devicemap-vm.apache.org/ where we could
>> run such an app.
>>
>> Connecting to JIRA directly might be trick as
>> https://issues.apache.org/jira is shared between many Apache projects,
>> so I suppose the ASF infra team might be careful about additional
>> plugins or ingress points.
>>
>> However, there's certainly a way to collect data from such apps
>> automatically, sending emails to a specific list, committing to an
>> external github repo...there's many options.
>>
>> -Bertrand
>>
>
>
>
> --
> Thanks & Regards,
> -Kiran
>
--
Gaurav Pruthi
http://en.wikipedia.org/wiki/User:Gaurav_Pruthi
Re: bol.com Hackathon
Posted by venkata kiran surapaneni <sv...@gmail.com>.
In our company, clients can send emails to a certain email id and JIRA will
create tickets/issues for all those emails directly. All the further
replies to that email will be updated automatically in JIRA also. May be
Apache Infra team can advice us if some thing similar can be done ?
On Fri, Apr 17, 2015 at 2:08 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> > ...Would Apache DM be willing to host such
> > an application officially and connect it to their own JIRA system...
>
> We already have a VM at http://devicemap-vm.apache.org/ where we could
> run such an app.
>
> Connecting to JIRA directly might be trick as
> https://issues.apache.org/jira is shared between many Apache projects,
> so I suppose the ASF infra team might be careful about additional
> plugins or ingress points.
>
> However, there's certainly a way to collect data from such apps
> automatically, sending emails to a specific list, committing to an
> external github repo...there's many options.
>
> -Bertrand
>
--
Thanks & Regards,
-Kiran
Re: bol.com Hackathon
Posted by Werner Keil <we...@gmail.com>.
Some more recent JSRs at JCP got a bi-directional (some just read-only)
mirror on GitHub similar to what we do at least with Browsermap.
Something like that could be explored for user-provided patches or
signature updates.
Werner
On Fri, Apr 17, 2015 at 10:38 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> Hi,
>
> On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> > ...Would Apache DM be willing to host such
> > an application officially and connect it to their own JIRA system...
>
> We already have a VM at http://devicemap-vm.apache.org/ where we could
> run such an app.
>
> Connecting to JIRA directly might be trick as
> https://issues.apache.org/jira is shared between many Apache projects,
> so I suppose the ASF infra team might be careful about additional
> plugins or ingress points.
>
> However, there's certainly a way to collect data from such apps
> automatically, sending emails to a specific list, committing to an
> external github repo...there's many options.
>
> -Bertrand
>
Re: bol.com Hackathon
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Apr 16, 2015 at 10:30 PM, Volkan Yazıcı <vo...@gmail.com> wrote:
> ...Would Apache DM be willing to host such
> an application officially and connect it to their own JIRA system...
We already have a VM at http://devicemap-vm.apache.org/ where we could
run such an app.
Connecting to JIRA directly might be trick as
https://issues.apache.org/jira is shared between many Apache projects,
so I suppose the ASF infra team might be careful about additional
plugins or ingress points.
However, there's certainly a way to collect data from such apps
automatically, sending emails to a specific list, committing to an
external github repo...there's many options.
-Bertrand