The Best Of The Best

Hi folks...

...We here at OmniTekk believe that reading is truly the gateway to the foundations of learning.

And besides, who doesn't just love a good book.

So in the spirit of sharing...'cause we care, we've compiled a list of our picks of the 5 best I.T. good reads.

And without further ado...

1) CODE By Charles Petzold

First of all, Charles is a New York native, so not only is he a highly prized I.T. author, but obviously the guy's got swag!

CODE is a brilliantly written book on the foundations of computing and the interworkings of the computer, all with an interesting and vividly crafted chronicle of a few historical facts on the talented guys who've made noteworthy contributions to the field.

2) THE ART OF COMPUTER PROGRAMMING By Donald Knuth

Knuth is the authority on the highly prized talent of 'programming the computer' by way of elegantly structured algorithmic puzzles that help solve some of our most difficult automation tasks.

TAOCP is a 4 volume series that truly serves to enlighten readers on the critical mathematical concepts that help the novice and seasoned developer alike, design sophisticated computer programs.

The Boxed Set Includes

• Volume 1: Fundamental Algorithms
• Volume 2: Seminumerical Algorithms
• Volume 3: Sorting and Searching
• Volume 4A: Combinatorial Algorithms

We should probably warn you that this set is fairly comprehensive, so I recommend the journey be taken on only by my serious programmers...

...not to worry though, if you do delve into the heavy stuff, we promise...you won't be dissapointed.

3)DATA STRUCTURES AND ALGORITHMS MADE EASY By Narasimha Karumanchi

This book is by far one of the best there is on dymistifying the very necessary and equally complex concepts of data structures and structural programming techniques.

DSAAME helps readers easily learn almost all there is to know of data structures, complete with comprehensive programing examples that help developers lighten the load when it comes to tasking themselves with writing the codes involved in algorithmic programming methods.

Definitely one of OmniTekk's faves!

4) COM AND .NET INTEROPERABILITY by Andrew Troelsen

Although this one's a bit dated, it is one of the best readings on the subject of interprocess communication, specifically with regard to the Microsoft brand of programming languages.

COM, as complex of an undertaking as it is to understand conceptually, is crafted with easily digestible tidbits of information that help the COM developer manufacture elegant processes that allow for 'poly-lingual' communications to be developed across the Microsoft suite of languages.

A must have in your arsenal of books on IPC for the Microsoft Windows PC developer.

5) WRITE GREAT CODE by Randall Hyde

Last, but certainly not the least, this insightful 2 book set on the primary constitutes of developing professional quality computer applications is packed with a ton of valued information on the tricks of the trade used by our most prized developers.

A true gem in helping developers better understand and apply low level programming techniques to high level programming languages, making way for writing efficient applications.

The Volumes Include

• Volume 1: Understanding The Machine
• Volume 2: Thinking Low-Level Writing High-Level

And there you have it folks...Good Reads Served. 

OmniTekk hopes you've enjoyed our picks of THE BEST OF THE BEST, and until our next I.T. adventure my friends...be well.

Data Structures

 Structuring Data

Here’s the scenario…

…You’re learning something new. And while the instructor is yielding the information to you and your class group, like the desultory methods of any other unorganized fellow, he jumps from subject to subject. So within a couple of hours you learn a few minutes of mathematics, yet still a few of social studies, and still again some other rhetorical learning subject, with none in such a way that you might utilize to make sense of.

And while I hate to break the good news to you, this is precisely how most of what we learn is constructed, making it especially difficult to grasp, hold on to or even connect the dots so as to form larger conceptualizations from the information we receive…pretty unorganized wouldn’t ya say?...yeah I must say I agree.

Not to worry though, our exceptionally smart machine developers have devised methods that help us better organize information so that the data we store in our software applications give us efficiency aim at grouping and retrieving data so that we mightn’t make the same mistake as our poor old desultory teaching instructor.  

This is what the use of data structures in our computer programs help us do.

How so Omnitekk?... 

Hmmm… let’s us have a look.

Just as we use specific methods of organizing the information we receive, to efficiently process and retrieve at some interval, it is always good programming practice to store relative clusters of data within groups of structural data sets, in our effort to improve data retrieval efficiency within our software applications.

Further, the use of data structures allows developers the added benefit of utilizing computer memory and addressing in such a way that the seasoned developer can make the best use of minimal storage assets within the computing ecosystem.

Information is stored in most machines using addressing schemes that make efficient use and retrieval of the groups of information closest to it. 

For instance, isn’t it far easier for you to retrieve an item that just happens to be closest to you than one farther away?

This is the same logic our computer folks used to design the addressing schematics within most computing machine environs.

And while fallacious to say that all data structures are stored in a sequential manor, when we programmatically group data, our programs do have the means of accessing relative information, such as records in a file, in such a way that allows machine processing methods to be implemented with higher efficiency.

But wait…it gets better!...

…we haven’t even covered all the nooks and crannies of the “Data Structure”…So shall we?

The Casting Call

When it’s cold outside, most none of us would wear shorts or t-shirts – except maybe those guys who polar bear dip in the arctic, but we’re not them…now are we? 

Any who, when it comes to the types of data structures or data organization methods we use to store, process and retrieve the data within our software applications, the data structure types we choose should largely depend on quite a few factors…such as

How The Data Will Be Used 

A few things to consider here is whether your software application is going to simply store, and retrieve data or shall it be some culmination of data processing types? Likewise, will the data be sorted or in unsorted form, or will it have a one-to-one data correlation or a one to many or even a many to many data relation? 

Data Size 

Some data structures yield far greater efficiency with smaller datasets than others, especially when it comes to data retrieval. You might ask yourself whether your application is designed for miniscule data inputs or whether you’re designing an enterprise level application. 

knowing the expected data size design specifications should help you choose the most efficient data structure to use for your project.

Data Structure Order

Some data is best used in first-in-first-out (FIFO) order, such as in a data queues, which we typically see in our lines at most stores. The first one to arrive is usually the first one to be attended to – unless someone cuts the line of course. There are also information storage processing types that utilize last-in-first-out (LIFO) processing method, such as stacked data or even the clothes you layer on. The top layers(last ones placed) are usually the nearest accessible(first one to come off)…like your coat for instance.  There’s also data priority structures, such that information is processed by its most critical use or priority.

Data Complexity

Some data can be easily grouped for storage, processing and retrieval using simple methods of structural data formations, while other data design methods are best constructed using a complex data structure to best represent the nature of the data solution.

Knowing whether your design goals call for a simple implementation, such as array data structures or something of higher complexity, such as a graph or map data structure to best represent your programming application can mean the difference in designing an efficient programming solution vs. one that’s inefficient

Data Type 

Some data structures work best with string data, such as string-matching algorithms, while others for other types of data, such as numerical data.

The Structures

There’s an array of data structures we might use to group our data for storage, processing and retrieval…ARRAYS being one of them…no really.

So let us have a look at them shall we?

Arrays

Array Data Structures are linearly organized or daisy-chain like data structures that are grouped in sequential addressing fashion where all data is adjacent to neighboring data.

Likewise, with few exception, array sizes are usually predefined prior to structure implementation, making them unfavorable if data is expected to grow or shrink exponentially. 

Linked Lists 

We might think of Linked List Data Structures as chain-like data grouping programming methods that follow a sequential forward or backward data retrieval scheme, where data is stored and retrieved usually by traversing or traveling the list using the neighboring data nodes within the list as counters into resident list data. 

And while linked list insertion and retrieval methods can certainly prove unorthodox, in retrieval method, especially for the crafty or artistic developer, they do typically follow specific implementation methods.   

Stacks

We’re stacking crates one on top or above the other. As we remove the stack of crates, so as to retrieve the contents, the last one placed, is usually the first one retrieved. This is the way Stack Data Structures work. They are usually last-in-first-out (LIFO) data structures, meaning that the data placed using this type of structure is retrieved in reverse the order they were placed. 

Queues

We’re waiting in a long line, a little anxious of course, but who isn’t. we just want to pay for our things and spend what’s left of our day salvaging through our purchases, marveling at what we’ve bought. Those in the line are usually processed in the order of arrival. And this my friend is the Queue Data Structure.  

With queues, the data retrieved is usually that which was first placed, as they are  first-in-first-out(FIFO) data structure types.

Trees

Now here my friends is where our data structure journey can get a little tricky.

Tree Data Structures are structures whose data connections can represent one-to-one and likewise one-to-many clustered data representations, making data traveling or traversal within the tree structure quite intricate.

Tree data structures follow the notion of a predecessor, successor nomenclature or naming convention whereby successor nodes are linked to specific predecessor nodes, which are linked to new groups of successor predecessor node groupings and so forth, all stemming from a single predecessor.

The basic concept of trees is in their clustered or branch-like nature, just as the branch, leaf, and bark structural leanings of actual trees.

Priority Queues And Heaps

Priority Queues function much like ordinary queues, with the exception that they don’t necessarily follow the stringent ordering of our dear unprioritized FIFO data structures. Instead, with priority queues, data is usually process in some contrived order of importance. So the data entered into the queue isn’t necessarily the data that will be processed in fashion as it was entered, or in other words, priority queues don’t necessarily follow a sequential pattern of data access or retrieval.

In the other cart on our train session here, Heap Data Structures can be thought of as trees that typically follow a sequential hierarchal priority data retrieval method, such that the predecessor is either greater than or less than the successor value nodes.

So like the priority queue, the storage and traversal method of accessing data in the queue is contingent on the neighboring node cluster value in that it’s value is connected to the way data is placed onto the tree structure by order of numerical value. 

The tree is either growing in value or shrinking, meaning the tree data values are increasing or decreasing as we traverse the heap left and right.

Disjoint Sets

As the name implies Disjoint Set Data Structures are open clustered tree structures that typically don’t follow the normal tree design methods of implementation. They might be thought of as incongruent tree data structures, such that the “clustered” tree connections or data nodes might be formed from numerous trees joined together to construct an accessible data relation or set of data items. 

Graph Algorithms

If you haven’t already figured it out yet from our provisional expose, data structure design and implementation methods increase in complexity from simple structures to ones that are quite complex, just as many real-world examples, such as a data representation of houses on a single street, requiring only a linear or simple data construct to represent versus the representation of a whole city, state, region or continent locality information. 

Such is the notion with Graph Algorithm Data Structures. 

Graph algorithms are structures similar to trees, except instead of representing a one-to-one or one-to-many data relation of connected predecessor successor pairings, graph data structures can represent many-to-many data representations, meaning there isn’t necessarily a single predecessor successor dynamic.

A group of successors nodes can have numerous predecessors, or we might think of these structures as a poly or matrices data representation instead of hierarchal ones.

Hash Tables

Hash Table Data Structures, like graph data structures, can depict many-to-many data representations. 

Unlike graph representations though, with hashing, the data represented is usually indexed using a key-pair data retrieval scheme that allows a single key to index a record of data values. 

With hash tables, the many-to-many relationship structure uses a few crafty tricks of the trade to retrieve numerous values using one key indexer.

Deconstructing

And that’s it folks, we have reached the end of our data structure journey...Data Structures Served...

I should probably note that there are a few lesser used, really complex data structures, such as Data Maps and Data Dictionary structures, but they aren’t much different than the ones presented here.

In fact, they are best described as the culmination of those listed.

I hope you enjoyed our walk down Data Structure Lane.

And until our next IT adventure my friends, OMNITEKK says be well.

So Just What Are Computers Anyway...

 Making Things Count…Literally

Our computing devices have managed to do what man has always longed to do in his (or should I say our…I am of the sapient kind also) quest for perfection…To process information without flaw.

And when programmed efficiently, they do just that!

I like to think of the machines of today as the ultimate reflection of both our (got it this time…yaay) ego and our leanings toward omniscience and omnipotence. 

I mean after all, how is it that we’ve managed to make something in our own likeness, that has actually outperformed even us, a fact that isn’t even prevalent in our good book of the holiest of holies - if not an act of self-prescribed omnipotence.

And I myself must say, the creation such creators have created is majestic to say the least…isn’t it?

Our workflows and levels of productivity have made way for some of the highest advances we’ve seen in human history…thanks to the computer.

We’ve used computing to solve some of the most sophisticated and complex scientific and mathematical conundrums known to mankind.

And both the industrial, commercial and personal use of machines have allowed us to delve into vestiges man dare not.

But let’s not digress – the title here is on making things count, so let us take a deep dive shall we.

Let us first consider this…

… Just as the human computer computes things, from the concrete and tangible to the abstract, so does the COMPUTEr.

Unlike humans though, the machine isn’t efficiently designed to compute abstractions, but is perfectly designed for calculating numerical data. 

But OMNITEKK…if computers are just really expensive calculators, then how do they craft such fanciful applications?...

…Why the same way we do of course.

They receive a function of inputs, just as we receive stimuli and then compute those inputs and render results in all sorts of fun ways.

The result might be shown as a window…we might view a picture or video. We might even have a look at our own reflection or of a provision in the functionality within our favorite software program…all through the use of numbers...It’s really quite brilliant if you consider it. 

Suppose I have some derivation of a number or scale of numbers, such that if a specific factor of my prescribed number is provided, I might supply a given visual response, or do a certain thing. 

That’s it folks…Computer Served!

A few really smart guys who obviously had way too much time on their hands and were obviously lazy – I mean who in the world could make something to do for him what he himself could do  - have managed to devise all sorts of interesting ways that calculating machines can present functional visual information based on number crunching.

So the primary premise of computing is a functional INPUT - PROCESS – RENDER means of presenting information to end users.

The central theme of how our computing machines receive, process and present information from user inputs, lie in their ability to receive a specific set of data based on our most prized mathematical formulae.

Oh Ok…I see OMNITEKK…

…So what does all this mean for the casual user, like me?...

No thing at all my friend. You can go on with your computer escapades just as you’ve always done.

Our folks here just thought it’d be cool to give you a little insight. That’s all.

Hope you enjoyed this brief little expedition of our journey down computation lane.

And until our next IT adventure my friend…OMNITEKK SAYS be well.

 

OSI Typological Analogy

 Clothes And IT - Layering Them On

When it comes to learning all those tricky little details in the world of computing and technology, most of us haven’t the IT abstractions demystified in such a way, that we can pragmatically apply what we know to help us build complex data applications and network transmissions.

And for the beginner and lightly seasoned developer… THAT’S OK… 

…there are layers upon layers of what can seem like sorcery to the average programmer who hasn’t yet dared to delve into the naked truth underneath all those layers of…shall we call them clothes?

The hierarchal and structural levels of both the mechanics and machinery involved in computing, as well as the supporting software protocols most view and reference simplistically, are actually quite complex, with some of the most advanced concepts of mathematics and computational theory observed and applied, making the machines and machine-like electronics most of us use daily, true mechanical marvels, to say the least.  

Let’s undress a little of it…shall we. 

The layered schema of what is known as the Open Systems Interconnection Model, or OSI for short, is a typological representation of the networking protocols used to receive, process, display, and share our computational data with the help of easy to use “windows” and graphical user interfaces that elegantly dress complex processes. 

So OMNITEKK… just what is this OSI typology…

…Let us demystify things a little with a warehouse packaging analogy shall we…

 

But first, my friend, I must provide those foundational concepts that help give us an overview of the typology first, so here goes.

The hierarchal typology is comprised of 7 layers of interconnected or networking protocols that essentially serve different functions, while also acting as “checks and balances” to those contiguous protocols most closely connected to it, to ensure that each layer or level within the typology maintains adherence to specific structural design methods.

A pictorial of the layer nomenclature or names are as follows - 

And now for our explanatory analogy highlight….

Let’s say we are workers at fictious warehouse company EFGlobal, who receives, sorts, routes, and delivers packages to their assigned destinations using the OSI typological designations. 

They manage to accomplish this within the context of the 7 layer Typology in the following ways -

Application Layer

The Application Layer or Human Machine Interface Layer (HMI) is designed to provide a layer of abstraction that seamlessly allows end users to interact with the computer without having to completely know what’s happening outside of what they see - or better phrased, outside of the application visuals. 

This layer is where most “window based” software applications are presented to the end-user. 

In our warehouse, this layer represents the packaging of all contents received, routed and shipped. For workers in our warehouse to successfully ship packages to their final destinations, we need not know what’s in them, we simply need the geolocation routing data, expected package receipt time, and who should be receiving the packages so that we know the who, where, and when in the 5 W’s concept of Who, What, When, Where, and Why.

Presentation Layer

Like a good circus show, before the audience can view the act, it has to be rehearsed so as to ensure its final presentation meets praiseworthy standards. This is precisely what the presentation layer does.

It acts as an intermediary between the application layer visuals and those attributes and protocols that have to be perfected or (presented) to ensure the end-user HMI is constructed as it should be.

Likewise, this layer also enforces encryption protocols and usable interface formats.

We aren’t interested in circus acts though are we…for all intents and purposes we don’t work at the circus, we’re warehouse workers. So, let’s visualize our warehouse process shall we... I digress…I digress.

In our warehouse, this layer is responsible for ensuring that all packages arrive in the best fashion possible. Who wants to anxiously await a package, only to find broken contents inside when they open it…no one!

So, in our warehouse, we ensure that all our packages are received as they should be. We use protective bubble wrap to protect package contents, we use tape to protectively seal the packages so the contents don’t come out and we might even add special stickers so that our delivery workers know to handle certain packages lightly. 

Session Layer

Sessions are the chronicles of reference where all communication between interfaces are maintained…so time is of the essence here…literally! 

The session layer maintains communication between nodes, user-computer interfaces and networked connections between them. 

We might think of this layer as our warehouse manager of operations communications, as it synchronizes and orchestrates all communications occurring between end-user applications so that we know when our packages will be sent to or received by end users. 

At this layer, we also keep a recorded account of our package locality information, so that we know where they are, so we don’t lose them.

Transport Layer

This layer is responsible for delivering messages between network and host. If we think of nodes or computers on a network, then the transport layer is responsible for directing the traversal of information between them. 

At this layer, specific protocols used to communicate package information are also enforced and observed so as to prevent data loss and data collisions.

Analogically speaking…as we move packages through our warehouse, at this layer, we determine how the packages will travel. 

For instance, will they travel by bus, car, plane or train. 

There are also a few checks performed, to ensure that all end-user addresses or destinations are in fact valid so that packages are delivered without fail. 

Network Layer

The network layer determines which physical or actual path a node on a network will take to deliver a communication between them.

Just as there are quite a few paths we can travel to reach our destination we have to choose one, and most of us (or at least those of us who mightn’t choose to meander as we travel to enjoy the scenery) choose the shortest route possible. This is the tasked function of the network layer.

Back at the warehouse, once our guys have figured out how those packages are going to travel, they should probably decide on a mapped travel route to get them there…shouldn’t they?

DataLink Layer

The datalink layer is the intermediary between point-to-point networking hardware or nodes on both end-user networks, such that the tangible peripherals that catalyze or facilitate the communication between all other layers on the network, and likewise their subsequent communications, occur as designed without fail.

In order for our warehouse operation to successfully deliver packages to all those lovely patrons, all other communicative processes must be properly coordinated so that we have happy consumers.

Those working in the warehouse must communicate within the facility so that packages are received, sorted, assigned a destination and route, and finally expedited to their destinations. 

Likewise, the base warehouse workers must also have a means to communicate with the transportation folks while packages are in transit, especially in the event that some sort of anomaly or problem occurs.

So, the entire family of warehouse workers procure the necessary communication channels, ensuring all package deliveries are routed as they should be.

After all, at EFGlobal we take pride in our means of ensuring our package delivery processes are the best in the business…And oh yeah…the folks here marvel at the chance to make consumers happy. 

Physical Layer

The physical layer comprises all the tangible components within the computing ecosystem that allow for all other communication between nodes, whether on a closed or unitary system or as a cluster of networked nodes to occur seamlessly and contiguously.

It includes all networking peripherals and hardware on the network alike, that make the communication channels necessary so that data is transferred across physical media, such as ethernet cables, routers or other tangible networking devices.

Our package delivery warehouse system has to have not only the manpower to coordinate the corporate processes that prepare our packages for delivery, but it also needs the tools to accomplish it all.

Let’s see here…There’s the warehouse equipment, the vehicles used for transportation of the packages, and likewise, the communication devices that allow all workers to communicate with each other, such as radio devices etc.  

Have The Clothes Come Off...

Omnitekk sincerely hopes you have a better sense of how computers help other computers and those natively networked software applications, communicate across a network.

If my anology helped you figure out a few things... Network Typology Served...

Until our next IT Adventure my friends.....Omnitekk says - Enjoy.