Introducing { Launch-Pad }

Nasa Launching Chandra X-ray Observatory

{ What is it? }

{ Launch-Pad } is a web application for centralizing PowerShell scripts. In addition to a script repository  – your team can share, launch, and schedule PowerShell scripts all within the application.

Current Features
  • Secure central location for all your scripts
  • Auditing – who ran what when
  • Syntax highlighting editor
  • Launch scripts from the web
  • Schedule scripts with recurring options
  • Ability to leverage parameters and variables in your scripts
  • View outcome results
Planned Features
  • Define custom end users groups and access levels
  • Publish scripts to end users
  • Dashboard for non-scripting end users to launch/schedule scripts they need
  • Export and/or email script results
  • Email alerts on failures
  • Version Control

{ Screenshots }

Scripts Dashboard

Scripts Dashboard

Create and Edit Scripts

Launching Scripts with Parameters

Launch Script with Params

View Output

View Output

Schedule

Schedule Scripts

{ License }

I’ve been blessed by the open-source community throughout my career and decided to give back in the freest way possible by using the MIT License. This license grants anyone, free of charge, the right to own a copy of this software and use it any way they see fit. The full license can be read here:

The MIT License (MIT)

Copyright (c) 2015 Michael Burns

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

{ Contribute and Test }

{ Launch-Pad } is still in a testing phase. If you’d like to contribute or test, feel free to reach out to me via  LinkedIn.

 

Dependency Inversion Principle

Welcome to the last part of my SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new series..

    SOLID is not a language, it’s not a framework, it’s a set of principles to help guide your team to design better applications. Using these principles will help ensure your code is adaptive to change. I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles does require a fundamental understanding of classes, interfaces, and class inheritance.

The fifth letter in SOLID stands for DIP: Dependency Inversion Principle and this principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions

    Before digging deeper, let’s define the term dependency. Most, if not all, applications have dependencies. These dependencies may be an operating system (Linux/Windows) or a framework (Django/.Net) Another concrete, or low-level, dependency often cited is an application’s database. Dependencies are anything your application depends on. Simple as that.

Sustainable Software Must Be Tolerant of Changes

     Our applications should never depend on implementation details. Imagine sprinkling SQL statements in your code which directly connects and queries the company’s MSSQL database. If your company never switches databases, maybe you get away with not being an efficient developer for now, but trust me dependencies will come to bite you in the ass sooner or later. Just imagine if your boss comes to you a week after deployment and tells you that management decided to use MongoDB instead. “How long will the change take?”, he asks. You and your team should shudder just daydreaming about the nightmare of rewiring an entire application, especially when it’s so simple to avoid.

Abstracting Implementation Details

    Code dependency is also known as coupling and DIP reduces coupling between different pieces of our code through the use of abstraction. Abstractions allows us to combine specific lists of things into ideas or concepts, an extremely powerful tool and one taken for granted everyday in our language.

    If we didn’t use abstractions, every time you or I wanted to talk about a house, we’d have to say something equivalent to, “the thing with a roof, door, windows, plumbing, electricity.” Actually, even these are concepts we’d have to break down into more detail until we end up talking about specific material properties. Thankfully English provides shortcuts for us. Just imagine how inefficient a language would be if we had to explain details each and every time we spoke about common ideas. Well, if you’re coupling classes in software development, that’s exactly what you’re doing. Adding to the MSSQL example, every time your application talks to the database, is just like telling your software over and over what it is and how to use it. .We can instead create a definition, giving our application a common database idea, defining a database’s concepts: i.e., create, read, update, delete and use the concepts instead of the specifics to decouple our code and make it interchangeable. Let’s take a look at some pseudocode:

First we can define the database concept in an IDatabase interface.

IDatabase Interface

Next we can write a specific MSSQLDB class with its implementation details.

MSSQLDB Class

Finally, we can use our abstraction, instead of a specific implementation, so we’re not dependent on the type of database

Using Abstraction in Code

By abstracting our database we can now interchange it with others, we could easily write a class constructor and decide which database to use at run time. We could take it one step further, write a TestDB using the same IDatabase interface, and use it as a completely separate database for Test Driven Development(TDD). Our TestDB doesn’t even have to be MSSQL!

Thanks for hanging with me throughout this SOLID principles series, I hope you’ve enjoyed it and I can’t wait to see you again!

Interface Segregation Principle

ISP

Welcome to part four of the SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new issues in this series..

   SOLID is not a language, it’s not a framework, it’s a set of principles to help guide your team to design better applications. Using these principles will help ensure your code is adaptive to change. In this series, I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles does require a fundamental understanding of classes, interfaces, and class inheritance.

   The fourth letter in SOLID stands for ISP: Interface Segregation Principle. This principle states, ““many client-specific interfaces are better than one general-purpose interface.” I have to confess, I kinda cheated by showing you this principle in my last post on the Liskov Substitution Principle. We used ISP to create a specific interface(IBallerPay.cs) for special employees with offshore accounts, fixing our LSP violation.

    ISP helps prevent fat interfaces, aka Interface Bloat. This isn’t Lord of the Rings style programming here, we don’t create one interface to rule them all. Dare to do so and I can’t promise Nazgul won’t come and find you while you sleep. So why does it matter if we stick methods and contracts inside interfaces we deem worthy?

    Imagine if we created an interface implementing unnecessary methods to all of our subclass. We’d be introducing unnecessary code, since every subtype would have to implement or override these methods whether or not they needed them. At the same time, we’d ensure any changes to our “God” interface would require changes to every inheriting class. On the other hand, if we create specific interfaces then we eliminate unnecessary code, keeping code clean and maintainable. When creating our interfaces, we must ask ourselves if every subtype will need to implement the defined properties and methods.

Next we’ll wrap up our SOLID principles with DIP: Dependency Inversion Principle

Liskov Substitution Principle

Programming

Welcome to part three of the SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new issues in this series..

    SOLID is not a language, it’s not a framework, it’s a set of principles to help guide your team to design better applications. These principles will help ensure your code is adaptive to change. In this series, I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles requires a fundamental understanding of classes, interfaces, and class inheritance.

    The third letter in SOLID stands for LSP: Liskov Substitution Principle. This principle, first introduced in 1988 by computer scientists Barbara Liskov and Jeannette Wing, states, “if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.”  Simply stated, base classes must be interchangeable with other derived classes.

Please do yourself a huge favor and watch Barbara Liskov’s presentation here on programming methodologies.

    In my previous post, Open/Closed Principle, I created an interface, IPay, and created two derived classes, FTEPay and ContractorPay. LSP requires each and every inherited class, FTEPay and ContractorPay, be interchangeable. Currently they fall within the LSP guideline, but let’s say, purely hypothetically, HR had originally requested our pay system to allow upper management to receive payments in their Cayman Island accounts. You know for *cough cough* tax incentive purposes.  We may have been tempted to add this to our IPay interface:

IPay

   Writing this abstract method (SendToBigBallerAccount) inside IPay breaks the Liskov Substitution Principle, since full-time employees and contractors won’t have offshore accounts and therefore can’t implement this method. These derived classes are forced to throw an exception for this method, potentially breaking the application since they are no longer interchangeable with our new BigBallerPay class:

BigBallerPay implements new method

BigBallerPay

FTEPay class throws an exception

FTEPay

   How can we get around this without breaking SOLID principles? One way is to further abstract our new method into a separate interface.  In this example, we’ll move the Cayman Islands pay method from our IPay and existing inheriting classes to a separate interface, IBallerPay:

IBallerPay

   Now our BallerPay class is interchangeable with any derived IPay class, without the application having to worry about throwing exceptions. We can also add new pay types,, C-suite executives etc, to our application without worrying about breaking any existing code..

LSP BallerPay

LSP covers many subtle OOP pitfalls when it comes to substituting types. Here are a few links to get you started with ways to spot, avoid, and refactor LSP violations:

Next week we’ll continue our SOLID principles building on what we’ve learned today with ISP: Interface Segregation Principle. See you then!

Open Closed Principle

SOLID

Welcome to part two of the SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new issues in this series.

    SOLID is not a language, it’s not a framework, it’s a set of principles to help guide your team to design better applications. Using these principles will help ensure your code is adaptive to change. In this series, I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles require a fundamental understanding of classes, interfaces, and class inheritance.

    The second letter in SOLID stands for OCP: Open/Closed Principle. This principle, defined in Bertrand Meyer’s 1988 book, Object-Oriented Software Construction, might first appear to be an oxymoron like Advanced BASIC, Microsoft Works, or American Soccer, but the definition is simple: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” Let’s break it down.

    You should write classes so they can be extended through inheritance, allowing for requirements to change while locking in current functionality. One way we can accomplish this is to write interfaces and abstract classes, in Object Oriented Programming this is known as polymorphism. Covering polymorphic strategies exceeds the limits of a single post, but what you should take away is that your base interfaces and classes should be abstract enough to allow inherited classes to override functionality. Confused yet? Let’s look at a simple concrete example.

    Payroll loved our changes from our last SRP post and the software runs smoothly now. They’d like a new feature to help calculate each employee’s current pay. We quickly whip up a calculate method in our HRM software:

Employee.cs
Employee.cs

    No doubt Payroll loves the change but they soon notice contractor pay wasn’t taken into account. After discussions, we learn employees can be full-time or contractors. Our full-time employees vary in pay rates, but our contractors are set at a pay rate of $12/hr. Since we didn’t leave our code open for extension, we only have one choice: we must modify our existing class:

New Functionality Added to Employee.cs
Employee.cs

    Writing our class this way forces us to change our existing code each and every time Payroll requests a new pay requirement. If we know requirements won’t change, SOLID would fall under YAGNI (You Aint Gonna Need It).. but If we anticipate requirements changing then we’ll need to design maintainable code.

    So what’s the SOLID way? How can we use class inheritance and code abstraction to ensure we don’t change and, therefore, break existing code?. There are many ways to do this, for this example we’ll build a simple Pay interface and two inheriting classes, FTEPay and ContractorPay::

IPay Interface

IPay Interface

FTEPay Class

FTEPay Class

ContractorPay Class

ContractorPay Class

FTEPay and ContractorPay both inherited from the Pay interface and execute different code for their CalculatePay method. This abstractions allows us to move the logic out of our Employee class and use an interface instead. Let’s take a look:

SOLID Employee Class
SOLID Employee Class

Our class now contains no logic for the CalculatePay method, we’ve obfuscated the code meaning we can interchange or “plug-and-play” any class inheriting from our Pay interface. We are free to add new requirements from Payroll and that’s great because they’ve asked for a new pay type for employees in California because of new min wage laws exceeding our 12/hr contractor rate. In a few simple steps we can:

  • Add a new class (CaliforniaContractor: IPay)
  • Write the CalculatePay logic
  • Set the Employee.PayType = CaliforniaContractor for contractors in California

We successfully added new functionality, without touching a single line of existing code🙂

Next week we’ll continue our SOLID principles building on what we’ve learned today with LSP: Liskov Substitution Principle.  See you then!

Single Responsibility Principle

SOLID

This is part one of the SOLID OOP design pattern series. You may wish to subscribe to the blog to stay tuned in as I post new issues in this series.

    SOLID is not a language, it’s not a framework, it’s a set of principles (practices) to help guide your team to design better applications. Using these principles will help ensure your code is adaptive to change. In this series, I’ll be using C# for examples, but the same principles apply to any OOP language: Python, Java, C++, etc.. Using SOLID design principles does require a fundamental understanding of classes, interfaces, and class inheritance.

    The first letter, ‘S’, in our acronym stands for SRP: Single Responsibility Principle and states: “A class should have only a single responsibility.” I’m not a fan of this definition. It’s vague, the word “responsibility” implies too many things. Your code should be responsible for many things: for running, for not containing bugs, for naming conventions, etc. What this principle is trying to articulate is a class should have only one reason to change. Let’s jump into an example to better understand what this means.

    Let’s say the company we work for hasn’t purged termed employees from their HRM software in over 10 years. The software now crawls through hundreds of thousands of records making it impossible for payroll to complete their work by their deadlines. Some employees are understandably furious when they receive their paycheck weeks late. Something must be done. Luckily, our company has a great development team🙂.  After we’ve spoken with our coworkers in payroll, we’ve agreed on the requirements for a solution: We’ll update payroll’s  HRM  software to purge termed employees every 180 days and move old records to a separate database for backup. This will keep the system up-to-date and running smoothly.

If we work in a team new or unfamiliar with programming  principles, it’s likely we’ll see a similar solution to the following:

UML Class Diagram
UML Class Diagram

Pseudo Sample Code:

Code Before SRP

 

Looking at this code, how many reasons for change can you think of? How many different requirement changes could be made that would force your team to change this code?

Here’s a few to get started:

  • HR wants to purge employees from a provided  list instead of relying on DB record details
  • HR wants two options: purge after 180 day and 90 day. The first for full-time employees and the other for contract employees.
  • HR wants to delete all records/backups after an employee record has been purged for 30 days

    Each one of the requests above would mean altering or, perhaps worse, repeating our class object: CleanRecords.cs. Currently, our class has more than one reason to change. For such a simple class, this might not seem like a big deal, but altering your code to add/change requirements leads to overly-complex logic, aka spaghetti code. Altering your code also makes it more likely you’ll break existing functionality and we want to remove any likelihood of this when, not if, requirements change. .

    We’ll need to change the class so that it only has one reason to change. We’ll separate each responsibility, each reason for change,  into separate classes, a process known as encapsulating.  Once we’ve encapsulated our employee, backup and delete logic into separate classes, our new CleanRecords.cs class will have one responsibility:

Cleanup After SRP

    Our class is no longer responsible for where and how employees are set and it’s no longer responsible for any database logic. It’s only reason to change now is if the process itself changes.  The classes single method, Purge, accepts three parameters: an employees list interface, a backup interface, and a delete interface. Let’s first look at the interfaces and  then what value we get out of this structure.

IGetEmployees | IDelete | IBackup

IGetEmployees IDelete IBackup
Using these interfaces as parameter types in our CleanRecords.cs’ Purge method allows us to “plug-and-play” inheriting classes . As requirements change, we can call the Purge method any way we’d like. For example, we could call the employees from the DB like so:

Purge(EmployeesFromDB, BackupEmployees, DeleteEmployees)

If HR wanted to use a file instead of getting employees from the DB, we could call the exact same method and pass in a class importing employees from file:

Purge(EmployeesFromFile, BackupEmployees, DeleteEmployees).

We could change data sources, databases, etc. All without changing a single part of our existing architecture or disrupting working code in our application.

    Your classes and interfaces should be so simple, that it becomes hard (almost impossible)  to write bad code. With SRP we get the benefit of modular parts we can interchange. It forces us to write simpler code making our application more maintainable. We no longer require ourselves to change our main class or  interfaces when requirements change. Instead, we can now add functionality to our existing/working code.

    Next week we’ll continue our SOLID principles building on what we’ve learned today with the OCP: Open/Closed Principle. See you then!

Rock SOLID!

Rock Solid - ScrumBlogMillionaire.com

    Rocking SOLID should be a top priority for any team coding in OOP. SOLID is a group of design principles which offer guidance to developers designing and coding complex applications. But, before I begin I have to rant. Professionals in any field love to create complex jargon through legalese, academese, and other species of “intellectual” and pretentious vernacular. Maybe it helps them feel big, special, smart, or part of a clique. Who knows. Whatever the reason, it’s crippling to those learning and damaging to those trying to communicate with others. Einstein said it best, “If you can’t explain it simply, you don’t understand it well enough.”

    SOLID may be intimidating the first time you come across it; the principle names ring of scientific conceit but don’t let this keep you from learning. Over the next 5 posts, let’s get together and break down each principle. We’ll look at how teams adopting SOLID have given rise to clean, concise, and maintainable code.

Part 1: SRP – Single Responsibility Principle

Part  2: OCP – Open/Closed Principle

Part 3: LSP –  Liskov Substitution Principle

Part 4: ISP – Interface Segregation Principle

Part 5: DSP – Dependency Inversion Principle