This page lists projects Jappie made. If they listed here it means they’re worthy of being talked about. This mean they either some kind off value right now, or they used to do that. With this in a mind, a large host of projects Jappie worked on get eliminated. For example, that one time he decided to try out PureScript and barely got an hello world operational, although this could be considered a success, it does not have value to anyone else. Indeed most ‘practice’ school work gets eliminated, although the projects that were made as part of team exercises to practice professional work may qualify (depending on if Jappie can find it, and manage to get it running so he can screenshot it). Everything is worth what people are willing to pay for it, so all work Jappie managed to sell classifies. Certain hobby projects also count because they receive star on github or Jappie thinks they could be usefull.
Table of Contents
There are three status kinds:
- Active, Jappie intends to work on this in the future
- Abandoned, There is no intention of working on this in the future
- Finished, No more work is necessary, the goals were achieved.
And various types:
- Startup, attempt to change the world and get rich beyoned ones wildest dreams.
- School, project was executed to learn from it.
- Hobby, doing something for fun, with no intend of making money.
- Contract, realizing other people’s wishes in exchange for currency.
Raster is a makes rosters easy! This makes rostering easy for restaurants. We combine it with reservations to make late adjustments to the roster. The idea is that we can ensure there is always enough but not too many employees. This is currently used at Restaurant De Huiskamer. A blog post was written about a possible extension idea, which essentially uses Q-learning to predict where future employees should be planned.
I’m currently working on this as much as I can. At this point the site itself is much more up to date than this page. Automated planning is for example possible. The picture below is pretty dated at this point.
Figure 1: The raster project
2 Gaia chatbot
This chat bot is the result of my thesis, in this work he build a rule based chat bot. Which at the core uses a rule management system. Jappie is of the opinion that this technology is extremely valuable, any technique can be used for any inquiry (eg, machine learning, Bayesian etc), by usage of simple rules. Therefore one can relatively easily combine machine learning with traditional symbolic methods. During his work his teacher urged him to do a PhD on this work. Jappie for personal reasons at the time chose to decline it.
The personality is implemented by analyzing the structure of this graph, and by attaching some extra values to it. The inner workings are explained in detail in this blogpost. This project tries to emulate a doctor patient interaction where the user is the doctor. with the idea that doctors in education could practice social interaction more efficiently.
Figure 2: An instance of the Gaia chat bot running in a reference implementation made for the browser.
This project is a data gather tool that scrapes distrowatch, puts it into a graph format, and transforms the result so that it’s parse-able by gnuclad, which turns it into an SVG. Note that the one’s in the tile actually should be a pipe symbol, but github didn’t allow that.
The inspiration for this project was that the distribution image presented on Wikipedia, impressed Jappie so much that he decided to give Linux a try. This choice had a profound impact on his life. This lead to all kinds skills we can roughly summarize with the word ‘devops’. In fact his website is an almost direct effect of Jappie getting familiar with Linux at that time.
Later when he saw it again, and found out how it was made, he decided to improve upon it. Perhaps someday, someone else may also appreciate the magic that is Linux, and the power it provides.
A sample can be seen in figure 3. The program finds all distributions that are on distrowatch, however it turns out that there are some small mistakes in this data source. Fortunately the source CSV for the original was made available on the GNUClad website. One of the remaining tasks is to unify these data sources for a more complete picture.
Another possible extension is rather than going in a 1 dimensional direction, where left is earlier in time and right is later in time, the output could be done in a 2 dimensional direction. Where the center point is the begin point and time goes outward in circles. To do this however the GNUClad program needs to be either modified or a new SVG generator has to be made.
Figure 3: Sample of svg output of this program, left the program, right the original.
4 Schijt je rijk
The supporters union of soccer club Ruinen1 approached Jappie to make a software variant of a gambling system. Traditionally what they did was setting up a field where a cow would be unleashed. This field would have squares marked out by numbers. The public could beforehand buy several of these numbers. Then in whichever of these marked out squares the cow would shit, would have a winning number and got some price. There were some additional requirements, such as being able to have a pause between a round, specify the amount of rounds and squares.
The task at hand was thus to create a field, add squares to it, and let a cow wander about. It also had shown on a big screen. Jappie decided to implement this in a little language called Elm. The best way to consider elm is as a simplified Haskell, that strongly encourages to use a React/Redux like architecture (in fact Redux was inspired by the elm architecture). At the time Jappie didn’t even know about React and Redux, he just wanted to try a new language, the fact that elm could be deployed on a browser rather easily was a big plus too. This meant it could be displayed on the big screen almost surely.
The result can be seen in figure 4. It was consider to deploy the system on the website too, but since some of the assets contain copyrighted material not owned by Jappie he decided to just show a figure instead. In the figure we can see the cow and some of the areas it shat in. In this case 297 won, the round blue thing is a button to continue to the next round (provided by the supporters union).
Figure 4: Example of solexmarkt at the time, Jappie helped implementing the design in html but did not make the design. (image from the wayback machine)
Time pressure was significant whilst implementing this project. The price was agreed upon when starting the project, and it turned out to be quite a bit on the short side for Jappie. Then when the supporters union saw the final result and decided to ask several more features, Jappie decided to send them a bill describing the cost of each feature. Although the union was quite unhappy with this at first, it did halt the requirement creep. Only one additional feature was asked, which was rather small to implement, and additional currency was payed for that.
Jappie learned two things from this, first of all people understand requirement sizes much better when there is a currency value attached to it. Secondly, doing this kind of work full-time is probably not a good option, negotiating these kind of deals is very stressful and difficult. This is one of the reasons he decided to consider a full time job instead.
5 AI game space
This was an attempt to make an Age of empires like game, build to allow AI to compete with each other. One of the top priorities was network transparency, and therefore it was build on top of the akka actor framework. The graphics used was libgdx, and the implementing language was Scala.
The way networking was implemented was rather naive, sending the entire world state to each client on each drawn frame. The advantage of this is that you don’t have de-syncrhonization issues. However in practice it turns out that this far to slow.
The reason why networking had such a high priority was for allowing to execute multiple AI’s from different machines. This is of course not a good way of doing game design, one should rather focus on implementing the core mechanics on the game, and figure things such as networking out later.
The reason for listing it here is that the architecture is pretty nice. It was one of the latest projects he did in Scala, directly preceding 5OL. Jappie wouldn’t put this on his resume however because the only utility it provides is in having nice source code.
The reason for abandoning it was two fold. First of all Jappie didn’t want to invest more into Scala (or any JVM based language). Secondly he wanted to make another kind of game. Rather than direct command and control he wanted to try what became 5OL. Currently there are no plans for taking up this project again.
The host is functional and rather easy to install thanks to gradle. Yes Scala was combined with gradle, and it worked well.
Figure 5: The running gamespace in deployment phase, after pressing start you can also move these guys around but there isn’t much else going on.
For the course ‘games and agents’ Jappie worked in a team to re-implement a board game so we could study various AI methodologies upon it. We chose to do a board game as we wanted to focus upon the AI aspect rather than having to do much game mechanics. This was written in Python. Jappie did personally neuro-evolution with help of TensorFlow.
The resulting network did not perform as expected, but Jappie did learn a lot about neural networks. Fortunately his team mates did have more successful approaches, Q-learning was highly successful. The hand programmed solution performed by far the best. The full report is available, unfortunately the source can’t be made available because it would infringe the intellectual property of gravwel (the board game used).
Figure 6: The implemented gravitas game. Function was prefered over form.
This was the first contracting job Jappie accepted. It started out by some simple requests: “Please make my website rank higher into Google” and “Help me straightening out the design in HTML”. This was done by modifying the meta tags to rather be as general as possible for each page to be as specific as possible. The HTML was also cleaned up.
Figure 7: Example of solexmarkt at the time, Jappie helped implementing the design in html but did not make the design. (image from the wayback machine)
Several months later the request got extended. “Could I make the static html into a web shop system”. This was done by using two external libraries. First there was simplecartjs for offline cart configuration, and secondly there was CakePHP. For handling payment and storing the items to be displayed.
Being new to programming, Jappie still used PHP a lot. because he was a second year software engineering student he had also heard about MCV systems. Which was all the motivation he needed to give CakePHP a try. At the time he really enjoyed that framework, it felt much more powerful than just plain PHP. MySQL was used as a database, because Jappie was already familiar with that and he was already experimenting2 by doing CakePHP. Also at the time it probably didn’t even occur to Jappie to try something else.
The reason why the current website is no longer maintained by Jappie is because of an aversion of using PHP, and due to poor estimation and negotiation skills. He kept getting rather low pay for doing this kind of work. Which was the result of poor estimation of work, combined with requirement creep (and not knowing how to handle this). This result into pay which was barely above minimum wage at times. So he decided to focus upon his studies instead of trying to setup a consultancy.
8 De Huiskamer
This company is owned by Jappie’s parents. It’s a restaurant, and as one can imagine, it provides lots of opportunity for automation.
8.1 Plan system(s)
The first task was more of a boast, back in 2008 Jappie barely new some basic PHP and MySQL, yet he told his father he could make the scheduling of employees much easier by making a website for it. His father must have thought his son would’ve been crazy, but rather than dismissing this, he decided to challenge him. “If you think you can do this, do it, I’ll give you money for it” he said. Fast forward a month or two and indeed a system had been created.
The style was ugly, the UX was unfriendly, but it worked. It worked well. And it saved his father loads of time. This was actually the pre-pre cursor to the raster project. Unfortunately it is not trivial to make a screenshot of this project. However the succeeding project, was made two years later when Jappie had learned about Object Orientated programming and decided to implement his own MVC framework (don’t we all at some point). See figure 8.
Compare that to the raster project which can bee seen in figure 1. In which he used Django, bootstrap and every library he could find to make his life easier. The raster project is still not in it’s final form. However Jappie is eager to work on that again once he finds the time.
Figure 8: The precursor to the raster project. It isn’t particularly beautiful either, but used for years and packed with features.
8.2 Website designs
He also made the website design of de2dekamer.nl (see figure 9), and implemented it within the Drupal CMS. This was the first time where he started comparing options in choosing a CMS. He went with Drupal because at the time he read blog posts that said it was the better choice for developers (rather than WordPress).
Figure 9: De 2de kamer, design was made by Jappie.
After that he re-used this design and put it in place for dehuiskamer.com. Although this design is currently no longer used it can be still appreciated with help of the waybackmachine as shown in figure 10. This design is unfortunately no longer used as the owner wanted to have a website that worked good on mobile. At the time Jappie did not have enough time available to implement this.
Figure 10: De huiskamer, design made by Jappie, thanks to the waybackmachine.
In another instance of Jappie seeing his father doing repetitive tasks, he boasted he could mostly automate making offers for him. Where he only needed to insert certain variable and the program would generate the result for him.
This was what the offertex project was about. Because it’s a terminal based program, we can appreciate the output in plain text shown in source block 1. Essentially the program just asks you questions about the possible offer. An offer in this case would be about a potential wedding some customers want to organize. It does various other things such as calculating the price and making the time planning for the offer.
Selecteer een template 0: brief 1: brief_bedrijf 2: email Uw keuze: 0 specificeer datumfeest 19-02-2020 specificeer groepgrote 20 specificeer kinderen 10 selecteer een betreft: 0: <? diversen ?> 1: Bruiloft 2: Familiedag 3: Jubileum 4: Personeelsfeest 5: Receptie 6: Vergadering 7: Verjaardag Uw keuze:
9 Projects still to be added
These are some projects that should be added to this page. However for various reasons they are more hard to do. They were not done all at once because there is a lot of effort involved.
- game programming minor: platform game
- game programming minor: board game (in 3d graphics, XNA, etc)
- game programming minor: 3d stuff
- Android app: city to city carpooling
- Android app: pick up taxi
- Iceberg (argarius)
- Pokemon implementation with GDX and some Scala. (Although I forked this from a friend).
- Playing around with 3D for AI homework
These are different entities, apparently
There is, or should be an informal rule to programming projects that says the reasonable limit for experimentation is one. That is to say, only experiment with either one framework, one new database, or one new language. Don’t start mixing as it will impact productivity too much. Never mix and you don’t learn much.