Week 48

Here are some highlights for leading into Week 48 🙂

  • “5-Hour Rule: If you’re not spending 5 hours per week learning, you’re being irresponsible” by Michael Simmons

    The value of knowledge isn’t static. It changes as a function of how valuable other people consider it and how rare it is. As new technologies mature and reshape industries, there is often a deficit of people with the needed skills, which creates the potential for high compensation. Because of the high compensation, more people are quickly trained, and the average compensation decreases.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    …when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    So the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e., that each task will take only as long as it “ought” to take. … The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    Oversimplifying outrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    I have earlier argued that the sheer number of minds to be coordinated affects the cost of the effort, for a major part of the cost is communication and correcting the ill effects of miscommunication (system debugging). This, too, suggests that one wants the system to be built by as few minds as possible.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    An ancient adage warns, “Never go to sea with two chronometers; take one or three.”

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    Programming productivity may be increased as much as five times when a suitable high-level language is used.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    How does a project get to be a year late? . . . . One day at a time.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    Two interesting studies of estimating behavior by government contractors on large-scale development projects show that:
    1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.
    2. During the activity, over estimates of duration come steadily down as the activity proceeds.
    3. Underestimates do not change significantly during the activity until about three weeks before the scheduled completion.

    Sharp milestones are in fact a service to the team, and one they can properly expect from a manager. The fuzzy milestone is the harder burden to live with. It is in fact a millstone that grinds down morale, for it deceives one about lost time until it is irremediable. And chronic schedule slippage is a morale-killer.

  • The Mythical Man-Month by Frederick P. Brooks Jr.

    Every user needs a prose description of the program. Most documentation fails in giving too little overview. The trees are described, the bark and leaves are commented, but there is no map of the forest. To write a useful prose description, stand way back and come in slowly:
    1. Purpose. What is the main function, the reason for the program?
    2. Environment. On what machines, hardware configurations, and operating system configurations will it run?
    3. Domain and range. What domain of input is valid? What range of output can legitimately appear?
    4. Functions realized and algorithms used. Precisely what does it do?
    5. Input-output formats, precise and complete.
    6. Operating instructions, including normal and abnormal ending behavior, as seen at the console and on the outputs.
    7. Options. What choices does the user have about functions? Exactly how are those choices specified?
    8. Running time. How long does it take to do a problem of specified size on a specified configuration?
    9. Accuracy and checking. How precise are the answers expected to be? What means of checking accuracy are incorporated?

  • Metaprogramming Ruby 2 by Paolo Perrotta

    Metaprogramming is writing code that manipulates language constructs at runtime.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    Ruby is a very metaprogramming-friendly language. It has no compile time at all, and most constructs in a Ruby program are available at runtime. You don’t come up against a brick wall dividing the code that you’re writing from the code that your computer executes when you run the program. There is just one world.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    You might argue that there are two types of Monkeypatches (Monkeypatch). Some happen by mistake, like the one that you and Bill experienced, and they’re invariably evil. Others are applied on purpose, and they’re quite useful—especially when you want to bend an existing library to your needs. … To minimize the dangers of Monkeypatches, carefully check the existing methods in a class before you define your own methods. Also, be aware that some changes are riskier than others. For example, adding a new method is usually safer than modifying an existing one.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    Let’s wrap it all up: an object’s instance variables live in the object itself, and an object’s methods live in the object’s class. That’s why objects of the same class share methods but don’t share instance variables.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    The superclass of Class is Module—which is to say, every class is also a module. To be precise, a class is a module with three additional instance methods (new, allocate, and superclass) that allow you to create objects or arrange classes into hierarchies.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    To put this differently, just as classes are nothing but objects, class names are nothing but constants.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    What’s an object? It’s a bunch of instance variables, plus a link to a class. The object’s methods don’t live in the object—they live in the object’s class, where they’re called the instance methods of the class. … What’s a class? It’s an object (an instance of Class), plus a list of instance methods and a link to a superclass. Class is a subclass of Module, so a class is also a module.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    …to find a method, Ruby goes in the receiver’s class, and from there it climbs the ancestors chain until it finds the method.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    You can take advantage of this mechanism yourself: if you add a method to Kernel, this Spell: Kernel Method will be available to all objects.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    There is one important reason to use define_method over the more familiar def keyword: define_method allows you to decide the name of the defined method at runtime.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    If you want a Blank Slate (Blank Slate), you can inherit directly from BasicObject instead.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    Blocks are just one member of a larger family of “callable objects,” which include objects such as procs and lambdas.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    You can’t run code in a vacuum. When code runs, it needs an environment: local variables, instance variables, self…. Because these entities are basically names bound to objects, you can call them the bindings for short. The main point about blocks is that they are all inclusive and come ready to run. They contain both the code and a set of bindings.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    There are exactly three places where a program leaves the previous scope behind and opens a new one:

    • Class definitions
    • Module definitions
    • Methods
  • Metaprogramming Ruby 2 by Paolo Perrotta

    There are two differences between procs and lambdas. One has to do with the return keyword, and the other concerns the checking of arguments. … The first difference between lambdas and procs is that the return keyword means different things. In a lambda, return just returns from the lambda … In a proc, return behaves differently. Rather than return from the proc, it returns from the scope where the proc itself was defined … The second difference between procs and lambdas concerns the way they check their arguments. … The short answer is that, in general, lambdas tend to be less tolerant than procs (and regular blocks) when it comes to arguments. Call a lambda with the wrong arity, and it fails with an ArgumentError. On the other hand, a proc fits the argument list to its own expectations

  • Metaprogramming Ruby 2 by Paolo Perrotta

    There is only one kind of object—be it a regular object or a module. There is only one kind of module—be it a regular module, a class, or a singleton class. There is only one kind of method, and it lives in a module—most often in a class. Every object, classes included, has its own “real class,” be it a regular class or a singleton class. Every class, with the exception of BasicObject, has exactly one ancestor—either a superclass or a module. This means you have a single chain of ancestors from any class up to BasicObject. The superclass of the singleton class of an object is the object’s class. The superclass of the singleton class of a class is the singleton class of the class’s superclass. (Try repeating that three times, fast. Then look back at Figure 7, Singleton classes and inheritance, and it will all make sense.) When you call a method, Ruby goes “right” in the receiver’s real class and then “up” the ancestors chain. That’s all there is to know about the way Ruby finds methods.

  • Metaprogramming Ruby 2 by Paolo Perrotta

    A Binding is a whole scope packaged as an object. The idea is that you can create a Binding to capture the local scope and carry it around. Later, you can execute code in that scope by using the Binding object in conjunction with eval. You can create a Binding with the Kernel#binding method

  • Metaprogramming Ruby 2 by Paolo Perrotta

    The lesson I personally learned from this story is: resist the temptation to be too clever in your code. Ask yourself whether there is a simpler way to reach your goal than metaprogramming. If the answer is no, then go forth and metaprogram the heck out of your problem. In many cases, however, you’ll find that a more straightforward OOP approach does the job just as well. … To sum it all up in a single sentence: keep your code as simple as possible, and add complexity as you need it.

Leave a Reply

Your email address will not be published. Required fields are marked *