Noelle Learns Things

Musings of a nerdy community manager and marketer exploring the craft of computer science. You can also find me on Twitter as @elnoelle.

[noellelearns]

 It’s...ALIVE!

Well, almost.

With two weeks of project time down, I’m pretty pleased with the progress I’ve made so far. At this point my project meets all of my initial goals of: scraping Craigslist, finding housing within a certain radius, and calculating the commute time. As I expected the most challenging aspects during week 1 were accessing the Craigslist data in the first place, making sense of it (arrays in arrays in objects in arrays in objects, oh my!), and deciding how to handle potentially outdated data. Fortunately the Google Maps and Distance API were an absolute breeze, thanks to their exceptional documentation and elegant Python wrapper.

The challenge I didn’t expect? Just how much Javascript I’d be writing. Since about 80 percent of my application’s interaction happens on one page, you can imagine it requires many, many event listeners and AJAX calls. There were all kinds of interesting design & efficiency decisions I had to make as a result. For instance, calculating distance with the Google Distance Matrix is a very resource-intensive task, which makes calculating the distance of 200 points from a given origin impractical and inefficient. Additionally, the user only really needs access to this information when they click on a particular posting. So in this case it makes much more sense to wait until a map marker has been clicked to make the API call and calculate distance. Afterwards this calculation can be stored along with the rest of the post information via the “favorites” page.

By far the most helpful tools for sorting out decisions like these were 1) mapping everything out with a pen and paper and 2) putting myself in the user’s shoes. While I am an avid (er, obsessed) Asana user, I found that physically writing things down helped me solve problems more easily and quickly. Additionally, during times when I was at risk of going down a programming wormhole (”maybe instead of adding this drop-down I should add a completely irrelevant feature that will be SO FUN TO BUILD!”), grounding myself in how people would actually use my application kept me focused. The survey data I gathered was invaluable for this. Thank you to you lovely readers who responded!

~~~

That’s it for now! Up next week: refactoring my Javascript to make it easier to maintain, writing more tests, and adding support for cities beyond the Bay Area.

Stay tuned! Check out other project updates here:

https://github.com/noelledaley/hb-final

[noellelearns]

Hello there! I'm researching apartment hunting and commuting as a part of my Hackbright Academy final project and I'd love your input. This survey should take no longer than 5 minutes. Thank you so much for your help! -- Noelle

It’s project time, folks! The first half of Hackbright is over, and tomorrow we begin working on our final projects full time.

After spending a few weeks brainstorming I’ve decided to build the #1 feature I wish Craigslist had: the ability to search for housing by distance and commute time from a key point of interest.

Without going into too much detail, I’m excited about this project for a few reasons:

It’ll help me solidify and showcase the technical skills I’ve developed at Hackbright thus far: Python, Flask, Javascript/jQuery, AJAX, CSS, SQL, ORMs, MVCs, and Object-orientation.

It’ll expose me to even more interesting libraries and frameworks! Scraping and visualizing data from Craigslist will require a lot of front-end magic, which I’m excited to explore.

I’ll get to learn more about mapping and geocoding, which is a longheld fascination of mine.

I’ll gain experience working with a pretty large dataset.

Before I dive into the code, though, I’m conducting user research to inform my process and design. If you’re reading this -- I’d love your input! Check out the link above for a 5 minute survey on apartment hunting and commuting. 

Thanks for your help!

--Noelle

[noellelearns]

I spent the better part of last weekend taking a break from SQL homework to work on a small side project called “Motivational Sloths.” My overall goal was to solidify some of skills I’d learned so far in a way that was fun and lighthearted. We’d spent the previous two weeks learning JavaScript, jQuery, and Flask, and were just starting to build full-fledged web applications. With so many new layers to our programs, I was initially confused about when to use Python vs. when to use Javascript and decided to get some extra practice. Plus, I wanted to brush up on my JavaScript syntax, since it had been a while since I’d last seen it!

“Motivational Sloths” is pretty straightforward, as you can see from the photo above. Users click on a button and are presented with a random Beyonce quote and sloth image. However there’s quite a bit of fun-programmy-goodness happening beneath the surface. Within this little app, I’m using Flask, Python, JavaScript, jQuery, AJAX/JSON, CSS and Bootstrap. Here’s how I laid everything out (you can also view my code on Github here):

Python: sets up and runs Flask server; stores list of quotes and sloth images via built-in os module. For a larger project this type of data would be stored in a database and accessed by a Model, but that seemed excessive here.

JavaScript / jQuery: watches for user behavior (i.e. clicking the button), and manipulates the DOM. This was the main distinction I gathered between between backend languages like Python and client-oriented Javascript: JavaScript is all about manipulating the DOM.

AJAX/JSON: sends a request to the server to fetch new information without reloading the html. Magic! 

CSS/Bootstrap: for responsive styling

I was able to tackle this project in about five hours total. I breezed through the Flask set-up, stopping only briefly to learn more about the os module, which I hadn’t used before. By far, the hardest part (as expected) was perfecting my JavaScript syntax. I spent a brutal three hours trying to debug a simple jQuery error -- I’d used ‘click’ on an event listener instead of ‘submit’. On the plus side, I gained much more experience using the JavaScript console, and tested out various jQuery methods I wasn’t sure about. Through troubleshooting I also learned more about JSON and how to successfully convert python dictionaries into JavaScript objects. I certainly learned my lesson when it comes to bugs, though -- test early, and test often. Your future self will thank you.

[noellelearns]

Brief Advice for Pair Programming

A core component of Hackbright’s curriculum is pair programming. They do this not only because pairing is common in the industry, but because it’s a great learning hack. Working collaboratively with a partner helps you hone your technical communication and problem-solving skills as well as your ability to empathize. It’s helpful for learning new concepts and solidifying knowledge you thought you already knew.

However, pairing can at times be downright difficult, and not necessarily for technical reasons. The psychology behind pair programming is sometimes hard to navigate. It’s one of the few experiences I can think of where you’re exposed to the inner-workings of someone’s mind relatively quickly. As such, it can lead to feeling vulnerable.

I enjoy pairing and find it generally rewarding and helpful. So I’ll leave you with a few pieces of advice I’ve received or picked up on my own that have helped me be a better pair:

Plan how you and your pair will work together. How will you divvy up roles? How often will you take turns?

Plan what you’ll do if you get stuck. Will you ask for help immediately? Check the docs or StackOverflow first? If you have conflicting ideas on how to move forward, will you try both?

Be self-aware. I think this is often implied but ought to be said more explicitly. To be a good partner/teammate in general, it’s incredibly helpful to do some self-reflection. Understand what you need to do good work. Be aware of how you communicate. Understand what makes you frustrated and why. Figure out how to turn your frustration into productive curiosity. Then:

Communicate your needs explicitly. If you’re feeling rusty on a particular topic, let your pair know. Likewise, if you prefer to test often, or not at all, let them know. Of course, don’t forget to offer your partner the same courtesy!

[noellelearns]

Debugging Python Programs with Pdb

This week at Hackbright: I gave my first technical lightning talk!

I chose to dig into the built-in python debugger (pdb) because I’ve found it to be an immensely helpful learning tool. While python error messages are great for quickly locating and assessing bugs, as a beginner it’s valuable to understand everything leading up to the error. Pdb does this by allowing you to step into your program so you can check on variables, functions, and so forth. In other words, Pdb helps you debug interactively. It’s awesome.

Lately I’ve been using Pdb even when I don’t encounter an error to make sure my program is working the way I expected. A few times, I’ve stepped in only to realize that while I ended up with the “correct” result, my script actually arrived there in a way I hadn’t at all intended. Almost always this teaches me something new about a given method or data structure.

You can take a look at my notes and slides above. 

Happy debugging!

[noellelearns]

Hackbright, Week 1

After months of anticipation, Hackbright is finally here! We just wrapped up our first week of class, and I’m feeling a bit like this:

I knew that we’d hit the ground running, yet my mind is still blown when I reflect on how much I’ve learned in just one week. It’s exciting and challenging and a bit intimidating, but mostly, it’s really rewarding. 

A few of the topics we’ve covered so far:

Navigating the command line (so long, drag-and-drop Finder windows!)

Algorithms and algorithmic thinking

Version control, git, and GitHub

Data types and python functions

Computer memory

Mutable and immutable types

You can see some the concepts I’ve learned in action by viewing my homework samples here and here.

One of the lessons I found most helpful was computer memory and mutability. I had encountered these topics in preparation for Hackbright and loosely understood mutable types as values (lists, dictionaries, etc.) which can be changed, and immutable types as those whose contents cannot be changed (strings, floats, integers). However I learned this week that mutability is tied to computer memory. That is, at the most basic level, variables in python are really just references to objects in memory. When you make a change to an immutable type (such as s += “hello”), Python creates a brand new object in memory with a separate ID and points the variable to it. Whereas changes to mutable types (like list.append(”hello”) can be made without storing a new object in memory. This becomes increasingly important to understand in order to write complex functions and efficient code, as described in this blog post.

Outside of the technical instruction, one of the things I’ve really enjoyed about Hackbright so far is how much the staff focuses on maintaining a healthy learning environment. Check-ins, Q&A, and breaks are built into our schedule. We talk freely about combatting feelings of inadequacy or perceived failure. We understand that getting stuck means you’re about to learn something awesome and that it’s far better to ask for help than to pretend you understand. (And if you didn’t already see my last post, go check out Sasha Laundy’s talk on giving and getting technical help!) Learning to program in a mere 10 weeks is an incredibly difficult task, but with such a supportive environment, I’m ready to tackle it head-on.

Now, on to week 2!

[noellelearns]

Two months ago I had the great pleasure of attending PyCon, one of North America's largest PyCon conferences in the beautiful city of Montreal. As a community manager, I’ve been to quite a few developer conferences over the last few years, but this happened to be my first Python conference. At the time I had just begun to really dig into Python, and with Hackbright just around the corner the timing of PyCon could not have been more perfect.

The conference -- just as I had hoped -- was wonderful. I was impressed with how kind and welcoming the Python community was and how diverse they were in their interests, industries, geographies, and backgrounds. I met data scientists from Boston, undergraduate astronomers from Wisconsin, linguists from Puerto Rico, hardware hackers from Nicaragua and many, many others. It was reassuring to see that there are in fact all kinds of people in software.

I attended several great talks, although Sasha Laundy’s “Your Brain’s API: Giving and Getting Technical Help” really made an impact on me. Being articulate and asking concise technical questions has been a crucial part of my learning process. It’s the skill I rely on when I hit a wall and am unable to solve a problem on my own.

Here’s a few of Sasha’s takeaways that I found useful:

Rules for asking for technical help:

Confusion is a sign you’re about to learn something.

Ask for feedback when you’re about 30% done with a project instead of 90%. You’ll be much more likely to implement their feedback this way.

When asking a question, try following this formula:

My current understanding is ___. I expect to see ___ here but instead it’s doing __. Why?

Rules for giving technical help:

Remember “the curse of knowledge”: you can forget what it’s like to learn a new topic.

Watch your language. Avoid terms like “easy,” “obviously”, “just”, “well actually”, which can come off as dismissive or condescending.

These guidelines are immeasurably valuable for a beginner like myself, but they can also apply to all experience levels (and even disciplines). Overall communication skills help you become a better programmer, a better teammate, and ultimately help you produce better products.

Check out Sasha’s full talk above, and read her blog for more resources.

[noellelearns]

How Did I Get Here?

Not surprisingly, I've found myself telling the story of how I became interested in programming a lot lately. Generally the conversation with friends, family members, and particularly coworkers has gone something like this:

Me: "I'm going to Hackbright!" Them: "Wow, that's amazing! Did you hang out with engineers so much that you decided you wanted to be one?" Me: "Um, kind of? But there's a lot more to it!" Them: "Cool! Tell me about it!"

As I prepare for Hackbright and set up this blog to document my learning, I thought now would be a good time to share my story.

For most of my school years, I considered myself a fairly "technical" person (I use the term "technical" loosely here, as I'm not a huge fan of the "technical" vs. "non-technical" binary). I excelled in math and science classes, casually enjoyed puzzles and logic games, and especially loved tinkering with gadgets like Game Boys and robotics. When my mom brought home our first desktop computer one day in middle school I was enamored.

Throughout middle and high school I taught myself bits and pieces of HTML, CSS, and web design thanks to the emergence of Super Cool Pre-Teen sites like Xanga, Livejournal, and, um...Neopets. However as much as I enjoyed building out my (by today's standards) crappy websites, for some reason I never actually connected my interest in computers and the web with school. The stuff I was building while hunched in the living room felt totally separate from computer class. I especially didn't identify with the glorified vision of a calculus & physics-obsessed SuperGenius™ that several of my male classmates embodied, so over time I let my hobby slip away, convinced computers (let along engineering) certainly weren't "for me."

Flash forward to the last few years where I've been working in the tech industry as a Community Manager. From the get-go one of the reasons I've enjoyed this role is because it involves interacting with interesting people building apps and software that I use every day. Talking to developers at meetups and conferences tapped into my inner-geek, and more and more I started to feel a real sense of belonging -- a small voice that nudged, "hey, these are my people."

So I started getting back into programming. A little CSS here, a little JavaScript there, maybe a little Ruby -- all with the initial intention of being able to communicate better with the communities I was managing. But then I really started to enjoy it. I shifted my focus to Python and suddenly (and by suddenly, I mean after months of studying after work) concepts like loops, dictionaries, and functions finally made sense. What’s more, as I delved further into programming, my narrow vision of what a programmer "could be" broadened. Through work I became more involved with the community and met amazing mentors like KWu, Jonan Scheffler, Liz Abinante, Davey Shafik, and countless others. With their support, along with a whole lot of late nights thinking about What I Want In Life, I realized that programming is something I can not only do, but do well, if I truly dedicate myself to it.

Thus...Hackbright. Dedicating myself to learning and switching careers is at once daunting, thrilling, and a bunch of other things.

But mostly I'm just excited.