Category Archives: Week 8

Apprenticeship Pattern Review 7: Sustainable Motivations

I feel like most people have been in this situation: you have passion for a hobby and decide that you want to take your craft to the next level. In doing so, a mountain of unforeseen stress and complications arise and at some point along the way you might even forget what motivated you to get to where you are in the first place. Sustainable motivations are important no matter what you are applying this pattern to. This pattern is especially important in the life of a software craftsman.

In an industry where it is all too easy to retreat into competence because the pay is “good enough”, it is easy to lose sight of the motivation that made you decide to devote your life to becoming a software developer. I can’t even describe the joy I felt as a sophomore in high school when I set out to make an, albeit shoddy, clicker game in JavaScript, and after slaving over the code for days I finally understood exactly how a game loop had to function in order to make the game playable. I proceeded to spend that weekend glued to my screen implementing all of the features I had only dreamed of days before, barely remembering to relieve myself periodically. It is that entering into a state of flow and  working through complex problems with the end result being something I created that made me fall in love with the craft. Sometimes I fall victim to forgetting what it is about programming that I love since it feels like I have been in school for a long time and the future in regards to employment and making ends meet is up in the air. To quote David Wood, “do what you love and the money will follow”. Making sure to never let your motivations become misguided is important into keeping energy and creativity levels as high as they can be.

An important distinction between motivations can be made. That is intrinsic versus extrinsic. The more intrinsic your motivations, meaning doing so because you find it personally rewarding, versus extrinsic motivations, doing so because you seek a reward, the more sustainable your motivations will be. I know I am extrinsically motivated by money and the desire to succeed for my family and teachers, and I am intrinsically motivated by the desire to create, the desire to increase the complexity of life, and the desire to solve problems. I find this pattern important because motivations truly change your outlook and mood when facing life. This pattern applies to everything in life and I think writing down motivations is a good exercise for my software development career and in life.

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

TypeScript, a better version of JavaScript

TypeScript, is it really a better
version of JavaScript? If you are like me and you never used JavaScript before
and then were told that TypeScript is better you will probably have the same
reaction, “OK, so what?”. Well it turns out it is a very useful thing, it is a wrapped
version of JavaScript that will pay attention to the types of variables used
and so on, hence the name. In my search for some answers I have stumbled upon THIS blog by Valentino
Gagliardi named TypeScript Tutorial For Beginners: The Missing Guide (2019).
Like it says it is a whole tutorial, but it also explains in some simpler words
what TypeScript is and why it is useful with a lot of examples. I will go through
it and then look for some more. What helped me right away was Valentino’s explanation
of what is TypeScript: “The definition from the official website says: “a typed
superset of JavaScript” but it assumes you know what a “superset” is and what
“typed” means. Instead to keep things simple you can think of TypeScript as of
“a layer on top” of JavaScript.”

Most of the blog is what it is
supposed to be, a Tutorial, and in my opinion it does it in a very good way, he
starts in an easy way to show certain things, even when somethings is not right
away understandable Valentino comes back to it later and explains in more
detail, what is a plus for me as well is that he does in somewhat humorous way
and that makes the whole learning a more easy going process. Having those kinds
of Tutorials is very helpful for me because knowledge can be learned but what
needs to happen is also the understanding of when and where to apply said knowledge
and with this blog post I’m starting to understand that about TypeScript.

Learning in school about best tools to perform today’s jobs and being able to see it in action before I am thrown into the deep end is a huge plus for me and it should be for everybody else as well. I am always very grateful for the opportunities like this one. I have found out that the TypeScript is used at my work in other departments which tells me it is a good thing to learn and maybe use to further my career. I cannot wait to start writing some more advanced programs in this format, but everything needs to be done slowly, you must learn to walk before you can run and I do intend to be able to run eventually.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Time for some more REST

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.

Adventures in TypeScript

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 253.
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.

TypeScript/JavaScript

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://dzone.com/articles/what-is-typescript-and-why-use-it

What Is JavaScript Used For And Why You Should Learn It

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.

Clarifying Edge Testing

I happened upon a very
interesting blog recently, searching for more examples of edge case testing,
wherein the author provides an interesting set of common edge cases. While they
use the same names or similar ones as those we’ve seen lately in class some
have new meaning here. In addition, they may have an actual value tied to the
name – such as zero, one, and two – but their values are defined otherwise.

 In order they
are as such:

  • Zero “represents
    any form of null input”, including the actual value zero but also null, an empty
    List or Array, et cetera. This of course is to test the capability of a program
    to deal with input that isn’t properly usable by it.
  • One represents what
    we have referred to as nominal up to this point, meaning a valid normal input
    which should test proper functionality of a program under ideal conditions.
  • Two does not
    correspond to the value two, but rather refers to testing the same code twice,
    usually in sequence, to see how repeated executions affect a system.
  • Two to Max-1 is
    most like one, in that it represents a nominal value as well, but in opposition
    this value should not be the absolute simplest needed to function but an average
    use case; meaning possibly complicated.
  • Max is
    fairly self-explanatory, used to test the upper limit accepted by a program, and
    can sometimes be an extreme value. As such, it can test the limits of the
    program under incredible load.
  • Max + 1 is
    used to ensure that limits placed on an application are working and that anything
    that does not correspond to a valid range is rejected in a reasonable manner.

These would most closely correspond to Normal Boundary Value Testing as we have covered in class but they are each less abstract than those counterparts. They provide an insight on what these values look like in actual QA testing, as well as expectations upon being used. Two for example does not have an actual value associated with it, but rather refers to a testing orthodoxy outlined above. One example of a test in this vein is found in another blog, in which the author proposes the edge case of the same user trying to log in from two different computers. I believe between the two of these blogs a clearer picture of the concepts we have covered can be found through these more concrete examples of the testing procedure.

Sources

A Beginner’s Guide to Testing: Error Handling Edge Cases
Build Strong Edge Test Cases

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Moving on with Story Mapping Tools and Creating Setup Diagrams

Last week started on Tuesday by meeting with Dr. Wurst. In our research meeting we discussed various topics from the previous week’s work including the story mapping tools and the continued discussion on which platform to use for LibreFoodPantry for communications. We decided that based on my findings and what we currently know, draft.do is still the best story mapping tool and that we will start using this to transcribe the LFP user story map created during the June story map using this and I should update the GitHub issue card regarding this. Frequently when talking about various things it seemed that we will need a server for hosting various tools for the LFP projects so one thing I will look into is what services (if any) have free server time for open source projects. After discussing the workflow documentation I created for the shop setups I learned I needed to create diagrams for these and research or create my own way of modeling different things in GitLab and GitHub such as repository structure and permissions. 

Wednesday I briefly updated the issue card regarding if we are still creating documentation for GitLab Free since it has restrictions on the number of issue boards you can create. I also updated the story mapping card with what Dr. Wurst and I discussed the previous day about reaching a decision on which tool we are using so we can move forward with that. 

Friday I looked at the updates to the story mapping issue and started working on transcribing the user story map created during the June retreat from the pictures taken and put onto the Google Doc during the retreat. I found that this went pretty smoothly using draft.do and following the format for the shop-level workflow we previously did in this tool made it easy. I updated the issue on GitHub with my work in progress story map and asked for it to be reviewed to make sure I got the colors and card positions correctly. I then tried pushing the workflow documentation to the LFP/Community GitHub repository and ran into a permissions error so I had to email Dr. Wurst to get write permissions for the repository. I switched the documentation extension over to .md so it would be recognized as Markdown by GitHub and the operating system. I then started working on creating diagrams for the various setup workflow documents. I started out by drawing the initial diagrams on a whiteboard then I would transcribe them over to a digital format to be stored in the GitHub repository. I tried using the yEd tool that Dr. Wurst suggested for creating diagrams and found that it was a bit tricky with yEd being a lot more restrictive in where you can place things after previously using draw.io for making diagrams. Although after using it for a couple of hours, I found that it is easier to have consistent formatting with this tool versus draw.io and I’m starting to warm up to it more. One thing I want to figure out is where and what format should these diagrams be stored in the repository and should they be included in the setup documents. I ended up finishing the diagrams for both GitLab Gold and GitLab Free, along with refactoring the documentation, and started working on the ones for GitHub Free. When I went to use the shop manager test account on GitHub I found out that all of my GitHub testing accounts had been flagged by some kind of auto spam detection bot so I emailed Dr. Wurst regarding what I should do about this and ended the week with this. Next week I will continue finishing up the setup diagrams and documentation and move on to the workflow ones, along with responding to Dr. Jackson’s additional questions on GitHub.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Dig Deeper

We live in a world where different complex software projects have different deadlines and they use a variety of tools to finish the projects. Most of the time employers cannot afford to hire too many specialists to fill every role. You learn only enough about any tool to get today’s job done. You select some … Continue reading Dig Deeper →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Hello dear readers. Here we are again in another blog post with another Apprenticeship Pattern. Today’s Pattern is called ‘Record What You Learn” and by the name you can kinda tell what this is all about.

One day before I started my job, one of my friends gave me the same advice “Take a notebook with you and write down everything they explain. Sometimes even the easiest things can be forgotten. Also this gives a good first impression on how seriously you take your job.” I got to say that my friend was definitely right and I can say with prof from my experience at my job and also from this pattern that I am writing today.

This pattern talks about the learning process and how important it is for you to record what you are learning. When starting a new job or working in a new project, you will be facing a bunch of new material and believe me you won’t remember all of that. It is very important for you to keep notes about everything you are learning but not only. There are a lot of people out there who keep notes and when they go back to review, they don’t even understand their own writing or what they were trying to note.

It is true that is very important to keep notes but it is also as important to keep clear notes. The authors strongly suggest to keep a blog post about these new information that you are being exposed but I would say that a blog  is not required or necessary. In my opinion it is perfectly fine to have all your notes stored in a notebook as long as everything is clear and clean. I would say that another advantage of the blog posts is that while writing about you learned, you also reflect about it.

It is totally your choice to decide on how you would like to record and store all your notes. I personally was very happy to show up on my first week of work with a notebook with me. Even after 6 months I needed to look at that notebook once in a while. Another use of my notebook was for my new teammates that joined the team. As I passed it along, they also found it very helpful and started to create their own.

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

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.