Edwin Unger

DBC Phase 3, Day 15: Final DBC Post

Fri, 05 Jun 2015 00:00:00 +0000

Today was incredible. We were the first to present this morning, and everything went smoothly. I felt confident in our group and what we had to deliver. We kept the time short enough, and there were a few questions about how the app worked, so it was nice that there was interest.

I’d seen all of the presentations already, but it was cool to watch everyone share the projects they’ve been working on for the past nine days. There are seven apps in all, and they all look really polished and impressive. I’d love to see some of these go into actual production, but I’d also like to see some of the pitches that didn’t make it get turned into apps.

After presentations, We had lunch. Some of us went to grab a celebratory drink afterwards, which was enjoyable. I don’t drink, but it was still nice to relax as a team. We got back in time for another chat with the Careers team, which was mainly about preparing for next week’s Career Week.

We had some time to kill before graduation, so we checked in on the Phase Two Final Projects and assisted some of the Phase One students with their challenges.

We also took a cohort field trip, but I’m sworn to secrecy, so you’ll find out only if you are a DBC student or if you ever become a teacher there. Suffice it to say that it was not what any of us expected, but well worth the surprise.

Graduation was really fun. For the past few days, we’ve been allowed to add ‘boot badges’, which are basically senior superlatives, to each of our cohort-mates’ pages. Most were funny, several were heartfelt. I ended up with ‘the wise bearded one’, among several others, so I’m happy.

We were each given dog tags (it’s a bootcamp, after all). Here’s mine:

We had one last check-in with our cohort before heading out to celebrate. It was touching to reminisce about the program and the relationships we’ve formed here. It was a good way to end the day, and the program.

Weekend plans include relaxing, but I don’t think I’ll be able to do much of it. I want to get started on building a new app, update my resume, LinkedIn, and all of my other job site profiles, and get ready for Career Week.

This will be my last post for a little while. I’ll need to spend my time looking for a job, working on projects, preparing for interviews. I would love to say that I’ll keep writing about this whole process until I actually land a job, but I don’t want to make any promises.

And really, I’ve accomplished exactly what I set out to do. I wanted to write for every day of DBC, and I did. I wanted to share with the reader everything I learned and felt and experienced during my time here, and I did.

The promise I made when I first arrived in SF: I will write what I learn every day. For you, the reader, who’s interested in keeping up with my journey through DBC. For you, the potential student who wants to know exactly what happens in this program and if it would be the right choice for you. For you, my current cohort, who just want to read and solidify your understanding of the day’s concepts. For you, my future contemporaries in the tech world. And for me, because when I write what I know, I remember it, and when I teach it, it becomes ingrained in my memory.

I kept my promise, and I hope whatever group you fit into, you found some use in this blog.

My name is Edwin Unger. I’m a junior web developer and a graduate of Dev BootCamp.

DBC Phase 3, Day 14

Thu, 04 Jun 2015 00:00:00 +0000

I’m ready. Ready to be finished with DBC, ready to return to the real world, ready to graduate and start looking for a job, ready to be finished with this project and start working on another one.

I’ve been feeling this way for the past few days now, but wasn’t really sure how to put it into words. I don’t think I’m getting burnt out, because the first thought I have when I imagine the day after DBC is getting started on another project. I also don’t think it’s just this final project, since there’s a lot for me to be proud of, and my fingerprints are all over it. I really think it’s just my brain telling me it’s time to move on to something new.

Today was mostly about putting the finishing touches on our app, though there were a few sections of which we wanted to change the functionality. All of the graphs work properly, we’ve got a nice demo created that walks through all portions of the site, and we’ve added a nice section for extra senses that tell you more about the city you’re visiting. Looks Like, Sounds Like, Smells Like, Tastes Like all give a little more info about the city, such as cool restaurants, the music scene, etc.

We presented a run-through of our demo today, but it definitely did not go smoothly. We kept the whole thing under ten minutes, but it looked and felt unprepared. Luckily, we weren’t the only ones, so we felt a little better, but we spent some time this evening really tightening each section.

Tomorrow is going to be awesome. Presentations, free lunch, graduation, freedom.

Until then, I’m Edwin Unger and I’m a junior web developer.

DBC Phase 3, Day 13

Wed, 03 Jun 2015 00:00:00 +0000

Feature freeze tonight, so there was a lot of hustle to make sure everything we wanted to include in our app was already up in some form on the site. Not really too much trouble for us, though, since we’ve been working on portions of the site from different computers the entire time. We just had to integrate everything into one app.

We figured out a way to take the data for the D3 graphs and split it into multiple charts that directly compares each particular attribute. Instead of seeing the high, low, and average temps for each city on one graph, we can now cycle through three different graphs that compare these temps for two cities directly. This is what we set out to do from the beginning, so it was great seeing it load exactly as we wanted.

We also spent some time integrating some plain English comparisons that one of our team members has been working on. Basically, you take two cities and select a month to compare. It spits out months in your current city that are similar to the selected month in your new city. If it can’t find a comparable month, it lets you know the closest month and how far off it is from what you’re used to.

Tomorrow will be spent cleaning everything up and doing a bit of rehearsing for the final presentation.

Two days until we present. Two days until we graduate. Two days until I have to start looking for a job.

Until tomorrow, I’m Edwin Unger and I’m a junior web developer.

DBC Phase 3, Day 12

Tue, 02 Jun 2015 00:00:00 +0000

Our little weather app is really starting to come together. We’ve built this awesome one page site that uses jQuery to slide in pages from different directions, so each slider will have different graphs that compare the weather of two different cities. I’m sort of working on adding a section that gives other information about the city, including activities, restaurants, pictures, etc. It’ll be nice if it comes together, but the core feature of the site is the weather.

We’re really diving into the D3 graphs now. Two of the graphs are very similar, which are the Actual temp and the Perceived temp. Different data, but duplicating the graphs will be easier. The other graph measures the Daylight, so you can see a nice ‘bubble’ effect in June and July when the daylight hours are longer.

I spent a large portion of the day working with one of my teammates on loading the graphs and resetting them with each click. We were having a bug where one graph would be loaded, but each time we refreshed, the old graph would still be there with a new graph pasted on top of it. We also realized that the API call to the back-end takes about 3 seconds to load all of the data into the graphs, so we had to figure out a way to clear the old data away and immediately load the new data while taking a minimal amount of time. We eventually got it going at a much faster pace, but as I said, it took a large portion of the day.

Tomorrow is feature freeze, which means we can’t add anything new to the app after 6pm. We have no new features that we want to insert, just finishing touches on the functionality of the site.

Until tomorrow, I’m Edwin Unger and I’m a junior web developer.

DBC Phase 3, Day 11

Mon, 01 Jun 2015 00:00:00 +0000

This weekend was action packed, but now I’m beginning to feel the drain. Our team agreed to core hours to work on the project, which means we’re at DBC from 9-6 every day, including weekends. No big deal, but I’m definitely noticing the lack of break time.

We managed to get most of the database seeded, and I’m pretty much finished with the routes that will be used to get data to the front-end. There was a unanimous decision made not to use React or Node/Ember on the front-end, so we’re now building a Sinatra website that utilizes Rails for the back-end. Nothing changes for me, but it makes it easier for the front-end team to create a more polished product.

Today was more of the same, just finishing up the database, working on the key features we’d like to implement, and figuring out what I can do to help the front-end team. We’re also trying to learn D3, but I’m not quite ready to attack that monster yet.

Until tomorrow, I’m Edwin Unger, and I’m a web developer in training.

DBC Phase 3, Day 10

Fri, 29 May 2015 00:00:00 +0000

Well, we’ve already pivoted on our app idea, but now I’m really beginning to be excited about it. We talked for a bit about the direction we expected the app to go, but realized that the market is flooded with every type of weather app already. What did we want to create that would bring a unique touch?

After some spitballing, brainstorming, paradigm shifting, and all those other buzzwords, we settled on the idea of weather comparisons. You can look at temperatures in one city and compare them to another, but it’s difficult to find a place that does that comparison for you based on historical data. With that, FeelsLike was born.

The premise for FeelsLike is this: you’re thinking of visiting or moving to a new city, but you’ve never been there. Wikipedia talks about the temperature, you can look at charts and graphs, but all you get are numbers on a line. How does that city compare directly to your own? Do you need a jacket in April, or sunscreen? We set out to create this app that will compare two cities based on historical data and give you a plain English answer.

The first thing we needed to do was get the data. Well, the REAL first thing to do was to FIND the data. We tried several weather APIs, but decided Weather Underground and Forecast.io would be the best options, since they provide lots of historical data and the specific values that we need. We agreed that five years of data from five different cities would be enough to get off the ground and provide a decent demo. This turned out to be a serious undertaking, however.

Each API request only provides one day of historical data, so we will need to make 9,125 requests to fully seed our database (5 cities x 5 years x 365 days). The trouble is, Weather Underground only allows 500 API requests per API key per day, so each of the four members of our team created a Dev account at Weather Underground so we could cycle through each team member’s API key. After we got everything set up, it was just a matter of babysitting the database to make sure all of the weather objects were being created properly. This will end up taking a few days, but should give us everything we need with plenty of time to spare.

While watching the database, I started building routes to the back-end data. We’re still planning on a fully decoupled app, so I volunteered to provide all of the data in easy-to-find JSON chunks.

On the front-end, the team quickly realized that React.js will be very difficult to learn in such a short time, so there will be a solid decision made over the weekend about either buckling down with React, checking out Node/Ember, or going back to Rails. We also have to figure out D3 during all of this, so there are a lot of hurdles to get over.

Until Monday, I’m Edwin Unger and I’m a junior developer.

DBC Phase 3, Day 9

Thu, 28 May 2015 00:00:00 +0000

Well, today kind of sucked. Not all of it was terrible, but enough that it’s kind of spoiled the rest of the day for me.

We delivered our pitches to the entire school today, and man, there were a lot of pitches. There are 28 of us, and there were 28 pitches. Some people didn’t pitch at all, but some people pitched two or even three different ideas. I even gave a few of my extra ideas out to people who hadn’t planned to pitch. Everything went well, and there were a LOT of good ideas. However, there were quite a few ideas that seemed like jokes or were poorly thought out. No big deal though, since there were plenty of good pitches to choose from.

Voting turned out to be a disaster, though. Rather than let us each vote on the seven apps we wanted to see get made, we were each only allowed to vote once. I knew this was a bad idea, because anyone who pitched would only vote for their own idea. Of course, that’s exactly what happened. One app had five votes (I’m assuming those who voted for it planned it out ahead of time), and four other apps had two votes each, which was enough to confirm them as final projects.

There were two slots left, but there was a tie. a fifteen-way tie, each of which had only one vote. As expected, everyone who had pitched an idea voted for their own app. We had to hold another vote to decide which two apps would get moved forward. There were several requests to scrap the original results and re-vote, but they were denied. We voted again, most people voted for their own apps again, and the two winning apps each had only four votes.

I don’t mind that my app ideas weren’t picked, since I can always make them after DBC is over. My frustration comes from the fact that so many great ideas were pitched and the ideas that were pushed through were not the best that we have to offer as a cohort.

After voting on apps was through, it was time to request the app that we each wanted to work on. I got my first choice, which was a weather app that would dig into D3.js and make some beautiful graphs from the data we found. I chose this app not because I am interested in D3 or weather, but because the team lead is incredibly talented and I know we’ll end up with a decent product at the end of it. For me, it’s all about the demo-ability of the app, so I expect great things in the next nine days.

We immediately sat down together to go over the plan for the app. Our team lead had already created a basic weather app for his Phase 2 final project, so this was meant to be an extension of that. We would find a better way to present the data, expand the coverage to the entire country, and display graphs of the weather changes over time.

I know the next week will be challenging for me, mainly because we’ll be getting into technologies I’m not familiar with, namely React.js and D3. I’m looking forward to pushing myself and delivering a product I can show off to potential employers.

I guess we’ll have to see. Until tomorrow, I’m Edwin Unger and I’m a junior developer.

DBC Phase 3, Day 8

Wed, 27 May 2015 00:00:00 +0000

I’m going to graduate DBC. I was pretty confident that I would, but after destroying today’s Assessment, I can breathe a long sigh of relief. Not only did I get through all of the test’s requirements, I had time to go back and add extra functionality to some of the sections, just for fun. I’ve still got a lot to learn before I’ll feel like a confident web developer, but I’ve now learned everything that DBC has to teach me. All that’s left is to complete a final project and then actually find a job. I am officially a junior developer.

After the assessment, a few of us went out to celebrate and relax a bit. The afternoon brought more Thunder Talks, but there were so many groups that waited until today to present that it took a couple hours to get through everything. I spent some time preparing my final project pitches, but I feel pretty good about what I want to create and how to go about doing it.

The pitch practice with the team was a little difficult, since we have to cut everything down to under a minute. I did okay, though. It was really nice to hear a lot of people offer support and suggestions for making my app ideas work.

Until tomorrow, I’m Edwin Unger and I’m now a junior developer.

DBC Phase 3, Day 7

Tue, 26 May 2015 00:00:00 +0000

We presented our Thunder Talk on Server Initiated Communication first thing this morning. I feel like it went really well, and I’m looking forward to using FireBase on my final project, or on another app in the near future.

We talked about how regular server/client communication works, how SIC has improved that, and some of the technologies that utilize it. FireBase is the best known one, and it’s especially useful to us at DBC because it’s fully supported by several different languages and frameworks, including Rails.

The challenge of the day was to create Twitter completely asynchronously in Rails using AJAX to make a one page app. My pair and I stumbled through it for quite a bit and only managed to get a few of the features working, namely the top trends and top tweets to post as they were created. There was a lot of JavaScript involved, and some of it was just beyond our understanding at the moment.

Afternoon brought a brief chat with the DBC Careers team, but it still felt like most of the information was being kept from us. Most of the questions we asked were side-stepped and we were told not to worry about it until after we graduated. It made me think that any communication with careers should just wait until they’re ready to actually share information. Ah well.

The afternoon lecture was by a guest who’s currently being interviewed to become a DBC teacher. She was very nice, but wasn’t fully prepared with the appropriate materials, so I felt like our time could have been better spent working on the Twitter challenge.

This evening, several of us got together to prepare for tomorrow’s Assessment. We knew that we would be expected to build a CRUD app and create AJAX requests in Rails, so we set about doing just that. It took us a little while to create all of the controllers, models, and migration files, but once we had the first couple pages created, we decided to focus on the AJAX calls, since that would be the more difficult part. We managed to make everything work, and I’m feeling pretty confident for tomorrow. It was especially helpful to be the one writing the code and creating the app, because I always learn better by doing than by watching.

Until tomorrow, I’m Edwin Unger and I’m a web developer in training.

DBC Phase 3, Day 6

Mon, 25 May 2015 00:00:00 +0000

I spent the weekend accomplishing almost all of what I set out to, though there wasn't enough time to study for the Assessment. Instead, I finished my portion of the Thunder Talk on Serve Initiated Communication and finished decoupling my Stack OverFlow clone in order to present it today. I'm planning to have a code review on Tuesday night with a few people, so that should be sufficient preparation for the Assessment.

Today started with presentations, and I wanted to be the first to go. I was really proud of the work I'd done to decouple the app, but I'd also styled the app a bit and put in a few funny animations for my team's entertainment. Here they are for you as well.

Stack GopherFlow Home Page:

Stack GopherFlow Edit Page:

Did I mention that our Cohort team name is the Pocket Gophers? I'm sure I did at some point.

Our lecture this morning brought us into some advanced JavaScript, mainly IIFEs, Closures, and Modules. Here's a quick rundown of each:

Immediately Invoked Function Expressions, or IIFEs ("iffys"), look just like any other JavaScript function, except that they have a '()'' at the end so as to immediately call them as soon as they are defined, like so:

function example() {
  console.log("I'm being called immediately!")
}();

This is different from the normal pattern, where you'd create the function and then call it at a later point:

function example() {
  console.log("I'm only called by my function name!")
};
example();

A Closure in JavaScript is basically a function within another function. The inner function has access to the variables and parameters of the outer function, and calling the outer function returns the product of the inner function's actions on the outer function's data. Here's what it looks like:

function outer (parameter) { 
  var outerIntro = "I'm in the outer function! ";
  function inner() { 
    var innerIntro = "Now I'm in the inner function!";
    return outerIntro + innerIntro + parameter; 
  };
  return inner(); 
} ;
outer(parameter);

Finally, using a Module in JavaScript allows you to define functions and keep their variables from being accessed outside the function.

var modular = (function() {
  var sum = 0;
  return {
    add:function() {
      sum = sum + 1;
      return sum;
    },
    reset:function() {
      return sum = 0;
    }
  }
}());
console.log(modular.add());
console.log(modular.add());
console.log(modular.reset());

Our challenge for the day was to rebuild jQuery with several parts of its functionality. I was very intimidated at first until we looked into what each call was doing. We figured out how to hide items, display them, and change their class so as to add other attributes. We even added definitions for clicking, so an action could happen based on how we interacted with the object.

After lunch, we had our first round of Thunder Talks. These were all pretty interesting, but not much applicable use to me right now. I'm definitely interested in learning more about background processes like auto mailing, since that seems to be a nice Rails tool to get into, but it's still a bit down the road for now.

The afternoon lecture was on JavaScript promises, and I'm still trying to wrap my head around how they work. From what I understand, a promise allows you to to define a value that isn't available yet, but may be in the future. When it is, the promise can be fulfilled and the function run. If the value never becomes available, the function never runs. There are other outcomes, such as the value being rejected, or an error, but when done correctly, the function simply waits for the value until it's available. Promises will be a huge part of JavaScript 6, so this is definitely something I want to get more comfortable with.

In the afternoon, we went back to working on the jQuery challenge. After that, I worked with my Thunder Talk team to rehearse a bit before tomorrow's presentation. We divvied up what each person would talk about in addition to our own technology, so the whole thing should go very smoothly.

Until then, I'm Edwin Unger and I'm a web developer in training.