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.

This week was all about design
patterns and ways to implement them. We have only just begun and to start with
we talked about Singleton. It is a design pattern that creates a single
instance of a class to be used from a well-known access point. I had some previous
interaction with this particular design pattern at my work, when we were using
the C++ language this was one of the ways we got around some of the problems we
had, since moving to C# it went away but still I knew about singleton before
this weeks class at school. I was a little bit curious and wanted to read about
it more, so I looked up blog post by Ted Neward called, surprise, surprise: “Singleton”.
Link to it is here.

                In this
blog Ted talks about it extensively in my opinion, from the context of it, the
problem that it solves and the consequences of the Singleton implementation. I definitely
like the information provided and it help me expand my knowledge of the design
pattern, which is a good extension on my current knowledge both from work and
school. One of the parts in the blog really helped me understand it better and
that is: “Reduced name space. “Singleton” is just “global” hiding behind
another name. One of the explicit goals (in 1995) was to be able to have the
necessary scope-wide state, but without accidentally clashing over names in
that global namespace. Languages which support explicit namespacing (Java, C#,
C++, Swift, yeah pretty much all of them) mean that we can have this benefit
even without doing anything more than moving the global variable into one of
those namespacing mechanisms.” This describes Singleton as global and I like
this description because it really drove home what Singleton is and how to use
it, I think….

                Overall,
I know I will be learning about many other design patterns and implementations
but for now having this is good enough, who knows maybe others will be a better
solution than Singleton, but I think it is the simplest one to learn. Neward
mention couple of time the debate of Singleton vs statics and that is something
interesting on its own. Something that I will research a little bit more when
time allows. Until then I remember one thing my boss said about singletons back
in the day: “Singletons were used everywhere, and somehow it worked, we didn’t
know why, but it did.”

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.

How can code smell? This was my
question last class in my Software Architecture class, and I was surprised to
learn that it can. Not literally of course, but because code can be written in
a manner that somebody may say that there is something going bad in here, as
food would. According to Wikipedia
Code Smell is: “any characteristic in the source code of a program that
possibly indicates a deeper problem” and “Code smells are usually not bugs;
they are not technically incorrect and do not prevent the program from
functioning. Instead, they indicate weaknesses in design that may slow down
development or increase the risk of bugs or failures in the future.” This is a
very interesting topic in my opinion because it can make me and other alike to
be a better coder and help us avoid common mistakes.

While searching for some more
information about the topic I have stumbled upon blog by Jeff Atwood that gives
and describes different kinds of smells that code can have. This directly related
to my class and helped me to specify different problems that can arise when I create
some software. In the class we have described smell in a little bit broader
scope then in the blog, which describes more detailed cases. For example,
Atwood gives us this: “Long Method – All other things being equal, a shorter
method is easier to read, easier to understand, and easier to troubleshoot.
Refactor long methods into smaller methods if you can.”, and in my opinion
anyone writing code nowadays can agree with that assessment. I know it can be
hard sometimes to write a short method because it would be more functional, and
that is a one of the subjects of one of my classes I took before about writing
clean code.

In my opinion this blog is a great reference
for everybody who wants to keep in mind problems that can arise, or to say avoid
you code from smelling a certain way. I know it will be helping me a lot both
in my school and professional life. Eventually anybody can learn this by heart
and know it  at the drop of a hat, but
for me until it will become almost a reflex I know I will be probably using
this post and other like it as a reference. Anybody who has plans to have a career
in a Computer Science field should learn this.

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.