A few days ago, Moove-it gave us the chance to meet Harry Roberts, an experienced Front End developer. Harry provides courses to companies such as Google, Etsy, and the BBC. The focus was on improving our Front End skills through a two-day workshop, but the experience gave us more than a bunch of technical skills and knowledge.
Writing CSS is very simple. Learning the language is not a big deal. It takes no more than 2 minutes to write 3 lines of CSS to style an element of the DOM. But, let’s think beyond that. What if the application grows bigger than we had originally expected, at the beginning of the project? Is our code maintainable? What things should we consider in order to write more maintainable and scalable CSS code?
Let’s look at just two technical elements we learned during the workshop.
As an application grows it starts demanding more and more work. At some point of the ongoing project, processing a task in the background becomes a necessity. One of the most popular tools to accomplish this in Ruby is Sidekiq.
Now, did it ever happen to you that you get it all up and running on the server and the next thing you know is the server is down and you get a colorful variety of error reports yelling that stuff is not working?
Meet Monit, a tool that’ll let you get ahead of trouble. It automatically restarts programs when they crash and can send email reports on failures!
In case you want to try it out –and make yourself a favour– here’s some aid on installing, configuring and get it up and running.
This post is inspired on a talk about Ruby & Linux at the RubyConf Uruguay 2014.
The Linux Process in Ruby
Creating a new process
In linux we use fork to create a new child process. In Ruby we have access to this by using
It accepts an optional block. We can use either Process.fork or simply fork. When a block is given the child process runs the block and terminates with a status of zero. When no block is given the fork call returns twice, once in the parent process returning the child pid and once in the child process returning nil. When using fork only the thread calling fork will be running in the child process, no other thread will be copied. Since ruby 2 there’s been an improvement to copy on write with relation to the GC. Instead of duplicating all the data it just copies the data when the shared memory is modified by one of the processes.
On June 2, 2014, RSpec 3 was released after months of announced features that were becoming available through new versions of the RSpec 2 branch.
Here at Moove-IT, we decided to take a look at the new stuff, as well as say goodbye to some of the old things that have been removed. Just in case some of us who use RSpec haven’t paid attention to them lately, we put a little bit of Better Specs on top of all that.
When you have to solve a problem, in order to make an efficient and effective solution you must choose the right tools to help you in the process of building it. As programmers, the languages we choose determine a big part of the solution and they will influence the way we reason about it, so it’s really helpful to understand what are the kind of problems that a language aims to solve before starting to use it. Following that line, this post tries to summarize the key features of Clojure that make it preferable over other languages under some conditions, based on what Clojure designers and its community predicate about the language.
Token based authentication is a new security technique for authenticating a user who attempts to log in to a secure system (e.g. server), using a signed token provided by the server.
The authentication is successful if the system can prove that the tokens belong to a valid user.
It is important to note that Json Web Token (JWT) provides signed tokens but not encrypted ones, so passwords or any critical information must not be included in the token unless you encrypt the data (e.g. using JWE).
Have you ever worked in teams, where several and simultaneous projects take place and stories need to be estimated quickly and accurately so as to commit to a delivery date?
If you ever encountered this challenge, you would probably find this article very useful.
A different scenario from Sprint Planning
Traditional Scrum Sprint planning definitely works for some of our clients. But, in this particular scenario we are talking about a team working on several projects for a single client. Therefore, we are constantly receiving tickets which need to be estimated. Since it does not make sense to gather the whole team too often in order to estimate, we came up with this idea of an asynchronous planning. We are positive you would find it extremely helpful.
How it works?
Once a new task arrives, the team members working for that particular project know they must post their personal estimates on a special board (asynchronously and not anonymously). This board would then contain several post-its with the right estimations facing the wall, so they are not visible for the rest of the team.
After a minimum of estimates have been cast, one team member turns around the pieces of paper and gets an average.
In cases where the estimates presented are too different (which is rare), and then the average could be just not that useful, the team members gather to discuss the estimates more in details and reach an agreement.
Every two weeks the estimations are analyzed and compared with the actual execution time. Along with this, a retrospective meeting takes place to improve the overall functioning of the team.
Average improves accuracy.
Visibility (every team member sees all estimates).
Team player philosophy.
Fewer group discussions.
Only works with highly organized teams.
Taking it to the next level
We started this process using only a whiteboard, a few markers and some post-its. As we are geeks, and love creating software to solve pretty much everything, we decided to take this to the next level and create a specific tool for it. We called it “Zenkai” – playing with the letters of “Kaizen”.
It works by simply automating the above described process.
We’ve been following this process (and using this tool) for almost a year now and are constantly trying to improve it. Naturally, this facilitates the estimation process. Beyond that, it truly helps our teams to stay aligned, deliver in time, and keep track of their improvement.
If you want to implement this with your team, please contact us and we’ll be happy to discuss further!