tpendragon

-@list.group_by(&:category).each do |category, items|
  %ul
  -items.each do |item|
    %li=item.name

tpendragon

module DynamicNetworkGraph
  class NetworkFlow
    def self.fields
      %w{srcAddr dstAddr srcPort dstPort protocol start end packets transferred status}  
    end
    
    fields.each do |field|
      attr_accessor field
    end

tpendragon

13:53 terrellt: I'm starting to flex my opinions about how specs should be written and I'd like some input from anybody out there writing Capybara specs.
13:53 terrellt: If somebody has time and an interest in the conversation, could you look at https://github.com/OregonDigital/oregondigital/pull/705 ?
13:55 jcoyne: terrellt: view specs are much better than feature specs for particular cases like this.  Feature specs are great to make sure all the layers are connected together correctly
13:56 terrellt: If this were two years ago I'd scoff at view specs at all. If it were a year ago I'd agree and write a Capybara test to make sure what I'm testing here holds true.
13:57 terrellt: I'm starting to think enforcing the interface in my test does the last part.
13:57 jcoyne: terrellt: I like to think of feature specs like the features you describe to your users.
13:58 jcoyne: Like "You can upload a file, supply some metadata and then it shows up in the search"
13:58 jcoyne: But not the particular edge cases of that 

tpendragon

15:55 smathy: terrellt, is the tl;dr that you're replacing capybara tests with controller and/or model tests?
15:57 smathy: Assuming so, capybara should be used only when it's impossible to test other ways.
15:57 pipework: I use feature tests for important workflows.
15:58 pipework: But I keep them pretty minimal and sometimes run them on-demand and just in CI, not in the default test suite rake task.
15:58 terrellt: smathy: Controller/model/view tests - effectively the tipping point for me is I'm deciding that there being an interface that I have to touch my tests for should I change it is a -good- thing.
15:59 terrellt: Whereas before I used feature specs to give me complete flexibility independent of architecture.
16:00 terrellt: pipework: I think where I'm landing now says that I'd avoid them ESPECIALLY for important workflows, because if I add that crutch I'm less likely to think critically about the architecture.
16:00 pipework: During development, I'll often write feature specs to drive implementation,

tpendragon

require 'rails_helper'

RSpec.describe StartersController do
  describe "#index" do
    fake(:starter_pet_finder, :all => [])
    before do
      stub(Tressonia::Pets::StarterPetFinder).new { starter_pet_finder }
      get :index
    end
    it "finds the pets" do

tpendragon

require 'rails_helper'

RSpec.describe "Error Handling" do
  describe "Active Record Not Found" do
    controller do
      def index
        raise ActiveRecord::RecordNotFound
      end
    end
  

tpendragon

#!/bin/bash
string=`tmux list-session`
directory_name=`basename $PWD`
if [[ $string == *$directory_name* ]]
then
  tmux new-session -As $directory_name
else
  tmux -2 new-session -As $directory_name -d
  tmux split-window -h
  tmux select-pane -t 1

tpendragon

module OregonDigital
  module SolrNTripleExtension
    def self.extended(document)
      document.will_export_as(:nt, "application/n-triples")
    end
    def export_as_nt
      graph = CleanRepository.new(ActiveFedora.fedora.connection, GenericAsset).find(self["id"])
      graph = OregonDigital::GraphMutators::SubjectChanger.call(graph, GenericAsset.id_to_uri(self["id"]), RDF::URI("http://oregondigital.org/resource/#{self["id"]}"))
      graph.dump(:ntriples)
    end

tpendragon

Keybase proof

I hereby claim:

• I am terrellt on github.
• I am terrellt (https://keybase.io/terrellt) on keybase.
• I have a public key whose fingerprint is 9928 4E50 9243 3416 3155 0908 A953 BFB4 24A6 A7C8

To claim this, I am signing this object:

tpendragon

curl -H "Accept: text/turtle" http://fragments.dbpedia.org