development

We recently faced significant challenges navigating the permission limitations inherent in Azure. Here’s how we overcame those with Terraform.

Estimating, like anything in software development, is a skill. And it’s a HARD one. No one begins their coding career already amazing at estimating.

Updating dependencies sounds simple, but its something were not usually taught. Which is why many of us feel like were figuring it out on our own.

Asking for help is a more efficient use of time than rabbit-holing. Don’t feel bad about doing it.

Our goal is to help clients get their projects off the ground and functioning smoothly. We love to be a part of their success stories. One of our recent success stories is Lob.com.

A solid pull request description can open doors to quicker and more productive pull request reviews.

Learn how the “staff augmentation” mindset can hold your team and project back. And why ditching this term can help everyone — employees and consultants — succeed.

Code review is an important part of our consultants’ workflow. In this post, our principal engineer breaks down her process for reviewing pull requests.

In-band authentication is like letting anyone come into your house, but locking every cabinet and drawer to keep your belongings safe. An out-of-band system simply locks the front door.

Worldwide Covid-19 responses illuminate the varying capacities of countries to prepare and react to major public health events. Cloud City is part of the effort to create tools that can help all countries succeed.

Learn everything about Ruby, all in under a minute. In this episode of Ruby55 we cover the fastest way to create a new RubyGem, using Bundler’s gem command

Covid-19 is one of the most disruptive global events to happen in our lifetime. Though there is still much to learn about the virus, public health leaders and policymakers must make strategic, rapid, and thoughtful decisions based on evidence and science. Working with PreventEpidemics.org, we built an accessible tool to help inform both decision makers and the public at large.

It’s been a month since San Francisco and the surrounding counties announced a lockdown, and at least a couple of weeks in most of the US. The good news is that it’s possible to build software even when everyone is staying at home every day, unlike a lot of jobs!

The bad news is this isn’t remote working, not the way that anyone has ever talked about it before. In the words of Juan Pablo Buritica, this is “stuck at home work”, and that’s much worse.

Cloud City’s Senior Developer Pamela McA’Nulty delivered a talk at PyCon 2019 on Saturday, May 4th based on her previous blog post on multiprocessing in Python.

Framing the problem

“Some people, when confronted with a problem, think ‘I know, I’ll use multithreading’. Nothhw tpe yawrve o oblems.” (Eiríkr Åsheim, 2012)

If multithreading is so problematic, though, how do we take advantage of systems with 8, 16, 32, and even thousands, of separate CPUs? When presented with large Data Science and HPC data sets, how to you use all of that lovely CPU power without getting in your own way? How do you tightly coordinate the use of resources and processing power needed by servers, monitors, and Internet of Things applications - where there can be a lot of waiting for I/O, many distinct but interrelated operations, and non-sharable resources - and you still have to crank through the preprocessing of data before you send it somewhere?

Building secure web applications is really, really hard. One of the biggest attack vectors in modern webapps is passwords. Even if we set aside the dangers of phishing or other more sophisticated attacks, passwords themselves are a source of danger, between simple passwords, guessable passwords, shared passwords among family members or teammates, and reused passwords across accounts.

Perhaps surprisingly, one of the most challenging things about operating RubyGems.org is the logs. Unlike most Rails applications, RubyGems sees between 4,000 and 25,000 requests per second, all day long, every single day. As you can probably imagine, this creates… a lot of logs. A single day of request logs is usually around 500 gigabytes on disk. We’ve tried some hosted logging products, but at our volume they can typically only offer us a retention measured in hours.

When interacting with Ruby devs, I’ve heard a lot of feedback along the lines of “I‘ve heard that pairing is supposed to be good, but every time I try to do it I get more and more discouraged”. Other devs I’ve talked to have lots of great experience pairing with their peers, but aren’t sure how to work with someone more or less experienced than they are. The goal of this talk is to prepare you so that pairing is not only something that you can do with any other dev, but something that you want to do with any other dev. By the end of this talk, I want you to be ready have awesome pairing sessions where you are energized and excited by working together with other devs to conquer your shared problems. Pairing is a fantastic tool for your professional toolbox: let’s learn how to design, discuss, refine, and refactor… together.

We built TSOMI in order to see the interconnections of people listed in Wikipedia. However, much of this data is missing or is incorrect.

Most projects have some previous code written. As programmers, we have to figure out where and when to refactor and how much is necessary to bring something up to the new standards. We inherited a D3 project from a few years back and went to work on refactoring some of the code. The project is called TSOMI, which stands for “The Sphere of My Influence”.

Three years ago, my friend Robert Harris and I made a toy project to help some of our friends who were teaching in the humanities. They wanted ways to help their students understand who was connected to who. Being data visualization nerds, we wanted that too! We added connection lines and put people on a timeline in order to visually sift through who influenced who, and who were contemporaries.

As software engineers, we look for best practices throughout the whole software life cycle. We are constantly engaged in research and rethinking as we investigate new technologies and find tighter ways to factor complexity. However, developing better projects faster isn’t just about improving your tools; it’s also about improving your developers. Therefore, we do our best to understand developer work and keep track of research that helps us to understand the coding process as a human process, a series of practices, and a discipline of the body and mind. Yet how do we know what we know?

Over several years of working at Cloud City Development, I’ve seen a consistent demand crop up repeatedly amongst our clients' companies: How can a team of software engineers hire aggressively to meet future needs, while still having time to meet current needs? How can developers (or their managers) find the expertise that they need to evaluate candidates, when it is precisely that very expertise that is needed for them to do so?

Humans are tool using creatures. When we want to drive in a nail, we use a hammer. When we want to dig a small hole, we use a shovel. When we want to connect something into a power outlet, we use a plug. Since there’s only one kind of hammer, shovel, or plug, it’s always easy to find the correct thing, right? Well, no, there are claw hammers, ball peen hammers, spades, shovels, 120V two-pronged and 3 pronged plugs, and those 220V plugs they use in Europe that I can never keep straight. Happily, software systems and packages don’t suffer from these incompatible interface problems, right? Of course they do. Maintaining the ability for a system or package to operate correctly against different versions and environments can be quite challenging. And testing against all of the supported versions can drive one to distraction and convince maintainers to limit supported versions to what they can deal with.

Even though the Internet has become six orders of magnitude faster in the last twenty years, there’s no way to move information around the world any faster than about ⅕ second. That's where caching comes into play. And which caching technique you choose depends on your use case as the optimum caching for a repeated-use application is at odds with the optimimum technique for marketing sites.

As a full-service design and software consultancy we get to help clients in their time of need and, if we do our job right, make a difference for that client and its customers. While all projects have their own goals and guideposts, all, including those for True & Co., Deis, and Engine Yard, start with the same question: why. We like to think that our approach and their engagements with us were partially respondible for our clients' acquisitions.

Andre Arko, Cloud City Development senior developer and lead developer of Bundler, the Ruby dependency manager, has three questions you should ask yourself before diving in. Then once you've answered why open source (and confirmed you have the time), he shares his 15 minute a day blueprint to go from Open Source Newbie to Core Contributor.

Feel like you're testing too much? Like you're a bad developer if you don't TDD? Fear not! I overview what parts of your Rails apps to test and offer an easy-to-digest PDF cheatsheet!

Today we use the Bluetooth Low Energy (BLE) standard to do this. Our primer introduces the BLE standard, explains how delegates function, and presents a basic development workflow.

The challenges to a front-end developer can be numerous. In addition to performing our day-to-day tasks, we are often expected to know a little (or a lot) about a wide array of subjects. Graphics, languages, user experience, accessibility, source control, security, browser compatibility, content management systems, and more.

This post was originally given as a presentation at RailsConf 2015.

Using Ruby code written by other developers is easy! Just add it to your Gemfile, run bundle install, and start using it.

But what's really happening when you do that? How can use you someone else's code just by putting it in your Gemfile?

Our Zero to BLE on iOS primer will have you gathering information from whatever the newest, hottest wearable mobile device is and sharing that information with your consumer's primary mobile device--iPhones and iPads. Evan K. Stone introduces basic concepts you'll need for developing for Bluetooth Low Energy (BLE), such as the terms Peripheral and Central; Advertising or Discovery; and commonly used classes like CBCentralManager, CBPeripheral, and more.

The other day, I helped debug an issue on some production Joyent Cloud servers (which use SmartOS, based on Illumos, the open-source successor to Solaris). The solution turned out to be so non-obvious, and the cause pretty interesting, so I thought it was worth writing up.

This post is a part news, part technical documentation, and part request for comment. I’m going to explain the technical nitty-gritty details of the planned next generation index that allows Bundler and Rubygems to know what gems exist and how to install them.

Detached is a tool for Macs that makes it easier to manage command-line processes running in the background. Developers spend a lot of time running commands and servers in terminal windows, but closing each window means closing the process running in it. Wouldn't it be great to be able to keep programs running even after their windows are closed?

So I titled this “How to be an ally,” but that’s a lie. You can’t be an ally. No one can. Ally-ness isn’t something that you can have intrinsically, any more than you can inherently be kindness, or rudeness. You can do ally actions. So probably a better name for this is How To Do Ally Work. But I’m getting a bit ahead of myself.

Bundler, Rubygems, and rubygems.org are vital infrastructure that every Rubyist uses just about every day. Over the last year, that infrastructure has seen a huge amount of change. This is an overview of the changes, an update on where things are now, and an explanation of where we’re going soon.

Business people and technology people are different. They use different language, think differently and worry about different concerns. Both sides of this divide are doing the best they can, but the old project management paradigm isn’t appropriate for software development. Agile methodologies address the very root of all the problems, shortening the feedback cycle to expose mistakes and misunderstandings quickly, when they are cheap to fix.

Last week I went to Tel Aviv, Israel for the Rails Israel and DevConTLV conferences, where I gave three talks on new developments in the Ruby community. The first talk was about how Bundler took down Rubygems.org last year, what we did to fix it, and the lessons that we learned as a result.

Many voices were heard at the 2013 Golden Gate Ruby Conference proclaiming it to be the best ever. Time will tell, but it was an outstanding conference, both technical and social. Ruby has come of age; Rails saw its 4.0 release this year. What can a conference add when many of the tricks have been found, tools have been built, adventures have been told? Well, GoGoRuCo 2013 had some good answers in store.

On a recent MVP, we needed a way for a client to maintain some simple information about several sponsors, like a name, an image, and a url. The client didn’t want to commit to a backend server this early in the game, so we needed a cheap but effective solution to store this data.

Security is a hard topic. It’s an especially hard topic in the Ruby community, where the security situation has historically been so great that hardly anyone has had to care about it. You may not know this, depending on how long you’ve been a rubyist, but Ruby security issues usually only come up once or maybe twice per year. They’re usually relatively benign, as those things go, so everyone updates as soon as it’s convenient, and life goes on.

A while back, I built a little iPhone app called Tag Along. It was my first iOS app and the idea was to build something as a way of teaching myself Objective-C and iOS development. Fast-forward a couple years, and, with the increased potential in iOS projects, it seemed like a good idea to brush up on my skills. So, I decided to learn about the changes in the ecosystem (ARC, storyboarding, etc.) and to see if I could update my app with any of these new technologies.

Nearly every business and software development methodology has value when applied to the right type of project and with the right amount of discipline. The amount of value realized depends on many things including the problem domain, the project participants' skill and discipline and the availability of the customer to address issues when discovered. Question: What’s the best methodology? Answer: It depends.

A little while back there was a now famous post on rapgenius.com that let the Rails world in on how we're all getting screwed by Heroku. This post, however, is not about the issue of whether this is right or wrong (or evil), but a way to work around the problem of requests being stuck in a long queue on one dyno while another dyno sits around watching reruns of "Friends."

For over a year now, I've been working remotely for Cloud City, telecommuting from my office in Salt Lake City. It's amazing being able to tap into the vibrant Ruby community in San Francisco and work with such great people and clients from hundreds of miles away. Google+ Hangouts, Skype, HipChat, screen sharing, document sharing, and now even Sqwiggle have become regular parts of my day — I love living in the future!

On a recent project we used Angular.js for some heavy lifting on the frontend. The framework has a steep learning curve but is pretty powerful once understood. A simple example of this is a currency filter for numbers passed into the view.

Recently, Cloud City Development was tasked with a project that included cropping an image upload in a number of squares of varying sizes based upon user selection. In order to accomplish this, we set out to write an extension to the paperclip library, which can be a hassle. Because this project already used paperclip, switching to something like dragonfly or carrierwave was not an option. This left us with test-driving the implementation with paperclip in RSpec.