DEV Community: Bartosz Mikulski

Disposable Company Syndrome

Bartosz Mikulski — Mon, 07 Jul 2025 05:34:28 +0000

If I had a dollar for every founder who said, “I’m excited to announce…” like they were narrating a funeral (of someone they never met), I’d have enough to fund my own startup, buy a failed one off Craigslist, and still have cash for launch party confetti.

Yet again, I watch a video of two dudes too tired to put on a fake American smile. One drones a lullaby of buzzwords. The other one nods like a human metronome on 1-second intervals.

Sure, it’s your 14th take. Your cofounder’s holding the iPhone. Their hands are cramping. The pizza’s cold. Everyone wants to go home. One of you never wanted to be here in the first place.

But if you can’t fake excitement (or at least hide disappointment) for your own launch, why should anyone else feel it for you?

I imagine it’s hard to cultivate excitement when you are building a disposable company.

Once, a company was a century-long bet with the founder’s name on the line. Honda. Heinz. Heineken. Those weren’t just companies. The founders were building a legacy. They were trying to tattoo their surname on the century (or five centuries like Barclays did).

Now, company names have no meaning and no association with the founder. Founders treat startups like scratch-off tickets because every company is built to be sold.

A disposable startup is a Hollywood set with cardboard walls propped up just long enough for the funding photo. The build-to-flip poison seeps into every sprint. No revenue? We plan to ship, hype, and offload before the investor money evaporates. Unstable software and constant bugs? “Move fast and break things.” Unsustainable working hours? “We are a startup” is an excuse for everything.

Employees swallow the silence tax in exchange for worthless options dressed up as “skin in the game.” If you’re lucky and the company actually sells, you may earn an equivalent of your quarterly salary. Your payment for three years of working nights and weekends, chasing the mythical hockey stick chart, and hoping to become a household name. Three years of trading craftsmanship for a delusion of a big payout one day. The first time I cashed out my “skin in the game,” my “owner bonus” bought me an unlimited bus pass for a month.

No doubt, we end up with founders sharing their big announcements with the enthusiasm of a radio speaker reading the death toll of a natural disaster. How different would it be if they planned the company to outlive them? But if the legacy is optional, enthusiasm is too.

Building an agentic AI workflow with Llama 3 open-source LLM using LangGraph

Bartosz Mikulski — Tue, 21 May 2024 05:45:14 +0000

We have a database of a fictional telco company providing home phone and internet services to customers in California. We want to build an AI system capable of analizing the data and answering users' questions about customers, services, and billing. We will design an agentic AI workflow to plan the data retrieval, generate SQL queries, execute the queries, and generate human-readable responses.

What Are Agentic AI Workflows?

An agentic AI workflow is a multi-step process that autonomously handles complex tasks. We build such a process by doing all (or at least some) of the following actions:

Breaking down the task into smaller steps.
The AI workflow doesn't try to tackle the whole task at once. Instead, the workflow orchestration code executes a series of simpler prompts. Those prompts gather information required to complete the task, generate parameters for intermediate steps, or define the subsequent action to take. In the end, we synthesize the final result.
Defining the next action iteratively.
The intermediate steps can be pre-defined by the workflow's author, but we can also write rules for automatically generating the actions based on the task's current state.

In such an iterative approach, the AI system consists of an action planning agent, the part executing the action, and a decision-making agent to judge whether the actions were sufficient or if another step is needed.
Using multiple specialized AI agents.
We don't have a single prompt encompassing the entire task and all tools available to the AI system. Instead, we break the prompt into smaller parts, each handled by a specialized AI agent. This increases the number of interactions with the LLM, but each interaction is simpler, less error-prone, and easier to debug.
Using autonomous action planning and decision-making.
The AI workflow doesn't require human intervention to execute the task. The AI system autonomically decides what to do next based on the task's current state and the information gathered during the previous steps.
Writing advanced prompts such as Chain of Thought or Self-Reflection.
We use Chain of Thought or Few-Shot in-context learning to define what the AI agent is supposed to do. Optionally, we can ask the AI agent to review the system's actions and suggest improvements.

Agentic Workflows with LangGraph

In LangGraph, we can define the agentic AI workflow as a graph consisting of LangChain chains. Each chain represents a single workflow step and usually consists of a single AI interaction (but that's not a rule). At the end of each step, we return new state variables. LangGraph passes those variables as input to the next step or uses them in conditional statements to decide what to do next.

In our example, we create an agentic AI workflow consisting of the following steps:

Decide if we can answer the user's question using the data available in the database.
Plan what data we need to retrieve.
Decide if we should continue the workflow. If not, we skip to the step where we explain why we can't answer the user's question.
If we continue, we generate an SQL query to retrieve the data.
Execute the query and generate a (markdown) text response.
Generate a human-readable answer for the user's question using the data retrieved from the database.

As we see above, we have autonomous action planning and decision-making because AI decides what data to retrieve or skip the question if we don't have access to the required information.

We have also broken the task into smaller steps, each handled by a specialized AI agent. We have an agent capable of generating SQL queries, another agent generating a human-readable response, and an AI agent planning the action.

Executing the query and generating a text response is a step using a pre-defined Python function. Only the function's input is AI-generated.

How Do You Use LLama LLM For an Agentic AI Workflow?

In this article, I use the llama3-70b model deployed in Llama API. The model is deployed and managed by a third-party service, so I need an API key and a client library.

Instead of using the Llama API SDK, we will change the base URL of the official OpenAI client. Because of that, I can use the tried and trusted LangChain client implementation instead of worrying about bugs in an experimental LLama API Client.

If you want a cheaper model, you can try llama3-8b, but the workflow may not work as expected. When I tested the workflow with the llama3-8b model deployed on Llama API, the response time was too slow, and many requests failed with an Internal Server Error. Still, repeating them to make them pass was sufficient, so I wonder if that's a problem with the model or the deployment environment. Anyway, a workflow where some of the requests randomly fail is useless unless you add retry logic to all of the AI-agent-invoking functions.

Required Libraries

Before we start, we have to install the dependencies. I used the following libraries:

langchain==0.2.0
langgraph==0.0.50
openai==1.30.1
langchain-openai==0.1.7

I want to use LangSmith for tracking and debugging the requests, so I need two API keys and the LangSmith configuration:

import os


LLAMA_API = "LL-..."
LANGSMITH_API = "lsv2..."

os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_ENDPOINT"] = "https://api.smith.langchain.com"
os.environ["LANGCHAIN_API_KEY"] = LANGSMITH_API
os.environ["LANGCHAIN_PROJECT"] = "SOME NAME"

Connecting to a Llama-3 LLM model in LLama API

Now, we import the client and configure the URL and the model name.

from langchain_openai import ChatOpenAI


model = ChatOpenAI(
    openai_api_key=LLAMA_API,
    openai_api_base="https://api.llama-api.com",
    model="llama3-70b"
)

Now, we can use the OpenAI-compatible code with an open-source model. Of course, switching to a different model is not that simple. We will also have to write Llama-compatible prompts, but I will explain the changes when we define the prompts.

Data Preparation

First, we need data in our database. In this article, I will use the Telco Customer Churt dataset from Kaggle. I load the data into a data frame, split the DataFrame into five parts, and store each as a separate table in an SQLite database.

import pandas as pd
import sqlite3


df = pd.read_csv("telco.csv")

df.columns = df.columns.str.replace(' ', '_')

customer_df = df[['Customer_ID', 'Gender', 'Age', 'Under_30', 'Senior_Citizen', 'Married', 'Dependents', 'Number_of_Dependents', 'Country', 'State', 'City', 'Zip_Code', 'Latitude', 'Longitude', 'Population']]
service_df = df[['Customer_ID', 'Phone_Service', 'Multiple_Lines', 'Internet_Service', 'Internet_Type', 'Online_Security', 'Online_Backup', 'Device_Protection_Plan', 'Premium_Tech_Support', 'Streaming_TV', 'Streaming_Movies', 'Streaming_Music', 'Unlimited_Data']]
billing_df = df[['Customer_ID', 'Tenure_in_Months', 'Offer', 'Avg_Monthly_Long_Distance_Charges', 'Avg_Monthly_GB_Download', 'Contract', 'Paperless_Billing', 'Payment_Method', 'Monthly_Charge', 'Total_Charges', 'Total_Refunds', 'Total_Extra_Data_Charges', 'Total_Long_Distance_Charges', 'Total_Revenue']]
referral_df = df[['Customer_ID', 'Referred_a_Friend', 'Number_of_Referrals']]
churn_df = df[['Customer_ID', 'Quarter', 'Satisfaction_Score', 'Customer_Status', 'Churn_Label', 'Churn_Score', 'CLTV', 'Churn_Category', 'Churn_Reason']]

conn = sqlite3.connect('telco.db')

customer_df.to_sql('Customer', conn, if_exists='replace', index=False)
service_df.to_sql('Service', conn, if_exists='replace', index=False)
billing_df.to_sql('Billing', conn, if_exists='replace', index=False)
referral_df.to_sql('Referral', conn, if_exists='replace', index=False)
churn_df.to_sql('Churn', conn, if_exists='replace', index=False)

conn.close()

We will also need a Python function executing a SQL query and returning the result as a DataFrame:

def query_db(query):
  conn = sqlite3.connect('telco.db')
  try:
    return pd.read_sql_query(query, conn)
  finally:
    conn.close()

Finally, we have to describe the database's content so AI can decide which columns to use and what possible values they may have.

DB_DESCRIPTION = """You have access to the following tables and columns in a sqllite3 database:

Customer Table
Customer_ID: A unique ID that identifies each customer.
Gender: The customer’s gender: Male, Female.
Age: The customer’s current age, in years, at the time the fiscal quarter ended.
Under_30: Indicates if the customer is under 30: Yes, No.
Senior_Citizen: Indicates if the customer is 65 or older: Yes, No.
Married: Indicates if the customer is married: Yes, No.
Dependents: Indicates if the customer lives with any dependents: Yes, No.
Number_of_Dependents: Indicates the number of dependents that live with the customer.
Country: The country of the customer’s primary residence. Example: United States.
State: The state of the customer’s primary residence.
City: The city of the customer’s primary residence.
Zip_Code: The zip code of the customer’s primary residence.
Latitude: The latitude of the customer’s primary residence.
Longitude: The longitude of the customer’s primary residence.
Population: A current population estimate for the entire Zip Code area.

Service Table
Customer_ID: A unique ID that identifies each customer (Foreign Key).
Phone_Service: Indicates if the customer subscribes to home phone service with the company: Yes, No.
Multiple_Lines: Indicates if the customer subscribes to multiple telephone lines with the company: Yes, No.
Internet_Service: Indicates if the customer subscribes to Internet service with the company: Yes, No.
Internet_Type: Indicates the type of Internet service: DSL, Fiber Optic, Cable, None.
Online_Security: Indicates if the customer subscribes to an additional online security service provided by the company: Yes, No.
Online_Backup: Indicates if the customer subscribes to an additional online backup service provided by the company: Yes, No.
Device_Protection Plan: Indicates if the customer subscribes to an additional device protection plan for their Internet equipment provided by the company: Yes, No.
Premium_Tech_Support: Indicates if the customer subscribes to an additional technical support plan from the company with reduced wait times: Yes, No.
Streaming_TV: Indicates if the customer uses their Internet service to stream television programming from a third party provider: Yes, No.
Streaming_Movies: Indicates if the customer uses their Internet service to stream movies from a third party provider: Yes, No.
Streaming_Music: Indicates if the customer uses their Internet service to stream music from a third party provider: Yes, No.
Unlimited_Data: Indicates if the customer has paid an additional monthly fee to have unlimited data downloads/uploads: Yes, No.

Billing Table
Customer_ID: A unique ID that identifies each customer (Foreign Key).
Tenure_in_Months: Indicates the total amount of months that the customer has been with the company by the end of the quarter specified above.
Offer: Identifies the last marketing offer that the customer accepted, if applicable. Values include None, Offer A, Offer B, Offer C, Offer D, and Offer E.
Avg_Monthly_Long_Distance_Charges: Indicates the customer’s average long distance charges, calculated to the end of the quarter specified above.
Avg_Monthly_GB_Download: Indicates the customer’s average download volume in gigabytes, calculated to the end of the quarter specified above.
Contract: Indicates the customer’s current contract type: Month-to-Month, One Year, Two Year.
Paperless_Billing: Indicates if the customer has chosen paperless billing: Yes, No.
Payment_Method: Indicates how the customer pays their bill: Bank Withdrawal, Credit Card, Mailed Check.
Monthly_Charge: Indicates the customer’s current total monthly charge for all their services from the company.
Total_Charges: Indicates the customer’s total charges, calculated to the end of the quarter specified above.
Total_Refunds: Indicates the customer’s total refunds, calculated to the end of the quarter specified above.
Total_Extra_Data_Charges: Indicates the customer’s total charges for extra data downloads above those specified in their plan, by the end of the quarter specified above.
Total_Long_Distance_Charges: Indicates the customer’s total charges for long distance above those specified in their plan, by the end of the quarter specified above.
Total_Revenue: The total revenue generated from the customer.

Referral Table
Customer_ID: A unique ID that identifies each customer (Foreign Key).
Referred_a_Friend: Indicates if the customer has ever referred a friend or family member to this company: Yes, No.
Number_of_Referrals: Indicates the number of referrals to date that the customer has made.

Churn Table
Customer_ID: A unique ID that identifies each customer (Foreign Key).
Quarter: The fiscal quarter that the data has been derived from (e.g. Q3).
Satisfaction_Score: A customer’s overall satisfaction rating of the company from 1 (Very Unsatisfied) to 5 (Very Satisfied).
Customer_Status: Indicates the status of the customer at the end of the quarter: Churned, Stayed, Joined.
Churn_Label: Yes = the customer left the company this quarter. No = the customer remained with the company.
Churn_Score: A value from 0-100 that is calculated using the predictive tool IBM SPSS Modeler. The model incorporates multiple factors known to cause churn. The higher the score, the more likely the customer will churn.
CLTV: Customer Lifetime Value. A predicted CLTV is calculated using corporate formulas and existing data. The higher the value, the more valuable the customer. High value customers should be monitored for churn.
Churn_Category: A high-level category for the customer’s reason for churning: Attitude, Competitor, Dissatisfaction, Other, Price.
Churn_Reason: A customer’s specific reason for leaving the company. Directly related to Churn Category.
"""

Defining the Workflow Steps

Our workflow consists of five steps. Each step is a LangChain chain and a function that reads the chain's parameters from the workflow state, executes the chain, and returns the new state.

We define the steps as PromptTemplates and use output parsers to extract the required information from the AI response.

from langchain_core.prompts import ChatPromptTemplate
from langchain.prompts import PromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.output_parsers import JsonOutputParser

LLama-compatible Prompts

If we used the Llama client for LangChain, we wouldn't have to adapt the prompts (the client library would handle the prompt structure). However, we use the OpenAI client with a modified URL. Because of that, we must follow the Llama prompt structure.

Action Planning

For action planning, we need an agent capable of reasoning which columns and tables contain relevant data and deciding whether all required information is available in the database. We will use the Chain of Thought to provide examples of the expected behavior. The agent will respond with a JSON object containing the reasoning and the decision. We will use the reasoning later as an action plan. The decision will be the variable determining whether we continue the workflow.

We have two input variables. One is the user's question, and the other is the database description we defined earlier. I separate the prompt and the description because it makes the prompt more readable, and we need the description in the next step, too.

can_answer_router_prompt = PromptTemplate(
    template="""<|begin_of_text|><|start_header_id|>system<|end_header_id|>
    You are a database reading bot that can answer users' questions using information from a database. \n

    {data_description} \n\n

    Given the user's question, decide whether the question can be answered using the information in the database. \n\n

    Return a JSON with two keys, 'reasoning' and 'can_answer', and no preamble or explanation.
    Return one of the following JSON:
    {% raw %}
    {{"reasoning": "I can find the average revenue of customers with tenure over 24 months by averaging the Total Revenue column in the Billing table filtered by Tenure in Months > 24", "can_answer":true}}
    {{"reasoning": "I can find customers who signed up during the last 12 month using the Tenure in Months column in the Billing table", "can_answer":true}}
    {{"reasoning": "I can't answer how many customers churned last year because the Churn table doesn't contain a year", "can_answer":false}}
    {% endraw %}

    <|eot_id|><|start_header_id|>user<|end_header_id|>
    Question: {question} \n
    <|eot_id|><|start_header_id|>assistant<|end_header_id|>""",
    input_variables=["data_description", "question"],
)

can_answer_router = can_answer_router_prompt | model | JsonOutputParser()

def check_if_can_answer_question(state):
  result = can_answer_router.invoke({"question": state["question"], "data_description": DB_DESCRIPTION})

  return {"plan": result["reasoning"], "can_answer": result["can_answer"]}

What to do next?

Check out my blog to read the rest of the article (for free; I just want more traffic there ;) ) https://mikulskibartosz.name/agentic-workflow-with-opensource-llms

Parsing logs from multiple data sources with Ahana and Cube

Bartosz Mikulski — Wed, 08 Jun 2022 14:31:39 +0000

Ahana provides managed Presto clusters running in your AWS account.

Presto is an open-source distributed SQL query engine, originally developed at Facebook, now hosted under the Linux Foundation. It connects to multiple databases or other data sources (for example, Amazon S3). We can use a Presto cluster as a single compute engine for an entire data lake.

Presto implements the data federation feature: you can process data from multiple sources as if they were stored in a single database. Because of that, you don’t need a separate ETL (Extract-Transform-Load) pipeline to prepare the data before using it. However, running and configuring a single-point-of-access for multiple databases (or file systems) requires Ops skills and an additional effort.

However, no data engineer wants to do the Ops work. Using Ahana, you can deploy a Presto cluster within minutes without spending hours configuring the service, VPCs, and AWS access rights. Ahana hides the burden of infrastructure management and allows you to focus on processing your data.

What is Cube?

Cube is a headless BI platform for accessing, organizing, and delivering data. Cube connects to many data warehouses, databases, or query engines, including Presto, and allows you to quickly build data applications or analyze your data in BI tools. It serves as the single source of truth for your business metrics.

This article will demonstrate the caching functionality, access control, and flexibility of the data retrieval API.

Integration

Cube's battle-tested Presto driver provides the out-of-the-box connectivity to Ahana.

You just need to provide the credentials: Presto host name and port, user name and password, Presto catalog and schema. You'll also need to set CUBEJS_DB_SSL to true since Ahana has secures Presto connections with SSL.

Check the docs to learn more about connecting Cube to Ahana.

Example: Parsing logs from multiple data sources with Ahana and Cube

Let's build a real-world data application with Ahana and Cube.

We will use Ahana to join Amazon Sagemaker Endpoint logs stored as JSON files in S3 with the data retrieved from a PostgreSQL database.

Suppose you work at a software house specializing in training ML models for your clients and delivering ML inference as a REST API. You have just trained new versions of all models, and you would like to demonstrate the improvements to the clients.

Because of that, you do a canary deployment of the versions and gather the predictions from the new and the old models using the built-in logging functionality of AWS Sagemaker Endpoints: a managed deployment environment for machine learning models. Additionally, you also track the actual production values provided by your clients.

You need all of that to prepare personalized dashboards showing the results of your hard work.

Let us show you how Ahana and Cube work together to help you achieve your goal quickly without spending days reading cryptic documentation.

You will retrieve the prediction logs from an S3 bucket and merge them with the actual values stored in a PostgreSQL database. After that, you calculate the ML performance metrics, implement access control, and hide the data source complexity behind an easy-to-use REST API.

In the end, you want a dashboard looking like this:

How to configure Ahana?

Allowing Ahana to access your AWS account

First, let’s login to Ahana, and connect it to your AWS account. We must create an IAM role allowing Ahana to access our AWS account.

On the setup page, click the “Open CloudFormation” button. After clicking the button, we get redirected to the AWS page for creating a new CloudFormation stack from a template provided by Ahana. Create the stack and wait until CloudFormation finishes the setup.

When the IAM role is configured, click the stack’s Outputs tab and copy the AhanaCloudProvisioningRole key value.

We have to paste it into the Role ARN field on the Ahana setup page and click the “Complete Setup” button.

Creating an Ahana cluster

After configuring AWS access, we have to start a new Ahana cluster.

In the Ahana dashboard, click the “Create new cluster” button.

In the setup window, we can configure the type of the AWS EC2 instances used by the cluster, scaling strategy, and the Hive Metastore. If you need a detailed description of the configuration options, look at the “Create new cluster” section of the Ahana documentation.

Remember to add at least one user to your cluster! When we are satisfied with the configuration, we can click the “Create cluster” button. Ahana needs around 20-30 minutes to setup a new cluster.

Retrieving data from S3 and PostgreSQL

After deploying a Presto cluster, we have to connect our data sources to the cluster because, in this example, the Sagemaker Endpoint logs are stored in S3 and PostgreSQL.

Adding a PostgreSQL database to Ahana

In the Ahana dashboard, click the “Add new data source” button. We will see a page showing all supported data sources. Let’s click the “Amazon RDS for PostgreSQL” option.

In the setup form displayed below, we have to provide the database configuration and click the “Add data source” button.

Adding an S3 bucket to Ahana

AWS Sagemaker Endpoint stores their logs in an S3 bucket as JSON files. To access those files in Presto, we need to configure the AWS Glue data catalog and add the data catalog to the Ahana cluster.

We have to login to the AWS console, open the AWS Glue page and add a new database to the data catalog (or use an existing one).

Now, let’s add a new table. We won’t configure it manually. Instead, let’s create a Glue crawler to generate the table definition automatically. On the AWS Glue page, we have to click the “Crawlers” link and click the “Add crawler” button.

After typing the crawler’s name and clicking the “Next” button, we will see the Source Type page. On this page, we have to choose the “Data stores” and “Crawl all folders” (in our case, “Crawl new folders only” would work too).

On the “Data store” page, we pick the S3 data store, select the S3 connection (or click the “Add connection” button if we don’t have an S3 connection configured yet), and specify the S3 path.

Note that Sagemaker Endpoints store logs in subkeys using the following key structure: endpoint-name/model-variant/year/month/day/hour. We want to use those parts of the key as table partitions.

Because of that, if our Sagemaker logs have an S3 key: s3://the_bucket_name/sagemaker/logs/endpoint-name/model-variant-name/year/month/day/hour, we put only the s3://the_bucket_name/sagemaker/logs key prefix in the setup window!

Let’s click the “Next” button. In the subsequent window, we choose “No” when asked whether we want to configure another data source. Glue setup will ask about the name of the crawler’s IAM role. We can create a new one:

Next, we configure the crawler’s schedule. A Sagemaker Endpoint adds new log files in near real-time. Because of that, it makes sense to scan the files and add new partitions every hour:

In the output configuration, we need to customize the settings.

First, let’s select the Glue database where the new tables get stored. After that, we modify the “Configuration options.”

We pick the “Add new columns only” because we will make manual changes in the table definition, and we don’t want the crawler to overwrite them. Also, we want to add new partitions to the table, so we check the “Update all new and existing partitions with metadata from the table.” box.

Let’s click “Next.” We can check the configuration one more time in the review window and click the “Finish” button.

Now, we can wait until the crawler runs or open the AWS Glue Crawlers view and trigger the run manually. When the crawler finishes running, we go to the Tables view in AWS Glue and click the table name.

In the table view, we click the “Edit table” button and change the “Serde serialization lib” to “org.apache.hive.hcatalog.data.JsonSerDe” because the AWS JSON serialization library isn’t available in the Ahana Presto cluster.

We should also click the “Edit schema” button and change the default partition names to values shown in the screenshot below:

After saving the changes, we can add the Glue data catalog to our Ahana Presto cluster.

Configuring data sources in the Presto cluster

Go back to the Ahana dashboard and click the “Add data source” button. Select the “AWS Glue Data Catalog for Amazon S3” option in the setup form.

Let’s select our AWS region and put the AWS account id in the “Glue Data Catalog ID” field. After that, we click the “Open CloudFormation” button and apply the template. We will have to wait until CloudFormation creates the IAM role.

When the role is ready, we copy the role ARN from the Outputs tab and paste it into the “Glue/S3 Role ARN” field:

On the Ahana setup page, we click the “Add data source” button.

Adding data sources to an existing cluster

Finally, we can add both data sources to our Ahana cluster.

We have to open the Ahana “Clusters” page, click the “Manage” button, and scroll down to the “Data Sources” section. In this section, we click the “Manage data sources” button.

We will see another setup page where we check the boxes next to the data sources we want to configure and click the “Modify cluster” button. We will need to confirm that we want to restart the cluster to make the changes.

Writing the Presto queries

Before configuring Cube, let’s write the Presto queries to retrieve the data we want.

The actual structure of the input and output from an AWS Sagemaker Endpoint depends on us. We can send any JSON request and return a custom JSON object.

Let’s assume that our endpoint receives a request containing the input data for the machine learning model and a correlation id. We will need those ids to join the model predictions with the actual data.

Example input:

{"time_series": [51, 37, …, 7], "correlation_id": "cf8b7b9a-6b8a-45fe-9814-11a4b17c710a"}

In the response, the model returns a JSON object with a single “prediction” key and a decimal value:

{"prediction": 21.266147618448954}

A single request in Sagemaker Endpoint logs looks like this:

{"captureData": {"endpointInput": {"observedContentType": "application/json", "mode": "INPUT", "data": "eyJ0aW1lX3NlcmllcyI6IFs1MS40MjM5MjAzODYxNTAzODUsIDM3LjUwOTk2ODc2MTYwNzM0LCAzNi41NTk4MzI2OTQ0NjAwNTYsIDY0LjAyMTU3MzEyNjYyNDg0LCA2MC4zMjkwMzU2MDgyMjIwODUsIDIyLjk1MDg0MjgxNDg4MzExLCA0NC45MjQxNTU5MTE1MTQyOCwgMzkuMDM1NzA4Mjg4ODc2ODA1LCAyMC44NzQ0Njk2OTM0MzAxMTUsIDQ3Ljc4MzY3MDQ3MjI2MDI1NSwgMzcuNTgxMDYzNzUyNjY5NTE1LCA1OC4xMTc2MzQ5NjE5NDM4OCwgMzYuODgwNzExNTAyNDIxMywgMzkuNzE1Mjg4NTM5NzY5ODksIDUxLjkxMDYxODYyNzg0ODYyLCA0OS40Mzk4MjQwMTQ0NDM2OCwgNDIuODM5OTA5MDIxMDkwMzksIDI3LjYwOTU0MTY5MDYyNzkzLCAzOS44MDczNzU1NDQwODYyOCwgMzUuMTA2OTQ4MzI5NjQwOF0sICJjb3JyZWxhdGlvbl9pZCI6ICJjZjhiN2I5YS02YjhhLTQ1ZmUtOTgxNC0xMWE0YjE3YzcxMGEifQ==", "encoding": "BASE64"}, "endpointOutput": {"observedContentType": "application/json", "mode": "OUTPUT", "data": "eyJwcmVkaWN0aW9uIjogMjEuMjY2MTQ3NjE4NDQ4OTU0fQ==", "encoding": "BASE64"}}, "eventMetadata": {"eventId": "b409a948-fbc7-4fa6-8544-c7e85d1b7e21", "inferenceTime": "2022-05-06T10:23:19Z"}

AWS Sagemaker Endpoints encode the request and response using base64. Our query needs to decode the data before we can process it. Because of that, our Presto query starts with data decoding:

with sagemaker as (
  select
  model_name,
  variant_name,
  cast(json_extract(FROM_UTF8( from_base64(capturedata.endpointinput.data)), '$.correlation_id') as varchar) as correlation_id,
  cast(json_extract(FROM_UTF8( from_base64(capturedata.endpointoutput.data)), '$.prediction') as double) as prediction
  from s3.sagemaker_logs.logs
)
, actual as (
  select correlation_id, actual_value
  from postgresql.public.actual_values
)

After that, we join both data sources and calculate the absolute error value:

, logs as (
  select model_name, variant_name as model_variant, sagemaker.correlation_id, prediction, actual_value as actual
  from sagemaker
  left outer join actual
  on sagemaker.correlation_id = actual.correlation_id
)
, errors as (
  select abs(prediction - actual) as abs_err, model_name, model_variant from logs
),

Now, we need to calculate the percentiles using the approx_percentile function. Note that we group the percentiles by model name and model variant. Because of that, Presto will produce only a single row per every model-variant pair. That’ll be important when we write the second part of this query.

percentiles as (
  select approx_percentile(abs_err, 0.1) as perc_10,
  approx_percentile(abs_err, 0.2) as perc_20,
  approx_percentile(abs_err, 0.3) as perc_30,
  approx_percentile(abs_err, 0.4) as perc_40,
  approx_percentile(abs_err, 0.5) as perc_50,
  approx_percentile(abs_err, 0.6) as perc_60,
  approx_percentile(abs_err, 0.7) as perc_70,
  approx_percentile(abs_err, 0.8) as perc_80,
  approx_percentile(abs_err, 0.9) as perc_90,
  approx_percentile(abs_err, 1.0) as perc_100,
  model_name,
  model_variant
  from errors
  group by model_name, model_variant
)

In the final part of the query, we will use the filter expression to count the number of values within buckets. Additionally, we return the bucket boundaries. We need to use an aggregate function max (or any other aggregate function) because of the group by clause. That won’t affect the result because we returned a single row per every model-variant pair in the previous query.

SELECT count(*) FILTER (WHERE e.abs_err <= perc_10) AS perc_10
, max(perc_10) as perc_10_value
, count(*) FILTER (WHERE e.abs_err > perc_10 and e.abs_err <= perc_20) AS perc_20
, max(perc_20) as perc_20_value
, count(*) FILTER (WHERE e.abs_err > perc_20 and e.abs_err <= perc_30) AS perc_30
, max(perc_30) as perc_30_value
, count(*) FILTER (WHERE e.abs_err > perc_30 and e.abs_err <= perc_40) AS perc_40
, max(perc_40) as perc_40_value
, count(*) FILTER (WHERE e.abs_err > perc_40 and e.abs_err <= perc_50) AS perc_50
, max(perc_50) as perc_50_value
, count(*) FILTER (WHERE e.abs_err > perc_50 and e.abs_err <= perc_60) AS perc_60
, max(perc_60) as perc_60_value
, count(*) FILTER (WHERE e.abs_err > perc_60 and e.abs_err <= perc_70) AS perc_70
, max(perc_70) as perc_70_value
, count(*) FILTER (WHERE e.abs_err > perc_70 and e.abs_err <= perc_80) AS perc_80
, max(perc_80) as perc_80_value
, count(*) FILTER (WHERE e.abs_err > perc_80 and e.abs_err <= perc_90) AS perc_90
, max(perc_90) as perc_90_value
, count(*) FILTER (WHERE e.abs_err > perc_90 and e.abs_err <= perc_100) AS perc_100
, max(perc_100) as perc_100_value
, p.model_name, p.model_variant
FROM percentiles p, errors e group by p.model_name, p.model_variant

How to configure Cube?

In our application, we want to display the distribution of absolute prediction errors.

We will have a chart showing the difference between the actual value and the model’s prediction. Our chart will split the absolute errors into buckets (percentiles) and display the number of errors within every bucket.

If the new variant of the model performs better than the existing model, we should see fewer large errors in the charts. A perfect (and unrealistic) model would produce a single error bar in the left-most part of the chart with the “0” label.

At the beginning of the article, we looked at an example chart that shows no significant difference between both model variants:

If the variant B were better than the variant A, its chart could look like this (note the axis values in both pictures):

Creating a Cube deployment

Cube Cloud is the easiest way to get started with Cube. It provides a fully managed, ready to use Cube cluster. However, if you prefer self-hosting, then follow this tutorial.

First, please create a new Cube Cloud deployment. Then, open the "Deployments" page and click the “Create deployment” button.

We choose the Presto cluster:

Finally, we fill out the connection parameters and click the “Apply” button. Remember to enable the SSL connection!

Defining the data model in Cube

We have our queries ready to copy-paste, and we have configured a Presto connection in Cube. Now, we can define the Cube schema to retrieve query results.

Let’s open the Schema view in Cube and add a new file.

In the next window, type the file name errorpercentiles.js and click “Create file.”

In the following paragraphs, we will explain parts of the configuration and show you code fragments to copy-paste. You don’t have to do that in such small steps!

Below, you see the entire content of the file. Later, we explain the configuration parameters.

const measureNames = [
  'perc_10', 'perc_10_value',
  'perc_20', 'perc_20_value',
  'perc_30', 'perc_30_value',
  'perc_40', 'perc_40_value',
  'perc_50', 'perc_50_value',
  'perc_60', 'perc_60_value',
  'perc_70', 'perc_70_value',
  'perc_80', 'perc_80_value',
  'perc_90', 'perc_90_value',
  'perc_100', 'perc_100_value',
];

const measures = Object.keys(measureNames).reduce((result, name) => {
  const sqlName = measureNames[name];
  return {
    ...result,
    [sqlName]: {
      sql: () => sqlName,
      type: `max`
    }
  };
}, {});

cube('errorpercentiles', {
  sql: `with sagemaker as (
    select
    model_name,
    variant_name,
    cast(json_extract(FROM_UTF8( from_base64(capturedata.endpointinput.data)), '$.correlation_id') as varchar) as correlation_id,
    cast(json_extract(FROM_UTF8( from_base64(capturedata.endpointoutput.data)), '$.prediction') as double) as prediction
    from s3.sagemaker_logs.logs
  )
, actual as (
  select correlation_id, actual_value
  from postgresql.public.actual_values
)
, logs as (
  select model_name, variant_name as model_variant, sagemaker.correlation_id, prediction, actual_value as actual
  from sagemaker
  left outer join actual
  on sagemaker.correlation_id = actual.correlation_id
)
, errors as (
  select abs(prediction - actual) as abs_err, model_name, model_variant from logs
),
percentiles as (
  select approx_percentile(abs_err, 0.1) as perc_10,
  approx_percentile(abs_err, 0.2) as perc_20,
  approx_percentile(abs_err, 0.3) as perc_30,
  approx_percentile(abs_err, 0.4) as perc_40,
  approx_percentile(abs_err, 0.5) as perc_50,
  approx_percentile(abs_err, 0.6) as perc_60,
  approx_percentile(abs_err, 0.7) as perc_70,
  approx_percentile(abs_err, 0.8) as perc_80,
  approx_percentile(abs_err, 0.9) as perc_90,
  approx_percentile(abs_err, 1.0) as perc_100,
  model_name,
  model_variant
  from errors
  group by model_name, model_variant
)
SELECT count(*) FILTER (WHERE e.abs_err <= perc_10) AS perc_10
, max(perc_10) as perc_10_value
, count(*) FILTER (WHERE e.abs_err > perc_10 and e.abs_err <= perc_20) AS perc_20
, max(perc_20) as perc_20_value
, count(*) FILTER (WHERE e.abs_err > perc_20 and e.abs_err <= perc_30) AS perc_30
, max(perc_30) as perc_30_value
, count(*) FILTER (WHERE e.abs_err > perc_30 and e.abs_err <= perc_40) AS perc_40
, max(perc_40) as perc_40_value
, count(*) FILTER (WHERE e.abs_err > perc_40 and e.abs_err <= perc_50) AS perc_50
, max(perc_50) as perc_50_value
, count(*) FILTER (WHERE e.abs_err > perc_50 and e.abs_err <= perc_60) AS perc_60
, max(perc_60) as perc_60_value
, count(*) FILTER (WHERE e.abs_err > perc_60 and e.abs_err <= perc_70) AS perc_70
, max(perc_70) as perc_70_value
, count(*) FILTER (WHERE e.abs_err > perc_70 and e.abs_err <= perc_80) AS perc_80
, max(perc_80) as perc_80_value
, count(*) FILTER (WHERE e.abs_err > perc_80 and e.abs_err <= perc_90) AS perc_90
, max(perc_90) as perc_90_value
, count(*) FILTER (WHERE e.abs_err > perc_90 and e.abs_err <= perc_100) AS perc_100
, max(perc_100) as perc_100_value
, p.model_name, p.model_variant
FROM percentiles p, errors e group by p.model_name, p.model_variant`,

preAggregations: {
// Pre-Aggregations definitions go here
// Learn more here: https://cube.dev/docs/caching/pre-aggregations/getting-started
},

joins: {
},

measures: measures,
dimensions: {
  modelVariant: {
    sql: `model_variant`,
    type: 'string'
  },
  modelName: {
    sql: `model_name`,
    type: 'string'
  },
}
});

In the sql property, we put the query prepared earlier. Note that your query MUST NOT contain a semicolon.

We will group and filter the values by the model and variant names, so we put those columns in the dimensions section of the cube configuration. The rest of the columns are going to be our measurements. We can write them out one by one like this:

measures: {
  perc_10: {
    sql: `perc_10`,
    type: `max`
  },
  perc_20: {
    sql: `perc_20`,
    type: `max`
  },
  perc_30: {
    sql: `perc_30`,
    type: `max`
  },
  perc_40: {
    sql: `perc_40`,
    type: `max`
  },
  perc_50: {
    sql: `perc_50`,
    type: `max`
  },
  perc_60: {
    sql: `perc_60`,
    type: `max`
  },
  perc_70: {
    sql: `perc_70`,
    type: `max`
  },
  perc_80: {
    sql: `perc_80`,
    type: `max`
  },
  perc_90: {
    sql: `perc_90`,
    type: `max`
  },
  perc_100: {
    sql: `perc_100`,
    type: `max`
  },
  perc_10_value: {
    sql: `perc_10_value`,
    type: `max`
  },
  perc_20_value: {
    sql: `perc_20_value`,
    type: `max`
  },
  perc_30_value: {
    sql: `perc_30_value`,
    type: `max`
  },
  perc_40_value: {
    sql: `perc_40_value`,
    type: `max`
  },
  perc_50_value: {
    sql: `perc_50_value`,
    type: `max`
  },
  perc_60_value: {
    sql: `perc_60_value`,
    type: `max`
  },
  perc_70_value: {
    sql: `perc_70_value`,
    type: `max`
  },
  perc_80_value: {
    sql: `perc_80_value`,
    type: `max`
  },
  perc_90_value: {
    sql: `perc_90_value`,
    type: `max`
  },
  perc_100_value: {
    sql: `perc_100_value`,
    type: `max`
  }
},
dimensions: {
  modelVariant: {
    sql: `model_variant`,
    type: 'string'
  },
  modelName: {
    sql: `model_name`,
    type: 'string'
  },
}

The notation we have shown you has lots of repetition and is quite verbose. We can shorten the measurements defined in the code by using JavaScript to generate them.

We had to add the following code before using the cube function!

First, we have to create an array of column names:

const measureNames = [
  'perc_10', 'perc_10_value',
  'perc_20', 'perc_20_value',
  'perc_30', 'perc_30_value',
  'perc_40', 'perc_40_value',
  'perc_50', 'perc_50_value',
  'perc_60', 'perc_60_value',
  'perc_70', 'perc_70_value',
  'perc_80', 'perc_80_value',
  'perc_90', 'perc_90_value',
  'perc_100', 'perc_100_value',
];

Now, we must generate the measures configuration object. We iterate over the array and create a measure configuration for every column:

const measures = Object.keys(measureNames).reduce((result, name) => {
  const sqlName = measureNames[name];
  return {
    ...result,
    [sqlName]: {
      sql: () => sqlName,
      type: `max`
    }
  };
}, {});

Finally, we can replace the measure definitions with:

measures: measures,

After changing the file content, click the “Save All” button.

And click the Continue button in the popup window.

In the Playground view, we can test our query by retrieving the chart data as a table (or one of the built-in charts):

Configuring access control in Cube

In the Schema view, open the cube.js file.

We will use the queryRewrite configuration option to allow or disallow access to data.

First, we will reject all API calls without the models field in the securityContext. We will put the identifier of the models the user is allowed to see in their JWT token. The security context contains all of the JWT token variables.

For example, we can send a JWT token with the following payload. Of course, in the application sending queries to Cube, we must check the user’s access right and set the appropriate token payload. Authentication and authorization are beyond the scope of this tutorial, but please don’t forget about them.

After rejecting unauthorized access, we add a filter to all queries.

We can distinguish between the datasets accessed by the user by looking at the data specified in the query. We need to do it because we must filter by the modelName property of the correct table.

In our queryRewrite configuration in the cube.js file, we use the query.filter.push function to add a modelName IN (model_1, model_2, …) clause to the SQL query:

module.exports = {
  queryRewrite: (query, { securityContext }) => {
    if (!securityContext.models) {
      throw new Error('No models found in Security Context!');
    }
    query.filters.push({
      member: 'percentiles.modelName',
      operator: 'in',
      values: securityContext.models,
    });
    return query;
  },
};

Configuring caching in Cube

By default, Cube caches all Presto queries for 2 minutes. Even though Sagemaker Endpoints stores logs in S3 in near real-time, we aren’t interested in refreshing the data so often. Sagemaker Endpoints store the logs in JSON files, so retrieving the metrics requires a full scan of all files in the S3 bucket.

When we gather logs over a long time, the query may take some time. Below, we will show you how to configure the caching in Cube. We recommend doing it when the end-user application needs over one second to load the data.

For the sake of the example, we will retrieve the value only twice a day.

Preparing data sources for caching

First, we must allow Presto to store data in both PostgreSQL and S3. It’s required because, in the case of Presto, Cube supports only the simple pre-aggregation strategy. Therefore, we need to pre-aggregate the data in the source databases before loading them into Cube.

In PostgreSQL, we grant permissions to the user account used by Presto to access the database:

GRANT CREATE ON SCHEMA the_schema_we_use TO the_user_used_in_presto;
GRANT USAGE ON SCHEMA the_schema_we_use TO the_user_used_in_presto;

If we haven’t modified anything in the AWS Glue data catalog, Presto already has permission to create new tables and store their data in S3, but the schema doesn’t contain the target S3 location yet, so all requests will fail.

We must login to AWS Console, open the Glue data catalog, and create a new database called prod_pre_aggregations. In the database configuration, we must specify the S3 location for the table content.

If you want to use a different database name, follow the instructions in our documentation.

Caching configuration in Cube

Let’s open the errorpercentiles.js schema file. Below the SQL query, we put the preAggregations configuration:

preAggregations: {
  cacheResults: {
    type: `rollup`,
    measures: [
      errorpercentiles.perc_10, errorpercentiles.perc_10_value,
      errorpercentiles.perc_20, errorpercentiles.perc_20_value,
      errorpercentiles.perc_30, errorpercentiles.perc_30_value,
      errorpercentiles.perc_40, errorpercentiles.perc_40_value,
      errorpercentiles.perc_50, errorpercentiles.perc_50_value,
      errorpercentiles.perc_60, errorpercentiles.perc_60_value,
      errorpercentiles.perc_70, errorpercentiles.perc_70_value,
      errorpercentiles.perc_80, errorpercentiles.perc_80_value,
      errorpercentiles.perc_90, errorpercentiles.perc_90_value,
      errorpercentiles.perc_100, errorpercentiles.perc_100_value
    ],
    dimensions: [errorpercentiles.modelName, errorpercentiles.modelVariant],
    refreshKey: {
      every: `12 hour`,
    },
  },
},

After testing the development version, we can also deploy the changes to production using the “Commit & Push” button. When we click it, we will be asked to type the commit message:

When we commit the changes, the deployment of a new version of the endpoint will start. A few minutes later, we can start sending queries to the endpoint.

We can also check the pre-aggregations window to verify whether Cube successfully created the cached data.

Now, we can move to the Playground tab and run our query. We should see the “Query was accelerated with pre-aggregation” message if Cube used the cached values to handle the request.

Building the front-end application

Cube can connect to a variety of tools, including Jupyter Notebooks, Superset, and Hex. However, we want a fully customizable dashboard, so we will build a front-end application.

Our dashboard consists of two parts: the website and the back-end service. In the web part, we will have only the code required to display the charts. In the back-end, we will handle authentication and authorization. The backend service will also send requests to the Cube REST API.

Getting the Cube API key and the API URL

Before we start, we have to copy the Cube API secret. Open the settings page in Cube Cloud's web UI and click the “Env vars” tab. In the tab, you will see all of the Cube configuration variables. Click the eye icon next to the CUBEJS_API_SECRET and copy the value.

We also need the URL of the Cube endpoint. To get this value, click the “Copy API URL” link in the top right corner of the screen.

Back end for front end

Now, we can write the back-end code.

First, we have to authenticate the user. We assume that you have an authentication service that verifies whether the user has access to your dashboard and which models they can access. In our examples, we expect those model names in an array stored in the allowedModels variable.

After getting the user’s credentials, we have to generate a JWT to authenticate Cube requests. Note that we have also defined a variable for storing the CUBE_URL. Put the URL retrieved in the previous step as its value.

const jwt = require('jsonwebtoken');
CUBE_URL = '';
function create_cube_token() {
  const CUBE_API_SECRET = your_token; // Don’t store it in the code!!!
  // Pass it as an environment variable at runtime or use the
  // secret management feature of your container orchestration system

  const cubejsToken = jwt.sign(
    { "models": allowedModels },
    CUBE_API_SECRET,
    { expiresIn: '30d' }
  );

  return cubejsToken;
}

We will need two endpoints in our back-end service: the endpoint returning the chart data and the endpoint retrieving the names of models and variants we can access.

We create a new express application running in the node server and configure the /models endpoint:

const request = require('request');
const express = require('express')
const bodyParser = require('body-parser')
const port = 5000;
const app = express()

app.use(bodyParser.json())
app.get('/models', getAvailableModels);

app.listen(port, () => {
  console.log(`Server is running on port ${port}`)
})

In the getAvailableModels function, we query the Cube Cloud API to get the model names and variants. It will return only the models we are allowed to see because we have configured the Cube security context:

Our function returns a list of objects containing the modelName and modelVariant fields.

function getAvailableModels(req, res) {
  res.setHeader('Content-Type', 'application/json');
  request.post(CUBE_URL + '/load', {
    headers: {
      'Authorization': create_cube_token(),
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({"query": {
      "dimensions": [
        "errorpercentiles.modelName",
        "errorpercentiles.modelVariant"
      ],
      "timeDimensions": [],
      "order": {
        "errorpercentiles.modelName": "asc"
      }
    }})
  }, (err, res_, body) => {
    if (err) {
      console.log(err);
    }
    body = JSON.parse(body);
    response = body.data.map(item => {
      return {
        modelName: item["errorpercentiles.modelName"],
        modelVariant: item["errorpercentiles.modelVariant"]
      }
    });
    res.send(JSON.stringify(response));
  });
};

Let’s retrieve the percentiles and percentile buckets. To simplify the example, we will show only the query and the response parsing code. The rest of the code stays the same as in the previous endpoint.

The query specifies all measures we want to retrieve and sets the filter to get data belonging to a single model’s variant. We could retrieve all data at once, but we do it one by one for every variant.

{
  "query": {
    "measures": [
      "errorpercentiles.perc_10",
      "errorpercentiles.perc_20",
      "errorpercentiles.perc_30",
      "errorpercentiles.perc_40",
      "errorpercentiles.perc_50",
      "errorpercentiles.perc_60",
      "errorpercentiles.perc_70",
      "errorpercentiles.perc_80",
      "errorpercentiles.perc_90",
      "errorpercentiles.perc_100",
      "errorpercentiles.perc_10_value",
      "errorpercentiles.perc_20_value",
      "errorpercentiles.perc_30_value",
      "errorpercentiles.perc_40_value",
      "errorpercentiles.perc_50_value",
      "errorpercentiles.perc_60_value",
      "errorpercentiles.perc_70_value",
      "errorpercentiles.perc_80_value",
      "errorpercentiles.perc_90_value",
      "errorpercentiles.perc_100_value"
    ],
    "dimensions": [
        "errorpercentiles.modelName",
        "errorpercentiles.modelVariant"
    ],
    "filters": [
      {
        "member": "errorpercentiles.modelName",
        "operator": "equals",
        "values": [
          req.query.model
        ]
      },
      {
        "member": "errorpercentiles.modelVariant",
        "operator": "equals",
        "values": [
          req.query.variant
        ]
      }
    ]
  }
}

The response parsing code extracts the number of values in every bucket and prepares bucket labels:

response = body.data.map(item => {
  return {
    modelName: item["errorpercentiles.modelName"],
    modelVariant: item["errorpercentiles.modelVariant"],
    labels: [
      "<=" + item['percentiles.perc_10_value'],
      item['errorpercentiles.perc_20_value'],
      item['errorpercentiles.perc_30_value'],
      item['errorpercentiles.perc_40_value'],
      item['errorpercentiles.perc_50_value'],
      item['errorpercentiles.perc_60_value'],
      item['errorpercentiles.perc_70_value'],
      item['errorpercentiles.perc_80_value'],
      item['errorpercentiles.perc_90_value'],
      ">=" + item['errorpercentiles.perc_100_value']
    ],
    values: [
      item['errorpercentiles.perc_10'],
      item['errorpercentiles.perc_20'],
      item['errorpercentiles.perc_30'],
      item['errorpercentiles.perc_40'],
      item['errorpercentiles.perc_50'],
      item['errorpercentiles.perc_60'],
      item['errorpercentiles.perc_70'],
      item['errorpercentiles.perc_80'],
      item['errorpercentiles.perc_90'],
      item['errorpercentiles.perc_100']
    ]
  }
})

Dashboard website

In the last step, we build the dashboard website using Vue.js.

If you are interested in copy-pasting working code, we have prepared the entire example in a CodeSandbox. Below, we explain the building blocks of our application.

We define the main Vue component encapsulating the entire website content. In the script section, we will download the model and variant names. In the template, we iterate over the retrieved models and generate a chart for all of them.

We put the charts in the Suspense component to allow asynchronous loading.

To keep the example short, we will skip the CSS style part.

<script setup>
  import OwnerName from './components/OwnerName.vue'
  import ChartView from './components/ChartView.vue'
  import axios from 'axios'
  import { ref } from 'vue'
  const models = ref([]);
  axios.get(SERVER_URL + '/models').then(response => {
    models.value = response.data
  });
</script>

<template>
  <header>
    <div class="wrapper">
      <OwnerName name="Test Inc." />
    </div>
  </header>
  <main>
    <div v-for="model in models" v-bind:key="model.modelName">
      <Suspense>
        <ChartView v-bind:title="model.modelName" v-bind:variant="model.modelVariant" type="percentiles"/>
      </Suspense>
    </div>
  </main>
</template>

The OwnerName component displays our client’s name. We will skip its code as it’s irrelevant in our example.

In the ChartView component, we use the vue-chartjs library to display the charts. Our setup script contains the required imports and registers the Chart.js components:

import { Bar } from 'vue-chartjs'
import { Chart as ChartJS, Title, Tooltip, Legend, BarElement, CategoryScale, LinearScale } from 'chart.js'
import { ref } from 'vue'
import axios from 'axios'
ChartJS.register(Title, Tooltip, Legend, BarElement, CategoryScale, LinearScale);

We have bound the title, variant, and chart type to the ChartView instance. Therefore, our component definition must contain those properties:

const props = defineProps({
  title: String,
  variant: String,
  type: String
})

Next, we retrieve the chart data and labels from the back-end service. We will also prepare the variable containing the label text:

const response = await axios.get(SERVER_URL + '/' + props.type + '?model=' + props.title + '&variant=' + props.variant)
const data = response.data[0].values;
const labels = response.data[0].labels;
const label_text = "Number of prediction errors of a given value"

Finally, we prepare the chart configuration variables:

const chartData = ref({
  labels: labels,
  datasets: [
    {
      label: label_text,
      backgroundColor: '#f87979',
      data: data
    }
  ],
});

const chartOptions = {
  plugins: {
    title: {
      display: true,
      text: props.title + ' - ' + props.variant,
    },
  },
  legend: {
    display: false
  },
  tooltip: {
    enabled: false
  }
}

In the template section of the Vue component, we pass the configuration to the Bar instance:

<template>
  <Bar ref="chart" v-bind:chart-data="chartData" v-bind:chart-options="chartOptions" />
</template>

If we have done everything correctly, we should see a dashboard page with error distributions.

Wrapping up

Thanks for following this tutorial.

We encourage you to spend some time reading the Cube and Ahana documentation.

Please don't hesitate to like and bookmark this post, write a comment, give Cube a star on GitHub, join Cube's Slack community, and subscribe to the Ahana newsletter.

How programmers can be more productive by following the most important rule of productivity

Bartosz Mikulski — Wed, 09 Feb 2022 08:32:35 +0000

Originally published at efficacious.engineering

Is it possible to run seven companies simultaneously, build a global business while working a few hours every week and spend 3-6 months a year traveling? I don't know how to do it, but I know who does - Mirosław "Miroburn" Burnejko.

Miroburn is a Polish entrepreneur who describes his approach to life as "optimizing life to get the maximal personal freedom." He used to work in IT, so even those of us who don't want to start companies can learn something from him.

Why should we care? We should pay attention because he has one critical productivity rule that is the bedrock of everything else. What is it? Four words:

Eliminate, simplify, automate, delegate

Would you like to learn how to apply the rule to your life? Brace yourself for a long article. It will be worth it!

Doing less

At first glance, it looks like I lied to you. I promised you one crucial rule, and now I am talking about four necessary actions. Not quite. Every time we take those actions, we have fewer tasks to do ourselves.

Doing less and being focused is the entire productivity trick!

We'll use those four actions to limit the amount of work and gain as much free time as possible. After all, our goal is to be productive, not busy. Nobody wants to be an overworked underachiever, yet many find themselves in such a terrible position.

To become relaxed high-performers, we must apply Miroburn's productivity rule in the proper order. Let's start with elimination.

Eliminate

The problem with productivity hacks

Productivity doesn't mean having a packed schedule and a mile-long to-do list.

You can use the Pomodoro Technique, wake up at 5:30 am, start the day imitating the morning routine of billionaires, hit the gym at 6 am, run a half marathon before breakfast, eat one meal a day, spend half of the money on diet supplements recommended by biohackers, and still achieve nothing.

All of those things may or may not matter. The problem is that hacks don't make any difference if you spend the entire time efficiently doing low-value work.

Working 14 hours a day and finishing 40 tasks is a waste of time if someone else could do those things cheaper and better than you. However, we won't focus on delegating yet. What's even worse than working on stuff someone else could do is working on something that we shouldn't do at all.

Eliminating low-value work to focus on essential tasks

It seems we instinctively know we should focus on the important task. But what is an important task?

We tend to confuse urgency with importance. Even when we don't fall for the urgency bias, we focus our efforts on low-hanging fruits or the tasks having the loudest proponents. We get distracted by what we see on social media. All of the other tech companies build MLOps tools and work with blockchain! That must be important! Well, not all of them, only those followed by you and those who are vocal about their work. Second, are they earning money from real customers or draining the investor's pockets?

To focus on the right stuff, we must figure out what is important. How do we do it?

Finding the important tasks

I suggest making a map of dependencies between your tasks and ideas. It doesn't matter how you do it as long as you can spot the stuff on which everything else depends. You can draw a mind map or use the Mikado method to find the dependencies.

I remember one project when we forgot about eliminating needless tasks. We were building a content delivery software. It was a replacement of a service we were renting from another company, and we were supposed to launch on the day when the contract ends. Missing the deadline was not an option.

Somehow, we spend months redesigning the user interface, building a design system (Whatever it is. I'm a data engineer, so I have no clue), and implementing a self-service configuration mechanism. Were those things useful? Yes. Were those things important? Yes. Were they critical? Hell no.

During the 18 months of project development, we repeatedly ignored the need to display the content to the users. We still had the rented service, and according to the contract, we could not switch it off even for A/B testing of another solution. We focused on building attractive-looking features. We prioritized getting prised for the UI design during product demos and almost forgot about the one feature without which everything else would be useless.

During the last two weeks, we implemented the delivery service working long hours in a quite unpleasant and hectic work environment. In the end, we managed to finish everything a few days before the deadline. The developers were yelled at and worked on weekends to meet the deadline. The product owner who prioritized the wrong things went on a trip with the rest of the management team to celebrate the successful project—business as usual.

What could we do differently? Could we eliminate something? The old system was based on Excel files uploaded by our sales team. We could use those files instead of building a self-service application from scratch. We could refrain from making a design system for a B2B application. After all, does anyone care about the UI in a configuration manager? What we couldn't do, though, was ignore the content delivery.

That's the point. In every project, we must do some things no matter what. Everything else is extra. We can add those features later or never. I opt for eliminating the nonessential features at least from the initial plan. We can always add them later when we build the second version.

Eliminating the unimportant tasks - the only productivity hint you need

It is great to prioritize the critical tasks, but skipping the things you don't need at all is even more important. What can we cut?

Applying the ROI (return on investment) to everything you do is one of the best productivity tips you can learn. Sometimes doing the task is not worth the effort.

Let me show you an example. I have two blogs, speak at conferences, teach workshops, and have a side hustle as a content writer and MLOps evangelist. Would it make sense to me to be more active on Twitter? It is good to have many followers on social media, but is it worth the effort? I don't think so. I think of myself as a content creator, not an online talker.

It is more difficult to monetize a Twitter thread than to sell tickets to a programming workshop. It's a blunt statement and 100% true, and it helps to eliminate ideas with minimal business/career impact. Of course, a vast Twitter following helps you with your career (for example, when you are looking for a new job). However, you can get a similar career boost with an email list or a tech blog visited by thousands of people every day.

You can't do everything. Focus on the high-value work.

Simplify

We can eliminate the entire task. However, applying the ROI thinking to individual tasks can also eliminate the unnecessary parts of things we decide to do.

We won't need as many productivity hacks when we have less to do.

Done is better than perfect

Productive people know they can stop working before they create a perfect product. Working on multiple high-value tasks is better than wasting time trying to be the best in one area.

Of course, sometimes being the best is the entire point of the task, for example, when you train for a sport's competition. Finishing a marathon run is an outstanding achievement. However, there are thousands of finishers and only one winner. In such cases, perfection is the only way.

Nevertheless, most of the time, we don't need perfection (yet). Perfectionism is often an excuse to postpone showing your work to the world or to give up.

Productive people don't wait until the work is perfect. They save time by showing good enough work to their clients or audience. They may already finish the work because people are satisfied with the outcome. On the other hand, maybe nobody wants the product, so it makes no sense to continue working on it. It's better to know about it early.

Every time we work on a task, we should ask ourselves whether we can simplify it a little bit while still getting most of the desired outcome. Our goal is productivity, not being tired, overworked, and disappointed with our lives.

For example, I could hire three editors to review this text before publication. It would be expensive. It would take lots of time. But maybe... maybe! I could get 10% more views. Is it worth it? I don't know yet. I will edit the text twice or perhaps three times and publish it. In three months, I will see how many people read it and whether it makes sense to invest in making it even better. After all, I may get dozens of emails saying how much you hate this article. That's why I stop at the "good enough" stage. I can always go back and do more later, but I would never publish it if I waited until the text was perfect.

Automate

It should be easy for programmers. Yet, somehow we spend lots of time doing manual tasks which we could automate.

Templates

You don't need to write scripts! Often, all you need is an email template!

How many times per week do you get a LinkedIn message about a job offer you are not interested in? How many of those messages look like a copy-pasted text or something sent by a bot? What do you do? Do you ignore them? That's one option. Although, I think it is rude. Instead of ignoring the copy-pasted messages, I reply to every message. Is this a waste of time? No! No, because I have a template saying, "Thank you for your message. Currently, I am not interested in new job opportunities." That's it—a copy-pasted response to a copy-pasted message.

Don't overdo it. I still write a unique response to messages about jobs I am interested in now, or I may be interested in a few months or years. I still say that I am not interested right now, but I also give them a non-lame reason and the time when we can talk about it again.

Documenting processes

Templates are the most straightforward automation, but we can do better without writing code.

What if we have six steps to do every time something happens? What if I have to pack a backpack for travel to a three-day-long conference where I am a speaker? Should I think about what I need every time it happens, or can I have a process? Or a checklist. A checklist is the simplest kind of process!

Having a list of things you have to do before travel or something you must take with you is the easiest way to ensure everything gets done, especially when you have one hour left until you leave the house and try to recall what else must get done.

Prepare your checklist before you need it, and mark the tasks as done when you are getting prepared. It doesn't matter whether you print the list, keep it in a to-do app, or a text file. What matters is adding new things to the checklist every time you realize you have missed something and removing useless steps from the list.

Did you assume that every conference room has wifi, and it turned out you were wrong? Next time, you can either take an ethernet cable and hope you see the socket on the wall or buy a mobile router. You can also write an email to confront your expectation with reality before you arrive. Will you remember about it? Probably no, so add it to the checklist!

Real automation

The ultimate goal of automation is to don't do anything manually. You automated the process, and it is running on its own.

Get used to writing scripts! As programmers, we should be comfortable doing it. However, I see many developers who waste lots of time clicking around UI or copy-pasting commands into the command line.

You don't have to automate everything. I recommend automating only the steps required to get the job done and avoiding automating the decision process for as long as possible. I want you to understand why you are doing something before attempting any decision-making automation.

It doesn't matter whether you use software for automation or delegate the process to other people. In any case, from your perspective, the task got automated.

Delegate

If you think the only way to get something done well is to do it yourself, you will be a sad, overworked underachiever. You don't have to do everything yourself. You are not the best person for every task.

How do you think Mirosław Burnejko runs seven companies while spending half of the year on vacation? He sets things in motion and lets others do them according to his process.

You don't need to be a manager. You can do it too. You can do it even when we are individual contributors working in a team.

Are you the best person to do the task?
The first question you should ask yourself is whether you are the best person to get it done. Do it whenever someone assigns a new task to you or when you think you should do something new.

I'm getting a new website designed right now. I could do the entire UI myself. After all, I want something so simple that even a data engineer can create it. At the same time, I don't want to spend hours checking how my website works on mobile phones and figuring out what combination of colors looks good. That's why I paid someone to prepare an HTML template for me.

You can delegate tasks too. The first thing you have to do is figure out your hourly rate, or even better, your aspirational hourly rate. You can also follow the Naval Ravikant's advice and set an absurdly high rate. He chooses $5000/hour.

When you consider delegating, check whether getting it done will cost you less than your hourly rate. Of course, when making the decision, you compare the cost with the actual hourly rate. The aspirational one works best as your inspiration to spend your time getting better.

Delegating when you are not a manager

How can you delegate as an individual programmer? It gets tricky, but you can still do it.

First of all, don't think about it as a delegation. You will ask people to do you a favor and do favors for them. If you aren't a manager, that's the only way. I work like this with our DevOps team. Formally, I can't delegate anything to them. But I can ask whether they can do something for me, and I help as much as possible. Also, I make sure I don't ask them to do boring stuff. I want to be a person who asks them to help solve cool problems.

When you can't ask people for favors, you have to convince your manager to delegate to someone else. Can you convince them that another person can do the task better than you? You have to be careful here, though. If you do it too often, you will look like a slacker. On the other hand, if you get everything done, and occasionally you ask to get a task delegated to someone else, they will agree.

Eliminate, simplify, automate, delegate

In summation, to be more productive, we must do four things:

Eliminate low-leverage tasks.
Simplify the tasks you decided to do to get the highest possible outcome with minimal effort.
Build a process to save the time you spend making decisions. Additionally, you can use software to automate it.
Find someone else who can do those tasks for you (or keep using the software automation).

I put a carnivorous plant on the Internet of Things to save its life, and it did not survive

Bartosz Mikulski — Wed, 22 Jan 2020 20:38:30 +0000

This article is a text version of my talk, "I put a carnivorous plant on the Internet of Things," which I presented during the DataNatives conference (November 25-26, 2019 in Berlin, Germany). It was originally published on my blog: https://mikulskibartosz.name

It was Winter 1998; all the kids at my primary school were playing with a virtual pet simulation game called Tamagotchi. It was sort of like The Sims of the late 90s, but without beautiful graphics and music (it looked good at the time). Also, the interactions were limited. You could only feed and play with the animal. Somehow, that was enough to keep it alive.

The game put us in trouble at school because a player had to interact with it a few times a day, so teachers were not happy with that. Because we could not play so often, fake animals were constantly dying.

In 2019 I did not have a Tamagotchi anymore. To be honest, I did not even know that you can still buy them. Things have changed. Instead of a Tamagotchi, I have plants.

Not everything has changed because all of my plants keep dying just like the Tamagotchi animals. I think it is time to admit that I have a problem because all of my plants are dead.

Dead plants

Look at this one! I hoped that it wasn't dead. I was thinking that perhaps it was just preparing for the Winter. I was wrong. The Winter has passed, and the plant was still dead.

Venus Flytrap

At some point, I got a new plant. It was the coolest plant I ever had. I even gave it a name - my plant is called Zdzisław.

Zdzisław is a Venus Flytrap. It likes bugs and wants to be a software tester ;)

Things to do

It should be easy to keep such a plant alive. After all, the only thing it needs is sun and water. No, you don't have to feed them.

Often, I was forgetting about watering the plant, so I tried reminders — many of them. The problem was, I was never nearby the plant when I had seen the reminder on my phone, and there was always something more urgent to do.

Obviously, I concluded that there must be something wrong with plants! I never had such problems with animals. I mean, the real animals.

Real animals can communicate. My parent's dog makes noise when he wants something. It may not be the most human-friendly way of communicating, but it works.

I had to help Zdzisław communicate with humans!

What did I need?

For that project, I needed a few things.
First of all, a little bit of overengineering because there are dozens of methods to water a plant. Most of them don't require writing any code.

I also needed ignorance towards 10000 years of agriculture history because we, humans, know how to take care of plants. Humans, in general, know how to do it. I, personally, have no idea.

Last but not least, I needed some equipment that I would use for only one project.

Connecting to server

I started by connecting my Arduino to WiFi. Fortunately, there is a great library I could use, so all I needed was five lines of code and around 15 seconds of waiting time.

#include <WiFiNINA.h>

int status = WL_IDLE_STATUS;

while ( status != WL_CONNECTED) {
    status = WiFi.begin(ssid, pass);
    delay(5000);
}

To make the project at least a little bit interesting, I wanted to store the measurements "in the cloud." I quickly coded a small JavaScript REST API and deployed it on a free Heroku instance.

The first problem with sending anything to my API was the fact that REST client libraries for Arduino are not very popular. I found only a few of them, and I decided that I didn't want to use them.

Those libraries had only a few stars on GitHub and a couple of forks. I did not want to run such an untrusted code on my computer.

The solution was obvious. I implemented my own REST client. Luckily, I needed only one function supporting one HTTP method and one Content-Type, so I connected to the TCP port and started pretending to be a web browser.

String request = "POST " + resource + " HTTP/1.1";

if (tcpClient.connect(server, port)) {
    tcpClient.println(request);
    tcpClient.println("Host: " + String(server));
    tcpClient.println("User-Agent: curl/7.60.0");
    tcpClient.println("Accept: */*");
    tcpClient.print("Content-Length: ");
    tcpClient.println(content.length());
    tcpClient.println("Content-Type: application/x-www-form-urlencoded");
    tcpClient.println();
    tcpClient.println(content);
}

Using sensors

When I finished working on the client-server connection, I started reading data from my sensors. At that point, I realized that I made a big mistake.

I purchased the cheapest sensors I could find, so all my data looked like this:

I had no idea why it worked like that. At the time when I measured those values, the sensors were lying on my desk, and I wasn't even touching it.

There were two more problems with those sensors. What was the unit? What was the range of possible values? The manufacturer of the sensors somehow forgot to mention anything about it in the documentation.

Using the water pump

I realized that I didn't need to know anything about the measurement units. I needed to figure out when I should switch the water pump on.

It was a very disappointing moment of the project because at the beginning I thought that maybe I could use machine learning for that. In the end, I used an if statement with a constant value as the threshold.

float SOIL_HUMIDITY_THRESHOLD = 350;

if(soilHumidity < SOIL_HUMIDITY_THRESHOLD) {
    start_pump();
} else {
    stop_pump();
}

The last thing was plugging in the water pump. I could not connect it directly to Arduino because the pump needs a higher voltage. I had to connect it using a power relay between Arduino and the pump. As a consequence, Arduino controls only the relay, which works like a light switch.

#define ENGINE 7

void start_pump() {
  digitalWrite(ENGINE, LOW);
}

When everything was connected and worked correctly, I concluded that I could not use that monstrous device. It was too big, even without the water container.

The outcome

It did not matter. It was too late for Zdzisław. The plant was dead, again.
I think it may be time for Zdzisław 2.0. This time everything is going to be different! I mean, I will kill a different plant.

Why do I tell a story of a failed project? I do it because I want to show you that if you want to make your own IoT project, the only thing you need is an answer to one question:
If this thing could talk, what would it say?

If the plant could talk, would it tell me when I should water it?
If a chair could talk, would it let me know that I'm sitting for too long, and it is slowly killing me?

When you know the answer to that question, the only task left to do is making that thing talk.

10x software architecture: high cohesion

Bartosz Mikulski — Thu, 16 Jan 2020 16:44:58 +0000

This text was originally published on my blog: https://mikulskibartosz.name

A few months ago, it was fashionable to complain about the 10x developer myth. I agree that such people don’t exist, but, in my opinion, proper software architecture can transform every developer into a highly productive person.

When the code is structured in the right way, everyone can deliver features very fast, programmers don’t produce many bugs, and the ones they produce are isolated and don’t break multiple parts of the system.

We can distinguish between good and poor software architecture by comparing two crucial characteristics of code: cohesion and coupling.

In this article, I am going to discuss high cohesion. I will also show you some heuristics you can use to determine whether you reached the optimal cohesion of your software.

What is cohesion?

The Cambridge online English dictionary defines “cohesion” as “(of objects) the state of sticking together, or (of people) being in close agreement and working well together.”

How does it apply to software?

A highly cohesive software is code that serves only one purpose and minimalizes noise. That rule applies to pieces of code of any size (packages, modules, files, classes, functions, etc.).

Such a design allows us to construct a program as a sum of smaller programs that implement only one feature (business, technical, or whatever). Moreover, a highly cohesive code does not contain anything that is not related to the functionality it implements.

How to write a highly cohesive code?

Here is a list of things you should avoid if you don’t want to destroy your carefully crafted software architecture.

Shared code

Let’s look at the definition again. Does it mean that we can have a util module in our code? Anything that is called “common,” “shared,” “util,” or “global” is, by definition, not highly cohesive.

I have an extreme opinion about util modules. I think that you must never create them. It is way better to create a specialized module that contains only one method than to spoil your code with a “util.” I recommend thinking of “util” as a massive pile of garbage.

Everyone who cooks has that one “util” drawer in the kitchen. The one where you keep everything that did not fit anywhere else. Is it useful? Can you quickly find what you need? Sure, we have to keep that stuff somewhere, and there is no space in the kitchen to keep it separately. Fortunately, that is not a problem in code.

Organizing code by technical layers

Can we create a module that contains all controller or repository classes? At first glance, such things seem to support a single technical aspect (feature), so everything is fine.

However, when you look deeper into the code, the controllers quickly start supporting multiple business features.

It gets even worse when we call something a Service. How often do we see an UserService that has everything? It registers new users, changes passwords, reset passwords, updates the user’s profile, sends notifications to the user, sometimes it even makes reports.

What is the biggest problem? We quickly end up with a large file with dozens of methods that seem to be related to each other only because all of them get the userId as one of their parameters.

Where is the code that changes passwords? It is somewhere in the UserService. Why do we have the newsletter provider as one of the dependencies? There is one method that updates the newsletter subscription status.

Statuses

Do you have a status field in your objects that switches between multiple branches in a long chain of if/else statements? If yes, I am going to risk stating that you are trying to support numerous features by the same piece of code.

I am not saying that using statuses is wrong. What I am saying is that replacing a rich domain model with a simple “status” field leads to unmaintainable code.

Lack of language skills

Speaking of the rich domain model, can you create it if you don’t know the language used by the domain experts? If you are implementing features for an online shop, and the only English word you know is “order,” you will have to model everything using statuses.

Things like “sales proposal,” “offer,” “withdrawn offer,” “processed payment,” “delivered order” will not magically appear in the codebase if the developers don’t know that such words exist.

Try not to overkill it

There is a risk that if you are supposed to write a CRUD application, you may try to build a complex architecture just because you think you should do it or because you are tired of writing boring software. However, if you remember that cohesion is all about minimizing the noise, it should be evident that the goal is to create a minimal amount of code that does the job.

Four books to boost your programmer career in 2020 (including the one that made me quit my dream job)

Bartosz Mikulski — Mon, 06 Jan 2020 08:34:28 +0000

This text was originally published on my blog: https://mikulskibartosz.name

Here we are, we are at the beginning of a new year. The time when people reflect on what they had done during the past year. The time of year when we think about everything we want to do during the next twelve months. For those of us who love reading books, it is also the time when we plan our reading lists for the beginning year.

In this article, I am going to show you a few books that, I think, may boost your career in software development. Most of them are not about technology, but I will order them from the most technical to the least technical.

The effective engineer by Edmond Lau

Let's start with "The effective engineer" by Edmond Lau because it is the only one of the books I am going to describe today that is written for the programmers.

In this book, the author describes the concept of high-leverage activities. He recommends focusing on activities that produce the most significant long term value. Edmond Lau described 10 such activities and the process of choosing the most impactful of them.

"Focus on high-leverage activities. This is the single most valuable lesson that I've learned in my professional life. Don't confuse high-leverage activities with easy wins." — The effective engineer

The author suggests asking yourself the three questions every time you are supposed to work on a task:

How can I complete this activity in a shorter amount of time?
How can I increase the value produced by this activity?
Is there something else that I could spend my time on that would produce more value?

Some of the high-leverage activities Edmond Lau suggests are regular prioritization, optimizing for learning, and automation.

What hit me the most was the fact that Edmond Lau is writing about stuff that should be obvious to every one of us. It should be obvious, so why don't we do it every day?

How will it boost your career?

For me, "Effective Engineer" was almost like a "recipe book." You can directly apply Edmond Lau's advice to get immediate results. There may be some resistance if you are the only person doing it, and you don't get buy-in from the team, but perhaps the next book is going to help you with that.

The Psychology of Computer Programming by Gerald Marvin Weinberg

The second book is quite old. Its first edition was published in 1971. I was reading the Silver Anniversary Edition published in 1998, which contains additional comments written by the author 25 years after the publication of the first edition.

Why do I bother you with publication dates? That timeline is important because I was reading that book for the first time in 2015.
At that time, I was under the impression that things have not changed much since 1998, and Gerald Weinberg claimed that they have not changed much since 1971, either.

Obviously, technology has changed, but team dynamics, communication problems, dealing with ego, scheduling, and decision making does not differ a lot.

I won't' call this book a timeless classic. Still, it certainly gives us valuable insight into the history of programming and what people considered to be the essential skills of a programmer.

How would it boost your career?

It won't directly teach you anything, but that book makes you wonder what the most important part of your job is and what is going to be essential after the next 25 years.

On writing well by William Zinsser

Programmers are writers. Period. The ability to create a cohesive narration that follows the logical flow of events is as crucial in code as doing it while writing fiction or a newspaper article.

Learning to write well will make you a better programmer. Let me give you an example.

Terry Pratchett opened his book "Hogfather" with the following scene:

The senior wizard of Unseen University stood and looked at the door.

There was no doubt that whoever had shut it wanted it to stay shut. Dozens of nails secured it to the door frame. Planks had been nailed right across. And finally it had, up until this morning, been hidden by a bookcase that had been put in front of it.

What happens next? Does the wizard stand in front of the door talking about the soup he ate yesterday? Does the action move somewhere else, and the readers need to wait for 20 pages until they finally know what happens with the door?

Of course not! That would break the flow of events and surprise the reader. The scene continues with a dialog:

'And there's the sign, Ridcully,' said the Dean. 'You have read it, I assume. You know? The sign which says "Do not, under any circumstances, open the door"?
'Of course, I've read it,' said Ridcully. 'Why d'yer think I want it opened?'

Can we be sure that a programmer would write it similarly? Not necessarily. Often, when we read code, we have one question in mind: "Why is it here?"

"The code was in the middle of generating a PDF. But now it reaches to the database, gets some value, sends it to a REST API, and puts the response in a variable. That variable will not be used at all until it starts adding the last page to the PDF file."

Have you ever seen code that resembles that description? Would you like to read a book where the storyline looks like this?

How does it help you?

This book helps you write emails that are actually read by the recipients, bug reports that are not ignored, and compelling documentation.

But that is not the only benefit, because good writing skills are necessary to create code that can be maintained by other people.

If you learn it, things like the Single Responsibility Principle or DRY won't be arbitrary rules that you must blindly follow. Instead of that, you will realize that such practices are essential elements of well-crafted literature that also apply to programming.

Career Superpowers by James A. Whittaker

I recommend that book because it was an "eye-opening" book for me. It is a book that persuaded me to give up all my attempts to become a data scientist. After reading it, I quit the data science job and went back to data engineering and backend development.

James Whittaker made me realize that I could put a massive effort into the career shift and still not reach above the performance level of a mediocre data scientist.

He persuaded me to do it by writing a two-page long "Underachievement Manifesto" that made me think about my career choices:

This may seem harsh, but there is opportunity written all over it for those who aren't too blind with ambition to see it. The ranks of any fields, no matter how mundane or exciting, are full of people who have stretched to get there. People not quite smart enough for medicine still practice medicine. People not quite dedicated enough to law are still lawyers. People who aren't particularly mechanically minded still try to fix cars. This is why a good mechanic stands out, he or she is competing against people who aren't really good enough to be there. (...)

What I am proposing is that we be honest with ourselves and instead of stretching to be the dumbest person at the level above you, choose instead to be the smartest person at the level below you. (...)

One of these days we may live in a world where no one stretches too far; it would be a world where everyone was imminently qualified to do their job. No fakers, no pretenders, no one scratching to get by. Until that happens there is an opening for ordinary people to stand out when doing ordinary things.

What else is in that book? The author shares stories about events that affected his career and the lessons he learned. It may sound boring, but, in my opinion, James Whittaker is a world-class master of storytelling!

He writes about choosing the right niche for yourself, creating your elevator pitch, finding experts who can become your mentors, and "succeeding on purpose."

Be careful

Right now, I should tell you how this book helps you boost your career, but instead of that, I have to warn you.

James Whittaker's book is dangerous. If you read it and apply his advice to your life, you will be incapable of doing many mundane tasks.

No one in their right mind wants to do tedious work because it literally kills your career.

If you care about your career, you won't want to do "invisible tasks." It does not matter if you do an excellent job if the C-level management does not even know that you are doing it or does not care about it.

If you do what James is telling you to do, you will probably get the results you want and be happy with your career. If you read it and do nothing, this book will make you feel miserable.

6 things I learned while public speaking

Bartosz Mikulski — Tue, 22 Oct 2019 19:34:45 +0000

Next month, I will give a talk about my IoT side project at the DataNatives conference in Berlin, Germany.

It is not the first time I speak at a conference. In fact, this is going to be my fifth conference talk. In addition to that, I was a speaker at a few meetups.

While preparing for those few talks, I have learned a couple of things about public speaking. Obviously, there are billion of things I still have to learn, but maybe I can share something useful for the first-timers.

Introverts are the best speakers

Ok. I am an introvert, so this is a totally biased opinion. Nevertheless, I firmly believe that it is true. As an introvert, you must spend a lot of time preparing for the talk. You don't speak all the time. It is not something that comes easily to you.

The time introverts spend on preparation pays off, and their talks are usually interesting and informative.

On the other hand, extroverts seem to be able to wing the talk. They have some ideas about the topic and just keep talking for 45 minutes.

That is why being an introvert is not an excuse for avoiding public speaking. Overthinking before you say anything is not a problem during public speaking. You prepare everything in advance, so the only thing left to do while being on the stage is just saying what you want to say.

I'm not the only person who has such an opinion. Here is a talk by
Dr. Michelle Dickinson, "Public speaking for quiet people," I highly recommend watching it.

Tell us a story

People love stories. Everybody knows that, but not many speakers remember about it while preparing a talk.

You have to tell a story. It does not matter how cool your idea is if you can't tell a story about it.

It does not even need to be a true story, just make it sound like something that could really happen.

But please... please... don't inform us that you are going to tell us a story.

I remember the time when our scrum master wanted to make team demos a little bit better and taught us about storytelling. After that, almost every sprint demo began with a sentence: "Let me tell you a story," followed by a completely made-up story.

Don't say everything you know during one talk

What happens when a person gives a talk for the first time? They feel that it is the one and only opportunity to share their knowledge with the world. The one and only chance! They can't waste it. They must tell the audience everything they know. Everything!

There is one rule about conference talks: one talk = one idea.

You should focus on one topic because people are not going to remember more than one idea after your talk. You may have 60 minutes for your presentation, but the audience has around 3 minutes long attention span.

They will listen to you a couple of times for twenty seconds. After that, their brains will take a break and think about something different.

They won't remember everything you say, so you should focus on saying the same thing over and over again in slightly different ways. Our brains are naturally good at listening to stories, so if you tell a story, you get a couple of additional minutes of attention.

There is nothing you can do to make people focus on your talk for 60 minutes. Nothing. Just get used to that and make the best use of the few minutes of attention you have.

Three things

A presentation consists of three things: your slides, the things you say, and a handout you give them after the talk. In 2019, instead of the printed handout, we usually show a link to a blog post or GitHub repository.

Those are three different things. Don't read your slides, don't give them a link to the slides. The slides are there just to draw their attention. The slides should be useless without your commentary.

Everything you want them to remember should be written down and shared at the end of the talk. I write a blog post and share a link on Twitter after the talk, so everyone who wants can easily find the content.

Use the microphone

I made that mistake twice. My talk was in a small room, so I thought that I could just speak a little bit louder. The first time I tried it, it was not a bad idea. I was standing next to the audience and basically just having a conversation with them.

The second time I tried talking without the microphone, it was a disaster. A few people left the room while I was speaking. I was embarrassed.

I decided that I must practice using a handheld microphone and get comfortable doing it. Now, I don't have a problem with that at all.

I totally recommend practicing for a few hours if you are not sure how to hold the microphone correctly. When you are on the stage, it is not as easy as it looks like ;)

Listen to the experts

Just play this video and listen to their advice. Everything they say is pure gold.

DataNatives 2019

If you want to hear my next talk at DataNatives, I have a 50% discount code you can use while buying the tickets: DN19_BARTOSZ_MIKULSKI_50

How blogging helped me get my first data science job

Bartosz Mikulski — Thu, 17 Oct 2019 07:23:55 +0000

I wanted to become a data scientist since I learned that such a job exists. I knew it was perfect for me. Cutting-edge technology and data analytics, what can be better?

Learning

I wondered how I can learn the necessary skills. The obvious choice was video tutorials, so I started watching online courses. I have purchased around six courses on Udemy and two or three Coursera courses. I watched dozens of YouTube videos.

I felt in love with data science, but I had no idea how to become a data scientist. I sort of knew what I needed to learn, but I did not know how to start learning it for real.

I wanted to understand the topics, not only learn that they exist, and copy-paste some code. I started doing Kaggle challenges. It was not the perfect choice, either.

Let’s face reality, the majority of Kaggle solutions are just copy-pasted code from top 20 Kaggle notebooks. I could train myself to copy some code, but I had no clue whether it is the best possible code or why does it even work. It was not enough for me. I could not accept that.

Quickly, I realized that I may learn something in such a way, but I won’t be able to show it to anyone or use it in practice.

Gatekeepers

I needed to practice solving real-world problems. I tried to “do data science” at work. We already had a data team, and they were trying really hard to “squash the competition.”

I needed to find a different way. A way that could not be controlled by the manager of the data team. I had to look for an opportunity outside of that company.

The problem was the fact that I had no real-world experience. I needed not only to learn but also show people that I should be hired because I can get the job done.

Blogging

I started blogging. First, I was blogging about everything. I wrote articles about software craft, Scala libraries, book reviews, etc. I did write a few texts about data-related stuff, but only some easy ones. Obviously, that was not helping me reach my goal.

One day, I decided that enough is enough. I was wasting time at a job that did not allow me to grow my skills or even fully use the skills I already had. I had to change that.

I made a blogging schedule. I began blogging three times a week. I continued writing about the same topics, but I was doing it more often. It still wasn’t giving me the results I wanted, but I was learning to produce good content faster.

After four months, I limited the topics of my articles to data analytics and machine learning. Of course, I continued writing three articles every week. At that time, it wasn’t a huge effort anymore because of the time I invested in learning my writing skills.

Getting hired

Three months later, a strange thing had happened. I sent CVs to two companies looking for data scientists. I was invited to both interviews, and… they did not ask me any technical questions. They mentioned that they had read my blog, and we talked only about the culture of their organizations.

I was surprised because I had still remembered the interviews from the past, during which I had been grilled for six hours by multiple interviewed who had tried to prove that I had not known anything.

This time, it was different. I did not need to show my technical skills during the interview. I was hired by one of those companies. Finally, I was a data scientist.

I have finally reached the goal, and I was happy. I was coming to work every day and doing something challenging. I was training machine learning models, doing data analysis, and spending most of the day reading research papers.

Was data science good for me?

It wasn’t perfect for long. Soon, I realized that something was missing. It was difficult to admit, but I learned that being a data scientist is not the perfect career path.

I missed software engineering. I missed talking about software architecture and focusing on software craft.

I wanted to be a data scientist, but I also wanted to do sophisticated software engineering. I needed to make a change in my career once again.

Next move

I sent my CV to one other company. I went to an interview. One week after sending the CV, I was hired by a company that is often described as the best workplace in the city where I currently live (Poznan, Poland). It was awesome!

Now, I’m a data engineer. It’s perfect for me. I can train machine learning models, build ETL pipelines, write complex software, care about code quality, and plan the architecture of my software.

How did it happen?

I firmly believe that none of that would happen if I did not start blogging regularly. Blogging not only helped me to learn a lot but also allowed me to show to other people what I am capable of doing.

It also helped me stop wasting time learning things that may be useful in the future. Now, when I learn something like that, I write an article about it.

I know that if I learn it and don’t use it, I will forget everything, so I use the blog also as a way to store notes and easily recall the things I used to know.

I know that my story about blogging may look like something requiring a massive investment of time. It is not like that. If I started blogging regularly earlier, I wouldn’t need to write three times a week.

I believe that you can achieve the same results by blogging once a week, every week for a year. For sure, it will take some time. I think that six months is the minimal amount of time you need to build a successful blog that boosts your career.

I think that the biggest problem of aspiring data scientists is standing out of the crowd. Everyone does Kaggle challenges, everyone has a blog and writes articles. Clearly, you need to do something differently.

I think that what makes the most significant difference is demonstrating work ethics and commitment. It is easy to have a blog and post one text a year. If you can regularly produce good quality content, you are no longer part of the wannabes. Instead of that, you become one of the people who know what they are doing and are available for hire.

Free Blogging Course for Aspiring Data Scientists

I have created a free blogging course for aspiring data scientists. If you subscribe to the course, I will send you a lesson every week. During the first month, I am going to show you how to choose the topics of your articles, how to set up your blog quickly, what kind of articles you should write, and how to write them quickly.

Later, I will teach you also where you can effortlessly find ideas for new texts, how to promote your content in social media, how to become a better writer, how you can get more readers without buying ads, and how you can earn money while blogging.

You can subscribe to the course here: https://www.mikulskibartosz.name/how-i-become-data-scientist#blogging_course

An efficient daily scrum meeting

Bartosz Mikulski — Wed, 03 Jul 2019 17:06:53 +0000

What happens during a typical, dysfunctional daily scrum meeting?
Most likely, a bunch of people stands in front of one computer and look at Jira. They also update the task statuses because they were too busy to do it before the meeting.

Every one of them tells what they have done the day before. They say what they would like to do today. Often times, the words they say are "I will do the next task from Jira." Probably nobody dares to mention any problems.

They are not talking to each other. There is someone else in the room. The local demigod with the power to reward for obedience and punish for misconduct. Usually, it is a project manager or product owner. The team looks at her/him and turns the "daily stand-up comedy meeting" into a status report.

At least they are standing. Clearly, standing up is the most crucial part of a daily scrum meeting. Nobody complains about side comments, interrupting, not listening to colleagues, but don't ever try to sit down during the meeting! They will eat you alive!

What happens when the meeting ends? The team meets again because they have to plan the upcoming day. What have they been doing during the last 15 minutes?!

Daily planning meeting

Can we do better? I have a suggestion. First of all, change the name of the meeting. Seriously. I know it is just a name, but words have meaning, and the name influences the attitude you are going to have during the meeting.

It is not a stand-up meeting. Nobody cares if you stand, sit, walk, or jump. If you call it "stand-up," standing up will be the only thing you care about and do correctly.

Instead of that, I propose renaming it to "daily planning meeting." I think it clearly conveys the goal. After all, we are supposed to plan the day.

The meeting itself has to change too. We don't need the (in)famous three questions. Let's start with the first one.

What I did yesterday?

Don't tell us what you did yesterday!

I like to believe that I work with trustworthy adults. This means that if people tell me that they are going to do something, I will assume that they have done it. It also means that if they have any problems with finishing the task, they will notify everybody, so we can deal with it together.

Do I have any problems/blockers?

I don't understand why people answer that question at the end of the meeting (or forget to do it at all). This is the most important one!

If there is a problem, the plan of the whole team may change. It makes no sense first to make a plan and then ask if there is anything more important or something stopping us from achieving the goal. You will need to re-plan the whole day!

That is why talking about the problems should be the first thing we do during the daily planning meeting. If anything is stopping the team from achieving the sprint goal, it should be announced as soon as possible.

What am I going to do today?

After discussing the problems, we can finally plan the upcoming day.

There is one change I want to suggest in this part too. Let's talk only about tasks that contribute to achieving the sprint goal.

One goal

I assume that the team has only one sprint goal. (no cheating! If there is a conjunction in the sprint goal, you have more than one!) I also hope that everyone on the team works on tasks related to that one common goal.

Honestly, I think that if you have multiple goals or some team members work on side-goals, you no longer have a team.

A team without a common goal is just a group of people who happen to be in the same room, use the same Jira, push code to the same repository, and track their work time in the same spreadsheet but don't need to cooperate with each other. Maybe they should attend separate daily planning meetings?

Nothing more

That is all. Looks simple, doesn't it? Change the name. Forget about one question. Reverse the order of the remaining questions. Nothing more.

Looks like a small change, but that small change may help you focus on the critical aspect of your job: achieving the sprint goal.

You are here to get the job done, not to waste time in pointless meetings.

How to connect Arduino UNO Wifi Rev.2 to WiFi

Bartosz Mikulski — Tue, 21 May 2019 17:08:44 +0000

Installation

When you connect the board for the first time to the USB port, the IDE should detect it and install the required drivers.

When you have the drivers installed, make sure that you choose the proper type of Arduino.

You should select the following settings in the Tools window.

Now, you should go to the Tools -> Manage libraries window and install the WiFiNINA library:

Connecting to WiFi

Now, you are ready to copy the example code from https://www.arduino.cc/en/Tutorial/WiFiNINAWiFiPing

Before you run it, click the arrow button in the top right corner and choose the "New Tab" option.

We need to create an arduino_secrets.h file which contains the following code:

#define SECRET_SSID "YOUR_NETWORK_SSID"
#define SECRET_PASS "YOUR_NETWORK_PASSWORD"

Save the file and return to the file which contains the code copied from the example.

Make sure that your Arduino is connected to the USB port and click the Upload button.

Testing

Click the Tools menu and open the "Serial monitor" window.
You should see something like this:

If you see a similar result, it means that everything works fine.
Now, you can start removing the redundant code from the example and adding your code.

Just make sure to keep this part of the setup and your arduino_secrets.h file:

#include "arduino_secrets.h" 
char ssid[] = SECRET_SSID;
char pass[] = SECRET_PASS;
int status = WL_IDLE_STATUS;

void setup() {
  while ( status != WL_CONNECTED) {
    status = WiFi.begin(ssid, pass);
    delay(5000);
  }

# your code here
}

Turning greenfield projects into brownfields projects

Bartosz Mikulski — Sat, 04 May 2019 14:42:01 +0000

We all know that there is nothing better than a greenfield project.
What happens when we begin a new project?
There is hope. There are big dreams and new ideas. Now, it is our time! Now, we can write the best code the company has ever seen! Now, we can prove that it is possible to finish a project three months before the deadline!

What does the project look like after six months? Are we still so enthusiastic? Is everything still brand new and cool? It is not a greenfield project anymore, is it? The bad stuff is not everywhere, but there are places we don’t want to touch. There is code we don’t talk about. What happened?

Bad code is created in the same way as good code, one line at a time.
What makes the difference?

Software architecture

What happened to software architecture? Somehow, we began to pretend we no longer need it. The architecture is not cool anymore.
Nowadays, when someone mentions software architecture, people think of ugly UML diagrams produced by the architects.
The architects, the people we hate. The ones who are sitting in their ivory towers. The ones who don’t code anymore.
We don’t want to be like them. We don’t do “software architecture.”

Obviously, we don’t do it for the right reasons. We are agile. There is no place for software architecture in Agile. Yeah, sure… and don’t get me started on data model design.

The fact is, we always have some architecture. If we don’t produce it deliberately, it will be the result of our random decisions.

We don’t need the cumbersome process of creating UML diagrams. We don’t need oversight of an architect. All we need is one piece of paper and a pen.

We can design the architecture of our software on a napkin while eating lunch. If we don’t like the outcome, we will just throw it away and start over. It is much easier to change the decision when we need to throw away only one piece of paper. Changing our mind gets tough when we need to remove 60% of the code.

Is randomly produced architecture the only problem? We should plan the architecture before starting implementing the code to define our intentions clearly. We must know how the code is going to look like and how it will behave before we write a new line of the production code. Architecture is not enough. We also need tests.

Test driven development

The second problem which turns beautiful greenfield projects into monstrous brownfield nightmare is “upside-down testing.”

Many programmers write tests only because they are expected to do it. They don’t believe in automatic testing. Because of that, the tests are produced after the implementation (check out my blog post about the 4 reasons why TDD slows you down.

How often do we hear: “I have finished this task. Now I only need to write tests, and we can close the ticket.”? Every time we listen to such a statement, we know that the outcome is going to be huge. The production code will be complicated and have double-digit cyclomatic complexity. In the test code, we will see many, many mocks, but there are going to be surprisingly few test function. Just one or two tests that verify everything.

It is not possible to produce such ugly code while practicing TDD. Seriously. Try it, I dare you. Follow the “red-green-refactor” procedure and write a function which has 14 mocked dependencies. You can’t do it. Writing such a terrible code will physically hurt you. Just as much as looking at it hurts.

The enemies of TDD claim that it is just a toy practice. It is suitable for some programming kata exercises, but there no place for it in the “real world.” I used to believe in that too. During one project, I saw that if we “trust the process,” all of our code starts to look like the outcome of a sequence of small, easy programming katas.

I know that someone is going to claim that writing any tests (unit tests, integration tests, use case tests) in any way (TDD, test-first, test-last, test-when-I-have-time-for-that, etc.) is not enough to avoid all errors, so why bother? Well, condoms are not 100% fault-proof either, but people use them anyway, don't we?

Refactoring

What word do we say when we want to terrify a project manager? Refactoring. It scares them because they know that we can’t do it without stopping the world. They know that we may clean up some code, but we will also produce a few more bugs.

How is that even possible? Refactoring is supposed to change the code structure without changing its behavior. We have tests, we can run them after every change and verify whether we have a bug or not.

There are two problems with this assumption. First of all, we don’t trust our tests. We wrote them after the production code was created. We know that there are some untested paths.

The second reason is the fact that we must change our production code and our test code at the same time. There is no other option. We wrote the tests when the production code was ready. We needed to fiddle with them to make them pass. Our test code is coupled with the implementation details of the production code.

That would not happen if we followed TDD. Our production code should behave like a plugin for our tests. We should be able to change the plugin. As long as the new implementation acts as expected, the tests will still pass. If we achieve such level of decoupling, we can refactor the production code any time we want and still be sure that the behavior of the whole application does not change.

// Detect dark theme var iframe = document.getElementById('tweet-1058086271011209218-909'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1058086271011209218&theme=dark" }

Do we care about the tests or are they only the necessary evil? Do we review the tests during code reviews? How many times do we scroll through the tests while reviewing the pull requests?

When we don’t follow TDD, tests become a second-class citizen. That should never happen. In the test, we can not only define the expected behavior but also describe the API we want to have. The tests show us how the code is going to be used. If we follow TDD practices, code design happens while writing tests, not when we implement production code.

Ownership

The next problem is the lack of ownership. Who should fix a problem? The person who found it? The person who was the last contributor to the broken project? The person who is affected the most by the problem?

It may be easy to decide when we are talking about a bug. What if the code quality is the problem? What happens when we see a 1000 lines long file, and we have just added another line to it? We found the problem. We are the last contributor to the file. We were affected by the problem. It wasn’t easy to find the right place for the new line of code, was it?

Do we fix the problem? Do we ignore the problem and justify our decision by saying that there were n lines of code, we added the n+1'th line, it is not our problem? The mess was already there. We may even complain about it and do nothing else.

The minor offense of adding a new line of code to already messed up file gets repeated by another person, and another, and another. Two weeks later we have 1000 lines of code.

If you need some tips about ownership in software engineering, check out my article: Extreme ownership and software engineering

Teammates

That observation leads us to the last problem. Who turns greenfield projects into brownfield monsters? People.

We can complain about teammates who don’t want to learn anything new. We may whine that some of them work 2 hours a day and for the next 6 hours only pretend to work. We may scream every time we see copy/pasted code. We may do many other things, but none of them is going to change anything.

We can’t change people. We can’t persuade them to do something they don’t want to do.
The only way to influence others is leading by example because the only person you can change is you. You are the only person who can stop an awesome project from turning into mud.

This text has been reposted from my personal blog: https://mikulskibartosz.name/turning-greenfield-projects-into-brownfields-projects-5028a2c90c