Hey, I have been gone for a year since I noticed this little blog website.
It has been fun for me, who has been doing things from experience and learning in 4 years in college.
Also, I am considering returning to this Blog for simple things while sitting on the blog website, which has changed. There are plenty of times to learn, and it is never too late.
From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.
Starting a day and a half of AWS training to learn how to deploy LibreFoodPantry on K8s! A former (20+ years ago ?) student is now working for AWS and volunteered to do the training for our coordinating committee. And thanks to AWS for providing credits for open source projects! #AWS #LibreFoodPantry #CSWorcester
From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
Since all the cool kids are doing it…
GitHub contributions and GitLab contributions
I'd rather not host my work with a company that doesn't respect my licenses.
From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
Success!
From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
Success!
From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
I am testing syndicating my toots to my blog. This should go to my blog, and from there it should be syndicated to the CS@Worcester blog. #CSWorcester
From the blog CSWorcester – On becoming an Eccentric Professor… by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
I am testing syndicating my toots to my blog. This should go to my blog, but not to the CS@Worcester blog.
From the blog Karl R. Wurst by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
(Mostly) sorted the configuration for MegaLinter on one of our projects. Now I just have to duplicate/modify that across 20 more projects! (And, eventually, fix some of the issues that MegaLinter was flagging…) #CSWorcester #LibreFoodPantry
From the blog CSWorcester – On becoming an Eccentric Professor… by Karl R. Wurst and used with permission of the author. All other rights reserved by the author.
Technical debt is a programming theory that refers to the
necessary work that gets delayed during the development of a software project
to meet a deadline or deliverable. It is an idea that shortcuts are taken to
quickly deliver a product, but this decision incurs a “debt” that
must be paid in the future when the work is eventually completed. Technical
debt is often the result of a tradeoff between perfect products and the short
timelines often required for product delivery. Developers may choose the easier
route with messier code or design to deliver a product faster, but this can
lead to technical debt that must be addressed later.
Technical debt can accumulate “interest” over
time, increasing the difficulty of implementing changes and leading to software
entropy. It is important to manage technical debt to avoid these negative
consequences. This involves identifying technical debt, accounting for
nonfunctional requirements, and implementing best practices and agile practices
to minimize it. It is also important to be proactive in reducing technical debt
in new initiatives by carefully planning and designing projects from the start.
I selected this post because I wanted to learn more about
technical debt as I found the concept to be particularly interesting and
relevant to my future projects. This topic also seemed important as I found it
amazing that despite the large file structure for projects in this class, it
was not too difficult to add and update code for the assignments. That showed
me how a codebase can avoid technical debt to a degree, and how it simplifies
for maintainers (or a group of students) the process of adding and updating
code to the codebase. After reading through the blog, I gained a better
understanding of what technical debt is and how it can accumulate over time.
This really resonated with me as I can see how important it is to consider the
long-term implications of the decisions, we make during the development
process. One of the most valuable takeaways for me was learning about the various
types of technical debt and how to identify them. This will be especially
useful as I continue to learn and grow as a programmer. I also appreciated the
discussion of best practices and agile practices for managing technical debt,
as I can see how these approaches can help to minimize the amount of debt that
is incurred. I expect to apply what I learned in my future practice by being
more mindful of the potential impacts of my decisions and actively working to
minimize technical debt whenever possible.
Source:
From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.
Technical debt is a programming theory that refers to the
necessary work that gets delayed during the development of a software project
to meet a deadline or deliverable. It is an idea that shortcuts are taken to
quickly deliver a product, but this decision incurs a “debt” that
must be paid in the future when the work is eventually completed. Technical
debt is often the result of a tradeoff between perfect products and the short
timelines often required for product delivery. Developers may choose the easier
route with messier code or design to deliver a product faster, but this can
lead to technical debt that must be addressed later.
Technical debt can accumulate “interest” over
time, increasing the difficulty of implementing changes and leading to software
entropy. It is important to manage technical debt to avoid these negative
consequences. This involves identifying technical debt, accounting for
nonfunctional requirements, and implementing best practices and agile practices
to minimize it. It is also important to be proactive in reducing technical debt
in new initiatives by carefully planning and designing projects from the start.
I selected this post because I wanted to learn more about
technical debt as I found the concept to be particularly interesting and
relevant to my future projects. This topic also seemed important as I found it
amazing that despite the large file structure for projects in this class, it
was not too difficult to add and update code for the assignments. That showed
me how a codebase can avoid technical debt to a degree, and how it simplifies
for maintainers (or a group of students) the process of adding and updating
code to the codebase. After reading through the blog, I gained a better
understanding of what technical debt is and how it can accumulate over time.
This really resonated with me as I can see how important it is to consider the
long-term implications of the decisions, we make during the development
process. One of the most valuable takeaways for me was learning about the various
types of technical debt and how to identify them. This will be especially
useful as I continue to learn and grow as a programmer. I also appreciated the
discussion of best practices and agile practices for managing technical debt,
as I can see how these approaches can help to minimize the amount of debt that
is incurred. I expect to apply what I learned in my future practice by being
more mindful of the potential impacts of my decisions and actively working to
minimize technical debt whenever possible.
Source:
From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.