bbc / alephant Goto Github PK

https://github.com/kenoir/alephant/blob/master/lib/alephant/views.rb#L4 threadsafe?

BBC::Cosmos::Config.app

https://github.com/BBC-News/alephant/blob/master/Example/Event-based/Renderer/app.rb#L23

Replace autoload with a threadsafe alternative.

The publisher functionality has been split into two separate gems now:

1. alephant-publisher-queue
2. alephant-publisher-request

We've since marked the original Publisher gem as being deprecated, but the code in this repo still loads that gem instead of the alephant-publisher-queue gem (which is the default functionality).

We should update this gem to pull in alephant-publisher-queue

Could we set the default of the views base data to be an empty hash?

From:

def initialize(data)
    @data = data
end

To:

def initialize(data = {})
    @data = data
end

At the moment we set this default in most view objects which extend the Alephant base class. If we did it here, then we wouldn't always need to have our own initialize methods.

https://github.com/BBC-News/alephant/blob/master/lib/alephant/views/base.rb#L7

I've was playing around with https://github.com/nixme/pry-nav and it works really well.

I think we should add it to Alephant's development gems.

This should include diagrams and architecture and a simple example application

We'd like to include common mustache templates using mustache partials.

Currently by default it will look for partials in the current directory, but as we have different queues in the election data renderer project it's not possible to store them in the same directory.

We have got around this issue by setting the following in our view model:

self.template_path = File.dirname(__FILE__) + '/../../lib/templates/'

It would be nice for this to be set somewhere in Alephant::Views::Base - however the only caveat with that, is that '/../../lib/templates/' is very specific to the election data renderer project.

Perhaps we can call a static method on Alephant::Views::Base from the election data renderer project which sets a path for partials?

For fun and profit

When Alephant parses data, it would be good if we used symbols as the keys as this is a Ruby convention which saves memory.

If it's not a default, it would be good to pass in the option to.

https://github.com/BBC-News/alephant/blob/faa5cb5a023385cc50f022282df177852196a7c0/lib/alephant.rb#L55

    JSON.parse(msg, :symbolize_names => true)

I wasn't able to add this issue to the BBC Alephant repo as that repo is forked from this one.

https://github.com/BBC-News/alephant/blob/master/lib/alephant.rb

def initialize(opts = {})
  @sequencer = Sequencer.new(
  {
    :table_name => @table_name
  },
  @sqs_queue_id
  )
end

It seems that if table_name is not provided then the attr_accessor for table_name wont be created and so I'm not sure what value is passed to Sequencer? I assume Nil.

We need to provide a fallback in case the user doesn't supply the required values for each of the model components.

http://robm.me.uk/ruby/2014/01/18/pathname.html

Will make code intent clearer (although potentially at the cost of more memory)

Just having a quick re-read of "The RSpec Book" and it seems that some of the test code that caused me a bit of confusion might not have if a clearer syntax was used.

double(), stub() and mock() are all effectively the same (they all create an instance of a MockClass).

The reason they exist is to indicate the different intent (rather than using double all the time).

Example give in the book was...

describe Statement do
  it "logs a message on generate()" do
    customer = stub('customer')
    customer.stub(:name).and_return('Aslak')
    logger = mock('logger')
    statement = Statement.new(customer, logger)
    logger.should_receive(:log).with(/Statement generated for Aslak/)
    statement.generate
  end
end

We know the stub method should be used on a Stub and the should_receive should be used on a Mock.

Admittedly that has made the existing code become clearer. But I like the idea of code having clear intention through better terminology.

Thoughts?

We currently only provide an example for the S3 load strategy - would be great to have one for both.

Seems the Alephant gem has a license of GPLv3 (GNU GENERAL PUBLIC LICENSE), where some of the other Alephant gems are MIT

This needs to be consistent across all gems.

The difference (as far as I'm aware) is that with the MIT license you're letting all users know that they can modify the code and redistribute it as long as the original authors information is included in that distribution.

I'm not sure if the GNU license enforces a similar principle or not?