omnisis

require 'bindata'

class CustomProtocol < BinData::Record
    endian  :big
    stringz :command_word
    uint8   :op1
    uint8   :op2
end

oogali

#!/usr/bin/env ruby

require 'rubygems'
require 'socket'
require 'ipaddr'

MCAST_GROUP = {
  :addr => '224.5.6.7',
  :port => 12345,
  :bindaddr => '192.168.1.2'

perplexes

Buildpacks

Heroku uses buildpacks to compile your application into a slug that is used across dynos for scaling horizontally quickly. A slug is a tar.gz archive of your app’s repository with certain pre-deploy features baked into the filesystem. Since everything to run your application is included in the archive, scaling becomes a simple matter of transferring it to a dyno, unpacking, and running the appropriate process. This is how Heroku achieves scaling-by-moving-a-slider.

For example, the Ruby buildpack will:

• install ruby locally
• install the jvm/jruby (if you’re using it)
• install/run bundler and install your gems to Rails.root/vendor
• create your database.yml (which ends up reading from your app’s environment variables)

benolee

$ rails r 'File.write("./viz.html", Rails.application.routes.router.visualizer)'
$ ruby -r webrick -e "s = WEBrick::HTTPServer.new(:Port => 8080, :DocumentRoot => Dir.pwd); trap('INT') { s.shutdown }; s.start"
$ open "http://localhost:8080/viz.html"

emilsoman

class CustomAuthFailure < Devise::FailureApp
  def respond
    self.status = 401 
    self.content_type = 'json'
    self.response_body = {"errors" => ["Invalid login credentials"]}.to_json
  end 
end

willurd

Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.

Discussion on reddit.

Python 2.x

$ python -m SimpleHTTPServer 8000

jendiamond

Presentation slides

Create a Gem - Make it a CLI - Add Rspec Tests

Create a Gem - Make it a Command Line Interface - Add Rspec Tests Using Bundler & Thor

#Creating your own Gem

1. Run this command in your Terminal. This creates and names all the files you need for your gem. We are going to create a Lorem Ipsum Generator; you can call it whatever you want but seeing as we are creating a Lorem Ipsum generator we'll call it lorem. Read about gem naming conventions.

atrepca

• Add a Heroku drain for your app to forward the logs to your rsyslog server:

    heroku drains:add --app my-prod-app syslog://logging01.prod.mydomain.net:514
  

• List the drain you just created to get the unique Drain ID:

    heroku drains -x --app my-prod-app
  

• On the rsyslog server save the logs coming from Heroku to separate files, without duplicating to /var/log/messages (thanks to the & ~). Create a /etc/rsyslog.d/90-heroku.conf file containing:

    if $HOSTNAME startswith 'Drain_ID' then /opt/log/heroku/my-prod-app.log
  

& ~

mobilemind

# delete local tag '12345'
git tag -d 12345
# delete remote tag '12345' (eg, GitHub version too)
git push origin :refs/tags/12345
# alternative approach
git push --delete origin tagName
git tag -d tagName

schneems

A not politically correct assertion of my feelings towards a piece of software:

Note: Repetition builds cynicism, asset_sync isn't bad, but when an asset problem cannot be solved via support it gets escalated to me. Often times someone using asset_sync the problem is due to their use of the library and not from Heroku.

Backstory

The asset sync gem uploads your assets (images, css, javascript) to S3. From there you can either point browsers to the copy on S3 or use a CDN + the S3 bucket. It's a good idea, and solved a problem at one time.

It is no longer needed and you should now use https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn instead. So rather than copying your assets over to S3 after they are precompiled the CDN grabs them from your website instead. Here's some reasons why it's better.