Attacking the November milestone

To conclude the works that had been conceived as of the NGI0 project plan (internal), as a developer I need to be aware of the next step that lies ahead, but also on the ones they are leading to.

Currently, for the first mission API anonymous view - create the definition is simple:

Departing from the point of not being a native Ruby coder, I can employ my current knowledge of computational systems to reverse engineer my current tasks. Rubberducking with myself here, I can explain them to me in a way, that will allow me to move forward towards the mission definition.

In that, I am first taking care of having a reproducible development environment¹, being able to run tests on the codebase² and have the domain model of my application³ specified.

Âą The first month of development
² wiki.c2.com/?CodeUnitTestFirst
Âł ddd.fed.wiki.org

These specifications are written as rspec tests and and will compare the model implementation against the expected definition.

From the side notes meanwhile scribbled from research at hack.allmende.io/incommon, I am able to infer more technical requirements to ease the development with develop for me, and possibly others.

Infrastructure

add a Dokku staging instance, to integrate develop in a production RAILS_ENV, donated by allmende.io, ecobytes.net

Testing and documentation

review and rewrite rspec tests for compatibility with ActivityPub model.
Either bonus: add apipie-rails HTTP API documentation

add rswag to get testable API specifications and interactive API documentation with Swagger UI, eventually deprecates rspec for HTTP API testing
Or bonus: add redoc for a screen-printed, non-interactive API documentation

write and review rswag API specification against CRUD requirement, adapt from rspec definitions.

set up rdoc documentation, push to some place like doc.incommon.cc/api or serve with an integrated HTTP file server at `api.incommon.cc/doc*

refactor README instructions to doc/, keep an overview there
mention the use of rails_panel


Further down the road are examples how to use byebug with Compose and adaptations to the incommon-docker package.

I will begin with a little further side tracking at the top of the list, as this investment in time will play out to be useful a lot in the future. Then the following will be much easier to tackle together.

@how Any opjections so far?

I am keen in resolving M1 with priority, since we were already supposed to start in September, and the work being done to recreate a development environment deemed neccessary to start nicely. In short: We’reI’m late. I hope the steps above don’t just set the bar higher, but will allow for a less steep learning curve right after they are implemented.


This happens, as I am staying in an old farm house in the beautiful, yet empty countryside of Oderbruch (east Brandenburg), a dried swamp 100 km east of Berlin close to the Polish border. Heating the building with non-regenerative resources is time consuming, and doesn’t bring the warmth one would wish for thinking straight in hours.

Therefore development is often interrupted in a physically demanding environment on a degrowth farm out in the nowhere. But LTE is good and stable, and food is plenty and tasty :wink:

hey @yala great that you got to the point of having a good working environment,

From now I agree with you that Anonymous View/Create is the main priority, and clearly it takes a bit of time to enter into a code and start dealing with it “courage et persistance”, I imagine its not easy to do this from a distance, maybe it would be good to have a chat? do you have any moment?

Nice thx, but I do not understand what is a Dokku staging instance

@how and @natacha are in the process of making a comparative documentation between specs in preparation for the intermapping, I think intermapping and comparative is preliminary to rewriting any spec, as we should do this in good intelligence with others.

All the rest I do not really know what it is about, I agree that documentation is crucial.

1 Like

Yes, I do not understand anything. I do not see what this has to do with the tasks at hand. I think you should focus on the tasks and not look ahead for other things we’ll be doing later. For example:

I do not know what dokku is and I don’t think it’s needed.

This is useful but not your concern, actually, @natacha and I are reviewing the models to prepare a synoptic view of what’s available, including AP compatibility.

apipie, rswag, redoc: not of our concern at this point: we’re on a proof of concept, and all these may become liabilities when we move on to the Object Capabilities requirements (since straight URIs like api/foo/bar won’t be accessible directly anymore) and we do not use the api/vN versioning stuff (we use HTTP headers for versioning).

We won’t be using rdoc. In general, use the Discourse for documentation, we’ll figure out something for doc.incommon.cc later – it’s not part of the tasks now.

Famous last words :slight_smile: Do not overengineer the documentation here. Aim for minimalism. We’ll have more funding to take care of proper documentation, once the API is ready to roll in a first version that other partners can use and think about. For the time being we need the basic functionality, and then move on to the real core of the decentralization (i.e., AP support and OCAP authorization to support Agents properly).

I appreciate your concern for long term stability of the development process, but I think the priority now is to iterate on the functionality. The risk is to get stuck into an existing (best) practice that is not entirely compatible with what we want to do (i.e., support decentralized databases and heteromorphic approaches that won’t tie the process simply to Rails).

1 Like

Good I was asking. Then I need to refocus my energies a little, in terms of minimalism, and attack the issues more directly with what is at hands.

1 Like

We started explaining https://talk.incommon.cc/t/model-compatibility-matrix-and-serialization-2/641 to help wrap your mind around the relation between ActivityPub and IN COMMON: you should see how separate concerns they are, and how indeed we need to figure out the details of what models and fields need to be matching the AP definitions, but it’s something we’re doing now.

Try focusing on the Anonymous Write, while we skim the specs…


Rubberducking… Yes indeed, it’s a necessary step, and very useful to help figure out documentation and other processes. It was fantastically useful to setup the Docker development environment, thank you!

Thank you for the recent work on documentation in the above link, but also esp. in

https://doc.incommon.cc/

and

They are helpful for rephrasing the above prospects into workable chunks.