In my previous post, I introduced the EuroClojure 2017 conference and covered two beginner-friendly talks to warm up a bit with something simple. As promised, I’m moving into more technical talks for this post and will cover the showcases in the third, and last, post of this series.
In both of the talks I’ll be summarising in this post, the speakers experimented with the tools available and either created new ones to fit their needs or demonstrated what you can do with them.
Let’s see if these talks can inspire other developers.
otplike – Erlang/OTP processes and behaviours for Clojure
Author: Alexey Aristov - Summary - Video
I must admit, this was one of those ‘out of my range’ talks where you think, “I’m not here to learn tech; I’m here to learn what I need to learn.” I found it interesting for several reasons.
I’ve recently started to understand what processes and components are, what they’re for, and how they’re started/stopped, so I thought it might be really useful for me to learn something new about them.
Also, I’m already familiar with some similar libraries; knowing about more widens my knowledge. It gives me more insight into the pros and cons of each so I can make an informed decision on which one is the best for me to use. Even if I don’t understand all the technical aspects of a particular library, I know that it exists, what it’s for and its requirements — which, in my opinion, is more important than knowing everything about it.
I’ve worked with Clojure for almost two years now, and I find it interesting to see how people use it to implement new things and how it can be used to build programs using concepts from other technologies and languages. I can’t give you all the technical details, but I can tell you that this library uses Clojure to build an asynchronous program using Erlang/OTP concepts.
How many times have you and your colleagues ended up comparing different technologies, languages, or libraries and wondered how amazing it would be to have the functionality of one and the syntax of the other?
That’s exactly what the team at Suprematic needed, and they made it possible. They have been able to take what they needed from Erlang/OTP, removed its weird syntax and applied those concepts on top of Clojure core.async. This is a great example of what you can do when you know the available tools, have a clear idea of what you need and understand the best solution for your project.
Building a collaborative web app with ClojureScript
Author: Gijs Stuurman - Summary - Video - Live CREPL
Have you ever thought to build your own version of Google Docs for developers? Or wanted to play tic-tac-toe with your best friend on the other side of the world but couldn’t find a decent online version of the game? Or tried your hand at solving a 4Clojure exercise with remote teammates? Whatever your reason, if you need an online code editor that allows you to live share code with other people, CREPL (Collaborative REPL) is the solution for you.
How can you build a CREPL? What are the ingredients to build one? Here’s the recipe:
- ClojureScript with self-hosting support in order to compile and evaluate your code
- CodeMirror as an editor so you can write your code in the browser
- Re-frame for the front-end architecture, which can handle events, detect updates and re-render your app’s view accordingly
- Pedestal for the server side, which makes it easier to create ‘live’ applications, letting the app give immediate feedback even while backend work is going on
- Clojure.java.jdbc for the database
Now we have all the ingredients and we know what they’re for, but what we don’t really know is this: What can we do with the final result? What are the features of this CREPL?
Obviously we can write code and see live changes from other users. Then, we can evaluate the current expression and see the result added to the document in a “comment” block. We can also evaluate the whole document, or, even more exciting, we can run the code continuously.
But what happens if two or more users change the same part of the code? We’re used to Git, which detects all the conflicts and lets us fix them, commit by commit. In the CREPL, we can find a faster approach using Operational Transformation, the same method used by Google Docs to let users work on the same files at the same time.
The process isn’t so different from Git’s. The document is a log of operations executed one after the other, applying each of them to the result of the previous one. The history of the document is still stored as snapshots, which allows the application to detect the conflict and resolve it.
Of course, the more users editing the same file or the larger the file is, the slower the process runs. But this is still a good starting point, even if there’s still room for improvements.
CREPL probably isn’t going to replace Git; maybe it’s not even meant to. CREPL might not be the solution for a big tech problem, but I appreciate the author creating something new and leaving the user free to find other ways to use it. Who knows, maybe someone will use CREPL and find new useful features and ways to implement them. Anyone want to take this chance?