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ı <[email protected]> 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 <[email protected]> > 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ı <[email protected] > > > > 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. > > > > > >
