==============
 Useless code
==============

Generally I am happy with my work codebase: it is just a few KLOC,
including inline documentation and comments, to work with a dozen of
awkward specialised (and often unspecified) network protocols and file
formats (using separate unixy programs for each), and with a few
databases. This is after about 7 years of development, constantly
trying to keep the bloat away, following the DRY principle, and with
all that code currently being in Haskell.

More than a year ago development of a new project started: a
standalone version of a part of the system that is normally provided
as a service. It didn't seem like much work at first: my regular
programs are easily reusable, front end was outsourced to be made in
JS, and I only had to prepare a database and a basic bridge between
that database and HTTP. Access control was implemented using
PostgreSQL row-level security policies, custom aggregate functions
were used for data aggregation (the database is mostly for time series
data), so the web back end was indeed supposed to be trivial.

By now that bridge is about 40% of my whole codebase, even after
refactoring with multiple attempts to get rid of the boilerplate, and
while trying to keep the API simple and consistent. The code itself is
also awkward, and keeps growing as new endpoints or their parameters
get requested. I kept wondering what can be done about it, and tried
to introduce restricted SQL queries, but that didn't take off, since
most of the front end was implemented already. Recently I learned
about PostgREST, which could have replaced most of the custom web back
end, if not all of it, but now is not the time to change the API.

Not that I am happy with this HTTP-based API business in general, and
the front end in this case is semi-broken at this stage, but shall I
have to do something similar in the future, most likely I will use
either PostgREST or (restricted) SQL: mapping queries and structures
between HTTP and SQL is pretty dull on its own, and can be quite a
pain if you do custom mappings.

That is one way to get a pile of useless code that should still be
maintained.


Phlog cleanup
=============

Not quite related to the primary topic, but I decided to truncate the
phlog directory; there is quite a lot of mostly useless information
already, and I am trying to turn the relatively useful bits into
properly organised notes on my web homepage, so keeping old posts
seems to just clutter it.


----

:Date: 2018-12-26