Seven Lessons about Tech and Life

As an artsy, outdoorsy type and a middle school humanities teacher in my mid-thirties, I am the last person you would expect to see in the role of intern at a cloud management platform like Sunshower.io.

Perhaps we can blame Marie Kondo for my transition into web development: I started off cleaning my house and by the time it was decluttered I had a new career plan. More likely we can point our finger at a bottle of wine and a dead-end career in education. Together, they conspired to make me complain to my sister and brother-in-law over dinner about my professional woes. (My sister and brother-in-law are the CEO and CTO, respectively, of Sunshower.io.)  By the end of our meal, he had suggested I go into tech and she had given me an internship.

That was four months ago. The past few months have taught me a few lessons about tech and life:

Lesson #1: You have to start somewhere, and you’re not going to learn it all in a day.

I started with Sunshower.io knowing the bare minimum of the tech it takes to keep a 21st century classroom running. I certainly did not know about IAM, AWS, EC2 management, or cloud cost optimization or why one would care about any of it.

Lisa and Josiah showed me crazy computer things that I had never seen before: pug, github, git, command terminals, Docker, and dev environments. We like to call this steep learning curve “Depends for the deep end” because, sometimes, you end up over your head in code and it’s so scary you want to pee yourself.

Honestly, needing Depends for the deep end is not only okay but expected. Lisa started off her software engineering career with a wee bit of CSS and HTML and a master’s degree in public communication and technology. Josiah was a math major. They both taught themselves everything they needed to know (using life lessons 2 and 3; see below), and they still have days where they have to ask each other questions or take brain breaks to figure out solutions.

Where does this leave me? Having a lot more patience for the learning process. Whether you learn a little bit every day–or, per the Sunshower.io experience, a lot in one day–you will start stockpiling an impressive amount of know-how.

Lesson #2: When in doubt, look it up online.

While Sunshower.io’s people look out for each other, it is also a culture of rugged individualism. When you are working for people who built up their skill set from scratch without help, there is minimal patience or time for hand-holding.

You have to learn to find answers on your own. And you will.

Lisa broke me of the habit of asking too many questions early on. When I would ask her something easily answerable, she would ask what I thought or whether I had looked it up. Pretty soon, I would answer my own questions before she could reply, and finally I stopped needing to ask. Except for unanswerable structural questions, that is, which leads us to lesson 3.

Lesson #3: If you can’t find it online, ask.

For a newb, solutions are easy to find online. However, when you are collaborating on projects like Sunshower.io’s visual modeler, distributed virtual machine or cloud optimization machine learning algorithms, in the end you often HAVE to ask about the factors that might be standing in your way.  

Lesson #4: Be patient. Tech is a rollercoaster of successes and failures.

Some days, your code will work perfectly. You will build something awesome and post your progress on social media. Your dev environment will load perfectly, and you can check off your to-do list in an hour.

Other times, you will run commands in your terminal, and it will take hours and still won’t work. You will run tests through your IDE, and it won’t work…and won’t work…and won’t work.

Lisa taught me that a big part of tech is being comfortable with the failures and dead-ends. Your code won’t always work. And that is okay. Maybe tomorrow you will ask the question that leads you to the solution you need, or perhaps the quick-fix to your broken code will dawn on you at a gloriously random moment.

So pour yourself a cup of coffee, sit in front of that computer screen, and buckle your seatbelt. See where today leads you.

Lesson #5: Have a dog close by.

Between the three founding members and me, we have three dogs, and they are always close at hand. When Sunshower did its QA night, during which we ran the web application with three people clicking buttons simultaneously, we ran tests while dogs roughhoused in our laps and under our feet.

Lisa and Josiah’s mini aussiedoodle Fran forces them to take breaks. Lisa’s brain breaks involve playing with Fran on the floor, and Josiah takes Fran for long runs before he starts working for the day.

In addition to forced breaks and relieved tension, dogs simply remind you not to take tech or life in general too seriously. Having a dog roll over on your laptop keyboard or drool on your computer screen reminds you that, no matter how important your tech projects are–and they are–they are just tech projects.

When the going gets tough, rub that belly or scratch those ears. You’ll figure it out. We promise!

Lesson #6: I will never, ever work as the chief of anything for a company. Ever.

Despite what I knew about Lisa and Josiah’s work days, I tended to romanticize what they did. Work all night? Sleep until noon? Take breaks when you want? Code your way to your dream life? Yes please! Sign me up!

I did not truly comprehend their daily grind, and I seriously questioned their love of cartoons as entertainment (really guys?), until I started working with them. Their work days start at ten in the morning and go until midnight if they are lucky. Josiah has been known to pull multiple all-nighters a week while tackling infrastructure projects. Lisa had chronic shoulder and forearm pain from typing for 14 hours a day that was only cured by throwing down over $80 for a split keyboard.

However, these epic workday ultramarathons have paid dividends. This week, they came in second place in the pitch competition at Fort Collins Startup Week. They have six clients and more in the wings. It is commendable. Truly.

And I would not wish it on anybody.

Lesson #7: Tech is about people, experiences, and services.

Tech is not just about the code you write or the tests you run. It is about connecting with Lisa and Josiah about their QA needs and with Tif about blog posts like this one. It is the Sunshower.io home office: a north-facing former bedroom in their Fort Collins home, the window opening to farmland. It is the late-night walks that help you work out your code, the new people Lisa adds to LinkedIn, the friends I have made through tech meetups. It is the hundreds of hours spent on a service that can save companies thousands of dollars on their monthly AWS bill. It is the scrappy tech stars working long hours to bring their services to life for future clients. Code is only the beginning.   

All source can be found at: Aurelia-Aire

Testing UI components is one of the more difficult parts of QA. In Stratosphere (one of the key components of our cloud management platform), we’d been using Karma + Jasmine, but the browser component had been complicated by the fact that providing a DOM to tests in a fast, portable manner subject to memory and speed constraints can be pretty challenging. Sure, initially we did the PhantomJS thing, then Chrome Headless came out, but writing UI tests just never really felt natural.

Then, last week, we decided to open-source our component framework, Aire, built on top of UIKit+Aurelia, and that created an exigent need to fix some of the things we’d been limping along with, most importantly testing. The success of OSS projects depends on quite a few things, but I consider providing a simple way to get contributors up-and-running critical.

Simple set-up

Internally, Aurelia uses an abstraction layer (Aurelia PAL) instead of directly referencing the browser’s DOM. Aurelia will (in principle) run on any reasonable implementation of PAL. Aurelia provides a partial implementation OOTB, Aurelia/pal-nodejs, that will enable to (mostly) run your application inside of NodeJS.

Project Structure

Our project structure is pretty simple: we keep all our components and tests under a single directory, src:

aire
├── build
│   └── paths.js
├── gulpfile.js
├── index.html
├── jest.config.js
├── jspm.config.js
├── jspm.dev.js
├── package.json
├── package-lock.json
├── src
│   ├── main
│   │   ├── aire.ts
│   │   ├── application
│   │   ├── button
│   │   ├── card
│   │   ├── core
│   │   ├── core.ts
│   │   ├── dropdown
│   │   ├── events.ts
│   │   ├── fab
│   │   ├── form
│   │   ├── icon
│   │   ├── init
│   │   ├── init.ts
│   │   ├── loader
│   │   ├── nav
│   │   ├── navbar
│   │   ├── offcanvas
│   │   ├── page
│   │   ├── search
│   │   ├── table
│   │   ├── tabs
│   │   └── widget
│   └── test
│   │   ├── button
│   │   ├── core
│   │   ├── init
│   │   ├── render.ts
│   │   ├── setup.ts
│   │   └── tabs

...etc

At the top of the tree you’ll notice jest.config.js, the contents of which look like this:

Basically, we tell Jest to look under src for everything. ts-jest will automatically look for your Typescript compiler configuration, tsconfig.js in its current directory, so there’s no need to specify that.

Our tsconfig is pretty standard for Aurelia projects:

Test

If you just copy and paste our tsconfig.json and jest.config.js files while following the outlined directory structure, everything will Just Work (don’t forget to npm i -D the appropriate Jest and Aurelia packages.)

At this point, you can use aurelia-test to write tests a la:

hello.html

hello.ts

hello.test.ts

Now, you can run your tests with npx jest:

aire@1.0.0 test /home/josiah/dev/src/github.com/sunshower/aurelia-aire/aire
npx jest

PASS src/test/button/button.spec.ts
PASS src/test/tabs/tab-panel.spec.ts
PASS src/test/init/init.spec.ts
PASS src/test/core/dom.spec.ts

Test Suites: 4 passed, 4 total
Tests: 12 passed, 12 total
Snapshots: 0 total
Time: 3.786s
Ran all test suites.

Enabling support for complex DOM operations

That wasn’t too bad, was it? Well, the problem we encountered was that we use the excellent UIKit framework, and they obviously depend pretty heavily on the DOM. Any reference in Aire to UIKit’s Javascript would fail with a ReferenceError: is not defined error. Moreover, if we changed the Jest environment from node to jsdom, we’d encounter a variety of errors along the lines of TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node' which I suspect were caused by pal-nodejs creating DOM elements via its own jsdom dependency while Jest was performing DOM operations using its jsdom dependency. In any case, the solution turned out to be to define a single, global jsdom by importing jsdom-global. Once we discovered this, we encountered other issues with browser-environment types and operations not being defined, but this setup.js resolved them:

At this point we could successfully test Aurelia + UIKit in NodeJS.

The final piece

All of our component views are developed in Pug, and I didn’t like that we’d be developing in Pug but testing using HTML. The solution to this turned out to be pretty simple: adding Pug as a development dependency and creating a pretty simple helper function:

With that final piece in place, our test looks like:

Conclusion

The benefits of writing tests in this way became apparent the moment we cloned the project into a new environment and just ran them via npm run test or our IDE’s. They’re fast, don’t require any environmental dependencies (e.g. browsers), and allow you to run and debug them seamlessly from the comfort of your IDE. But, perhaps most importantly, these are fun to write!

As a kid, I remember having my mom drop me off at the library so I could rummage through the card catalog. I still have warm-and-fuzzy nostalgic feelings about spending hours pulling books off the shelves, checking the indexes, and finding exactly the pieces of information I needed. It’s a nice memory, but would I trade away the Internet to get another chance at flipping through musty drawers of tiny typewritten cards? No way. You’d have to be bonkers to go backwards and do research like that. I’d rather sit at home in my pajamas and access hundreds of sources online in seconds, thanks very much.

Innovation is a funny thing. We get so accustomed to doing something one way, that it never occurs to us that it could be different. Better. Think about all of the things we used to consider perfectly fine until we figured out a better way:

• Driving to the store to rent a movie (RIP, Blockbuster)
• Placing a personal ad in the newspaper
• Pulling over to make call from a pay phone
• Planning a route using a tri-fold city map
• Sending a fax
• Looking numbers up in the Yellow Pages
• Listening to music on a Walkman
• Checking out what’s on tonight in the TV Guide
• Using a typewriter with a bottle of Wite Out handy
• Checking spelling using a dictionary
• Looking facts up in an encyclopedia
• Keeping business contacts in a Rolodex
• Calling the theater for showtimes
• Making a mixtape

At one point, someone asked: Why isn’t there a better way? Then they changed the game.

That’s what we did for the cloud at Sunshower.io.

People used to think it was okay to be surprised by their cloud bill, or to spend hours, sometimes days, sometimes months, deploying applications. We used to find it totally acceptable to ask developers to become experts in how to deploy their software, while still … you know … finding the time to actually write said software. Not anymore. Sunshower.io has all the tools you need to work with the cloud faster, simpler, and more efficiently than ever before. We’re a cloud management platform that’s dedicated to offering better cloud resource management strategies and simple cloud cost optimization tools.

Why take a boat across the ocean when you could fly? You have stuff to do, deadlines to meet. Check out our beta on DigitalOcean to see how we can offer you a more innovative cloud management system.

When you’re spending your days (and nights) developing the best cloud management platform possible, blogging consistently is hard. That said, we’re redoubling our efforts to get content out semi-regularly, even if it’s just to post something simple and (hopefully) helpful. To that end, I’d like to discuss setting up Github pages with a backend.

The Problem

 

Github.com allows you to host static content via its pages feature.  This is fantastic because it makes it trivial to create, deploy, and update a website.  This is how https://sunshower.io is hosted.

But what if you wanted to interact with, say, a database, to track signups?  Furthermore, what if you wanted to do it all over TLS?  This tutorial presumes that your registrar is AWS and your DNS is configured through Route53.

 

Set up Github DNS Alias Records For Github Pages

This one’s easy: In your Route53 Hosted Zone, create an A record that points to Github Page’s DNS servers:

>185.199.110.153

> 185.199.109.153

> 185.199.108.153

> 185.199.111.153

 

 

Then, check in a file in your pages repository under /docs called CNAME containing your DNS name (e.g. sunshower.io)

 

Push that sucker to master and you should have a bouncing baby site!

 

Publish your backend with the correct CORS Preflights

We pretty much just have a plugin for Sunshower.io that registers unactivated users.  Create an EC2 webserver/Lambda function/whatever to handle your requests.  The thing you have to note here is that your backend will have to support preflight requests.  A preflight request is an OPTIONS request that your server understands, and responds with the set of cross-origin resource sharing (CORS​ ) that your backend understands.

This is because your page, hosted at a Github IP, will be making requests to Amazon IPs, even though both are subdomains beneath your top-level domain.  For a JAX-RS service at, say, https://mysite.com:8443/myservice, you will need two methods:

 

@Path("myservice")
@Produces({
MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML,
})
@Consumes({
MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML,
})
public interface SignupEndpoint {

@POST
RegistrationConfirmationElement signup(RegistrationRequestElement request);
@OPTIONS
Response getOptions();
}

Note that there must be an @OPTIONS method for each actual conversation method that you want to interact with (e.g. the @POST method here).  What will happen is that a preflight will be made to the same path as the request, and the server will respond with whether that request is allowed.  You can widen the scope of @OPTIONS responses, but you should have a pretty good reason for doing so.

 

The actual @OPTIONS method will look something like:

@Override
public Response getOptions() {
return Response.status(Response.Status.OK)
.allow("POST")
.header("Access-Control-Allow-Origin", "*")
.header("Access-Control-Allow-Methods", "POST, OPTIONS")
.header("Access-Control-Max-Age", 1000)
.header("Access-Control-Allow-Headers", "origin, x-csrftoken, content-type, accept")
.build();
}

where the allow value and Access-Control-Allow-Methods values align with the request type of the actual backend methods.

 

Set up a SSL-enabled ELB

The first thing to do here is to create a certificate using AWS’s wonderful Certificate Manager Service.

Request a certificate by navigating to Certificate Manager > Request a Certificate in the AWS Management Console.  Request a public certificate, and then request it for the fully-qualified name that you want your backend to appear under (e.g. backend.sunshower.io).  If you have access to any of the follow e-mail addresses at your domain:

• administrator@your_domain_name
• hostmaster@your_domain_name
• postmaster@your_domain_name
• webmaster@your_domain_name
• admin@your_domain_name

then select e-mail verification, otherwise select DNS verification and proceed according to the instructions provided by AWS.

 

Once you’ve verified your certificate, create an elastic load balancer on whatever availability zones your backend spans.  If you only have one instance in one availability zone (shame shame!), add that availability zone first.  Create a listener targeting the port that your actual backend is listening on, and add a security group with an ingress port that corresponds to the port that you want your public-facing backend to listen on (for instance, if you want your backend to respond to requests to https://backend.sunshower.io, configure your ingress to be 443.

From there, configure a target that points to your actual backend. If your backend is hosted on EC2 instances, select the instance type for the target, otherwise select ip.  Reference the IP/instances of your backend and create the ELB.

 

Configure a DNS A Record for your ELB

The last thing we need to do is create an A Record that points to your ELB.  If, previously, you requested a TLS certificate for backend.mysite.com, you’ll want to create an A-record whose name is backend, alias=true, with an alias target that is the ELB you created in the previous step.  Save that sucker and you are good to go!

 

 

 

We’re thrilled to announce a preview launch of Sunshower.io, a cloud management platform that offers cloud resource management and cloud optimization. ! I’d like to take a little time to explain what we do.

Beautifully Simple Multicloud Management

The first thing we do is provide a simple, unified interface for managing your public clouds. This means that you provide some read-only access to your cloud, which we store securely in our vault, and then we go discover whatever infrastructure is in your cloud(s) and manage and organize it for you.

Let me step through a quick example or our public cloud management system:

Discover your Resources (aka “Systems”)

The first thing we need to do is to discover your resources. Upon logging into Sunshower.io, you’ll be presented with the System Discovery Wizard. A System (i.e. Weather System) is the set of all infrastructure associated with a set of cloud accounts. So, if you have:

• 1 Azure Scale Set with 4 active members that is your development cluster (azure-dev)
• 1 Azure Scale Set with 20 active members that is your production cluster (azure-prod)
• 1 AWS Autoscaling Group with 10 active members that is your AWS dev cluster (aws-dev)
• 1 AWS Autoscaling Group with 30 active members that is your AWS production cluster (aws-prod)

Then you will create a system with at least 2 credentials, one for AWS, the other for Azure.

You can add as many accounts from as many cloud providers as you want. Each of the cloud providers is implemented as a (relatively) simple plugin, and if you add a new plugin (e.g. Google Cloud), you’ll be able to add credentials for that cloud, too.

Once all your accounts have been added, we’ll go through and perform the actual discovery. Once that completes, you’ll be presented with a topological overview of your cloud infrastructure:

The group color is used in the topology view as the color between edges of nodes, and in the geography view to color connections between regions:

And yes, you can totally spin the globe!

Use Your Groups

Grouping is pretty fundamental to Sunshower.io:

• Access control is based on groups
• Management operations can be performed on entire groups (yes, you can spin down every node in a cluster by stopping its group)
• Deployments are based on groups

For instance, you can SSH into an individual machine or an entire group. It’s pretty typical to have a ton of identical machines, so executing the same series of commands produces identical output from each machine. We de-duplicate the output and provide you with the results. Just store your private key in our vault (the actual key is stored in the excellent HashiCorp Vault). But, hey, tailing logs across a bunch of machines has never been so easy!

Visual Deployments (aka “Strata”)

One feature that we’re really excited about is visual modeling of deployments. Basically, you start off with a series of commands (e.g. shell commands), and you compose them together:

From there, you can select a deployer format (e.g. Docker or Packer or even just the userdata section of an AMI, whatever you have plugins installed for) and viola! You have a deployment that you can share with coworkers, publish to everyone, or share with a specific group. For instance, you might create a Stratus that

• Installs Java
• Installs NodeJS
• Installs Gulp

And you can generate a Dockerfile for it, a Packer file, an Azure Image, or an AMI without changing a thing!

Visual Infrastructure Modeling for Systems

But let’s say you don’t have any existing infrastructure and you want to create some. Now, you can log into your various cloud providers’ consoles and spin up whatever you need, but what if you want to create some infrastructure and try it out across clouds? Enter our visual infrastructure modeling for Systems. You can quickly model your infrastructure and deploy it out to any supported cloud (below is the cluster structure for Sunshower.io’s deployment)

You can also export the model to a variety of provisioners like AWS CloudFormation, Azure Resource Manager, or Hashicorp Terraform. We’re currently figuring out what generating Kubernetes manifests looks like, but you’ll be able to do that soon too.

Finally, Anvil for Cloud Optimization

All of the data that we collect about your infrastructure we use to build a model of your tasks. If you think about purchased infrastructure as a shipping container, then it makes sense to purchase the smallest shipping container that can fit all of your packages. Anvil extends this analogy by allowing you to define new dimensions for your packages (think 5 or more), and we’ll figure out the smallest shipping container with those dimensions possible across any infrastructure for which there’s an infrastructure plugin. For instance, here’s an example of us spinning up a suboptimal configuration of resources and running Anvil on it:

It yields a much more compact (dense) configuration for your infrastructure. In fact, it typically yields an optimal configuration. You can even configure it to model packages based off of their greatest historical dimensions (like peak hours) so that you’ll never under-provision again, even while saving a substantial amount on your infrastructure. The result is total cloud cost optimization.

Conclusion

Thanks for sticking around! I wanted to provide a list of Sunshower.io’s current features to give everyone a better idea as to how it’s used and what it can do for you. Many people will only need one or two of the features, and we’d like to get some feedback as to which might be the most valuable for your organization so that we can get them to you ASAP.