Nabble - Atalaya-dev

RSS feeds

2008-09-16T03:32:53Z

Hi

I've had to install a CI tool here (hudson) and I'm seeing that it makes a fairly neat use of RSS feeds.
(Background: this hudson schedules builds of projects and reports their exit status)

In particular it allows to subscribe for events at the dashboard level (every build for every project, every failed build for every project) and on a per project basis.
Thinking back to Atalaya I'm thinking of something similar where levels are what we have now, i.e:

-dashboard
-groups
-hosts

and where the events are the updates. The only tricky part is to define a consistent set of URIs so that someone can subscribe to selected feeds.

Giacomo: I'm not proposing to rework the schedule, just build up a backlog. for it to be useful we should discuss whethere a feature like this is useful/desiderable...

Up?
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Using Treemaps for data visualization?

2008-09-13T01:03:33Z

well,

if the objective is to induce violent headaches I think tree maps are just perfect,
I think that it might be useful to introduce a tree menu in order to rationalize tables hierarchy and ease navigation between them. Nevertheless I suggest to focus on the agreed development plan before introducing new elements to it.

Ciao

On Fri, Sep 12, 2008 at 9:25 PM, Roman Kalyakin <theorm@...> wrote:

Hi,

This reminded me of The Map Of The Internet (c). :)
http://xkcd.com/195/

Frankly, that looks interesting, especially since there is a java implementation already. I doubt it's possible to eliminate all tables. But that would work at least as an alternative way of representing data.

-Roman

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

Re: Using Treemaps for data visualization?

2008-09-12T13:25:14Z

Hi,

This reminded me of The Map Of The Internet (c). :)
http://xkcd.com/195/

Frankly, that looks interesting, especially since there is a java implementation already. I doubt it's possible to eliminate all tables. But that would work at least as an alternative way of representing data.

-Roman

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Using Treemaps for data visualization?

2008-09-11T11:09:22Z

Follow up for the Russian-speaking:)

Voronoi treemaps for the visualization of software metrics
http://portal.acm.org/citation.cfm?id=1056018.1056041

a special case of http://en.wikipedia.org/wiki/Voronoi_diagram

cheers
F

On Thu, Sep 11, 2008 at 7:31 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

Using Treemaps for data visualization?

2008-09-11T10:31:12Z

Hi all

I don't know if you guys had the chance of reading this blog post: http://radajo.blogspot.com/2008/09/security-book-review-applied-security.html .In case not a short cite:

"Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps."

I've read a bit here and there and I found them a neat way of displaying multi-variate datasets. You can find the main page at: http://www.cs.umd.edu/hcil/treemap-history/

For the impatients: there's an OS java implementation of the main algorithms.
At least I think this topic deserves a bit of study, I've a gut feeling that we might be able to get rid of boring tables if correctly planned:)

Re: Flash charts

2008-09-08T00:38:58Z

nice!

On Mon, Sep 8, 2008 at 12:34 AM, Roman Kalyakin <theorm@...> wrote:

Hi there,

Work is going on and there are the first results for those who want to improve motivation. :)
See attached screenshot.

Cheers,
Roman

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-07T15:34:00Z

Hi there,

Work is going on and there are the first results for those who want to improve motivation. :)
See attached screenshot.

Cheers,
Roman

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

s.png (171K) Download Attachment

Re: 1st Atalaya meeting minutes

2008-09-04T13:04:04Z

Hi,

I agree with Francesco that we can postpone with migration until we reach a consensus or get tired of SF tracker.
Meanwhile, I started working on Flash charts, according to the defined priorities.

-Roman

On Wed, Sep 3, 2008 at 11:25 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi

after some discussion about some of the tasks listed below, it might be time to see whether the priorities are really what we first agreed on.

In particular I think that we agree that while a nice-to-have, migrating the tracker from SF doesn't make the project move ahead a lot. Flash charts do instead, as they improve the look and feel a lot.

Another piece that we have overlooked so far is SCM. With this I mean at least to make so that someone can develop an appliance without having to rebuild the whole codebase. Same goes for implementations of bindings of new ticketing systems.

Well, ok this might go on another thread, I was just trying to make a point here:)
cheers
F

On Fri, Aug 1, 2008 at 7:48 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: 1st Atalaya meeting minutes

2008-09-03T14:25:10Z

Hi

after some discussion about some of the tasks listed below, it might be time to see whether the priorities are really what we first agreed on.

In particular I think that we agree that while a nice-to-have, migrating the tracker from SF doesn't make the project move ahead a lot. Flash charts do instead, as they improve the look and feel a lot.

Another piece that we have overlooked so far is SCM. With this I mean at least to make so that someone can develop an appliance without having to rebuild the whole codebase. Same goes for implementations of bindings of new ticketing systems.

Well, ok this might go on another thread, I was just trying to make a point here:)
cheers
F

On Fri, Aug 1, 2008 at 7:48 PM, Francesco Vivoli <f.vivoli@...> wrote:

Hi everybody

as promised here go the minutes of what we said between on tinto and the other:)
(and btw, I think there should be shifts for whom does the note keeping)

List of high level features (+'s for priorities)

1- reporting(-): agreed to remove the current impl and to rethink the whole thing.

2- UI(++):
   - make it smoother (cut rough edges, clutchy actions and the like)
   - fix bugs
   - improve charts (flash?)

3-plugins(+):
   - how to develop, i.e the API and also providing some basic declarative configuration mean
     (many plugins only differ for a regex...)
   - lifecycle: how to configure/deconfigure and load/unload them

4- error handling and reporting(++): be more descrptive when some updates fail

5- configuration management(+):
   - initial setup (user side)
   - for developers (what they need to import to develop plugins - see the API stuff)
   - for the project (setup TRAC and migrate from SF bug tracker)

6-issues repository(++): this means re-activating corration between security elements)

7-policies(++): finish this first impl across the appliance set

8-false positives(++): finish this first impl across the appliance set

9-XML API(+) : draft design

10-MSBA(++): implement

11-testing(): evaluate what makes sense to be tested with Selenium

Now, speaking of assignments, I think that Giacomo can easily carry on what he was doing, that is
7,8 and 10. Then I can get on 4, 6 and part of 2. Roman, as you see you've got plenty of speculative
work ahead (:)) but IMO 2.3 and 5.3 should be given priority. Then the rest of 5 would be great to
have, since it also eases our daily work. Once these things are done I'm eager to see how we
can tackle the plugin matter:)

well, friday - 19:47...I think this's enough, I'm offff!
ciao
F

Re: New ticketing system?

2008-09-02T01:54:36Z

Not considering functionality, I think that a hosted solution better
fits our actual team configuration.
I don't think we have time to spend in development overhead; I
understand that there has been some displease about SF ticketing
system, expecially from myself; in any case the worst problem has been
laziness; once mitigated that (thanks Francesco) it didn't take so
much to cleanup bugs queue for instance.

I would stick to SF for the moment.

On Mon, Sep 1, 2008 at 11:41 PM, Francesco Vivoli <f.vivoli@...> wrote:

> HI
>
> since we are starting to have some concrete activity, wouldn't be best if we
> made up our minds and to get along once and for all?
> Giacomo, although you might not have much of experience with this issue,
> could you maybe make up a point about hosted vs in house?
> To me hosted=(less maintenance, less traffic but also less control) while in
> house=(more maintenance, more traffic thus more $$ if we move to hosting but
> also greater control ).
>
> Now, even if we move to some hosting service, we could maintain the dev
> server to our facilities. As for the control, it's kind of clear but at the
> same time I'm not sure of which benefits we could derive from such a plus...
>
> ideas?
> F
>
> On Fri, Aug 29, 2008 at 11:43 AM, <giacomo.collini@...> wrote:
>>
>> On Thu, Aug 28, 2008 at 11:52 AM, Roman Kalyakin <theorm@...> wrote:
>> > cut
>> > Conclusion: I would give launchpad a try. It's robust and doesn't seem
>> > to
>> > disappear within the following two years. If not, then Jira is a better
>> > option than Trac. They both do not have a hosted option, and the rest of
>> > pros and cons speak for Jira.
>> >
>>
>> Hi guys,
>>
>> As I don't have a considerable experience on these platforms I don't
>> have a strong opinion. For sure the effort of migrating to a new
>> platform is compensate by the cumbersomeness of SF ticketing system.
>>
>> I will support any decision the team will take.
>>
>> Thanks
>>
>>
>> --
>> Giacomo Collini - CISSP
>>
>> Information Security Analyst
>>
>>
>> email: giacomo.collini@...
>> mobile: (+34)628332736
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Atalaya-developer mailing list
>> Atalaya-developer@...
>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: New ticketing system?

2008-09-01T14:41:02Z

HI

since we are starting to have some concrete activity, wouldn't be best if we made up our minds and to get along once and for all?
Giacomo, although you might not have much of experience with this issue, could you maybe make up a point about hosted vs in house?
To me hosted=(less maintenance, less traffic but also less control) while in house=(more maintenance, more traffic thus more $$ if we move to hosting but also greater control ).

Now, even if we move to some hosting service, we could maintain the dev server to our facilities. As for the control, it's kind of clear but at the same time I'm not sure of which benefits we could derive from such a plus...

ideas?
F

On Fri, Aug 29, 2008 at 11:43 AM, <giacomo.collini@...> wrote:

On Thu, Aug 28, 2008 at 11:52 AM, Roman Kalyakin <theorm@...> wrote:
> cut

> Conclusion: I would give launchpad a try. It's robust and doesn't seem to
> disappear within the following two years. If not, then Jira is a better
> option than Trac. They both do not have a hosted option, and the rest of
> pros and cons speak for Jira.
>

Hi guys,

As I don't have a considerable experience on these platforms I don't
have a strong opinion. For sure the effort of migrating to a new
platform is compensate by the cumbersomeness of SF ticketing system.

I will support any decision the team will take.

Thanks

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer

Re: Flash charts

2008-09-01T08:10:42Z

So do I:)

On Mon, Sep 1, 2008 at 5:05 PM, <giacomo.collini@...> wrote:

I took a look to commercial alternatives like FusionChart.
They are quite cheap indeed but on the other hand I would like to
stick to the "preference to open source components and libraries"
policy. So I strongly support Open Flash Charts.

Thanks,

On Mon, Sep 1, 2008 at 11:31 AM, Francesco Vivoli <f.vivoli@...> wrote:
> For me they look ok. If there is some other compelling reason for yahoo I'll
> be fine with yahoo as well.
> ciao
> F
>
> On Mon, Sep 1, 2008 at 11:19 AM, Roman Kalyakin <theorm@...> wrote:
>>
>> Okay. The last thing is to decide what charts to use. I suggest if
>> everyone is satisfied with the look'n'feel of the open flash charts, let's
>> go for it.
>>
>> -R
>>
>> On Mon, Sep 1, 2008 at 11:16 AM, Francesco Vivoli <f.vivoli@...>
>> wrote:
>>>
>>> Yes, this makes sense. After all much of the work is on the data format,
>>> which can be reused.
>>> F
>>>
>>> On Mon, Sep 1, 2008 at 11:14 AM, Roman Kalyakin <theorm@...> wrote:
>>>>
>>>> Taking into account the limitations of the bar charts, if we want to
>>>> finish the charts at once without rewriting things later, that would make
>>>> sense to implement a polar chart from the beginning. From the other side, we
>>>> could just drop in a swf bar chart instead of the polar chart and see how it
>>>> looks. If we don't like it - we write a polar chart extension.
>>>>
>>>> -R
>>>>
>>>>
>>>> On Mon, Sep 1, 2008 at 10:05 AM, Francesco Vivoli <f.vivoli@...>
>>>> wrote:
>>>>>
>>>>> Wrt to the polar chart, don't you think that changing it for a stacked
>>>>> bar chart is an option.
>>>>> We use it because we want to display multiple datasets, where each
>>>>> point represent a certain quantity.
>>>>> In the specific we are drawing a polar line (i.e, a segmented line that
>>>>> rounds the origin:)) for each asset group (sites or bu's).
>>>>> Every edge represent how much that group scored for a certain
>>>>> appliance, right?
>>>>>
>>>>> The problem with stacked bar charts is that each data point (an
>>>>> appliance for a group) is bound within [0,10], so if there are 5 appliances
>>>>> the whole bar can assume values within [0,50], with the upper value
>>>>> increasing with the number of appliances. This could lead to some
>>>>> visualization problems now that I think about it. If these SDKs provide
>>>>> zooming, which I don't know, it would be ok though.
>>>>>
>>>>> Another possibility is to have segmented bar charts (one bar per
>>>>> appliance/group, grouped by group), in this case we'd have lesser
>>>>> variability on the y's but a much wider chart.
>>>>>
>>>>> Finally, creating a polar chart in SWF would be cool. The only issue
>>>>> would be that I'd like for it to be better than JFreeChart's one, since
>>>>> right now we can't even put a label for the edges (the degrees numbers are
>>>>> hard-coded into JFree code-_-)
>>>>>
>>>>> F
>>>>>
>>>>> On Mon, Sep 1, 2008 at 9:52 AM, Roman Kalyakin <theorm@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Francesco,
>>>>>>
>>>>>> Yes. Open Flash Chart improved a lot within the last year. I checked
>>>>>> both OFC and Yahoo charts and they both don't have a polar chart. That means
>>>>>> that we have two ways: either display this data on another type of chart or
>>>>>> implement the polar chart on top of Open Flash Chart or Yahoo charts. It
>>>>>> requires however some knowledge of actionscript. I took a look at it though,
>>>>>> and it doesn't look so much different comparing to Java. So, I beleive it
>>>>>> would be not a big deal to implement it.
>>>>>>
>>>>>> Regarding the data format: Yes, JSON is more compact. And to adopt
>>>>>> Atalaya data format to the charts we can either change the format within the
>>>>>> chart or implement the xml->json converter. I think the second option is
>>>>>> better. We could even start using data in JSON format for the UI too as it
>>>>>> is more compact.
>>>>>>
>>>>>> What to choose. For me both are ok. Yahoo SDK seems more robust and
>>>>>> flexible. But it requires some coding. The fact that it's Yahoo also annoys
>>>>>> me a bit. But since it's just an SDK with primitives and not a set of charts
>>>>>> with yahoo logo on them, it's still a candidate.
>>>>>>
>>>>>> Cheers,
>>>>>> -Roman
>>>>>>
>>>>>> On Mon, Sep 1, 2008 at 9:32 AM, Francesco Vivoli <f.vivoli@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Roman
>>>>>>>
>>>>>>> I had given a look at the open flash chart thang a while ago, it
>>>>>>> looked good then and it seems they have improved. As for the yahoo sdk, I
>>>>>>> don't know enough about it to make a comment.The only thing is that an year
>>>>>>> ago we decided not to use yahoo UI nor GWT, because well, there was a direct
>>>>>>> link to these bigbig corps... I don't know, maybe it's me who's too
>>>>>>> skeptical.
>>>>>>>
>>>>>>> Ok, speaking from a purely technical perspective I'd say let's look
>>>>>>> at the requirements. Right now we use time series, pie and polar charts.
>>>>>>> While the first two are supported for sure, I'm not sure about the latter.
>>>>>>>
>>>>>>> In the case we can't make polar charts well, we still can rethink how
>>>>>>> to depict the same information: a stacked bar chart could maybe do the job,
>>>>>>> couldn't it?
>>>>>>>
>>>>>>> Then there is data format issue. As you know, right now we produce
>>>>>>> XML by default which could be fed into OFC, at least before. Nevertheless I
>>>>>>> don't think it's desiderable, JSON is much more compact as a format. Beside
>>>>>>> that, the XML that produce is atalaya-domain specific, whereas we should
>>>>>>> produce an OFC-specific one. Wrt we should start investigating how to
>>>>>>> produce JSON strings from our model, i.e how to refactor the all
>>>>>>> ChartBuilder chain.
>>>>>>> What do yo guys say?
>>>>>>>
>>>>>>> ciao
>>>>>>> F
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 7:32 PM, Roman Kalyakin <theorm@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As we discussed one of our initial goals is to move towards nice
>>>>>>>> charts, possibly flash. I've been checking current situation with flash
>>>>>>>> charts in opensource world and found this project:
>>>>>>>> http://teethgrinder.co.uk/open-flash-chart-2
>>>>>>>> I saw it before, but it used to be a charting server running on php.
>>>>>>>> Now, in version 2 they moved towards pure SWF + JSON. The charts look nice
>>>>>>>> and easy to use. It's GPL v2.
>>>>>>>>
>>>>>>>> There is another project that is worth attention:
>>>>>>>> http://developer.yahoo.com/flash/astra-flash/charts/examples.html.
>>>>>>>> It's a Yahoo SDK for flash and is not for charts only. The SDK is
>>>>>>>> under BSD. The only problem is that it's not a ready made SWF that reads
>>>>>>>> data from external file, thus it needs some flash/actionscript development
>>>>>>>> skills. However this option is more flexible because the SDK seems to
>>>>>>>> include a huge variety of primitives.
>>>>>>>>
>>>>>>>> What do you guys think?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> -Roman
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Atalaya-developer mailing list
>>>>>>>> Atalaya-developer@...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Atalaya-developer mailing list
> Atalaya-developer@...
> https://lists.sourceforge.net/lists/listinfo/atalaya-developer
>
>

--
Giacomo Collini - CISSP

Information Security Analyst

email: giacomo.collini@...
mobile: (+34)628332736

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Atalaya-developer mailing list
Atalaya-developer@...
https://lists.sourceforge.net/lists/listinfo/atalaya-developer