Category Archives: Hackbright

Hackbright Academy experiences

Week 7 – SF Sun Finder Project Progress

Development progress has definitely been enlightening the last week and a half.  I’ve summarized highlights that have taken place to show what I’ve gone through so far and an example path of developing a HB project.

At the end of week 6, I spent Thurs. playing with Balsamiq and mocking up all kinds of ideas. Friday, I spent the day catching up on emails and just getting things in order so I could think straight. Then all I did over the weekend was start setting up my virtual environment.

This past Monday, I started to really build out the first couple Flask views. I also took some time to finally learn about CSS and how to apply it to the HTML pages. Having a couple working pages kept me motivated throughout the week.

On Tues, I built a temporary local database in SQLlite to map a couple SF neighborhood names to central coordinates. I used this for initial test purposes and applied the SQLAlchemy package to interact with my db. It was a nice brief practice in designing databases and utilizing a seed file to populate.

Wed I began learning how to use and integrate the Forecast.io app into my application through requests (vs. urllib). I was able to complete the loop of capturing a user query, pulling coordinates from my local database, using the coordinates to request forecast information and then posting the results on the HTML results page.

So guess that means I’m done…not exactly.

Also on Wed, I finally finished understanding how to keep my API keys secret in my environment and not posting them to Github (hint: .gitignore is your friend as my mentor thankfully showed me). I had worked on that as a side research since Monday with lots of help from my instructors. Last, I searched for really cute stock photos to use for each weather instance so I would enjoy looking at my results.

On Thurs, I started to build out the more details page, tweak existing pages and build out some validation points on the data (e.g. is it day and if percent cloud cover is less than 20% then a sun should show vs. partly cloudy). That was the day that I finally realized one of my biggest challenges which was based on my initial design, I was apparently trying to recreate search. Definitely a fantastic challenge but so much bigger than the scope of what I can handle right now. Fortunately, I also happened to talk to someone that day who had worked for Google and thankfully clued me in on a potential solution with Google Places.

Friday I started to investigate the Google Places API. I also confirmed that Weather Underground (WUI) does have more details and variations between SF neighborhoods. So I started reading up on how to use that API in addition to Forecast.io. Friday was really about research and tweaks since we did field trips most of the day.

This last week, we talked often about minimum viable product  (MVP). Meaning prioritize the development that will give the most basic functionality for demo and testing. Technically I could argue my app is done since it does the most basic of functions, and I’ve already been sharing it with my classmates. Reality is that there is so much still to do. If anything a common challenge is that I am constantly thinking of new features and functionality that I want to add and its great practice on prioritization. So the change out of WUI could wait in comparison to other functionality since Forecast.io has very valid data.

Something to also note is that in addition to all the coding, we had several speaker visitors throughout the week, went for some cool field trips as mentioned and did interview practice every other day. By Friday, my brain was tired. It was a funny feeling because it was not the usual tired feeling and my head was not cottony like the first several weeks. I just knew I was at the no brain state anymore. It happens and is a good sign to take a break.

Advertisements

In Need of a Neck Beard

Neck Beard

In Hackbright we talk and joke a lot about the great, mighty beards of computer scientists and software engineers. Initially, I was clueless to the jokes. Not a fan of beards, I couldn’t understand why anyone would want one.

Apparently, there is a tendency in the computer science community (esp. from the older school) to grow beards. The beards are supposed to be a symbol of the scientist’s knowledge and prowess in the field. We would talk about the long beards and grey beards and so forth. Yes, there was Lord of the Rings references at times when discussing beards.

So I got that correlation point, but it wasn’t till I was halfway through the program that I really got the underlying point. I find myself regularly grabbing at my chin in thought when discussing different topics at school. I frequently wish there was something more there to get a good hold of. My classmates, and I have joked about tying our hair into a ponytail in front of our faces as an alternative, but it just is not the same.

Thus, I now have neck beard envy. “Oh ye mighty beard, how I get it now.”

Hackathon Quick Bits for Beginners

I participated in my first hackathon a week ago, Gates & Facebook HackEd 2.0, with several of my fellow classmates. The hackathon’s focus was about building apps to improve education especially around college going, retention and social learning outside of school.  There are others who were there that wrote some great overviews on the experience like KWu’s post.

I just have a couple quick bits to share about this experience and what I understand so far about hackathons.

  • There is usually a purpose or theme to work towards
  • Great way to practice problem solving under pressure (like exam cramming)
  • Opportunity to meet and work with people you don’t know
  • Don’t think too much about what you don’t know
  • If there is something specific you want to practice, go for it (it’s a great space to do that)
  • Make sure you have the tools you plan to use already loaded on your computer
  • Length is a couple of days typically with people working through the night (catnapping where they can)
  • One day (like what we did) is not a lot of time (esp. for beginners) to build something substantial (so have fun with it)
  • Make sure you take breaks and take a look around because it will be over in a flash
  • Plenty of food is provided
  • Make sure to get to your demo (if you have one) when presenting
  • Present the concept even if you don’t have a demo
  • Begin with the end in mind

On that last point my friend and teammate, Marissa, kept our group on task with the perspective that the presentation was our end game. So we focused on building back from that point. We sketched out the first couple pages and agreed to focus on building with JavaScript even though we all wanted to code in Python. The reality was that we only had 3 pages and the point of our app was going to be conveyed in the look and feel of those first couple pages. When we presented, our app was very much a rough draft. Still we had something to show, we did present and it was a good learning experience on the whole.

Enhanced by Zemanta

The Final Project Kick-off

It’s the end of week 6, and we are in the thick of our starting and/or working on the final project. It could be called a type of thesis, and as I mentioned in a previous post, it has caused a lot of excitement over what to do for a variety of reasons. This post is to covey two main points: what I’m doing and key points to get started.

My Project:

My classmate, Kelley, wrote a great post on her experience and challenge with choosing a project, which I can definitely relate to. Figuring out what to do and putting a stake in the ground with so many ideas is not easy.

The concepts from our class have run the gambit from Gulnara’s focus on developing a new programming language to Lindsay’s work on automating text mining from scientific journals. Many of us are targeting web applications and/or a data analytics tools with very different goals in mind.

In the interest of time, I have shifted my initial plan from using the Arduino and Raspberry Pi despite my desire to learn the technology. We have about 3 weeks before we present at Career Day, and faced with that reality, I am targeting a web application to really solidify what I have learned regarding the LAMP stack. If there is time I may try to leverage the Raspberry Pi to expand functionality, and if not then there is always personal projects after the program.

The idea for my project came from trying to figure out where to get some sun during a hike last weekend. Living in SF, the weather can be tricky from neighborhood to neighborhood let alone where you are in relation to the bay. This is a very Bay Area centric issue, and I’m fine with sticking to that scope (for now).

Most weather sites already cover this in one form or another, and I’m sure someone has done or is already doing my project. Still I want to make a solution that quickly answers the question I have when going for a hike. Also to note, Hackbright encourages us to recreate solutions that exist from a purely academic perspective (we are here to learn).

I plan to continue to post on the experience as well as publish my progress on Github.

Last point for anyone interested, this idea is different from what I used in my application to Hackbright, and I think about 80 to 90% of the rest of the class is doing something different than what they applied with.

How to Start

  • Set a goal

“When deciding on a project, figure out a question you are trying to answer or problem you are trying to solve.” – Christian

This quote really helps set the stage on how to find a project as well as to keep perspective on what you are trying to accomplish. If you are trying to figure out how to get ideas, look around you during the day and think about things that could be done differently or better through technology.  If there is a technology and/or concept you want to thoroughly understand, this is a great way to recreate and practice it. One main point that we hear time and time again is to do something you enjoy because that will motivate you to learn.

  • Think about the audience

While trying to define what you want to do, keep in mind who the main audience is and how you will use this application. Usually, you want to think about who will use the application and/or who will buy it. For most of the students, it’s about having something to showcase our skills on Career Day to an audience of engineers looking to hire. Additionally, this is about the learning experience and leveraging the resources we have at school. You can have other audiences or Career Day does not have to be a focus for you. Just make sure you are clear on who you are really producing this project for and what you want to get out of it.

  • Keep time and scope in mind

We’ve heard that most students up to this point didn’t finish their project. Meaning it wasn’t fully executed to the extent that they planned. They all did finish their projects to the point of having a solution to present at Career Day. What finished means can be debatable. You may have a passion for a concept, but if you find that its too ambitious for the timeframe, be open to scaling it back to accomplish the real purpose of the project. Don’t let your ego get in the way of being able to deliver for the underlying purpose.

  • Make a plan

We were asked to first plan our project before doing any coding. Planning is key to breaking down the problem you are tackling into digestible pieces. This means research, wire-frames and pseudocode.  My mentor recommended a couple online wireframe tools (Keynote Kung-Fu, Mockingbird, Balsamiq), and several students just used the back-to-basic pencil and paper solution. I did use the trial-version of Balsamic for my wireframes, and really enjoyed the ease of it. They are not paying me to post this, and I didn’t try the other options; thus can’t compare. The main goal of this point is that you need to make a plan so you can break the challenge into small enough steps for work to begin.

  • Start

Don’t ‘boil the ocean’ with the plan. Its so easy to get lost in in the details of planning and never get started. I even got so into my wireframes this week that I made lots of notes of things I’d like to do in future versions. Its important to be aware when you have enough planned out to get started, and you can always come back to continue refining later. If you are still not sure where to start, the instructors and your cohort are very helpful on giving pointers. Just start somewhere.

  • Manage time

If you are able to plan out milestones and activities for each week or day when planning your project, knock yourself out. For most, I would recommend keeping the presentation date in mind and target to have the core of the project work largely done a few days before. This means plan to stop working on any major functionality additions or changes. Give yourself a couple days so you have time for tweaks and getting it ready to show as well as to practice your presentation.

  • Be very flexible

Flexibility is a valuable skill to learn and with any project, it will almost never go according to plan. I’m pretty sure I have yet to see any project I’ve been a part of and/or planned, go exactly as expected. The key to success here is the ability to adjust and to do it quickly. This is when a goal keeps you sane. As long as you know what you are going after, you can stay focused on it and figure out how to get there while accounting for challenges.

The points above are take-aways from working on this project so far as well as experience with projects in general. A blank canvas can debilitating at times but it is surmountable.

 

Stomach ache (aka not enough time challenge)

This week I felt like a kid with a nasty belly ache after being left alone in the tech candy shop. There has been so much interesting and fantastic things to learn and experience, and I hit the wall with trying to do it all at once. I know better. My career for the last several years has been about prioritization. Still here I am gorging on the tech candy because it’s so hard not to.

This past Monday, the wall came in the form of feeling like a trigger switch in my brain (like it was revolting against me) and everything we were talking about suddenly went Greek. It was frustrating to the point in which it made me cry….twice.

This is not easy to admit. I am very conscious of showing any sign of what may be perceived as weakness in public settings. Years of working in business has taught me how quickly perceptions and belief in your abilities is shaken by the sight of doubt let alone tears. Plus, showing signs of vulnerability is hard when others may try to use that against you. And when you have limited time to generate value and are trying to drive efficiency, it can be very distracting.

On the flip side, I understand the cathartic value of a good cry and letting out the emotions just as much as a regular workout, sports, etc. can help balance the stress. Crying makes me human at the end of the day and when I’ve moved through the emotions, it’s also helps me move on from the challenge and keep going.

This program is far from some of the most stressful experiences I have taken on and accomplished/overcome in my life. I have cried for stupid things as much as for major challenges. I still don’t know how I managed to setup my father’s funeral arrangements while he was near death without shedding a tear (probably denial). I have shed plenty of tears since, but it goes to show that crying can come or not come at weird times.

I know that at the heart of my embarrassment was that I’m thinking I’m one of the oldest in the program and I shouldn’t be crying. I should demonstrate confidence and support my classmates. The reality is there is strength in showing and owning these emotions and what better place to have them than in the classroom. I know it, I still struggle with it and it doesn’t make it any easier if it happens again.

If anything this week really emphasized how special this program is. The women in the class, the instructors and my mentor, in different ways gave me a shoulder to lean on, encouragement, commiseration, reasons to laugh, and help to work through the programming challenges I was working on.

I totally had the thought, “screw it, I can’t do this” and after crying, I picked myself up and tried again. And I did make a couple of breakthroughs this week. I think Objected Oriented and LAMP are finally sinking in and I found that I really understand recursion. Still there is so much to learn and do and it only serves as a reminder, to pace myself and enjoy the accomplishments in whatever form and whenever they come.

Last point on this, we had a great field trip to Salesforce at the end of the week. A panel of women engineers gave us insight into their background and experiences. Without us even saying anything, they talked about all the different challenges and fears that I’ve heard from classmates and felt myself. They also talked about the “not enough time challenge” because there is so much cool stuff that you want to learn. In addition, they recommended saying yes to opportunities. I asked them how do they balance between the two concepts, and the response was being very clear in regards to personal and work priorities.

They also said it is an ongoing challenge and they recommended getting comfortable with being uncomfortable because that’s how you know you are learning.

 

Finding a Project

As we near the halfway mark of our program, the top of mind question is: ‘What project will I work on?’

It can be a stressful question when there is still so much to learn, there are concerns with picking something too simple or too complex, there are so many options to pick from, and that we know it will influence whether anyone at career day will invite us to interview.

The instructors at Hackbright have been providing one-on-one guidance last week and will continue this week to help coach students picking a worthwhile and reasonable project. They’ve already given pointers to us about not picking something that is mobile or just front-end. They are recommending to go for something that can present our ability to work across the stack. One recommendation that is coming through from the instructors and the mentors is that we should focus on something that is reasonably attainable and then build out from there.

I’ve already heard some really interesting ideas from my classmates and admittedly, I want to try to do them all myself.  One project that someone is taking on this year is writing a compiler and I heard from an alum that she developer her own web analytics tools.

My main interest is around data analytics and the tools that are in existence or being created to improve this field. I’m also fascinated by the cheap, mini computers / electronics that are out there and their potential use. Similar to programming, electronics have intimidated me. Thus I thought, it would be good to tackle that challenge while in a classroom environment.

Recently, I purchased the Arduino and Raspberry Pi and I currently plan to use them in my project. I’m still noodling on the specific project goal. My general direction is to integrate the two technologies and use a type of sensor to collect/analyze data and then present back a decision/reaction/output.

More to come and soon on where this will go next.

Days Blur Together

I can’t believe I’m already 3 weeks into this 10 week program. I was thinking through what we’ve learned so far this weekend and thought it would be helpful to post the core programming concepts to help keep it in perspective.

Week 1

  • Keyboard shortcuts
  • Terminal command line
  • Python language and logic for math, strings, tuples, lists, dictionaries
  • Git & Github

Week 2

  • Continuing dictionaries & general Python review
  • OOP (Object Oriented Programming)
  • Markov and APIs

Week 3

  • Markov (continued)
  • Regular Expressions
  • SQL
  • Stack integration (LAMP)
  • HTML

Week 4

  • LAMP (continued)
  • Flask
  • JavaScript
  • Recursion
  • Interview practice

Week 5

  • LAMP (continued)
  • OOP (continued)
  • Flask (continued)
  • SQLAlchemy
  • Recursion
  • CSS

Week 6

  • Project (primary focus)
  • Interview practice
  • Predictive Analytics
  • Bash (continued)
  • Wire-framing

Week 7

  • Project (primary)
  • Interview practice
  • Data Analytics

Week 8

  • Project
  • Project
  • Project
  • Interview practice
  • jQuery
  • Cracking the Coding Interview presentation (McDowell)

Week 9

  • Project

Week 10

  • Career Day
  • Graduation

We also have lectures that cover different concepts from what types of jobs are out there for the skills we are learning to computer science overview (how the computer functions). They broke the lectures into consumable size and spread out throughout the program when they think we are ready for those concepts.

We’ve been told that we are moving through the material faster than they expected. It does go at a fast clip. I typically try to review what I’ve learned either end of day or on the weekend to make sure I’m soaking it in.

I plan to update this post for the remaining weeks as we go through them for myself to keep track as much as for anyone else interested.