You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Werner Keil <we...@gmail.com> on 2015/04/30 11:33:30 UTC

.NET Clients and Visual Studio Code

Hi,

After the hackathon last weekend and a busy week in local projects, I
should have a little more time this weekend, also due to May 1st holiday
tomorrow.

I have not set up any Jenkins job or requested one, but
got /trunk/clients/w3c-ddr/ consistent by fixing old names or POM
references like "java". This module is now self-contained and also builds
properly in Maven. I trust Reza or other committers can help doing the same
on the /clients/java side. Ideally also with separate /examples building on
top of a particular client.

How about .NET? It was pretty unaffected by the actual change, but Log4Net
shows clearly, there is a Jenkins node and possibly plugins allowing to
build C# or VB.net projects, too.

@Eberhard, would you be able and willing to drive that, or do you currently
have no time for that?

Also on the long run, it seems Microsoft plans to replace Visual Studio
Community Edition with something called "Visual Studio Code", see
https://code.visualstudio.com/Docs

I downloaded it, probably give it a try here or on my laptop if it doesn't
take too much HD space over the weekend. It looks like it does the basic
stuff for all of these languages:
https://code.visualstudio.com/Docs/languages so more or less an answer to
Eclipse, NetBeans or free versions of IntelliJ from Microsoft.
Thus trying to edit and compile the .NET codebase with this new "Open
Source friendly" IDE from Microsoft and maybe offer some level or README
(VS Code also supports MarkDown;-) seems like a good idea. Not to mention a
lot of other languages, including Java also are supported.

Werner

Re: .NET Clients and Visual Studio Code

Posted by Volkan Yazıcı <vo...@gmail.com>.
Thanks for the detailed instructions Reza.
At the weekend I will work on the issues you pointed.
I will probably create separate branch with the issue
code and will ask for a review before merging it to the
trunk.

On Thu, Apr 30, 2015 at 3:05 PM, Reza Naghibi <re...@naghibi.com> wrote:

> >> Reza, would you like to do the structural organization?
>
> I believe all outstanding tasks are done.
>
> As for tasks, the only task that need attention right now is data. Im not
> aware of any priority client tasks at the moment. Also, given that 2.0 is
> on the horizon, time spent on clients is better spent on 2.0 than 1.0. If
> there is something substantial that can be added in 1.0, then im all for
> it, especially in the performance or accuracy area.
>
> Back to the data, I am still planning on more data release, 1.0.3,
> hopefully in May. So take a look at these tickets:
>
> https://issues.apache.org/jira/browse/DMAP-96
> https://issues.apache.org/jira/browse/DMAP-154
>
> Between these 2 tickets, there are about 30 relevant devices which can be
> added which would complete the 1.0.3 release.
>
> The steps for adding devices:
>
> 1) Create a JIRA ticket for the device, assign it to yourself, and add as
> much info to the device as possible. There are numerous examples of this on
> JIRA that you can use as a guide. Most importantly, make sure the model,
> specs, and user-agent are in the ticket. This is important because Google
> (and other engines) will index the JIRA ticket and future searches for the
> device and its attributes will return the ticket as a top result. This is a
> great way to expose our data to future users.
>
> 2) Add the pattern and device attributes to the ODDR xml. Once again, use
> previous devices as a guide or just ask the list if you have a question.
>
> 3) Add a unit test for the device to the Java client. Just add 1 line at
> the bottom with the user agent and the device id to this file:
>
>
> https://svn.apache.org/viewvc/devicemap/trunk/clients/1.0/java/src/test/resources/uas.data?view=markup
>
> Make sure that the client is using the data snapshot dependency that you
> are working on.
>
>
>
> On Thu, Apr 30, 2015 at 7:05 AM, Volkan Yazıcı <vo...@gmail.com>
> wrote:
>
> > I will have some time at the weekend to check this out.
> >
> > Reza, would you like to do the structural organization?
> > Or do you prefer me to do it? If so, I will be appreciated
> > if you can share a couple of steps that I need to take.
> > Such as,
> >
> > - remove X dependency from POM,
> > - move modules X to directory Y,
> > - etc.
> >
> > Best.
> >
> > On Thu, Apr 30, 2015 at 11:33 AM, Werner Keil <we...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > After the hackathon last weekend and a busy week in local projects, I
> > > should have a little more time this weekend, also due to May 1st
> holiday
> > > tomorrow.
> > >
> > > I have not set up any Jenkins job or requested one, but
> > > got /trunk/clients/w3c-ddr/ consistent by fixing old names or POM
> > > references like "java". This module is now self-contained and also
> builds
> > > properly in Maven. I trust Reza or other committers can help doing the
> > same
> > > on the /clients/java side. Ideally also with separate /examples
> building
> > on
> > > top of a particular client.
> > >
> > > How about .NET? It was pretty unaffected by the actual change, but
> > Log4Net
> > > shows clearly, there is a Jenkins node and possibly plugins allowing to
> > > build C# or VB.net projects, too.
> > >
> > > @Eberhard, would you be able and willing to drive that, or do you
> > currently
> > > have no time for that?
> > >
> > > Also on the long run, it seems Microsoft plans to replace Visual Studio
> > > Community Edition with something called "Visual Studio Code", see
> > > https://code.visualstudio.com/Docs
> > >
> > > I downloaded it, probably give it a try here or on my laptop if it
> > doesn't
> > > take too much HD space over the weekend. It looks like it does the
> basic
> > > stuff for all of these languages:
> > > https://code.visualstudio.com/Docs/languages so more or less an answer
> > to
> > > Eclipse, NetBeans or free versions of IntelliJ from Microsoft.
> > > Thus trying to edit and compile the .NET codebase with this new "Open
> > > Source friendly" IDE from Microsoft and maybe offer some level or
> README
> > > (VS Code also supports MarkDown;-) seems like a good idea. Not to
> > mention a
> > > lot of other languages, including Java also are supported.
> > >
> > > Werner
> > >
> >
>

Re: .NET Clients and Visual Studio Code

Posted by Reza Naghibi <re...@naghibi.com>.
>> Reza, would you like to do the structural organization?

I believe all outstanding tasks are done.

As for tasks, the only task that need attention right now is data. Im not
aware of any priority client tasks at the moment. Also, given that 2.0 is
on the horizon, time spent on clients is better spent on 2.0 than 1.0. If
there is something substantial that can be added in 1.0, then im all for
it, especially in the performance or accuracy area.

Back to the data, I am still planning on more data release, 1.0.3,
hopefully in May. So take a look at these tickets:

https://issues.apache.org/jira/browse/DMAP-96
https://issues.apache.org/jira/browse/DMAP-154

Between these 2 tickets, there are about 30 relevant devices which can be
added which would complete the 1.0.3 release.

The steps for adding devices:

1) Create a JIRA ticket for the device, assign it to yourself, and add as
much info to the device as possible. There are numerous examples of this on
JIRA that you can use as a guide. Most importantly, make sure the model,
specs, and user-agent are in the ticket. This is important because Google
(and other engines) will index the JIRA ticket and future searches for the
device and its attributes will return the ticket as a top result. This is a
great way to expose our data to future users.

2) Add the pattern and device attributes to the ODDR xml. Once again, use
previous devices as a guide or just ask the list if you have a question.

3) Add a unit test for the device to the Java client. Just add 1 line at
the bottom with the user agent and the device id to this file:

https://svn.apache.org/viewvc/devicemap/trunk/clients/1.0/java/src/test/resources/uas.data?view=markup

Make sure that the client is using the data snapshot dependency that you
are working on.



On Thu, Apr 30, 2015 at 7:05 AM, Volkan Yazıcı <vo...@gmail.com>
wrote:

> I will have some time at the weekend to check this out.
>
> Reza, would you like to do the structural organization?
> Or do you prefer me to do it? If so, I will be appreciated
> if you can share a couple of steps that I need to take.
> Such as,
>
> - remove X dependency from POM,
> - move modules X to directory Y,
> - etc.
>
> Best.
>
> On Thu, Apr 30, 2015 at 11:33 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Hi,
> >
> > After the hackathon last weekend and a busy week in local projects, I
> > should have a little more time this weekend, also due to May 1st holiday
> > tomorrow.
> >
> > I have not set up any Jenkins job or requested one, but
> > got /trunk/clients/w3c-ddr/ consistent by fixing old names or POM
> > references like "java". This module is now self-contained and also builds
> > properly in Maven. I trust Reza or other committers can help doing the
> same
> > on the /clients/java side. Ideally also with separate /examples building
> on
> > top of a particular client.
> >
> > How about .NET? It was pretty unaffected by the actual change, but
> Log4Net
> > shows clearly, there is a Jenkins node and possibly plugins allowing to
> > build C# or VB.net projects, too.
> >
> > @Eberhard, would you be able and willing to drive that, or do you
> currently
> > have no time for that?
> >
> > Also on the long run, it seems Microsoft plans to replace Visual Studio
> > Community Edition with something called "Visual Studio Code", see
> > https://code.visualstudio.com/Docs
> >
> > I downloaded it, probably give it a try here or on my laptop if it
> doesn't
> > take too much HD space over the weekend. It looks like it does the basic
> > stuff for all of these languages:
> > https://code.visualstudio.com/Docs/languages so more or less an answer
> to
> > Eclipse, NetBeans or free versions of IntelliJ from Microsoft.
> > Thus trying to edit and compile the .NET codebase with this new "Open
> > Source friendly" IDE from Microsoft and maybe offer some level or README
> > (VS Code also supports MarkDown;-) seems like a good idea. Not to
> mention a
> > lot of other languages, including Java also are supported.
> >
> > Werner
> >
>

Re: .NET Clients and Visual Studio Code

Posted by Werner Keil <we...@gmail.com>.
Volkan,

Thanks for offering to help.
At some point it would be great to sync up with Reza on who might help with
turning the "Console Example" (https://issues.apache.org/jira/browse/DMAP-54)
into an actual "DeviceMap Console for Java Client", just like the 2 .NET
clients both got these properly separated.
I know you volunteered to help earlier, feel free to either assign this to
yourself (or ask others if you can't do it in JIRA) or create a new
separate JIRA ticket that isn't dedicated to "examples".

Cheers,
Werner



On Thu, Apr 30, 2015 at 1:05 PM, Volkan Yazıcı <vo...@gmail.com>
wrote:

> I will have some time at the weekend to check this out.
>
> Reza, would you like to do the structural organization?
> Or do you prefer me to do it? If so, I will be appreciated
> if you can share a couple of steps that I need to take.
> Such as,
>
> - remove X dependency from POM,
> - move modules X to directory Y,
> - etc.
>
> Best.
>
> On Thu, Apr 30, 2015 at 11:33 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Hi,
> >
> > After the hackathon last weekend and a busy week in local projects, I
> > should have a little more time this weekend, also due to May 1st holiday
> > tomorrow.
> >
> > I have not set up any Jenkins job or requested one, but
> > got /trunk/clients/w3c-ddr/ consistent by fixing old names or POM
> > references like "java". This module is now self-contained and also builds
> > properly in Maven. I trust Reza or other committers can help doing the
> same
> > on the /clients/java side. Ideally also with separate /examples building
> on
> > top of a particular client.
> >
> > How about .NET? It was pretty unaffected by the actual change, but
> Log4Net
> > shows clearly, there is a Jenkins node and possibly plugins allowing to
> > build C# or VB.net projects, too.
> >
> > @Eberhard, would you be able and willing to drive that, or do you
> currently
> > have no time for that?
> >
> > Also on the long run, it seems Microsoft plans to replace Visual Studio
> > Community Edition with something called "Visual Studio Code", see
> > https://code.visualstudio.com/Docs
> >
> > I downloaded it, probably give it a try here or on my laptop if it
> doesn't
> > take too much HD space over the weekend. It looks like it does the basic
> > stuff for all of these languages:
> > https://code.visualstudio.com/Docs/languages so more or less an answer
> to
> > Eclipse, NetBeans or free versions of IntelliJ from Microsoft.
> > Thus trying to edit and compile the .NET codebase with this new "Open
> > Source friendly" IDE from Microsoft and maybe offer some level or README
> > (VS Code also supports MarkDown;-) seems like a good idea. Not to
> mention a
> > lot of other languages, including Java also are supported.
> >
> > Werner
> >
>

Re: .NET Clients and Visual Studio Code

Posted by Volkan Yazıcı <vo...@gmail.com>.
I will have some time at the weekend to check this out.

Reza, would you like to do the structural organization?
Or do you prefer me to do it? If so, I will be appreciated
if you can share a couple of steps that I need to take.
Such as,

- remove X dependency from POM,
- move modules X to directory Y,
- etc.

Best.

On Thu, Apr 30, 2015 at 11:33 AM, Werner Keil <we...@gmail.com> wrote:

> Hi,
>
> After the hackathon last weekend and a busy week in local projects, I
> should have a little more time this weekend, also due to May 1st holiday
> tomorrow.
>
> I have not set up any Jenkins job or requested one, but
> got /trunk/clients/w3c-ddr/ consistent by fixing old names or POM
> references like "java". This module is now self-contained and also builds
> properly in Maven. I trust Reza or other committers can help doing the same
> on the /clients/java side. Ideally also with separate /examples building on
> top of a particular client.
>
> How about .NET? It was pretty unaffected by the actual change, but Log4Net
> shows clearly, there is a Jenkins node and possibly plugins allowing to
> build C# or VB.net projects, too.
>
> @Eberhard, would you be able and willing to drive that, or do you currently
> have no time for that?
>
> Also on the long run, it seems Microsoft plans to replace Visual Studio
> Community Edition with something called "Visual Studio Code", see
> https://code.visualstudio.com/Docs
>
> I downloaded it, probably give it a try here or on my laptop if it doesn't
> take too much HD space over the weekend. It looks like it does the basic
> stuff for all of these languages:
> https://code.visualstudio.com/Docs/languages so more or less an answer to
> Eclipse, NetBeans or free versions of IntelliJ from Microsoft.
> Thus trying to edit and compile the .NET codebase with this new "Open
> Source friendly" IDE from Microsoft and maybe offer some level or README
> (VS Code also supports MarkDown;-) seems like a good idea. Not to mention a
> lot of other languages, including Java also are supported.
>
> Werner
>

Re: .NET Clients and Visual Studio Code

Posted by Werner Keil <we...@gmail.com>.
Hi,

Thanks for your roadmap and feedback.

It didn't answer the question, whether you would like to have a CI instance
showing the builds pass for the .NET clients and unless you think this was
a waste of time if you'd be willing to request these Jenkins Jobs. Putting
it on a CI server has nothing to do with Java-fy.

On the contrary, I was so far the only one who showed other clients than
Java even exist;-D
At least the site practically doesn't mention. If you run the Apache VM you
get one of the Java/Spring examples based on Reza's Java client. And even
the download links don't seem to mention the .NET clients. That (at lest
speaking for myself) is not the intention to hide it "in the closet" or get
rid of it, but someone (usually the person who is considered "module
owner") has to ensure, these aspects of visibility are there, otherwise
people will only see what other modules and their owners/committers do.

With the separation it makes it a little easier, but take Browsermap or the
.NET clients they never had any dependencies on anything other than data,
so except for the parent folders they are pretty unchanged.

Werner

On Thu, Apr 30, 2015 at 1:46 PM, eberhard speer jr. <se...@ducis.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> as I have indicated on a number of occasions I totally don't get this
> desire to Java-fy everything.
> I would like to keep the 'core' DeviceMap code as 'clean' as possible.
> By that I mean -- this also, in answer to Reza's earlier question on
> how I see the future :
> - - zero dependencies
> - - CLI compliant [.Net specific]
> - - as platform/language agnostic as possible
> - - as accurate, fast and small as possible
> so it can be embedded, dropped, integrated into any other application
> with zero effort. [Basically, as it is now.]
> In that scenario I imagine DeviceMap 'core' in for example :
> - - a canonical DDR compliant client
> - - a web service
> - - a client targeting specific user-agent types [bot, OS, version]
> - - a 'vanilla' MVC client
> - - a log analysis tool
> - - ...
> [I once 'embedded' an Java DeviceMap client in a Tomcat server.]
> They each have their own specifics with regard to environment, logging
> etc and the core should neither impose limits nor add a burden to that.
>
> I agree that DeviceMap should provide examples of such clients and
> encourage the development of them but these can only thrive if we :
> a) keep the 'core' clean and lean [and yes, a little mean]
> b) work on the data !
>
> ;)
>
> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJVQhYnAAoJEOxywXcFLKYcPQMH+gIdDSugTuGA2aydiP9qEick
> ffPir6SRSXDTi3qHzkrlG2j2m+fHfUt1F0tSCaCgjt2M3scpnKt9u2vp/vXF1n96
> TuJMlXadl38+WU5075uS98Hh0C/ZYpIUHIs3Xn/QzuTR/5SoOSVqiKFO9PZIKDYb
> fZyIgoP9C4BbyqzKSveoARaSdF8GnV2U977AKSGr1ENpfClxLuB8tIBokQ/lqrGs
> /xxnTXR8YdO7kU5r2KZhKYhT4e4wT8bH0TubRrO6Pkm7nEZS++cPMVCC/5/c1LHl
> VQaEUZaVpr6y+3DUsRxvKIqWTGXkl+Olj8hxyV3QJgRk69BVDP+RE3rxd3Pa1Tc=
> =+fgg
> -----END PGP SIGNATURE-----
>
>

Re: .NET Clients and Visual Studio Code

Posted by "eberhard speer jr." <se...@ducis.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

as I have indicated on a number of occasions I totally don't get this
desire to Java-fy everything.
I would like to keep the 'core' DeviceMap code as 'clean' as possible.
By that I mean -- this also, in answer to Reza's earlier question on
how I see the future :
- - zero dependencies
- - CLI compliant [.Net specific]
- - as platform/language agnostic as possible
- - as accurate, fast and small as possible
so it can be embedded, dropped, integrated into any other application
with zero effort. [Basically, as it is now.]
In that scenario I imagine DeviceMap 'core' in for example :
- - a canonical DDR compliant client
- - a web service
- - a client targeting specific user-agent types [bot, OS, version]
- - a 'vanilla' MVC client
- - a log analysis tool
- - ...
[I once 'embedded' an Java DeviceMap client in a Tomcat server.]
They each have their own specifics with regard to environment, logging
etc and the core should neither impose limits nor add a burden to that.

I agree that DeviceMap should provide examples of such clients and
encourage the development of them but these can only thrive if we :
a) keep the 'core' clean and lean [and yes, a little mean]
b) work on the data !

;)

esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJVQhYnAAoJEOxywXcFLKYcPQMH+gIdDSugTuGA2aydiP9qEick
ffPir6SRSXDTi3qHzkrlG2j2m+fHfUt1F0tSCaCgjt2M3scpnKt9u2vp/vXF1n96
TuJMlXadl38+WU5075uS98Hh0C/ZYpIUHIs3Xn/QzuTR/5SoOSVqiKFO9PZIKDYb
fZyIgoP9C4BbyqzKSveoARaSdF8GnV2U977AKSGr1ENpfClxLuB8tIBokQ/lqrGs
/xxnTXR8YdO7kU5r2KZhKYhT4e4wT8bH0TubRrO6Pkm7nEZS++cPMVCC/5/c1LHl
VQaEUZaVpr6y+3DUsRxvKIqWTGXkl+Olj8hxyV3QJgRk69BVDP+RE3rxd3Pa1Tc=
=+fgg
-----END PGP SIGNATURE-----