As a junior in college majoring in CS, naturally I cannot stop worrying about what is going to happen to me after I finish college. I recognize that I am not the best programmer in my major, there are plenty of colleagues I know with more experience, better grades, and stronger connections that will help move their career down the line. Comparatively, I worry about my own standing in the industry once we all graduate, so what am I to do? Firstly, enough self deprecating, I need some experience.

https://www.quora.com/How-do-you-get-a-programming-job-or-internship-if-you%E2%80%99re-a-sophomore-CS-major-but-dont-have-experience-How-do-you-choose-a-project-and-set-goals-for-it

This link is a question posted on quora.com asking how to get a job as a CS major in college with little experience outside the classroom, with advice from people currently in the field. The first person down the list of answers, Jane Huang, has particularly useful and calming advice. She goes over 5 points explaining how to answer this question, each of which can apply to various people with the same question.

Her first statement is meant to immediately disarm any person panicking and stressing out over what to do. She emphasizes that although it seems like life is hitting us fast, we are still very young and have plenty of time on our hands to gain experience with. She includes that interviewers will cut you some slack generally as they expect you to learn as you go.

Next she states that its very important to learn a framework, any framework. You can get by as long as you know either ruby on rails or django in python, since most frameworks are similar and you can adjust accordingly after you learn at least one. This isn’t a particularly daunting task, you can learn django in about a week if you practice it about three hours a day. It is also important to just start working on a project that you can manage, it doesn’t have to be original or groundbreaking, just finishing a project is good experience and something you can show as knowledge outside the classroom.

Lastly she makes the point that you might not enjoy coding, and should consider another field you might enjoy more. This isn’t meant to demotivate anybody in the field, you can do it if you believe you can do it. Her point is that if you are afraid switching your major too late and hate the idea of having to spend another year in college to make up for it, imagine spending many more years in a field you find you don’t like and dragging yourself to work every day to support yourself or your future family. Conversely, you don’t have to absolutely love programming in order to succeed professionally. It isn’t required that you have an extreme passion for programming, so really don’t think about it too much but don’t commit to it if you honestly don’t like it.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Source: https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/

SOLID Class Design: The Liskov Substitution Principle written by Tom Dalling on Tomdalling.com is a five part series about the SOLID class design principles in OOP. He starts off with a problem about inheritance. For instance, if you had a penguin which is a bird that falls under an “is a” relationship. However, when the penguin inherits from the bird class, it will also inherit the fly method. As soon, as you set the fly function to do nothing, then it violates the LSP. Then Tom explains that from applying the Open Closed Principle, subclasses must follow the interface of the abstract base class. If the class has to be altered in such a way to account for certain classes then it also violates the Open Closed Principle of being able to extend a classes behavior without modifying it. In conclusion, two solutions are presented, one is adding a method to check for a flying bird or non-flying bird. The other which, he states as a better solution, would be to create separate classes to account for a flightless type, that way the fly method is not inherited from the superclass.

After doing assignments for CS-343 revolving around refactoring a pre-existing poorly implemented code by applying design patterns. I did not realize that we touched upon the Liskov Substitution Principle before reading the blog post. However, choosing this post, serves as a great source of review material upon topics covered in class. The assignment that incorporated multiple design patterns started off with a clear application of the LSP, as the original design had two instances of overriding to do nothing. However, the criteria for our first refactor requires the LSP and other inheritance reworks.  Since we were working with Ducks, you can imagine a QuackBehavior and a FlyBehavior, that incorporated real and inanimate ducks. So, the LSP application is similar to the second solution presented earlier, in which the fly and quack methods aren’t inherited from a superclass but rather an interface later implemented by the duck class. But even though the method still does nothing, it isn’t an override method, so it does not violate the LSP.

Like other OOP principles, these exist to help achieve code that is maintainable and reusable. By acknowledging the existence of these SOLID class design principles, it will hopefully prevent future projects from projecting these type of code smells. Also, by understanding them and utilizing them wherever they suit best, my code will be cleaner, easier to maintain and add new features.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

This week is another blog post on code review. Unlike the other article which gives suggestions, this article is an overview of code review. So, what is code review? This article defines it as a systematic examination of programming language source codes. It main intent is to find and fix mistakes overlooked in initial development phase. This helps to improves the quality of the software and also helps give critiques on the developer’s skills, which is always an advantage to improving their skills.

Why are code reviews important? We start with some statistics. The article lists that the average rate for detecting defect is 25%, the rate found through functional testing is 35%, and that found through integration testing is 45%. In contrast, the rate of defect detection through code review is 55% to 60%, indicating that code review is one of the most important aspects of code review. The article further goes on to list some important statistics on code review that I thought were extremely interesting. Before code review were introduced into the organization, it is estimated that about 55% of one-line maintenance changes were in error. After its introduction it decreased to 2%. After code reviews were introduced it was estimated that 95% were correct the first time whereas before under 20% were correct the first time. In an experiment, a group of 11 programs were developed by the same group of people. The group were split into 2 groups. The first 5 developed without code reviews. The remaining 6 developed with code reviews. After its release into production, the first 5 had an average of 4.5 errors per 100 lines of code. The other team had an average of .82 errors per 100 lines of code. Reviews were found to cut the errors by over 80%, which demonstrates the importance of code reviews. For this study however, I wonder if for both teams the individuals had equal experiences and skills. Were both sides equally weighted? An interesting statistics is the IBM Orbit project. IBM’s 500,000 line Orbit project used 11 levels of inspections and had only about 1% of errors.

Finally, we close off this blog post with a discussion on the main goals of code review. The article lists the main intent to spot and fix defects early in the development process. The second goal is to share ideas with other team members, so that everyone can share from one another. Sharing ideas then helps to maintain a level of consistency in the design and implementation. Finally, code reviews helps to build confidence in the stakeholder about the technical quality of execution. Code review overall, helps to create more confidence and reliability in the product, since as a team it is easier to catch bugs.

Overall, I choose this article because I strongly believe a good code review is always difficult to conduct. It takes practice to be efficient. This article emphasizes the importance of code review in software engineering, but still it takes time to develop the essential skills to be effective in code reviews. That is why I chose this article this week to emphasize the importance of code reviews and to learn about its main intents and advantages in software engineering.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

I chose the article “Software Analysis and Design Tools” because I think it’s important to know how to put design knowledge to work using the common tools and practices. Software design and analysis allows the requirements of an application to be converted to actual code. I chose Tutorials Point for this article because I’ve used them quite a bit as I’ve learned different topics in computer science.

The first tool that is mentioned is a data flow diagram. This is basically a graphical representation of the path of data in an information system including incoming, outcoming, and storage. It’s important to know that this flow does not convey underlying “how” the data actually flows, it just shows the path. The two types of DFD’s are logical and physical and they use a set of components to represent data flow and relationships. This includes entities, processes, data storage, and data flow which are organized into different levels which represent a layer of abstraction.

The next tool used is called a structure chart which is actually derived from a data flow diagram. It shows a system in much more detail down to the lowest functional modules and describes the functions of these modules. The actual chart depicts a hierarchy of modules where each layer performs a specific task. The charts use special symbols to represent things like conditions, jumps, loops, data flow, and control flow.

The next tool is called a HIPO diagram which stands for Hierarchical Input Process Output. This diagram represents a hierarchy or modules in a system and depicts all the functions and sub-functions of a module. They are a good tool to represent system structure and allow designers and managers to picture the overview of a system.

There is also a diagram called IPO which stands for Input Process Output. This diagram shows a good representation of control and data flow in a module as the HIPO diagram does not depict the flow of any data.

Some of the other tools mentioned in the article include pseudo code, decision tables, entity-relationship models, and data dictionaries.

After reading this article I think I realized there’s a step in the software design implementation that I’ve been overlooking. Creating these models and diagrams mentioned is a pre-cursor to choosing a design pattern or implementing any code. Creating a usable understanding of how a system will work is a crucial first step in any design. I think this article did a really good job or covering some of the more popular software analysis and design tools. When it comes time to design an application I will definitely make sure I’ve represented the system using one of these tools before I think about the actual design pattern or architecture I want to use.

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

I chose this topic because I tend to forget exactly what kinds of tests are being done when system testing is mentioned. The term is very vague so I thought it’d be smart to write my own explanation of it. I chose the specific article “What is System Testing?” because I’ve used articles from this website before and have found them to be helpful.

To start, system testing is the testing of a complete and integrated software system. The important part of this is to recognize an entire system and not just one program. Interfaces, programs, and hardware are integrated frequently and there needs to be a way to test how they all work as a system. System testing is how this can be achieved.

System testing is one type of black box testing (as opposed to white box testing). System tests examine how software works based on a user’s perspective. One of the things being tested are the fully integrated applications in an end to end testing scenario. This checks for how components interact with each other as well as the system as a whole. Inputs in the application will be tested and compared to what is the expected outputs are. Lastly, a user’s experience is also part of the system testing to ensure the system flows and can be navigated smoothly by the end user.

While system testing is extremely important it’s not the only type of testing needed and it’s important to realize when it needs to be conducted. Typically it will be towards the end of the development cycle as most of the system needs to be operating correctly in order to properly execute the test cases. Unit testing and integration testing will come prior to system testing and usually acceptance testing will follow.

While there are quite a few types of system some of the more popular types include usability, load, regression, recovery, and migration.

After reading this article I definitely have a better and clear understanding of what system testing is. I think this article gave good explanations and included a helpful video as well. In order to actually implement system testing on a project I’d need to do some further reading on one of the specific types in order to decide what type best covers my system. I haven’t had the need to really implement system testing so far mainly because my programs have been relatively simple. As I head to the work force this type is testing will become very important working on much larger systems.

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

Mediator Pattern

      This week, I chose to talk about a blog I found that went over the mediator design pattern and its implementation. The blog post starts off by explaining that the mediator design pattern is a famous pattern found in the Gang of Four book. It is known to reduce coupling between classes that can communicate with each other. The basis of this pattern is to create a mediator object that has control over the channels of communication between the objects. All messages to other objects essentially must go through the mediator to be directed to another object. The blog post says that this eliminates the need for the deploy objects to have knowledge of the receiver objects. The post goes on to talk about the removal of direct dependencies as it can simplify communication in programs with a large number of classes. It then talks about some of the positive effects this may have like making the code easier to read overall and the maintainability for future editing. The post then goes on to explain the pattern with an example that uses communicating between colleagues and mediators within a project.

      I chose this blog because it was a design pattern that focused on communication between classes which I find very interesting. I found that the explanations this blog uses makes it very easy for me to understand how this design pattern works. The easy to digest wording allows for an easy read that works well with the examples used. The phrasing within the examples allowed the UML diagram and the definitions of the classes underneath to make more sense. The only issue I had was with following the code at first glance due to the fact that it was written in C# but it didn’t take me long to piece it all together. The test classes were well written to show meaningful variable names as well making it easier to understand the parallels they were making from the examples. Through this information I was able to learn that if there is a mediator it can be implemented to make sure all the objects don’t hold unnecessary amounts of code in terms of communication. This will cut down on code within class heavy projects that need objects to remember each other’s addresses. This will help me in my future practice by making the code run much more efficiently and create a better sense of organization that makes it easier to read when dealing with many classes.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer

This blog discusses various techniques that can be used to make your code cleaner and easier to understand. Writing high quality code is very important for software that is updated over time, and the following tips will help improve your code readability and quality.

Variable and Method Names

• Use names that reveal the intention of the variable or method
• Use names that can be pronounced
• With programming languages that support namespaces it is better to use them rather than prefixing names
• Use one word per concept throughout the program. For example, don’t use get and fetch to do the same thing in different classes
• Use solution domain names
• Use verbs for method names and nouns for classes and attributes

Better Functions

• The smaller the better
• A function should only do one thing (single responsibility principle)
• Less arguments are better
• Functions should only do what the name suggests and nothing else
• Avoid output arguments. If returning something is not enough then your function is probably doing more than one thing.
• Throwing exceptions is better than returning different codes dependent on errors
• Don’t repeat yourself

Comments

• Don’t comment bad code, rewrite it
• Explain your intention in comments
• Warn of consequences in comments
• Emphasize important points in comments
• Always use doc comments
• Any comments other than the above should be avoided
• Never leave code commented. With source control software you can always revert back to old code. Comments can be used when debugging or programming, but commented code should never be checked in

Code Smells and Anti-Patterns

The following should be avoided:

• Dead code
• Speculative generality
• Large classes
• God object
• Multiple languages in one file
• Framework core modifications
• Overuse of static
• Magic numbers (should be replaced with const or var)
• Long if conditions (replace with function)
• Call super’s overwritten methods
• Circular dependency and references
• Sequential coupling
• Hard-coding
• Too much inheritance (composition is better)

I selected this blog because being able to write high quality code is extremely important in software development. Quality code decreases time spent trying to understand it, making the code easier to maintain and reducing the possibility of bugs. I thought this blog was very well done because it was entertaining to read and gave plenty of examples. Reading this blog helped cement ideas that I learned previously from this class and taught me new techniques that increase code quality. Since none of the information is hard to understand I can begin applying what I’ve learned right now, and hopefully I will continue to get better at writing clean code.

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

HTML which stands for hypertext markup language and CSS(Cascading Style Sheets). Are what i decided to read about since with our final project with the typescript and angular , we will need HTML and CSS for it to work properly. Also giving it a better graphical look or user interface with the help of CSS.  Hope you viewers enjoy the article.

HTML stands for Hypertext Markup Language, and it is the most widely used language to
write Web Pages.
* Hypertext refers to the way in which Web pages (HTML documents) are linked
together. Thus, the link available on a webpage is called Hypertext.
* As its name suggests, HTML is a Markup Language which means you use HTML
to simply “mark-up” a text document with tags that tell a Web browser how to
structure it to display.
Originally, HTML was developed with the intent of defining the structure of documents like
headings, paragraphs, lists, and so forth to facilitate the sharing of scientific information
between researchers.
Now, HTML is being widely used to format web pages with the help of different tags
available in HTML language.

HTML Tags
As told earlier, HTML is a markup language and makes use of various tags to format the
content. These tags are enclosed within angle braces <Tag Name>. Except few tags,
most of the tags have their corresponding closing tags. For example, <html> has its
closing tag</html> and <body> tag has its closing tag </body> tag etc

A typical HTML document will have the following structure:

Document declaration tag
<html>
<head>
Document header related tags
</head>
<body>
Document body related tags
</body>
</html>

HTML Attributes

Attributes provide additional information about HTML elements.

• All HTML elements can have attributes
• Attributes provide additional information about an element
• Attributes are always specified in the start tag
• Attributes usually come in name/value pairs like: name=”value”

Now let get into CSS(Cascading Style Sheets).

CSS(Cascading Style Sheets) describes how HTML elements are to be displayed on screen, paper, or in other media. It saves a lot of work. It can control the layout of multiple web pages all at once

CSS is designed primarily to enable the separation of presentation and content, including aspects such as the layout , colors , and fonts . This separation can improve content accessibility , provide more flexibility and control in the specification of presentation characteristics, enable multiple HTML pages to share formatting by specifying the relevant CSS in a separate .css file, and reduce complexity and repetition in the structural content.

Separation of formatting and content makes it possible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. It can also display the web page differently depending on the screen size or viewing device. Readers can also specify a different style sheet, such as a CSS file stored on their own computer, to override the one the author specified.

Changes to the graphic design of a document (or hundreds of documents) can be applied quickly and easily, by editing a few lines in the CSS file they use, rather than by changing markup in the documents.

example of Css

<!DOCTYPE html>
<html>
<head>
<style>
body {
background-color: lightblue;
}
</style>
</head>
<body>

<h1>Hello World!</h1>

<p>This page has a light blue background color!</p>

</body>
</html>

output:

Background will turn lightblue. try it!

Even though i know much about this article. It really helped me refreshed my mind on some stuff i forgot. now with no doubt , i know i will utilized this info to work better on my final project. Hope you guys also find this article very useful.

references : 

https://www.codecademy.com/courses/web-beginner-en-HZA3b/0/1?curriculum_id=50579fb998b470000202dc8b

https://www.w3schools.com/css/css_intro.asp

https://en.wikipedia.org/wiki/Cascading_Style_Sheets

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.