In the Computer Science track at Worcester State, and as a prerequisite to this course, students have to take a Database Design course that teaches SQL. Because of this, before this course, when databases were mentioned, it typically invoked thoughts and memories of SQL queries and database management using the SQL language. However now, the project being made works with the use of MongoDB, a NoSQL database management system. This made me curious about the differences between managing databases with and without SQL and when it is smarter to use each.

I watched a video called, “Which is Better? SQL vs NoSQL”. The key point I took away is that SQL is a relational database whereas NoSQL, such as MongoDB, is a document database. The key differences being that relational databases store information in tables with keys whereas document databases store information in documents with JSON data. One main benefit of a document database such as MongoDB is that it is much easier to store unstructured data. This adds flexibility at the expense of being able to use simple commands such as JOIN which can be used in SQL. 

Another core advantage of NoSQL databases is that they can handle having multiple people connected to them at the same time. SQL databases on the other hand do not manage this well. This fact gave a lot of clarity as to the usefulness of using MongoDB over something like MySQL for the purposes of Thea’s Pantry.

The video also mentions that NoSQL databases are better at scaling across different servers which can be useful if we need to write information across multiple platforms and in many places.

Overall, from what I understand, SQL tends to be stronger for performing more in depth and informative queries on a set of data, at the expense of requiring the data to be organized and consistently formatted. NoSQL, on the other hand, does not have the inherent ability for users to submit queries on the data but it allows for lack of format and consistency and that leniency provides more flexibility for data storage. 

The ultimate conclusion was that both SQL and NoSQL databases are powerful in the hands of the right user. While they each have their strengths and weaknesses, they are similar enough to allow users to perform most of the same tasks on either one and that allows developers the freedom to choose the database that they are more comfortable using for the purposes of any project.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

For the last homework in the course, we were assigned the task as a group to create a lesson plan for the class to do and put it in a POGIL activity. My group sat for a while throwing around ideas before I came across something called testing smells/code smells. Testing smells, also known as code smells, which refer to issues and/or warning signs in an individual’s code that won’t necessarily throw an error or cause the code not to run but likely leads to some bigger issue that would cause fundamental problems in the code. 

Code smells come in all shapes and sizes and often seem harmless or meaningless such as reusing variable names, repeating lines of code, hard coding data and more. Testing smells typically refers to code smells that occur specifically in the testing files. These mistakes affect the validity, functionality, and reliability of a test. 

Since the whole purpose of testing is to check for problems or potential issues in the code, testing smells is a serious issue that is worth learning about. I watched this video on youtube called, “a few common code smells to be aware of and how to fix them”. 

In this video, the individual talks about how testing smells can often point to bigger problems in the code which are important to pay attention to. The first code smell that is mentioned in the video is long functions. The video explains how long functions may seem harmless at first, especially to programmers that are first starting out, but the purpose of a function is to perform one task simply and directly. Long functions often do more than one thing, making them complex and convoluted, therefore more prone to causing bugs in the program. This also makes them more difficult to maintain and to fix.

Another testing smell mentioned is duplicate code. Duplicate code is another testing smell that seems harmless because from a technical standpoint, although a tedious task, does it really matter if you rewrite the same line 30 times? While it is true that if you do this perfectly the functionality of the code shouldn’t be affected, the code will still become messy and unreadable. Additionally, repeating code in this manner increases the likelihood of making a mistake. Turning repeat code into a function or having them inherit from a shared class not only improves cleanliness and readability but prevents simple and clerical errors that would cause frustration at a later point in the coding process.

Overall, Testing smells is something that I believe is an important subject matter worth learning about in order to improve coding ability both on a personal and professional level.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

After learning about test driven development in class a couple classes ago, I found myself confused as to why this process would prove itself successful in software development so I did some research and found a video on YouTube from a channel called Fireship called, “Test-Driven Development //Fun TDD Introduction with JavaScript“ While, of course, JavaScript is not currently one of the programming languages that I primarily work with, the video proved informative and educational nonetheless. The video begins by emphasizing the importance of the phrase “Red, Green, Refactor” and describes test driven development as a technique where a programmer describes the behavior of the code before proceeding to implementing that code. “Red, Green, Refactor” describes the process of, firstly, writing a failing test, then writing some code to get the test to pass, then going back and optimizing the code in a manner that suits the project requirements. 

Although I have no doubt that the majority of the confusion around this topic comes from inexperience and being in the process of learning, I certainly had questions and confusion around how and why it makes sense to put forth an implementation process for code before even writing a single line. Conceptually it makes sense to lay out the general steps to a project and attempt to anticipate some of the issues that may come up beforehand, but something about testing code that doesn’t exist is a confusing concept for me.

The video talked about different types of testing at the different levels starting with unit testing and working into more complex testing methods. Each testing method is built to cater to a different type of program that is being tested.

Generally, after watching this, it sparked curiosity around what software development would look like without testing and how the continual development of the testing process has allowed for programers to not only improve the way they work but to create more robust and successful outcomes in the results of their code. 

I think it’s interesting looking back at the first three or so years of computer science classes, learning to code in multiple different languages with different use cases and styles and intents and outcomes. Not one class between the two schools I went to and the three years I was in school worked with testing before the higher level senior year classes. This made me wonder why something so important and integral to software development such as testing code was left out of the learning process until very late.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

There is a video on YouTube from a channel called The Digital Project Manager about Project Management called, “Agile project management methodology explained (with burgers?!)”. This video talks about Project Management, a topic from our course, but more specifically, agile project management. I found this video particularly educational and informative because instead of explaining agile project management in typical terms, the methodology is described using burgers. The video explains that agile project management is all about flexibility and adaptability. The agile project management style runs through multiple cycles of project production and release, taking feedback and input from the customer and users after each release cycle. This is a very effective and efficient method of project management because it allows a smooth flow of progress while making a more accurate product based on the customers’ desires. The way that the video compared this method of project management to burgers is by suggesting that there could be a goal of making the world’s best burger and in order to do that the chef would have to make a burger, get feedback from those who try it, then make changes to the burger in order to improve it. Agile project management implies that after every round of changes, the product should (hypothetically) get better and better. This made me wonder, in a professional setting, how each of these phases of the project would be tested and improved. Further, at what point could the project/program be determined as complete and who has the authority to make that decision? Agile project management is also inherently iterative. This means that multiple iterations or cycles can be completed throughout the process of completing the project. This method is particularly successful with dynamic projects and environments such as game development and software development because the requirements for these types of projects tend to be constantly changing and developing. Agile project management is also a more flexible form of project management. Because multiple cycles of development will occur, not all of the planning for the project has to be done prior to the developing stage of the project. This allows for more flexibility and a more robust and high quality product to come out of the process. During agile project management, each sprint can be broken down into five parts: Define, Craft, Develop, Deploy, Evaluate. The evaluate phase is what allows for this method to be iterable and flexible to multiple rounds of work.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

I happened to stumble across a YouTube video by a channel called Licenseware by the title of, “A Brief History of Software Licensing – Why it exists, and why it is so important”. This video covered information about how software licensing came to be, how it is used, and why it is important in the world of software and coding. The video explains how our world has developed to become, ultimately, reliant on software for organizing and controlling everything from transportation to communication. Because of all of this, the software industry has gained many rules and regulations around when, where, why, and how software can be used. These rules and regulations are more commonly known as Software Licenses. Software Licensing is one of the topics we covered relatively early on in our course, going over the different types of licenses and their uses as well as when and in what scenarios they worked or didn’t work. The history of licensing stems from the history of copyright which came from The Copyright Act of 1710 (The Statute of Anne). This act, passed by the British Parliament, stated that authors had the right to publish and sell their work for a renewable period of time. This is relevant because Software Licensing falls under the category of Copyright Law. This is because software is ultimately seen as a type of literary work. The video goes on to talk about how the Free Software Foundation (FSF) introduced the concept of open source software which led to the development of the open source software movement and the creation of the General Public License. I found this video very interesting because, prior to watching it, I hadn’t realized to what extent and depth software licensing was similar to and fell under the umbrella of a legally documented copyright. This confusion came from the fact that open source software creates an atmosphere of open communication and sharing that doesn’t typically appear in other copyrighted pieces of work. I find it interesting that software seems to be the only field, at least to my knowledge, that has this type of sharing of information and work between other users and developers. The collaboration between maintainers, leaders, collaborators and users allows the field to expand and advance quicker and more efficiently than other fields. This video helped solidify my understanding of different licenses and the importance of not only having an active license in place but also the correct license in place. This also gave me a better concept of what to do in the future if I should choose to post any of my code online as open source material.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.

This is my first blog entry! This blog will encompass the information I learn throughout my journey to achieve a degree in Computer Science. It will also contains some of the struggles, the conversations, and the growth that I experience as a minority in the field.

As a Middle Eastern Woman in a male dominated field, there have always been struggles with exclusion, micro aggressions, and passive aggressive views towards women not belonging in the field.

This blog will aim to destigmatize the idea that women don’t belong in the tech industry and shine a light on some of the discriminatory behavior that women in STEM experience in the classroom setting.

From the blog CS@Worcester – The Struggle of Being a Female Student in CS by Noam Horn and used with permission of the author. All other rights reserved by the author.