nathany

# Activate the gem you are reporting the issue against.

# gem 'activerecord', '4.0.9' # works
gem 'activerecord', '4.0.10.rc1'

# gem 'activerecord', '4.1.5' # works
# gem 'activerecord', '4.1.6.rc1'

gem 'pg'
require 'active_record'

collinvandyck

package main

import "testing"

type Stuff struct {
    Hello   string
    Goodbye string
    Slice   []string
}

hash

Go Package Management



interface type version

type version interface {
	string Version()
}

hajimehoshi

package main

// #cgo CFLAGS: -x objective-c                                                                                                                                               
// #cgo LDFLAGS: -framework Cocoa                                                                                                                                            
// #import <Cocoa/Cocoa.h>                                                                                                                                                   
//                                                                                                                                                                           
// void run() {                                                                                                                                                              
//   @autoreleasepool {                                                                                                                     

schneems

On heroku compiles are done without environment variables. Why?

If you compile the same source code you will ge the exact same compiled app output every time.

This is determinisim. The app build is deterministic.

If you allow environment variables at build time, the output of the app is no-longer deterministic based soley on the code. You can deploy the same code and get different results.

If you are using user-env-compile your app builds are now non-deterministic.

BanzaiMan

$ jruby -v
jruby 1.7.5.dev (1.9.3p392) 2013-09-04 090d5dd on Java HotSpot(TM) 64-Bit Server VM 1.7.0_25-b15 [darwin-x86_64]
$ time jruby -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-Xverify:none -e 'require "rails"'
jruby -J-XX:+TieredCompilation -J-XX:TieredStopAtLevel=1 -J-Xverify:none -e   5.18s user 0.47s system 136% cpu 4.142 total
$ time jruby -e 'require "rails"'                    
jruby -e 'require "rails"'  14.60s user 0.44s system 202% cpu 7.444 total

steveklabnik

Gems that need help with Rails 4

• cucumber-rails
• simple_form - has a 3.0.0.rc but it depends on rails 4.0.0.rc1
• delayed_job_active_record - has a v4.0.0.beta3 so likely ready to release soon
• spork-rails - has no indication of even a beta for rails 4
• authlogic: binarylogic/authlogic#368
• activeadmin/activeadmin#1963

mattetti

package main

import (
	"bytes"
	"fmt"
	"io"
	"log"
	"mime/multipart"
	"net/http"
	"os"

ericlathrop

Say there's a Go app at github.com/supermighty/app, which has a package a that references b. If I fork that repository to github.com/ericlathrop/app, now the local file $GOPATH/github.com/ericlathrop/app/a/something.go still has the line

import ("github.com/supermighty/app/b")

so when I edit $GOPATH/github.com/ericlathrop/app/b/something.go, my changes are never seen in a because it's still using the original copy of b!

The workaround is to symlink the original repository path to the fork's path:

steveklabnik

Versioning is an anti-pattern
=============================

We often say "use the right tool for the job", but when managing change
in software systems, we always use versioning. Hypermedia APIs are
actually hindered by introducing versioning and manage change in a
different way. With that in mind, there are also a lot of options for
managing change in a Hypermedia API. We'd like to change our service and
break as few clients as possible. Versioning is only one way to manage
change, though... and my contention is that it's not appropriate for