OSU CS online – Today I Learned… in Code

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…

The VOIP problem (first seen in week 1)
The routers-in-sequence problem (first seen in week 1)
The File X and File Y problem (first seen in week 2)
The persistent vs. non-persistent HTTP problem (first seen in week 3)
The “find the utilization for a TCP sender that is continuously sending” problem (first seen in week 5)
The effective delay problem (first seen in week 6)
The “mythical protocols” MSS problem (first seen in week 6)
Finding the netmask, network address, host mask, etc. for a given IP address

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

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.

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.

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

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.

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

OSU eCampus CS361 Software Engineering I review & recap

Six-word summary: Group work group work group work

In CS361 you’ll get a high level look at “real world” scheduling methodologies (mostly waterfall and agile) and you’ll work in a group with 3-4 other students to meet weekly milestones designing and implementing parts of some other student’s “Vision Statement”.

CS361 Review

You don’t have to spend long on the OSU CS subreddit to realize that virtually no one likes this class. It’s not awful, but I understand the frustrations people voice on various forums around the web.

The heavy reliance on group work was frustrating more often than not and the course materials felt dated or like they were specific to a certain industry, but I didn’t dislike this class as much as most people seem to. I think it helped that I already have design and software development experience and enjoy writing and making diagrams/mockups, so this class played to some of my strengths.

The materials that introduce common planning and scheduling techniques for software projects were a welcome inclusion – I’m glad this stuff is covered somewhere in OSU’s CS program – but I thought they didn’t go nearly in depth enough to prepare students for the realities of working on an agile team. There wasn’t enough story writing, requirements gathering, pointing exercises, or customer involvement.

I thought the weekly homework assignments were a little lackluster. Working in a group is tough even in the best situations – some parts of the homework depended on other parts being done first, and some people’s schedules didn’t seem to allow for them to start the homework early in the week.

The documents we wrote as a group seemed excessively heavy on diagrams and put too much emphasis on satisfying a very specific set of expectations. For example, there’s a lot of emphasis placed on terminology such as “functional requirements” and “functional definitions”, which I had never heard outside of this class or seen used so religiously, but the concepts they represent were familiar. That describes a lot of this class’s materials: heavy focus on overly-specific methods and terms that probably don’t translate to every industry.

Maybe the course’s materials would be improved by taking a step back from strict terminology and definitions and talking instead about how to write good step-by-step documentation, how to write a good bug, how to write a good feature design that someone else can implement from – skills that can be applied to a variety of specific methodologies, since it’s impossible to predict which ones your future company or team might be using. There are so many skills that have nothing to do with programming that programmers still need to develop, and this class could be a good place to start learning them.

Class structure

In the first week of the class, everyone in the class writes a 2000 word “Vision Statement” for a software product that solves some lofty real-world problem. Forget about making a simple app to solve a simple problem, your idea for this vision statement should be utterly epic. They are surprisingly strict about the 2000 word count, but you should be able to hit that easily by showing off your design skills and covering every topic imaginable in relation to your app idea. You really can’t write too much, and no topic is too trivial to not write a page about. (I thought I’d covered security pretty well with the half page I wrote on it, but I got got dinged for not writing enough on the topic. I got the feeling the TA had to find something wrong with my document and if it wasn’t that, it’d have been something else.)
In the second week of the class, everyone votes on which ideas they think are best.
It doesn’t matter what you vote for. Your voting has no bearing on what project you get assigned. But you should vote anyway to help lift decent-sounding projects to the top, so that nobody has to work on the duds.
Expect to be assigned to a project you didn’t vote for because you thought it sounded stupid or impossible (or both).
You’ll then get grouped with 3-4 classmates based on absolutely no criteria whatsoever, so expect clashing schedules/mismatched interests/time zone incompatibilities. The instructor says this is part of life, and I agree (and every single software team I’ve been on has had an off-shore counterpart on the other side of the globe), but don’t expect your teammates to be so understanding. My group insisted that the only time we could meet was what was usually my bedtime, which sucked for me.
You’ll get to know these people very well as you meet 1-2 times a week (probably over a voice chat if your group is keyboard-phobic or generally unavailable at any time of day outside of the specific meeting window)
Every week you’ll work with these people to produce a lengthy document in response to a lengthy prompt. It will require diagrams and lots and lots of writing.
This assignment will be graded by a TA who might have limited English skills or a general lack of interest in reading 12+ pages of rather dry writing. We lost points on things that were present and the TA missed and we lost points on things that were never part of the requirements in the first place.
The last two weeks of the term are spent coding a small portion of the stuff you designed thus far; your group members may or may not participate in this process depending on whether they’re dirtbags or not
The final is made up of rather vague questions, but you should review the slides anyway to scoop up whatever points you can here

CS361 Tips

Vision statement tips

The grading requirements on the vision statement draft are really vague, but you can get full credit by writing a ton on every design topic you can think of and meeting the 2000 minimum word requirement.

Some ideas of what to include (beyond what the assignment suggests):

What differentiates your app from similar ones – do some market research and write comparisons. Someone’s probably already made a product like the one you’re imagining. What makes yours better?
User profiles – Imagine some hypothetical users for your app and write about them. Are they young? Old? Tech-savvy? Tech-illiterate? How is your app designed to appeal to them and meet their needs?
Accessibility features – imagine how your app might work on a screen reader or to someone with limited vision and write about how accessibility concerns are addressed in your app.
Security features – I wrote like half a page on security, which wasn’t enough according to my TA. Maybe you can do better!
Mockups! I made mine in mockflow

Journal tips

Work on the journal regularly – every other day is a good pace. The class’s instructor looks at these himself (or at least he looked at mine himself and commented on it) and he’s very good at detecting who wrote theirs in one fell swoop the night before it was due.

If you don’t know what to write, here are some ideas I used throughout the course to inspire myself:

Draw a comparison between the class’s material and your experiences working in a team – you ought to have some from your previous career or OSU classes
Talk about any previous software development experience you have; maybe throw in a bit about how you think CS361’s teachings on topics like agile will help you on future projects you develop
Talk about how your group work is going
Relate the lecture material to outside reading you’ve done or things you’ve heard
Sometimes the lecturer asks questions in the video; respond to those
Respond to the weekly learning topics: early in the week, write what you think they mean, then, after you do the lectures and your part of the homework, write again about what you’ve learned about those topics and correct any misinterpretations you had initially

Track your group members’ contributions

Yes, it feels creepy to keep secret notes about who in your group isn’t attending meetings, who turned in their part just hours before it was due, etc., but in the last week you’ll be asked to produce a very long, very detailed document rating each group member on a half-dozen criteria and justifying your rating in writing, so having kept track of this stuff will help you earn full credit on the assignment. I did my group member tracking in a Google Spreadsheet with a column for each week of the class and a row for each group member.

A lot of people in the Slack channel reported getting dinged for not being detailed enough, so keep regular notes and you should have plenty of material for this document and you should be able to write it in very little time. (Mine was 14 pages and included screenshots and data about meeting attendance and how close to the weekly deadline each person submitted their work; I got full credit on the group evaluation.)

Pick a programming language / framework that plays to your group’s strengths

Three people in my group inexplicably voted in favor of a framework they had little to no familiarity with – and majority ruled. I spent 2 weeks giving myself a crash course in JavaFX, coding as I went, which was fine but our development weeks would have gone so much better if the group had just picked something we already knew and could’ve hit the ground running in. The end result: some group members struggled to produce anything at all during the coding weeks.

Here’s what we ended up with: a clickable map of the United States that colors states according to how they voted in the 2016 presidential election and, alternatively, according to how gerrymandered they are.

This screenshot best represents my portion of the work: building the map and hooking it up to real data.

Implementing this much functionality posed plenty of interesting challenges to work through. Things like building a complete map out of individual SVG boundaries, figuring out how to make them clickable, altering their color based on data from the project’s database, and fitting containers within containers to get everything fitting in the application window kept me busy for the two weeks.

For some people in my group this was their first exposure to Git as well, so this project came with a side-helping of Git training. (Note to any future students out there: if you don’t know git yet, start learning it now – don’t wait until you’re in a time crunch of a group project with multiple people counting on you.)

And finally…

Don’t be a dick

Show up to meetings. Do your part and do it early enough so that your group can review it. Don’t disappear during the coding weeks. Be a good team member and make connections on LinkedIn once the class is over.

An educational program like this one is a huge opportunity to network and make friends; you never know who might end up at a great company someday and put in a good word for you. You can gripe about 361 and sandbag for two months, or you can impress a bunch of future industry peers by knocking it out of the park every week.

It’s only 10 weeks – you can do it!