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.

Decision table

Source: http://www.softwaretestingmaterial.com/decision-table-test-design-technique/

This week I decided to write about Decision tables.  I found a great blog called Software testing materials.  They had a blog post called Decision Table Test Case Design Technique. Written by Rajkumar. In this blog he talks about decision table test case. This test technique is appropriate for functionalities which has logical relationship between inputs. In designable they deal with many different combinations of situations, inputs, and test and they would give you examples of what kind of output would be expected with the inputs. Here he gives a few examples of decision tables. In the examples he gives conditions to be able to transfer money. Conditions are account already approved, one time password matched, sufficient money in account. Then according to if each one is true or false it would do an action such as. Transfer money, show a message as “insufficient amount”, block the transaction in case of suspicions transaction. Then according to if one of the conditions are false it would do action 2 or 3 but if everything is true it would transfer the money. A much simpler decision table test that he gives is the case of entering a username and password. The conditions are Valid user ID and Valid Password. The actions that would be given is Home page or Show a message as “invalid user credentials” if any time the username or the password is False it would show the message for invalid user credentials. But if both are true then it would go to the home page.

I like this blog because it breaks down how decision tables work.  Raikumar gives very easy and understandable examples of how each of the decision table work. He explains it step by step that anyone who has no knowledge about decision tables would be able to understand what a decision table is. I would use this blog for future homework or even use this information to show future students are learning about decision tables to show them how they are used and made. I think that decision tables can be used in everyday life not in just computer science but in making choices for everyday life big and small.

Design Patterns

Source: http://www.bambielli.com/posts/2017-04-02-decorator/

This week I am writing about Decorator design pattern. I found a blog by Brian Ambielli called Design Patterns: Decorator. Here he talks about decorator and how it works. Decorator patterns allow us to extend object with added functionality at runtime. It allows developers the power to compose objects that are purpose driven for the current demands for their users. He talks how decorators can be thought of as super types where they are wrappers around the object they are decorating. They can be used and passed in a program in place of the original wrapped object. He gives us an example using pizza as the topic where you can make a pizza either a deep dish or thin crust pizza and gives us choices of what kind of topping you want the toppings are wrapped by a decorator that allows the user to choose either the pepperoni topping or cheese topping. With this blog, he even talks about the downside of the decorator. Some of the limitations that the decorator pattern has is that the code relies on the type of concrete implementation that you are wrapping. With decorators, they often have numerous small classes that are each responsible for one behavior modification. This makes code hard to read and understand.

 

What I like about this blog is that is has a very good example of how decorator design patterns work and they even give us the code to even test it with. With this we can even test and mess around with decorator designs. In the blog he talks about when you should even use decorator design patterns and this is very helpful for people who want to try and test out these design patters in their own code. I also like how he doesn’t just talk about the good of decorator design patterns he talks about the bad about it. So we know which kind of design patters would work for different situations. What I would do this this blog is that I think I would read up more about different deign patterns and try and test it out with some of the code I write seeing which ones I like the best.

Software Testing Life Cycle

Source: http://blog.mallow-tech.com/2016/02/software-testing-life-cycle/

This week I looked up software testing blogs. While searching the web I found this one blog called mallow-tech. there was this one blog post called “Software Testing Life Cycle” written by Periannan, a test engineer for Mallow Tech. In this blog it talks about what software testing life cycle (STLC) is. Software testing talks about the testing process that has specific steps to be done to make sure that the code meets the quality standards. For many companies they have different phases for STLC however the base of it is the same for every company. STLC usually has six phases. Requirement Analysis, Test Planning, Test Case Design, Test Case Execution, Re-Testing and Regression, and Final Testing and Closure. In the Requirement Analysis phase this is where the team talks to the client about what they want and talks to the team of developers about what parts are testable and how they would run those tests. The next phase is test planning which they see what kind of they are going to use to test out the code. Number three is test designs this is where test cases are created according to the specifications for the project. Next is the test execution. Here they execute the tests in logical sequences with specific test data. Next is the retesting and regression testing phase by this time the tests would have been done and the bugs would have been reported. The team would then fix those bugs and then run the test again to make sure everything was fixed. Lastly final testing and closure is where the final parts of the STLC is completed and they start to send it out into the public to find out if the code works.

This blog was very helpful for me because I did many blogs about different tests that we have to do but this blog talks about the process of testing. With this blog I think it is super helpful as an add on to my other blogs. In the real world we are not going to just run tests one right after another. We need a plan on what to do and when to do it. This shows me that everything in the computer science world is not just doing code and making sure it works it is all about doing things in steps just like how we write code it should be neat and organized and planned.

YAGNI

Source: http://deviq.com/yagni/

This week I decided to look up blogs about YAGNI also known as “You Ain’t Gonna Need It.” This blog called DevIQ had a post about YAGNI. For me this was the first time I have ever heard of the acronym. This blog talks about how most of the times people code things for the future of the development. However, it is not a good thing to do. For many programmers, they follow this rule because it maximizes the amount of unnecessary work that is left undone. Features that are not necessary is a huge source of waste. In the blog, they compare YAGNI to the Just-In-Time manufacturing. Instead of ordering a bunch of parts based on what you think you are going to get you should order the parts based on what the customers need. This insures that you don’t waste money and time. This is the same as programing where you should just keep things basic and never try to do anything over the top and try to keep things to what the customer wants done. The blog talks about keeping code simple. Avoid adding features and complex designs unless it is needed. There is a good quote that is in the blog also that says “every line of code we don’t write is dollars we didn’t spend, and time on the calendar we get back for free.” This to me is very simple but powerful because it talks about how we should not over complicate things because it would not be worth the time and money we are putting in to trying to make it better.

To me this blog is something I should follow to heart because when I was doing my assignment 1 for a class I was reading too much into the assignments and was making things way too complicated for myself. There were times I wanted to delete the whole code and rewrite it however luckily in the instructions it said not to change anything and just to add a few lines. This kept me on track for my assignment. So with the YAGNI I think I would be keeping this to heart for as long as I code because this is something that many programmers especially people who are programing for the 1st time should hear about.

Ethical Hacking

Source: https://www.computersciencezone.org/what-is-ethical-hacking/

This week I found a blog called computer science zone. There was this one blog that caught my eye which was called What is Ethical Hacking? Ethical hackers sound like an oxymoron because when you think of hacking you think of people who break into people’s computers, small business accounts, and websites. Where they would go on and steal personal information such as bank accounts, addresses, social, and many other things. The people that I was just talking about fall into the category of black hat hackers. However, there are hackers that are not all about stealing information their people are called white hat hackers. These people are actually hired to hack into company’s websites to find security leaks or holes so that way they can take care of it before someone who is trying to do serious damage can find it. There are a few specialists that this blog talks about as well such as information security analyst, security engineer, and penetration tester. As an information security analyst, they are responsible for solving security problems are companies and origination with substantial technology and informational infrastructure. Because of this there are a team of it professionals that monitor the database for these companies and they even ward off cyber-attacks daily. With security engineer, they are responsible for beefing up the security that they have and even creating new and effective ways to make the security for the company even stronger. With penetration tester, they are responsible for maintaining secure connect ability between internal and external communications. This means that they are often between email servers and accounting and communication software and the internet to keep hackers from invading those firewalls.

I like this blog a lot because it talks about a few future jobs that we have available to us as computer science majors. They even give the amount of money you make what you do at the work place and where they are usually at. This blog is very cool to read because when I was taking data security we learned about white and black hat hackers and I was very into that topic that it was really cool to see that there are different types of hackers in the work and not all of them are out in the world trying to do evil. So, it is nice to see that with computer science we are able to do many different jobs with many different people from small business and even muli-billion dollar companies.

Tips and Tricks

Source: http://www.codingdojo.com/blog/7-tips-learn-programming-faster/

Today I read up on a blog called Codingdojo. This blog was written by Stephen Sinco. In this certain blog post, he wrote a post called “7 Critical Tips to Learn Programming Faster.” In this blog post, he talks about things to help new programmers to learn programming faster. A few of those tips that caught my eye are to learn code by always doing code. When learning a new chapter, you should do little personal projects with the new methods or ways to write the code as soon as possible because that way you will be able to learn the new chapter more efficiently. It also talks about doing code by hand. This is very surprising to me because I always thought that we would always have a pc to work on. To many people this may seem like basic tips and tricks but it is very important to remember these tips.

To me this blog was very helpful especially writing the code by hand. I think I would start doing this every once in a while, to be able to learn code more efficiently. With these tips, I think it is something we all should read while we are coding because there are times when we are debugging things and we just get frustrated and we lose focus so I think it would be good to take a quick break and relax.

Levels of Testing

Source: https://blog.testlodge.com/levels-of-testing/

Another week into my blog for CS 443 this week I decided to look up blogs about levels of testing. While I was searching the web, I found a blog testlodge by Jake Bartlett he wrote a blog post titled “Levels of Testing In Software Engineering” here he talks about the levels of testing in software engineering. There are 4 levels of testing he talks about. Unit testing, integration testing, system testing, and acceptance testing. The first testing that most people do is unit testing. It involves testing pieces of code to make sure each one is right. With unit testing it helps verify internal design and internal logic, internal paths, as well as error handling. Unit testing is usually done by the developer who wrote the code. The second level of testing is called integration testing. This level of testing test how well each of the code works together. Each class is usually combined and tested as a group. This way it identifies interface issues between modules. The third test is called system testing with this kind of testing it test the entire application. This is done in a test kind of environment where the program would be sent out to. With this kind of test, the application is tested from beginning to end. This test is usually done by the testing team and includes a combination of automated testing and manual testing. Finally, the last test is called accepting testing. With this level of testing it test if the software is ready to be released. This kind of testing is mostly done by the business user and end user. With these levels of testing it show that testing is not just a onetime thing it is multiple test just like my other blog talks about. You have to make the right kinds of test and test often.

I chose this blog because I wanted to stay on the same topic I did for my last blog and keep with testing. I liked this blog a lot because it makes things easy and clear to understand and breaks each testing in to different levels and gives a clear description of what each of the testing is about. With testing ideas, I learned that you will never have enough tests. So, to make sure you are efficient when testing you have to break down your testing into different levels. I think the blog will help me a lot in the future because I will be testing a lot of code for class, school, work, and personal projects. Know what to these how to test and when to test is the best way to use my time efficiently.

 

Proxy Pattern

Source: http://java-design-patterns.com/blog/controlling-access-with-proxy-pattern/#author-info

Another week into writing my blogs and I found this new blog called java-design-patterns written by Ilkka Seppälä. He wrote a blog post called Controlling Access with Proxy Pattern That talks about proxy concepts. He talks about how proxy concepts work and how useful it is. There are many ways where the proxy pattern is useful. Protection proxy, virtual proxy, caching proxies, remote proxies, and smart proxies. With protection proxy’s they can limit the access to the real subject. He gives an awesome example talking about the protection proxy where he makes a public interface WizardTower. He then writes a class called IvoryTower which implements WizardTower. What the IvoryTower did was that it kept track of who went into the tower and how many Wizards are in the tower. To keep the tower from over filling and to keep the tower nice and organized he then writes a class called WizardTowerProxy that implements WizardTower with this it has the wizards have to go through this proxy before even entering the tower. With this proxy it only allows 3 wizards max to enter the tower and if anymore tries to go in it would say “{} is not allowed to enter!”

I chose this blog because at first when I skimmed though it I saw the words wizards so I was like this is it. I then continued to read the blog even more and I found that that it is a super helpful blog about proxy patterns. I like this blog a lot because I don’t know much about proxy except for the basic stuff so this gave me a wider range of information. I also like that it even has an example with code to follow. So that way I know what I am reading and I know what it looks like in an actual code. I also like how it made the blog more interesting by bringing a little humor into the code and kept me wanting to read it because with code it usually is just boring stuff and most people just skim through it and not think twice about it. However, with this it was entertaining to read and I wanted to continue to read it. I think that this blog would be very helpful in the future because in my CS 343 class we are talking about diagrams and in the beginning it shows a diagram of the code that he was talking about and I thought that was nice since I know more about diagrams now because of that class.

Testing Code

 

Source: https://blog.bugsnag.com/better-software-testing/

I found a blog post called “You don’t have enough tests and you never will!” by William Starling. This post he talks about how there is never enough tests for coding. The reason why people do test is because the earlier you find a bug the cheaper it is to fix it. The sooner a developer finds the bug right after writing the code they can quickly fix it. He then goes off by talking about different tests such as unit testing, integration testing, and system testing. Testing is hard and software is complex. No matter how many testing you do there will always be a bug. He says a lot of software teams gets too caught up on trying to measure how much testing is being done. Sometimes they would do an unhelpful testing that would say the program is 100% correct but they are testing for the wrong behavior and the test itself could be buggy as well. So what is the best testing strategy? Typically the best is where you are testing for major and the most obvious bugs at first. Then you would test things that would affect the security or integrity of the program.  An example he talks about is that what if you want to make a self-driving car so you don’t want to have it drive off the road thinking it’s still within the lines. More tests does not mean there are going to be less bugs. Focusing the tests in the right places can be the difference between a good code and a bad code. Examples of areas where testing can make a difference is complex logic, public accessible interfaces, and high impact code. You should also design your code to be able to modify later on to fix those bugs. Once the program is out for the public the best way for bug testing is the consumer themselves. When people are using the software they will find things that many programs will never think of so that way.

I chose this blog because testing code has come up a lot whenever I write code. In class, we do code that no matter how we wright it once it prints that final line we are done with it. However once we get out into the real world we are going to be writing code that will be used constantly and would be seen by billions of people and sometimes it won’t run the way that we expect it to and we would have to fix it so reading up on how to text and what test we should do is a good way to prep-ourselves for future projects