Rethinking Bounce

[timmacfarlane]

Hi all,

I've been working on a different direction for Bounce.

Bounce was originally an experiment in building a lazy, dependency
driven build framework. This kind of worked, in a technical sense, but
I essentially produced a sub-language akin to Haskell inside C#. While
this sounds cool, it's really not cool when people just want to deploy
websites.

The new direction is to keep some of the good aspects of bounce, those
being (IMO):

* An easy to use command line to code interface. It's easy to add
parameters and commands that can be called via the command line.
* Build scripts in C#. I found this to be particularly useful in my
experience. We were able to reuse test and production code in setting
up databases, configuring web.configs, and generally tweaking stuff in
the app using common code.

That's it.

The Task<T> stuff was a major obstacle for people unfamiliar with
bounce. I had to explain numerous times that the build code is
executed lazily: it runs only if some dependent task depends on it,
and it certainly doesn't run the way you write it. It's a sub-
language, it has very different semantics to regular C#, and because
of that it's damned confusing for the unsuspecting programmer.

Too hard, too weird. So I want to make it easier.

I spent some time over the weekend trying something new. The idea is
to rebuild a command line to code interface, so it's easy for people
to invoke code from the command line. And to rebuild all of the old
"tasks" into regular objects that can be invoked by regular C# code.
If you've ever used Rake, you should see some similarities.

Here's an example of what I have so far:

public class SomeTasks {
[Task]
public void WebSite(int port = 80, string name = "WebSite") {
// do stuff to install web site
}
}

And to invoke it:

bounce WebSite /port:4000

It's currently in the "simple_api" branch. No documentation yet.

This should be a good start. Next up will be to rebuild the various
VisualStudio, MSBuild, NUnit, IIS, Windows Service and MSMQ tasks into
a regular object oriented API.

One question remains to me though: what do we do with the old bounce?
There may still be some users out there who depend on the old API. My
approach at this stage is to keep the branch there, perhaps called
"legacy". Any bug fixes for the old API can be committed to that
branch, and the new "master" branch will carry on with the new API. If
there are any objections to this, let me know!

Otherwise, I'd like to know what you think. If there is anybody who
would like to see the (not yet) old API live on, then I'd like to hear
from you. Otherwise I'm headed for an all new bounce.

Cheerio,
Tim

[Alexander Beletsky]

Hi Tim,

Thank for that email.

First of all, Bounce is one of the best code I ever saw. Very nicely written, very cool ideas behind. 

As you might know, I attempted to use bounce in one of the project I work ( https://github.com/alexanderbeletsky/candidate ). At the begining it looked very promising, but at the end I got to conclusion - "I have to get rid of bounce". Why?

1. Big-ceremony setup code - bounce is not that kind of framework, as you might remember I did several pull request to allow it act more as framework. I want to reuse good code of checkout from SVN or Git or deploy web site on IIS, but instead I struggle through a lot of infrastructure. 

2. Support for async code. It might not have to much sense for writing "deployment scripts" right for command line, but it has much sense in my case then I run deployments from web application.

3. Logging - I still not sure how logging actually work. It does not put the info in log as long as root task finished.. and that's not cool to me, cause sometimes the deployment just hangs but I can see only empty log file till the task is finished by exception.

4. Timeouts and stuff - I think bounce lack some robustness. Timeouts, watches, re-runners is something that should make it more stable and error-proof in such unreliable environment.

Anyway, I'm happy you found a will to improve the project. I definitely vote for 'Simple-API' project. I would be happy if you take my considirations into account and happy to help with project.

Thanks,

--

Alexander Beletsky,

http://beletsky.net