Author Archives: houtyr

2# Software Design and Construction

Coding Blocks – Design Pattern- Episode 2

I think this was one of the podcast episodes I was really excited to see. The topics was design patter so I figured I would hear things and concepts I was familiar with and also serve as a measure for me to test what I knew and how in-depth I could follow the episode. Right off the bat, they begin to talk about the absence of design patterns in their curriculum when they were in school. This made a light bulb go off. Meaning I am technically ahead of that era in terms of the tools I am being provided in school to better succeed in the real software construction and development world. Joe Zack also mentions that he knew the big O notation for the entire basic sorting algorithm, which is something I am also familiar with. I am currently an expert at the shell-sorting algorithm. With all the things they were talking about I was able to face reality that I am not really too far away from being a developer on a software development team. Also it demonstrated how much the field of software engineering has changed. It’s crazy for someone to graduate from computer science and not know what design patterns are in today’s world. All projects and programs   today utilize design patterns to create a hierarchy of classes comprising of parent, children, abstract and class interfaces. This helps organize and makes thing more legible for the next programmer that is hired to “maintain” the program. To become a great programmer, one need to develop great design and organizing skills that can be translated into project design patterns. Again Design pattern can actually be divided into three (3) categories.

 

  1. Creational Patterns. (Factories, Builders, Prototype and Singletons)
  2. Structural Patterns. (Adapter, Bridges, Flyweight, Proxy, etc.)
  3. Behavioral Patterns (Observers, strategy, Chain of responsibilities, etc.)

 

This I did not know!

 

Creational Patterns: They help encapsulate the logic of creating classes in a more separate class where classes are created and represented outside the logic that utilizes the creational pattern.

 

As the discussion got deeper, I noticed that most of these guys recording the podcast have done tons and tons of projects that utilize some of the concepts they are talking about. Right of the bat, I got the initiative to start a project and try to use and implement as many new concepts as I can. Because after all, the best thing you can do for yourself as an upcoming developing in school is to start many projects on your own and try implementing new things you learn and read in school because in the worst case, you familiarize yourself more with topic and concepts that get taught in class.

 

Link

 

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-11-design-patterns-part-1-you-create-me

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.

QA & TESTING – Episode 1

AB Testing – Episode 1 by Brent Jenson and Allen Page.

In this weeks testing episode, I went back to episode 1 just so I can address topics that Allen and Brent found necessary to start their testing podcast episodes with. Both Allen and Brent are high-end software developers and testers who worked for many big companies and performed many big tasks in the world of software developing and testing. Allen page was a software-testing manager who contributed to many books in the world of software testing. (His books are really good if you wanted any information of software testing). Brent Jenson also worked for Microsoft for over 20 years and accumulated many experience holding the position of software testing Director. They continued to talk about a presentation method used at Microsoft which I thought would benefit the software testing industry should we all decide to utilize it. They called it the Lean coffee lives. As comical as this sounds, lean coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. These agendas are often address to things viewed as highly important and then goes all the way down to items on the list, which is viewed, as less important. So this sounded like something we can bring to our Testing Team meetings!! As quickly as the podcast began, Allen began to dive into real Software testing concepts. He began by emphasizing the great difference that lies between testing and quality. With constant changes and improvising’s, system and program bugs quickly lose values. Finding bugs on constantly or sometimes daily changing software does not constitute to the quality level of the software product. This is because today’s bug can be fixed in tomorrows code implementation and that can also create a new bug that could be fixed with the next program/code modification. Now here is the case that is it the Job of software testers to find bugs and errors in the program. Now it’s the job of a test manager to schedule test runs and passes for the specific product in development. How do you think a test manager could work successfully an environment where code changes and modifications are being made on a daily base? The proposed solution goes back to the beginning of the project where planning and thoughts have to be put in place. To put forth a great product, time allocation for testing has to be incurred in the project timeline. You can put out quality without considering all aspects of possible challenges and inputs.

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.

I for Interface

Coding Blocks – I for interface- Episode 1

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. I think I am really going to enjoy these podcast episodes because they began by talking about things that I could relate directly to. The three presenters started this episode by defining what an interface is to them. Although I have an understanding of what an interface is, hearing what is means to professional programmers gave light to some different ways of looking at what an interface is. My favorite was “ An interface can somehow be seen as the guard rail on the highway”. I think I “vibed” the most with this definition because that along the lines of what I see an interface to be. After several definitions, the question was then asked what the difference between an abstract class and an interface was. It was at this point that I realized I might have pushed the definition of an interface too far but luckily, this podcast straighten me out. The presented settled on the definition that an abstract interface contained more information and made allocations for storage unlike the interface, which just provided guides for what is to be implemented. The abstract class provided guides and instructions and also storage allocations for the type of data or information to be implemented. Wow!

Again the discussions progressed rapidly, it was discussed that an abstract class has to be inherited but an interface must be implemented. An abstract class can’t be instantiated but needs to be inherited. I thought this topic was very important because I recall the first couple of classes, we often found our selves lost in discussions to try and understand the differences and functionalities between these programing concepts. For best practices, it was mentioned that foregoing naming conventions in interfaces sometimes makes it easier to read and also utilizing underscores would group the abstract classes in the top of the file directories when looking at the directory tree structure. Also, they did advise to also prefix all interfaces that we create with an “I” so that everyone that looks at the program will know what it is. Didn’t know that was the standard in the real world.

“You can’t define constructor methods in an interface” – This means we can’t create an interface that informs the classes that are to implement the interface how those classes can be implemented. Again this is a confusing statement but by pondering on it for a few hours, it becomes pretty clear. Instead it makes sense to utilize a base class. Overall this podcast has a lot to be learned from it. They really emphasize on explaining technical concepts and terminologies. Will be posting a different episode next week.

 

Link – Episode 1

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Le Blog Spot 2017-10-16 19:24:48

Week 5

AB Testing – Episode 68 by Brent Jenson and Allen Page.

 

-In this episode, Brent and Allen begin by talking about their stressful lives as software QA engineers. Working late hours and trying to stay up to date with the latest trends in the industry. From this brief intro I was able to get look at the potential challenges that exist in the field of Software testing. One needs to have the ability to be able to learn and implement new technologies regardless of how qualified or advanced one is at software QA and testing. As the podcast continues, allan talks about his position and how much work goes in to generating and creating substantial testing procedures that gets the job done and optimizes the testing process. To me, a student majoring in Computer science with a focus in software development, it’s easy for me to understand and know what Alan is talking about. Due to my class studies, I understand the importance of software testing and how a bad-testing process can be of little to no value to a product whiles a good testing procedure can make or break a product. HE emphasized on all the intangibles that only a person in the industry could understand and enumerated on how useless his positions appears to be to the average person. Brent expands on this topic by saying that organizations generally see the QA department of organizations as a cost for the organization without realizing the true benefits of this department. They are often not given the credit when things are going well and consistent but they are often the first department in software industries that deals with layoffs and budget cuts should there be a need for cuts.

With this topic both Allan and Brent went off on a tangent and began comparing and contrasting Traditional testing and modern testing. Prior to this podcast, I didn’t know there were “traditional testing era” and   “modern testing era”. According to them, the old way of testing followed the following sequence. Requirement => Design =>Code & Build => Testing => Maintenance whiles the modern way of testing follows the following sequence.

Requirement => Testing => Design => Testing => Build & Execution => Testing =>Test => Testing => Installation => Testing => Maintenance => Testing.

As we can see, the modern way implements more testing stage with might appear to be more costly that the old way but overtime saves more and enables modulation of components. The software gets built by parts instead of one giant big project.

LINK 

https://testingpodcast.com/category/ab-testing/

 

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.

Week 1 Blog Post

Hi Everyone ,

 

The name is Kwame Degraft Ofori. I am possibly a senior , well i was a transfer student so my credit status is kind of complicated. Anyway , i am currently taking CS-443 and CS-343 both with prof. Worst.   i hope to learn a lot from both of these classes and lot forward to a bounteous semester.  Goodluck ! 

From the blog CS@Worcester – Le Blog Spot by houtyr and used with permission of the author. All other rights reserved by the author.