2018-12-01 16:07:24 +00:00
|
|
|
\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
|
2018-12-03 15:38:22 +00:00
|
|
|
working on it, in case I've experienced something that might be useful for
|
2018-12-02 20:01:18 +00:00
|
|
|
someone else reading this in the future.
|
|
|
|
|
|
|
|
\section{Project Evaluation}
|
|
|
|
|
|
|
|
How do we define if a project is a success or not?
|
2018-12-03 15:38:22 +00:00
|
|
|
Instead of attempting to do so, in this section I am going to express
|
2018-12-02 20:01:18 +00:00
|
|
|
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.
|
2018-12-03 15:38:22 +00:00
|
|
|
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.
|
2018-12-02 20:01:18 +00:00
|
|
|
|
|
|
|
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 hunders of times.
|
|
|
|
User feedback is getting better and better as the project moves forward.
|
2018-12-03 15:38:22 +00:00
|
|
|
As a maintainer, currently I know about a single unfixed bug in the framework, which
|
2018-12-02 20:01:18 +00:00
|
|
|
is getting reported by users as well.
|
|
|
|
There are more, of course, the world is never going to run out of bugs to fix,
|
2018-12-03 15:38:22 +00:00
|
|
|
but at least I sleep well knowing that things aren't breaking on a constant basis.
|
2018-12-02 20:01:18 +00:00
|
|
|
Considering that this is a one year old project including initial development,
|
|
|
|
I'd consider this a solid success.
|
|
|
|
|
2018-12-03 15:38:22 +00:00
|
|
|
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
|
2018-12-02 20:01:18 +00:00
|
|
|
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
|
2018-12-03 15:38:22 +00:00
|
|
|
apart from implementing new features, as these will always keep coming in, and we
|
|
|
|
have some great ones planned, that I can promise.
|
2018-12-02 20:01:18 +00:00
|
|
|
|
|
|
|
First of all I think that we need to put more focus on developing TFW, as currently
|
|
|
|
other projects are often being priorized over it.
|
|
|
|
While some of these are understandable, the framework is a very promising project
|
|
|
|
with great potential and deserves more attantion from us.
|
|
|
|
The fact that it is stable does not validate neglecting it.
|
|
|
|
|
|
|
|
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 accomodate 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.
|
|
|
|
|
2018-12-03 15:38:22 +00:00
|
|
|
An other thing is that I often feel like that there are some things in using TFW
|
2018-12-02 20:01:18 +00:00
|
|
|
that could be made a lot easier. As a maintainer sometimes I find it hard to
|
2018-12-03 15:38:22 +00:00
|
|
|
tell what these things exactly are, as I know the framework inside out, having written most
|
2018-12-02 20:01:18 +00:00
|
|
|
of the codebase myself.
|
2018-12-03 15:38:22 +00:00
|
|
|
I'd like to set some time aside to create tutorials using the framework myself,
|
2018-12-02 20:01:18 +00:00
|
|
|
so I can better narrow these potential difficulities down.
|
2018-12-03 15:38:22 +00:00
|
|
|
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?
|
2018-12-02 20:01:18 +00:00
|
|
|
|
|
|
|
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
|
2018-12-03 15:38:22 +00:00
|
|
|
the company to do so.
|
2018-12-02 20:01:18 +00:00
|
|
|
|
|
|
|
\section{Things That I Have Learned}
|
|
|
|
|
2018-12-02 23:24:06 +00:00
|
|
|
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.
|
2018-12-02 20:01:18 +00:00
|
|
|
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.
|
2018-12-03 15:38:22 +00:00
|
|
|
An other 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 of 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.
|
2018-12-02 20:01:18 +00:00
|
|
|
|
2018-12-02 23:24:06 +00:00
|
|
|
The most important thing, that I will always remember as a software engineer
|
|
|
|
and is something that I've learned during this period
|
2018-12-02 20:01:18 +00:00
|
|
|
is to never, ever lower my expectations regarding code quality.
|
2018-12-02 23:24:06 +00:00
|
|
|
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
|
2018-12-02 20:01:18 +00:00
|
|
|
deepest respect towards our craft.
|
2018-12-02 23:24:06 +00:00
|
|
|
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.
|
2018-12-02 20:01:18 +00:00
|
|
|
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.
|