Issue #8: 10 Reads, A Handcrafted Weekly Newsletter for Humans

Hey y’all,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 125 minutes.
Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth. — Marcus Aurelius
  1. Introvert or Extrovert? Here’s How to Boost Your Productivity: 10 mins read. I consider myself an introvert and I have no issues accepting that. I agree with post’s author that few people are pure introverts or extroverts. It could depend on the situation or people we hang out with. For me the best part of the post was productivity tips for introverts. Interesting I also came with the same conclusions as shared in this post for boosting my productivity. The four productivity tips for introverts — 1) Control your environment 2) Focus on one-on-one interactions 3) Slow down 4) Prepare for meetings.
  2. Survivorship Bias And Startup Hype: 5 mins read. Luck plays a significant role in business success. Not just in the mere fact of success, but in the magnitude of any given company’s triumphs. We tend to overlook this reality because of a mental distortion called survivorship bias. It is a common cognitive failure, and a dangerous one because it obscures the distastefully harsh nature of the world.
  3. Don’t Eat Before Reading This: 20 mins read.  Anthony Bourdain shares some trade secrets of chef industry. He writes Being a chef is a lot like being an air-traffic controller: you are constantly dealing with the threat of disaster. You’ve got to be Mom and Dad, drill sergeant, detective, psychiatrist, and priest to a crew of opportunistic, mercenary hooligans, whom you must protect from the nefarious and often foolish strategies of owners. Year after year, cooks contend with bouncing paychecks, irate purveyors, desperate owners looking for the masterstroke that will cure their restaurant’s ills: Live Cabaret! Free Shrimp! New Orleans Brunch!
  4. The Bullshit-Job Boom: 15 mins read. We all have seen people bullshitting around and reaching the top and then building a senior team with all bullshitters together. This happens in most organization. I love the definition of bullshit job. Author writes a form of paid employment that is so completely pointless, unnecessary, or pernicious that even the employee cannot justify its existence even though, as part of the conditions of employment, the employee feels obliged to pretend that this is not the case.
  5. Becoming a dramatically better programmer : 15 mins read. It is always beneficial for me to read posts like these. They either teach me a new way to look at how I can become better programmer or they assure me if I am doing something right. I also realized most of the suggestions mentioned in the post and trying to follow them. The post is divided into two parts — 1) Learning skills directly 2) Learning meta-skills. The first part Learning skills directly talks about importance of building new skills that complement your existing skillset and learning things that you think you don’t completely understand. The second part learning meta-skills is about deliberate practice, identifying common mistakes, and deep work.
  6. Pain Plus Reflection Equals Progress : 10 mins read. Author writes, The easy path means being the same person you were yesterday. It’s easy and comfortable to convince yourself that the world should work differently than it does, that you have nothing to learn from the pain. The harder path is to embrace the pain and ask yourself what you could have done differently or better or what your blind spot was. It’s harder because you stop living in the bubble of your own creation and start living in reality.
  7. Seven Reasons Why RightSizing AWS EBS Capacity Is Hard : 10 mins read. Right-sizing EBS volumes can provide a handsome return on investment. The reason is simple: AWS charges for provisioned capacity, not consumed capacity, and almost all AWS customers over-provision their EBS volumes. In our experience, the average amount of unused storage is about 75%. That’s a lot of empty storage that AWS customers are paying for!
  8. CPU utilisation is wrong : 5 mins video. This is a 5 mins video by Netflix’s Brendan Gregg on why %CPU is not the right way to measure performance.
  9. Go code refactoring : the 23x performance hunt: 15 mins read. These days I am also working on a piece of code where I am trying to do performance optimisation. This blog give me some ideas to explore. A good post at the right time for me.
  10. Building A Pub/Sub Service In-House Using Node.js And Redis: 20 mins read. The primary reasons for building an in-house Pub/Sub system are 1) Reliability 2) High Performance 3) Cost effectiveness.
Advertisements

TIL #9: PostgreSQL SQL query to find column count for all the tables in a PostreSQL schema

Today, I wanted to find column count for all the tables in a PostreSQL schema. The following query could be used.

select table_name, count(*) as column_count 
from information_schema."columns" 
where table_schema = 'public'  
GROUP by table_name order by column_count desc;

TIL #8: Installing and Managing PostgreSQL with Brew

This post documents how to install and manage PostgreSQL using brew package manager for macOS.

To install PostgreSQL using brew, run the following command.

$ brew install postgresql

If you wish to start and stop PostgreSQL, then you do that using following brew commands.

$ brew services stop postgresql
$ brew services start postgresql

To get information about your PostgreSQL installation, you can run following brew command.

brew info postgresql

There are time you might forget if you installed PostgreSQL using brew. You can check if PostgreSQL was installed by brew by running following command.

brew list |grep postgres

The brew package manager installs PostgreSQL under following location.

/usr/local/Cellar/postgresql/

The configuration files as inside following directory.

/usr/local/var/postgres

Issue #7: 10 Reads, A Handcrafted Weekly Newsletter for Humans

Hey y’all,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 135 minutes.
  1. 10 Practices to be a better Scrum Master : 10 mins: This is a good read for any Agile team. For me the best practice among the list is Don’t Beat the Team over the Head with an Agile Rule Book. This is what most Agile coaches or Scrum master get wrong. They try to force rules that they themselves have never followed. Other thing that I have observed is that many of the Agile coaches have either never done software development or if they did it was 5 or 10 years in the past. I think they can be more helpful if they have real Agile software development experience.
  2. Your IDE as presentation tool: 10 mins. I do that is most of my talks as well. It is difficult to get it right but if you are confident and prepared well your talk can be more informational to the audience.
  3. Remote Only: 15 mins: I worked remotely for couple of years when I was working with Red Hat. I enjoyed the experience most of the time but there was times when you feel lonely or wanting to work with people. I plan to do remote work again in future as I think it is more productive than working in open space offices. This post shares practical tips, advantages, and disadvantages of working remotely. The best point for me is Writing down and recording over verbal explanations. In the book Rework by Basecamp guys, they talked about if they had to hire between two equally competent people they would prefer to hire a person who is a better writer.
  4. The Day You Became a Better Writer (2015): 5 mins. This is small useful post giving advice on how to write effectively. The key point for me is Simple writing is persuasive.
  5. Replacing jQuery with Vue.js: No Build Step Necessary: 15 mins: The post uses simple examples to demonstrate how we can replace jQuery with Vue.js. Vue.js looks simple to use and you can introduce it to your project incrementally.
  6. Fear of Better Options (FOBO) is The Reason You Can’t Make a Tough Decision : 15 mins. The post talks about why having more choices and optimising for the best option leads to frustration, stress, regret, and unhappiness. The reality of the matter we will never have complete information so we will never be in position to make the best bet. The author suggests instead we should look at option and the first that meets our criteria should be chosen. This decision making paradox happens to us in all walks of your life. This is relevant when you are trying to make decision about partner you want to settle or what next thing you should learn. I usually get overwhelmed when I have to decide what should I learn next.
  7. The Scientific Argument for Mastering One Thing at a Time: 5 mins. The counterintuitive insight from all of this research is that the best way to change your entire life is by not changing your entire life. Instead, it is best to focus on one specific habit, work on it until you master it, and make it an automatic part of your daily life. Then, repeat the process for the next habit.
  8. Building Services at Airbnb, part 1 and Building Services at Airbnb, part 2 : 30 mins. Airbnb is moving its infrastructure at an accelerated pace towards a SOA (Service-Oriented Architecture), but moving from a monolithic Rails service towards a SOA while building out new products and features is not without its challenges.
  9. 6 things I’ve learned in my first 6 months using serverless : 10 mins. The six lessons are 1) Ditch Python 2) Burn the middle layer to the ground 3) Enjoy the Vue 4) Learn to love DynamoDB 5) Serverless Framework FTW 6) Authorization is the new sheriff in the town.
  10. Genius as Circumstance : 15 mins. There is a way of thinking about genius that could powerfully encapsulate the creative process. It begins by no longer applying the term to individuals. If calling an individual “a genius” sounds pompous and grandiose, describing some thing as “genius” is commonplace. “That was a genius move,” I find myself saying too often for it to actually mean very much.

Refactoring conditional logic

A couple of weeks back I was working on a piece of code that was becoming a tangled mess of if-else conditions. I was finding it difficult to reason and adding a new condition without breaking the existing code was becoming difficult. I knew as we will discover rules for new conditions the code in the class will grow. I was not satisfied with the code so started looking for ways to refactor the code. The code used in this post uses Java 8 as the programming language.
Read More »

TIL #7: Java Lambda Puzzler

Today, a colleague asked me how they can pass a java.util.Stream to a function that accept an java.lang.Iterable.

Let’s suppose we have a following function that accepts an Iterable.

public static void doSth(Iterable<String> iterable){
        iterable.forEach(System.out::println);
 }

The calling function has a Stream that it want to pass to the doSth function.

public static void main(String[] args) throws IOException {
        Stream<String> lines = Files.lines(Paths.get("src", "main", "resources", "names.txt"));
}

One way we could easily achieve this is by collecting the Stream into a Collection like List. As List is an Iterable so we can pass it. This is should below

Stream<String> lines = Files.lines(Paths.get("src", "main", "resources", "names.txt"));
doSth(lines.collect(Collectors.toList()));

This works but what if Stream is big and collecting into an in-memory data structure like List leads to java.lang.OutOfMemoryError: Java heap space.

I googled around and found a nice Lambda hack.

Stream<String> lines = Files.lines(Paths.get("src", "main", "resources", "names.txt"));
doSth(lines::iterator);

I have worked a lot on Java 8 but first time I looked at it I couldn’t figure out how it works. If you know Java 8, give it a shot.

The magic here is that Iterable interface has a single abstract method iterator.

public interface Iterable<T> {
    Iterator<T> iterator();
}

This means we can write it as following Lambda function.

Iterable<T> iterable = () -> iterator();

In our case, Stream has an iterator method. So, we can convert Stream to Iterable by defining a lambda function as shown below.

Stream<String> lines = Files.lines(Paths.get("src", "main", "resources", "names.txt"));
doSth(() -> lines.iterator());

You can refactor the Lambda to a method reference.

Stream<String> lines = Files.lines(Paths.get("src", "main", "resources", "names.txt"));
doSth(lines::iterator);

Can we use () -> iterator() in the for-each loop

I wondered if we can use the lambda expression in the for-each loop

for (String str : () -> lines.iterator()) {
    System.out.println(str);
}

This looks like a valid use case. As for-each loop works with types that implement Iterable interface. But, it turns out the code does not compile. It gives Lambda expression not implemented here error.

The answer for this is mentioned in the JSR335

Deciding what contexts are allowed to support poly expressions 
is driven in large part by the practical 
need for such features:

The expression in an enhanced for loop is not in a 
poly context because, as the construct is currently defined, 
it is as if the expression were a receiver: 
exp.iterator() (or, in the array case, exp[i]). 
It is plausible that an Iterator could be wrapped 
as an Iterable in a for loop via a 
lambda expression (for (String s : () -> stringIterator)), 
but this doesn't mesh very well with the semantics of Iterable.

Another Interesting thing to note is that Iterable is not marked as @FunctionalInterface. I don’t know the exact reason why Iterable is not marked as @FunctionalInterface. My guess is that because Iterable has special semantics in Java so they didn’t explicitly marked it @FunctionalInterface.

Issue #6: 10 Reads, A Handcrafted Weekly Newsletter for Humans

Hey y’all,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 130 minutes.
Half of everything you hear in a classroom is crap. Education is figuring out which half is which. — Larrabee’s Law
  1. The 5 Lies We Love to Tell : 10 mins read. The author makes the point that we all lie to ourselves. We should stop fooling ourselves that we don’t lie. The biggest problem with lies is that they consume a lot of your mental power in the background. You have to expend your mental energy to keep reminding yourself what lie you made to your inner self so that you don’t deviate from it.
  2. Please Stop Using Adblock (But Not Why You Think) : 10 mins read.  The key point in this post is that Adblock is making a lot of money by making advertisers like Google to whitelist their ads. I was shocked to read the dark side of AdBlock. The author recommends that people use free and open source uBlock Origin.
  3. Tech’s Two Philosophies : 15 mins read. The author makes the point that there are two main philosophies in the tech industry. The first philosophy shared by Google and Facebook is that computers should do work for humans. The second philosophy shared by Microsoft and Apple is that computers empower humans and help them do their work efficiently.
  4. It’s about time to design in the real world. Introducing Hadron! : 10 mins read. Hadron is a tool aimed to make designing through code visual, fast and easy by embracing the web platform. Even though you will use code, the great thing is that not only very little writing is needed to get started, but also your designs can be progressively enhanced. Meaning that you can start designing with only simple HTML and CSS, and later make your design do more by adding behaviour through other Web Components or even writing JS yourself.
  5. The Economics of Writing a Technical Book: 15 mins read. This is a good post that will help you understand economics of writing a technical book. In my opinion, author made good money from writing his first book. Part of it has to do with the fact that he wrote for O’Reilly Media. Writing a book is tiring and cumbersome so kudos to the author on publishing his first book.
  6. Three-day no-meeting schedule for engineers: 5 mins read. It is great to see organisations understanding the need for focussed time. I strongly believe what Paul Graham wrote in his essay on Manager vs Maker schedule. Software development is a creative endeavour that requires an undistracted, peaceful environment for good work. I hope my organization also does the same one day.
  7. High availability and scalable reads in PostgreSQL : 20 mins read. A detailed primer on streaming replication, complete with performance measurements.
  8. How Postgresql analysis helped to gain 290 times performance boost for a particular request : 10 mins read. This is an interesting read as the guy tried many difficult solutions before figuring out a simple change to improve performance of his query by 290 times. Simple solutions are difficult to find. This post shows  how query and data model design minor mistakes can lead to performance bottlenecks and how extremely useful explain analyze command can be.
  9. Experiences with running PostgreSQL on Kubernetes : 20 mins read. Kubernetes is not aware of the deployment details of Postgres. A naive deployment could lead to complete data loss. Here’s a typical scenario when that happens. You set up streaming replication and let’s say the first master is up. All the writes go there and they asynchronously replicate to the standby. Then suddenly the current master goes down but the asynchronous replication has a huge lag caused by something like a network partition. If the naive failover leader election algorithm kicks in or the administrator who doesn’t know the state manually triggers failover, the secondary becomes the master. That becomes the source of truth. All of the data during that period is lost because all of the writes that were not replicated disappear. Whenever the admin recovers the first master it’s no longer the master any more and it has to completely sync the state from the second node which is now the master.