Hello world! This is my first post for CS-443. I am very excited for this semester and what’s to come!
From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.
Introduction CS-443
Renz here! This is just an introduction to CS-443.
From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.
Introductory Post
This is my introductory post for CS-443-02.
From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.
Introductory Post
This is my introductory blog post for CS-443 Fall 2018.
From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.
My First Blog Post CS 443
Welcome Reader,
My name is Andrew Finneran and this is my first blog post. 
-Computing Finn
From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.
CS-443 Introduction
This is my introductory blog post for CS-443 Software Quality Assurance & Test.
From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.
Introductory Blog Post
Hello,
My name is Mia and this my first blog for my new blog website. Here you will find articles, blogs, book and/or podcasts that I have found interesting and my point of view on them. More is to come in the near future, Thank you for reading! Mia
From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.
Fall 2018 – New (mostly) and Improved (probably)! Part 1
The Fall 2018 semester begins in 4 days and I’ve been working hard for the last month or two on the courses I am teaching – CS-343 and CS-443. In this post, I’m going to talk about two course changes – Full POGIL and All OER.
Full POGIL and All OER
These two changes affect both courses.
POGIL
POGIL is an acronym for Process Oriented Guided Inquiry Learning. It is a student-centered, group-learning instructional strategy and philosophy developed through research on how students learn best.
The POGIL Project, What is POGIL
In past semesters, I have done some POGIL or POGIL-like activities in classes. Students seemed to be highly engaged with them. When I started to lecture, engagement started to go down. So, I plan to teach entirely with POGIL activities this semester in both of my courses.
In 2015, I attended the 3-day Northeast Regional POGIL Workshop held at Muhlenberg College, in the Introductory Track. That gave me the basics about how to teach with POGIL, I used it occasionally, mostly using activities that had been written by Stoney Jackson at Western New England University, or Clif Kussmaul at Muhlenberg.
I also tried to write some activities of my own, which were generally better than lecturing, but didn’t really fit the full POGIL methodology. So, this summer, I decided to attend the 3-day 2018 Northeast Regional POGIL Workshop (at Manhattan College), and take the Writing Activities track.
But before I went to the workshop, I decided to go all-in and teach CS-140 this summer as a full POGIL course. This was a good time to try this experiment because I had a small class (only 6 students) and I knew that there were a lot of already written activities for CS1 (Introductory programming) in Java. I used the activities from Chris Mayfield (at James Madison University). I read all of his activities, and soon decided that I would have to write some of my own. But having such a great collection of activities from Chris helped me generalize the structure of the activities and write some of my own.
Now I am writing all my own activities for my two courses this semester. This will be a challenge to keep up with, and I’m sure they will not always perfectly follow the POGIL learning cycle, but it feel confident that these will be a good start that I can improve upon for future semesters.
OER
In Fall 2017, I applied for and received an Open Educational Resources Initiative (OERI) mini-grant from the Worcester State University Library. I used it to teach CS 343 without a textbook. I did the same with CS 348 in Spring 2018 (without a grant). This semester I will be continuing by using OER in CS-343 again and eliminating the textbook from CS-443.
One of the reasons I decided to go full POGIL is that the activities replace much of the reading material in the courses. I can write an activity that introduces the concepts and terminology to the students for the first time, and then assign them some online readings for more details.
It’s great that I can save the students money with OER instead of a textbook, but from my perspective the most important feature of OER in my classes is that I can organize the class around material that I feel is important to the students. Often the course topics in these upper-level software development courses cannot be covered in a single book – I would have to assign 3 or 4 books to cover the areas, and I would use only part of each book. And I’m very fortunate that Computer Science is a field where practitioners feel compelled to document what they do, what tools they use, and how they work, on the Web providing me with a large collection of materials I can assign to my students.
Still to come…
In future posts, I’ll discuss Specification/Competency Grading, Self-Directed Professional Development Blog Entries, as well as changes in tools that I am using this semester.
From the blog CS@Worcester – On becoming an Eccentric Professor… by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
Sprint Retrospective – 2 May 2018
As the final full sprint comes to a close, I find myself wishing for just a bit more time to work. With the testing issues resolved, we were able to work much better than we have in the past, and with a newfound grasp of the technologies at hand. Had we begun the semester with this kind of understanding of what we were working with, I think we would have had a vastly different product than what we currently do. During this sprint, we corrected what was left of the sync/async issues we were having, made a switch over to a singleton pattern for our service (with a bizarre development), and got as much of the service in minimum working order as we were able.
Having redone the tests to be compatible with Promise objects, I spent the first bit of the sprint trying to convert the offline storage service into a singleton pattern. The primary difficulty in this turned out to be that Ampath had its own tslint.json file for enforcing the organization’s style guide. When coupled with the fact that WebStorm regards conflicts with the tslint file in the same way it regards syntax errors, it meant that the code wouldn’t compile, and I had no clue what was wrong with it. Only after reordering my field and static method declarations would the tslint stop holding my code hostage. After going through this whole ordeal, I think it would be nice if at the start of future semesters, Ampath provided capstone sections with a style guide to avoid headaches like this one. After the conversion to singleton, I moved to the tests to rewrite them to interact with the singleton object. In the middle of this process, however, something very non-intuitive and very obnoxious became visible.
First, a recap of the purpose of Singleton Pattern: by making the default constructor for a class private, one can disable willful instantiation of that class. Then, a static method which returns the single instance of the class allowed to exist is written. With this structure, you can guarantee that only one instance of a class exists, and there is an easily available mechanism to grab a reference to that class.
“Not in my house,” says Angular. It turns out that making the default constructor private doesn’t actually give it any kind of private visibility; you can still instantiate the class with “new.” I only realized this when halfway through writing my test cases, I accidentally wrote “= new OfflineStorageService();” and was not told that it was a problem. Rather, the tests all ran and passed, even though – and I triple checked myself on this one – the default constructor in OfflineStorageService was most definitely declared private. I shared this information with my group at the next meeting, and we each agreed that it was one of the most baffling things we’d ever seen in programming.
In spite of my shock, things proceeded smoothly and steadily for the rest of the sprint. Our communication was spot-on, as we were giving each other daily, sometimes hourly updates in our group text message. The code, while sometimes strange and alien, was actually starting to behave like we wanted it to behave. We were in consistent communication with one of the other groups, and occasionally communicating with the other two. Really, this felt like a culmination of what we’d learned from the last five sprints – as it ought to have. Perhaps we could have done something better; I probably could’ve been better about standup meetings and asking questions about Ampath, but I think in general, each of us feels far more comfortable with this entire process. With only the documentation left to do, along with our final presentation, I think I can say I’m beginning to feel what it means to be this thing called a “software developer.”
From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.
Be The Worst
Intimidating in much the same way that The White Belt pattern is, Be The Worst encourages software developers to surround themselves with peers that have much greater skill levels. As the weakest member of a team, one has ample amounts of room to learn and grow. Practically speaking, due to the skill present in the surrounding developers, they will be able to correct the unseasoned programmer’s mistakes, and prevent those mistakes from recurring in the future. Furthermore, the goal of the pattern is quite emphatically to cease to be the weakest; the person making use of this pattern will be working extra hard to climb up to the level of the professionals surrounding them.
Admittedly, this is a bit of a difficult pattern to put into practice – at least for me – in the immediate present. The only time I can relate to Being The Worst is when I first joined the programming team back in sophomore year of college. I certainly noticed the gap in capabilities; I was much slower than the other members at solving problems, and my solutions tended toward the bulky side, with optimizations that weren’t necessary for the problem at hand. Over time, being among the other members of the team taught me to evaluate context to determine how thorough I needed to be with my code, and gave me mechanisms for assessing problems in a way that was more programmatic.
I expect that this pattern will come into play whether I like it or not as I enter the workforce. Whatever team I happen to join will have been doing the things it does for years before I ever showed up, and may have tools and environments that I’ve had minimal exposure to, if any. As such, I will need to keep the ideas of Being The Worst in mind while I learn to navigate that team, working in any ways I can to raise myself to their standard and beyond. For now, though, I will have to settle for my position of Being The Neither-Worst-Nor-Best in my current team for the remainder of the capstone.
From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.