num_jenny - A Versatile Number Generator for the Security Mindset

A helpful ruby class for all sorts of security projects...this class is a member of my periodic table of classes.  Get it here:

https://github.com/ninp0/num_jenny 

It's pretty cool since this ruby class can be invoked to produce all types of numbers!

require './num_jenny'
# Only needed for last example
require 'creditcard'

n = NumJenny.new
puts n.range(:start_with => 0, :end_with => 10)

n.range(:start_with => 0, :end_with => 9999, :pad => true).each do |pin|
  puts "Attempting: #{pin}"
end

puts n.range(:start_with => 0, :end_with => 10, :random => true)

puts n.range(:start_with => 0, :end_with => 10, :pad => true, :random => true)

puts n.range(:start_with => 10, :end_with => 20, :pad => true)

n.range(:start_with => '1-493-555-0000', :end_with => '1-493-555-9999', :random => true).each do |phoneno|
  puts "ATDT#{phoneno}"
end

n.range(:start_with => "344543800000000", :end_with => "344543800999999", :random => true).each do |ccno|
  puts "Valid #{ccno.creditcard_type} Card Found: #{ccno}" if ccno.creditcard?
end

Cheers!

Streamlining the Evolution of Application Development by Developing a Periodic Table of Classes

"The best designs are those that mimic life."

Remember the aforementioned statement, as it's critically important to reflect upon this statement as you read further.

Now, when we begin to imagine how the  building blocks of life interact and bond with one another at a sub-atomic >> atomic >> molecular level to form more self-aware and complex forms of life, it's easy to consider how those building blocks of life provide an excellent model to approach object oriented design within applications we write for ourselves and others.  "Phew, that was a long run-on sentence to consume..."  Run through it again.

Atoms, when bound with other atoms, produce various compounds (molecules).  For example, two Hydrogen atoms and one Oxygen atom when bound, form a single water molecule.  Now stay with me here, there's a point to all of this...that is if you haven't already started to understand why this is such a beautiful mindset to develop when designing applications.

When new programmers design code (and I've certainly been guilty of this as well), it's pretty common to write an application top-to-bottom...in one file.  Cool, it works...at least for the time being.  We do this because we have deadlines and we believe it's the fastest way to accomplish our goal or the goal of our employers.  It's time to think differently now that we're stepping back a bit further, thinking deeper, and really wrapping our minds around the bigger picture (all in the spirit of supporting maintainability, scalability, re-usability, interoperability, and my favorite collaboritive code to share with one another).  While we're here, let's ask ourselves...aren't we sick of copying and pasting code or worse yet, sick of writing the same code snippets over and over?  Me too.

An application can become harder and harder to manage over time as change presents itself.  Change is inevitable and this is especially true over longer periods of time - more folks depend on your application because hey, it makes their life easier right?  As a result, new requirements also present themselves - life never seems easy enough for most.  This is perfectly okay because it's this fundamental desire that can drive innovation and the progression within all of us.

Unfortunately, the top-to-bottom evolution process likely results in hundreds, if not thousands of lines of code all managed in a single file (or a small collections of files).  It's likely we can all agree that wrapping our minds around the logic contained within hundreds, if not thousands of lines of code in aggregate simply becomes...a huge pain in the ass.  In simpler terms this approach could be described as the, "Dodo Bird Approach" to development - a development design mindset that can't adapt to it's ever-changing and demanding environment - ultimately leading to its extinction.

Now, back to life's approach to design - particularly at the atomic/elemental level.  Looking at the periodic table of elements we start to notice a pattern - all elements/atoms contain certain properties that define how they behave.  For the context of this post, we will assert that the properties of an element/atom are synonymous to the methods/functions/subroutines found within a particular "elemental/atomic class."

What this means from the perspective of a developer is the need to create our own "periodic table of classes" - each with their own specific properties (public/private methods) small enough to share and use interchangeably to streamline the application development process.  The classes only focus on accomplishing a specific task and should only focus on that task.  An example of this may be an "element" designed to connect and interact with various types of databases.  We instantiate a collection of various "elemental/atomic classes" to create a complex organism (the application), capable of evolving in a manner that makes it more efficient through its evolution process.

In essence, when we think of object oriented design in this context we are actually thinking about how to design code in way that is meant to be shared, providing an opportunity to learn from one another.  This in turn promotes innovation, an efficient evolution process to support the ever-changing demands of our environment, and ultimately a means to present a better quality of life for one another.  Big things start really small and as a person smarter than Myself once said, simply put...the best designs are those that mimic life.

An excellent book around more design patterns is called, "Design Patterns: Elements of Reusable Object-Oriented Software"

I hope this mindset helps you as it's certainly helped me...

To see code using this design methodology check out this git repo:
https://github.com/ninp0/kore_kit

Cheers!