Real World Web Development

Since I graduated from The Iron Yard, I’ve turned my attention to my own websites, of which I have several, to rewrite them and improve them. As I anticipated, real world experience is a little different than the experience in the classroom.

I’ve started with 2 sites: a site promoting me as a web developer/social media expert/video provider at, and an informational site featuring my healthy living books at

I wasn’t far along in developing these sites when I realized I would have to learn some additional skills in coding: working with social media widgets, for instance. But, I knew enough to realize I needed to find the developer’s area of Facebook, Twitter, etc. to get the code that I needed to put a social media widget or badge on a website. Once there, I needed to select the options I needed, and modify the code for the website, and again, the concepts I learned in class helped me to get everything working. In some cases, the process was fairly clear. In others, I had to search through the developer part of the site before I found the code or the combination thereof to use. I got one widget working in a timely manner. Another didn’t work, so I had to keep going back until I found a section that had code that worked for me. Yet another time, I kept getting error messages which did not make sense. So I did what I remembered hearing in class: I copied and pasted the error message right into Google, and immediately Stack Overflow said that the code wouldn’t work in a simulator, or even localhost…it would only work on a live web page. And indeed, that’s what did work.

I found some curious omissions, such as getting error messages because of the absence of “http” in the code for an “src=”…when I inserted the “http” it worked, but I wonder why it was missing in the first place.

Some code worked…and then it didn’t…and then it did…and then it didn’t. Same code.
Also, as I mentioned earlier in this blog, the documentation for these and other items was sometimes frustratingly obscure. Again, I learned enough in class to eventually determine what was going on by myself, but I can definitely see how, when I was just starting my classwork, I was not able to grasp some of the coding concepts explained in online documentation right away. They definitely presume that the reader knows things that a novice may not, in fact, know.

In spite of these obstacles, I got the 2 websites working satisfactorily. (I even successfully added a favicon and web counter to each site!) Now to see whether I can get my other websites updated as well.

Be Sociable, Share!

Writing Code, Writing Stories

I’m probably not the first to notice that writing code is very similar to writing stories. There is structure and creativity involved. There’s writing the first draft, editing the draft, and then publishing the result for the public to view. There can be second/revised editions. There can be collaborations. Reviewers check and comment on the published result.

In particular, I’ve noticed that when I write a story, and think it’s complete, I still wait before sending it off or publishing it, because in the following days or week, I will get additional ideas on what to add, delete, or change. This has also happened with my code: I thought my “Demo Day” project was complete, but after a couple of days, I got additional ideas for improvements.

There’s definitely a similar feeling of accomplishment and satisfaction upon publication of either code or prose. The sense of fun in building also applies to both activities.

It’s hard to select a preference for one or the other; I think I’ll continue happily doing both.

Be Sociable, Share!

Week 12 at The Iron Yard…end of class, but not the end of learning

IronYard-certificateI have now completed week 12 at The Iron Yard and have the certificate to prove it! Week 12 was another week of intensive learning. I completed an online portfolio, and in the process learned more about CSS styling as well as responsive design (and media queries). I made more pages based on the Open Weather API: one page which gives current weather conditions when the user inputs a city name or zip code, and one page which gives a 7-day forecast when the user inputs a city name or zip code.

My demo project is now live on the web. This proved to be a more complex process than I had anticipated, and I learned that there is a significant difference between a web page that simply displays data and a web page that accesses storage on a server.

I have always thought that coding was fun, and this class was a lot of fun…and a lot of work (and I’d do it all again if it could!). I’d highly recommend The Iron Yard to anyone who wants to learn coding, and highly recommend Jim as a Front End instructor. I’ll miss seeing my classmates daily, though there will be opportunities to see them again, especially since our Demo Day is later this month.

My plans are to start a job search, and to work on even more projects. I particularly wish to find out more about jQuery and about CSS animation. I expect that my GitHub repository record will remain active.

I also hope to speak to future Iron Yard classes and meetups to share all the fun I’ve had!

Be Sociable, Share!

The Goal of Web Development

myAPODLately, I’ve been constructing web pages for my online portfolio and for display on my own domains. One of the web pages I have made (this was the result of a class assignment, and it was a page that I wanted to make for myself) is the Astronomy Picture of the Day from the NASA API. (For those not familiar with APIs, they’re databases an entity keeps and allows others to access and use through a key). I made and styled my own Astronomy Picture of the Day and compared it with NASA’s. NASA’s is larger and has a lot of links and added information. It’s great for those who want links and added information, but to me, the appearance is “busy.”  I styled my own Astronomy Picture of the Day (which NASA encourages the use of its API for – essentially, they tell web developers such as myself, “go ahead and make your own Astronomy Picture of the Day using our data.”), and I find it much more to my taste. I’m now checking my version daily.

Similarly, I made and styled my own weather app from the Open Weather API (the Open myweatherWeather API essentially says, “go ahead and make your own weather report using our data”). I realize there are a number of weather apps out there that users can customize to their personal tastes, but this is my very own weather app that I specifically styled to my own personal tastes and I am happy with it.

It occurred to me that this is the goal of coding (or more specifically, front end web development): to make applications/web pages that present users with the information they want in the style they prefer. I find this both challenging and exciting, and is one of the reasons I find coding so much fun.

Be Sociable, Share!

Week 11 at The Iron Yard

My project for Demo Day was nearing completion this week. I made the pages responsive, mostly with the use of the Aphrodite library. I also added a “print” button to the main directory page. Right now all that I may need to add are more test entries and perhaps some minor styling changes.

With the Demo Day project well on its way to completion, I spent time this week learning additional skills by working on additional projects. I built an online portfolio, with screen captures of projects I have completed, and links to both the code on GitHub and to the working web pages. The portfolio page also contains a summary of what I’ve learned at The Iron Yard.

I felt a great sense of accomplishment on Thursday when the API call that I sent to the Open Weather API worked on the first try. I spent most of the rest of the day on Friday building my own weather app, which I’ve wanted to do ever since The Iron Yard Crash Course I attended before starting week 1.

Our campus director started talking about job seeking skills this week, which was most welcome. She invited us to find three job listings for web developers, and I was pleasantly surprised to find four that I felt I was qualified for.

Next week is week 12…even more learning to come!

Be Sociable, Share!

Week 10 at The Iron Yard

This week I started my project for Demo Day and worked on it for most of the week. I was very pleased with the progress I made this week, and even more pleased with the fact that I was learning more ways to use JavaScript and ReactJS to build a web page. For example, I wanted to make a list from a string where the entries were separated by carriage returns. The method I first tried resulted in error messages. So I searched on Google for a technique that would work and was directed to, where I found an example that was similar to what I wanted to do. In particular, it suggested that the method be placed between the render and the return, instead of within the return. I did and it worked. I have searched Google for information on other techniques I have wanted to use, and have found it (and, among other online resources) to be helpful. I’ve also been using Trello to keep track of the features that I want to include and my progress on those features (those not started yet, those in progress, and those which have been completed).

I also made more progress on preparing an online “portfolio” of my work. I have three projects in place and visible (a chat function, an API call to the omdb media database, and a “guess a number” game), but need a unifying home page. That’s still in the beginning stages, but taking shape.

Our class took a field trip to Best Buy headquarters to talk to the web developers there. They gave us a tour and answered our questions. It was informative to learn about what sort of work they do, and what sort of knowledge and skills are required in their jobs. They’ve offered a place there for our Demo Day in September.

Continuing work on the Demo Day project next week. Still having fun!

Be Sociable, Share!

Week 9 at The Iron Yard

The week started out on Sunday when I took a look at some code that Jim had introduced to us about a month ago. At the time, I had only a vague idea of what the code was for and how it worked. Now I realized that I understood it fairly thoroughly. (Progress!)

Early this week, we all worked on getting our chat functions working with Horizon, placing data on a web page for retrieval. Wednesday we had a lecture on Java (even though our course is front end web development) so that we would have an idea of what it was about and what it did. Thursday, our class voted to have Jim go over APIs and jQuery (he included Bootstrap as a bonus), all of which was very useful. For the afternoon lab session, we were asked to develop code to get data from an API with  jQuery, and at the end of class I was feeling discouraged because I had been unable to make a successful connection to the server. After a brief discussion on Slack in the evening, I was back on track on Friday and made a successful API retrieval using jQuery. Not only that, but I felt I understood the jQuery code clearly.

I have been going over previous assignments and improving the code and functionality in preparation for building an online “portfolio” of my work. I am very pleased with myself for taking code that I wrote only 2 weeks ago and making significant improvements to the style, functionality, and sophistication. Friday afternoon, Jim went over with me how to place that code on one of my web pages to start the online portfolio.

Friday morning we also went over my project for the upcoming “Demo Day” in detail, mostly diagramming it on the board.  Working on this will, I expect, take up a significant part of the next 3 weeks. I feel excited about getting started with it.

Be Sociable, Share!

Week 8 at The Iron Yard

We continued our work in React JavaScript this week, with an introduction to Horizon and RethinkDB to facilitate placing data on a web page. Our exercise this week was to develop a chat application. At the end of class on Tuesday, I was feeling discouraged because I had worked all afternoon and not made much progress with the code. However, by the end of class Wednesday, I was making significant progress, and on Thursday I was seeing satisfactory results.

There are still some subtleties in the code that I am working to grasp. However, I realized that while I may not understand everything completely at this point, I am gaining more familiarity with the code the more I work with it.

I also had some difficulties uploading code to GitHub; again, because of not realizing the ways that GitHub handles uploaded files. Fortunately, Jim (our instructor) was able to suggest the appropriate instructions to get things working again.

I also discussed my idea for my project for “Demo Day” with Jim, and was able to define some realistic goals.

Jim says one more week of lecture, and then we begin work on our graduation projects for “Demo Day.” This promises to be exciting.

Be Sociable, Share!

Week 7 at The Iron Yard

We continued our work on React this week. Our activities included splitting our previously written JavaScript code (in earlier assignments) into Component modules, and learning web navigation using the Router tag. We also learned how to set up scripts to install webpack functionality, and how to reference fonts within React components. I’m impressed with the results of our coding exercises: we are building more and more sophisticated web pages.

When discussing our progress for the week, one of my fellow students remarked that the times when we think, “Oh, yes, we’re getting this” are often accompanied by thoughts of, “oh, no, this is really hard and will we ever understand this?” Certainly I have felt this way, though I know from past coding experience that eventually, yes, I will understand this, and having moments when I wonder if I ever will are part of the process (though undoubtedly frustrating at the time).

In any event, looking forward to seeing what we can build next week.

Be Sociable, Share!

Halfway There: Week Six at The Iron Yard

This week we worked on React, which is a JavaScript subset (or library) that makes coding applications more concise. In particular, it facilitates output to the web page (and input from the web page). At this stage, React seems more complex than the JavaScript it is based upon; however, as with most code, I presume this is just a matter of getting used to it.

During the week, we had a group exercise, which was enlightening not only due to the fact that working together helped us reached a result a bit faster than we might have done individually, but also because it demonstrated that those of us in the class are all pretty much at the same level in feeling challenged by the code. We are also all open to seeking out different ways of understanding and building the code, and sharing that information.

We also celebrated the fact that we’ve completed week six – halfway through the course – and took a class picture.

Left to right: Tim, Hunter, Alec, Joan, Eric

Left to right: Tim, Hunter, Alec, Joan, Eric

Be Sociable, Share!

Star Trek Beyond review (2016)

The 50th Anniversary of Star Trek would not have been the same without an addition to the Trek universe, and Star Trek Beyond is a solid performance. It’s not the best, it’s not the worst, but it does have a lot to recommend it. (And yes, spoilers follow. Stop now if you don’t wish to see any.)

Early in the movie, Kirk and Spock are shown having second thoughts of continuing the five-year mission (it’s year three). Kirk wonders if he can live up to his father’s reputation; Spock learns of Ambassdor Spock’s death and wonders if he should continue his work on New Vulcan. The Enterprise visits a city in space called Yorktown (a spectacular special effect) and is assigned to assist a ship captain who has asked for help to get her crew back. However, this turns out to be a trap: the Enterprise is destroyed and the crew is stranded on a planet. Scott quickly encounters an ally (Jaylah), Kirk and Chekov try to get to the crashed saucer section to get technological assistance, Spock and McCoy try to find the others, Sulu and Uhura and the remainder of the crew are detained by Krall, who has a grudge against the Federation. The rest of the film finds the crew resisting Krall and preventing him from destroying the space city and its millions of inhabitants. (This involves finding and restoring an old starship which had crashed on the planet over a century before. The seatbelts on the bridge were welcome and needed in the escape. They also, interestingly, found a strategic use for music radio.)

The film has interesting references to events that had happened in previous Treks (particularly original Trek and Enterprise)—though Simon Pegg (a co-writer) seems to have forgotten about the Vulcan healing trance. The special effects are outstanding (particularly the space city and the Enterprise traveling through space at warp speed, which is brief but breathtaking). All of the the regulars have significant roles in resolving the issue, which makes Anton Yelchin’s loss keenly felt (the credits have an acknowledgement of him). I thought his Chekov was extremely well portrayed, both in the 2009 film and in this one.

Most of all, I was happy to see that Roddenberry’s overall Trek philosophy of Starfleet (and the Federation) as a representation of peaceful exploration (and not of war) was emphasized, and the point was made that resilience and strength can be developed without conflict. At the end, each member of the crew takes a line of “Space, the final frontier…,” and Uhura’s (Zoe Saldana’s) recitation of “to boldly go where no one has gone before” moved me to tears (it was wonderful!).

Let’s hope that the next film (already scheduled) does at least as well.

P.S. Though I’m standing in front of an IMAX poster for Star Trek: Beyond, I saw it in 3D. (Not because I wanted to, but because 3D was the only choice at the time I wanted to see it.)

P.P.S. Before the movie, the theater showed a brief clip of Simon Pegg (Scotty) thanking the audience for coming to see the film in a movie theater (as opposed to waiting until it was available on cable, DVD, or NetFlix, I suppose).


Be Sociable, Share!

Web Documentation: Week Five at the Iron Yard

This week we had guest speakers. On Monday, the speaker covered the work environment for a developer (writing code for the web). Tuesday and Wednesday the speakers covered features of es6 (a 2015 update of JavaScript). Thursday the speaker covered debugging JavaScript code.

This week, a particular challenge I had was to place the code for an input box in the html file (and thus on the web page), capture the value entered into it on the web page, and transfer that value into JavaScript for processing. I spent hours (literally) searching the web for a procedure that would do it. I would follow the instructions and get error messages. I would repeatedly see comments saying “just do this” or “this would do it,” but they didn’t work, and the meaning was not clear to me. After numerous failures, I finally tried some simple input and capture code, as best as I could understand it. With the help of a classmate, Hunter Hawes, I finally got it working.

Here’s the process in brief:

In the html file, the following code places an input box with a submit button next to it on the web page. After the user enters data in that box and the user clicks on the submit button, the data is placed in the variable “number” and the function GuessNumber in the JavaScript file is called and run:

Enter number: <input type=”text” name=”number”>
<input type=”button” onClick=”GuessNumber()” value=”Submit”>

..which shows on the web page as:

Enter number:


In the JavaScript file, document.querySelector puts the value entered in the box on the web page (stored in the variable “number” from “input’) into the variable mybutton:

var mybutton = document.querySelector(“input”).value

..and one can proceed from there. Why this concept was nowhere explained in clear and concise language in the sites I visited is a mystery to me. I’m finding a lot of the coding documentation on the web is not well-written or clearly explained. It appears that a number of contributors may be proficient at writing code, but less proficient in writing explanatory prose. This can become a problem when researching information.

P.S. A direct, one-line JavaScript capture code does exist:

var guess = prompt(“Input number between 1 and 100”);

where guess captures the data entered into a pop-up box on the web page which is labeled “Input number between 1 and 100.” However, most users prefer to avoid a pop-up box, and there are other disadvantages as well. It will get the job done, but may not be the most efficient way to gather information on a web page.

Be Sociable, Share!

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

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:

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:

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:

Be Sociable, Share!

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

Be Sociable, Share!

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.

Be Sociable, Share!

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.

Be Sociable, Share!

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!

Be Sociable, Share!

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.

Be Sociable, Share!

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 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 site for future reference, and may find myself referring to it.

Be Sociable, Share!

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.

Be Sociable, Share!