Forem: Łukasz Tenerowicz

Inbox Zero with Gmail

Łukasz Tenerowicz — Sun, 24 Jan 2021 18:29:33 +0000

Too many times I’ve heard someone saying “Don’t send me any emails, I won’t read them anyway, my mailbox is a mess”.

That’s just sad. But it doesn’t have to be like this.

Right now, in my Gmail mailbox, there are zero messages. It’s empty. It’s not an anomaly, it’s usually like that because of a method called Inbox Zero.

Ok, so what’s this Inbox Zero?

The whole process is easy – we should think about our email inbox as a task list , where we do a single task, put a tick sign on it to mark it as done, and move to the next one.

Another metaphor could be a computer program in the form of a list of CPU instructions. The most basic activity of a typical CPU is to load an instruction, do an action according to that instruction and move to the next one.

Back to our mailboxes. Our inbox should be a single list of messages. No priorities, no stars, no categories, etc. Just a list of messages, that we haven’t processed yet.

When we check our mailbox, we should:

read the first email on top
do an appropriate action
mark the message as done, thus removing it from our inbox
move to the next email.

We repeat the process until there are no messages left in our inbox.

Marking emails as “done”.

It’s obvious, that if we want to clean up our mailbox, we should somehow reduce the count of our messages.

Back when Inbox by Gmail was a thing (may it rest in peace), we could get rid of a processed email by clicking a tick button – the email would disappear, and we could check the next one.

Under the hood, those emails were simply archived. Therefore, even though there is no tick button in Gmail, we can still use the Archive button and achieve the same results.

Not only will it make a message disappear from our Inbox, which is exactly what we want, but on the other hand, if we ever need that message (or if we simply fear losing it), it’s not deleted, it’s always there under the “All mail” section.

On the mobile Gmail app it’s even easier, you just need to swipe right:

Snooze

Another great feature of Inbox ported to Gmail itself is a snooze functionality. If the email is about doing some action, but we can’t do it right away, we don’t have to hold this email in our inbox. We can schedule the message to reappear in our inbox at a selected time. When we do it, the message disappears, and we can move to the next email.

The mobile app has this feature too, just swipe left:

Reply

Well, emails are about communication after all and even though we mostly read stuff (like notifications, newsletters, etc.), sometimes we receive an actual message we have to reply to.

The funny concept I discovered that may be helpful here is “replying like a CEO“. Basically, it’s an approach where you reply even with just a few words, but right away. I remember that one of our professors at the university had this style of communication. When someone wrote him a long, elegant, respectful email, he simply replied with “OK”. Back then it was ridiculous to me. Now I get it, and given the number of students that he had to reply to, I would probably do the same.

The bottom line is, do whatever helps you to minimize the time you spend processing the message, so you can move to the next one.

Filters

The Inbox Zero technique might seem counterproductive if we receive a lot of emails. This is where filters are a great help.

When we receive far too many messages of a given kind or if they aren’t that important, we can filter them out, by specifying criteria about sender address or message’s content.

On this view, we can specify what should happen with this message. We can simply make it skip the inbox, we can also assign it a label if it is one of those emails we sometimes read, but we don’t want it to distract us.

And here we go – the inbox is clear, but at the same time those filtered messages are easy to find.

But how do I start? I already have a mess in my mailbox …

The solution is simple – select all emails older than a week (or a month) and archive them. If they are this old, you probably won’t need them anymore. However, if you do, they are always there under “All mail”.

What are the profits?

Messages you’ve dealt with already won’t distract you. Not only because they disappear from your inbox, but also because of the “Zeigarnik’s effect”. It was discovered, that we tend to remember unfinished things better. If we mark a message as done, it’s easier for our mind to think of it as a finished thing, and we can focus on other activities.

The other profit is that you won’t miss any emails – because you read and process each of them.

Additionally, if we “unclog” our mailboxes, we could use it as a “low priority communication channel”. We can agree within our team, that we send the important stuff via Slack or other IM platform we use and if we don’t need the answer within the next few hours, we send it via email. The result is that you and your teammates are less distracted. However, the important prerequisite is that you have to agree on that way of communicating within your team.

What do you think?

Have you tried this technique? Maybe in some different flavor? What do you think about it? If you’ve reached that far, you surely can let me know in the comments! 😉

The post Inbox Zero with Gmail appeared first on Konkit's Tech Blog.

My journey through JVM languages

Łukasz Tenerowicz — Sun, 25 Oct 2020 18:06:48 +0000

Java is not just a language. The real reason why it’s still so popular today is the mature and performant platform. And because the programs are compiled to the bytecode, the language's deficiencies could be made up for by ... creating other JVM languages.

To be honest, throughout my career, I’ve used more Groovy, Scala, or Kotlin than pure Java itself!

So how do those languages look like and how do they compare with each other?

Groovy – powerful language and modern syntax

Groovy was the first JVM language I’ve learned. I was using it mostly when I was using the Grails framework at my first job.

Syntax

What made Groovy stand out was its syntax. On the one side, it eased some of Java language pains via optional semicolons, allowing more than one class per file or type inference with the def keyword.

On the other hand, it featured modern language features, such as traits, closures, string interpolation, optional chaining (?. operator) and many other features long before even Java 8 came out.

// Optional chaining:

def gear = car?.getGearBox()?.getGear()

// Instead of

Gear gear = null;
if (car != null) {
  if (car.getGearBox() != null) {
    gear = car.getGearBox().getGear();
  }
}

Moreover, Groovy is a superset of Java. It means, that a Java class is a perfectly valid Groovy class too! This makes its adoption way easier because you can just change the file extension to .groovy and transfer it to a more idiomatic code step by step as you need.

DSLs

Closures, maps and optional dots and parentheses allows us to create Domain Specific Languages, which can look like almost like written in plain English.

The excerpt below is from the official Groovy documentation and in my opinion it explains it quite well.

show = { println it }
square_root = { Math.sqrt(it) }

def please(action) {
  [the: { what ->
    [of: { n -> action(what(n)) }]
  }]
}

// equivalent to: please(show).the(square_root).of(100)
please show the square_root of 100
// ==> 10.0

Those DSLs are used for example in Gradle, Jenkins Pipelines, or Spock, so there is a chance, that you’ve been using Groovy without even realizing it.

Summary

Groovy is a dynamic language, which means, that objects can be modified at runtime via appending methods or intercepting the calls. This is also the reason, why Groovy isn’t my g0-to language anymore. It kind of suffers from the disadvantages of both approaches it tries to merge.

On one side, it still has to be compiled, because it is run on the JVM platform. Because of that, it can’t benefit from fast feedback loops like in other dynamic languages such as Ruby, which are interpreted.

On the other one, because it’s a dynamic language, the compilation step won’t give us that much guarantees about program correctness. Even though we can specify types of our variables and method arguments, we still can run into a runtime error at some point.

Scala – FP and static typing combo

Scala also features some syntax improvements, but way more important is its support for the functional programming paradigm. Immutable objects and lack of side-effects not only make refactoring and testing easier, but it makes Scala well suited for asynchronous programming. Therefore the ecosystem is rich in libraries for that purpose, such as Akka, Monix, Cats, or ZIO.

Types

Scala is statically typed, but it is a way more advanced mechanism than in Java. Types are not just classes. The hierarchy is larger, including types such as Any, AnyVal or Nothing. We can also construct types as functions, with defined arguments and returned values. It’s possible to define type aliases to make our definitions shorter and clearer.

Case Class is another help in using types in Scala. It’s basically a class with immutable fields and all batteries included. Because the fields are immutable, we don’t have to define getters and methods such as equals or hashCode are already there for us. Usually, those classes have just one line of code and they are very convenient to define simple structure types.

case class Circle(x: Double, y: Double, radius: Double)

In Scala, we also make use of monad types. What monads are is a topic for a completely separate blog post, but what’s important is that they help to make our code more meaningful. We can use Option if we want to represent a value that may or may not be defined or we can use Try or Either if we want to represent a successful result of some operation or an error if it failed.

val studentOpt: Option[Student] = students.findById(123)

studentOpt.foreach(student => println(student.name))

The gamechanger here is the fact, that the Scala Standard Library uses those types throughout the library, so we don’t have to worry about null checks or runtime exceptions within the Scala code unless we use them explicitly or integrate with Java libraries using them.

Pattern matching and for comprehension

Scala has two particular features, that help to work with monad types and case classes – pattern matching and for comprehension.

Pattern matching seems like a simple switch statement, but it is much more than that. We can define more advanced conditions, especially check types, and use the filtered values without unsafe casting.

val result: Either[ErrorCode, SuccessValue] = ???

result match {
    case Right(successValue) =>
      handleSuccess(successValue) // no cast needed, successValue is already of SuccessValue type 

    case Left(errorCode) if errorCode.value > 300 => // additional conditions are possible too
      handleLowPriorityError(errorCode)

    case Left(errorCode) =>
      handleHighPriortyCode(errorCode)  
}

For comprehension is the syntactic sugar, which helps us to avoid nested chains of .flatMap or .foreach calls when we work with monad types. It’s the easiest to explain it with an example:

 val employeeNames = for {
  company <- companies
  employee <- company.employees
  if employee.currentlyEmployed
} yield {
  employee.name
}

// is an equivalent of this:

val employeeNames = companies
  .flatMap(company =>
    company.employees
      .withFilter(employee => employee.currentlyEmployed)
      .map(employee => employee.name)
  )

Downsides

The obvious Scala’s downside is a steep learning curve. Due to its complexity, it takes some time to be productive in it and write a proper idiomatic code. In my case, I’ve made the biggest progress during my first code review in a team, which was already using Scala and I think it’s the best way to learn it – from other teammates already proficient in it ;)

Another issue is that it is similar to C in one specific manner – both of those languages are powerful tools, but because of that, it’s very easy to get carried away and write complicated, unreadable code. It’s part of the reason why Scala’s learning curve is so steep.

The last one is harder integration with Java libraries. Not being a Java superset could be annoying, but in fact, IDE support makes it negligible. A more serious problem is that Java libraries do not use Scala monad types and they may use mutable objects. Therefore we can receive a null object when we do not expect it, running into a NullPointerException. This is probably one of the reasons why Scala collections were written from scratch and they even don’t implement the java.util. interfaces.

Kotlin – a “better Java”

Kotlin is the newest of the described languages. Because of that, it had the opportunity to take what’s best from other languages and fix those aspects which were less ok.

Nullable types and Java integration

Kotlin’s approach to tackle the NullPointerException problem is to introduce nullable types. When a type is declared with a ? sign at the end (e.g. String?), it means that it can be null. The best part is that it’s the compiler that checks if we try to use such an object without checking if it wasn’t null and returns the error if we did.

val nullableString: String? = null // OK
val notNullableString: String = null // compilation error!

All values coming from Java code are nullable by default, which makes this mechanism work even when we integrate our Kotlin code with some Java library.

Just like in Scala, we can work with immutable values and collections, but without committing that much to the functional programming paradigm:

Data classes can have mutable fields, where Scala’s case classes can not.
There are no monad types in the standard library. We can use libraries, like arrow-kt, but we have to wrap the values ourselves.
No pattern matching, no for comprehension, less complicated (but thus – less expressive) type system.

Those functionalities make Kotlin a perfect candidate for being a “better Java”. We can see results today, where Android and Spring already have Kotlin integration.

Domain Specific Languages

Similarly to Groovy, Kotlin has closures, which lets us build DSL in Kotlin too. The advantage is that in Kotlin such DSLs are typed. Gradle has Kotlin DSL and my IDE can finally check my code for errors and give me some hints about available properties.

Coroutines

Closures are also used in another distinct Kotlin feature – Coroutines. In essence, they are simply lightweight threads, which can handle asynchronous operations while preserving the readability.

The below example comes from Kotlin documentation. If we tried to run 100k of thread at once, we would cause an OutOfMemoryException.

import kotlinx.coroutines.*

fun main() = runBlocking {
    repeat(100_000) { // launch a lot of coroutines
        launch {
            delay(5000L)
            print(".")
        }
    }
}

Within the coroutine context, the code can be organized with suspend functions , which are functions that are run within the coroutine and its execution can be paused and resumed later, e.g. when the data from the HTTP request arrives.

import kotlinx.coroutines.delay
import kotlinx.coroutines.runBlocking

fun doSomeWork() = runBlocking {
    val result = makeHttpCall()
    println(result)
}

// Simulate making the call and return the result
suspend fun makeHttpCall(): String {
    // The delay here is also a suspend function, which does block the thread.
    // The execution of the makeHttpCall function is paused until
    // the time of delay passes and then it's resumed
    delay(1000)
    return "Some result"
}

Coroutines are pretty heavily used in the web framework called Ktor.

Downsides

Regarding downsides, I think that the biggest one is Kotlin’s young age. I could especially experience it with Kotlin Gradle DSL, where on one hand it’s great that finally the DSL is typed, but on the other hand, it was still easier to copy and paste some Groovy code from the internet than to figure out how to translate it. However, I’m sure, that this situation will be better and better over time.

Other languages

There are of course other JVM languages, but I won’t describe them in such detail, because I haven’t really used them that much.

The most popular language of this group is Clojure. Just like Scala, it’s a functional language with a steep learning curve. Unlike it, however, it’s a dynamic language and it’s a Lisp implementation. This makes it a very powerful language because the code is also the program’s data and it can be modified. However, in my subjective opinion, this also makes Clojure programs very unreadable. However, a lot of people that influenced me in some way are Clojure users, so maybe I am wrong, therefore I’m not ruling out using it in the future :D

There are JRuby and Jython, which are basically Ruby and Python implementations on JVM. While using Java libraries in those languages is still possible, they are usually used just as a more performant Ruby or Python interpreter.

Finally, there is … Java :D I can’t neglect the progress, that Java has made throughout versions 9 to 15 and onwards. New features like type inference with var, pattern matching, or records definitely sound like a breath of fresh air and a step in the right direction. Unfortunately, I don’t have much experience with that either.

Summary

Currently, I’m using Scala at work and Kotlin for my hobby projects.

Which language would I recommend using?

I’d choose Scala for data-oriented, asynchronous-heavy applications. That part is pretty well worked out in Scala. There are many libraries for that and functional programming paradigm makes writing such code easier.

I’d choose Kotlin, for simple applications or the ones which have to be heavily integrated with Java libraries. This is becoming more and more convenient because many Java libraries already started to integrate with Kotlin too.

Groovy handed to Apache is in my opinion a sign of declining popularity and purpose of this language. However, if you use Java for your production code, I think that Spock alone is a good enough reason to check Groovy out.

The post My journey through JVM languages appeared first on Konkit's Tech Blog.

What have I learned from speaking at 4Developers 2020 conference?

Łukasz Tenerowicz — Thu, 01 Oct 2020 17:01:18 +0000

At this year’s edition of the 4Developers conference I gave a talk titled “Productivity for Ordinary Developers”. It wasn’t the first time I was speaking at an event, however, there were some new experiences for me anyway. Here are some insights I hope you’ll find interesting.

Lightning talks are hard

It was the first lightning talk I created and I have to admit – they are hard. Earlier, I was thinking, that if the talk is 3 times shorter, it should be 3 times easier to prepare. The truth is, 15 minutes (or in this case even 12) leave a very little margin. I had to rehearse even harder to make sure, that I’m within the time limit.

Recording myself training my talk at home was a great help for my preparations. It allowed me to check how the final result would look like. I could watch myself talking, and I could find mistakes or annoyances, which I wasn’t even aware of.

It also put an element of pressure on me. If I wanted to record a complete try, I couldn’t make any mistakes. Because of that element of mild stress, I could measure the time of my talk more accurately. It also helped me to prepare a schedule for my talk. I played the recording once and noted minute ranges of all major sections of my talk. Thanks to that, I had a cheat sheet, which I could quickly check during the actual talk to instantly know how am I doing with my time. Was I rushing, dragging? Did I have extra time or should I hurry up a bit?

My cheat sheet :D

However, it’s extremely important to remember to turn the timer on. Without that, as I unfortunately learned, the cheat sheet is of no use … ! :D

Online conferences are … different

This year’s edition was unique because due to the COVID19 pandemic it was a completely online version.

In terms of technicalities, I think that the 4Developers crew has made a tremendous job. Everything was very well organized, we had rehearsals, where we could learn beforehand how it would look like during the conference. It felt like an appearance in a live TV show :D.

However, it’s still not the same as the usual on-site event.

I missed the live audience. Even though the stage fright was a little bit less significant, I really missed that triumph moment between saying “thank you” and the applause from the audience.

I also missed the networking. A friend of mine once said that he measures how he liked the conference by a number of new connections he has made. This year, there weren’t many occasions to talk to each other.

I have also watched way fewer talks then I would usually do at an on-site conference. If you are at the venue, where the conference is organized, you usually have a free day at work and there is nothing to distract you from attending the talk and focusing on it. On the other hand, if they are in a form of a broadcast you can watch now or later – there is always something more important to do at home or at work.

Luckily, the next edition is scheduled on-site :D.

Summing up – full success!

I am extremely happy, that in terms of speaking it wasn’t a wasted year for me and I am really grateful for the opportunity to speak at a country-wide conference.

If you want to see the slides or the “further reading” links, you can find them here.

Why should you use Ruby for your next command-line tool?

Łukasz Tenerowicz — Thu, 18 Jun 2020 21:34:42 +0000

One day, I needed to write a command-line tool. It was more complicated than copying a couple of shell commands to a file with .sh extension, but at the same time it was too simple to make a full Java or Scala application out of it.

Even though I work mostly with Scala and Typescript, I’ve chosen to do it in Ruby because it’s good for that very purpose – to quickly get your stuff done.

Here is why:

TDD is first-class citizen

Ruby is a dynamic language. That means, that the type of the object is not checked before executing an operation. Objects can be modified at runtime, methods can be added dynamically, etc.

This sounds like hell for those coming from languages like Java or Scala, but it’s very helpful if you want to do a TDD approach.

Because there isn’t any compiler to do some checks, proper testing is very important in Ruby. Because of that, there are a lot of tools, which help with that. RSpec lets us write tests with a surprisingly small amount of lines. Nesting lets us reuse the setup between cases, keeping our tests testing only one thing at a time. This makes not only writing, but also reading tests easier.

  context('when the rectangle has size 2 x 3') do
    subject { Rectangle.new(2, 3) }

    it 'should return correct area' do
      expect(subject.area).to eq(6)
    end

    it 'should return a correct circumference' do
      expect(subject.circumference).to eq(10)
    end
  end

There are lots of other libraries, which we can use alongside RSpec. One example, which I’ve never seen anywhere else is the vcr gem. It can be used to record calls to external APIs during tests execution and use cached data on the following runs instead of making the same calls over and over again. The funny thing is, that such things wouldn’t be possible (at least not that easily) if Ruby wasn’t a dynamic language.

Tools and community support

Because of Rails popularity, there are Gems (Ruby libraries) for almost everything. Using the work someone once done instead of reinventing the wheel can greatly speed up the development. Also, most of the problems you may face are probably already solved and explained in a Stack Overflow question.

Object-oriented and High-level API

Ruby’s APIs are simple and with a quite high level of abstraction. For making a command-line tool this is great because we can focus on getting the job done, abstracting the details away.

require 'csv'

lines = CSV.readlines("filename.csv")

Operations on collections are also syntactically nicer and more familiar to those I know from Scala or Kotlin. I realize, that it’s just a matter of taste, but for me, the intention is clearer this way.

> [1, 2, 3, 4, 5, 6, 7].select { |number| number > 3 }

 => [4, 5, 6, 7]

> ["lorem", "ipsum", "dolor"].each_with_index do |word, index|
> puts "#{index+1}. #{word}"
> end

1. lorem
2. ipsum
3. dolor

 => ["lorem", "ipsum", "dolor"]

Interpreted language

I’ve mentioned, that Ruby is not a compiled language, thus there is no compiler to check for syntax errors. But what you get in return is instant feedback. You don’t have to wait for your application to compile to see the results.

This may not sound that convincing – after all, we are developing a simple tool, so the compilation times shouldn’t be that long after all. But on the other hand, you could gain on the faster feedback loop. If your tests run almost instantly, running them automatically each time you change your code suddenly doesn’t sound that insane (check out the guard gem).

Summary

Don’t get me wrong – I don’t want to say, that you should out of the sudden use Ruby for everything. In my current job, we use Scala and I find it an excellent choice for a product developed by a larger team. However for that specific scenario – a simple command-line tool – it might be worth to at least consider Ruby.

I realize that I may be biased because I’ve been working with the Rails framework in the past. If you are used to other languages such as Python or Go, it may be a good idea to choose them and be productive with tools you already know. However, once in a while, it’s good to expand your horizons and discover what our options do you have.

The post Why should you use Ruby for your next command-line tool? appeared first on Konkit's Tech Blog.

Obvious and not-so-obvious Bash/Zsh terminal shortcuts

Łukasz Tenerowicz — Thu, 21 May 2020 06:43:15 +0000

For a very long time, I’ve been using just tab, ctrl-C, ctrl-D and ctrl-R shortcuts. However, there are more useful gems out there. In this post, I’m going to show you Bash/Zsh terminal shortcuts that I find useful.

Tab

It’s the most important shortcut because it’s the autocompletion. It simply saves you a whole lot of typing. If there is just one possible option, then it will be automatically filled for you. If not, possible options will be presented below.

Ctrl-C and Ctrl-D – oversimplified explanation

Ctrl-C terminates the currently running command or a process. Ctrl-D is an equivalent of exit command. You can think about the Python REPL, where Ctrl-C ends the currently running command, but Ctrl-D exits the REPL itself.

Ctrl-C and Ctrl-D – a longer explanation

Ctrl-C sends a SIGINT signal, to a process, which is currently in the foreground. Application usually interpret this as a signal to kill the process, but they don’t have to do so. This is why Python interpreter doesn’t end the process, but just ends the command that is currently running.

Ctrl-D sends an End-Of-File marker. To explain this, imagine that we run a Python script. The interpreter reads the program from a file and executes commands until the whole file is read. When it reaches the end of the file, the interpreter terminates.

When we run the interpreter without any script, our keyboard input is treated as a “file”, from which the commands are read. When we push Ctrl-D, we inform the interpreter, that it reached the end of the file, all commands are read and thus it can terminate.

Of course it doesn’t have to be a Python interpreter – the same goes for other interpreted languages or shells like bash. Try to run bash inside a bash – you can “go back” with Ctrl-D shortcut.

Ctrl-Z and fg command

When you have some long-running command, you don’t necessarily have to terminate it if you have to do something else. When you press Ctrl-Z, the current process goes to the background. You no longer see its output, but the process is still running.

If we want to bring back that process to the foreground, we can use the fg command to do that.

Ctrl-S and Ctrl-Q

We may also pause the output for a moment. This is useful, when there is a lot of fast-changing output, like application logs we would like to inspect. To pause the output we can use the shortcut Ctrl-S (like s top). To resume it back, use the Ctrl-Q.

Up and Down Arrows or Ctrl-P and Ctrl-N

To run a previous command, we just need to press the up arrow. With up and down arrows we can navigate between already executed commands.

The same effect can be achieved using Ctrl-P (like in p revious command) and Ctrl-N (like in n ext command). At first, arrow keys may be more intuitive, but as you become more proficient with keyboard, it may be more efficient to use the latter ones, because you can keep your hands on the letter keys.

Ctrl-R

Arrow keys are not convenient to use if the command was executed some time ago. To search in history for a command, we can use a Ctrl-R shortcut.

To display whole saved history, we can also use a history command.

Ctrl-A i Ctrl-E

Ctrl-A is basically an equivalent of the Home button. It moves the caret to the beginning of the line.

Ctrl-E is like the End button. It moves the caret to the end of a line.

Ctrl-L

To clear the screen and go back on top of our terminal screen, we can use the clear command, but we can also do it faster, using the Ctrl-L shortcut. You know – c L ear (not very intuitive, but it’s something …)

Ctrl-W

If we make a mistake in a last written word, we can use this shortcut to quickly delete the last word.

Ctrl-U

When we would like to remove a whole line, we can use Ctrl-U shortcut (like in u ndo) to clear the whole line.

Ctrl-K

Ctrl-K shortcut deletes characters from the cursor to the end of the line.

Ctrl-Y

Now, if we remove a command or its part by either of Ctrl-K, Ctrl-U or Ctrl-W shortcuts, we can paste it via Ctrl-Y shortcut (like in y ank). It’s very useful when you write a very long command, but then you realize, that you have to run another one first.

That’s it

Did I miss any shortcut that should be on that list? Let me know in the comment!

The post Obvious and not-so-obvious Bash/Zsh terminal shortcuts appeared first on Konkit's Tech Blog.

Hi, I'm Łukasz Tenerowicz

Łukasz Tenerowicz — Tue, 09 May 2017 14:00:05 +0000