“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

• Atom: text editor
• Eclipse: IDE
• Insomnia: REST client
• GIMP: image editor
• Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The Dig Deeper pattern is all about knowledge and gaining more of it. More specifically, this pattern is about taking something new that you have learned or are currently learning and teaching yourself about that subject’s roots. It’s not enough to know how to use the subject matter to solve your specific issue, you need to know that subjects use as a whole to gain knowledge of its context. This pattern is about understanding how a system works as a whole and not just the part you are working on. This deeper knowledge allows you to understand your work more concisely based on the context of it as a whole, which will help you understand your specific issue even more.

When I first started reading on this pattern it felt like a very blunt lecture. It felt as though I was being told to learn everything to its fullest and if I do not then I will be a less desirable individual for hire. However, as I read on I realized it was not about having total knowledge of EVERYTHING, that would be overwhelming and nearly impossible. I began to understand that it was about delving your knowledge into specific things, subjects that you are currently working on. If you are working on a specific issue and find the solution, it’s not about knowing every way to solve the problem, but to know in detail the workings of your solution.

This pattern further enforced my idea that you can do anything, learn anything if you put your mind to it. If there’s something I really want to excel at, deepening my knowledge can only help me achieve my goal. Being able to fully express my knowledge on the specific things I have worked on, though maybe few, is far greater than a larger quantity of surface knowledge. It reminds me of using MongoDb for the first time in our libre food pantry project. It’s all good and well to set up a database and query and get the results you want. However, it’s much more important to understand how the database functions beyond my own entries and data types I’m working with. In furthering my knowledge I was able to communicate my understanding into the other areas of the project including tying the database to a Java REST API. I fully agree with the ideologies of this apprenticeship pattern, dig deeper into your knowledge and it can only benefit you.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

I’m promoting you from Senior Engineer to Lead Engineer. The pay is the same but people will disrespect you less.

—Dilbert’s Pointy-Haired Boss

“Use your Title” is a very effective pattern for those who feel like the title they have is everything in life. We all have our own goals in life, and we approach differently to achieve them. For some, a software engineer position is all they have wanted to achieve in life, and there are others who would not feel accomplished until they become seniors or leaders in the industry. On the other hand, it happens to have an unimpressive title, even though you have given more authority in your position than your title or job description says. In this case, people get discouraged and lose hopes that one day they would get what they deserve.

In my opinion, we should “Use our Title” in a way that benefits us professionally. Titles are only made to feed our egos. What is more important is that we should never stop learning or stop searching for better opportunities that would complete us professionally. Let’s think of it as climbing mountains. The second highest mountain in the world is K2. If a person’s goal a year ago was to climb that mountain, he/she would feel accomplished when he/she gets there, but then he/she would feel the need of having another goal to achieve and would end up climbing Mount Everest. This tells us that even when we get to have the title we always dreamed of in the industry, there’s more we can achieve.

In this pattern, I found interesting the part that suggests writing down a long and descriptive version of our job title. I think this would help us reflect on what we do at our workplace, if the title matches with the authority we have given, and maybe find the need to update the title with superiors’ permission. I, myself am going to try and see what I find out when it comes time to update it.
As a conclusion, make sure your skill level matches your job description and title, and no matter how far you go with titles, remind yourself that your apprenticeship is not over.

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

This apprenticeship pattern caught my eye for discussing the Peter Principle, which states that an individual will only be promoted if they do well in a position. The result of this is an organization full of people who have been promoted to positions in which they no longer perform well, creating an incompetent organization.

Reflecting as you work is meant to prevent this. The idea is simple enough: constantly probe your work process and ask yourself whether it is ideal. Take note of the positive aspects, but also the negative aspects so that they can be fixed.

The pattern suggests focusing on increasing skill rather than experience. This is a subtle but important distinction, because spending a lot of time doing a single thing wrong is still a lot of experience, but it’s not necessarily useful as a professional.

In certain parts of our industry,
it is quite easy to repeat the same year of experience 10 times without making significant progress in your abilities.

Apprenticeship Patterns

I certainly reflect on my work when it’s done, but I tend to focus on the work itself rather than the process. I’ve spent countless hours before a project commit making sure every line of code is perfect and the necessary documentation is in place. This led to nice code and happy professors or managers, but it didn’t help my work process. It was doing more of the same; obtaining a good result, but without improvement in workflow.

Figuring out how work processes connect is a helpful practice to identify counterproductive habits. We tend to take the path of least resistance and easily fall into a workflow that we assume works best for us, but this may be an illusion due to our limited scope of experience. We know redundancy can be reduced within a project’s architecture. We strive for this. Why then, would we not give our work process the same courtesy?

This pattern is a great example of software development’s being more than simply writing code. And by writing code, I mean using tests, DevOps, OOP, and anything else that can be considered a software engineering practice. As the entire book aims to prove, software development is an organic, human process. Moving from a software apprentice, to journeyman, to master requires understanding your own flaws, not just the flaws in your product.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

This week I have chosen to deepen my understanding of REST API. The article, “RESTful API Design Tips from Experience” by Peter Boyer, goes over good RESTful design practices. The article covers many topics, including some I do not have experience with but are still useful for a greater understanding overall.

The article proposes that the API should state its version
in the URLs. The author suggests adding a prefix to all URLs to specify API
version. This makes the eventuality of version updates easier to handle.

A simple tip mentioned in the article is the use of plurals.
When designing endpoints, plurals should be used instead of the singular form.
This is to avoid possible misunderstandings of what the endpoint is used for.

Example:             /orders/customers          VS           /order/customer

Another tip in the article is to use nesting for
relationship filtering. From what I understand, it is better to have multiple
path variables for filtering than the use of query strings. The example in the
article is very clear on the tip. Following this advice will make your
endpoints easier to read.

The author advises to keep your API as flat as possible. He
suggests that creating and fetching data should have a longer resource path
than updating and deleting data. I do not really understand why this is the
case. My best guess is the shorter path reduces unnecessary processes.

The next tip I found interesting was the important, if not
obvious, idea for pagination of results. When working with larger databases, requests
can have thousands of results. Since it would be impossible to display all the
data, it makes sense to partition the results into pages and return one page at
a time. Pagination can also significantly reduce the expense of a request.

The last tip I will mention from the article is the usage of
status codes.  HTTP status codes should
be used consistently and properly. This means the status should use the proper
code and provide additional details when necessary: an error code with a
message of why the error occurred.

Overall, I found Boyer’s article to be very informative. I
only mentioned a few of the topics raised in his article but all the topics are
interesting and useful. Reading through this article gave me a better
understanding of the nuances of RESTful API design and has helped me comprehend
my current coursework (CS343) better. I suggest to anybody that is new to REST
to read this article.

Article Referenced:
https://medium.com/studioarmix/learn-restful-api-design-ideals-c5ec915a430f

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

This week in CS-343, I was introduced to TypeScript, a
scripting language that uses typed variables to prevent coding errors caused by
mismatching data types. My introduction to TypeScript was my first time working
with a scripting language, and I am really looking forward to learning more
about it and using it to write new kinds of programs. However, the tutorial I
did in class was rather simple, as it only showed how to set up a basic project
in TypeScript. To learn more about this new language, I decided to research
TypeScript’s other features. I eventually came across a useful blog post by
Nwose Lotanna titled “New Features in TypeScript You Didn’t Know Exist.”

Link to the blog:

https://blog.bitsrc.io/new-features-in-typescript-you-didnt-know-exist-54b7ab8d0b4f

As the title suggests, this blog post discusses several
features of TypeScript that were introduced between versions 3.0 and 3.4. Each
feature has a short description that explains why it is useful, and many are
also demonstrated using example code. The post seems to be targeted at developers
who are experienced with TypeScript, which made it difficult for me to
understand every feature it discusses. However, there are a few features listed
in the blog that I could definitely see myself and other newcomers to TypeScript
making use of even in simple programs. I chose to discuss this blog to help spread
information on these useful but often overlooked features.

The first feature discussed in this blog is project
references. As of TypeScript 3.0, it is possible for one TypeScript project to
reference another by referencing its tsconfig.json files. This feature is
heavily reminiscent of the import feature in Java or the #include
feature in C, which have proved invaluable in my experience. Having the ability
to reference code in other files helps keep projects simple and organized, which
will undoubtedly be just as important in TypeScript as it is in other
languages.

Another feature discussed in the blog that caught my
attention is TypeScript’s BigInt object. BigInt was introduced in
TypeScript 3.2 and allows programs to use numbers greater than 2⁵³.
While I can’t recall a time where numbers that large were necessary, it is nice
to know that the option exists in TypeScript. There are certainly potential
uses for such large numbers, such as the Fibonacci function that Lotanna uses
to demonstrate the feature. Should I ever need to write a program that uses
numbers of this magnitude, I would certainly take advantage of TypeScript’s BigInt
feature.

A third TypeScript feature that I expect to be useful is the
const assertion. Since TypeScript 3.4, it has been possible to declare
arrays and objects as read-only constants using the syntax demonstrated by the
example code in the blog post. Though the syntax is different, this feature
seems to function just like C’s const and Java’s final keywords.
Having used these features frequently, I expect TypeScript’s const
feature to be useful in many programs to ensure that the values of certain variables
cannot be changed.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Ever wanted to build a website and be able to add in
interactive elements to the page? With JavaScript this can all be accomplished.
JavaScript is a programming language that is used with websites in order to
make the design better, sleeker and an overall better website. JavaScript can
also allow for people to create games and apps as well. These games would be browser
based and would allow for the creator to be able to implement the useful tools
that JavaScript provides. Mobile apps are starting to come around to JavaScript
as well. However, JavaScript is not always the easiest to learn or pickup. That’s
where typescript comes in handy.

With typescript, users are able to code with a far more interactive
interface. Once the typescript is written, there is a TSC or type-script
compiler that compiles the typescript code and converts it into JavaScript.
This allows for a much easier integration of JavaScript because of the ease of typescript.
Typescript is a rather new concept, only recently appearing in 2012 by the
creator Anders Hejlsberg. Typescript has many advantages to it over JavaScript.
For starters TypeScript, as mentioned before, is far easier to code and the
user does not have to worry about it being converted into usable JavaScript. TypeScript
is also open-source, meaning that the software for its development can be used
by anyone which allows for constant improvements to be made to the software.
TypeScript also comes with development tools built in. With these tools,
debugging becomes far easier to do and allows for different types of testing.
Another great feature that TypeScript has is that it can function with REST
parameters. REST is a type of software design that I have mentioned previously
in this blog. Another benefit of the TypeScript language is that it is an OOP
language, or object-orientated programming language. This allows for TypeScript
to be easy to maintain and keep clean.

TypeScript is essentially the next phase of JavaScript
because of the fact that TypeScript is a superset of JavaScript. This means that
every feature that JavaScript normally has is implemented with TypeScript. The only
difference is that TypeScript, as mentioned before, has far more additional
benefits to it. When it comes down to choosing whether or not to use JavaScript
or TypeScript, it’s a personal choice. However, since TypeScript was recently
released, it has not had as much time to spread but I believe the obvious choice
would be to switch over to TypeScript because you are missing out on many great
features.

https://en.wikipedia.org/wiki/TypeScript

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.