Search results for 'type check'

10,157

Releases

1.0.2

2011-03-20

2015-10-31

Activity

lookout Homepage Documentation

lookout

0.0

No release in over 3 years

Lookout Lookout is a unit testing framework for Ruby┬╣ that puts your results in focus. Tests (expectations) are written as follows expect 2 do 1 + 1 end expect ArgumentError do Integer('1 + 1') end expect Array do [1, 2, 3].select{ |i| i % 2 == 0 } end expect [2, 4, 6] do [1, 2, 3].map{ |i| i * 2 } end Lookout is designed to encourage ΓÇô force, even ΓÇô unit testing best practices such as ΓÇó Setting up only one expectation per test ΓÇó Not setting expectations on non-public APIs ΓÇó Test isolation This is done by ΓÇó Only allowing one expectation to be set per test ΓÇó Providing no (additional) way of accessing private state ΓÇó Providing no setup and tear-down methods, nor a method of providing test helpers Other important points are ΓÇó Putting the expected outcome of a test in focus with the steps of the calculation of the actual result only as a secondary concern ΓÇó A focus on code readability by providing no mechanism for describing an expectation other than the code in the expectation itself ΓÇó A unified syntax for setting up both state-based and behavior-based expectations The way Lookout works has been heavily influenced by expectations┬▓, by {Jay Fields}┬│. The code base was once also heavily based on expectations, based at Subversion {revision 76}Γü┤. A lot has happened since then and all of the work past that revision are due to {Nikolai Weibull}Γü╡. ┬╣ Ruby: http://ruby-lang.org/ ┬▓ Expectations: http://expectations.rubyforge.org/ ┬│ Jay FieldsΓÇÖs blog: http://blog.jayfields.com/ Γü┤ Lookout revision 76: https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe Γü╡ Nikolai WeibullΓÇÖs home page: http://disu.se/ ┬º Installation Install Lookout with % gem install lookout ┬º Usage Lookout allows you to set expectations on an objectΓÇÖs state or behavior. WeΓÇÖll begin by looking at state expectations and then take a look at expectations on behavior. ┬º Expectations on State: Literals An expectation can be made on the result of a computation: expect 2 do 1 + 1 end Most objects, in fact, have their state expectations checked by invoking ΓÇ╣#==ΓÇ║ on the expected value with the result as its argument. Checking that a result is within a given range is also simple: expect 0.099..0.101 do 0.4 - 0.3 end Here, the more general ΓÇ╣#===ΓÇ║ is being used on the ΓÇ╣RangeΓÇ║. ┬º Regexps ΓÇ╣StringsΓÇ║ of course match against ΓÇ╣StringsΓÇ║: expect 'ab' do 'abc'[0..1] end but we can also match a ΓÇ╣StringΓÇ║ against a ΓÇ╣RegexpΓÇ║: expect %r{a substring} do 'a string with a substring' end (Note the use of ΓÇ╣%r{ΓÇª}ΓÇ║ to avoid warnings that will be generated when Ruby parses ΓÇ╣expect /ΓÇª/ΓÇ║.) ┬º Modules Checking that the result includes a certain module is done by expecting the ΓÇ╣ModuleΓÇ║. expect Enumerable do [] end This, due to the nature of Ruby, of course also works for classes (as they are also modules): expect String do 'a string' end This doesnΓÇÖt hinder us from expecting the actual ΓÇ╣ModuleΓÇ║ itself: expect Enumerable do Enumerable end or the ΓÇ╣ClassΓÇ║: expect String do String end for obvious reasons. As you may have figured out yourself, this is accomplished by first trying ΓÇ╣#==ΓÇ║ and, if it returns ΓÇ╣falseΓÇ║, then trying ΓÇ╣#===ΓÇ║ on the expected ΓÇ╣ModuleΓÇ║. This is also true of ΓÇ╣RangesΓÇ║ and ΓÇ╣RegexpsΓÇ║. ┬º Booleans Truthfulness is expected with ΓÇ╣trueΓÇ║ and ΓÇ╣falseΓÇ║: expect true do 1 end expect false do nil end Results equaling ΓÇ╣trueΓÇ║ or ΓÇ╣falseΓÇ║ are slightly different: expect TrueClass do true end expect FalseClass do false end The rationale for this is that you should only care if the result of a computation evaluates to a value that Ruby considers to be either true or false, not the exact literals ΓÇ╣trueΓÇ║ or ΓÇ╣falseΓÇ║. ┬º IO Expecting output on an IO object is also common: expect output("abc\ndef\n") do |io| io.puts 'abc', 'def' end This can be used to capture the output of a formatter that takes an output object as a parameter. ┬º Warnings Expecting warnings from code isnΓÇÖt very common, but should be done: expect warning('this is your final one!') do warn 'this is your final one!' end expect warning('this is your final one!') do warn '%s:%d: warning: this is your final one!' % [__FILE__, __LINE__] end ΓÇ╣$VERBOSEΓÇ║ is set to ΓÇ╣trueΓÇ║ during the execution of the block, so you donΓÇÖt need to do so yourself. If you have other code that depends on the value of $VERBOSE, that can be done with ΓÇ╣#with_verboseΓÇ║ expect nil do with_verbose nil do $VERBOSE end end ┬º Errors You should always be expecting errors from ΓÇô and in, but thatΓÇÖs a different story ΓÇô your code: expect ArgumentError do Integer('1 + 1') end Often, not only the type of the error, but its description, is important to check: expect StandardError.new('message') do raise StandardError.new('message') end As with ΓÇ╣StringsΓÇ║, ΓÇ╣RegexpsΓÇ║ can be used to check the error description: expect StandardError.new(/mess/) do raise StandardError.new('message') end ┬º Queries Through Symbols Symbols are generally matched against symbols, but as a special case, symbols ending with ΓÇ╣?ΓÇ║ are seen as expectations on the result of query methods on the result of the block, given that the method is of zero arity and that the result isnΓÇÖt a Symbol itself. Simply expect a symbol ending with ΓÇ╣?ΓÇ║: expect :empty? do [] end To expect itΓÇÖs negation, expect the same symbol beginning with ΓÇ╣not_ΓÇ║: expect :not_nil? do [1, 2, 3] end This is the same as expect true do [].empty? end and expect false do [1, 2, 3].empty? end but provides much clearer failure messages. It also makes the expectationΓÇÖs intent a lot clearer. ┬º Queries By Proxy ThereΓÇÖs also a way to make the expectations of query methods explicit by invoking methods on the result of the block. For example, to check that the even elements of the Array ΓÇ╣[1, 2, 3]ΓÇ║ include ΓÇ╣1ΓÇ║ you could write expect result.to.include? 1 do [1, 2, 3].reject{ |e| e.even? } end You could likewise check that the result doesnΓÇÖt include 2: expect result.not.to.include? 2 do [1, 2, 3].reject{ |e| e.even? } end This is the same as (and executes a little bit slower than) writing expect false do [1, 2, 3].reject{ |e| e.even? }.include? 2 end but provides much clearer failure messages. Given that these two last examples would fail, youΓÇÖd get a message saying ΓÇ£[1, 2, 3]#include?(2)ΓÇ¥ instead of the terser ΓÇ£trueΓëáfalseΓÇ¥. It also clearly separates the actual expectation from the set-up. The keyword for this kind of expectations is ΓÇ╣resultΓÇ║. This may be followed by any of the methods ΓÇó ΓÇ╣#notΓÇ║ ΓÇó ΓÇ╣#toΓÇ║ ΓÇó ΓÇ╣#beΓÇ║ ΓÇó ΓÇ╣#haveΓÇ║ or any other method you will want to call on the result. The methods ΓÇ╣#toΓÇ║, ΓÇ╣#beΓÇ║, and ΓÇ╣#haveΓÇ║ do nothing except improve readability. The ΓÇ╣#notΓÇ║ method inverts the expectation. ┬º Literal Literals If you need to literally check against any of the types of objects otherwise treated specially, that is, any instances of ΓÇó ΓÇ╣ModuleΓÇ║ ΓÇó ΓÇ╣RangeΓÇ║ ΓÇó ΓÇ╣RegexpΓÇ║ ΓÇó ΓÇ╣ExceptionΓÇ║ ΓÇó ΓÇ╣SymbolΓÇ║, given that it ends with ΓÇ╣?ΓÇ║ you can do so by wrapping it in ΓÇ╣literal(ΓÇª)ΓÇ║: expect literal(:empty?) do :empty? end You almost never need to do this, as, for all but symbols, instances will match accordingly as well. ┬º Expectations on Behavior We expect our objects to be on their best behavior. Lookout allows you to make sure that they are. Reception expectations let us verify that a method is called in the way that we expect it to be: expect mock.to.receive.to_str(without_arguments){ '123' } do |o| o.to_str end Here, ΓÇ╣#mockΓÇ║ creates a mock object, an object that doesnΓÇÖt respond to anything unless you tell it to. We tell it to expect to receive a call to ΓÇ╣#to_strΓÇ║ without arguments and have ΓÇ╣#to_strΓÇ║ return ΓÇ╣'123'ΓÇ║ when called. The mock object is then passed in to the block so that the expectations placed upon it can be fulfilled. Sometimes we only want to make sure that a method is called in the way that we expect it to be, but we donΓÇÖt care if any other methods are called on the object. A stub object, created with ΓÇ╣#stubΓÇ║, expects any method and returns a stub object that, again, expects any method, and thus fits the bill. expect stub.to.receive.to_str(without_arguments){ '123' } do |o| o.to_str if o.convertable? end You donΓÇÖt have to use a mock object to verify that a method is called: expect Object.to.receive.name do Object.name end As you have figured out by now, the expected method call is set up by calling ΓÇ╣#receiveΓÇ║ after ΓÇ╣#toΓÇ║. ΓÇ╣#ReceiveΓÇ║ is followed by a call to the method to expect with any expected arguments. The body of the expected method can be given as the block to the method. Finally, an expected invocation count may follow the method. LetΓÇÖs look at this formal specification in more detail. The expected method arguments may be given in a variety of ways. LetΓÇÖs introduce them by giving some examples: expect mock.to.receive.a do |m| m.a end Here, the method ΓÇ╣#aΓÇ║ must be called with any number of arguments. It may be called any number of times, but it must be called at least once. If a method must receive exactly one argument, you can use ΓÇ╣ObjectΓÇ║, as the same matching rules apply for arguments as they do for state expectations: expect mock.to.receive.a(Object) do |m| m.a 0 end If a method must receive a specific argument, you can use that argument: expect mock.to.receive.a(1..2) do |m| m.a 1 end Again, the same matching rules apply for arguments as they do for state expectations, so the previous example expects a call to ΓÇ╣#aΓÇ║ with 1, 2, or the Range 1..2 as an argument on ΓÇ╣mΓÇ║. If a method must be invoked without any arguments you can use ΓÇ╣without_argumentsΓÇ║: expect mock.to.receive.a(without_arguments) do |m| m.a end You can of course use both ΓÇ╣ObjectΓÇ║ and actual arguments: expect mock.to.receive.a(Object, 2, Object) do |m| m.a nil, 2, '3' end The body of the expected method may be given as the block. Here, calling ΓÇ╣#aΓÇ║ on ΓÇ╣mΓÇ║ will give the result ΓÇ╣1ΓÇ║: expect mock.to.receive.a{ 1 } do |m| raise 'not 1' unless m.a == 1 end If no body has been given, the result will be a stub object. To take a block, grab a block parameter and ΓÇ╣#callΓÇ║ it: expect mock.to.receive.a{ |&b| b.call(1) } do |m| j = 0 m.a{ |i| j = i } raise 'not 1' unless j == 1 end To simulate an ΓÇ╣#eachΓÇ║-like method, ΓÇ╣#callΓÇ║ the block several times. Invocation count expectations can be set if the default expectation of ΓÇ£at least onceΓÇ¥ isnΓÇÖt good enough. The following expectations are possible ΓÇó ΓÇ╣#at_most_onceΓÇ║ ΓÇó ΓÇ╣#onceΓÇ║ ΓÇó ΓÇ╣#at_least_onceΓÇ║ ΓÇó ΓÇ╣#twiceΓÇ║ And, for a given ΓÇ╣NΓÇ║, ΓÇó ΓÇ╣#at_most(N)ΓÇ║ ΓÇó ΓÇ╣#exactly(N)ΓÇ║ ΓÇó ΓÇ╣#at_least(N)ΓÇ║ ┬º Utilities: Stubs Method stubs are another useful thing to have in a unit testing framework. Sometimes you need to override a method that does something a test shouldnΓÇÖt do, like access and alter bank accounts. We can override ΓÇô stub out ΓÇô a method by using the ΓÇ╣#stubΓÇ║ method. LetΓÇÖs assume that we have an ΓÇ╣AccountΓÇ║ class that has two methods, ΓÇ╣#slipsΓÇ║ and ΓÇ╣#totalΓÇ║. ΓÇ╣#SlipsΓÇ║ retrieves the bank slips that keep track of your deposits to the ΓÇ╣AccountΓÇ║ from a database. ΓÇ╣#TotalΓÇ║ sums the ΓÇ╣#slipsΓÇ║. In the following test we want to make sure that ΓÇ╣#totalΓÇ║ does what it should do without accessing the database. We therefore stub out ΓÇ╣#slipsΓÇ║ and make it return something that we can easily control. expect 6 do |m| stub(Class.new{ def slips raise 'database not available' end def total slips.reduce(0){ |m, n| m.to_i + n.to_i } end }.new, :slips => [1, 2, 3]){ |account| account.total } end To make it easy to create objects with a set of stubbed methods thereΓÇÖs also a convenience method: expect 3 do s = stub(:a => 1, :b => 2) s.a + s.b end This short-hand notation can also be used for the expected value: expect stub(:a => 1, :b => 2).to.receive.a do |o| o.a + o.b end and also works for mock objects: expect mock(:a => 2, :b => 2).to.receive.a do |o| o.a + o.b end Blocks are also allowed when defining stub methods: expect 3 do s = stub(:a => proc{ |a, b| a + b }) s.a(1, 2) end If need be, we can stub out a specific method on an object: expect 'def' do stub('abc', :to_str => 'def'){ |a| a.to_str } end The stub is active during the execution of the block. ┬º Overriding Constants Sometimes you need to override the value of a constant during the execution of some code. Use ΓÇ╣#with_constΓÇ║ to do just that: expect 'hello' do with_const 'A::B::C', 'hello' do A::B::C end end Here, the constant ΓÇ╣A::B::CΓÇ║ is set to ΓÇ╣'hello'ΓÇ║ during the execution of the block. None of the constants ΓÇ╣AΓÇ║, ΓÇ╣BΓÇ║, and ΓÇ╣CΓÇ║ need to exist for this to work. If a constant doesnΓÇÖt exist itΓÇÖs created and set to a new, empty, ΓÇ╣ModuleΓÇ║. The value of ΓÇ╣A::B::CΓÇ║, if any, is restored after the block returns and any constants that didnΓÇÖt previously exist are removed. ┬º Overriding Environment Variables Another thing you often need to control in your tests is the value of environment variables. Depending on such global values is, of course, not a good practice, but is often unavoidable when working with external libraries. ΓÇ╣#With_envΓÇ║ allows you to override the value of environment variables during the execution of a block by giving it a ΓÇ╣HashΓÇ║ of key/value pairs where the key is the name of the environment variable and the value is the value that it should have during the execution of that block: expect 'hello' do with_env 'INTRO' => 'hello' do ENV['INTRO'] end end Any overridden values are restored and any keys that werenΓÇÖt previously a part of the environment are removed when the block returns. ┬º Overriding Globals You may also want to override the value of a global temporarily: expect 'hello' do with_global :$stdout, StringIO.new do print 'hello' $stdout.string end end You thus provide the name of the global and a value that it should take during the execution of a block of code. The block gets passed the overridden value, should you need it: expect true do with_global :$stdout, StringIO.new do |overridden| $stdout != overridden end end ┬º Integration Lookout can be used from Rake┬╣. Simply install Lookout-Rake┬▓: % gem install lookout-rake and add the following code to your Rakefile require 'lookout-rake-3.0' Lookout::Rake::Tasks::Test.new Make sure to read up on using Lookout-Rake for further benefits and customization. ┬╣ Read more about Rake at http://rake.rubyforge.org/ ┬▓ Get information on Lookout-Rake at http://disu.se/software/lookout-rake/ ┬º API Lookout comes with an API┬╣ that letΓÇÖs you create things such as new expected values, difference reports for your types, and so on. ┬╣ See http://disu.se/software/lookout/api/ ┬º Interface Design The default output of Lookout can Spartanly be described as Spartan. If no errors or failures occur, no output is generated. This is unconventional, as unit testing frameworks tend to dump a lot of information on the user, concerning things such as progress, test count summaries, and flamboyantly colored text telling you that your tests passed. None of this output is needed. Your tests should run fast enough to not require progress reports. The lack of output provides you with the same amount of information as reporting success. Test count summaries are only useful if youΓÇÖre worried that your tests arenΓÇÖt being run, but if you worry about that, then providing such output doesnΓÇÖt really help. Testing your tests requires something beyond reporting some arbitrary count that you would have to verify by hand anyway. When errors or failures do occur, however, the relevant information is output in a format that can easily be parsed by an ΓÇ╣'errorformat'ΓÇ║ for Vim or with {Compilation Mode}┬╣ for Emacs┬▓. Diffs are generated for Strings, Arrays, Hashes, and I/O. ┬╣ Read up on Compilation mode for Emacs at http://www.emacswiki.org/emacs/CompilationMode ┬▓ Visit The GNU FoundationΓÇÖs EmacsΓÇÖ software page at http://www.gnu.org/software/emacs/ ┬º External Design LetΓÇÖs now look at some of the points made in the introduction in greater detail. Lookout only allows you to set one expectation per test. If youΓÇÖre testing behavior with a reception expectation, then only one method-invocation expectation can be set. If youΓÇÖre testing state, then only one result can be verified. It may seem like this would cause unnecessary duplication between tests. While this is certainly a possibility, when you actually begin to try to avoid such duplication you find that you often do so by improving your interfaces. This kind of restriction tends to encourage the use of value objects, which are easy to test, and more focused objects, which require simpler tests, as they have less behavior to test, per method. By keeping your interfaces focused youΓÇÖre also keeping your tests focused. Keeping your tests focused improves, in itself, test isolation, but letΓÇÖs look at something that hinders it: setup and tear-down methods. Most unit testing frameworks encourage test fragmentation by providing setup and tear-down methods. Setup methods create objects and, perhaps, just their behavior for a set of tests. This means that you have to look in two places to figure out whatΓÇÖs being done in a test. This may work fine for few methods with simple set-ups, but makes things complicated when the number of tests increases and the set-up is complex. Often, each test further adjusts the previously set-up object before performing any verifications, further complicating the process of figuring out what state an object has in a given test. Tear-down methods clean up after tests, perhaps by removing records from a database or deleting files from the file-system. The duplication that setup methods and tear-down methods hope to remove is better avoided by improving your interfaces. This can be done by providing better set-up methods for your objects and using idioms such as {Resource Acquisition Is Initialization}┬╣ for guaranteed clean-up, test or no test. By not using setup and tear-down methods we keep everything pertinent to a test in the test itself, thus improving test isolation. (You also wonΓÇÖt {slow down your tests}┬▓ by keeping unnecessary state.) Most unit test frameworks also allow you to create arbitrary test helper methods. Lookout doesnΓÇÖt. The same rationale as that that has been crystallized in the preceding paragraphs applies. If you need helpers youΓÇÖre interface isnΓÇÖt good enough. It really is as simple as that. To clarify: thereΓÇÖs nothing inherently wrong with test helper methods, but they should be general enough that they reside in their own library. The support for mocks in Lookout is provided through a set of test helper methods that make it easier to create mocks than it would have been without them. Lookout-rack┬│ is another example of a library providing test helper methods (well, one method, actually) that are very useful in testing web applications that use RackΓü┤. A final point at which some unit test frameworks try to fragment tests further is documentation. These frameworks provide ways of describing the whats and hows of whatΓÇÖs being tested, the rationale being that this will provide documentation of both the test and the code being tested. Describing how a stack data structure is meant to work is a common example. A stack is, however, a rather simple data structure, so such a description provides little, if any, additional information that canΓÇÖt be extracted from the implementation and its tests themselves. The implementation and its tests is, in fact, its own best documentation. Taking the points made in the previous paragraphs into account, we should already have simple, self-describing, interfaces that have easily understood tests associated with them. Rationales for the use of a given data structure or system-design design documentation is better suited in separate documentation focused at describing exactly those issues. ┬╣ Read the Wikipedia entry for Resource Acquisition Is Initialization at http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization ┬▓ Read how 37signals had problems with slow Test::Unit tests at http://37signals.com/svn/posts/2742-the-road-to-faster-tests/ ┬│ Visit the Lookout-rack home page at http://disu.se/software/lookout-rack/ Γü┤ Visit the Rack Rubyforge project page at http://rack.rubyforge.org/ ┬º Internal Design The internal design of Lookout has had a couple of goals. ΓÇó As few external dependencies as possible ΓÇó As few internal dependencies as possible ΓÇó Internal extensibility provides external extensibility ΓÇó As fast load times as possible ΓÇó As high a ratio of value objects to mutable objects as possible ΓÇó Each object must have a simple, obvious name ΓÇó Use mix-ins, not inheritance for shared behavior ΓÇó As few responsibilities per object as possible ΓÇó Optimizing for speed can only be done when you have all the facts ┬º External Dependencies Lookout used to depend on Mocha for mocks and stubs. While benchmarking I noticed that a method in Mocha was taking up more than 300 percent of the runtime. It turned out that MochaΓÇÖs method for cleaning up back-traces generated when a mock failed was doing something incredibly stupid: backtrace.reject{ |l| Regexp.new(@lib).match(File.expand_path(l)) } Here ΓÇ╣@libΓÇ║ is a ΓÇ╣StringΓÇ║ containing the path to the lib sub-directory in the Mocha installation directory. I reported it, provided a patch five days later, then waited. Nothing happened. {254 days later}┬╣, according to {Wolfram Alpha}┬▓, half of my patch was, apparently ΓÇô I say ΓÇ£apparentlyΓÇ¥, as I received no notification ΓÇô applied. By that time I had replaced the whole mocking-and-stubbing subsystem and dropped the dependency. Many Ruby developers claim that Ruby and its gems are too fast-moving for normal package-managing systems to keep up. This is testament to the fact that this isnΓÇÖt the case and that the real problem is instead related to sloppy practices. Please note that I donΓÇÖt want to single out the Mocha library nor its developers. I only want to provide an example where relying on external dependencies can be ΓÇ£considered harmfulΓÇ¥. ┬╣ See the Wolfram Alpha calculation at http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010 ┬▓ Check out the Wolfram Alpha computational knowledge engine at http://www.wolframalpha.com/ ┬º Internal Dependencies Lookout has been designed so as to keep each subsystem independent of any other. The diff subsystem is, for example, completely decoupled from any other part of the system as a whole and could be moved into its own library at a time where that would be of interest to anyone. WhatΓÇÖs perhaps more interesting is that the diff subsystem is itself very modular. The data passes through a set of filters that depends on what kind of diff has been requested, each filter yielding modified data as it receives it. If you want to read some rather functional Ruby I can highly recommend looking at the code in the ΓÇ╣lib/lookout/diffΓÇ║ directory. This lookout on the design of the library also makes it easy to extend Lookout. Lookout-rack was, for example, written in about four hours and about 5 of those 240 minutes were spent on setting up the interface between the two. ┬º Optimizing For Speed The following paragraph is perhaps a bit personal, but might be interesting nonetheless. IΓÇÖve always worried about speed. The original Expectations library used ΓÇ╣extendΓÇ║ a lot to add new behavior to objects. Expectations, for example, used to hold the result of their execution (what we now term ΓÇ£evaluationΓÇ¥) by being extended by a module representing success, failure, or error. For the longest time I used this same method, worrying about the increased performance cost that creating new objects for results would incur. I finally came to a point where I felt that the code was so simple and clean that rewriting this part of the code for a benchmark wouldnΓÇÖt take more than perhaps ten minutes. Well, ten minutes later I had my results and they confirmed that creating new objects wasnΓÇÖt harming performance. I was very pleased. ┬º Naming I hate low lines (underscores). I try to avoid them in method names and I always avoid them in file names. Since the current ΓÇ£best practiceΓÇ¥ in the Ruby community is to put ΓÇ╣BeginEndStorageΓÇ║ in a file called ΓÇ╣begin_end_storage.rbΓÇ║, I only name constants using a single noun. This has had the added benefit that classes seem to have acquired less behavior, as using a single noun doesnΓÇÖt allow you to tack on additional behavior without questioning if itΓÇÖs really appropriate to do so, given the rather limited range of interpretation for that noun. It also seems to encourage the creation of value objects, as something named ΓÇ╣RangeΓÇ║ feels a lot more like a value than ΓÇ╣BeginEndStorageΓÇ║. (To reach object-oriented-programming Nirvana you must achieve complete value.) ┬º News ┬º 3.0.0 The ΓÇ╣xmlΓÇ║ expectation has been dropped. It wasnΓÇÖt documented, didnΓÇÖt suit very many use cases, and can be better implemented by an external library. The ΓÇ╣argΓÇ║ argument matcher for mock method arguments has been removed, as it didnΓÇÖt provide any benefit over using Object. The ΓÇ╣#yieldΓÇ║ and ΓÇ╣#eachΓÇ║ methods on stub and mock methods have been removed. They were slightly weird and their use case can be implemented using block parameters instead. The ΓÇ╣stubΓÇ║ method inside ΓÇ╣expectΓÇ║ blocks now stubs out the methods during the execution of a provided block instead of during the execution of the whole except block. When a mock method is called too many times, this is reported immediately, with a full backtrace. This makes it easier to pin down whatΓÇÖs wrong with the code. Query expectations were added. Explicit query expectations were added. Fluent boolean expectations, for example, ΓÇ╣expect nil.to.be.nil?ΓÇ║ have been replaced by query expectations (ΓÇ╣expect :nil? do nil endΓÇ║) and explicit query expectations (ΓÇ╣expect result.to.be.nil? do nil endΓÇ║). This was done to discourage creating objects as the expected value and creating objects that change during the course of the test. The ΓÇ╣literalΓÇ║ expectation was added. Equality (ΓÇ╣#==ΓÇ║) is now checked before ΓÇ£caseityΓÇ¥ (ΓÇ╣#===ΓÇ║) for modules, ranges, and regular expressions to match the documentation. ┬º Financing Currently, most of my time is spent at my day job and in my rather busy private life. Please motivate me to spend time on this piece of software by donating some of your money to this project. Yeah, I realize that requesting money to develop software is a bit, well, capitalistic of me. But please realize that I live in a capitalistic society and I need money to have other people give me the things that I need to continue living under the rules of said society. So, if you feel that this piece of software has helped you out enough to warrant a reward, please PayPal a donation to now@disu.se┬╣. Thanks! Your support wonΓÇÖt go unnoticed! ┬╣ Send a donation: https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Lookout ┬º Reporting Bugs Please report any bugs that you encounter to the {issue tracker}┬╣. ┬╣ See https://github.com/now/lookout/issues ┬º Contributors Contributors to the original expectations codebase are mentioned there. We hope no one on that list feels left out of this list. Please {let us know}┬╣ if you do. ΓÇó Nikolai Weibull ┬╣ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues ┬º Licensing Lookout is free software: you may redistribute it and/or modify it under the terms of the {GNU Lesser General Public License, version 3}┬╣ or later┬▓, as published by the {Free Software Foundation}┬│. ┬╣ See http://disu.se/licenses/lgpl-3.0/ ┬▓ See http://gnu.org/licenses/ ┬│ See http://fsf.org/

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

33,300

Releases

3.0.1

2011-03-20

2013-09-04

Activity

rzd alno/rzd Homepage Documentation Source Code Bug Tracker Wiki

rzd

0.0

No commit activity in last 3 years

No release in over 3 years

Rzd is a gem automating checking ticket information for russian railway service rzd.ru. Now it allows to get available ticket types fro given cities and date.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

7,219

Releases

0.2.0

2011-05-14

2011-05-27

Activity

2011-05-22

preconditions ctucker/preconditions Homepage Documentation Source Code Wiki

preconditions

0.01

No commit activity in last 3 years

No release in over 3 years

The Preconditions library provides a simple set of methods for checking arguments being passed into a method. Instead of writing custom checks and raising exceptions directly in your code you can use Preconditions to verify basic properties of your arguments (not-nil, satisfying a boolean expression, being of a certain type/duck-type) and raise the appropriate exception for you.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

129,013

Releases

0.3.0

2011-05-19

2012-07-31

Activity

2011-07-14

typed-array yaauie/typed-array Homepage Documentation Source Code Bug Tracker Wiki

typed-array

0.01

No commit activity in last 3 years

No release in over 3 years

All methods that alter the contents of an array that implements this Gem are first checked to ensure that the added items are of the types allowed. All methods behave exactly as their Array counterparts, including additional forms, block processing, etc. Defining a TypedArray Class: ```ruby class ThingsArray < Array extend TypedArray restrict_types Thing1, Thing2 end things = ThingsArray.new ``` Generating a single TypedArray ```ruby things = TypedArray(Thing1,Thing2).new These classes can be extended, and their accepted-types appended to after their initial definition.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

34,746

Releases

0.1.2

2011-08-03

2011-08-03

Activity

100%

2011-08-22

ame Homepage Documentation

ame

0.0

No release in over 3 years

Ame Ame provides a simple command-line interface API for Ruby¹. It can be used to provide both simple interfaces like that of ‹rm›² and complex ones like that of ‹git›³. It uses Ruby’s own classes, methods, and argument lists to provide an interface that is both simple to use from the command-line side and from the Ruby side. The provided command-line interface is flexible and follows commond standards for command-line processing. ¹ See http://ruby-lang.org/ ² See http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html ³ See http://git-scm.com/docs/ § Usage Let’s begin by looking at two examples, one where we mimic the POSIX¹ command-line interface to the ‹rm› command. Looking at the entry² in the standard, ‹rm› takes the following options: = -f. = Do not prompt for confirmation. = -i. = Prompt for confirmation. = -R. = Remove file hierarchies. = -r. = Equivalent to /-r/. It also takes the following arguments: = FILE. = A pathname or directory entry to be removed. And actually allows one or more of these /FILE/ arguments to be given. We also note that the ‹rm› command is described as a command to “remove directory entries”. ¹ See http://pubs.opengroup.org/onlinepubs/9699919799/utilities/contents.html ² See http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html Let’s turn this specification into one using Ame’s API. We begin by adding a flag for each of the options listed above: class Rm < Ame::Root flag 'f', '', false, 'Do not prompt for confirmation' flag 'i', '', nil, 'Prompt for confirmation' do |options| options['f'] = false end flag 'R', '', false, 'Remove file hierarchies' flag 'r', '', nil, 'Equivalent to -R' do |options| options['r'] = true end A flag¹ is a boolean option that doesn’t take an argument. Each flag gets a short and long name, where an empty name means that there’s no corresponding short or long name for the flag, a default value (true, false, or nil), and a description of what the flag does. Each flag can also optionally take a block that can do further processing. In this case we use this block to modify the Hash that maps option names to their values passed to the block to set other flags’ values than the ones that the block is associated with. As these flags (‘i’ and ‘r’) aren’t themselves of interest, their default values have been set to nil, which means that they won’t be included in the Hash that maps option names to their values when passed to the method. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#flag-class-method There are quite a few other kinds of options besides flags that can be defined using Ame, but flags are all that are required for this example. We’ll get to the other kinds in later examples. Next we add a “splus” argument. splus 'FILE', String, 'File to remove' A splus¹ argument is like a Ruby “splat”, that is, an Array argument at the end of the argument list to a method preceded by a star, except that a splus requires at least one argument. A splus argument gets a name for the argument (‹FILE›), the type of argument it represents (String), and a description. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#splus-class-method Then we add a description of the command (method) itself: description 'Remove directory entries' Descriptions¹ will be used in help output to assist the user in using the command. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#description-class-method Finally, we add the Ruby method that’ll implement the command (all preceding code included here for completeness): class Rm < Ame::Root version '1.0.0' flag 'f', '', false, 'Do not prompt for confirmation' flag 'i', '', nil, 'Prompt for confirmation' do |options| options['f'] = false end flag 'R', '', false, 'Remove file hierarchies' flag 'r', '', nil, 'Equivalent to -R' do |options| options['r'] = true end splus 'FILE', String, 'File to remove' description 'Remove directory entries' def rm(files, options = {}) require 'fileutils' FileUtils.send options['R'] ? :rm_r : :rm, [first] + rest, :force => options['f'] end end Actually, another bit of code was also added, namely version '1.0.0' This sets the version¹ String of the command. This information is used when the command is invoked with the “‹--version›” flag. This flag is automatically added, so you don’t need to add it yourself. Another flag, “‹--help›”, is also added automatically. When given, this flag’ll make Ame output usage information of the command. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#version-class-method To actually run the command, all you need to do is invoke Rm.process This’ll invoke the command using the command-line arguments stored in ‹ARGV›, but you can also specify other ones if you want to: Rm.process 'rm', %w[-r /tmp/*] The first argument to #process¹ is the name of the method to invoke, which defaults to ‹File.basename($0)›, and the second argument is an Array of Strings that should be processed as command-line arguments passed to the command. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#process-class-method If you’d store the complete ‹Rm› class defined above in a file called ‹rm› and add ‹#! /usr/bin/ruby -w› at the beginning and ‹Rm.process› at the end, you’d have a fully functional ‹rm› command (after making it executable). Let’s see it in action: % rm --help Usage: rm [OPTIONS]... FILE... Remove directory entries Arguments: FILE... File to remove Options: -R Remove file hierarchies -f Do not prompt for confirmation --help Display help for this method -i Prompt for confirmation -r Equivalent to -R --version Display version information % rm --version rm 1.0.0 Some commands are more complex than ‹rm›. For example, ‹git›¹ has a rather complex command-line interface. We won’t mimic it all here, but let’s introduce the rest of the Ame API using a fake ‹git› clone as an example. ¹ See http://git-scm.com/docs/ ‹Git› uses sub-commands to achieve most things. Implementing sub-commands with Ame is done using a “dispatch”. We’ll discuss dispatches in more detail later, but suffice it to say that a dispatch delegates processing to a child class that’ll handle the sub-command in question. We begin by defining our main ‹git› command using a class called ‹Git› under the ‹Git::CLI› namespace: module Git end class Git::CLI < Ame::Root version '1.0.0' class Git < Ame::Class description 'The stupid content tracker' def initialize; end We’re setting things up to use the ‹Git› class as a dispatch in the ‹Git::CLI› class. The description on the ‹initialize› method will be used as a description of the ‹git› dispatch command itself. Next, let’s add the ‹format-patch›¹ sub-command: description 'Prepare patches for e-mail submission' flag ?n, 'numbered', false, 'Name output in [PATCH n/m] format' flag ?N, 'no-numbered', nil, 'Name output in [PATCH] format' do |options| options['numbered'] = false end toggle ?s, 'signoff', false, 'Add Signed-off-by: line to the commit message' switch '', 'thread', 'STYLE', nil, Ame::Types::Enumeration[:shallow, :deep], 'Controls addition of In-Reply-To and References headers' flag '', 'no-thread', nil, 'Disables addition of In-Reply-To and Reference headers' do |options, _| options.delete 'thread' end option '', 'start-number', 'N', 1, 'Start numbering the patches at N instead of 1' multioption '', 'to', 'ADDRESS', String, 'Add a To: header to the email headers' optional 'SINCE', 'N/A', 'Generate patches for commits after SINCE' def format_patch(since = '', options = {}) p since, options end ¹ See http://git-scm.com/docs/git-format-patch/ We’re using quite a few new Ame commands here. Let’s look at each in turn: toggle ?s, 'signoff', false, 'Add Signed-off-by: line to the commit message' A “toggle”¹ is a flag that also has an inverse. Beyond the flags ‘s’ and “signoff”, the toggle also defines “no-signoff”, which will set “signoff” to false. This is useful if you want to support configuration files that set “signoff”’s default to true, but still allow it to be overridden on the command line. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#toggle-class-method When using the short form of a toggle (and flag and switch), multiple ones may be juxtaposed after the initial one. For example, “‹-sn›” is equivalent to “‹-s -n›” to “git format-patch›”. switch '', 'thread', 'STYLE', nil, Ame::Types::Enumeration[:shallow, :deep], 'Controls addition of In-Reply-To and References headers' A “switch”¹ is an option that takes an optional argument. This allows you to have separate defaults for when the switch isn’t present on the command line and for when it’s given without an argument. The third argument to a switch is the name of the argument. We’re also introducing a new concept here in ‹Ame::Types::Enumeration›. An enumeration² allows you to limit the allowed input to a set of Symbols. An enumeration also has a default value in the first item to its constructor (which is aliased as ‹.[]›). In this case, the “thread” switch defaults to nil, but, when given, will default to ‹:shallow› if no argument is given. If an argument is given it must be either “shallow” or “deep”. A switch isn’t required to take an enumeration as its argument default and can take any kind of default value for its argument that Ame knows how to handle. We’ll look at this in more detail later, but know that the type of the default value will be used to inform Ame how to parse a command-line argument into a Ruby value. An argument to a switch must be given, in this case, as “‹--thread=deep›” on the command line. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#switch-class-method ² See http://disu.se/software/ame-1.0/api/user/Ame/Types/Enumeration/ option '', 'start-number', 'N', 1, 'Start numbering the patches at N instead of 1' An “option”¹ is an option that takes an argument. The argument must always be present and may be given, in this case, as “‹--start-number=2›” or “‹--start-number 2›” on the command line. For a short-form option, anything that follows the option is seen as an argument, so assuming that “start-number” also had a short name of ‘S’, “‹-S2›” would be equivalent to “‹-S 2›”, which would be equivalent to “‹--start-number 2›”. Note that “‹-snS2›” would still work as expected. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#option-class-method multioption '', 'to', 'ADDRESS', String, 'Add a To: header to the email headers' A “multioption”¹ is an option that takes an argument and may be repeated any number of times. Each argument will be added to an Array stored in the Hash that maps option names to their values. Instead of taking a default argument, it takes a type for the argument (String, in this case). Again, types are used to inform Ame how to parse command-line arguments into Ruby values. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#multioption-class-method optional 'SINCE', 'N/A', 'Generate patches for commits after SINCE' An “optional”¹ argument is an argument that isn’t required. If it’s not present on the command line it’ll get its default value (the String ‹'N/A'›, in this case). ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#optional-class-method We’ve now covered all kinds of options and one new kind of argument. There are three more types of argument (one that we’ve already seen and two new) that we’ll look into now: “argument”, “splat”, and “splus”. description 'Annotate file lines with commit information' argument 'FILE', String, 'File to annotate' def annotate(file) p file end An “argument”¹ is an argument that’s required. If it’s not present on the command line, an error will be raised (and by default reported to the terminal). As it’s required, it doesn’t take a default, but rather a type. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#argument-class-method description 'Add file contents to the index' splat 'PATHSPEC', String, 'Files to add content from' def add(paths) p paths end A “splat”¹ is an argument that’s not required, but may be given any number of times. The type of a splat is the type of one argument and the type of a splat as a whole is an Array of values of that type. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#splat-class-method description 'Display gitattributes information' splus 'PATHNAME', String, 'Files to list attributes of' def check_attr(paths) p paths end A “splus”¹ is an argument that’s required, but may also be given any number of times. The type of a splus is the type of one argument and the type of a splus as a whole is an Array of values of that type. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#splus-class-method Now that we’ve seen all kinds of options and arguments, let’s look on an additional tool at our disposal, the dispatch¹. class Remote < Ame::Class description 'Manage set of remote repositories' def initialize; end description 'Shows a list of existing remotes' flag 'v', 'verbose', false, 'Show remote URL after name' def list(options = {}) p options end description 'Adds a remote named NAME for the repository at URL' argument 'name', String, 'Name of the remote to add' argument 'url', String, 'URL to the repository of the remote to add' def add(name, url) p name, url end end ¹ See http://disu.se/software/ame-1.0/api/user/Ame/Class#dispatch-class-method Here we’re defining a child class to Git::CLI::Git called “Remote” that doesn’t introduce anything new. Then we set up the dispatch: dispatch Remote, :default => 'list' This adds a method called “remote” to Git::CLI::Git that will dispatch processing of the command line to an instance of the Remote class when “‹git remote›” is seen on the command line. The “remote” method expects an argument that’ll be used to decide what sub-command to execute. Here we’ve specified that in the absence of such an argument, the “list” method should be invoked. We add the same kind of dispatch to Git under Git::CLI: dispatch Git and then we’re done. Here’s all the previous code in its entirety: module Git end class Git::CLI < Ame::Root version '1.0.0' class Git < Ame::Class description 'The stupid content tracker' def initialize; end description 'Prepare patches for e-mail submission' flag ?n, 'numbered', false, 'Name output in [PATCH n/m] format' flag ?N, 'no-numbered', nil, 'Name output in [PATCH] format' do |options| options['numbered'] = false end toggle ?s, 'signoff', false, 'Add Signed-off-by: line to the commit message' switch '', 'thread', 'STYLE', nil, Ame::Types::Enumeration[:shallow, :deep], 'Controls addition of In-Reply-To and References headers' flag '', 'no-thread', nil, 'Disables addition of In-Reply-To and Reference headers' do |options, _| options.delete 'thread' end option '', 'start-number', 'N', 1, 'Start numbering the patches at N instead of 1' multioption '', 'to', 'ADDRESS', String, 'Add a To: header to the email headers' optional 'SINCE', 'N/A', 'Generate patches for commits after SINCE' def format_patch(since = '', options = {}) p since, options end description 'Annotate file lines with commit information' argument 'FILE', String, 'File to annotate' def annotate(file) p file end description 'Add file contents to the index' splat 'PATHSPEC', String, 'Files to add content from' def add(paths) p paths end description 'Display gitattributes information' splus 'PATHNAME', String, 'Files to list attributes of' def check_attr(paths) p paths end class Remote < Ame::Class description 'Manage set of remote repositories' def initialize; end description 'Shows a list of existing remotes' flag 'v', 'verbose', false, 'Show remote URL after name' def list(options = {}) p options end description 'Adds a remote named NAME for the repository at URL' argument 'name', String, 'Name of the remote to add' argument 'url', String, 'URL to the repository of the remote to add' def add(name, url) p name, url end end dispatch Remote, :default => 'list' end dispatch Git end If we put this code in a file called “git” and add ‹#! /usr/bin/ruby -w› at the beginning and ‹Git::CLI.process› at the end, you’ll have a very incomplete git command-line interface on your hands. Let’s look at what some of its ‹--help› output looks like: % git --help Usage: git [OPTIONS]... METHOD [ARGUMENTS]... The stupid content tracker Arguments: METHOD Method to run [ARGUMENTS]... Arguments to pass to METHOD Options: --help Display help for this method --version Display version information Methods: add Add file contents to the index annotate Annotate file lines with commit information check-attr Display gitattributes information format-patch Prepare patches for e-mail submission remote Manage set of remote repositories % git format-patch --help Usage: git format-patch [OPTIONS]... [SINCE] Prepare patches for e-mail submission Arguments: [SINCE=N/A] Generate patches for commits after SINCE Options: -N, --no-numbered Name output in [PATCH] format --help Display help for this method -n, --numbered Name output in [PATCH n/m] format --no-thread Disables addition of In-Reply-To and Reference headers -s, --signoff Add Signed-off-by: line to the commit message --start-number=N Start numbering the patches at N instead of 1 --thread[=STYLE] Controls addition of In-Reply-To and References headers --to=ADDRESS* Add a To: header to the email headers % git remote --help Usage: git remote [OPTIONS]... [METHOD] [ARGUMENTS]... Manage set of remote repositories Arguments: [METHOD=list] Method to run [ARGUMENTS]... Arguments to pass to METHOD Options: --help Display help for this method Methods: add Adds a remote named NAME for the repository at URL list Shows a list of existing remotes § API The previous section gave an introduction to the whole user API in an informal and introductory way. For an indepth reference to the user API, see the {user API documentation}¹. ¹ See http://disu.se/software/ame-1.0/api/user/Ame/ If you want to extend the API or use it in some way other than as a command-line-interface writer, see the {developer API documentation}¹. ¹ See http://disu.se/software/ame-1.0/api/developer/Ame/ § Financing Currently, most of my time is spent at my day job and in my rather busy private life. Please motivate me to spend time on this piece of software by donating some of your money to this project. Yeah, I realize that requesting money to develop software is a bit, well, capitalistic of me. But please realize that I live in a capitalistic society and I need money to have other people give me the things that I need to continue living under the rules of said society. So, if you feel that this piece of software has helped you out enough to warrant a reward, please PayPal a donation to now@disu.se¹. Thanks! Your support won’t go unnoticed! ¹ Send a donation: https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=Ame § Reporting Bugs Please report any bugs that you encounter to the {issue tracker}¹. ¹ See https://github.com/now/ame/issues § Authors Nikolai Weibull wrote the code, the tests, the documentation, and this README. § Licensing Ame is free software: you may redistribute it and/or modify it under the terms of the {GNU Lesser General Public License, version 3}¹ or later², as published by the {Free Software Foundation}³. ¹ See http://disu.se/licenses/lgpl-3.0/ ² See http://gnu.org/licenses/ ³ See http://fsf.org/

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

12,907

Releases

1.0.1

2011-09-04

2015-10-31

Activity

Checked

0.0

No release in over 3 years

Checked Documentation

Various DSLs to clean, question (Ask), and validate (Demand) your objects, their classes (data types), and their properties.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

76,882

Releases

3.5.0

2011-10-13

2012-01-30

Activity

com now/com Homepage Documentation Source Code Bug Tracker Wiki

com

0.0

No commit activity in last 3 years

No release in over 3 years

# COM # COM is an object-oriented wrapper around WIN32OLE. COM makes it easy to add behavior to WIN32OLE objects, making them easier to work with from Ruby. ## Usage ## Using COM is rather straightforward. There’s basically four concepts to keep track of: 1. COM objects 2. Instantiable COM objects 3. COM events 4. COM errors Let’s look at each concept separately, using the following example as a base. module Word end class Word::Application < COM::Instantiable def without_interaction with_properties('displayalerts' => Word::WdAlertsNone){ yield } end def documents Word::Documents.new(com.documents) end def quit(saving = Word::WdDoNotSaveChanges, *args) com.quit saving, *args end end ### COM Objects ### A COM::Object is a wrapper around a COM object. It provides error specialization, which is discussed later and a few utility methods. You typically use it to wrap COM objects that are returned by COM methods. If we take the example given in the introduction, Word::Documents is a good candidate: class Word::Documents < COM::Object DefaultOpenOptions = { 'confirmconversions' => false, 'readonly' => true, 'addtorecentfiles' => false, 'visible' => false }.freeze def open(path, options = {}) options = DefaultOpenOptions.merge(options) options['filename'] = Pathname(path).to_com Word::Document.new(com.open(options)) end end Here we override the #open method to be a bit easier to use, providing sane defaults for COM interaction. Worth noting is the use of the #com method to access the actual COM object to invoke the #open method on it. Also note that Word::Document is also a COM::Object. COM::Object provides a convenience method called #with_properties, which is used in the #without_interaction method above. It lets you set properties on the COM::Object during the duration of a block, restoring them after it exits (successfully or with an error). ### Instantiable COM Objects ### Instantiable COM objects are COM objects that we can connect to and that can be created. The Word::Application object can, for example, be created. Instantiable COM objects should inherit from COM::Instantiable. Instantiable COM objects can be told what program ID to use, whether or not to allow connecting to an already running object, and to load its associated constants upon creation. The program ID is used to determine what instantiable COM object to connect to. By default the name of the COM::Instantiable class’ name is used, taking the last two double-colon-separated components and joining them with a dot. For Word::Application, the program ID is “Word.Application”. The program ID can be set by using the .program_id method: class IDontCare::ForConventions < COM::Instantiable program_id 'Word.Application' end The program ID can be accessed with the same method: Word::Application.program_id # ⇒ 'Word.Application' Connecting to an already running COM object is not done by default, but is sometimes desirable: the COM object might take a long time to create, or some common state needs to be accessed. If the default for a certain instantiable COM object should be to connect, this can be done using the .connect method: class Word::Application < COM::Instantiable connect end If no running COM object is available, then a new COM object will be created in its stead. Whether or not a class uses the connection method can be queried with the .connect? method: Word::Application.connect? # ⇒ true Whether or not to load constants associated with an instantiable COM object is set with the .constants method: class Word::Application < COM::Instantiable constants true end and can similarly be checked: Word::Application.constants? # ⇒ true Constants are loaded by default. When an instance of the instantiable COM object is created, a check is run to see if constants should be loaded and whether or not they already have been loaded. If they should be loaded and they haven’t already been loaded, they’re, you guessed it, loaded. The constants are added to the module containing the COM::Instantiable. Thus, for Word::Application, the Word module will contain all the constants. Whether or not the constants have already been loaded can be checked with .constants_loaded?: Word::Application.constants_loaded # ⇒ false That concludes the class-level methods. Let’s begin with the #connected? method among the instance-level methods. This method queries whether or not this instance connected to an already running COM object: Word::Application.new.connected? # ⇒ false This can be very important in determining how shutdown of a COM object should be done. If you connected to an already COM object it might be foolish to shut it down if someone else is using it. The #initialize method takes a couple of options: * connect: whether or not to connect to a running instance * constants: whether or not to load constants These options will, when given, override the class-level defaults. ### Events ### COM events are easily dealt with: class Word::Application < COM::Instantiable def initialize(options = {}) super @events = COM::Events.new(com, 'ApplicationEvents', 'OnQuit') end def quit(saving = Word::WdDoNotSaveChanges, *args) @events.observe('OnQuit', proc{ com.quit saving, *args }) do yield if block_given? end end end To tell you the truth this API sucks and will most likely be rewritten. The reason that it is the way it is is that WIN32OLE, which COM wraps, sucks. It’s event API is horrid and the implementation is buggy. It will keep every registered event block in memory for ever, freeing neither the blocks nor the COM objects that yield the events. ### Errors ### All errors generated by COM methods descend from COM::Error, except for those cases where a Ruby error already exists. The following HRESULT error codes are turned into Ruby errors: HRESULT Error Code | Error Class -------------------|------------ 0x80004001 | NotImplementedError 0x80020005 | TypeError 0x80020006 | NoMethodError 0x8002000e | ArgumentError 0x800401e4 | ArgumentError There are also a couple of other HRESULT error codes that are turned into more specific errors than COM::Error: HRESULT Error Code | Error Class -------------------|------------ 0x80020003 | MemberNotFoundError 0x800401e3 | OperationUnavailableError Finally, when a method results in any other error, a COM::MethodInvocationError will be raised, which can be queried for the specifics, specifically #message, #method, #server, #code, #hresult_code, and #hresult_message. ### Pathname ### The Pathname object receives an additional method, #to_com. This method is useful for when you want to pass a Pathname object to a COM method. Simply call #to_com to turn it into a String of the right encoding for COM: Word::Application.new.documents.open(Pathname('a.docx').to_com) # ⇒ Word::Document ## Installation ## Install COM with % gem install com ## License ## You may use, copy and redistribute this library under the same [terms][1] as Ruby itself. [1]: http://www.ruby-lang.org/en/LICENSE.txt ## Contributors ## * Nikolai Weibull

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

12,585

Releases

0.4.0

2011-10-14

2012-06-19

Activity

50%

2011-01-07

rubybreaker rockalizer/rubybreaker Homepage Documentation Source Code Bug Tracker Wiki

rubybreaker

0.0

Repository is archived

No commit activity in last 3 years

No release in over 3 years

RubyBreaker is a dynamic type documentation/checking tool for Ruby. It dynamically instruments code, monitors objects during execution, performs dynamic type checking, and generates type documentation based on the profiled information. RubyBreaker helps Ruby programs "break" out of obscurities and convolutions by auto-documenting type information.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

26,686

Releases

0.0.9

2012-05-10

2012-07-01

Activity

100%

2012-06-06

jsonrpc2 livelink/jsonrpc2 Homepage Documentation Source Code Bug Tracker Wiki

jsonrpc2

0.0

Low commit activity in last 3 years

No release in over a year

== Description A Rack compatible JSON-RPC2 server domain specific language (DSL) - allows JSONRPC APIs to be defined as mountable Rack applications with inline documentation, authentication and type checking. e.g. class Calculator < JSONRPC2::Interface title "JSON-RPC2 Calculator" introduction "This interface allows basic maths calculations via JSON-RPC2" auth_with JSONRPC2::BasicAuth.new({'user' => 'secretword'}) section 'Simple Ops' do desc 'Multiply two numbers' param 'a', 'Number', 'a' param 'b', 'Number', 'b' result 'Number', 'a * b' def mul args args['a'] * args['b'] end desc 'Add numbers' example "Calculate 1 + 1 = 2", :params => { 'a' => 1, 'b' => 1}, :result => 2 param 'a', 'Number', 'First number' param 'b', 'Number', 'Second number' optional 'c', 'Number', 'Third number' result 'Number', 'a + b + c' def sum args val = args['a'] + args['b'] val += args['c'] if args['c'] val end end end

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

43,022

Releases

0.3.0

2012-07-17

2023-02-10

Activity

100%

2018-09-26

jeckyl osburn-sharp/jeckyl Documentation Source Code Bug Tracker Wiki

jeckyl

0.0

No commit activity in last 3 years

No release in over 3 years

Create and manage configuration files in Ruby for Ruby. Jeckyl can be used to create a parameters hash from a simple config file written in Ruby, having run whatever checks you want on the file to ensure the values passed in are valid. All you need to do is define a class inheriting from Jeckyl, methods for each parameter, its default, whatever checking rules are appropriate and even a comment for generating templates etc. This is then used to parse a Ruby config file and create the parameters hash. Jeckyl comes complete with a utility to check a config file against a given class and to generate a default file for you to tailor. Type 'jeckyl readme' for more information.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

21,554

Releases

0.4.0

2012-09-20

2014-10-01

Activity

2012-06-07

licenses ryanscottlewis/licenses Homepage Documentation Source Code Bug Tracker Wiki

licenses

0.0

No commit activity in last 3 years

No release in over 3 years

# License Create software licenses easily. ## Install ### Bundler: `gem 'license'` ### RubyGems: `gem install license` ## Usage ### Simple ```ruby license = License::Software::MIT.new do |l| l.year.start = 2012 l.author.name = 'Ryan Scott Lewis' l.author.email = 'ryan@rynet.us' end p license.to_s # => "Copyright (c) 2012 Ryan Scott Lewis <ryan@rynet.us>\n\nPermission is hereby granted, free of charge..." ``` ### Multiple Authors ```ruby license = License::Software::MIT.new do |l| l.year.start = 2012 l.authors.add name: 'Ryan Scott Lewis', email: 'ryan@rynet.us' l.authors.add name: 'John Doe', email: 'john.doe@example.com' l.authors.add name: 'Snake Pliskin' l.authors.add 'John McClane <john@mcclain.org, jmcclane@gmail.com>' end p license.to_s # => "Copyright (c) 2012 Ryan Scott Lewis <ryan@rynet.us>, John Doe <john.doe@example.com>\n\nPermission is hereby granted, free of charge..." p license.authors.first.name # => 'Ryan Scott Lewis' p license.authors.first.email # => 'ryan@rynet.us' p license.authors.last.name # => 'John McClane' p license.authors.last.email # => 'john@mcclain.org' p license.authors.last.emails # => ['john@mcclain.org', 'jmcclane@gmail.com] ``` #### Smart Setters ```ruby license = License::Software.new do |l| l.type = License::Software::MIT # Set which type of license here instead l.year = '2006-2011' # Will set year.start to 2006 and year.end to 2011 l.authors = 'Ryan Scott Lewis<ryan@rynet>, John Doe < john.doe@example.com >' end p license.to_s # => "Copyright (c) 2012 Ryan Scott Lewis <ryan@rynet.us>, John Doe <john.doe@example.com>\n\nPermission is hereby granted, free of charge..." ``` #### Advanced usage (preferred method) ```ruby license = License::Software.new do # Do not pass block variables to enter the scope of the License::Software type MIT year 2012 author 'Ryan Scott Lewis <ryan@rynet.us>' end p license.to_s # => "Copyright (c) 2012 Ryan Scott Lewis <ryan@rynet.us>\n\nPermission is hereby granted, free of charge..." ``` ## Contributing * Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet * Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it * Fork the project * Start a feature/bugfix branch * Commit and push until you are happy with your contribution * Make sure to add tests for it. This is important so I don't break it in a future version unintentionally. * Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it. ## Copyright Copyright © 2012 Ryan Scott Lewis <ryan@rynet.us>. The MIT License (MIT) - See LICENSE for further details.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

4,085

Releases

0.0.1

2012-11-28

2012-11-28

Activity

2016-07-18

the_only_event_reporter_ever blairand/event_reporter_final Homepage Documentation Source Code Bug Tracker Wiki

the_only_event_reporter_ever

0.0

No commit activity in last 3 years

No release in over 3 years

# EventReporter EventReporter is a CSV parser and sorter. you can load a CSV and then search it. ## Installation $ gem install the_only_event_reporter_ever $ gem list event_reporter -d ## Usage After installation run: $ event_reporter Then Type 'load <filename>' to load records from a CSV $ Load event_attendees.csv Try these commands $ Find first_name sarah $Queue Print $Queue Save to <filename> ### Saving the queue accepts extensions JSON, XML, TXT, CSV. ## Contributing 1. Fork it 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create new Pull Request

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

6,352

Releases

0.0.2

2013-02-07

2013-02-07

Activity

2013-02-07

fat_fingers charliepark/fat_fingers Homepage Documentation Source Code Bug Tracker Wiki

fat_fingers

0.03

No release in over 3 years

Low commit activity in last 3 years

Makes sure users don't accidentally create an account for the wrong e-mail address. Because 'gmial' isn't actually what they meant to type. Similarly, 'yaho.com', or the strange-but-true '.c0m'. Not even making that one up. If you're concerned about false-positives, it's super-easy to check. There's only a single method. Also, it's fully-tested.

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019

2020

2021

2022

2023

2024

Popularity

120,160

Releases

0.1.35

2013-02-21

2020-10-01

Activity

100%

58%

2018-03-11