People with desk job spend half of their waking life tied to a desk. Yet most are NOT deliberate about their office setup. Today I’m going to talk about one of my favourite topics; how to setup your home office (or office office) so it’s better for your body and productivity. I will cover standing desks, monitors, mounts, docking station, chairs etc. The information is applicable universally but for folks in India, I’ll share my favourite brands/models/vendors and prices as well.
Disclaimer: All opinions are personal.
I have been running my bootstrapped venture over a year now & previously been on a startup team that went from angel-seed-series A. Having seen both the sides closely I have some thoughts to share. I’m writing mainly to solidify my own thoughts but you might find it a fun/useful read.
tl;dr – Both sides of the camp over glamorize their approach (yeah bootstrappers too), while in fact they both have pros and cons and really serve different purposes. Good news is, it’s one of the easier decisions in your journey. It ultimately depends on founder’s goal, personality & nature of the problem to some extent.
If you are not familiar with ReviewNB, you might want to check that out first. It’s a tool that lets your team review Jupyter Notebook changes & enables collaborative workflows with it.
Today, I’m excited to announce commenting feature for all the ReviewNB users. Here’s everything you can do with it,
I’m excited to announce ReviewNB, a code review tool for Jupyter Notebooks.
Jupyter is great for data exploration but it’s hard to go beyond that & do any kind of collaborative work with it. Following challenges exist in using Jupyter Notebooks with modern version control system like Git,
- Notebook diffs are hard to read. Hence we can’t do code reviews on GitHub
- Merging in remote changes is hard due to JSON format of Notebook files (.ipynb)
- No easy way to share feedback & have a discussion around Notebooks
- It’s not easy to reproduce Notebook results
- It’s not easy to test notebook code cells
UPDATE: I built a tool to solve some of the challenges mentioned in the post. It’s now live at https://www.reviewnb.com/
A lot of people, including me, love Jupyter Notebooks. It’s a fantastic tool for data science. Today I’m not going to talk about it’s amazing capabilities but rather how it fails at two important things: Version Control and Reproducibility. I will also outline the current state-of-the-art to solve these problems. It’s a useful read if you are a Jupyter user. Let’s jump right in.
Companies that care about uptime generally use pager duty & have an on-call rotation. Instructions to handle common incidents are maintained on internal documents called runbooks. These are written in plain English & typically maintained on an internal wiki. First, let’s see some challenges with current form of runbooks:
- You need to manually execute each step, no automation
- It’s quite an effort to get everybody onboard to keep the runbooks up to date
- Unless well written, there can be ambiguity/confusion in following instructions
To tackle some of these problems I am proposing a use of novel data science tool, Jupyter Notebooks. Notebooks are a unique combination of markdown text, executable code, and output all within a single document served in a browser. This combination of features fits the runbook need very well. Let’s see with an actual example. Here’s a before & after picture of simple Gitlab runbook converted into Jupyter Notebook. (kudos to Gitlab for making their runbooks public).
Apache Kafka has grown a lot in functionality & reach in last couple of years. It’s used in production by one third of the Fortune 500, including 7 of the top 10 global banks, 8 of the top 10 insurance companies, 9 of the top 10 U.S. telecom companies [source].
This article gives you a quick tour of the core functionality offered by Kafka. I present lot of examples to help you understand common usage patterns. Hopefully you’ll find some correlation with your own workflows & start leveraging the power of Kafka. Let’s start by looking at 2 core functionalities offered by Kafka.
Earlier last week I was working on a python package that would compress numerical series into strings (and back). The package is now available on Github. It gets you around ~80% compression. It is useful to store or transmit stock prices, monitoring & other time series data in compressed string format.
Estimating software development effort is tricky and can often be a point of contention in the team. I have seen teams spending an entire day planning a 2 week sprint, working out every detail of every task. After a few sprints they have some sense of their team’s “velocity” and could tell how much work their team can deliver in a sprint. And I have seen teams where developers huddle casually, take on major features, gives out rough dates, and miss their deadline by a lot.
I can’t propose a generic process for estimation as it’s highly dependent on the nature of business, team size, culture etc. And frankly I don’t even know what the best process looks like. Instead I am going to share some common pitfalls and best practices that are applicable for any development team. This is a useful read for developers and product owners alike. Let’s dive in!
Elasticsearch is primarily known for it’s search capabilities but it’s also very well suited for storage, aggregation, and querying of time series data. In this tutorial, we’ll learn how to use Elasticsearch to store simple metrics and visualize them with Kibana.
To summarize, we’ll generate dummy signup data with this script. Ingest it into locally running Elasticsearch. Use Kibana to visualize the data in different ways. For simplicity, we are not using Logstash in this tutorial but you can easily configure the same data to be ingested through Logstash. Let’s dive in!