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.
Caching Optimization Isn't One Size Fits All
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.
Three Cloud City Development Clients Acquired Recently
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.
New to open source and wondering where to start?
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.
For as little as $5, develop your very own personal Tile or Trackr knockoff.
Now that you've gotten started developing for Bluetooth Low Energy (BLE) devices on iOS using the Core Bluetooth framework, it's time to talk about iBeacons. In this bonus installment of our Zero to BLE with iOS primer, Evan K. Stone shows you how to use a Estimote iBeacon to track your luggage through its journey to you at the airport.
Swift BLE tutorial will have you connecting and interacting with the Internet of Things (IoT) in no time at all!
In this third and final installment of our Zero to BLE with iOS primer, Evan K. Stone updates Apple’s sample demo app, which was last revised in 2012, and converts it from Objective-C to Swift. While the revised sample app’s behavior is similar to the original, it behaves slightly differently, going beyond what the demo accomplishes to cover advanced topics such as Disconnection and Reconnection; Backgrounding; and State Preservation and Restoration.
Ready to contribute to the Internet of Things? Learn the key to success with Bluetooth Low Energy (BLE) and develop an iOS app with Swift.
In Part 2-Swift Edition of the Zero to BLE on iOS, Evan K. Stone shows you how to develop an iOS app with Swift 2. He'll introduce you to the Texas Instruments SensorTag and then walk you through the creation of a mobile app that displays the current temperature and humidity.
Testing Rails can be challenging. Handy roadmap shows it's possible to have well-tested code & an enjoyable workflow.
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!
Not everyone has screaming fast Internet. But slow mobile connections don't have to spell doom for Angular.js app loads.
Two common annoyances -- an empty view and an API data delay -- can be avoided. Learn how to make initial page loads for your Angular on Rails apps as responsive as server-generated pages.
New wearable devices are everywhere and consumers expect your apps to communicate with their iPads and iPhones out of the box.
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.
Get your apps communicating in this Internet of Things era.
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.
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.