writing test

how-to-make-your-server-run-4x-faster/writings/4x-faster.md

@@ -1,15 +1,89 @@
-[How to make your server run 4 times faster](https://git.xpub.nl/kamo/4x-faster)
 
-From the perspective of hosting others into "our" code, documentation becomes a form of hospitality. A form of care for a shared space. 
 
-In XPUB, each group begins its two-years programme by setting up a self-hosted server. We called ours Soupboat, and it houses many of our prototypes and experiments. This small server, running on a Raspberri Pi, feels like a place to call home on the internet. Over the past two years we have done all sorts of projects there: generated web-to-print publications, custom CMSs to keep track of birthdays, Etherpad documents, and soup recipes, workshops, personal wikis, and so on. While living on a server with others, my approach to code began slowly to change. Publishing open git repositories, instead of hiding behind private ones. Writing more readme files to be more generous with friends and colleagues and tutors. Cultivating small gestures and rituals, like leaving comments in config files to remind others where to mount the next app or where to find some credentials.
+From the perspective of hosting others into _our_ code, documentation becomes a form of hospitality. A form of care for a shared space.
+
+
+In XPUB, each group begins its two-years programme by setting up a self-hosted server. We called ours Soupboat, and it houses many of our prototypes and experiments. This small server, running on a Raspberri Pi, feels like a place to call home on the internet. Over the past two years we have done all sorts of projects there: generated web-to-print publications, custom CMSs to keep track of birthdays, Etherpad documents, and soup recipes, workshops, personal wikis, and so on. 
+
+While living on a server with others, my approach to code began slowly to change. Publishing open git repositories, instead of hiding behind private ones. Writing more readme files to be more generous with friends and colleagues and tutors. Cultivating small gestures and rituals, like leaving comments in config files to remind others where to mount the next app or where to find some credentials.
+
+This awareness grew by acknowledging the particular context of this [situated software](https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html): a personal yet public server, shared between less than twenty users. 
+
+```
+[ expand ] 
+shared server
+shared space
+tools
+```
+
+In many readmes for example, the explanations are tailored specifically for the Soupboat, and they cannot probably be ported 1:1 somewhere else. Code can never be ported 1:1 somewhere else. Nonetheless, the hardware and software space are prepared to host new guests.
+
+
 
-At the same time, this awareness grew by acknowledging the particular context of this [situated software](https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html). In many readme files for example, the explanations are tailored specifically for the Soupboat, and they cannot probably be ported 1:1 somewhere else.  
-Nonetheless, the space is prepared for hosting new guests.
-_(maybe expand a bit here)_
+NGINX is a web server gateway interface: a piece of software used to orchestrate the interactions between the internal network of a server and the external world. It is a central aspect of self-hosting practices and server maintainance, and because of that is also major cause of lot of headhaches. My experience with NGINX has always been one of trial and error. Being unfamiliar with the basic concepts of server itself, navigating the official documentation always proven to be really difficult. On top of that the particular situation of our configuration added some spices to the whole process, making it even more complicate. (Our server is connected to the real world through an ultra-protected institutional network, routed through a common hub with a VPN) To found a working configuration required hours and hours of attempts, and that's why the instinctive reaction was to put the same amount of hours into writing some pieces of documentation for it.
 
 [NGINX configuration](https://git.xpub.nl/kamo/pad-bis#nginx-configuration)
 
+Drw is an app to gather drawings for live visuals. During a concert or a performance, the public can draw from their smartphone in realtime. On the other end of the drw server a destination receives the drawings encoded as SVG graphics, and can use them as source material for generating visuals. It was developed in a moment of shift from the usage of SaaS platforms such as Heroku and Northflank to a more DIY and hands-on server practice. These services make configuration and setup matters of one click, hiding and automating most of the requirements. They are super handy because even without experience one can put online an app in minutes. At the same time they feel a bit like black boxes, where because of complexity what's happening behind the scene is rendered opaque. Another aspect concerns consumption and proportions: do I really need these massive systems with millions of features, automations and magic just to put online my small drawing app that will have at max some dozens of users on a friday night performance? Drw was a moment to explore the practical implications of an alternative, self-hosted approach.
+
 [Drw - Going online](https://git.xpub.nl/kamo/drw#going-online)
 
+## Open ended
+
+Drw is an app to gather drawings for live visuals. It is organized as a decoupled network of sources and destinations, where different drawing apps and output surfaces can coexhist at the same time. It is simple to plug-in different sources and destinations, from a wide variety of platforms. The only requirements is websocket communication. One can draw from a web app on their smartphone and send it to a projection, or from different motion sensors to a pen plotter. It's programmed to be a simple and extensible tool, welcoming modifications and interventions from others, as well as hosting others applications. 
+
+[Drw - Setup](https://git.xpub.nl/kamo/drw#setup)
+
+> (ah ah! less work for us)
+
+[Drw - How does it work](https://git.xpub.nl/kamo/drw#setup)
+
+The Workbook is a tool to keep track and annotate configurations for synthetizers and other instruments. It was developed together with [Supi](https://supisara.info/) as a surface to facilitate the learning process of sound synthesis. With digital instruments one can easily save presets and load them as necessary, but with analog and modular ones things are more messier than that. Often a sound is an ephemeral combination of knobs turned to a certain degrees and cables connecting sources and destinations together. The programmer familiar with the horrors of spaghetti code will recognize the same irresistible danger in spaghetti patching. Messing with all these handles is for sure one of the joys of playing with such instruments, but to remember which configuration generated that specific sound can be tough. The Workbook offers a way to store configuration snapshots by turning knobs and drawing cables. It is an open-ended tool, that let users upload their own instruments. The readme is far from complete, but a lot of efforts were put to highlight this extensibility. Core of the writing was the workbook as a starting point, and not as a finished product. An invitation for users to get hands-on and fiddle with code with a non-standard and non-perfect attitude.
+
+[Workbook - Add an instrument](https://git.xpub.nl/supisara/workbook#3-add-instrument)
+
+Seq is a csv sequencer that delegates logic to the user from the very beginning. As the [workbook](https://git.xpub.nl/supisara/workbook) and [drw](https://git.xpub.nl/kamo/drw) can be seen more as a platform than a tool itself. Or maybe a device to stimulate tool-thinking and prototyping. Its readme is not an exaustive explanation of the code, but rather a list of implementation examples, each a way to attune and think to the sequencer in a different way.  
+
+[Seq - an open-end csv sequencer](https://git.xpub.nl/kamo/seq)
+
+
+
+[How to make your server run 4 times faster](https://git.xpub.nl/kamo/4x-faster)
+
+
+
+
+
+
+
+## Situated documentation
+
+Universal solution 
+multiplicity
+
+
+-   **situated docs**
+-   it's a 2 words title
+-   **docs** stands for documentation
+-   the documentation of coding related practices
+-   code documentation
+-   instruction on how to use and make software
+-   how to be a developer™
+-   or how to do things with code without being a developer™
+-   that is actually the case for most of the people that enjoy coding
+-   or a way to enjoy coding more
+
+-   **situated** refers to the context of research
+-   which kind of software to look into
+-   _situated software_
+-   site specific software
+-   emerging from a community
+-   that can rely on a a social infrastructure
+-   used by specific social groups instead of generic set of users
+-   that don't need to scale
+-   that don't need to solve every problems
+-   our software
+
+Some intresting frictions arise when thinking about situated code documentation: how to share knowledge about very specific programming practices with other contexts? How to remain legible and accessible, for ourselves, for the ourselves of the future, and for others, while at the same time preserving specific and characteristic decisions? 
 
+Usually documentation doesn't take into account the messiness of coding contingencies, where multiple software coexist on the same server and configurations conflict or are installed with different setups. Collective learning moments and small, shared rituals can bridge the gap between the default setup described in documentation and a real-world, situated one.

how-to-make-your-server-run-4x-faster/writings/temp.md

@@ -0,0 +1,15 @@
+This pathway is a collection of readme files from small tools with a focus on open-endedness: where code asks for more code, and invite users to expand and re-elaborate what is framed as a starting point, more then a finalized instrument. 
+
+Read these readme as invitation, as provocation, as a way to lure developers in with the promise of full automation, as a way to delegate hard work to other developers, as a way to delegate the creative parts to other artists, as a way to delegate the demanding aspect of writing even more documentation to possibly future coders.    
+
+Drw is an app to gather drawings for live visuals. It is organized as a decoupled network of sources and destinations, where different drawing apps and output surfaces can coexhist at the same time. It is simple to plug-in different sources and destinations, from a wide variety of platforms. The only requirements is websocket communication. One can draw from a web app on their smartphone and send it to a projection, or from different motion sensors to a pen plotter. It's programmed to be a simple and extensible tool, welcoming modifications and interventions from others, as well as hosting others applications sharing the same infrastructure.
+
+[Drw - Setup](https://git.xpub.nl/kamo/drw#setup)
+
+ 
+
+Seq is a csv sequencer that delegates logic to the user from the very beginning. As the [workbook](https://git.xpub.nl/supisara/workbook) and [drw](https://git.xpub.nl/kamo/drw) can be seen more as a platform than a tool itself. Or maybe a device to stimulate tool-thinking and prototyping. Its readme is not an exaustive explanation of the code, but rather a list of implementation examples, each a way to attune and think to the sequencer in a different way.  
+
+[Seq - an open-end csv sequencer](https://git.xpub.nl/kamo/seq)
+
+