Crash Course Python

Last week I was sent a code challenge that had to be completed using SQL and Python. It involved a SQL query, a test in Python to see if an IP address was valid, and a query to an external API using Python. All of that is pretty standard, except I had never used Python before. I was excited about this challenge because Python is a language that I have really wanted to learn for a while, and the challenge was sent with the full awareness of my lack of Python knowledge and they wanted to test my resourcefulness. That’s exactly the kind of challenge I love.

Between finding out what the challenge would involve and beginning it, I sped through Code School’s first Python tutorial and grasped the basics of syntax(i.e. whitespace), lists, and dictionaries. I was relieved by how quickly I was able to pick it up. Python is so fundamentally similar to Ruby; it’s the syntax (mainly the use of whitespace/indentation to mark the end of a loop or function) that feels like the major difference (at least so far). While I have strong feelings about maintaining clear indentation in my Ruby code, I still feel like denoting the end of a loop or function with ‘end’ is much more clear.

That said, it is already clear to me how much better Python is for working with data. The Counter library (and the fact that the challenge itself allowed me to import that library) made sorting the output of my API query  (which was a requirement) so much easier. More than once I found that I was able to import a library for handling data that saved me several loops of my own, and I was able to use them immediately.

It took me more time to complete this challenge in Python than it would have in Ruby because I kept having to Google things that I was second-guessing myself on, but it forced me to get further in less than a day in Python than I had in a week of Ruby, which was my first language.

Bootstrap Baggage

Lately I’ve been working on a purely front end project to brush up on my front end skills, which I haven’t spent as much time on since the beginning of my Flatiron School program. I felt like Bootstrap was a framework that I needed to get more comfortable with, so I began with a bootstrap cover template. Because I’m practicing the execution of an image file of a design, I am trying to customize every last detail of this template to match it. For anyone who has worked with bootstrap, you can probably guess where this is going. My very practical program warned me, but I wanted to find out for myself.

Customizing bootstrap components requires a combination of detective work to find out where the css code for the relevant attribute for that component is being held prisoner, and, when in doubt, figuring out how to override that code, wherever it is. I’ve already used the “!important” tag more times than I’m proud of. Being as specific with css selectors as possible in order to control the component is something that Flatiron taught me well, but it is not that I thought I would ever need as much as I have on this project. At times this takeover has felt a little hostile.

Another aspect of Bootstrap that Flatiron warned me about, but which didn’t really click for me until this project, is just how much unnecessary code comes with a basic Bootstrap template. I saw for myself, as I was scrolling through the bootstrap.css file, that the reason bootstrap can make all these components as if by magic, is that it is like a Mary Poppins bag for code. It has everything you need, and lots of things you don’t, but you can’t see that from outside that file. This makes Bootstrap ridiculously “heavy” as far as size goes. I am seriously considering an experiment in which I delete the code from that file, selector by selector, and just see how much I can get rid of before the page breaks. The amount of new css I’ve written at this point to customize attributes, probably makes a lot of the out of the box css redundant anyway.

Gaga’s Drones

gaga

Lady Gaga just delivered an amazing halftime performance at the Super Bowl, despite not bringing Beyonce out to do Telephone with her. One of many noteworthy moments in the show was in the beginning when 300 drones  flew in formation behind her, like static fireworks. These drones were made by Intel and are piloted by a suite of desktop computer programs. The implications for the potential role of drones in big stadium performances like this are exciting, and Disney has started using them for performances in their theme parks.

super-bowl-li-flag

This is one of the first times I’ve noticed it being used in a live performance, but programming has been finding its way into the music world for years. I found my way into The Flatiron School in part because of a webinar they were offering on using Sonic Pi, which allows programmers to program songs. Even in Googling the website for Sonic Pi for this post, I was inundated by apps that allow users to make music on a computer, without ever touching a musical instrument. And need I mention autotune?

The computers are even making their way onto the stage now. We’ve all seen a laptop being set up on a stand during a band’s live performance now, with someone in charge of “playing” it during the show. I even saw a laptop onstage at a (really good) Peaches concert in September and I’m pretty sure I saw her reach over to start a track at one point.

There has never been a better time to be both a music and programming nerd, and some brave souls are even making it onto the stage.

Testing Bcrypt

This week I ran into an issue with a Node servers lab that had an encrypted component. The way the lab had originally been set up, the encryption used the Node crypto module, which it then decrypted in the test suite to confirm that the result matched the input. However, the lab had then been updated to use the bcrypt module, which I’m very familiar with from Ruby on Rails.

The problem I ran into was that after updating to bcrypt, someone had updated the test suite to include bcrypt methods instead of crypto, but it looks like that had not been merged into the Master. So when I had forked and cloned the Master, I got the updated version of the lab, but not the most up to date version of the test-suite. So even though I was pretty confident that I had set up my bcrypt hash correctly (see below)  the tests weren’t passing.

let data = JSON.stringify(messages);

bcrypt.hash(data, 10, (error, hashed) => {
     response.end(hashed);
});

Because I did not yet realize there was a version I could copy from github, I googled how to test a bcrypt hash and found a bunch of snarky responses saying you can’t. Which isn’t exactly true. After some investigating on the github repository and a little customization on my part I ended up with the following test (within a larger request), which worked like a charm:

bcrypt.compare(
     ‘[{“id”:1,”message”:”This is a test message.”}],
     response.text,
(error, response) => {
          response.should.eql(true);
          done();
}
);

Behold, the magic of the compare method.

The Women’s March

This weekend I attended The Women’s March in New York City. I thought about trying to write a more technical post, and I could, as I am delving further into Node and rediscovering bootstrap. However, the march has occupied my mind and my newsfeeds all week. And here’s why I feel it belongs on my programming blog:

  1. The belief that women should have the same rights and opportunities as our male counterparts should not be a political issue at this point, but a commonly accepted truth.
  2. Programming is a field that is still predominantly occupied by men, and one in which women are frequently still paid and promoted less than their male counterparts.
  3. This field exists in no small part due to the pioneering work of female programmers, many of whom have been women of color, and that fact is only recently starting to become well-known.

So, a little tribute to a few of our programming foremothers.

Now everybody go see and read Hidden Figures.

Hello Node

I’ve also recently started learning Node.js. In many ways, it’s been easy because it is at heart JavaScript, and it’s something that I’m very comfortable with. What’s new is that Node event-oriented, whereas all my JavaScript training and experience up to this point has been object-oriented.

This is server-side JavaScript. And in the quest to build projects that run as quickly as possible, Node is incredibly competitive because it allows for asynchronous, non-blocking code. Which means that it is much better at multi-tasking than I am.

I have already noticed a huge improvement in the speed with which testing and programs are run on the command line. When testing my Ruby and vanilla JavaScript projects, sometimes it takes a few minutes to get results, to the point where I have to increase the timeout limit. It doesn’t help things that I have a 2012 MacBook Pro, which feels more and more like a dinosaur every day. So I’m used to running a test and then getting up to get a drink of water or walk around because I know it’s going to be a little while. Last night I entered npm test into the command line and the test was done before I had even gotten out of my chair.

 

Design

I recently tried to explain to a friend why I felt like I struggle to add design to my own apps. It’s not that I can’t draw, and it’s not that I’m not creative — I’ve been an improviser and comedy writer for years. I understand design principles and I have the front end skills I need to carry them out. However, when I try to add design to my own apps, I feel like I spend a long time working without ever actually making a design that looks polished and professional.

ep00vsf12bbfq

Then something very very obvious finally dawned on me. I’m coming up with and keeping my design ideas in my head, while trying to code. Those are very different parts of my mind, and by trying to use both at the same time, they are getting in each other’s way. I need to separate these steps and sketch out an actual design so that I can focus on the creative side, and then try to execute it. In other words, combining these processes is actually less efficient.

img_0316

Admittedly, I was also looking for an excuse to buy new writing and drawing supplies…

Getting into PHP

After beginning my job search, I noticed that a lot of open jobs that I was interested in required experience with PHP, which isn’t something I had used before this week. I decided that I wanted to get familiar with it, so I dove in and completed CodeSchool’s tutorials on “Try PHP”.

I was surprised at how easily I picked it up. Its syntax reminds me of AngularJS, but with brackets around each section that reminded me a lot of embedded Ruby (ERB). In fact, PHP, Ruby, and JavaScript were created within a year of each other. PHP stands for “Personal Home Page” and it has existed since 1994. It was originally  designed to be similar to Perl and C, with the purpose of adding advanced functionality to simple home and navigation pages. (actual facts courtesy of php.net/manual/en/history.php.php)

 

 

Angular App with Rails Backend

This project has been a little intimidating, because, once again, while I know how to make a Rails app and I know how to make an AngularJS app, I have had to do a lot of Googling to figure out how to combine the two. And the ratio of Rails to Angular seems to vary a great deal in each tutorial.

One thing I learned is that you can generate two different apps in the same directory and have them pretty much combine themselves, which surprised me. I definitely had to delete folders and move files around to transfer what I had done so far in Angular into the Rails asset pipeline. As a result, a lot of my github commits were moving and renaming files, mainly templates, so that I could access them.

Because this was a single page app that needed to have five views, there were a lot of challenges and limitations to setting that up. It turns out that I can’t do a traditional nested state when I am displaying templates as views in one state. Because of the structure I chose in app.js, in order to get my nested templates to display within my main views, I had to use a combination of directives and ng-include.

I also found too many problems in trying to set my user/current_user element using resolve in the app.js file, which I wanted to. The promises generated by the $http requests in services didn’t want to pass themselves into the resolve. As a result, I have to call my controllers’ load functions automatically in the controllers.

I also have to make use of a lot of ng-if statements so that views don’t display until after login, which created some controller scope challenges. In the end, like most challenges in this project, I found the solution to be elegant enough — adding the user controller to the home template and letting the user and sessions templates access it inside — but the process of finding the solution was so messy.

At one point I got so frustrated that I tweeted that hooking a Rails back-end to an Angular front-end felt like hooking an elephant up to a butterfly. Based on the end result, I see the benefits of using Angular. It is light and elegant where Rails would be heavy and clunky. You can make your changes without refreshing and see the results dynamically. However, based on the production process, I really see the benefits of working with a Ruby on Rails end to end framework, mainly because Angular is just so easy to break. One comma in the wrong place in the app.js file, and nothing works.