Category Archives: Hackbright

Hackbright Academy experiences

Flask Mega Tutorial, Sun Finder and SheCodes

It has been a busy several weeks and I’ve written just as lengthy of a blog post as last time from all of it. After deploying my Rails app, I switched gears to refocus on Sun Finder (through an indirect route). I signed up to present the app at SheCodes Conference on August 9th (yesterday) and I wanted to spiff it up a bit.

Flask Mega Tutorial (detour)

Before going back to Sun Finder, I spent a week finally going through the Flask Mega Tutorial which I had wanted to do since March. I highly recommend it because it goes from setting up a virtual environment through full stack development to a variety of deployment options. Going through that after the Rails tutorial was valuable because it solidified common concepts around web application structure (e.g. configuration, app instance setup, db setup and integration, where to delineate between view and controller). And of course it was helpful to contrast the differences to better understand how much Rails does for you behind the scenes.

New Stuff
The tutorial was great to help me work through a full Flask implementation on Heroku. I wanted to go through this so I would be able to better navigate how to finally deploy Sun Finder. Additionally, Flask Mega covered a couple concepts that I hadn’t seen yet and I was pretty excited to learn:

OpenId allows using one username and password to login to multiple websites. This is also known as decentralized authentication standard. Flask provides a package for easy integration, and the benefits of course are to simplify the number of logins that users need for all these websites. To note, OpenId is not OAuth which is another login concept that sometimes gets confused with OpenId. They can be used together or separately. OAuth authorizes one website to have access to another website’s data about a user (e.g. Facebook and Spotify) while OpenId is just a single login sans data sharing.  Some key benefits of logging in with these applications are you don’t have to deal with password storage security, validation and resets. Its basically outsourcing your site’s login.

FlaskBabel is a package that determines the primary language (e.g. Spanish) set in the client’s browser and then displays the site in that language. Granted there is some setup including translation efforts to get this to work, but once it is setup, the web application becomes multi-lingual.

Moment.js is a more user-friendly date time rendering library that uses the client’s browser to track and display time based on her/his time settings. This is a better way to display time because it will adjust to user preferences from zone to whether to use a 24 hour clock and/or the order of month, day, & year. The server-side can store events based on utc timestamp, but when displaying date time on the client’s browser, the utc timestamp will be converted by Moment.js.

Coverage.py measures code coverage by providing an easy to use report that notes which parts of the code have been tested.  This is such a great package to use because figuring out the balance of how much to test is tough and this really gives a good understanding of where there are gaps to help pinpoint what tests to add. It’s also really easy to add in this package.

Last on my list, the tutorial went over how to set up your own server. I actually skipped this section for now because I needed to get back to Sun Finder and Miguel warned it would be a long chapter for the uninitiated.  I’m definitely going to complete that chapter because as always I want to learn about everything and I think setting up a personal server sounds fun.

On the whole the tutorial was great to reinforce concepts I’ve learned so far as well as expand my exposure to new ways to work. I’m a big believer in practice makes perfect in this space and going through this process as much as possible will hone skills over time.

Return to Sun Finder

So I finally opened up Sun Finder again and I really hated it when I got back to it. I could see how much I didn’t know when I had written it. I felt like there were so many obvious flaws that it’s a wonder I got any interviews at all after career day.

After hating on it for a bit and having a hard time reviewing where I left off, I talked with a few people who have been in the industry for a while about the fact that this is typical. We write code, we learn and we see all the flaws in what we wrote before (we also wonder what we were thinking when we wrote it) because we are always learning and growing. So my focus needs to be on how far I’ve come. I mean really, I did start coding in late Feb. Building a full stack app in 4 weeks between April and May was and is impressive no matter how noobie it its. And the fact that I saw so many ways to improve it reinforced how much I have learned.

Standard App Structure
I did find that I wasn’t afraid to completely rip up what I had started with and rework the whole thing. That used to be a problem for me back in May because changes completely threw me since I didn’t have as solid grasp on site structure and functionality. This time I literally overhauled my project to align the Flask Mega structure so it would function like other apps and be setup for deployment.

Reworking the structure was a challenge because Flask Mega recommended using an extension package that preconfigured SQLAlchemy vs. direct interaction (my setup back in May). The main difference is that the extension takes care of some of the configuration especially running and maintaining the database session (accessing and storing data). A little more specifically, the package generates a SQLAlchemy object when the application is passed into it. Using the package vs. working directly with SQLAlchemy gives access to all the same functions, a preconfigured scoped session, the engine and a declarative base that is a configured Model baseclass with a query attribute. To note, the session still needs to be committed when working with a database, but it doesn’t need to be removed at the end of a request.

Additional tricky bits included the fact that Flask Mega focused on applying SQLite throughout the tutorial and I already had Postgres setup with my project. SQLite is directly integrated into the web application for local storage while Postgres works separately and requires an adapter (e.g. psycopg) to integrate with the web app. The main change I needed in my code from Flask Mega was that instead of writing the database reference to a file in my web app folder like below:

  • SQLALCHEMY_DATABASE_URI = ‘sqlite:///’ + os.path.join(basedir, ‘app.db’)

I needed to write it the code to point to the location of my separate postgres database as noted:

  • SQLALCHEMY_DATABASE_URI = ‘postgresql://localhost/sun_finder_db’

A couple clarifying points, the os.path.join is just pulling the directory path for where the application is stored using basedir variable and app.db is the SQLite db file which is the equivalent to the Postgres db file named sun_finder_db. I left the SQLite code the same as what you would see in Flask Meg in case you reference that setup.

Javascript & JQuery:
After restructuring the files and getting my app to work, I started focusing on how to improve views dynamically. I easily spent a couple of weeks beating my head against the JavaScript wall. I read and worked with various documentation including the JQuery site and Code School as well as other resources. Also, I did a lot of trial and error with my code. There were definitely times where I made progress in my understanding and many others where I felt like I was back in the mire of figuring it all out.

During Hackbright, we spent 1/2 week reviewing JavaScript. There is a lot to cover in 10 weeks when learning full stack development and becoming an expert in all of it at once is not doable. Still, JavaScript is a complex beast that takes time to get to know. It is not like other scripting languages and requires practice to understand it. That practice is worth it because it is very valuable and just continues to grow in importance in the web. Similarly, JQuery is just as important and you can consider it JavaScript’s close relative. JQuery primarily provides shortcuts to Javascript code and ensure performance consistency across browsers. I highly recommend taking the time to learn and understand both.

My initial use of Javascript and JQuery in the app really was because I had a lot of help from my instructors and mentors. I didn’t fully understand how the code worked and what it was doing. Spending the time I did over the last couple weeks helped force me to really appreciate whats going on and how to apply the language. I also actually enjoy using it now despite the fact that it still frustrates me any time it can.

One key change is that I applied the Bootstrap typeahead plugin (akin to autocomplete) from a code challenge I did back in June. Typeahead in essence uses an Ajax (asynchronous Javascript and XML) call to pull data from the server without changing the display or behavior of the existing page.

The real improvement came from the fact that I no longer passed the full contents of the database into the view and then looped through it to create and display the list of predictive text in my search bar. In May, I had been really proud when I first built that functionality out because it was what I understood at the time and it worked. This time, I understood how to pass the request from the view through the Ajax call and build a targeted list on the server-side that would feed back directly to the Ajax request and then post to the view.  This is a much more optimized solution especially when I grow out the list of database location names so I only pass a small amount of data vs. everything.

I actually started getting obsessed with Ajax to the point where I wanted to load everything on one page. This is a bit complex and unfortunately, I hit a couple of walls that were too difficult to get past in time for the SheCodes conference. So in the interest of time, I ended up rolling back my one page concept to loading separate views for each request. Basically its a full page load based on most of the links that are pushed. It’s not as elegant or efficient but it works. I also get that I have to try lots of things and sometimes go back to square one before making progress. Its part of the learning process.

Sunrise & Sunset Data:
I pulled out the Forecast.io API because I have known for a while I wanted to focus on WeatherUnder Ground results. In so doing, I managed to lose my data points on sunrise and sunset which I used to help determine whether to show a sun or moon image for the results. Now it seems the easiest thing would be to leave the use of the Forecast.io API, but I wanted to pull it out. I thought it would be easy data to find. However, not as easy as I would expect.

I tried the PyEphem package to calculate the times based on given coordinates. The results unfortunately were not accurate; thus, I switched gears to apply the Earthtools API. In so doing, I had to learn how to parse XML data which is good to learn, but it just was one of those moments of, “there has got to be an easier way to do this.” And fyi, Json is definitely easier to manage.

I applied the BeautifulSoup package to help parse XML. There are many parsers out there. I just picked BeautifulSoup because I was familiar with the name. Still this proved tricky to do and it took some time to realize that the XML response was an object and it needed to be converted to a string in order for BeautifulSoup to process it.  Note, I use the requests HTTP library vs. urllib2 to pull API data. So when I run request.get on the earthtools url, I get back a response object. In order to get to the XML content, I actually have to pass the content attribute on the response object instance. So if I assign what earthtools sends back to a variable name earth_response then I have to pass that variable into the  BeautifulSoup object as BeautifulSoup(earth_response.content) to get it to parse the response.

Map:
I added the Bootstrap modal plugin (after unsuccessfully loading the pop-up plugin) to show a Google map when the map icon is clicked. I have further plans for this feature mentioned below.  What I was able to accomplish for now is that I’ve added the HTML5 Geolocation API to pull the coordinates from the client’s browser. These coordinates are used to build the initial map which can be seen when clicking the map icon. It was easy to setup and cool to see in action.

Other:
Some additional changes that I made were to stop passing all content to all pages now that I have a better handle on the view setup and what data I needed where. I also started to update the user login information based on what I learned from Flask Mega, but I tabled the further adjustments till after the conference. I fixed view content, improved page and variable names for clarity and added Coverage.py in anticipation of applying tests.

There were a number of changes that I made and what was funny is that despite all that work, the front-end view actually hasn’t changed that much.

SheCodes

Presenting the app at SheCodes was good practice in technical demonstrations, and in general, I really enjoyed the conference with the type of speakers and content covered. I created a couple slides that diagram the high-level MVC (model view controller) setup for my application and the difference technologies and resources that I’ve used so far. Those slides can be found on Speakerdeck.  And if you want to see visual samples of the site, they can be found at nyghtowl.github.io.

I am pseudo proud of it again. I say pseudo because I will always have things I want to improve and it will never be perfect but apparently that is fairly standard with coding. My appreciation for the web app is in the fact that it has shown me how far I’ve come and gives me a space to continue to experiment and grow.

What I haven’t Finished Yet

So I am going to avoid the elephant in the room for a minute and explore it below. In terms of things I want to do, I want to  pull out the current object that organizes the weather data and instead use Ajax and JavaScript to obtain the weather information and pass it directly to the results page. I also want to finish the user login and preference pages to help customize user experience. Additionally, I plan to make the map more interactive from having links that can direct users to results as well as caching and showing weather data points for immediate view. Last as usual but not least is to add tests that will help keep track of my application and give more information on what is breaking and when.

Deployment is the Devil

So deployment is hard and I kinda hate it. I actually am still working on that as we speak because my deployment involves S3 and there is something special you have to do with static assets that Flask Mega didn’t cover. Lets just say that Rails is so much easier for this and I’ve heard the same about Django. Plus, my previous deployments didn’t require the kind of configuration I’m dealing with. My app is such a simple solution that it makes me laugh at the complexity of what I have to do to get it to work. Still I will deploy. Its going to happen come hell or high water, and I will post up what I learned from that experience once I get there.

Advertisements

Sun Finder – Where is it now?

For those following along, I have made very little progress on my Sun Finder application since Career Day about a month ago. Since hindsight is 20/20, I probably could have seen this coming, but I was living in a blissful imaginary world that said: “There will be all this time after I graduate to do all these things”. The reality is that all that time was about to be commandeered by interviews, practice & studying for interview and a bunch of life stuff that you can never plan for.

I do plan to get back to Sun Finder, and I’ve already started the process to get it online for friends who tell me they keep finding themselves in situations where they want to use it. I hit a bit of a snag while going through the posting process, and there are some errors that I need to work through. As soon as that’s done, I’ll share the location.

Now don’t get me wrong, there is still so much to build out and fix on it, and if you look at my code on GitHub you can see a running list of my top items.  Still I want to get something live so I’ve gone through the process and know how to do it. I’m a big believer in putting a stake in the ground and getting something out for consumption. It will never be perfect and others can call out issues for you that you can’t see from being so close to it. Plus being a newbie to this field, I can definitely use guidance from others who have more expertise on more optimal ways to build the app’s functionality.

For the curious, here are screenshots to show you want it looks like: nyghtowl.github.io.

Also, I posted a README file on the GitHub project site to give an overview.

As always more to come.

Week 10 – Graduation!

In the true spirit of graduation, I am posting this late and after the fact. I can’t believe 10 weeks have come and gone. I know I’m also not fully feeling it yet since most of us have transitioned into the post graduation job search.

May 10th on week 10 was our official graduation day. Although, it felt like we started celebrating graduation after Career Day, and didn’t let up until that weekend. Right after Career Day, most of us went out to let our hair down and celebrate a pretty amazing accomplishment.

I’m not 100% sure where the next 3 days went since I know I went to school, but the tone and focus had completely shifted. People were not as heads down on projects, but there was still a lot of activity. We were definitely spending time connecting more with each other since some were not coming back the following week.  Many of us were working on interview questions, resumes, posting projects on Heroku and follow-ups with companies. Some people even started interviewing with companies as early as Thurs.

There was a Girl Geek dinner held for Hackbright at the Google San Francisco office on Thurs. night where we presented some of our projects, talked about the Hackbright experience and even walked across the stage to proclaim our accomplishment. Then Friday all bets were off. We got almost everyone into school by noon (just barely) where we presented the instructors with gifts, and we were given our hoodies and something that is much better than a diploma. (I am deliberately leaving that off.)

Afterwards it was just a free-for-all of fun, movies, forts, games, geeking out and spending time together while we still had time. Slowly people started to leave as the it got later in the day, but a core of the group hung in and stayed the night. The next day Cynthia hosted a BBQ at her place to help cap off the full graduation experience.

It went fast and although I’m thrilled to have come so far, I’m sad its “officially” complete. This group of women and the instructors have meant the world to me. I am already missing them even though thankfully I still see several of them right now at school while we are preparing for interviews. It has been a wonderful experience that I would never expect to duplicate, but I do hope to find ways to add to the experience for those that come afterwards.

HB Quick Tips

Below are some quick tips for those considering something like Hackbright Academy. If you have time before or want to get some preliminary building blocks, check out the links and pointers below.

  1. Keyboard Shortcuts:
  • Learn keyboard short cuts (before starting any programming bootcamp)
  • If you are not used to it, it does suck royally to learn
  • Push through it and practice, practice, practice!
  • The less you use the mouse, the more credible you are as a developer
  1. Ask for Help Early and Often:
  • Leverage your classmates
  • Leverage google, stackoverflowreddit, etc…
  • Leverage your network and online social tools
  1. Start Reviewing:
  1. Check-out HTML, CSS & JavaScript
  1. Git with Git:
  • Read about git
  • Read about GitHub
  • Want more?…
  • Load git on your home computer
  • Setup a GitHub account
  1. Balance is Key:
  • As Cynthia would say “take breaks!”
  • Make sure to keep up a workout regime – its good for the brain
  • Eat healthy to keep the energy up
  1. Check out Zach Holman’s deck (it’s 5 min)
  1. Additional Resources:

Career Day – Done & Done

As promised, I’m taking a moment to post commentary regarding Career Day. It went fast, was a whirlwind of companies and was a relief when it was done.

How it Worked:

Career Day is when Hackbright partner companies meet with students individually and see our skills on display through our final project. It was literally interview speed dating. Each student had a table and every 7 minutes the companies would rotate between the tables. It was a brief time to get a sense on whether there was enough fit for a further conversation/interview.

The day started with each company taking a couple of minutes to introduce themselves to all the students before the individual discussions started. After meeting with half the students and companies, there was a break for lunch were we were able to mingle and talk longer. Then the second half continued in the afternoon.

The good stuff: 

  • There were 25 companies interested in seeing us
  • After a couple of meetings, I got comfortable quickly sharing my background, interests and app
  • It was a great way to get a feel for the company and see if there may be a fit

The challenges:

  • There were 25 companies we talked to in almost 3 hours
  • Sometimes hard to keep who I was talking to straight
  • Sometimes hard to remember what I coded or how to explain it
  • Sometimes hard to remember my name and how to speak English

Tips – My Approach:

Following is a summary of what I did to prepare for, during and after the day that I took from my previous experiences.

I looked up the websites of all the attending companies (they gave us a list a couple of days before). I kept a list on of the companies and put brief notes about the product and questions that I might have. Also, I looked at open positions to see what they were currently hiring for so I’d have an understanding of what roles they may be looking to fill. If I didn’t see a role listed, I noted a question for them to find out what they were hiring for.

During Career Day, it took the first couple interviews to get comfortable with how fast 7 minutes went and sort out story points I wanted to hit. So by the 3rd or 4th, I was finally managing the time to usually spend half of it getting the company to tell me about themselves (culture, roles available, timing, etc.). Sometimes its easy to forget that you are interviewing the company for fit as well. When there were brief breaks between meetings, I updated my notes with take-aways from the company as well as tagged the ones I wanted to send a follow-up email.

There were a couple different perspectives/recommendations on when to send emails from our mentors and instructors. Some said to send immediately and others recommended to wait. Career Day was exhausting and its understandable that its hard to have the focus to follow-up (esp. when you have limited experience with writing those emails).

The business world is all about follow-up, and I went with what I know. I sent emails to the ones I liked that night and the next day. I also made a point to thank ones that didn’t seem a fit but that I enjoyed talking to.  My notes were fairly short with appreciation and asking for next steps. I added commentary if there was something specific I remembered from the conversation and/or something specific I wanted to thank the person for.

For example, Google came and I gave them a pointer on how they can improve maps to help with the label challenge I was having (see earlier posts). It was said with good humor, and it was a more funny and fun discussion. I followed up in my email with a heartfelt thanks for being a good sport about the feedback and how much I did like the company.

Additional Thoughts:

There were some companies there (not naming names) that I honestly had no interest in. I didn’t think they would be a good culture fit and after talking with the representatives, my opinion was completely changed. So it was a great reminder in being open and challenging assumptions.

Week 9 – Crunch Time

It is hard to stop long enough to write this. Sometimes this past week I was too excited to work on my project to sleep. Still I know this is valuable for my sanity to think through what I’ve done so far and appreciate how far I’ve come. Plus, my brain functions better when I take breaks from coding.

Looking at my post from even a week ago surprises me because it feels like longer than 2 weeks since I was figuring out how to use web APIs for example.  At the time it made me feel very lost and the concept seemed extremely foreign. Now whenever I see there’s an API that can be used, it feels like it’s the easiest thing to implement and leverage.

So this week definitely went fast and continued to remind me about “best laid plans”.  I had a couple of key functionality goals like trying to get clickable text on my map. Which I worked off and on all week to get that functionality, and I’m still just cracking the edges of that nut. Still there are cracks so I know it’s a matter of time. Anyway, where I am going with this paragraph is that I had some goals and I chipped at them. When they got too hard or there was a barrier, I shifted focus and tried something else for while before going back. Some things were much easier wins that I went for to feel some level of success, and others I let myself accept were items I can deprioritized for later based on complexity.

Last Sunday, there was a lot of other life stuff going on so there wasn’t a lot of coding. It was a good break. I did take time to define a larger local database of neighborhood data, and I found lots of variations on how San Francisco neighborhoods are defined. There are a lot of opinions in this town.

On Monday, I decided to take a crack at setting up login and create account functionality using Flask Login and WTF (for WTForms integration – not for what some of you are thinking but at times feels applicable). I had heard a number of classmates talking about using these  extensions, and I wanted to practice applying the packages while I had my cohort’s expertise to leverage. At some point, I plan to add functionality where there will be customizable views for logged-in users (e.g. choose the key locations you want to know the weather on like where you live and work). We had a lot of speakers that day so there wasn’t a lot of coding time.

Tuesday, I built out the login and create account pages so they were loading. The code I wrote was pulled from tutorials and code that my classmates had written to implement login into their apps (thanks Marissa & Jennyfer). At Hackbright, we talk a lot about reuse and not reinventing the wheel in programming if you don’t have to (unless you are trying to understand the fundamentals or you want to create your own thing) .

Also, I re-ran the database model setup to seed it with the revised neighborhood dataset from Sunday, and to build out a table to hold user account data. Furthermore, shifted my database management system from SQLite to Postgres. I wanted to practice Postgres (again while I can leverage the collective knowledge of classmates – thanks Lindsay & Dee), and its what you need to use if you deploy to Heroku.

Wednesday, I spent a good chunk of time really trying to understand the login code to see how I could adjust it as well as test it. For example, there are WTF default validators you can use or customize for form submission validation. So you can apply and throw standard errors if a user enters their password incorrectly and customize the errors and say “random error just to annoy you”.

One thing I figured out when reviewing the login and create account code was how to take the repetitive display code, and simplify it to a for-loop. It was satisfying to make it more compact. Lindsay thankfully helped me fix this one issue I was having with the consolidation because there was a second/embedded for-loop to generate the WTF errors. I was having a hard time figuring out the right object reference name to use, but Lindsay was able to identify it with a little testing.

Thursday was a much needed code clean up day. I adjusted file and variable names to take out duplication and make it easier to understand the structure. I shifted code into files that made sense like pulling straight functions out of my views file and into a functions file. I went back and added more comments when I found myself reading code and not remembering what it was for. I also continued to tweak the app design and finally finished small gaps in results like having the neighborhood name populate in the title of the results page.

With the help of my instructors, I also started to restructure the code in preparation for adding an Ajax spinner while the page loads. It involves creating a shell page that shows the spinner until the page with the content has finished loading. This is valuable considering I have several web API calls that can take time to pull the data into the results page. I’ve got a couple more items to look up to finish this functionality.

One of my more satisfying moments was at the end of the day. I tackled including autocomplete (when typing in the search bar it will give suggestions) into my code. I wanted to use my local neighborhood database to fill in autocomplete vs. some of the plug-ins that are out there. After a couple of hours of trial and error, I was able to pull my database results into an object variable with SQLAlchemy and Python and then pass that variable with Flask views to the rendered HTML page where Jinja was able to reference the object variable inside of the script tags.

I ran a Jinja for-loop over the object to generate a list of the neighborhood names and assigned it to a JavaScript variable. That was then referenced in my JS file and utilized by the jQuery code to generate autocomplete in the search bar (also referencing the jQuery code in HTML to activate it). Basically there was a couple different languages I was writing in, lots of data passing between them and referencing of different files. And when it all came down to it, it worked. It was so cool when it worked. It made me feel like I was starting to get the hang of this programming stuff.

As mentioned above, throughout the week I took some time to work on setting up maps with text. I researched examples that were already implemented and tried incorporating the code. On Friday, I went in with the intention of getting text on the page. As usual, I got sidetracked. While trying again to apply the JS Mark With Label library, I found that this error I was having since I setup maps was getting in the way.

Maps loaded when the app initialized, but it was always looking for coordinates which weren’t generated until at least one search ran. So on the first page when no searches had taken place, it would throw an error. I could have just passed it some static coordinates but I wanted to stop it from trying to load. I had put that as a low priority fix since it wasn’t preventing any page loads or the map to load when a search did take place. However, I found that I needed to understand how to fix that error in order to make any additional JavaScript/jQuery progress.

Thankfully Alex, one of the cofounders of Codepen, was on site yesterday and just helping all of us with our projects. He helped continue to further my understanding of JavaScript/jQuery and to resolve the loading error. After that and on my own, I was able to get Mark With Label to work. So there is a label now showing up on the map. Next steps are to revise it and make more than one label for the different neighborhoods and then to make it clickable. The rest of the day I spent time on some easy wins (e.g. adjusting look and feel and applying Bootstap’s JS modal plugin for the login) to offset all the time spent around just getting a label to show.

There is so much still I want to do and I can’t believe its one more week officially left in the program. This next week there won’t be much time for coding because of Career Day, prepping for interviews and general hanging out with the class and soaking in the time we have left together. I still can’t believe its May.

If you read this far, I’m impressed. My last couple posts have really been for me to keep track of progress and status. They have not been as laymen friendly or geared towards mass consumption. Next week, I plan to post more around what Career Day was like and less about project status.

If you are reading this and thinking about getting into programming and have any questions about getting started or wanting more clarity about comments above, feel free to email me. If I don’t know the answer, I know how to find it and/or I know a lot of people who do.

 

Week 8 – Time Goes Fast When You’re Having Fun (Project Status)

To anyone out there who’s watching, I wrapped up week 8 and I’m thinking about how I want to leverage my time in week 9 in preparation for Career Day. I do talk a lot about that as the D day, and it is to some extent. It’s a goal to help keep focus in terms of how I want to prioritize my time. A second goal is that I only have technically 2 weeks left in the program and there are certain subjects I want to practice while I have class time. Sometimes those goals match in purpose and sometimes I have to just pick based on how I’m feeling that day.

So this past week went fast and I found myself eager to get to coding, but also surprised at all the other “stuff” that kept me from touching code at times.

Last Sunday, I spent the day reading up on the Google Places API with the intent to resolve my search functionality requirements. It definitely expanded search capabilities in terms of what can be entered, and I was able to center the search results with coordinates and a radius around the Bay Area. Thus, typing in golden gate more likely came up as the park vs. showing up in another location like LA or somewhere in China. I also concatenated the word “neighborhood” on any search to help further influence the results. There is a lot more I can do here but this is good enough for now.

Monday I decided to leverage the results from both Weather Underground(WUI) and Forecast.io because they had different data points I wanted to report out. I put together a dictionary of the results that mapped to the data points from the different sources to help keep me clear on what I would use. To note, the temperatures between the two at times varied wildly based on given coordinates. Supposedly WUI is more precise based on all the local inputs they are leveraging but it would be interesting to see how accurate they are based on location and time. Again something to think about down the road.

I also started to work on developing the More Details page on Monday and that hit a bit of a snag on Tuesday because I was trying to figure out how to pass the forecast dictionary to the new page. The approach recommendation I received was to pass it in as a Flask session variable. The problem was that the code I put together for the session was spot on, and after checking it several times myself and with others (esp. instructors – huge thanks to Cynthia on that one), we were flummoxed.

I decided to set that aside for the moment, and start to look more at the front-end of the app. Sometimes its important to step away and get a refreshed perspective to help solve problem. So I spent Tuesday and a good deal of Wednesday understanding Bootstrap and CSS. I’ve always wanted to keep my design simple without a lot of distraction. The goal of the app is a simple question that needs a fast and simple answer. Still I found a lot of adjustments to make to the layout and format that made the pages look and feel cleaner. It was a fun activity to do and the right distraction from the session kerfuffle.

Late in the day on Tuesday, my mentor, Michelle, helped me identify and start work on an alternative for the more details page to bypass the need to use session. Interestingly enough the alternative was what I had wanted to do with the page in the first place. The way it worked was that on the first results page there is a link to click and expand the page with more details. We used Bootstap’s accordion functionality to make this happen. The reason it bypassed the need for using session was that the dictionary had already been passed directly to the main results page when it was created and the more details expansion took place now on the main results page. So there wasn’t a new page being generated.

Wednesday I figured out how to apply a calendar on the search page with jQuery, and continued building the more details results expansion.  I also figured out how to add a Google map onto the more details section which helped make the page really feel like it was coming together.  By the end of the day, session started working even though I didn’t need it at that point. No one knows why (the thought is that it’s probably a cache problem), but it works.

Thursday I spent time optimizing my code and changing the forecast dictionary into an object which helped me practice my understanding on classes and OOP. I also spent a good amount of time testing code and fixing functionality. At the end of the day, I needed something a little more fun; thus, I expanded the results to include night. I had been ignoring it purposefully before since it is a sun finder app. Before I was just popping up a message at night to tell people to go to sleep. So I added in images of different phases of the moon and the moonphase package to help generate the phase and subsequent picture to pop up on the results page.

Friday was more code clean-up and testing. I started to hook up the calendar to the backend functionality and I shifted the date results from timestamp format to datetime format. For anyone who works with dates and times, just be aware that datetime is tricky and can take a little time to understand. I also started working with timepicker to include choosing an hour in the search process, but decided to shelve it for now. There are other features and functions that are more of a priority for now. Also, I still need to finish building out how the results will populate if a date is picked that is not the current day. As I mentioned last week, every time I do something it brings up a number other questions and things to do. It continues to be great practice in finding and keeping focus.

Saturday (yes I worked on this thing every day this past week), I spent the whole afternoon with my awesome mentor, Jeremy, who helped me debug the moon functionality that I added. He also gave me great pointers on keyboard shortcuts and how to utilize pdb when looking at the results from the weather APIs. This allowed me to work with results directly in the terminal and will make it easier to search for the data points that I will want to target in my results page based on the date chosen. We started working on building the functionality for setting up the map to have names of neighborhoods and make it clickable. While working on that we stumbled on the weather overlay on Google Maps which was cool but on further inspection, I realized it just wasn’t detailed enough to use for my purposes.

At the end of the day, he shared a great video, JavaScript: The Good Parts by Doug Crockford. We went through some of the video together and he took time to coach me through the concepts which helped speed up my understanding of the subject. It was definitely very helpful as I work on getting more comfortable with JavaScript.

Something to stress that I mentioned a few times above is that throughout the week I was constantly testing my pages to make sure they were working, and that the results were what I expected. Any time I made changes, I would go back to test to see the impact. So a good percentage of my time was spent in just testing. It’s good practice to have because as you develop, something doesn’t always work the way you expect, and it can be a small error. It’s harder to debug if you’ve been making several changes, and you get an error that is not easy to track down despite all the error reports.

This past week was definitely full and there is plenty still that I want to do. I understand it won’t all get done and I’m ok with that. I’m pretty happy with where the app is at already. Michelle had me show it to some of the alumni this past Thursday night, and I got some great feedback on it. SO I plan to this next week to really try out functionality I want to learn and get practice with. Its going fast and I know this next week will not be any different.