Dash-Board-for-Newton-OS VS Knapsack

For me, it was the second application I ever released, when I was a student at university and still didn't really know how to program properly.

The application was Dash Board[1] for Newton OS, and it only ran on the final generation of Newton hardware (created by Apple, but spun out as a separate company in its final days, before being killed by Steve Jobs shortly after his return).

It "only" sold a few thousand copies. (But it was during the warez heyday, and I am pretty sure there were also tens of thousands of bootleg copies being used, thanks to the registration code generator by "DocNZ" that was widely shared on Hotline back then.)

But that was really pretty great, since the final MP2000/2100 generation of hardware it required was thought to have only sold about 200,000 devices in total.

I have since had a fairly normal software engineer career, and have worked on apps that shipped far more copies, and today I work on customer facing web applications and API SDKs that have more users, and arguably do stuff that is more "important" (e.g. help companies manage large fleets of machines/robots/IoT stuff) than what Dash Board did — which was basically just improve the user interface of the Newton.

But it's 100% clear to me that the magnitude of user impact of Dash Board was much higher than any other thing I've built. People really loved it — I know because hundreds of them actually wrote to us to let us know. (LOL I mean wrote to me "me" — old habits of pretending the company wasn't just one student in his tiny apartment die hard).

Of course, I made more money later, and worked on things that touched a much larger number of people's lives. But "impact" has both X and Y axes. It was the depth of the users' fondness for Dash Board that makes it eclipse everything since. I don't think there are that many chances to just go for "user delight" as the number one metric.

For me, developer satisfaction is a function of that user delight more than anything else.

[1]: http://www.fivespeedsoftware.com/dashboard

[2]: 15 years later, I open-sourced the code and gave it a proper retrospective: https://github.com/masonmark/Dash-Board-for-Newton-OS

The experience of resurrecting this software is similar to the odyssey of Mason Mark, detailed here.

I've created a knapsack ruby gem for CI parallelisation that has over 122 million downloads. Primarily due to the fact, Gitlab is using it.

I spin off https://knapsackpro.com from the knapsack gem and we are helping our customers run fast CI builds.

name: Main on: [push] jobs: test: runs-on: ubuntu-latest # If you need DB like PostgreSQL, Redis then define service below. # https://github.com/actions/example-services/tree/master/.github/workflows services: postgres: image: postgres:10.8 env: POSTGRES_USER: postgres POSTGRES_PASSWORD: "" POSTGRES_DB: postgres ports: - 5432:5432 # needed because the postgres container does not provide a healthcheck # tmpfs makes DB faster by using RAM options: >- --mount type=tmpfs,destination=/var/lib/postgresql/data --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 redis: image: redis ports: - 6379:6379 options: --entrypoint redis-server # https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix strategy: fail-fast: false matrix: # [n] - where the n is a number of parallel jobs you want to run your tests on. # Use a higher number if you have slow tests to split them between more parallel jobs. # Remember to update the value of the `ci_node_index` below to (0..n-1). ci_node_total: [8] # Indexes for parallel jobs (starting from zero). # E.g. use [0, 1] for 2 parallel jobs, [0, 1, 2] for 3 parallel jobs, etc. ci_node_index: [0, 1, 2, 3, 4, 5, 6, 7] env: RAILS_ENV: test GEMFILE_RUBY_VERSION: 2.7.2 PGHOST: localhost PGUSER: postgres # Rails verifies the time zone in DB is the same as the time zone of the Rails app TZ: "Europe/Warsaw" steps: - uses: actions/checkout@v2 - name: Set up Ruby uses: ruby/setup-ruby@v1 with: # Not needed with a .ruby-version file ruby-version: 2.7 # runs 'bundle install' and caches installed gems automatically bundler-cache: true - name: Create DB run: | bin/rails db:prepare - name: Run tests env: KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC: ${{ secrets.KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC }} KNAPSACK_PRO_CI_NODE_TOTAL: ${{ matrix.ci_node_total }} KNAPSACK_PRO_CI_NODE_INDEX: ${{ matrix.ci_node_index }} KNAPSACK_PRO_LOG_LEVEL: info # if you use Knapsack Pro Queue Mode you must set below env variable # to be able to retry CI build and run previously recorded tests # https://github.com/KnapsackPro/knapsack_pro-ruby#knapsack_pro_fixed_queue_split-remember-queue-split-on-retry-ci-node KNAPSACK_PRO_FIXED_QUEUE_SPLIT: true # RSpec split test files by test examples feature - it's optional # https://knapsackpro.com/faq/question/how-to-split-slow-rspec-test-files-by-test-examples-by-individual-it KNAPSACK_PRO_RSPEC_SPLIT_BY_TEST_EXAMPLES: true run: | bundle exec rake knapsack_pro:queue:rspec

# Ruby CircleCI 2.0 configuration file # # Check https://circleci.com/docs/2.0/language-ruby/ for more details # version: 2 jobs: build: parallelism: 10 # https://circleci.com/docs/2.0/configuration-reference/#resource_class resource_class: small docker: # specify the version you desire here - image: circleci/ruby:2.7.1-node-browsers environment: PGHOST: 127.0.0.1 PGUSER: my_db_user RAILS_ENV: test # Split slow RSpec test files by test examples # https://knapsackpro.com/faq/question/how-to-split-slow-rspec-test-files-by-test-examples-by-individual-it KNAPSACK_PRO_RSPEC_SPLIT_BY_TEST_EXAMPLES: true # Specify service dependencies here if necessary # CircleCI maintains a library of pre-built images # documented at https://circleci.com/docs/2.0/circleci-images/ - image: circleci/postgres:10.6-alpine-ram environment: POSTGRES_DB: my_db_name POSTGRES_PASSWORD: "" POSTGRES_USER: my_db_user # Rails verifies Time Zone in DB is the same as time zone of the Rails app TZ: "Europe/Warsaw" - image: redis:6.0.7 working_directory: ~/repo environment: TZ: "Europe/Warsaw" steps: - checkout # Download and cache dependencies - restore_cache: keys: - v2-dependencies-bundler-{{ checksum "Gemfile.lock" }}-{{ checksum ".ruby-version" }} # fallback to using the latest cache if no exact match is found - v2-dependencies-bundler- - run: name: install ruby dependencies command: | bundle install --jobs=4 --retry=3 --path vendor/bundle - save_cache: paths: - ./vendor/bundle key: v2-dependencies-bundler-{{ checksum "Gemfile.lock" }}-{{ checksum ".ruby-version" }} # Database setup - run: bin/rails db:prepare - run: name: run tests command: | export CIRCLE_TEST_REPORTS=/tmp/test-results mkdir $CIRCLE_TEST_REPORTS bundle exec rake "knapsack_pro:queue:rspec[--format documentation --format RspecJunitFormatter --out tmp/rspec.xml]" # collect reports - store_test_results: path: /tmp/test-results - store_artifacts: path: /tmp/test-results destination: test-results

One, the interesting out-of-the-box solution is Knapsack Pro. It helps run your tests in a parallel efficient way.