The New Alacrity Studios Website

July 13th 2015 @ 3:50:53 PM

The new redesign of alacritystudios is here! While there’s likely to be some lingering tweaks to be made, everything is working nicely, and the new site looks great on both mobile and desktop.

As stated in my last post, this site runs on the Express.js framework (which runs in Node.js), with a couple additional libraries of my choosing (Tumblr.js, Moment.js, and a tiny bit of JQuery). I chose Express over larger frameworks (like Django or Rails), and other micro-frameworks (like Flask or Sinatra) I’ve worked with, because I wanted this site to be quick to load and to develop for by using one language for the entire stack.

Along with added Jade template and Stylus CSS preprocessor support, creating everything was less of a headache.

All this runs on a DigitalOcean droplet, with Forever.js running the app continuously. A bit of Nginx was used to proxy the site to the domain.

If you’re interested in looking at the inner-workings of the site, feel free to check out the source code. If you’d like to build a site of your own using the same stuff I did, check out my Express.js starter kit.

I’ll be writing a post here very soon about a side project I’ve been working on using Express and!

Redesign Incoming

June 19th 2015 @ 1:48:14 PM


Here’s the current progress on the new alacritystudios website. Everything is built on top of ExpressJS (a JavaScript-based micro framework), and it grabs blog posts from the Tumblr API. Please note: the favicon is not for alacritystudios, it’s just a bug from running localhost. I also need to fix how the timestamps under the blog titles are shown.

The new site should be ready towards the end of the month. I’ll be making a post in the future about how it was built!

Weeks 9 & 10 @ Launch Academy + Beyond

November 6th 2014 @ 2:02:00 PM


Sorry to have left you in the dark a bit, everyone.

It’s been a busy few weeks and a rough transition, from working on my final project at Launch Academy, to hopping around Boston going to interviews each day.

I have some good news to share about the outcome of all that, but I will be saving it for a future post, when things are all completed, final, and official.

For today, I’ll talk about my final project, “Emphasis”, as well as a key lesson I took away from the Launch Academy experience. I hope to impart at least a modicum of advice for members of future cohorts.


# Weeks 9 & 10 - Emphasis

Weeks 9 & 10 at Launch Academy were dedicated to working on our final solo project, our “Breakable Toy”. With the knowledge we gained in our group projects making a CRUD (Create Read Update Delete) Rails app, our mission this time was to create a CRUD app, however with at least one special feature that was uniquely tied to us.

A few years ago, I wanted to create my own Content Management System (CMS) for webcomics. I always found templates on top of blogging CMS platforms, like Wordpress or Tumblr, to be too cumbersome for graphic novel style webcomics.

If the creator wanted to make this kind of webcomic, they would either have to use someone else’s service, or had to learn a bit about web design/development to create the site they wanted. I’m aligned with the idea that creators should have the choice to be their own islands, away from publishers or platforms that work like a publisher.

Even with something as simple as Tumblr, they would have to spend a lot of time configuring their page to get things right, which would take time away from actually creating their comic.

I wanted something a bit easier, for the creator to not care about those things, and to just draw and upload their pages.

So with that, I had the basic framework for my app, but I needed something special.

At Launch Academy, we gained a solid foundation on the Ruby programming language. During the past few years though, JavaScript has been ever more so important in the world of web development, mainly because every browser can run JavaScript. Also, now with the help of Node.js, JavaScript can now run in the backend.

I decided that if I wanted to know more JavaScript, I should have my app include a core feature that featured JS. Knowing that JS can be used to manipulate the DOM (Document Object Model) in a webpage, I could power my app to make truly interactive and animated webcomics.

It was with this, I named my app “Emphasis”, because the user was able to add emphasis to the elements on their comic pages.

I planned out and calculated my risk– I estimated it would take me three days at most to make a basic webcomic CMS Rails app, with all the right controllers and models. That would give me a bit over a week and a half to learn and experiment with JavaScript.

I then came across my first challenge: What was the best way to animate elements on a page?

I first tried to do a lot of research, looking through Google and Stack Overflow, but there never was really a direct answer to my question. I could use HTML5 Canvas, JQuery, or a library like Kinetic.js.

I asked the mentors at Launch, and I got three different responses: “Use Canvas”, “Use a JavaScript library”, or “Just use something that simply works.”

I decided to spend a day to try out all the different methods to animate an element, and measure how effective they were.

Canvas was very fun to use, but it led to development and time problems. Certain animations in Canvas did not work in every browser, including my tablet or phone. Also, due to my lack of a foundation in JS, developing and learning Canvas could turn out to be a month-long project, which was outside the realm of something to be completed in less than two weeks.

I looked at JQuery, but it only supported minor tweening and transitions. While it made me more familiar with JQuery, I wanted something that was truly flexible, and more akin to actual JavaScript.

I then stumbled on GreensockJS, which was easy to implement, and its syntax for selecting and animating an element was fairly simple. It supported rotations, alpha channel effects, looping, and even timelines for making a series of animations. Plus, it worked across many browsers.

I then spent the next couple of days learning it through hard coding, integrating it in my app, then afterwards I got a basic animation working.

That led me to my next problem: In order to make the animations run and work, I let the user write their own JavaScript. This was bad, because now users could write malicious code that redirects people to malware sites, or spam their browsers with alert dialogs.

This also was a counter to the core purpose of my app, which was to make things simple enough so the user would spend more time creating, and less time configuring.

In a previous non-LA related side project, I made a Sinatra app called “Ask the Duck!”, which was a virtual rubber duck companion that answered programming questions by sending you to relevant pages. You can also ask it to quack an amount of times, or give you random advice.

How this app worked, was that I created an object oriented duck parser and interpreter. This feature split the user’s query apart into an array of key words, and deciding what to do with them through a giant case statement.

I decided to make a similar feature for Emphasis, to let the user type in key words through an interpreter in plain english. This would allow them to easily create animations without even typing JavaScript, and the app would automatically produce the variables and secure JS needed to make their animation work.

So instead of typing this:

window.onload = function() {
  var cat3 = document.getElementById(“cat3”);, 1, {top: 200,right: 200,repeat: -1,yoyo: true,delay: 1});

They now can type:

animate; time: 1; top: 200; right: 200; repeat: -1; yoyo: true; delay: 1;

I only whitelisted certain commands in the interpreter, so animation commands and mouse interactions for hiding and showing things are supported. This would block out any other code that could be used for nefarious purposes.

With these two key features, I ended up creating more than what I originally planned, with a little extra time available for polish. While there are still more features, further security patches, and even more polish I would like to add, my app was functioning, the core features were working, and it was ready to be showcased.


# A Key Lesson from Launch Academy

I want to say that I was very happy with my experience at Launch Academy. While there were some tough challenges that everyone faced at one time or another, I learned more about coding in 10 weeks than 5 years on my own.

If you are thinking about going to a web development bootcamp like Launch Academy, please consider the following:

* Do you like to code?
* Is coding something you would want to do almost every day?
* Are you comfortable with entering an environment where there is always something to learn, and that process will never stop?
* Are you willing to put aside other things to commit almost 3 months (and beyond that) worth of time on just coding?
* Are you comfortable working with other people? If not, are you willing to improve that part of yourself?

If you’ve learned some coding through resources like Codecademy, Code School, or Treehouse, and enjoyed it, you might be ready to take that step.

Do your research, and find out what’s the best way you learn things. If you like to dive deep into a subject, experiment, and go hands on, a bootcamp like Launch Academy would be for you.

Everyone at LA, my fellow cohort to the mentors, were supportive, positive, and in it together to bring learning and success into our lives.

If there was only one key thing I could mention that I took away from the Launch Academy experience, it would be to “Never give in to fear.”

Before LA, and even during the beginning of LA, there were many times where I had an ambitious idea, but I believed I was either too inexperienced, or not ready to take on such a project.

Talking to the mentors at LA drove this fear away. “Just do it.”, one would say. “Start with the simple things you can implement and build up from there.”

“Don’t be afraid of making mistakes and breaking things.”, another said. “You learn the most about how things work that way.”

Time and time again, it was with these kind of responses I was able to do things like making a Pong clone with Gosu, to creating an ambitious project like Emphasis.

Never give in to your fear. I will never forget that, and I thank everyone there for it.


# Beyond

In my spare time before the next chapter in my life begins, I’ve been learning JavaScript. One of the books I’ve been reading is Eloquent JavaScript, which is free to read online or in e-pub format. It’s a great book, and I highly recommend it.

I hope to be well-versed (or even more so) in JS as I am in Ruby, and eventually want to make some insane web apps, including games in my spare time. Everything is possible now, and I have only scratched the surface as an advanced beginner.

Knowing the foundation on how to learn, as well as coding is a wonderful feeling. It’s the closest thing in the real world that is akin to magic. You can create whole things and concepts out of nearly nothing. Everyone in this industry values knowledge and learning, and many of them love to help you learn and grow.

Everything is new and it seems that changes happen so often that it’s hard for things to permanently go stale. I’m enjoying every moment. Coding to me is just as fun and creative as drawing, and it’s like playing the ultimate puzzle game.

Again, I am thankful for all the friends I’ve made, and the experience I had. Here’s to the wonderful future we all have ahead of us, because I feel there are more great things to come.


October 17th 2014 @ 5:58:00 PM

Seven Sovereigns page 2 - 2014


October 11th 2014 @ 8:25:09 PM

Seven Sovereigns page 1- 2014

More to come…

Weeks 7 & 8 @ Launch Academy: Caturday Funtime

October 6th 2014 @ 11:35:12 AM

Work on our group projects spanned these past two weeks, so I decided to skip posting an update last week, to make a more comprehensive post today.

Our group project is live now, and you can check it out at Thanks goes to my team: Anne, Kristin, Josh, and our mentor Adam!

Overall, the experience was great. Like previous weeks, I learned a ton, but I really mean it this time that I learned A TON. Without the group project experience, I would have not seen my own weaknesses and improved on them. I’m thankful for the people I’ve worked with on my own team and outside of it, as well as the guidance we received from our mentors.

The mission over the past two weeks for all groups was to make a CRUD (Create Read Update Delete) app that allows you to review and vote on items. Our team decided to create a cat picture review site to keep things fun, motivating, and interesting.

There’s a lot of thoughts that come to mind about the past two weeks, but I decided to be brief here and distill what I’ve learned to five key points:


1) There aren’t enough hours in the day to work on all the things you want to build.

Early on, our group decided to define the core meaning of our app: posting and reviewing cat pictures. With this in mind, we laid the foundation to work solely on those core features first. We made it a goal to finish 1-2 features a day, and use the leftover time towards the end of the project to polish the app, fix remaining bugs, and add a couple extra features.

It’s always neat to come up with ideas, but if you don’t have the core structure of your app mapped out, it’s going to cause more problems down the road. I’ve heard a lot about the term “Minimum Viable Product” before, and that idea was really hammered-in here as we started the framework for our app. Get your core features out the door, everything else comes afterward.

2) Work in pairs, and if not, communicate often.

Every morning, our group would meet and discuss what to work on for the day. We’d often split into two pairs, each working on a feature. If someone was really passionate about working on a particular thing, or wasn’t strong on it but really wanted to learn it, we’d pair them up and give them the task of working on it.

Whoever was the least confident in the pair we’d put in the driver’s seat, while the more confident would be the navigator, giving frequent feedback.

This allowed the pair to work through their weaknesses, and increase the number of teammates who were familiar with an added feature.

Later on in the project, we were pretty confident we could all work individually (and got 4 or more features done at once), but we made sure to keep each other updated on the team’s Flowdock (our chat program) every couple hours on what we were doing.

When we would meet later in the afternoon as a group, we would go over all our code so we could all learn, critique, and provide feedback on what could be fixed and improved upon.

3) Deploy often. Test often.

Our mentor Adam pushed us to deploy our first base feature to Heroku (an app hosting service) early, so we could get used to working and deploying to the live environment. At the end of each day, after merging all the branches and resolving any conflicts, we would frequently deploy to live to see if anything would break, and give us time to reflect on our work.

Getting used to deploying got rid of the stigma of “hiding” your project to the world before going live, because you don’t actually know if everything works unless you deploy.

Another thing was to test often, we made frequent use of Capybara as well as TravisCI to test out features of our app, and we had a little fun with it by making our test produce a Nyan-cat animation:

4) Branch often, without stepping on each other’s toes.

If I was to mention one thing I learned to do that I hadn’t done before, it would be branching. Prior to the group project, I only made frequent additions and git commits to the master line of my programs.

Learning about the problems that could arise without branching in a team, we quickly adjusted and made as many focused branches for each feature. Whenever a teammate worked on a new feature, they would create a branch, announce it to the team what exactly they were working on, and work on it.

5) Have fun with what you’re doing.

I think the reason why the group worked so well together, and learned so much was that we each shared the same funny vision, and it helped with the app being as silly as it could be. You learn things when you are having fun, when things are memorable and unique, and you’re still having fun while struggling together.

The silliness of it all really made us remember a lot of features we worked on, like making tests for error messages like “FAEL REVIEW LOL” if you incorrectly filled out a review, or adding a link that says “DELETE THIS LOSER” for the Admin control panel.

We had a lot of fun trying to break the app too (and I’m sure others in the cohort had fun trying to break our app during live development), and it helped make everything more secure and polished towards the end.


There are two weeks left. I’ll be working on my personal “breakable toy” project during this time, which I feel will be of interest to all my friends at the Boston Comics Roundtable. Be sure not to miss it when I start writing about it!


September 22nd 2014 @ 12:21:12 AM

# Week 6 @ Launch Academy: Sinatra vs Rails

Another week has come and gone, with a hint of Javascript, and a large helping of Rails. After making a couple Rails-powered sites, I feel more comfortable with it.

For the folks out there reading who don’t know what I’m talking about, Ruby on Rails is a large web application framework that does a bunch of the heavy-lifting for you. It powers a lot of dynamic web sites, such as Github and formerly Twitter.

Before encountering Rails, we made a lot of light web applications built on top of Sinatra, another Ruby framework.

As the drawing I made above states, Sinatra is a Don Corleone who sometimes doesn’t take your crap, and you really have to work with him (or else his enforcer will dump a horse-head on your bed). Rails is the equivalent of Cooking Mama, who’s there to tell you all the instructions and lay things out step-by-step in the MVC (Model View Controller) model.

After working with both, I see that they each have their advantages.

If you’re making something simple and you just want to put up a light web app, Sinatra works well. You have to make everything yourself, and tell it what to do, but at least it’s mostly your code, and you know what’s working behind the scenes. You control the code, the file structure, everything with Sinatra.

Once things get overly complex, like if you’re making a full-featured web app that manages multiple sets of nested data, like a blog, forum, social network, or analysis site, then it might be time to look at Rails. You have to follow Rails’s file structure, and the way it names or calls things, because like Mama, it knows what’s best for you. The benefit of this is that you can care about how you really want your app to work, rather than spending all that time on how you’re going to import or manage data.

If you wanted to, you could even use both together. For example, while large parts of GitHub are powered by Rails, small parts like GitHub’s Gists are powered by Sinatra.

Overall, it’s been a very informative and interesting week, and starting Monday, we’ll begin working on group projects for the next two weeks.

There are four more weeks left in the cohort, and I’m looking forward to working with my peers, and on my personal “Breakable Toy” in the last two weeks.

Week 5 @ Launch Academy

September 14th 2014 @ 9:50:06 PM

Since I was recovering from a cold this weekend, please forgive my lack of drawings and enjoy some flying toasters.

#Week 5

Active Record, Active Record, Active Record… This week was all about the first and most important part of Rails. Making up the big ’M’ for model in MVC, we spent all this week figuring out migrations, relationships, normalization, ER diagrams, and how this part of Ruby on Rails does it’s data magic.

Aside from this, I spent a night and a good part of Thursday recreating Pong (in Gosu) as a side project for fun. It still needs some work, but the essentials are there and I’ve put the source code up on GitHub. It even has particle effects!

Since Active Record was pretty much the singular topic that permeated throughout most of the week, I’m actually going to talk about something more interesting here, that made me more excited about becoming a web/software developer.

On Friday, a good chunk of us at Launch Academy attended the Engineers4Engineers conference. It was an all-day event with many great and fantastic speakers who talked about their prior experiences as well as the insights regarding the tech industry. 

Here were the presentations I attended:

Beginning Keynote w/ Michael Lopp

Michael Lopp, who worked at Borland, Netscape, Palantir, and Apple, talked about two archetypes in the industry: Stables and Volatiles, and how they play with each other.

This was such an amazing talk, and it had me thinking deeply about my working relationships with people. Michael explains while you need both of these archetypes, and you need an ecosystem where they can both work together to create new ideas.

Laziness in the Time of Responsive Design w/ Ethan Marcotte

Ethan Marcotte talked about very clear ways to create responsive elements in web design, and I found his connections with the animation and print industries very intriguing. Instead of thinking of web design as a mechanical structure, we need to start thinking about the human connections and meanings of the interfaces we interact with on the web.

He also gives some great CSS pointers for responsive elements that don’t require Javascript.

Initiation to Code: A Roadmap for New Developers and Their Mentors w/ Alice Mottola

Alice Mottola from Constant Contact (and a graduate of General Assembly, another bootcamp), explains mentorship with a great metaphor related to swamp gator tour guides. While this was geared more towards mentors, it was great to hear her convey the need for mentorship for junior developers in the tech industry.

Overkill w/ Katrina Owen

Katrina Owen did a great job explaining simplicity in programming, and it really helped me think about naming and solving certain problems properly in Ruby. I sometimes have the tendency to think something I’ve programmed is simple, yet in reality it’s not quite readable. This talk definitely pivoted me in the right direction. 

How to Build Innovative Technologies w/ Abby Fichtner

Abby Fichtner is the Hacker in Residence @ the Harvard Innovation Lab, and she explained about different processes for forming a product idea for a startup. What I got out of this is to start with a simple baseline idea, “dominate a small market”, then grow after that.

Ending Keynote w/ Merlin Mann

Merlin Mann’s ending keynote was a laughing riot. Zigzagging his subject from the early Internet in the 90s, to his early downloading of Betty Paige porn, to modern society and how this all wraps up into our own knowledge… He explains that we can never guess that the things we know now can be relevant to tomorrow. The key thing is to stay curious about everything.


All these talks were fantastic and made me fascinated about the industry I’m entering. It seems that the tech industry is one of the few industries that has avoided complete gentrification, and that there’s this great culture of knowledge seeking, and mindfulness.

These things are some of the reasons why I wanted to take a deep dive into becoming a developer. Even with five more weeks to go, I feel this is only the beginning of my grand adventure and there are many more exciting things to come.

Read more blog posts @