Agora Octave: CSS preprocessors and continuous integration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Agora Octave: CSS preprocessors and continuous integration

Wendy Liu
Hi all,

I've been working on implementation details for Agora Octave (http://dellsystem.me/posts/socis-2012-with-octave/), and I was hoping to hear some thoughts on the following topics:

CSS preprocessing with Less.js (http://lesscss.org/): Standard CSS syntax is very limited and lends itself to code duplication and disorganisation. To counter this, Less.js pre-processes CSS and brings in variables, mixins, nesting, and basic operations to the mix. It's released under the Apache license. I'm planning on using client-side compilation for debugging and then enabling server-side compilation in production. Anyone have any objections to or see potential problems with using Less.js?

Continuous integration: Unit tests are very helpful in a project of this complexity. As development proceeds and the codebase increases in size, so will the number of tests and so, too, will the time taken to run all the tests. After a while it will become too cumbersome to run the tests regularly, especially if we want to ensure compatibility with multiple versions of Django and/or Python. I'm this vein, I'm thinking of using Travis (http://travis-ci.org/) for automated unit testing management; however, I'd like to know if the community has other recommendations, particularly if there is integration with Mercurial.

Thanks!

-Wendy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

Juan Pablo Carbajal
On Fri, Aug 10, 2012 at 7:31 AM, Wendy Liu <[hidden email]> wrote:

> Hi all,
>
> I've been working on implementation details for Agora Octave
> (http://dellsystem.me/posts/socis-2012-with-octave/), and I was hoping to
> hear some thoughts on the following topics:
>
> CSS preprocessing with Less.js (http://lesscss.org/): Standard CSS syntax is
> very limited and lends itself to code duplication and disorganisation. To
> counter this, Less.js pre-processes CSS and brings in variables, mixins,
> nesting, and basic operations to the mix. It's released under the Apache
> license. I'm planning on using client-side compilation for debugging and
> then enabling server-side compilation in production. Anyone have any
> objections to or see potential problems with using Less.js?
>
> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.
>
> Thanks!
>
> -Wendy

Hi Wendy,

Good to hear your work is progressing.

I have no experience at all about what you are asking, so what you
said sounds good, provided you know how to use these tools or learning
them will not hinder the Agora development.

I say go ahead.


--
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

Mike Miller
In reply to this post by Wendy Liu
On Fri, Aug 10, 2012 at 1:31 AM, Wendy Liu wrote:
> Hi all,
>
> I've been working on implementation details for Agora Octave
> (http://dellsystem.me/posts/socis-2012-with-octave/), and I was hoping to
> hear some thoughts on the following topics:

Like Juan, I don't know anything about either one but what I've just
read following your links.

> CSS preprocessing with Less.js (http://lesscss.org/): Standard CSS syntax is
> very limited and lends itself to code duplication and disorganisation. To
> counter this, Less.js pre-processes CSS and brings in variables, mixins,
> nesting, and basic operations to the mix. It's released under the Apache
> license. I'm planning on using client-side compilation for debugging and
> then enabling server-side compilation in production. Anyone have any
> objections to or see potential problems with using Less.js?

I've only looked at the splash page, but this looks beneficial.

> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Again, only what I've read in a few minutes, but AFAICT this locks you
in to git and github, correct? So the unit testing you are planning on
doing will only work on the github mirror repository?

The only problem I have with that is if it requires significant hooks
in the source tree to get it to work with travis. If travis is
non-intrusive, all the configuration is on its side, I can still run
"make check" or equivalent on my own terms, then it's just an external
tool that doesn't affect anyone but you, like whichever editor or
shell you prefer, and I'd say you can do what you want.

If you want the rest of the community to benefit from a CI tool, then
it should be completely free and I should be able to stand up my own
instance anywhere I choose, and point it at the original mercurial
repository. From the admittedly limited reading I've done on travis,
this is not the case currently.

--
mike
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

Jordi Gutiérrez Hermoso-2
In reply to this post by Wendy Liu
On 10 August 2012 01:31, Wendy Liu <[hidden email]> wrote:
> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Wendy, we have another CI tool for the GNU project. It's called Hydra:

    http://hydra.nixos.org/project/gnu

Maybe I'm stupid, but I don't think CI is all that important. I mean,
it's desirable, but not critical. Octave itself could benefit from CI
too, but since so many volunteers are regularly building it, we sort
of have our own crowdsourced CI system already. ;-)

If you decide to use CI for Agora, I would prefer that you write the
Hydra recipe (and it's VCS-agnostic, AFAICT). Here is an example for
Octave, but I don't know if it's actually correct:

    http://git.savannah.gnu.org/cgit/hydra-recipes.git/plain/octave/release.nix

I like the idea of using a framework for CSS, so go right ahead with that.

HTH,
- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

Wendy Liu
In reply to this post by Mike Miller
On 10 August 2012 07:54, Mike Miller <[hidden email]> wrote:
On Fri, Aug 10, 2012 at 1:31 AM, Wendy Liu wrote:
> Hi all,
>
> I've been working on implementation details for Agora Octave
> (http://dellsystem.me/posts/socis-2012-with-octave/), and I was hoping to
> hear some thoughts on the following topics:

Like Juan, I don't know anything about either one but what I've just
read following your links.

> CSS preprocessing with Less.js (http://lesscss.org/): Standard CSS syntax is
> very limited and lends itself to code duplication and disorganisation. To
> counter this, Less.js pre-processes CSS and brings in variables, mixins,
> nesting, and basic operations to the mix. It's released under the Apache
> license. I'm planning on using client-side compilation for debugging and
> then enabling server-side compilation in production. Anyone have any
> objections to or see potential problems with using Less.js?

I've only looked at the splash page, but this looks beneficial.

> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Again, only what I've read in a few minutes, but AFAICT this locks you
in to git and github, correct? So the unit testing you are planning on
doing will only work on the github mirror repository? 

The only problem I have with that is if it requires significant hooks
in the source tree to get it to work with travis. If travis is
non-intrusive, all the configuration is on its side, I can still run
"make check" or equivalent on my own terms, then it's just an external
tool that doesn't affect anyone but you, like whichever editor or
shell you prefer, and I'd say you can do what you want.

If you want the rest of the community to benefit from a CI tool, then
it should be completely free and I should be able to stand up my own
instance anywhere I choose, and point it at the original mercurial
repository. From the admittedly limited reading I've done on travis,
this is not the case currently.

--
mike

Yes, it only works in conjunction with github. However, the only thing that travis really requires is a configuration file in which you can tell it what dependencies you need, what worker you want to run it on, and what command to run to execute the test script. The actual testing would be completely CI-platform-independent. In fact, you could always run it on your own machine (not `make check`, but `python manage.py test`), with the same results - Travis just obviates the need to do that. So it's really a non-intrusive, external tool (and I won't even need to add the Travis configuration file to the Mercurial repository).

On 10 August 2012 08:10, Jordi Gutiérrez Hermoso <[hidden email]> wrote:
On 10 August 2012 01:31, Wendy Liu <[hidden email]> wrote:
> Continuous integration: Unit tests are very helpful in a project of this
> complexity. As development proceeds and the codebase increases in size, so
> will the number of tests and so, too, will the time taken to run all the
> tests. After a while it will become too cumbersome to run the tests
> regularly, especially if we want to ensure compatibility with multiple
> versions of Django and/or Python. I'm this vein, I'm thinking of using
> Travis (http://travis-ci.org/) for automated unit testing management;
> however, I'd like to know if the community has other recommendations,
> particularly if there is integration with Mercurial.

Wendy, we have another CI tool for the GNU project. It's called Hydra:

    http://hydra.nixos.org/project/gnu

Maybe I'm stupid, but I don't think CI is all that important. I mean,
it's desirable, but not critical. Octave itself could benefit from CI
too, but since so many volunteers are regularly building it, we sort
of have our own crowdsourced CI system already. ;-)

If you decide to use CI for Agora, I would prefer that you write the
Hydra recipe (and it's VCS-agnostic, AFAICT). Here is an example for
Octave, but I don't know if it's actually correct:

    http://git.savannah.gnu.org/cgit/hydra-recipes.git/plain/octave/release.nix

That's true, it's definitely not critical, especially at this stage. It's just one of those additional tools that I think will improve the development process for Agora Octave.

I didn't know about Hydra. It looks interesting, although I can't find much information on it. Is it easy to integrate it with Python?
 

I like the idea of using a framework for CSS, so go right ahead with that.

HTH,
- Jordi G. H.

Great. 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

Jordi Gutiérrez Hermoso-2
On 10 August 2012 14:11, Wendy Liu <[hidden email]> wrote:

> On 10 August 2012 07:54, Mike Miller <[hidden email]> wrote:

>> On Fri, Aug 10, 2012 at 1:31 AM, Wendy Liu wrote:

>> > I'm this vein, I'm thinking of using Travis
>> > (http://travis-ci.org/) for automated unit testing management;
>> > however, I'd like to know if the community has other
>> > recommendations, particularly if there is integration with
>> > Mercurial.
>>
>> Again, only what I've read in a few minutes, but AFAICT this locks
>> you in to git and github, correct?

> Yes, it only works in conjunction with github.

If that is the case, I would really prefer if you de-emphasised the
importance of using Travis. I won't push the point if you really want
to use Travis, but Agora being sort of a GNUish package, well, y'know:

    http://mako.cc/writing/hill-free_tools.html

Focus on the other parts of the Agora project. I'll work on figuring
out the Hydra manual and using it with Agora:

    http://hydra.nixos.org/build/2923466/download/1/hydra/manual.html#id1015862

We should be using that more properly with Octave anyways, so me (or
you!) learning Hydra and the Nix language won't be a waste of time in
the long run.

I'm looking forward to next week's output. :-)

Thanks,
- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Agora Octave: CSS preprocessors and continuous integration

rezahousseini
This post has NOT been accepted by the mailing list yet.
I think this is a very good idea to build octave with the support of hydra. And at Delft University of Technology they've a big build farm and are willing to host open source projects, did someone contact them already?
Loading...