Since COVID-19 began, all of us have been looking for good alternatives to our traditional in-person get-togethers with family and friends. In this post, I’m going to be talking about my most recent side project creating a virtual baby shower.
Kotlin is a JVM language that hit version 1.0 about a year ago (February 2016).
It is developed by JetBrains, the same people who make my favorite suite of
IDEs. The language itself is open-source under the Apache License 2.0 and is
developed as a community project over at kotlinlang.org. Kotlin is something
that I have become rather excited about over the past year. This post’s goal is
not to teach you Kotlin but to get you excited about it!
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!
In the past we would often treat a server as a machine which has a variety of roles. A single server may be responsible for serving web content, email, processing background jobs, and even hosting a database system. Your application is really only one of the many things that runs on that machine.
I work from all over the place: Home, on public transit, the office, coffee shops, etc.
A big challenge to developing android apps in an environment where my laptop and phone are on different networks (wifi vs. LTE, or laptop tethered through phone) is the inability for my phone to see the API server that is often running locally on my laptop. Here is a simple tip to allow your phone to hit the backend over ADB and a usb cable.
It is a new year and I can exploit that to write a post proclaiming how
something ought to be done in 2015. We can use the new year to discard last year’s practices and mistakes as “the old way” and start fresh from lessons that we’ve learned.
The interesting (and also most frustrating) part about building frontend apps is
how fast the landscape changes. The tools, libraries, and frameworks that you
use today might not be the same as what you’d end up using on a new project only
a month from now. While we’ve ended up with this culture of adopting something
new as soon as someone posts that the “old” way is “dead”, I’ve found a few
pieces of the frontend stack that I do not plan on switching out anytime soon.
I would also like to preface this with stating that this post is highly
opinionated. The opinions expressed here are mine and formed through my own
experiences. These opinions may not reflect what I end up doing in practice, nor
does it reflect on what others at Grio may choose or use.
This is Part II of my series on writing awesome CLI (command line interface) tools using ruby (Part I). In the first part I described how to create your project layout, add an executable binary, and get started. In this next part I will cover:
I am always writing small tools to help me out on a daily basis. Sometimes shell scripts, but
other times I want something a bit more complex. When I need more than a simple shell script, I like to leverage ruby for its vast library of gems which can greatly accelerate and simplify the task of building these helpful tools.
This post will give an introduction to writing your own CLI tools in ruby and packaging them
as a gem.
On Thursday, October 31st Google announced their new flagship phone, the Nexus 5. Along with their newest device they announced it would ship with Android 4.4, codenamed “KitKat” (much to the surprise of the entire Android community that was expecting “Key Lime Pie”.)
I received my Nexus 5 on November 7th, and have had some time to get used to KitKat as well as the device itself. Originally this post was going to review the device and the new Android version, but instead I want to discuss several of the key changes that have been introduced with 4.4 and my thoughts on them.
When working on Filedart we wanted some statically served pages, but to use our site template(s) to have them fit the look and feel. Updating our site’s assets (javascript, css, images, etc) should be easy to update in our static pages as well. Here is a brief overview of how I made this happen.