Skypager

Skypager is a high power, low code, automated software publishing platform. It aims to make it very easy to deploy react applications for the web and native platforms. I created it because I believe that everyone should be able to use and contribute to the improvement of growing libraries of software modules and components, and all of the automation capabilities they offer, not just developers. Anyone should be able to come up with ideas that combine existing capabilities in unique and novel ways, or in very common ways that might have their own unique twist. Everyone shouldn't need to hire a developer to do this, and at the same time everyone doesn't need to sign up for 50 different SaaS products, or spend their life savings on a bootcamp.

Skypager works as a result of collections of software modules that produce a metadata API with tons of information about the project and its code that is derived from the project files and anything else that can be linked to them using at least the names of those files, but almost certainly also the content itself. This metadata is made available to developers, and can be taken advantage of with re-usable plugins, or with a very syntax lite and intuitive set of ES6 Javascript commands that are perfect for people who want to learn to write code themselves.

Technology

Skypager uses ES6 and Babel, PostCSS, Remark (markdown), ESlint, and other language tools because of their rich plugin and extension eco-systems, and because they provide a wealth of metadata about the code, by giving easy access to web developers to the formerly arcane world of source code abstract syntax trees (ASTs).

Skypager makes all of this data available to a Redux data store, which can be connected to actual React applications, in addition to your own custom React applications that you deliver to anyone who wants to express some sort of desire for how the application should behave. Deliver it over the web, deliver it in an email form, deliver it as a desktop application.

It is up to you.

Skypager provides project creators with a system for declaring the meaning and intention behind the folder names they use:

``javascript
import Skypager, { configure, describe } from 'skypager'

configure({
source: 'src',
output: 'dist',
presets: ['react-boilerplate'],
})

// a lot of this will just be inferred if you leave it off
describe.source({
components: ':groupName/:name/index.js',
routes: ':groupName/:name/route.js',
})

describe
.components({
// Skypager will search the portfolio for editors/ComponentWorkbench
editor: {
type: 'ComponentWorkbench',
options: {
savesTo: 'github'
}
}
})
``

This gives developers the ability to develop user interfaces that they can hand off to somebody else, and that interface can accept the user's input and store it in a way that can be used by the software project. The simplest example would be using a color coder and SVG upload form to get CSS color variables and an icon font from a designer, but the possibilities are endless. A content management system for your client, that gets stored in your source code, and which you can edit by hand in your IDE or with a custom script before deploying to the web or app store.

Why did you make it

What if we could relive the glorious period of technology that emerged when we all abandoned our web applications based on custom portfolios and SQL Database Backed CGI Apps, for the convention and configuration approach popularized by Ruby on Rails? Where might we look for another transformation like that occur?

It is unlikely that it will occur because of a Portfolio or a language, or a combination of the two. In my opinion, the Ruby on Rails revolution was less about Ruby and Rails than it was about the power that comes from the single act of taking something from the real world, giving it a name, and saving it in a file in a designated folder. Think of what happens to the possibilities once this crucial piece of information is decided?

The next revolution in software productivity needs to occur -- and naturally will occur -- it will do so not only in the form of clever patterns to use inside of our software project folder, but in the clever patterns that we apply across the dozens of other project folders we are connected to, especially the folders of people who are not developers at all.

Skypager enables a model of collaboration where anyone can contribute directly to a software project, using the tools they love and are trained to use, without repeating themselves, and without even thinking about it thanks to webhooks and other events we can easily detect. These contributions can easily be converted, streamed, transformed, combined, whatever the developer wants to or needs to do.

But not only can anyone contribute, anyone can inspect, query, or generate any type of file or visualization they want using everything that can be known or calculated by analyzing the names in a software project and following the relationships to other files and systems really, anything that can have a URL.

The goal is to take these capabilities, and build the best possible custom user interfaces for working with them.

What is it?

Skypager provides a powerful automation layer for anyone with a growing collection of software projects that have some core web and mobile user experience. The more projects you develop, and the more obvious the patterns are which naturally emerge in your work, or in the process you use, the more Skypager amplifies what you can be capable of.

In Skypager you have a portfolio that consists of Projects -- real world, prime time Projects. Baller projects. These are, really, whatever your beautiful creative imagination can come up with. And you can do with them, all the things you do. These possibilities are beyond my comprehension. You are the domain expert, your audience, your people. I want you to reach them, and I want it not to suck for you, I want it not to suck for your user, and I especially want it to suck less for me if I'm in the process of building, maintaining, debugging, and supporting the software.

Skypager is intended to help domain experts benefit from the same techniques developers user in our work. Version control, continuous delivery, automated testing, and especially convention over configuration, or inversion of control. Developers use these ideas every day, but very rarely are these ideas broadened in their applications or scope, beyond the source code itself.

What stops organizations from using the same convention over configuration assumptions in the organization of all of their work? In my experience, I believe it relates to the fact that developers are, for the time being both Gatekeepers and Enablers of every amazing power the internet gives to people.

The Skypager Portfolio approach to Software Projects

When I say projects do you think of full websites and webapps? complete products with multiple apps on different platforms, front end and back end? do you think of packages or modules? themes, UI Components, API Integrations, Messaging and Content Blocks, Sign-up Forms?

Skypager uses the powerful webpack module bundler to give teams the highest quality build tooling and development environment, and takes advantage of webpack's unlimited support for loading any kind of file you're accustomed to seeing as if it were javascript. Skypager integrates with services like Github, Dropbox, and Google Drive, and turns them into streams of events and data that can be used to power other applications, or produce other kinds of content, hopefully you get the idea.

Skypager can work for you as a single developer, or it can work for you as a large team of people, even with more non developers.

Getting Started

- If you want to jump right into using Skypager, see the Getting Started Guide
- If you want to learn more about some of the concepts, see Key Concepts
- If you want to see some examples of things that you can build, see Example Projects
- Otherwise, you can read the API Documentation