Monday, July 13, 2015

"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. 

Tuesday, November 18, 2014

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.

Friday, March 28, 2014

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

Tuesday, February 11, 2014

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

Wednesday, February 5, 2014

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

Saturday, January 4, 2014

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

Sunday, September 8, 2013

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!


Thursday, August 8, 2013

Focus


          Welcome back and I be pleased to hear if anybody had actually returned to the site but seeing as how there is only 29 views total so far, that's doubtful. Wether this is your first time reading this from the future (I suppose any form of reading would be the future) are more recently it's been a few days since I've posted anything. Today, I wanted to talk about project management and how to deal with the difficulties that arise from both the project and ourselves.

          The last few weeks have been a brain scramble from having to switch between projects and mindsets while also dealing with time management. Time has been a crucial concept for me lately because I have so little of it and so many things to do within it. One of my older projects has came back to life by the act of the company having found a designer for it, while my newer projects are fast approaching their deadlines with much programming still remaining. While these tasks are daunting in their own respects, they also make me excited. I love staying busy and having three projects to switch between, each with their own flavors, keeps me plenty busy. Time management is the most important virtue and demands a careful breakdown in order to weed out errors and feel proud of the positives.

         Important above all else to good time management is focus. Focus is being able to look at one task at a time, apply a step-by-step process, solve it while keeping it in perspective with the rest of a project. My definition of focus could be because I'm a programer and this approach is similar to  solving a programming problem but that's why I feel it's so effective in not only dealing with programming but a lot of life's issues. Firstly, being able to complete a tasks means forgetting everything that isn't related to the work and breaking it down.  I verbalize what the problem is (if it's not already in words), repeat it a few times, and then I begin listing my possible solutions in the broadest sense. For example, my last project required a data structure to be set up for storage of books with the author's names. I said to myself, "How do I get these books to be associated with these people?" Then I looked a little deeper, "How is every person going to be unique?" This is the first real base level, answerable question and is easily answered: unique id's. From this system I can build all of the parts that make up the project in my mind, the id's, fields of data, structure of trees, sorting, and create a blueprint of whats needed.

         From this point, it's easy. Like a recipe, I have all my ingredients and I just have to start building them then mix them together. Order within a program is crucial which has taught me how important it is for everything. Thinking, planning, and consistency are key in creating solid projects that aren't just passion but completion from consistency. Reward yourself for consistency and you'll be surprised by what your happiness ultimately creates.

         I have to get going but I really hope this starts getting a little more attention, perhaps I need to market myself more. Have a wonderful time and leave any comments that you'd like!

Thank you,
Joseph Priest

Saturday, August 3, 2013

Website Design

          Last week I purchased my first domain name and hosted it through GoDaddy.  I did this to solidify my work resume by tying all my social media/networking sites together. It's incredible to be that it takes so many of these types of websites to be considered a viable candidate. That's actually a half truth. The fact that I've only been able to find a few programmers online that have laced all of these things together tells me one of two things; programmers don't have to do all of this to get a job or they're not very Google friendly. Regardless of the answer, my hope is that this will get me a job or at the least boost my chances. So I downloaded my design resources, made a collection images and content I wanted to use and stepped off.

          Website design has never been an interest of mine because it seemed like a softer, more front end aspect of technology and I've always been interested in the more in depth, programming side of it.  I've grown a large appreciation for web developers in the last few weeks due to my efforts in making my web site and having to create a site from scratch. Let me clarify that I am not talking about those that are concerned with just the design aspect. This is a very important aspect of the creation process but it can all be done by one person while the coding is a different realm entirely.

          A company that I'm currently writing an app for, or have been writing an app for, has been waiting to release the app because we've been missing a designer on the project. To be honest, I didn't understand why this was a difficult person to find; in college there were hundreds of them and they were all looking for work. I waited patiently, hoping that a person with the specific "skill" set they were looking for would come along. Three other projects came up during that time and I kept busy with them and after three months, I had started to think the app was bunked until they finally found one. It turns out that the manager for the project was looking for somebody who had good design work, efficient, and could code their own designs. That last one was the confusing to me.

It confused me to hear that most designers weren't able to design and code their projects. College was a time of pressing yourself to understand brand new concepts and become familiar with them to a functional level as quickly as possible, which meant exploring every concept of their field. Didn't everybody do that?

          Software developers are faced with thinking about a big problem such as allowing a customer to input a variable amount of inputs in order to receive a solution, and are then required to break that problem down step-by-step and design a program to execute those steps; design and code. From what the project manager was telling me, most web designers didn't do that. In fact, most only got as far as Fireworks and called it done. This was pretty amazing to me and coincided with my need for a personal web site, so I explored.

          After buying the domain, paying for the hosting, setting up an FTP I was ready to go. Then I hit the problem of design, which I thought would easily be solvable by template, but I was wrong. Of the templates, very few of them had anything that I wanted on my website and even fewer had the flexibility that I was looking for. Like most of the programmers that I know, I approached it like a new language and decided to learn from the basics; the only way to learn something is to try. I spent the next two weekends working with everything from templates with no CSS, to complex frameworks, to JS outlines and any combination of those tools. It was daunting, but I kept my focus and researched everything I didn't understand and eventually I came to an understanding. My website is still in it's alpha phase, but I realize how difficult it is to design and code. I love coding and while I don't consider (I don't think anybody does) scripting or web programming to actually be programming, it is a very difficult thing to wrap you're head around. You've got to consider every aspect of what you're designing and think of the tools to make that vision come alive which shares a lot of parallels to programming.

I'll wrap this up but I just wanted to acknowledge the magnitude of work that somebody do that it overlooked. I still love designing programs far more and enjoy piecing everything together and producing a working program from scratch more than anything else in the market, but I'm always glad to cross train and try something new. Here are some of the tools I used for the website:
- Frame Work: Twitter Bootstrap
- Design Program: Dreamweaver
- Code Editing: Komodo
- FTP:  Cyber Ducky
-Google Chrome's Developer Tools are amazing

I'll make sure to upload some other tools in the future for those who are interested and I'd love to hear some suggestions too.

Thank you,
Joseph Priest


Wednesday, July 31, 2013

Introduction Piece

Hello everybody!

          I'm not really used to writing my thoughts out in a public place, but seeing as how I routinely write them down for myself in order to organize my thoughts, this shouldn't be too much of a difference.

          This is just going to be a quick introduction as I haven't had time to organize the pages of notes that I've written over the last few years into a presentable fashion. My goal here is to create a place where I can dump my creative thoughts, discoveries, epiphanies, and frustrations and organize it into a neat timeline so others can see what I've been doing. Not only will this allow others to see where I'm at in my programming mind set but it will also allow an open form for people to comment constructively on what i'm doing.

          I look forward to eventually getting some replies on these post but for now it will be a good place to organize thoughts on some projects that I currently working on. Recently, I graduated from Park University, having transferred from the University of California Irvine, and have been working on iPhone apps for various companies and people that i'll have to check with if it's ok to write about the details of their projects. These projects have been getting increasing more difficult to work on due to the various time constraints imposed by work (active duty Marine Corps), my wife, and most recently and enjoyably, Comic Con. I've had an continue to have a very supportive wife who lets me stay up all night and type into the wee hours.

          I'll wrap this up with a promise of future posts, some of which will visit past projects, future projects and current projects, and wish everybody a wonderful day. I feel like this should have some articles or news for people to see, like a link to something interesting. I watched this video (linked below) earlier when I was working on my website (which will be up later this week) and thought it was really interesting and potentially something that I could write a response to during the next few days. Enjoy the video and I look forward to hearing some feedback.

Thank you,
Joe

The Future of Programming: http://worrydream.com/dbx/