Just to make sure my message was clear at Railsconf...recursion is actually pretty cool & powerful...recursion in the database isn't cool :)
Now more recursive hasselhoff for your viewing pleasure:
Here are my slides and code samples from my RailsConf 2010 talk. Hope you all enjoyed it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
require 'rubygems' require 'json' require 'rest_client' def create_person(name) JSON.parse RestClient.post( "http://localhost:8988/neo4jr-social/nodes", :name => name ) end def make_mutual_friends(node1, node2) RestClient.post "http://localhost:8988/neo4jr-social/nodes/#{node1['node_id']}/relationships", :to => node2['node_id'], :type => 'friends' RestClient.post "http://localhost:8988/neo4jr-social/nodes/#{node2['node_id']}/relationships", :to => node1['node_id'], :type => 'friends' end luke = create_person('Luke Skywalker') han_solo = create_person('Han Solo') chewy = create_person('Chewbacca') lando = create_person('Lando') akbar = create_person('General Akbar') make_mutual_friends(luke, han_solo) make_mutual_friends(han_solo, chewy) make_mutual_friends(han_solo, lando) make_mutual_friends(lando, akbar) suggestions = JSON.parse RestClient.get("http://localhost:8988/neo4jr-social/nodes/#{luke['node_id']}/recommendations?type=friends") friend_suggestions = suggestions.map{|n| n['name']}.join(', ') puts "Luke Skywalker should become friends with #{friend_suggestions}" #RESULT: # Luke Skywalker should become friends with Chewbacca, Lando |
I couldn't find anything on how to connect to an Oracle database using ruby's sequel with just a TNS configuration....here is what worked for me:
1
|
Sequel.connect(:adapter => 'oracle', :user => 'something', :password => 'secret', :database => '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<somehost>)(PORT=<someport>))(CONNECT_DATA=(SID=<somesid>)))') |
I've decided to scrap my old blog of over 5 years and all of it's posts except the very few that get the most traction. I'm hoping the move to posterous and their easy way to post encourages me to write more since it has been about 2 years since my last post.
Capistrano makes an assumption that all servers in your application stack
share the same credentials. As much logical sense as this makes, in large
enterprise landscapes it is often not a reality. The nature of this world
(Enterprise) is that trying to shift the mindset of all shareholders
(infrastructure, support teams, security, etc) and then changing long running
practices is not always feasible. This is especially true when doing so on
numerous severs servicing numerous other systems that depend on the already in
place mismatched credentials. For us...we have our normal application servers
and database servers that DO share matching credentials. But along with them
we use a separate server env to store and host our assets (images, css, js)
with its own credentials.
After you configure a resource in your rails routes configuration, you have
access to generate named routes with _path and _url. The main difference
between _url and _path can be demonstrated in the following example.
we can now do the following:
#### _path versus _url
I was talking to a former associate I used to work with about a new "[Inversion of Control][1]" (IOC) container I had been playing with. He is a big OOP enthusiast but had not heard of IoC before. He later emailed me that after his research that Inversion of Control was nothing new and that it was formulated a long time ago in the "[Dependency Inversion Principle][2]" (DIP).
(FYI: DIP and IoC's primary purpose is to decouple implementations of classes. With that come many benefits too long to go into in this post. But I highly recommend following the links provided in this article to learn more.)
I have heard this before and I agree that IoC is definitely not something new.
But there are some differences. "[Dependency Inversion Principle][2]" is an
Object Oriented Design **principle** where as "[Inversion of Control][3]" is a
Design **Pattern**. Principles are meant to be followed but provide only the
basic guideline to follow where as Patterns are concrete solutions to common
problems so there alone separates their purpose/intent. Personally I think
that Ioc is at the core of DIP, but they both compliment each other but in
different aspects. (Think chicken before the egg?) The only way you can have a
good, successful _dependency inversion_ of a class is by using one of the IoC
patterns (I, II, or III) or also as my friend suggested to me the alternative
design pattern "[plugin][4]".
Then as my friend asked, what is the hype about IoC containers and when do we
use an IoC contatiner over creating our own Plugin? (Paraphrasing here)
First what is a [plugin][4]? To summarize, it links classes during
configuration _rather than compilation_. The plugin depends heavily on
factories and some conditional logic to decide which implementation to return
to the requesting client. The plugin can be used in many contexts but the
[author][5] originally wrote its primary purpose for unit testing or running
an application in multiple environments. Factories can be evil for reasons
like that they usually implement the singleton, or another problem is that now
you may have avoided tightly coupling two object implementations by using DIP
but the requesting client is still tightly coupled to a factory class to get
it's loosely coupled implementation.
What about [IoC][6]. Using an IoC container assists us in DIP without
recreating the wheel. Though each container use different ways (see below) of
binding implementations dynamically during runtime…none of them use a factory
to that. We can also now choose our preferred method of IoC using open freely
available frameworks. I wont go to company A and have to learn company A's
proprietary IoC framework and then do the same again for company B, company C,
and so on. - Standardization is good.
*Very Quick Reference to how IoC is implemented in frameworks. I use the
dependency injection terms (setter, constructor, interface) over the original
IoC terms (I, II, III). Martin Fowler provides us with an [easier way][3] of
understanding this pattern.
* Setter
* This usually requires an external configuration file that will bind
classes together. This depends on properties to provide the implementation to
the class needing them.
* .Net Implementation:
* [Spring.Net][7]
* Constructor
* A Class that requires supporting classes get these through the
constructor as arguments. The client code will request a specific type of
object from the framework. The framework then will Instantiate an instance of
an object of that type or of a class that implmenets that type. Every class
needed will by linked up dynamically.
* .Net Implementation
* [Castle Project][8]
* [PicoContainer][9]
* Interface
* The framework will bind up classes that match particular types of
interfaces. I know this is a weak definition but there are lots of sources
that go deeper into these subjects if you wish to learn [more][3].
* .Net Implementation
* [Castle Project][8]
[1]: http://www.martinfowler.com/articles/injection.html
[2]: http://www.objectmentor.com/mentoring/OOPrinciples
[3]: http://www.martinfowler.com/articles/injection.html
[4]: http://patternshare.org/default.aspx/Home.MF.Plugin
[5]: http://www.martinfowler.com/
[6]: http://wiki.apache.org/excalibur/InversionOfControl
[7]: http://www.springframework.net/
[8]: http://www.castleproject.org/castle/show/HomePage
[9]: http://picocontainer.org/
Anyone that has worked with me knows that I am anti-datasets and pro-creating
custom business object/entities. Microsoft has spent some time making their
controls, like the _DataGrid_, work very cohesively with the _System.Data_
classes (primarily _DataTables_ and _DataSets_). To take advantage of the same
functionality with my custom collections I have to implement the
_IBindingList_. The _IBindingList_ is the interface that is at the root of the
_DataTable_ and is what the _DataGrid_ and other controls use to effectively
bind data to the UI.
My article on aspect oriented programming has been published on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/AOPArticle.asp).