Building up a simple test runner by example. It’s a great way to explain how the testing framework is doing. The testing framework is relatively simple for most of the scenarios. Learn by doing is a good practice.
The Changelog podcast is interviewing with Matz this week. I had listened many Matz interviews, but this is one of the good ones to intensively covers the origin and early history of ruby. Even now, new languages are keep appearing after years of computing history, and it’s good to know how the languages are born and grow.
It was a great course which covers wide range of topics around testing in golang. I once saw some descriptions that golang has very simple verification syntax, and I was assuming that it only has limited testing functionalities. It was wrong and golang comes with various and extensive toolsets for testings.
Among the topics, what I found interesting are,
- Blackbox Testing
- “testing/quick” package (https://golang.org/pkg/testing/quick/) provides utility functions to help with black box testing. It’s kind of property-based testing, which verifies against randomly generated values.
- Example Testing
- Examples can be used for both documentation and behavior verification (https://golang.org/pkg/testing/). It’s kind of doctest with nice StdOut hooking.
- Performance Profiling
- pprof (https://golang.org/pkg/net/http/pprof/) tool can provide very detailed and graphical analysis of performance bottlenecks.
Other languages have similar functionalities, but these ones in golang sounds simple and solid, and I would like to try out.
As an exercise for catching up latest Phoenixframework features, I’ve updated an fairly old heroku app to the latest (v0.4.0 -> v1.1.1) version. It was harder than expected, and leaving some struggle notes here.
- Basically, the official document (http://www.phoenixframework.org/docs/heroku) covers the procedure to deploy phoenix application to heroku.
- Struggled on the error around missing
config/prod.secret.exswhich is described in the document.
- Also, there’re some configuration settings required around
config/prod.exsand it seems difficult to apply heroku button with fixed parameters.
- As phoenix requires node verison >= 5.0, and
phoenix_static_buildpack.configneeded to be specified by following the buildpack README description.
- Struggled on the error around missing
- The controller’s
json/2expects data model which
Poisoncan encode into JSON (changed from JSON data itself). I was using
exjsxand needed to change the data accordingly as keyword lists couldn’t be encoded.
- Reloading pages seems not working on Chrome + Ghostery, and just showing blank. It was confusing for isolating the issues.
- New asset compilation with
Brunchwas a difficult for me, as I don’t much experience on JS developments. The js files using global variables (highlight.js) needed to be stored in
vendordirectory instead of
jsas in the following document.
Anyway, re-realized upgrading from actively developed v0.x.y framework is very hard…
I once configured elixir build at CircleCI (Elixir on CircleCI), but haven’t been able to update it. As some of the builds are failing, I’ve updated the configurations as follows.
CircleCI doesn’t seem supports erlang/elixir builds, but there’s nice library (asdf) to configure specified versions of them. The 1st time build takes time, but caching works well and 2nd time or later becomes fast enough.
Continuing to read the book and additional notes are,
- Asynchronous interfaces helps decoupling modules and provides horizontal scalability.
- Location transparency – By writing the application in a distributed manner, even for the local processing, your application can become resilient to the failure. It makes writing tests easier too.
- Akka’s Actor systems (http://doc.akka.io/docs/akka/snapshot/scala/actors.html) provides simple interface for message passing between components. It provides simple interface and it makes it easier to tests through stubs/mocks on the interface.
- You need to work with non-determinism in distributed systems. One approach is explicitly synchronize for avoiding ordering issue. The other is to avoid/isolate computations which will be affected by the computation order.
- Back-pressure and flow control becomes required between components. Reactive stream (http://www.reactive-streams.org/) is one way to control flow.
- Netflix is building Chaos Monkey which randomly disabled production instances for ensuring system resiliency (https://github.com/Netflix/SimianArmy).
This book covers various concepts and methodologies for building solid system in a distributed manner. Also, the examples written with Scala is relatively simple and good to understand.
Also, the following coursera courses covers similar topic and would help gaining knowledge on this topic too.
Just started reading the book (2 chapters), but it seems to contain various good insights.
The reactive systems are gaining popularity these days along with the trends in computing like hardware (cpus/cores architecture) and software (granular computing resources – virutal machines or containers).
The reactive systems provide scalability and resiliency, and the need to be designed from ground up. The traditional synchronized processing fundamentally limits the scalability of applications and resilience to the failures. By designing the asynchronous processing on distributed computing resources in to the system, the handling becomes part of the scenario.
Some notes so far are,
- One difficult aspect of distributed system is caused by the partial failure instead simple all or nothing.
- Aiming for fault tolerance instead of just avoiding failures, are more reasonable approach, as completely avoiding failure cannot be fully successful. Providing resilience goes one step further from tolerance which aims for recovering to original state and functionality.
- Distribute and compartmentalize are the only generic methodologies to protect the whole system from failing. However compartments are not fully isolated, the failure can cascade and result in a whole system down (ex. partial failure overloads the system and chains into to the system down).
- Supervision is one way to provide resilient system. If the bending machine is broken, you will be calling the maintenance operator instead of trying to fixing by itself.
Just read the Kotlin book after listening to the Fragmented podcast with JetBrain engineer which mentioned in the previous post (Watching – Mouseless driven development).
I heard of the language several times, but didn’t have chance to look at it. This time, I made up mind to investigate more.
The Getting Started with Kotlin in 2 minutes is a good introductory video for understanding its syntax and behaviors. Kotlin works on JVM and its concept and syntax are mainly coming from Java, but also good parts of Scala or Groovy is incorporated and making it modern language.
Scala has powerful extension of type-safety and functional-programming, but it’s a little too complex. Groovy has concise syntax and good productivity on small programs, but it’s a little too loose to cause dynamic exceptions like NullPointerException. Kotlin seems going between the two, and if the balance is good, it may be worthwhile to dig in deeper.
Just watched a funny and interesting presentation on mouseless operation of IntelliJ, which was referenced at Fragmented podcast. There’re various good tips introduced for more efficiently operating IntelliJ products.
I love using IntelliJ for JVM-related programming and usually applying keyboard-centric operations, but this presentation realized me that I wasn’t fully utilizing its power. Search and navigation through keyboards are very powerful.
Just completed reading through the B2.0 of “Programming Phoenix” book during the weekend. I hadn’t been able to use phoenix some time since pre-1.0, but this book was a good material for catching up the latest features.
The book starts with the strong statements about the benefits of phoenix and underlying elixir, as in the subtitle – Productive |> Reliable |> Fast. Then, the main content explains the features by gradually building up simple and concise application called Rumbl. Building up standard CRUD operations to user models backed by Ecto with postgreSQL DB, and implementing authentication using the model didn’t take long and it was a good exercise.
Definitely looking for the remaining part to complete, which includes the web-socket channel.