Forem: Bobby Priambodo

When reading a thorough tutorial, would you rather read it in a single long article or multiple short articles?

Bobby Priambodo — Sat, 17 Mar 2018 12:32:50 +0000

I'm writing a tutorial, but based on the sections I have outlined I imagine it would be somewhat lengthy for a single post (e.g. more than 4000 words).

Think of a tutorial in building a complete (although simple) app. The goal is not the end result of the app per se, but rather walking through the development phase, tying things together, in a beginner-friendly way.

Would love input on which method you prefer and why. Thanks!

Getting your feet wet with OCaml

Bobby Priambodo — Thu, 14 Dec 2017 13:18:18 +0000

Originally published on Medium

I have a confession to make: I love OCaml. It was love at nth sight, with n is a sufficiently small positive integer (kept putting it off in favor of Elixir and Haskell, but I have come to regret it).

OCaml is statically- and strongly-typed, (mostly) functional, fast, safe, and compiled to native, resulting in a single executable binary. The compiler is blazingly fast, and its Hindley-Milner type system (same as for Haskell) is so sophisticated that you don’t need to over-annotate your program and still be type-safe. I’ve always been looking for a fast compiled-to-native—preferably functional—language and OCaml seems to fit the bill so well.

After bashing Java for years in college, working with JavaScript for a year after I graduated, and almost another year working with Java (karma?), I can’t help but appreciate languages that have explicit types. The compiler is a very great, smart friend that can actually stop you from stupid things like using wrong types in your code. OCaml’s compiler is even more so. And it’s blazingly fast!

So here I am now, trying to share the love with you. But first, why OCaml?

The rise of ReasonML

One trend that has seem to arise on my Twitter feed is ReasonML. Reason is a syntax and toolchain for OCaml from the folks at Facebook. To oversimplify, it’s a new face to OCaml; along with the sister project BuckleScript, we can write OCaml with a JS-ish syntax that is type-safe and can target JS and native (even mobile!). It is evident that it’s gaining traction on Twitter sphere and other online platforms. Even Dan said so:

Fun pattern I noticed while making this list: people who came to the @reactjs community early are now mostly tweeting about @reasonml.
— Dan Abramov (@dan_abramov ) December 3, 2017

Acknowledgement from Dan!

As with the rise of any technology, new tutorials, articles, and videos start to sprout here and there. I’d also like to contribute, but I thought it might be interesting to cover from the OCaml side of things! It is a bit unfortunate that even though OCaml is not a new language, the materials surrounding it is a bit sparse. I’d like to improve that. (It is steadily improving, and Reason without a doubt has a significant contribution there for bringing more people to the ecosystem.)

The goal of this article is to get you up and running with an installation of OCaml on your computer to actually try and explore stuff. I’m not going to cover syntaxes and such, only about setting up the development environment. Hopefully this can help fellow beginners who are interested in OCaml. I also will provide you some links at the end to follow-up should you want to explore more.

Some disclaimers: you’re not going to get much of Reason here, but I believe the information in this article can also benefit you if you wish to dig deeper. Also, it’s necessary to inform you that Windows story is a bit under represented in OCaml, and AFAIK some parts are broken, so I have to assume that you’re running on either Linux, MacOS, or a VM.

Well then, let’s get to it!

Installation

Fun stuff: to install OCaml, you don’t need to install OCaml! (Well, at least not right away.)

What you need first is opam, the OCaml package manager. If you come from other languages, opam is pretty much rustup + cargo (Rust); nvm + npm (Node.js); rbenv/rvm + gem (Ruby); stack (Haskell); pyenv + pip (Python); and others alike. Basically, it is both OCaml version manager and package manager.

I’m going to walk you through installing the beta version of opam v2 (2.0.0~beta5 at the point of this writing). The current official stable version is v1.2.2, but I’ve been using v2 beta for months and feel that it’s stable enough for daily use.

To install, open up your terminal and run:

$ wget https://raw.github.com/ocaml/opam/master/shell/install.sh
$ chmod +x install.sh
$ ./install.sh --fresh

Here we do three steps:

Download the install script from the repo
Make the script executable
Run the script (you may inspect the content of install.sh first before running it).

You can also use the one-liner: wget https://raw.github.com/ocaml/opam/master/shell/install.sh -O - | sh -s -- --fresh. Note that in general running a shell script from the internet should be done with caution, therefore I advise to inspect the content first.

The script will download the pre-compiled opam binary (of around 5 MB in size) from the GitHub releases page that matches your architecture. It currently has binaries for Linux (i686, arm64, armhf), OpenBSD (amd64), and MacOS/OSX (x86_64). If you already have opam installed, it will make a backup of both your old binary and .opam directory, so it’s safe!

After downloading, it will ask you where to put the binary. Unless you have a specific reason not to, the default /usr/local/bin works fine. Make sure that whatever the destination directory is, it is available on your $PATH.

Verify the installation by running opam --version:

$ opam --version
2.0.0~beta5

Great! We have opam up and running. You can now delete install.sh if you want since we don’t need it anymore.

Next up, we are going to initialize our opam environment. Run this:

$ opam init

This will:

Check installed and available version controls on your computer (e.g. git, darcs, mercurial)
Fetch opam repository information (basically where OCaml third party packages are listed)
Prompt you to add an entry to your .bashrc/.zshrc/.*rc file to setup opam environment. The default is no (n), but you will most likely want to say yes (y). This will save you from having to execute some extra commands everytime you open a terminal.
Install OCaml for you!

At the time of this writing, the latest stable OCaml version is 4.06.0, so that’s what I get on step 4. On installation, this might take some really long time depending on your computer’s spec (particularly on the commands make world and make world.opt), and this is fine. That’s because we’re compiling the OCaml binary from source. It might be best to get used to this since it will happen occasionally, e.g. when we want to switch OCaml versions or when we want to start hacking on a recently created/cloned project.

(Note: opam related files are isolated inside the ~/.opam directory, so if you want to uninstall it’s as simple as removing that directory, removing the entry added at your .*rc file from step 3 above, and removing the opam binary itself.)

Afterwards, you can verify the OCaml installation with ocaml --version:

$ ocaml --version
The OCaml toplevel, version 4.06.0

Neat! We can now try the builtin REPL, officially called “toplevel”, by invoking ocaml:

$ ocaml
       OCaml version 4.06.0

#

The # sign is a prompt. We can use it for a simple calculator like such (note: the double semi ;; is used to mark the end of an expression):

$ ocaml
       OCaml version 4.06.0

# 1 + 1;;
- : int = 2
# 2 + 10 * 3;;
- : int = 32
# "hello " ^ "world!"
- : string = "hello world!"

Congrats! Your OCaml installation is working properly.

Switching OCaml versions

One action that you will perform every now and then is switching OCaml versions. As I have described above, opam is also a version manager; that means you can have multiple OCaml compiler versions on your computer and the ability to switch between them at will.

You are also able to have version aliases, say you want to have two aliases project-a and project-b, each using the same OCaml version. The two is considered two different “switch”-es, completely isolated from one another. This is particularly great for dependency isolations — OCaml expects packages to be available globally, and you can imagine the version-conflict troubles it would cause if we use a global namespace for all of our projects’ dependencies. (There are also a neat new feature on opam v2 called local switches, but we’re not going there in this article.)

Now that you have the latest 4.06.0 installed, let’s switch to a slightly older version. A good use case of this is that 4.06.0 was just recently released and introduced a (necessary) breaking change, which currently causes many libraries failing to build (more on that here). So, let’s switch to the older stable version: 4.05.0! Run this command:

$ opam switch create 4.05.0

This will again download the source of the 4.05.0 compiler and build it locally.

(Yes, it will take some time. Better go get your coffee!)

After it’s done, it will advertise a command that you would need to run. Let’s run it now:

$ eval $(opam env)

This will set the necessary environment variables to correctly point to the newly installed switch. To list the installed switches, we can run opam switch:

$ opam switch
#   switch   compiler                    description
->  4.05.0   ocaml-base-compiler.4.05.0  4.05.0
    default  ocaml-base-compiler.4.06.0  default

You can see that we are now using the 4.05.0 switch. You may also notice that the 4.06.0 one has default as its name. You can switch back to it easily:

$ opam switch default
# Run eval $(opam env) to update the current shell environment
$ eval $(opam env)
$ opam switch
#   switch   compiler                    description
    4.05.0   ocaml-base-compiler.4.05.0  4.05.0
->  default  ocaml-base-compiler.4.06.0  default

Nice! Switching between, uh, switches, are so fast. You can create switch aliases with opam switch create <name> <compiler>, for example opam switch create project-a 4.05.0, which will create a project-a switch using 4.05.0 as the base compiler. Note that this command will again rebuild the compiler locally, even when you already have a 4.05.0 switch installed!

(If you’re using ReasonML and/or BuckleScript, this is where you can use 4.02.3+buckle-master as the compiler to get the compatible version.)

Writing, compiling, and running programs

Okay! Now we’re going to try to write a simple program, compiling it to a native executable, and running it. Make sure to switch back to 4.05.0 for the purpose of this experiment (opam switch 4.05.0 && eval $(opam env)).

Let’s come up with your everyday simple program that prints “Hello, OCaml!” to the standard output. Open up your favorite text editor and write this:

let () =
  print_endline "Hello, OCaml!"

Save it as hello.ml. We have the source code, now let’s compile it:

$ ocamlopt hello.ml -o hello

This will compile hello.ml into a native executable named hello. Let’s now try to run it!

$ ./hello
Hello, OCaml!

It works perfectly! How about if we introduce type errors? Let’s try with this program:

let add a b = a + b

let c = add 1 "not a number"

Save it as should_error.ml. What happens when you try to compile it?

$ ocamlopt should_error.ml -o should_error
 This expression has type string but an expression was expected of type
         int

In OCaml, you cannot “+” an integer and a string, because the + operator only operates on integers, so that resulted in a compile error! Thankfully no weird results such as 1not a number or NaN.

You can play around with the file to write more OCaml code, compile, and run it.

Note, however, that you will seldom use ocamlopt directly to compile programs that have multiple files and complex directory structures that uses third party packages, because you would need to enumerate and wire all the files and packages that your program depend on. Fortunately, there are several tools out there that simplifies this for us, and the majority of the community is converging to Jane Street’s jbuilder as the de facto build system.

I will not delve into the topic of build systems further, perhaps that’s for another article on another time. Just remember that you’re in good hands! :)

Installing libraries and programs with opam

The last thing I want to share with you in this article is how we install third party libraries and programs via opam. Let’s differentiate the two:

Libraries are packages that are meant to be used programmatically in code; while
Programs are packages that provide executables that you can run, e.g. via command-line.

A package can act as both a program and library, that is, they provide a command-line executable and an API to use it programmatically. Note that “program” and “library” are terms that I come up with myself for explanation purposes, I‘m not sure if there’s a convention for that already.

In the perspective of opam, there are no significant differences between the two; only that programs usually have extra steps after downloading the source, which is to copy the resulting executable binary. Installing packages for both programs and libraries are done using the opam install command.

Let’s try to install a program, ocp-indent. It is a utility program that is used to format your OCaml source code to make sure it have proper indentation format (very useful!). Run this command:

$ opam install ocp-indent
The following actions will be performed:
  - install result     1.2          [required by cmdliner]
  ...snip 8<...
===== 9 to install =====
Do you want to continue ? [Y/n]

It will list the packages to install. Notice that we will install 9 of them, because ocp-indent depends on 8 other packages for it to work — and opam resolved them automatically for us! Answer Y (or just enter) to make it proceed with the installation.

First, opam will download the sources (subsequent installs will get them from local cache). Then, opam will build all the packages. If you notice, each of the packages may use different command for building, e.g. make, jbuilder build, etc. That is because each package provides its own build instructions. That way library authors can have flexibility on what build systems they use.

After the process is done, you will have the ocp-indent program installed. Let’s try it!

$ ocp-indent --version
1.6.1
$ ocp-indent hello.ml
let () =
  print_endline "Hello, OCaml!"

Great! You can try for example adding more spaces before print_endline and run ocp-indent again on hello.ml, and it should print out the program with correct indentation. To actually modify the file, you can provide the -i flag (or --inplace) , e.g. ocp-indent hello.ml -i.

So that’s a program! Now, let’s try to install a library package. We’re going to install alcotest, a lightweight testing framework.

$ opam install alcotest
The following actions will be performed:
  - install astring  0.8.3      [required by alcotest]
  ...snip 8<...
===== 5 to install =====
Do you want to continue ? [Y/n]

This time it’s going to install 5 packages. Let’s proceed with Y. It will again download and build the sources.

After it’s done, how about we try it?

$ alcotest
zsh: command not found: alcotest

Uh-oh, what happened? Turns out that alcotest is a library, and therefore it doesn’t provide any command-line executables. Alcotest is meant to be used from code. We’re not going to talk about how to use it now, of course; I just want to give you a look on how programs and libraries differ.

Okay, so how to list the packages that we have installed? We can use opam list. Try it now! It will list all packages that is installed. You can also use opam list --installed-root to see the packages you directly installed, cutting out the transitive dependencies.

Package installations are local to the current switch. If you switch to another compiler switch and do opam list, you will see that the installed packages on the previous switch is gone! Again, because packages are expected to be installed “globally”, this is done so that each switch can have isolation on their installed packages, and projects won’t need to worry about version conflicts.

I hope that you get the gist of installation of packages with opam now! That also concludes my introduction tour to the OCaml ecosystem.

Are your feet wet enough?

So, what’s next?

In this article we have installed opam, installed an OCaml compiler, learned how to switch compiler versions, how to compile and run OCaml programs, and how to install third party packages. Where to go from here?

For starters, you can explore the official Tutorials page. I recommend skimming the Basics, reading the Structure of OCaml Programs, and go through the rest in sequential fashion on your own pace. It will give you a good view of the capabilities of the language.

One canonical resource that most folks recommend is the Real World OCaml book, which is available for free online. OCaml from the Very Beginning is also a recommended book as an entry point.

I am planning to write more articles on OCaml. Two that I have jotted down on my notes are, in no particular order: setting up your text editor environment for OCaml development, and also building and publishing OCaml packages with jbuilder and topkg. I’m not promising anything yet, though! :D

I have also written an article about building a lightweight Docker image using multi-stage builds with OCaml that is available here: Lightweight OCaml Docker Images with Multi-Stage Builds. When writing it I was using opam v1.2.2, but with the knowledge from this article it’s only a matter of translating the opam commands to the ones for v2 (the only difference is on switching compilers, which I have shown above).

Blocked? Have questions? A few channels of communication you can try: discuss.ocaml.org official Discourse forum, the ReasonML Discord, /r/ocaml on Reddit, and #ocaml on Freenode. The community is full of friendly folks more than willing to help you out!

So that’s it for today, folks! Thanks for reading, I hope you get something out of this post! Tell me in the comments if I can improve anything.

How do you handle updating project dependencies?

Bobby Priambodo — Sat, 30 Sep 2017 06:29:22 +0000

Most projects use third-party packages as dependency, no matter what languages you use.

How often do you update your dependencies? Do you automate it, and if yes what tool do you use? Do you use single commit for updating each dep or use one commit for all the deps? Some libs don't provide changelogs that makes it hard to know the changes between versions, what are your thoughts on them (are you using them anyway)? Any other thing that you consider when updating deps?

Suggestions, anecdotes, any kind of experiences welcome!

Why I dislike chat-based platforms for OSS communities

Bobby Priambodo — Thu, 03 Aug 2017 14:52:26 +0000

This article was first published on Medium.

For the past few years, I’ve been trying to keep myself up-to-date with the latest news in technologies that I’m interested in. I started going through the “Community” pages of many OSS products, from programming languages to tools and libraries. I registered and subscribed to many platforms, mailing lists, IRC channels, subreddits, etc.

Fast-forward to today. Among all the platforms that I tried, I can say with confidence: I dislike chat-based apps. By “chat-based apps”, I am including the most prominent ones on this field, such as Slack, Discord, IRC, and Gitter. By “dislike” I mean that I prefer not to use them if possible, unless the issue is pressing and no other choice is available. Unfortunately, several communities seem to use it as their primary channel of communication.

Note that I’m not saying that Slack et al are bad products. I use Slack at work and it’s been very helpful with its integrations and such. Seeing how most communities have at least one chat-based channel, I also believe that it definitely has value for some–if not most–people.

Now, with that out of the way, let me tell you why I think the way I do.

I dislike chat-based apps because they are synchronously real-time.

What’s so bad about it? Real-time is good! We make everything real-time nowadays! Well, Let’s see how being synchronously real-time can hurt communications and the community as a whole.

1. Great conversations vanish into thin air

At times when I lurk at some Slacks and Discords, I can’t deny that is where many discussions on interesting topics got initiated. It also solves many issues that needs to be solved immediately.

But then that’s that. The discussions and solutions there are not globally searchable. AFAIK there’s still no way a google search could point to a specific point of conversation in a Slack channel, so it’s not really SEO-friendly. Perhaps it helped one user, but it will not help the next person, and they would need to ask the question again.

Unless someone put the result of discussions into a blog or something, there will be no record of the exchanges whatsoever. Of course, there actually can be a record, by using services such as SlackArchive.io. But good luck finding specific conversation there–which brings me to the next issue…

2. It’s unorganized and hard to keep track of conversations

With many people speaking at the same time, there’s a high possibility of race conditions. Two or more questions got asked at the same time and many people tried answering them in the same manner. Who’s replying to who? Has the other person finished writing their answer? There is no logical way to group messages. Even after Slack introduced message threads, I never see anyone actually uses it in OSS Slack channels. They mostly stick with the IRC style of conversation.

As software engineers/developers, we embrace efficiency. We embrace the DRY principle. It should be the same with questions–the same question should not be asked twice, or at least there should be a way to answer the second question by only a reference to the first one. It would save everyone’s time. Stack Overflow does it with duplicate questions. Quora does it with merging questions. You would need to search for a similar question before posting your own. But that is impossible in chat-based apps; you have no choice but to ask the question again–not knowing if it has been asked and answered before.

Seriously, I’ve seen an instance where a question was answered by “please scroll up a few hours”. For longer than a few hours (or less if the channel is really active), the answerer would have no choice but to write their answer again.

3. It’s distracting

It being synchronous means that if I post something, I would need to keep the window open and focused to see whether or not I get responses. It’s good if someone mentions your handle when they answer and you receive notifications, but at times they don’t. I simply can’t do other things; leaving the app would introduce the possibility that the response (if any) is far up already; drowned in other chats.

It’s even more distracting than Facebook and Twitter, which I am able to open only occasionally and not miss out on many things.

4. Language barrier for non-English speakers

It being real-time might introduce problems to non-English speaking users that may not be used to expressing their ideas in English. It might take time for them to write questions, and write the replies to the answers. My English is not perfect, and there are times when I can’t find the vocabulary that I needed to express what I want to know exactly. The real-time aspect of chats can be intimidating.

Of course, me being generally an introvert might have something to do with that, and I’m trying to improve my English over time. However, doing things less real-time-y and asynchronously would certainly help me compose better messages.

5. Timezone issues

This is where chat-based apps being synchronously real-time hits me hard. I live in Indonesia, and the timezone here is UTC+7. The timezone in the US (where most interesting things happen) ranges from UTC-8 to UTC-4, which roughly translates to 12 hours difference from here. That means their noon is my midnight.

I don’t know about you, but I’m not keen on the idea of asking questions in the middle of the night, even when doing so will get more active responses from the folks on the other side of the world.

So what’s the solution?

What platform gives us the capability to record and group discussions, communicate asynchronously, navigate through conversations, and be globally searchable and SEO-friendly?

Reddit or mailing lists come to mind. I’m not exactly a fan of Reddit’s or Hacker News’ threaded discussions as it is not chronological, although navigating to parent post and replies are a breeze. Mailing lists on the other hand, are a bit better, but too linear. There are also no way to “mention” a participant, and it has poor support for code blocks. Subscribing to too many mailing lists might also make your inbox unwieldy, even when it is labeled differently.

I am finding Discourse as the most ideal communication channel that I have experienced so far. There are many communities go down this path: Elixir, Docker, Kotlin, Go, and Rust to name a few, and they are arguably several of the best OSS communities out there. I know there’s one for React, but I’m not sure how active it is. I am delighted that the OCaml community has also started to migrate the discussions from the mailing list to the new forum (although it might take some time for it to get traction).

FWIW, I am also a fan of Twitter for being my one-stop news outlet and community channel for tech related things. I follow many devs and that fills my timeline with so many great discussions and blog posts, and fewer fake news.

So that’s about it! I realize that this is mostly a rant :) If I missed something, or if you think that I am not giving chat-based apps the credit it deserves for bringing together a community, do tell in the comments!