Tag Archives: CS-348

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Using environments to develop software

Different environments in software development, outlining the roles of Development, Testing, Staging, and Production environments.

So you want to get started with developing a piece of software but aren’t quite sure where exactly you are meant to do that. Well luckily for us we have environments created specifically for developing software.

Introduction to development environments

Put simply, it is an environment which provides developers with a workspace that features programming software and other resources and processes required to develop source code for an application.

Some key components of development environments can include:

  • A physical or virtual machine, including an underlying operating system, database system, and so on.
  • Development tools, including development environments, compilers, and libraries.
  • Data management solutions
  • Associated services, including internally hosted resources and external environments, such as those running in the cloud.

Environments must be able to support a few things like:

  • Writing code
  • Debugging
  • Testing
  • Version control

The importance of these environments

All developers can find benefits to using these environments. It helps improve productivity, stability, reliability, and more towards development. The usage of these environments speaks for themselves as to just how beneficial they truly are to software developers.

Integrated development environments (IDE):

An overview of Integrated Development Environments (IDE), highlighting key features like writing, debugging, and running code.

IDEs are a very popular form of Software development environments. Some popular IDEs, a few of which you have almost guaranteed heard of, include:

  • The JetBrains environments (CLion, GoLand, PyCharm, RubyLand)
  • Visual Studio
  • Eclipse
  • XCode
  • Android Studio
A bar chart displaying the most popular integrated development environments (IDEs) from 2004 to 2019, highlighting Android Studio and Visual Studio as top choices.

What makes these environments to attractive is that they are fairly user friendly, with a little practice of course, and paired with the fact that they can be extremely customizable therefore giving a software developer the freedom to focus on other things related to their developments.

Final thoughts

Doing my research in development environments taught me just how many different development environments there are, all useful in their own respective ways, and many open-source as well. I am used to using a few IDEs like Eclipse for Java development or Visual Studio for general development but expanding my knowledge of environments is very useful for specialized projects. If you wish to learn more I would highly suggest reading this article from devzero.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

More on Clean Code

For this quarter’s blog, I decided to research more into the book Clean Code by Robert C. Martin and found a blog discussing the good, the bad, and the ugly regarding the book. I chose this article because we have spent the last few classes working through POGILs related to the book. The author writes about how Clean Code has had its positive and negative impact on software development. For new programmers, the author highlights useful practices that are good for new software developers, such as good naming techniques, not repeating your code, and having functions only do one thing. On the other side, the author describes how the age of the book and its dated techniques can be considered obsolete. Clean Code was written over twenty years ago and is heavily focused on Java programming and outdated extensions that “[limit] the applicability for modern programming practices.” Another criticism by the author is that applying the rules of the book all the time can result in harmful code, such as excessive abstraction and code that is harder to maintain over time. The author argues that programmers should learn when these rules should be broken and apply them on a case by case basis.

This article was certainly helpful to give a further opinion on Clean Code and its subject matter. After going through the Clean Code POGILs in class, I had learned many things that I was not previously taught about programming. They were helpful to correct some bad practices that I was guilty of, such as commenting in place of poorly written code. However, some topics, such as the levels of abstraction or how to use classes and methods properly were initially confusing to me. It seems like the author also expresses similar frustrations in regard to these things. The author of the article describes any of the things from the book can be described in one phrase: “it depends.” Overall though, I felt it necessary to dive deeper into Clean Code for my own benefit. Even though I do not plan on pursuing a career in software development, many of these rules and structures can be applied to other disciplines within computer science and information related fields. When the time comes for me to work on a personal project or something needed for my career, I feel better equipped to handle such a task knowing what I know now. Even if some of the advice is dated, most of it can still be applied and result in better software development.

Original blog post: https://gerlacdt.github.io/blog/posts/clean_code/

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Importance of version control in the process of development

An infographic illustrating version control processes in Git, showcasing key operations like fork, merge, and pull request.

As a software developer version control you will undoubtedly run into version control of any projects which you are working on. Eventually a developer will have to fix bugs or add a feature to a product. In order to learn more about version control there is no better website to learn from than Github.

What is Version Control?

Illustration of distributed version control system showing interactions between developers and the main repository.

Github gives an amazing allegory: Imagine you’re a violinist in a 100-piece orchestra, but you and the other musicians can’t see the conductor or hear one another. Instead of synchronized instruments playing music, the result is just noise.

Version control is a tool used to prevent this noise from happening. It helps streamline development, keep track of any changes, and allow for upscaling of projects.

Version Control tool factors

Version control may not be necessary depending on the scale of your project, however most of the time it is useful to have it set up. Some of the factors of deciding to use version control include:

  • Scalability: Large projects with many developers and files benefit from VC
  • Ease of Use: User friendly UI helps manage learning curves and adoption.
  • Collaboration features: Supporting multiple contributors and communication between them.
  • Integration with existing tools: Using tools everyone already has access to.
  • Supports branching: Ability for developers to work on different parts of development benefits a project greatly.

Common Version Control pplications

  • Git: Git is an open-source distributed version control tool preferred by developers for its speed, flexibility, and because contributors can work on the same codebase simultaneously.
  • Subversion (SVN): Subversion is a centralized version control tool used by enterprise teams and is known for its speed and scalability.
  • Azure DevOps Server: Previously known as Microsoft Team Foundation Server (TFS), Azure DevOps Server is a set of modern development services, a centralized version control, and reporting system hosted on-premises.
  • Mercurial: Like Git in scalability and flexibility, Mercurial is a distributed version control system.
  • Perforce: Used in large-scale software development projects, Perforce is a centralized version control system valued for its simplicity and ease of use.

Final thoughts

Every developer has at one point heard of Git, and without a doubt it may be one of the best developer tool ever invented. I have prior experience using version control but this research was an important refresher to learn from. If you wish to learn directly from Github you can read the article this blog was inspired by here.

From the blog CS@Worcester – Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

More Information on Agile and Scrum

I decided to write this self-directed blog entry on an article I found regarding information and differences between Agile and Scrum, two topics we have recently been covering in class. I sought to learn more about these two topics, as I was not entirely confident in my understanding of them. I unfortunately was absent due to an illness on the day we covered the Agile methodology in class, so in order to get a better understanding on the topic, I went through the activity and learned more about it on my own time. This article summarizes what Agile and Scrum are, their differences, the core Agile values and principles, the basics of Scrum, and when and how they should be utilized. This was quite a thorough read and was very informative to reinforce what I had learned from the class. One thing that I did not immediately connect from class was that Scrum was based on the Agile philosophies. As best said in the article, Agile is the guiding principles to shape how you work, Scrum gives a structured playbook to follow.

Though I do not plan to go into software development as a career path, I think this is still a beneficial way to learn quality teamwork and collaboration. Regardless of concentration or field of study, computer science and information systems related disciplines require efficient teamwork and collaboration. Working professionally in the field for four years now, there has never been a project or major task that involved no one besides myself. I always had to work with different teams to accomplish the final goal that was needed. Learning this framework could be very beneficial for me moving forward so I can apply it to my future professional projects. Having better tools almost always leads to a better job done, and I always strive to improve and better myself as a technology professional.

One discovery made from this article is that there are other common implementations of Agile outside of Scrum. One of these, I recognized from my professional experience, as my current organization requires all full-time staff to participate in Lean training. I was not aware that Lean training, which according to the article, “aims to eliminate waste and maximize customer value by focusing on efficiency and continuous improvement,” was an extension of the Agile methodology. This is critical, especially in the healthcare environment that I work in. It is an everchanging field and an environment that can change drastically within a matter of seconds. Though I am not a full-time employee and have yet to participate in that training, I will participate in it once I resume full-time work permanently at the end of December 2025.

ZG

The link to the blog post: https://monday.com/blog/rnd/agile-vs-scrum/

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Team management in software development

As a software developer there is a significant chance that you will develop software in a team environment. I know as an entry level developer gaining this experience beforehand would be a massive boost for my career but what exactly does team management entail?

The importance of team management

In a perfect world a team of developers all work perfectly together synchronously & complete a task in the best way possible. In reality, each team will have people of different skillsets, creativity, and ideas for development. Therefore, teams need to be managed in order to optimize development as much as possible.

Diagram illustrating the roles within a software project development team.

Creating a team

Before assembling a team for a project its important to highlight the scope & needs in order to figure out how many, and the type of, developers. According to itrex, some examples of developers you may need would be:

– Software Developer: Engineers and stabilizes the product & solves any technical problems emerging during the development lifecycle
– Software Architect:
Designs a high-level software architecture, selects appropriate tools and platforms to implement the product vision, & sets up code quality standards and performs code reviews
– UI/UX Developer:
Transforms a product vision into user-friendly designs & creates user journeys for the best user experience and highest conversion rates
– QA(quality assurance) Engineer:
Makes sure an application performs according to requirements & spots functional and non-functional defects
-Test Automation Engineer: Designs a test automation ecosystem & writes and maintains test scripts for automated testing
– DevOps Engineer: Facilitates cooperation between development and operations teams & builds continuous integration and continuous delivery (CI/CD) pipelines for faster delivery
– Business Analyst: Understands customers business processes and translates business needs to requirements.
– Project Manager: Makes sure a product or its part is delivered on time and within budget & manages and motivates the software development team
– Project Owner: Holds responsibility for a product vision and evolution & makes sure the final product meets customer requirements

Infographic illustrating the challenges of managing software development teams, including communication, role clarity, and meeting deadlines.

Post-team assembly

Depending on your project you now have an idea on what team you have, the next step is actually managing them. This entails setting clear objectives/goals, creating a timeline, allocating resources, setting communication strategies, delegating, implementing, tracking progress, monitoring project, managing risks/challenges & maintaining flexibility.

Overview of a project manager’s essential roles and responsibilities in software development.

Final thoughts

I now have a better understanding the importance of team management in software development. In order to maximize efficiency towards a project/goal you definitely need to manage a significant amount of aspects related to development. The ability for a team to work together is also valuable & must be taken into account. Overall, I really enjoyed researching this topic, the main sources I used in my research was this section in Atlassians website as well as this section in the itrexgroup website.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Why Clean Code is so Important for Workflow

When coding there are a lot of factors to consider, the time complexity of your algorithms, the space complexity as well, and even power efficiency can all affect the decisions you make and the flow of your program. It’s a complicated task and with constant distractions in our ever-growing busier and busier lives the need to make the coding process as quick and easy as possible is constantly present (of course it almost never is quick and easy).

One way that we can optimize our time effectiveness is clean code. What is clean code? As Thiraphat Phutson puts it in his blog, “The Art of Clean Code: Writing Code that Lasts“, it’s code that’s easy to understand, maintain, and extend.

There are plenty of aspects to writing clean code such as using good naming schemes for variables and functions, proper spacing, consistent indentation and bracket use, the list goes on and on. And just like there’s many aspects of clean code there’s plenty more attributed to “messy” coding.

So how does clean code apply to me? As a major in computer science the ability to code is almost the entire point of my degree. Learning how to keep my code clean and organized, making it easier for myself to understand if I ever need to come back to it as well as fellow team members and coworkers is incredibly important.

As I’ve mentioned my honors project in my past few posts, I’ll mention it again here. Although as I’m writing this my project has been submitted and is officially done in terms of what my professor will see for now, I’m not done with it. In fact, I’ve barely begun. Most of my honors project was geared around performing my own sprint for a product I’ve chosen to create. In the first sprint I completed almost no coding got done, most of it was setting up to be able to start programming the project.

This is where I can take the clean code skills I’ve acquired, and make sure that as I’m coding what I can only imagine is going to be a very complex project I’m keeping it organized and efficient. As Phutson mentions, clean code allows for maintainability, scalability, and efficiency, all things I’ll need for my project. He also mentions collaboration which is another fantastic aspect of writing clean code, but it doesn’t apply as much to my case with me being the only developer.

Clean code is an incredibly important skill to have in the computer science world and I’m grateful to have had not only an introduction to it but some practice with it as well. I will be sure to keep it ever-present in my mind as I code not just my current project but any project in the future.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

Performing a Sprint Retrospective

A sprint retrospective is an event that occurs at the end of a sprint where the team meets to discuss improvement for the next sprint. This is to say, the team gets together and looks back at the sprint completed and looks for areas of improvement that they can adjust for the next sprint.

Following the theme of my last few blog posts, I will be manning a one-man scrum team (which is an odd sentence). How exactly will a sprint retrospective look for me and by extension how would it look for someone following a similar journey through scrum?

A great place to start is knowing what’re the right questions to ask, thankfully Rodrigo Ribeiro has provided us with these questions is his blog, “How to Run a Sprint Retrospective 101: The Essential Guide”. Now, this blog was written with an entire scrum team in mind so let’s take a look at the four major questions he poses for a retrospective and look at them in our scenario.

“What did you like in the sprint?”

This is a simple question, but it may have more significance to our situation than you would think. As Ribeiro notes this section is mainly for giving credit where credit is due to your team members and making sure to thank them for their efforts. Well for us we are our team members, but that doesn’t mean we don’t deserve credit or appreciation for our effort. Taking a moment to pat yourself on the back for completing your sprint and telling yourself you did a good job can really improve your attitude and confidence when looking towards the next sprint.

“What is puzzling you right now?”

This question is an opportunity for your team to ask for clarification about roles in the team, as well as technical and functional purposes. For us, roles are not relevant as we are assigned all of them. As for technical and functional purposes, as the product owner we already know what the purpose of our product is, both technical and functional as we’ve designed the backlog. With this being said, maybe this question is better omitted from out one person retrospective.

“What didn’t work so well?”

This is the time for the team to express their feelings about the project. In our instance, this is the perfect opportunity to be fully honest with ourselves about our current feelings towards the project as well as our feelings about that last sprint. Were there issues with backlog items? Did we move the project towards completion in the same direction we set out product goal? These are very important questions to ask ourselves and to be fully honest about as we’re the only input.

“What are your improvement ideas?”

This is the section where you, of course, should ask your team for solutions to issues you’ve been having as well as general ideas for project improvement. So how does this relate to us? After the end of our previous sprint, with certain backlog items finished and maybe even some scrapped, some adjusted, and some still alluding a solution, we can take a minute to reassess our current situation and decide our next steps. Were some of the completed backlog items not completed to our standard, or in the direction we wanted to move our project? Are some backlog items unable to be completed now irrelevant or should a new way of looking at them be implemented. Without the input of others during a sprint it can be hard not to be one track minded and tunnel visioned so this is a great opportunity to take a breather, relax, and try to search for a new angle. Maybe write down some solutions, think them through, and try again with new tasks and backlog items for the next sprint.

It’s important as a one-man scrum team to be incredibly flexible, and getting held up on one backlog item can really stagnate progress and burn out a single developer. Asking these questions in the middle of the sprint will only lead to complicating something that’s already complicated navigating as one person. It’s better to do what you can during the sprint and assess and reevaluate with yourself after. From there you can make changes and move forward in the direction of your choosing.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

Creating a Sprint Goal and Backlog

As a one-man Scrum team, a lot of the framework provided with Scrum and Agile can be hard to apply. For example, how do I define a sprint goal for my team when I am the team, or how do I determine how much work the team is capable of when again, I’m the team.

Shouldn’t being a single person scrum team make these easier to accomplish? I mean it would stand to reason yes as I don’t have to confer with others on a sprint goal and who better to know my own capabilities than myself. The issues arise in a few places.

The most important being, as someone who is new to scrum how will I know I’m setting a realistic or achievable sprint goal. How will I know I’ve chosen the right goal for that given part of development?

Another given issue is with being the one who sets the goal and the timeframe who’s going to keep my honest and working as hard as I can without burning out? I can push myself incredibly hard and burn out after one sprint or I could accomplish almost nothing because I just didn’t feel like it and didn’t have to answer to anyone.

Thankfully, the first issue can be solved by researching sprint planning. In “Creating a Sprint Backlog: Your Guide To Scrum Project Management” by Dana Brown, she details how to create a sprint goal, how to create a sprint backlog, and how to prioritize tasks.

She highlights the first two steps of sprint planning as setting a sprint goal and identifying important product backlog items. Thankfully this is where my first issue is solved. As someone inexperienced to scrum, I would start at step two which is identifying the important product backlog items and using those to create a sprint goal. This way my sprint goal is relevant and knocks off the items highest on the priority list.

From there I can breakdown my product backlog items into smaller tasks and add them to the spring backlog. Finally organizing these tasks based of their priority and prerequisite tasks.

So, my first issue has been resolved, I now have a method of creating a sprint goal relevant to what’s highest priority. As for my second issue, unfortunately I don’t think I’m going to find an answer to that one online. It’s going to be trial and error as well as being completely honest with myself on whether the workload is too much or too little. Ultimately, it’s going to come down to how disciplined I can be.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.