21 Apr 2021

Managing your reading

History / Edit / PDF / EPUB / BIB / 3 min read (~529 words)

The process described below attempts to optimize reading quality books and enjoying the reading experience. As such, it promotes book exploration (discovery of new books) and reading books which have a high rating according to your own taste. Books which receive lower ratings (compared to other books) are moved down the reading priority list and will not be read until books that have higher priority (i.e., rating) either are finished reading or their rating decreases such that other books are now high priority.

  • Pick highly read books (use a site like goodreads to identify those books).
  • When reading a book, record the page you start and stop reading on, the time you start and stop reading and emit a rating for what you've read.
    • You can decide to optimize whether you want to optimize per page rating or per duration rating, that is, get the most value per page or by time spent reading.
  • Add new books to your reading list regularly. Those books are considered as having the highest priority and are then added to the prioritized list of books according to its rating.
  • When not reading a new book, read the books in order of priority and by interest at the time of reading.
  • From time to time you may look at your list of prioritized books and decide whether the books with the lowest priority should ever be finished. In some cases it is reasonable to decide that certain books will never be read completely.
  • As an alternative approach, one can use multi-armed bandits algorithms to decide which book to read next. Given that we can convert multi-armed bandits problem into the problem of selecting which book to read next given a sequence of readings and associated rating ("rewards"), the various algorithms (such as Epsilon-greedy or UCB1) will provide us with the next book we should read.
    • Interestingly enough, an algorithm like UCB1 will promote reading books we've never read first over reading books we've already started reading.

  1. Read partially any book for which you haven't given any rating
  2. Rate what you have read on a 1 to 5 scale, 1 being very bad and 5 being very good (see book rating)
  3. Compute the weighted rating of the book (the sum of rating times # of page associated to the reading divided by the total # of pages read so far for the book)
  4. Sort books by weighted rating (descending), then average estimated amount of time left to complete (ascending)
  5. If you have books that you haven't read yet, go back to the first step. If not, then pick the book at the top of the list computed in the previous step, then continue from step 2

  • It's better to read a good book than to finish a bad book

I make extensive use of Laravel Debugbar to track performance of parts of my application. I sprinkle calls to Debugbar::startMeasure and Debugbar::stopMeasure to track the duration of certain segments of my code. However, when this code goes into production, this dependency isn't present. This cause the code to break since it cannot find Debugbar anymore.

To solve this issue, I thought I would create a dummy Debugbar class and have it added as an alias, so that any code depending on Debugbar would still work, but end up as a "no operation". I found the article Dynamic class aliases in package which introduced the necessary piece of information to accomplish this.

<?php

use Illuminate\Foundation\AliasLoader;
use My\SuperPackage\FooBar;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function register()
    {
        $this->app->booting(function() {
            $loader = AliasLoader::getInstance();
            $loader->alias('FooBar', FooBar::class);
        });
    }
}

In my desired use case, I simply implemented the following changes:

In app/Providers/DebugbarServiceProvider.php (a new file)

<?php

namespace App\Providers;

use Illuminate\Foundation\AliasLoader;
use Illuminate\Support\ServiceProvider;

class DebugbarServiceProvider extends ServiceProvider
{
    public function register()
    {
        if (!class_exists('Debugbar')) {
            $loader = AliasLoader::getInstance();
            $loader->alias('Debugbar', NullDebugbar::class);
        }
    }
}

class NullDebugbar
{
    public static function __callStatic(string $name, array $arguments)
    {
        // Do nothing
    }
}

In app/config/app.php

    // under the 'providers' key, add
    'providers' => [
        [...]
        // This will take care of loading the service provider defined above
        App\Providers\DebugbarServiceProvider::class,
    ],

With those two changes, it is now possible to make use of Debugbar in most places and have it work even without the Laravel Debugbar dependency installed.

07 Mar 2021

Closing tabs

History / Edit / PDF / EPUB / BIB / 1 min read (~84 words)
browser tabs

  • Want to read but
    • Too long -> Transfer to pocket
  • Want to watch but
    • Too long -> Add to a youtube watchlist (which I'll never watch)
  • I need them open to quickly enter data
  • I want to watch them again and again
    • Download with youtube-dl and watch using VLC
  • Would maybe read one day, but definitely not now (very low priority)
    • Transfer to pocket

  • If a tab is scanned more than 5/10 times, it goes into the backlog bin

The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.

  • Setup laptop
  • Access to slack
  • Access to zoom
  • Setup calendar reminders
  • Initial meeting with buddy
  • Access to git central repository
  • Installation of development tools/languages
  • Request software licenses
  • Access to CI/CD
  • Find where task management is done
  • Find the documentation to build projects
  • Connect 1 on 1 with each member of the team
  • Meet with manager 1 on 1
  • Define a 30-60-90 days plan with manager
  • Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
  • End of week meeting with buddy

  • Setup and run the one step build process
  • Determine how are features/tasks prioritized, who prioritizes features/tasks
  • Review the team documentation
  • Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
  • Review common vocabulary, terminology, glossary documents
  • First PR + code review
  • Review the career ladder of the position

  • Review user definition, use cases, requirements
  • Read prior team meetings notes

  • Identify how deployments are done
  • Review the team roadmap
  • Determine where I can have the biggest impact
  • Determine a timeline where I'll have reached my 80/20 at the company
  • Determine the maturity of existing projects
  • Determine how fast can we iterate on certain aspects given the team/company composition
  • Identify the core/principal/staff contributors and their contributions
  • Review the architecture of the system
  • Review the database architecture
  • Learn about "how we got to this point"
  • Determine whether the product is a monolith or micro-services
  • Identify which (3rd party) tools are used by the team/company
  • Determine the portfolio of STARS situations of the team/company
  • Determine a rough estimate of the number of people in the different organizations
  • Connect 1 on 1 with important collaborator in other teams
  • End of first month meeting with buddy
  • First month performance review with manager
  • Informal 360-degree review with manager and peers on adaptation
  • Month 1 job satisfaction review

  • Team interaction diagram
  • Month 2 job satisfaction review

  • Month 3 job satisfaction review
29 Nov 2020

Day trading in Canada

History / Edit / PDF / EPUB / BIB / 2 min read (~358 words)
finance stocks

Notice/Advisory: I am not an accountant nor a day trader. The following is not advice, only notes I've taken for myself. Content may be wrong or inaccurate. Use at your own risk.

The following is a list of items and things to think about if you would like to be a day trader. I wrote it with the intent of identifying what were the requirements to be a day trader and what would be the impacts of being considered as one vs being an investor.

  • Basics
    • Computer or phone
    • Internet
    • Broker
    • Money
  • Do not do day trading in your TFSA/RRSP/RESP accounts
  • Your gains/losses will either be categorized as capital gains (50% taxable) or business income (100% taxable) based on how you trade. In any case, since this is a day trading article, you can assume this will be business income. Here are some properties taken into account
    • Volume and frequency of trading
    • Length of ownership of securities
    • Type of securities owned
    • Your profession and level of stock market knowledge
    • If trading is your main source of income or substantially supplements it
      • Here it is not clear what substantially represents. I would estimate that anything below 25% of your non-trading income isn't substantial.
  • If you want to day trade, you will want to have access to level 2 data, which costs money depending on your broker
    • Some brokers will reimburse your data package fees if you spend a certain amount of money on commissions each month. For example, Questrade data package will cost you 90$/month, but if you spend over 400$ on commissions this fee will be rebated.
  • You do not need to register with the government or any agency
  • You do not need a minimal amount of money, although it is suggested to have a few thousands dollars otherwise you will not make a lot of profit daily and your commissions fees are likely to eat any profit you will make
    • Some brokers have minimum account balance
  • You have a trading strategy
  • Track your transactions
    • Time of entry/exit
    • Cost at entry/exit
    • Symbol/Ticker