Category Archives: Week 9

Javascript vs. Typescript

As someone fairly new to coding, learning new languages is both fun and painful. When I heard we were going to be doing some web development, I figured Javascript would be involved, and I had a brief moment of panic. I am a frequenter of subreddits like /r/programmerhumor, or other humor-based tech blogs, and there is a lot of dogpiling on Javascript as a language. It gets a lot of flak for being very weakly typed, and for its default behaviors utilizing this weak typing leading to a lot of wacky and confusing results for people who aren’t deeply familiar with the language. A quick example:

When I discovered we would be using Typescript (And what Typescript was), it was a bit of a relief. The way that the language looks just feels more comfortable to me, especially as someone who has mostly been learning Java. I have been trying to expand my horizons as of late, and wanted to look into people that may feel the opposite. Maybe the verbosity and strictness of a strongly-typed object oriented language is bad if you know what you’re doing, and I found a very interesting blog expressing just that.

In the blog post “Shit Javascript Coders Say” by Dave Sag found here: https://medium.com/@davesag/shit-javascript-coders-say-7a2d2881228d,
he utilizes a very pointed and crass writing style to express his distaste for OOP and strong-typed languages in general compared to Javascript. He also does not like Typescript. One reason I find this funny is because in this Software Architecture class I am writing this blog for, there is a big focus on creating interfaces, organizing classes, and figuring out the best ways to group and create objects. These are all things, according to Dave Sag, that are not needed in Javascript, and that Typescript “encourages the use of these practices as a weak, wobbly crutch” (paraphrasing).

I found this juxtaposition very amusing, and would be very interested in going down the rabbit hole more and finding out about best pure Javascript practices, or if Mr. Sag’s views are commonly held in some communities (I found plenty of blog posts praising Typescript, for what it’s worth).

In my brief time with Typescript so far, I have found it a bit verbose and clunky (though I am certainly a neophyte coder). Hopefully as I continue to learn, these distinctions become more clear and I can post an updated perspective.

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

Getting Angular

The topic for my post this week is Angular. CS 343, Software construction, design, and architecture, introduced REST API frontend last week. I did not have a good grasp of what Angular is, so I read the article “Angular Tutorial: Getting Started With Angular 4”, by Shubham Sinha. The article breaks down Angular into easy to understand parts which are then explained thoroughly.

The article begins with describing the general history of
Angular and why it was designed. Originally AngularJS, Angular was designed for
the use in designing SPAs (Single-Page Application). SPAs are useful as they do
not require an entire page to be refreshed. Instead SPAs only refresh necessary
components. This allows for SPAs to act similarly to desktop applications.

The article then begins its tutorial, though I would describe
it as an overview of the details of Angular projects. The author goes into the
different parts of Angular and describing them each in detail.

  • Modules:                           
    Chunks of code with a specific task, such as classes.
  • Components:                   
    Code that use API to control sections of the screen. Contains instructions for
    client-side GUI.
  • Templates:                        
    HTML tags that describe how to render components.
  • Metadata:                          
    The code that informs Angular on how to process a class.
  • Data
    binding:                       
    The connection used to tie parts of a template to parts of a component. An easy
    connection for data state and data events.
  • Directives:                         
    Logic code for manipulating data: adding, removing, changing.
  • Services:                             
    A wide category for encompassing anything an application my need.
  • Dependency
    Injection: 
    Allows Angular to create new instances of a class with all its dependencies
    that can be “injected” into another class.

From what I understand, the page code will be divided into
modules. The page view will be divided into components that use templates and
metadata to determine how to display the component. Directives are logic code
that manipulate data. Data binding allows for easy access to a data’s state and
events. Dependency injection inserts an instantiation of a class with all its
dependencies. Finally, services are simply anything an application may need:
value, function, feature.

I found that after reading this article I have a better
understanding of Angular. Angular can be used for client-side rendering of
data. By separating the page into several different components, Angular can create
SPAs that are dynamic and responsive. This article is informative and accessible,
I highly recommend this article to anybody who is getting acquainted to
Angular.

Referenced Article:
https://www.edureka.co/blog/angular-tutorial/

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.

If It’s Broke Don’t Fix it: Treating Bugs Like Buddha

For my last blog for this course instead of taking one
particular course subject, summarizing it, and theorizing about what actual
implementations may look like – I’d like to look at the whole course and do the
same. More specifically, I would like to cover how bugs or defects are actually
addressed, or not, in Software Development and Testing. To do this I have found
some interesting blog posts which argue that 100% of bugs may be able to be
fixed, but shouldn’t be. Instead, one should focus on serving the vast majority
of users under expected circumstances.

           Both blogs
focus on how impractical, and expensive, maintaining 100% stability or up-time
is. In the first focusing on bugs specifically they give many reasons why this
goal is unadvisable. The first is the prevalence of Agile Development,
dominating nearly the entire software development landscape. As such, the constraints
of this fast-paced development style limit the ability to do traditional QA testing;
if a program can have several revisions in a week, maybe even a day, then how
could a team reasonable test all these iterations. Instead, the author suggest
a stability monitoring tool to automatically test each revision.

           In
addition, they suggest that eliminating 100% of bugs would eliminate many which
users would never see, so why waste resources addressing them? Even if you
could fix everything how could you possibly know? This focus is reinforced when
considering the truly incredible breadth of devices that one may have consider,
and specifically in mobile development: where they cite the over 24,000
different android devices on the market. One must focus on the average expected
user experience and not waste time fussing with the outliers until, presumably,
a bug report is filed.

The second blog discusses
defects in systems in a similar way, covering more or less the same points, although
mentioning a rather obscure possibility: being legally challenged for claiming
that your product has no defects. Instead, what I believe they are trying to emphasize
is that products are always fallible, and the amount of resources required to
get them even close is impossible or impractical. As a result, as we move
forward in this class and towards graduation I think we should resist the impulse
to try for complete perfection and instead focus on what is achievable and
provides the best experience for the majority of users.

Sources

Not all bugs are worth fixing and that’s okay
The Zero Defect Fallacy

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.

Understanding Typescript

Let’s start by discussing javascript a bit. Javascript is currently a must know programming language in the computer science world. It is widely used for web development on both front-end and back-end development. Javascript can also be found in many other fields of development including mobile apps, desktop apps, and game development. 

Javascript language is quite user friendly and can even be considered easy to learn but it doesn’t come without its concerns of course. The same code you’ve written may work differently when used in different browsers such as Google Chrome versus explorer, or safari, for example. Javascript is also very stripped down so it can be easy to create errors by mistake especially for beginners. An example of this is that Javascript is dynamically typed. Programs don’t know the types of variables until they are assigned at runtime and then they must do an awful lot of referencing to figure out the type depending on the size of the program. Since types are not required there are no compiling errors or messages to tell you what you are doing wrong. It leaves a hard traced error if or not careful when working with your code. 

Now moving on to Typescript!

Typescript is a superset of Javascript which means it contains all the same functionality of Javascript as well as added features. Typescript compiles to plain Javascript so any code you write in Javascript will run just fine in Typescript, as long as you have written it correctly of course. The big additions of Typescript are type annotations, interfaces, and classes. 

As opposed to Javascript, which is dynamically typed, Typescript uses static typing. Static typing means that things like variable types can be checked at compile time since variable annotations are available. The code will still run if you have an error but you will receive a message warning you about the specific error that was detected. Also depending on your IDE it may offer the function of displaying errors to the user while they are typing. If you want to take advantage of this functionality then you can check out the Visual Studio Code IDE, which contains that function.

I chose to blog about this subject because I am a newcomer to this language and material. I figured if I did some research on my own and actually typed out the words then it would all become more clear to me what the relationship of Typescript was to Javascript and what they are used for in the real world. I feel now that I have this general overview and understanding of the language and its use that I can now conceptualize my own uses for it. I’m looking forward to implementing what I have learned about Typescript into my own projects.

Lease, Diana. “TypeScript: What Is It & When Is It Useful?” Medium, Frontend Weekly, 31 Jan. 2018, medium.com/front-end-weekly/typescript-what-is-it-when-is-it-useful-c4c41b5c4ae7.

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

GitHub and GitLab Issues

Week 9 started on Monday by dealing with the flagged GitHub accounts. As suggested by Dr. Wurst, I created a support ticket in the account and said that I was a student researcher testing out the GitHub platform for an open source project and if they could unflag the account and to contact Dr. Wurst if they had any questions about the project. I also included the issue of issue cards on project boards getting automatically removed by a spam filter. I copied this response for each one of the testing accounts so I ultimately filed 4 support tickets with GitHub. After that I tested out Dr. Jackson’s question about if shop managers on GitLab had the ability to manage their own subgroups if they are given owner permissions from the parent group owner. I tested this under the testing GitLab group by removing the shop manager account from the top-level group, creating a new shop subgroup, and adding the shop manager as the owner. This worked the way I thought it would and the shop manager was able to create subgroups within the shop subgroup and could add new members that weren’t in the parent GitLab group. I updated the GitHub issue card with confirming this finding. Then, I went on to read Dr. Jackson’s response to my earlier question of if it was still worth it to create documentation for GitLab Free based on his earlier response that GitLab Free doesn’t allow the creation of multiple issue boards and this would impact our use of the platform. Dr. Jackson’s detailed response included different ways of having workflows with the one issue board limit on GitLab Free. I ended up drawing some of these out on a whiteboard to visualize the concepts. I kind of like the concept of Dr. Jackson’s second option of having one board at the LFP level and that would be used by all of the shops. Although he says it is a disadvantage, right now I like the idea of all shops using one unified workflow as it makes documentation simpler and makes sure everyone is following the same steps to contribute to the projects. One question I have from this is how do the shop level boards look with this option or is it only just the one board in the LFP group? I also listened to the podcast he recommend about why a company switched from GitHub to GitLab. I found it pretty interesting and what they were saying mostly goes along with the differences I have found between the two services. I did like hearing from the perspective of someone who has a self-hosted instance of GitLab as this hasn’t been something I have been looking into but was interested in how this worked. Finally, Monday finished with discovering that our GitLab Gold membership wasn’t renewed properly and that we don’t have the Gold features available to us currently. This is a pretty big issue as it limits what I am able to test to just GitLab Free features. I emailed Dr. Wurst about this and he submitted a support ticket. 

For the rest of the week I checked to see if the GitLab Gold or the GitHub support tickets were updated. On Sunday I got a response from GitHub support to all of the support tickets saying that having multiple user accounts was against their terms of service and that they would remain flagged. I emailed Dr. Wurst about this and he would contact GitHub Education to see if there was anything they could do to help us. The GitLab Gold membership still hadn’t been fixed yet at this point. After looking at those, I went back to the diagrams I had been working on the previous week. I updated some of the GitLab diagrams to be consistent and fix an issue that it looked like the shop manager had to add themselves to a group which they don’t have to do. I then looked at some of the other documents in the community section of the LFP organization on GitHub to see how Dr. Jackson had formatted the other documents and what information to include. One thing I have a question on is what is the DCO and do I need to sign off on this for the commits I will be making to the project? Another is what to include for the licensing information at the bottom of the document? I then looked at the question Dr. Jackson had about if GitLab had an equivalent to the GitHub Probot framework for creating and using bots across the service. I found that although it seems possible to create bots on GitLab, they don’t seem to have a framework yet like GitHub does. 

Week 10 was short. On Monday I looked at the email response from GitHub Education regarding the multiple testing accounts. I found their response to be unhelpful to our situation and that their education features weren’t what we are looking for in testing permissions and project configurations for LFP. I took a quick look at the new website that Dr. Wurst created for LFP and how it currently links to the GitHub organization. I also read some of the principles listed on the LFP GitHub Community section like the Agile principles and the “FOSSisms“. I found the FOSSisms to be particularly interesting to read about with the process of contributing and working in open source projects, especially with how to get started with contributing to an open source project since that’s what I have been learning with this project. 

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.

Craft over Art

If you consider yourself to be a programmer or developer, you are not an artist. Programming is a craft, a type of art, but it cannot be classified as a fine art. It can be more constructive than artistic. As an programmer you will be paid to build something that helps the customers to have … Continue reading Craft over Art →

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.

Apprenticeship Pattern – Expose your ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

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

sweep the floor

Hello everyone and welcome back to another apprenticeship pattern blog post. Today blog post is “sweep the floor” which Is basically about what happens usually you’re a newcomer. The task will be simpler than you expect but as the more you learn the more skill you become and eventually you will start to have more complex tasks. I learned that when you are in a team and you don’t know your place on the team and the team is unsure of you, you should try to find some way to contribute so you can earn some trust from the new team. I agree with this completely because when I start with a new team I always try to contribute as much as possible, so I don’t feel like I’m not contributing. I learned from experience that it’s best to contribute early as possible because you don’t want to give a wrong impression even if you don’t mean it. The more you put in to the project the more people will respect you because if you don’t put in any effort, they will all think that you shouldn’t be on the team and you don’t know what you are doing. I learned that its’s really important to volunteer for any task even if the task is not unglamorous but necessary tasks. I agree that it show you can do any job and gives you a chance to display your work. I learned that I should tackle the grungiest task that everyone is putting off because it will show people that you know what you are doing and it’s a way to exceeds people’s expectations. Always try to make the task more creative so that it can be more fun to work on. All in all, I think this individual apprenticeship pattern sweep the floor is really important pattern to learn because it teaches you how to function when working within a new group. I took a lot from this pattern and agree with every information that it gives. I have implemented most these tips in my daily life and benefit from them.

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

“Read Constantly” Apprenticeship Pattern

I am writing this blog post about the “Read Constantly” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about spending more time reading about new material and ideas in order to stay in touch and learn about some new things. I think that this pattern is similar in many ways to the “Practice, Practice, Practice” apprenticeship pattern, because it is about taking the time and effort to become more familiar with a new topic. Reading research papers is an example given in the chapter. Any time I read about some unfamiliar topics, I always find that there is a huge depth of information that I have no idea about. Machine learning is one such topic that I spent a while reading about. After I had a good enough grasp of the basics behind the theory of it, I tried practicing implementing a basic multi layer feed forward neural network myself and have it classify some handwritten number symbols. Reading about it and implementing it was an interesting introduction into the field of machine learning, but continuing to read further into deep learning and the theory behind various learning algorithms, it becomes clear that there is still a ton about computer science that I have a ton to learn about. This is the case any time I look more than briefly into any broad topic. I was trying to implement a solution to a variant of the subset sum problem years ago and stumbled into NP-completeness and computational complexity theory. Constantly reading about new things is the only way to learn about different topics. The “problem” section in the book describes that there seems to be an endless amount of fundamental concepts that are unfamiliar despite proficiency in a programming language, and this is inevitable without reading constantly. Continuing to only practice in topics that are familiar makes it nearly impossible to expand into other fields without re-discovering them independently, which is unlikely when the areas are particularly advanced. Reading is like practicing learning. Proficiency in a language can only go so far.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

The Long Road

This week’s blog is gonna be about “The Long Road” pattern. This pattern is all about traveling the long road. No matter how much you try to master anything, it will always be ahead of you. Mastery is a lifetime journey. You got to love whatever it is you are mastering. That is why they said, “Choose a job that you love and you’ll never work a day in your life.”

The book suggests valuing long term growth opportunities over salary and some sort of leadership or managerial role.  This long journey to become a master will bring you a rich set of skills. You will become skilled at learning, problem-solving, and developing a good relationship with your customers. You will learn to wield these abilities and technologies. If you go through this long road, you will realize and appreciate what being a software developer really is.

This journey would not be short. It will be a long winding road. You should have a goal. Being on this long road, you will be a software developer even when you’re old. This pattern is not gonna make you filthy rich like the other positions, but it will be rewarding. This pattern is not for everybody, there are more people who will take a higher position without blinking an eye. Everyone wants to achieve something big and probably make more money.

I don’t really agree with this pattern. I think that taking the promotion would be a better path. It is not every day that a promotion would happen or a better position would be available. So why not grab the opportunity. It will also teach you more skills since it would it is a different role, it will also have different responsibilities. You will also learn how everything is run in the company and not get stuck at just creating software. They do talk about in the solution, that this long road does not only apply to being a software developer but for any position.

This pattern is good if you see yourself doing the same thing 10 years from now. Although, in my opinion, that is not a good thing to do. I think we need a bit of variety so that we do not get tired of it.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.