Oregon State University online CS degree eCampus program review and recap

In this article: my review of Oregon State University’s online post-bacc CS degree program, which I attended for 3.5 years, starting in September 2016 and finishing in June 2020, completing 15 courses with a 3.9 GPA and graduating with my second bachelor’s degree, a Bachelor of Science in Computer Science.

Yay! Being done is a great feeling. Pictured: my new diploma surrounded by the books, notes, and worksheets that were my BFFs during this program.

First, I’ll answer the most frequently asked questions I was asked while in the program:

  1. Yes, the program is completely online – the coursework is unlocked weekly in the online portal known as “Canvas”, you take tests online with a proctor supervising you over webcam the whole time, you submit coursework and get your grades online
  2. No, it is not self-paced – quarters are 10 weeks long, deadlines are firm barring exceptional circumstances (I never pursued an extension but they exist for those who can justify the need for one)
  3. But you can vary your pace through the program, such as taking 1 class a quarter to go at a slower pace and leave more time for the rest of your life, or taking 2-3 classes a quarter to get through the program faster (more thoughts on class pairings later in this article)
  4. You can take quarters off – I took a few quarters off here and there for things such as moving cross country and having a baby
  5. Yes, you have to already have a bachelor’s in some unrelated field – it’s a “post-bacc” program, so your first degree entitles you to skip all the gen-ed classes you’d normally need to do
  6. It’s still a normal bachelor’s degree on paper and the degree does not call out the “online” nature of the program in any way (you can see the diploma I received at the top of this article)
  7. Yes, there is a decent degree of “self teaching” in the program – at a high level, the courses give you problems to solve and they usually provide lectures and readings to guide your learning, but you’ll be on YouTube, Stack Overflow, experimenting in your own codebase, etc. to find answers and a deeper understanding than the course materials alone give you.
  8. Yes, it was still challenging (and I learned a lot) even with prior industry experience. I came into this degree with about 2.5 years of web development experience and prior to that, a bootcamp, and I still learned a ton from most classes. Previous experience will give you a small advantage, but there’s still a ton of work to do and problems to solve that take time and effort.
  9. Yes, it requires sacrifice – there are many things I missed out on during the last four years because I was busy with school, which dominated evenings and weekends.
  10. Yes, it was an excellent experience – I learned so much and rounded out my CS knowledge in ways that my bootcamp and industry experience had not.

Computers have been my passion since I was a child, and completing this degree meant a lot to me. It formalized something I’ve explored via hobby projects, game mods, my own little websites, etc. since I was a kid.

My favorite resource for learning more about the program is r/OSUOnlineCS. I lurked here for nearly a year before I applied, and visited frequently while in the program.

About me (and some encouragement for other “non-traditional” students)

I want to write briefly about being a “non-traditional” student because that’s basically who this program is for: students who already have an established life and commitments outside of school.

Returning students usually have at least a couple reasons why they think they can’t go back to school – they’re “old” (over 30, or 40, or whatever), they have children, they have a full-time job, etc.

I check all of those boxes – I’m almost 37, I had two babies while I was in the program, I worked full-time for part of it, I relocated cross-country, blah blah. If this is you, with all these existing demands on your time, I just want to say: it is possible! It is hard but it is possible.

I met quite a few other parents with full-time jobs on my journey through the program so I don’t think I am unique, just disciplined and willing to work hard. If this is you, too, don’t count yourself out just because you have other things going on in your life.

My path through the program

Here are the classes I took in the order I took them, along with links to my reviews on each class.

I put a ★ next to my top three favorites.

  • Fall 2016: CS161
  • Winter 2017: CS162
  • Spring 2017: CS225
  • Summer 2017: no class
  • Fall 2017: CS261
  • Winter 2018: CS325
  • Spring 2018: CS271 + CS361
  • Summer 2018: CS290
  • Fall 2018: no class
  • Winter 2019: CS344 + CS340
  • Spring 2019: CS475
  • Summer 2019: no class
  • Fall 2019: CS372 + CS362this was a punishing schedule, I do not recommend these classes together
  • Winter 2020: CS492
  • Spring 2020: CS467 ★

OSU regularly updates and revamps the courses, and some of these courses were revamped since I took them.

The most notable (and controversial) change was the switch from C/C++ to Python in the foundational classes. I took the C/C++ versions of 161, 162, and 261.

I think this was a good change. While I appreciate the experience I got with pointers, memory allocation, and a relatively “low-ish level” language, sometimes it felt like debugging C got in the way of learning the higher level concepts the courses were trying to teach.

What to expect from OSU’s online CS program

Pacing and scheduling

Classes follow a strict schedule. Each week, usually on a Sunday, a batch of lectures, worksheets, projects, quizzes, discussions, etc. unlocks. Most classes have a “late work” policy you can invoke (once or twice) if you need an extra day or two, but this is not a self-paced program. Deadlines and exam windows are generally strict.

The workload and time commitment varies a lot between classes. The OSU CS Course Explorer is a tool I made to help students determine which classes to pair and which to take alone. It scrapes its data from the survey hosted on r/OSUonlineCS. You can also search the OSUonlineCS subreddit for tips and advice from other students.

At any given time in the program I was either working full-time with a baby, or caring for two children while working my way through the courses. I frequently alternated between one class a quarter and two classes a quarter.

When I took one class at a time, I felt like I was making glacial progress towards the degree but I also had room to breathe. I could dig into each assignment, do extra credit, work on side projects, or spare a few days for an illness or a short trip somewhere. I even went to Disney World for three days in the midst of CS225! :)

When I took two classes at a time, every week was the time management Olympics with no room for slop. I started assignments the moment they unlocked and made every minute count, but the sheer workload guaranteed the two-class quarters were brutal. I lost my 4.0 GPA the first time I attempted two classes at the same time. It was exhausting, but… faster progress!

Classes to take alone

I realize there are financial aid and “I want to get this over with” reasons to take two (or more) classes at a time, but my personal recommendation is that these classes benefit from being taken alone due to their difficulty, time-consuming nature, and/or overall importance to one’s CS education:

  • CS162 Intro to Software Engineering II – insane workload and challenging topics, but I took the C version so maybe it’s not quite so unforgiving now
  • CS325 Algorithms – most challenging course of the program, it dominated my life for 10 weeks
  • CS261 Data Structures – high workload and challenging, especially when it was taught in C
  • CS271 Computer Architecture and Assembly – high workload and challenging subject matter
  • CS467 Capstone – it’s your final project, give it (and your group) the time it deserves

Classes to take with other classes

These classes were lighter weight or just generally not so programming heavy. A coding problem can occupy me up for hours as I investigate and trial-and-error my way through it, but I never get stuck like that when the task is just to write a document or forum replies.

  • CS225 Discrete Math – challenging but manageable
  • CS361 Intro to Software Engineering I – mostly a writing class
  • CS290 Web development – relatively light workload
  • CS340 Database – a very entry-level look at SQL plus a final project you can do the bare minimum on if you are so inclined
  • CS3344 Operating Systems – the projects are huge but they’re manageable, topics aren’t exceptionally challenging
  • CS475 Parallel Programming – well-scoped assignments, evenly paced
  • CS492 Mobile Development – predictable workload

Obviously, your mileage may vary – and courses get revamped every so often, too, so my opinions and experiences will become less relevant over time. (This was written summer 2020.)

Exams

Most classes have some sort of big test to take at some point. Some classes split this up as a “midterm” and a “final”, some require it to be proctored (supervised), some allow open book, and a few don’t have any kind of big tests at all. At one end of the grading spectrum are classes that treat exams as the bulk of your final grade, while others weight their exams so lightly you can basically fail them. Every class is a little different in this regard.

Before doing this degree, I was never the kind of person who studied for exams. I usually just winged it and did okay, but the OSU classes demanded it. Flash cards, practice worksheets, practice exams – I did them all, and usually managed a B or better on midterms and finals.

Proctored exams are no fun but they help ensure the quality of the program’s graduates. A proctored exam is taken either at a local test center (if you live near a community college they may offer proctoring services) or online with a service such as ProctorU on your usual computer. The overwhelming majority of students seemed to be using ProctorU.

For the first half of the program I took my exams in person at a community college branded testing site near me. The big advantages with an in-person testing site:

  • a dedicated testing environment where no one is going to come along and ring your doorbell mid-exam
  • you get to use scratch paper instead of a whiteboard

ProctorU makes you use a whiteboard, and it’s small so you have to have to wipe it every few problems and can’t easily refer back to previous problems later in the exam. With a stack of scratch paper, you don’t “lose” your work as you work through the exam.

But, after a scheduling snafu with my local test site, I switched to ProctorU and never went back to my local site. ProctorU was half the cost of the test center and way more flexible with the scheduling options (my test center was only open a few days a week and after they lost my reservation and had no proctor present on the last day of the exam window, I was done with them).

As a whole, I would describe the exams in this program as tough but fair. There are a few exceptions, of course – CS290’s final stands out as being particularly bizarre and nonsensical, but it made up for it by being worth just a small portion of the final grade. Most classes seemed to derive around 20-50% of the final grade from tests alone.

Course content and materials

Unfortunately, as a whole, the course lectures are not great. There are some exceptions (CS492 had amazing lectures), but in general, you can find better instruction on virtually every topic covered by this degree program on YouTube, and you should. There are tons of talented people out there who can teach you how to do a summation or how to step through recursion better than the OSU course materials.

Courses get refreshed every 3 years on a rolling basis (so not all at the same time), and you’ll see people in the Slack channels and the subreddit talking about upcoming refreshes and retooling their schedule to get in either before or after a refresh. In my experience, the refreshes tend to be a good thing – you want to get in after a refresh, rather than before.

The most notable refresh that occurred while I was in the program was the switch from C++ to Python in CS161 and CS162 (with the change propagating up to the higher level classes after I graduated). There was also an elective that got split into two separate courses (Mobile & Cloud became Mobile and Cloud). Also, CS372 became an elective, and new electives were added.

I think these are good changes – they are trying to keep the courses relevant to the industry as a whole and useful to students. When I was in it, CS162 was like being punched in the face every week, but in the three quarters since that change occurred I’ve heard much better things about the class.

Feedback and help

You will get little to no feedback on the code you turn in. I never got any kind of “Hey, you know what might make this code read better…” input on any of the code I wrote for this program. Do not enroll in this program hoping to get 1:1 feedback on your code, because it will not happen. (I did get quite a bit of that kind of help at my bootcamp, though.) This was a disappointment for me in the program. I was accustomed to code reviews on everything I wrote at work so just turning in whatever I wanted and never hearing a word about whether the code style or approach was any good was a weird feeling.

Office hours – most courses had a scheduled set of times each week where you could drop into the Slack chat or a meeting room and converse with one or more TAs about the coursework. I rarely attended these – they were almost always at some impossible time (either they overlapped my work hours or they were right in the middle of the dinner hour) or way too late in the week (I was not going to “save” my problems for a Friday TA chat when the thing is due Sunday).

There’s a Slack channel for every class but the usefulness of each one varied widely. Some were great, with active discussion and helpful links and tips being shared. Others were completely dead.

As I was finishing up at OSU they were moving to a system of having official Slack channels for each class but having a teacher and/or TA in the room seemed to kill any interesting discussion beyond simple Q&A about the assignments.

Other student projects on GitHub/blogs – these were a goldmine of help. Usually the assignment had changed in some way since someone posted their code five years back, but having something similar to analyze was extremely valuable to me. Some OSU assignments are identical to assignments given by other universities, too, so if you find yourself stuck on an assignment just searching for the premise of the assignment might uncover something helpful.

Group work

There is a lot of group work in this degree program and for the most part it sucks.

The group work in this program is at its best when it’s things like discussions on Canvas or Piazza, and it’s at its worst when you’re a team of 3+ and one (or more) of your team members isn’t doing anything at all.

The problem with group work in an academic setting is there’s no recourse for problem teammates. In a professional environment, the team usually has avenues for dealing with a non-performing or always-absent teammate. Generally, managers don’t let someone do nothing and collect a paycheck. In a classroom setting, though, these non-performers are your problem.

I cannot sugarcoat it: many group projects in this program will feature one or more students who just don’t give a shit. I had group members who promised to do work and then just never did it, group members who turned in garbage, group members who skipped meetings and acted like it was no big deal if they turned their part in the same day it was due while others in the group were unable to work until that part was done. I had one group member drop a mess into the codebase and then go out to dinner for two hours just hours before it was due.

The TAs and teachers don’t want to hear about your team’s turd, so it is best to make peace with it and come up with contingency plans for your group’s non-performers. Try to arrange the workload to minimize dependencies – ie: don’t make it so you can’t start your part until someone else has finished theirs, because that person might wait until the 11th hour to do the part you’re waiting on. I’ve talked with enough other students to know that my experience was not unusual. Expect some dead weight on at least a few of your group projects. The group work is one of the worst parts of the OSU program.

Why I enrolled in OSU’s CS program even though I’m a web dev bootcamp grad who already works in software

My first degree is in fine art and my first career was in designing video games. The industry shift to “free to play” style games left me unhappy with my role. I’d always liked making websites, so in 2014 I quit my video game designer job and completed an 8-week web development bootcamp with Code Fellows in Seattle, WA.

My first engineer role was at Expedia, where I worked on a web app that allowed Expedia’s suppliers (people selling tours and activities) to list their products on the flagship website. This was great – I loved the bootcamp and I loved my job at Expedia, but I felt like my long-term advancement might be held back by the lack of a degree. (Some people even made comments to me to that effect, too.)

With decades of career still ahead of me, I decided to invest in a degree to support it.

I was impressed at how many of the topics I first encountered in my bootcamp resurfaced while working on this degree. Recursion, picking the right data structure for the task, interfacing with an API, CRUD operations, writing tests, and performance considerations were all covered in the bootcamp. Doing this degree made me feel even better about how good my bootcamp was! (Thanks, Code Fellows! You guys are legit!)

To me, this CS degree symbolizes my commitment to my new career and dedication to learning. I was already tooling around with side projects all the time, why not focus them into something tangible?

People argue that you can learn all of this stuff online for free, and that is true – I relied heavily on free online resources for every class in this degree – but the program exposed me to (and pushed me through) to things I’m not even sure I would have found on my own. For example, I don’t think I would have built a shell in C or worked through recursive algorithms on my own. I definitely would not have studied discrete math on my own. And I probably would’ve given up on some of the harder things if it weren’t for needing to pass a class motivating me to work through it.

People say you don’t need a degree once you’re already working, but I was called “just a boot-camper” or “just a front-end dev” enough times to convince me otherwise.

With the degree, now I feel like I can do anything!

Job prospects

I was going to fill out this section with a brief discussion of my post-degree job search, but due to COVID-19 I’m in a holding pattern as I wait for my children’s daycare to reopen and for it to be safe to venture into the outside world again. Many companies seem to be on hiring freeze, too.

I’ll write something useful here when I have something to report.

In conclusion

To some extent, it’s hard to say if the degree is worth it when I’m only a month post-graduation and have barely begun my job search (in the midst of COVID-19, no less).

But I can say this: it was a good 4 years and I’m proud of the work I did.

The degree was no replacement for on-the-job training: the degree didn’t touch 90% of the technologies, techniques, workflows, or complexities of the codebase that I encountered in my professional job. The bootcamp I did in 2014 handled those areas better.

Here’s a diagram that attempts to illustrate how much “overlap” there was in topics and learning between my bootcamp, the OSU degree, and the web developer job I had for the first three years after I finished the bootcamp:

This diagram needs a big fourth circle labeled “tinkering around with stuff on my own”.

Just going by what my other CS-degree having friends have told me about my coursework and projects vs. theirs, the OSU program seems to be roughly on par with what other state schools are offering for on-campus CS. In general, the OSU program seems to be more modern than what some of my friends did for their degrees (circa 2005-2015), though less math-heavy.

Overall, the degree gave me what I wanted: the peace of mind that comes from having put in the hours and the work to earn the same degree so many of my colleagues have. I think the degree will open doors down the road, especially if I ever want to do something besides front-end web dev (which I’m actually very happy in). Hopefully, the degree communicates that I am serious about my career change and dedication to CS!

I’m glad I did it.

Be sure to check out my individual course reviews if you want to know more about the classes in greater detail.

OSU eCampus CS467 Capstone review and recap

This post is part of an ongoing series recapping my experience in Oregon State University’s eCampus (online) post-baccalaureate Computer Science degree program. You can learn more about the program here.

Six-word summary: One big project, make it count!

You group up with two other students and spend the entire quarter making a project together.

CS467 Review

CS476 is one quarter-long project with a 3-person team of your choosing. If you can’t find groupmates, you can volunteer to be assigned a team. I looked for my groupmates a quarter ahead of time and I think it’s how I ended up with such a high performing group. My team was great.

You can pick one of the instructor-provided projects (which is what my team did) or you can come up with something of your own design, but you’ll have to “sell it” to the instructor or a TA to get approval to make it.

There were a good 20 or so instructor-provided projects to pick from and about half of them seemed to involve developing some kind of mobile app, so if you aren’t keen on developing an app (which some people in the class weren’t) this might rub you the wrong way. I wanted to build a React website and, luckily, there were a couple suitable prompts.

There is very little (if any) instructor/TA feedback on what you make. You won’t get any feedback on your code or what you make, or at least no one on my team did.

Every week you record a 3-4 minute video demonstrating the progress you personally made, and at the end of the quarter someone on your team will put together a poster that summarizes the project.

The class doesn’t really “teach” anything – there’s no lectures or worksheets or tests, it’s just there to make sure you make progress each week. We had to make a presentation poster at the end, but I have no idea who actually saw it (our project showcase was held virtually in the midst of COVID-19 and I couldn’t attend due to my kids’ daycare closing).

If I have any complaint it’s that I had to spend $2000 to just… do a project. I can do that by myself for free. (And I have done that: see OSU Course Explorer, my collection of WordPress plugins, Scene Together, Amazin’ Link Checker). But my group was solid and we made something cool, so at least it was a positive experience overall.

Time commitment

The class’s instructions tell everyone to spend 10 hours a week on it but they also lay out a list of requirements that, in my opinion, could not be achieved if everyone on the team just shut their laptop at the 10-hour mark. I put in around 20-25 hours most weeks.

Tech stack

Since everyone in the team either already worked in web development (or aspired to), choosing React for the project felt relevant and meaningful.

We used:

  • React 16.8
  • TypeScript
  • Google Firebase and Firestore
  • Web speech API and Azure Speech Services
  • Node.js
  • Heroku

My contributions

Just to give you a feel for what an individual might contribute to a quarter-long project, here’s a list of my major contributions:

  • Project setup, structure, naming conventions
  • Early working examples of routes, components, and features to serve as a template/guide for the rest of the project
  • User account creation and management (using Firebase Authentication API)
  • User schema in Firebase to hold additional user account data
  • All of the user-facing forms
  • Account linking system, whereby one user can “invite” another to follow and that other account either accepts or declines the invitation
  • Settings page where account links are viewed, deleted, and account profile details are changed
  • Researching, prototyping, and implementing the “voice to text” feature which required access to the on-device microphone and camera
  • Prototype work for the “photo reply” feature
  • “Quality of life” improvements, such as being able to refresh app and stay on the page you were on, the header collapsing into a drawer for mobile users, form validation, supported browser notification text
  • Responsive app UI works on desktop, iPad, and mobile (in both vertical and horizontal layout)
  • CSS-based solution to create “envelope” graphic that has open/closed states
  • Created art assets and icons for the project
  • App “look and feel”
  • “Sent” animation
  • Heroku pipeline owner
  • Contributed to fixing bugs found by teammates

My teammates had similarly long lists of accomplishments. We arranged the workload such that each of us owned a full “slice” of the app, so they took on the creation, sending, and display of messages between users. Everyone owned the “full stack” of their features, so (hopefully) everyone finished the project feeling like they owned a section of it top to bottom.

What we made

We called our app “Hola, Oma!” and it was based on a prompt provided by the instructor. We built a messaging app wherein the interface is simplified for the “grandparent” user but more complex for the “post creator” user. The user can send text, photos, or videos, and the recipient can respond with text or a selfie. We implemented “voice to text” to make replying with a message simpler for a less tech-savvy user.

Here’s our poster:

Main screen for the “grandparent” user:

User log-in flow and “link up” screen on mobile (for “post creator” type user):

Post-creator type user’s home screen (mobile and desktop):

Post creation (mobile and desktop):

By the end of the quarter the app felt pretty robust! We completed all of the goals we set out to achieve, and even had time for some nice extras. I think it helped a lot that everyone on my team had either an internship or an industry job already, so it was truly a team of professionals.

You can view our project’s GitHub repo here.

In conclusion

Capstone was the final course in my OSU CS studies and it was great to end on a high note. You can read my reviews of other OSU CS courses here.

OSU eCampus CS492 Mobile Development review and recap

This post is part of an ongoing series recapping my experience in Oregon State University’s eCampus (online) post-baccalaureate Computer Science degree program. You can learn more about the program here.

Six-word summary: BEST COURSE IN THE PROGRAM 🥇

This class rules. Yong Bakos is a fantastic lecturer and course designer. CS 492 is the missing link between all the small-scope student projects you’ve done so far and the much larger, much more complex projects you’ll work on as a professional.

They call it “mobile development” because you’ll do this class’s work in Dart and Flutter, and see your work on a mobile device, but this class grows a ton of skills that are important no matter what you end up working on.

My advice: take this class even if you have no interest in mobile development.

CS492 Review

CS492 is what every class in this program should’ve been.

Every week introduces a batch of lectures that are actually enjoyable and useful. Follow along with the examples and what you build is directly useful for the projects you turn in every 2 weeks.

This class covers a huge range of topics, including:

  • Setting up a development and build environment above and beyond just running a file from the command line
  • Coding style, with concrete examples of what to do and what not to do
  • Working with an SDK
  • Reading and using API docs
  • Refactoring, “code smells”, best practices for structuring methods and projects as a whole
  • Design patterns that you can take to any language
  • Best practices (guards, import order, function design)
  • Actually building something!

I took CS492 the first time it was offered so I have to admit, I was pretty scared. Some OSU classes have taught me to temper my expectations and I was bracing for an uneven workload, messy, unfinished course content, unclear expectations, long-winded 50 minute lectures full of “ums” and mistakes that go uncaught, etc.

I mean, even the courses that have been running for longer than I’ve been a student suffer from all of these problems and they’ve had ample time to clean up, so why wouldn’t a brand new one be more of the same?

None of these things were a problem in CS492.

This class was organized, consistent, and predictable. The lectures are high-res, easy to follow, and enjoyable. You follow along with the professor as he builds a project from scratch. Each lecture is just 4-8 minutes long and covers a specific topic, so you don’t waste time scrubbing through a marathon hour-long lecture for the part you need. Early lectures are followed by a coding exercise built right into Canvas where you can complete a quick ungraded exercise to reinforce what you just learned.

The project grading rubrics were clear. The weekly discussions felt meaningful (for the most part), and I found myself skimming what other people contributed just to see what I could learn from them.

The projects felt like the start of something “real”, and I enjoyed the opportunity to use all the pieces of the framework. Overall, I learned a ton in this class and it was almost entirely smooth sailing.

The only things I didn’t like were:

  1. Initially, new modules unlocked on Mondays instead of Sundays (like almost all the courses do), making it hard to get a running start during the weekend. Many students complained and the instructor running the course (not the same person who recorded the lectures) started unlocking them Friday at midnight. This kind of responsiveness is fantastic. The early-unlocks ended around week 7, when I think the instructor was still editing the pre-recorded lectures. If they improve one thing in this class, I hope they make the next week’s content unlock earlier than Monday.
  2. Initially, the correct answers to the weekly quizzes remained hidden forever. During Week 3, the instructor changed a Canvas setting to release the quiz answers a day after the quizzes were due. Quizzes that just tell you what you got without telling you the right answers so you can learn from them are useless, so I’m glad the instructor listened to reason on this one, too.

I liked that the instructor (who was different from the guy who recorded the lectures) was responsive to student complaints about these things.

I also liked how this class hit the ground running. In the first week you get set up with Flutter and follow a well put-together tutorial that guides you through making a simple app. Wow, a simple app in the first week! The following weeks continue to add complexity, and the end result is a course with a very satisfying “deep dive” feel to it.

CS492 course structure

  • 10 weeks
  • There’s a book but I didn’t get it and managed an A without it
  • Weekly quizzes (took me about an hour apiece, they’re not trivial and there is some wording I would have changed here or there, but they aren’t horrible)
  • Class-wide Canvas-based discussion to post to by Wednesday of each week (the topic changes each week)
  • Response to someone else’s discussion post due by Sunday of each week (the response was usually fairly detailed, ie: write a rebuttal, provide sources, implement a some code to create what the OP was describing, etc.)
  • New material unlocks every Monday – later changed to early Saturday morning, later back to Monday much to everyone’s chagrin in the final weeks
  • 4 projects (the 3rd one was the hardest/most time-consuming, but they were all a fair bit of work)
  • Project submissions are both your code and a 90-120 second video (screen recording) of your project as you quickly step through it to demonstrate it meets the requirements
  • Proctored final exam worth 35% of the grade – note: in my run of the class, the final was changed to unproctored near the end of the quarter due to a lack of testing sites because of COVID-19

I cannot say enough good things about the quality of teaching in CS492.

Take this class. Take this class. Take this class.

Topics covered

  • Many Flutter-specific conventions like Widgets that, while they may seem specific to Flutter, have analogs to other libraries like React
  • Structuring and modularizing a project
  • Asynchronous programming (async/await)
  • Saving data to on-device storage
  • Saving user preferences
  • Hooking up to an external database with Firebase
  • Uploading and retrieving photos to/from cloud storage with Firebase
  • Integration testing in Flutter (lightly covered)
  • Debugging

Time commitment

I took CS492 alone, which gave me time to really dig into everything. I might’ve spent a little less time on it had I paired it with a second class, but every week was very consistent and worked out to about:

  • 3-4 hours watching the lectures, reading the accompanying explanations, and following along with the code (the lectures themselves are maybe 45-70 minutes of content each week but I paused a lot to follow along)
  • 2 hours on the weekly quiz
  • 1-2 hours on my weekly discussion post
  • 1-2 hours on my weekly discussion post reply
  • About 8-10 hours on the current project

That’s about 15-20 hours a week depending on the week. The weeks where projects were due tended to be closer to the “20” end of that spectrum than weeks where projects were introduced. This was mostly because the second week of each project tended to contain the lectures pertaining to the more challenging aspects of the project.

The projects spanned 2 weeks, but lectures unlock weekly, so you could only get through half the project the first week because the second half of lectures wouldn’t unlock until the next week.

For example:

  • Week A – Project assigned, needs Lectures from Week A and Week B to complete, only Lectures A are made available
  • Week B – Lectures B become available, project due at the end of the week

This got irritating at times. At the end of every “Week A” it felt like sitting in a holding pattern all weekend waiting for the second batch of lectures to unlock so I could start the second half of the project, but I always had enough to for the first part of the project and could fill the weekend.

My advice to other students in this holding pattern is to do absolutely everything you can do for the first half of the project in the first week. Leave nothing that could be done in “Week A” for “Week B”, and you’ll be fine.

Recording projects

This was my first class that asked for screen recordings and I was pretty intimidated at first. I do not like being recorded and tend to make a lot of mistakes, get really self-conscious, freeze up, etc. However, much to my relief, you don’t have to record yourself or any kind of voice-over, just your screen.

You just step through the script they provide you and after a few run-throughs you’ll nail it all in one take. I found it helpful to create a doc with an extremely detailed, click by click script to follow and have someone else read it to me. That way I didn’t have to switch between the script and my active recording, and didn’t lose my place so much.

On a Mac, it’s easy to make a screen recording using Quicktime. Just search for Quicktime Player, cancel the default dialog it opens, then right click it to start a new screen recording.

My recordings were usually around 80MB but Canvas accepted them just fine.

CS492’s lectures are fantastic

In general, the lectures in this online CS program are low quality. Many classes have lectures that are poorly paced, unedited, boring, or only loosely related to the assignment you’ll be doing that week.

CS492’s lectures are none of that. They are short, punchy, and purposeful. They’re organized by topic and easy to find later when you need to refer back to one.

You follow along with the lecturer as he codes from scratch, explaining every decision he makes. He gives tons of little tips, too (like “build frequently”, “don’t make a temp variable just to return it in the next line”, etc.) and he explains his reasoning as he splits things into methods.

It’s like getting to pair program with the most senior dev on your team. This screencap is from week 2 and while a lot of what he covered was review for me, I didn’t feel like he was wasting my time. I genuinely enjoyed following along with him.

Yes, I could use a second monitor.

Nothing in this class felt irrelevant. The work felt like real work (like the kind of work you’ll do at a job once you graduate from OSU). Week 2 was the only week that felt like a bit of a rehash (it covers starting a project, wiring up inputs, organizing things into functions, etc.) but it was a good review and it didn’t take up too much time.

(This process of breaking a program down into pieces, setting up the prints, the inputs, breaking it into modules, and reasoning through the project’s could be moved to CS162 where everyone will see it and learn from it early on.)

Whoa, Canvas has a repl?

I hope Canvas’s support for repl.it is a new feature, otherwise I’m going to be seriously salty that every previous class in this program missed this incredible teaching opportunity.

The repl exercises in CS492 aren’t graded, but they’re broken down into little bite-size pieces that take a few minutes to complete and do a great job of reinforcing the current topic.

Honestly, some of these exercises feel like entry level interview questions. I was grateful for the practice.

Even better (I didn’t discover this until Week 3), you can hook up repl.it to your GitHub account and your edits to the repls will be saved.

They’re public, which isn’t how I usually like to store my student work, but keeping organized backups of my work on these exercises was a big help.

Tips for CS492

Set up the Dart SDK and Flutter ahead of time, or at least early. The setup isn’t necessarily straightforward. In my case, it took about 2-3 hours to work through all the missing components of the install (I needed to upgrade RVM, Ruby, install Cocoapods in the right place, read half a dozen Stack Overflows from people with similar problems, etc.) Some people had a harder time than I did. Starting early is a good idea. You’re good to go when running flutter doctor gives you a clean output of checkmarks.

Get a second monitor (or use a second computer) to display the lectures on their own screen. I made it this far in this CS program before I felt like I needed a second monitor. If you can get two screens, do it – the lectures are much more enjoyable if you aren’t flipping between tabs/programs every few seconds.

Week 3 is also when I got clever and started watching the lectures on my PC and following along on my laptop. Not having to flip back and forth between Chrome and Visual Studio Code saved me a lot of time.

Quiz tips: Unlike some classes, the multiple choice options in this class’s quizzes are not obvious joke answers. Here, the wrong answers are often correct in some way, but don’t answer the question that was asked. Pick the answer that is both correct and most accurately answers the question. It’s sometimes subtle and difficult to spot at a glance. This same advice applies to the final.

Mac/MacBook tip: I worked in Android Studio because I liked it best of the options, but I found the Android emulator to run extremely slowly (like 2 frames a second) while the iOS Simulator ran like butter. You can invoke the iOS Simulator from Android Studio, so don’t let the “Android” label scare you off if you’re on a Mac.

Final exam tips: None of the questions were repeats from the quizzes, but reviewing all the quizzes and the writings that accompanied each lecture was time well-spent in preparation.

Due to COVID-19 shutting down so many test sites at the end of the Winter quarter, the final exam was changed to be unproctored. Future versions of this class might go back to a proctored final, but in my humble opinion, they should leave it unproctored.

The exam was still challenging, but since it was open book it felt like one last opportunity to learn something instead of a punitive experience. The questions aren’t readily Googleable and still require in-depth familiarity with the course’s material. I don’t think having access to the course’s material during the exam raised my final exam grade by more than a point or two, and the timed-but-open-book exam (which was still worth 35% of the final grade) felt more in line with the spirit of the class.

If you do face a proctored version of this final, you can take some comfort in knowing that if you paid attention all quarter long, you’ll do fine. Nothing on the exam was a surprise, and there wasn’t anything painful about it (no tracking memory registers by hand, no memorizing formulas and algorithms, no writing code into a blank Canvas form).

Take this class. Even if you have no interest in being a mobile developer, you’ll benefit from working in a more complex, real-world SDK than what previous classes exposed you to. This class also covers a ton of general-purpose topics that will refine your skills and be useful no matter what you do in your CS career.

If this class is indicative of the quality we can expect at OSU periodically revamps this program’s classes, then I’m very optimistic about the quality of OSU’s online CS program in the coming years. CS492 felt like getting to pair program with a senior engineer for a few hours a week, every single week. Thanks for the great class, Professor Bakos.

CS492 is the highest quality course in the OSU program. It does not run every quarter (I took it in Winter 2020) but it is worth waiting (or retooling your schedule) for.

And that’s it! The only class I have left is Capstone next quarter.

PS: Seriously, take this class.

OSU eCampus CS372 Intro to Networking review & recap

This post is part of an ongoing series recapping my experience in Oregon State University’s eCampus (online) post-baccalaureate Computer Science degree program. You can learn more about the program here.

Six-word summary: How the Internet Works: The Class

It’s an evenly-paced, heavy-workload class. It’s predictable (and the grading is sane), but it’s a lot of work and over half of your grade in the class comes from tests. When I think back to this class, I will remember the Canvas test interface. This class is quiz after quiz after quiz after quiz.

I’ve been in the OSU program since 2016, so I’m on the old “two electives” plan that treats CS372 as a required class. Going forward, though, I imagine most people reading this will be considering CS372 as an elective and wondering how it stacks up against other offerings.

CS372 Review

This class is just like CS271 (Assembly) in that it attempts to work you half to death in a subject that probably feels peripheral – if not completely unrelated – to your intended career path.

Every week feels exactly the same. There are about 1.5 hours of lectures to watch, a few book chapters to read, worksheets to do (if you want, they aren’t graded), a graded “summary exercise” you can take twice (they’re like quizzes in that they’re graded, but you get 6 hours to do them so they’re also open-book), and pick one or two of the following: a lab, a project, or a 90-minute quiz. That’s every single week from beginning to end.

You will study things like:

  • How a bit gets from one machine to another (in excruciating detail)
  • Calculate the realtime delays a packet will experience as it traverses a transmission medium
  • Different networking protocols
  • How things like TCP, UDP, HTTP, and email work
  • How delayed a packet will be (in milliseconds!) if the network is such-and-such congested
  • How wireless networking works
  • How a packet gets packaged and split up as it makes its way across the mighty interwebs
  • A brief glance at security-related topics

Networking as a topic is interesting and somewhat relevant to my web development interests but ultimately this class didn’t feel like it fed directly into my programming career or ambitions.

There’s very little programming in this class, and while I can imagine an interviewer or manager shrugging and saying, “Neat!” at the fact that I took a 10 week course in networking, I can’t imagine it’ll make or break my viability as a candidate for a programming job. (Just watch, now someone will ask me to label all the parts of a network-layer datagram header.)

Structurally, though, it’s a solid course – the workload was even, the grading was fair, and I walked away feeling like the class packed a lot of knowledge into my brain.

Class structure

  • 10 weeks
  • A weekly graded summary exercise of maybe 30 questions. You get two attempts, and they keep the higher score. There’s a 6 hour time limit but the most I ever spent was about 2.5 hours (and the fastest I ever got through one was about 45 minutes).
  • A lab every 2 weeks
  • 2 projects in which you program sockets using C or Java and Python
  • Midterm, final, both proctored and closed book but you get to take a one-sided note sheet in with you (size 4 font worked nicely)
  • There’s stuff due every week but it follows a consistent pattern

Time commitment

CS372 class was fairly time-consuming. Each week, I spent…

  • 2 to 4 hours on lectures and worksheets
  • 3 to 4 hours on the “weekly summaries” (6 hour graded quizzes), depending how many novel math problems were on them (this was worse in the first half of the quarter than it was in the latter half)
  • 3 hours on any given lab, if there was one that week
  • Anywhere from 6 to 10 hours on the current project, if there was one that week
  • 90 minutes on the quiz, if there was one that week
  • As many hours as I could afford studying for the midterm and the final in the 7 to 10 days leading up to the exam

Overall, I spent about 12 hours a week on this class. My children are in daycare 3 days a week to give me time to work on schoolwork, and I typically spent two of those days exclusively on this class’s material, plus some time in the evenings and the weekend if needed. The most time-intensive weeks were the ones that included a project. There were no “easy” weeks, and they don’t lighten the workload in anticipation of the midterm or final.

Compared to other classes, CS372 was a bit lighter than notoriously time-consuming classes such as CS162, CS261, and CS325. It was about on par with CS271 and CS361.

Lectures != worksheets != quizzes

Here’s my biggest gripe about this class, and the part where I try to help future students have a slightly easier time than I did.

The lectures lecture on one thing, the worksheets prompt you on another thing, and then the quizzes throw a bunch of math problems at you that weren’t really covered in the lectures or the worksheets. For many of them, you’re on your own to suss out the formula.

Worse, when you go Googling for help the top results are often for chegg.com, who will happily sell you the answers (eww) and old digital flashcards from previous students who posted answers but not how they actually solved the problems.

So, all that said, I thought I’d do something radical and document how to solve these problems for the benefit of anyone else taking this class.

How I solved…

Is it worth taking this class as an elective?

That’s the question everyone’s asking now as CS372 moves from being required coursework to an elective.

My short answer is no.

For me, there wasn’t enough practical problem-solving and programming in this course. The two socket programming projects are big and time-consuming, but they are dwarfed by the massive amounts of non-programming related work.

Some people may enjoy the theoretical nature of this class, but I prefer courses that teach skills and concepts I can immediately put to use on my software projects. I know there’s no “bad” knowledge, but I do feel like I spent 10 weeks studying something I will almost certainly never use.

OSU is rolling out a bunch of new electives in 2020 and beyond, and they all sound really exciting to me. (I’m graduating before I’ll have the chance to take them.)

Of the electives I have taken, I can easily recommend CS475 (Parallel Programming), and I will update this review with my opinion on CS492 (Mobile Dev) after I complete it next quarter (Winter 2020).

I really wanted to take CS493 (Cloud Application Development) but it requires CS372 as a pre-req and I’ll be graduating before Cloud runs again. Don’t be like me: many electives only run once or twice a year, so try to look ahead at least a full year so you can get into the electives you want. (I regret missing out on a chance to take Cloud.)

On the bright side, there’s no group work in CS372! So, if you’re sick of teammates who don’t produce anything and graded Canvas conversations, CS372 is a nice break from those sorts of things.

CS372’s Labs

This class alternates “labs” and “projects”. Labs are all about inspecting packets in a program called Wireshark, and projects are programming in a mix of C/Java and Python. (More on Projects in the next section).

There were 5 labs total and each one took about 3-4 hours apiece.

You can run the “trace” yourself, or you can use the downloaded trace from the author’s computer. I highly recommend using the downloaded trace. My own traces were polluted with tons of noise from my home network and I found that things were often “different” in one way or another. I wanted to just slice through labs like a hot knife through butter, and the easiest way to do what was using the provided trace data.

Each lab is 15-20 questions and you produce a pdf document that includes screenshots from Wireshark justifying your answer for each question. Overall, these were straightforward and manageable.

PS: I couldn’t get Wireshark to run on my Macbook so I had to use my Windows PC for the labs. Just a heads up for anyone else on a Mac. (And it’s well within the realm of possibility that the problem was unique to my machine or could have been solved with more effort.)

CS372’s Projects

There were two socket-programming projects in this class, and they were both challenging and time-consuming.

I felt like both of the projects were the most difficult part of the class. The rest of the class’s material is memorizing definitions and stepping through a series of steps to solve a math problem.

If you can, take CS344 first. The socket programming project in that class offers more hand-holding and provides some code you can adapt to CS372’s projects. (CS 372 students are directed to Beej’s Guide for help, but I didn’t find the guide useful at all. It’s long-winded, the examples are difficult to adapt to the project’s needs, and the attempts at humor are lame and eat up valuable screen real estate.)

I spent about 15 hours on Project 1 and about 30 hours on Project 2. Definitely start early on the projects and work in small, incremental steps. The times when I got mired were when I tried to do too much at once.

To the class’s credit, they provide a detailed rubric to test against. This was extremely helpful and something I wish all OSU CS classes would do.

Pro tip: The second project is meant to be a “portfolio piece”, meaning you can share your project code publicly once grading is over. Many students have done exactly this on GitHub. Part of being a software engineer is reading and understanding code you didn’t write, so there is value in looking up what others have done and stepping through it yourself until you comprehend it. My heartfelt thanks goes out to the past students who posted their Project 2 work publicly – I don’t think I could’ve gotten through the file transfer/sockets project without a few examples to study.

CS 372 Exams

Both the midterm and the final are proctored.

They are similar in structure to the weekly “summary exercises”, so taking the practice versions of those (look in the “Grades” section in Canvas and scroll all the way down for the ungraded practice versions) is time well spent. Expect a few novel problems that you’ve never seen before (those are definitely where I lost my points, some of the questions were unlike anything I’d studied).

My strategy (and I think this was a good one, as I walked away from this class with a solid A) was to score 100% or near it on every weekly summary, lab, project, etc. to make some room for mistakes on the tests.

Overall, I felt the tests were fair and that the materials provided were adequate preparation.

Final tips for CS 372

Get a good weekly routine going. The workload is extremely consistent (and rather heavy) so a consistent pattern will serve you well. Mine was something like…

  • Sunday and Monday were lectures and worksheets
  • Tuesday was the first attempt at the weekly summary and starting the lab or project assigned that week
  • Wednesday was all lab/project and the second attempt at the weekly summary
  • Friday was all lab and project
  • Saturday was anything that was left (I rarely needed Saturday, with the exception of Project 2, which totally dominated my life until it was over)

Get proficient (and fast) at solving the kinds of problems you encounter on the weekly summary exercises and you’ll be 80% of your way to a good grade on the exams.

Right before the midterm and the final, go back and practice the stuff you did a few weeks ago (preferably on a whiteboard or scratch paper like you’ll have in the exam). I was surprised at how rusty I got at problems I was solving with ease just a few weeks ago. You really want to be a well-oiled machine at solving the math problems come exam time.

Some whiteboard practice a few days before the final exam. I found it helpful to solve the same kind of problems over and over on the whiteboard so it was just muscle memory come test time.

Don’t be afraid to go straight to teh Googlez for help. The projects in this class basically leave you on your own, and the fastest and best way (imo) is to start Googling. You’ll do that at work someday, anyway.

Onwards to Winter 2020! I’ll be taking CS 492 Mobile next quarter, followed by Capstone in the spring.

OSU eCampus CS362 Software Engineering II review & recap

This post is part of an ongoing series recapping my experience in Oregon State University’s eCampus (online) post-baccalaureate Computer Science degree program. You can learn more about the program here.

Six-word summary: The nadir of OSU’s CS program

It’s not a great class. It’s not even a good one, unfortunately.

I have no idea how you dedicate 10 weeks to the topic of testing and spend about one sentence on the topic of Test Driven Development and absolutely zero time exposing students to any of the zillions of existing testing tools.

If you disliked CS290 for its obtuseness and CS361 for its general irrelevancy, I have bad news for you: CS362 is like they took the worst of those classes and combined them into one tedious, time-consuming course that doesn’t teach much that’s relevant to real world programming.

All this class does is have students write the same kinds of tests on the same (broken) code over and over and over until the end of the quarter. If you walk away from this class hating testing or unconvinced of its importance, please know that this class isn’t representative of what it’s like to write and maintain tests in a professional capacity.

CS362 Class Structure

  • 10 weeks
  • 5 code-writing assignments
  • Unproctored midterm and unproctored final
  • The occasional quiz, with no real consistency in length or content (most are 10 minutes of multiple choice but – surprise – one quiz is actually a standalone coding project, and you won’t know what you’re in for until you open the quiz!)
  • The way the class has you use Git/GitHub suggests they don’t understand how versioning works
  • Due dates and time allocations don’t follow much of a pattern
  • A large group project at the end where three students total form up a group and write more of the same tests
  • Very little that resembles “real world” testing practices

Repetitive assignments

Essentially, students spend the quarter doing five variations on the same project.

  • Assignment 1: Fork the class repo from GitHub and study the provided, bug-ridden Dominion code (this isn’t really an assignment in the way the ones that follow are).
  • Assignment 2: Refactor a small portion of the Dominion card code into separate methods (this part is basically copy/paste) and introduce five bugs of your choosing and document every change you make in a .pdf (the Dominion codebase was already packed with bugs, there was no reason to further break it)
  • Assignment 3: Write unit tests for your refactored Dominion card methods. Document your tests in a separate .pdf file. This assignment was an absolute beast in terms of scope and time required, and misconstrues unit tests as integration tests. Unit tests should test a small portion of the code’s behavior. These tests run the entire method and then verify that a variety of things either changed or did not change.
  • Assignment 4: Write “random tests” for your refactored Dominion card methods. This assignment was another beast and it basically repeats Assignment 3 except now you’re randomizing the inputs and running many more iterations.
  • Assignment 5: Test a classmate’s code with your tests. This assignment was unnecessary and painful. It essentially asks you to repeat Assignments 3 and 4 on a slightly different codebase (your teammate’s), which requires hours of tedious line-by-line updates to hundreds of lines of tests. The point of this assignment was to demonstrate that a change to the underlying codebase might require a change to the tests, but they could have made that point with far less busywork.
  • Group Assignment Part A: The instructor hand-picked 11 bugs from the “Find Dominion Bugs” Piazza thread that everyone wrote hundreds of bugs into earlier in the quarter. Students form up into groups of 3 and produce a .pdf documenting the ways they plan to capture those 11 bugs in a collection of “unit” tests.
  • Group Assignment Part B: Actually fix the bugs identified in Part A. Commit the functioning test code to the team’s shared GitHub repo. Turn in 40+ pages of documentation on every single bug, fix, and decision made.

You don’t get to fix any bugs until the very end of the class, and you only get to fix a few. It’s very unsatisfying to write endless tests without fixing anything. I fixed things to see if my tests were any good, but I had to put the code back to its broken state before turn-in. There’s no sense of progression.

Also, the numbering and due dates don’t follow a strict pattern so double check those due dates.

The class’s git practices are a mess

This class does more with Git/GitHub than any other OSU class, but it doesn’t teach it nor does it do much to help students who are struggling with it.

If you are new to git, do yourself a huge favor and get used to it before you get to this class. Use it for classwork and personal projects. GitHub lets you make private repos now. This class won’t teach git, but it will expect you to be proficient enough to fork a repo, make branches, and push/pull to them, and you’ll have to do it in a group setting by the second half of the course, so start getting familiar with it now. Don’t burden your group mates with teaching it to you (or fixing your mess) at the 11th hour.

There was one particular “bad practice” I think this class could improve. Throughout the course, the assignments instruct students to make multiple copies of the “dominion” folder, which is weird and unnecessary in a versioning system.

By the end of the quarter, my repo looked like this:

  • dominion/ <– pristine untouched copy of dominion game code
  • projects/
    • robertwen/ <– the teacher’s folder, untouched in my repo
      • dominion/ <– another untouched copy
    • granaman/ <– me
      • dominion/ <– where my work was done
      • FinalProject-BugFree/
        • dominion/ <– group tests and bug fixes
      • FinalProject-Bugs/
        • dominion <– group tests, no bug fixes

There is no reason for the dominion folder to exist in 5 different places in the project repo. Two of those versions are completely untouched throughout the class.

Branches and pull requests could have handled versioning for each assignment, and if anyone needed to refer back to the original code it was always available in the teacher’s repo (the one we all forked our copies from) or by checking out an earlier version of the repo.

I think this poor organization sets a bad example for students, many of whom are still new to git and were confused as to why the same directory was copied into multiple locations.

No feedback on your work

Unfortunately, it’s rare to get feedback on your code in this program in general. CS362 is not unique in that the TAs don’t give suggestions for improving your coding.

But this lack of feedback is exceptionally disappointing in a class that’s has you write literally hundreds of lines of tests of your own design only to hear NOTHING back.

Students are given a lot of freedom in this class, but they’ll never know if they were on the right track or not. I wrote a ton of code in this class and sent it into a void, never to be heard from again. I got an A on most of it, but maybe that’s because the accompanying document was 30 pages long.

The one time I didn’t get an A on an assignment was because the TA marked me down 15% for exposing a crash bug that was in the dominion code to begin with. At that point I didn’t know what was real anymore.

If we aren’t writing tests to expose bugs then why ARE we writing them?

I don’t know.

But I can tell you what I didn’t do in the assignments that built on that assignment: I didn’t expose that crash bug again.

I let that bug sit there, undocumented and unacknowledged, in all future assignments because to test it would be to turn in a “crash bug” that would deduct 15% off my grade each time.

I’ve worked on software for over a decade and the idea of ignoring a crash bug and knowingly failing to cover it with a test is ridiculous. Like, fireable offense ridiculous. Nobody who takes pride in their work or values transparency does this. I died a little bit inside.

But that’s the kind of class CS362 is. :(

Testing is misrepresented

If you’re hoping for help with coding style, theory, practical approaches, “what to do vs. what not to do”, you won’t find it here. What this class calls “unit testing” is more like integration testing, and little effort is made to explain the difference.

There is no TA feedback on work produced in this class. Again, that’s not a surprise, but the work in this class seems designed to invite feedback, especially since the assignments are just variations on each other. Surely the TA looked at my code and had at least one idea for improving it? I don’t think I’ve ever been in a code review of a substantial amount of code where literally nothing was suggested.

Every assignment is accompanied by pages (often 20 or more) of written documentation. There is no need to write this much documentation on code that is, for the most part, self-evident in what it is doing. I mean, there’s a string baked into every test announcing its purpose – how much more help does a TA need to figure out what the code is doing? Plus, nobody writes (or reads) this kind of stuff in the real world. They expect your code to be self-documenting and, if a process does have to be documented, it’s expected to be concise, not bloated for length’s sake.

This class doesn’t mention any existing industry-standard testing libraries and tools. I thought they could at least mention test runners, configuring tests to run automatically as part of a deployment pipeline, mocking data and services for tests, and in a 10 week class there’s time to really dig into at least one or two assert libraries.

This class has students write tests in the style of integration tests but calls them unit tests. This just made me cranky – a unit test tests a very small portion of the code. Like, a unit test tests a method that only does one job. The methods we tested were larger than that, like 25-100 lines long, and made multiple changes to the game state via their own code and calls to other methods. That’s more of an integration test at that point.

At least I wasn’t alone, I guess?

CS362 Group work

The last two assignments require students to work in self-selected groups of 3 to write unit tests and fix bugs (identified and assigned by the instructor) in the Dominion code.

There is a special place in software developer hell for the group member who dumped their unreviewed code into our repo hours before the project was due and then went out to dinner. This isn’t unique to CS362 but it’s ridiculous the way every other group in this CS program contains a student who just doesn’t give a shit. This student promises everything and produces nothing, turns in work hours before the deadline, and acts like it’s no big deal that their work is garbage.

In CS362, they split the last project into two parts (A and B), made B depend on the work done in A, but gave them both the exact same due date. So, of course, one of our teammates saved all of their work on A and B for the last day and turned in a bunch of grade-dropping junk at the 11th hour.

The very least they could do in CS362 is make it so Part A is due before Part B so the functioning members of the team can identify the non-performing team member earlier than the day it’s all due.

What’s missing from CS362

Test-driven development. This class could’ve given students a simple project and asked them to write and turn in the tests before writing the project code. If they still want students to write reams of documentation, an assessment of how well those tests “held up” once the program was written might be valuable.

Expose students to at least one existing test/assert library. There are so many to pick from. Pick anything, it doesn’t matter, the point is to show students that test libraries exist and get them accustomed to writing in their unique syntax. My first assert library was Chai: https://www.chaijs.com/api/assert/ and I named (and structured) my C test methods for CS362 similarly.

Teach more testing know-how. The class could cover mocks and stubs, unit and integration tests, and how to write a bug. The class tries to cover “how to write a bug” but the only thing you’re really graded on is how well you followed the bug reporting template they provided, so don’t leave off irrelevant fields (such as “browser version” for a program that runs as a standalone executable) or you’ll lose points.

Show students how testing can be part of an automated build/deploy pipeline. Testing in this class kinda comes off as a thing you do locally on your machine when/if you modify the codebase and then forget about. It kinda blew my mind when I started working to see that tests were actually the build’s gatekeeper – that is, the deploy didn’t happen if the automated tests didn’t pass, and the tests were run in their own environment and occasionally subject to failures that didn’t happen on our dev machines. This topic could be its own post, but it might be a nice thing to expose students to.

Pass on some testing “wisdom”. One of my favorites is “if you haven’t seen it fail, then you haven’t really seen it pass“. That is, if your test passes right out the gate, don’t move on right away – perhaps it always passes?

But don’t just take my word for it…

If you’re used to checking the Course Explorer to scope out a class ahead of time, be warned that most of the reviews for CS362 are from a previous version of the class. They’re not accurate anymore. In the meantime, here is some real (anonymized) commentary from the class Slack chat.

Pretty much.

There were better ways to spend $2000. But it had to be done, and I’m glad it’s over. I hope that OSU improves this course soon.

Onwards to CS 492 in Winter 2020!

Networking – how to find the netmask, network address, host mask, broadcast address, number of possible hosts, and host number for a given IP address

Suppose you are given an IPv4 CIDR address

153.10.22.56 /22 

This IP address represents a particular device (“host”, in networking terminology) on a network, such as a laptop computer or gaming system.

From this simple set of numbers you can calculate all sorts of things about the network it belongs to, such as the network’s starting address, the number of devices (“hosts”, in networking terminology) the network supports, and the ordinal number in the network of this particular device. Let’s go be leet hackers…

Find the Network mask

The number after the “/” indicates what portion of the network address belongs to the network itself, and which portion is available for hosts. In the case of /22, it means the first 22 bits are used for the network itself, and the remaining 10 bits can be used by the various hosts that join the network.

In a 32-bit binary number, the first 22 bits should be 1’s, and the rest 0’s.

11111111 11111111 11111100 00000000 // that's 22 1's

Convert each “chunk” back to decimal and you get:

255.255.252.0  // the netmask! 

Find the Network’s Address

Now that we know the network mask, we can figure out the network’s address. The network address is the address of the network itself and it is the lowest address on the network.

If you’ve ever poked around your own home network, you might recognize 192.168.1.0 (or similar). All devices that join the network are given a similar, higher-numbered IP address when they are on the network: your phone might be 192.168.1.05, your laptop might be 192.168.1.12, etc.

You can find the network’s address by using your knowledge of the IP address of any given device on the network and the netmask.

Start by converting the IP address and the netmask to binary. Then, perform a bitwise and, meaning that for any position that has two 1’s, the result will be a 1. (Two zeroes or a 1 and a zero results in a 0.)

153.10.22.56        10011001 00001010 00010110 00111000
255.255.252.0       11111111 11111111 11111100 00000000
                    --------------------------------------
Bitwise AND:        10011001 00001010 00010100 00000000

Convert the result of the bitwise and back to decimal to get your network address:

153.10.20.0        // the network address!

Sanity check: The network address is always the lowest address on the network, so it makes sense that a device found at 153.10.22.56 could be somewhere in a network that began its addresses at 153.10.20.0. You should be suspicious of your result if you end up with a network address that is higher than the IP you were given to start with.

Find the Host Mask

The host mask is the inverse of the network mask and we’ll use it later on to find the broadcast address.

Go back to your network mask result in binary and flip the 1’s and 0’s to get the host mask:

11111111 11111111 11111100 00000000 // network mask
00000000 00000000 00000011 11111111 // host mask (bits flipped)

You may wish to convert it to decimal:

0.0.3.255

We’ll use the host mask in the next section to find the broadcast address.

Sanity check: Since the host mask is just the opposite of the network mask, you might able to “eyeball it” by finding the difference between each portion of the address and 255. For the given netmask, 255.255.252.0, you could subtract 255-255 = 0 for the first two parts, 255-253 = 3 for the second-to-last part, and 0-255=|-255| for the last part. Be suspicious of any result you get that doesn’t appear to be the “inverse” of the net mask you started with.

Find the Broadcast Address

The broadcast address is the highest address on the network.

To find it, use the IP address you started with and the host mask from the previous step. Perform a bit mask on them, meaning that anywhere you have a 1 is good enough to get a 1 in the result. Two 1’s = 1 and a 0 and a 1 = 1.

153.10.22.56        10011001 00001010 00010110 00111000  // IP 
   0.0.3.255        00000000 00000000 00000011 11111111  // host mask
                    --------------------------------------
Bit mask:           10011001 00001010 00010111 11111111  // broadcast addr.

Convert to the broadcast address to decimal:

153.10.23.255  // the broadcast address!

Find the number of possible hosts

To find the maximum number of hosts a network can support, go back to that “/22” from the IP address you started with. Subtract it from 32. (Why 32? Because that’s how many bits are in an address, total.)

32 - 22 = 10

Now raise 2 to that power:

2^10 = 1024

And subtract 2:

1024 - 2 = 1022  // hopefully that's enough room for everyone 

We subtract 2 because there are two reserved host numbers: the network address itself, and the broadcast address. We can’t assign those to laptops and smart TVs so we don’t include them in the maximum number of supported hosts.

Find the host number

My class often asked us for the “host number” of a device but didn’t really explain what was meant by that or how to calculate it.

The host number is just the ordinal number of the host on the network. It’s the Nth device on the network. Pretend you’ve already got a printer, a TV, and a computer on your network. You add your phone. Your phone is the 4th device to join. Its host number is 4.

In other words, you’re not looking for an IP address here, you’re looking for an ordinal number. For the sake of questions like the ones I got in CS372, you’re also assuming that hosts were added “in order” and assigned their IP addresses accordingly.

You need to know both the network’s address and the IP of the device itself. it from the IP if you know where the network starts.

153.10.22.56   // this is where we are, what is our host number?
153.10.20.0    // this is where the network starts

I imagine each section of the IP address to be like a bucket. Each bucket holds 255. Once a 256th is added, the number to its left has to increase by 1 and that bucket is reset to 0. (This is just like “carrying over” a number the way we’ve done since elementary school.)

Let’s do an easy one first.

153.10.20.0   // this is where the network starts
153.10.20.1   // what host number am I?

The device at 153.10.20.1 is host number 1. It’s the first host on the network because 153.10.20.0 is reserved as the network’s own address.

Here’s a harder one:

153.10.20.0    // this is where the network starts
153.10.20.255  // what host number am I?

The device at 153.10.20.255 is host number 255.

Now let’s see what happens when the number to the left also changed.

153.10.20.0    // this is where the network starts
153.10.21.1   // what host number am I?

Hey, that 20 became a 21! We must have added a lot of hosts to this network. We added so many, that the 153.10.20.nnn space was exhausted and we had to increase 20 to 21 and start numbering over. This “carry over” is just like you did in elementary school math, except here the limit is 255.

Since this is where it gets complicated, I’ll show you the steps:

153.10.20.0    // this is where the network starts
153.10.21.1 // what host number am I?
20 - 21 = 1    // there was 1 "carry over" 
1 * 255 = 255  // which means 255 hosts were added...
255 + 1 = 256  // and there's still 1 in the far-right bucket
256 + 1 = 257  // add that 1 from the first line to account for reserved addresses

The device at 153.10.21.1 is host number 257.

Hopefully you see the pattern here: each section is like a “bucket” that can be filled to 255, and then it has to “carry over” to the left and get reset to 0.

Now that you know how it’s calculated, we can look at “reverse engineering” it from our problem’s IP address.

153.10.20.0    // this is where the network started
153.10.22.56   // this is where we are, what is our host number? 
22 - 20 = 2     // two "carry overs" in the bucket
2 * 255 = 510   // 510 were added to get from 20.0 to 22.0
510 + 56 = 566  // add the 56 from the last bucket
566 + 2 = 568   // add 2 from the first line

The device at 153.10.22.56 is host number 568.

I think that last step is worth elaborating on a bit more. The 2 was added because 153.10.21.0 and 153.10.22.0 are also not used for devices. The 2 was derived from subtracting 20 from 22 (the second-to-last segment of the IP address).

More host number examples

Example 1:

128.193.42.0     // this is where the network starts
128.193.43.35    // this is where we are, what is our host number? 
43 - 42 = 1      // there was one "carry over" 
1 * 255 = 255    // so we know at least that many hosts were added so far
255 + 35 = 290   // add the 35 from the furthest-right bucket
290 + 1 = 291    // add that 1 from the first step, we're host #291

Example 2:

128.193.0.0      // this is where the network starts
128.193.43.35    // this is where we are, what is our host number?
43 - 0 = 43          // that's a lotta "carry overs"
43 * 255 = 10965
10965 + 35 = 11000
11000 + 43 = 11043   // we're host #11043

Networking – how to solve the “find the utilization for a TCP sender that is continuously sending” problem

In this post: A detailed, step-by-step guide demonstrating the steps I use to solve a problem similar to one encountered in my CS 372 Intro to Networking class.

You have a TCP sender that is continuously sending a 1,096-byte segment. If a TCP receiver advertises a window size of 8,551 bytes, and with a link transmission rate 35 Mbps an end-to-end propagation delay of 33.3 ms, what is the utilization?

(Assume no errors, no processing or queueing delay, and ACKs transmit instantly. Also assume the sender will not transmit a non-full segment.)

Suppose they want the answer as a percentage rounded to one decimal place.

This one breaks down into a series of simple steps:

Step 1: Calculate how many segments the pipeline holds

formula: 
segments = floor(pipeline size / segment size)
8551 / 1096 = 7.802 
= 7 segments

Remember to round down! There are no partial segments in this pipeline.

Step 2: Calculate how long it takes to send one segment

This uses the L/R formula, which is:

formula: 
time to send one segment = length of segment / transmission rate

(Don’t forget to use the same units for both. I convert everything to bits for consistency.)

(1096 * 8) / (35 x 10^6) = 0.250514 time to send one segment

Step 3: Calculate the Round Trip Time (RTT)

formula: 
RTT = propagation delay * 2 
33.3 * 2 = 66.6 round trip time

Step 4: Calculate the delay per packet

formula: 
delay per packet = RTT + time to send one
66.6 + 0.250514 = 66.850514 delay per packet

Step 5: Calculate the utilization!

formula: 
utilization = (segments * time to send one) / delay per packet
(7 * 0.250514) / 66.850514 = 0.026316

Move the decimal to places to the right to get the percentage.

= 2.6% utilization

Networking – how to solve the “effective delay” problem

In this post: A detailed, step-by-step guide demonstrating the steps I use to solve a problem similar to one encountered in my CS 372 Intro to Networking class.

Given an effective delay of 99ms when network usage is 76%, what is the effective delay when network usage is 53%?

Suppose they want the answer in milliseconds rounded to 1 decimal place.

You might’ve seen a variation of this problem where the delay is given in ms and the network usage is 0%. If you’re given a delay with a network that’s in-use, you have to first figure out what the the delay would be if the network congestion was 0%.

Let’s call that value x and solve for it.

We will use the same D = Do/(1-U) formula we would use if we already knew the delay for a zero-congestion network, but we will put our 99 ms delay where D goes and our unknown “x” value for Do.

Do / (1 - U) = D
x / (1- 0.76) = 99ms 
x / (0.24) = 99

Multiply both sides by 0.24 to turn that into a value for x:

x = 0.24 * 99
x = 23.76 <-- network delay in ms when congestion is at 0%

Now that we know the delay in ms when congestion is at 0%, we can plug it into the D = Do/(1-U) formula again.

D = 23.76 / (1 - .53) 
D = 50.6 ms

It’s not a difficult problem but my class’s materials only covered the “easy” version so I wanted to demonstrate the “missing steps” for anyone else who might be wondering what to do when they give you the delay for a partially-congested network instead.

Networking – how to calculate the size of MSS for a “mythical set of protocols”

In this post: A detailed, step-by-step guide demonstrating the steps I use to solve a problem similar to one encountered in my CS 372 Intro to Networking class.

Imagine a mythical set of protocols with the following details:

  • Maximum Link-Layer data frame: 1,331 bytes
  • Network-Layer header size: 29 bytes
  • Transport-Layer header size: 34 bytes

What is the size, in bytes, of the MSS?

Answer:

1331 - 29 - 34 = 1268

You just subtract the header sizes from the data frame. Easy.

You probably could’ve guessed that, but if you’re in CS372 and you’re reading this then it might be because you weren’t 100% sure wanted to check your work but the class materials didn’t really cover it. And that’s the thing that irked me about this problem: the class just threw it at us as a surprise on the weekly (graded but open-book) exercises in week 6. Then you go a-Googlin’ and end up somewhere like chegg.com who wants $15 to sell you a solution! That’s just silly.

Now you know: calculating the maximum segment size is just a simple subtraction problem.

Networking – how to solve the “non-persistent vs persistent HTTP” problem

In this post: A detailed, step-by-step guide demonstrating the steps I use to solve a problem similar to one encountered in my CS 372 Intro to Networking class.

A client’s browser sends an HTTP request to a website. The website responds with a handshake and sets up a TCP connection. The connection setup takes 2.5 ms, including the RTT. The browser then sends the request for the website’s index file. The index file references 2 additional images, which are to be requested/downloaded by the client’s browser. How much longer would non-persistent HTTP take than persistent HTTP?

Suppose they want the answer in milliseconds rounded to 2 decimal places.

You can get fancy with writing out each and every request (and this is what they’ll show in the worksheet), but there’s a faster way, especially if the number of referenced objects is more than a few.

Step 1: Count the total number things you’re getting, ie: 1 index file + 3 images = 3. That’s your N value.

index.html + image1.jpg + image2.jpg = 3 things total

Step 2: For non-persistent HTTP, your answer will be the result of N x 2.

3 x 2 = 6 connections needed for non-persistent HTTP

(That’s because for each and every item you request, you also need to request a TCP connection.)

  1. TCP request
  2. index.htm request
  3. TCP request
  4. image1.jpg request
  5. TCP request
  6. image2.jpg request

Step 3: For persistent HTTP, do N+1

3 + 1 = 4 connections needed for persistent HTTP

(That’s because you only need to connect once, and then request all the things you want.)

  1. TCP request
  2. index.htm request
  3. image1.jpg request
  4. image2.jpg request

Step 4: Now you have:

6 connection requests for non-persistent HTTP
4 connection requests for persistent HTTP

Step 5: Find the difference.

6 - 4 = 2

Non-persistent HTTP needs 2 more connections than persistent.

Step 6: Multiply that difference by how long each connection takes to set up.

2 x 2.5 milliseconds = 5 milliseconds. 

Double-check your rounding and units! You might be asked to give this in seconds instead of milliseconds.

In summary

  • Sum the things (index file and images) to get N
  • Non-persistent HTTP = N x 2
  • Persistent HTTP = N + 1
  • Find the difference
  • Multiply the difference by how long a round trip takes