| desc "build and deploy sitemap" | |
| task :refresh_sitemap => :environment do | |
| s3_credentials = YAML.load_file("#{Rails.root.to_s}/config/amazon_s3.yml")[Rails.env].symbolize_keys! | |
| # builds the sitemap and deploys to S3 without notifying search engines | |
| Rake::Task["sitemap:refresh:no_ping"].invoke | |
| AWS::S3::Base.establish_connection!( | |
| :access_key_id => s3_credentials[:access_key_id], | |
| :secret_access_key => s3_credentials[:secret_access_key] |
| :+1: | |
| :-1: | |
| :airplane: | |
| :art: | |
| :bear: | |
| :beer: | |
| :bike: | |
| :bomb: | |
| :book: | |
| :bulb: |
| if (isTrue) | |
| { | |
| // return true value | |
| return true; | |
| } | |
| else | |
| { | |
| // if not... | |
| // return false value | |
| return false; |
| group :development, :test do | |
| gem 'sqlite3' | |
| end | |
| group :production do | |
| gem 'pg' | |
| end |
Sublime Text 2 ships with a CLI called subl (why not "sublime", go figure). This utility is hidden in the following folder (assuming you installed Sublime in /Applications like normal folk. If this following line opens Sublime Text for you, then bingo, you're ready.
open /Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl
You can find more (official) details about subl here: http://www.sublimetext.com/docs/2/osx_command_line.html
One of the problems with advancing the discussion on DCI is that we lack a comparable alternative pattern that has the same goals, but favors a low ceremony approach. The closest thing we have to that is Rails concerns, but they are more like distant relatives of the DCI concepts rather than first cousins, and that makes comparisions between the two approaches not especially fruitful.
I am considering the idea of experimenting with my own paradigm that captures the intent and purity of DCI, but with the convenience of concerns. Please note that this is just the starting point of a conversation, it is NOT a promise of comercially available cold fusion or a cure for cancer. It's just a gist with an idea on it I'd like to hear your thoughts on.
What if we had a top-level topology that was split into Models, **Rol
| Get the Heroku db as detailed here: | |
| http://devcenter.heroku.com/articles/pgbackups#exporting_via_a_backup | |
| 1. heroku pgbackups:capture | |
| 2. heroku pgbackups:url <backup_num> #=>backup_url | |
| - get backup_num with cmd "heroku pgbackups" | |
| 3. curl -o latest.dump <backup_url> | |
| Then locally do: | |
| $ pg_restore --verbose --clean --no-acl --no-owner -h localhost -U myuser -d mydb latest.dump |
| #!/bin/sh | |
| # | |
| # Suggested name for this script: git-clean-stale-branches | |
| # | |
| # This script will help to remove "stale" branches from a remote | |
| # repository (by default the "origin" repository). Stale branches | |
| # are any branches that does not exist in the local repository. | |
| # | |
| # This script should be run in the local repository. It will print | |
| # out a git command to remove all branches from the remote repository |
| # | |
| # Don't want to run PostgreSQL as a service? Want to manually start and stop it? | |
| # >> bundle exec rake rabbitmq:mac:start | |
| # >> bundle exec rake rabbitmq:mac:stop | |
| # | |
| namespace :rabbitmq do | |
| namespace :mac do | |
| desc "Starts a Mac brew installed RabbitMQ server." |
