Saturday, 18 October 2014

Τι θα έκανες αν ξυπνούσες ένα πρωί και ήσουνα 30 χρόνια νεότερος

45 παράξενες αλήθειες της ζωής

1. Η ζωή δεν είναι δίκαιη, αλλά ακόμα κι έτσι είναι ωραία.

2. Όταν αμφιβάλλεις για κάτι, απλά κάνε το επόμενο μικρότερο βήμα.

3. Η ζωή είναι πολύ μικρή για να χάνεις χρόνο μισώντας τον οποιονδήποτε.

4. Αν αρρωστήσεις, δε θα σε κοιτάξει η δουλειά σου. Θα σε κοιτάξουν οι φίλοι και η οικογένειά σου. Μη χάνεσαι.

5. Πλήρωνε τις πιστωτικές σου κάθε μήνα.

6. Δε χρειάζεται να κερδίζεις σε κάθε διαφωνία. Συμφώνησε με το να διαφωνείς.

7. Κλάψε παρέα με κάποιον. Είναι πιο εύκολο να συνέλθεις απ' το να κλαις μόνος.

8. Δεν πειράζει να θυμώνεις.

9. Βάζε στην άκρη για τη σύνταξή σου από τον πρώτο σου μισθό.

10. Απέναντι στη σοκολάτα κάθε αντίσταση είναι μάταιη.

11. Συμφιλιώσου με το παρελθόν σου για να μην καταστρέφεις το παρόν σου.

12. Δεν πειράζει αν σε δουν τα παιδιά σου να κλαις. Άφησέ τα να το κάνουν.

13. Μην συγκρίνεις τη ζωή σου με των άλλων. Δεν έχεις ιδέα τι νόημα μπορεί να έχει το δικό τους το ταξίδι.

14. Αν μια σχέση πρέπει να κρατιέται μυστική, τότε δεν πρέπει να την κρατάς εσύ.

15. Τα πάντα μπορεί να αλλάξουν μ' ένα ανοιγοκλείσιμο των ματιών. Αλλά μην ανησυχείς. Ο Θεός δεν τρεμοπαίζει τα βλέφαρά του.

16. Πάρε μια βαθιά ανάσα. Ηρεμεί το μυαλό.

17. Ξεφορτώσου ό,τι δεν είναι χρήσιμο, όμορφο ή γεμάτο χαρά.

18. Ό,τι δε σε σκοτώνει πράγματι σε κάνει δυνατότερο.

19. Ποτέ δεν είναι αργά για να έχεις μια ευτυχισμένη παιδική ηλικία. Αλλά τη δεύτερη φορά εξαρτάται από σένα.

20. Όταν είναι να κυνηγήσεις αυτά που αγαπάς στη ζωή, μη δεχτείς ποτέ το όχι.

21. Άναψε τα κεριά, στρώσε τα καλά σεντόνια, φόρεσε τα ακριβά εσώρουχα. Μην τα φυλάς για ειδικές περιπτώσεις. Κάθε μέρα είναι ειδική περίπτωση.

22. Προετοιμάσου για όλα. Και μετά ακολούθησε το ρεύμα.

23. Γίνε εκκεντρικός τώρα. Μην περιμένεις να πάρεις σύνταξη για να φορέσεις μωβ χρώμα!

24. To πιο σημαντικό σεξουαλικό όργανο είναι το μυαλό.

25. Σε κάθε αποκαλούμενη «καταστροφή» σκέψου: «Σε 5 χρόνια, αυτό θα έχει καμία σημασία;».

26. Πάντα να επιλέγεις τη ζωή.

27. Συγχώρησε σε όλους τα πάντα.

28. Το τι πιστεύουν οι άλλοι για σένα, δεν είναι δική σου δουλειά.

29. Ο χρόνος θεραπεύει σχεδόν τα πάντα. Δώσε χρόνο στο χρόνο.

30. Όσο καλή ή κακή κι αν είναι μια κατάσταση, θα αλλάξει.

31. Μην παίρνεις τον εαυτό σου τόσο στα σοβαρά. Κανείς άλλος δεν το κάνει.

32. Πίστευε στα θαύματα.

33. Ο Θεός σ' αγαπάει επειδή είσαι αυτός που είσαι, όχι για κάτι που έκανες ή δεν έκανες.

34. Μην παρακολουθείς τη ζωή. Βγες μπροστά και εκμεταλλεύσου την πλήρως τώρα.

35. Το να γερνάς είναι καλύτερο από την εναλλακτική λύση: να πεθαίνεις νέος.

36. Τα παιδιά σου θα ζήσουν μόνο μία παιδική ζωή.

37. Το μόνο που έχει σημασία τελικά είναι ό,τι αγάπησες.

38. Βγες έξω κάθε μέρα. Τα θαύματα παραμονεύουν παντού.

39. Αν όλοι ρίχναμε τα προβλήματά μας σε ένα σωρό δίπλα - δίπλα, θα αρπάζαμε τα δικά μας πίσω.

40. Η ζήλια είναι χάσιμο χρόνου. Έχεις ήδη όλα όσα χρειάζεσαι.

41. Τα καλύτερα έπονται.

42. Ό,τι διάθεση και να έχεις, σήκω, ντύσου και πήγαινε εκεί που έχεις να πας.

43. Να ενδίδεις.

44. Η ζωή δεν είναι τυλιγμένη με κορδέλα, δεν παύει όμως να είναι δώρο.

45. Κανείς δεν είναι υπεύθυνος για την ευτυχία σου παρά μόνο εσύ.

lifo.gr/lifoland/you-send-it/54275

Monday, 11 August 2014

Collection Proxy

Proxy

http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html




Proxy

Proxy is any object that acts as a drop-in replacement object that does a bit of work and then delegates to some other underlying object. This is another pattern that’s easy to recognize for Rails developers, because it is used extensively in ActiveRecord associations support. The following example shows a typical interaction between a base model and one of its associations.
  1. quiz = Quiz.first  
  2. quiz.questions.class #=> Array  
  3.   
  4. quiz.questions.count #=> 10  
  5.   
  6. quiz.questions.create(:question_text => "Who is the creator of Ruby?",  
  7.                       :answer        => "Matz")  
  8.   
  9. quiz.questions.count #=> 11  
  10.   
  11. quiz.questions[-1].answer #=> "Matz"   
While the questions association claims to be an array, it also provides some of the common helpers found in ActiveRecord::Base. If we stick to the core idea and ignore some of the Rails specific details, creating such an association proxy is fairly easy to do using Ruby’s delegate standard library. The code below more or less does the trick.
  1. require "delegate"  
  2.   
  3. class Quiz  
  4.   def questions  
  5.     @questions                  ||= HasManyAssociation.new([])  
  6.     @questions.associated_class ||= Question  
  7.   
  8.     @questions  
  9.   end  
  10. end  
  11.   
  12. class Question  
  13.   def initialize(params)  
  14.     @params = params  
  15.   end  
  16.   
  17.   attr_reader :params  
  18.   
  19.   def answer  
  20.     params[:answer]  
  21.   end  
  22. end  
  23.   
  24. class HasManyAssociation < DelegateClass(Array)  
  25.   attr_accessor :associated_class  
  26.   
  27.   def initialize(array)  
  28.     super(array)  
  29.   end  
  30.   
  31.   def create(params)  
  32.     self << associated_class.new(params)  
  33.   end  
  34. end  
  35.   
  36. quiz = Quiz.new  
  37.   
  38. # grab the proxy object  
  39. questions = quiz.questions  
  40.   
  41.   
  42. # use custom create() method on proxy object  
  43.   
  44. questions.create(:question_text => "Who is the creator of Ruby?",  
  45.                  :answer        => "Matz")  
  46. questions.create(:question_text => "Who is the creator of Perl?",  
  47.                  :answer        => "Larry Wall")  
  48.   
  49.   
  50. # use array like behavior on proxy object  
  51.   
  52. p questions[0].answer #=> "Matz"  
  53. p questions[1].answer #=> "Larry Wall"  
  54. p questions.map { |q| q.answer }.join(", "#=> "Matz, Larry Wall"  
Interestingly enough, while Ruby provides a standard library for building Proxy objects, most people tend to implement them in a different way, through the use of an explicitmethod_missing() hook on a blank slate object such as Ruby 1.9’s BasicObject. For example, we could have written our HasManyAssociation code in the manner shown below and things would still work as expected.
  1. class HasManyAssociation < BasicObject  
  2.   attr_accessor :associated_class  
  3.   
  4.   def initialize(array)  
  5.     @array = array  
  6.   end  
  7.   
  8.   def create(params)  
  9.     self << associated_class.new(params)  
  10.   end  
  11.   
  12.   def method_missing(*a, &b)  
  13.     @array.send(*a, &b)  
  14.   end  
  15. end  
Without looking at the source, I’m almost sure that Rails does something similar to this, because doing some_association.class returns Array rather than the name of the proxy object. This is the only noticeable difference on the surface between this approach and the DelegateClass approach.
Personally, I’ve written proxies in both ways, and I tend to prefer the DelegateClass()approach slightly, simply because it’s more explicit and doesn’t require me to explicitly define amethod_missing() hook. But on the other hand, we can see that rolling your own proxy implementation is trivial in Ruby, and some may prefer the self contained nature of doing the delegation work yourself. It’d be interesting to hear what readers have to say on this topic, so please feel free to post to the mailing list if you prefer one approach over the other.

Thursday, 24 July 2014

activesupportconcern

FROM: http://engineering.appfolio.com/2013/06/17/ruby-mixins-activesupportconcern/



Ruby Mixins & ActiveSupport::Concern

A few people have asked: what is the dealio with ActiveSupport::Concern? My answer: it encapsulates a few common patterns for building modules intended for mixins. Before understanding why ActiveSupport::Concern is useful, we first need to understand Ruby mixins.
Here we go…!

First, the Ruby object model:

As you can see mixins are “virtual classes” that have been injected in a class’s or module’s ancestor chain. That is, this:
module MyMod
end

class Base
end

class Child < Base
  include MyMod
end

# irb> Child.ancestors
#  => [Child, MyMod, Base, Object, Kernel, BasicObject]
results in the same ancestor chain as this:
class Base
end

class MyMod < Base
end

class Child < MyMod
end

# irb> Child.ancestors
#  => [Child, MyMod, Base, Object, Kernel, BasicObject]
Great? Great.
Modules can also be used to extend objects, for example:
my_obj = Object.new
my_obj.extend MyMod

# irb> my_obj.singleton_class.ancestors
#  => [MyMod, Object, Kernel, BasicObject]
In Ruby, every object has a singleton class. Object#extend does what Module#include does but on an object’s singleton class. That is, the following is equivalent to the above:
my_obj = Object.new
my_obj.singleton_class.class_eval do
  include MyMod
end

# irb> my_obj.singleton_class.ancestors
#  => [MyMod, Object, Kernel, BasicObject]
This is how “static” or “class” methods work in Ruby. Actually, there’s no such thing as static/class methods in Ruby. Rather, there are methods on a class’s singleton class. For example, w.r.t. the ancestors chain, the following are equivalent:
class MyClass
  extend MyMod
end

# irb> MyClass.singleton_class.ancestors
#  => [MyMod, Class, Module, Object, Kernel, BasicObject]

class MyClass
  class << self
    include MyMod
  end
end

# irb> MyClass.singleton_class.ancestors
#  => [MyMod, Class, Module, Object, Kernel, BasicObject]
Classes are just objects “acting” as “classes”.

Back to mixins…

For example:
module MyMod
  def self.included(target)
    puts "included into #{target}"
  end

  def self.extended(target)
    puts "extended into #{target}"
  end
end

class MyClass
  include MyMod
end
# irb>
# included into MyClass

class MyClass2
  extend MyMod
end
# irb>
# extended into MyClass2

# irb> MyClass.ancestors
# => [MyClass, MyMod, Object, Kernel, BasicObject]
# irb> MyClass.singleton_class.ancestors
# => [Class, Module, Object, Kernel, BasicObject]

# irb> MyClass2.ancestors
# => [MyClass2, Object, Kernel, BasicObject]
# irb> MyClass2.singleton_class.ancestors
# => [MyMod, Class, Module, Object, Kernel, BasicObject]
Great? Great.

Back to ActiveSupport::Concern…

Over time it became a common pattern in the Ruby worldz to create modules intended for use as mixins like this:
module MyMod
  def self.included(target)
    target.send(:include, InstanceMethods)
    target.extend ClassMethods
    target.class_eval do
      a_class_method
    end
  end

  module InstanceMethods
    def an_instance_method
    end
  end

  module ClassMethods
    def a_class_method
      puts "a_class_method called"
    end
  end
end

class MyClass
  include MyMod
# irb> end
# a_class_method called
end

# irb> MyClass.ancestors
#  => [MyClass, MyMod::InstanceMethods, MyMod, Object, Kernel, BasicObject]
# irb> MyClass.singleton_class.ancestors
#  => [MyMod::ClassMethods, Class, Module, Object, Kernel, BasicObject]
As you can see, this single module is adding instance methods, “class” methods, and acting directly on the target class (calling a_class_method() in this case).
ActiveSupport::Concern encapsulates this pattern. Here’s the same module rewritten to use ActiveSupport::Concern:
module MyMod
  extend ActiveSupport::Concern

  included do
    a_class_method
  end

  def an_instance_method
  end

  module ClassMethods
    def a_class_method
      puts "a_class_method called"
    end
  end
end
You’ll notice the nested InstanceMethods is removed and an_instance_method() is defined directly on the module. This is because this is standard Ruby; given the ancestors of MyClass ([MyClass, MyMod::InstanceMethods, MyMod, Object, Kernel]) there’s no need for a MyMod::InstanceMethods since methods on MyMod are already in the chain.
So far ActiveSupport::Concern has taken away some of the boilerplate code used in the pattern: no need to define an included hook, no need to extend the target class with ClassMethods, no need to class_eval on the target class.
The last thing that ActiveSupport::Concern does is what I call lazy evaluation. What’s that?

Back to Ruby mixins…

Consider:
module MyModA
end

module MyModB
  include MyModA
end

class MyClass
  include MyModB
end

# irb> MyClass.ancestors
#  => [MyClass, MyModB, MyModA, Object, Kernel, BasicObject]
Let’s say MyModA wanted to do something special when included into the target class, say:
module MyModA
  def self.included(target)
    target.class_eval do
      has_many :squirrels
    end
  end
end
When MyModA is included in MyModB, the code in the included() hook will run, and if has_many() is not defined on MyModB things will break:
irb :050 > module MyModB
irb :051?>   include MyModA
irb :052?> end
NoMethodError: undefined method `has_many' for MyModB:Module
 from (irb):46:in `included'
 from (irb):45:in `class_eval'
 from (irb):45:in `included'
 from (irb):51:in `include'
ActiveSupport::Concern skirts around this issue by delaying all the included hooks from running until a module is included into a non-ActiveSupport::Concern. Redefining the above using ActiveSupport::Concern:
module MyModA
  extend ActiveSupport::Concern

  included do
    has_many :squirrels
  end
end

module MyModB
  extend ActiveSupport::Concern
  include MyModA
end

class MyClass
  def self.has_many(*args)
    puts "has_many(#{args.inspect}) called"
  end

  include MyModB
# irb>
# has_many([:squirrels]) called
end

# irb> MyClass.ancestors
#  => [MyClass, MyModB, MyModA, Object, Kernel, BasicObject]
# irb> MyClass.singleton_class.ancestors
#  => [Class, Module, Object, Kernel, BasicObject]
Great? Great.
But why is ActiveSupport::Concern called “Concern”? The name Concern comes from AOP (http://en.wikipedia.org/wiki/Aspect-oriented_programming). Concerns in AOP encapsulate a “cohesive area of functionality”. Mixins act as Concerns when they provide cohesive chunks of functionality to the target class. Turns out using mixins in this fashion is a very common practice.
ActiveSupport::Concern provides the mechanics to encapsulate a cohesive chunk of functionality into a mixin that can extend the behavior of the target class by annotating the class’ ancestor chain, annotating the class’ singleton class’ ancestor chain, and directly manipulating the target class through the included() hook.
So….
Is every mixin a Concern? No. Is every ActiveSupport::Concern a Concern? No.
While I’ve used ActiveSupport::Concern to build actual Concerns, I’ve also used it to avoid writing out the boilerplate code mentioned above. If I just need to share some instance methods and nothing else, then I’ll use a bare module.
Modules, mixins and ActiveSupport::Concern are just tools in your toolbox to accomplish the task at hand. It’s up to you to know how the tools work and when to use them.
I hope that helps somebody.