It’s been almost 10 years since my last post… Here is a short one I’ve been meaning to write for a while.
Whatever profession you are a part of it requires some set of skills in order to accomplish. The skill is useful, or at least someone thinks it’s valuable enough to pay you to perform it. At the beginning of your career you are learning many new things every day. Your new job/project constantly pushes the boundaries of your experience. As time progresses and you become able to perform your job with less assistance from mentors and co-workers. The great initial momentum at which you learn new skills and refine existing ones begins to peter out. This is not guaranteed to happen, but it gets harder to find time to really focus on improving your craft. It’s something I’ve found myself struggling with this past year.
Recent events like the leaking of PRISM have reinvigorated the concerns of many for their privacy online. This is a broad subject, and I am by no means a security expert, but I would to talk about an easy way to give a little control back to your users.
Most rails applications have some sort of “user” to represent either customers who are consuming the service or administrators that are publishing content to the web application. It’s important that these users are authenticated (ensuring that they are who they say they are). For user authentication in a Ruby on Rails application, Devise is one of the best solutions out there. It has a very active community and wide variety of options and extensions to fit your business model. Sometimes customers may ask for or the application requires an additional layer of authentication beyond the basic username/password combination.
If you have been part of building an application that has lasted longer than a month then you’ve probably had some troubles as the project grows. Business logic requirements get more and more complicated. Features change direction. You occasionally “hack” something just to satisfy a release or an urgent bug fix, saying “I can refactor/clean this up this later…”
The use of “includes(:association_name)” in rails is a widely accepted rails best practice to prevent n + 1 queries in your views. If you aren’t sure what either of those mean check out the ruby on rails guide about eager loading associations. When you are retrieving a collection of things, this will automatically retrieve the associated object from the database and store it into memory. Without this rails would need to call an extra query for each object when you call an attribute on the association.
In a project this week I had send some http requests from a ruby program and do something with the response. One of the requests needed to be https so I tried something along these lines…
This post is just a friendly reminder for those that practice TDD/BDD to make sure they are not putting more ceremony into their tests than is necessary. Use mocks and stubs instead!
Productivity and concentration are two very important words to someone who writes code for a living. There is a wide variety of tools, methodologies, tricks and “hacks” out there that claim to help one improve in these areas. One such technique that I’ve adopted over the past couple of months is known as the “Pomodoro”.
For the current project I am working on we are using the CarrierWave gem as an upload solution for users to upload files. It is a great solution for uploading files to your rails that allows you to specify “versions” of uploaded images that are cropped and/or resized to the width/height you need. This is a great feature for creating thumbnails or other precise image sizes that was needed for this project. Unfortunately we needed the users to be able to have this single CarrierWave “uploader” to upload many differenty file types of files not just images.
This was the one post I made on my tumblr blog. Since it looked kind of lonely up there I thought I would bring it over…
© 2013 Lupine Software Development