frabjous

  
  if &background == 'dark'
    
  let s:guishade0 = "#131518"
  let s:guishade1 = "#303236"
  let s:guishade2 = "#4d5053"
  let s:guishade3 = "#6a6d71"
  let s:guishade4 = "#878b8f"
  let s:guishade5 = "#a4a8ad"

dominicfreeston

/// Wraps its content in a HostingViewController that has the backgroundColor of UITableView appearance
/// within it set to .clear, thus working around the issue where SwiftUI Lists always have white backgrounds,
/// without inadvertently affecting the appearance of all UITableViews in the app.
/// Setting the listRowBackground explicitly is still required, setting that to clear won't work.
struct ListAppearanceContainer<Content>: View, UIViewControllerRepresentable where Content: View {
    let content: Content
    
    class AppearanceContainerViewController<Content>: UIHostingController<Content> where Content: View {}
    
    init(_ content: () -> Content) {

holyjak

(ns ssr-test
  "Try server-side rendering in Fulcro where we want to display a non-default 
  dynamic router target.
  *BEWARE*: This is an exploration. I have *no* idea what is the correct way."
  (:require
    [com.fulcrologic.fulcro.application :as app]
    [com.fulcrologic.fulcro.algorithms.denormalize :as denorm]
    [com.fulcrologic.fulcro.algorithms.server-render :as ssr]
    [com.fulcrologic.fulcro.components :as comp :refer [defsc]]
    [com.fulcrologic.fulcro.dom-server :as dom :refer [div label input]]

levand

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

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil