When developing websites it is important to consider your audience and how they interact with your application. This can be even more significant for a person with disabilities. Even the most stunning visual presentation can lose its value when the content cannot be interpreted by an individual due to, for example, a learning disability or difficulty seeing. Therefore, it is important, when doing any development or design, we do not dismiss the 1 in 5 people that would benefit on an accessible web.
Data mining is an interdisciplinary subfield of computer science used to discover patterns in complex datasets. The field has been widely studied since the 70’s since it can produce useful insights that can help to better understand underlying relationships and trends in data sets.
Due to the recent increase of personnel at Grio, it emerged the need of having an automated way of setting up new employers’ machines.
Starting with a brand new machine is always a pain for a developer, and setting it takes at least a couple of days if not the whole first week, resulting in big waste of valuable time. Besides, when a developer starts on a new technology it is not always clear which tools are suggested and which ones the rest of the team are using. Therefore, I have been asked to work as a side project on a way to solve such issues.
At some point in March I received an email stating that I had roughly $40 in DigitalOcean (referral link – get $10 credit!) credit which was going to expire on the first of May. I wanted to do something cool, learn new things, and leverage a large portion of my remaining credits.
My initial plan was to spin up a CoreOS cluster, as it is something that I have had my eye on. Once running I would get Kubernetes running for management/orchestration of deployed applications. During this journey I learned a lot of new things, had a lot of fun, and even got a cool cluster running. However, I never made it to the end goal of Kubernetes in time for my presentation (and this post). Looking back, I don’t consider this to be defeat: I learned a lot of new concepts along the way. I can be certain that I will leverage and use that knowledge in the future too!
With the acquisition of Next in 1997, a new tool was initiated into the Apple family. Originally known as an enhancement of OpenStep, called NextStep, it caught the attention of the developer community under the name of Interface Builder, as part of the XCode suite. Now about to celebrate its 20th birthday, Interface Builder represents the most powerful IDE to design user interfaces in a development suite. It doesn’t matter if you are writing an app for iOS, Cocoa, tvOS or watchOS; when carefully used, it will save you hundreds of lines of code. For this and other innumerable reasons, many developers, like myself, love this tool.
Howdy, lazy bum! Enjoying the ReactiveX magic? Want to take a look at polling?
I’ll be walking you through a solution I put together for one of our up and coming apps! It works rather well, I learned a lot, and so far no complaints…although there are no users yet either!
Feeling quite charitable, I’m going to let you in on some useful bits and pieces as we build up to polling: threading, late subscribing, replay, manual re-triggering and error handling (a must for preserving replays).
As part of my exploration of a minimum set of devops tools, I’ve been learning how to stack containers full of Rails apps onto the Docker. There are plenty of examples of how to get started with Rails and Postgres on Docker, even one from the whale’s mouth, as it were. Working from this example, it was pretty clear to me that one of Docker’s major strengths is that it makes it really, really easy to get something running with a minimum of fuss; it took all of about a half day to learn enough Docker to hoist anchor, and even tweak a few things to my liking. One thing kept nagging me about the Docker example, though, and that was a warning from bundler when running docker-compose.