Rietta.com Security logo
You are reading The Rietta Blog, a publication about the web since 2005. If you enjoy this, you may also want to subscribe via RSS.

The First Real Investor Meeting Post Investment


A client recently shared Gordon Daugherty’s article on Your First Board Meeting.

The gist is that when you first start your C Corporation with the intention of raising investment, the first board meetings are not really meetings at all. Just the co-founders signing some paperwork. But once investment is brought on, the lead investor is going to have a board seat and things become formal.

It is sound advice to keep in mind if you see yourself raising capital for your startup company.

Oh, and one more thing, if you have ever watched an episode of Shark Tank, you know that Investors Write Checks for Outcomes, Not Activities (another post by Gordon on his blog). Be sure to keep that in mind as an entrepreneur considering approaching outside investment.

[Video] Project Estimation With Mike Cohn


Estimating software projects is hard, really hard.

Mike Cohn (@mikewcohn on Twitter) is the author of a number of books on Agile estimation and planning from which the Rietta team has learned a lot that has directly improved the work we do.

Here is one of Mr. Cohn’s 2007 presentations at Google. Even though it is eight years old, it’s entirely relevant to today’s projects and web applications. It is worth your time.

Uniqueness Validation Race Condition in Ruby on Rails Applications


Are you a practicing Ruby on Rails developer? It doesn’t matter if you are called a junior developer, senior developer, or the janitor. It is surprisingly easy for race conditions to slip into your code and out into production. Some of these can lead to annoying duplicate e-mails in your database or they could lead to serious security issues that impact your company’s bottom line.

As you read on, I’m going to teach you a bit about race conditions, also called hazards in some engineering circles, and give you a practical example of how one can slip into a Rails application if you were to choose to enforce validation constraints only within an application’s models with a validates :field_name, uniqueness: true rather than through database constraints.

Before we begin, I do want to remind you about one thing. Preventing race conditions is not just something that can be added to Ruby on Rails because the methods for automatically detecting race conditions is an NP-hard problem in computer science. That’s why it’s so important that you understand something about spotting situations where they may occur so that you stand a better chance at leaving them out of your next deploy.

10th Anniversary Blog


Today, Wednesday, April 8, 2015, is the tenth anniversary of this blog. I was a Georgia Tech student at the time of the first post. I was a student at Georgia Tech, about to present my research on SQL Injection at the UROC symposium the next week. That research project lead to my first published paper on Application Layer Intrusion Detection for SQL Injection that was accepted as a single author paper by the ACM while I was still an undergraduate student and was instrumental in my decision to pursue Information Security at the graduate level.

The blog itself has had its starts and stops with some challenges settling into a sustainable post schedule. I started this as a CS student, not an author, so some writing disciplines can only be developed over time.

It has had some posts that have been crazy popular, with thousands of readers a month for years, and some that I do not think anyone has ever looked at other than myself. But post after post, readership has increased to the point that we now consistently have more than 9,000 visitors and I hope to cross the 10,000 mark within the year.

Adding a Rake Task for SQL Views to a Rails Project


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.

Recommended Content for Agile Startups and Entrepreneurs - March 2015 Edition


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.

How to Use Story Points to Estimate a Web Application Minimum Viable Product


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.

Mike Cohn’s “User Stories Applied” Page 4

In short, user stories are designed to facilitate clear communication between technical and non-technical members of the project team, and to prioritize work. The collection of well-formed user stories serve as a roadmap that can help manage the uncertainty inherent in software projects.

Get the Current Year in the Ruby Programming Language


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 class
   current_year = Time.new.year  # or Time.now.year

   # Using the Date class
   current_year = Date.today.year

   # Using the DateTime class
   current_year = DateTime.now.year

New Video! Understanding & Defending Against Data Breaches


Nash.rb Understanding & Defending Against Data Breaches starts with a proper understanding of Professional Ethics

A few weeks ago, I spoke with the Ruby users’ group in Nashville, TN, about the importance of understanding the root cause of data breach security incidents and countermeasures that developers can put in place to help prevent them. It’s up on YouTube for your enjoyment at Understanding & Defending Against Data Breaches, as a Practicing Software Developer – Nash.rb.