The pattern “The White Belt” is all about becoming a student once again and not letting your knowledge or expertise in a certain subject get in the way of learning new things. The pattern also talks about how you should put aside past experience and unlearn things so that you can understand what you were struggling to learn. The pattern also wants you to use a new language or style to solve a problem so that you don’t fall into the same hole that you have been when it comes to learning. I often find myself in a similar problem when it comes to programming because I often use similar code in future projects or rely heavily on what I know works versus trying new things that may work better. This pattern is similar to other patterns but focuses on relearning or learning new things and setting aside past experience. I felt that this pattern is important to remember for my professional career cause I could see myself facing a similar problem to the one described in the pattern.
I think that an extremely important part of the pattern is that you should try to learn from other people. This part of the pattern is discussed and is the key focus of the pattern “Be the Worst”. I do not like the fact that they continue to blend patterns together since it makes it harder to distinguish between the different patterns. I think focusing on learning new things without allowing old knowledge to corrupt the new knowledge is an important part of learning anything and especially coding. With the way people can easily connect on common interests and topics on platforms like Discord, Twitter, FaceBook, and more, I can see myself joining different coding communities and interacting with other people that may have more knowledge on a topic than me, in order to learn more in different areas of coding. This pattern has given me a new way to avoid getting stuck in a rut that is common in the computer science field. Using different languages is important to better understand the inner works of what a function does and how it can be implemented in different ways.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

All the big CEO’s and entrepreneurs will give you trite advice on their LinkedIn pages: you need to fail a lot in order to succeed a lot.

I can’t be too hard on anyone who wants to get this message out, because I had to hear it at some point too. Failure meant incompetence to me, not part of the path to success. But what if failures don’t stop? The “Learn How You Fail” apprenticeship pattern attempts to solve the problem of lingering failures despite increased success.

This is likely due to something you are repeatedly doing that causes the failures. Hone in on these behaviors, because changing them is the only way to stop failing. Furthermore, you may simply not be good at some things, and finding these things can prevent wasted time and effort.

A potential problem with this pattern is that a lot of failure is likely due to blind spots in our perception of ourselves, so it’s likely not easy to solve the problem of uncovering the cause of our failures. But as software developers, our skills in pattern recognition should be top notch. Carefully documenting your failures and how they connect should reveal the patterns.

A coworker asked me years ago what my chosen superpower would be. I answered that I would want to know everything. Omniscience. Besides briefly earning me the nickname “know-it-all”, this reflects my own desire to fix my unfixable flaws. Now, I do think significant effort should be put into things that you are especially bad at. But this pattern is a good reminder to let go of the things that you’ve tried to do and simply haven’t worked out.

Success is many cases is figuring out what you are good at, not about fixing all of your weaknesses. This is the reasons the US President has a cabinet, Congress has subcommittees, companies have divisions, and software team members have roles. We can’t all do everything.

My biggest issue with this pattern going forward will be striking a balance. There will always be a desire to learn as much as possible. Gaining more skill and broadening horizons may be tempting, but knowing when to give up in a specific area is the challenge. The CEOs who credit their success to past failures knew what to give up on within their chosen field. Almost always, this doesn’t mean choosing a brand new career; it means finding what you’re doing wrong in the current one.

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.

Reading consistently give you ability to happen our mind.

And when reading connately about good programming, it will build you knowledge and would open more understanding of programming.

“If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.”

Books are the key component for growing. Not even book, just the articles or some options on a certain programing tasks you are doing. 

I like how this section cover the need of reading the words. looking at the word and understanding it. We as a software developer should not only be doing readings on the language tat we are familiar with but also on other languages that is some how connected it the pervious one.

The similarity will connect the broad perfection of a different but yet similar languor. For example,  HTML and CSS are quite similar, java and javascript function and calls are similar but are implemented differently. 

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

For my final project in my Software construction, design, and architecture class, my partner and I had the idea of creating a web page that was able to access data of a SQLite database. The structure of this project was to connect to a database using Java as a backend and use Rest api to send out sql commands. We needed to run the backend on a server using a Spring Boot framework available to us. Once our connection was setup and our backend methods to access the database was ready we had to create the front end. We used Typescript and Java Angular to create our front end, or in other words our web page. The typescript code had to connect to the Java rest api so our chain of connections from the top goes; Typescript and Angular -> Java Rest api -> SQLite database. 

Starting the project the very first obstacle we ran into was connection Java rest api to the SQLite database. It was something we had never done before, but thankfully there was helpful resources online. We found out that there was a series of Java imports to facilitate this function. A few imports needed are as follows:

import java.sql.*;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

Using these imports we were able to create an object of type ‘Connection’ in order to establish the actual connection to the database. Here is our method:

public static Connection getConnection() {

   if (conn == null) {

       try {

           conn = DriverManager.getConnection(“jdbc:sqlite:” + dbpath);

       } catch (SQLException e) {

           e.printStackTrace();

       }

   }

   return conn;

}

The set method to set our path:

DatabaseSQL.setPath(“C:/…(insert path here)…”);

We are now able to get the connection inside our Java rest api classes that contain our SQLite query methods using this statement:

Connection conn = DatabaseSQL.getConnection();

As I said this information can be found through many sources online so we were lucky such a function was available for us to use at our disposal. We needed the connection to be established before we could proceed with anything else because the entire project relied on accessing the database. However, in order to actually know if our connection was working we couldn’t rely on the absence of errors. We needed to create a rest api method to access the database and give us a result so that we could be sure.

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

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.

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.