The blockchain is a trendy subject, and we believe one needs to apply its principle to an actual project to understand its technology and progress status. We chose to implement an online money pot in Ethereum, a kind of blockchain that focuses on smart-contracts instead of money transfer. This article demonstrates how we can leverage Ethereum to develop this use-case.
by Alexandre Masselot (OCTO Technology Switzerland), Catherine Zwahlen (OCTO Technology Switzerland) and Jonathan Gianfreda.
The possibility of custom plugins is a strong Kibana promise. We propose an end to end tutorial to write such plugins. But this “end to end” approach also means “how to continuously deploy them?”, “how to share an environment with seeded data?” Those questions will bring us in a full fledged integration infrastructure, backed by Docker.
The Elasticsearch has grown from a Lucene evolution to a full fledged distributed document store, with powerful storage, search and aggregation capabilities. Kibana has definitely brought a strong component for interactive searching and visualization, transforming the data storage tier into an end user browser.
Customizable dashboards via a rich library of graphical components made its success, but soon, the need for real customization arose. If plugins were thought to be integrated from early on, the actual customization often lied into forking the master project and adapting to on particular purpose. Merging back fixes was soon to be a daunting effort to keep up with the high pace of the Github repository evolution .
So, that should be easy. Just google and you would craft wonderful shiny visualizations.
But not fast, young Kibana Padavan! Documentation lacks, resources are valuable but scarce. But the promise is still shiny and we want to reach it.
In this post, we propose to share our journey into the writing of Kibana plugins, the little pitfalls we fell in and the setup of continuous deployment into a Docker environment. There is no dramatic discovery or stunning breakthrough today, but a tentative to write a map to make your journey easier.
A smooth user experience is a common attribute of all the successful Android applications. It might sound as an obvious statement but many are the applications that are a little bit “laggy”. Moreover android developers are use to test their application mostly on high-end devices (generally their own devices), forgetting that their app will be run on cheaper devices, which will deteriorate the app smoothness a lot.
It is pretty easy to find documentation on the Internet that will give you advices to have an efficient android application (for instance the great android performance documentation page itself). In this article we propose the opposite: presenting tools that will help you benchmarking an existing Android application in order to find some room for improvement. It can also be a way to measure improvements when we are doing some performance related tasks. We will try to have first a macroscopic approach and then will go deeper and deeper in the analysis in order to find the hidden cause of a performance issue.
Some of the tools I will talk about are part of the android standard build tools, some are “external” products. All of them have proven their efficiency on the projects I have worked on, including Le Monde applications which are massively downloaded (over one million downloads) and need to be performant even on low end devices .
In the first part we will see how we can identify app launch slow downs thanks to two tools: Nimbledroid and AndroidDevMetrics. In the second part we will focus more generally on User Experience (UX) issues by using standard Android tools.
Going faster on a mobile has become essential. Putting aside the actual choice on the means of communication, the data format used weighs in quite a bit when it comes to the speed. As of Today, JSON has proven to be a standard media for APIs. Still, is this data format suitable for mobile? For instance, handling JSON in an Android environment is difficult.
Other data formats are emerging in recent years like Thrift, Avro, Message Pack or Protocol Buffers.
Protocol Buffers has the ability to have a binary format that is easily adaptable and which can be manipulated. It also has a very basic structure to write and understand and easily generate source code for several languages.
This blog featured two articles on Protocol Buffers (protobuf) in 2012. The version used was 2.4.1, and the standard was proto2.
docker run busybox /bin/echo ‘hello boys and girls!’
As humans, we like new shinny things. And working in a wannabe devops world, that means solving problems with containers, too. We have been working with them for quite a while now, and we are more than happy with the results. We like them so much, that we decided to travel more than 8000 km, to Seattle, Washington, in order to go to this year’s DockerCon.
So if you’re into containers as well, and you’re dying to hear the hot news, you’ve come to the right place. Fasten your seatbelts, and enjoy the ride!
The 9th USI Conference organised by OCTO took place this year on June, 6th and 7th. If you do not already know what USI is, you should have a look at www.usievents.com and the great video talks on their YouTube channel (https://www.youtube.com/user/usievents).
As USI lovers, OCTO Mobility team cared to deliver the best experience to all attendees providing them good-designed, well-crafted mobile applications.
It is now time to have a deeper look into usage analytics during these two amazing days at the Carrousel du Louvre. Read more
Ah, the old office directory: page after page, or screen after screen, of names and job titles. Wouldn’t it be great to have a virtual directory that displayed employees’ faces, included the company hierarchy, and grouped employees according to responsibilities and expertise? Better yet, what if that directory could be navigated by using natural hand gestures?
By combining the power of the Microsoft Kinect sensor and the Oculus Rift virtual reality (VR) headset, we have created just that – a VR company facebook that lets users traverse the company’s human resources and find the right employee with a flip of their hand.
Days of traditional servers are counted. Flexibility of cloud platforms towards traditional datacenters is the root cause of the shift. For a developer, the question is no more where will be my application deployed but on which cloud platform. And designing an application in the cloud is more complex than on premise. As developers we must be ready for that, we must write code ready for the cloud. But, what is exactly a cloud ready application? Is it a one push action to Heroku? Yes, the Cloud can make life easier for the developer. But in order to unleash all its benefits you must design your code for the cloud. And this article aims to explain you the why and the how through 3 highlights of the shift of applicative architecture from the on-premise to the cloud world.
I hacked something together in order to highlight text and send it automatically to fpaste, then put the fpaste link in your clipboard automatically.
Well, I just happen to share a lot of content (code snippets, application/middleware logs, ASCII art, you name it!) with other people using both fpaste and pastebin. It makes it easier to read text when trying to debug something.
Tired of using EC2 instance, creating your infrastructure, instantiating as many node as possible to handle the amount of data? Good news! it is now possible to get rid of these servers and focus only on the code. Pretty nice, isn’t it? To illustrate this topic, this article is dedicated to a real-time “serverless” platform.
Let’s dive into it!