{{site_title_here}}

Tag: programming

  • Creative Coding Domestika Course

    Instagram has been nudging me to take a programming course for a couple of months. Not that I frequently act on Instagram ads…. though there is this silly keyboard that I use, worthless earplugs, fake liquor, fake cocktails, a gaudy puzzle that we’ve yet to start…. OK… I’m a sucker, but I like excuses to make pretty pictures. I signed up for Making Visuals with JavaScript when Domestika offered it on sale for $10.

    Domestika offers arty courses, presumably for less-technically inclined people. The course looks to be aimed at less-experienced programmers, but I am interested in low-barrier projects to experiment with visually.

    Here are some notes from my first afternoon listening to the first course unit and messing around on my iPad.

    Writing Code on an iPad

    The rap on iPads that they are difficult to create new product certainly seems well-deserved, at least for writing code. To start, Chrome for iPad seems brain-dead in comparison to the desktop, and even Android version; the relevant complaint here is that there is no “Developer Tools” pane to inspect the console, inspect or edit document elements, or to experiment with code…. I’ll save the rest of my Chrome-for-iPad rant for later.

    The text-editor iPad app genre seems to be barren. Maybe there’s less motivation to use a text editor when it’s difficult to aim a browser at a local file or directory even. The experimentation cost, like most iPad apps, is substantial, with the dearth of free apps at the App Store.

    I did end up finding a workable solution in JavaScript Anywhere, which bundles a stripped-down text editor, a browser suitable for previewing your work, and a web server– mostly for use to copy your work to another machine. The side-bar ads are annoying and the syntax highlighting and auto indent don’t work, but it’s an OK solution if you’re just looking to experiment. One nice feature is the starter templates, which, for example, create file stubs to quickly bundle your mark-up, code, and style files.

    For further coursework, I will move on to the desktop.

    JavaScript Canvas

    The course begins by using the JavaScript Canvas as motivation to use variables, arrays, and loops. The presentation is a little breezy with respect to explaining how to access the browser document and the difference between declaring a function and assigning a closure to a variable, but it’s enough to get a motivated student hacking.

    Below are some quick demonstrations for drawing an arc and filling a rectangle. The basic pattern seems to be:

    • Get the graphic context from the document canvas. (Only use one canvas in a div, unless you know what you’re doing.)
    • Set your fill style, line width, etc.
    • Issue context beginPath().
    • Draw your shape using the context object methods.
    • Issue context stroke().

    More-programmatic Drawing

    The course concludes with practices to parameterize your image to allow for experimentation and dynamic fitting. One tool, not demonstrated here, is canvas-sketch, which sets up a web server to watch your files and update active browsers, as well as handling dimensions.

    Below I’ve messed around with the lecture demo by adding jitter to the square placement and looping painting to better demonstrate the probabilistic layout.

  • Attractors Returned

    About a month ago, I posted an in-flight doodle of an attractor, which turned out to be a spirograph. I’m returning here with the correction for a Clifford attractor.

    The result plots a constellation of points, rather than a path — consecutive points in the series are not necessarily close to each other — so many iterations (say 25,000) might be required to paint a “pretty” picture.

  • React, Redux, and Typescript

    Talking with a react-redux user earlier this year, I thought I should probably get with the program and learn some sort of state-management framework. I’m posting my notes from getting started with Redux applied to React and Typescript, hopefully so others and my future self can quickly jump into the ECMAscript pot-pourri.

    Redux

    The react-redux primer provides a gentle introduction to a rather disjointed framework. Honestly, Redux looks like it was extracted from a webapp following good design patterns without much regard to usability on the framework for developers outside the original project.

    Redux prescribes a framework to

    • use “immutable” application state objects (there’s no enforcement of immutability)
    • invoke actions as pure functions to build a new state from a previous state
    • store and dispatch actions for agents/components/etc driving state changes and agents/components/subscribing to state changes to respond.

    The result compartmentalizes all of your application logic from presentation, making things easy to compose and test, though not necessarily to read. Much of the processing in Redux just building objects to represent state or dispatch and there’s no support from ECMAscript to flag usage errors, so it’s easy for users make mistakes wiring up components or violate “immutability”.

    To add to any confusion documentation overloads the word “action” to mean a token describing which action to take, a factory to create the token, and the actual processing action. Combined with React, the term “state” is overloaded, sometimes denoting application state driving Redux, and sometimes the changing qualities of a React component, driving rendering.

    Mix in Typescript

    With the far-flung objects and files, having some compiler help would seem appreciated. In fact, using Typescript detects a lot of wiring mistakes early, but with several costs, especially since the Redux-with-Typescript introduction is pretty thin.

    Experimentation

    My experience incrementally adding Typescript to a sample project illuminated several benign mistakes, mostly surrounding polluted types. It’s easy to conflate the React properties of simple React components and those wired for Redux, or just to omit the former and use exclusively the latter — don’t do it!

    The benign mistakes are infuriating, since an app made with create-react-app will initially render and run…. and then halt once the Typescript compiler finds an error. The prevalence of these sorts of errors might discourage one from experimenting or refactoring. On the up-side, at least the default set up for unit-tests with Jest is more lax than the app served by react-scripts start.

    Versioning

    React has gone through so many versions and patterns, it can be difficult to align your usage with documentation and examples… and type definitions! Especially with the onset of React render and useState hooks, and the lag in update to declaration files.

    Dealing with Dynamic Types

    Redux leverages dynamic typing in ECMAscript to compose state and reducers as well as to decorate/inject React components with actions. The result can be a nightmare of tangled union types for you and the Typescript compiler.

    Where the Rubber Meets the Road

    Redux builds React component properties with react-redux.connect() a curried function taking two parameters, usually called mapStateToProps and mapDispatchToProps, each functions as well.

    Components respond to state changes with mapStateToProps(), which translates the application state to component properties. At minimum, the function should pull out the relevant fields to build some of the property fields for the component. Make sure to forward along only fields relevant to the component, as the Typescript compiler will infer types and throw an error if the JSX instantiating the component is missing the field.

    The dual to mapStateToProps() is mapDispatchToProps(), which allows components to forward messages to the reducer for state updates. The property fields that the function builds are methods to which components wire DOM events.

    You build a regular/simple React component, which you then pass to connect() which is used by react-redux to build a factory to create connected React components. It’s useful to distinguish simple from connected component classes, especially the property types used by the two:

    • You will export the connected components for JSX use. The connected components will likely have simplified properties, probably (hopefully) silently inferred by the Typescript compiler.
    • The simple components have all the property fields, which you will explicitly define, many of them actions, used to wire up and respond to DOM events.

    Tersely, mapStateToProps() provides property fields used for rendering; mapDispatchToProps() provides property fields that are functions to drive state changes. The union of the two should fill out the simple component property type.