I've learned many of these things on the job and even more in my spare time for fun. Right now I'm living w/ the cognitive dissonance of concurrently loving programming in Go and Haskell. I've built many JS SPAs, managed DevOps for multi-data centers, countless APIs in various languages, ETL jobs, lead teams & hired/interviewed, and always thinking architecturally and at a system level. I love what I do and love learning all things related to software development.
Thanks for the compliment and please do submit an Elixir version. I'm played around a bit with Erlang/Elixir but not substantially. I try to follow the Elixir community a bit and have done extensive reading of the OTP/actor system in Erlang :) Also, one of the reviewers of the article, Daniel Farrell, does Elixir for fun: https://github.com/danielfarrell/sass.ex.
Regarding test suites: yeah, I agree but it's a first pass and right now the "test" is "does running the program produce the correct output?" and that's sufficient for now:)
that "test" is literally 1 step away from a "proper" test :) Slap an "assert_equal" in there and boom, tested! Or heck even "raise unless expected == actual"
Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far.
Also, your comment, to me, shows there is still some confusion regarding Om's internals:
> However, this relies on being able to listen for state change from the underlying model data. [...] Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.
Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.
Interfacing with an external js library that publishes changes would be trivial though. Typically if you're building a ClojureScript app you're building a ClojureScript app... which means using atoms.
A hacker is a person that loves to program, or someone who enjoys playful cleverness, or a combination of the two.[3] The act of engaging in activities (such as programming or other media[4]) in a spirit of playfulness and exploration is termed hacking. However the defining characteristic of a hacker is not the activities performed themselves (e.g. programming), but the manner in which it is done: Hacking entails some form of excellence, for example exploring the limits of what is possible[5], thereby doing something exciting and meaningful.
Just kind of a walk-through. I think part of it is that I can't fully force myself to read it as code when it's written poetically like that, so even syntax conventions I fully get are causing my eyes to glaze over.
Remote: Yes
Willing to relocate: For the right opportunity.
Technologies:
* Languages: PHP/Ruby/JS/Go/Scala
* Front-end: Backbone/React/Elm/Boostrap/Foundation
* DevOps: Puppet/Ansible/ELK/Riemann/Splunk/Grafana + graphite/Vagrant/Docker/AWS/OpenStack/nginx/HAProxy
* DB, etc: Kafka/Postgres/MySQL/Aerospike,
* For fun: Currently building a gossip protocol in Haskell: https://github.com/jpfuentes2/swim
Résumé/CV: https://www.dropbox.com/s/q1lohk24bj808ud/resume.pdf?dl=0
Email: jpfuentes2@gmail.com
I've learned many of these things on the job and even more in my spare time for fun. Right now I'm living w/ the cognitive dissonance of concurrently loving programming in Go and Haskell. I've built many JS SPAs, managed DevOps for multi-data centers, countless APIs in various languages, ETL jobs, lead teams & hired/interviewed, and always thinking architecturally and at a system level. I love what I do and love learning all things related to software development.