The document is limited, but it seems the basic interface is the same as WebDriverJs, and the protractor.js source-code can be used to identify the additional definitions in “ProtractorBy.prototype” parts.

Nice.

Notes

Default testing file defined in “myConf.js” is “spec/testAppSpec.js”, which needs to be created for your tests.

“Appendix A: Setting up a standalone selenium server” in the github page covers the webdriver setup, and then running “node_modules/.bin/protractor myConf.js” works.

It’s pretty much basic one, but the following is what I tried for testAppSpec.js.

It’s the Elixir version, following after the Ruby(EventMachine) and Go ones. Basically it ended up to similar as Go, due to the similarity of go’s channel and Elixir’s spawn/receive statements. There seems some differences in error handling between the two, but it’s not covered here.

Notes

Good

Elixir’s pattern matching provides polymorphic mechanism. After getting used to this functional concept (no if statement and no loops), it might gets interesting to write codes.

Calling Erlang’s library is not so difficult. It provides some sense of comfort when facing issues (there would be some reasonable solutions).

Bad

Error messages are sometimes cryptic. When child process dies with error, error is presented in weired form, though it has information of locations of error.

Just trying out Elixir (http://elixir-lang.org/) using above book and screencast, as part of my concurrency series.

It’s functional programming language. I had been avoiding the purely functional languages after I studied Lisp at school, and only relationship with them was copy-pasting emacs lisp.

However, Elixir seems reasonably well structured for beginners with the essence of Ruby, while keeping the power of underlying Erlang VM. The official documents are still limited, but the book “Programming Elixir” provides a good guidance for understanding the interesting paradigm of this language.

Then the “Meet Elixir” screencast presented by José Valim describes good insights of background philosophy of Elixir, which is pretty much interesting and quite different from the standard object-oriented ones. The contents are relatively presented fast, so maybe it’s good to start from the book.

The power of Elixir would come out on the concurrency part – featured by Erlang VM. The following example (it’s from the book, though slightly modified) spawns 10000 processes, and each process counts up one. It just takes sub-second, interesting.

$ elixir chain.exs
time = 122ms, msg = Result is 10000

chain.exs

defmodule Chain do
@moduledoc """
Spawns Erlangs's lightweight processes for counting up numbers.
"""
# When receiving a number from the previous process, 'receive' block is executed with number 'n'.
# Then, propagate the 'n + 1' to the next process.
def counter(next_pid) do
receive do
n -> next_pid <- n + 1
end
end
# Creates 'n' number of processes to count upto 'n'
def create_processes(n) do
# loop 'n' times to spawn processes, then returns the process id of last one, which comprises
# of 'n' process chain starting from 'self' process.
last = Enum.reduce 1..n, self,
fn(_, send_to) -> spawn(Chain, :counter, [send_to]) end
# send the initial number 0 to the last process.
last <- 0
# wait for the 'n' length propagation to complete back to 'self'
receive do
final_answer when is_integer(final_answer) ->
"Result is #{inspect(final_answer)}"
end
end
# Execute the process creation with the timer count.
def run(n) do
{time, msg} = :timer.tc(Chain, :create_processes, [n])
IO.puts "time = #{div(time, 1000)} milliseconds, msg = #{msg}"
end
end
# spawning 10000 processes which each counts up one.
Chain.run(10000)

This book covers fundamental mechanism of computation, like automaton or turing machine. Though it’s a kind of text-book topic, this book brings a fun out of it through implementing interpreters for a simple language, using Ruby.

Ruby is popular for implementing DSL, but this book is going further on implementing programming language itself. I once learned this kind of topic while I was in university, but I’ve almost forgotten most of them. One of the reason was maybe I felt a little boring at the time, just with mathematical theories.

Actual code works.

It’s a lot of information covered in this book, and I haven’t been able to read through the book yet. But, I definitely would like to take time to try-out each of the examples.

The costs for testing takes major part of the development, and also there’s no way to verify the 100% complete. Therefore, identifying the method that maximize the cost-performance is crucial. This session talks about the practical way to limit the scope of unit-testing, based on the message types (query and command), their directions (outgoing and incoming).

Good part of the unit-tests is that they perform the important role on quickly identifying the mistakes in the code. However, there is also a bad part that the maintenance costs (especially for the flaky ones) can prevent the fast development. This kind of scoping is a good one to apply.

Too much focus on enforcing basic rules could reduce the productivity, and it may be good to have this kind of exception under some conditions and rules.

There are many scenarios that simple rules cannot cover the real situations, like existing code-base that doesn’t have tests, or some difficult codes to test. Technically speaking, most of the cases may have solution, but sometimes it’s not practical, due to various reasons (lack of time, lack of skills, etc). Putting a decent fallback plan over the fundamental rules would be an important factor.

Notes

Test incoming query message by asserting the query result.

Test the interface not the implementation.

Test command message by making assertions about direct public side effects.

Don’t test private method, as it’s redundant and easier to break. However, temporally breaking this rule can save your time.

For outgoing command message, confirm the message is sent using “expect” of mocks.

It’s amazing. As indicated, AngularJS’s 2-way binding is extended into multi-clients by just adding a hook for Firebase. The Firebase nicely handles both persistence and notification with a simple interface. There’re some applauses in the demonstration (around 10:00-11:00), and I would make a similar response.

One more concurrent server topic, following to the previous post – EventMachine – UDP Server Example. As I sometimes hear that GoLang (Go Programming Language) is good for concurrent programming, I just tried on the similar logic.

After struggling on the fact that “learning a new language is tough”, I could manage to make the code work as follows (I was looking for some ways to simplify the code, but I gave up…).

Server

% go run server.go
2013/07/17 00:41:23 Completed in 5 second with param = A
2013/07/17 00:41:24 Completed in 5 second with param = B
2013/07/17 00:41:26 Completed in 5 second with param = C
2013/07/17 00:41:31 Completed in 1 second with param = E
2013/07/17 00:41:34 Completed in 5 second with param = D
2013/07/17 00:41:36 Invalid command is specified

Client

% telnet localhost 5000
Trying ::1...
Connected to localhost.
Escape character is '^]'.
LARGE A
LARGE B
LARGE C
Completed in 5 second with param = A
Completed in 5 second with param = B
Completed in 5 second with param = C
LARGE D
SMALL E
Completed in 1 second with param = E
Completed in 5 second with param = D
xxx
Invalid command is specified

‘Personal’ Impression

The language is interesting, but there’re some good/bad parts. Actually, I haven’t been able to find the good spot to use this language yet. It would be more concise than Java/C++, but not sure if the good parts are large enough to switch from script languages like JavaScript or Ruby.

Good

Rigid static analysis of codes, which catches many errors at the beginning. For example, if the imported package or defined variables is never used, it throws an error (rather than warning).

Fast compile time. It’s fast enough to start executing, which may be comparable to script languages (not the same, but good enough).

Concept of asynchronous/concurrent execution is interesting, and built-in features (go/channel/defer) would work nicely once we get the concept.

Bad

Though basic language concept is similar as standard C++/Java based language, there’re too many small differences (keywords, statements, etc.). It may be better than Objective-C, but may not be enough to get accustomed to it easily.

Object Oriented Programming is supported (GoLang Tutorials), and inheritance/polymorphism can be applied. However, the separation between data (struct) and methods makes me feel like it’s not fully integrated. For example, JavaScript doesn’t have class concept, but it can be defined like class (variable and methods) through some idioms (or use CoffeeScript).

In the if/else statement “} else if”, putting line-break between “}” and “else” throws “unexpected semicolon or newline before else” error. I personally don’t like this style.

One more EventMachine. Just tried to write a simple chat server using “em-websocket” gem (WebSocket server written over EventMachine). Client part is a simple HTML with AngularJS. It’s just wrapped around the native WebSocket object (couldn’t provide strong interaction with AngularJS).

Referenced Documents

It describes the integration with angularJS and Socket.IO. Also, the angular-socket-io-im referenced in the document just works nicely with node.js server.

The above example doesn’t use this library, as I couldn’t make it work (at around loading related libraries). The Socket.IO examples are almost always being used with Node.js, and I didn’t have enough knowledge on that part.

EventMachine is an event-driven I/O and lightweight concurrency library for Ruby. It provides event-driven I/O using the Reactor pattern, much like JBoss Netty, Apache MINA, Python’s Twisted, Node.js, libevent and libev.

PeepCode has nice screencasts for the EventMachine, and I coded some examples based on that.

The previous post was about a simple UDP server to handle user-specified jobs. I wrote similar feature using EventMachine as follows. The server accepts jobs like “SMALL” or “LARGE” which takes several seconds to complete, and then responds with a message. In the following example, standard “nc” command is used for the client part.

With EventMachine, asynchronous job handling can be simply implemented with the event-driven model. It also just works concurrently. It’s nice.

Server

% ruby server.rb
2013-07-14T00:40:00+09:00 : Received LARGE A
2013-07-14T00:40:02+09:00 : Received LARGE B
2013-07-14T00:40:03+09:00 : Received LARGE C
2013-07-14T00:40:05+09:00 : Completed in 5 second with param = A
2013-07-14T00:40:07+09:00 : Completed in 5 second with param = B
2013-07-14T00:40:08+09:00 : Completed in 5 second with param = C
2013-07-14T00:40:35+09:00 : Received LARGE D
2013-07-14T00:40:36+09:00 : Received SMALL E
2013-07-14T00:40:37+09:00 : Completed in 1 second with param = E
2013-07-14T00:40:40+09:00 : Completed in 5 second with param = D
2013-07-14T00:40:54+09:00 : Received XXX
2013-07-14T00:40:54+09:00 : Invalid command is specified

Client

% nc -u 0.0.0.0 9000
LARGE A
LARGE B
LARGE C
Completed in 5 second with param = A
Completed in 5 second with param = B
Completed in 5 second with param = C
LARGE D
SMALL E
Completed in 1 second with param = E
Completed in 5 second with param = D
XXX
Invalid command is specified

It’s great presentation which talks about refactoring the code by showing examples. The actual refactoring part is 20-minutes or something, but it has a lot of nice viewpoints. Defining the roles of modules and their interactions are the key factor of designing maintainable codes. Always, actual example-code works well understanding the concept.

One concern point (which I felt) is some of the classes are cross-communicating each other, making the class relationship a little complex.

(e.g.)

PushDaemon <-> UDPServer

UDPServer <-> Client <-> Job

Worker <-> Job

These classes are arbitrarily calling the other one’s method. As ruby’s duck typing doesn’t define the specific interface, it’s a little difficult to identify the method call-graph. Maybe, at least for the 1st item, instead of calling pre-fixed method each other, apply observer pattern (subscribe/notify) from one side makes it clear about their relationship?