Rashida Reviews Her Week in Girl Develop It’s JavaScript Class

Rashida’s #MotivationalMonday guest post grabbed so many readers’ attention that I’ve invited her to share her coding journey with us on Our Code.  In today’s post, Rashida discusses her first week in the Intro to JavaScript class sponsored by Girl Develop It.  If you haven’t heard of the organization, GDI organizes classes, lectures, online hangouts, and hack nights for women who are learning to code. Click here to find a chapter in your city, and join me on twitter to congratulate Rashida on completing her first week in the class by sharing this post!

*******

As I continue my long journey to becoming a front-end developer, I’ve realized that I can’t escape learning JavaScript. I mean, HTML & CSS are great to know, but you won’t get very far only knowing markup languages if you want to become a true programmer.  From what I’ve observed, becoming an actual front-end programmer means getting down & dirty with JavaScript.

Overcoming Intimidation

My first attempt at learning it was in 2014.  I was enrolled in the Skillcrush Web Designer Career Blueprint.  The last module of the 3 month course was an introduction to JavaScript. Let’s just say I didn’t make it past the first 3 lessons.  I was so intimidated by the syntax that I gave up before I even started.  In the back of my mind, I knew that I’d eventually have to just suck it up and conquer my fear of JavaScript.  I kept thinking to myself that maybe it wouldn’t be so bad.  Every programming language has its difficulties, so trying another would only lead me down a similar frustrating path.

Over a year later, I’m now enrolled in another Intro to JavaScript class, hosted by Girl Develop It Atlanta.  I actually got pretty lucky because a fellow dev-in-training offered me her free voucher since she wouldn’t be able to attend due to being accepted into a coding bootcamp.  Who am I to pass up free learning?!  (Sidenote: thanks again, Mallory!)

Intro to JavaScript Class

This class is a 4-week series on Tuesdays throughout the month of October.  Each class is 2 hours long and there are around 20 ladies total enrolled.  The first class covered a brief history of JavaScript and basic programming concepts such as variables, data types, and functions.

// Think of a variable as storage for a value that you can go back & retrieve later
var firstName = "Rashida";
var lastName = "Thompson";
var age = 29;
var favoriteColor = "pink";

firstName + lastName; // Calling these 2 variables result in "RashidaThompson"

document.write("I want to order a pizza."); // This is an example of a string.  
//Strings are enclosed in quotes.

// Function example
function sayCheese(name) {
    var firstName = "Rashida";
    alert("Say cheese, " + firstName + "!");
}

sayCheese("Rashida");

So far, one concept that I’m having trouble grasping is the return keyword. I understand that using this keyword returns a value and also stops a function, but beyond that, I don’t understand its importance.   As I do more research, I’ll be sure to come back with a better understanding and an example of my own.

What I really like about the class so far is that we learn a concept and then we immediately practice it by writing our own code. No question is a stupid question and the learning environment is very open & relaxed.  Stay tuned for updates over the next 3 weeks!

*******

Rashida is a marketer & mom-to-be transitioning into web development after many years of denying her techie roots. Despite numerous coding hiatuses, she has become the ultimate comeback kid. When she’s not knocking out front-end tuts like a boss, you can often find her on Twitter @rashidathompson.

Advertisements

My Review of Coursera’s Full Stack Web Dev Specialization Course I

In the past, I never been serious about sticking to a particular development stack.  I’ve explored and studied enough to realize what I was good at and what I needed to do to obtain clients and projects, which left me uncommitted.  I can’t say I didn’t try; I as really gunning for LAMP stack and even spent some time learning more about MySQL and Apache this past spring.  I also played around with Django after being encouraged by other python enthusiasts to give it a try.  Still, I kept my options open, and after being given the opportunity to do a couple of freelance projects over the summer building websites for a friend’s charity organization, a local food club community,  and a transportation non-for-profit, I’ve been gravitating more towards front-end development and really diving into JavaScript.

Studying JavaScript led to me taking up a specialization in the MEAN stack.  The MEAN stack is JavaScript based, using MongoDB as the database, Express as the framework, AngularJS as the MVC app environment, and NodeJS to handle the back-end in web and application development.  After 2 weeks of researching learning resources that would best suit my introduction to MEAN, I was able to plan a route that would get me to advanced beginner (perhaps intermediate?) level by January 2016.  In right timing, Coursera had just organized their first set of specializations focusing on front-end web development that were released this fall.

I reviewed the curriculum to make sure I would not be repeating myself as far as learning something I had already learned before.  Specializations offered by London University and Hong Kong University factored in advanced JavaScript functionality and NodeJS which would help me progress.  The difference is London U chose Meteor as their app environment, and HKU chose AngularJS.   Since AngularJS is growing more in popularity, I went with HKU.

Each course in the specialization is around $80 each, for a total around $480 including the capstone project.  What I love about Coursera is they offer scholarships if you can write a great essay about how you intend to use what you learned in the class.  I applied, got a scholarship, and was able to start the specialization at the beginning of September.

Week 1 of Course I: HTML & CSS

I was not excited about going over HTML and CSS in the first week of the course. I have been using those two in my design work and didn’t want to spend the course rehearsing what I’ve already become proficient in.  The course was geared towards advanced learners though, and gave brief overviews instead of going into full detail about specifications.  Professor Rossiter focused on HTML5 forms and we built a dating application form as our first assignment.

My Dating App HTML5 Form

My Dating App HTML5 Form

Week 2 of Course I: JavaScript Intro

The second week focused on JavaScript, giving a brief overview of variables, scope, arrays, and loops.  Prof. Rossiter had us concentrate on functional programming, developing iteration loops through arrays and using methods in the lecture part of the course.  I had previously finished up Toni Alicea’s course on understanding JavaScript’s weird parts with the CodeBuddies crew and worked my way through by John Pollock’s JS book for beginners, so once again I was glad that Rossiter centered on a few main concepts, most of which I was familiar with.

Week 2 Assignment: My Color Guessing Game

For our second assignment, we had to build a user-prompted game that took responses from the user and gave feedback.  I had to submit the assignment as one file, so I included the in the HTML form and assigned the the onload event handler to start the game once the code had been loaded and recognized in the browser.  Here’s the basic page body*:

<html>
<head>
<title> Color Guessing Game </title>
</head>
<body onload = “onload”>
< script >
….javascript goes here….
< / script >
</body>
</html>

After creating the body of the page, I first assigned a set of global variables for the colors in my game, the user’s guess input, and the number of guesses the user would take to answer correctly (initially set to 0).  I also set a global variable to finish the game that I would use in the while loop of the game to keep it from becoming infinite.   My color guessing game used an array named colors to index each color a number:

var colors = ["blue", "cyan", "gold", "gray", "green", "magenta", "orange", "red", "white", "yellow"]; 
var guess_input;
var guesses = 0;
var finished = false;

I then had to create a function do_game( ) that would generate a random number which represented a color that was targeted as the answer, as well as run the while-loop that would continue to ask the user to guess a color from the list (array) until the correct one was chosen.  The while-loop also counted the number of guesses it took the user to create the right answer:

function do_game() {
   var target_index = Math.random() * colors.length;
   var choice = Math.floor(target_index);
   target = colors[choice];

   while(!finished) {
     guess_input = prompt("I am thinking of one of these colors:\n\n" + "blue, cyan, gold, gray, green, magenta, orange, red, white, yellow\n\n" + "What color am I thinking of?");
     guesses += 1;
     finished = check_guess();
   }
 }

The gist of the code that we were being graded on was to create a function that would check the user’s guess correctly.  I created a function check_guess( ) that would run a series of conditional if-statements comparing the target to the user’s guess as the argument parameter.  Because the colors were already indexed in the array, and the target was set to a random number in the do_game( ) function, I was able to compare the two as if they were numbers.  The if-statements were set to false if the guess was incorrect, which would re-run the while loop prompting the user for another guess. The game continued until the user picked the right color illustrated in the else conditional, in which the user would get a congratulatory screen would change the background to that answer:

function check_guess() {
   if (colors.indexOf(guess_input) == -1) {
     alert("Sorry, I don't recognize that color!\n\n" + "Please try again.");
     return false;
   }
   if (guess_input > target) {
     alert("Your color is alphabetically higher!");
     return false;
   }
   if (guess_input < target) {
     alert("Your color is alphabetically lower!");
     return false;
   } else {
     myBody = document.getElementsByTagName("body")[0];
     myBody.style.background = target;
     alert("Congratulations! The color was " + target + "\n\n It took you " + guesses + " guesses.");
     return true;
   }
 }

Week 3 of Course I: Advanced JavaScript

The course ended with a series of lectures on advanced concepts in JavaScript.  Prof. Rossiter concentrated on node relationships in the DOM structure, teaching us more event handlers and showing how the browser registered handlers.  I paid attention to this part of the course the most because I could easily add event handlers to my existing sites, thus I had a practical incentive to watch all the lectures instead of just a few to get by.  For the final assignment, we had to create another game that would focus on click handler responses from the user.  We were graded on how the game board was created and styled in HTML/CSS, the correct use of images generated and displayed via a set of functions, and the JS code that contained the game’s main functionality.  The code is too long for me to list in this blog, but you can view it the code and play the game through my github repo for it here.

My Matching Game Board

My Matching Game Board

Conclusion

In reviewing the first course of the specialization, I probably wouldn’t suggest it for someone who has never written code before.  I realized that the reason why I did so well in the course was because I had some basic knowledge of the JS concepts being taught in the lectures.  I found the pacing of the course too fast, and I spent a lot of time answering other students questions in the discussion board– a clue that most of the class had trouble understanding.  Even with my past experience, I still had someone review my code before I submitted.  Instead, I recommend going through HTML/CSS and the first 3 parts of Codecademy’s JavaScript track first, as this was clearly not a class for beginners.

I was right in my assumptions that the course would be nothing more than a brief overview of web page components targeted to those who just want to learn the minimal amount of JS necessary to understand how AngularJS and Node.js works.  Knowing this now, I will need to supplement what I learn in the specialization with either books or more detailed tutorials, as I can’t rely on the pacing in the next course to be slowed down for my understanding.

I’ll keep you all updated as I go through the specialization.  The next course starts on October 16th, and will focus on UI frameworks, Gulp, Grunt, and Node.js.  I’ll do a review of each course, so keep on the look out for Part II next month.  Anyone can take the course, regardless if you are enrolled in the specialization or not, so comment below if you would like more information.

Andrea’s Raspberry Pi Adventures

Next to my hackathon series, the most read series on Our Code was #MarchIsForMakers, where I offered an introduction to microcontrollers and wearable projects for newbies.  Due to the success of that series, I made a mental note to do more posts about computer hardware, specifically microcontrollers such as the Arduino and Raspberry Pi.  What I love about microcontrollers is that they are essentially micro PCs that can be programmed using Ruby (with Artoo or the SerialPort gem) and Python.  Things you can make with microcontrollers, such as heart monitors, small robots, drones, and casual wearables have caused an uptick in Internet of Things (#IoT) programmers and tinkerers.

Fellow coder and Our Code reader, Andrea, has been using RaspPi to create a video tracking project.  I thought it would be great to showcase her project for others who want to follow along and learn more about RaspPi’s capabilities.  She politely agreed.   Here’s Part I in Andrea’s Raspberry Pi Adventures.

*********

I’ve been really excited about one of my personal projects for the past couple of weeks, but haven’t wanted to say too much in case it wasn’t going to be feasible for whatever reason.

My project: I’m a bit of a windowsill gardener, and I thought it would be pretty cool to create a time lapse video tracking the growth of a couple of my plants. A combination of confidence in my green thumb (courtesy of one of my friends) and too much time spent on Pinterest has resulted in a pineapple plant growing in my living room. We go through a lot of pineapples at my day job (working in a hotel), so sourcing one wasn’t hard. I just cut off the top of the pineapple, cut away all of the flesh from the stem, peeled away some leaves and trimmed away until I could see some of the roots.  At that point the pineapple stem was placed in a jar of water.  The remaining leaves stick out and sit on the edge of the jar, keeping the stem from going too far into the glass. The stem sits in the water for a few weeks while the roots grow, and once they’ve reached a few inches in length I moved the stem to a plant pot with soil. Slowly new leaves start to grow, and I’m at this point with my pineapple now.

The logistics: I decided to use a Raspberry Pi for this project. It’s an extremely cool, adaptable microcomputer, and you can learn more about it from their official site. I’ve been wanting to play around with one of these for a while, and this was the perfect opportunity! I was originally planning on using a wifi adapter to send the images (taken two or three times each day) directly to cloud storage, but in the interest of power consumption I’m just going to be saving the images to the Pi, and harvesting them weekly. Looking at power- power supply is cited as an source in a lot of online posts about Raspberry Pi issues, so I was happy to see that my power supply and cable did supply adequate power.  The Pi makes this obvious by displaying a rainbow-coloured square in the upper right corner of the display if it isn’t receiving what it deems to be enough power.

Since I’m planning on having the Pi on a window sill, and would like it to still be fairly discreet, I’m actually going to try using a power bank to power the Pi. Ideally, I would like the Pi to send me a notification (perhaps via Bluetooth, or over the internet) when the power drops below a certain level, but that may be slightly beyond me for the time being. I’m currently testing my power bank to see how long it can supply power for before it needs recharging.

A few weeks ago I ordered a Raspberry Pi B+, along with the camera module, and last week ordered a micro SD card, mount for the camera, and a case for the Pi itself.

Raspberry Pi microcontroller

Raspberry Pi microcontroller

 

RPV

Initially, I had hoped to set up the Pi using SSH, but I got a bit frustrated after a few failed connection messages, so picked up an HDMI cable this week, and set up the Pi using a television for a monitor, and a controller that we have for one of our other devices. Suddenly I was making great headway! It took a few tries, but I set up the camera and wrote the command to take a photo and save the file to a certain directory, and then edited the crontab file so that the script runs three times each day.

Raspberry Pi Welcome Screen

This is the point that I’m at, so tonight when I get home from work I’ll see if the Pi is still running and on my next day off, or when I next have time, I’ll connect it back up to the telly so I can see how many photos were taken, also helping me figure out exactly how long the power pack will last.

It’s also worth noting that everything here was bought separately- you can buy kits, but I wanted these specific cases: the one for the Pi itself, and that particular one for the camera.

I’d love to hear from anyone who has used a Raspberry Pi before! They seem really versatile, and I’ve been reading about some of the really creative things people have been doing with them!

********

Stay tuned to read more about Andrea’s RaspPi project.  I will be posting any followups here in the future.

A Kulbaba: When she’s not playing with sugar or getting covered in chocolate in my day job as a pastry chef,  she’s busy with all sorts of geekery!  Andrea blogs mainly about learning to be a front-end web developer, and her tinkerings with a raspberry pi.  Follow her on Twitter @AKulbaba and read her blog Part Timer here.

Insight on Developer Testing

Editor’s note: Our Code will be featuring more guests posts and interviews with web designers, developers, and engineers with experience in order to provide more insight on what it’s like to work in tech. These posts will be career-centered and discuss topics on an expert level. I’ll make sure to mark them for you all in the “News and Views” category. Enjoy!

*****

Testing is a significant aspect of development. Yet it is often underrated and undervalued. Many developers are of the mindset that testing is only to be done by Quality Assurance professionals. Some even feel it isn’t “their job” to test. Others do it, but only begrudgingly.

Testing code, however, within the greater context of quality assurance, begins with the developer. The old “throw it over the wall” mentality has gone by the wayside in favor of iterative development that aspires to create higher quality systems. This requires a shift in thinking and doing.

Because testing comes in many shapes and forms, it is often a dynamic and expensive activity. But developers, in essence, test code all the time – whether through handling exceptions, fixing compilation errors, or debugging.

Testing that occurs at this level helps assure that the code base is robust and error-free. Integrative testing ensures the system functions as it should and behaves as expected when acted upon in predictable and unpredictable ways.

To what degree, then, should developers test? The most common form of testing is unit testing, writing code against a module with different inputs to test that different scenarios are handled. However, in addition to this, a simple smoke test of one’s developed feature, so-called “golden flow” testing, that runs through the normal end user path can behoove the developer in both assuring quality and expanding his or her comprehension of the system in totality. This kind of testing usually suffices but it depends on the complexity of the feature. In a TDD (Test Driven Development) environment, some Developers work hand-in-hand with QA professionals to feed the system a set of scenarios and then handle for such scenarios in-code, working in reverse from a “quality first” model.

At the very least, if your organization has no unit testing in place it is imperative to make sure your feature passes a basic smoke test before handing it over to QA. This helps increase efficiency by removing an iteration cycle. It also helps Developers think like testers, ultimately making their code more robust and potentially bug free.

****

Rice Om. is a technical and content marketing writer based in Los Angeles. She can be reached on Twitter at @OmaryMedia.

Review of ChicagosNEXT Hackathon Storified

Had a great time at the ChicagosNEXT Hackathon this past weekend and decided to do something new when it came to reviewing the event.  Thankfully, Roy Beasley tracked the hashtag we used for the event #CrushingIT and put together this great review on Storify.  Enjoy!

View the story “ChicagosNext Hackathon — 5/2/15 to 5/3/15” on Storify

How to Survive Your First Hackathon Part IV: The 7 Tips I Learned as a Newbie

This post is part of a series I created detailing my experience at my first hackathon, to read part I, Setting goals and preparing for my first hackathon, click here. To read part II, Attending my first hackathon and rubbing elbows with the sponsors, click here. To read part III, Surviving a hackathon when failure seems imminent, click here.

Going home around midnight on Day 2 was probably my biggest mistake.  I had realized that night that I would fail in getting my project completed by Day 3.  However, I had gone home at the end of Day 2 with the intentions of waking up by 4am, finishing at least a prototype draft of my project by 10am, and submitting it not to compete, but to get feedback from the judges and sponsors on Day 3.  I did wake up early, but more ill than had I been on Day 2.  Staring at my screen at the wee-hours of the morning made my eyes feel like they were bleeding. I finally gave up, took some Sudafed, and rested.

Overall, I enjoyed being at the hackathon, meeting people, and challenging myself on a project that was out of my comfort zone.  Feeling less intimidated, I already signed up to attend another hackathon, Code til Dawn which is nearby, has more participants, and is only 24 hours.  Though disappointed, I had to remind myself once again on Day 3 that I didn’t go to the hackathon to compete, I went to learn new things.  If anything, I feel like I accomplished that goal.

Attending your first hackathon soon? Here is my advice on what you should do if you are a code newbie:

  1. Come prepared. While most hackathons provide food, wifi, printing, and some utilities, most are BYOD.  If you have an idea in mind of what you want to build, make sure you have all the software you need downloaded before the event.  If you don’t have a hardware resource you need, work the room, and introduce yourself to someone who does.
  2. Be honest about what you don’t know.  I found that when I put my weaknesses on the table, there are usually one or more people willing to help me out. Don’t assume everyone there is experienced, many may be newbies just like you. Leave your ego at the door and prepare to be uncomfortable.  Your ability to build under pressure is the main challenge of participation.
  3. Find at least 3 people who know your language or a language you want to learn.  I’m pretty proficient with python as a language, and I wanted to know more about how others were using it in their projects. I also wanted to learn how to integrate frameworks such as Flask or Django with with my scripts. Unfortunately, I wasn’t able to connect with other python developers based on the participant pool.  However, at larger events, finding one or a few people who you share a common language with shouldn’t be too difficult.
  4. Try to connect and organize a team.  I was at disadvantage because I didn’t have a team to work with and my project was fairly large.  With no one to distribute tasks to, I didn’t finish.  If you’re a newbie, find a group and join a team as soon as possible. Unless you’re a seasoned programmer, a hackathon is not the type of event to go it alone.
  5. Talk with the sponsors, they are potential employers.  Not only did I find the sponsor reps at the event, I introduced myself and asked them questions about their companies. Which leads to my next tip…
  6. Follow up. Blog and share ideas to build online community around issues, themes, and trends discussed at the event.  Don’t just take business cards, do the work in connecting with others afterwards. Stay in touch with your team members and offer to take a sponsor or two out to lunch to discuss internship opportunities.

My final tip and what I learned the most from my first hackathon: don’t beat yourself up.  I went through a period of “should’ve/could’ve/would’ve” thinking that afternoon after I realized I failed.  I could have familiarized myself with python web frameworks to help out on the backend, I should have used tools like Node to assist with coding the javascript, I would have used App Inventor to prototype the app component of my project.  Doing all those things would not have changed anything: I was fighting against time, being sick, and my own high expectations.

As a code newbie, don’t worry about creating the perfect submission or winning. Focus on completing your project, connect with others, and learn new skills you can use later.  Your first experience at a hackathon is whatever you make it.  Only you can decide what you want to get out of it, so make the best of your time.

How to Survive Your First Hackathon Part III:

This post is part of a series I created detailing my experience at my first hackathon, to read part I, Setting goals and preparing for my first hackathon, click here. To read part II, Attending my first hackathon and rubbing elbows with the sponsors, click here.

In Part II of the series, I summarized the type of project I wanted to build: a location-specific news and trending source powered and automated by web-crawled social media data I gathered.  I decided to use the Twitter API to perform search queries based on my region’s lat-long coordinates, create a bot and web crawler to pull tweets and info from that location, and use the data to report trends and news via a web app/site.  A big project indeed considering I only knew how to do 3 of the 5 tasks it would take me to complete it, but somehow I convinced myself I had enough time.  Blame it on a sugar-induced energy spike caused by the delicious espresso powdered bon-bons I was munching on at the event.

As the time carried on, staying awake was the hardest thing for me.  I had been use to getting at least 7-8 hours of sleep even with a busy work schedule, so working throughout the night and early morning was out of the ordinary.  Not to mention, the food there was mostly college dorm junk: candy, pizza, donuts, chips, and lots of soda.  On Day 1, I broke into the facility kitchen to find coffee and munched on an apple and banana, trying to stick to eating healthy and avoid brainfog.  After a while, I dived in and ate whatever was offered to avoid starving.  Big mistake, by 11am on Day 2 of the hackathon, battling food allergies had now been added to my agenda.

I was incredibly optimistic about my chances of finishing the project in less than 24 hours.  Even if I had no intention of entering the competition in the webdev category, I wanted to finish it according to the guidelines set, just to prove to myself that I could.  Another slight setback occurred in the afternoon: we lost our WIFI connection for an hour and half.  Feeling powerless and ill from allergies, I used the time to take a nap in one of the breakout rooms.  When I woke up, I felt even more ill, but I still got up and headed back to my workspace.

By night, I had made progress.  The twitter bot was created, the web crawler program I coded in python was set up, and I had a functioning site mockup with the important widgets I needed to make the crawler work.  I still had a lot to do though: I needed to add content, get the python code synced to the site and functioning on the backend, create my first graphs from the data I had gathered earlier, deploy the app, and upload the site.  Though it seemed like my tasklist was growing by the hour, I still felt optimistic until another setback occurred: the organizers had decided that due to the low turnout of those who entered the competition, the judging would be moved up 5 hours on Day 3, thus moving up the time we were all expected to be finished.  Because I had not entered the competition, I accepted the changes.

Truthfully, I was disappointed in myself because I knew I couldn’t finish my project by the time the hackathon would end.  A friend that I had made at the event encouraged me to carry on with the site after the event, and use it in my portfolio.  I concluded this would be the best route. I continued to work until around midnight, packed up, and went home to try to get some more sleep.

To read my 7 tips for how to survive your first hackathon, (and the final conclusion of what happened at mine), stay tuned for Part IV.