Dev Bootcamp Blog @devbootcamp-blog - Tumblr Blog

DBC NY Student Project: Thoughtly

Link: thoughtly.io

Built by: Adrian Soghoian, Ian Shuff, Richard Macias, Natalie Baer

What is your app?

Have you ever found an article on a topic of interest, but did not have the time to finish reading or explore the topic in greater detail?

With Thoughtly, users can easily mark topics of interest and return to them later. Thoughtly takes the topic, and searches for relevant information, which is stored in an intuitive and user-friendly interface, allowing users to quickly explore topics in detail.

Why is this app meaningful to your group?

This project introduced us to a wide range of new and interesting technologies, and the final product will be useful to us as we learn about new topics.

What technologies did you use and why?

We used the following APIs:

Google Freebase

Alchemy Concept Tag, Keyword Tag, and Scraping

NYTimes

YouTube

Financial Times (Education version)

Coursera

TED

Wikipedia

Chrome.storage

We used some of these interesting gems to improve our project:

SASS

HTTParty

Google API client

Capybara

Dotenv

We used the following technologies:

Google Chrome Extension

Ruby on Rails

Javascript

Describe the workflow process of your team

We each focused on one area at a time, as delineated in Trello. We set milestones every day and a half, and had standups every 2.5 hours to ensure we were progressing towards completion. Each milestone included a list of features we intended to implement along with ownership.

What struggles and problems did you encounter? (both technological and interpersonal)?

No interpersonal challenges. We had a democratic process. We abided by Holocracy and used Trello.

For areas that required group input we worked together, for new topics we paired. There were some technical challenges but none were insurmountable:

(1) Learning new libraries: Ian focused on learning arbor.js and though it was challenging he was able to make a successfully functioning node graph.

(2) Unexpected API responses: Some of our APIs did not give back information or function as expected. For example, we originally planned to use the Freebase API as the backbone of our project. However, upon further investigation we found that it did not provide the information we expected to see. Rather, we used a library of other informative and curated APIs. To get the names and descriptions to appear, the API information was insufficient and we had to use scraping.

(3) Challenges with authentication: Adrian spent significant time on authorization and authentication, trying to get the Google Chrome extension to play well with the website. Though he ultimately succeeded, the path included installing and uninstalling several potential options.

In hindsight, what might you have done differently?

We originally over-focused on making our app a single page app and explored using Angular JS. Ultimately we decided to prioritize feature development and felt we could achieve a comparable result through simplicity of design and a friendly UX.

What's next? (what features would you like to add, etc)

Further refine the algorithm to increase the accuracy of topics returned from the Alchemy API

Oauth on rails app and Chrome extension

Create more entry points for users to create categories. For example, node interaction with category list or text fields.

DBC NY Student Project: SuprStar.me

Link: suprstar.me

Built by: John P Quigley, Kenneth Mendonça, Kai Prout

What is your app?

SuprStar.me is a karaoke app that allows you to host your own karaoke event anywhere and anytime. In order to provide a seamless interaction between users and our application we integrated the Twillio and Youtube API’s allowing users to choose a song and comment on friend’s performances all from their phone. We use the Twilio and Youtube API’s together to provide an easy way of texting in your name and song to populate a queue with the karaoke version of your song.

Why is this app meaningful to your group?

This app was way too much fun to work on! It allowed our group to express their creativity and pursue those interests. With such a project features and design went as far as any members imagination. While this may have resulted in a long list of icebox features we were able to accomplish the core features necessary for the app to function while also pursuing any personal goals.

What technologies did you use and why?

Twilio API – This API was utilized to allow users to text in their song and comments about the ongoing event.

Youtube API – This API was utilized to allow us to filter the incoming songs and provide the user with the top result for karaoke.

Alchemy API – This API was utilized to allow us to find the sentiment value of a users comment, which we used to display in our customized Boo Meter.

Describe the workflow process of your team

From day 1 our team did an amazing job at laying the groundwork by making sure that organization was a key priority. By utilizing tools such as Trello, Google Docs, Mockingbird(wireframing), and email/messaging our team made sure that everyone was on the same page. To further enforce our belief in constant communication we did standups nearly every 2 hours or when a major accomplishment took place.

What struggles and problems did you encounter? (both technological and interpersonal)?

One of our biggest struggles came when our group had to make the tough decision to rollback and loose a full days worth of work due to deployment errors on heroku. Our decision resulted in us correcting our misunderstandings and moving forward collectively with a stable ground under our feet. We had other struggles (websockets, callback, responsiveness…)

In hindsight, what might you have done differently?

In hindsight rather than using the polling technique to ping the server for our incoming comments and songs we would have liked to implement web sockets to allow for a live more effective and efficient updating process of our comments and songs.

What's next? (what features would you like to add, etc)

While the goal of our app was to avoid having users walk up to a computer, enter in their song and name we would like to consider being able to manually add users to the queue. This would allow for individuals who aren’t as tech savvy to still use our site.

Another feature we would like to consider adding is if someone would like to do a randomly generated song.

DBC NY Student Project: Firstperson.io

“People know each other better on a journey.” -Plaatje proverb

Link: firstperson.io

Built by: Joe Cohen, Matthieu Gavaudan, Greg Piccolo, Vic Schaeperkoetter, Drew Teter

What is your app?

FirstPerson.io immerses the user in a gamified version of their real life. Using the Foursquare api we allow you to check in at various locations in order to gain experience points. You can interact with other players by accepting quests or making your own and watch as other people complete tasks and reach checkpoints to gain rewards.

Why is this app meaningful to your group?

We wanted to offer a fun way for people to cooperate. communicate and compete with each other on both everyday tasks and special occasions. The app is designed to motivate and reward the end user for discovering new places, traveling far distances and notifying they friends of their discoveries. We also saw an opportunity to offer brick and mortar businesses a new way to add value and offer deals to customers.

What technologies did you use and why?

We used the Foursquare api because it allowed users to check into various locations and automatically receive a response to our POST route. However, Foursquare does now allow us to search their location database by address. To fix this problem we used the geocoder gem to provide foursquare with location coordinates and later implemented the MapQuest api when we used up our requests.

To display quest and check-in locations we chose to implement the gmaps4rails gem as it allowed us to access the Google Maps api and display the information in a meaningful way.

We also choose to factor in distance between check-ins when we calculated experience for users. The Haversine gem proved to be easy to use and quick to implement.

Describe the workflow process of your team

We have documented our team workflow through Trello.com. Tasks have been organized into ‘Current’ ‘Done’ ‘Backlog’ and ‘Icebox’ categories and the tasks were moved according to completion status.Our Wiki, which is linked to our repo on Github also includes a daily summary of what was implemented and topics that were discussed in our stand ups.

What struggles and problems did you encounter? (both technological and interpersonal)?

We maxed out geocoder's api requests in testing and had to swap it out for a set of custom written methods to access MapQuest's api. The gmaps4rails gem did not have built in support for some features we wanted to implement so we had to hack it into working behavior. Javascript's asynchronous nature made it hard to write events we needed to happen in a sequential order. Foursquare does not accept localhost as a valid push route so we had to do most of our feature testing on Heroku.

In hindsight, what might you have done differently?

In hindsight, I think we should have learned more about concerns and service objects. They would have allowed us to write better and cleaner tests. Additionally I think our design would have been improved by a more test driven approach.

What's next? (what features would you like to add, etc)

We'd like to implement a system where you can gain experience in a specific class based on the category of quests you complete and locations you check into. For example, when you check into a hip restaurant your "Foodie" points increase.

We would like to add the ability to create custom rewards and trade rewards with other players.

The ability to create different kinds of user accounts so that businesses can create special quests and adding friends to your account.

DBC NY Student Project: ReadyReader

Link: http://ready-reader.herokuapp.com/

Built by: Ben Brostoff, Greg Knudsen, Brendan Susens-Jackson

What is your app?

ReadyReader is a mobile and desktop compatible reading platform that allows users to upload and read documents sentence by sentence. Readers can comment and bookmark content that peaks their interests. The application saves a user’s progress to his or her local browser, making offline bookmarking possible.

Why is this app meaningful to your group?

We are firm believers in free and open source education. eBooks in many respects represent the great equalizer with regard to the knowledge economy, and we are proud to play a part in delivering content to users at zero cost. Additionally, books do not necessarily deserve to be read in a linear fashion and, in our opinion, should be interacted with. Finally, mobile reading is especially important for frequent commuters (we all take the train to Dev Bootcamp), and serves as a means of improving one’s knowledge base during travel time.

What technologies did you use and why?

Our application was built using the Ruby on the Rails framework and included significant JavaScript and AJAX on the client side. We also made significant use of the following technologies:

jQuery UI -- jQuery User Interface provided the tools for us to build a slider with custom tick marks to represent bookmarks. We utilized event listeners to dynamically change book progress as the user moved the slider to the left and right, and initiated a number of tasks (e.g. saving to localStorage and the database) upon slider release.

localStorage --- HTML5 localStorage was the vehicle through which we saved user progress offline. localStorage can hold up to 5MB of key-value pairs, and every time a user opens up a new book, we create a new key-value pair. Users do not overwrite each other since the key uniquely distinguishes user and book.

Redis and Resque -- Initially, when we uploaded our first epub, the request timed out. However, after careful investigation and evaluation of our method for parsing the sentences, we were able to streamline this process down to a reasonable amount of time, but the client was still blocked while this process was occurring. Moreover, the uploading process still seemed sluggish and left the UX much to be desired. Utilizing Resque and Redis, we were able to use workers to pass off the heavy lifting of the upload and parse process from the controller and create a more streamlined and anxiety-free uploading process for the user.

CSS Media Queries - Our early attempts at configuring our stylesheets for different devices were a mess. Greg took it upon himself to organize the CSS and SCSS into well segmented files, and also mark off different media queries in these files. Greg could often be seen during this project hunched over his iPad, iPhone and two monitors in a state of intense concentration.

Describe the workflow process of your team

Our group was fortunate enough to have three team members who took strong initiative to work on parts of the project that inspired them. We democratically made decisions and did not have a project lead or team manager. When an individual team member struggled, he would pair with another member to improve spiking, refactoring and other processes. Our team trusted individual members to run with certain processes -- Greg led the charge on mobile and other device responsiveness; Brendan devoted a significant portion of his time to performance optimization; Ben took a deep dive in localStorage.

What struggles and problems did you encounter? (both technological and interpersonal)?

“Tokenizing” content is extremely memory intensive and optimizing performance presented the largest technical challenge for our group.

Initially, our approach was to store all tokenized sentences in an array within the Book model. Tokenization occurred before save at the database level. As a result, upload time was relatively poor, and our group quickly abandoned this approach.

Next, our group tried tokenizing upon page load. While this approach improved upload time, it was commensurately costly to page load time. Also, the only way to find the total sentences (“pages”) in a book was to tokenize and count - each tokenization process weighed on our performance.

Finally, our group elected to create a separate Sentences model wherein each sentence constituted a separate Sentence object. Tokenization occurred once at upload for each book. After this point, all sentences were available to us as strings. Total pages could be found by a simple count.

This final approach did not solve the slow upload time issue, and our group as a result began to research background jobs and secondary databases. We eventually settled on using Redis and Resque. Importantly, this research and implementation effort was led by Brendan, while Greg and Ben paired and individually worked on mobile responsiveness, bookmarking and slider “jump to” functionality. We found a major strength of our group was our ability to split up and regroup without sacrificing strong lines of communication.

Additionally, making the app responsive to mobile devices was a high priority. Formatting the content for up to 8 different screen sizes was both challenging and fun. Greg spent many an hour sandboxing different media queries whilst frantically checking his iPhone, iPad and desktop browser.

In hindsight, what might you have done differently?

Our group underestimated the challenges inherent in styling and positioning for different browser sizes. Were we to start over, we would have made a style guide and wireframes for all views on the major different media types. Because the app is not graphics heavy, it is easy for the user to notice elements that are not well positioned.

We also would have done pseudo coding and planning on (i) parsing individual books and (ii) devising a plan for storing sentences in our database. We went through an extended process of trial and error on both (i) and (ii) - improved planning would have benefitted us on both.

What's next? (what features would you like to add, etc)

Our group would love to have this application be truly designed for mobile. As currently constituted, “gesturing” functionality is very limited in ReadyReader - the user cannot swipe left, right, up or down, which are all motions most mobile users expect mobile applications to have.

In addition, we would love to support file types beyond EPUB. We did some very preliminary research into PDF parsing tools and believe supporting PDFs is an achievable object.

DBC NY Student Project: Quotemunk

Group Members

Judy Jow, Dave Kerr, Raghav Malik, and Ken Sin

Why is this app meaningful to your group?

A lot of us are avid readers and we wanted to build a tool to allow readers to discuss books and share ideas by quoting passages.

What technologies did you use and why?

We used the GoodReads and Twitter APIs, OAuth, cron jobs, Trello, Git, Github, Travis-CI, Rails, SASS and Javascript.

Describe the workflow process of your team

Our group worked in two day sprints with multiple stand-ups during the day. We did code reviews for all pull requests, ample testing, and made sure to maintain good communication.

What struggles and problems did you encounter (both technological and interpersonal)?

Problems we encountered included: non-friendly GoodReads API that required us to scrape with Nokogiri, OAuth request tokens behaving unexpectedly, trying to implement TDD while learning new technologies.

In hindsight what might you have done differently?

We would have started styling and designing sooner, and we would have spent more time upfront spiking on Twitter and GoodReads for our app before focusing our efforts on GoodReads.

What’s next? (what features would you like to add, etc.)

We would like to make the app more community oriented by having friends lists. We would like to add media queries to our app. Adding privacy to quotes. More quote sorting and book club functionality in general would be nice.

DBC NY Student Project: Percolate

Group Members

Mario Marroquin, Tim McClung, Indigo Nai, Simon Zhang

Why is this app is meaningful to your group?

In the same way the Dev Bootcamp curriculum emphasizes learning how to learn, Percolate is an exercise in meta-ideation. We wanted to create a tool where the potential for improving the world was not limited to a science, a study, or a scene. When we looked at other discussion forums we noticed the conversation streams were linear and often lost the core of the dialogue. We wanted to build a more dynamic tool to display conversations around ideas.

What technologies did you use and why?

The majority of our application is written in Javascript. There was a heavy focus on Raphael.js. Since we decided to go with a single-page application, all of our HTML, JS and CSS is loaded at once and then dynamically altered. We utilized Travis CI to continually test our project every time we committed and pushed a change onto Github. We created our own JS MVC framework.

Describe your team’s workflow process

Our group used a hybrid of a forking workflow and a feature branch workflow. We trusted TravisCI for merge validations and each used our own forks of the main repository so we could all submit pull requests. This allowed us to spend as much time as possible on feature development.

What struggles and problems did you encounter (both technological and interpersonal)?

Technologically, our biggest difficulties arose from our core app residing on a single page. Raphael exacerbated these difficulties since we had multiple canvases residing on the same page, which were in turn toggled to the front and back depending on specific event triggers. This nested event structure coupled with a Solution factory that handled both level 1 and level 2 canvas element creation made identifying dom elements especially difficult.

Interpersonally, we would sometimes face communication problems when we would all focus on our own tasks. We amended this by having standups more frequently and pairing on tasks more often. We would also get frustrated when it became apparent that we couldn't add all the features that we originally intended, but by stepping away and looking at the big picture, we were able to prioritize and get Percolate where we needed it to be.

In hindsight, what might you have done differently?

In the beginning our team was divided over how ambitious we should be with our project given the time constraints. Ultimately we ended up reeling back some of the features we had originally hoped to finish.

If we were to repeat this project, we would design it with less emphasis on the front end at first, because we spent the first several days just learning how to use Raphael.js. We also wouldn't aim to have a one page application, because it would have allowed us to implement many more features.

What's next?

Next we want to implement a physics engine with either traer.js or d3 so we can create a more animated bubble effect, incorporating gravity into the canvas. Model wise, we would like to implement improvements to solutions. Currently we only have solutions, neglecting one of the key components of the original vision of being able to trace an idea's iterations back in history. There is a lot of potential for Percolate and we all look forward to continuing to work on the project.

DBC NY Student Project: EmotionAll

Group Members

Kevin Zhou, Danielle Adams, Jake Huhn, Ruben Osorio

Why this app is meaningful to your group?

EmotionAll brings light to the often-forgotten yet always-present pillar of the human condition: the universality of our emotions. No matter where in the world you might be, or be from, there is always that underlying feeling that governs everything from disposition to thought to eventual action. EmotionAll is a platform by which we can analyze the world's emotions, both visually and dynamically, in order to better understand the fundamental ideal that in the end, we aren't so different after all.

What technologies did you use and why?

Because our app relies on being able to know the user's location, we used both Twitter's REST API and the Streaming API to maximize the amount of tweets we could find where the user shared their location. We then used AlchemyAPI to analyze the sentiments of each Tweet and record the sentiment scores to our database. Finally, using the Highcharts library, we were able to make a heat-map based on the averages of the sentiment scores for each country.

What the process workflow of your team like?

Although our team was made up of disparate personalities we were able to circumvent these very real differences thanks to a solid leader in the form of our team lead, Kevin, whom was insistent on persistent stand-ups in order to ensure group cohesion. By doing so, the team was able to both move forward and apart, respectively, by working autonomously on branches that ultimately formed a much larger tree of cooperation. In the end this workflow created a successful and rather idolatrous group process.

What struggles and problems did you encounter (both technological and interpersonal)?

Continuous integration setup via Travis CI was a difficult learning experience. We also encountered some trouble when setting up Jasmine testing due to gem incompatibilities. We didn't realize the Twitter REST API had a 100 tweet limit on search queries until 2 days in, at which point we started supplementing with the Twitter Streaming API. Heroku's limits on background tasks and table entries led us to search for a new host. We ended up switching to Ninefold because of an ad we saw on Stack Overflow and it's been much better.

In hindsight what would you have done differently?

For testing, we would have liked to have done more up front analysis to determine the appropriate testing suite. Since Highcharts provides so much functionality, there was very little homegrown JavaScript to test so jasmine testing was not worth pursuing for our application.

What’s next? (what features would you like to add, etc.)

- See sample tweets connected to a trend to give the sentiment analysis more context.

- See charts showing further trend analysis (ie: sentiments over a given time period).

- Geolocate tweets onto the map since we have the coordinates in our database already.

- Allow users to enter a trend to track.

- See world average for a trend.

- Incorporate more real-time information.

DBC NY Student Project: Embark

Github: https://github.com/cicadas-2014/Embark

Group Members

Jason Matney, Dinesh Rai, Lasse Sviland and Jessica Tatham

Why is this app meaningful to your group?

The member of our group who initially pitched the idea for Embark has had a lifelong passion for travel. As a team, we were motivated to turn that passion into a real product, and inspire that same sense of adventure in our users. There are plenty of reasons to not travel, but with this app, we hope to get users to see that there are just as many, if not more, reasons to get out there and create an experience.

What technologies did you use and why?

We used the Panaramio, and G Adventure APIs as they provided a rich repository of categorized adventures. Our group also considered, but rejected the Groupon and Rome2Rio APIs as well as the Alchemy sentiment analysis API and an interactive globe built with D3.JS. We ultimately chose not to use these because they either they were too difficult to implement or because they provided us with different results than what we were looking for. We used the Geocoder gem to categorize adventure distances and the Curb gem to access the G Adventure API.

Describe your team’s workflow process

Initially our process workflow was discrete and logical, as it involved basic tasks which had a low probability of failure. We utilized the same workflow that we had been practicing over the last nine weeks, which allowed us to design the schemas, wire-frame the pages, and pitch feature ideas seamlessly. Naturally each of us were drawn to different elements of the project.

Lasse was very strong with manipulating the database

Jessica maintained a calm poise and parsed out available features

Dinesh also looked into implementing novel technical features

Jason checked out different websites for design inspiration

As the days wore on and our project grew in size and complexity. As we were hit with new challenges we were forced to shift our workflow. Rather than designating an individual to work on a piece they were drawn to, we were more motivated by time constraints, compelling us to switch to a workflow based on feature priority. As such, the most technically-skilled member of the group morphed into a de-facto team lead, as much of the workflow began to run through his ability to implement different features. Our process workflow had morphed from a collaborative sphere into a more hierarchical tree. This, as mentioned, was a necessary response to the situations we faced, and ultimately proved to be an effective strategy insofar as we were able to the release our highest priority features.

What struggles and problems did you encounter (both technological and interpersonal)?

Our struggles were pretty normal and we were able to come together to overcome them by working together. We were twice forced to revert back several hours on our main repository. The first time, we were inspired to refactor some shoddy CSS by consolidating the different pages into a single layout. This was a great idea in theory, but unfortunately implementing the refactored layout proved difficult and ultimately ended up breaking the website. Fortunately, we handled the situation pretty well by lowering our heads and returned to work after the problem had been solved. The second revert occurred on Wednesday in the final 48 hours before our project was due when a push broke one of the main features of the site. This caused distress among our group. However our team lead corralled the troops and got us back on course to complete the final push towards our live website.

In hindsight what might you have done differently?

The team became proficient at time boxing. When we first started the project, we would attempted to finish every task we signed up for on the trello board. By the end though, we chose to move on after the time box was over and would eventually come back to incomplete tasks with fresh eyes, where the solutions came to us much more easily.

What’s next? (what features would you like to add, etc.)

In the future, we would like to incorporate a rotating globe displaying markers where our adventures take place. Users will be able to rotate the globe and select a marker to view the adventure. We would also like to incorporate infinite scroll on the adventures index page. Also our group envisions the app providing users with a way to easily start their adventures by giving them access to travel options, such as flights through our app.

Inside Dev Bootcamp New York From the Student Perspective

What if there was a school where the students graded the teachers instead of the teachers grading the students?

"I give Dev Bootcamp an A" says one student from New York, "it's not an A+ though."

Dev Bootcamp operates in a way that most schools could only dream.

We iterate on our program every 3 weeks and take feedback directly from our students on what they like and didn't like.

The principles of Empathy, Learning, Building, Feedback and Impact guided our first cohort in San Francisco and continue to fuel our program today.

We definitely care what our students think and appreciate when students share both positive and negative feedback.

Below is a 45-minute conversation with Dev Bootcamp New York students, Ken, Jake, Kevin and Dinesh.

To save you some time and give you just the good stuff, we've linked to key discussion areas throughout the video.

1:22 - Does Engineering Empathy and yoga help with your coding?

5:52 - What does a typical day look like at Dev Bootcamp?

7:10 - What do you think of the work load? Does it consume your whole life?

9:30 - Why are we making this podcast?

12:55 - Advice for someone considering DBC

18:33 - Tips for our Phase 0 students

If you're interested in learning more about Dev Bootcamp NYC, be sure to check out our weekly meet up events or visit our NYC campus page on our website to meet and connect with our team.

rube-on-rails-deactivated201611

"And in the midst of this wide quietness/A rosy sanctuary will I dress/With the wreath’d trellis of a working brain," - Keats

I’m long overdue for an update. I graduated Dev Bootcamp June, 21st; that means I’m already done with Phase 4, the optional 3 week-extension where topics like...

orayward-deactivated20180119

And finally, last Thursday, after 12 weeks, was my last day at Dev Bootcamp.

After these 12 weeks, I don’t consider myself a fabulous programmer, but I do consider myself a great beginner with an incredible hunger to keep on learning and improving my technical skills.

On Thursday, we had...

roybahat

Got this email from a CEO I respect. Struggling with one of the essential issues for any working person.

Respect went up 2x when I got it:

Team — Now that some of the chaos is over, I need to focus a bit more on the family — or at least give them the time they deserve. To that, I am going to...

kateybasye

Final projects are over, Banana Slugs are graduated, sleep has been caught up on, and I’m here, facing endless possibilities—which translate into endless things to learn and do.

Our project ended up great. SchoolSay is an education news aggregate that pulls from Tumblr, Twitter, Instagram, and...

saintsintosea

Tomorrow I wake up with no alarm clock. For the first time in a little over 2 months I no longer have to wake up at precisely 7:30 AM so I have enough time to get ready, eat, and walk to Dev Bootcamp.

It’s been an amazing journey. A lot can be said, let’s see.

I love you all

(That’s me...

kateybasye

“What is family? They were the people who claimed you. In good, in bad, in parts or in whole, they were the ones who showed up, who stayed in there, regardless. It wasn’t just about blood relations or shared chromosomes, but something wider, bigger. We had many families over time. Our family of origin, the family we created, and the groups you moved through while all of this was happening: friends, lovers, sometimes even strangers. None of them perfect, and we couldn’t expect them to be. You can’t make any one person your world. The trick was to take what each could give you and build your world from it.”

Quote by Sarah Dessen: What is family? They were the people who claime…

Relevant.

(via kateybasye)

orayward-deactivated20180119

And finally, last Thursday, after 12 weeks, was my last day at Dev Bootcamp.

After these 12 weeks, I don’t consider myself a fabulous programmer, but I do consider myself a great beginner with an incredible hunger to keep on learning and improving my technical skills.

On Thursday, we had...

mattbarackman

This past weekend, everyone in my “Red Admiral” cohort of DBC was given our mid-point assessment. It was the last hurdle to clear before being fully accepted into the program and I’m happy to say I passed.

They didn’t give much feedback, but I felt that my performance was really solid. I’d love...

Trending Blogs

Recently Viewed Blogs

Dev Bootcamp Blog