Mission: Impossible Code – Super Planning + Surrealism = Getting the Job Done Every Time (Part 1)

Super action spies like Ethan Hunt, Jason Bourne, and Evelyn Salt live by the ethos of getting the job done no matter what. They carry out their missions in the face of extremely diverse situations and unforeseen circumstances.

Super spies utilize specialized tools and techniques when available (and work), but they always keep simple, practical alternatives in mind. They jump out of windows, walk on moving cars, use household items as weapons, and drive cars down stairs. They consistently create everything around them as tools for their situation. They do not believe that objects and situations have a fixed purpose, but rather that objects and situations are flexible in order to fulfill their imposed purpose.

Is it possible to write code that behaves like a super spy? Over time, I have adhered to a set of coding design heuristics that are similar to a super spy’s priorities and interesting Thing.

Updated Post: Mission Impossible Code Heuristics for Creating Super Spy Code That Always Gets the Job Done

Super Spy’s striving for surrealism is offset by an equal commitment to hyper-planning. As much as possible, every movement, every motion, every breath is planned to a tee. For a super spy, planning and opportunism are not seen as his two contradictory ways of approaching problems, but rather as completely complementary.

The work of a super spy will never be in a museum, nor will it support the workings of a great machine. Their work is evaluated solely on results. Superspies appreciate beautiful art and love good machinery, but building such things is not a skill they can apply to their work.

First of all, as is the nature of coding, pragmatism often means breaking conventions of coding style, verbosity, or obsequious adherence to best practices – pursuing what works under the most diverse conditions .

Recognize that the effort is not a spy mission

When you speak passionately in defense of a particular approach, many inevitably take it as a universal manifesto statement. The principles contained therein apply at all times and in all situations. I’ll tell you right now, I love Mission Impossible Coding. But that love also drew me to a specific field of technology (of my choice). As a cloud DevOps automation developer, I am constantly asked to bring together systems and requirements across different technologies, contexts, and layers.

I accept that super spies have a similar self-selection. They are required to combine different requirements, equipment, and personnel to accomplish their jobs. We all intuitively understand that James Bond is the perfect man to drive a $2 million super spy car. But we also know that the best person to make a spyker is Q, not James Bond.

Some problems require super spy field techniques, and some problems require spy car engineering techniques. Not only is the method advocated here likely to fail miserably in spiker production, it is also likely to be mostly an anti-pattern for such efforts.

Drive on the road when possible

Therefore, if the method proposed here does not fit within the constructs of the language, does not follow the rules of self-documentation, or the solution does not take into account proper modularity or other similar details, then here If you are averse to the method proposed, please continue with the following: Because building super spikers and weapons is very important in the grand scheme of things.

Qualities of a super spy

In the rest of this series, we’ll look at how a tough and opportunistic super spy approaches his job, using specific traits to ensure he gets the job done no matter what happens. . Some of them are:

• tenacious
• resilient
• resourceful
• opportunistic
• self-sufficient
• independent
• flexible
• practical
• Ready
• minimal assumptions
• fault tolerance
• predictive
• perceptive
• Accurate
• methodical

Train your super spy instincts using design heuristics

Do the above characteristics sometimes contradict each other? yes.

Do you sometimes find it difficult to decide which one to prioritize in a particular situation? yes.

Despite these challenges, do these heuristics produce results? yes.

Design heuristics are like needles on a gauge – Indicates which end of the selection should take precedence, all other things being equal. However, combining heuristics creates competitive tensions in the overall decision of which priorities should be optimized. This is because all other things are not equal when combining heuristics. (A combinatorial set of heuristics is similar to connected points in 3D space that define a shape that contains possible solutions.)

To get better at using design heuristics, you need to go the extra mile and practice experiencing and resolving these tensions over and over again. This is not a learning mode unnatural to the human mind, but is supported by an agile mindset. discovery. The rewarding result is training your “instincts” to come up with practical solutions when given complex input criteria. Design heuristics also take into account real-world experience that many problems can be solved with multiple different solutions. A hard-and-fast law approach may mean that there are few or only one solution to a particular problem.

show me the code

Oh, wonderful. Another series of articles supporting theoretical positions about how the world of code should work. I prefer writing code. me too! That’s why this series is littered with working code. my working code.

This series is a distillation of the results of applying practice, rather than a set of untested design claims. This practice arose out of continuous iterations of efforts to address the superspy problem.

Lesson 1 now – Degrade your implementation for simplicity and compatibility

Superspies quickly and deliberately downgrade their options from the “best” or “purpose-built” options to the old options at hand. Don’t you have modern weapons like guns? Use an ink pen instead.

Here’s a great example of PowerShell task scheduling CMDLets and schtasks.exe. Combining three or more PowerShell CMDlets to schedule simple tasks is difficult. The first time you do it, it takes hours to days, but it seems like it takes hours to days to reliably update the same code to meet newly discovered requirements. In my opinion, this is because his CMDLet set reflects the underlying object structure of the scheduled task a little too directly (where the PowerShell implementation is) The usual (hide the underlying complexity). Therefore, to schedule most tasks, you need to create a CMDLet and three or more types of objects with their respective parameters. Additionally, these CMDLets are not available in all versions of PowerShell and are easily confused with the PowerShell Job Schedule CMDlets.

I think Ethan Hunt prefers schtasks.exe. It is available on all versions of Windows and allows you to schedule most tasks in one line. For really complex scenarios, you can use the XML exported from your work tasks to set up a new system.

A good example is shown below.

Using PowerShell CMDLet:

$TaskTrigger = (New-ScheduledTaskTrigger -atstartup)
$TaskAction = New-ScheduledTaskAction -Execute Powershell.exe -argument "-ExecutionPolicy Bypass -File $scriptlocation"
$TaskUserID = New-ScheduledTaskPrincipal -UserId System -RunLevel Highest -LogonType ServiceAccount
Register-ScheduledTask -Force -TaskName HeadlessRestartTask -Action $TaskAction -Principal $TaskUserID -Trigger $TaskTrigger

schtasks.exe accomplishes the same thing more concisely.

schtasks.exe /create /f /tn HeadlessRestartTask /ru SYSTEM /sc ONSTART /tr "powershell.exe -file $scriptlocation"

I am aware that there is a way to reduce the number of lines in the CMDLet version, but it does not reduce the number of objects. In other words, compressing rows makes the end result more complex and difficult to construct, understand, and maintain. Also, more refactoring is required when new requirements are discovered.

For me, this is a case where Mission Impossible coding moves me away from the preferred stance of staying within the built-in capabilities of one language.

My perspective on scheduling tasks in the most practical way did not come from a single implementation attempt. I’ve iterated on the implementation using his CMDlet and faced many times its complexity challenges (both initial build and code maintenance) and PowerShell version limitations, schtasks. exe does not have these problems.

Using schtasks.exe provides the following super spy benefits:

• The resulting code will be simple and easy to understand.
• The resulting code has excellent backreach (scheduled task CMDLet is available in PowerShell V4 and later).
• If needed, you can use the GUI Task Scheduler as a code builder for scheduled tasks, as it can handle scheduled task XML that can be easily exported from Task Scheduler.

Back to Basics: Testable Reference Pattern Manifesto with Testable Example Code – Mission Impossible code samples are intended to be both 1) usable directly in production, and 2) first-class patterns that you can use for your own innovations. That’s what I mean.

Continue running an automation after restarting a headless Windows system

Fully Viable Implementation (SVI) for running code under the system account on Nano Server

Simplicity Manifesto Principles

Principles of minimalism (with cord)