A8c team meetup Athens, 2019

During the first week of October, we had our team meetup in Athens, Greece.

We had a lot of projects going on, and one of them (which I was involved in) was working on the architecture of WooCommerce Services. It has wp-calypso as a dependency, and we wanted to move out of that and just rely on @wordpress/components. We have a PoC PR and wrote an internal P2 post about it.

Fun stuff, right? Now for the actual fun stuff. We did a lot of escape rooms. And I mean a lot.

Continue reading “A8c team meetup Athens, 2019”

Metapost: Tuply singleton – Freedom of creativity

I like puzzles. If it’s a non-trivial one, in order to come up with a solution I usually spend a few days (on and off) thinking about it. But it also has to be interesting to get my attention.

As an example, consider one of my earlier blog posts series: Tuply singleton, Tuply singleton v2, Tuply singleton v3. This is what I do in general, and blog posts are usually just the result of my thinking. Blogging (or pen & paper) is one of the best tools we have as humans – given the reliability of our memory.

But then another thought came. What if someone had asked me that same question on a job interview? Most job interviews usually have a time constraint, so there’s a high chance I would come up with the first (erroneous) version.

To me, this is freedom of creativity – to keep thinking about something that seems interesting and come up with a solution, without being pressured or constrained by time.

Customer-driven engineering

We’re in the process of renovating our house with my wife.

We have a bunch of “engineers” working on it: electricians, plumbers, wall painters. These guys have direct contact with the customers. What they are working on will be immediately visible to the customer. They must be thinking about the customer all the time, and satisfy their needs. There is no management, customer support, release dates in between (I’m sure there is for larger objects). What they are doing is visible at the spot and they must make sure it looks right, otherwise the customer will be mad.

This sounds very similar to what freelancing software engineers are doing. On the other hand, software engineers that work at big companies have huge layers before they reach the customers. As a consequence, most of them even rarely think about their customers at all.

Lately I’ve been thinking about our customers more and more. What we are building as software engineers are decisions that were discussed with other smart people at meetings, etc. But I think there is still value in constantly asking yourself: “what will the customer think about this?”, “what will their reaction be on what I’m building right now”, etc.

Do you ever think about your customers, or only your code like most of us? 🙂

Igpay Igpay Atinlay

The other day I watched an interesting episode of Teen Titans Go with my kids. What caught our attention is the song that was part of the episode. You can listen to it here.

Despite the song being fun for my kids to listen to, my daughter asked me if those words made any sense at all. Do they? 🙂

At first I thought it was a simple rotation system. For example, “test” would turn to “estt”, and “scheme” would turn to “chemes”. This is what I told my daughter without any further analysis and we had fun playing with the words.

But then after a while we heard the song again and it seems our system isn’t what was used. Next thinking was, they would rotate the words, and append “ay” at the end of them. So I found the transcript and I noted this works, but you need to keep rotating until you reach a vowel. That’s it! I quickly sat and wrote an encoder in Scheme:

(define (word-to-piglatin str)
  (letrec [(vowels '(#\a #\e #\i #\o #\u))
           (l (string->list str))]
    (cond ((> (length (set-intersect vowels l)) 0)
           (if (member (car l) vowels)
               (list->string (append l '(#\a #\y)))
               (word-to-piglatin (list->string (append (cdr l) (list (car l)))))))
          (else (error "no vowels")))))

Now, just run it:

> (let ([song "pig pig latin is the dopest its real simple i will explain pig pig latin is the dopest say ay always at ends of words pig pig latin is the dopest"])
    (string-join (map word-to-piglatin (string-split song " ")) " "))
"igpay igpay atinlay isay ethay opestday itsay ealray implesay iay illway explainay igpay igpay atinlay isay ethay opestday aysay ayay alwaysay atay endsay ofay ordsway igpay igpay atinlay isay ethay opestday"

Ahh, close, but not really. If you look at the song lyrics, some words do not match. Specifically “isway” vs “isay”. So I thought maybe for some ending letters we append “ay” and for others we append “way”.

Constructing a table was the next step:

Ends in letter | Append
       a       | way
       b       | ay
       c       | ay
       d       | ay|way
       e       | way
       f       | ay|way
       g       |
       h       | ay|way
       i       | way
       j       |
       k       | way
       l       | ay|way
       m       | ay|way
       n       | ay|way
       o       |
       p       | ay|way
       q       |
       r       | ay
       s       | ay|way
       t       | ay|way
       u       |
       v       | ay
       w       | ay
       x       |
       y       | ay|way
       z       |

Nope, for some words it’s “ay”, for some it’s “way”, and for some it’s both. Also, for “on” it’s sometimes “onway” and sometimes “onay”. So it’s pretty random, but was still fun to look into! 🙂

EDIT: Thanks to my coworker Bartosz Budzanowski who told me that Pig Latin is really a thing! The rules are clearly stated on its Wikipedia page. Still, reverse engineering it was fun 🙂

Code updated:

(define (word-to-piglatin str [init #t])
  (letrec [(vowels '(#\a #\e #\i #\o #\u))
           (l (string->list str))]
    (cond ((> (length (set-intersect vowels l)) 0)
           (if (member (car l) vowels)
               (list->string (append l (if init '(#\w #\a #\y) '(#\a #\y))))
               (word-to-piglatin (list->string (append (cdr l) (list (car l)))) #f)))
          (else (error "no vowels")))))

Bonus: Haskell code

WordToPiglatin :: String -> String
WordToPiglatin "" = ""
WordToPiglatin s
    | isVowel (head s) = s ++ "way"
    | any isVowel s    = rotateUntil (isVowel . head) s ++ "ay"
    | otherwise        = s
    where
    isVowel c = c `elem` "aeiouAEIOU"
    rotateUntil _ [] = []
    rotateUntil p s = let res = rotate s in if p res then res else rotateUntil p res
    rotate (x:xs) = xs ++ [x]

Self-publishing my first book

It all started in 2013, when one of my former coworkers told me about this weird mathematical programming language called Haskell. I already had an interest in mathematics, so it didn’t take long before I started looking into it. I visited the awesome community on Freenode and was suggested to read Learn You a Haskell for Great Good.

I was amazed by both the book and the language. I started to blog about the things I learned. Algebraic data types eventually turned out to be my bachelor thesis in 2015. As the number of blog posts kept increasing, I thought of writing a book on dependent types. I collected all the blog posts, edited them, put them in a logical order and asked some friends to review the chapters. Finally, in September 2018 I self-published my first book, Gentle Introduction to Dependent Types with Idris.

My book has exceeded the sales expectations I had. I didn’t do any paid marketing at all. The only marketing was maybe doing a few posts on social media. It was a great experience for me, my writing skills improved, and I learned a lot about books, reading, and writing, receiving feedback.

Here’s a summary of what I’ve learned during the process:

  1. Receive feedback as early as possible – what makes sense to you does not necessarily make sense to all readers. I found reviewers by pinging some friends and googling for bloggers interested in the same topic. Reviewers’ feedback is very valuable. It is important to keep low ego and revise parts that really suck, but it needs to work both ways – reviewers must be providing constructive criticism
  2. Writing a book is harder than blogging (it requires logical flow, every paragraph needs to have context similar to previous, etc). Putting thoughts randomly on a blog is OK but a book has to have a kind of structure. Writing, in general, is hard and requires a lot of patience
  3. I didn’t know everything when I started writing the book – only some parts. I found it’s interesting and fun to learn as you go – you eventually become an “expert” in the field
  4. Grammar – keep simple statements, active voice, paragraphs, etc
  5. Continuously read and revise

For the writing process, I started copying and pasting my blog contents to a Google Drive document and shared it with the reviewers. After a while, I found out about Leanpub, and moved all of the content to a GitHub repository using Leanpub’s extended Markdown which also supports LaTeX. Reviewers would then either create GitHub issues or pull requests. Leanpub allows you to export your book as a pdf/mobi/epub format. It also allows exporting of a so-called “print book” format, so I could build my book with a few clicks and upload it to Amazon’s Kindle Direct Publishing service. I also used Grammarly and aspell.

It was interesting to me how writing a book in today’s age is very simple with all the tools that are available to us.

I’m thankful to my family, the reviewers, my former and current coworkers, and everybody else directly or indirectly involved.