 I think now we have a really professional view on programming, and I'm more representing the amateur side. And thanks for the invitation first. I'm going to cover the design paradigm of the UNIX philosophy and how I relate to it. That's why we start by going back to the 70s somewhere in New Jersey at the Bell Laboratories. And they started to develop an operating system which is UNIX. And actually what I find interesting that it's quite a long time for when you think in computing time. So it's in 2013 they celebrated their 40 years uptime. It's like when you celebrate you use Comic Sans, it's very clear. And since I never really touched the genuine UNIX, we're talking more about what started with Richard Stolman and the GNU project. And so in 2007 I really got my first introduction to GNU Linux. And I pretty early came really interested in a lot of principles that were behind this operating system and how they were approaching stuff. And that's kind of the UNIX philosophy. It's really not a strict set of principles but more loose tenets or principles that can be applied. So this is like one collection of these principles. Like smallest beautiful, make each program do one thing well, build a prototype as soon as possible, choose portability over efficiency. So numerical data and flat ASCII files, use software leverage to your advantage, use shell scripts to increase leverage and portability, avoid captive user interfaces and make every program a filter. These are the principles more in detail. I will skip through this pretty fast. So we can have a look at the application and what I kind of interpreted this set of rules. So when I first got introduced to Linux, it was a big thing that you tend to, you have to get along with the command line. And the principles behind it, the simple function of piping, the output of one program into another, I really found interesting because it was like a very simple way to have a user interface that lets you build your own application and really do like a tool chain that lets you achieve what you want also in a very sometimes inefficient and unordinary way. It's not like there's one right way to do it. Prototyping is a learning process, very general principle but also interesting. That's not so much and that for me is really, it's like the fundament for a lot of works that I really look for file formats that are human readable. This can be understand and that can be manipulated not only with the application that it's meant for. Like for example in proprietary, a software would be like you have a Photoshop file format that you should or mostly edit with Photoshop but you have more general file format that you can lose a lot of different tools to manipulate. And that's also in a way important because I do mostly best scripting and it was interesting that it's not like a natural law that shell scripts are and not to do a thing like if you talk to a lot of programmers it's like it's so ugly to do shell scripting and I found it interesting that's actually people who do not think so and it was like awakening for me. Avoid captive user interfaces kind of relates to the small tool approach so you can really include your programs in a batch workflow on the comment line and you don't have to start the application to do something because in this way if you have a captive user interface you have to start that graphical user interface programs tend to become like islands. They are more harder to really be combined with another program and therefore you're kind of captured in this program. Just like 10 leather tenants and so for me that's like the extraction of this principles that kind of interested me most like I just explained and then we come to practical application in 2009. I had a chance to do for the Makeout Festival in Partier some design work. Beside the general design around the festival it included a processional generative poster setup. That's in a way what did happen and how you can see what I really wanted to do is how many different stuff I can connect and how do I connect it and what will come out of this. So what we do we have like I base preparation I call it. I create modules that I will use later on. The modules also included in this case the preparation of small processing sketches that will produce just an output in this case PDF. Like this modules I start in a certain directory structure. I will come to that later. When the generator or the engine is started what it does is it selects randomly one of the sketches. I think about 40 different generators. It collects some information and then the processing sketch is run. The way interesting is I was working on that time or the generator was running on a headless machine and therefore processing is actually not meant to be used without a graphical interface. But there is a workaround, this x virtual frame buffer. You can tell processing there is a surface and it runs. It exports PDF. I collect all this stuff in plain text files and from this collection I generate a lattice file. Render PDF is PDF. Let's have a short view of what came out. It's like I have set up the system and it produces a lot of variations of posters. Also very practical in this case was that I could replace just certain parts. We had to do since the festival was in France to do different versions. English and French. I have to search for what's poster in French. It's a fish. That's the collections. We had also different dean formats A3, A2, A1. And by just replacing the part of the language, which is like the title and the information, I used the same engine and just replaced a module. Shortly after there was a fork of the Makeout Festival, which was, I think, somewhere in the Netherlands. I don't remember. It's ChangeMod plus X art. There I used a similar engine, but basically replaced just some part of the process and was therefore able to reuse a lot of the work. I think that's kind of coming back to this modular approach. Since I tended to write small parts and not one monolithic thing, I was able to reuse on my own parts of the process. Yeah, so it's like this was for the other festival. And here, I use also PDF-Latic as a render engine. And what I did, I collected information about the processing programs that were used. They were kind of annotated in like a visual map. So you have these programs and you have, for each reference, what program produced this. Since we're running already out of time, I will go through this because more interesting is perhaps for the last LGM in Madrid. We also did some work. And interesting in this case is I think that we had a really separated part, which was also quite functional from the stability because we had a web interface where people could enter questions and answers regarding free software and graphic design. So, just shortly, that's where all these projects are collected. Really, it's more or less a mirror of the working environment. So you can browse through the directory and see, okay, here is, for example, the shell script as it used, which is quite messy. But that's also a point about this talk. I think it's so interesting what I do, but what enables me to do, and this is the set of principles. Okay, then it was this interface for questions of users or non-users or potential future users of free software. Either enter a question or give an answer. It's closed right now because a lot of spam boards are also interested in giving answers and asking questions. Okay, then we have the local interface. We have the input, which stores all the questions answered in a simple text file. This text file is synchronized to a local machine where all the generation of the posters happens, which is quite useful because actually you do not want to have something like this running on a web server because something could go wrong and you don't want your main web server to crash. It synchronizes the file. It generates for every new question-answer posters and then it pushes them up per FTP and they're available because that's part of the thing you have for the questions. I can see here all posters that were generated for these questions. You have the big text is the question and then you have all the answers attached to it connected to the illustrations, which are part of the eye-based preparation but you most probably have seen this. To make it more simple, I will give two very simple examples. Just to reduce what I see behind is the ASCII text thing. SED is like a common line utility. It's like a search and replace functionality really extended. With Inkscape, we have XML-based for SVG and therefore you can use the functionality which was originally intended as a useful thing to edit config files. You can also use on your Inkscape files. For example, just replace. In this case, you just replace who with bar and you do this actually in a visual level. That's what I find quite interesting that in Inkscape you have a very close connection between text and the source file. You have also the XML editor that you can access and you see what elements have what IDs and it's very useful because we're not just talking in this case about text but the same for colors. You can replace since it's all stored as plain ASCII text you can edit different things. It can be quite powerful because you can only replace in one layer if there is red then black should be blue or anything like this. You can really think up your applications. As it is kind of complicated. I didn't really get it until today. I just find examples and adapt them to what I need. So best resources as a day and one-liners. There you have a lot of examples. Second is automate everything. This example would be I used PDF2Kid with a function to use one PDF as the background for another one and in this case I just wanted to have a certain or all PDFs in the directory to be layered one above another. So I have really a simple loop that uses one PDF as the background of another and then this layer PDF becomes the background for the next round of the loop. The problem was that there was a maximum amount of times you could do this. This was like 20 times. But there we come back to another principle that computing time is cheap. I did just another conversion in this loop like flattening the PDF and all it actually does cost me is like, I don't know, two seconds in every loop and since automated I don't really care if you would do this by hand and do this save as or export it would be not quite useful. So interesting what is my kind of essence behind this I'm really keen on like human readable source files and accessible render engine to the comment lines can be a whole different stuff. It can be KDE and live source files that you can also edit on the comment line but generate a video from or it can be HTML or anything. So a showstopper is basically a binary file format lacking comment lines port. For example, I think looked in the Scribo's bug tracker it's recommended since 2004 that people want to have an export option so this would be really nice and kept with user interfaces. It's mainly problem for a lot of proprietary software which have like a scripting capability but you have to start the interface to do the JavaScripting so that's like for me of my opinion kind of useless. Future, yes, the same and we closed another principle of the UNIX philosophy distrust all claims for one true way so forget what I said thanks to the people that made a lot of the projects possible and time is over.