The Require Method in Ruby

The Require Method in Ruby In order to create reusable components, ones that can be easily used in other programs, a programming language must have some way of smoothly importing that code at run-time. In Ruby, the require method is used to load another file and execute all its statements. This serves to import all class and method definitions in the file. In addition to simply executing all of the statements in the file, the require method also keeps track of which files have been previously required and, thus, will not require a file twice. Using the 'require' Method The require method takes the name of the file to require, as a string, as a single argument. This can either be a path to the file, such as ./lib/some_library.rb or a shortened name, such as some_library. If the argument is a path and complete filename, the require method will look there for the file. However, if the argument is a shortened name, the require method will search through a number of pre-defined directories on your system for that file. Using the shortened name is the most common way of using the require method. The following example demonstrates how to use the require statement. The file test_library.rb is in the first code block. This file prints a message and defines a new class. The second code block is the file test_program.rb. This file loads the test_library.rb file using the require method and creates a new TestClass object. puts test_library includedclass TestClassdef initializeputs TestClass object createdendend #!/usr/bin/env rubyrequire test_library.rbt TestClass.new Avoid Name Clashes When writing reusable components, its best not to declare many variables in the global scope outside any classes or methods or by using the $ prefix. This is to prevent something called namespace pollution. If you declare too many names, another program or library might declare the same name and cause a name clash. When two completely unrelated libraries start changing each others variables accidentally, things will break seemingly at random. This is a very difficult bug to track down and its best just to avoid it. To avoid name clashes, you can enclose everything in your library inside of a module statement. This will require people to refer to your classes and method by a fully qualified name such as MyLibrary::my_method, but its worth it since name clashes generally wont occur. For people who want to have all of your class and method names in the global scope, they can do that using the include statement. The following example repeats the previous example but encloses everything in a MyLibrary module. Two versions of my_program.rb are given; one that uses the include statement and one that does not. puts test_library includedmodule MyLibraryclass TestClassdef initializeputs TestClass object createdendendend #!/usr/bin/env rubyrequire test_library2.rbt MyLibrary::TestClass.new #!/usr/bin/env rubyrequire test_library2.rbinclude MyLibraryt TestClass.new Avoid Absolute Paths Because reusable components often get moved around, its also best not to use absolute paths in your require calls. An absolute path is a path like /home/user/code/library.rb. Youll notice that the file must be in that exact location in order to work. If the script is ever moved or your home directory ever changes, that require statement will stop working. Instead of absolute paths, its often common to create a ./lib directory in your Ruby programs directory. The ./lib directory is added to the $LOAD_PATH variable which stores the directories in which the require method searches for Ruby files. After that, if the file my_library.rb is stored in the lib directory, it can be loaded into your program with a simple require my_library statement. The following example is the same as the previous test_program.rb examples. However, it assumes the test_library.rb file is stored in the ./lib directory and loads it using the method described above. #!/usr/bin/env ruby$LOAD_PATH ./librequire test_library.rbt TestClass.new

How to write for non-accountants - Emphasis

How to write for non-accountants How to write for non-accountants Finance is a murky place for many people. Money comes into the bank account and it goes out again. And the process in between is something of a mystery. But even if your clients are financially savvy, it can still be difficult to explain money matters. Accounting has its own language and is often riddled with jargon that even experienced business people can sometimes find difficult to understand. (I know: Im one of them.) Writing financial information in accountingese can waste time and money. If your clients are unclear about what your figures mean, theyll ask for further clarification. A single document could lead to several hours of unnecessary (and frustrating) follow-up phone calls. Thats one reason why the tide is turning in the financial industry. Leading firms such as Deloitte, Ernst Young and Grant Thornton have commissioned specialist writing training programmes. And more accounting firms are following suit, adopting plain English in all their written communications. The other is that the Financial Services Authority keeps a watchful eye on adverts for financial products and services that are misleading. So as a finance professional, you still have to make sure your writing is not just legal, but effective. Here are six steps to clear client communication. One: put your reader first Many accountants overestimate the knowledge their clients have. Even if you have been working with a client for many years, theres no guarantee they really understand the nuances of finance. Get back to basics by asking yourself the following questions: What is the document about? Who will read it? How much do they already know about the subject? What do they absolutely need to know? How important is the subject to them? How interested are they in the subject? Use the answers as a guideline for the amount of detail that you need to include in your document. Two: avoid a mind-dump of ideas Whether youre writing an email, contract or report, do plenty of ground work before putting pen to paper. Brainstorm all your ideas using a mind map and then put your points in order of importance. If youre having trouble getting started, ask yourself the questions: Who? What? Where? When? and Why? Becoming clear in your thinking helps you to create clearly structured documents that are easy to follow. Three: communicate technical terms in plain English Financial abbreviations and other technical terms can be useful when communicating with colleagues but they can confuse clients. For example, the term accrual rate may seem simple but it still needs to be accompanied by an explanation of how the interest is built up. Similarly, never assume that your clients will understand terms such as smoothing, arbitration and cap and collar rate. You dont need to dumb down your writing, just make sure you provide clear, concise explanations. Four: avoid verbosity Often though its the words in between the jargon that cause the problem. Never add in redundant words into your writing. For example, I herein enclose details of your asset classes for the aforesaid investment, as requested sounds complicated, archaic and stilted. A much simpler way of writing it is, I enclose details of your investments, as requested. Five: opt for verbs instead of nouns Verbs help to give sentences movement and life. So write, We will decide on our next steps on Monday, rather than A decision will be made on our next steps on Monday. The word decide is more powerful than decision. And the first sentence is also written in the active voice, so it is punchier. Six: keep sentences short and sweet Aim for your sentences to be a maximum of 20 words. If you make your sentences longer, its likely your readers will have trouble making sense of what you mean. Remember, clear language makes sound business sense. It sends out the message that you have nothing to hide and that your words are as transparent as your financial dealings. Robert Ashton is the Chief Executive of Emphasis.