"This" (not this this but that this) JavaScript

Introduction

I wanted to write a little bit about JavaScript seeing as how I've been working with it so much lately. Specifically, I wanted to write about a common topic of confusion in multiple languages; the dreaded this. I'm only going to talk about this in terms of Java for now but many of these concepts are similar in other languages.

A good place to start with this discussion is with execution contexts. The idea of execution contexts is embedded in how JavaScript is executed. The JavaScript run time environment keeps track of a these as a stack. As the script runs, the active context is on top. As the program leaves contexts by leaving functions or other scopes, this stack changes to always show the active window. This brings me to what defines a execution context in JavaScript.

Execution Context

When code runs in JavaScript, it executes within an environment. The environment that its running in is referred to as the execution context and has three distinct areas: global code, function code, and eval code. ECMAScript Standard defines this as a keyword that "evaluates to the value of the ThisBinding of the current execution context." 

There are a lot of resources and articles about scope online but for the purpose of this article I'm going to keep it simple. Global context refers to an area of execution that relates to the script in general meaning that when you're running code outside of any function. Function context is reached whenever the flow of execution enters a function's body. Eval context refers to the code to be executed inside of an internal eval function. I've separated some code below to highlight how these different contexts would look.


Global Context:

//Global Context

int x = 1;
int y = 1;
int z = x + y; 

Execution Context:

//Execution Context
function executionContextMethod(){
var hello = "Wassssup"; 
}

Eval Context:

function executionContextMethod(){
     var hello = "Wassssup";
     function EvalContext(){
          //This is the eval context
     } 

There isn't anything going on here that is really complicated but the eval code deserves a closer look. Technically, where the comment is eval context but only if its called. This is an odd concept because we tend to think about programs only as they're written but in this scenario we have to think about the code in run time. Since JavaScript is a single thread, meaning only 1 things can happen at once, the browser has to keep track of where it's current context is located.

As a page loads, the script enters the global execution context. This means that its pointed at the global object. As it enters functions that are called, the context shifts an execution area and now refers to that function. This process is controlled by a stack that pushes and pops contexts depending on where its at.

The take away about execution contexts is that the focus of this depends solely on where the context is currently located at. I've put together a JSFiddle to demonstrate some of these concepts.

Conclusion

JavaScript may execute in a single thread (in most cases) but it is a very complex scripting language that has adopted many features of object oriented languages and will continue to get more complex and powerful. When thinking about this, always look at whats around it and think about the current execution context and you should be fine. 

Fright and Elitism

It's been a while since the last time that I posted and much of my situation has changed and many events have occurred that have put me in a drastically different spot than I was in a few months ago. To give a recap, the last time I posted was in March. At this time I was still in the military looking to update my portfolio and was applying at positions in America (I was in Japan) with little success. Things seemed to be going well with the process because I was learning and continuing to code which were the two most important parts of the process. Since then I've gotten my first in-office programming role, sought opportunities in multiple companies, and have refined my search to a point.   These events have led me to some revelations that could be helpful to others looking for a similar path in this career.

First, let me mention that getting a programming job is not as simple as just applying and testing in. This will seem obvious for anybody that has already gone through the process but I still remember how it felt to be applying for random positions, just hoping for any job that had me working with code. Getting a job at a company as a programmer is about marketability of yourself(this could be said about any job), understanding what they need, understanding what you offer, and selling yourself to them for the job. I believe a lot of this is self explanatory or implied with any job but programming positions can be tricky. 

When you interview for a technical role in a company you get two feelings; one of fright and one of elitism. The fright comes from not knowing what specific questions the company is going to ask you about for the technical interview. There are literally an infinite number of programming questions one can be asked due to the nature of the field and most of them are difficult. The questions could range from basic data structure questions such as, "How would you store orders from a customer?" to more advanced topics like, "How would you create a neural network to create an adaptive AI?" The second questions sounds like you're being interviewed for a senior position for either gaming or some robotics company but I was asked this...at a company that does tax software. The second feeling elitism is by far the more dangerous. Elitism is dangerous in any job or walk in life as it implies hubris to the extent that you feel that you're better than everybody else. This leads to resentment from your fellow workers, you trying less to make yourself better because you think you're already the best, and a general unprogressive attitude. Programmers are especially susceptible to this because of the nature of our work. We deal with science. We may not be mixing chemicals in beakers but we are dealing with complex ideas to accomplish high level tasks and a lot of companies acknowledge this. Programming teams will be in the Research and Development section or be in the famed software corner and will be drawn under a different light than a lot of the other parts of the company. 

Dealing with both of these problems can be done by taking a step back and reassessing. When you're feeling frightened about a programming interview or just a problem in general, breath and think about what it is you need to do. If you're still a few weeks out study, and get ready for the next interview every way that you can. If you study hard and write as much could as possible and you feel like you've put as much effort as you could had into it, then you succeed regardless of the result.
By pushing yourself to write code and read problems, you're forcing yourself to become a better programmer therefor your winning regardless of wether you get the job. The more programming practice that you do the more confident you're going to feel and eventually you'll start getting a lot of things right which leads me to elitism. 

When you're killing it and have an instant answer to every question, you're on top. You feel like nothing can bring you down because you can answer or handle any problem that comes your way and people come to you for answers. This is a great feeling but how you handle it can be a huge problem or a huge advantage for you depending on your choices. Allowing yourself to be unfriendly and full of yourself is going to drive others away from you and make managers dislike you and more importantly people won't help you.

If you're on top you probably are thinking that you don't need anybody's help but you do. You do so strongly and vehemently that you don't realize it right now because you can't fathom the problems that you don't know. People observe you everyday and when you're coding they observe your code because they need to be able to write code to work with yours and if they see something wrong with it or something that could be done more efficiently then you want them to tell you. If they strongly dislike you, chances are that they are going to want to see you crash and burn. Take a breath when you're feeling good and ask others what you could be doing to be even better and if nothing returns find things to make your self better.

Amazon Interview Preparation

It's been about a month since my last post and a lot has happened. For the last three weeks I've been in northern Japan doing training with the Japanese Ground Self Defense Force (JGSDF) and have been swamped with schoolwork and studying for upcoming interviews. The biggest news out of all of this is that one of those interviews is with a large company that I'm very excited to have gotten an interview with; Amazon.

Amazon has one of the most successful online retailing websites on the planet and is constantly striving to innovate and improve themselves at such a high rate that they're constantly hiring new talent. Along with the scheduled time for my first interview, the email included two attachments of subject matter I should brush up on. The topics included typical programming concepts like data structures, algorithms with big O notation, operating system concepts, distributing ideas, SQL, and coding abilities.

This might seem like a lot for the average person who either does a small amount of coding or not all but after four years of college these are familiar. When I was browsing through the list when I first received the email, I was skeptical of my abilities and felt like I wouldn't be able to code a lot of these topics. I imagined myself in an interview where they asked me question like, "please code a merge sort where we pass you an array with up 300 elements" and me staring in silence for a while. Interviews are supposed to be quick, fast, and hardly have any silences in them. You want the interviewer to know that you're not only confident in your abilities but you can also make coding a social experience.

I hit the whiteboard in my local library the next day and went down a list of interview questions that I found on glassdoor.com. The first question that I read was, "design a program that takes a integer value up to 999 and outputs it's English equivalent. So if I entered 124, it would output one hundred and twenty four." I've done a problem like this before but staring at the board, I had no idea how to start. The interview books I've read said to ask questions about the problem, so I asked if I would error check, test for non-integers, and if I was just writing a function. Since I was the interviewer for this problem, these questions didn't help.

I was a little frustrated with myself because I felt like I was such a stronger programmer than this. When I worked on projects for the iPhone, it just came naturally; I need a class for these objects, and I need to create lists here, but coding a simple problem was so much different. After a few minutes of self anguish I decided to consult the internet for the sage advice of senior programmers who've all been through the same problems. The first result that popped up after I typed in "Programming Interview Amazon" was a video from Careercup.com

If anybody who's reading this unfamiliar with what Careercup does or it's back story, it was founded by Gayle Laakmann McDowell who was a head recruiter for some of the biggest software companies in the United States and started the company. The intention of the company was to provide references for those applying for jobs in the programming field including books such as Cracking the Coding Interview, and the Google Resume. The video had McDowell with a interviewee as he attempted to solve a problem by following a set of guidelines.

The pace of the interview made me feel immediately more comfortable because this "perfect example" was relaxed. The interviewee wasn't a hot shot who immediately responded with perfect answers and the suaveness of Harrison Ford but just a 20 year old in a hoodie who would stop and think about his problem and ask questions. I'm sure that this seems obvious to those that have interviewed but undergraduate school doesn't teach you what to expect in an interview and the only other interviews that I've done were for customer service which required well rehearsed lines to pass.

He would ask questions about the problem and it's implications and would begin talking out loud about some possible solutions while giving them pro's and con's as he went. At the end of this process McDowell would ask wether he felt those were the best approaches or what the benefits of one over the other was. I found myself answering over the candidate because it seemed like a class discussion now and I felt far more comfortable with that. After that he decided what approach would yield the best results and started to code while talking through it. The best part about the coding process was that he had minor syntax errors through the code but McDowell didn't care and mentioned as long as they weren't too big or numerous, she only cared about the functionality of the code. Coding without an IDE can be intimidating because you're not sure if you're making mistakes or not.

To anybody who is planning on going into their first interview for programming just remain calm and do what you've been doing for four years: code. If you have a passion to code, you probably have a lot of valuable skills that employers are looking for and they only need you to understand the basics of the process in order for them to develop you into a productive programmer. Good luck to future coding interviews and I'll be sure to keep posting about my upcoming interviews and results.

-Joseph Priest

Crunch Time

With possible interviews looming in the future and my resume poised for release into the job market, I've been reading everything I can get my hands on pertaining to programming interviews. My familiar search of "Programming interview questions and exercises" that I've typed into Google a hundred times, autofills and brings me to a long list of purpled visited web pages that I've grown familiar with. My Chrome bookmark bar has a folder labeled "Programming" with more subfolders than anything in my bookmark bar and within that, the "Interview Stuff" folder holds the most links in any folder. As I'm reading about the Apache framework for the tenth time and attempting to memorize it for server design, I start to wonder if everybody else is doing this to get an interview. Not everybody is doing it but if there happens to be even a few, I have to look better than them and be that much better prepared.

I buckle back down and start writing out a linked list problem on my whiteboard and walk my bed through the steps of inserting and deleting elements. My bed retorts with a witty question about wether I know how to find the half way point of that list on one pass; I draw a blank. The bed may have gotten the best of me for now but after I look it up one more time, I'll know it for good. As I'm reading through it I think about how I'm not going to have my computer to look anything up during my interview and how intimidating that is. I tell myself that they couldn't possibly expect me to have memorized every single thing from these book but a bad feeling lurks inside me as I imagine a candidate who does know all of these questions. The MIT graduate would easily breeze through these questions without breaking a sweat and would be charming, wonderful, and have a portfolio that could serve as dissertation. Back to the white board and my bed.

I've found myself in this cycle for the last couple of months and am memorizing a lot of useful information but am always on edge. I can't wait for the comfort of knowing that I'm working somewhere and can start contributing real software. It's not that I feel these study times aren't valuable, it just they're not producing actual products. I feel like a Padawan who must learn the tools of being a Jedi before combining them to be a badass force wielding programmer. After being hired I can unleash my programming force powers and defeat the dark side of the force (inefficiency). Alright, this might be a little too much fandom in the Star Wars area, but it gets the point across. This stage is nerve-racking and invalidating but I feel like it's a necessary evil.

Something else that I've noticed from having read a few programming interview books such as Cracking the Coding Interview and The Google Resume is how much my school didn't teach me about programming. The one conversation that you usually hear from liberal arts majors after college is, "at least you have a skill that you can use" which is partially right. In undergrad, I learned the valuable skill of programming, but if I wouldn't had done extra research and done outside projects I never would had known enough to be applying for jobs. Undergraduate work teaches you close to nothing that you need to know for programming actual applications and if anybody has ever attempted to create usable open source software, you know what I mean when I talk about the countless hours that I've spent reading online articles and watching Youtube videos to learn how to patch a project together. It's kind of frustrating to think of how much money that I've spent on my degree and how little that I've actually learned from the school. The school did do one amazing thing for me though, and that's that it opened my eyes to the possibilities. Without it, I'm not sure I would had ever pursued the number of projects that I have.

A few more months and I'll be back in the states and ready to start interviewing and now is the time to crunch and remember that my hard work will pay off (hopefully). Good luck to anybody else who is at this same stage of your career and know that there are others working just as hard as you and if you're an employer, I'm ready for whatever you've got. Looking forward to demonstrating what hard work I've put into this.

Thanks,
Joseph Priest

Programmer's Jobs Search

Hello everybody (in the words of the great Dr. Nick)! It's been sometime since I've written here mostly because of work and school it's become my mission to regularly make contributions to this blog. While I may have failed in the regular part I will make posts because I need a brain dump for all of the programming concepts that I've learned recently.

I've noticed a trend about these posts and that's that they are only half about programming concepts and half about a programmer's lifestyle. This period is a transition from school to work but it's a subject that I can't seem to find very many blogs or posts about so I think it's excusable to be half and half on the subject matter. 

This week's post is about finding a programming job coming out of undergrad and the military. I'm going to try and tailor this more for just the undergrad experience because I don't think there are many computer science majors that joined the Marine Corps. For the last few weeks, I've been submitting applications and altering cover letters to fit the needs of each company and have received a rainbow of advice. I've heard a lot of weird advice lately but the most consistent and crazy one is that you should lie on your resume. Nobody that I've spoken to has told me to just lie but they all do the same chuckle and indirect head movements and say, "everybody embellishes a little bit." I can see somebody marking up their resume from something like, "programmed one time in C," to "familiar with C" as long as they have a large basis of programming knowledge because they could probably learn it quickly, but having programmed once in a language doesn't qualify you to say something like "Expert C programmer."

These statements seem like gross exaggerations of the truth and could be hurting the job market. Since so many people are embellishing and website all over the internet are suggesting to do it, it leaves the truthful applicant with only one choice; lie. If everybody is lying and you're an entry level programmer with barely any experience, it would be impossible for your, "I worked with Java once on a project" to compete with somebody else's "Java master-->barista he man."

While the last part might be a bit of a stretch, the problem still holds validity in a wave of applicants who are not sure to fib or tell the truth. I've decided to take the high road on my applications and only make claims that I can back with projects that I've hosted on Github. This seems legitimate because I can write an abstract about the project and if somebody thinks that I'm embellishing they can just check the project for themselves. 

Though I'm in week two of my job search, I remain faithful that my method will be rewarded even though my application might be against "master coders" who are fluent in every language imaginable. I've received a few reply's for my applications but they are interested in hiring immediately and I won't be out until early June so unfortunately I have to wait. If you happen to be an employer who is browsing through this to gauge me as a candidate, I'm legitimate! I've been practicing coding on a white board for the past few months to get ready for an interview so please give me a shot in your office and I promise you'll be pleased. If you're just another programmer facing some of the same issues, stay strong as there are many of us that I've spoken to from my college who are experiencing the same uneasiness; we'll prevail.  

Once again, I look forward to hearing back from anybody who has opposing or similar ideas or just wants to chat. I love networking and even if you're from a drastically different walk of the programming life, drop me a line. 

Thanks,

Joseph Priest

Science and Thought

          A girl asked me while I was having a few drinks at my friends house, why I had gotten into a science major? I told them because I enjoyed understanding how things worked in the world around me and I satisfied some Nietzschistic desires of mine to support the world in it's progression. As if my answer were prosaic she said that she didn't understand why anybody would go into something as boring as a science major. I was a little confused so I asked why she felt science was boring and to what aspects of other majors did it lack luster in comparison to. She looked around for a little bit in contemplation and said that she wasn't sure but it just bored her to have to look at numbers all day. She said it wasn't about the money it was about self vindication and walked into the other room. Still sitting in the recently abandoned room, I thought about what had just happened.

          I've had a feeling since college that anybody that I talked to from a liberal arts major had felt that my choice in major was less interesting or less emotionally satisfying. It was just a strange intonation when they spoke about science that made me feel like they didn't think I was getting enough maturity from my subject. I disagree with that because I've arrived at many philosophical points because of math and had even more of them reinforced because of later discovered math. Also, many of my thoughts on productivity and creation have arisen and been solidified by the patience it takes to pursue a math or science degree. This argument between liberal arts and science, dwindles after college but the remnants still come up in conversation and are strange to me. I understand why people would be interested in history, languages, art, photography, music, acting, etc and because I've asked myself why they would go into their majors. I can place myself into everyone of those jobs and see interesting and inspiring things about them all, so why is this so difficult to do when the roles are reversed. There must be something about mathematics, computers, chemistry, biology that mystifies people's interests and steers them to the liberal world. There has to be something that gives the sciences the repulsive status that it's achieved with so many college students.

          To be interested in a subject is to be be confident in your ability to interpret the subject and further our understanding of it. If you wanted to learn about poetry you would have to know the language in which you were attempting to learn poetry first. Hard learning is learning from nothing and easy learning is building upon things that you already know. Topics like history and english are easy learning because we have spent our entire lives using these subjects and building upon them but subjects like mathematics and foreign language are considered hard learning because we are presumably building on little or  nothing. I've heard that mathematics is difficult because it's a subject that isn't natural to us but I feel like it's even more natural than english. While we learn english to read, write and speak we learn mathematics to describe the world around us. At this time we learn to speak while we also learn how to count and describe the world around us using numbers. English is how we associate objects, feelings, events, etc.

I think I've vented enough about this subject but this topic has been brought up a few times in the last year I felt like it needed to be addressed. Hope everybody enjoyed this and if you have anything to add to this or other post, feel free to leave a comment.

Thanks,
Joseph Priest

iOs Programming

iOS Programming

          It's been a few weeks since I've written anything and I've been missing these posts as a creative vent for structured periods of work. The process that I've locked on has been to set aside an hour or two to do an activity (program, guitar, read, etc), do said activity in silence, and then write about what I've learned from it. It feels like a good structure and allows me to really focus on what I'm doing and then digest it through writing afterward. The biggest challenge is making sure I stick to that schedule. 

          Tonight's activity was an admission of sloppiness. As you can see from my personal website (still in the works), I've worked on a few iPhone apps for various people and have learned a lot from those projects. Recently, I've been working on one that deals with an established servers with pictures stored with accounts  and is supposed to retrieve them after the user has logged into the app. It's not a huge project and in comparison to the scope of my last project, it seems fairly easy but I've had some major hiccups in it. My first few projects in Xcode were made by using what I knew about C and C++ and combining that with random tutorials that fitted my needs for those specific instances within the app. This worked for one app,  but not with the other. 

         My professors have always warned me of becoming a sloppy coder and to avoid taking shortcuts in learning new languages. Up until recently, I had no reason to believe this would ever be a threat to me as most of my projects had been school ran or at least text book ran, but I see now. This latest project has shown me that my understanding of the View, Controller, and Model method of programming for Objective-C has been set about all wrong. 

          I remember reading about this style of programming in the Apple Documentation but it didn't really occur to me that it was any different from Object Oriented Programming (OOP). When I started creating the app about the accounts and pictures I realized that I had overlooked some really important aspects of design. The first thing that I learned was his system is meant to keep objects in objects and maximize efficiency and reusability. It's standard knowledge that OOP is for efficiency and reusability but Apple's model takes it even further. Objective-C wants you to handle your programs like factory workers and management and really break up the process, but it makes sense. 

          Firstly, you think about the variables as models. Models are Apple's way of creating a visual way of imaging storage such as arrays so that the programmer can see what they have to offer. For instance, if we were to store a list of questions like "What color is the sky," "How many seas are there in the world," and "Why ask so many questions," we would store these in an array and create a pointer instance variable to reference them. So far, there isn't very much of a difference but it gets better.

         Next, we have the Views and the Controllers. To simply put it, the Views are what you see and the Controller...controls! It's so easy but the exchange of information is extraordinarily quick. Your view on your phone is what you see: the buttons, labels, pictures, etc and your Controller is what handles the processes between the Views and the Models. For instance, the View knows that it's supposed to be displaying a label with the question variable but it doesn't know where to get it from so it asks the Controller. The controller knows that it's variable is pointing at an array that holds the questions so it grabs it and passes it back to the view to display. Both the Model and the View act as single minded drones that only do one thing apiece: the Model stores, and the View displays. 

         This model of exchange doesn't seem that crazy of a concept but it makes a huge difference when you're taping together all of these Controllers which are conflicting with each other and causing heaps of errors. Tonight, I accepted my lack of discipline and settled to reread a book that I've had in my possession for some time but have never brought myself to get to the Big Nerd Ranch Guide to iOS Programming. It's a pretty good book but most importantly it stresses the process of design and that's something that I really wanted to refocus on. 

          Having a schedule and sticking to a format is good practice for life and programming. I hope you guys enjoyed this and I look forward to writing again soon!