writefully 0.3.6

data/spec/dummy/config/writefully.yml

@@ -0,0 +1,9 @@
+development: &default
+  :content: <%= Rails.root.join('content') %>
+  :storage_folder: 'codemycasts'
+  :storage_provider: 'AWS'
+  :app_directory: <%= Rails.root %>
+  :hook_secret: '00e4de0cf7647cd447b6659bd0b3b5fe'
+
+test:
+  <<: *default

data/spec/dummy/config.ru

@@ -0,0 +1,4 @@
+# This file is used by Rack-based servers to start the application.
+
+require ::File.expand_path('../config/environment',  __FILE__)
+run Rails.application

data/spec/dummy/content/codemy-net/posts/1-hash-selector-pattern/README.md

@@ -0,0 +1,119 @@
+# Hash Selector Pattern
+
+Its generally common that our web application needs to take different routes based on certain conditions. There are a few ways we can express these conditions in Ruby. Ifs and Case / Switch come to mind. They're one of the most common ways to express logical paths in our application.
+
+Case / Switch can offer very nice syntax and clear code however if / else are much faster than case / switches. At the same time complex if else can make your code very complicated and difficult to read.
+
+Lets take a look at a simple example.
+
+Remember our flash partials? What if we wanted the color to change based on the type of error. Using ifs we can write it like this.
+
+```ruby
+  if flash[:type] == :success
+    'alert-success'
+  elsif flash[:type] == :error
+    'alert-danger'
+  elsif flash[:type] == :warn
+    'alert-warning'
+  elsif flash[:type] == :info
+    'alert-info'
+  end
+```
+
+> Note that these outputs are based on bootstrap alert classes that output different colors based on the class names.
+
+Lets take a look at the case / switch solution. Its much cleaner but its also a lot slower than the if based solution.
+
+```ruby
+  case flash[:type]
+  when :success then 'alert-success'
+  when :error   then 'alert-danger'
+  when :warn    then 'alert-warning'
+  when :info    then 'alert-info'
+  end
+```
+
+Let me introduce you to the hash selector pattern
+
+```ruby
+  { success: 'alert-success',
+    error:   'alert-danger',
+    notice:  'alert-info',
+    warn:    'alert-warning' }[flash[:type]]
+```
+
+We're using hash to store the result for the different routes of our application, and simply selecting the result based on the selector. 
+
+In this case the selector is the `flash[:type]`. We have a very simple example here of the hash selector pattern. Our code more readable and concise.
+
+## Procs and Lambdas
+
+Great so we can output simple text using hashes nothing special. What about calling methods, can we do that? Well absolutely! Let me demonstrate.
+
+In your controller you may be fimiliar with this sort of logic
+
+```ruby
+  if @comment.save
+    respond_with @post, @comment
+  else
+    xms_error @comment
+  end
+```
+
+Generally when you have a simple logic like this I recommend with the if / else solution as its small enough to be clean and readable. However if you have a more complex logic with multiple elsifs you might want to do something like this 
+
+```ruby
+  { true  => -> { self.respond_with @post, @comment },
+    false => -> { self.xms_error @comment } 
+  }[@comment.save].call
+```
+
+The code above does the exact same thing as the if / else solution. However it is much shorter. In this case I wouldn't say that hash / selector has improved our code but here I am just trying to show you that it is possible to call methods using hashes. You just have to wrap it inside of a proc.
+
+## Conclusion
+
+The hash selector pattern separates the logic from the result, generally this will make your code easier to read. It gives the right balance between readable code and performance. In most cases Hash / Selector pattern will be faster than if / else, but if your `selector` is very complex it might become slower.
+
+My general rule of thumb is if you are using a lot of `elsif` in your codebase chances are you can probably refactor it using hash / selector pattern.
+
+Here is my Fizzbuzz solution using Hash / Selector
+
+## Further Examples
+
+```ruby
+class Fizzbuzz
+  def initialize(number)
+    @number = number
+  end
+ 
+  def self.count(number)
+    count = new(number)
+    count.output_data[count.selector]
+  end
+ 
+  def self.count_if(number)
+    count = new(number)
+    count.output_if
+  end
+ 
+  def output_if
+    result = 'Fizz' if @number % 3 == 0
+    result = 'Buzz' if @number % 5 == 0         
+    result = 'Fizzbuzz' if @number % 15 == 0
+    result 
+  end
+ 
+  def output_data
+    { "3" => "Fizz", 
+      "5" => "Buzz",
+      "15" => "Fizzbuzz" }
+  end
+ 
+  def selector
+    output_data.keys.map { |k| k.to_i }.select do |k| 
+      @number % k == 0 
+    end.last
+  end
+end
+```
+

data/spec/dummy/content/codemy-net/posts/1-hash-selector-pattern/benchmark/selector.rb

@@ -0,0 +1,77 @@
+require 'benchmark'
+
+class Selector
+
+
+  def initialize(key)
+    @key = key
+  end
+
+  def selector_if
+    if @key == :success
+      'alert-success'
+    elsif @key == :error
+      'alert-danger'
+    elsif @key == :warn
+      'alert-warning'
+    elsif @key == :info
+      'alert-info'
+    end
+  end
+
+  def selector_case
+    case @key
+      when :success then 'alert-success'
+      when :error   then 'alert-danger'
+      when :warn    then 'alert-warning'
+      when :info    then 'alert-info'
+    end
+  end
+
+  ALERT_TYPES = { success: 'alert-success',
+                  error:   'alert-danger',
+                  notice:  'alert-info',
+                  warn:    'alert-warning' }
+
+  def selector_hash_cached
+    ALERT_TYPES[@key]
+  end
+
+  def selector_hash
+    { success: 'alert-success',
+      error:   'alert-danger',
+      notice:  'alert-info',
+      warn:    'alert-warning' }[@key]
+  end
+end
+
+Benchmark.bm(25) do |x|
+  x.report("if") { 
+    1.times do 
+      selector = Selector.new([:success, :error, :notice, :warn].sample)
+      selector.selector_if
+    end
+  }
+
+  x.report("case") { 
+    1.times do 
+      selector = Selector.new([:success, :error, :notice, :warn].sample)
+      selector.selector_case
+    end
+  }
+ 
+  x.report("hash_select_cached") { 
+    1.times do 
+      selector = Selector.new([:success, :error, :notice, :warn].sample)
+      selector.selector_hash_cached
+    end
+  }
+
+  x.report("hash_select") { 
+    1.times do 
+      selector = Selector.new([:success, :error, :notice, :warn].sample)
+      selector.selector_hash
+    end
+  }
+end
+

data/spec/dummy/content/codemy-net/posts/1-hash-selector-pattern/meta.yml

@@ -0,0 +1,7 @@
+title: "Ruby Hash Selector Pattern"
+slug: "ruby-hash-selector-pattern"
+tags: ["Ruby"]
+playlists: ["A Shot of Ruby"]
+details:
+  blurb: "We show you an alternative to if / else and case / switch."
+  cover: "assets/hash-selector-icon.png"

data/spec/dummy/content/codemy-net/posts/2-rails-flash-partials/README.md

@@ -0,0 +1,171 @@
+# Rails Flash Partials
+
+Outputting flash messages is one of the most convenient ways of letting your users know when things happen in the system. Things like when users update their content or create new content.
+
+With rails generally its pretty simple to output flash messages. You just do 
+
+![Cover Picture](assets/cover.png)
+
+```ruby
+flash[:notice] = "Your post has been updated!"
+```
+
+And Voila! you can output flash messages in your views. However what if you want to output flash messages that are more than just simple text. What if you want to put links in there or use your view helpers in them? How would you go about handling all that? 
+
+Well lets take a look!
+
+## Skeleton Partial
+
+The best way to use views helper is well in the view. So lets start by creating a simple partial. We create this in the `views/application/_flash.html.erb`. If you don't see an `application` folder in your views simply create it.
+
+```erb
+<div class='alert alert-info'>
+  <div class='cotainer'>
+    ... flash content goes here ...
+  </div>
+</div>
+```
+
+This simple partial will serve as the skeleton for our flash message. It will provide the basic structure. If your using twitter bootstrap the alert box will look something like the above. However you can just as easily come up with your own concoction.
+
+
+## Flash Helper
+
+Once we have our partial we need some helper code to help us use the flash partial. This code goes into a helper file called `flash_helper.rb`
+
+```ruby
+module FlashHelper
+  def render_flash
+    render 'flash' if can_flash?
+  end
+
+  def can_flash?
+    flash.keys.sort == [:from, :object_id, :object_type, :type]
+  end
+
+  def flash_object
+    flash[:object_type].classify.constantize.where(id: flash[:object_id]).first
+  end
+
+  def flash_path
+    File.join(controller_name, 'flash', flash[:from].to_s, flash[:type].to_s)
+  end
+end
+```
+
+The render_flash is called in our `layouts/application.html.erb` like so.
+
+```html
+...
+<body>
+<%= render 'navigation' %>
+<%= render_flash %>
+<div class='container'>
+  <%= yield %>
+</div>
+
+</body>
+...
+```
+
+The `render_flash` checks with `can_flash?` whether or not it can display the flash message. 
+
+In our `can_flash?` message all we're doing is making sure that the flash has that is passed to the view has the right keys. Basically for our flash to work right we need those keys. I'll explain abit later where all these are coming from.
+
+When we work with flash it means we could also be working with redirection. Which means that the action thats rendering the actual flash message may have different objects in them. For example think of this scenario. We're creating a new post and after the post is created we redirect to the posts index. Well in the `posts#index` action we may not have the original `@post` object. So we need the `flash_object` to ensure that the object that the flash message depends on is available to the flash.
+
+Lastly the `flash_path` just generates the partial path for the flash. We will explain later how and where we use this helper method.
+
+## Controller Madness!
+
+We need to do a few things in the controlle to get our partials working right. Lets have a look at whats going on with our `application_controller.rb`
+
+```ruby
+class ApplicationController < ActionController::Base
+  # Prevent CSRF attacks by raising an exception.
+  # For APIs, you may want to use :null_session instead.
+  protect_from_forgery with: :exception
+
+  def set_flash(type, object: nil)
+    flash[:from] = action_name
+    flash[:type] = type
+    flash[:object_type] = object.class.name
+    flash[:object_id]   = object.id
+  end
+end
+```
+
+We just have a `set_flash` method that simply builds our flash hash which we will then use in our `flash_helper.rb`
+
+Now all we need to do is call `set_flash` in our controller action as required.
+
+```ruby
+def update
+  @post = get_post
+  if @post.update_attributes(post_params)
+    set_flash :success, object: @post
+    redirect_to posts_path
+  else
+    set_flash :error, object: @post
+    render :edit
+  end
+end
+
+def create
+  @post = Post.new(post_params)
+  if @post.save
+    set_flash :success, object: @post
+    redirect_to posts_path
+  else
+    set_flash :error, object: @post
+    render :new
+  end
+end
+```
+
+You'll see that we have a case where the flash is being used to handle success messages and error messages. We're going to get back to the views and see how we'll render out these flash messages.
+
+## Into the Views
+
+Once we've set everything up all we have to do now is render our flash messages through the partials in our views. However we need to use the path we defined in the FlashHelper called `flash_path` basically this is where its going to look for the flash message. You can change this and structure your flash messages however you like however in this case we're going to put it in the views that correspond to the controller.
+
+We're going to create a few files 
+
+```bash
+views/posts/flash/create/_success.html
+views/posts/flash/create/_error.html
+views/posts/flash/update/_success.html
+views/posts/flash/update/_error.html
+```
+
+Here are some example content of what you can do with these flash partials. Here is what my `create/_success.html.erb` looks like.
+
+```
+<h4>Congratulations!</h4>
+Your post has been successfully created! <%= link_to object.title, object %>
+```
+
+Here is `update/_success.html.erb`
+```
+Your post has been successfully saved! <%= link_to "edit: #{object.title}", edit_post_path(object) %>
+```
+
+
+Basically this file structure is what we have setup in our `flash_path` method. So your free to use whatever kind of structure you like by modifying the `flash_path` method.
+
+```ruby
+  # def set_flash(type, object: nil)
+    # flash[:from] = action_name
+    # flash[:type] = type
+    # flash[:object_type] = object.class.name
+    # flash[:object_id]   = object.id
+  # end
+
+  def flash_path
+    File.join(controller_name, 'flash', flash[:from].to_s, flash[:type].to_s)
+  end
+```
+
+## Conclusion
+
+You may be wondering why go through all that trouble. Well if your working with a large scale rails app. Having some sort of structure to help keep your flash messages clean and versatile might be something worth investing time into getting right. There are many solutions out there and they all work in their own way. Depending on what sort of app your building this could be a great solution for you!

data/spec/dummy/content/codemy-net/posts/2-rails-flash-partials/meta.yml

@@ -0,0 +1,7 @@
+title: "Rails Flash Partials"
+slug: "rails-flash-partials"
+tags: ["Rails"]
+playlists: ["A Shot of Ruby"]
+details: 
+  blurb: "How to setup flash messages in your application"
+  cover: "assets/cover.png"

data/spec/dummy/db/schema.rb

@@ -0,0 +1,89 @@
+# encoding: UTF-8
+# This file is auto-generated from the current state of the database. Instead
+# of editing this file, please use the migrations feature of Active Record to
+# incrementally modify your database, and then regenerate this schema definition.
+#
+# Note that this schema.rb definition is the authoritative source for your
+# database schema. If you need to create the application database on another
+# system, you should be using db:schema:load, not running all the migrations
+# from scratch. The latter is a flawed and unsustainable approach (the more migrations
+# you'll amass, the slower it'll run and the greater likelihood for issues).
+#
+# It's strongly recommended that you check this file into your version control system.
+
+ActiveRecord::Schema.define(version: 20140403181629) do
+
+  # These are extensions that must be enabled in order to support this database
+  enable_extension "plpgsql"
+  enable_extension "hstore"
+
+  create_table "writefully_authorships", force: true do |t|
+    t.integer  "user_id"
+    t.hstore   "data"
+    t.string   "role"
+    t.datetime "created_at"
+    t.datetime "updated_at"
+  end
+
+  add_index "writefully_authorships", ["user_id"], name: "index_writefully_authorships_on_user_id", using: :btree
+
+  create_table "writefully_posts", force: true do |t|
+    t.string   "title"
+    t.string   "slug"
+    t.string   "type"
+    t.text     "content"
+    t.hstore   "details"
+    t.datetime "published_at"
+    t.integer  "position"
+    t.string   "locale",                default: "en"
+    t.integer  "translation_source_id"
+    t.integer  "site_id"
+    t.integer  "authorship_id"
+    t.datetime "created_at"
+    t.datetime "updated_at"
+  end
+
+  add_index "writefully_posts", ["authorship_id"], name: "index_writefully_posts_on_authorship_id", using: :btree
+  add_index "writefully_posts", ["site_id"], name: "index_writefully_posts_on_site_id", using: :btree
+  add_index "writefully_posts", ["slug"], name: "index_writefully_posts_on_slug", unique: true, using: :btree
+  add_index "writefully_posts", ["translation_source_id"], name: "index_writefully_posts_on_translation_source_id", using: :btree
+
+  create_table "writefully_sites", force: true do |t|
+    t.string   "name"
+    t.string   "branch",     default: "master"
+    t.string   "slug"
+    t.hstore   "repository"
+    t.string   "domain"
+    t.boolean  "processing", default: true
+    t.boolean  "healthy",    default: false
+    t.integer  "owner_id"
+    t.datetime "created_at"
+    t.datetime "updated_at"
+  end
+
+  add_index "writefully_sites", ["owner_id"], name: "index_writefully_sites_on_owner_id", using: :btree
+  add_index "writefully_sites", ["repository"], name: "index_writefully_sites_on_repository", using: :gin
+  add_index "writefully_sites", ["slug"], name: "index_writefully_sites_on_slug", unique: true, using: :btree
+
+  create_table "writefully_taggings", force: true do |t|
+    t.integer  "tag_id"
+    t.integer  "post_id"
+    t.datetime "created_at"
+    t.datetime "updated_at"
+  end
+
+  add_index "writefully_taggings", ["post_id"], name: "index_writefully_taggings_on_post_id", using: :btree
+  add_index "writefully_taggings", ["tag_id"], name: "index_writefully_taggings_on_tag_id", using: :btree
+
+  create_table "writefully_tags", force: true do |t|
+    t.string   "name"
+    t.string   "slug"
+    t.string   "type"
+    t.datetime "created_at"
+    t.datetime "updated_at"
+  end
+
+  add_index "writefully_tags", ["slug"], name: "index_writefully_tags_on_slug", unique: true, using: :btree
+  add_index "writefully_tags", ["type"], name: "index_writefully_tags_on_type", using: :btree
+
+end