# Skypager Project / Portfolio 

**IDEA**: Take full advantage of naming conventions and patterns 

You will notice the following about our file structure:

- ./Helpers/models
- ./Helpers/models/Component.js
- ./Helpers/models/DataSource.js
- ./Helpers/models/Project.js

From the file structure alone we can deduce that among these files, there are several types of files which  
all seem to be a type of `Helpers` called `commands`.  If we look more closely at them, we can see they all export 
a javascript module that has a similar structure:

```javascript
export const execute = (options = {}, context = global) => {
  const { project } = context
}

export const command = (commander) => commander
  .program('myCommand').
  .usage('usage description')
```

What this allows us to do is write a common and abstract interface on top of 
ever expanding collection of different javascript modules that amongst ourselves, we refer to as commands. 

**Note:** The technology this project is based on doesn't need to dictate very much about what 
exactly a command does, or what modules and third party libraries commands depend on. 

It doesn't provide much outside of ways for leveraging the ability to make certain assumptions about our code 
based on what names we give to the things inside of our project and where we store them. 

People who work with Ruby on Rails are going to be very familiar with this concept, and i only recently 
learned of the name `Inversion of Control`, which is how people describe this pattern of building larger applications
and having a framework look for certain types of functionality in certain folders in the project.

As helpful as this pattern cane be, applying these ideas in Javascript is still very labor intensive. For people who do not work with 
monolithic frameworks, enjoying the benefits of this practice is still mostly personal, or mostly manual and 
dependent on people learning the system.

## Products 

This section describes the different folders of the project which contain source code and assets for products 
produced for the purposes of supporting interaction with this portfolio, such as in the 
form of an API, Website, Desktop App, etc.

### App
> an Electron App that uses React.js and the React Semantic-UI component kit

### Documentation
> A Website with information about the design, concepts, and other details for this project

### Server
> A Realtime API for interacting with the portfolio especially in development and test, but also in production. 

## Collections

This section describes nested subfolders which are deliberately named according to specific categories 
which can communicate essential facts for how the projects are used. 