Tag: CS courses

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!

OSU eCampus CS340 Intro to Databases 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: Surprise, it’s a web development class!

You’ll glance at some database topics in CS340, but you’ll put most of your effort into building a big full-stack website.

CS340 Review

Get ready to sharpen your web skills! You’ll work with a partner the entire quarter (try to pick a good one!) to design and implement a website that interfaces with a database. This class is very heavy on web development. You’ll make tables to display data that comes in from the db, forms that can create, update, and delete data, and you’ll need it all up and running on the school’s servers by end of quarter. Course pacing is uneven and the numbering of assignments, projects steps, and assignments is borderline illogical.

I HIGHLY recommend finishing 290 before you take 340 so that you can use your last 290 project as starter code for 340’s. It’s criminal that people say you should take 290 and 340 simultaneously. Don’t do it. One of the last projects of 290 is a node.js website that interfaces with a database, and if you have this project complete, you have a fantastic head start on 340’s website project.

Class structure

  • 10 weeks
  • No midterm, no final
  • Pick your partner in the first week
  • Each week you make progress towards a completed website project with your partner
  • Some weeks require “peer review” in which people from outside your group look at what you turned in and critique it (and you, in turn, review others’ work)
  • Hits hard in the last few weeks of the quarter when you have to put the entire site together. Start early.

The first week is slow: you’ll pick a partner and you’ll import a database dump into the database tool of your choosing. You’ll sit on your hands after this ~30 minutes of work is complete.

This is a good time to figure out what you want your site to be. My partner and I did a museum ticketing system and found it easy to hit all the requirements. Don’t reinvent the wheel here.

Each week you’ll work on an ever-growing document outlining your plans. No one will read it, but you’ll submit it every week nonetheless. There is absolutely no TA feedback at any point in this class. I finished this class without so much as a “Looks good!” from a TA.

About midway through the quarter they’ll give you an assignment to build the HTML portion of your site. If this is all you do this week you’ll probably fall behind, because each week after this has a much higher workload. You should immediately look at your projects from 290 to get started with the routing and db queries once you’re happy with the HTML.

There are no exams and no quizzes.

CS340: Too light on database-specific stuff

For a database class, this class is (sadly) rather light on hands-on query writing. It tries to teach database design, which is appreciated, but I think it spends too long belaboring minutia relating to the design diagrams (we must’ve done three iterations of ours before the precise requirements finally became clear on Piazza). It also spends weeks on the diagrams – one would’ve been enough.

The two places CS340 has you get your hands dirty is on Mimir for a few query-writing assignments and in your quarter-long website project. This is where the class shines: where it’s actually teaching (or forcing you to figure out on your own) how to interact with a database to do something useful.

CS340’s Mimir assignments

Rather than write SQL queries in any kind of industry-standard tool, CS340’s query writing is done in a browser-based tool called Mimir. Deadlines are generous and the work takes maybe 2-5 hours to get through (per assignment). Mimir is slow and the feedback it gives is not as robust as what you might get in a better tool. CS340 does give you the db dump, so you can go play around in a better environment (I used MySQL Workbench) but sometimes syntax that works locally does not work in Mimir.

Nonetheless, the Mimir-based parts of the course are some of the best parts. Experience writing queries is a skill you can take to an interview and job. I just wish there had been more of it.

CS340 group work

“What one engineer can do in one week, two engineers can do in two weeks.” The adage holds up in CS340. My partner was great, but I think I would’ve moved faster through the project without having to coordinate with someone else. There’s a lot of overhead in keeping someone else in the loop, not duplicating work, waiting for input before continuing, etc.

A few weeks into the quarter, everyone gets assigned a random group of 5. This is your “peer review” group. (Your partner will be in his/her own peer review group). Since 340 doesn’t seem to feature any TA feedback, this is what the class gives you instead: feedback from other students who probably know the same or less than you do about what you’re working on.

The real kicker? You have to bring their feedback into your document and either act on it or explain why you chose not to. The feedback we got was generally useless: at best it was people pointing out UI bugs we already knew about, at worst it was a hot take dashed out 2 minutes before the feedback was due that suggested little to no reading comprehension on the reviewer’s part. At least we didn’t have to all meet at the same time like we did in 361.

Our CS340 project

We made a museum ticketing system. This project was a bit large for the time given but I enjoyed working on it.

In our app, you can add museums, add exhibits to museums, “sell” tickets to guests with a variety of exhibit entitlements, create new guests, add orders to existing guests, search for tickets by ID, date or transaction, view transactions, refund exhibit entitlements from tickets, and refund tickets themselves. You can also rename exhibits and museums, and update guest info.

We used Bootstrap on a node.js/Express/MySQL stack. (I’d have preferred to use an actual front-end framework but my partner was much newer to all this so we went with a nice big bowl of JQuery spaghetti instead.)

Here’s a few screenshots from our completed web app:

Our app’s default page – you can change which museum to view tickets and exhibits for.
Here’s the “sell tickets” flow, where the user chooses which guest types to create tickets for as well as a visit date.
The user can manage which extra exhibits each guest ticket should have access to.
Review your order before proceeding…
Enter guest info and complete the purchase! The ticket info is added to the database.
The Transactions page shows all pages and provides links to individual tickets.
In the Museums page the user views all museums and can choose to rename them.

Here’s one of the queries from the project that I wrote: 

app.get('/get-transactions', function(request, response) {
     var context = {};
     var queryStr = "SELECT tr.transaction_id, tr.trans_date, tr.trans_time, g.fname, g.lname, tr.pymt_type, GROUP_CONCAT(ti.ticket_id) AS ticket_ids, GROUP_CONCAT(ti.admission_type) AS guest_types "+
       "FROM transactions tr "+
       "JOIN guests g ON tr.guest_id = g.guest_id "+
       "JOIN tickets ti ON tr.transaction_id = ti.transaction_id "+
       "WHERE tr.museum_id = ? "+
       "GROUP BY tr.transaction_id;";
     pool.query(queryStr, [request.query.id], function(err, result, fields) {
         if (err) {
             console.log(err);
             return;
         }

     context.transactions = result;
     response.json(context);
  });
});

GROUP_CONCAT is a neat trick we used to get a string of ticket IDs and admissions types back from the db (which you can then parse on the front-end).

My favorite parts of this class were when I got to do something new and exciting in SQL.

CS340: What’s missing?

I wish the class had covered any (or all) of these topics:

  • Non-relational databases
  • Input sanitization
  • Security
  • Stored procedures
  • Thread locks
  • Transactions
  • Advanced SQL (this class never goes further than a SELECT within a SELECT)
  • Best practices

And this is just “what I know I don’t know”.

If I were to redesign this course, I would give students a defined project (“Make a theme park ride ticketing system”) and provide a functioning front-end so the class can super deep dive into database-specific topics instead. I know databases don’t exist in isolation, but the sheer amount of front-end work it required to interact meaningfully with our data greatly overshadowed the database work.

A few final tips for CS340

The course is disorganized and the assignments never fall into a predictable “rhythm”, so double-check everything. Every week it’s something different: this week you turn in a PDF, the next week a .zip. Sometimes you turn it into Canvas, sometimes you post it to your “peer review” discussion group. Does it count for you and your partner or just you? It varies week to week. Is there a quiz that opened last week due this week? These aren’t difficult things to figure out, but they add a lot of “overhead” and I saw more than a few people going “OMG I thought that submission counted for both of us!!” in the Slack chat.

Take 290 first. Easily the best thing you can do for yourself to ensure success in CS340. The last 290 assignment will have you make routes for interacting with a database. You can use that work as boilerplate for your CS340 project and save yourself a ton of grief. Can you imagine taking 290 and 340 at the same time and being stuck on the same problem for both classes? Take 290 first! It should be a hard pre-req for 340.

Skip the lectures. They’re a mess. I mean, I won’t tell you how to live your life, but the lectures in this class are worthless. They won’t help you build your site, they’re thin on examples, and sometimes the topic they introduce was actually needed for the homework due last week so… yeah. I’m a diehard “watch the lectures no matter what” person and I gave up on them. It’s like they’re from a previous version of the course or something.

Don’t reinvent the wheel. Use Bootstrap (or similar) to make your front-end look nice, choose a project idea that lends itself to lots of pairings (customers to orders, people to tickets, etc).

Overall, I was disappointed by CS340. I’ve weathered other not-so-great courses and found the good in them, but this one was just a whole lotta making a bigger website than we made in 290 and writing a few SQL queries on the side. My database/SQL skills didn’t grow much in this course and I’m bummed that it didn’t live up to my expectations. My partner was awesome, though, so there was that. :)

I made an AngularJS web app! Check out the OSU CS Course Explorer

Browse 300+ candid student reviews and helpful tips for OSU’s online CS degree courses

Check it out: https://osu-cs-course-explorer.com/

What it does: Aggregates real student course reviews from the OSUOnlineCS subreddit survey, which dumps data into this spreadsheet, and displays that same data in an easier-to-navigate format.

Who it’s for: OSU CS Ecampus students

Technologies used:

The rest of this post is about the app itself (not its code). If you’re hoping for some code walkthroughs, stay tuned – I’ll be writing a few in the next month or two before I move onto my next side project.

App inspiration

I started OSU’s online CS degree program Fall 2016, and I am so grateful for the opportunity the school has given me to receive a formal CS education.

Ever since I applied to the program I’ve been an avid reader of the OSU CS subreddit. I was always looking for info on my next class – survival tips, strategies, what to study, etc. The course survey (linked in the sidebar) contains years of useful student data but at 300+ entries, it was becoming difficult to browse or parse on a macro level (ie: there was no way to look at it and determine how time-consuming on average a particular class might be).

I had the idea for a simple web app that would take the Google spreadsheet data and reorganize it by course, listing all the tips (with timestamps) and aggregating the time spent and difficulty data into a couple of easy-to-read pie charts. I knew other people would find this useful, too, so I planned to make it publicly and freely available once it was presentable. (From this experience I also wanted a finished, portfolio-worthy app that I might show to a potential employer.)

I started the project in the summer of 2017, worked on it bit by bit whenever I wasn’t swamped with classwork (or my full-time job, or my baby who was 9-13 months old while I worked on this, or the cross-country move I did in August). It’s definitely a testament of what you can build even if you don’t have loads of contiguous free time, as long as you are consistent and keep going.

Browse the code

If you want to browse the app’s progress (and see some of the mistakes I made along the way) you can browse the GitHub repo for it here. I tried to leave concise comments explaining what I was doing, in hopes that other students and beginning web devs would find it helpful.

I plan to write a few blog posts dedicated to different sections of the app’s code. I love “here’s an app I built and how I built it” type posts myself and owe a lot of my own knowledge to them, so I’ll try to give back a few contributions of my own.

Why I chose AngularJS

I know everyone’s got the hots for React these days but I had just come off of 2 years of working in Ember and wanted to return to my ancestral headwaters for a bit and build something in the framework I got my start in. I wanted to see if all my “I liked how that worked in Angular better” feelings towards Ember were actually accurate or just some rose-colored tinting of history (as it turns out, I really do prefer Angular to Ember :P)

I don’t know if I’d pick it again, though. The world has largely moved on from AngularJS (to Angular 2 and beyond, and React), but there’s still a ton of helpful blog posts and Stack Overflow questions about every imaginable Angular topic (way more than Ember has, that’s for sure) so for that reason, I think it’s still a good, established choice if you’re new to web development frameworks and want to try something.

Thanks to contributors

Special thanks goes to Yong Joseph Bakos for his pull requests after the project launched – cleaning up some cruft in the codebase, improving tests, documentation, etc.

Special thanks also goes to Jonathan Burley for helping unstick me at some critical points in development, like when I needed help customizing the canvas legends in a way that wasn’t documented and when Heroku was being a pain.

I feel like I always learn so much from even the briefest encounters with other developers, so I am grateful for the help I received along the way.