Blackcoat's Daughter

Review: The Blackcoat’s Daughter

The Blackcoat’s Daughter is a slow-paced, mysterious narrative where you need to figure out for yourself how the pieces fits together. It’s not a type of horror movie that relies on sudden increases of audio volume and other clichés associated with horror movies (OK, maybe there’s one which I mention at the end of the next paragraph). Instead working on a shock-value and a jump-scare it does so in the vein of terror. It features boarding school for girls and a demonic possession, two core settings of horror movies. I have really enjoyed the movie and rated it 8/10.

There are various theories circulating the internet about the plot/it’s ending and I think the true one is that at the end of the movie Joan (grown-up Kat) is incredibly sad because the offerings to the demon, probably Satan himself, didn’t work in terms of her being repossessed and is thus left alone. Joan is played by Emma Roberts and she is the reason I’ve decided to watch the movie after seeing it’s announcement on a local cinema’s schedule for a Halloween night. But the actress Kiernan Shipka who plays Kat (she’s actually nine years younger version of Joan) and whom the movie is revolving around, steals the show. We also have another girl, Rose (Lucy Boynton), in the same timeline as Kat’s, with the mentality of your average girl in horror movies – young, beautiful, gets killed when investigating strange sounds like she never saw a horror movie before.

After finishing the movie I wondered for a moment why the writers opted for two different actress playing the same character. I know that the answer is to make story more mysterious and appealing to viewers. Related to that I believe parents of Rose should have recognized the killer’s face albeit being nine years older. It’s not like she underwent a plastic surgery while being locked in a mental institution for all nine years. 😀

The Blackcoat’s Daughter is a directorial debut by Oz Perkins, a son of late Anthony Perkins (Norman Bates in Psycho). What’s a complete surprise in closing credits was the music score was provided by Elvis Perkins, director’s brother. The two of them also come up with a movie title since previous one was rejected by distributor who thought it doesn’t indicate a genre strongly enough.

Libraries over frameworks

Lately (in term of years) I noticed I prefer using libraries over frameworks. Or in other words I like to use packages that each do their one thing well rather than one package with all batteries included. I recognize both libraries and frameworks have their pros and cons.

You can see my preference for libraries if you are reading my blog where I write a lot about web development, specifically about React and Go. Well, Go is a programming language but because it has an excellent standard library, there’s actually no need for a framework.

The most obvious advantage of using libraries over frameworks I have are:

  • I have a freedom of putting all pieces of an application as I see fit and only those necessarily.
  • I can easily replace one piece after another, better option appears.
  • they take less time to learn.
  • feeling I have a control over them not other way around.
  • process of updating a library is less painful.

The biggest pain point is writing boilerplate after starting every new project. But this is solvable by maintaining your own starter/base/boilerplate. I don’t like using boilerplates from other people because they don’t fit my mental model (but that doesn’t mean I don’t like inspecting them for fresh ideas on how to I improve my own boilerplate).

Disadvantages of using frameworks I’ve experienced so far are:

  • hard to learn
  • developing in it I often don’t feel like a [insert a programming language] developer
  • learning specifics which are in general useless instead of core programming concepts, computer science that can be reapplied to every new project.
  • using only small subset of features or fixing a bug? Too bad, you have to learn all of it so that you might not break anything.
  • having to conform to specific mindset and way of doing things because framework is designed for doing things THAT way (convention over configuration).

I only enjoyed using/learning frameworks at the beginning of my career because I didn’t exactly know what a modern applications consist of. After years of learning how to architecture an application (folder structure, design patterns etc) on my own or from popular frameworks I became confident in doing them from scratch with the help of libraries that aren’t limiting my creativeness.

kotlin logo

Kotlin is so cool and easy to learn

I enjoy developing Android applications. When I’ve read couple of months ago Kotlin has been added as a official language to Android Studio I finally decided to learn it. Up to that point I had been hearing only good things about Kotlin.

I don’t know when I first heard of Kotlin but probably year and a half ago when I became interested in Android mobile development, again (“again” because I was having on and off relationship with Android because of my distaste for Java). It stayed in my mind because it’s developed by JetBrains, a company which develops software products that make programmers more productive at developing all sort of applications. I also own a licence for one of their products (WebStorm) and use couple of others that are shipped under free, so called community, edition.

Android Studio is official IDE from Google for developing Android applications which in fact is based on JetbBrains’ software.

Kotlin is a modern programming language that makes you write less code in Java. It’s not a new language but to me it looks like a language full of syntactical sugars for programming Java applications. It has good documentation which feels more like a guide and is easily comprehended.

There a quite a few things I like about it:

  • the way classes are instantiated with var/val without specifying new keyword (variable type if inferred from class used)
  • functional programming (have I already mentioned I like the paradigm??)
  • function extensions (I call this monkey-patching but without negative sound the term has in JavaScript world)

After reading few tutorials and official documentation, I decided to apply it by rewriting/refactoring existing app I’ve created a while ago to Kotlin. So that I have hard evidence how Kotlin simplifies code. I am comfortable with using a subset of Kotlin features at this stage. I also noticed Android Studio suggests to me from time to time a code simplification which happen to teach me something new about Kotlin.

The following deserves its own post but when I switched to Kotlin, at the same time I also incorporated Reactive Extensions into my development workflow (RxJava/RxAndroid). That’s because:

  • I way already familiar with Reactive Extensions from JavaScript,
  • it plays nicely with functional programming
  • it makes switching from main thread to another and back to main thread a lot easier (so app doesn’t freeze in event of long computations)
  • it makes dealing with new permission model introduced in Android 6 a breeze.

The best way of rendering a collection of items in React/Redux

In short

The best way to render a collection in React, backed by Redux or other similar library: store a collection as an object where key is item id and value is item itself. That way when rendering collection, pass only item’s id to the item component. Than in item’s connected component query a collection by item’s id you passed early. So something like this.

//Item.js
import React from 'react'
import {connect} from 'react-redux'

const Item = ({item}) => {
    // use item to render markup
}

const mapStateToProps = state, {id} => ({
    item: state.collection.data[id]
})

export default connect(mapStateToProps)(Item)
// Collection.js
import React from 'react'
import {connect} from 'react-redux'
import Item from './Item'

const Collection = ({ids}) => (
    <div>{ids.map(id => <Item key={id} id={id} />)}</div>
)

const mapStateToProps = state => ({
    ids: state.collection.ids // actual collection is obtained with state.collection.data 
})

export default connect(mapStateToProps)(Collection)

Storing collection as an object also improves performance of querying and deleting an item from it.

Longer explanation

When I began developing in React a few years ago I was rendering a collection of items this way:

items.map(item => <Item {...item} key={item.id} />)

Then Flux/Redux came in my way and I realized storing items in state as a list of items is inefficient as noted. That’s because querying a list is O(n) operation but querying an object only O(1).

Given that performance boost I was still rendering a collection as before only now I had to turn an object into a ordered list because .map() only works on lists. Imagine doing that after every render! Using reselect can improve this by only converting it to list when collection changes. But we can still do better than that.

Satisfying solution came after reading a blog posts about making React and Redux more performant together. The point I think was “don’t be afraid of using connect often and breaking reducer into smaller reducers”.

You can build object of (id, item) pairs yourself or use library like normalizr which normalizes input data according to provided schema and returns entities and result (ids).

The reason why I prefer this method over previous is also because I love to use functional programming in react/redux. I think those two are brilliant couple. But to make functional programming easier, I use utility libraries. The two most known are lodash/fp and ramda. Lodash/fp might be superior to ramda when it comes to amount of functions included but I love ramda more because of the documentation. It’s easier to find what you are looking for (in lodash/fp I need to look at two places).

I was indecisive though which one to pick and stick with before discovering this new way of rendering collection because ramda doesn’t support iteration over an object.

Context package in Golang

Go has a package named context in its standard library. It’s responsibilities are cancelations and carrying request-scoped data (but that doesn’t mean it’s only used in HTTP handlers). I’ve learned it in two parts. For a long time I used it only for storing request-scoped data in HTTP middlewares, but recently I’ve learned the rest of it – (1) how to set up canceling context and (2) acting upon receiving canceling signal from context.

Setting up canceling context

Setting up canceling context is easy. We can use context.WitCancel(), context.WithTimeout() or context.WithDeadline(). All those functions return resulting context and cancel function. When calling, cancel function will cancel context:

  • immediatelly if created with WithCancel or
  • after elapsed time if created with WithTimeout and WithDeadline.

WithDeadline and WithTimeout differ on how to specify time when cancel function sends signal to context’s Done() channel. WithTimeout expects time.Duration while WithDeadline expects time.Time.

Another important note is that when new context is created from existing, a parent-child link between contexts is created. This allows us if parent is canceled, its childrens are canceled too. So that’s why when we are creating a context we need to specify a base context (in most cases that would be context.Background() or in HTTP handlers, r.Context() where r is of *http.Request).

Acting upon receiving canceling signal from context

Here we acknowledge contex.Done() signal and cancel function/service that could take a long time to execute and for which we are doing all this context thing.

Acknowledging is easy because for this we use built-in select with at least two cases. One case is reserved for Done() and other for our function/service singaling that it’s done (as in it’s result is sent into dedicated custom channel). If our function/service is done before canceling signal then we return its return.

If Done() is triggered first, we also need to cancel our function/service so it stops eating system’s resources. This might be the most challenging part of all. For example canceling a request requires us to get a reference to its transport instance and call its cancelRequest. If we our service/function is implemented with third-party package, explore its API if some sort of cancelation is offered.

Simple example

Below is an example of canceling a request that takes too long to complete and we’d like to cancel it after timeout. We have a server that simulates long running task by sleeping

Than we have a client which sends request to server. On line 17 we create context with WithTimeout and then defering call to cancel. Function httpDo performs the actual canceling part.

You can start client with different timeout to see how client’s response differ if timeout is greater/lower than server’s response time.