Ona Blog

William Mucheru joined our Nairobi office as a front-end engineer a few months ago. As a designer with a background in writing code, he is in the unique position of bringing our features to life through intuitive interfaces and user experiences. William’s interests lie in UI research and creating new tools like the automatic Student ID generator he built at the University of Nairobi. When he is not designing or programming, he can be found on a football field, playing Burn Out, or sitting in Ona's lobby listening to music.

William in his own words: “Since I joined Ona, I have been on a steep learning curve, moving away from basic technologies to newer ones such as Python, Django and Pyramid frameworks, and trying out new UI frameworks and Database & Mapping technologies (Postgres, PostGIS and GeoJSON). Everyday presents a new opportunity for growth. Working with Roger has been inspiring as he challenges me to take bolder directions in design. I’m looking forward to learning a lot from the team.”

We are introducing InsideOna to share stories and experiences we have building a social enterprise tech startup. Roy started 6 months ago at Ona as a software engineer.

What's your tech background?

I come from a PHP/Java background, being mostly self-taught. I thought I was a hard-core developer, but joining well-seasoned engineers such as Peter, Dickson and Larry has been quite the experience for me. From jumping into new languages like Python & Clojure, starting with test-driven development, learning new DevOps tools and strategies, pair programming, to going through application deployment and tough code reviews — it’s been arduous, but a developer’s paradise for me.

What are you working on?

I’m currently on Ona’s core product, OnaData, which has a mature and well-established codebase. Being on it has improved my understanding of the standards on which web applications should be built. And, I’ve been learning Clojure (Clojure is a functional programming language in the Lisp family).

What's it like working in a Clojure shop?

I’ve been using Clojure for 3 months. Learning Clojure will force you to change the way you think around solving problems, whether you are an OOP enthusiast or an expert with scripting languages such as Python and PHP. Clojure provides a completely different paradigm of building applications. When I started, I definitely asked myself — Why would someone put effort into learning and using it? [laughs].

So, why use Clojure?

One of the things that has stood out is that Clojure is concise. It requires very little code to program complex operations. It is also expressive and elegant. Its syntax is consistent and basic, but strict, forcing you to structure your code elegantly by default. Clojure runs on the JVM and leverages existing Java classes. That’s right — you can import and use Java classes and methods in Clojure code!

Thus far, building Ona’s new front-end with Clojure/ClojureScript has been rewarding. It has simplified basic code requirements such as modularity, simplicity and readability; allowing us to focus more on problem solving and working on the functionality.

Is it easy to pick up Clojure, despite requiring a different paradigm of building applications?

Getting started with Clojure is straightforward. The setup is simple — all you need is a JVM and Leiningen. In a few minutes you can start experimenting with it interactively in the REPL. We are nowhere near tapping the full potential of Clojure, but I’m confident that as we continue developing in it, it will improve productivity as well as the performance and stability of our apps.

Any parting thoughts?

Just about the developers here. Ona has a thriving culture that requires learning, promotes using and contributing to open-source tools, and — I know this will sound schmaltzy — encourages you to be the engineer that you want to be.

Look out for a post from the Ona team with tips on using Clojure.

The last time we talked about Pallet we described using a pallet.clj file in concert with Leiningen to bring up remote servers, configure web applications, and deploy new version of web applications. We glossed over the details required for sharing deploys amongst a group of developers, i.e. allowing multiple developers to deploy to the same web server. These details were obviously prerequisites for a workable infrastructure system. Accordingly, below we describe how we are currently handling multi-user deploys and how we would prefer to handle them.

Current approach to multi-user deploys

There are two main changes we made to accommodate multi-user deploys:

1. Set a specific admin user when creating the server and starting the web app process
2. Ensure deploys are performed as this user

To handle the first, pallet.crate.automated-admin-user provides the automated-admin-user function, which is passed to a plan-fn in the bootstrap phase and takes a username argument. Similarly the app-deploy/server-spec takes a {:user "[username]"} key-value pair to set the user which will run the web application.

To handle the second requirement, deploying to the server as a specific user, there are a number of options. The sub-optimal route we have chosen for now is to use the global .pallet/config.clj file to set the pallet admin username and the paths to ssh keys. We also played around with a script to su into an account named after the admin user and deploy as that user. The benefit of this is that a developer does not rely on any files outside of the repo. However we think this benefit is outweighed by the detriment of having an unnecessary user on the developer’s system and the potential security vulnerabilities.

Preferred approach to multi-user deploys

Ideally, we would like a way to make a change to our pallet.clj script that sets the admin user used in deploys. We tried binding the *admin-user* dynamic var, and passing the :user key to various operations, but to no avail. If any Pallet users, like real-life users, have insight into configuring the admin user, please let us know!

While our chefs are working hard away on the upcoming version of Ona, we wanted to introduce a new resource for our growing community of users: the Ona Community mailing list. All are welcome!

Already, we’re seeing Ona being used in a number of creative ways to make a difference. We hope this community becomes a place where you can share your experiences, recipes for success!, and learn from others. We also greatly value your input. Hearing first hand what is working and what isn’t - provides invaluable feedback to our team of designers and engineers working hard to bring you a world class service.

We will still maintain the support@ona.io email service for urgent support issues, but we might share the support request on the mailing list if we feel it would be useful for other users. If you’re interested in having access to dedicated support for your project, please email contact@ona.io for more information on our paid plans.

The primary focus of our product team over the past few months has been working to overhaul the Ona platform. While the existing data collection tool is useful, we’re improving it on three fronts:

• Revamping the user interface with a new design language
• Adding new functionality to support user management, organization accounts, and improved access and permissions controls
• Bolstering the code to be more stable and secure so that we can guarantee uptime and reliability and improve performance

Our plan is to release a revamped version of Ona by August in January 2015. Sign up for our mailing list below to receive notifications of new Ona releases.