Category Archives: Week 13

Practice, Practice, Practice – Apprenticeship Pattern

This apprenticeship pattern might be one of the most important ones in the book because it is something that can be applied to any aspect of life, especially for software development. You need to practice your craft and work on improving it by practicing it each and every day or at least the times when you can in an environment without interruptions or deadlines to help you focus. Software architects need to make mistakes to learn and they need to practice in order to learn. The mindset for this type of approach is to always be ready to perform and be as prepared as you can. If you don’t take action on what you need to know, then you will just be stagnant and stuck in the same place. The pattern doesn’t only talk about practice to improve, but talks about practicing in the best way. You need to try and practice in the best way possible by getting periodic feedback or getting more analysis on your mistakes. Practice will be come permanent in the wrong if you don’t constantly focus on way to improve the way you practice to learn in a more efficient way. This is why it says to practice in a relaxed environment so when you make mistakes you are comfortable with making mistakes and not burdened by it.

I think the biggest takeaway and thing I would add to this pattern is that the only way to learn is by doing and not focusing immensely on theoretical. Anyone can learn the theoretic aspect of software in a short period of time, but there takes more effort and practice to learn the practical aspect since you learn by doing. If someone were to learn all the rules and basics of a sport, but not practice actually playing the sport, then they will not be good at the sport. This is very similar to developing software, since you need to learn the theoretical aspect, but in order to be good you need to keep on practicing and learning. It is essential to always be prepared and up to date with how to learn and the most efficient way to learn a specific software. Overall, the end goal is improvement and to learn to adapt and adjust as time goes on for the most out of your software journey.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Familiar Tools

The section “Familiar Tools”, found in chapter six in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on the tools a craftsman uses. Focusing and familiarizing oneself with a particular set of tools will help increase productivity since there won’t be any need to go over the functions or specifics of said tools. This also allows one to more accurately know how long a task will take using these sets of tools. However, overreliance on one set is discouraged as there will likely be other tools that are either better suited to a particular task or are an outright upgrade. There are also situations where one will have to either choose your familiar tools and personal efficiency or less familiar tools and the overall team’s efficiency. Regardless, familiar toolsets will become obsolete and have to be replaced over the course of a software developer’s career.

The concept of having to swap familiar toolsets overtime is something I’m experiencing in real time despite my relatively small experience. For example, the first program that I used to develop and edit code in was BlueJ. It’s a fairly simple IDE that focuses entirely on the Java language and is mainly used for educational purposes. I got comfortable with it pretty quickly but then I had to learn C language which lead me to switch to Code::Blocks if I’m remembering correctly. The IDE I’ve been using for over a year now is IntelliJ which I mainly use to code in Java. I used all these different IDEs over the course of around three to four years and in the case where IntelliJ becomes obsolete or I need to code in a different language, like Python for example, I’d have to change IDEs again. This process is going to repeat again and again for as long as I use IDEs; though it doesn’t mean that I lose out sticking with one IDE for a period of time. Like the book states, I’ll be saving a significant amount of time coding in Java since I’m already familiar with IntelliJ and I’ll also have a frame of reference when estimating how long a task will take to get done.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Record What You Learn

            The learning pattern “Record What You Learn” from the Apprenticeship Patterns book is mostly self-explanatory from the title. The main concern of someone who gains a lot of knowledge quickly, such as a new software developer, or, in my case, a software development student, is retaining that knowledge. The chapter describes some good ways to track this learning, like with a wiki or a blog (hey!). Having to relearn or continuously practice concepts or bits of skill is time consuming and wasteful, especially if you don’t have something to quickly reference. This is a solution to that problem.

            Recording and retaining my learning has definitely been a problem in the past, although I’m trying to get better at it. At the start of my sophomore year, I realized I had forgotten a solid chunk of the programming skills that I had learned at the end of my freshman year. I had to work a lot over that summer, so I didn’t have a ton of time to practice these skills through personal projects or places like LeetCode. Getting back into the swing of things, especially as difficulty was ramping up, was a struggle. Luckily, I haven’t hit a patch like that since, but there have been plenty of times that I found smaller, but still useful concepts, escaping me.

            Some things in this department might be like remembering some concepts, but forgetting the implementation, or even just one key part of implementation. This is exactly where a wiki/blog would be super useful. I find I usually follow my own train of thought best, as I assume is the same for everyone, so having something to reference in my own writing, in a way that I find is useful in understanding a topic, is best as well. Just in recent memory, I had some trouble trying to remember how to create a custom comparator for two objects. I had just done it last week, at which point I had to look it up. It was excusable the first time, but just a pain the second time. So, even after a week, I still face these troubles. I definitely need to get better as recording my learning, so this learning pattern is a great point of emphasis for me.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Passion

I decided to once again choose patterns that cover related issues, this one being about passion. This is something that I find myself struggling with on and off between projects, where I have moments of excitement starting a project and successfully implementing a function, but often encounter issues that can stifle this passion. Beyond this I simply have times where I lose the drive to work on personal projects and struggle to find the desire to continue working with software design of any sort. Thus for this post post I chose to focus on the Nurture Your Passion pattern.

There are a few key points mentioned to help with this issue. The first mentioned is that you might just have to put any current work you are struggling with aside if possible to focus on another aspect that interests you. This can be in the form of a different part of the system you are currently working on or even just a breakable toy that will help you learn and grow, rather than stifling this advancement. Additionally, you should try to find a community that you can participate in. More often than not there are others in similar situations, and if you look online you can find discussion boards or even whole websites that have a variety of programmers discussing with each other. Getting different perspectives on the craft from others can reveal new insights to you, reigniting your interest in what you do. Furthermore there are even online study groups if you need particular help with specific issues. Beyond this you can also try reading some of the classic, well-regarded books in your free time. This will allow you to learn in a very low risk environment, removing the immediate stress of having to have functional code and allowing you to enjoy the intricacies of whatever is discussed in the book. Finally, if you are in a professional setting, you have to set work environment standards ahead of time. This can mean setting a hard time for when you stop working to ensure any toxic conversations are steered towards a productive topic.

While I am not in a professional setting yet, this information has helped me. I have never really thought about having to set standards for myself going into a job and will keep that in mind for the future. Many of these tips, as always, sound like they will be very helpful in the future and i have nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Failure

Something that I am sure many others who have pursued a career in computer science have encountered is failure. Throughout my attempts at coding, I have found that a vast majority of my time is spent trying to fix my own failed programs. This was, and can still be, a pretty large barrier to my enjoyment of programming, as simply trying to fix your own broken code over and over give the impression that you are not really making progress. To get a different perspective on this issue I chose to cover the Learn How You Fail pattern for this week.

This pattern gives a few key ideas to keep in mind when you feel like you find yourself stuck in a rut of failure. Firstly you should try not to focus on the disappointment of your failure, but focus on determining what happened that caused this failure. Work back through what you did to get to the point of failure and determine exactly what you did that caused this, then make note of the cause. If you can record these issues you will be able to determine your own strengths and weaknesses. This may lead you to realize that you have to put in a large amount of effort for seemingly small gains, but this will allow you to set accordingly realistic limitations on your goals. Accepting these limitations is also important, as it allows you to determine where you should and should not spend your time, which may require you to drop some projects for now. This will allow you to focus on any other issues you are encountering, and you can always return to the previous issue later.

So far I have found that failure is something that goes hand-in-hand with software design, especially when learning something new. Personally, I have always taken the very straightforward hit your head against the brick wall until it breaks method with failure, often  spending a long time solving small issues. After reading this pattern I have realized I should be recording what I am doing wrong each time, and that would certainly save me some time in the long run. Though I am still early in my career I found this pattern to be useful yet again and had nothing to disagree with.

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Use the Source

 When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Use the Source

 When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Use the Source

 When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

MongoDB in Five Minutes

This week I wanted to look more into MongoDB. I found an introduction video titled “MongoDB in 5 Minutes with Eliot Horowitz” from MongoDB’s YouTube channel to do so. I wanted to learn more about MongoDB because we have been using it a lot in class, but I do not yet have a clear idea of what it is and how it works. I have already taken a relational database course, so I have a clear mental image of what an SQL database is and how it is organized. I know MongoDB is not a relational database but that is the extent of my knowledge.

They start by describing relational databases as excel sheets on steroids, which is a pretty close comparison. They then use an example of a patient record keeping system for a doctor’s office. A patient information table might need multiple phone numbers and addresses, and these columns would end up being mostly empty in a relational database. We might also have the patient’s information spread over many tables, adding complexity. When this database is used in in application it makes the application inefficient and hard to maintain.

MongoDB uses documents and each document can be different. Not all the documents in this case would have to have the same number of phone numbers or addresses. They don’t need the same number of columns like records in a relational database table.

This video is very short and was also created by MongoDB. It is not surprising that they only show one use case where MongoDB is better than relational databases. If relational databases are Excel then MongoDB is kind of like Microsoft Word. It is important to remember that relational databases enforce things like integrity that MongoDB doesn’t, making it better in certain situations. Using multiple tables also isn’t too much of a problem; that is what joins are for. I can definitely see the advantages of using MongoDB now though. The idea of documents is so simple and it is easy to grasp compared to relational databases. This provides a good start to look more into MongoDB. I may have needed this knowledge for the final project, though we won’t have one anymore. I will definitely be using MongoDB in the future though as it is just becoming more and more popular.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Learning JavaScript

As my interest in learning Javascript grows, I have started to try and strategize how I should go about learning it. I have heard of several JavaScript frameworks, so I was wondering if I should start with one like Angular, Vue, Ember, or something, and in my research I found a blog post by Francois-Xavier P. Darveau with a very telling title: Yes, You Should Learn Vanilla JavaScript Before Fancy JS Frameworks. This is a post which details why Darveau believes that learning vanilla JavaScript is so important. He starts with a short story of his time in college in which he started to learn Node.js for a project and rather than quickly find libraries and do some Stack Overflow style copy/pasting to get the project working, he dove in and tried to do everything himself. Although it was time-consuming and arduous and was not exactly optimal, he had learned far more behind the scenes than he would have otherwise. He emphasizes that learning all the shortcuts from frameworks and libraries without knowing the how’s or why’s is more akin to pretending than real knowledge. He then explains the meaning of vanilla JavaScript, if not inferred before, as “plain JS without any additional libraries.” He notes that, of course, frameworks and libraries can be extremely useful and time-saving, a lack of vanilla JS knowledge can leave one helpless if something goes wrong or the field collectively decides to hop over to the next new best framework. Some framework pros and cons are detailed as well. Pros: abstracting hard code, shipping code faster and increasing development velocity, and focusing on an app’s value instead of its implementation. Cons: When work scales up and apps become more complex or multiple teams are working on multiple apps, there will no doubt be times when a deep JS understanding is needed to get everything to go smoothly. If a vanilla JS foundation is strong, the only thing changing when getting into a new framework will be mainly syntax. The speed at which new useful frameworks come out is faster than one can master them on their own, but with a vanilla JS understanding, you can already be a step ahead. He then provides plenty of resources for how to learn JS and where it can be studied. I found this very useful as I hope to learn much more JS soon. I have just done some work with Node.JS in order to implement a new REST API endpoint and I hope to get down JS as it becomes increasingly prominent in the CS world. I am also doing an independent study related to mathematical modeling and linear algebra using MATLAB in the upcoming semester, so maybe there will be an opportunity there to apply my JS knowledge.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.