Welcome to my Website/Blog

Well, hello dear reader. You’ve come across my little section of the Internet.

To start, my name is Sean M. Raleigh. I am a Computer Science Programming major at Worcester State University, a beautiful campus with  hardworking, smart professors and kindly students.

In this blog, I am going to post solely work related content, mainly at first just to keep up with my Robotics class, but other content related to my skills and accomplishments will show up here as well. I will review various methods for programming, working with robotics, and other Computer Science related materials. I hope to use this Blog for the purpose of education and the sharing of knowledge.

I hope you find my site pleasing to the eye and enjoyable to read. Have a great morning, afternoon or night, and I look forward to writing more!

Until we meet again, dear reader,

Sean Raleigh; CS WSU Student.

Image Credit: https://static.pexels.com — used for the purpose of review and education

Update on how Ive been

Hi everyone, Sean here again with an update on my progress in QCC. Everything is going well enough and I’m passing my courses with decent marks, so there is truly nothing to complain about on my end.

I just miss people from University but I still have some friends that have graduated and some still on their journey, as life goes.

I’ll make sure to write a more detailed post later on, perhaps on one of my other blogs! Until then take care and have a good day.

Detour: Studying at Quinsigamond

Hi guys. Its been a long while since I last wrote here.

So, the past few semesters at Worcester State University haven’t been working out all that well for me. I’ve been taking less classes per semester, and not passing each one. Me and my mom and Aunt (whom covers the cost of my tuition) decided that going for my associates and a certification from Quinsigamond would be the best course of action. This is because I will be able to get into the workforce sooner and save money aside while I decide whether to immediately go back into my bachelors program at WSU, or if I want to wait it out a year and see where I want to go from there.

Anyways, I’ve been brushing up my web development skills. I can properly program in html, css and soon enough I will be working on my JavaScript skills, too.

In conclusion, my time spent at Quinsigamond is just a small detour from ultimately obtaining my bachelors degree, but it is a useful detour nonetheless.

 

Thank you for reading!

Software Capstone: Refining the Intake Form

Welcome again to my blog;

Lately, we’ve been working to add missing fields and options into the Intake Form. The code necessary to run the server and open the form had been implemented long ago, so with that functionality taken care of, there has been a lot of progress in terms of how the page is formatted and what questions and information were required/optional for the user to input.

The most recent two changes have been the requirement of the pantry-goer’s zip code, and an optional field for gender. From there, the requirement for the persons annual income was implemented. Over the past few weeks there has been rapid necessary progress regarding the software’s usefulness and much of that progress has come in the form of our teams effort to finalize the form prior to May 15th, where we will present on the project in its entirety.

I am currently working on finalizing a change to the intake form where the user can check more Federal programs that they are participants in. Once that is done, there are about 4 other issues we have assigned to one another to take care of prior to the form being fully presentable. Other than that, it appears we have made great strides in how far this program has come ever since its inception. We started with a ground layer where a page could be run on a local server to instantiate the form. Now, we have a well formatted web page with an assortment of necessary questions and fields for the user to respond to, giving the Pantry workers the necessary information needed to run the Pantry.

I will write again soon, once more progress has been made. The semester is coming to a close soon, so there should be only two more posts until this section of my blog ends. Next time I will continue writing on about the progress of the code, afterwards I will write about the presentation we have coming up.
Until then, have a good rest of your day or evening.

-SMR

Software Capstone: Where We Are Now.

Hello again, reader!

Much work has been completed on the repository our professor has created on Github, initially moving our original files from Gitlab over. Now, it appears very much different than our original project our small team had begun working on this semester.

There is another separate team which has put in the time to help develop this project, leading to the software coming together more rapidly.

We have two repositories in Github. The one we are working on at the moment is titled “Theas-Pantry” and is the software which brings up the intake form through ones browser, run on a local server. To first make use of the code, one needs to use an Angular command (ng -serve) inside of a command prompt which has been brought to the projects directory.  The application will load into port 4200 on Localhost. From there the software is usable but is currently unable to store filled forms.

Instead of our project being organized into a src and server folder respectively, the code is now ordered in folders labeled frontend and backend, referring to how the code found within each folder is meant to function. The backend works to set up the server, whereas the frontend is the program which displays the intake form.

I believe that at this moment our project is much more organized and pleasing to browse. I’m happy we have some sort of prototype to show our customer and I’m relieved to know that this program will continue to be developed and improved long after this semester comes to a close. We’ve made much progress but I know the software could have more functionality or be expanded to work on a larger data set/flow (when the project is more widely used and there is a larger amount of food pantry users.)

With that set, our current sprint is under way and we still have plenty of work to do regarding components of the intake form, general features and one card functionality. I will write again once we make more progress.

Until next time;

-SMR

Software Quality/Assurance (8/8)

Topic: When a program becomes outdated.
Sometimes, programs lose relevancy; whether it is because new software has been developed that eclipse the capabilities of the older software, or because of a lack of developer interest, programs eventually become outdated or obsolete.
Take for example Internet Explorer. Internet Explorer was Microsoft’s internet browser developed for their Windows line of Operating Systems. From the first version of the program being developed in 1994, to the eleventh and final version released in 2013, Internet Explorer had a massive lifespan when it comes to computer programs.
In the year 2015, Microsoft Edge was released and is meant to be the replacement to Internet Explorer. This was the year that they simultaneously discontinued Internet Explorers further development, but (as part of their support policy) continue to maintain the software such that security vulnerabilities do not develop with exploits, glitched components of the software, or newer and more invasive viruses that take advantage of Internet Explorers outdated status.

In this situation, a long-time running program was made obsolete due to a newer program that did everything the older program could, and more, while having better performance in a consistently updated state. There are cases where programs can no longer be developed and are made outdated very quickly. Sometimes the developing company or programmers are put out of business. Other times, the outdated software is still used and dispersed from the company which created it – they simply provide no more updates (like an older version of an operating system which has been replaced by a newer build of the system.)  Besides the term outdated, old operating systems are referred to as legacy systems, when they are still quite often used (an older version of a Linux based system may be used on older computers when a customer cannot afford to upgrade to a new device, for example.) There are programs which are outdated and left to collect virtual dust, and then there are programs that people still use to this day despite the lack of official updates. Nowadays, software abandoned by its original developers can find developmental support from a third party, whether its a single person working to add new features and bug fixes, to groups of people banding together to increase the lifespan of a specific piece of software or product.

I hope that this series of posts has helped you understand the different aspects of Software Quality and Assurance. From development to the end-of-care state of programs, there is a lot that goes into the design and maintenance of software. Until next time,
-SMR

Software Quality/Assurance (7/8)

Topic: Software Versions (Pre-Alpha, Alpha, Beta, Release)

There are classifications that software falls into dependent on the stage of development it is in. In the Pre-Alpha stage, this is where the plans for the software are made and a general design is thought up.

During the Alpha stage, there is a working program (which is prone to bugs and crashes and, at worst, data loss.) Most developers test the Alpha program in-house or between the developers only. The inclusion of specific customers in testing the program is limited but some companies take advantage of user input in this stage of development

During the Beta phase, the program is essentially a fully function piece of Software. There is much less in the way of bugs compared to the Alpha stage, however many issues still remain prior to the Release phase of the software. Besides developers continuing to update and maintain the code within the program, there is often a presence of beta testers and beta releases which allow for a larger set of user input to be received. Bugs that developers were not able to detect during testing can be discovered when there are more people examining each component of the program. These kinds of Betas are known as Open Betas.

When software has reached its Release phase, all testing has been done and the code is considered finalized enough to be available for the Public to use/the Customer to use without worrying if the program would be prone to crashes and other errors. This is where the developers may continue to maintain the program and release updates to the final version of the software over a period of time (usually related to the performance of the software and minor bug fixes.) Development ceases on the software if a completely new version is to be developed or the project just becomes outdated.

I will finish this series of blog posts by covering when a program becomes outdated in the next post. I hope this post was of interest to you and enjoyable to read, until next time;

-SMR

Software Quality/Assurance (6/8)

Topic: Steps to creating quality software/Software Development Cycle

 

There is a general procedure to how software is created that can help assure that there is a baseline for quality – a plan for how the software should work, what functions it can complete, what the customer of the software wants and more. Out of six steps in the design process, three have to do with coming up with the design, and the last three steps have to do with implementing the ideas altogether and ultimately creating something useful.

The first of six stages has to do with planning out the course of development. With a good plan set in place, developers know exactly how the program should work and what steps/pieces of code is needed to accomplish the finalization of the software package. If one were to lack a good plan, progress might be made solely on a whim and a group of developers may not be able to work together as easily. Without a shared vision, developers may end up working on a portion of the project that is redundant or unnecessary. There may be times where they are working on separate portions of the project, making good progress, but with a good plan comes an easier development cycle.

The second stage begins and is still a part of the development process throughout the other stages: this stage has to do with analyzing the code/entirety of the software throughout the rest of the stages of development. With good analyzing skills shared across the developers comes a project that rarely has many serious issues in its development. Problems with the code will be pointed out and fixed more often if the team practices analyzing the code on a consistent basis. Without analyzing the code, unseen errors can build up and the format of the code could worsen.

The third stage has to do with the design of the project. This is where the structure and backbone of the software is created. With a good design, the system is easier to understand to the developers. With a poor design, pieces of code may be left in places they shouldn’t be, organization may not be up to par, and developers just will not have the ease they could have in making the project come to life.

The forth stage comes directly off the heels of the design stage, because this stage is where ideas are implemented into the design. At this stage, the software is starting to reach a place where it could be run and tested. It is evaluated to see if it is running correctly. The fifth stage requires enough implemented features to be able to run a prototype of the software.

The fifth stage is the testing stage. This stage is crucial in weeding out any errors and in helping the developers reconsider the design of the program during their next Sprint or development cycle concerning the software. Without good testing, the code could run improperly, creating false outputs or having code that could run much quicker than what is currently implemented.

Once the software is done being designed, analyzed, tested and with features implemented, the final stage begins: maintaining the software through its various releases. Once the software is released, it may still be in an in-development state (it may be an early alpha or a beta version of the code, not released officially.) The project needs to be consistently evaluated and code should be tweaked/deleted/created when necessary to further update the project and to be able to release newer versions of the program. Many, many projects – whether productivity software or builds of a video game – remain in this stage for a very long time, until the developers consider the software complete and in need of no further editing and maintaining. The game is released, the software becomes officially available to the public (not still stuck in the beta stage or earlier) and the developers can move onto different projects.

Following this set of events in order and with care helps the creators of software maintain the quality of the project. It is easier to develop on a project that has been planned out and tested throughout the implementation of features and design of the program as a whole.

The quality of the software can be assured through the careful execution of each step of the development process. Until next time,

-SMR

Software Quality/Assurance (5/8)

Topic: CppUnit in Microsoft Visual Studio

So, we have JUnit tests for Java files. But what about C++ files? What is a Unit test format we could use for this programming language?
One solution that appears similar to JUnit (in terms of how the code is formatted,) is CppUnit, part of the Microsoft Unit Testing Framework for C++.

In the header, you need to use #include to make sure you have the required files (one being your “CodeNameHere.h” file and the other being the “CppUnitTest.h” file.) With these files, you can write tests based on the CodeNameHere.h file. The test code would look like:
TEST_CLASS(UnitTestExample)
{
public:

TEST_METHOD(UnitTestMethod)
{
std::string animal = “Cat”;
CodeNameHere cnh(species);
Assert::AreEqual(animal, cnh.GetSpecies());
}
}

In testing C++ code, we can see that the form in which we assert whether something is equal or true (the method/function called towards the end of the test method/function) is quite similar to how we test in Java. Instead of assertEquals(variable, expectedVariable) in Java, we see Assert::AreEqual(variable, expectedVariable)

There are other Unit Testing frameworks out there for C++ code, but as the CppUnit testing framework is based off of XUnit (the same base that JUnit uses) I thought it might be more approachable a framework to cover. Thank you again for taking the time to read my blog posts, and I’ll see you again next time.
-SMR

 

Software Quality/Assurance (4/8)

Topic: What is JUnit testing?

JUnit is the most widely known testing framework for Java. JUnit tests typically are developed prior to the development of actual code. With the tests in place, the developer knows how the code should function (much like if an Interface class was created, outlining the needed methods of a class implementing the Interface.) Once code is written in the main class, the test class is run and will return true or false dependent on whether or not the main class functions correctly/outputs the correct data.

Who developed JUnit? JUnit falls under a series of testing frameworks known as XUnit, which was created by Kent Beck as part of his “Extreme Programming” form of project development. Extreme Programming is like a programming Sprint (much like in my Capstone course.) There is a focus on multiple shorter development periods, communication between peers/colleagues, and (of course) testing.

Why use JUnit? Well, all of the code is ready for use when one implements JUnit into their Java project. You do not need to write your own code to test your main code; you have a system already in place that gives you very useful methods and an easy-to-learn style of testing code. For example, you can assert the following:
1. That a boolean value comes out A: True or B: False.
2. That an object or variable is Null/Not Null.
3. That an object or variable is the same as what is to be expected (same object as another, same variable as another.)
4. That an array is or is not the same as another.
5. If objects are exactly the same.

With the assortment of assertions that can be made, there is much flexibility and verticality in the ways code can be tested. Thank you for reading my post, I will see you next time!

-SMR

Software Quality/Assurance (3/8)

Topic: Main classes VS Test classes

In Java, the project in the file system is set up in such a way that there are two separate directories for code to be put into. The file directory looks something like (src/main/java) for the main code, and (src/test/java) for the testing code. The testing code should be developed first to outline how the main code will function.

In the main java folder, one would save their java classes, the classes of which are the main program and where most time is spent (the code takes longer to develop in comparison to test code, in most cases.) If you have a file, student.class, in src/main/java, then there would be a corresponding class named studentTest.class

The student class would be responsible for storing a students information. The testing class may create a student object with assigned variables, then use one or more of the assertEquals() function to test for valid input. If the students variables match up with the expected variables, the test passes.

You may have another class, course.class in main and courseTest.class in the testing directory. One could imagine what types of methods in course.class would be used (course name, course ID, course professor – where professor could be another Java class with a professorTest class to follow.) You can make many assertions in a test case that could check on the validity of the classes output and furthermore outline any errors there may be.

Thank you for reading my post, I will see you again soon!

-SMR