89 lines
4.7 KiB
TeX
89 lines
4.7 KiB
TeX
\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 this 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 trying 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 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 hunders 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 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 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
|
|
apart from implementing new features (new features will always come in as we go).
|
|
|
|
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.
|
|
|
|
An other thing is that I often feel like that there are some things in using the framework
|
|
that could be made a lot easier. As a maintainer sometimes I find it hard to
|
|
tell what these things are, as I know TFW 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 difficulities down.
|
|
|
|
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
|
|
us to do so.
|
|
|
|
\section{Things That I Have Learned}
|
|
|
|
I've spent a long time working on and maintaining this project.
|
|
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.
|
|
|
|
A thing that I will always remember as a software engineer and I've learned during this period
|
|
is to never, ever lower my expectations regarding code quality.
|
|
No matter what anybody tells you about ``but we have to finish until'' and stuff like that,
|
|
in the long run it is always like shooting yourself in the foot.
|
|
We as professionals must always 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 as craftsmen.
|
|
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.
|