Hello I’m Alejandro Montes de oca and this is my ;professional blog. I started this blog for my CS 348 and 343 classes. I hope to gain an internship or any form of employment by the end of the semester.
From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.
Hello I’m Alejandro Montes de oca and this is my ;professional blog. I started this blog for my CS 348 and 343 classes. I hope to gain an internship or any form of employment by the end of the semester.
From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.
Hello I’m Alejandro Montes de oca and this is my ;professional blog. I started this blog for my CS 348 and 343 classes. I hope to gain an internship or any form of employment by the end of the semester.
From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.
Hello I’m Alejandro Montes de oca and this is my ;professional blog. I started this blog for my CS 348 and 343 classes. I hope to gain an internship or any form of employment by the end of the semester.
From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.
The article I chose for this week’s blog post is “Understanding Software Process Models: What They Are and How They Work” from the Institute of Data. I chose this article because it fits well with the software process models section of the course topics in the syllabus and can help solidify an understanding of this topic. I was also surprised to learn that software process models are very dynamic. Before reading the article, I thought they were a rigid but vague system of how to develop any project. The article mentions that each system process model is tailored around the current project being developed. The parts of this article I will be discussing are defining process models, the role of software process models in software development, and the critical components of software models.
The first section of the article I will discuss is defining software process models. The article defines software process models as “…frameworks that define the sequence of activities, tasks, and deliverables required to develop high-quality software.” The article says that software process development models act as a roadmap, providing steps that help guide a software development team and are also a dynamic way of structuring a project development. The article also discusses the role that software process models have in development.
Software process models are essential for development teams to work alongside one another. The article discusses in depth how important software process models are for development. “Process models play a crucial role in ensuring that projects are executed smoothly in software development. They provide all team members with a common language and understanding, promoting effective collaboration and communication.” As stated in the article, software process models allow colleagues to have a common understanding of how and what needs to be implemented and when. This allows for significant clarity and helps discover potential issues early in development. The article also mentions how using system process models can help with costs. “By clearly understanding the activities and tasks involved in each phase of the development process, teams can estimate the time and resources required more accurately. This helps in setting realistic project timelines and budgets.” This is one of the most important benefits of using software process models during development, saving developers time and money and resulting in shorter development cycles. The article also discusses some key components of software process models.
The article mentions some key components of software process models. I will just be going over requirements gathering and analysis for the sake of brevity. “Requirements gathering and analysis is the first phase of the software development process. It involves understanding and translating the client’s needs into clear and concise requirements.” This part sets the groundwork for the project and helps ensure the end product matches the client’s vision. If this part of the software development process is not completed correctly, your end result will likely not be what the client wanted, which means that this first part of the process is one of the most important parts of the entire process.
Article: https://www.institutedata.com/us/blog/understand-software-process-models/
From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.
For this week, I am focusing on Jacob Schmitt’s blog post “Trunk-based vs feature-based development”. This is a short yet efficient article in explaining the differences between the two types of software development processes. Schmitt discusses the alternate use cases of such processes, where and when they might be utilized, who is most likely to use them, and the advantages and disadvantages of them. I chose this blog because as I learn more about forks, feature branches, commits and pull requests, it is important to also understand the overall development processes of companies and why they might use them. The development processes mentioned by the blog intertwine perfectly with git commands and usage.
According to Schmitt, Trunk-based development allows for developers to push changes straight to the main branch. However, if the new feature will take longer than usual changes, then they can “check out a branch from main, move the changes into it, then merge it back in when the development is complete” (Schmitt). Then, there would be a code review held by other developers to ensure that the new changes do not break the main production branch. Although this development approach is quite popular, it is used more often in the realm of experienced developers rather than newcomers.
As for feature-based development, many developers can work on many different changes or branches at the same time. This is done by each developer creating their own feature branch, and then eventually requesting to merge with the main branch. One of the most important differences between feature and trunk based development is that in feature-based, developers never push straight to the main branch. This approach is much friendlier to beginner developers like myself, as there would be no worry of breaking production with new code since changes are on a different branch.
An advantage that trunk has over feature is that the code changes are more likely to be merged faster. Feature-based development pull requests can add up fast over time, which leads to a longer time between requesting and merging. Despite this, feature-based is much safer for larger development projects and groups, when there are too many feature branches to keep track of at once. As of right now, I prefer feature-based development because I would not be very comfortable working directly with the main branch as a new developer.
Although it might be simple, I found this article to be quite helpful in preparing me for what a future job or internship workflow might look like. When one has little to no experience with development in a professional environment, articles such as this one are very beneficial to learning more about team-based development. It gives a bit more background as to why we do this type of development, rather than just stating that we do it. I hope to use this knowledge in future projects with internships or jobs.
Link to article: Trunk-based vs feature-based development | Jacob Schmitt
From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.
For my first blog post for CS-348 and in general (in terms of actual content), I wanted to look into code review. I already had an inkling as to what it could entail, but I wanted to know what sorts of techniques and tools are used in looking over our peers’ (and our own) code.
For this blog post, I consulted a post on SmartBear to get a better understanding of it all. The post establishes reasoning for why we need code review so that we can overall reduce the excess workload and costs that can be caused by unreviewed code being pushed through. The post also gives us 4 common approaches to code review in the current day (which is noted to have been very much improved from methods found in the past). These approaches are email threads, pair programming, over-the-shoulder code review, and tool-assisted reviews.
An email thread provides advantages in versatility but sacrifices the ease of communicating that you get in person. Pair programming is the practice of working on the same code at the same time, which is great for mentoring and reviewing at the same time as coding, but doesn’t give the same objectivity as other methods. Of course, over-the-shoulder reviews are simply having a colleague look over your code at your desk, which while fruitful, doesn’t provide as much documentation as other methods. Lastly, tool-assisted reviews are also straightforward, utilizing software to assist with code review.
The SmartBear post goes on to say that tracking code reviews and gathering metrics helps improve the process overall, and should not be skimped out on. Some empirical facts from Cisco’s code review process in 2005 are given as well. According to an analysis of it, code reviews should cover 200 lines of code or less, and reviews should take an hour or less for optimal results. Some other points are given as well if you visit the post.
Considering most of my ‘career’ has been independent coding (that is, coding as the sole contributor), this was rather interesting to me. I’ve done code reviews for my peers, helping them with assignments and the like, while I’ve only really utilized tools and software to assist myself. It’s interesting to see how something as simple as looking over someone’s code on their computer is such an important step in the software development process, but it certainly makes sense. I also wonder how much the code review process has changed since the popularization of AI companions such as ChatGPT and Github’s Co-Pilot. Perhaps these tools have made code review with our peers less important, but I wonder if it’s more important to have our peers second-guess the AI’s suggestions in case of mistakes. Nonetheless, having a solid grounding of the actual ramifications of code review will prove very useful during my programming career, I am sure.
From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.
Mastering Git: Navigating the World of Version Control
As someone deeply immersed in the world of coding and development, I often find myself seeking the latest insights and innovations to stay ahead in this dynamic field. Recently, I had the opportunity to explore the GitHub Blog (https://github.blog/), a treasure trove of information that offers a glimpse into the exciting developments in code collaboration. GitHub, a cornerstone of the coding community, continuously adapts to cater to the ever-changing needs of developers worldwide.
The GitHub Blog, in this context, serves as my primary source of knowledge, delivering timely updates, tutorials, and in-depth insights into the platform’s newest tools and features. These innovations significantly boost productivity and code quality, making my coding journey smoother and more efficient. What truly stands out, though, is how GitHub is fostering a culture of open-source contributions and building inclusive communities.
I encourage you to delve into this blog and embark on your own journey of discovery in the ever-evolving realm of code collaboration. I chose the GitHub Blog as my go-to resource for several compelling reasons. Firstly, it consistently offers a pulse on the rapidly evolving landscape of code collaboration. This blog not only keeps me informed but also inspires me to be part of a larger, positive change within the coding community.
Having explored the GitHub Blog, I’d like to share my thoughts on the content and how it has impacted my perspective as a student in the field of computer science. This resource has been an invaluable source of knowledge for me, primarily due to its dynamic and up-to-date nature.
As a student, staying informed about the latest developments in technology is crucial to my education and future career. The GitHub Blog has proven to be a goldmine of information in this regard. I’ve learned about cutting-edge tools like GitHub Actions and GitHub Copilot, which have the potential to revolutionize the way code is written and managed. This exposure has not only broadened my understanding of these tools but also inspired me to explore them further in my coursework and personal projects.
Beyond the technical aspects, the blog’s emphasis on open-source contributions and inclusivity within the coding community has left a lasting impact on me. It has reinforced the importance of collaboration, diversity, and community engagement in the tech world. Studying for CS, I now see the significance of not just acquiring technical skills but also contributing to the greater good by participating in open-source projects and fostering an inclusive environment for all.
In my future practice as a computer scientist, I plan to apply what I’ve learned from the GitHub Blog in multiple ways. Firstly, I’ll integrate the knowledge of GitHub Actions and GitHub Copilot into my coding projects to boost efficiency and code quality. Additionally, I’m motivated to actively engage in open-source initiatives, leveraging the collaborative spirit and sense of community that the blog has instilled in me. I believe that by embracing these principles and tools, I can become a more effective and socially responsible developer.
From the blog CS@Worcester – Site Title by asejdi and used with permission of the author. All other rights reserved by the author.
The contents that I have been learning in week 2 are git, GitHub and FOSS communities. First, we focused on FOSS communities, git and GitHub work together to allow this communities to share their work. We also have focus on working in your local repository using branches and commits and then upstreaming your changes using a pull request. Then we learned how to keep the local and origin repositories synchronized with the project’s upstream repo.
I found this blog giving the general definition about the upstream which relates to a content that I have learned in CS-348 class this week.
URL:
https://www.redhat.com/en/blog/what-open-source-upstream
In this blog, they talk about what an upstream is, how it relates to enterprise open-source products, and how they matter to your organization.
What is an upstream?
Upstream refers to the flow of data within information technology, particularly
in open-source projects. It serves as the precursor to other projects and
products, with contributions flowing from upstream to downstream. Users may
receive releases or code directly from the upstream. So, why are upstreams
important?
They are important because that’s where the source contribution comes from.
Each upstream is unique, but generally the upstream is where decisions are
made, the contribution happens, and where the community for a project comes
together to collaborate for the benefit of all parties. Work done at the
upstream might flow out to many other open source projects. The upstream is the
focal point where collaborators do the work. It is so much better if all the
contributors work together.
From the blog CS@Worcester – Hong Huynh-CS348-WSU by hhuynh3 and used with permission of the author. All other rights reserved by the author.
If we were to try to categorize all software applications into two groups (a bit of an ambitious task, but bear with me), we could separate them into apps that are platform-specific and natively-installed, such as apps downloaded from an app store onto a smartphone; as well as web-based apps, which run through a web browser. In the past, the majority of all applications can fall neatly into either category, each with it’s own advantages and disadvantages.
Historically, the most capable applications are those directly installed onto the user’s device. They can make use of the full use of system hardware, can launch regardless of internet connection, are more robust and reliable, directly read and write data stored on the device, and are their own platform. Native apps like Spotify, Waze, as well as more platform specific apps like iMessage, have the feeling of directly being part of their respective devices.
This is in contrast to web-based applications, which trade the capability and reliability of native apps for a design that is meant to be accessible to anyone, at any time, from any platform. Additionally, web applications have the advantage of only needing one codebase, as the only platform they must have compatibility with is just a web browser. While a developer of a native app may be able to create a more powerful and capable product, they must design and implement compatibility with each type of platform they want to run on. For example, the navigation app Waze must have compatible versions for iOS, Android OS, as well as other available operating systems.
This is now beginning to change, as Progressive Web Apps (PWA) have exploded into the field and promise to bridge the gap between platform-specific apps and web-based apps. Built using modern APIs, PWAs are able to fully realize their capabilities to the level of native apps, while still maintaining the reach and accessibility of web apps.
Authors Sam Richard and Pete LePage hit on the “best-of-both-worlds” abilities provided by PWAs in their article, What are Progressive Web Apps? “Progressive Web Apps are web applications that have been designed to be capable, reliable, and installable. These three pillars transform them into an experience that feels like a platform-specific application.”
While many different aspects of a developed application can be assessed and critiqued, the most important attribute of any app is the end-user experience. In other words, Is my app easy to use? Does it have all the features the user would need? Is it easily accessible? Reliable?
Progressive Web Apps cover all of these bases, and more. With the ease-of-access as a website and the capabilities of a native app, these new apps have the potential to reimagine how we think of web-based applications. While still a growing field, I believe the inherent ease-of-use provided by this platform will lead it to becoming a new standard for many different fields of application development.
From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.