Category Archives: Computer programming

API Examples

An API is a database kept by an entity which allows developers (programmers) to access its data through a particular protocol. Programmers can get a key that allows them entry into the API; they can then gather the data and display it.

Here are 3 APIs that I found:

1. The NASA API at https://api.nasa.gov/

The NASA API gives access to items such as the Astronomy Picture of the Day, Mars, and Earth pictures. There’s an API access endpoint, documentation, and a getting started guide. There’s an hourly limit of 1000 requests per hour. An API key is recommended but not required (no authentication needed). GitHub has 169 results on a NASA API search.

2. The Goodreads API at: http://www.goodreads.com/api

This API grants access to a lot of information about authors, book reviews, etc. There seems to be less information about single titles, but one can get lists of books as well as entire virtual bookshelf. One can acquire a developer key and there are instructions as to how to how to use the API. The site also has links to a developer’s forum. GitHub shows 95 results for the Goodreads API.

3. The United States Census Bureau API: http://www.census.gov/data/developers/data-sets.html

This site lists about a dozen categories of survey data. In each category, there’s a summary file and data file with sample calls. Users can get an API key. There’s an API forum and technical documentation. GitHub shows 125 results for the census API.

For more APIs, there’s a directory at: http://www.programmableweb.com/apis/directory

Reflections on the Fourth Week at The Iron Yard

This week we learned more techniques for using JavaScript code to place items onto a web page. The code we reviewed to do this seemed somewhat complicated, so I “diagrammed” the code and went over it with Jim (our instructor) to make sure that I understood the functionality correctly.

The class format on weekdays (Monday-Thursday) generally has a lecture in the morning, and lab (working on programming tasks) in the afternoon. Friday is entirely dedicated to the lab work. I’ve started to notice that I tend to reach an impasse about 2 pm, when I think to myself, “what the heck does all this mean, and am I ever going to be able to understand it?” Fortunately, Jim is available to answer my questions and point out what steps I can take next, at which time I’m able to continue with the assignment.

This is the main reason I prefer a classroom learning experience to an online learning experience. The lectures allow me to ask questions at the time the time the material is presented; later, in-person advice and guidance is equally valuable to me when I’m in the midst of processing new information.

This week the data we used with JavaScript came from an API (application programming interface). The particular one we used was the Marvel interface at developer.marvel.com. An API is a database kept by an entity which allows developers (programmers) to access its data through a particular protocol. Programmers can get a key that allows them entry into the API; they can then gather the data and display it. In this case, the results can be visually spectacular with the large number of superhero and comic art available that Marvel offers to developers to use.

I’ve checked out other APIs (and browsed through a directory of APIs to see what’s out there), and I’m highly motivated to get to know how to use them, because there are a lot of exciting APIs out there, and I’m eager to try them out.

Running the code

When I was learning computer programming, before the internet, we learned that there were a couple of main ways to run the computer code: first in, first out, where the first instruction to the computer is the first one completed, and last in, first out, where the latest instruction to the computer is the one that is run first.

Now computer code is run with browsers (e.g. Chrome, Firefox), which makes things a little more complicated. The set of instructions are still put on a virtual “stack,” and in JavaScript, instructions are run one at a time. This is fine if the instructions are simple ones, such as console.log (which simply prints to the console). However, if the instructions are complicated and take a long time to run, this can hold up the rest of the code. Meanwhile, the browser is waiting for JavaScript instructions to complete so it can refresh the screen (at a preferred rate of 60 frames per second).

There’s a way to make things run faster. The browser has its own stack/storage for instructions called webapi, and there’s a secondary storage area called the task/callback queue. A programmer can help out by placing a function (or subroutine) within an instruction called setTimeout, which says wait a certain number of milliseconds (at minimum, it can take longer) before running this instruction. In addition, if a programmer knows that something will take a while, the code can be placed within a setTimeout of zero, which means essentially to hold the code until the stack is clear (and then run it).

The structure, then, is this: there’s a stack running the code (instructions). There’s a browser stack called webapi which holds code that is to be run later. There is another intermediate holding area called the task/callback queue. The stack is taking code and running it. The webapi holds code for a certain amount of time, and then places that code into the callback queue. A mechanism called the event loop checks the stack, and if the stack is empty, it places the item in the callback queue into the stack so that it can be run. (Items can also be placed in the callback queue directly for holding until the stack is empty.)

Essentially, we have webapi – – > callback queue – – > event loop – – >stack.

The goal of the programmer is not to “block the event loop” with code that takes a (relatively) long time to run, but to allow the faster instructions to go into the stack, and the more complex instructions to go into the callback queue or webapi to wait and run when the stack is clear.

This produces a web page which loads and responds quickly.

Reflections on the Third Week at The Iron Yard

We continued to learn JavaScript in week 3, focusing on functionality and constructing our own libraries of functions. We also got an introduction on how to place JavaScript on a web page so that the results of the code show up. There was also some review on html and css; I was particularly interested in constructing buttons. On Friday, we had an exercise in which we set up a web page using html and css (which we hadn’t used significantly since week one) from a diagram. The web page I made was less sophisticated than I had hoped for, but this is something I can work on in the coming weeks.

I got another chance to present my code to the class for discussion. We also worked on some team projects, and I’ve been impressed with the results from collaboration.

We were introduced to prototypes in JavaScript, which didn’t make sense to me until Jim went over one of the exercises, and I realized that prototypes are a way to associate a function with an object. It’s generally easier and more effective for me to understand an aspect of code when it is put into practice, beyond just reading about it.

I anticipate even more progress in the upcoming weeks.

Reflections on the second week at The Iron Yard

During week 2 we worked on JavaScript. I was glad that I went through the JavaScript exercises at Codecademy before class started, because we quickly went through the basics and into the more complex aspects of the programming language. If I had not already had experience with those basics, I might have felt lost.

We continued to read each other’s code, which was useful in that we were able to see that, in general, there are different ways for the code to accomplish the same task. Sometimes we paired up to compare methods; other times someone would get up in front of the class to show the code they had written and invite comments. I was able to do this earlier in the week.

On Friday, some of our assigned tasks involved using one function to call another. A particularly complicated assignment required us to write a function where one of the arguments was another function (referred to as a callback). This initially posed a dilemma for me, since I could not see how this could work unless I was able to add functionally within the callback—and, as it turned out, that’s what needed to be done and was actually possible, though not easy.

Along with this we covered “best practices” of coding, as well as the reasons why one style of coding might result in fewer problems than another style. In addition, we continued to learn more programming tools and techniques.

Overall, this continues to be a satisfying learning experience. It is intensive, but the intensity seems to give the tasks focus. Looking forward to seeing what’s next!

Reflections on the first week at The Iron Yard

It’s the end of my first week at The Iron Yard code school. The first week was learning and applying code in HTML and CSS, as well as acquiring and learning to use a set of programming tools. Jim (@JimTheDev) is an excellent instructor: knowledgeable, patient, and upbeat. The environment is fast-paced without being frantic, though the result has been that when I turn in my work for evaluation, I tend to think that I could have done better if I had more time. However, Jim said, and I agree, that in real-world programming, one has to do one’s best in the time frame one has.

 

Another point Jim made was the value of repetition: performing tasks often until they become second nature. In this way, I’ve managed to learn the basics of the command line fairly well.

 

Manuals are great for reference, and I prefer to have one around—although, for me, lasting learning has come from applying the code, and to that end, we (the entire class) are getting lots of practice. In my experience, this is the fun of coding, and the time passes pleasantly. However, I’m learning the code and the essentials on how to operate a MacBook Pro and how to inspect a website and so forth, at the same time, which makes the process more time-consuming. I expect that learning the tools and the hardware will take proportionally less time as the course continues.

 

GitHub was introduced to me as a way to collaborate on code. Right now, though, I’m appreciating it as a way to back up and preserve my code for my own reference.

 

Overall, it’s been a fun and challenging week.

HTML vs. HTML plus CSS

The first websites I built were using html only. They were functional, but not sophisticated. It wasn’t until I started using software which converted a page of text and graphics to html, and later, WordPress, that I was able to build websites that had anything beyond basic functionality.

 

CSS (and SASS) is what helps give a website structure and better functionality. The box model, in particular, defines the page. Additional CSS selectors can define characteristics such as line height, fonts, letter sizes, and so forth. These selectors can apply to just one line, to a section of the web page, or the entire web page. Other selectors can be used to structure menus and drop-down menus. The variety and versatility of choices means a wide variety of web formats can be built.

 

I went over 26 sections at atozcss.com in an afternoon. I would have found them even more helpful had I known about this site before starting code school, because then I could have taken the time to go over the material in more depth, and perhaps test out some sections of code. Showing the code alongside how a web page featuring the code appeared would have been even more useful, in that I could have seen the one-to-one correspondence between the code and the page appearance.

 

Nonetheless, I have noted the atozcss.com site for future reference, and may find myself referring to it.

Changing Computer Programming Practices

Some observations in learning a computer language for the first time: the internet (as it is known today) was not around when I was introduced to computer programming languages (BASIC, FORTRAN, assembler, etc.). The instruction was primarily in a classroom, using a manual (textbook), followed by assignments where we were asked to write a program to [fill in the blank]. This is the way I prefer to learn anything new (not limited to computer languages). I remember once I got a job where I was taught assembler language through watching videotapes, and didn’t get much out of it. To supplement that, I took night classes in the language, where I learned much more. I find I get far better results from interaction with an instructor and from the use of a written text.

That’s not to say that I don’t get anything from online learning. The Codecademy courses (css, Javascript), were very instructive, and I find that I can interpret code written in those languages fairly well, now that I have completed those exercises. One item I noticed was the vertical organization. In my previous education as a computer programmer, we wrote FORTRAN (for instance) horizontally, though we still used indents to group related items.

The languages themselves retain essentially the same functionality: loops, arrays, and so forth. Javascript reminds me of FORTRAN. The command line codes remind me of the more recent MS-DOS. GIT is different: while I recognize the principle behind it, and realize that it serves a useful function, the commands are not intuitively obvious to me at this point, though I expect that I will become accustomed to them with use.

Learning coding without the use of a manual is also a challenging experience. When I first learned computer programming, if I had a question, I’d either consult the manual, or ask the instructor or the instructor’s assistant. When I was on the job as a programmer, though I could ask my co-workers or my supervisor (and sometimes did), I most often consulted the manual (generally, I knew what I wanted to do, I just needed to find the optimal operation to accomplish the task). In the past year, however, I have found that Google can often answer a coding problem or question, and that it routinely consults message boards where users post their problems and get responses from other users. I have to admit I found it amusing that someone asking a simplistic question can get an answer in an acronym meaning “have you consulted [censored] Google!?!?!” (Or was it “have you [censored] consulted Google!?!?”)

Most of all, I’m impressed by the depth and complexity of the code, which offers a deliciously wide range of options. I’m looking forward to putting all that into practice.

The computer programming experience: learning and application

I have taken computer programming courses before (in programming theory and also in languages such as FORTRAN and assembler language), and I have worked as a computer programmer, so I have had experience in writing, testing, and modifying code.

I’ve found that a flexible attitude (or what author Carol S. Dweck calls a “growth mindset” in her book, Mindset) is an asset in learning and applying coding skills. My experience is that code that reads well does not always perform well; it does not always perform as expected. When that happens, I don’t take it personally or as a failure on my part; I simply go back to the code and see what sort of adjustments need to be made.

This is not to say that the experience is not extremely frustrating; it is. Looking at a section of code for what seems to be hours for a missing parenthesis or misplaced semicolon can be aggravating. Not getting the expected result can be discouraging. This is pretty much inevitable when taking a programming class. When that happens, my plan is to pause, reflect, take a breath, analyze the problem, and where needed, get other ideas on what might be causing the difficulty.

Most of all, I’ve found that, eventually, I can get the code to do what it needs to do. It just takes time, patience, and flexibility.