\chapter{Summary}

In this chapter I am going to evaluate the state of the project and set future goals for
the framework.
I'll also try and reflect on some of the most important things I have learned during
working on it, in case I've experienced something that might be useful for
someone else reading this in the future.

\section{Project Evaluation}

How do we define if a project is a success or not?
Instead of attempting to do so, in this section I am going to express
my personal feelings and opinions about the Tutorial Framework.
To get unbiased opinions I'd recommend asking someone who hasn't been maintaining
this project for so long.
I could promise to be as objective as possible, but I think that it is just better to
be honest and admit that I have a sweet spot for this project.

Currently a total of 63 tutorials based on the framework are running in production,
with new ones being released on a weekly basis.
These exercises have been solved several hundreds of times.
User feedback is getting better and better as the project moves forward.
As a maintainer, currently I know about a single unfixed bug in the framework, which
is getting reported by users as well.
There are more, of course, the world is never going to run out of bugs to fix,
but at least I sleep well knowing that things aren't breaking on a constant basis.
Considering that this is a one-year-old project including initial development,
I'd consider this a solid success.

We were able to achieve most --- if not all --- of the goals we have envisioned on the
beginning of this journey, and considering some of the things we have planned for the future
we are just getting started.

\section{I Have a Plan!}

In this section I'd like to set some goals regarding the future of the framework
\emph{apart} from implementing new features.
Features are important, of course, but they will always keep coming in, no
matter what we do and I have no fears: our roadmap is filled with awesome new
ideas.
Instead, what I'd like to focus on is areas that need improvement,
and some of the plans I have regarding these areas.

A very important thing that currently needs improving is language support.
While it is very easy to implement event handlers on arbitrary languages,
there are some things which are only convenient to do from Python.
The remedy here would be exposing all Python-specific functionality on TFW message APIs
as well, which should only take a few days of work for me to do.

Another issue is that some developers, who might have no experience in dealing
with low-level socket logic could find working with ZeroMQ somewhat frightening%
\footnote{Despite ZMQ is actually a lot easier to work with than raw TCP sockets}.
This is only problematic if there is no event handler library code for
their chosen languages of course.
A new idea I have been playing around with is somehow allowing developers to use
named pipes\footnote{\href{http://man7.org/linux/man-pages/man7/pipe.7.html}
{http://man7.org/linux/man-pages/man7/pipe.7.html}}
to implement event handlers, as working with these is similar to reading and writing
to simple files, a concept every developer is familiar with.
A similar idea is to allow registering simple shell commands as event handlers, with
the received message as a command line argument:
there are lot's of cases when developers don't want to keep listening for more
messages to handle, they just want a ``fire and forget'' type of approach.

Built-in event handlers could also have a config file like frontend components have
with \code{config.ts}.
This would allow developers to set them up without having to deal with additional
Python code, and would allow me greater freedom in implementing them, as I
wouldn't have to keep developers without Python knowledge in mind when working on these.

I'd also like to concentrate on stabilizing the API of the framework.
Currently each major release lasts for a few months before I am forced to break something
to accommodate new features.
While the communication of these breakages is fine --- we use mailing lists for this purpose
and our versioning scheme seems solid so far, this forces developers
to constantly update older tutorials to comply new API\@.
To make this better I'd need to consider planning ahead more, so that the newest API is flexible
enough to support new features on the roadmap and not get distracted as much by
other features emerging on the horizon.

Another thing is that I often feel like that there are some things in using TFW
that could be made a lot easier. As a maintainer sometimes I find it hard to
tell what these things exactly are, as I know the framework inside out, having written most
of the codebase myself.
I'd like to set some time aside to create tutorials using the framework myself,
so I can better narrow these potential difficulties down.
This would require me to be able to take things slow for a few weeks, as this is not
something that is possible to do effectively in a rush. In the summer months, maybe?

Currently the framework is proprietary software.
While it is not feasible to go open source today or tomorrow for various reasons,
we all believe that software which is free as in freedom \emph{is} the future.
As such, at some point I'd like to open source the whole thing if the circumstances will allow
the company to do so.

\section{Things That I Have Learned}

Despite being an enthusiast of \LaTeX{} for a few years now, I still managed to learn a great
deal about it while working on this text.
This might seem like something unrelated, but most documentation issues with software often
come from the fact that developers usually dislike writing documentation.
Since working with \LaTeX{} I \emph{love} writing larger bodies of text such as this,
as I just simply enjoy admiring quality typography which WYSIWYG%
\footnote{What You See Is What You Get} editors just seem unable to produce.

I've spent a long time working on and maintaining the Tutorial Framework.
While the list of technical things I've learned is long and exciting, I also feel like
I've learned a lot about supporting other developers, project management and communication.
Another thing that I've been able to learn is to adopt a more patient mindset while
working. Back in the day I used to be nervous because of deadlines and things not
working how they were supposed to, but now I know that these things are a part
of the job and one must be able to deal with them without getting agitated.
Any time I feel like something is not OK, I just try take a step back, relax a bit to
blow off steam and approach the issue without acting in haste.
I think this is not too related to working as a software engineer, but something
that can be applied to anything we do.

The most important thing, that I will always remember as a software engineer
and is something that I've learned during this period
is to never, ever lower my expectations regarding code quality.
No matter what anybody tells you about things like ``but we have to make haste and finish in time'',
in the long run, making compromises in code quality is always like shooting yourself in the leg.
We as professionals must always \emph{thrive} for excellence, and must always express our
deepest respect towards our craft.
The only way we can do this is by creating quality software while being a responsible
\emph{craftsman}.
It is a thing of great importance, which cannot be stressed enough, that in the software
field \emph{craftsmanship}%
\footnote{\href{http://manifesto.softwarecraftsmanship.org}
{http://manifesto.softwarecraftsmanship.org}} is what matters most.
Many developers fail to understand that no matter how insignificant the code you write
today may seem, software is art, and art is something worth pursuing just for the sake
of doing art itself.
\emph{If} that art has some purpose --- and usually the code we write has ---
that is a good thing, but not something that we always have to keep in mind.
More often than not will you find, that while creating that funky little piece of
code with no purpose back in the day, it is you who have learned something new and
valuable.