Author Archives: Camille

Software Craftsmanship

 Hello!

 I’ve had a bit of assigned reading to do for my capstone course, ans as such, I thought it would go the way of most readings of that ilk; incredibly dry and ungodly boring. But surprisingly I had a pretty good time with Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. 


The text captures something that I find to be incredibly important to the process of becoming a career programmer, the ability to be flexible. Much of my time spent learning to program has consisted of how to do things, but never why or when we should do them. Sometimes it feels like I have a fairly full toolbox, but I don’t have the required knowledge to apply my tools in ways they weren’t explained to me in. I’ll admit, this is more of a personal failing I feel, but the point still stands. 


Chapter 1 and the introductory paragraphs to Chapter 4 really stood out to me the most, as Chapter 1 goes into detail about what it means to be a craftsman, and an apprentice. It highlights the experiences one might go through, and what one might expect to get out of an apprenticeship, but the most compelling out of that chapter was the focus on the need to continue learning. In order to be a good apprentice, and get anything meaningful out of the experience, it takes a want to learn how to become a master, and the willingness to continue to developing your craft, and focusing on how you can improve your mindset and workflow. Chapter 4 stood out to me with it’s anecdote about Dave’s experience with certifications, and his discarding of them as he learned from a group of Perl hackers. Not only was it quite amusing, it highlights ths importance of a flexible mindset. None of us are ever done learning, and in order to ever become a master, you cannot be satisfied with jist maintaining the status quo.

 

Overall I found the selected chapters to be genuinely pretty inspiring, and it put into perspective where my head is at in terms of my software development journey, and how I might go about improving them. This might be optimistic, but this book might end up being one I read in my off time, a rare feat for an assigned reading of this nature.

 

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Software Craftsmanship

 Hello!

 I’ve had a bit of assigned reading to do for my capstone course, ans as such, I thought it would go the way of most readings of that ilk; incredibly dry and ungodly boring. But surprisingly I had a pretty good time with Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. 


The text captures something that I find to be incredibly important to the process of becoming a career programmer, the ability to be flexible. Much of my time spent learning to program has consisted of how to do things, but never why or when we should do them. Sometimes it feels like I have a fairly full toolbox, but I don’t have the required knowledge to apply my tools in ways they weren’t explained to me in. I’ll admit, this is more of a personal failing I feel, but the point still stands. 


Chapter 1 and the introductory paragraphs to Chapter 4 really stood out to me the most, as Chapter 1 goes into detail about what it means to be a craftsman, and an apprentice. It highlights the experiences one might go through, and what one might expect to get out of an apprenticeship, but the most compelling out of that chapter was the focus on the need to continue learning. In order to be a good apprentice, and get anything meaningful out of the experience, it takes a want to learn how to become a master, and the willingness to continue to developing your craft, and focusing on how you can improve your mindset and workflow. Chapter 4 stood out to me with it’s anecdote about Dave’s experience with certifications, and his discarding of them as he learned from a group of Perl hackers. Not only was it quite amusing, it highlights ths importance of a flexible mindset. None of us are ever done learning, and in order to ever become a master, you cannot be satisfied with jist maintaining the status quo.

 

Overall I found the selected chapters to be genuinely pretty inspiring, and it put into perspective where my head is at in terms of my software development journey, and how I might go about improving them. This might be optimistic, but this book might end up being one I read in my off time, a rare feat for an assigned reading of this nature.

 

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Software Craftsmanship

 Hello!

 I’ve had a bit of assigned reading to do for my capstone course, ans as such, I thought it would go the way of most readings of that ilk; incredibly dry and ungodly boring. But surprisingly I had a pretty good time with Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. 


The text captures something that I find to be incredibly important to the process of becoming a career programmer, the ability to be flexible. Much of my time spent learning to program has consisted of how to do things, but never why or when we should do them. Sometimes it feels like I have a fairly full toolbox, but I don’t have the required knowledge to apply my tools in ways they weren’t explained to me in. I’ll admit, this is more of a personal failing I feel, but the point still stands. 


Chapter 1 and the introductory paragraphs to Chapter 4 really stood out to me the most, as Chapter 1 goes into detail about what it means to be a craftsman, and an apprentice. It highlights the experiences one might go through, and what one might expect to get out of an apprenticeship, but the most compelling out of that chapter was the focus on the need to continue learning. In order to be a good apprentice, and get anything meaningful out of the experience, it takes a want to learn how to become a master, and the willingness to continue to developing your craft, and focusing on how you can improve your mindset and workflow. Chapter 4 stood out to me with it’s anecdote about Dave’s experience with certifications, and his discarding of them as he learned from a group of Perl hackers. Not only was it quite amusing, it highlights ths importance of a flexible mindset. None of us are ever done learning, and in order to ever become a master, you cannot be satisfied with jist maintaining the status quo.

 

Overall I found the selected chapters to be genuinely pretty inspiring, and it put into perspective where my head is at in terms of my software development journey, and how I might go about improving them. This might be optimistic, but this book might end up being one I read in my off time, a rare feat for an assigned reading of this nature.

 

 

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Test Test Test Redux

 Hello!

 

I’m still Camille and this is still my blog, I guess!

 

CS443

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Test Test Test Redux

 Hello!

 

I’m still Camille and this is still my blog, I guess!

 

CS443

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Test Test Test Redux

 Hello!

 

I’m still Camille and this is still my blog, I guess!

 

CS443

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Blog Post VERS. 4.1.63

 Greetings! 

This week during class, among other things, we learned about semantic version numbers. As the name implies, the process of determining what kind of version goes to what kind of version number is quite complicated, and requires some level of thought, which I admittedly hadn’t done before now. The MAJOR.MINOR.PATCH format for changes does seem rather useful and straightforward, but actually figuring out how to classify changing how a print command prints to the console seems like a lot of work. I always had this notion in mind that developers kind of just picked versions numbers at random, or at least sequentially, I didn’t know there was an actual structure behind what appears to be a simple string of numbers.

I feel like with writing these posts I have a tendency to view other blog posts that completely contradict, or speak about the shortcomings of what we learn in class. I don’t mean to be a cynic, I just want to be aware of what can go wrong when using such a structured method of formatting. That being said, I viewed “Semantic Versioning is a terrible mistake”, from the Reinvigorated Programmer, which is a personal blog of a career programmer and hobby archeologist. While I don’t fully agree with the overly cynical title of the article, I do believe it makes some very valid points. Within this article, the writer speaks about the problems with having numbered releases for software, as it makes it so programmers can make frequent breaking changes to software, which are denoted by a version number. Instead of having a real “Major Release”, it’s really just an excuse to release a small breaking change and release it as it’s own version. I can see obvious problems with this, such as the tedium of upkeep and maintenance. While I haven’t worked with many of these constantly changing APIs in my school programming career, I can certainly relate to the struggle of dealing with a constant influx of new versions. To anyone that has tried to play the video game Minecraft, and attempted to mod said game, you know how difficult it can be to make sure everything is working with the same base version of the software. 

Overall this article was pretty good! I enjoyed the semi-comedic tone of the author, and it feels a little less dry than some of the other more technical blogs I’ve viewed in my time. In terms of semantic versions, I am glad I’ve taken the time to look into it further, as I think it’s helped me clarify what the differences are between the different numbers, and what it means to release a major version following this numeric scheme. So the next time I use a piece of software that has some history to it, and is on version 21.3.56, I can smile in satisfaction at the fact that I know what that means, but also grimace at the fact that, inevitably, software will break. Eugh.


Article Link:https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.