Witnet's feedback on developer experience

The Witnet team built on Aragon at the Ethereum Madrid Hackathon. I jumped on a call with them and asked about their dev experience.

Publishing some notes from the call here.

aragonCLI was broken

This is not even related to aragonCLI itself, but probably to one of its dependencies. Dependencies break often, and it definitely feels like building a sand castle.

I think the aCLI maintainers have been improving this by reacting quicker to these kind of issues, but maybe we could set up something that installs the CLI on a VM every day, and alerts if it doesn’t work?

Too overwhelming

They felt overwhelmed by all the different components (aUI, aAPI, aCLI, aOS…) and would have preferred to just see a “simple” mode, and then have more advanced documentation as needed.

We should also make the initial docs better, so the architecture feels easier to understand.

Unclear tradeoffs

With getting into frameworks, developers give up some flexibility in exchange for some benefits.

We need to be more clear and direct on the tradeoffs, maybe a documentation page about it would be great.

Permission system feels complex

We should expand on the tradeoffs of the permission system, since that’s the most important thing we ask developers to buy into.

It takes forever to run the first time

They cited installing dependencies as the main bottleneck.

aragonUI is easy and enjoyable

They highlighted that aragonUI felt minimal and easy to adapt without hacks, which is good to hear!

9 Likes

I completely agree. I remember “long” time ago (during an Offsite discussion) we were talking about 3 levels of documentations.

4 Likes

Couldn’t agree more. I’ve had similar struggles.

In the longer term, I think it’d be useful to have a book that gives you an overview of Aragon from first principles.

Another devoted to examples (some people learn better that way).

And a third that takes you through building a few apps that get progressively more advanced.

5 Likes

Amen to that! :laughing::sob::laughing:

That’s almost the setup we have:

  • A couple of end-to-end tests that run the binary directly (ensuring npm installs the CLI correctly)
  • They run on every commit/pr (although it might make sense to do it only on master as they are kind of heavy)
  • They run on various node versions: 8, 9, 10, 11 ( and soon 12 )
  • They run on linux machines (hopefully soon on Windows machines as well)
  • Today I’ve enabled a Cron Job in Travis as well, so that if no build occurred in the last 24h it will get triggered

The only thing this setup is not accounting for is a broken npm deployment (this is because it gets build and installed locally).
That being said, having Continuous Deployment in place would remedy this, and we are almost there.

In addition to this setup, we started using shrinkwrap files (lockfiles) since v5.9.0 so if a new version of a dependency is out and is breaking, it should not affect anyone.

I think now we are almost in a place where there is no reason for it to break unexpectedly…but at the same time when it comes to people using newer dependencies like node v12 (which was released on 2019-04-23) there isn’t much to do, but wait… I suppose this is the problem the Witnet team was experiencing (?).

I say almost because these tests cover installation, aragon run and a few other. (recently aragon apm publish broke so we definitely need to write more tests - at least to cover common patterns)

2 Likes

This is very good to know! Excited to see you are working to minimize the possible “oh it’s not working I’m going elsewhere” surface :muscle::muscle:

1 Like

I too have had difficulties. The learning curve is steep and the information is complex (often seems unrelated at first). Might be good to add some “overview guides” as an introduction for hack.aragon. Something like this post, but for all the various components.