MA Day 55: Alex! [JavaScript Promises and Images Breaking on Heroku]

Alex is back today!!! <3 I overhear somebody asking “Where is Alex?!?!” at least once a day, every day. We joked about massive lines forming for Alex once he gets back.

So bright and early, first thing in the morning, we made a new list on our team den’s white board of all the miscellaneous things we need to clean up on that didn’t quite fit on Trello, which serves more of a high level overview of separate tasks. Notice our little list of questions saved for Alex on the left:


Also, notice we changed our logo to grapes (on the top) today. The back and forth between grapes and bananas ensues. So, things from Alex that we learned today that we couldn’t figure out for about a week are as follows:

Images break when we push to Heroku despite showing up fine on our local machine because Heroku adds a little string (for security?) after all the links in HTML image tags, and they probably Heroku wasn’t locating the images with the strings appended properly. So the way to fixed this, is to use Ruby image tags instead of HTML tags and Ruby will take care of things for us. So here’s how we made everything work:

Fix image urls · da21643 · thejennywang bunch Second, we couldn’t get our JavaScript callbacks to happen in the order that we need them to, because Javascript works asynchronously, meaning it doesn’t run code line by line, top to bottom, it runs all the code at once and returns whatever comes back first. The solution to this problem would be use promises and Q is a tool for making promises. Here’s what our code looks like with Q added: Added promises to JS · 02f7f78 · thejennywang bunch

By the end of the day, Dave and Peter got a carousel of images playing in our homepage background. Yay! We’ve been wanting to implement this carousel forever, but our biggest problem was actually not technical, but finding nice, appropriate photos! It turns out that nice, high resolution photos of cafes and pubs are hard to find, and ones with people in them are even harder, because those are almost always paid. Yargh!

Charlotte and I got Foursquare results to show up (uglily) in the sidebar, as well as worked on getting different venue categories into tabs (Top Picks, Food, Coffee, Drinks).

Screen Shot 2014-09-09 at 9.06.14 PMWe didn’t quite get around to working on our end goal of having tabs until 5PM. we kept getting sidetracked with fixing broken image links and styling the boxes that venue information show up in instead of making tabs for categories. It was easy enough to get the appropriate venue types loading and showing up when we clicked on the category links, but the most difficult part of making tabs work is setting a tab to being the ‘active’ tab when it’s been clicked on, and having that tab highlighted. 

The answer to this was using .addClass() in JavaScript, to add the class ‘active’ to the appropriate bootstrap tab and have the active styling apply. And then everything worked! Yay! :)

Screen Shot 2014-09-09 at 9.09.46 PM
Well, sort of. We get to that tomorrow. Look how much we got done today! :)

IMG_4558-0.JPGI left at probably an all-time early today because some of my team members were still around (I’m almost always the last to leave) to get some delicious ramen in SoHo. Yum yum!


MA Final Project Weekend 2: Snazzy Maps


I planned to go to Camden Market and then Tate Modern, but after I showered, I felt motivated to code and didn’t want to let it slip by, so I went to this wonderful vegetarian cafe called Gallery Cafe near Bethnal Green.

IMG_4540.JPGIMG_4536.JPGI went there in the morning to avoid my landlord, but I liked it there so much I went back for more in the afternoon!


I redid my Week 4 Takeaway challenge to make it perfect the way Enrique asked for. It felt really good to actually know what I’m doing and be able to do the whole thing from start to finish TDD’ed and with 5 classes!

Screen Shot 2014-09-09 at 7.43.10 PMCheck it out on GitHub :) I don’t plan to be showcasing this, but I just wanted to finally get this done, well. For myself. :)



We decided to all go to Charlotte’s again, bright and early, at 11am this time so that we’d be able to leave earlier. Pete was probably the only one who showed up on time. I showed up 10 minutes late, Jeremy a bit while after that, and Dave had his mom’s 60th the day before, so he let us all know he’ll get there when he gets here. Classic Dave.  Jeremy seemed genuinely frustrated because he didn’t understand why something wasn’t working for the first time in the morning, but he worked it out soon enough before going insane. Noam came by to film us, made us some coffees, and helped us choose a Snazzy Maps theme for our maps page. We went with Pale Dawn.

Screen Shot 2014-09-09 at 7.56.09 PMSome close contenders: Midnight CommanderScreen Shot 2014-09-09 at 7.58.58 PM

“The Stride’s One” – Neutral BlueScreen Shot 2014-09-09 at 7.56.38 PMOur team has really spent an unreasonable amount of time choosing the color scheme of our maps page. But despite spending a weird amount of time on choosing our map theme, we still got a lot of other work done and was pretty happy with the amount we got done by the end of the day. We’ve been working on building the backend for getting Foursquare recommendations onto our app, but haven’t gotten to showing the results on the sidebar yet. So one of the main tasks for tomorrow would be to have the recommendations showing instead of having those empty input boxes.

In the afternoon, we got to have amazing salads and sandwiches in Charlotte’s garden and everything was so wonderful. The sun was so nice and the company and food was so good. I wish I got a photo, but Noam has much of it on film. I wonder if it’ll make it into the documentary.

We got around 4 more solid hours of work done after lunch and Jeremy had to go around 6:30pm. Even though we all decided to go to Charlotte’s earlier so that we could leave earlier, we all leave at around the same time we left last time- 7 ~ 7:30 ish. I forgot to take a photo all day until the end:

IMG_4555.JPGDave and I walked to the tube station together and talked about how lucky we felt we were for getting such a great team and being able to get so much work done so swimmingly. We wondered about the other teams’s apps look like and realized that neither of us has really seen what the other teams have been doing. We decided to check their sites out tomorrow. Yay!

MA Day 54: Flipping the table

I almost flipped the table today!


I spent a long time trying to get a bunch of styling and refactoring done, but when I tried to pull from development to have my copy calibrate with the development version that everyone is working from, I had 3 merge conflicts – the biggest merge conflict I’d ever seen because I’ve been spoiled by everyone being good with frequently pushing and pulling.[1. This is essentially, working on and submitting on small, isolated pieces of code that wouldn't conflict with what other people were working on which they would later push (submit).]

While we still got a lot of work done, but we’ve had the most ever of THREE files having merge conflicts! Merge conflicts happen all the time though – so juniors, don’t think that merge conflicts means somebody did something wrong – they’re just annoying because time must be spent fixing conflicts rather than coding.

Screen Shot 2014-09-05 at 6.46.21 PMScreen Shot 2014-09-05 at 6.46.42 PM

Charlotte and Peter paired on integrating the Foursquare API and I made a small contribution by pointing out we don’t need a model for venues during my pop-in as the rover for the day. 1

Dijkstra's Algorithm
Dijkstra’s algorithm, conceived by computer scientist Edsger Dijkstra in 1956 and published in 1959, is a graph search algorithm that solves the single-source shortest path problem for a graph with non-negative edge path costs, producing a shortest path tree. This algorithm is often used in routing and as a subroutine in other graph algorithms. -Wikipedia

Jeremy worked by himself on implementing this algorithm based  Dijkstra’s Algorithm on the solving the problem of finding the meeting point which produces the least cumulative travel (by driving) for all parties.

I thought it was pretty cool when I saw him scribbling stuff on a piece of paper working out the algorithm for our specific problem and asked to pair with him in working it out, but Jeremy usually doesn’t feel particularly collaborative (I’ve worked with him before) when he wants to work things like this out, so he basically said no. So I tag alongside him when he consulted our coach, Sam, so that he wouldn’t be the only person on the team knowing what’s going on with a pretty integral part of our code. 2

So the algorithm Jeremy worked out was simple enough – because he’s really smart and clearly has a deep understanding to be able to work out a simple/elegant solution that makes sense – and it was basically taking the midpoints of midpoints until the midpoints by travel time (not distance, even though it looks like distance in the following diagrams) become less than 5 minutes, our definition of the equality in travel time:


I made Jeremy promise to pair with me to implement the algorithm on Monday. Hehehe

Building off our great  ripoff the of the Airbnb homepage yesterday, Dave presented us with this nice semi-transparent side bar for our site that we all love.  Screen Shot 2014-09-05 at 17.53.37I contributed to the look & feel of the site to this:Screen Shot 2014-09-05 at 6.12.52 PMWe had some debate about whether the “Add another address…” link should just be a big plus sign or if it should be a text link like the second version. I wonder if other teams are having as many debates about everything as we are. All of this conjecture is quite good though; it means we all care and feel comfortable challenging one another and defending our ideas, which are terrific signs of a healthy and productive team. :)

  1. We have an odd number of 5 people, so we have 1 person being a ‘rover’ working on miscellaneous tasks like writing our README file or doing some CSS styling that everyone hates, or research APIs and what not.
  2. Read: I will find a way get what I want one way or another.

MA Day 53: Breakthroughs

Today feels like a day of much productivity and breakthroughs in expense of our energy levels.

I childishly and incorrectly force-appointed myself head of UI/UX and design to impose my ideas on  the site’s design, but everything became much better very quickly when I just let go and decided that everyone liking my design was not important. Look how great everything looks after a big overhaul!

Screen Shot 2014-09-05 at 12.22.59 AMThe whole team spent loads of time on styling and today was probably a low in our usually very-productive days. We did get more parts of our algorithm and back-end done though.

Later, my mentor Makis came in and I learned about how to reset my ‘subl’ path for Sublime Text to the new version I just updated to. Here’s what I did:

1. Install Sublime Text 3

2.Uninstall Sublime Text 2 (with CleanMyMac 2)

3. Went to Terminal and typed:

open -a Finder /usr/bin

This should open your Finder to the /usr directory in a new Finder.

4. Went to Applications, right click on the Sublime Text icon and go to Show Package Contents > Contents > SharedSupport > bin.

5. Copy the subl file and paste it into the other Finder showing /usr/bin

And that’s it! You should be set to use the command: subl . (or subl 1

I also switched to the Solarized colorscheme by Ethan Schoonover on my Sublime Text editor.

solarized dualmode

Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. Makis told me there’s a nice article about the development behind the color scheme and I thought it was pretty cool, so I decided to give it a go. Here’s a snippet from Ethan Schoonover’s site on the features of the colorscheme:

It has several unique properties, described below, and it was designed with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships. It has been tested extensively in real world use on color calibrated displays (as well as uncalibrated/intentionally miscalibrated displays) and in a variety of lighting conditions.

solarized palette
solarized vim

  1. Selective contrastOn a sunny summer day I love to read a book outside. Not right in the sun; that’s too bright. I’ll hunt for a shady spot under a tree. The shaded paper contrasts with the crisp text nicely. If you were to actually measure the contrast between the two, you’d find it is much lower than black text on a white background (or white on black) on your display device of choice. Black text on white from a computer display is akin to reading a book in direct sunlight and tires the eye.

    solarized selective contrast
    Solarized reduces brightness contrast but, unlike many low contrast colorschemes, retains contrasting hues(based on colorwheel relations) for syntax highlighting readability.

  2. Both sides of the forcesolarized dualmode
    I often switch between dark and light modes when editing text and code. Solarized retains the same selective contrast relationships and overall feel when switching between the light and dark background modes. A lot of thought, planning and testing has gone into making both modes feel like part of a unified colorscheme.
  3. 16/5 palette modessolarized palettes
    Solarized works as a sixteen color palette for compatibility with common terminal based applications / emulators. In addition, it has been carefully designed to scale down to a variety of five color palettes (four base monotones plus one accent color) for use in design work such as web design. In every case it retains a strong personality but doesn’t overwhelm.
  4. Precision, symmetrysolarized symmetry
    The monotones have symmetric CIELAB lightness differences, so switching from dark to light mode retains the same perceived contrast in brightness between each value. Each mode is equally readable. The accent colors are based off specific colorwheel relations and subsequently translated to CIELAB to ensure perceptual uniformity in terms of lightness. The hues themselves, as with the monotone *a*b values, have been adjusted within a small range to achieve the most pleasing combination of colors.

So now our bunch app in my text editor now looks like this!

Screen Shot 2014-09-05 at 6.30.15 PM

I find all of this very cool and look forward to using this colorscheme everyday! :)


  1. Source:

MA Day 53: Differences

Today seemed to have been a day of differences. I felt this in three ways throughout the day:

The first difference is in what I perceive as the the underlying issue in the gender gap problem vs the general ideology that I often come across in conversations about the topic, that I discovered in the  Women in IT Focus Group conference call facilitated by Everywomen in partnership with American Express.

Screen Shot 2014-09-04 at 11.27.16 PMDuring this call, I thought it was quite interesting to the difference in my interpretation of the gender gap in tech vs the common notion of the gender gap being a ‘women’s issue’ rather than a gender issue. It seems the common ideology of the lack of women coming and staying in IT is a “women’s” issue because it’s about not having enough women. But I think the problem stems from gender inequality and that men are just as affected, and should be just as involved and encouraged to join the conversation as women. There’s also the stale boiler plate idea: “Oh, we need more women in tech because diversity is important. Because diversity = more variety of ideas = more money.” Thinking of a problem as complex and as frustrating as gender inequality boiling down to something that simple is nowhere near cutting it.

To illustrate my point, at one point in the focus group, we were asked what types of benefits or compensation, would be enticing to us, as women, in tech to leave a company to join another, and I immediately said, “Paternity leave.” I said this would be strong signal to me that a company gets it. This will make it so women aren’t the only parent, in a heterosexual relationship, to leave their jobs to take care of their child. Many of the systems that we are in exacerbates the problem and few are looking at the issue, in my opinion, the right way.  What if the woman makes more money, but the man cannot take leave without worrying about not having a job to come back to? And further, it’s hard for women, even with leave, to be able to go back to jobs and be up to speed if they’ve taken a long period off, so it would make it so that it makes the most sense to be the non-working parent permanently. Gender equality is not only relevant to men, but highly beneficial and influences their success greatly in a positive way.

The second difference, is in the opinions of what our product should be redefined into, given our barriers. Essentially, we are limited, at the point, in the modes of transport our product can accommodate, and we need to make a choice of what mode of transport Bunch is going to be calculating the travel time for. Charlotte wanted public transport, advocating more for the user and something we might actually be able to use after, and Jeremy wanted driving by car, advocating more for the developer and building something that’s more ‘clever’. We almost had a tear in team spirit and unity, but our Charlotte/Leader held it all together and kept everyone on the same boat. Phew. I see why communications skills are so intrinsic to being a great leader, how great leaders can really hold it together and are therefore so important and Charlotte’s a damn good one.The rest of us as a team also did a good job in not alienating Charlotte nor Jeremy or siding too heavily with either of them, and facilitated the both of them and subsequently the entire team in coming back on a shared path we can all move forward together in.

The third difference, was in aesthetic and design tastes between me and the rest of my team. I thought this design made the most sense:

Screen Shot 2014-09-04 at 11.51.52 PM

Additional inputs for more addresses would pop up before the ‘Add another address’ link and after the first few input boxes.Screen Shot 2014-09-04 at 11.52.37 PM

It also looks good with a small screen – keeping in mind the modern way of designing for mobile first.

Screen Shot 2014-09-04 at 11.52.12 PM


But Jeremy wanted out submit button to be a big bunch of bananas while everyone else, myself included, was against it; everyone thought it was too much yellow and too offensive, while I fought for the yellow background. White would be too bland!! Dave raised the really good point of us tying our identity and styling too much to a fruit which compromised too much good design and it’s kind of irrational. Charlotte really want us to have bananas and we’re like “…We’re not really feeling the whole bananas thing anymore… ”

Today wasn’t super productive in terms of work produced, but I think we still made substantial progress in our project overall. We recognized that our product needed to be rethought and redefined based on our new understanding of the technology available to solve our problem in a timely fashion, and the heated/passionate debate our team had further strengthened us as a team. Us arguing show that we care and us reaching a unified decision after hearing everyone out results in us being an even stronger team than we were before.


MA Day 51: Mapnificent and Mapumental!

Charlotte and I spent the day exploring Mapnificent because it’s a free API, and also looked into Mapumental a bit because that’s what Mapnificent is based off of.

Screen Shot 2014-09-04 at 8.04.49 PM

Here’s a video of how to use Mapnificent:

Mapnificent from Stefan Wehrmeyer on Vimeo.

Mapnificient is quite outdated though, and it didn’t really return to us the data that we were looking for to get our app working.

Mapumental, on the other hand, is totally up-to-date and really swanky with its real-time rendering of destinations reachable via public transport within a certain amount of travel time! What more is that the program works so fast for the amount of data it’s processing.

Screen Shot 2014-09-04 at 8.05.03 PMGo to the site, click “Try it” and be amazed by sliding the slider around. Isn’t it cool?! I sent the team at Mapumental to see if we can get a trial of their program for 2 weeks for the duration of our final project, but we are concerned we won’t be able to extract the travel time data that we need from the API since it seems to just be providing a  map overlay, the semi-transparent black coloring of places you can’t reach within 100 minutes, rather than travel time data.

But the folks over at Mapumental were really cool and granted us limited access to old data for free seeing as we are just students learning to code, rather than trying to make some money out of using their API.

In any case, we also learned today why our app hasn’t already been done and in popular use – because it’s really freaking hard!! It all seemed nice and easy when we were thinking about it, but when we go and actually try to build it, it’s wall after wall, obstacle after obstacle! POI call limits and restriction of data usages and unanticipated problems left and right.

But today was still a solid day and I look forward to continued smooth sailing hereonout! :)

MA Day 50: First day of Final Project

First day of coding on final project!


Today we learned all about nested forms and how to get attributes updating. This is because nested forms are quite fussy and it took us forever to get this first bit of code for creating midpoints!

Screen Shot 2014-09-01 at 8.10.45 PMThe UX stream is taking longer than anticipated, but we’re ahead of schedule on our Algorithm stream. We still haven’t completed UX 1, but we’re onto Algorithm 3 already! :)

Screen Shot 2014-09-01 at 7.44.00 PMSam is also back to help us today! He introduced us to a nice testing tool called Byebug, that allows us to pause the execution of targeted code and lets us play with the code while it’s running!

Screen Shot 2014-09-01 at 14.40.59We get to run up to a specific line of code, in the middle of a method, then check to see parameters or things that we want in there are in there, and then run the next line and see what’s in there, and so on and so forth. This alleviates the need for us to change a tiny thing and run our program over and over because we don’t know which part of our program is causing the problem.

Though we didn’t rotate people as much as I liked, but we’ve had zero merge conflicts and have quite a good work pace! We’re overall ahead of schedule and feel pretty good about where our work is going. :)

Team photo at the end of the day :)


First Final Project Weekend: Planning & Organization


Jeremy came around 3pm after boxing, and we got straight to setting up a new rails app and install all the gems we expect we’ll need:

Screen Shot 2014-09-01 at 12.25.07 AMWe made sure we added our secret.yml file to .gitignore and properly secure our secret keys before committing to GitHub. Simplecov and CodeClimate for test coverage reporting. Then we spent some time looking into setting up hitch for proper credit attribution when we pair. We even made a team gmail account to set up the hitch gem, but to no avail – Jeremy wasn’t getting credit for the work we did together because everything was done via my computer. We uploaded our app to a staging environment on Heroku:

Screen Shot 2014-09-01 at 12.30.54 AM Just look at those beautiful bananas. Jeremy left about 2 hours later and we were quite happy with we had done



Great Leader Charlotte’s house!* We all showed up at around 1:30, enjoyed a spot of tea, and got straight to more planning, researching, organizing!

We all looked into the APIs that might be useful and Charlotte is showing everyone the Mapnificent API that is pretty damn cool.

IMG_4502.JPGCharlotte showed everyone a bunch of features that could be useful to our app and Jeremy and Dave talked about the potential routes we could take testing and implementing our map features.

After a lot of going around the table to see other people’s screens, I suggested that everyone should get Screenhero, a really great tool for remotely (across the table) sharing a screen. So we all set up screenhero for remote controlling your pair’s computer!

Screen Shot 2014-09-01 at 12.42.18 AM

Everyone gave setting up the hitch gem for attributing credit to both people in a pair another go.


We didn’t get it to work, so we will be having Enrique show us tomorrow.

Ah yes, I forgot to mention that while simplecov is awesome – look at the wonderful detailed test-coverage report it gives you:

Screen Shot 2014-09-01 at 1.07.03 AM

…it started causing merge-conflicts when we were all working out hitch and were pushing and pulling with our master and development branch!

Screen Shot 2014-09-01 at 1.04.39 AM

So we had to add our /coverage folder into .gitignore to remediate having merge conflicts when our coverage folder doesn’t match.

Next, we worked our user journey (sort of) and map of how our app will technically work:

IMG_4516.JPGWe worked out our division of labor into three streams: Algorithm, UX [User Experience], and CSS/Styling. Then we deciding on how our project schedule would look:

PlanWe decided working on weekends is optional and reserved for fire-fighting, should there be any. :)

Something I was particularly happy with was that as we got deeper and deeper into planning, people got more and more into Trello. There was a bit of friction with adopting yet another piece of technology in the beginning when I pushed using Trello for project management, but after we divided up the work that needed to be done, everyone started vigorously making Trello cards for everything we’ll have to do, while I worked on something non-Trello. My team introduced me to color coding and due-date setting and we all discovered that Trello highlights the due date if it’s within 24 hours. I was bursting in glee and delight when I saw how SO ON TOP OF THE ORGANIZATIONZ we were! Here’s what our Trello board looks like by the end of the day:

Screen Shot 2014-09-01 at 12.53.23 AMWe called it a day at around 6:30PM and everyone seems to feel we will be able to hit the ground running tomorrow morning at 9am. I really good and motivated to work efficiently and effectively on our project for the next two weeks. I’m really happy with how well our team gets on and the rapport we have with one another. We didn’t go to Charlotte’s with a plan of what we’ll be doing together, an idea of what we want to get done or anything like that. I literally asked in the beginning, “So what did say we were going to do together today?” But we all just decided to start looking at APIs together, and all the work we got done was just organically produced as we worked along. There was constant communication, suggestions, sharing of thoughts and ideas, banter, jokes, and everything just fell into place.

If what people say about things ending the way they begin is true, then this is going to be an awesome two weeks.



*We have a running joke by calling Charlotte ‘Charlotte Leader’, ‘Great Leader Charlotte’, and ‘Leader Charlotte’.

MA Day 49: Final Project Teams

Our final project teams were announced this morning! I forgot to snap a photo of the team assignments, but I think the coaches & staff did a really good job placing us all in our teams.  I got into Charlotte’s Meet Your Mate app. Our final project team is the only team of five. Here are the awesome members of our team:

Our Great Leader, Charlotte; Detective Debug DavePeter; and Jeremy!


This is gonna be so good!! The other projects and members were:

Get a Room – Jean, Alex, Talal, Marco

To Bump or Not to Bump – Eddie, Hannah, Zoe, Michiel, Thomas, Charlie

Prove It Do It – Nicola, Toan, Nikesh, Joe, Chloe, Jamie

Meet Your Mate – Charlotte, Jeremy, Dave, Peter, Jenny (me)

(Whoa, I can’t believe I just came up with the projects and members from memory.)

Jean pitched Get a Room as a sort of yelp for flats and flatmates. People are to review flats as well as flatmates for future tenants to learn more about what they’ll be getting themselves into, especially if they have no way of visit a flat or meeting up with their flatmates before signing an agreement.

Eddie pitched To Bump or Not to Bump as an app for learning about missed opportunities to bump into certain people. The app will supposedly tell the user the friends they could have bumped into but nearly-missed during the day, 24 hours later. Very interesting concept and I’d be intrigue to see how they execute this idea.

Prove It Do It was pitched by Nicola who wants an app for people, who sponsored their friend to do a marathon or race for charity, to see that their friend is actually suffering training. So it’s an app that shows your friends evidence of your training if they’ve sponsored you.

Finally, as I said yesterday, Meet Your Mate is an app that helps people meet their friends at places that makes the travel time for everyone more or less equal.

We spent Friday setting up our Github repo, integrated our Github repo to HipChat, set up our Trello board, worked out some iterations of our product, hashed out some basic features, and spent a funny amount of time on what bunch of fruits we want as our logo.

We decided to call our product Bunch and wanted to use a bunch of bananas as our team logo, but couldn’t find a classy bunch of bananas to work as our logo, so we thought about maybe going with grapes instead. Clearly, we were focusing on the big issues here. Alas, I was able to find a nice classy image of a bunch of bananas:

bananas copy

Just look at it. So classy.

We had a team lunch and decided we weren’t going to write any code until Monday, but get the planning and organization down instead. The Bunch team spent the rest of Friday looking into APIs we could use: Google Maps, GMaps, Mapnificent, TFL, Foursquare, Yelp.

upload (2)upload

(Notice the lovely signs Jeremy made for the team)

upload (1)

Charlotte had to leave early and I took a nice long nap after Charlotte left before doing some meditation with Dana. At 6, I made plans with Chloe and Enrique to see the Digital Revolution exhibition at the Barbican Centre, so I left Makers early as well. Pretty solid first day of final project.

We’ve decided to meet up over the weekend, but everyone except Jeremy and I were busy on Saturday, so we all decided to meet at Leader Charlotte’s on Sunday afternoon. Jeremy and I decided to meet at my flat to set up an empty rails app to upload to GitHub and Heroku.


MA Day 48: OmniAuth, Gems… and then what?

So today and tomorrow are kind of  free-for-all lecture days because our cohort has been doing surprisingly well and covered all the material we are meant to cover and still have two days left.

We asked Stephen to teach us how to make gems and he demonstrated by building 5-line app that just says ‘Yo’ and then uploading it to as a gem. Screen Shot 2014-08-28 at 9.01.58 PMA lot of the class is little bit obsessed with this new app called Yo, and Stephen absolutely hates it. So we kind of all got a kick out of making Stephen build a Yo gem when he asked us what really simple program he should build. Check out the say_yo gem he built!


largeIn the afternoon, Enrique talked to us about a plethora of things that vaguely fall under the topic of “Makers Academy!… and then what?” He told us that after Makers Academy, we should expect to be pretty shellshocked because of all we’ve been through for the past 12 weeks. He answered whatever questions we threw at him and shared his rich experiences with us as a guy who’s kind of done it all it seems. He’s freelanced, worked at a big company, worked for a startup, coded in the jungle in Costa Rica, started his own company, self-published his own book, Inceptions.

He told us his recommendations on how to move forward as a developer after Makers and what he suggests we all do for whatever it is we want to pursue, be it front-end, back-end, starting our own startup, or anything else. He also gave us some tips on technical interviews, but it was mostly on how he doesn’t believe in them and thinks they don’t work. We still got some good insights on how to approach companies and being a dev for them though.

Then Eddie and I continued to toil away at working on the Insta300px app and implementing the web sockets and Pusher functionality into it. Slowly but surely, we got Pusher quite close to what we wanted it to be doing. The information that we would want a webpage to be receiving would get to the site in real time, and we just need to figure out how to get the page to display it now.

Alrighty, it’s 9:13pm. Time to bounce.