I have previously written about Using Rails and SQL Views for a Report. A practical consideration when employing SQL views, which create wonderfully fast read-only tables that can be used by ActiveRecord models seamlessly, in a Ruby on Rails project is where to maintain them in a project.
One approach is to use migrations, since that’s where database stuff normally goes. But a big downside is that this approach is not DRY because changing the SQL view requires a new migration that drops the old view and replaces it with the updated version. Simply changing a field in the SQL view requires copying and pasting the entire definition over again. That’s just annoying!
The second, and in my opinion better approach, is to treat SQL views more like models.
We’d like to post helpful content more often and find ourselves frequently
lacking the available time to compose well-written posts of our own, but we are
constantly reading the best material we can find on the web for a variety of
topics of interest to us, our business, and our clients, so today I’d like to
begin sharing some hand-picked “best-of” selections from what we’ve been
learning from lately, and hopefully we can begin to post more regularly by
including high-quality content recommendations like this on a regular schedule.
Here are some excellent and highly recommended sources of information and
education for startups, entrepreneurs, or anybody who works with them.
A user story is a concise written description that describes an item of functionality that is valuable to a user or a purchaser of a web application, preferably from the point of view of that person’s individual desires. They typically consist of three components:
a written description of the story used for planning
conversations about the story that serve to flesh out the details of the story
tests that convey and document the desired outcome and can be used to determine when a story is complete
The best user stories are sufficiently small to be accurately estimable by developers and arranged in a prioritized list where a member of the development team can always confidently pick the next most important task to work on at all times during his or her work week.
But please remember that when applied properly, user stories are not just a form of requirements documentation, but are instead a placeholder for a conversation among team members. Consider that:
Ron Jeffries has named these three aspects with the wonderful alliteration of Card, Conversation, and Confirmation (Jeffries 2001)….Rachel Davies (2001) has said that cards “represent customer requirements rather than document them.” This is the perfect way to think about user stories: While the card may contain the text of the story, the details are worked out in the Conversation and recorded in the Confirmation.
When learning Ruby on Rails, sometimes you just need to get the current year as a number. I posted one example on why this is a useful way on a real-life website in the 2011 post on how to automatically update copyright notices.
In this article, I will show you some methods for getting the current year, such as the number 2015. I will then show you how to benchmark the methods to determine which is the fastest method for you, given your machine and Ruby version.
Okay, just how do I get the Current Year in Ruby?
It’s easy. Just use any of the Date/Time objects and call the year method, like this:
# Using the Time classcurrent_year=Time.new.year# or Time.now.year# Using the Date classcurrent_year=Date.today.year# Using the DateTime classcurrent_year=DateTime.now.year
Two new videos of the data breach talk and class that I lead in August and December are now up on YouTube! I hope that it helps you level up on your security knowledge because good software security needs to be a moral stance.
The POODLE SSL vulnerability marks the third major security flaw discovered this year that impacts the security of millions of websites.
The attack works by forcing the connection to downgrade from the newer TLS protocol to the 18 year old SSL 3 protocol, which is obsolete and insecure, and then utilizing a weakness to calculate small strings of data from the encrypted communication, such as session cookies.
When you read books on security, at some point the importance of classified information systems is covered. These typically look at Mandatory Access Control in the context of military classifications, such as top secret, secret, for official use only, and sensitive but unclassified. While the existence of commercial classification systems in use outside of a government context may be mentioned, it’s not as common to see a commercial information classification system presented.
In this article, I shall present to you a commercial information classification system that you can use to help plan your web application’s security standards based upon information sensitivity considerations. It is the system that I have developed for use with my own clients and have presented on publicly as part of my series on how a Ruby developer can help prevent a data breach.
We’ve been hearing a lot recently about law enforcement officials
upset over the so-called “going dark” problem, with Apple and Google
implementing stronger encryption solutions for their mobile platforms.
These government organizations are arguing that by making encryption easy to
use and unbreakable, Apple and Google will help criminals escape from
justice by impeding investigative work.
“You can’t build a backdoor that only the good guys can walk through.”
As security-focused developers, we discuss these issues
quite often at Rietta. Sometimes it is difficult to articulate our opinions on the subject, but luckily
Bruce Schneier’s post on the subject
does a superb job of laying out the major considerations along with supporting
evidence, which is well worth a read.
“… let’s wait for some actual evidence of harm before we acquiesce to police demands for reduced security.”
The essential takeaway is that providing a way for the government to
legitimately access the data means there is also a way for the various bad guys
of the world to access it as well. At the end of the day, the goal is to protect
people from harm. Unbreakable encryption can certainly help with that, but
sometimes-breakable encryption usually can’t.