I’ve been playing with Reason a lot lately as I’m building an open source personal note taking app. One thing I like to do in my projects is be strict about warnings by treating them as errors, so I wanted to do this in Reason as well.
I couldn’t find exactly how to do this in the docs, so I started looking at some OCaml resources and stumbled upon this chapter of the Real World OCaml book where it was mentioned in passing that
@A can be used to enable all warnings.
Putting it all together, for Reason this means putting the following in your
"bsc-flags": ["-warn-error", "@A"]
This worked, but also suddenly enabled warnings that were not enabled before and looked pretty harmless. Fortunately, it’s possible to disable warnings on a per warning basis like so:
"bsc-flags": ["-warn-error", "@A", "-w", "@A-9-40-41-42-102"]
These numbers like
40 and so forth refer to specific compiler warnings documented here. The Bucklescript compiler also outputs these numbers as warnings are generated so it’s easy to figure out which ones you want to put in there.
These days, SPA’s (Single Page Applications) are an undeniable trend on the web. However, there are still use-cases where a ‘traditional’ server rendered application makes a lot of sense.
At work, we’ve been using Dashing for years for internal dashboards that are displayed throughout the office. I’ve always loved Dashing because it provides just simple building blocks that allow you to do anything. The process of getting information on a dashboard is as simple as:
- Write some data fetching logic in Ruby, schedule it to run every X minutes.
It’s just code. As a developer, I love this. Many dashboarding tools out there exist that allow you to drag and drop widgets on page and connect it to ‘data sources’, but truth is data comes from many different places that all have their unique APIs etc. Being able to write some simple code and have all the flexibility that comes with that is very powerful.
One problem that Dashing has is that it has began to show it’s age. Especially it’s frontend, written with Batman.JS and Coffeescript is no longer on par with modern development stacks like React with ES2015+ and tools like Webpack.
This is exactly where Dashbling, my new open source project, comes in.
If you want to squeeze out that last bit of performance on your site like me you might consider inlining your stylesheets into the HTML. This saves a roundtrip to the server and can increase render performance. Now this definitely doesn’t make sense in all cases but for sites with tiny stylesheets like mine it’s a nice win to speed up (first) render.
I’ve written about building Github Pull Requests with Jenkins back in 2013. Three years later we’re still strong Jenkins users here at Kabisa, even though Jenkins changed quite a bit. Most notably Jenkins introduced the notion of Pipelines.
Jenkins Pipelines allow you to describe your entire CI/CD pipeline in code and version it together with your production code. Additionally the whole Jenkins Pipelines ecosystem allows for many powerful setups, including building jobs in Docker containers and built-in support for building Github Pull Requests.
In this post I’m going to show you how to configure Jenkins 2.0 with Pipelines to setup a complete CI/CD pipeline with builds running in Docker containers for isolation and ease of environment setup.
February 29, 2016 External
Hosted PaaS (Platform As A Service) offerings like Heroku and OpenShift are great but not always suitable or even possible to use. If you need or want full control over your data and servers, or you just want to host your latest side project but don’t want Heroku dyno sleeping you might just want to self host.
Traditionally self-hosting was painful and cumbersome but today there are plenty options to self-host your apps that are nearly as painless as a hosted PaaS solution. In this tutorial I will show you how to deploy an app on Dokku.
I’ve written about Continuous Integration at Kabisa before. Recently we’ve upgraded our CI environment to be even more awesome. Here’s how.
November 5, 2013 External
At Kabisa we’re pretty heavy Jenkins users. We live and breathe Test Driven Development, so a CI server continuously running our tests and building our apps is vital.
About a year ago we switched some projects over to Travis CI, because it had such awesome Github pull request integration. Nowadays it’s possible to make Jenkins build your GitHub pull requests as well, let me show you how.
For a while I have been wanting to write a Jekyll plugin to automatically index all pages on IndexTank. I was reminded to this by the introduction of Tapir and decided to finally go ahead and create the plugin.
I’m about to graduate for my Software Engineering Bachelor and will be starting as a Ruby and IOS developer at Kabisa soon. I haven’t done much Ruby work yet (I used to be more of a Python guy), so this was an excellent chance for me to practice my Ruby skills a bit.
Recent developments have made possible what a lot of people have been waiting for: AirPlay music streaming to non-Apple (licensed) hardware. A lot of people have asked me since if I could include this in Airplayer. While this is certainly possible, I’ve decided not to do that. Here’s why.
Recently, I’ve been working on Airplayer, a Python script to make media playing software Apple Airplay compatible. It currently supports XBMC, Plex and Boxee, but could support any media playing software through the ‘pluggable backends’ feature.
Recently, I wanted to assign a second public IP address to a Linux (Debian) server. First thing that came to mind was to create a network interface alias like so:
iface eth0 inet dhcp
iface eth0:0 inet static
address x.x.x.x (the secondary IP)
gateway x.x.x.x (the secondary IP gateway)
netmask x.x.x.x (the secondary IP netmask)
Creating a network interface alias makes sense because both my IP addresses are in the same subnet. Doing this worked, but it also posed a problem. I had to be able to specifiy which of my IP addresses was used for outbound connections. Here’s how.
For the last few years my website has been running on a custom made PHP (eew) ‘blog engine’. Nowadays I prefer to code my websites using Python and Django.
However, Django is quite memory intensive (for my 128MB RAM vps server that is) and it’s way to advanced for a simple blog and some static pages anyway. So I decided to take a different road.
A little while ago, I found myself in the position of needing a UIProgressView in a color different then the default blue. I was suprised to find out that the UIProgressView class does not support setting a tintcolor. So I decided to subclass UIProgressView and draw my own ProgressView with support for setting a tintcolor.
The result became ‘PDColoredProgressView’.