Stylin and Profilin

As I finished up the back end part of my project, I Knew I would need to figure out some HTML and CSS because I wanted my site to look good and I haven’t done HTML or CSS since a class I took in High school. Since most of my college coding has been back end stuff I needed a refresher and to look for things similar to what I wanted on my website and to figure out how to adapt them to work for me. Things that i wanted where to display different information at different places, create a better layout for the website, a search bar and, of course, stylish buttons. There was alot of helpful code examples for what I wanted to do for my website which made the process easier. One thing I knew i would need to do was create a border for the news posts since the pictures and text would scale and stretch to fit the whole screen. Once I created a margin for the posts the images and text looked alot better. I decided to bold and make the title font bigger than the description since I wanted to draw the user’s eyes when they read the posts.
I used material classes from angular to make the process of styling even easier and through css i created a better looking website by customize each individual class. I had a search bar and a button to search by source which looked a little to basic so i customized the buttons to be blue, have white text, and when you hoover on it, it places a shadow behind the button. I also made a reset button to return to the “home Page” after a search by source and made the button uniform with the search button.
Lastly I created a list of sources that were all interactive buttons that had the same style as all the other buttons on the website. I wanted to make this list a drop down menu or something that would only appear on the side if you clicked on another button instead of being constantly there, but I did not have enough time to implement this addition to the website. Overall this learning of CSS and HTML was really fun and helped me to realize that this is how I am going to be learning other coding languages in the future and applying them as needed.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

The Key to Apis

I was searching for a good api that did not require a key to use since i had no idea how to use one or how long it would take to get one. I searched and searched but I was unsuccessful in my search and ended up looking for one that had a key and an easy process to get that key. when i found the newsApi and it said all you needed to do was give an email address and sign up to get a key, I was ecstatic at the simplicity. After I got the key, I needed to figure out how it worked and what I should do to make using it even easier. I decided like most people on the internet chose to do and save it as a string called api key and passed it at the end of each api request.
I assumed that api keys were used to log what people do with the api and at what times for both security and to keep track of the usage of the api and I was right. Api keys are important for any api to use to keep spam and other malicious users from constantly requesting from your api or server and causing a denial of service. since the people who made the api have access to the keys, they can shut a key off if it request too many times in a certain time frame. I noticed, in my search for an api, that many of the apis had strict rules about how many times you can request in a time frame. The api i was using had pricing plans for different number of requests and how far back you could request articles and how fast they would load. The one i was using was free and allowed me to request 500 times a day which was more than enough for me to show off what it does and test it. The other plans costed 449 dollars a month and 849 dollars a month. these kinds of api that are hosted and easily accessible have the ability to make a lot of money. The other thing I noticed was that they didn’t allow it to be used for commercial use which means if you pay for the larger plans you would be just pumping money into the service without getting anything back.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

The Flavors of Software Testing

Recently I took a final in my Software Quality and Assurance class. While I think the final went relatively well there was one question that has been haunting my dreams, hiding in every dark corner of every dark room I find myself in. The question was one so simple yet for reasons unbeknownst to me, I froze. A concept that, at a former point in my life in the not so distant past had been second nature to me. The question was “What is the difference between static and dynamic testing?” Since I failed myself and my professor on that test I felt like I should use this blog as a way to freshen up my understanding of both types of software testing.

I found myself seeking elder guidance on the matter and landed at the doorstep of Lakshay Sharma on the ToolsQA blog. A very short and simple read later I felt the rush of knowledge come back to me and I feel comfortable that I can talk on the matter of static vs dynamic, white vs black box testing. The blog made it very easy to understand the concept because it is laid out in a simple format: the first section explains static testing, and the second black box. After both sections there is a small graphic that shows the differences between the two. So, what is static testing anyways?

Static testing refers to software testing that is done without running the program. This testing is also called white box testing and is done prior to running the code and can help sort out a multitude of issues within the program. Things such as code structure, and code pathing can be tested at this stage and without the use of unit tests. This type of testing is beneficial because it forces developers to take a step back and review the code they are writing. If you’ve ever gotten into a groove while programming and then taken a step back to see the mess you just created you would know why static testing is such a good tool to have in your software testing tool belt. Static testing is full about preventing errors in the first place, and as the age old saying goes: an ounce of prevention is worth a pound of cure. While that prevention is great, in the event that you do get sick, you are going to want that cure as fast as possible and as strong as possible to get you back on your feet. This is where dynamic testing comes in.

Dynamic testing is the act of testing code while its running. Although while creating dynamic tests you may be able to see the code, dynamic testing falls under the umbrella of black box testing because the tests themselves do not care about the inner workings of a program. Dynamic testing tests behavior such as input/output. The good thing about black box testing is that tests can be written prior to developing code and give programmers an easy way to determine if a program is working as intended. Dynamic testing requires more time to set up than static since it involves actually creating test cases.

Just as life is made up of thesis and antithesis and one cannot exist without the other, static testing and dynamic testing go hand in hand and to use only one is to cheat yourself of the best possible work you could be producing.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Good Code Reviewing

For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.

In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.

Articles Referenced:
https://www.michaelagreiler.com/code-review-blog-post-series/
https://www.michaelagreiler.com/code-review-checklist/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Junit 5 testing & testing with lambda expressions

hello all so in my software testing class I have learned about using junit 5 and using lambda expressions to test for exception throwing. I had used junit 4 before I learned this and I liked the way junit 5 makes it easier to make and test classes. I had an assignment to do testing an order system. I used the repeated test for testing auto incrementation. I also used lambda expressions to test for expressions and this was a ton easier then it was with junit 4. Below are two examples of the tests I wrote for that.

From the blog CS@Worcester – Tim’s Blog by therbsty 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.

Final Presentation Eve

With CS 343’s final presentation tomorrow, this will be the last post for this project. (Unless I choose to keep playing around with it later) The work on this project has really helped me learn HTML, CSS, and TS.

The newest feature I added to my Pokedex SPA was having the background colors linked to the selected pokemon’s typing.

This took a bit a time, figuring out how to dynamically link the HTML background color to the TS pokemon data. I eventually found the use of angular’s [ngStyle] to be very useful. This method injects a JSON object with CSS properties defined in it. With it, I simply used a method in the TS to grab the pokemon’s typing and return a created JSON object with the CSS property ‘background’ with either a solid color for single typing or a gradient for dual typing.

This project was a lot of fun and I’ve learned a lot. I am tentatively looking forward to tomorrow’s presentations.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.