Tag Archives: Python

Deployment is not the Devil (Flask & Heroku Tips)

On a previous post I claimed deployment is the devil because after several successful (not always easy) deployments, pushing up my Sun Finder app proved elusive. I seriously wanted to scratch my eyes out at times with all the errors and issues. Still it was a good learning experience (one that I fought against but a good one all the same), and I did finally deploy as of last week! Check it out at sunfinder.io.

So deployment isn’t all bad but it sure can be frustrating if there is a ton more work that is needed to deploy after the long haul of web app development.

To help others new to deployment and especially working with Flask, here are some things I learned along the way.

First off, if you are working with Flask then use this help page as a starting point on how to develop and setup apps on Heroku.  On the left side of the page, there are links that provide similar support for other frameworks. Just make sure to setup a repository to store your project and configure remote access.

1. Local Database

The biggest deployment challenge I had was importing a pre-populated database from my personal computer (local).

Overview
Heroku provides a Postgres add-on from Heroku Postgres which adds a remote database onto the application. When a remote database is provisioned, a config variable is assigned to the repository which usually includes a color in the name. This variable is a reference to the URL where the empty database is accessible.

DB Remote Storage Option
In order to load a pre-populated database, it has to be stored remotely in a service provider like AWS S3 (Amazon Web Services Simple Storage Service) or Dropbox and then imported to Heroku. S3 is a popular storage solution because its been around for a while and is known for its optimization. I haven’t looked into Dropbox as a solution, but I suspect its a good option as well.

High-level directions on how to setup S3 for Heroku are provided at this help page. AWS also provides pretty extensive usage directions.

IAM: User & Permission Setup
After signing onto AWS, go to the IAM section under Deployment & Management section. In this area, setup a user and obtain security credentials. Make sure to capture the credentials  (Access Key ID and Secret Access Key) for later reference. Then setup a group and assign access permissions. Go for the admin permissions setup if its just one person. Once the group is created, click on it and look below the tab section for the option to add a user. Make sure to add the user to the group.

S3: Bucket Setup
From IAM, return to the main section by just clicking on the box in the top left corner and choose S3 under Storage & Content Delivery section. In this area, create a bucket (aka root folder) to store the database. Make sure to create the bucket in the region where the app is stored which for Heroku is the US Standard region. This is important because S3 is free for in region data transfer rates. Also, make sure the group is granted access permission to this bucket. At this point the database can be uploaded.

DB: Compression,  Upload & Configuration
In order to upload a database, compress the local copy first which is also referred to as dumping. Heroku’s directions on how to create a compressed version of the file can be found at this page.  Create the dump file and open the AWS bucket in order to access the upload option. Once the file is uploaded, add the AWS security credentials into Heroku configuration following the directions on the Heroku S3 help page.

DB: Import
I followed the import directions on Heroku’s help page that explained compression but there were a number of errors (like “invalid dump format: /tmp/…/sunfinder.dump: XML  document text”). In order to resolve these problems, I logged into the Heroku Postgres site.  It showed all of my Postgres provisioned databases and when I clicked on one of the databases, I was able to see connection settings and statistics. There is an icon of two arrows pointing in opposite directions in the top, right corner that provides a list of additional options. There I clicked on PG Restore and found more explicit command directions for import. The only part of the command that needed to be changed is to swap “your data file” with the dump file name that is inside the bucket. This resolved my errors and enabled database setup.

Just remember that any changes made to the local database need to be compressed, uploaded onto AWS again and imported in order for it to be seen in the remote application.

2. Static Content

When I first read the Heroku S3 help page, I mistakenly thought I had to store all of my static content on S3 (e.g. img, js, css). Granted previous deployments seemed to work and not require this, but I couldn’t get the css and js files to load correctly on my application.  I was getting a 403 error with a link to an XML page that said “Access Denied”. 

So I loaded all the static content on AWS S3 and made it public. This actually made the application work once I changed the static file references to the new AWS location and links. Then I finally figured out that the Heroku application key configuration was incorrect and thus, the problem. So I rolled back my changes to keep the static reference links internal vs. pointing at AWS.

Using AWS to store and reference static files is more useful in situations where there is a significant amount of content and/or users are loading content onto the application. There is a lot of literature out there that provides more details.

3. Heroku Configuration & Updates

In the process of setting up the Heroku repository, don’t forget configuration. It can make things go wonky like 403 errors if its wrong. In the errors around static page loads, my configuration of the Flask app secret key was incorrect on Heroku. Definitely read this link and make sure to load all the secret keys that are needed.

Additionally, make sure to git add and commit changes in order to push updates to Heroku. If a change doesn’t show on the remote site, it’s possible that it wasn’t committed before the Heroku push.

4. Not All Browsers are the Same

Another error/warning I found was in the he Chrome browser’s Inspect EIement console: “The page at … displayed insecure content for ….”. The dots represent a link that the warning referenced. My current hypothesis is this is because I loaded HTTPS Everywhere on my computer and some of the links in my site point to sites that do not use secure socket layer protection. Its just not an option at some sites. This is just a warning and does not prevent my application from functioning. If I learn more, I will update this post.

One thing that I was reminded of while troubleshooting my app is that not all browsers function the same way. So I opened my app in a different browser to check if some errors and warnings would go away. Its just one more way to test the application and help narrow down the problems. Granted there are many browsers and versions of browsers that can impact functionality and plenty of materials on how to develop for all those variations.

5. When All Else Fails – Reboot

Initially I made the first Sun Finder deployment attempt in June. When I returned to deployment in Aug., I tried working with the already established Heroku repository and configuration. At some point in my error tackling, I realized its better to just reset and restart. So I deleted the Heroku repository and created a new one. This didn’t resolve all my errors, but it did help clear out some of the more mysterious ones (e.g. the ones unknowingly created during the learning process).

For those out there working on Heroku deployment, I still stick by a previous post comment that Rails is an easy experience, but it is very doable to achieve deployment with other frameworks. If anything it can be a little more educational at times. Just don’t let the challenges keep you from that final hill to launch.

Advertisements

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.

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.

 

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

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.

Room Full of Brilliant Women

My favorite part about Hackbright so far has been that I am working with such smart and driven women who are constantly geeking out on technology. It also adds to the challenge of the experience. We had two alumni visiting today that spoke about how they were amazed by their class but also intimidated whether they were good enough to be part of the program.

I come from a background of many years in the consulting industry where confidence is key. Many times you are thrown into a situation where you have to solve ambiguous problems and pretend like you know what you are doing whether you do or you are getting up to speed on the fly. Based on that experience, I know I have a wealth of knowledge and valuable skills as well as I am very capable at applying myself.

So here I thought I would go into this program ready to embrace where I land without qualms. I said to myself, “Self, this time around you aren’t going to worry about being the best in school, just learning what you need to know to do the things you want to do.” Who am I kidding. I have always and will always be my own worst enemy. And I have found myself in awe of the women in my cohort which has at times left me questioning whether I really belong.

I think what is behind the fear is that many of us have taken a big life changing risk going into this program. Even though I’m all about taking smart risks, its still scary as hell when there isn’t a concrete plan about what comes next.

What I’ve known but still need to be reminded of is that talking to others helps. Sharing with my classmates, alumni and friends my frustrations and concerns and finding out I’m not alone in my concerns is one of the best ways to keep the little fear demons at bay.

The bottom line is that I am here to learn. The program is specifically setup to take complete newbies and make us programmers. Thankfully the team running Hackbright (esp. Christian) keep reminding us that we are at the level we need to be after just two weeks. We also keep hearing how the classes before us have gone through the same struggles.

When I take stock of where I’ve come from to where I am now, I realize I am currently reading and coding in Python on a daily basis after officially 2 weeks in this program and more like 4 weeks of working on understanding python in general. We are officially developers at this point and there is still another 8 weeks in this program.

Keeping perspective is very valuable to stay strong in such a big change.

.startswith()

Hackbright Class Spring 2013

Hackbright Class Spring 2013

8. Its around the age I was when my father brought home our first PC and I learned how to get around in DOS to play games.  Fun fact is also used to be the number of standard bits in a byte.

So here I am 30 years later enrolled in the Python programming boot camp, Hackbright Academy, learning how to be a developer (or hacker as I’ve been informed).

When I was 18, I was totally into hanging out in the BBs on Prodigy, and I was loving my Pascal programming and Calculus classes in high-school. I was so on the right track to pursue computer science yet I didn’t. There are a lot of reasons on why. Bottom line, over the last 20 years I let my own insecurities and misperceptions about what it takes to really be in the thick of technology, keep me on the fringe.

Don’t get me wrong, I had plenty of other interests I was pursuing and I still worked on technology related projects. Still I always harbored a desire to know more. My father’s recent death made me really take stock of life and revisit this interest as well as challenge my assumptions about myself.

So here I am making a go of it to learn code again. I know that it is definitely not a bad skill to have. With the way things are going in our world. Knowing a programming language is probably giving Spanish a run for its money in valuable skills to have.

This blog is to share parts of this experience for those considering programming or just thinking about taking a risk to do something very different.

Note: For those interested, here is a link to the function .startswith() .