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.

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.