Category Archives: Week 8

HTML (Hypertext Markup Language) and CSS(Cascading Style Sheets)

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.

7 Ways to be an Efficient Software Tester

Link to blog: https://testlio.com/blog/how-to-be-an-efficient-software-tester/

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

“Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports 

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

  1. Write with detail
  2. Write with clarity
  3. Write for others

Write Clear Test Cases 

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive 

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

11/6/17 Software Development

Manifesto for Adaptable Software Development

This post is from the same blogger as last week’s. This post is about the manifesto of software development. The blogger gives a list of activities in to columns. The left columns are activities that faces challenges on the right column in software development. The blogger briefly goes over what they mean and gives an example of each. Experimentation instead of Specification: Instead of writing software program with specifications, write a software program with room to experiment and make changes along the way as needed.Example: Build a minimum viable product which allowed the programmer to delay decisions until the last responsible moment. Sound engineers build flexible software platforms to support cost effective experiments.  Evolution instead of Implementation: Instead of writing the system for implementations write it where there is room for it to evolve over time. Example: Domain modeling allows users to capture the essential aspects of an application while enabling future specializations. Adaption instead of modification: Write code that can easily be changed over time when needed, instead writing code with the modified changes and no room to make future adjustments. Example: Frameworks with several alternative components that may be chosen at a time needed. Extension instead of growth: Instead of writing a system for allowing the code grow overtime, create extensions making easy access to change the code when needed. Example: Plug-ins allow the user to add new features to an existing application without increasing its size or complexity.

This was an interesting blog. This blog how software development changes over time and how to keep up with the new changes. I like the example the blogger gives for each item on the list. They gave me an idea on how to adjust code when needed. This also give me a better idea of what plug in are. I’ve seen the word in the past on my computer when I try to run a game or a video on the internet. Shortly after that I am notified to update the flash on my computer and then usually the gam or video starts working again. Sometimes it does’t but that’s when the computer is old and outdated. Framework is something I already knew from this class and several other previous classes I took. This blog gave me a better idea on how frameworks can help make adjustments to coding over time, by being able to add and move parts at different times when needed.

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

Test Automation

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming.  With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Refactoring

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

behavioral vs Structural Testing

Behavioral

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

Podcast Highlights

https://www.codingblocks.net/podcast/clean-architecture-programming-paradigms/

This podcast, coding blocks episode 69, talks about various aspects of coding paradigms. So in this post ill summarize some of the topics i found interesting and insightful.

firstly, before their main discussion they talked about a question from a viewer that is definitely worth mentioning. The viewer is a project manager with the question: “if there is a room full of programmers working on a project, and another room with just a handful of programmers, which room is more productive and why?” The general consensus from each of the hosts concluded that there is a lot of valuable communication that gets streamlined through having just a few people, and blocked by having too many people. However, there is a certain threshold where obviously 300 people can do more work than say 50. So the answer really depends on the situation, which is up to the project manager to decide based on the project itself.

Skipping a few minutes down the podcast, around 40 minutes they start discussing interfaces. Allen states his basic rule for using interfaces, where if your coding something that doesn’t have any behavior, just a bunch of data, there is no reason to use an interface. In any other case however, if your coding something that has any behavior at all, it should be an interface. He says that even if you never use that interface for inheritance, the effort isn’t wasted in assuming that you might use it for something later. Joe jumps in by saying that using interfaces makes it much easier to change or debug your code with less volatility, overall if you don’t know if you should or shouldn’t make an interface, its probably a good bet that you should.

Later on towards the middle-end of the podcast, they start talking about the open closed principle. In this concept, changes can be made to code only by extending it and nothing can change the original directly, in this way all code is completely additive. This concept is very good because literally perfect base code is created and cannot be changed in any way, but still widely used. Joe remarks that some companies actually have a problem where developers are too scared to change base code that they may not fully understand, so they create a copy of it and only change the copy which leads to clutter. however, when done correctly, this concept is extremely efficient and easy because the coder doesn’t have to rewrite certain segments.

I recommend listening to this podcast, these guys are easy to listen to and know a lot about many different subjects of computer science. I’m sure you can learn something new with every podcast as these three hosts have both fun and educational banter.

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

Object Oriented Programming

Source: https://medium.com/omarelgabrys-blog/the-story-of-object-oriented-programming-12d1901a1825

This week I decided to write about Object Oriented Programming. I found a really helpful blog written by Omar El Gabry. This is his own blog talking about object oriented programming. I honestly wished I wrote about this sooner because it would have explained things to me much easier then when I was trying to learn for class. This blog explains all about object oriented programming. He breaks things down step by step even explaining what objects, classes, attributes, behaviors, etc. mean. I really like this in a blog because when someone with little or no programming background can be able to understand what he is talking about. In the blog he even gives real world examples talking about object orientation. He then talks about abstraction and what abstraction means. He uses the example of a car and what do you think about when you hear the word car with abstraction it’s the color or the size of the car and that is basically what abstraction is. It is the adjective of the car. He then talks about encapsulation where in code we don’t want to write out super long programs because there are things that we write that we don’t want someone to read or have access to so we would just hide the classes we write and restrict access to it. He gives a very true statement that I think every coder should take to heart is that when you encapsulate something we should hide as much as possible because in the real world you do not want everyone seeing what you wrote. He even added code so people can mess around with it and see how it works. In the code he has classes called animal and then dog, duck, and kangaroo that extends to the animal class and the main class uses the animal class to prints the name of the dog and the color of the dog and everything like that.

 

I thoroughly enjoyed reading the blog because it was a good refreshment of what I just learned and a much easier explanation of what I did before. To me I don’t think it would affect my future learning practices but I do think it’s a good recap of what I did before. I may just come back to it if I ever want to have a quick refresh or even send it to a friend who is thinking of learning about programming.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Post #10

This week, I will be preparing a tutorial on the Observer Design Pattern and I figured I could assist my own understanding of the pattern by writing a blog post to accompany it.  This post will be a summary of the Observer pattern as it is described on this page of the Object Oriented Design website.  The motivation behind the Observer pattern is the frequent need of objects, in object oriented programming, to be informed about the changes that occur in another object.  An exemplification of this concept in the real-world can be imagined as a stock system which provides data for several types of client; the subject(stocks server) needs to be separated from its observers(client applications) in such a way that adding a new observer would be transparent to the servers.

The intention of implementing the Observer pattern is to define a one-to-many dependant relationship between objects so that when an object’s state is altered, its dependants are notified and updated automatically.  The Observer pattern is effectively adhered to with the implementation of 4 classes:

  • Observable/Subject(GOF) – interface or abstract class; defines operations for attaching/de-attaching observers to client
  • ConcreteObservable – concrete Observable class; maintains state of an object and notifies Observers when a change occurs
  • Observer – interface or abstract class; defines notification operations
  • ConcreteObserverA, ConcreteObserver2, etc. – concrete Observer implementations

How it Works:

  • ConcreteObserverable object is instantiated in main framework
  • ConcreteObserver objects are instantiated and attached to ConcreteObservable object via methods defined in the Observable interface
  • ConcreteObserver objects are notified each time the state of the ConcreteObservable object is changed
  • ConcreteObservers are added to the application by simply instantiating them in the main framework and attaching them to the ConcreteObservable object

This allows for classes, that are already created, to remain unchanged.

The Observer pattern is applicable in situations where the change of a state in one object must be reflected in another object without keeping the objects coupled, and in situations where the main framework needs to introduce new observers with minimal changes.

The Observer pattern is often used, in conjunction, with other design patterns:

  • Factory – A Factory pattern can be utilized to create observers so no changes will be required in main framework
  • Template – An Observer pattern can be utilized to make sure that Subject state is self-consistent
  • Mediator – A Mediator pattern can be utilized in cases of many subjects and many observers

The Observer pattern is so well-known because its implementation has proven to be quite powerful in event handling systems of languages such as Java and C# and in the model-view-controller architectural pattern.  I am excited to put together a tutorial on how to use this pattern and I believe that having a good grasp on its motivations and intentions will aid me in future if I ever consider using it.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

How to simplify your life as a Software Developer

Link to blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

Throughout the time the I spent as an individual when it comes to coding, it takes me awhile to write the perfect code that I need for my college homework assignments. Sometimes, I would try and write code during my free time if I’m bored and implement a certain design that I would attempt to do. After I finish writing the code, I feel that I could’ve done it more quickly and efficiently without having to write so much code, or try to edit and fix the code so many times. I know that I have a tendency to repeat code and make it more difficult than it already was. As I’m trying to improve on being an efficient programmer I know that I have to stop myself from repeating code, and to keep it simple when it comes to a specific design pattern while fulfilling the necessary specifications.  In this blog written by Jonathan San Miguel, he identifies three principles to keep the life of a developer simple as possible. These principles are KISS, DRY, and YAGNI.

KISS: This acronym stands for “Keep it Simple, Stupid!” It basically means that try to keep your code clean and simple as possible. The simpler the code is, the simpler it’ll be to maintain it in the future in case if you want to edit it. Miguel also adds “avoid using fancy features from the programming language you’re working with only because the language lets you use them…use them only when there are perceptible benefits to the problem you’re solving.”

YAGNI: This acronym stands for “You Aren’t Gonna Need it!” This means that as the programmer, you need to focus on your specification and write the code that does that particular task without adding anything extra such as features you think you might need in the future.

DRY: This acronym stands for “Don’t Repeat Yourself!” Try and prevent yourself from writing code that is similar to others that you previously wrote. “Maintain the behavior of a functionality of the system in a single piece of code” as Miguel noted in his blog. This principle is useful especially in big applications where they are constantly maintained, changed, or extended by many programmers.

Among these three principles, I think I need to focus on the DRY principle the most because I do have the tendency to repeat code. If I can improve on that, I’ll be golden, and coding won’t be that much difficult for me. Jonathan San Miguel briefly explained that main points of each principle, which made it easy to understand. He also gave his advice on some of the principles and identified which principle was useful for certain circumstances. Understanding these three principles will help me in my future career as a video game developer because when I write the code for video games, I’ll have to condense and simplify as much as I can within the design so the software can run smoothly and efficiently. It will also help me save time to do other things with the code too.

 

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.