Posts tagged ruby

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.

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!

Improving diversity in tech won’t happen overnight and can’t start until we include everyone. Andre Arko covers five things he’s seen and experienced over the last six years of working on Bundler. Before jumping in blindly, keep in mind that they may not work for everyone. Pay attention to how tech as a field mistreats underrepresented people and actively work to fix it.

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?

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?

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.

This is a difficult blog post to write. At Cloud City Development, we had many conversations about the problems with diversity and sexism in tech, such as women reporting harassment and abuse at tech conferences, online conversations challenging the Ruby culture, and community struggles to make everyone feel welcome, especially marginalized groups. As individuals, employees, and Ruby community members, what is our role in creating the kind of community we want to be in?

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.

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 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!

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.