straws

If anyone can help figure out how to trigger the leap keys in the emulator, I'm all ears:

https://archive.org/details/canoncat

- - -

It's fascinating to compare a tool like this to the direction the Macintosh actually took — though Jef Raskin conceived the project in the early days of Apple, the graphical user interface took its design cues from the research at Xerox Parc instead. The Humane Interface is Raskin's book on the principles behind a product like this: focus on spatial context with a zooming UI, be forgiving with ubiquitous undo, provide one way of doing things, never trap the user in a mode. A lot of those ideas are embedded in the interfaces we have today, but they feel entirely orthogonal to the discoverability that a Parc-style GUI provides.

An additional summary (with sample code!) lies in the explainer document:

https://github.com/WICG/budget-api/blob/gh-pages/README.md

An enormous amount of the shavings and inlining that the Closure compiler is capable of assumes that you write your code according to rules that reduce ambiguity and dynamic features in your code. Variable names get mangled, so things like using string names for properties is out the window, which means invoking methods by string names is out as well. It uses objects for namespaces so things like `Shape.Quad.Square` get renamed to `Shape$Quad$Square` before getting minified to some one-letter variable, so don't use `this` outside of constructors or prototype methods.

There's a larger list of restrictions at https://developers.google.com/closure/compiler/docs/limitati...

If you do write code obeying these rules (check out the closure library), or you use something like ClojureScript that generates straightforward, monomorphic, closure-compiler-compatible js, the payoff in both file size and parse/execution performance is pretty great.

Often recommended, but Anne Lamott's Bird by Bird and Stephen King's On Writing are both autobiographies wrapped in textbook sheepskin. Writing advice that may seem obvious or trite is then backed up with beautiful vignettes.

Good writing is not necessarily good speech, as you've noted. Learning technical writing is a superpower — I would recommend The Essentials of Technical Communication. A chemistry teacher once introduced it alongside a Vonnegut quote:

"It would never occur to me, to look for the best minds of my generation in an undergraduate English department anywhere. I would certainly try the physics department or the music department first."

Technical writing and writing for emotional impact both have their place. Learn both, and learn when to employ them. You may find yourself appreciating that Thoreau quote one day.

I've found http://www.ccs.neu.edu/home/matthias/HtDP2e/ to be the best resource to drill the "code as data" mindset necessary for Lisp programming. And I would recommend going through as many exercises in http://sarabander.github.io/sicp/ as possible using the Racket IDE: https://docs.racket-lang.org/sicp-manual/index.html

https://github.com/aarongustafson/jekyll-crosspost-to-medium is a fair option if you have a Jekyll blog. Many static site generators include an idea of "publishing targets", and often include an easy way of making plugins.

Dead code removal relies heavily on writing JS in a style that allows for static analysis. Dynamic requires, heavy usage of closures, knowledge of external/global variables are all things that prevent a lot of commonjs code from being removed. https://developers.google.com/closure/compiler/docs/limitati... has more information if you're interested in the assumptions that the compiler makes.

Interestingly, we're finally starting to see these ideas get more mainstream as people adopt es6 modules and publish bundled code with explicit externs in tools like Webpack 2 and Rollup.

littleBits | Software Developer | NYC | littlebits.cc

littleBits is a company aiming to get the world inventing. We make an award-winning system of modular electronics. Our kits have been integrated heavily in STEAM education programs and we are dedicated members of the maker movement. We aim to teach kids of all ages about systems thinking, empathy, and curiousity.

Our roots have been in hardware, but we are starting to rely more and more on software to enhance the system. We recently launched an iOS and Android app to allow you to control our Bluetooth LTE bits wirelessly. We also make a small internet-connected bit and run our own internet-of-things cloud to back it. Right now we are working on a programming-based kit that runs on top of our Arduino bit.

As a small team of software developers, we choose sharp tools and aim to keep our stack small. We enjoy a services layer written in Scala. Our main client is a Rails application that powers our community invention platform. Most UI work is done in React. A lot of our embedded systems work is C. Our IoT cloud is Java and a bit of Go.

If any of this sounds interesting to you, don't hesitate to get in touch at [adrian.schaedle@littlebits.cc]. There's a tremendous amount to do; ideally you have experience. Most of all though, we hope you're warm, understanding, funny, and committed to the cause.

Are there any alternatives to TodoMVC out in the wild?

I rather like https://github.com/staltz/flux-challenge myself, but I wonder if there are any other projects that are focused on more complex examples.

littleBits | NYC | Software Developers | Full Time | littlebits.cc

littleBits is a company aiming to get the world inventing. We make an award-winning system of modular electronics. Our kits have been integrated heavily in STEAM education programs and we are dedicated members of the maker movement. We aim to teach kids of all ages about systems thinking, empathy, and curiousity.

Our roots have been in hardware, but we are starting to rely more and more on software to enhance the system. We recently launched an iOS and Android app to allow you to control our Bluetooth LTE bits wirelessly. We also make a small internet-connected bit and run our own internet-of-things cloud to back it. Right now we are working on a programming-based kit that runs on top of our Arduino bit.

As a small team of software developers, we choose sharp tools and aim to keep our stack small. We enjoy a services layer written in Scala with Akka as guiding framework. Our main client is a Rails application that powers our community invention platform. Most UI work is done in React. A lot of our embedded systems work is C.

If any of this sounds interesting to you, don't hesitate to get in touch at [adrian.schaedle@littlebits.cc]. There's a tremendous amount to do; ideally you have experience. Most of all though, we hope you're warm, understanding, funny, and committed to the cause.

I've had a painless time setting up my mac with https://github.com/msanders/cider

That's why the distinction is so lovely. Same identity, different value. State is a snapshot of an identity at some point in time.

And unopinionated. It takes a tremendous amount of listening, polishing, and gardening to arrive at what github has built.

For B, https://pragprog.com/book/vmclojeco/clojure-applied is very nice if you are coming from a traditional Java or OO background, and if you are familiar with design patterns but are wondering how to structure your code in a language style that is unfamiliar.

Fairly well! https://github.com/JeanMertz/chruby-fish

om.next lifts some great ideas out of Relay and Falcor. All three libraries share the assumption that components should describe the data they want, in the shape that they want it in. A querying layer is then responsible for for maintaining a local cache of the data, fetching it from the server when it's not available in the cache, and updating the components that are subscribed that data when it changes. This leads to some really impressive performance optimizations (only parts of the page that depend on new data need to be updated) and some very impressive server-side caching characteristics (om.next can use HTTP for caching because the data is normalized).

More of a fun experiment than anything else, but the Pig Shell is worth playing with:

http://pigshell.com/

Not to mention idempotent code is trivially memoized, allowing you to skip computations you couldn't previously reason about. A function that produces a value is always comparable to another value — a function that modifies some state requires that you have a way to observe that the world changed in order to skip doing it again.

That's a bit unfair — you're talking about an expository and introductory Medium post. Compare that to the first sentence of the guide itself:

  Open source UI components and visual style guide to create consistency and
  beautiful user experiences across U.S. federal government websites.

The thing that always stops me from making something similar to this (other than willpower and interest) is: how do you enforce constraints on the data? How do you keep it from accumulating junk data if you're cutting out the role of an application validating it?

It could be that this is really only for directly-mapped CRUD data, but I haven't seen a lot of applications out there that don't require at least a little bit of integrity checking.

I'm not sure I'd agree that those are examples of people fighting React though — using it on the client and server allows you to never duplicate markup you might have in a component with markup in a template, for example. The case for writing your entire UI in React is pretty strong actually, as it's just a matter of where you create the data to pass down to your tree of components: once, on the server for a complete page load, or incrementally and dynamically on the client.

There are some cases though where the component model feels strained — consider components that act as a pass-through for debouncing data, components that implement routing as a tree of routes and handlers, or components that perform data-fetching. Perhaps it's that the community hasn't found the right APIs for these higher-order components, but it's hard to argue against using React for a stateless tree of UI components.

There's a benefit to teasing apart two ideas here:

- writing functions that expect immutable data (you get referential transparency and value equality → a system that's easier to reason about) - using persistent data structures (makes it cheap and efficient to create new changes to your data over some messy Object.assign helpers)

Javascript doesn't promote applications written in that style though, so you're definitely going to want to use a library like Immutable.js everywhere for those kinds of guarantees.

Should have started with a service-oriented architecture, then their civilization would have never collapsed.

It's a very cool feature of Datomic that the storage engine is pluggable, and easily changed depending on the characteristics of your data. Using Postgres is trivial:

http://docs.datomic.com/storage.html#sql-database

Inconsolata-dz is a great font, though I recommend

https://github.com/DeLaGuardo/Inconsolata-LGC

for fans of Inconsolata that would like bold and italic weights, as well as extended glyphs.

I'm getting really sick of these monad tutorials

Reagent presents a very simple api at the expense of a lot of complex/magical bookkeeping to link components and their update cycles to a framework-specific application atom. If you're really looking to demystify how clojurescript can wrap React, I can't recommend reading through the source code of Quiescent enough:

https://github.com/levand/quiescent/blob/release/src/quiesce...

That said, I've really enjoyed Reagent for prototyping, and the magic is the good kind of magic. It's just that Quiescent feels so much like a clojure library, trading ease for simplicity — and is often a better brick to build your own abstractions on top of.

Nikita Prokopov has presented a pretty cohesive vision for front-end programming in the cljs community. Even if you don't agree with all of his opinions, he's one of the only people assembling a big picture about how to write apps in this way. It's worth reading his blog:

http://tonsky.me/

An emphasis on low-level tooling and not enough discussion around high-level architecture/examples has hurt the react+cljs combo adoption from my point of view. It's the nature of Lisp to come up with your own abstractions around application architecture, but the community would be wise to talk more about solving common web patterns and how to cleanly break away from those patterns when necessary.

Great question! Actions should be thought of as a mapping between some mechanical UI event (typing in a form, clicking on a button) and an event with some meaning in your application ("user typed a hacker news comment", "user submitted a reply to this comment with this text"). Whatever your application data store abstraction is, it should be responsible for taking that meaningful event and figuring out what to do with it (check to see that the message isn't empty, check to see that the comment was persisted to the server).

Actions describe things that happened in the world and the role of your store is to figure out if that thing that happened is valid or not, and pass the necessary data to components listening for changes.

Actually, custom getters and setters exist in ES5:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

AmpersandJS, for example, implements its observable pattern in this way:

http://ampersandjs.com/learn/state

That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data structure that allows for efficient diffing — which nicely mirrors the diffing react does with both it's internal component tree and diffing with the DOM — is a much more straightforward approach. Just re-render your application 60 times a second, like a game engine, and make that process as efficient as possible.