Monthly Archives: October 2013
The above is a nice session video which talks about the Ruby’s functional programming aspect, by comparing it with Haskell. There’re many topics are covered, but I found interesting about the quick sort and fibonacci examples.
In the beginning, Haskell’s quick sort example is mentioned, which is mostly the same as in here (http://www.haskell.org/haskellwiki/Quicksort).
I tried with similar approach on Elixir as follows. They’re concise and intuitive with the power of functional programming language, nice.
At around 35:29, Haskell memorization is described. I knew the term “memoization” previously, but didn’t know much about its meaning. After learning the functional languages, I’m getting to understand the concept of the no-side-effects and the purpose of the memoization.
The memoization is described in here (http://www.haskell.org/haskellwiki/Memoization). I haven’t been able to fully understand them, but the concept of remembering/reusing the function inputs/outputs along with the lazy evaluation sounds interesting.
Elixir has “Stream” for lazy evaluation, as similar way as Ruby. As it’s not natively integrated as much as Haskell, it requires to separately store the calculation results for memoization. The following has nice discussion and some example codes on this topic.
The more frequently I’m using Git, the more I’m getting fascinated by its well designed architecture.
In the session, he’s manually manipulating the branch (around 40:00), which is just a simple text file that contains the SHA-1 hash of the commit. That’s pretty much interesting, considering the pain of making branches on the standard version control systems. Another compelling part is the structure of git objects (around 19:40). They are comprised of tree and blob, and they’re referenced by commits. It’s a good example of functional way of immutable object operations, which provides very solid data manipulations.
It’s a nice introduction to a lot of NoSQL databases. Though it’s opinionated, it well captures the good/bad points of each databases. Among of them, Visual Guide to NoSQL Systems topic (around 7:40) was interesting (it may be an old one, but I didn’t know).
This theorem talks about the characteristic of the distributed systems, which indicates the system can provides only two of the three (Availability, Consistency and Partition Tolelance) attributes. Brewer’s CAP Theorem page has detailed explanation.
As the distributed systems are getting popular, this kind of failure scenario consideration would be gaining importance. As the triangle picture indicates, tranditional DBMS were focusing on providing consolidated datasource, and didn’t provide much distribution which can causes partitions. Now, everything is getting distributed, and variety of options are being provided.
I’m now learning Erlang and Scala, and this kind of languages are well designed for distributed systems through lightweight processes and error handling. Combining theses technologies properly would be a key factor today or in near futures. I need more learning on that.
Just created a GitHub Pages for organizing my project documents. It was easier than thought. The page can be directly created from GitHub page, but I tried Jekyll for locally building the static web page.
Jekeyll updates the markdown into html file in real-time, and just a ‘git push’ is enough for reflecting the changes into the server. Nowadays, everything is in real-time and no back-and-force. It’s pretty much wonderful.
While I was working on exvcr, there were some issues on performance. So, I made up a mind to look for profiling capability.
Erlang provides several profilers as indicated in Efficiency Guide – 11 Profiling, and I tried to write a wrapper library.
The “fprof” library seems to provide detailed information, but output structure is a little cryptic, and also difficult to parse. So, I decided to go with simpler “eprof” as a first approach. It may be enough for simple checking on bottlenecks, though it doesn’t have absolute time (only relative %) and is forced to print out to screen.
Super great talk on Scala. It’s very funny and very insightful. The more getting to know about Scala, the more getting interested in the deep and well-thought design concept of the language.
Java gained much popularity through it’s practicality, but it lacks simplicity and conciseness which caused criticisms from experienced hackers. Though the Scala is based on the Java’s JVM, its grammar is simple and concise with both the object and functional aspects.
Static typing and pattern matching provide powerful expressions. Then, class and object structure provide encapsulated feature module. I love Elixir/Erlang’s functional power, but its lack of object-structure (records only provides set of data fields) and strongly-enforced immutabilities are sometimes cumbersome.
Anyway, functional programming is pretty much interesting.
Designing module boundary is an important factor on developing a software. As it grows, number of paths and its combination grows exponentially. Then, it becomes difficult to pick paths to test, since it’s not feasible to test all the possible paths.
One idea is to isolate modules into smaler pieces by making “values” as boundary, rather than the message communications. It reduces the dependency, and removes the complex mocking codes.
Another idea is to seperate modules into 2 different types, which are functional core and imperative shell. Functional core provides logics in a isolated manner. It has few dependencies and many paths, which is suitable for unit testing. Imperative shell provides the adapter functionality wrapped around the core. It has many dependencies and few paths, which is good for integration testing.
Just uploaded the initial version of ExVCR, which I was working on over the last weekend. It’s a record and replay HTTP-interactions library for elixir. As the name stands for, it’s inspired by Ruby’s VCR.
Before this one, I tried to create several libraries which involves HTTP interactions, and one of the issues was mocking server request/response on tests. Mostly, manual stubbing with Erlang’s meck library worked, but the test-data tends to become too simplified, and also it was a little cumbersome to manage test-scenarios. This library is a trial for easing the HTTP related testing.
It’s pretty much immature yet, but I am planning to improve it, at least for a couple of weeks from now.