Weeks 7 & 8 @ Launch Academy: Caturday Funtime

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 https://caturday-funtime.herokuapp.com. 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!

# 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 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

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.

Week 4 Reflections @ Launch Academy

# Week 4 @ Launch Academy

Week 4 has quickly come and gone, due to the long weekend prior. During this past week, we delved into object-oriented programming by creating multiple types of programs.

First, we created a workout analyzer, which pulled in external CSV file data on daily exercise routines, then from that data we calculated the total time of the workout and the burned calories from the different types of exercises listed. This data would then be output into a table on screen.

Second, we recreated the game Blackjack, in Ruby. The most challenging parts of this were determining if an ace had the value of 1 or 11, and then determining the winning conditions for the player and opponent.

In regards to Aces, it was best to determine its value at the end, by noting the number of aces and if the player’s total was over 21, if an Ace was computed as 11. For the winning conditions, it took me a bit of time to make sure if the player busted and if their total was higher than their opponent.

Third, we created a Bank Account program that pulled data from two separate files: one included account data with the starting balances, while the other contained data on daily transactions and deposits. This particular challenge took me a long while to solve, and I stayed until near 8pm to finally solve it.

The reason why it took so long for me was I was approaching the problem by using a way too complex solution. Instead of trying to detect if a transaction was below zero to find out if it was a deposit or not, I was trying to make a text search method to see if it could detect the word ‘deposit’ in the transaction description instead.

Ultimately, it was best for me to start from scratch and take it a piece at a time from the basic problems, and working towards the more complex ones. 

The forth program we worked on was the Lunar Kitchen app, which also utilized our previous knowledge of SQL and Sinatra. What was introduced to us in this challenge was the use of RSpec and Capybara (two Ruby programming testing tools), where we would find the failing conditions in our kitchen app, and make them pass.

With one of our previous challenges being a similar recipe app, I didn’t have too much problem using Rspec and making the tests pass.

Aside from the challenges we worked on during the week, I made a Rocks Paper Scissors side project unrelated to the curriculum to strengthen my working knowledge of objects. I also attended the Boston Ruby group’s project night on Tuesday. A lot of neat people were there, and I had some good pizza.

Next week, we’ll be learning Javascript, and I’ll be attending the Engineers4Engineers developer conference on Friday. I’ll be posting a usual update next week!

magicscience:


REBLOG REBLOG REBLOG FOR FABULOUS PRIZES 5 LUCKY REBLOGGERS WILL GET THIS KIT FREE


Reblogging this because you should see Zoe’s art, her cool brushes… and I want that brush kit.

magicscience:

REBLOG REBLOG REBLOG FOR FABULOUS PRIZES 5 LUCKY REBLOGGERS WILL GET THIS KIT FREE

Reblogging this because you should see Zoe’s art, her cool brushes… and I want that brush kit.

# Week 3 @ Launch Academy: Hacknado the SQL
Last week, we dived right into SQL using PostgreSQL with the terminal and within Ruby. Then, we then finished off the week with a little object-oriented programming.
At last, we now know the basics of making a CRUD (Create Read Update Destroy) app.
It took some time getting used to querying data tables, and understanding things like LEFT OUTER JOIN, but after some thorough learning and testing, I understand it now. 
What did we build last week? We remade our news site that used CSV files for articles and now it uses SQL, created a web app that pulled movie, cast, and actor data from a database, and finally attempted to make minesweeper for the object-oriented programming part.
Once getting the hang of the syntax, the SQL isn’t too difficult. Minesweeper, while not a core assignment however, was a challenge.
While I have not fully finished it yet, I have been able to create a minefield and allowed it to propagate mine objects (with random coordinates) within the specified grid. What’s left for me to do is the clearing method initiated by the player. That’s been the hard part, however I feel I am close to an answer.
We’ll be continuing our learning about object-oriented programming this week, and I’ve also been working on a simple game side project I will be talking about at some point.

# Week 3 @ Launch Academy: Hacknado the SQL

Last week, we dived right into SQL using PostgreSQL with the terminal and within Ruby. Then, we then finished off the week with a little object-oriented programming.

At last, we now know the basics of making a CRUD (Create Read Update Destroy) app.

It took some time getting used to querying data tables, and understanding things like LEFT OUTER JOIN, but after some thorough learning and testing, I understand it now. 

What did we build last week? We remade our news site that used CSV files for articles and now it uses SQL, created a web app that pulled movie, cast, and actor data from a database, and finally attempted to make minesweeper for the object-oriented programming part.

Once getting the hang of the syntax, the SQL isn’t too difficult. Minesweeper, while not a core assignment however, was a challenge.

While I have not fully finished it yet, I have been able to create a minefield and allowed it to propagate mine objects (with random coordinates) within the specified grid. What’s left for me to do is the clearing method initiated by the player. That’s been the hard part, however I feel I am close to an answer.

We’ll be continuing our learning about object-oriented programming this week, and I’ve also been working on a simple game side project I will be talking about at some point.

# Week 2 @ Launch Academy: Taming Data Structures
At this point, I’m feeling fairly confident working around complex data structures. Unlike my first week, there has been less head-bashing this time around, and more investigating.
We’ve played a lot with Sinatra. If you’ve heard of Ruby on Rails, Sinatra is its minimalistic younger sibling. I’ve been enjoying my time with it thus far: learning a lot about routes, post requests, and generating data from files into information on a webpage.
We created a clone of Y Combinator’s Hacker News, and in the last version of this challenge, we used HTML forms to send article links and descriptions via a POST request. I deployed a final version up on Heroku using Redis cloud and JSON to handle the data.
In another challenge, we made a dynamic web page hosting a list of movies, and each generated movie title would be a link that would provide specific info about that movie. For the last part of that challenge, I worked on pagination so only 20 movies would be shown at a time. It took a bit of math, and I had a brief bug where you can get NEGATIVE pages, but I fixed that and got it working.
# IRB, PRY, .grep, .zip, & .sort_by
Two things that were great debugging and learning tools were both IRB (Interactive Ruby) and the Pry REPL. Allowing me to type code line by line and dig into my data, these were singlehandedly the best tools to help me learn my way around complex arrays and hashes.
In working on some of my recent projects, I learned three new methods: .grep, .zip, and .sort_by.

# .grep
frequent_name = [ ]names = [“voldemort”,”bobjoe”,”harry”,”sandra”,”harry”]names.each do |name|    frequent_name « {name => names.grep(name).size}end
—-
Using .grep in conjunction with other methods like .size, I could find and count the most frequent word. The result from this would be a hash:frequent_name=> {“harry” => 2}

#.zip
names = [“chris”, “henry”]moar_names = [“meredith”, “agatha”]names.zip(moar_names).flatten!
—-
Zip works like it sounds like. Like a zipper, it weaves the teeth of the zipper together, creating something new. Used with .flatten, we create a merged version of the array:
names=> [“chris”, "meredith", "henry", "agatha"]

# .sort_by
wizard_rank = [ ]
wizards = [{:name => “Voldemort”, :score => 4}, {:name => “Harry”, :score => 8}, {:name => “Hermione”, :score => 10}]wizard_rank = wizards.sort_by { |wizard| [-wizard[:score]] }
——
.sort_by is really great. It allows me to sort out hashes using the key value I want. The minus before “wizard” allows the highest number to come up first in the new compound data structure:
wizard_rank=> [{:name=>”Hermione”, :score=>10},      {:name=>”Harry”, :score=>8},     {:name=>”Voldemort”, :score=>4}]
Like the first week, I’ve learned a lot. Next week we’ll start playing with SQL, and I’m looking forward to working with it!

# Week 2 @ Launch Academy: Taming Data Structures

At this point, I’m feeling fairly confident working around complex data structures. Unlike my first week, there has been less head-bashing this time around, and more investigating.

We’ve played a lot with Sinatra. If you’ve heard of Ruby on Rails, Sinatra is its minimalistic younger sibling. I’ve been enjoying my time with it thus far: learning a lot about routes, post requests, and generating data from files into information on a webpage.

We created a clone of Y Combinator’s Hacker News, and in the last version of this challenge, we used HTML forms to send article links and descriptions via a POST request. I deployed a final version up on Heroku using Redis cloud and JSON to handle the data.

In another challenge, we made a dynamic web page hosting a list of movies, and each generated movie title would be a link that would provide specific info about that movie. For the last part of that challenge, I worked on pagination so only 20 movies would be shown at a time. It took a bit of math, and I had a brief bug where you can get NEGATIVE pages, but I fixed that and got it working.

# IRB, PRY, .grep, .zip, & .sort_by

Two things that were great debugging and learning tools were both IRB (Interactive Ruby) and the Pry REPL. Allowing me to type code line by line and dig into my data, these were singlehandedly the best tools to help me learn my way around complex arrays and hashes.

In working on some of my recent projects, I learned three new methods: .grep, .zip, and .sort_by.

# .grep

frequent_name = [ ]
names = [“voldemort”,”bobjoe”,”harry”,”sandra”,”harry”]

names.each do |name|
    frequent_name « {name => names.grep(name).size}
end

—-

Using .grep in conjunction with other methods like .size, I could find and count the most frequent word. The result from this would be a hash:

frequent_name
=> {“harry” => 2}

#.zip

names = [“chris”, “henry”]
moar_names = [“meredith”, “agatha”]

names.zip(moar_names).flatten!

—-

Zip works like it sounds like. Like a zipper, it weaves the teeth of the zipper together, creating something new. Used with .flatten, we create a merged version of the array:

names
=> [“chris”, "meredith", "henry", "agatha"]

# .sort_by

wizard_rank = [ ]

wizards = [{:name => “Voldemort”, :score => 4},
{:name => “Harry”, :score => 8},
{:name => “Hermione”, :score => 10}]

wizard_rank = wizards.sort_by { |wizard| [-wizard[:score]] }

——

.sort_by is really great. It allows me to sort out hashes using the key value I want. The minus before “wizard” allows the highest number to come up first in the new compound data structure:

wizard_rank
=> [{:name=>”Hermione”, :score=>10}, 
     {:name=>”Harry”, :score=>8},
     {:name=>”Voldemort”, :score=>4}]

Like the first week, I’ve learned a lot. Next week we’ll start playing with SQL, and I’m looking forward to working with it!

# The First Week @ Launch Academy & Pivoting the Bootcamped Comic
I’ve survived my first week at Launch Academy.
When asked about my experiences thus far, I’ve replied to friends that “Every day is like solving an intense mind puzzle. I’m engaged, excited, mentally tired, but I want to keep on programming at the end of the day because it’s fun.”
So far, what have I learned? We’ve been diving deep into Ruby and have learned flow control, arrays, methods, hashes, working with CSV and JSON files, compound data structures, and a bit of Git. We’ve created more than a dozen programs. There are always extra challenges to complete, to keep me out of my comfort zone and to keep on learning something.
Sometimes solving a challenge comes easy, and other times it is head-bashingly difficult. When working on the 3rd iteration of the cash register program, I spent two and a half days really tying to understand hashes.
Thanks to our learnings on “how to learn”, I know that I am capable of overcoming these short-term problems. I either seek the solution on my own, with others in my cohort, or with the help of an experience engineer. I always end up being more wiser, more enlightened, and more satisfied with what I am capable of doing with each passing day.
I’ve also made some test programs unrelated to our workshops and challenges, to reinforce my knowledge. I spent half a day converting one of my programs to use methods, to be more familiar with them and to not face problems in the long run when we get into object-oriented programming.
The thing I have enjoyed the most about the learning experience here is that it’s so different than anything I’ve experienced in the past. I’ve always been a hands on person, and had trouble retaining information during long lectures in college. I like to be highly involved in the search for answers and the discovery of knowledge, and the program at Launch Academy rewards me for doing so.
I’ve learned more about programming than my random dabbling in the past decade, and I’m at the point where I can look at other programming languages and see the many similarities between them. I’m excited, and I can’t wait to see what we make next week as we start interacting with the web.

# Bootcamped
Last week, I mentioned a comic side project that I would be working on during the cohort. I am still going to work on it, however I am scaling it down a bit as I had no idea on the amount of work I was going to experience at Launch.
No site will be launched (yet), but I will be posting my drawings and comics here once a week. I also have been jotting down the many experiences I’ve had, so I have a backlog of material to work through.
I intend to tie this into my future “Breakable Toy” project, so hopefully you all will see something cool towards the end of the cohort.
See you all soon.

# The First Week @ Launch Academy & Pivoting the Bootcamped Comic

I’ve survived my first week at Launch Academy.

When asked about my experiences thus far, I’ve replied to friends that “Every day is like solving an intense mind puzzle. I’m engaged, excited, mentally tired, but I want to keep on programming at the end of the day because it’s fun.”

So far, what have I learned? We’ve been diving deep into Ruby and have learned flow control, arrays, methods, hashes, working with CSV and JSON files, compound data structures, and a bit of Git. We’ve created more than a dozen programs. There are always extra challenges to complete, to keep me out of my comfort zone and to keep on learning something.

Sometimes solving a challenge comes easy, and other times it is head-bashingly difficult. When working on the 3rd iteration of the cash register program, I spent two and a half days really tying to understand hashes.

Thanks to our learnings on “how to learn”, I know that I am capable of overcoming these short-term problems. I either seek the solution on my own, with others in my cohort, or with the help of an experience engineer. I always end up being more wiser, more enlightened, and more satisfied with what I am capable of doing with each passing day.

I’ve also made some test programs unrelated to our workshops and challenges, to reinforce my knowledge. I spent half a day converting one of my programs to use methods, to be more familiar with them and to not face problems in the long run when we get into object-oriented programming.

The thing I have enjoyed the most about the learning experience here is that it’s so different than anything I’ve experienced in the past. I’ve always been a hands on person, and had trouble retaining information during long lectures in college. I like to be highly involved in the search for answers and the discovery of knowledge, and the program at Launch Academy rewards me for doing so.

I’ve learned more about programming than my random dabbling in the past decade, and I’m at the point where I can look at other programming languages and see the many similarities between them. I’m excited, and I can’t wait to see what we make next week as we start interacting with the web.

# Bootcamped

Last week, I mentioned a comic side project that I would be working on during the cohort. I am still going to work on it, however I am scaling it down a bit as I had no idea on the amount of work I was going to experience at Launch.

No site will be launched (yet), but I will be posting my drawings and comics here once a week. I also have been jotting down the many experiences I’ve had, so I have a backlog of material to work through.

I intend to tie this into my future “Breakable Toy” project, so hopefully you all will see something cool towards the end of the cohort.

See you all soon.