knowtheory

Rando's DM Goals
================

 * Adapters (complete)
 * Types (waiting on dkubb to realize my ideas are right)
 * Migrations
   * Work with the new type system
   * Combine auto- and normal migrations 
 * Alternative Methods of Doing Joins (foreign_key, links, embedded) See: http://gist.github.com/94246

knowtheory

%w[rubygems dm-core].each { |g| require g.to_s }

DataMapper.setup(:default, 'sqlite3::memory:')

class Something
  include DataMapper::Resource
  
  property :id, Serial
  property :p1, String
  property :p2, String

knowtheory

Good news everyone!

We at Videojuicer are currently working on our next-generation API product, and we have a vacancy for a Ruby application developer to join our small team.

Our product is an API-led platform for generating leads from online video. It's designed to work in any situation where you have a video, and want it to drive traffic back to your product. That means it's good for screencasts, movie trailers, music videos, product commercials - you name it.

Our environment is a distributed team in the UK, US and Canada. We communicate mainly with Skype. Your working hours will be flexible, and you'll be able to work from your home, our London office or from a Brighton coworking venue if you so choose.

We work with Merb/Rails/Rack, DataMapper, Flex, Git, and jQuery. We use a series of futuristic moon-standards including HTML5, OAuth, OEmbed and SMIL3.

knowtheory

require 'dm-core'
require 'dm-core/core_ext/symbol'
require 'dm-validations'
require 'appengine-apis'
require 'appengine-apis/local_boot'
require 'dm-appengine'

DataMapper::Logger.new(STDOUT, :debug)
DataMapper.setup(:default, "app_engine://memory")

knowtheory

Adapter Returns
===============

create(resources)
-----------------

Nothing. Doesn't matter what it returns. In the case of auto-populated fields, the adapter HAS all the records, it can just modify the 
values directly. They don't need to be returned, DM should just update the identity map, and keep using them.

If something bad happens (not created for some reason) that is, and should be, and exception. In the case of DO, the most common case 

knowtheory

## full stack

 NoMethodError in CommentController#post_comment

undefined method `new_record?' for "oooh trying again, goddamn it!":String

RAILS_ROOT: /home/jeremy/dk4-exper
Application Trace | Framework Trace | Full Trace

/usr/lib/ruby/gems/1.8/gems/dm-core-0.9.11/lib/dm-core/property.rb:450:in `lazy_load'

knowtheory

module Addressable
  include DataMapper::Resource
  is :remixable
  # ...
end

module Linkable
  include DataMapper::Resource
  is :remixable
  # ...

knowtheory

module Addressable
  include DataMapper::Resource
  is :remixable
  # ...
end

module Linkable
  include DataMapper::Resource
  is :remixable
  # ...

knowtheory

= Ruby Packaging Standard

The aim of this document is two-fold.  First, to specify a common
structure of how a Ruby package distributed as source (that is, but
not limited to, development directories, version-controlled
repositories, .tar.gz, Gems, ...) should conform to.

Second, to document common and proven ways to structure Ruby packages,
and to point out certain anti-patterns that sneaked into common use.
It is by intent not to innovate.

knowtheory

Rails 3.0.pre on App Engine¶ ↑

You can Rails 3 on App Engine, but it won’t be especially useful until bundler 10. You should try these instead:

• Rails 2.3.5: DataMapper version: gist.github.com/268192

• Rails 2.3.5: TinyDS version: gist.github.com/269075

Install the Development Environment¶ ↑

The gems for the development environment include a pre-release appengine-tools gem that provides a pre-release version of jruby-rack.