The Nonconformist

On reclaiming the lost art of long-form prose

Mon, 24 Apr 2023 11:57:14 +0000

Whatever happened to long-form prose? In this era of social media, where status updates and 140-character tweets dominate our attention spans, the art of writing at length seems to be fading into obscurity. It’s a trend that’s been happening for years, as brevity has become the preferred mode of communication in the digital age.

In a world where we are constantly bombarded with information and distractions, it’s no wonder that we have little time or patience for long-form writing. We have become accustomed to quick and easy information, and the idea of sitting down to read a novel or a lengthy essay can seem daunting.

But in our rush to consume information in bite-sized pieces, we are losing something important. We are losing the ability to immerse ourselves in a story, to become fully invested in a character’s journey, or to explore complex ideas in depth.

Long-form prose is a romantic art, one that requires time and patience. It invites us to slow down, to take a deep breath, and to savor the words on the page. But in our fast-paced world, we have no time to stand and stare.

We have become so accustomed to scrolling through our feeds, skimming headlines, and clicking on links, that we have forgotten how to appreciate the power of language. We have forgotten how to get lost in a book or an essay, to be transported to another time or place, or to see the world through someone else’s eyes.

It’s time to reclaim the art of long-form prose. It’s time to embrace the power of language and to appreciate the beauty of a well-crafted sentence. Let’s slow down, take a deep breath, and immerse ourselves in the written word. Let’s rediscover the romance of long-form writing and remember what it means to truly engage with a piece of literature.

Writing cleaner code in Laravel

Fri, 26 Jun 2020 08:45:11 +0000

I recently came across this Twitter thread, where @samuelstancl listed tips for writing cleaner code in Laravel, as well as some general Laravel coding advice. These are a great starting point to develop a sense for what’s good code and what’s bad code - so I collated them below (with code samples), in no particular order.

It’s about the micro

Using some “macro” philosophy for structuring your code, like hexagonal architecture or DDD won’t save you. A clean codebase is the result of constant good decisions at the micro level.

Use lookup tables

Instead of writing repetitive else if statements, use an array to look up the wanted value based on the key you have. The code will be cleaner & more readable and you will see understandable exceptions if something goes wrong. No half-passing edge cases.

// Bad
if ($order->product->option->type === 'pdf') {
    $type = 'book';
} else if ($order->product->option->type === 'epub') {
    $type = 'book';
} else if ($order->product->option->type === 'license') {
    $type = 'license';
} else if ($order->product->option->type === 'artwork') {
    $type = 'creative';
} else if $order->product->option->type === 'song') {
    $type = 'creative';
} else if ($order->product->option->type === 'physical') {
    $type = 'physical';
}

if ($type === 'book') {
    $downloadable = true;
} else if ($type === 'license') {
    $downloadable = true;
} else if $type === 'creative') {
    $downloadable = true;
} else if ($type === 'physical') {
    $downloadable = false;
}

// Good
$type = [
    'pdf'      => 'book',
    'epub'     => 'book',
    'license'  => 'license',
    'artwork'  => 'creative',
    'song'     => 'creative',
    'physical' => 'physical',
][$order->product->option->type];

$downloadable = [
    'book'     => true,
    'license'  => true,
    'creative' => true,
    'physical' => false,
][$type];

Return early

Try to avoid unnecessary nesting by returning a value early. Too much nesting & else statements tend to make code harder to read.

// Bad
if ($notificationSent) {
  $notify = false;
} else if ($isActive) {
  if ($total > 100) {
    $notify = true;
  } else {
    $notify = false;
  } else {
    if ($canceled) {
      $notify = true;
    } else {
      $notify = false;
    }
  }
}

return $notify;

// Good
if ($notificationSent) {
  return false;
}

if ($isActive && $total > 100) {
  return true;
}

if (! $isActive && $canceled) {
  return true;
}

return false;

Split lines correctly

Don’t split lines at random places, but don’t make them too long either. Opening an array with [ and indenting the values tends to work well. Same with long function parameter values. Other good places to split lines are chained calls and closures.

// Bad
// No line split
return $this->request->session()->get($this->config->get('analytics.campaign_session_key'));

// Meaningless line split
return $this->request
  ->session()->get($this->config->get('analytics.campaign_session_key'));

// Good
return $this->request->session()->get(
  $this->config->get('analytics.campaign_session_key')
);

// Closure
new EventCollection($this->events->map(function (Event $event) {
  return new Entries\Event($event->code, $event->pivot->data);
}));

// Array
$this->validate($request, [
  'code' => 'string|required',
  'name' => 'string|required',
]);

Don’t create useless variables

Don’t create variables when you can just pass the value directly.

// Bad
public function create()
{
  $data = [
    'resource' => 'campaign',
    'generatedCode' => Str::random(8),
  ];

  return $this->inertia('Resource/Create', $data);
}

// Good
public function create()
{
  return $this->inertia('Resource/Create', [
    'resource'      => 'campaign',
    'generatedCode' => Str::random(8),
  ]);
}

Create variables when they improve readability

The opposite of the previous tip. Sometimes the value comes from a complex call and as such, creating a variable improves readability & removes the need for a comment. Remember that context matters & your end goal is readability.

// Bad
Visit::create([
  'url' => $visit->url,
  'referer' => $visit->referer,
  'user_id' => $visit->userId,
  'ip' => $visit->ip,
  'timestamp' => $visit->timestamp,
])->conversion_goals()->attach($conversionData);

// Good
$visit = Visit::create([
  'url'       => $visit->url,
  'referer'   => $visit->referer,
  'user_id'   => $visit->userId,
  'ip'        => $visit->ip,
  'timestamp' => $visit->timestamp,
]);

$visit->conversion_goals()->attach($conversionData);

Create model methods for business logic

Your controllers should be simple. They should say things like “create invoice for order”. They shouldn’t be concerned with the details of how your database is structured. Leave that to the model.

// Bad
// Create invoice for order
DB::transaction(function () use ($order) {
  Sinvoice = $order->invoice()->create();

  $order—>pushStatus(new AwaitingShipping);

  return $invoice;
});

// Good
$order->createInvoice();

Create action classes

Let’s expand on the previous example. Sometimes, creating a class for a single action can clean things up. Models should encapsulate the business logic related to them, but they shouldn’t be too big.

// Bad
public function createInvoice(): Invoice
{
  if ($this->invoice()->exists()) {
    throw new OrderAlreadyHasAnInvoice('Order already has an invoice.');
  }

  return DB::transaction(function () use ($order) {
    $invoice = $order->invoice()->create();

    $order->pushStatus(new AwaitingShipping);

    return $invoice;
  });
}

// Good
// Order model
public function createInvoice(): Invoice {
  if ($this->invoice()->exists()) {
    throw new OrderAlreadyHasAnInvoice('Order already has an invoice.');
  }

  return app(CreateInvoiceForOrder::class)($this);
}

// Action class
class CreatelnvoiceForOrder
{
  public function _invoke(Order $order): Invoice
  {
    return DB::transaction(function () use ($order) {
      $invoice = $order->invoice()->create();

      $order->pushStatus(new AwaitingShipping);

      return $invoice;
    });
  }
}

Consider form requests

Consider using form requests. They’re a great place to hide complex validation logic. But beware of exactly that — hiding things. When your validation logic is simple, there’s nothing wrong with doing it in the controller. Moving it to a form request makes it less explicit.

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
  return [
    'title' => 'required|unique:posts|max:255',
    'body'  => 'required',
  ];
}

Use events

Consider offloading some logic from controllers to events. For example, when creating models. The benefit is that creating these models will work the same everywhere (controllers, jobs, …) and the controller has one less worry about the details of the DB schema.

// Bad
// Only works in this place & concerns it with
// details that the model should care about.
if (! isset($data['name'])) {
  $data['name'] = $data['code'];
}

$conversion = Conversion::create($data);

// Good
$conversion = Conversion::create($data);

// Model
class ConversionGoal extends Model
{
  public static function booted()
  {
    static::creating(function (self $model) {
      $model->name ??= $model->code;
    });
  }
}

Extract methods

If some method is too long or complex, and it’s hard to understand what exactly is happening, split the logic into multiple methods.

public function handle(Request $request, Closure $next)
{
  // We extracted 3 tong methods into separate methods.
  $this->trackVisitor();
  $this->trackCampaign();
  $this->trackTrafficSource($request);

  $response = $next($request);

  $this->analytics->log($request);

  return $response;
}

Create helper functions

If you repeat some code a lot, consider if extracting it to a helper function would make the code cleaner.

// app/helpers.php, autoloaded in composer.json
function money(int $amount, string $currency = null): Money
{
  return new Money($amount, $currency ?? config('shop.base_currency'));
}

function html2text($html = ''): string
{
  return str_replace('&nbsp;', ' ', strip_tags($html));
}

Avoid helper classes

Sometimes people put helpers into a class. Beware, it can get messy. This is a class with only static methods used as helper functions. It’s usually better to put these methods into classes with related logic or just keep them as global functions.

// Bad
class Helper
{
  public function convertCurrency(Money $money, string $currency): self
  {
    $currencyConfig = config("shop.currencies.$currency");
    $decimalDiff = ...

    return new static(
      (int) round($money->baseValue() * $currencyConfig[value] * 10**$decimalDiff, 0),
      $currency
    );
  }
}

// Usage
use App\Helper;
Helper::convertCurrency($total, 'EUR');

// Good
class Money
{
  // the other money/currency logic

  public function convertTo(string $currency): self
  {
    $currencyConfig = config("shop.currencies.$currency");
    $decimalDiff = ...

    return new static(
      (int) round($this->baseValue() * $currencyConfig[value * 10**$decimalDiff, 0),
      $currency
    );
  }
}

// Usage
$EURtotal = $total->convertTo('EUR');

Dedicate a weekend towards learning proper OOP

Know the difference between static/instance methods & variables and private/protected/public visibility. Also learn how Laravel uses magic methods. You don’t need this as a beginner, but as your code grows, it’s crucial.

Don’t just write procedural code in classes

This ties the previous tweet with the other tips here. OOP exists to make your code more readable, use it. Don’t just write 400 line long procedural code in controller actions.

Read up on things like SRP & follow them to reasonable extent

Avoid having classes that deal with many unrelated things. But, for the love of god, don’t create a class for every single thing. You’re trying to write clean code. You’re not trying to please the separation gods.

Avoid too many parameters in functions

When you see a function with a huge amount of parameters, it can mean:

The function has too many responsibilities. Separate.
The responsibilities are fine, but you should refactor the long signature.

Below are two tactics for the fixing second case.

Use Data Transfer Objects (DTOs)

Rather than passing a huge amount of arguments in a specific order, consider creating an object with properties to store this data. Bonus points if you can find that some behavior can be moved into to this object.

// Bad
public function log($url, $route_name, $route_data, $campaign_code, $traffic_source, $referer, $user_id, $visitor_id, $ip, $timestamp)
{
  // ...
}

// Good
public function log(Visit $visit)
{
  // ...
}

class Visit
{
  public string $url;
  public ?string $routeName;
  public array $routeData;

  public ?string $campaign;
  public array $trafficSource[];

  public ?string $referer;
  public ?string $userId;
  public string $visitorId;
  public ?string $ip;

  public Carbon $timestamp;

  // ...
}

Create fluent objects

You can also create objects with fluent APIs. Gradually add data by with separate calls, and only require the absolute minimum in the constructor. Each method will return $this, so you can stop at any call.

Visit::make($url, $routeName, $routeData)
  ->withCampaign($campaign)
  ->withTrafficSource($trafficSource)
  ->withReferer($referer)
  // ... etc

Use custom collections

Creating custom collections can be a great way to achieve more expressive syntax. Consider this example with order totals.

// Bad
$total = $order->products->sum(function (OrderProduct $product) {
  return $product->price * $product->quantity * (1 + $product->vat_rate);
});

// Good
$order->products->total();

class OrderProductCollection extends Collection
{
  public function total()
  {
    $this->sum(function (OrderProduct $product) {
      return $product->price * $product->quantity * (1 + $product->vat_rate);
    });
  }
}

Don’t use abbreviations

Don’t think that long variable/method names are wrong. They’re not. They’re expressive. Better to call a longer method than a short one and check the docblock to understand what it does. Same with variables. Don’t use nonsense 3-letters abbreviations.

// Bad
$ord = Order::create($data);

// ...

$ord->notify();

// Good
$order = Order::create($data);

// ...

$order->sendCreatedNotification();

Try to only use CRUD actions

If you can, only use the 7 CRUD actions in your controllers. Often even fewer. Don’t create controllers with 20 methods. More shorter controllers is better.

Use expressive names for methods

Rather than thinking “what can this object do”, think about “what can be done with this object”. Exceptions apply, such as with action classes, but this is a good rule of thumb.

// Bad
$gardener->water($plant);

$orderManager->lock($order);

// Good
$plant->water();

$order->lock();

Create single-use traits

Adding methods to classes where they belong is cleaner than creating action classes for everything, but it can make the classes grow big. Consider using traits. They’re meant primarily for code reuse, but there’s nothing wrong with single-use traits.

class Order extends Model
{
  use HasStatuses;

  // ...
}

trait HasStatuses
{
  public static function bootHasStatuses() { ... }
  public static $statusMap = [ ... ];
  public static $paymentStatusMap = [ ... ];
  public static function getStatusId($status) { ... }
  public static function getPaymentStatusId($status): string { ... }
  public function statuses() { ... }
  public function payment_statuses() { ... }
  public function getStatusAttribute(): OrderStatusModel { ... }
  public function getPaymentStatusAttribute(): OrderPaymentStatus { ... }
  public function pushStatus($status, string $message = null, bool $notification = null) { ... }
  public function pushPaymentStatus($status, string $note = null) { ... }
  public function status(): OrderStatus { ... }
  public function paymentStatus(): PaymentStatus { ... }
}

Create single-use Blade includes

Similar to single-use traits. This tactic is great when you have a very long template and you want to make it more manageable. There’s nothing wrong with @include-ing headers and footers in layouts, or things like complex forms in page views.

Import namespaces instead of using aliases

Sometimes you may have multiple classes with the same name. Rather than importing them with an alias, import the namespaces.

// Bad
use App\Types\Entries\Visit as VisitEntry;
use App\Storage\Database\Models\Visit as VisitModel;

class DatabaseStorage
{
  public function log(VisitEntry $visit)
  {
    $visitModel = VisitModel::create([
      // ...
    ]);
  }
}

// Good
use App\Types\Entries;
use App\Storage\Database\Models;

class DatabaseStorage
{
  public function log(Entries\Visit $visit)
  {
    $visitModel = Models\Visit::create([
      // ...
    ]);
  }
}

Create query scopes for complex where()s

Rather than writing complex where() clauses, create query scopes with expressive names. This will make your e.g. controllers have to know less about the database structure and your code will be cleaner.

// Bad
Order::whereHas('status', function ($status) {
  return true$status->where('canceled', true);
})->get();

// Good
Order::whereCanceled()->get();

class Order extends Model
{
  public function scopeWhereCanceled(Builder $query)
  {
    return $query>whereHas('status', function ($status) {
      return $status->where('canceled', true);
    });
  }
}

Don’t use model methods to retrieve data

If you want to retrieve some data from a model, create an accessor. Keep methods for things that change the model in some way.

// Bad
$user->gravatarUrl();

class User extends Authenticable
{
  // ...

  public function gravatarUrl()
  {
    return "https://www.gravatar.com/avatar/" . md5(strtolower(trim($this->email)));
  }
}

// Good
Suser->gravatar_url;

class User extends Authenticable
{
  // ...

  public function getGravatarUrlAttribute()
  {
    return "https://www.gravatar.com/avatar/" . md5(strtolower(trim($this->email)));
  }
}

Use custom config files

You can store things like “results per page” in config files. Don’t add them to the app config file though. Create your own. e.g. In an e-commerce project, you can use config/shop.php.

// config/shop.php
return [
  'vat rates' => [
    0.21,
    0.15,
    0.10,
    0.0,
  ],
  'fee_vat_rate' => 0.21,

  'image_sizes' => [
    'base' => 500, // detail
    't1'   => 250, // index
    't2'   => 50,  // search
  ],
];

Don’t use a controller namespace

Instead of writing controller actions like PostController@index, use the callable array syntax [PostController::class, 'index']. You will be able to navigate to the class by clicking PostController.

// Bad
Route::get('/posts', 'PostController@index');

// Good
Route::get('/posts', [PostController::class, 'index']);

Consider single-action controllers

If you have a complex route action, consider moving it to a separate controller. For OrderController::create, you’d create CreateOrderController. Another solution is to move that logic to an action class — do what works best in your case.

// We use class syntax from the tip above.
Route::post('/orders/', CreateOrderController::class);

class CreateOrderController
{
  public function _invoke(Request $request)
  {
    // ...
  }
}

Be friends with your IDE

Install extensions, write annotations, use typehints. Your IDE will help you with getting your code working correctly, which lets you spend more energy on writing code that’s also readable.

$products = Product::with('options')->cursor();

foreach ($products as $product) {
  /** @var Product $product */
  if ($product->options->isEmpty()) {
    // ...
  }
}

///////////////////////////

foreach (Order::whereDoesntHave('invoice')->whereIn('id', $orders->pluck('id'))->get() as $order) {
  /** @var Order $order */
  $order->createInvoice();

  // ...
}

///////////////////////////

$productImage
  ->help('Max 2 MB')
  ->store(function (NovaRequest $request, ProductModel $product) {
    /** @var UploadedFile $image */
    $image = $request->image;

    // ...
  });

Use short operators

PHP has many great operators that can replace ugly if checks. Memorize them.

// Bad
// truthy test
if (! $foo) {
  $foo = 'bar';
}

// null test
if (is_null($foo)) {
  $foo = 'bar';
}

// isset test
if (! isset($foo)) {
  $foo = 'bar';
}

// Good
// truthy test
$foo = $foo ?: 'bar';

// null test
$foo = $foo ?? 'bar';
// PHP 7.4
$foo ??= 'bar';

// isset test
$foo = $foo ?? 'bar';
// PHP 7.4
$foo ??= 'bar';

Decide if you like spaces around operators

Above you can see that I use space between ! and the value I’m negating. I like this, because it makes it clear that the value is being negated. I do the same around dots. Decide if you like it. It can (imo) clean up your code.

Helpers instead of facades

Consider using helpers instead of facades. They can clean things up. This is largely a matter of personal preference, but calling a global function instead of having to import a class and statically call a method feels nicer to me. Bonus points for session('key') syntax.

// Bad
Cache::get('foo');

// Good
cache()->get('foo');
// Better
cache('foo');

Create custom Blade directives for business logic

You can make your Blade templates more expressive by creating custom directives. For example, rather than checking if the user has the admin role, you could use @admin.

// Bad
@if(auth()->user()->hasRole('admin'))
  // ...
@else
  // ...
@endif

// Good
@admin
  // ...
@else
  // ...
@endadmin

Avoid queries in Blade when possible

Sometimes you may want to execute DB queries in blade. There are some ok use cases for this, such as in layout files. But if it’s a view returned by a controller, pass the data in the view data instead.

// Bad
@foreach(Product::where('enabled', false)->get() as $product)
  // ...
@endforeach

// Good
// Controller
return view('foo', [
  'disabledProducts' => Product::where('enabled', false)->get(),
]);

// View
@foreach($disabledProducts as $product)
  // ...
@endforeach

Use strict comparison

ALWAYS use strict comparison (=== and !==). If needed, cast things go the correct type before comparing. Better than weird == results. Also consider enabling strict types in your code. This will prevent passing variables of wrong data types to functions.

// Bad
$foo == 'bar';

// Good
$foo === 'bar';
// Better
declare(strict_types=1);

Use docblocks only when they clarify things

Many people will disagree with this, because they do it. But it makes no sense. There’s no point in using docblocks when they don’t give any extra information. If the typehint is enough, don’t add a docblock. That’s just noise.

// Bad
// No types at all
function add_5($foo)
{
  return $foo + 5;
}

// The @param annotation adds precisely 0% value and 100% noise.
/**
 * Add 5 to a number.
 *
 * @param int $foo
 * @return int
 */
function add_5(int $foo): int
{
  return $foo + 5;
}

// Good
// Everything is clear without a docblock
function add_5(int $foo)
{
  return $foo + 5;
}

// The typehint said as much as it could & the annotation said even more.
/**
 * Turn words into a sentence.
 *
 * @param string[] $words
 * @return string
 */
function sentenceFromWords(array $words): string
{
  return implode(' ', $words) . '.';
}

// Personal favourite. Only use the annotations that bring value. Don't use description or @return just because it's so common.
/** @param string[] $words */
function sentenceFromWords(array $words): string
{
  return implode(' ', $words) . '.';
}

Have a single source of truth for validation rules

If you validate some resource’s attributes on multiple places, you definitely want to centralize these validation rules, so that you don’t change them in one place but forget about the other places. I often find myself keeping validation rules in a method on the model. This lets me reuse them wherever I may need - including in controllers or form requests.

class Reply extends Model
{
  public static function getValidationRules(): array
  {
    return [
      'thread_id' => ['required', 'integer'],
      'user_id'   => ['required', 'integer'],
      'body'      => ['required', 'string', new SpamRule()],
    ];
  }
}

Use collections when they can clean up your code

Don’t turn all arrays into collections just because Laravel offers them, but DO turn arrays into collections when you can make use of collection syntax to clean up your code.

$collection = collect([
  ['name' => 'Regena', 'age' => null],
  ['name' => 'Linda', 'age' => 14],
  ['name' => 'Diego', 'age' => 23],
  ['name' => 'Linda', 'age' => 84],
]);

$collection->firstWhere('age', '>=', 18);

Write functional code when it benefits you

Functional code can both clean things up and make them impossible to understand. Refactor common loops into functional calls, but don’t write stupidly complex reduce()s just to avoid writing a loop. There’s a use case for both.

// Bad
return array_unique(array_reduce($keywords, function ($result, $keyword) {
  return array_merge($result, array_reduce($this->variantGenerators, function ($result2, $generator) use ($keyword) {
    return array_merge($result2, array_map(function ($variant) {
      return strtolower($variant);
    }, $generator::getVariants($keyword)));
  }, []));
}, []));

// Good
return $this->items()->reduce(function (Money $sum, OrderItem $item) {
  return $sum->addMoney($item->subtotal());
}, money(0, $this->currency));

Comments usually indicate poor code design

Before writing a comment, ask yourself if you could rename some things or create variables to improve readability. If that’s not possible, write the comment in a way that both your colleagues and you will understand in 6 months.

Context matters

Above I said that moving business logic to action/service classes is good. But context matters. Here’s code design advice from a popular “Laravel best practices” repo. There’s absolutely no reason to put a 3-line check into a class. That’s just overengineered.

// Bad
public function store(Request $request)
{
  $this->articleService->handleUploadedImage($request->file('image'));
}

class ArticleService
{
  public function handleUploadedImage($image)
  {
    if (!is_null($image)) {
      $image->move(public_path('images') . 'temp');
    }
  }
}

// Good
public function store(Request $request)
{
  if ($request->hasFile('image')) {
    $request->file('image')->move(public_path('images') . 'temp');
  }

  // ...
}

Use only what helps you and ignore everything else

Your goal to write more readable code. Your goal is NOT to do what someone said on the internet. These tips are just tactics that tend to help with clean code. Keep your end goal in mind and ask yourself “is this better?”

Running a startup in the times of Covid-19

Tue, 19 May 2020 19:18:01 +0000

Dear fellow startup founder,

The worst part of the Covid-19 crisis isn’t just that previously-profitable businesses have touched zero revenues - it is that there is no visibility on a timeline for a return to normalcy or even an end in sight. This isn’t the first time we have seen an economic crisis. Historically, there was the Great Depression of the 1930s, and more recently, the 2000 dot-com bubble followed by the 2008 global financial crisis. However, the Covid-19 pandemic threatens to eclipse the rest in terms of the sheer amount of time companies around the world will require to make a successful return to their respective pre-Covid growth & revenue numbers.

The impact of Covid-19 has been felt on a majority of startups, with several employees losing their jobs & startups with earlier high revenues seeing zero revenues for several months now. This means that now is the time to revisit not only business and consumer mindsets but also core business models.

Here are a few things you can do to ensure that you & your startup survive (and hopefully thrive as well) during these times of crisis:

Being everywhere means that you will be nowhere, so it is time to be decisive

While it is our job as startup founders to be paranoid and visualize worst-case scenarios, it is also our job to be calm and thoughtful. Knee-jerk reactions are characteristic of a crisis. We need to think of this crisis as an opportunity and be decisive. Trying to address multiple problem areas/issues at once will only dilute our efforts. It is time to conserve and focus our strengths on key areas.

Identify factors that are in your control

External factors like when the lockdown in different parts of the country isn’t in our control. What is in our control are expenses, communication with employees, and customers, identifying new opportunities and so on. We must capitalize on & make the most out of the things that we can control.

Go deeper into fine-tuning your product-market fit

The crisis is going to have implications for the next 18-24 months at least. Now with the lockdown slowly opening up, there are going to be cycles of ups and downs in the market, with intertwined negative and positive signals. Founders have to go three-layers-deep within their usage and customer data to really figure out their respective PMF and really isolate the signal from all the noise.

Be conservative, but not pessimistic

There are entrepreneurs who are worried about the crisis, entrepreneurs who are not worried and entrepreneurs who are ignoring the crisis. We need to have a healthy balance of optimism and conservatism. We have to be as lean as possible with expenses. Investors can advise capitalizing on the crisis and expansion but always remember - once the money leaves the bank account, there is no bringing it back.

Update your action plan and account for worst-case scenarios

As an entrepreneur, one of the toughest tasks is to make an Annual Operating Plan with clearly-identified key targeted metrics. However, if we don’t have an updated plan in place, we will have no visibility on whether we are moving in a positive or negative direction overall at any given moment. In a crisis like this, it is also important to plan for various worst-case scenarios which have been unprecedented.

Believe in yourself and don’t play to the gallery in times of crisis

Lastly, now is the time to remind yourself of why you started this business you were so passionate about in the first place. Speak to yourself, your leadership team as well as your employees and customers on why you started on this journey. It is extremely important to take care of yourself and your mental health in these tumultuous times.

Stay safe. Stay strong. We’ll make it through this. 🙂

Death of a Unicorn, Part 2

Mon, 10 Feb 2020 15:25:45 +0000

This article is an in-spirit continuation of the previous one.

India is a growing market for food consumption. Uber Eats has significantly ramped up, with engaging ad campaigns having leading celebrities. Uber Eats does 1/3rd of Swiggy orders, yet the company is being sold for 1/10th of Swiggy’s valuation. Why would Uber sell Eats cheaply after a significant long-term investment in a promising market, just to “cut short-term losses”?

It becomes clear if you look at it as a fire sale, and Uber critically needs capital now. Uber’s IPO is driving this, as it looks to pare down losses to become “healthier”. While the party line is that the sale is to “cut losses”, the real question is “Is an IPO the only way Uber can raise money”? The sale is a strong indication that private investors are no longer willing to back Uber. It is a deeper problem, as Uber stops long-term investments to solve for money to fund its losses.

Lyft, it’s competitor, has also stolen a march by announcing its IPO. Being a second-mover may result in lesser buyer interest. Uber needs the IPO money, and it needs it now. Swiggy is getting a terrific deal. By acquiring a competitor, it cuts losses and accesses a larger delivery/customer network. Swiggy is the ultimate winner here, while Uber is having a tough time.

Of love and timing

Mon, 05 Nov 2018 13:56:25 +0000

When Love finds you, it’s seldom at your best.

Rather, it happens upon you at your worst - when you’ve lost all faith in yourself and your confidence lies tattered in a thousand scraps.

It finds you to patiently put those pieces back, one after the other, painstakingly. It finds you to teach you to love again. It finds you in spite of all the walls you build up over time. It finds you despite all the odds stacked up against it. And once it finds you, it stays - asking but for nought in return.

But once it finds you, it deserves to see a brilliant sunset after a hand-in-hand hike in the mountains. It deserves a warm hug and a kiss. And it deserves to be around for many such more sunsets to follow.

Of new year resolutions (and lack thereof)

Sun, 31 Dec 2017 15:12:29 +0000

Come the last few weeks of December every year and we are faced with a deluge of “new year resolutions” - promises to keep and targets to attain in the upcoming three hundred and sixty five days or so. The utility or veracity of such resolutions is often questioned, especially as they have the dubious distinction of being relegated to the very bottom of our to-do lists as the year progress. Many dismiss the entire concept altogether as junk.

Be as it may, I would rather envision these as kind of a summary of all that we have learnt and imbibed over the last year, with all its ups and downs. In this aspect, here are some of my own “resolutions” (so to speak) for the upcoming year, in no particular order.

I will not book an Uber if I can walk the same distance. #WalkBeforeIRide
I will delegate and allocate responsibilities instead of micromanaging people.
I will read a new book every week.
I will learn sales and marketing from the ground up.
I will meditate for 30 minutes every day.

I am not sure how many I will be able to check off, but hey - always good to have a checklist, right?

Here’s hoping the new year brings fruition to all your wishes and aspirations. Happy New Year, everyone!

Death of a Unicorn

Mon, 18 Sep 2017 17:45:34 +0000

In today’s world, one would be hard-pressed indeed to come across someone who has not heard of Uber in any way. From a ride-sharing startup on the streets of San Francisco to a global transportation behemoth valued at a mind-boggling $70 billion, the startup, as they say, has apparently seen it all. People attribute it’s unprecedented success to a variety of sources - ranging from novel use of technology, tapping into previously unexploited geographic regions and downright strong-arming local rules and regulations to level the playing field against local competition in emerging markets. Whatever be the modus operandi, the end result is as clear as daylight for all to see - an Uber is ubiquitous to a cheap, reliable and efficient mode of transportation around the world, so much so that “uber” is now a verb.

But in this tale of guns and glory to rise to the pinnacle of success, there is more than meets the eye. Even in the early days of its implementation, Uber came negatively into the public eye when an internal tool named “God view” was used freely by Uber employees to track anyone taking an Uber ride at that point - enabling them to tail anyone from celebrities to ex-beaus. When faced with media backlash on this issue, an Uber executive euphemistically suggested hiring private investigators to dig up dirt on the journalists covering the story, provoking massive outrage. While these early transgressions could be forgiven owing to a startup mentality of “move fast and break things”, things did not look up in the upcoming years. Uber was successively accused of promoting sexism and misogyny at the highest levels of the management, allegations of sexual harassment and gender discrimination ran rife, leading to top executives resigning from the organization. Things were also not helped by Uber CEO Travis Kalanick caught on dashcam to be lambasting an Uber driver. More worryingly, researchers showed that the Uber application kept tracking users’ locations even after their ride had ended.

But, ethical and moral concerns aside, there is an even bigger elephant in the room. Uber is not profitable in any single one of the multiple global markets it operates in, and it’s cash burn rate on new customer acquisition and customer retention is astronomical, to put it very mildly. (A more exact term would probably be a clusterf**k). Although Uber CEO Travis Kalanick says he has a roadmap to profitability in the near future, the colossal amount of money that has been spent already makes this a bit hard to digest. While Uber is not a public corporation and thus does not need to appease it’s shareholders, (and obviously, it has had no problem attracting private capital in ginormous quantities so far) the principal source of Uber’s bankroll today is dilution of more equity in successive funding rounds. The company has no assets of proportionate value to back up its multi-billion dollar valuation. It does not own the vehicles, and the drivers are Uber contractors, not employees (as Uber itself has gone out to state time and again, most recently in a class-action lawsuit settlement). It’s self-driving car technology, arguably its most valuable intellectual property, has been locked down in a (potentially lengthy) patent lawsuit with Google.

That leaves the Uber model - an aggregator between supply and demand in a market. While the scale of implementation (and the logistics involved) have definitely been unprecedented, the concept is not new in itself, and Uber shall have a hard time proving the contrary. And Uber’s recent exit from the Chinese market, which until very recently was its second largest, glaringly shows its inability to compete with a well-entrenched local player with relatively deep pockets. Economies of scale have always defined the relationship between price and supply, and there has been a “bubble” so to speak every time the market tried to artificially move against supply-and-demand. Uber’s massive valuation today is no longer a valuable war chest - rather it is on the verge of becoming a very large stone tied around the company’s neck. While the successive rounds of inflated valuations allowed initial investors to exit with large profits, it in turn created a vicious cycle that tied in the next round of investors. And sooner or later, this system will implode.

If and when that happens, it would probably send a cold shiver down the collective spines of the so-called “Unicorns” of the startup world. It might as well even trigger a selling frenzy that would cause a market meltdown like the Tulip craze in mediaeval Europe, or the more-recent dot-com bubble on an exponentially exaggerated scale. How and when Uber gets off this burning train - remains the question to be answered.

Engineering as a career

Sat, 15 Jul 2017 18:14:55 +0000

Every year around this time, a new batch of high school students finally confront the looming question in front of them - which course of study to pursue moving forward? (Sure, there is that 10% who has it all figured out for the next decade, but lets stick to the majority here). For most, due to a combination of parental nudges, peer pressure and sometimes simple herd instinct and aggressive televertising, the choice boils down to a binary one - medical or engineering, with a large fraction opting for the later. While the exponential proliferation of “engineering” colleges has supposedly led to a boom in the number of engineering graduates passing out each year, the quality of the graduates has taken an equally sharp downturn as per most industry surveys. At this juncture, it becomes extremely important to judge whether you want an engineering degree, or you want to be an engineer - for the distinction between these two has been even more marked in recent times. So, without further ado, here is what it means (and takes) to be an engineer.

Engineers create new things and add value to society on a day-to-day basis. Developing novelty is pretty much the bread-and-butter of an engineering job. From skyscrapers to spaceships, apps and websites to higways and bridges - all are the handiwork of engineers.
Engineers find solutions to real-world problems. At the core of engineering is the desire to make human lives better, and this finds implementation by way of solutions to issues that are faced on a day-to-day basis. Today, we move faster, eat better and stay safer than ever before, with engineers at the helm of every aspect.
Engineers apply mathematics to scale solutions to obtain repeatable results. No innovation can truly benefit society if it only remains in the hands of a few and is not mass-producible, or can be accessed freely by everyone. And it is engineers who ensure that a solution to a problem can scale, from one to many, so that the benefits can be reaped by all.

If you are a high school graduate looking to make your choice of field of study, I would sincerely recommend you opt for engineering only if you can identify yourself with all of the above. And remember, most importantly, engineering is not a silver bullet - you can do well in whatever field you opt for. Go with your heart, not with the herd. All the best!

Inspired by this awesome post by Balaji Viswanathan on Quora

Thoughts on site speed, or why do sites slow down

Sat, 29 Apr 2017 11:34:25 +0000

We so often face the scenario when we wanted to look up something on our mobile phones, but gave up halfway when the site was too slow to load. In a world where more traffic is moving to mobile from traditional desktop browsers, loading speed has become a major factor that determines bounce rate and time spent by users on a website. But the dichotomy lies in the fact that if we make the site too barebones in an effort to make it lightweight, it reduces the usefulness (and often the usability as well) of the website.

So, how do we attain the “just-right” mix of loading speed and functionality, while keeping the site simple and user-friendly too? Well, as it turns out, it is not too difficult, actually, if we keep some basic tenets in mind while optimizing:

A site with lots of high-resolution images, several fonts and a lot of stylesheets shall be sluggish to load, no matter the level of optimization. Before optimization even begins, we have to clean the cruft at the core. Replacing large JPGs with PNGs or WEBPs, several different fonts with a single (or maybe two at most) are a good place to start.
Once the basic cleanup is out of the way, we can now try to optimize our server setup. Most sites on the internet are served by some dedicated or shared hosting server running some flavour of Linux. While this is a great out-of-the-box solution to get you up and running, it doesn’t necessarily scale well under loads. There are several ways in which we can tackle this. For example, we absolutely have to start using different servers to run your application and the database, instead of having them run on the same machine. If you are on a cloud server platform such as Heroku or DigitalOcean, you can additionally benefit from horizontal scaling by spinning up more nodes on-demand as you receive a spike in traffic and putting them behind a load balancer. Also, if you have the moolah to splurge, buying the biggest and baddest server out there probably won’t hurt. :stuck_out_tongue:
With the server optimization in place, it’s time to look at your app code. If you are using a dynamic website (which you probably are, for I have never heard of a static site having scaling issues till date), you are either rocking an off-market CMS such as WordPress or Joomla, or something custom-made on top of Rails, Django, Laravel or insert your framework name here. Most content management systems provide some way to cache the generated views. (WP Super Cache or W3 Total Cache come to mind for WordPress.) Also, MVC frameworks also usually come with out-of-the-box support for caching views, so it is usually a question of enabling it. You can cache your views on disk, in memory or in a database. For the more technically proficient, there is always Memcached or Redis for object storage.
The last thing that you do to boost your site speed is caching at the DNS level. CloudFlare, with its distributed CDN and globally distributed network, is undoubtedly the king of this hill. (What’s more, it throws in DDoS protection for free.) Amazon CloudFront could also be used for this, but it requires a lot more configuration to work than CloudFlare. By storing cached copies of your site locally at datacenters across the globe, your site speed can be boosted hugely for global audiences.
If you are looking to squeeze the very last ounce of speed from your site, you can try swapping out the hosting sofware that you run on your server. While Apache is often commonly used as a web server (with mod_deflate enabled for compression), many people have reported speed upticks after switching to Nginx with a load balancer and GZIP compression. However, this is subject to interpretation and may not even be compatible with your website or app, so your mileage here may vary.

And that’s pretty much it! If you have followed along, you now are the proud owner of a shiny new website which is pretty much rearing to go at full throttle by this point, and hopefully your Google SiteRank has been cranked up a couple of notches. Follow my blog for more sysadmin and random tech tutorials. Cheers!

CloudBleed, and how you are impacted

Mon, 27 Feb 2017 11:03:35 +0000

The latest story doing the rounds on Hacker News is how Cloudflare, one of the leading edge CDN providers, was susceptible to a vulnerability that dumped a massive amount of user credentials and other private data onto publicly accessible search engines. According to the same story, this vulnerability was first picked up by security analysts at Google’s Project Zero team and reported to CloudFlare, who worked on deploying a rapid fix to issue. What has been adding to the confusion, however, is this blog post by Cloudflare where they seriously downplay both the extent of the problem, as well as the number of users actually affected by this bug.

So, is all well in CDN-land? Apparently not - for the same security researcher who reported the vulnerability has now released some redacted snapshots of the data dumped due to the vulnerability, post the expiry of the vulnerability notification window - and some pretty damning evidence comes to light. We see live ride details of an Uber driver (including OAuth credentials) using the Uber app on an iPhone, a person’s fitness records on FitBit, and a chat log on the dating site OkCupid. All of these, as well as some SSL private keys, were dumped in plain-text. While Cloudflare has since fixed the vulnerability, what is even more worrying is that the fact the dumped data has been in many cases surreptitiously cached by search engines. Update: CloudFlare has updated that the cached data dumps have since been removed, so kudos to a rapid response at least.

With Cloudflare confirming that no usernames or passwords have been directly leaked, the greatest impact of CloudBleed is how it has pointed out that users, in spite of having secure passwords and 2-factor authentication enabled, can be vulnerable to data breaches due to unforeseen bugs. On the bright side, Cloudflare has been very proactive in patching the bug once it was identified, so we have to now wait and see out the whole saga of CloudBleed plays out in the longer run.