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!
Since I was recovering from a cold this weekend, please forgive my lack of drawings and enjoy some flying toasters.
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.
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 @ 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.