WTF is The Cloud, SaaS and AWS?

First of all, I really hope you are using cloud-to-butt right now (available on Chrome or Firefox). It makes the Internet a sillier place and will make this post much more fun to read.

Second of all, I tend to be a literal person and I understand things better when I can touch them and take them apart. Whenever I try to learn abstract concepts, I have to relate them to physical objects so that I can understand them better. When my friend Namrata did a lightning talk on JavaScript libraries at DBC, it didn’t click for me until she explained that the performance cost of using a library is like a human being who speaks a different language from you having to physically run to a library and look up words every time you speak to them. That’s why I try to think of physical or well-known examples to help me understand concepts. They’re not always perfect, but they help.

So with that, here is my understanding of The Cloud:

The cloud is not your computer’s hard drive. It’s not an external hard drive. The cloud is a server or a computer or something that exists somewhere else that you have to use the Internet to access. You can store stuff on the cloud. You pay for space.

This is totally how I imagined The Cloud, as millions of servers floating on actual clouds in the sky!

This is totally how I imagined The Cloud, as millions of servers floating on actual clouds in the sky!

It’s sort of like having a storage unit. If you only need a small amount of space you can rent a locker and use it to store small items. If you have something large like a jet ski that you need to store, you need to rent a larger space. There are security issues with storing your stuff elsewhere. If someone breaks into your storage unit and steals your jet ski, the storage unit company is usually not liable. You need to have insurance on that jet ski. If someone hacks into the cloud and steals your information, the company hosting the cloud is not liable.

The problem is, sometimes you don’t even realize that you are using the cloud. Apple’s default iCloud settings automatically back up copies of any picture taken with an iPhone to remote servers. It’s not like you buy a jet ski and bring it home, meanwhile your storage unit automatically stores a copy of the jet ski to provide you with a backup.

Google Drive is an example of cloud computing. It allows you to create and store documents that you can access from anywhere via the Internet. Compare this to an MS Word doc that you have saved to your computer’s hard drive. It’s more easily accessible, you can share access with other people, but (in most cases) you compromise some level of security.

There are other issues too, like ownership of the materials you are storing on the cloud. When you upload a photo to Instagram, according to their Terms of Service, you retain ownership of that photo. This is different for every single service and in order to find out if you’re about to give away your rights to your content, you need to actually read the ToS instead of just clicking the checkbox that says you’ve read it.


So that’s my understanding of the cloud. Next on the list is SaaS or Software as a Service.

SaaS is software that is in the cloud, that you access via the Internet instead of installing it on your computer. Usually you buy a subscription to the software and that gives you access. As a user, you don’t need to worry about upgrading or maintaining the software, and as a developer you don’t need to worry about whether your customers are using an outdated version of your product.

It’s kind of like buying a subscription to Netflix (streaming not discs) instead of buying a bunch of DVDs. You pay a monthly fee for the ability to watch a movie and you don’t need to worry about owning a DVD or Blu-Ray player or storing all of the discs. The downside is that you rely on the SaaS provider to not disrupt service (and in the case of my Netflix example, you rely on your Internet provider to not throttle your bandwidth).

Imagine Homer as Comcast or Verizon and Bart as Netflix or any video streaming service.

Imagine Homer as Comcast or Verizon and Bart as Netflix or any video streaming service.

OK, last but not least, what the hell are AWS (Amazon Web Services)?

Amazon provides things like storage, databases, email clients, search clients and lots of other little pieces that you need to build software. Similar to how SaaS is convenient to your customers because they don’t have to install or maintain your software, using AWS for your databases means that you don’t have to build a server farm to host them (maintenance becomes somebody else’s problem) and you can scale up or down as needed. You can buy access to as many virtual servers (which are different from virtual machines) as needed, so you don’t actually have to own any of the hardware. I think I signed up for the free trial at some point? I’m not sure. I’ve never actually used it.

So that’s what I learned today. I also got a basic understanding of Elastic Search, but I need to do some more research before I can write a blog post on it.

Helpful Links:


As always, if you see something that is inaccurate PLEASE let me know in the comment section! I’m still a beginner and I can’t continue to grow if no one ever corrects my mistakes. Thank you!

WTF is Continuous Delivery?

One of the products that I am learning how to support at work is an advanced Continuous Integration and Release Management system. For starters, those are very big words (worthy of capitalization) and I don’t know what the hell any of it means!

Some of the instructors at Dev Bootcamp attempted to teach us how Agile Development works…but not really. None of us actually practiced agile except for having daily stand-ups where we talked about blockers and successes.


Fast-forward to now, and my job is to support several tools for Agile Development. I really needed to learn this stuff. I figured out most of it on my own just from watching, but today I decided to sit down and patch some of the holes in my knowledge. Here it is, laid out for you:

First up, how does software even get made?

When you’re in school or bootcamp, here is your process:

  1. Someone tells you to write some code.
  2. You write the code.
  3. You run some tests to see if the code works.
  4. If it doesn’t work, you try to fix it.
  5. Sometimes the code works. No one knows why.*
  6. You submit your code for review by your instructor, possibly by pushing it to GitHub, or by deploying to Heroku, or something.
  7. You’re done. Go have a cookie!

* Magic. That’s why. magic

In a workplace that practices Agile Development, here is your process:

  1. Identify a need (aka, what am I building and why am I building it?)
  2. Flesh out the idea (what are the specifics? create a blueprint.)
  3. Design the thing (what features should it have? what user stories?)
  4. Code the thing (allocate tasks to designers, developers, etc)
  5. Test the thing
  6. Integrate the thing into existing code base and test that too
  7. Deploy the thing to production (OMG it’s live and everyone can see it!)
  8. Maintain the thing (bug fixes, documentation, etc)
  9. Repeat

What does continuous delivery do?

Some of the above steps can be automated to make the whole process faster. The faster you push a bug fix or a new feature, the happier your customers will be.

When you use continuous delivery software, here is your process:

  1. Think up the idea
  2. Flesh out the idea
  3. Design it
  4. Code it
  5. Each time you make a commit, it triggers a build server to package the code and send it off for testing. You should treat any commit as if it could cause your code to be deployed to production and released to your customers.
    • You could manage this with Feature Toggle, which allows you to manually toggle something on when you’re ready for it to be deployed. That way you don’t have a panic attack every time you write a commit.
  6. Code is automatically deployed to different environments and tested there (unit tests, functional tests, integration tests, etc) and if any of them fail the process stops and you are alerted.
    • Your code is deployed to a bunch of performance machines which triggers a suite of performance tests
    • Your code is deployed to a user acceptance server for beta testing
    • Your code is deployed to production and released to your customers
  7. Maintain your code, fix some bugs and write some documentation to help your friendly support people troubleshoot the thing.
  8. Repeat

Ok that’s great, but how does it work?

First you need Continuous Delivery software. I’m not going to turn this blog post into an advertisement for Go, but I am going to mention it because it’s the only software that I’m even remotely familiar with.

Here’s what the automated build-test-release cycle looks like:

First you need to link your software to a version control system, like git. Remember how every time you make a commit, the software triggers a build server that packages the code and sends it off for testing? In order to make that happen you need to connect git (or svn, or whatever you use).

Next you set up a pipeline. What do you want the CD software to do? Run a testing suite? Deploy to a server? Then set up some environments like production, testing and development. Do you want Feature Toggle? Set that up! Do you want a fart noise to play when there’s a failed test alert? Set that up! Every product will be configured different, but some things are universal.

Here’s a good blog post on Continuous Deployment by Eric Ries on what CD software can do.

Helpful links:


Just like before, if you see something wrong or not-quite-correct in this blog post, speak up! Leave me a comment explaining what parts I got wrong so that I can continue to learn from them!

Never stop learning, especially at work

I graduated from Dev Bootcamp. I got a job. I’m a total n00b in an entry-level position. It’s completely understandable that I don’t know anything everything and need to ask questions all the time. And yet, all of my experience at various workplaces up until now has taught me that I should know what I’m doing, I should walk in the door automatically knowing how to do my job, and if I don’t know how something works I should be able to figure it out on my own. Bothering people with questions is a good way to make people think that you are incompetent and should be fired.

That, of course, is bullshit.

In some cases it’s completely 100% true (I can think of 2 companies in particular where my bosses discouraged questions and often looked at me like I was a complete idiot for asking them anything), but it’s still bullshit.

I’ve mentioned before that I did not attend DBC to learn how to code, I learned how to learn. I learned how to reject all of the things that I was taught in traditional education, such as how to stay quiet when I’m completely lost or confused because I don’t want to hold up the rest of the class with my questions,
and how to recognize the superego voice that lives inside of me and invokes such feelings as the “Fear-of-Looking-Stupid” and “Feeling-Defensive-and-Sensitive-When-Facing-Criticism.”

That being said, it’s very easy to learn these things and to practice them inside of the bubble that is DBC. It’s 1000000x harder when you’re in the real world and you’re completely on your own. The rest of the world did not go through empathy training. There is no counselor sitting nearby who you can talk to about the difficulties that you are facing. There are no coaches who have been in your shoes and can reassure you that you’re not alone. It’s just you. Sometimes you can get together after work with members of your cohort, but they’re not working by your side anymore and ultimately your career and the decisions you make are in your own hands.


That’s a very long way of saying, I’m still a n00b (do the kids still say n00b? Do I sound like I’m stuck in the 90’s and early 2000’s when I say that? Am I getting old? UGH!). I still don’t know stuff and I’m still learning stuff. It’s time for me to start blogging about the technical things that I am learning in hopes that other people can chime in and help me, just like I did in Phase 0 and throughout DBC. I can’t write about everything, because some information is sensitive to the company, but I can write about a lot of things.


Here are some of the topics that I am completely clueless about:

  • Elastic search
  • Deployment (I often deployed to Heroku when I was at DBC by sacrificing chickens* and chanting**. I almost never got it to work. It’s all magic.)
  • AWS (I vaguely understand what “The Cloud” is, in the same way that I vaguely understand what a car’s transmission is. It’s the thingy that lives under the hood and changes gears. The Cloud is a remote server somewhere that is someone else’s problem. That’s it, that’s all I know.)
  • SQS (Freaking acronyms! Also I understand what the concept of a queue is, but I have zero practical knowledge.)
  • Librato (So data is information that you gather, and metrics are the charts and stuff that you make to understand the data, and then Librato is something that you use to understand the metrics? I think?)
  • Background jobs (Yeah I get it, they’re jobs that happen in the background, like logs, but how do they do that and how do you set them up and what ARE they exactly? I think this is one of those concepts that is too abstract for me to really understand, so it’s going to take some hand-holding. AJAX was the same type of deal for me. )
  • Redis and memcache (What is caching, anyway?)
  • Continuous delivery, continuous deployment, and deployment pipelines (I don’t even know where to start)
  • SaaS (Your software lives on the Internet instead of living on your computer, I think?)
  • And of course, what the hell is an API and how the hell do they work? (Yes I have worked with APIs, but I completely do not understand them at all! They are 100% magic.)

So that’s just a small list of the things I need to learn. I’m going to start by asking my co-workers for help getting me started, and then go from there. Step 1 is getting over the whole “Fear-of-Looking-Stupid” thing. Everything after that should be easy.




*By “sacrificing chickens” I mean that I sometimes ate a chicken sandwich.

**By “chanting” I mean cursing Heroku, the Internet and computers in general and swearing under my breath.




Current Reading List: Design, Circles and Smoke

The Design of Everyday Things by Donald A. Norman

I love stuff like this. It forces you to stop and really think about the time and energy that went into the creation of the most mundane objects that you use everyday. When is the last time you examined your coffee maker? Do you think about door handles and light switches before you use them? What objects have you used wrong, or didn’t know how to use until you read a manual or were corrected by someone else? This book is the focus of a Udacity course by the same name. In the course, you follow the ideas portrayed in the book (you don’t need the book in order to take the course, and vice versa) and pause frequently to test out the things you’ve learned. The book and course were proposed by my co-workers so I have them to thank for my new obsession.

Sacred Circles by Robin Carnes

This book focuses on women’s spirituality groups, but while reading it I keep thinking of the non-religious, non-spiritual groups in my life consisting of mostly women. I think of the family I’ve built for myself on the West Coast (during the last 3am earthquake we all texted each other just to check in. It made me feel good that there are people close by who care about me and who I can count on.) and the groups I’ve joined (a Knitters/Crocheters Meetup, Book Club, Game Night, Casual Magic The Gathering players, Women in Tech, etc) since moving here in 2012. Each of these groups gives me something. It’s like something inside of me occasionally needs to be filled with a feeling of belonging or purpose. When I sit around with a group of women (and often a few men) and work on a crochet project, discuss the book of the month or write some code, I feel like I was starving and now I’m being fed. Maybe it’s because humans are social creatures (even the introverted ones) and the current social norms prevent us from connecting with other people. Who knows?

Smoke Gets in Your Eyes and Other Lessons from the Crematorium by Caitlin Doughty

Do not read this book while eating, it gets graphic and gross sometimes. Like most modern people, I know nothing of death and the businesses surrounding it. I have no idea what embalming is, or if I should have an opinion of it. I know nothing on cremation or burial practices. I know nothing of different cultural practices involving mourning death or celebrating life. Caitlin of The Order of the Good Death and Ask a Mortician fame (neither of which I knew about before reading this book) has a great voice and interesting stories to tell. I loved this book (even the really gross parts that made me throw the book across the room because I was trying to eat dinner and read), and the fact that I live in San Francisco and actually knew each of the places discussed in the book just made me love it more!

Halloween 2014

We didn’t do much with costumes or candy this year, but we did have fun at a pumpkin carving party with dogs running all around us trying to eat pumpkin seeds off the floor! How was your Halloween?


Sully, Mike Wazowski and Boo




Charlie in the pumpkin patch


Mike Wazowski



Pepper and Sherlock


Sherlock’s Halloween costume!


Pepper and the pumpkins


Pumpkin-orange hair!


Happy Halloween!

Technically Supportive

It’s been a little over 1 year since I applied and was accepted to Dev Bootcamp.

Roughly 1 year since I decided to get serious about making a career change.

1 year of studying, pairing, coding, crying, pushing myself past my limits and ripping out my hair.

1 year of unemployment while I completely devoted myself to programming.

The past year was not pretty, and it sure as hell wasn’t easy.

Now it’s 5 months after my graduation day and I’m sitting at my shiny new desk, with my shiny new laptop, at my shiny new job doing tech support, with my shiny new hair (I went back to bright orange) and I can finally finally finally say with certainty that it was all worth it.




What are your five words?

My allergies were so bad today, I woke up feeling like a tree had punched me in the face. (After seeing an allergist, apparently I’m very much allergic to oak trees and walnut trees. Guess what grows in the Bay Area?) I took some ibprofen for the pain and swelling, and used the Neti Pot to try and flush out my sinuses but there was nothing doing. So instead of volunteering at Railsbridge today, I’m at home in bed with my allergy pills, my cool gel mask and a list of blogs to catch up on.

Jerk tree

Jerk tree

The best thing I read today was Nora Ephron’s quote featured on A Cup of Jo. Ephron and her friends would play a game while waiting for tables in restaurants where they wrote down 5 words that describe themselves, like “journalist, feminist, New Yorker, divorced, funny.” Over time the words change dramatically. Words that so perfectly described who you were 10 years ago don’t appear anywhere on your current list.

My five words are currently “feminist, maker, married, evolving, hopeful.” I was going to add “sinus pressure” in there somewhere, but decided to take this seriously.

I wonder what my five words will be in a year.

What are your five words?


“When Harry Met Sally” written by Nora Ephron

Teaching, coaching and volunteer gigs

Fun fact, it was almost exactly one year between my first Railsbridge workshop as a student, and my first Railsbridge workshop as a volunteer TA! A year makes a HUGE difference!

Screen Shot 2014-08-31 at 1.22.50 PM

Teaching is awesome! It totally gives you a license to be your ridiculous self. I think the more silly and personable you are, the more your students connect with you and understand what you’re talking about. You can lecture on and on about the pros and cons of jQuery and how using it can affect the performance of your program, or you can act out 2 people talking and the one person has to literally go to a library and look up what the other person is saying after every sentence. Which one is more memorable?

If you’re interested in learning how to code, or if you know how to code and want to give back to the tech community by volunteering your time, you should definitely check out some of the meetups happening in San Francisco (most of which are FREE and will help you meet other fun techy people)!

  • For my fellow Jr. Devs who are trying to push our way into the world of programming – The Junior Jump Speaker Panel at CarbonFive
  • For those who want to learn front-end web development, I’ll be volunteering at the next upcoming Railsbridge in San Francisco
  • For those who want to learn git but have no experience with command line interface and have never used the Terminal, I’m teaching a workshop on Git for Absolute Beginners at Hack Reactor. (This meetup costs $20 per person because it lasts all day and we want to order lots of food that isn’t pizza. Most likely Greek, so that we have plenty of GF, veggie and vegan options for everyone.)
  • DBCxSF is the Dev Bootcamp San Francisco meetup, which hosts talks and lectures on a variety of subjects. You don’t need to be a DBC student to attend, and if you’re considering applying to DBC it’s a great way to check out the space!
  • Women Who Code host occasional workshops as well as weekly study groups where you can bring your current project and ask lots of questions.
  • Girl Develop It has some fantastic introductory classes coming up, as well as a newbie-friendly hackathon! I’ll be volunteering as a TA for the JavaScript 101 workshop at Mozilla.

Here is my tentative calendar for the upcoming month (subject to change if/when additional events are announced):


Screen Shot 2014-09-05 at 7.31.36 PM

Open letter to phase 1 Dev Bootcamp students

Hey how’s it going? Welcome to DBC! I bet you’re nervous. I sure as hell was. Don’t worry, you’ll settle in soon. This place is pretty chill. Just don’t be a jerk and you’ll do fine.

One piece of advice that you’ll hear a lot is that you’ll only get as much out of this place as you put into it. I know that’s a cliché but it’s true. The problem is, when I heard that advice I interpreted it as “work really, really hard.” It took me a while to realize that’s not what was meant. Don’t get me wrong, you’re going to work hard. It’s not called bootcamp for nothing. But it’s much more than that.

DBC is a collaborative effort. Every single person in your cohort is there for a reason. You all come from different backgrounds and bring different skills with you. You’ll each learn new skills at different rates. For some people the morning lecture will totally click. For others it totally won’t. This is where the collaboration comes in.

Every single person at DBC is a teacher. All of them. Including you. Especially you. You don’t need to be some kind of super genius or an absolute perfect expert on a topic in order to teach it, you just need to know a chunk of information and believe that knowing said information would be valuable to your cohort-mates.

DBC tries to convey this to you by encouraging you to share “Aha!” moments during Phase 1 and assigning you lightning talks during Phase 2. These are times specifically set aside so that you all can teach each other.

You are not required to save all of your “Aha” moments for the designated time. If you figured something out and want to share your knowledge with everyone else, please do so as often as possible! Make an announcement that you’d like to do a quick breakout on whatever topic you choose, gather anyone who wants to listen, and teach away.

Your topic doesn’t have to be something huge, it can be a handy little keyboard shortcut that you discovered today, or a metaphor to explain AJAX. You can share a pneumonic device that helps you remember something. All of this counts as teaching. All of this helps.

The more you all teach each other, the more you will learn and the stronger your cohort will be. This is a good thing! Programming is collaborative, not competitive. You need to be able to work on a team. The stronger your team is, the better your work will be.

Then once your 9 (or 12, or 15) weeks are over and you’ve graduated and earned your dog tags, you don’t stop learning. You didn’t just come to Dev Bootcamp to learn how to program, you came to learn how to teach yourself new things. It’s not like technology is going to stop evolving. You’ve got to keep learning if you want to keep up. You’ll have to keep learning new languages and concepts for the rest of your career. You might be able to do it alone, maybe, but it will be a lot faster and a lot easier if you have friends to help teach you along the way. Can you see yourself in 5 years attending a workshop to learn some new language and running into other DBC grads? How do you want them to remember you?

Make the most out of your time at Dev Bootcamp (after all, you paid for it! Get your money’s worth!) Put in as much as you possibly can, and get out as much as you can.

- Erin Joan Snyder, Fiery Banana Bear 2014 -


2014 Banana Slugs

Tourist in my town: Coit Tower and the Filbert Street Steps

I really needed a change of pace today, so I decided to spend some time outside exploring the city. I walked through Chinatown and North Beach to Telegraph Hill. I didn’t see any parrots, but Coit Tower is still a nice landmark and the gardens surrounding the Filbert Street steps are gorgeous! The steps are my new happy-place in this part of the city, and all of the people I met there today were very respectful and nice (unlike most of the people I meet in touristy areas)!