## Searching Algorithms In Javascript

Searching is fundamental to any programming language. It would be a waste to have data structures, and no way of searching through them. Searching is fundamental in in life (we even search for the meaning of our very own existence), so it only makes sense that after we create collections of data, that we want to search through them. By searching we are able to find answers to problems we are trying to solve. Take a phone book for example, or a telephone directory. Most of these come with tools that help make search relatively simple. For example, there are guides within the book that show you which letter you are currently on (making it easy to jump quickly to a section). If you wanted to call “Konstantin Addaquay” for example, you would just go the A section, which gives you listings of all people in the area with a last name starting with the letter A. Now imagine that telephone directories didn’t come already sorted alphabetically. It would be almost impossible trying to find someone in there (so many entries). Searching and sorting go hand in hand in computer science. Most of the time, the most efficient way to search is to have data that is already sorted. That is why this post and the next one will be covering searching and sorting algorithms.

## Javascript Graphs

Graphs are mind blowing! The first time i studied graphs and its applications, i was simply in awe. The first thing one might think when they hear graphs is to think of some kind of chart or diagram. But that is not the case. They are actually derived from the study of networks and are an extremely hot topic these days. We have all used graph applications without even realizing it. Social media and social networks (Facebook, Twitter, Instagram, etc), the internet, etc. are applications of Graphs, and are used to model many real world systems, like airlines, road traffic, communication, etc. Graphs also fall under the non-linear data structures, but take things to a whole new level. You can even think of linked lists and the binary tree data structure as a form of graph (so we have been using graph applications without even realizing it). Linked lists have node connections from one node directly to another node, and binary trees have one node which could potentially connect to 1 or a maximum of 2 nodes. With graphs any node could potentially link to another node within the collection. So it is not limited as linked lists or Binary Trees. Lets look at our first graph.

## Javascript Trees

A tree data structure is very similar to a linked list. Where linked lists linear (meaning we have each node in the collection pointing to a next node in a fixed sequence), a tree data structure is non-linear. This means we can have each node potentially pointing to one or more nodes. Think of a trees as a way to order things hierarchically. Example are, graphical representations of data (like an organizational charts), files in a file system or even sorted collections of data. When working with trees, order of the elements is not important (if it is, you can store your collection in a linked list, stack, queue, etc). Lets take a look at an example of an organizational chart ( a type of tree structure showing hierarchical data ).

## Hashing

In the last post we talked about Maps. We learned that Maps can be referred to as dictionaries, associative arrays, etc. Sometimes you will also hear Maps or Sets being referred to as a Hash ( You will hear  the likes of HashMaps or HashSets ). These types of key/value pair collections, are “Hash-bashed Data Structures”. What is hashing? In my very first post on data structures, i mentioned that Linked Lists are faster at adding data quicker to a collection, than it is at retrieving. Hashing is a way of storing data that makes retrieval and access extremely fast (Runtime complexity of O(1) for both retrieval, access, and deletion operations). Our collection is stored in a data structure known as a hash-table. This table is what makes data retrieval and storage so fast. When we looked at Maps in the last post (or even linked lists), anytime we wanted to find data, we had to traverse the whole collection in order to find it. Given a key, we would enumerate the whole thing for its value. Therefore it would take a long time we had a huge collection. Hash tables can be used to solve this problem. When using hash tables we can find data in the shortest amount of time because we already know which position in the table the value is stored. Like an array, we can retrieve the value at position 4 instantly. But as we said in the previous post, writing a statement like state[4] does not convey meaning (number index based structure, what if we don’t know its location?). When we tried to solve this problem with maps, we looked at how to write data structures so we could retrieve them using syntax that looked more like this state[‘NY’]. The only disadvantage here is we still would have to enumerate the entire object to get its value (though the syntax was nicer). Hashing employs a technique using something called a hash function. Given a key, it is passed to a function, and a value is returned right away (the key is hashed into a value). That value is used as an array index(in the hash table to retrieve values). The value of the index can be retrieved instantly because of its array nature.

## Maps (Dictionaries) & Sets

As we journey down the lane of data structures, you may or may not have noticed a pattern for how we access data. Since the underlying data storage we have used have been arrays, we have had to rely heavily on using numeric type indexing to retrieve values. Even though in stacks and queues we were only interested items at the top or front, indirectly we were still using some sort of indexing to get those item values. Also when we did traversals in our data structure, it was based on indexing. While this has served us well, sometimes you want to put more meaning into how you retrieve values. Asking for items[0], doesn’t really give a clear definition of what is being asked for. In this and the next post, we will be talking about accessing data based on meaningful keys/names. Think of a real world dictionary for example. Every word in a dictionary has a meaning. You can think of a word as a key, and the meaning as a value. So in essence you are using one unique word to look up a meaning. A key mapped to a value ( key/value pairs). Notice that dictionaries do not have duplicate keys. If you need the meaning for a word, for e.g engineer, you will not find the key twice. You may however find multiple meanings under that key word. Lets think of another scenario where you might want to use a dictionary. What if you wanted a data structure where you could find a state name based on abbreviation? Like NY (key) for New York (value), or CA for California. We are not using an index here. We might access it like this instead state[“NY”]. We are using a unique identifier to refer to a particular state. This is when we use the dictionary data structure. Dictionaries are also referred to as maps, and may be the preferred word to use depending on the programming language. Dictionaries, associative arrays, maps, … they all mean the same thing! We will be referring to them as maps from now on.

## Javascript Queues

In the previous chapter, we learned about the Stack data structure. We will be talking about javascript queues in this post. The difference between a stack and a queue is the way items are added and removed. While items in a stack are LIFO collections, items in a queue are FIFO (First In First Out). A queue returns items in the same order it way added. The first to get in, is the first out! Lets see how this relates to the real world. Think of a grocery store or the bank cashier for example. The people who join the line, checkout out in the order they got in. If you are in line first, you get served first. If you are last in line, you are served last. Anyone who enters the bank goes to the back of the line (in queue). The same applies when you tell a printer to print a document. The items to print are queued, and are printed on a first come first serve bases. In software development, queues are used in multi threading and concurrency situations, where tasks that are waiting to be processed, are executed in an order of FIFO.

## Javascript Stacks

In previous posts we learned what data structures are and their importance when engineering software applications. In this post, we will learn a new data structure called a Stack, and find out what benefits it gives us when storing and organizing data. What is a stack? Well, the meaning is in the idea of the word. Think of a stack of books or papers in a bookstore, or a stack of dirty plates in kitchen. The idea is we have a container (our stack) in which things (data) are stacked on top of another. We are trying to organize data in a stacking order, hence the name. When we add an item, it is added to the top of the stack. And when we remove, we also remove from the top. So think of javascript stacks as a collection in which data is added or removed in a Last In First Out (LIFO) out manner. Lets take a look at a simple diagram.

## How AEM Works!

Adobe Experience Manager (AEM) is massive. There’s a lot of confusion when most developers and content editors come to this proprietary content management system. There are new terminology, processes and tools that one must understand. It can be overwhelming. Though it is impossible to write everything about AEM architecture in a single post, I wanted to write a post detailing some fundamentals for developers, but could still be read by anyone already working in AEM (using a language everyone can understand). So this is not a deep dive type of post. Understanding how AEM works will help you as a developer or author have a better insight into issues you may be having. My aim in the post is to give you the BIG picture. This is AEM architecture fundamentals.

AEM is a cloud based client-server system for building enterprise grade websites and applications. A copy of AEM running on a server is what you would normally hear of being referred to as an instance. The installation of AEM usually involve two instances running on separate machines on a production site. These is the author and the publish instances. Most of you know what the author instance is. This where you edit content. By editing content, i mean this is where you create, upload and management content on your website. Pretty much any website administration is done on the author instance (the name make sense since you are actually authoring content). Typically a content editor logs into AEM, edits or creates a page and either put their work in some kind of workflow for it to be approved, or perhaps they just publish the page when that content is ready (which goes live right away). What happens in the background, most of us don’t know. Here is where i want to shed a little light on because i feel knowing it gives you better insight into issues that might come up.