Category Archives: Web development

Montana Code School–Week Four

Our class had its first marathon weekend this past weekend, the first of six. We spent all day Saturday and Sunday as a class working on coding projects. Given their intensity, I’m glad these sessions are only held once per month. But it’s helpful to have some extended time to work on projects since our three-hour weekday classes just seem to whiz by.

Mob and Pair Programming

We’ve been spending a lot of time in class working in pairs and groups. The instructors introduced pair programming and mob programming to us in the first week of class, but now that we’ve been starting projects we get to put these ideas into practice. In pair programming, a technique associated with Agile software development, two people sit together and work at one computer. One person serves as the “driver,” the other as “navigator. ” The navigator sits to the side and helps by talking through the ideas that could get turned into code. Her role is strategic and keeps the pair connected to the program’s “big picture.” The driver sits at the keyboard and does the actual typing. His role is tactical as he figures out how to turn the ideas into actual code. Every so often the two rotate so the driver gets to navigate and vice versa. Mob programming is similar to pair programming, except that there are four or five people instead of two, and the team may be sitting around one or two larger computer monitors. All teammates rotate through the driver and navigator roles, switching roles every 15 minutes or so.

I confess that before being introduced to pair and mob programming techniques, if you were to have mentioned computer programming to me, I would have immediately thought of the solitary guy in his bedroom cranking out code. Having grown up in the 80s, that guy would look a lot like Matthew Broderick in War Games or Anthony Michael Hall in Weird Science. While coders still often work alone, pair and mob programming techniques do a lot to turn programming into a collaborative endeavor. Programming with others has additional advantages. The code produced by pairs or teams is usually of higher quality. Navigators have to make others understand their ideas before they can be programmed which leads to better communication and more accurate code. Drivers have teammates who can check for typing mistakes and syntax errors. Team members also report greater job satisfaction when pair or mob programming is used. The diversity of experience that is brought to pair or mob programming enables greater creativity too. For this reason, mob programming has been found to be especially valuable in the early stages of project development when the need to generate lots of ideas is greatest. These cooperative arrangements are ideal for coding novices. By watching and learning from experienced coders, beginning programmers can be incorporated into the programmers’ “community of practice” while contributing to work on real projects.

Not all situations call for group coding. Although it promises higher quality code, group coding is more labor intensive. The amount of code produced per person is less, which increases labor costs. When all the programmers are familiar with the software, as with an application that has already been in production for a while and where the main goal is program maintenance rather than idea generation, group coding is less advantageous. Experienced coders may also become impatient and domineering when paired with novices unless they are made to understand the benefits of coding in groups. Nevertheless, for those like me who may have veered away from coding because of the “lone wolf” stereotype, knowing that independent work can be combined with more cooperative modes makes the possibility of working in tech all the more enticing.

JavaScript libraries: jQuery and P5.js

One of the projects we worked on over the marathon weekend was a simple “to-do list” web application. For this app we had to work with basic structural and form elements in HTML so that users could add tasks to the to-do list. Additionally, we had to add CSS to style the page and make it look pretty. Then we had to work a bit with jQuery, a JavaScript library, to make the page more interactive. Most of our time was spent trying to figure out how to create balloons and have them release when someone checked off a completed task on the to-do list. To make the balloon shape we worked with a different JavaScript library called P5.js.

A JavaScript library is a collection of pre-written code that makes working with JavaScript easier. When using JavaScript libraries you aren’t always reinventing the wheel each time you write a new program since some of the base code has been written for you. P5.js, for example, allows you to jump in and use JavaScript easily to create dynamic shapes and designs. jQuery is one of the more popular JavaScript libraries because it makes working with the DOM—Document Object Model—more efficient. Since the HTML structure and CSS styling of a web page are essentially static, if you want to make the web page interactive or to include animations, you need a way to manipulate the HTML and CSS without permanently changing it. Since the DOM is a representation of the HTML document, you can work with DOM elements and create temporary changes to the HTML and CSS without altering the original files. For example, if you had a button on your web page that you wanted to turn from black to orange and to expand in size when you clicked on it, you would target the button element in the DOM rather than in the HTML file. Then you could program a JavaScript “event” that would be associated with that button element in the DOM and that would result in the button turning from black to orange and expanding in size when the button on the web page was clicked. In this case, the original HTML and CSS remain the same and the change in color and styling is only temporary. If you were to refresh your web page the button would go back to its original size and color.

While you can use HTML to target the DOM, using jQuery makes for a cleaner and simpler process. jQuery scripts, since they are based on JavaScript, can be kept in the project’s JavaScript file, allowing you to keep your programming of dynamic events separate from the static structures and style definitions in the HTML and CSS files. As opposed to JavaScript itself, jQuery works quite nicely across different web browsers so no matter which web browser your user has likely there won’t be any problems running your jQuery scripts.

After a lot of work, our group got our balloon-themed to-do app running quite nicely with a thousand balloons released each time a user checks an item off the to-do list.  No one is going to use our app for actually tracking completed tasks (the app’s a bit too basic for that), but we had a lot of fun inventing tasks and crossing them off just to release all the balloons.

For a look at our balloon-filled To-Do app, click here.

For additional reading on Mob programming:

 

Montana Code School–Week One

Just as I was finishing my last post, I decided to turn in an application to the Montana Code School to see what happened. Once I submitted the short, online application (which was handled by Submittable – a Missoula tech company!), I went back and took another look around the Montana Code School website and realized that they had a part-time bootcamp scheduled to begin right away, as in the following week! Within a half-day of submitting the application I received a phone call from the school director wanting to set up an interview. So I went in for the interview on Friday and heard later that day that I’d been accepted to the part-time program.

While I’d been thinking of doing some kind of coding bootcamp, I wasn’t exactly prepared to act on the idea quite so quickly. I decided to jump on the opportunity for several reasons. For one, the price, while still significant, was much better than the online course I was considering. The timing also was good—I’d get to start on it right away and since it was part-time I could work on other projects at the same time. Possibly more importantly I’d be able to work with local classmates and get the support of the local tech sector through networking and other events. Since I’m only freelancing and doing odd jobs at the moment, I haven’t been as connected to the Missoula professional scene as I have wanted to be. I’m hoping that doing the code school will help in this regard.

Pre-work

At the same time the school sent the acceptance letter, they also sent a list of “pre-work” that they asked I complete. Probably about 40 hours of work altogether. Most students who had enrolled earlier than I had had already been working on it and were expected to have it finished by the first day of class. Since I wouldn’t get it all done before the first Tuesday, they said I’d be a bit behind for the first couple of weeks while I finished it but encouraged me to hang in there. The “pre-work” consisted primarily of a few online tutorials, mainly on the basics of Javascript, HTML and CSS, but mostly Javascript since it’s more complicated to understand than the other two. Javascript, as I learned, is a programming language used heavily in front-end (user-side) web development, though apparently it has some back-end uses too. Since it loads right into the user’s web browser, the user’s computer doesn’t have to continually call information from a remote server every time it wants to execute a Javascript function. This apparently cuts down on the wait time especially for certain complex web actions like animations.

image of compter and server interaction

How the HTML, CSS and Javascript code gets to your web browser.

Tuesday

The class meets regularly in a room at MonTEC (Montana Technology Enterprise Center), an office building which houses a number of local tech companies and startups. There are about 11 students in the class, many working full-time already and doing the boot-camp on the side. The first part of class was spent both on introductions and on going over some of the productivity methods that get used frequently in web development and that we’ll be using in the class, such as Kanban and Agile. We were then given a stack of sticky notes and asked to write down our “goals” “values” and “resources” as they related to the bootcamp. It was clear from some of the responses, especially for “values” and “resources,” that people were both excited and anxious about the learning ahead. A number of the “goals” that people stated were to be expected: earn more money, have a more meaningful work life, be creative. Others’ reasons were a bit more surprising initially, but made sense. One person mentioned the desire to combine tech with social justice. Amita, the school director, then mentioned that this was a reason more women are getting into tech. As an aside: I think this is actually key. If more people think first of what kinds of questions they can solve or explore through programming, they might be more interested in seeing coding not as an end in itself but as a means to other ends.

Our assignment for Thursday was to start creating a website with the HTML and CSS we had learned so far.

Thursday

Austin, our instructor, introduced GitHub, the command line and then had us continue work on our basic websites. I’ve known about the command line (Terminal on macs) for a while, but it’s always been super intimidating and I’ve been convinced I’m going to break something or lose something if I use it. Apparently there are a lot of advantages to getting used to the command line though, such as saving time when navigating through your folders and files. It’s also how Austin wants us to “push” our work to GitHub. I’m still scared of the command line, but now that I know a few commands it’s a bit more accessible. One thing you probably don’t want to do from a command line is to remove something. Unlike dragging it to the trash on your desktop, removing a file in the terminal will probably delete it permanently—as in forever. Scary.

I’d played around with GitHub for a short time before the class started, but found the workflow hard to grasp. Basically, GitHub is an online repository for coding projects. That is, it’s a kind of cloud storage for your project files, but also serves as a version control platform. Every time you make changes to your files on your home computer and then “commit” and “push” those changes to the repository in GitHub, it stores a version of those changes that you (or others) can later access. It’s useful if you make a change that results in your code “breaking” (a.k.a “not working”). You can go back to an earlier version to help identify which changes were responsible for the code breaking. It’s going to take me some time to get used to GitHub, but I can see where it can be super useful, especially for collaboration.

Career Change + Coding

When I started this blog I said I would share my experiences and learning about instructional design as a career field.   I also promised to tell about my own career transition with the hope that something in my experience might be helpful to others. In the end, it may be this latter goal that becomes the more significant one. In the two months or so that I’ve been looking into the instructional design field my thinking has already shifted, both in terms of my understanding of the field as a whole and of how I want to position myself within it. Since the ending to this career transition story isn’t written yet, it’s entirely possible that instructional design is not the area I want to move into. Only time and more experience and research will tell. Consequently, I think it will be instructive, both for me and for my readers, to explicitly reflect on my learning process from time to time. And so with this in mind, let me tell you about my current adventure! This will be a story without an ending (at least not yet) as it is still unfolding. But before I begin recounting my current saga, I have to take us back in time a little bit.

Exploring Web Development

I first thought about moving into the instructional design field back when I was still employed at the University of Arizona. I had been using the Desire2Learn learning management system (LMS) heavily for my courses, was experimenting with “clickers” (Classroom Response Systems) and was getting some exposure to the technologies in use in higher ed. Mostly, though, I was not a techie. I’d never coded, never played or been interested in gaming, and didn’t really know the first thing about digital technologies. Outside of what I was doing for my classes, the closest I’d come to working in the digital space was creating a couple of WordPress travel blogs (you can see them here and here) and playing with my iPhone. When it became clear I wouldn’t be staying in my faculty position (a blog post for another day), I started reflecting on my options. I figured it couldn’t hurt to have some technical knowledge regardless of my ultimate path, so I looked online for some free resources to help me learn more about HTML (Hypertext Markup Language) and CSS (Cascading Style Sheets). I found Codecademy and started working through its HTML tutorial. I didn’t get very far into it when I got offered and then accepted a job teaching high school in China. With an overseas move on the horizon, I put off learning more about web development.

Flash forward to this past summer. My high school teaching contract was up and I decided to come back to live stateside. For personal reasons I’ve ended up in Missoula, Montana and have decided to make a go of it here one way or another.   After another side excursion into educational consulting (another blog post for another day), I have come back to the idea of teaching and learning, and especially instructional design and educational technology. Given my self-imposed geographical restrictions, I thought working in edtech would both allow me to remain connected to education and be something I could work on remotely if needed. I’ve also always loved planning and design work. Developing courses, planning and writing curricula and creating learning activities have been the aspects of teaching I’ve always had a passion for, so I thought some kind of edtech development work might be a good fit for me.

To learn more about instructional design and digital learning I set up a couple of informational interviews, both with professionals involved in online learning in higher ed. From them, and then subsequently from reading websites like O*Net Online, it’s become clear that I’m not going to get very far without some background in multimedia production and/or web design. And so I’ve been investigating several different learning options to see which might work best for me in my current situation. So far I’ve narrowed it down to three different paths: studying on my own with books and websites, taking a class or two in Media Arts at the University of Montana, enrolling in an online coding bootcamp like Bloc, or attending a residential coding bootcamp like Montana Code School. I still haven’t made a decision about which of these to choose, though at the moment I’m leaning toward just self-study with some media arts classes or an online coding camp. While a residential camp isn’t off the table, it would have to be Montana Code School since I’m not willing to move for it. The costs associated with relocation added to the cost of a coding bootcamp make the whole thing prohibitive, at least for me. Independent study, while certainly the least expensive option in the short-term, has its drawbacks. Not yet having a technical background or many contacts in the tech industry, I do worry about getting the kind of mentorship that I need. Finding good mentors was always a challenging proposition, yet I’ve learned the hard way that mentoring is crucial to getting you where you want to go. It also ties in with what I’ve learned about collaborative learning and communities of practice in the Coursera eLearning Ecologies class I’ve been taking. While I’m sure I could learn quite a bit just by reading on my own and building my own projects, I think I will need someone I can ask questions of, who can critique my work and who can give me an insider’s perspective on the web development industry. Mainly for this reason I’m thinking hard about online coding bootcamps. I’m especially interested in Bloc because it offers a special designer track where I could get training in both user experience (UX/UI) design processes and applications and some front-end development (the user side of the web). But I’m also trying to talk to a few people I know in the tech world to see whether they think it is worth the money since, like other bootcamps, “they ain’t cheap.” In the meantime I’m starting my own self-study program with books and websites. Even if I decide to do a camp, I’ll still do my own reading and investigation. So you can look forward to future blog posts from me that provide more detail on my web design learning! If anybody has any experience with coding bootcamps, especially the online ones, please leave a comment and tell me about your experience.