Starting My New Career

The first week after MakerSquare was a bit of a whirlwind, to say the least. After talking with a variety of companies at OpenHouse, I followed up with the recruiters/hiring managers and arranged several interviews for the following week. On Monday, I showed up in person for what I later found out was supposed to be a phone interview. Whoops. Tuesday went much more smoothly. For starters, I was supposed to be there in person and I did, in fact, show up in person. Good start.

My Tuesday interview was with a company called ShipStation, which coordinates shipping logistics for e-commerce retailers. I sat down with the lead developer, whom I had met at OpenHouse, as well as one of the founders of the company. Afterwards, I interviewed with two members of the development team. I enjoyed talking with all of them, learning more about the company and seeing the offices. After 12 weeks in a windowless classroom at MakerSquare, I was overly excited by the floor-to-ceiling windows. I thought it went well, and I left anxious to hear back. Luckily, I didn’t have to wait too long- they reached out with an offer later that day!

I spent most of Wednesday researching ShipStation and the tech stack that they use (C# and .NET).  I was a bit apprehensive about switching over to developing in a Microsoft language after spending all of my 6 months of experience on a Mac. But almost everything I read and everyone I talked to was very positive about C# as a language and as a solid foundation for a junior developer. Plus I was really excited about the people and the company and the prospect of working as a full-stack developer. I called first thing Thursday morning to accept my offer.

Since before starting at MakerSquare, I had a three month job search timeline in my head. I was planning to be unemployed at least through the end of 2014 and possibly beyond. Accepting a position within a week of completing the program was a much quicker turnaround than expected, but I’m excited to say I started my first junior developer job tomorrow! Can’t wait to dive in.

Final Projects (Part 2)

Well, it’s official- I am no longer a MakerSquare student. Open House was Thursday. Our final day of class was on Friday. We turned in our keys and walked out into the world as better, more confident developers.

My two final projects that I presented at Open House were a collaborative list-making app called Lyst (site) and a lecture communication tool that I called DiaLoggr (site).  They are both deployed to Heroku (I included the links above)- please feel free to check them out and let me know what you think!

Lyst was inspired by my friends and our love of planning- we enjoy making lists to cover all of the things we want to accomplish when we are actually in the same city. Users can create private or public lists, share those lists with other users for communal use, and search public lists for keywords of interest. I built it in Ruby on Rails and JavaScript, with an emphasis on jQuery and AJAX.

I was inspired to create DiaLoggr as a replacement for the i-clicker tool user by many universities. It allows discussion leaders to send out surveys for the participants to view and respond to, giving the leaders a better idea of where people stand in terms of understanding or interest level. It also allows for participants to submit questions to the leaders about material and receive answers. The goal is for two-way communication in lectures that encourages open, honest discussion. I used Ruby on Rails, WebSockets and Bootstrap. I also tested the models and features with RSpec and Capybara.

I spent a lot of time on these two projects over the past month- building new features, refining those features, refactoring and testing the code. It was a really good experience but I certainly had my share of frustrations along the way. One instance in particular was trying to implement Capybara as a testing tool for DiaLoggr. Previously, my only testing experience was with RSpec. In learning RSpec, I focused on testing the actual code and ensuring that the methods and routes all made the expected changes in the databases and/or took the user to the right page. Capybara, on the other hand, actually pulls up a browser window and allows you to test the user experience directly- are items appearing on the page when they should, are buttons functioning correctly, etc.

I read the documentation online and several blog posts about implementing it, and felt prepared to add it to my testing suite so I jumped in. But getting it to work was a lot more than I bargained for. I could test routes and check if links went to the right routes and the right titles were there, but the tests failed anytime I was adding elements to the page dynamically. Which was the core focus of my project. Without the ability to test that, my application would not have sufficient test coverage and would be at risk for bugs and issues as I went back and added/updated code.

I tried Googling my problem and kept running into the same solution- installing selenium webdriver and setting js to true for any tests dynamically adding elements to the page.  Unfortunately, this alone didn’t solve my problem. When it started looking for new elements on the page, it stopped routing through the controller correctly and actually making changes to the database, which broke other aspects of those same tests. I was stuck.

After three days of trying and failing to get my tests to run properly, I finally ran across this Rails Cast: http://railscasts.com/episodes/257-request-specs-and-capybara. The combination of the database cleaner configuration and setting config.use_transactional_fixtures to false finally worked! My :js => true tests were functioning as expected. I was able to move on to the next feature of my application, knowing that I had good test coverage. It was a great feeling.

There were many other bugs and issues I ran into during final projects and MakerSquare. That’s what being a web developer entails- solving problems using all of the resources at your disposal. There is no greater feeling that figuring something like that out and feeling good about the result. It’s a huge motivator for me, and it’s one of many reasons I’m looking forward to a career as a web developer. The job search begins…

Final Projects (Part 1)

It is Final Project time at MakerSquare, and the pressure is on…We have Open House next Thursday, November 13 at 6:30pm at the MakerSquare offices (716 Congress Ave). If you are in the Austin area, please feel free to stop by! Here’s a link with the details.

The last four weeks of our twelve week program are dedicated to building projects to show off what we have learned and/or teach ourself new technologies that we want to have experience with going into interviews. We present them to contacts and potential employers at the Open House during the last week of the program, and have them as part of our personal portfolios when we start the job-search. A portfolio is certainly not the only thing that potential employers will look at, but it definitely helps.

So I choose my most awesome project idea and work with the tech stack that follows, right? Not necessarily. As I’ve been reminded, this is not about creating a new or original business idea. I will not be presenting this to investors or finding prospective customers at the Open House- I am simply trying to show potential employers what I know.

Keeping that in mind, it makes sense to look at the companies I am interested in applying to, seeing what technologies/tools they use and implementing those in my final projects.  But I found that process to be much harder than it sounds. Every company uses a slightly different tech stack or tool set, and there are only so many you can implement in 2 final projects over 4 weeks. What is a MakerSquare student to do?

Personally, I made the choice to focus my final projects on the technologies that we have already learned in MakerSquare. I came here to learn Ruby on Rails and JavaScript fundamentals and I wanted to leverage the knowledge of the instructors on those topics for my final projects. I can focus on new technologies for my ongoing side projects (currently working on Haskell, Python and Angular.js) after the program.

More details and hopefully links to my deployed projects in Part 2 of this post next week…

Mentorship

One of the options we have as MakerSquare students is to be matched up with a mentor in the Austin tech community. During Week 4, we had a mentor mixer after class during which the mentors came to chat and mingle to give us the opportunity to find someone we clicked with. Although there were many qualified mentors in attendance, I actually requested one of the mentors who was not able to make it that evening. This had nothing to do with the people who attended, but more so with the profile of that particular mentor. His bio mentioned vast experience in the technology field with current specialization in Ruby on Rails projects- one of the languages I am learning and interested in pursuing. But what really stuck out to me was his very candid opinions- I always appreciate having someone who will tell it like it is.

That was five weeks ago, and my mentor and I have continued to meet regularly. He does in fact have very strong opinions on the Ruby community, the use of Rails as a framework, current programming design patterns and design structures and much more, but that is precisely why I have already learned so much from him. He provides a different, more seasoned perspective than the MakerSquare instructors or other junior developers that I have met.

He also gave me the opportunity to join his newly started Haskell study group, which I jumped at. Haskell is a server-side programming language that is capable of doing all of the same things that Ruby (the server-side language I am learning through MakerSquare) is capable of. But where Ruby is an object-oriented language (which focuses on the data objects that store information), Haskell is a functional language (which focuses on the program functions). If that doesn’t mean much to you, just note that they are very different ways of programming to accomplish the same thing. It’s not easy to add additional homework and readings on top of what I am already doing through MakerSquare, but I believe it will make me a better programmer and help me to look at problems from different angles to find the best solution.  Isn’t learning new things really what mentorship is all about?

Coding Challenges

We’ve been doing a coding challenge per day as a ‘warm-up’ at MakerSquare. Love ’em or hate ’em, coding challenges are a given in the world of programming. They’re like brain teasers, forcing you to break down a problem and work through it until you can find a solution. Ideally, an efficient solution.

Personally, I love ’em. They’re exactly that, a challenge. Being the competitive person that I am, I can’t let go until I understand them, solve them and try to make them better.

Some of them are pretty straightforward:

  • Given a string, determine if it is a palindrome.
    • ‘kayak’ -> yes
    • ‘boat’ -> no
  • Given a list of numbers, find the length of the longest increasing sequence.
    • [1,2,3,2] -> 3
    • [10, 11] -> 2

Others are more elaborate:

  • Given an alphabet, an offset value, and a message, encode or decode the message based on the the offset and alphabet provided.
    • alpha: “abcde”, offset: 1, message: “bbc”, command: “encode” -> output: “ccd”
    • alpha: “abcde”, offset: 1, message: “hallo thara”, command: “decode” -> output: “hello there”
  • Given a text file of speeding camera log data, detailing the times at which different cars passed by each camera and the distance between cameras, determine which cars were speeding.

Either way, they’re brain food for programmers. I always feel like I learn something new through these sorts of challenges. If they’re more straightforward, I push myself to solve it as efficiently as possible. If my first solution isn’t good, I refactor to try to make it better. I feel like I’m on my best programming behavior with these coding challengers. Of course, I’ve barely grazed the surface of the complexity of programming challenges that are out there- some of them completely blow my mind. But it’s a start! Check out some of my solutions here on GitHub.

Quizzy

Last week was a client-side focused week (meaning most of what we did stayed in the browser, to increase the speed of an application and improve the user experience). There are definitely some benefits to this approach, namely not having to make multiple requests to the server and refresh the page. We also built our first Single Page Applications (SPAs), meaning content is removed and added dynamically all on the same page. No additional pages need to be loaded.

To do this, we learned and implemented the MVC (Model-View-Controller) design pattern for JavaScript. Essentially, this separated the data models, the view displayed to the user, and the application logic into three distinct parts. The goal is to keep everything well organized and create modular, reusable code to minimize any repetition.

For any non-technical people reading this, that was probably more confusing than anything. Instead of explaining it to you, let me show you: quizzy.

Quizzy was our project for the week. It’s a basic quiz application which comes with one pre-loaded quiz and the ability to create/delete your own quizzes and add/delete questions from those quizzes. The pre-loaded quiz is “What is your spirit animal?” which is a silly little quiz that determines your spirit animal based on a scientific method that I completely made up. It means nothing, but it’s fun so feel free to give it a try. And if you do, please let me know what spirit animal you got matched up with!

The more complicated aspects revolve around the quizzes that can be added by the user. These are more of your typical quizzes that have a right answer for every question rather than a personality quiz. But you can add as many as you’d like and add/delete questions to those quizzes once they’ve been created.

Word of caution- this app has been optimized for Google Chrome, and may not function as intended in other browsers. If you run into any issues, please let me know but I encourage you to use Chrome for the optimal user experience with this app.

It’s simple, but it works! And it’s my first published app- aren’t you excited to see what else I have in store? I’ll be sure to keep sharing!

ATX Start-up Crawl

The ATX Start-up Crawl was this past Thursday. The idea was for Austin-area start-ups to market themselves to potential employees, business parters and just spread the word about their businesses. The start-ups could host people at their offices or get a table at the Omni Hotel, the main stop on the crawl. There were about 70 participating businesses on the crawl, with most of them at the Omni and about 12-15 or so hosting at their office spaces.

In practice, the so-called start-up crawl also included business such as AT&T, Aetna, Indeed.com, and Visa- it probably would have been more correct to just call it the Austin tech crawl. Here’s a map  for the event that lists all of the businesses that participated.

Although it was more geared toward tech companies than start-ups, overall it was a great event. MakerSquare hosted a stop on the crawl, which was worked well as a central home-base. I also went to the Omni, which was more of a career-fair type vibe, and spoke with several companies, some of which may be hiring junior developers (fingers-crossed).

The vibe at the office locations on the crawl was quite different than the event at the Omni. Many of the business had catered food, kegs of beer, liquor sponsors, DJs, games and more to offer. What started out as a networking event at the Omni quickly turned into one big tech community party around downtown Austin- and it was a lot of fun! Some of the locations maintained the cocktail party vibe, while others turned into techno dance parties, and some were more reminiscent of college frat parties. Keep in mind this event only went from 5-10pm.

The best part for me, on top of meeting new people, was seeing how many people in the tech community I had already developed relationships with. As I was jumping from one business to the next, I ran into multiple people that I had already met in my short time in Austin. It was great really feeling a part of the Austin tech community and familiarizing myself with a lot of businesses that I didn’t know much, if anything, about. The parties were a pretty nice perk as well!