Author Archives: Pawel Stypulkowski

Stubs

When it comes to testing software I am definitely all for it but at the same time I am for it by doing it the “old school” way. Even at work this mentality stands, but recently the more I learn about testing the more I understand the need for it.

Having learned more about the subject of testing I feel like I can talk a little bit about it. Stubs is the part I been educated on recently and it is a bit confusing but that will probably go away with time and practice. Anyway Stubs. Those in programming are (according to Wikipedia): a piece of code used to stand in for some other programming functionality. A stub may be a temporary substitute for yet-to-be-developed code. I do know how to use those but until now I didn’t know what they are called and that is cool in its own way. Everybody knows how to use some fake code that is there just to run something for a time or to fool rest of the code into working. Now you know what to call it to. A STUB!!!

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.

Testing, Testing and some more Testing

In my Testing class we are constantly learning some new techniques and ways to test software, although there is some hands on testing on actual code a lot of it is more theoretical or to be more specific it is describing how we can test. It is all useful I know it but as a CS major I do want to write code if possible, less theory please, more practice. End of rant? Maybe for now.

This week was about Define-Use Testing. It is somewhat simple concept and I am glad that I can learn about it. It showed us some of the ways that today’s compilers work and make comparisons to display errors in the code. The whole concept of Define-Use testing is all about visual inspection and checking of the code. This will be some useful information for certain aspects of Computer Science field.

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.

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.

Singleton…

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.

Digital Code apparently can smell.

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.

What is UML?

UML Diagrams – as a CS major at a university
I realize that sooner or later I would have heard something about it and had to
work with it, on that subject even though I am already a little bit familiar I
found myself a little bit lacking in knowledge because I simply didn’t have to
deal with it too much. To help me familiarize myself with them I stared browsing
the net and stumbled upon this blog
by Noel Ceta on Tallyfy website, which helped me to understand the topic a
little bit more.

                This
blog goes into some details about different types of UML diagrams and what are
they best used as well as how they look and present. It gives some examples on
each one of them which helps a lot to help and differentiate between them. It helped
me. Even though I am supposed to use UML at work because it helps with
documentation, I rarely do due to the time constraints of the projects I work on
and honestly nobody makes it a big issue, which is a problem, I think.

Noel in his blog uses one of the descriptions
of UML as follows: “Sketch – UML diagrams, in this case, are used to
communicate different aspects and characteristics of a system. However, this is
only a top-level view of the system and will most probably not include all the
necessary details to execute the project until the very end.

Forward Design – The design of the sketch is done before
coding the application. This is done to get a better view of the system or
workflow that you are trying to create. Many design issues or flaws can be
revealed, thus improving the overall project health and well-being.

Backward Design – After writing the code, the UML diagrams
are drawn as a form of documentation for the different activities, roles,
actors, and workflows.”. This description really fits with what I think UML is
and how it should be used.

                Over all
this blog post is a good way to introduce people to UML and show them what a powerful
tool they can be if, like in my own life’s example, they are used and people
spend time to work with the design of their software starting with UML. I believe
everybody should learn about this because not only CS majors will find it
useful but others as well, for example a business person who can describe the
relationships in their business to better understand it or to describe it to
others.

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.

Before we start….

To kick things off for my blog
about Software Architecture I would like to say a few words about programing
itself. I have recently read a blog
post
by Joseph Gentle called “3 tribes of programming” from May third of
2017.

In his blog he talks about a subtle
but nevertheless existing differences between people who write code. Gentle
says: “… I think there’s fundamentally 3 architypes of programmers, divided by
which ideals we hold in highest esteem: You are a poet and a mathematician.
Programming is your poetry; You are a hacker. You make hardware dance to your
tune; You are a maker. You build things for people to use. We self-select into
communities of our peers based on these ideals. We use coded language to
express these ideals to our peers. I think each group has its own conferences,
and its own subreddits. Its own programming languages, heroes and its own
villains.”, and I could not agree more. Each camp as he says has its own quirks
and they are spelled rather plainly in my opinion.

I have chosen this blog to write about
because it gives me and hopefully other an idea of what kind of a programmer one
wants to be, and how I will possibly design my software in the future. I work
as low-level programmer for a big company, and I work with some very talented people.
Take my boss for example, in accordance with this blog and its descriptions he
will be in the second camp (The Hardware Hacking people) but with a small twist
of camp 1 (Mathematician) since he loves beautiful and easy flowing code. Based
on that I would be in the 3rd camp, I use programming as a tool to
make things, be it a simple app to help me with things or something work
related to help me in that aspect. I like people using my software and having
some feedback about, even if it not too good at least I know somebody took their
time to check it out. I design my programs with the end user in mind most of
the time.

Reading Gentles blog helped me to familiarize myself more with how others might think about programming and how to approach certain aspects of it, but it also helped me see that “Ultimately code is code. Even though we have different reasons for writing software, what we write is (usually) compatible. And even when it’s not (looking at you, Haskell) – there’s always a lot of ideas we can learn from and steal.”. We all have some part to play in this world of Computer Science and we all help each other one way or another, no matter which camp somebody belongs to.

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.

Learning with POGIL

This is going to be my second semester with POGIL (Process Oriented Guided Inquiry Learning) style classes and I have to admit I am a fan. The classes are a lot more involved for students and in my opinion it makes it a lot more interesting and helps with retaining information about topics.

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.

Let’s get it done

Being an older student (not too old, I’m only 32 at the moment) makes me somewhat feel like I am late to the party all the time, but at the same time I realize I have the drive and also the experience required to finish what I have started. I want to learn new things, especially the ones I’m interested in. So just like I have said in the title: Let’s get it done!!!!

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.