Learn Concurrency by Implementing Futures in Ruby. Futures are a concurrency abstraction that represents the result of an asynchronous computation. This means that when you give a future some computation to process, this is done in a separate thread. Therefore, the main thread is free to do other processing. The moment you need a result from the future, you can ask for it. If it is still processing the computation, then the main thread gets blocked. Otherwise, the result is returned. In this article, we will implement our very own Futures library in Ruby. How are Futures Useful? Before we begin, it’ll help a little to see how Futures can be useful to us. Require 'open-uri'require 'json'require 'benchmark' class Chucky URL = ' def sequential open(URL) do |f| f.each_line { |line| puts JSON.parse(line)['value']['joke'] } end end end In order to run this application, save the above as chucky.rb and run the program like so: % irb > require ". 10.times { chucky.sequential } % bin/setup Resolving dependencies...
Understanding Ruby's strange "Errno" exceptions - Honeybadger.io Blog. If you’ve ever taken a look at Ruby’s exception hierarchy, you may have noticed something weird. In addition to all of the normal exceptions like RuntimeError and NoMethodError, there’s an odd reference to Errno::* . If you’ve ever had the bad luck to write to disk when the disk is full, or to try to make an API call over a failing network then you’ve probably seen this type of error in action. You can trigger one right now by attempting to open a file that doesn’t exist. But what exactly are the Errono exceptions? And why are they treated differently thank other kinds of exceptions? The Errno exceptions are essentially an adapter. In ruby, errors tend to be reported as exceptions.
We can use IRB to see all of the exceptions in this module. But why are they named so cryptically? …There’s actually a very simple answer. Whoever first built the Errno module just copied the error names directly from libc. Butterfly example. NOTE: REFERS TO ØMQ/1.x This tutorial explores the strategies to use to break a single monolithic application into a set of components forming distributed computational environment. The main focus is on the overall performance of the system and on the scaling issues. Monolithic application Application is a software component that is fed by input data ("requests") producing output data ("replies") in the process: The life-cycle of a single transaction consists of input phase (fetching the request to process), processing phase itself and output phase (posting the reply): Throughput of application is measured by number of requests it can process during fixed time interval.
To compute the throughput we'll use following equation: The equation yields 1,000,000 / (4 + 8 + 4) = 62,500 requests processed per second. Pipelining To improve the throughput we can divide the processing into two consecutive steps (named "component1" and "component2") and process each of them on a separate box: Parallelisation.
Floating point arithmetics in 19 programming... Update: It seems that there has been some confusions about the results. I’m reminding that you can click on each programming language name to edit the source and see the running results for yourself! But since there is only two type of results - false & true until Pascal and false & false for others, then I wouldn’t bother much. Update #2: There has been mentioned in the comments one very useful and good article by Bruce Dawson called “Comparing floating point numbers”. Thank you for the suggestion! I got an e-mail from a co-worker about one spec which should have not been failing. At least he thought so. 1.2 - 1.0 and checked that it equals to 0.2 exactly (well, duh).1.2 * 10 - 1.0 * 10 and checked that it equals to 0.2 * 10 exactly for trying to rule out syntax errors hopefully.
The results with some comments will follow plus you can click on the language name to see the actual results on ideone and change the source code to play around. Ruby Java Oh, and the result? And the result? Perl. New in RSpec 3: Composable Matchers. Myron Marston Jan 14, 2014 One of RSpec 3's big new features is shipping 3.0.0.beta2: composable matchers. This feature supports more powerful, less brittle expectations, and opens up new possibilities. An Example In RSpec 2.x, I've written code like this on many occassions: # background_worker.rbclass BackgroundWorker attr_reader :queue def initialize @queue = [] end def enqueue(job_data) queue << job_data.merge(:enqueued_at => Time.now) endend # background_worker_spec.rbdescribe BackgroundWorker do it 'puts enqueued jobs onto the queue in order' do worker = BackgroundWorker.new worker.enqueue(:klass => "Class1", :id => 37) worker.enqueue(:klass => "Class2", :id => 42) expect(worker.queue.size).to eq(2) expect(worker.queue[0]).to include(:klass => "Class1", :id => 37) expect(worker.queue[1]).to include(:klass => "Class2", :id => 42) endend Matcher aliases As you may have noticed, the example above uses a_hash_including in place of include.
…to: Compound Matcher Expressions change contain_exactly. Wrapped exceptions in Ruby | Pablo's blog. Sometimes you want to raise an exception when a method fails but without losing information about an inner exception. Let me explain it with an example. At Watu we have a method that causes a user to be indexed in our search engine. This method is called many times in different situations. One of those situations is when indexing most or all of our users. Recently, something failed and I got this exception: Something that should be an array is actually a string.
Now I get something like: which allows me know that user 1234 has something wrong in its data. The solution to this problem is exception wrapping (or nesting). The secret lies in a new method in the class Exception called, cause. No documentation for the method Exception#cause Using it is very straightforward. You get two exceptions: the divided-by-zero wrapped inside one with the “Something went wrong” message.
The problem arrises that nobody seems to be using the causes of exceptions yet. Would produce: Like this: Like Loading...