Category Archives: cswsu

Breakable Joys: what I was missing in my breakable toys

As I picked through the list of Apprenticeship Patterns one of the earlier ones jumped out to me, as it seemed fairly obvious from the name what it was. Upon reading the description I was correct in this assumption and further I had experience with this particular pattern – even if outside of an apprenticeship. That description being a “toy system that [is] similar in toolset, but not in scope to the systems you build at work”. If you were to insert “school” instead of “work”, then I have built breakable toys for the same reason the book describes: to try and fail in private so that your successes can be applied to a real project using the same technologies, but your failures do not come at the expense of said project.

I have a sense already that many of the patterns I pick this semester will be those that I either have experience with or involve skills I feel insecure about. This being a pattern I feel familiar with I hoped to see if I was applying it correctly, and I wasn’t, at least not completely. First, the book stresses that a breakable toy should be like any real toy, fun. I think this is at least one hang up I have had with my own toys is that I try too hard to make them into potentially repurposable that I can use in whatever project I am training for. Instead, I think moving forward I will try first to make something fun, but overengineer it like the book says, such that I can gain as much experience possible from some silly little program.

Additionally, the book mentions making a little wiki as your toy, and this I had never thought of. Initially, I had read this as meaning thoroughly documenting the toy you are building. It makes perfect sense and follows logically one of the best points that has been made to me about learning, which is that the best way to do so is to teach. However, upon subsequent readings I realized they meant developing a wiki with your selected tools. While this certainly would help foster an understanding of yours selected tools, it would clash with the previous goal of being fun, at least in my mind. Instead, despite it being a misunderstanding, I think much could be gained from documenting one’s progress on a breakable toy. Considering I have a spike project to work on currently, I think I will apply these lessons as I begin.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

A series of relatively unconnected thoughts about the Apprenticeship Patterns readings

This blog contains mostly random thoughts as I did the reading. Nearly each paragraph is a new thought, but they all build to a whole that is effective strategies I hope to adopt or observations about the way the contents relate to my current place in school and work. Please take note as you read this.

I find it interesting that not only did they take the time to address what you should expect to do as an apprentice, but in outlining how your responsibilities change as a journeyman and eventually master they set you up for what you should expect from your mentors and what to strive for as a mentor. They do make a point of saying it is not their intention to write this book to make effective mentors, but I think despite their protestations it does provide a decent lens for the breadth of experiences, however brief their descriptions may be. While I may still be hardly able to envision my life as an apprentice let alone something higher, I hope to remember at least some of these lessons.

As well, one portion stood out to me very specifically as in the process of writing internship applications I had a cover letter I was very confident in, but realized that I could come off as too confident in it and had not emphasized my willingness to learn and accept new techniques. As a result, I will be going back to revise that letter again.

Unsurprisingly, much of these introductions is spent telling you to get out of your comfort zone for a deeper learning experience, but this should be understood innately, so it feels redundant. However, one good idea was to pick up a lesser documented language and try to write the documentation on your own. You could even do this exercise with an already well-established language to solidify your knowledge of it. In fact, more than just languages this is a great idea for any subject, as the old adage goes: “the best way to learn is to teach”. I have found for myself that tutoring a class while here at school was an amazing refresher for the material that I had forgotten since I had taken it so long ago and I picked up new knowledge that I had missed previously.

One thing that did confuse me a little was these chapter’s seeming insistence on remaining a developer rather than moving on to a leadership position or some other “higher ranking” position. Or rather, the utility of this book to those who wish to remain in software development, which makes a little more sense. With the mention of difficulty in keeping or finding good developers, despite a deluge of mediocre ones, made me worried about proving I am worth hiring or having a team that is uninvested in the work or does not possess anything close to mastery over it.

I was particularly struck by the quote at the beginning of Chapter 6, as I have a lot of trouble finding personal motivation without the structure and reward of grading found in school. Therefore, the advice of keeping a reading list is very pertinent to me as perhaps one way of building my own internal mechanisms for remaining engaged in my field and becoming self-motivated.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Libre Food Pantry Impressions

Upon reading the Libre Food Pantry landing page I was very pleased with the vision and mission sections, as they express the better angels of a computer scientist’s nature. Often times, I get very discouraged by the field as it seems like while many people may just not care, so many more simply want to create and solve problems – but these creations are used to exploit other workers, or invade people’s privacy. “Big Tech”, like all things under capital, takes the creative energy of its workers and uses it to enrich itself at the cost of human dignity, and oftentimes, lives. In a just society, we would value much more the contributions of these open source contributors than the efforts made to perpetuate war and mass surveillance.

…or at least that what I would say BUT if I decided to go to any other tab from the overview and then back, the contents wouldn’t load correctly. Rest assured I will be supporting a bug report.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Beginning of the End: Software Development Capstone

This feed will contain blogs for my aforementioned Software Dev Capstone course, as it did for the courses I have taken previously. I’m excited to share my experiences in class as well as reflections on the reading materials this spring semester.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

CS343 Final Project – Blog 3

In this blog I hope to show what a beast typescript animations can be. To do so I’ve isolated one animation in a set of ten that control the slide in animation for each page.

transition('HomePage <=> *', [
  style({ position: 'relative' }),
  query(':enter, :leave', [
    style({
      position: 'absolute',
      top: 0,
      left: 0,
      width: '100%'
    })
  ]),
  query(':enter', [
    style({ left: '-100%'})
  ]),
  query(':leave', animateChild()),
  group([
    query(':leave', [
      animate('400ms ease-out', style({ left: '100%'}))
    ]),
    query(':enter', [
      animate('400ms ease-out', style({ left: '0%'}))
    ])
  ]),
  query(':enter', animateChild()),
])

On the first line you’ll notice I have the transitions from the element I currently am on, “HomePage”, representing the Home Page component, to a placeholder representing any other component. Next, there are queries which represent what to do when the animation is triggered. The components slide in from the left and send the old component out the same way, and that is what the left 0% and 100% would seem to represent; with of course a set time for the duration of the animation.

           The result of this is that the new component is placed virtually to the left of the current component, then the new component is slid in eventually having its left side arrive at the 0% mark as expected, while the old component has its left side shifted to 100%. This making it virtually placed to the right, where it presumably is then removed.

           When I first added these animations, they would not trigger correctly and often only in one direction. As mentioned, there are a total of ten, which is the total after added one to represent moving from any defined page to any random page, or vice versa. That way no matter what page you are on the correct animation triggers. However, the next problem I ran into was that adding a whole other element to the left of a page, essentially making the page 200% wide even for a split second, would cause the horizontal scroll bar to appear and the window would jitter. This was quickly remedied by turning off the x-overflow, or rather setting it to hidden, in the css properties for the div in the app component html that contains the router for all these elements. With that done, I had slick page animations and no nonsense!

           One last touch added was something I realized the webpage could use when testing the animations. I noticed that when the animations trigger it would slide in the other page but the viewport would remain at the same level as the last page. It didn’t make much sense to me that a page be loaded in with the user at the bottom of it. So I added an additional method to scroll the user to the top of page each time they clicked on a button and a new element slid in.

<button mat-flat-button color="primary"
        routerLink="/about-me" (click)="returnToTop()"
        [ngStyle]="{'font-size': button_font_size + 'pt'}">
  About Me
</button>
returnToTop() {
  window.scrollTo({
    top: 261,
    left: 0,
    behavior: 'smooth'
  });
}

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

CS343 Final Project – Blog 2

On the last blog I had mentioned the painstaking process of getting my sticky header to function correctly and especially so when accounting for the top margin and mobile scaling. I have provided the code below for the sticky header.

 @HostListener('window:scroll', ['$event'])
 onWindowScroll(e) {
   if (window.pageYOffset > 251) {
     let element = document.getElementById('navbar');
     element.classList.add('sticky');
     element.classList.remove('non_sticky');
     if(window.innerWidth <= 850) {
       this.top_padding_var = 87;
     } else {
       this.top_padding_var = 43;
     }
   } else {
     let element = document.getElementById('navbar');
     element.classList.remove('sticky');
     element.classList.add('non_sticky');
     this.top_padding_var = 0;
   }
 }

What this is doing, essentially, is adding the sticky header to the document when past a certain point and removing the non-sticky variant. The toolbar is nested inside a non-sticky div, inside the sticky div, which is present at the top of the page below the header. When scrolling past a certain point the non-sticky version is “swapped” for the sticky variant which is fixed to the top of the page. Here below is the code for this sticky component where you can get a better idea of what I mean by nesting.

<header class="animated fadeInDown" id="navbar">
  <div class="non_sticky" [ngStyle]="{'height':header_height}">
    <app-toolbar></app-toolbar>
  </div>
</header>

You can see here as well that the height of the container for the toolbar is determined by the variable, header_height. I mentioned previously as well that considerations were made for mobile use and this is one. Below is the method that determines this variables value.

resize() {
  if(window.innerWidth <=850){
    this.header_height = 40;
  }
  else{
    this.header_height = 60;
  }
}

Increasing the height makes readability on mobile more effective as well as providing enough space for the buttons to fit in the bar. Some may have noticed a variable being assigned in addition to the sticky-header being added/removed, which highlights another challenge of this particular bit of styling. As mentioned, the sticky header simply swaps in a fixed version of the normal toolbar, but in doing so this new fixed element has a higher z-index and does not “touch” the other elements.

As a result, this new element naturally covers whatever was behind it just a moment ago. To remedy this, I added this variable to the method to dynamically add padding to push the elements on the page back down where they belong. Honestly, it feels like trickery the way everything works together but when it does its nearly seamless unless you know exactly what to look for. In the next blog I will discuss a part of this element that I did not include previously: animations.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

CS343 Final Project – Blog 1

Since this semester began, I’ve known exactly what I wanted to do for my final project, and even before the semester I’ve had this project kicking around my head. Ever since I saw my good friends personal site years ago, I thought it may be exciting to create my own, even before I even considered doing computer science. So, it should be obvious then, when I found out we would be creating a web page for our final project I knew this was the perfect opportunity to finally begin this project.

I knew that this personal – or rather, professional – site would be an interactive resume of sorts, a really incredible showing of capability that I could link to on resumes and in online professional profiles (LinkedIn, Handshake, etc). Consider this exchange:

“Have you done any web development?” asks a potential employer.

“Well sir/madam/neither, if you simply navigate to [web address] you’ll see the extent of that experience”.

“My goodness, this website looks amazing! I have no choice but to make you the president”.

As such it has to look good, like really good, you don’t become the president for nothing (you get it for being related to someone important). So, if I wanted a website that would make someone important adopt me, I needed to perfect the aesthetics of the website. I would need interactive elements and animations, a pleasing color palette, a readable layout, and of course sections on who I am and what my accomplishments are. I will, of course, not be linking this blog to it considering the beginning of this paragraph.

The first element I knew I wanted was a sticky header, or a toolbar that would “stick” to the top of the page once you scrolled down far enough for the top of the toolbar to touch the top of the page. This would mean that users could change page even while far past the header of the site. Another element I wanted was large tiles representing each page that would expand to fit the whole screen when clicked. However, I realized that it was incredible difficult to implement and also redundant considering I already had a way to access any other page at any point a user may be on said page.

I would reach the previous conclusion long after I had already begun, starting with the sticky toolbar. Folks online have implemented similar designs, so I began with those that were most effective and simple as a template. The way it works is actually very clever: a typescript method is used to check the yOffset of the page and if it goes past the offset of top of toolbar the toolbar is changed from a regular element to one that is fixed at the top of the page. As such, the elements on the page below would normally be covered slightly by this bar, however I have it dynamically add to the top-margin of the page to shift the content down appropriately. When this happens, by painstakingly finding the exact right values, it all appears perfectly seamless.

This work took, no joke, 4 hours or more, as I added scaling for page width such that when the page is shrunk horizontally as it would be on mobile the header and toolbar grow in height to accommodate the text and buttons correctly. However, I’ve already gone long on this blog so I will continue in the next one!

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

If It’s Broke Don’t Fix it: Treating Bugs Like Buddha

For my last blog for this course instead of taking one
particular course subject, summarizing it, and theorizing about what actual
implementations may look like – I’d like to look at the whole course and do the
same. More specifically, I would like to cover how bugs or defects are actually
addressed, or not, in Software Development and Testing. To do this I have found
some interesting blog posts which argue that 100% of bugs may be able to be
fixed, but shouldn’t be. Instead, one should focus on serving the vast majority
of users under expected circumstances.

           Both blogs
focus on how impractical, and expensive, maintaining 100% stability or up-time
is. In the first focusing on bugs specifically they give many reasons why this
goal is unadvisable. The first is the prevalence of Agile Development,
dominating nearly the entire software development landscape. As such, the constraints
of this fast-paced development style limit the ability to do traditional QA testing;
if a program can have several revisions in a week, maybe even a day, then how
could a team reasonable test all these iterations. Instead, the author suggest
a stability monitoring tool to automatically test each revision.

           In
addition, they suggest that eliminating 100% of bugs would eliminate many which
users would never see, so why waste resources addressing them? Even if you
could fix everything how could you possibly know? This focus is reinforced when
considering the truly incredible breadth of devices that one may have consider,
and specifically in mobile development: where they cite the over 24,000
different android devices on the market. One must focus on the average expected
user experience and not waste time fussing with the outliers until, presumably,
a bug report is filed.

The second blog discusses
defects in systems in a similar way, covering more or less the same points, although
mentioning a rather obscure possibility: being legally challenged for claiming
that your product has no defects. Instead, what I believe they are trying to emphasize
is that products are always fallible, and the amount of resources required to
get them even close is impossible or impractical. As a result, as we move
forward in this class and towards graduation I think we should resist the impulse
to try for complete perfection and instead focus on what is achievable and
provides the best experience for the majority of users.

Sources

Not all bugs are worth fixing and that’s okay
The Zero Defect Fallacy

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Clarifying Edge Testing

I happened upon a very
interesting blog recently, searching for more examples of edge case testing,
wherein the author provides an interesting set of common edge cases. While they
use the same names or similar ones as those we’ve seen lately in class some
have new meaning here. In addition, they may have an actual value tied to the
name – such as zero, one, and two – but their values are defined otherwise.

 In order they
are as such:

  • Zero “represents
    any form of null input”, including the actual value zero but also null, an empty
    List or Array, et cetera. This of course is to test the capability of a program
    to deal with input that isn’t properly usable by it.
  • One represents what
    we have referred to as nominal up to this point, meaning a valid normal input
    which should test proper functionality of a program under ideal conditions.
  • Two does not
    correspond to the value two, but rather refers to testing the same code twice,
    usually in sequence, to see how repeated executions affect a system.
  • Two to Max-1 is
    most like one, in that it represents a nominal value as well, but in opposition
    this value should not be the absolute simplest needed to function but an average
    use case; meaning possibly complicated.
  • Max is
    fairly self-explanatory, used to test the upper limit accepted by a program, and
    can sometimes be an extreme value. As such, it can test the limits of the
    program under incredible load.
  • Max + 1 is
    used to ensure that limits placed on an application are working and that anything
    that does not correspond to a valid range is rejected in a reasonable manner.

These would most closely correspond to Normal Boundary Value Testing as we have covered in class but they are each less abstract than those counterparts. They provide an insight on what these values look like in actual QA testing, as well as expectations upon being used. Two for example does not have an actual value associated with it, but rather refers to a testing orthodoxy outlined above. One example of a test in this vein is found in another blog, in which the author proposes the edge case of the same user trying to log in from two different computers. I believe between the two of these blogs a clearer picture of the concepts we have covered can be found through these more concrete examples of the testing procedure.

Sources

A Beginner’s Guide to Testing: Error Handling Edge Cases
Build Strong Edge Test Cases

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Test Driven Development: Formal Trial-and-Error

Test Driven Development (TDD), like many concepts in
Computer Science, is very familiar to even newer programming students but they
lack the vocabulary to formally describe it. However, in this instance they
could probably informally name it: trail-and-error. Yes, very much like the
social sciences, computer science academics love giving existing concepts fancy
names. If we were to humor them, they would describe it in five-ish steps:

  1. Add
    test
  2. Run
    tests, check for failures
  3. Change
    code to address failures/Add another test
  4. Run
    tests again, refactor code
  5. Repeat

The TDD process comes
with some assumptions as well, one being that you are not building the system
to test while writing tests, these tests are for functionally complete
projects. As well, this technique is used to verify that code achieves some
valid outcome outlined for it, with a successful test being one that fails,
rather than “successful” tests that reveal an error as in traditional testing.
Related as well to our most recent classwork, TDD should achieve complete
coverage by testing every single line of code – which in the parlance of said
classwork would be complete node and edge coverage.

Additionally, TDD has
different levels, two to be more precise: Acceptance TDD and Developer TDD. The
first, ATDD, involves creating a test to fulfill the specifications of the
program and correcting the program as necessary to allow it to pass this test.
This testing is also known as Behavioral Driven Development. The latter, DTDD, is
usually referred to as just TDD and involves writing tests and then code to
pass them to, as mentioned before, to test functionality of all aspects of a
program.

As it relates to our coursework, the second assignment involved writing tests to test functionality based on the project specifications. While we did not modify the given program code, at least very little, we used the iterative process of writing and re-writing tests in order to verify the correct functioning of whatever method or feature we were hoping to test. In this way, the concept is very simple, though it remains to be seen if it stays that way given different code to test.

Sources:

Guru99 – Test-Driven Development

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.