In JVM Clojure, Exceptions are for operating errors ("something went wrong") and Assertions are for programmer and correctness errors ("this program is wrong").
An assert might be the right tool if throwing an Exception isn't enough. Use
them when the assertion failing means
SQLite supports several journal modes, each offering advantages in performance, concurrency, and the way changes are logged and applied. This guide explains the journal modes available in SQLite so you can choose the right one for your application.
PRAGMA journal_mode = WAL;
The Clojure Style Guide is pretty good overall. It's very detailed and most of its advice is solid. There are handful of places it makes bad recommendations or is missing some advice.
Many of these criticisms apply to the output of linters like clj-kondo as well.
| #!/usr/bin/env bb | |
| ;; Ported from https://gist.github.com/pyr/d5e17af9c572b681a57de52895437298 to babashka | |
| ;; klein aims to be a small joker script to mimick | |
| ;; most of leiningen's default behavior while minimizing | |
| ;; divergence from standard facilities provided by | |
| ;; tools.deps | |
| ;; This is built as a single file script to simplify | |
| ;; deployment and will avoid requiring any code beyond |
| #!/bin/sh | |
| #_( | |
| #_DEPS is same format as deps.edn. Multiline is okay. | |
| DEPS=' | |
| {:deps {clj-time {:mvn/version "0.14.2"}}} | |
| ' | |
| #_You can put other options here | |
| OPTS=' |
The response to my first few posts has been much larger than I’d imagined and I’d like to thank everyone for the encouragement.
If you’re interested in building a trading system I recommend first reading my previous post on general ideas to keep in mind.
My first really technical post will be on how to build a limit order book, probably the single most important component of a trading system. Because the data structure chosen to represent the limit order book will be the primary source of market information for trading models, it is important to make it both absolutely correct and extremely fast.
To give some idea of the data volumes, the Nasdaq TotalView ITCH feed, which is every event in every instrument traded on the Nasdaq, can have data rates of 20+ gigabytes/day with spikes of 3 megabytes/second or more. The individual messages average about 20 bytes each so this means handling
| # frozen_string_literal: true | |
| # Use this setup block to configure all options available in SimpleForm. | |
| SimpleForm.setup do |config| | |
| # Default class for buttons | |
| config.button_class = "button" | |
| # Define the default class of the input wrapper of the boolean input. | |
| config.boolean_label_class = "checkbox" |
| SPC | |
| SPC: find file | |
| , switch buffer | |
| . browse files | |
| : MX | |
| ; EX | |
| < switch buffer | |
| ` eval | |
| u universal arg | |
| x pop up scratch |
NOTE: Specific examples given for options, flags, commands variations, etc., are not comprehensive.
Vim has 2 main "modes", that chance the behavior of all your keys. The default mode of Vim is Normal Mode and is mostly used for moving the cursor and navigating the current file.
Some important (or longer) commands begin with ":" and you will see the text you enter next at the bottom left of the screen.
:q[uit] - quit (the current window of) Vim. ("Window" here is internal to Vim, not if you have multiple OS-level windows of Vim open at once.)
:q! - force quit (if the current buffer has been changed since the last save)
:e[dit] {filename} - read file {filename} into a new buffer.
Since it has come up a few times, I thought I’d write up some of the basic ideas around domain modeling in Clojure, and how they relate to keyword names and Specs. Firmly grasping these concepts will help us all write code that is simpler, cleaner, and easier to understand.
Clojure is a data-oriented language: we’re all familiar with maps, vectors, sets, keywords, etc. However, while data is good, not all data is equally good. It’s still possible to write “bad” data in Clojure.
“Good” data is well defined and easy to read; there is never any ambiguity about what a given data structure represents. Messy data has inconsistent structure, and overloaded keys that can mean different things in different contexts. Good data represents domain entities and a logical model; bad data represents whatever was convenient for the programmer at a given moment. Good data stands on its own, and can be reasoned about without any other knowledge of the codebase; bad data is deeply and tightly coupled to specific generating and
