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 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 each 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 CS290 Web Development 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:  :(  :(  :(  :(  :(  :( 

Web dev is, for some reason, this really polarizing thing in tech. I’ve certainly heard a lot of devs go “Ewww, JavaScript!” (both in my real life job and from my classmates). That’s too bad, because I think the web is really cool and it’s where a lot of people spend a lot of their time these days! I like building web apps, but I can see why some people don’t – it’s prone to “flavor of the week” syndrome, the tooling isn’t great, JavaScript does some things “weird”, etc.

I went into this class curious to see what aspects of web would be taught, since it’s such a broad topic to stuff into just 8 (or 11) weeks. Here’s some of what we covered in CS 290:

Git

This is the first OSU class I’ve had that covers git in any capacity (I’m halfway through the program). This is awesome – hooray, CS290, for introducing git!

I wish the OSU program covered it sooner. It has been frustrating to group with people in my previous classes who have never used it before and would rather use things like email (!!!) to share files because they don’t know git.

Unfortunately, 290 didn’t go very in-depth with git. We pushed two files to a Github repo in the first week and called it good. We literally never used git again. I think this was a huge missed opportunity: the class could easily include a group project of some sort that focuses on collaborating in a git repo, or require us to post incremental work on a project to our github repos, or something.

Quirks of JavaScript

The first three weeks of CS290 focused heavily on “this weird thing JavaScript does”. The usual suspects are here: lack of strict typing, hoisting, closures. It’s not that these things aren’t important, it’s that they aren’t what makes web development compelling or useful. Starting the class out by spending three weeks on these topics just seemed to make JavaScript look weird and annoying, when in practice, these things aren’t that big a deal.

I think it’d have been cooler if they set us to actually making things and learning the tools of the trade in those first three weeks. In the accelerated schedule, week 4 is when it got interesting: we made an HTML website with JavaScript methods to navigate around in a table and mark cells yellow. 

Week 4 homework: a bare-bones interactive “website”. This is the first step in building the kind of stuff that makes the web compelling!

Installing npm packages on a server

They had us do this in week 1 – OSU provides some server space, and everyone was tasked with claiming a port and setting up a little server on it.

We never came back to it. I don’t know why we did this so early in the class. Node and its (infinite) packages is an interesting topic and it’s weird to just install it and never come back to it. It was like a story that someone started telling and never finished. 

Some light database stuff and routing with Express

This part was fun – make routes (like “/get”) and make them return data from a class-provided database. This work will be extremely useful as starter code when you take CS340 (Databases) so keep it somewhere safe. 

The biggest, most complex project of this class is the one where you develop backend routes for database interaction. You’ll spend a lot of time on form validation and making rows in a table switch between a read-only state and an editable state. This is also the project I thought was the most interesting of all of them, since it was the most like a real site. 

What CS290 didn’t cover

Sadly, there was no mention of Chrome’s various debugging tools, running node locally, front-end frameworks like React, the difference between running JavaScript on the front end and the backend, the staggering quantity of problems that have already been solved with neat existing NPM packages, unit testing, integration testing, and deployment.

Somewhat irritatingly, some of the assignments had what I would consider poor coding practices. The second assignment (sorting automobiles) in particular irked me because it makes unnecessary copies of an array:

/*This function sorts arrays using an arbitrary comparator. You pass it a comparator and an array of objects
appropriate for that comparator and it will return a new array which is sorted with the largest object in index 0
and the smallest in the last index*/
function sortArr( comparator, array ){
//returning a new array to satisfy assignment requirements; we could have run sort on array itself (it's passed by reference)
var sortedArr = array.sort(comparator, array);
return sortedArr;
}

Arrays are passed by reference; there was no need to create a new one and return the new one. In fact, we could have run .sort() in place instead of calling a completely separate method for it. Maybe I’m just cranky, though.

The workload in weeks 1, 2, 3, and 4 is very low, but then things pick up after that. 

CS290 final exam

Whoever wrote this exam does not know what is important in web development.

I’ve used JavaScript (both as a hobbyist and a professional) for over half a decade, and I got one of the lowest scores I’ve ever gotten on a test here. I don’t know what to say – expect a ton of oddly-worded bullshit questions about tricky trivia that have no relevance to how JavaScript is used or real life web development practices. 

CS290 parting thoughts

I can only guess what this class is like for someone who is new to web development. It’s probably a disjointed pastiche of topics that get introduced in a vacuum and then quickly abandoned. I’m sure this class isn’t helping anyone become enthusiastic about web development, which is too bad. 

For a better introduction to modern web development consider building your own site. I think that’s how a lot of us got started – we wanted a website for some reason or another and set one up. There’s plenty of project starters (known as ‘boilerplate’) out there to pick from. Here’s what I would recommend…

  • Buy some $5/month shared hosting and make your own portfolio site out of HTML and your own CSS. Once you’ve got that…
  • Start up a node server on your own computer and get it to serve your own project
  • Build a simple one-page app that does a simple job using a front-end framework such as Angular or React (here are some ideas: a text capitalizer, a shipping price calculator, an anagram solver)
  • Use a popular front-end styling framework, such as Bootstrap
  • Realize what you made is garbage and start over
  • Repeat a bunch of times
  • Keep Googling any time you get stuck
  • If you build something decent, deploy it somewhere like Heroku and show it off!

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.