domkm

import polars as pl
import httpx

class IBProductsScraper:
    """
    https://www.interactivebrokers.com/en/trading/products-exchanges.php
    """
    
    def __init__(self):
        pass

domkm

{
  "$schema": "https://raw.githubusercontent.com/jsonresume/resume-schema/v1.0.0/schema.json",
  "basics": {
    "name": "Dom Meyer",
    "label": "Software Engineer",
    "email": "[email protected]",
    "phone": "(415) 299-0102",
    "url": "https://www.domkm.com",
    "summary": "Hands-on software engineering leader with experience in startups and enterprises\n\nExcels at taking products from zero to one and finding product-market fit\n\nProven record of\n- building and managing high-performance remote software engineering teams\n- recruiting, developing, and retaining world-class software engineers\n- delivering successful software projects  in challenging environments on time and on budget\n- initiating and facilitating important and difficult conversations\n\nInternational conference speaker - Europe, North America, South America\n",
    "location": {

domkm

import SwiftData
import SwiftUI

@Model final class Parent {
  init() {
    child = Child()
  }
  @Transient let uuid =  UUID()
  @Relationship(deleteRule: .cascade, inverse: \Child.parent) var child: Child?

domkm

Synthetic IDs and cache normalization in Apollo 3

We are using Apollo 2 in production and are very happy with it. Thanks for developing it! :) Now that Apollo 3 is out, we tried to upgrade and ran into some issues with caching.

Apollo 3 seems to believe that it is practical to manually specify merge strategies for every type and/or field (hundreds or thousands of lines of configuration) and also that this manual configuration cannot be checked at build time or start time, but instead fail eventually at runtime. To me, this sounds like an unacceptable combination. Given this, I set about writing code to inspect our schema and generate type policies. However, I ran into issues with Apollo not exposing sufficient information to build these policies.

I believe that a simple and general normalization strategy is sufficient for our use and for the vast majority of non-pathologic schemas that make the following assumptions:

1. Most objects have ids that allow normalization
2. Objects that do not have ids a

domkm

  // Available variables:
  // - Machine
  // - interpret
  // - assign
  // - send
  // - sendParent
  // - spawn
  // - raise
  // - actions

domkm

(ns broadbrim.react-relay
  (:require
   [cljs.core :refer [specify! this-as js-arguments js-obj]]
   [clojure.java.io :as io]
   [clojure.string :as str]
   [clojure.tools.macro :as macro]
   [me.raynes.conch :as conch]
   [potemkin]
   [sablono.core :as sablono]
   [taoensso.timbre :as log]))

domkm

;;;; Entity wrapper

#?(:clj (declare ->EntityMap))
#?(:clj (deftype EntityMap [^datomic.query.EntityMap entity ^boolean ident?]
          Object
          (hashCode [this]
            (.hashCode entity))
          (equals [this o]
            (and (instance? (class this) o)
                 (.equals entity (.entity o))))

domkm

(ns namespace)

(defrecord Language [name])

(defmacro lang [name]
  (->Language name))

(def clj
  (lang "Clojure"))

domkm

### Keybase proof

I hereby claim:

  * I am DomKM on github.
  * I am domkm (https://keybase.io/domkm) on keybase.
  * I have a public key whose fingerprint is E8A7 7F7C FC53 EE8E 59FA  5468 0A66 DE7B 9E89 228D

To claim this, I am signing this object:

domkm

(require '[automat.core :as a])

(-> [1 2 (a/$ :conj) 3 4 (a/$ :conj)]
    (a/compile {:reducers {:conj conj}})
    (a/find nil [1 2 3 4])
    :value)
;=> (4 2)

(-> [1 a/any (a/$ :conj) 3 4 (a/$ :conj)]
    (a/compile {:reducers {:conj conj}})