raskchanky

#
# Add this to the bottom of environment.rb
#

require 'smtp_tls' 

ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.raise_delivery_errors = true

ActionMailer::Base.smtp_settings = {

raskchanky

# When a spammer wants to attack your site, they'll likely send an automated bot
# that will blindly fill out any forms it encounters. The idea of a "honeypot" is that
# you place a hidden field in a form. That's the honeypot. If this field is filled in, then 
# it's almost certain to be a spammer (since a normal user wouldn't have even seen the 
# field), and the contents of the form can safely be discarded. 

# Normally, you would implement a "honeypot" in a Rails app with some combination of a 
# special field in a particular form, and then some logic in the corresponding controller that 
# would check for content in the "honeypot" field. This is somewhat of an inefficient 
# approach, because it requires special code (not DRY), and bots are still going through an 

raskchanky

# http://www.jamesbritt.com/2007/12/18/sending-mail-through-gmail-with-ruby-s-net-smtp
# http://d.hatena.ne.jp/zorio/20060416

require "openssl"
require "net/smtp"

Net::SMTP.class_eval do
  private
  def do_start(helodomain, user, secret, authtype)
    raise IOError, 'SMTP session already started' if @started

raskchanky

development: &global_settings
  database: textual_development
  host: 127.0.0.1
  port: 27017

test:
  database: textual_test
  <<: *global_settings

production:

raskchanky

Programming Achievements: How to Level Up as a Developer

This gist is part of a blog post. Check it out at:

http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer

raskchanky

# ~/.tmux.conf
#
# See the following files:
#
#   /opt/local/share/doc/tmux/t-williams.conf
#   /opt/local/share/doc/tmux/screen-keys.conf
#   /opt/local/share/doc/tmux/vim-keys.conf
#
# URLs to read:
#

raskchanky

    desc "Create about and revision files."
    task :rev_deployment, :roles => [:app, :web] do
      require 'grit'
      require 'chronic'
      # include Grit
      work_dir = File.join(File.dirname(__FILE__), '../../')
      g = Grit::Repo.new(work_dir)
      since = Chronic.parse('last week friday')
      msg = "\n"
      rev_file = File.join(File.dirname(__FILE__), '../../','tmp/revision.txt')

raskchanky

#!/usr/bin/env sh

##
# This is script with usefull tips taken from:
#   https://github.com/mathiasbynens/dotfiles/blob/master/.osx
#
# install it:
#   curl -sL https://raw.github.com/gist/2108403/hack.sh | sh
#

raskchanky

;
; Netatalk 3.x configuration file
; http://netatalk.sourceforge.net/3.0/htmldocs/afp.conf.5.html
;

[Global]
; Global server settings
vol preset = default_for_all_vol
log file = /var/log/netatalk.log
uam list = uams_dhx.so,uams_dhx2.so

raskchanky

With Heroku's new JRuby support you may have already seen that you can run TorqueBox Lite on Heroku. But, that only gives you the web features of TorqueBox. What about scheduled jobs, backgroundable, messaging, services, and caching?

With a small amount of extra work, you can now run the full TorqueBox (minus STOMP support and clustering) on Heroku as well! I've successfully deployed several test applications, including the example Rails application from our Getting Started Guide which has a scheduled job, a service, and uses backgroundable and messaging.

The version of TorqueBox you'll be running on Heroku is almost identical (two commits newer) than TorqueBox 2.2.0. We had to expose a small extra flag to control when TorqueBox actually binds to the HTTP port since Heroku uses that as the trigger that your application is up and ready to serve reque