jdickey

- posts = PostData \
    .select { |post| post.author_name == @user.name } \
    .map(&:decorate)

div class='row'
  div class='col-md-12'
    div class='row'
      div class='col-md-1'  
      div class='col-md-10'

jdickey

We have been using RuboCop for quite some time; one of our projects tracks the Github repo rather than the released Gem (0.25.0 as I write this).

Commits 05cf121 and e9f3428 (and all later commits) fail when run as a Rake task in otherwise default configuration, or when running the command line

rubocop -dnR app/models/cco/blog_cco.rb

The debug output from that command is included in this Gist as output-dump.log, and the source file demonstrating the failure is also included, as well as the blo/blog_data_boundary.rb file which it includes.

jdickey

# == Schema Information
#
# Table name: post_data
#
#  id          :integer          not null, primary key
#  title       :string(255)      not null
#  body        :text
#  created_at  :datetime
#  updated_at  :datetime
#  image_url   :string(255)

jdickey

require 'awesome_print'

module DSO
  module Support
    # Value object for passing into post-creation interactors, etc.
    class PostCreationParam
      attr_reader :status

      def initialize(basic_attribs = {}, status = 'draft')

jdickey

Here's a fun little hack:

Look at the original BlogHelper module code in the first file below (and read this comment describing the problem with it if you haven't already).

Basically, we need a more flexible summary generator. When there aren't any draft posts by the currently logged-in user, we want the behaviour that #summarise_blog presently exhibits. If there are draft posts (and authorisation will limit visibility of those to the author only, so we don't need to worry about that here), then our select and sort_by calls are wrong (because we'll want all available posts, not just published ones, and because the pubdate field an a draft record is nil). But everything else in the #summarise_blog method, we want to keep the same.

Enter BlogHelper::BlogSummariser. The "New blog_helper.rb" file replicates the functionality of the old, using the class; as you see, the only thing we need to touch is the number of entries t

jdickey

Below is the transcript, edited, between myself and Charles, my CEO and collaborator in Prolog, regardiong some bizarre behaviour I'd encountered in an ActiveRecord validation. This is in the midst of converting some pretty basic data access architecture in new_poc, which I'll likely blog about at further length eventually.

If anyone finds this helpful, or can shed light on the confirmation quirk being discussed, feel free to chime in, either here or on Gitter.

jdickey

Here's an example from a public project of a (fairly basic) RSpec custom matcher that wraps an instance of a class that "does the real work"; what's in the actual matcher is mostly the "syntactic sugar" needed for it to play nice with the rest of RSpec.

This was in response to a comment thread on Reddit discussing the question, "Multiple assertions in a test, bad practise?" I want to express my appreciation to /u/jrochkind for his response to my initial comment (that led to my responding to him, that led to a far better approximation of Enlightenment).

The matcher, as I said, is pretty basic:

• A match block instntiates a SavedEntityVerifier class with the source and actual values for the expectation; specifies which fields in an entity are required in the source, the actual, or both, and calls that instance's #reasons met

jdickey

To apply the patch:

1. Ensure that you are in the init_password branch and that your working copy has no changes from the repo (git status produces no output);
2. Save the following patch-user-actions.diff file to a known directory not in the project tree, such as /tmp;
3. Ensure that you are in the project root folder;
4. Assuming that you saved the patch in /tmp, run the command patch -p1 < /tmp/patch-user-actions.diff
5. Run git status to verify that only the files app/actions/create_user.rb and app/actions/update_user.rb have been modified;
6. Run bundle exec rake to verify that specs and RuboCop finish cleanly;
7. Commit to your existing init_password branch; and
8. Push the branch to your GitHub repo.

jdickey

What I Have

I have an "entity" domain model class, formerly in the main app as UserEntity and now moved into a namespace as Newpoc::Entity::User (see excerpt in 01-user.rb below). It uses ActiveModel validations, and validations work just fine, although the message that's produced is undesirably verbose. For example, when #valid? reports an error, the message displayed in the view starts with the line 1 error prevented this Newpoc::Entity::User from being saved:.

What I Need

What I want instead is 1 error prevented this User from being saved:.

What I've Tried

jdickey

Right. Take a look at the console log below; we're running bundle package --all (after a successful bundle install).

Note lines 163-167 where the various Gems we pulled from rails-assets are shown as Using rails-assets-WHATEVER x.y.z.

Then note lines 208-211 where Bundler says it "could not find" the Gem it says it just pulled.

What introduced this HCF? Traffic on various Ruby-related fora in mid-February alerted people to "update your system Gems, especially Bundler, yesterday". It seems that there's a particularly nasty CVE that's been addressed in Bundler 1.7.0 and later.

Another interesting bit of the plot is that, despite running bundle update --system on a regular, typically weekly, basis, Tuesday 24 Feb 2015 was the first t