In Rails, User.find_by_name(“myName”) will run sql like “SELECT users.* from users where users.name = ‘myName’”
We have found that it is occasionally producing “SELECT users.* from users where users.name = 0″.
This is invalid and will give a database error. Help!
The 3.0.x and 2.3.x lines are affected. It’s a mega security flaw in JSON parsing. Upgrade your old apps now. 3.1.x and 3.2.x lines unaffected. Read more here: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/1h2DR63ViGo
Talk about Software Development and Agile.
There is an interesting article by Swizec Teller over at Business Insider talking about why programmers do their best work late at night.
This is not the case at Pivotal. Generally when we have clients committing code late at night, the team ends up having to refactor it and get tests around it the next day. Often leading to a net loss of productivity even if the amount of time invested was greater. So why then do so many developers seem to agree with the article?
The article has two general theories, and unfortunately I think they are correct for most developers. However, rather than having developers commit all their code at night, Pivotal has better solutions to problems the article talks about.
The first theory is that developers need to hold the whole code base in their head, and any interruptions will force them to start over. So late at night is the only time developers are able to get work done without interruptions.
At Pivotal, we have large open spaces that would generally provide enough distraction to keep any work from being done if this theory were always true. So how do we get anything done then? We avoid the problem altogether. We don’t keep the whole code base in our heads, we simply don’t have to. Since all of our code is test driven, you are focused only on making a single test pass at a time. You don’t have to worry about the whole system. Once your test passes, you can run all of the tests, and they will tell you if you’ve broken any other part of the system. Test driving code also tends to make code that is more loosely coupled, meaning it is easier to change one part of the system without changing the others. So we don’t have to worry about the other parts all at once, we can do them one piece at a time.
The second theory, is really just the first one but from the developers perspective. He says that once it is late enough, you are so tired that nothing can distract you from writing code. Essentially, once nobody else is distracting a developer, they have a tendency to distract themselves by checking email, web, IM, etc. And once it is late enough, these distractions either go away, or you are too tired to devote attention to them any longer.
I certainly agree with the problem stated here. If left to my own devices, I will often find a dozen other things to occupy my time, rather than writing code, even if I find the code interesting. This is, in my opinion, one of the biggest advantages of pair programming. Your pair is simply not interested in your email. Because of this, a pair of developers is able to stay on task all day long. The productivity boost from this is tremendous. I simply had no idea how productive I could be until I started pair programming. There are many other benefits to pairing: training of the weaker developer, knowledge transfer, shared ownership of code, better code design. If I could only pick one benefit though, keeping everybody on task would probably be it.
Unfortunately, it is also one of the hardest selling points of pairing programming. The decision of pairing or not, is usually not made by the developers. Most managers are going to see the situation of two people working on the same problem as a waste of time. Splitting them up should double the productivity right? Unfortunately it’s really hard to say, “We don’t actually work as hard when we are working by ourselves.” It’s not a proud fact, and you don’t really feel that it should by the foundation of your “why we should pair” argument. So try to sell them on the other benefits first…
Since Pivotal developers are so productive during the work day, couldn’t we be extra productive by going home and working late into the night? Maybe, but probably not. Working late tends to throw schedules off. It’s hard to get to work at 9 if you go to bed at 4. Everybody starting at the same time means everybody pairs. It’s one of the few drawbacks of working at Pivotal, your work schedule is not flexible if you are pairing.
Working at Pivotal can also be very tiring. We only work 40 hours a week, but because we are pairing full time, you can get exhausted by the end of the day. You especially see this in new Pivots. Their first couple of weeks are pretty intense. After that people seem to fall into the rhythm of things.
The original article wasn’t trying to solve a problem, it was only explaining why developers tend to do their best work at night. So if you are developer, I’d recommend using the solutions Pivotal uses rather than working until 4am. If you manage developers who do this, your job is more difficult. Developers are not easy to change. The reason it works at Pivotal is we only hire people who are capable of working this way. Some people are simply not good socially, and will not be a good pair. So it will be a struggle, and may require new people, but in the end, your development will be better off.
Before we start, the .gemspec itself only appears once. Here it is, as generated by bundle init and hand-tweaked for relevance:
lib = File.expand_path("../lib", __FILE__)
$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
require "your_gem/version"
Gem::Specification.new do |s|
s.name = "your-gem"
s.version = YourGem::VERSION
s.authors = ["Your Name"]
s.email = ["you@example.com"]
s.homepage = "https://github.com/you/should-use-github"
s.summary = "Describe this gem like you're talking to me."
s.description = "Describe this gem like you're talking to your mom."
s.require_paths = ["lib"]
s.files = `git ls-files`.split("n")
s.test_files = `git ls-files -- spec/*`.split("n")
s.add_dependency "hashie", "~> 2.0"
s.add_development_dependency "rspec", "~> 2.12"
end
But what does all this mean? Moreover, how do all these crazy bits fit together?
The most important component of any gemspec is the list of files that it includes when building the gem. After all, a .gem file is just a tarball with a metadata header written in Ruby. Here’s how we make that happen:
s.files = ['file/one', 'file/two']
s.test_files = ['spec/one', 'spec/two']
Let’s exploit part of git to give us the list of files. Don’t use git on your project? Start using git. Problem solved! Here’s what it gives us:
$ git ls-files
.gitignore
.rvmrc
Gemfile
LICENSE
README.md
your-gem.gemspec
lib/your_gem.rb
lib/your_gem/version.rb
spec/lib/your_gem.rb
spec/spec_helper.rb
We can make this output into a Ruby array of strings quite simply:
`git ls-files`.split("n")
Now, gems are laid out in a conventional way. That means a lib directory, a spec directory and some predictable files. That means nobody has to guess where your files are, which is fantastic!
Now let’s say you want to exclude your .rvmrc and .gitignore, because those files aren’t really all that important:
`git ls-files`.split("n") - %w(.rvmrc .gitignore)
Note: exclude Gemfile.lock from git, even though it might exist in your directory. This is conventional.
Your gem’s classes are called YourGem, while they live in files named your_gem. As a matter of taste, I believe gems should be named your-gem. There’s an argument to be made that gem names should match their requires (i.e., the gem should be named your_gem).
The first component here is the version number for your gem. In this example, the your_gem/version.rb looks like this:
module YourGem
VERSION = "0.1.0"
end
This is a Semantic Versioning string, and it’s the Simplest Thing that Could Possibly Work for a version.
This is the fun part. I’m of the opinion that dependencies should be as loose as possible until they’re not, but that throwing them away by doing >= 0 is the wrong approach.
For example, the above file will pull in RSpec as a dependency, but require any version that matches a pattern like 2.y.z, as long as y is above 12. Note that z is allowed to be anything, which allows patch versions to be included.
Of course, this means that everyone in the community has to play along and not break their gem on a minor version bump. Also, the community now includes you!
So now you’ve got a conventional gem with loosely-required dependencies. How do you know if these change? Well, if you’re on github, you can use Gemnasium to watch for new dependency versions and see if anything’s broken!
Dropping a new version of your gem is as easy as gem release with @svenfuchs‘s gem-release gem.
As of git 1.8.0, git rebase learned “–edit-todo”. This is something you can use to edit the todo list while in the middle of a rebase. For example, if you mark a commit as e (for edit) when you initially edit the todo list, when git stops at that commit allowing you to edit it you can then git rebase --edit-todo to edit the remaining portion of the todo list.
If you set up some bindings such as
viewClass = Backbone.View.extend({...})
view1 = new viewClass();
view2 = new viewClass();
model.bind("event", view1.myFunction, view1)
model.bind("event", view2.myFunction, view2)
and then want to unbind one of the callbacks…
model.off("event", view1.myFunction)
you will unbind both callbacks. You need to use
model.off("event", view1.myFunction, view1)
This is fundamentally because of javascript prototypes that mean view1.myFunction == view2.myFunction
Ruby 1.9 regexs can match Unicode Categories . Not filtering out Joëlle in your validations has never been so easy (/p{L}/)!
Railsbridge is a monthly-ish workshop to teach programming, primarily focused at women.
December’s Railsbridge event will be at Pivotal SF on December 14-15.
All you pivots in the office know tons about Ruby and Rails. Please come to the workshop to spread your knowledge and be awesome!
I want to TDD contenteditable, where a DT element can be changed and it’s underlying resource receives an PUT. Is this even possible?
Today’s github outage drove us to try ssh urls instead of the https urls we were using. A pleasant speed improvement in deployment time resulted.