octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Agora Octave: CSS preprocessors and continuous integration


From: Mike Miller
Subject: Re: Agora Octave: CSS preprocessors and continuous integration
Date: Fri, 10 Aug 2012 07:54:01 -0400

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 via email to

[Prev in Thread] Current Thread [Next in Thread]