Electronic circuit boards are at the core of current and future inventions, from augmented reality to autonomous vehicles

Circuit Mind

circuitmind

I wrote previously about libs for error management in Rust. This week, I want to write about the try block, an experimental feature. The limit of the ? operator Please check the above article for a complete refresher on error management in general and the ? operator in particular. In short, ? allows it to hook into a function call that returns a Result: If the Result contains a value, it continues normally
If it contains an error, it short-circuits and returns the Result to the calling function. fn add(str1: &str, str2: &str) -> Result<i8, ParseIntError> {
  Ok(str1.parse::<i8>()? + str2.parse::<i8>()?)
}

fn main() {
    print!("{:?}", add("1", "2"));
    print!("{:?}", add("1", "a"));
} The output is the following: Ok(3)
Err(ParseIntError { kind: InvalidDigit }) Note that the defining function's signature must return a Result or an Option. The following block doesn't compile: fn add(str1: &str, str2: &str) -> i8 {
  str1.parse::<i8>()? + str2.parse::<i8>()?
} the `?` operator can only be used in a function that returns `Result` or `Option` The verbose alternative We must manually unwrap to return a non-wrapper type, e.g., i8 instead of Option<i8>. fn add(str1: &str, str2: &str) -> i8 {
  let int1 = str1.parse::<i8>();                  //1
  let int2 = str2.parse::<i8>();                  //1
  if int1.is_err() || int2.is_err() { -1 }        //2-3
  else { int1.unwrap() + int2.unwrap() }          //4
} Define Result variables


Manually checks if any of the variables contains an error, i.e., the parsing failed


Return a default value since we cannot get a Result. In this case, it's not a great idea, but it's for explanation's sake


Unwrap with confidence The try block to the rescue The sample above works but is quite lengthy. The try block is an experimental approach to make it more elegant. It allows "compacting" all the checks for errors in a single block: #![feature(try_blocks)]                           //1

fn add(str1: &str, str2: &str) -> i8 {
  let result = try {
    let int1 = str1.parse::<i8>();
    let int2 = str2.parse::<i8>();
    int1.unwrap()? + int2.unwrap()?               //2
  };
  if result.is_err() { -1 }                       //3
  else { result.unwrap() }                        //4
} Enable the experimental feature
Use the ? operator though the defining function doesn't return Result
Check for errors only once
Unwrap confidently Alas, the code doesn't compile: the `?` operator can only be applied to values that implement `Try` i8 doesn't implement Try. Neither i8 nor Try belong to our crate; a custom implementation would require the use of the wrapper-type pattern. Fortunately, a couple of types already implement Try: Result, Option, Poll, and ControlFlow. fn add(str1: &str, str2: &str) -> i8 {
  let result: Result<i8, ParseIntError> = try {   //1
    str1.parse::<i8>()? + str2.parse::<i8>()?     //2
  };
  if result.is_err() { -1 }
  else { result.unwrap() }
} The compiler cannot infer the type
Using ? on Result inside the try block is now allowed Conclusion I learned about the try block in Java over twenty years ago. Java needs it because exceptions are at the root of its error-handling system; Rust doesn't because it uses Functional Programming for its error handling - mainly Result. The ? operator builds upon the Result type to allow short-circuiting in functions that return Result themselves. If the function doesn't, you need a lot of boilerplate code. The experimental try block relieves some of it. To go further: Error management in Rust, and libs that support it
"The Rust Unstable Book: try_blocks"
The Rust RFC Book
Extending Rust's Effect System I wrote previously about libs for error management in Rust . This week, I want to write about the try block, an experimental feature. libs for error management in Rust try The limit of the ? operator ? Please check the above article for a complete refresher on error management in general and the ? operator in particular. In short, ? allows it to hook into a function call that returns a Result : ? ? Result If the Result contains a value, it continues normally If it contains an error, it short-circuits and returns the Result to the calling function. If the Result contains a value, it continues normally Result If it contains an error, it short-circuits and returns the Result to the calling function. Result fn add(str1: &str, str2: &str) -> Result<i8, ParseIntError> {
  Ok(str1.parse::<i8>()? + str2.parse::<i8>()?)
}

fn main() {
    print!("{:?}", add("1", "2"));
    print!("{:?}", add("1", "a"));
} fn add(str1: &str, str2: &str) -> Result<i8, ParseIntError> {
  Ok(str1.parse::<i8>()? + str2.parse::<i8>()?)
}

fn main() {
    print!("{:?}", add("1", "2"));
    print!("{:?}", add("1", "a"));
} The output is the following: Ok(3)
Err(ParseIntError { kind: InvalidDigit }) Ok(3)
Err(ParseIntError { kind: InvalidDigit }) Note that the defining function's signature must return a Result or an Option . The following block doesn't compile: must Result Option fn add(str1: &str, str2: &str) -> i8 {
  str1.parse::<i8>()? + str2.parse::<i8>()?
} fn add(str1: &str, str2: &str) -> i8 {
  str1.parse::<i8>()? + str2.parse::<i8>()?
} the `?` operator can only be used in a function that returns `Result` or `Option` the `?` operator can only be used in a function that returns `Result` or `Option` The verbose alternative We must manually unwrap to return a non-wrapper type, e.g. , i8 instead of Option<i8> . e.g. i8 Option<i8> fn add(str1: &str, str2: &str) -> i8 {
  let int1 = str1.parse::<i8>();                  //1
  let int2 = str2.parse::<i8>();                  //1
  if int1.is_err() || int2.is_err() { -1 }        //2-3
  else { int1.unwrap() + int2.unwrap() }          //4
} fn add(str1: &str, str2: &str) -> i8 {
  let int1 = str1.parse::<i8>();                  //1
  let int2 = str2.parse::<i8>();                  //1
  if int1.is_err() || int2.is_err() { -1 }        //2-3
  else { int1.unwrap() + int2.unwrap() }          //4
} Define Result variables Manually checks if any of the variables contains an error, i.e., the parsing failed Return a default value since we cannot get a Result. In this case, it's not a great idea, but it's for explanation's sake Unwrap with confidence Define Result variables Define Result variables Result Manually checks if any of the variables contains an error, i.e., the parsing failed Manually checks if any of the variables contains an error, i.e. , the parsing failed i.e. Return a default value since we cannot get a Result. In this case, it's not a great idea, but it's for explanation's sake Return a default value since we cannot get a Result . In this case, it's not a great idea, but it's for explanation's sake Result Unwrap with confidence Unwrap with confidence The try block to the rescue try The sample above works but is quite lengthy. The try block is an experimental approach to make it more elegant. It allows "compacting" all the checks for errors in a single block: try experimental #![feature(try_blocks)]                           //1

fn add(str1: &str, str2: &str) -> i8 {
  let result = try {
    let int1 = str1.parse::<i8>();
    let int2 = str2.parse::<i8>();
    int1.unwrap()? + int2.unwrap()?               //2
  };
  if result.is_err() { -1 }                       //3
  else { result.unwrap() }                        //4
} #![feature(try_blocks)]                           //1

fn add(str1: &str, str2: &str) -> i8 {
  let result = try {
    let int1 = str1.parse::<i8>();
    let int2 = str2.parse::<i8>();
    int1.unwrap()? + int2.unwrap()?               //2
  };
  if result.is_err() { -1 }                       //3
  else { result.unwrap() }                        //4
} Enable the experimental feature Use the ? operator though the defining function doesn't return Result Check for errors only once Unwrap confidently Enable the experimental feature Use the ? operator though the defining function doesn't return Result ? Result Check for errors only once Unwrap confidently Alas, the code doesn't compile: the `?` operator can only be applied to values that implement `Try` the `?` operator can only be applied to values that implement `Try` i8 doesn't implement Try . Neither i8 nor Try belong to our crate; a custom implementation would require the use of the wrapper-type pattern. Fortunately, a couple of types already implement Try : Result , Option , Poll , and ControlFlow . i8 Try i8 Try Try Result Option Poll ControlFlow fn add(str1: &str, str2: &str) -> i8 {
  let result: Result<i8, ParseIntError> = try {   //1
    str1.parse::<i8>()? + str2.parse::<i8>()?     //2
  };
  if result.is_err() { -1 }
  else { result.unwrap() }
} fn add(str1: &str, str2: &str) -> i8 {
  let result: Result<i8, ParseIntError> = try {   //1
    str1.parse::<i8>()? + str2.parse::<i8>()?     //2
  };
  if result.is_err() { -1 }
  else { result.unwrap() }
} The compiler cannot infer the type Using ? on Result inside the try block is now allowed The compiler cannot infer the type Using ? on Result inside the try block is now allowed ? Result try Conclusion I learned about the try block in Java over twenty years ago. Java needs it because exceptions are at the root of its error-handling system; Rust doesn't because it uses Functional Programming for its error handling - mainly Result . try Result The ? operator builds upon the Result type to allow short-circuiting in functions that return Result themselves. If the function doesn't, you need a lot of boilerplate code. The experimental try block relieves some of it. ? Result Result try To go further: To go further: Error management in Rust, and libs that support it "The Rust Unstable Book: try_blocks" The Rust RFC Book Extending Rust's Effect System Error management in Rust, and libs that support it Error management in Rust, and libs that support it "The Rust Unstable Book: try_blocks" "The Rust Unstable Book: try_blocks" The Rust RFC Book The Rust RFC Book Extending Rust's Effect System Extending Rust's Effect System

The Try Block in Rust: Streamlining Error Management Beyond the '?' Operator

People who work with or on industrial batteries face unique hazards every day. Here are the most critical safety concerns and practices for dealing with them and protecting workers. 1. Hazardous Dusts Chemical fumes and powder get into the air during manufacturing. Usually, workers wear personal protection equipment (PPE) like masks and goggles to keep from breathing or ingesting hazardous materials. However, it’s not uncommon for people to skip wearing their PPE. Exposure to lead dust and the top source of work-related lead absorption. Unfortunately, it can quickly cause severe organ, nerve, and blood vessel damage. is the biggest health hazard Workers should always use their PPE when near hazardous chemicals to protect themselves. On top of wearing masks, they need goggles and gloves to minimize indirect contact. Could you imagine avoiding breathing in lead dust all day only to rub your eyes with a contaminated hand after work? 2. Sudden Explosions Have you seen those videos of smartphone batteries randomly blowing up? They generate heat when they charge or discharge, and overheating can lead to an explosion. Usually, electrical abuse — overcharging, rapid charging, or short-circuiting — is the cause. Also, many batteries produce flammable byproducts. Any spark or heat source could set off an explosion if too much fills an enclosed space. To make matters worse, commonly used gases like hydrogen are colorless, odorless, and tasteless — undetectable by human senses. Safety practices include following charging protocol, ventilating rooms, and using hydrogen detection systems. You can avoid most explosions if you prevent overheating and monitor the level of flammable gases. However, you’re still at risk even if you follow the manufacturer’s recommendations. Since , there’s always a chance one will happen. This possibility is one of the reasons inspections are a standard safety practice. Routinely checking for flaws can protect you from random battery detonation. faulty cells can cause sudden explosions 3. Corrosive Materials Many industrial batteries contain corrosive materials. For example, the flooded lead-acid variety can leak sulfuric acid, a chemical that burns through the skin. This type needs to be topped up with distilled water, meaning workers come into close contact with it regularly. Refilling it before or during charging could cause the acid mixture to boil over. Corrosive materials can also escape because of mechanical abuse. In other words, physical mishandling — dropping, denting, or otherwise damaging an industrial battery — can cause it to leak. In these cases, the person who breaks it should immediately report the issue to prevent others from getting injured. You must wear proper PPE whenever you’re close to a corrosive material. In the case of a flooded lead-acid battery, you’d need gloves, goggles, boots, and an apron. However, these are just precautionary measures. Prevent highly toxic liquid from leaking by following the manufacturer’s charging and handling recommendations. Eye-washing stations and safety showers should be nearby if someone comes into contact with a corrosive or toxic liquid. Considering the damage acid can do, it’s also best to have special first-aid equipment. 4. Fast-Growing Fires Overcharging or improper charging can cause thermal runaway — an uncontrollable temperature increase. Since , they’re at risk of suddenly bursting into flames. intense heat damages batteries Battery fires grow quickly and are challenging to put out, so most safety practices are preventive. There are still safety practices left to follow when the fire’s out. If you don’t address the root cause of thermal runaway, there’s a chance the industrial battery will reignite. Disconnecting it from its power source and quarantining it can prevent it from bursting into flames again. At the very least, it’ll keep the fire from spreading. 5. Electrocution and Shock Electrocution is a significant safety concern for people working on or near industrial batteries. Although it isn’t as standard — or deadly — as explosions, acid leaks, and toxic gases, there are still safety standards workers must follow. For one, they should keep metal away during charging, which includes jewelry. Additionally, they shouldn’t touch the positive and negative terminals simultaneously. The possibility of electrocution increases substantially during a fire. Stranded energy — the unknown amount of power left over — means workers can’t safely discharge the battery without posing a shock hazard. While it’s a serious risk, for it. there are no standard safety practices For now, first responders take the lead, and everyone else stays a reasonable distance away. 6. Highly Toxic Gases Batteries often produce highly toxic gases during charging and discharging. For example, lead-acid varieties can produce arsenic hydride — which — while connected to power sources. This particular chemical is extremely dangerous. Militaries have even used it as a weapon because it causes symptoms similar to poisoning. is colorless and flammable Other common toxic gases include hydrogen, methane, carbon monoxide, and carbon dioxide. They can be harmful or deadly in high concentrations. Usually, they remain at very low levels unless there’s a leak. The best safety practices include using gas detection systems, following the manufacturer’s charging recommendations, and routinely inspecting the battery. Address Safety Concerns With Standard Practices No one wants to deal with acid leaks and explosions at work. Anyone working with or on industrial batteries must keep safety practices in mind to protect themselves and their colleagues.

Exploring the Safety Concerns of Industrial Battery Use

MAGNETISM IN ITS RELATION TO INDUCED ELECTROMOTIVE FORCE AND CURRENT

Things To Make by Archibald Williams is part of the HackerNoon Books Series. You can jump to any chapter in this book . A MODEL ELECTRIC RAILWAY. here XIII. A MODEL ELECTRIC RAILWAY. The rapid increase in the number of electrically worked railways, and the substitution of the electric for the steam locomotive on many lines, give legitimate cause for wondering whether, twenty or so years hence, the descendants of the “Rocket” will not have disappeared from all the railways of the world, excepting perhaps those of transcontinental character. [Illustration: Fig. 41.—Electric Locomotive.] The change is already spreading to model plant, and not without good reason, as the miniature electric railway possesses decided advantages of its own. Instead of having to chase the locomotive to stop or reverse it, one merely has to press a button or move a switch. The fascinations of a model steam locomotive, with its furnace, hissing of steam, business-like puffings, and a visible working of piston and connecting rods, are not to be denied, any more than that a full-sized steam locomotive is a more imposing object at rest or in motion than its electric rival. On the other hand, the ease of control already noticed, and the absence of burning fuel, water leakage, smoke and fumes, are strong points in favour of the electric track, which does no more harm to a carpet than to a front lawn, being essentially clean to handle. Under the head of cost the electric locomotive comes out well, as motors can be purchased cheaply; and connecting them up with driving wheels is a much less troublesome business than the construction of an equally efficient steamer. One may add that the electric motor is ready to start at a moment’s notice: there is no delay corresponding to that caused by the raising of steam. The Track We will consider this first, as its design must govern, within certain limits, the design of the locomotive. There are three systems of electrical transmission available. That in which one of the wheel rails is used for taking the current to the motor, and the other as the return. The objection to the system is that the wheels must be insulated, to prevent short circuiting; and this, besides causing trouble in construction, makes it impossible to use the ordinary model rolling stock. To its credit one may place the fact that only two rails are needed. The third and, we think, best system, which has an insulated third rail as one half of the circuit, and both wheel rails as the return, the motor being kept in connection with the third rail by means of a collector projecting from the frame and pressing against the top of the third rail. The last, for reasons of convenience, is placed between the wheel rails. We will assume that this system is to be employed. [Illustration: FIG. 42.—Details of rails for electric track.] Gauge.—For indoor and short tracks generally it is advisable to keep the gauge narrow, so that sharp curves may be employed without causing undue friction between rails and wheels. In the present instance we specify a 2-inch gauge, for which, as also for 1-1/2 and 1-1/4 inch, standard rolling stock is supplied by the manufacturers. Track Construction.—It is essential that the centre rail and at least one of the wheel rails shall have all joints bonded together to give a clear course to the electric current, and the centre rail must be insulated to prevent leakage and short-circuiting. Where a track is laid down more or less permanently, the bonding is most positively effected by means of little fish-plates, screwed into the sides of the abutting rails; but in the case of a track which must be capable of quick coupling-up and uncoupling, some such arrangement as that shown in Fig. 42 is to be recommended. Fig. 42 (a) is a cross vertical section of the track; Fig. 42 (c) a longitudinal view; while Fig. 42 (b) shows in plan a point of junction of two lengths of rail. The wheel rails are made of carefully straightened brass strip 3/8 inch wide and 1/16 inch thick, sunk rather more than 1/8 inch into wooden sleepers (Fig. 42, a), 3-1/2 inches long and 3/4 inch wide (except at junctions). The sleepers are prepared most quickly by cutting out a strip of wood 3-1/2 inches wide in the direction of the grain, and long enough to make half a dozen sleepers. Two saw cuts are sunk into the top, 2 inches apart, reckoning from the inside edges, to the proper depth, and the wood is then subdivided along the grain. The saw used should make a cut slightly narrower than the strip, to give the wood a good hold. If the cut is unavoidably too large, packings of tin strip must be forced in with the rail on the outside. To secure the rails further, holes are bored in them on each side of the sleeper (see Fig. 42, c), and fine iron or, brass wire is passed through these, round the bottom of the sleeper, and made fast. [Illustration: FIG. 43.—Tin chair for centre rail of electric track.] The centre rail is soldered to small tin chairs, the feet of which are pinned down to the sleepers. The top of the rails must project slightly above the chairs, so that the current collector may not be fouled. Junctions.—At these points one 3/4-inch sleeper is reduced to 1/2-inch width, and the other increased to 1 inch, this sleeper being overlapped 3/8 inch by the rails of the other section. To the outsides of the wheel rails are soldered the little angle plates, AA, BB, attached to the sleepers by brass tacks, which project sufficiently to take the brass wire hooks. These hooks must be of the right length to pull upon the tacks in AA and make a good contact. The centre rails are bonded by two strips of springy brass, riveted to one section, and forced apart at their free end by the interposed strip. Two pins projecting from the narrower sleeper fit into holes in the wider to keep the sections in line at a junction. General.—The sleepers of straight sections are screwed down to 3/4 by 1/4 inch longitudinals, which help to keep the track straight and prevent the sleepers slipping. Sections should be of the same length and be interchangeable. Make straight sections of the greatest convenient length, to reduce the number of junctions. Sleepers need not be less than 6 inches apart. Fix the sleepers on the longitudinals before hammering the rails into the slots. [Illustration: FIG. 44.—Laying out a curve for electric track.] Curves.—A simple method of laying out a semi-circular curve is shown in Fig. 44. Sleepers and longitudinals are replaced by 1/2-inch boards, 8 inches wide. Three pieces, about 32 inches long each, have their ends bevelled off at an angle of 60 degrees, and are laid with their ends touching. Two semi-circles of 24 and 22 inch radius are drawn on the boards to indicate the positions of the rails, and short decapitated brass nails are driven in on each side of a rail, about an inch apart, as it is laid along one of these lines. (See Fig. 44. A.) The inside nails must not project sufficiently to catch the wheel flanges. The spring of the brass will prevent the rail falling out of place, but to make sure, it should be tied in with wire at a few points. The centre rail should on the curves also be 3/8 inch deep, and raised slightly above the bed so as to project above the wheel rails. The method already described of bonding at joints will serve equally well on curves. If the outer rail is super-elevated slightly, there will be less tendency for the rolling stock to jump the track when rounding the curve. When the rails are in place the boards may be cut with a pad-saw to curves corresponding with the breadth of the track on the straight. If the boards incline to warp, screw some pieces of 1/8-inch strip iron to the under side across the grain, sinking the iron in flush with the wood. The brass strip for the rails costs about one penny per foot run. Iron strip is much cheaper, but if it rusts, as it is very likely to do, the contact places will need constant brightening. Points.—Fig. 45 shows the manner of laying out a set of points, and connecting up the rails. The outside wheel rails, it will be seen, are continuous, and switching is effected by altering the position of the moving tongues, pivoted at PP, by means of the rod R, which passes through a hole in the continuous rail to a lever or motor of the same reversible type as is used for the locomotive. If a motor is employed, R should be joined to a crank pin on the large driven cog—corresponding to that affixed to the driving wheel (Fig. 47)—by a short rod. The pin is situated at such a distance from the axle of the cog wheel that a quarter of a revolution suffices to move the points over. The points motor must, of course, have its separate connections with the “central station.” To show how the points lie, the rod R also operates a semaphore with a double arm (Fig. 46), one end of which is depressed—indicating that the track on that side is open—when the other is horizontal, indicating “blocked.” The arms point across the track. [Illustration: FIG. 45.—Points for electric railway.] Details.—The tongues must be bevelled off to a point on the sides respectively nearest to the continuous rails. The parts AA are bent out at the ends to make guides, which, in combination with the safety rails, will prevent the wheels jumping the track. Care should be taken to insulate centre rail connecting wires where they pass through or under the wheel rails. It is advisable to lay out a set of points, together with motor and signals, on a separate board. [Illustration: Fig. 46.—Double-armed signal, operated by points.] Preservation of Track.—All the wooden parts of an outdoor track should be well creosoted before use. The Electric Locomotive. An elevation and a plan of this are given in Fig. 47. The two pairs of wheels are set close together, so that they may pass easily round curves. [Illustration: Fig. 47.—Plan and elevation of electric locomotive.] The Motor.—A motor of ordinary type, with electro field magnets, is unsuitable for traction, as it cannot be reversed by changing the direction of the current, unless a special and rather expensive type of automatic switch be used. While a motor of this kind is, in conjunction with such a switch, the most efficient, the motor with permanent field magnets is preferable as regards cost and ease of fixing. It can be reversed through the rails. The armature or revolving part must be tripolar to be self-starting in all positions. A motor of sufficient power can be bought for half a crown or less—in any case more cheaply than it can be made by the average amateur. The motor used for the locomotive illustrated was taken to pieces, and the magnet M screwed to a strip of wood 1-5/8 inches wide; and for the original armature bearings were substituted a couple of pieces of brass strip, HH, screwed to two wooden supports, SS, on the base, E (Fig. 47, a). It was found necessary to push the armature along the spindle close to the commutator piece, C, and to shorten the spindle at the armature end and turn it down to the size of the original bearing, in order to bring the motor within the space between the wheels. The place of the small pulley was taken by an 8-toothed pinion wheel, engaging with a pinion soldered to the near driving wheel, the diameter of which it exceeded by about 3/16 inch. The pair, originally parts of an old clock purchased for a few pence, gave a gearing-down of about 9 times. The position of the driven wheels relatively to the armature must be found experimentally. There is plenty of scope for adjustment, as the wheels can be shifted in either direction longitudinally, while the distance between wheel and armature centres may be further modified in the length of the bearings, BE. These last are pieces of brass strip turned up at the ends, and bored for axles, and screwed to the under side of the base. To prevent the axles sliding sideways and the wheels rubbing the frame, solder small collars to them in contact with the inner side of the bearings. The Frame.—Having got the motor wheels adjusted, shorten E so that it projects 2 inches beyond the centres of the axles at each end. Two cross bars, GG, 3-1/2 inches long, are then glued to the under side of E, projecting 1/8 inch. To these are glued two 3/8-inch strips, FF, of the same length as E. A buffer beam, K, is screwed to G. A removable cover, abedfg, is made out of cigar-box wood or tin. The ends rest on GG; the sides on FF. Doors and windows are cut out, and handrails, etc., added to make the locomotive suggest the real thing—except for the proportionate size and arrangement of the wheels. Electrical Connections.—The current collector, CR, should be well turned up at the end, so as not to catch on the centre rail joints, and not press hard enough on the rail to cause noticeable resistance. The fixed end of CR is connected through T2 with one brush, B, and both wheel bearings with T1. [Illustration: FIG. 48.—Reversing switch.] Electrical Fittings.—The best source of power to use is dry cells giving 1-1/2 to 2 volts each. These can be bought at 1s. apiece in fairly large sizes. Four or five connected in series will work quite a long line if the contacts are in good condition. A reversing switch is needed to alter the direction of the current flow. The construction of one is an exceedingly simple matter. Fig. 48 gives a plan of switch and connection, from which the principle of the apparatus will be gathered. The two links, LL, are thin springy brass strips slightly curved, and at the rear end pivoted on the binding posts T1 T2. Underneath the other ends solder the heads of a couple of brass nails. The links are held parallel to one another by a wooden yoke, from the centre of which projects a handle. The three contacts C1 C2 C3 must be the same distance apart as the centres of the link heads, and so situated as to lie on the arcs of circles described by the links. The binding post T3 is connected with the two outside contacts—which may be flat-headed brass nails driven in almost flush with the top of the wooden base—by wires lying in grooves under the base, and T4 with the central contact. As shown, the switch is in the neutral position and the circuit broken. [Illustration: Fig. 49.—Multiple battery switch.] Multiple Battery Switch.—To control the speed of the train and economize current a multiple battery switch is useful. Fig. 49 explains how to make and connect up such a switch. The contacts, C1 to C5, lie in the path of the switch lever, and are connected through binding posts T1 to T6 with one terminal of their respective cells. The cells are coupled up in series to one another, and one terminal of the series with binding posts T0 and T6. By moving the lever, any number of the cells can be put in circuit with T7. The button under the head of the lever should not be wide enough to bridge the space between any two contacts. Change the order of the cells occasionally to equalize the exhaustion. [Illustration: FIG. 50.—Adjustable resistance for controlling current.] Resistance.—With accumulators, a “resistance” should be included in the circuit to regulate the flow of current. The resistance shown in Fig. 50 consists of a spiral of fine German silver wire lying in the grooved circumference of a wood disc. One of the binding posts is in connection with the regulating lever pivot, the other with one end of the coil. By moving the lever along the coil the amount of German silver wire, which offers resistance to the current, is altered. When starting the motor use as little current as possible, and open the resistance as it gets up speed, choking down again when the necessary speed is attained. General.—All the three fittings described should for convenience be mounted on the same board, which itself may form the cover of the box holding the dry cells or accumulators. SOME SUGGESTIONS. Instead of dry cells or accumulators a small foot or hand operated dynamo generating direct, not alternating current, might be used. Its life is indefinitely long, whereas dry cells become exhausted with use, and accumulators need recharging from time to time. On occasion such a dynamo might prove very convenient. Anyone who possesses a fair-sized stationary engine and boiler might increase the realism of the outdoor track by setting up a generating station, which will give a good deal of extra fun. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Archibald Williams (2005). Things To Make. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/14664/pg14664-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

A MODEL ELECTRIC RAILWAY.

of this series of articles, we looked at more common mistakes in functions and methods composition. In this article, we will focus on writing code that will be readable by a human-like book. We will consider best practices in naming, code composition, and . These practices will prevent developers from wasting time in debugging and maintaining code. In Part 1 code optimization Table of contents Naming Destructuring assignment a. Binding pattern b. Assignment pattern Template literals for string concatenations Function parameters Optional changing instead of a promise chain Async await Conditionals 1. Naming Use meaningful and pronounceable names of variables // Bad
const yyyymmdd = moment().format("YYYY/MM/DD");

// Better
const currentDate = moment().format("YYYY/MM/DD"); Use the same style naming for the same type of variables or functions // Bad
getProductInfo();
getFoodData();
setGroceriesUpdate();

// Better
getProductInfo();
getProductData();
setProductUpdate(); In this example, we have a set of functions working with the same logical level of data. To focus on this, we need to follow one naming pattern get/setProduct… Use searchable names // Bad
buildHeadlinesList(documents: Doc[], 5) {/.../}

// Better
const HEADLINES_COUNT = 5;
buildHeadlinesList(documents, HEADLINES_COUNT); In this example, we have a magic number in arguments. But for clear code, we need to create a constant with a meaningful name. It will give an understanding of what we are doing in function. 5 2. Destructuring assignment The syntax makes it possible to assign values from arrays or properties from objects into distinct variables. With this approach, we make our code compact and reduce needless computations. destructuring assignment There are two patterns in destructuring assignments: and . Let’s take a look at both of them. binding pattern assignment pattern a. Binding pattern The binding destructuring pattern starts with the declaration keyword . Then, each individual property must either be bound to a variable or further destructured. var, let, const Binding patterns could be realized in the following ways: Simple variable assignment const product = { name: "Lemon", count: 200, country: "Portugal" };

// Bad
 const name = product.name;
 const count = product.count;
 const country = product.country;

// Better
const { name, count, country } = product; Looping variable in for...in for...of and for await...of loops var users = [
   { user: "Alex", bio: { age: 35, country: "Poland" }, phone: "700-12-13" },
   { user: "Mike", bio: { age: 21, country: "France" } },
 ];

for (let { user, phone = "DEFAULT VALUE", bio: { age, country } } of users) {
  console.log(user, phone, age, country);
} In this example, we are destructuring an object with nested destructuring in loop to top up all values on one level and define if the key is missed in the target object or has value (if it is default value will not be assigned). for of "DEFAULT VALUE" undefined null Function parameters interface Product {
  name: string, 
  count: number, 
  country: string,
}

const product: Product = { name: "Lemon", count: 200, country: "Portugal" };

// Bad
function analyzeProducts(product: Product): void {
  const name = product.name;
  const count = product.count;
  const country = product.country;
  // ...
}

// Better
function analyzeProducts(product: Product): void {
  const { name, count, country } = product;
  // ...
}

analyzeProducts(product); The catch binding variable try {
  throw new TypeError("Something went wrong");
} catch ({ name, message }) {
  console.log(name); // "TypeError"
  console.log(message); // "Something went wrong"
} b. Assignment pattern In the assignment pattern, there are no keywords . Each deconstructed property gets assigned to a target in the assignment. This target can be pre-declared using , or it can be a property of another object — essentially, anything permissible on the left side of an assignment expression. var, let, const var, let, const const users = [];
const objUsers = { a: "Alex", b: "Mark" };
({ a: users[0], b: users[1] } = objUsers); // ['Alex', 'Mark'] 3. Template literals for string concatenations The template literals offer brevity, cleanliness, and support for multiline strings. // Bad
const helloMessage = “Hi ” + name + “, today is “ + currentDay;

// Better 
const helloMessage = `Hi ${name}, today is ${currentDay}`; 4. Function parameters Avoid one-letter parameters even in callbacks. // Bad
array.forEach((n) => { /.../ });

// Better
array.forEach((node) => {  /.../ }); Use default parameters instead of short-circuiting or conditionals // Bad
function createBlock(name: string, lines?: number): string {
  const linesAmount = lines || 8;
  // logic
}

// Better
function createBlock(name: string, lines = 8): string {
  // logic
} 5. Optional changing In cases when we need to merge some objects, update some fields, or leave the old ones if they were not updated, it will be good practice to use operator or instead of conditions. spread Object.assign() const user = {
  name: 'Alex',
  email: "user@gmail.com",
  organisation: "XXX",
  secondPhone: 56459544,
  country: "Poland"
}

const updatedUserData = {
  email: "newmail@gmail.com",
  organisation: "ZZZ",
}

// Bad
const updatedUser = {
  name: updatedUserData.name || user.name,
  email: updatedUserData.name || user.email,
  organisation: updatedUserData.organisation || user.organisation,
  secondPhone: updatedUserData.secondPhone || user.secondPhone,
  country: updatedUserData.country || user.country
}

// Better, 1 option
const updatedUser = { ...user, ...updatedUserData };

// Better, 2 option 
const updatedUser = Object.assign(user, updatedUserData); 6. Async await instead of the promise chain When you have a set of chained promises, it would be a good practice to use to make code readable. async await // Bad
analyzeProducts(products: string[]): Promise<AnalyzedProduct[]> {
    return this.productService.analyze(this.buildQueryParam(products))
      .then((products: Product[]) => {
          requestIds(products)
            .then((products: AnalyzedProduct[]) => mapProducts(products));
            .catch((error: ) => {
                notifyUser(error)
            })
      })
}

// Better
async analyzeProducts(products: string[]): Promise<AnalyzedProduct[]> {
  try {
    const analyzedProducts = await this.productService.analyze(this.buildQueryParam(products));
    const productsWithIds = await this.productService.requestIds(products);
    return mapProducts(productsWithIds));
  } catch(error) {
     notifyUser(error)
  }
} 7. Conditionals Encapsulate conditionals // Bad
if (token.category === Token.Operator && isFirstToken && !token.disabled) {
  // ...
}

// Better
function showToken(token: Token, model: Model<Token>): boolean {
  return (token.category === Token.Operator && model.length && !token.disabled)
}

if (showToken(token, model)) {
  // ...
} Avoid negative conditionals For readability, it is recommended to use affirmative conditions rather than negative ones. // Bad
if (!tokenIsNotHidden(node)) { 
  /.../ 
}

// Better
if (tokenIsHidden(node)) { 
  /.../ 
} Conclusion In this article, we considered the best practices for code readability. In the next article, we will take a look at code smells in Classes, Objects, and Data Structures and the ways it could improved.

Clean Code: Naming and Code Composition in TypeScript [Part 2]

Erotic Symbolism

The Real C++ Killers (Not You, Rust)

দ্য রিয়েল সি++ কিলার (তুমি নয়, মরিচা)

Die wahren C++-Killer (Nicht du, Rust)

Los verdaderos asesinos de C++ (no tú, Rust)

Les vrais tueurs C++ (pas vous, Rust)

द रियल सी++ किलर (नॉट यू, रस्ट)

真の C++ キラー (Not You, Rust)

진짜 C++ 킬러(당신이 아니라 Rust)

Os verdadeiros assassinos de C++ (não você, Rust)

Gerçek C++ Katilleri (Sen Değil, Rust)

Kẻ giết C ++ thực sự (Không phải bạn, Rust)

真正的 C++ 杀手（不是你，Rust）

What is Event Driven Architecture? Serverless streaming architecture is modeled after event-driven microservice architecture, where each microservice is connected to one another using a message bus. Event-driven architecture inherently provides all the capabilities we need from a streaming solution. By overlaying managed services provided by cloud providers with an event-driven architecture, one can build a serverless streaming solution. If you can map the above pattern with managed services like AWS Lambda as a microservice and AWS Kinesis as a message bus, you can achieve the event-driven architecture using the serverless stacks. Error Handling Strategies In this Architecture, one of the critical architecture patterns to think of is how you handle the runtime Error handling is very critical. Error handling is an important aspect of any system, but it becomes especially crucial in event-driven architectures. This type of architecture relies on events and their corresponding handlers to process data and trigger actions. If an error occurs in one of these handlers, it can disrupt the entire system. This pattern handles millions of messages and processes them every second. This means there are chances of different kinds of runtime errors in this pattern and not handling these errors can turn into critical system failure. In event-driven architecture, events are generated by various sources, such as user actions, system notifications, or external APIs. These events are typically delivered to a queue or broker, where they are stored until the appropriate event handler can process them. Event handlers are responsible for responding to events and triggering the appropriate actions. For example, if a user clicks a button on a website, an event is generated and sent to the queue. The event handler for that button might trigger an API call, update a database, or send an email. When an error occurs in one of these event handlers, it can have cascading effects on the entire system. If the error is not properly handled, it can cause subsequent events to fail, resulting in a domino effect of errors. This is why error handling is so important in event-driven architecture. There are several strategies for handling errors in event-driven architecture. One common approach is to use a circuit breaker pattern, where the system monitors the health of event handlers and automatically stops sending events to handlers that are failing. This can prevent the domino effect of errors and allow the system to continue functioning, even if some event handlers are failing. Another strategy is to use retries and backoff. In this approach, the system automatically retries failed events a certain number of times, with increasing intervals between retries. This can help to recover from transient errors, such as network connectivity issues, which might resolve themselves after a short delay. Error logging is also important in event-driven architecture. Detailed logs can help to diagnose and troubleshoot errors and can provide valuable information for improving the system. The nature of the Event Driven architecture is more stateless and microservices are simply good at doing one thing, so when you think about Error handling in the Event Driven Architecture, you need to think about whether the given message should be retried or not. Let’s talk about some of the techniques mentioned above in more detail. Retriable Errors Retriable Errors can be handled based on which level that error is happening. For Example, If the Error is happening due to a System issue like a network error or some API error then you might want to keep trying to resolve it before you take the next event. The reasoning behind this is, if you drop the event or put it into the queue for later processing then there is a high chance that the same kind of error could happen for all the next events and your application will fail in the domino manor. However, if you keep retiring from this event and not taking the next event then at least you are not losing the event until it’s fixed. In the System-level retriable error mentioned above, you must be very thoughtful otherwise you will block the entire system. For Example: if you keep retrying the event for which the error is specific to that event like an invalid request then you don’t want to retry it and drop that event. For Above mentioned Errors, which are more the Event specific. You might want to try the Backoff Error handling. In backoff Error handling, you may send the event at the end of the Queue and can try it a configured number of times before discarding the event. Circuit breaker pattern Think about the Circuit Breaker pattern as the Fast Fail functionality, where let’s say your application is failing for one of the messages then you might want to break the system for that event and send it to the separate Queue also known as the Dead letter queue. Dead later Queue can be thought of as the parking lot where you can retry or investigate the failing event. This kind of event can mostly happen due to the issue in the event format itself, so it often needs manual intervention. A circuit breaker can be in one of three states: Closed: The remote service is working as expected. No short-circuiting is required. Open: Remote service not responding as expected, down, or frozen. All requests are short-circuited. This state is achieved only when a specified number of failures have occurred. Half Open: Records the number of successful attempts to invoke the remote calls. This helps in checking if the remote server is back online and working as expected. Conclusion Overall, error handling is essential for maintaining the reliability and stability of event-driven architecture. By using strategies such as circuit breakers, retries, and logging, it is possible to prevent errors from disrupting the system and ensure that it continues to function smoothly.

Error Handling Strategies for Serverless Event-Driven Architecture

A friend of mine shared with me the other day about CVE-2022-43412. The issue disclosed in that CVE is that Jenkins Generic Webhook Trigger Plugin was using a non-constant time comparison function when checking whether the provided and expected webhook tokens are equal. this link In addition to the aforementioned CVE, there's also CVE-2022-43411 which is the same issue but with the Jenkins Gitlab plugin. In this blog post, we will explain how the attack works, how to avoid similar problems, and what we do at Svix to protect our customers. What Is the Issue? The issue described in this CVE uses a timing-based side channel to execute an oracle attack against the hash verification. Or in more plain words: this attack uses the fact that the comparison may take different times based on the content, to construct a valid signature even without knowing the key. I know this may sound a bit like magic because it kinda is. Though let's demystify it by using a more simple example, and go from there. What's a Timing-Based Oracle Attack? Let's assume it's not a webhook, but rather a website, and the website is password protect. The developer who built this website is new to security, so they implemented the security as follows: const password = 'Secret123'
if (user_provided_password != password) {
  return 'Wrong password!'
} Now, let's take a deeper look at the comparison in the condition. Because we used a high-level function, we can just use between strings, but what goes on behind the scenes is that it actually compares them character by character (well, it's actually more complex than that, but let's assume that for simplicity). != So, a naive implementation may look like this: // This function assumes the strings are the same length for simplicity
function is_equal(a, b) {
    for (let i = 0; i < a.length; i++) {
        if (a[i] != b[i]) {
            // Can stop iteration, strings are not equal!
            return false;
        }
    }

    return true;
} For the sake of example, let's assume our computer is very slow and doing takes a second each time. a[i] != b[i] Looking at the above then, we can see that if the user passes as the password, it'll try to compare the first characters ( vs ), and because they are unequal, the comparison will stop early so the whole function will take 1 second. Bad123123 B S Though, if we pass , the whole function will take 9 seconds, as it compared all of the characters. Secret123 This means that we found an observable change of behavior based on the password. Now, let's use that to our advantage. We know that this function is slower the more characters are correct. So, we can just start feeding it with characters one after the other and measure the time it took. We try and get 1 second, and get one second, all the way to , where it all of a sudden takes two seconds. This lets us find the first character. A B S Now, we can do the same for the second character. We pass which takes 2 seconds, and then , which takes two seconds, all the way to which then takes 3 seconds, so our password starts with ! Sa Sb Se Se We can repeat this process until we found the full password. What's the correct way to solve it then? Well to make a comparison constant time! // This function assumes the strings are the same length for simplicity
function is_equal_constant(a, b) {
    let ret = true;

    for (let i = 0; i < a.length; i++) {
        // Putting the && ret at the end, to avoid short-circuiting
        ret = (a[i] != b[i]) && ret;
    }

    return true;
} With this function, the comparison always takes the same time, which protects us from timing attacks! do not use the function above in production as it may not work as expected. Optimizing compilers may change the behavior, so it's important to use purpose-built comparison functions that are provided by your system libraries which already protect against that. Note: How Does It Apply to Webhooks? Webhooks don't really have a password, but they have signatures, which in a way are dynamic passwords. With webhooks you pass a specific payload, e.g: {
  "foo": "bar"
} and sign it with a secret key in a way that only someone with the key could have signed it. The signature (e.g., ) is then passed with the payload, and the receiver can verify the sender has the secret key, and thus, that the webhook can be trusted. Vh082qUqkhY7WiBWktRKRbP6/c+EYoqtHi/dMULaTKc= An attacker may want to send a malicious webhook, but without the secret key, the signature will not match and the webhook will be rejected. The aforementioned timing attack can't help us with recovering the secret key used for the signature, but it can help us find a valid signature! So similarly to how we managed to find the password, we can find a valid signature for the malicious payload, and then just use this valid signature as proof we know the key and get the webhook validated. Even though we never actually learned the key! How Does Svix Solve It? Security is hard. The reason for that is that security issues are not always obvious. If you have a bug in your code, you will usually notice it while testing it. Though with security, you don't always know what to test for. This issue, unfortunately, can't be mitigated on the sender side (Svix), it has to be mitigated on the client side. So we can't blanket solve it on our end. We have however created a set of , that make it easy both to sign and verify webhook signatures correctly. Svix customers can offer them to their customers to ensure they have a great developer experience and stay secure. open-source webhook signature libraries Additionally, non-Svix customers can also reuse them, both for signing, and verification to ensure that they offer their customers an easy and secure experience. For more content like this, make sure to follow us on , , or for the latest updates for the , or join the discussion on . Twitter GitHub RSS Svix webhook service our community Slack Also published here Photo by on Philipp Katzenberger Unsplash

How to Securely Verify Signature Hashes

The Lord of The Dynamos

El señor de los dínamos

Le Seigneur des Dynamos

डायनामोस के भगवान

ダイナモの主

O Senhor dos Dínamos

Chúa tể của Dynamos

发电机之王

The server room within companies can house their most important assets, like data and operating systems. With such vital information and procedures packed into digital mainframes and devices, enforced optimal security provides proper protection. There are measures for server room protection — perimeter security, facility controls, computer room controls and cabinet controls. The following are physical security practices that can keep server rooms safe and secure. four layers of physical security Threats To Security Encrypted data and personal information often reside within server rooms. With access to this data set, identities risk getting stolen and systems risk corruption. Natural events like floods and fires also threaten data centers and server rooms. Threats to physical security are evolving faster than some companies can keep up with. When credit card skimming was prominent, companies created chips to combat these scams. Now, some juice-jacking hackers for mobile devices. Server rooms rank much higher than personal technology on the importance scale, so businesses and IT professionals should protect them at all costs. prey on public charging stations Merging cybersecurity and physical security can robustly protect server rooms. Sensitive information is at risk when hackers infiltrate server rooms and pose the risk of fraud and identity theft for the business and its employees. Various technology techniques can , whether physical or virtual. defend against security threats Authenticated Access Physical security for server rooms comes in many shapes and sizes. Corruption or loss of data can result in delayed operations, lost revenue and stolen information. Among the various ways to protect a server room and its critical data, authentication access is of utmost importance. Limit the number of people who have access as much as possible — using a server room as storage allows more people access to the room. Locked doors with pin codes given to only those granted access are an excellent option for security. Access cards are an alternative solution for a bigger room with more to protect. Server racks and trusted security partners can also obtain optimal protection. Motion sensors are also a great tool in physical security to alert the appropriate personnel of someone entering a server room. When the light inside the room comes on, security can check to ensure the person has the appropriate access levels to gain entry. Motion sensors also alert security if any violation occurs within the server room and record movement to retain data for further analysis if needed. Security guards on-site can help enforce authenticated access to server rooms. They can monitor visitor frequency and monitor who enters and leaves the room. Additionally, an uninterruptible power supply can ensure security measures don’t fail. Avoiding momentary power losses can prevent significant damage if the wrong person gains access. Video Surveillance Video surveillance is another excellent way to monitor server rooms. Because they contain such essential information for a business's performance, there shouldn’t be any unchecked measures. Video surveillance allows security staff to watch server rooms closely around the clock. Additionally, video surveillance goes one step further than motion sensors. While motion sensors can retain data based on movements within the room, video surveillance can specifically show who or what is moving. This allows for a more precise analysis of security breaches and how to prevent them in the future. With an increased , hybrid cloud emerged. Hybrid cloud infrastructures store video data, making remote monitoring accessible on any digital device. In-depth analytics are available and increase video retention for those needing it. Hybrid cloud infrastructures are perfect for growing surveillance systems because they can accommodate for lack of storage. demand for hardware storage solutions Fire Protection System Fire suppression systems protect server rooms from accidents and electrical fires. Even if a facility takes every precaution, there is always the potential for a server to overheat and cause destruction. Having a plan to minimize the damage can help IT teams and businesses secure their server rooms. With a , the server room and everything it houses will have robust protection against possible incidents. Smoke detection systems can alert and stop fires as soon as possible to ensure minor damage occurs to servers and their information. fire suppression system in place Insurance companies can assist with fire damage to a building, but destroyed servers can result in losing all vital information. Server rooms are also at high risk for fires with wiring malfunctions and overheating possibilities since they contain levels of electricity that can cause overloading or short-circuiting. Ensure the appropriate extinguisher is within the room since different types of fire extinguishers are available. Backup Strategy A data backup strategy assists in routinely storing data so an emergency doesn’t completely destroy it. When servers regularly back up their data, the result won’t be as catastrophic because there will be restorable files and folders. Online and remote backup solutions are handy because they can house significant encrypted storage users can access remotely in unforeseen events. Backing up information on devices at least once a day can be significantly helpful, but it is wise to back it up more if possible. Sensitive information lost can be detrimental for companies relying on particular data sets. Employees should back up the servers before every update to ensure they can restore the hard drive. A server-class operating system should also be running by a proper file server. Generators should be in server rooms so information isn’t lost during power outages. Automatic transfer switches are available for installation so the when the power goes out. No one has to flip the switch manually, so losing data is less likely without the possibility of lag time. Spot coolers are also excellent to ensure server rooms stay cool and don’t overheat during environmental threats. generator automatically comes on Utilize the Best Physical Security Practices Physical security practices for server rooms can be overwhelming. Try out the tips above to make any business’s server rooms more secure. When companies rely heavily on the data they store in these rooms, they must remember to protect it physically and digitally.

Best Physical Security Practices for Your Server Room

Mejores prácticas de seguridad física para su sala de servidores

Meilleures pratiques de sécurité physique pour votre salle de serveurs

आपके सर्वर रूम के लिए सर्वोत्तम शारीरिक सुरक्षा अभ्यास

サーバー ルームの物理的セキュリティのベスト プラクティス

Melhores práticas de segurança física para sua sala de servidores

Các phương pháp bảo mật vật lý tốt nhất cho phòng máy chủ của bạn

服务器机房的最佳物理安全实践

This is the sixth post in a series about property-based testing. This post describes "random shrinking", the third and last implementation of shrinking I know of. It keeps all the advantages of internal shrinking, which we discussed in part 5, and is much simpler. Previous posts are: What is Property-based Testing? Essentials of Vintage QuickCheck Shrinking For Easier Debugging Unifying Random Generation and Shrinking Shrinking Choices, Shrinking Values The last posts discussed two different approaches to shrinking failing test cases, aiming to make the failing example easier to understand and debug. The first approach, direct shrinking, makes values smaller by directly changing them. The second approach, internal shrinking, instead tries to change the sequence of choices that are made during random generation. These choices are like the DNA of a generated value, and choices can be edited to make the resulting value smaller. When we discussed the advantages of internal shrinking vs direct shrinking, we also noted that editing the choices can be tricky. Significant engineering effort is needed to make it work well. What if we could have our cake and eat it too - an approach to shrinking that keeps all the advantages of internal shrinking, but is much simpler to implement? The unreasonable effectiveness of randomness The idea is simple: instead of coming up with a deliberate algorithm to make values smaller, we just - in technical terms - throw shit to the wall and see what sticks. That is, we're already counting on random generation to find bugs, let's also randomly try to find smaller values that still make our test fail. Unlike the shrinking strategies we've seen so far, which produce a limited number of smaller values to try, this new approach can keep trying forever. If the random generator is "random enough", a good shrink should show up at some point. In practice, that can take too long, especially if the test itself is slow. However, we can avoid running a test, or even generating an actual value, by calculating the size of the value that we're about to generate beforehand. We'll keep the size of the smallest value that fails the test so far, and then randomly generate another and estimate its size while we generate. If that size is greater than that of the current smallest value, we're not interested in running the test with it or creating the rest of the value. Instead, we'll make the generator short-circuit - basically abort and move on to the next value. This avoids a lot of useless work. I learned of this beautiful idea via by Anthony Lloyd, and to the best of my knowledge, he is also the inventor of it. As we'll see it's simple to implement - the shortest reference implementation of all - and it's effective. As with previous implementations, it's worth noting that CsCheck's approach is slightly more complex than what I'll describe here - I'm just capturing the main idea. CsCheck Matters of size The implementation contains all the same concepts as the previous posts. We make two modifications to . In addition to generating a random value, we also return the size of the generated value. For our purposes, the size is simply represented by a positive integer. The smaller the integer, the smaller the size. Additionally, to enable short-circuiting, the generator takes in the current minimal size, . Random min_size Size = int

class SizeExceeded(Exception):
    pass

class Random(Generic[T]):
    def __init__ (self, 
        generator: Callable[[Optional[Size]], Tuple[T, Size]]):
        self._generator = generator

    def generate(self, min_size: Optional[Size] = None) -> Tuple[T, Size]:
        return self._generator(min_size) If is , we're in the random generation phase of the test run - meaning we haven't found a failing test yet and so the generator should never short-circuit. If is a value, we are shrinking, and is the current smallest value for which the test fails. If a generator exceeds that size, there's no point in going on, and the generator should throw to short-circuit. Don't worry if that doesn't make sense yet - examples below. min_size None min_size Size min_size SizeExceeded Beginning with , as usual: constant def constant(value:T) -> Random[T]:
    return Random(lambda: (value, 0)) A constant value has a size 0 - no amount of random generation is going to make the constant value change, so if we have found a value with size 0 we can just stop shrinking. Our old friend is a bit more tricky. int_between def int_between(low: int, high: int) -> Random[int]:
    def zig_zag(i: int):
        if i < 0:
            return -2*i - 1
        else:
            return 2*i
    def generator(min_size: Optional[Size]):
        value = random.randint(low, high)
        size = zig_zag(value)
        # short circuit - implementation below
        dec_size(min_size, size)
        return value, size
    return Random(generator) uses so-called ZigZag encoding to calculate the size of an int. ZigZag encoding is also used in . The gist of it is that each signed integer gets a positive size, by zigzagging between negative and positive integers. Unlike the implementation here, with a limited type like int32 or int64, you only need a few bit shifts and exclusive or to compute the size, which makes it pretty fast in practice. The idea is that integers with greater absolute value have greater size. int_between Protocol Buffers I've also introduced a method (for "decrease size"), which makes sure we short-circuit generation as soon as possible. dec_size def dec_size(min_size: Optional[Size], 
             decrease: Size)
    -> Optional[Size]:

    if min_size is None:
        return None
    smaller = min_size - decrease
    if smaller < 0:
        raise SizeExceeded()
    return smaller If is not , meaning we're currently shrinking, subtracts the size of the currently generated value from the current minimum size, and checks if that is still positive. If it's not, it throws to indicate that the value we're about to generate is greater than the best, minimum size - thereby short-circuiting. The less work we do, the more values we can generate in a shorter time, and the more opportunities we have for finding smaller values. We're not yet using the result of but we will do so soon. min_size None dec_size SizeExceeded already dec_size is uninteresting - it just maintains the size: map def map(func: Callable[[T], U], 
        gen: Random[T])
    -> Random[U]:

    def generator():
        result, size = gen.generate()
        return func(result), size

    return Random(generator) The size of is the sum of the sizes of all its inputs: mapN def mapN(func: Callable[...,T], 
         gens: Iterable[Random[Any]])
    -> Random[T]:

    def generator(min_size: Optional[Size]):
        results: list[Any] = []
        size_acc = 0
        for gen in gens:
            result, size = gen.generate(min_size)
            min_size = dec_size(min_size, size)
            results.append(result)
            size_acc += size
        return func(*results), size_acc

    return Random(generator) Both and assume that the size of the output value decreases as the size of the input values decreases. Reasonable, though it's easy to imagine a counterexample. Here's where the result of is used: as values for the inputs are generated, subtracts their size from . This ensures that, if say we have 10 inputs, and we already exceed the by the third generator, we short-circuit as soon as possible. map mapN dec_size mapN min_size min_size Finally, : bind def bind(func: Callable[[T], Random[U]], 
         gen: Random[T])
    -> Random[U]:

    def generator(min_size: Optional[Size]):
        result,size_outer = gen.generate(min_size)
        min_size = dec_size(min_size, size_outer)
        result,size_inner = func(result).generate(min_size)
        size = size_inner+size_outer
        return result, size

    return Random(generator) The size of is interpreted as the sum of the size of both inner and outer generators. bind And that is pretty much it! We can literally reuse our implementation of and , which I've repeated here as a reminder. Property for_all @dataclass(frozen=True)
class TestResult:
    is_success: bool
    arguments: Tuple[Any,...]

Property = Gen[TestResult]

def for_all(gen: Gen[T], 
            property: Callable[[T], Union[Property,bool]])
    -> Property:

    def property_wrapper(value: T) -> Property:
        outcome = property(value)
        if isinstance(outcome, bool):
            return constant(
                TestResult(
                    is_success=outcome, 
                    arguments=(value,)
                )
            )
        else:
            return map(
                lambda inner_out: replace(
                    inner_out, 
                    arguments=(value,) + inner_out.arguments
                ),
                outcome
            )
    return bind(property_wrapper, gen)

def test(property: Property):
    def find_smaller(min_result: TestResult, min_size: Size):
        ... # the only new bit

    for test_number in range(100):
        result, size = property.generate()
        if not result.is_success:
            print(f"Fail: at test {test_number} with arguments {result.arguments}.")
            find_smaller(result, size)
            return
    print("Success: 100 tests passed.") Now, is new but is hardly difficult. The idea is to keep generating random values until we find one that is both smaller than the current smallest known size, and that still fails the test: find_smaller def find_smaller(min_result: TestResult, min_size: Size):
    skipped, not_shrunk, shrunk = 0, 0, 0
    while skipped + not_shrunk + shrunk <= 100_000 and min_size > 0:
        try:
            result, size = property.generate(min_size)
            if size >= min_size:
                skipped += 1
            elif not result.is_success:
                shrunk += 1
                min_result, min_size = result, size
            else:
                not_shrunk += 1
        except SizeExceeded:
            skipped += 1

    print(f"Shrinking: gave up at {min_result.arguments}")
    print(f"{skipped=} {not_shrunk=} {shrunk=} {min_size=}") We stop shrinking after trying 100,000 values, or if we somehow found the smallest possible size of 0. For each try, there are three possible outcomes: "skipped". This means that during or after the generation of the value, we detected that its size is greater than our current minimum size. "shrunk". Successful shrink - we've found a smaller value that still fails the test. "not_shrunk". Unsuccessful shrink - we've found a smaller value, but it passes the test. Before we check how that works out in practice, let's take a break and have a healthy snack. Putting it to the test Now the question is - does this even work? It seems naively simple. Only one way to find out - using our canonical example. Note once again we didn't have to change generators or test code, so I won't repeat that code here. prop_wrong_sort_by_age > test(prop_wrong_sort_by_age)
Fail: at test 0 with arguments ([Person(name='pjahgc', age=27), Person(name='gndrlt', age=70), Person(name='qukflk', age=79), Person(name='dknczu', age=2), Person(name='jqtqgr', age=8), Person(name='xlcxhk', age=22), Person(name='wotanl', age=5), Person(name='nxkupy', age=99), Person(name='pxngky', age=31)],).

Shrinking: gave up at arguments ([Person(name='etkdgb', age=8), Person(name='haagjh', age=5)],)

skipped=81616 not_shrunk=18373 shrunk=12 min_size=2502

> test(prop_wrong_sort_by_age)
Fail: at test 0 with arguments ([Person(name='cigepg', age=69), Person(name='lqkqmp', age=100), Person(name='nlgbbl', age=33), Person(name='xrnzfq', age=76), Person(name='ujjnfz', age=34), Person(name='xlcvxf', age=19)],).

Shrinking: gave up at arguments ([Person(name='adcyxh', age=1), Person(name='hrclbb', age=0)],)

skipped=81931 not_shrunk=18055 shrunk=15 min_size=2530 Each of these examples took a couple of seconds to generate. The second example is one of the best results I've seen, the first is more typical. A few notes:' It's alive! I've only tried a dozen or so times, but it always manages to shrink to a list of two s, with relatively low ages. Person This approach has more problems with shrinking lists of letters - it's not even clear that there is a pseudo-random seed that generates the letters "aaaaaa" and "aaaaaab" in succession, which is what would have to happen for those "minimal" names to show up. The stats in the last line of each example are typical. happens about 80% of the time, about 20% of the time. The number of values is almost insignificant! These numbers are similar if I try 1,000,000 times instead of 100,000 times. In fact, the number of successful shrinks remains around 10-15 even with 10x more tries. This indicates that for this case at least, it's unlikely to help much if we keep shrinking for longer. skipped not_shrunk shrunk Picking a winner This third and last approach to shrinking sounds almost too simple to work. But it does, and pretty well at that. We've removed all human cleverness from the shrinking process, and as a result, we gain a straightforward implementation, while keeping an integrated generation and shrinking API. Shrinking works just as well for mutable as for immutable values, and we can reproduce any run with just a single seed value for the pseudo-random number generator (typically a couple values). int64 Now, I've emphasized that this approach is by far the simplest to implement, and simplicity is its own reward. But does it also buy us anything? Yes, it does - besides having all the advantages of internal shrinking, it's also trivial to parallelize. All you need is a pseudo-random number generator that can generate several separate streams of random numbers. Secondly, if you have the code and the random seed, it's easy to pause and resume the shrinking process at a later time. After all that, you may be left with a question: what's the best-shrinking strategy? As usual, I would say "it depends", and rephrase the question: if you're writing a property-based testing library from scratch, which approach should you choose? The answer to that question is random shrinking, in my view. Faced with such decisions, it's tempting to find the "best" solution, by some measure. Instead, I think it's better to find the solution that gets people something useful, in the least amount of time, and with the highest optionality - meaning, while keeping as many options open as possible. In this case, random shrinking is certainly going to produce something useful (i.e. it will make counterexamples smaller). It is by far the simplest and thus fastest solution to implement. And finally, we can move to another approach without bothering our users much, which keeps our options open. Also, it's feasible to tack on any of the other shrinking methods random shrinking: for example, we can try to find the smallest example using random shrinking, and then try and make that value even smaller by any of the two other methods. after Finally Phew! When I started this series I didn't think I'd get to six posts on property-based testing, and the worst is that I'm not even done - for example, there are approaches that allow exhaustive generation of values as input to a property-based test. That said, I'm going to take a break (of currently unknown duration) from writing about property-based testing because I have a bunch of ideas for other topics I'm excited to write about. The complete code for this post can be found on - in particular and . GitHub example.py random_based.py Also published . here

Random All the Way Down; Property-based Testing (Part 6)

Crucial Cloud Computing Security Threats Everyone Should Know

Before reading this, I would recommend trying and learning what are imperative and declarative styles of programming. See Imperative vs Declarative One of the powerful features the Java team included when bundling JDK 1.8 is the Streams API. The purpose of streams is to process a sequence of elements by executing different kinds of operations on the elements. The New Java package for streams is . java.util.stream What is a stream? Let us see some of the important aspects of Streams API. Streams API is used to process collections of objects. No Storage. A Stream is not a data structure like Arrays/Stack/Queue etc. instead it takes input from Collections, arrays, or I/O channels. Streams don’t change the original data structure, they only provide results as per the pipelined methods. Streams are used to perform complex data processing operations on collections data. They represent a pipeline through which the data will flow and the functions to operate on the data. In streams, we make use of Lambda expressions to improve the collection library, by making it easier to iterate through the filter and extract data from a collection using streams. Any stream might have an unlimited amount of data flowing through it. Data received from a stream is processed individually as it arrives. Functional in nature. An operation on a stream produces a result but does not modify its source. For example, filtering a Stream obtained from a collection produces a new Stream without the filtered elements, rather than removing elements from the source collection. Laziness-seeking. Many stream operations, such as filtering, mapping, or duplicate removal, can be implemented lazily, exposing opportunities for optimization. For example, “find the first String with three consecutive vowels” need not examine all the input strings. Stream operations are divided into intermediate (Stream-producing) operations and terminal (value- or side-effect-producing) operations. Intermediate operations are always lazy. Possibly unbounded. While collections have a finite size, streams need not. Short-circuiting operations such as limit(n) or findFirst() can allow computations on infinite streams to complete in finite time. Consumable. The elements of a stream are only visited once during the life of a stream. Like an Iterator, a new stream must be generated to revisit the same elements of the source. Creating Streams We have a few different ways to create a stream. From Collections. From arrays. From an arbitrary number of objects. Infinite and finite streams. Benefits Following are the advantages of using Streams API. We have already seen the difference between imperative and declarative approaches. With Streams, we move from imperative to declarative programming. Streams can only be applied to Collections such as , , , , etc. List Map Set Arrays Streams encourage less mutability They can operate on their contents in parallel using the . parallelStream() Another benefit/advantage is streams process data lazily. Let us assume we are reading lines of text from a large file as a stream, which means the stream loads data as required which saves a lot of memory. Stream Pipeline Enough talk! Let us see an example 🤩 Let us see an example to understand the stream pipeline. We have a list of the books and we are running some chain of methods on it like , , etc. This chain of method calls is called a . filter map Stream Pipeline This is also called functional programming as we are passing functions. is a POJO with a constructor, getters, and setters. Book class Book {
  String title;
  String author;
  Integer year;
  Integer copiesSoldInMillions;
  Double rating;
  Double costInEuros;

  public Book(String title, String author, Integer year, Integer copiesSoldInMillions, Double rating, Double costInEuros) {
    this.title = title;
    this.author = author;
    this.year = year;
    this.copiesSoldInMillions = copiesSoldInMillions;
    this.rating = rating;
    this.costInEuros = costInEuros;
  }

  public String getAuthor() {
    return author;
  }

  public Double getRating() {
    return rating;
  }

  @Override
  public String toString() {
    return "Book{" +
      "title='" + title + '\'' +
      ", author='" + author + '\'' +
      ", year=" + year +
      ", copiesSoldInMillions=" + copiesSoldInMillions +
      ", rating=" + rating +
      ", costInEuros=" + costInEuros +
      '}';
  }
} Another class for dummy data injection. BookDatabase import java.util.Arrays;
import java.util.List;

public class BookDatabase {
  public static List<Book> getAllBooks() {
    return Arrays.asList(
      new Book("Don Quixote", "Miguel de Cervantes", 1605, 500, 3.9, 9.99),
      new Book("A Tale of Two Cities", "Charles Dickens", 1859, 200, 3.9, 10.0),
      new Book("The Lord of the Rings", "J.R.R. Tolkien", 2001, 150, 4.0, 12.50),
      new Book("The Little Prince", "Antoine de Saint-Exupery", 2016, 142, 4.4, 5.0),
      new Book("The Dream of the Red Chamber", "Cao Xueqin", 1791, 100, 4.2, 10.0)
    );
  }
} And finally out class that does the declarative programming or immutability on each object. BookApplication book import java.util.List;

public class BookApplication {
  public static void main(String[] args) {
    List<Book> books = BookDatabase.getAllBooks();

    books.stream()
      .filter(book -> book.getRating() >= 4)
      .map(Book::getAuthor)
      .forEach(System.out::println);
  }
} Output: J.R.R. Tolkien
Antoine de Saint-Exupery
Cao Xueqin In the above example, we have a list of Book objects. We applied to convert the list of objects into a . .stream(...) Book stream of objects We applied two intermediate operations that take a and to get the filtered stream of objects. .filter(...) Predicate .map(...) We terminated it with to print all the objects. .forEach(...) Disadvantages If streams are not handled properly, they have a huge impact on performance. The learning curve is time taking, as there are many overloaded methods you need to learn which is confusing, not a disadvantage though but wanna keep it here as a downside. First Published here

Have you Used the Streams API in Java?

What is Breadboard? When learning how to build a circuit, the is one of the most basic components. There are many small jacks on the breadboard, which are specially designed and manufactured for solderless experiments of electronic circuits. A breadboard consists of a plastic block holding a matrix of electrical sockets of a size suitable for gripping thin connecting wire, component wires, or the pins of transistors and integrated circuits (ICs). The sockets are connected inside the board, usually in rows of five sockets. Since various electronic components can be inserted or pulled out at will according to needs, welding is eliminated, circuit assembly time is saved, and components can be reused, so it is very suitable for the assembly, debugging, and training of electronic circuits. breadboard How to Use Breadboards You can use a breadboard to make quick electrical connections between components- like resistors, LEDs, capacitors, etc so that you can test your circuit before permanently soldering it together. Without welding and manual wiring, the circuit and components can be tested by inserting the component into the hole, which is convenient to use. Before use, determine which component's pins should be connected together, and then insert them into the same group of 5 small holes. : LED Lighting Example : One breadboard, several connecting wires (the connecting wires should use needle-shaped wires at both ends), one led light, and one 3V button battery. Materials First, put the battery into the battery holder (this can be bought online), and plug it into the breadboard. Then, insert the battery holder into the left and right parts of the breadboard. Parts are separated by grooves to avoid a short circuit between the positive and negative poles of the power supply). Lead two wires from the positive and negative poles of the battery, and then plug the LED into any two grids that are not conductive on the breadboard (the long pin of the led is positive and the short pin is negative), and finally connect the wires from the positive and negative poles of the battery to the two LED segments. Basic Principles of Breadboard Wiring Complete the circuit overlap on the breadboard, different people have different styles. However, no matter what style or habit, the following basic principles must be paid attention to when completing the circuit overlap: The fewer connection points, the better Each additional connection point actually increases the probability of failure artificially. There are common faults such as impassability in the breadboard hole, loose wire, and broken wire inside. 2. Try to avoid overpasses The so-called "overpass" means that components or wires ride on other components or wires. Beginner is easy to make such mistakes. It will bring trouble to the replacement of components in the later stage. On the other hand, in the event of a failure, the messy wires can easily make people lose confidence. 3. Try to be as reliable as possible There are two phenomena that need attention: Breadboard integrated circuits are easy to loosen. Therefore, for integrated circuits such as operational amplifiers, it is necessary to press down forcefully. Once it is not reliable, the position needs to be changed. The pins of some components on the breadboard are too thin, so please be careful to move them slightly. If you find that they are not secure, you need to change the position. Breadboard Using Tips for Beginners When installing discrete components, it should be easy to see their polarity and signs. After placing the component pins, bend them where needed. In order to prevent the exposed leads from short-circuiting, a wire with a sleeve must be used, and the component pins are generally not cut to facilitate repeated use. Generally, do not insert components with a pin diameter> 0.8mm, so as not to damage the elasticity of the contact piece inside the socket. The pins of integrated circuits that have been used many times must be repaired neatly, the pins cannot be bent, and all the pins should be slightly skewed outward so that the lead angles and the jacks can be reliably contacted. The arrangement of the components on the breadboard should be determined according to the circuit diagram in order to facilitate the wiring. In order to be able to correctly route and facilitate wire checking, the insertion direction of all ICs must be kept the same, and which cannot be inserted upside down for the convenience of temporary wiring or to shorten the length of the wire. According to the sequence of the signal flow, the method of installation and debugging is adopted. After the components are installed, first connect the power cord and the ground wire. In order to check the line conveniently, try to use different colors for the line. For example, the positive power supply generally uses a red wire, the negative power supply uses the blue, the ground wire uses the black, and the signal wire uses the yellow. Other colors can also be selected according to the real conditions. The breadboard should use a single-strand wire with a diameter of about 0.6mm. Cut the wire according to the distance of the wire and the length of the jack. The wire end is required to be cut into a 45º, and the stripped length of the wire end is about 6mm. All the wires are required to be inserted into the bottom plate to ensure good contact. In addition, bare wires should not be exposed to prevent disconnection with other wires. The connection is required to be tightly attached to the breadboard to avoid collision and ejection of the breadboard, resulting in poor contact. The wiring must pass around the integrated circuit, and it is not allowed to cross the integrated circuit, and the wires must not be overlapped with each other, try to be horizontal and vertical. This is conducive to line wiring and checking, and components replacement. It is best to connect a capacitor with a capacity of tens of microfarads in parallel between the input terminal of each power supply and the ground, so as to reduce the impact of current during transients. In order to suppress the high-frequency components in the power supply, a high-frequency decoupling capacitor should be connected in parallel at both ends of the capacitor, generally 0.01~0.047Uf. During the wiring process, it is required to place the various components in the corresponding position on the breadboard and mark the pin numbers used on the circuit diagram to ensure the smooth progress of debugging and troubleshooting. All ground wires must be connected together to form a common reference point. Maintenance of the Breadboards Using a breadboard is more convenient than using a soldering method, easy to replace wires and components, and can be used multiple times. However, the breadboard should be maintained during daily use. After multiple uses of the breadboard, the spring sheet will become loose and the elasticity will become poor, which is easy to cause poor contact and virtual welding. They are difficult to find out. The breadboard that has been used many times should be uncovered from the back; the spring sheet with poor elasticity should be taken out, repaired, and then inserted into the original position. This can enhance the elasticity and increase the reliability and service life of the breadboard. In addition, pay attention to where the breadboard is used. Large-volume, high-quality, or high-power components cannot be plugged into the breadboard because the breadboard jacks are small and the leads of such large components are relatively thick. At this time, the components can only be placed outside the board. Use a single strand of hard wire to solder to the lead, and then insert it into the breadboard. Breadboards are not suitable for high-frequency circuits because the lead inductance and distributed capacitance of the breadboard are relatively large, which has a great impact on the performance of high-frequency circuits. A breadboard is suitable for integrated circuits, especially for digital integrated circuits because digital integrated circuits usually have low operating frequency and low power, and they use fewer RC components. It is more difficult for discrete component circuits to use breadboards, especially for circuits with high frequency and high power. Reference Note: https://www.apogeeweb.net/electron/the-best-tech-guide-to-electronic-breadboards.html

How to Build a Circuit: Breadboards for Beginners

1. Destructuring Assignment Destructuring assignment allows one or more object properties to be assigned to variables in a single expression. The created variable will have the same name as the property. let myObj = {
  id: 1,
  name: 'My Object'
};

// without destructuring assignment
let id = myObj.id;
let name = myObj.name; 
// id = 1, name = 'My Object'

// with destructuring assignment
let { id, name } = myObj;
// id = 1, name = 'My Object' This is most useful when you know that you need to use multiple properties from an object, you need to use the same property multiple times, or the property that you wish to use is deeply nested in that object. In all these cases, using destructuring assignment saves you from all the clutter of getting the object properties through chaining and makes your code more concise and easier to read. For example, I have recently been working a lot with , a Javascript framework for building interactive maps. It is highly customizable and allows you to assign your own properties to different markers on the map. However, accessing these properties can get somewhat messy - we can clean this up with destructuring assignment. Leaflet // without destructuring assignment
function onEachFeature (feature, layer) {
  if (feature.properties.hasPopup) {
    let popupContent = `<a href="/feature/${feature.properties.id}">${feature.properties.name}</a>`;
    layer.bindPopup(popupContent);
  }
}

// with destructuring assignment
function onEachFeature (feature, layer) {
  let { hasPopup, id, name } = feature.properties;

  if (hasPopup) {
    let popupContent = `<a href="/feature/${id}">${name}</a>`;
    layer.bindPopup(popupContent);
  }
} We may have added an additional line of code, but I believe this makes it much clearer and easier to read the intention of this function now. It is also possible to destructure arrays, which allows you to assign one or more elements in that array to variables. However, I do not personally find myself using this syntax often so I won’t cover it any further here. If you wish to learn more, please see the . MDN reference Finally, if you are using a function that has an object as a parameter, it is possible to destructure that object within the parameter list. This saves you the effort of having to explicitly declare the variables yourself and makes it clear which properties are required by the function. function logPerson(person) {
  let { name, age } = options;
  
  console.log(`${name} is ${age} years old`);
}

function logPerson({ name, age }) {
  console.log(`${name} is ${age} years old`);
} 2. Short Circuit Evaluation & Assignment The JavaScript logical operators, AND (&&) and OR (||) are known as short circuit operators because they only evaluate the expression as far as necessary in order to determine the result of the boolean expression. For example, AND requires that both sides of the expression evaluate to true. Therefore, if the left-hand side of the expression evaluates to false, it does not bother to check the right-hand side as it would be a waste of time. Similarly, OR requires that only one side of the expression evaluates to true. Therefore, if the left-hand side evaluates to true, it doesn't bother to check the right-hand side. This short-circuiting can be useful for adding some safety to expressions involving objects. For example, consider the following function: function logIfAdult(person) {
  if(person.age >= 18) {
    console.log("Person is an adult");
  }
} The problem with this implementation is that you cannot guarantee that the person object is not null. If you run this function with a null person, you will get the following error: . Uncaught TypeError: Cannot read property 'age' of null Thanks to short circuit evaluation, we can add some safety like this: function logIfAdult(person) {
  if(person && person.age >= 18) {
    console.log("Person is an adult");
  }
} This is because, if person is null it will evaluate to false (this is because null is a "falsey" value, if this concept is new to you, ), and the whole expression will short circuit. Only if person is not null will the expression move on to check the right-hand side of the expression, at which point we know it is safe to check and we wont get any errors. please read this article too We can exploit this short-circuiting when assigning variables too. For example, consider the following function: function logName(person) {
  let name = person && person.name;
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'null' What is happening here? Well in the first example, we pass the function a valid person object. Because the person object is not null, the AND operator moves over to the right-hand side of the expression, and assigns the value of to the name variable. In the second example, person is null so the expression short circuits and returns null to the name variable. person.name We can extend this further to log a default name instead of just null. This time we use the OR operator, so we will only use the default value if the person object is null. function logName(person) {
  let name = person && person.name || 'Default Name';
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'Default Name' 3. Optional Chaining & Nullish Coalescing Operator Short circuit evaluation and assignment is so common that new more concise syntax is being added in to JavaScript to achieve the same aim. These are the optional chaining and nullish coalescing operators. I have decided to include both short-circuiting and optional chaining/null coalescing since, at the time of writing, the latter are newer features and may not be fully compatible with older browsers. The optional chaining operator (?.) allows you to dive into objects without explicitly having to check if the object is not null. If the object is null, then the expression will just return undefined instead of throwing an error. For example, with optional chaining, the logIfAdult function from above can be rewritten as: function logIfAdult(person) {
  if(person?.age >= 18) {
    console.log("Person is an adult");
  }
} The nullish coalescing operator (??) is used to return a default value if the value on the left-hand side of the expression is null. In this way, it replaces the functionality of the OR operator in the logName function above: function logName(person) {
  let name = person?.name ?? 'Default Name';
  console.log(name);
} 4. Named Callback Functions Anonymous functions can be really useful - they can be declared when and where you want, and are great if you only need the function as a one-off. let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let viewModels = people.map(p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
}));
// viewModels = [{ id: 1, name: 'Sam Walpole' }] However, since the function has no name, you are leaving it up to future developers to work out what the code inside your callback function does - that's ok here, but in longer, more complex functions it may waste unnecessary time. By declaring the function first as a named function, you instantly make the code more readable and give future developers some clues as to the intent of the function. let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let toViewModel = p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
});

let viewModels = people.map(toViewModel);
// viewModels = [{ id: 1, name: 'Sam Walpole' }] 5. Enums/Dictionaries An enum is a way to store a set of constant values as a type. Most languages have in-built support for enums, but in JavaScript we have to construct them ourselves using an object. const Color = {
  RED: 'RED',
  GREEN: 'GREEN',
  BLUE: 'BLUE',
};

let redCar = {
  make: 'Ferrari',
  model: '812',
  color: Color.RED,
};

let greenCar = {
  make: 'Aston Martin',
  model: 'Vantage',
  color: Color.GREEN, 
}; Enums pair nicely with switch statements for flow control: function getHexColor(car) {
  switch (car.color) {
    case Color.RED:
      return '#ff0000';
    case Color.GREEN:
      return '#00ff00';
    case Color.BLUE:
      return '#0000ff';
  }
} However, sometimes this can be a bit verbose. Instead of using a switch statement here, we could use a dictionary. Dictionaries in JavaScript are declared in a very similar way to enums, but conceptually they have a different purpose. Where enums are a set of constant values, dictionaries are a collection of key/value pairs. function getHexColor(car) {
  let hexColors= {
    [Color.RED]: '#ff0000',
    [Color.GREEN]: '#00ff00',
    [Color.BLUE]: '#0000ff',
  };

  return hexColors[car.color];
} In the above example, we have got rid of the need for a switch statement, as we have created a dictionary with the enum values as the key, and the hex colors as the values. By removing all the clutter of the switch statement, I believe that this leads to much easier-to-read code. Conclusion In this article, I have provided 5 tips that I regularly use in JavaScript to make my code more concise and easy to read. I hope that you have found them helpful and will find the opportunities to use them in your own code. I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and . If you found this post helpful, please like it and share it. You can also find me on . subscribe to my newsletter Twitter

Write Cleaner Code with My Top 5 JavaScript Hacks 

In this article, I look into some of the shortages of event-driven programming and suggest behavior trees as an effective alternative, suitable for back/front-end application development. What is AI? (and what event frameworks have to do with it) In 2020, for most people, AI is machine learning (ML). While ML is a revolution in its own right, it does not affect day to day application development. Although Wikipedia roots artificial intelligence in classical philosophy, the cornerstone is formal reasoning - the idea that human thought can be mechanized. : every computer program is AI, and the question becomes, what kind of AI does your program need? For most application developers handling events and interruptions is the norm, and the idea here is that a program receives a signal, such as a mouse button press, or an incoming request over the network, and (hopefully) there is enough context to process the request effectively. TLDR So, is this a good thing? It has to be good, right? This is how we've been writing programs since the 1980s! Either that, or we are overlooking swathes of bugs? Correctness vs Efficiency , I explained the difference between event handling and update loops from a management perspective: an event ongoing workflows. This only works when the problem at hand is very localized. Whereas running an update loop is like standup meetings. Concise, frequent standups are useful to keep team members . Over on dev.to interrupts synchronized The advantage of a "walk-in" policy is promoting a fast response. , because we may be taking a decision without consulting the team. Event handling offers speed at the cost of accuracy Conversely, standups are often pretty bland as there isn't always something new or interesting happening. In fact, the takeaway from many stand up meetings is "keep at it". As such . update loops promote correctness at the cost of efficiency In computer programming there is a rule about optimization: don't optimize. Speed at the cost of accuracy is a raw deal. The lesson here is: . actively move away from event handling and get application development back in the (update) loop What is a Behavior Tree? Behavior trees are a new (~2010) control paradigm based on tasks. A task can be , or . Behavior trees are like decision trees (an intuitive concept, I hope) with the time dimension factored in. succeeding failing running Behavior trees were first introduced in games (Halo). They are making headway in robotics and the point of this article, essentially, is encouraging developers to consider their potential in developing interactive, time aware applications (front/back-end). A behavior tree hooks a top-down decision process onto an update loop. The state allows postponing decisions until an ongoing task has completed. running "Not done yet" is a specific flavor of uncertainty (see ). my paper on Arxiv (C/C++/Java/Python/Swift/[yourlang]) is already good at decision trees and this boils down to: understand decisions; understand decisions. So long as a yes/no answer can be provided. As a case in point functional programming: if-elses bools What traditional control flow is not handling well is the "not done yet" factor involved in interaction - be it with users, other applications (local), or networked computers. With BTs, the primary control flow structures are sequences and selectors: A ( ⍈ ) iterates a list of tasks, until the first failing (not succeeding or running) task is encountered. Sequence A ( ⍰ ) iterates until the first succeeding task (and for this reason that is also known as a 'fallback node'). Selector For clarity it is really important to understand that . If we have a sequence of tasks A, B, C we are going to run: a sequence is not an action queue until it succeds. A and until B succeeds (A is not really running at this stage; only acknowledging it is already succeeding). A B and and until C is also succeeding. A B C Not coincidentally this execution model is stateless. Where no state is stored no state is out of date. Similar to standup meetings (where we get information from everybody) stateless execution ensures correctness. Behavior trees in code "Behavior trees" - the wording has visual flair and it is also true that (in game development) BTs are perhaps most successful through visual tools. Part of the problem (we are writing computer programs, not drawing arrows and boxes) was, as I already noted functional programming is good at decision trees, and control flow is designed to handle binary logic - not the three-valued logic implied by a ' state. running' On the whole functional languages are not very well suited to intelligent control in the sense that, almost anything that goes beyond if-elses needs an explicit data/node structure. and started working on a new behavior tree library; works especially well in C# (because they wanted to support three valued logic re: SQL), and to some extent still works (some memory/perf. overheads) in other languages. Two years ago I redefined BT using binary operators This approach leads to concise control code; here is a small example showing how BT programs look using the Active Logic library: => TaskA() && TaskB() && TaskC(); => A() || B() || ...; // Sequence status ( ) MySequence // Selector status ( ) MySelector A small gripe is, other than C#, no mainstream language does preserve the short-circuiting behavior of the (overloaded) conditional operators. Still, behavior trees may be supported gracefully, effectively and efficiently in any of these languages, with the one feature needed filed under "oversight". In the meantime C# is a better choice than you'd know. Via .NET Core it is cross platform and installs like a breeze (on Linux too). The Active Logic library (also, NuGet). lives on Github : I am the author of the Active Logic Library; in the Unity Asset Store (and beyond AGPL) variants of this library may be sold; the A.L. calculus is . Disclosure MIT-Licensed

Stories, News & Mentions about CIRCUITMIND

Circuitmind’s Stories on HackerNoon