Skip to main content


See how Google is tracking your location. With Python, Jupyter, Pandas, Geopandas and Matplotlib

In sales, you can hear the acronym ABC: Always Be Closing . Closing means making a deal with a customer. Last decade gave rise to another acronym ABCD: Always Be Collecting Data . We use Google for mail, maps, photos, storage, videos, and much more. We use Twitter to read a stream of consciousness of one President. We use Facebook for messaging and… well, pretty much it. Our parents use it though. We use TikTok… I have no idea what for. Actually, turns out most of the above are useless… Nevermind, the bottom line is: we use them. We use them, and they are free. In XXI-century economy, if you are not paying for the product, you are the product. So, long story short, I wanted to investigate how much Alphabet corporation , the owner of Google, knows about me. Just a tiny fraction, I looked at geolocation history. I never turned off location services because I was valuing comfort over privacy. Bad idea. Download your data In order to download all data Google collected about you, go to

GraphQL server in Java: Part III: Improving concurrency

The idea behind GraphQL is to reduce the number of network round-trips by batching multiple, often unrelated requests, into a single network call. This greatly reduces latency by delivering many pieces of information at once. It’s especially useful when multiple sequential network round-trips can be replaced with a single one. Well, honestly, every web browser does that automatically for us. For example, when we open a website with several images, the browser will send HTTP requests for each image concurrently. Or, to be precise, it will start not more than a certain number of connections to the same host. It’s something between 2 and 8, depending on the browser. The same applies to multiple AJAX/RESTful calls (see fetch() API ), which are concurrent by default with no extra work on a developer’s side. Actually, that’s what A stands for in AJAX 1 . So, what’s the advantage of GraphQL? If a web browser can make concurrent requests to multiple pieces of data at once already, why bot

GraphQL server in Java: Part II: Understanding Resolvers

In part I we developed a really simple GraphQL server. That solution has a serious flaw: all fields are loaded eagerly on the backend, even if they weren’t requested by the front-end. We sort of accept this situation with RESTful services by not giving clients any choice. RESTful API always returns everything, which implies always loading everything. If, on the other hand, you split RESTful API into multiple smaller resources, you risk N+1 problem and multiple network round trips. GraphQL was specifically designed to address these issues: fetch only required data to avoid extra network traffic as well as unnecessary work on the backend allow fetching as much data as needed by the client in a single request to reduce overall latency RESTful APIs make arbitrary decision how much data to return, therefore can hardly ever fix the aforementioned issues. It’s either over- or under-fetching. OK, that’s theory, but our implementation of GraphQL server doesn’t work this way. It still f

GraphQL server in Java: Part I: Basics

Near Zegrzyńskie Lake Superficially, there is no reason GraphQL servers are typically written in Node.js. However callbacked-based languages that don’t block waiting for the result turn out to play really well with GraphQL philosophy. Before we dive into details why that’s the case, let us first understand how GraphQL server works underneath and how to implement it correctly. In the second installment we shall split the implementation to lazily load only necessary pieces of information. In the third installment we shall rewrite the server using non-blocking idioms to improve latency and throughput. What is GraphQL First things first, what is GraphQL? I’d say it lies somewhere between REST and SOAP (sic!) It’s a fairly lightweight, JSON protocol that works best for browsers and mobile apps. Just like REST. On the other hand it has a schema, describing valid attributes, operations and payloads. However, unlike SOAP, schema is designed to evolve and we have a great control over th

Fallbacks Are Overrated - Architecting For Resilience

Abstract Fallbacks in circuit breakers replace failure with some pre-configured response so that the scope of the malfunction is limited and hidden from the end user. However, in real life, a naïve fallback is often too simple and either confusing or unacceptable. I suggest a more robust approach to handling failures, compensating for broken transactions in the future. Reading time: 8 minutes. What is a circuit breaker? A circuit breaker is a layer between your code and external dependencies that have a high risk of failure. Every time you call another service, database, or even touch your own disk, there is a possibility of failure. Without circuit breakers such a simple error quickly escalates, bubbling up to your end user. All too often minor dependency brings down a huge system, resulting in 503 HTTP responses or slowness. Circuit breaker discovers raised error levels or elevated response times quickly. Rather than slowing the whole system, it cuts off entire dependency

Map.merge() - One method to rule them all

Suwalszczyzna Russian translation available:  Map.merge () - метод, чтобы управлять всеми остальными I don’t often explain a single method in JDK, but when I do, it’s about Map.merge() . Probably the most versatile operation in the key-value universe. And also rather obscure and rarely used. merge() can be explained as follows: it either puts new value under the given key (if absent) or updates existing key with a given value ( UPSERT ). Let’s start with the most basic example: counting unique word occurrences. Pre-Java 8 (read: pre-2014!) code was quite messy and the essence was lost in implementation details: var map = new HashMap<String, Integer>(); words.forEach(word -> { var prev = map.get(word); if (prev == null) { map.put(word, 1); } else { map.put(word, prev + 1); } }); However, it works and for given input produces desired output: var words = List.of("Foo", "Bar", "Foo", "Buzz", "

Designing Data-Intensive Applications: my favourite book of last year

Warsaw Old Town Martin Kleppmann, the author of Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems wrote a wonderful, comprehensive book. I consider this to be my most valuable reading of 2018, even though the book is almost 2 years old now. Martin proves that great bestsellers in the programming industry aren’t about shiny new frameworks and buzzwords. Data-Intensive Applications is a solid piece about the fundamentals of computer systems, especially from the data manipulation perspective. This book introduces and explains all topics related to data storage, retrieval and transmission. That doesn’t sound very exciting, does it? However, expect very thorough (600+ pages!) and enjoyable journey through databases, protocols, algorithms and distributed systems. In the first chapter : “ Reliable, Scalable, and Maintainable Applications ” the author describes the environment in which our systems live nowadays. What are the poss

RxJava vs Reactor

Summary: Stick to whichever library you already have on your CLASSPATH. If you get a choice, Reactor is preferable, RxJava 2.x is still a good alternative In case you’re on Android, then RxJava 2.x is your only choice Table of contents: API Type-safety Checked exceptions Testing Debugging Spring support Android development Maturity Summary Many people ask me, which library to use in their new projects (if any). Some are concerned that they learned RxJava 1.x and then 2.x came along, and the Reactor. Which one should they use? And some also wonder, what’s with this new java.util.concurrent.Flow ? Let me clarify a few things. First of all, both versions of RxJava and Reactor are quite similar from a functional perspective. If you know 1.x or 2.x, Reactor will be very familiar, though you still have to learn about the differences. Secondly, Flow class (a set of interfaces, to be precise) is part of a reactive streams specification, bundled into JDK. This spe

Brute-forcing a seemingly simple number puzzle

From StackOverflow Something was bothering me for almost two decades. It was a pen and paper game that I learned when I was around 13. The rules are simple: on an empty 10x10 grid (100 squares in total) you put a number 1 on an arbitrary square. Starting from that square you can move horizontally or vertically jumping over two squares or diagonally jumping over one square. There you can place number 2 . Your task is to reach number 100 , filling all squares. You can not visit already visited squares. Here is an example of a solved game with a reduced 5x5 grid, starting at top-left corner: 1 24 14 2 25 16 21 5 8 20 13 10 18 23 11 4 7 15 3 6 17 22 12 9 19 On the other hand, if the program makes bad choices, we might get stuck without reaching the perfect score of 25 (on a reduced 5x5 grid): 1 8 2 9 16 13 5 17 14 10 4 7 15 3 6 19 12 18 11 Notice how we got stuck at number 19, unable to move anywhere and f