Staying Focused

2018-12-28 14:14:00 +0100

A while ago I’ve read Christopher Lemmer Webber’s post Will your tooling let me go offline and found it inspiring (a lot of his blog is inspiring for me, for that matter).

It starts with a quote from Donald Knuth:

I have been a happy man ever since January 1, 1990, when I no longer had an email address. I’d used email since about 1975, and it seems to me that 15 years of email is plenty for one lifetime.

Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don’t have time for such study.

Source: Knuth versus Email.

Christopher complains about tools having online-only documentation, which is counterproductive because going offline is the key to good focus and productivity. I like the idea of going offline for certain periods of time a lot and would like to do it at work and in my private life, but sometimes it’s hard. But how hard is it, and how much of it is just my habit of being online?

Not knowing exact answers, I’ve decided to be going offline more often. Therefore, I have:

  1. uninstalled Fediverse client from my phone;
  2. extended periods between mail-checks on my phone and at work (main account: 1 hour, less important accounts: 3 hours);
  3. got rid of all email notifications at work – now I only check for email when I want to (though I keep a few custom notifications based on rules so I don’t miss on things that are actually important);
  4. set up Nextcloud applications Notes and Bookmarks, to be able to collect notes and references to use later;
  5. switched from Fennec to Firefox Focus;
  6. started using Android’s Do Not Disturb feature when doing something I want to focus on (e.g. writing this entry).

I’ve already been using bullet journal for some time, which also helps because it’s completely analogue and offline, so I can use it without my laptop or phone. I like it a lot for several reasons, but perhaps it’s a topic for a blog post of its own.

Apart from the list above, there are other things one can do to further limit distractions:

  • full-screen mode of editor, IDE or whatever one’s using (and when full-screen is misssing, at least maximize the app);
  • specific distraction-limiting features of one’s tools (e.g. IntelliJ IDEA has a distraction-free mode);
  • one can always reduce the amount of information on the screen by customizing one’s tools. For instance, I’ve hidden almost all toolbars in MS Word at work, so I can focus on the text I’m reading (I rarely write anything).

All this is working great, esp. when used with some discipline and planning: I’ve set up calendar blockers for periods of time I want to use for uninterrupted work. Of course I’m flexible and can shift my blockers or cancel them altogether when there’s an important meeting I need to attend. But most of the timie it gives me a chance to focus and it’s got the additional benefit of a reminder, which helped me develop a habit.

What I like about my Nextcloud setup is that it gives me all I need to do to plan things and work on them: I put events in my calendar for things I don’t want to miss on particular day, I save bookmarks for things I want to read later or buy or work on in the future (e.g. when writing a longer text about a particular topic, it’s a great way to collect materials to read in preparation) and I keep notes about all this (things to write about, things I’ve read, etc.).

That Do Not Disturb feature of Android is also very useful, esp. thanks to the ability to define how long one wants to keep distractions away.

My main conclusion is that it pays off to learn one’s tools well because they can sometimes do a lot to help us stay focused. But of course even with the best tools, environment can always make it harder and then it’s all about creative approach and the art of the possible.

Learning Scala

2018-12-23 12:28:00 +0100

Some time ago I’ve decided I’d like to learn Scala. I remember a friend of mine learning it a few years ago and my general impression of the language: quite powerful, but with a concise syntax. Concise syntax is a great advantage over Java, but I didn’t know Scala too well so this comparison is far from fair.

The problem I’ve been solving was counting (and displaying) combinations of chess pieces on a board where none of them would take / capture another.

Since Scala is a functional language, I’ve been focusing on using typical approaches found in functional programming: recursion (with tail-call optimization when possible) instead of while-do iteration, simple immutable data structures and so on.

My initial approach has been to represent a chess board as a 2-dimensional vector (Scala has a persistent data structures, including one called vector, based on Clojure’s implementation of a similar data structure). That way I could provide O(1) access to each piece on the board. I’ve implemented figures as case classes, with two special objects (scala has singletons built into the language):

  • Nothing, representing a free location on the board, and
  • Captured, representing a location on the board that was not occupied by any figure, but it was unsafe to put any figure there because it would be taken by another one.

My assumption has been that a persistent data structure would save me from OOM thanks to sharing common parts of board representations. Well, it hasn’t. I’ve launched my first version of the program with a 7×7 board and got an OutOfMemoryError quite soon (though it did work well with boards small enough). So I’ve faced the good old problem of being fast or correct.

I’ve started redesigning my code to reduce the memory footprint by taking another approach:

  1. each figure would know its location and based on its coordinates it would calculate unsafe locations;
  2. internally, board would be represented by a list of figures on the board (therefore adding a new figure was cheap and easy to repeat with different configurations: by “consing” a new list);
  3. everything else would need to be calculated.

With this approach there was very little to store in memory but probably a large amount of repeated calculations. Nonetheless this version of my code did produce output for a 7×7 board (after 100 minutes of computation).

Among other problems I’ve found when implementing the second approach was that in my first solution, pieces didn’t have any state so I could instantiate them all at the beginning of the program and place on the board when appropriate. This had to be changed with introduction of piece coordinates as state. So I’ve introduced a kind of a factory:

object Pieces {
  def rook(x: Int, y: Int):   Piece = Rook(x, y)
  def queen(x: Int, y: Int):  Piece = Queen(x, y)
  def knight(x: Int, y: Int): Piece = Knight(x, y)
  def bishop(x: Int, y: Int): Piece = Bishop(x, y)
  def king(x: Int, y: Int):   Piece = King(x, y)

and instead of passing object instances, I’ve been passing curried functions:

val rookProducer = Pieces.rook _
val rook = rookProducer(3, 1)

Another thing I like a lot about functional programming are higher-order functions. I’ve used them in my solution as well:

def isCaptured(x: Int, y: Int): Boolean = {
  anyItem((p) => p.wouldCapture(x, y, dim), pieces)

def wouldCaptureExisting(newp: Piece): Boolean = {
  anyItem((p) => newp.wouldCapture(p.x, p.y, dim), pieces)

def anyItem(pred: (Piece) => Boolean, pcs: List[Piece]): Boolean = pcs match {
  case Nil => false
  case p :: ps => pred(p) || anyItem(pred, ps)

Short explanation: isCaptured checks whether location (x, y) is taken by any piece on the board while wouldCaptureExisting does it for a new piece that’s not yet on the board.

The key take-away is that Scala code is highly expressive and helps avoid unnecessary code duplication. And thanks to support for tail-call optimization it encourages recursive approach, which often is a good way to deconstruct bigger problems into smaller ones. However, it isn’t always easy to design a recursive algorithm to have that tail call without an additional argument to aggregate results.

Week 2018-W50 in reading

2018-12-16 23:55:00 +0100

This week’s list is rather short as I’m still ill.

  • Some materials about Information Mapping(R):
  • Elliptic Curve Cryptography:
    • A brief introduction by Nick Sullivan. It helped me grasp the key concepts and while I’m far from ready to start implementing anything based on that limited knowledge, I have at least got an idea how it works.
    • Another article on math behind ECC is still on my list. It contains some more math so maybe I’ll get to understand it a bit better? Let’s see.
    • It all started when I’ve read about Ed25519, which I would like to implement one day in Scheme. I’ve already started porting DJB’s python version to Racket a few days ago but decided I first need to understand it better because just rewriting it in another language won’t be useful even a bit.
  • Christopher Lemmer Webber on MediaGoblin and ActivityPub, a not so short interview with a very interesting person who took part in standardizing the protocol that the Fediverse uses.
  • I’ve been reading The Racket Guide, which is very nice and whenever it’s not enough, one has the option of reading the full docs (e.g. Byte Strings).

Whenever I had some spare time, I’ve been reading Christopher Lemmer Webber’s blog.

In the paper books department, I’ve picked a book I’ve suspended a while ago: “How Not to Be Wrong. The Power of Mathematical Thinking” by Jordan Ellenberg.

Week 2018-W48 in reading

2018-12-02 20:00:00 +0100

Although I have’t read it, I’ve started this week with the first episode of Libre Lounge, a podcast by Christopher Lemmer Webber and Serge Wroclawski. I liked it very much and got inspired to refresh my GNU Emacs setup to adjust it to use features I wasn’t aware Org-Mode had. That led me to Org-Mode’s manual’s section on clock table. Then, I’ve read GNU Emacs manual section about text display as I’ve been interested in making octal sequences (used to denote non-alpha-numeric characters) more standing out / highlighted. (Hint: adjusting escape-glyph face did the trick.)

I’ve also read vermaden’s The Power to Serve - FreeBSD Power Management. Vermaden’s texts are always very informative and good to read.

This week I’ve started using FunkWhale instance and learned about Luka Prinčič. It turned out he’s also available on fediverse as

Now back to strictly reading items: I’ve read Design Patterns for Micro-Service Architecture but haven’t found it particularly well-written. I’ve also finished reading AOSA chapter about Bash. It’s interesting how GNU Readline design (also covered in this chapter) is similar to how Emacs does some of the stuff internally (esp. keymaps and the philosophy of redisplay).

From time to time I read stuff about monads and this week it’s been about the Reader Monad.

And the creative part of me, finding a link to Lisp generative art I have saved a long time ago, started wondering if I could play around with extempore, but I had no time to make it compile on FreeBSD (which it doesn’t out of the box), so I’ve given up for now. Unfortunately SuperCollider doesn’t support FreeBSD either and don’t know any other such software so… I’ll have to get back to it later.

Information mapping and structured writing, a topic I’ve found out about when learning about knowledge sharing and representation, got me very interested but I’m still reading a summary of its methods. So far I’ve decided I’d like to write a simple Clojure PDF genenrator to format text according to structured writing guidelines. I’ve already done some first experiments and they look nice, but I’ll need to read more before I continue.

And finally there’ve been two texts about philosophy: Emptying Your Boat, which gives a hint how we can improve our lives by caring less about the self and focusing more on living our lives (at least that’s how I’ve interpreted it); and an excerpt from Enchiridion of Epictetus which opens with a very nice idea:

Of things some are in our power, and others are not. In our power are opinion, movement toward a thing, desire, aversion (turning from a thing); and in a word, whatever are our own acts: not in our power are the body, property, reputation, offices (magisterial power), and in a word, whatever are not our own acts.

This is an incredibly important thing to keep in mind when we are angry because anger usually means we don’t accept something. Thinking about what we can and cannot do about our situation might turn liberating – I’ve tried it myself and it worked like a charm!

Week 2018-W47 in reading

2018-11-24 22:55:00 +0100

I’ve been quite busy this week, so the list is very short. I’ve been mostly reading Dave Snowden’s Christmas blogs (from 2017) about anthro-complexity, as he named the inherent complexity of human populations. Although it doesn’t relate to what I do at work, I find his writing thought-provoking.

A side-note: you might have heard of Dave Snowden as the creator of the Cynefin framework.

For the past few days I’ve been reading bits of “The Architecture of Open-Source Applications” chapter about Bash, but now on my company’s ebook reader as I’ve asked them to order that book. The license is very nice: not only is this book available under CC-BY 3.0 (Unported) – they also donate all royalties to Amnesty International!