A ZSH theme optimized for people who use:
- Solarized
- Git
- Unicode-compatible fonts and terminals (I use iTerm2 + Menlo)
For Mac users, I highly recommend iTerm 2 + Solarized Dark
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
When you are not very skilled in some area, you are more likely to think you’re actually pretty expert at it.
In the paper “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments” [AUOIHDIROOILTIS] , psychologists Kruger and Dunning relate the unfortunate story of a would-be thief who robbed a bank in broad daylight. He was incredulous at his prompt arrest, because he was under the impression that wearing lemon juice on your face would make you invisible to security cameras.
The “lemon juice man” never suspected that his hypothesis was, er, suspect. This lack of accurate self-assessment is referred to as second-order incompetence, that is, the condition of being unskilled and unaware of it.
This condition is a huge problem in software development, because many programmers and managers aren’t aware that better methods and practices even exist. I’ve met many younger programmers (one to five years of experience) who never have been on a successful
É um design pattern que o Rails implementa a partir da gem ActiveRecord.
Serve para conectar a camada Model da aplicação com tabelas do database, para assim criar um modelo de domínio persistível, onde a lógica (Model) e dados (BD) são apresentados em uma única solução.
Já persiste no BD:
obj.create
#!/usr/bin/env bash | |
uninstall() { | |
list=`gem list --no-versions` | |
for gem in $list; do | |
gem uninstall $gem -aIx | |
done | |
gem list | |
gem install bundler | |
} |
# Put this file on config/initializer | |
# This will create an empty whitelist of attributes available for mass assignment for | |
# all models in your app. As such, your models will need to explicitly whitelist | |
# accessible parameters by using an attr_accessible declaration. This technique is best | |
# applied at the start of a new project. However, for an existing project with a thorough | |
# set of functional tests, it should be straightforward and relatively quick to insert this | |
# initializer, run your tests, and expose each attribute (via attr_accessible) as dictated | |
# by your failing tests. |
class PostsController < ActionController::Base | |
def create | |
Post.create(post_params) | |
end | |
def update | |
Post.find(params[:id]).update_attributes!(post_params) | |
end | |
private |
For a while, I have felt that the following is the correct way to improve the mass assignment problem without increasing the burden on new users. Now that the problem with the Rails default has been brought up again, it's a good time to revisit it.
When creating a form with form_for
, include a signed token including all of the fields that were created at form creation time. Only these fields are allowed.
To allow new known fields to be added via JS, we could add:
articles = Article.find(:all) | |
articles.each do |article| | |
next if article.published_at.nil? | |
published_at = article.published_at | |
year = published_at.strftime('%Y') | |
month = published_at.strftime('%m') | |
day = published_at.strftime('%d') | |
require File.expand_path(File.dirname(__FILE__) + '/../test_helper') | |
class BuildStatusTest < ActiveSupport::TestCase | |
test "remove the old statii" do | |
assert_equal 2, BuildStatus.count | |
BuildStatus.expire_old | |
statii = BuildStatus.all | |
assert_equal 1, statii.size | |
assert statii[0].updated_at >= 30.days.ago | |
end |