- Short, focused classes
- Clear goals from the outset
- Measurable progress & outcomes
- Tangible takeaways
- Ruby
class Novel < Neo4j::Rails::Model | |
property :title, type: String, index: :exact | |
has_n(:authored_by).to(Author) | |
end | |
class Author < Neo4j::Rails::Model | |
property :name, type: String, index: :exact |
- Alex Burkhart | |
- @Saterus | |
- neo.com | |
BASICS: | |
- REPL | |
- Ruby Classic: IRB | |
- ****gem install pry-plus**** |
START user=node(Z) | |
MATCH (user)-[:LIKES]->(y) | |
WHERE y.classname = 'Discussion' | |
RETURN y; |
module Foo | |
def instance_foo | |
puts "called instance_foo" | |
end | |
def self.classy_foo | |
puts "called classy_foo" | |
end | |
end |
[1] pry(main)> module Foo | |
[1] pry(main)* def self.included(base) | |
[1] pry(main)* base.instance_exec do | |
[1] pry(main)* define_method :foo do | |
[1] pry(main)* puts "foo!" | |
[1] pry(main)* end | |
[1] pry(main)* end | |
[1] pry(main)* end | |
[1] pry(main)* end | |
=> nil |
Today's Kata will evolve a simple API from both the server and the client point of view. The end goal is to produce an API for crafting delicious, delicious burritos.
You will need a pair for this. One person will be writing the server and one person will be writing the client. This will let us evolve our API quickly and require both people to make the appropriate changes. Luckily, Hyper can play both roles!
[11] pry(main)> module M | |
[11] pry(main)* def foo | |
[11] pry(main)* puts "self: #{self}" | |
[11] pry(main)* end | |
[11] pry(main)* end | |
=> nil | |
[12] pry(main)> class C | |
[12] pry(main)* include M | |
[12] pry(main)* end |
I hereby claim:
To claim this, I am signing this object: