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.

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 #5

Today I will be summarizing and providing commentary on a blog post from The Developer’s Piece called “8 design patterns that every developer should know”.  I was immediately attracted to the title but I was even more pleased when I actually read the article; it not only provides clear and concise descriptions of each pattern, it also provides examples of each pattern in practice in the form of code chunks.  Among these reasons, I primarily chose this article to be the subject of this week’s blog post because it lists patterns that we have and will cover in class.  Like I said in my last post, nothing is better than when you have thorough understanding of why you are covering a piece of material in school.

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

Limitations of Inheritance and how to solve them using composition

In java, you can use one type as template of making another type. The new type can inherit all the same behavior as the original type. This is known as inheritance. Java class inheritance allows you to reuse existing type functionality and let you make modification in behaviors as it fit. Inheritance in the other words is when you design your classes by what they are rather than what they do. This is also term as “Is-a relationship” which sometimes can be misleading. For example, an SUV car or Sedan car can inherit the supper class base Car/ Vehicle on the “Is a relationship” functionality. The same time, it could be implemented based on the “Has- a relationship” functionality because, a car has a tire, break, engine etc. so when it comes to determining which one to implement, this becomes a little bit confusing. This seems to be very bad to me because the sub classes are base on the super or base classes and when something accidentally changes from the base classes, it automatically affects the sub classes.

Composition in the other hand is a design technique use to implement has-a relationship in classes unlike an inheritance which is an “IS A” relationship classes. Composition is basically designing the class base on what they do. According to Wikipedia, composition is a principle that classes achieve polymorphic behavior and code reuse by containing instances of other classes that implement the desired functionality rather than inheriting from the base or parent class.

Again, in composition, we can control the visibility of other objects to the client classes and reuse only what we need.

In general, composition is has-a relationship between objects, it is implemented using instance variables, code can be reused, it hide visibility to client classes and more importantly is it flexible to use.

Now, what do I learn from this study? I have come to learn that implementation of composition over inheritance basically start with the creation of various interfaces representing the behaviors that the code will perform.

I have also learn that inheritance will not only encourage you to go predicting the future which may or may not work but it also encourages you to built the branches of object very early in the project and you are likely to make a very big design mistake whiles doing that because we cannot predict the future even though we feel like we could. To me, inheritance is very bad way of designing classes as sub classes may inherit some functionalities from the supper classes which will never been used but cannot do away with it. With regards, I do not see myself designing a projects using inheritance unless for educational purpose project that will explicitly require me to use of inheritance. I will always go for composition when designing project with multiple functionalities.

Citations:

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

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

The Importance of Cost Effective Software Testing

I chose to write my post about this article because I am guilty of thinking “I’m pretty sure this works” and not testing my code, then running into a bug later on. I’m not the only one is guilty of doing that, developers and companies around the world often do the same thing, and though sometimes we get away with it, other times it completely blows up in our faces. I wanted to read this article to see the arguments the author had against this common dev habit.

The first and most obvious argument that the author gave was making certain that the system actually met it’s objectives. Developing a product is expensive, and companies might think that it’s more effective to just have the developers “test” as they code, and save money by not having a dedicated team (or at least not a big one). The problem that comes up with this is that as a dev the pressure is on you to just get the product out there, and testing often takes a backseat. Yes, you might have saved some cash by skipping on testing, but you’ll end up losing a lot more money when the client gets the product and it doesn’t even work!

The author had many more strong points, but the most significant was how he elaborated that in some cases, not testing enough can be catastrophic and even fatal. For most software we typically test with a pretty high level of confidence, we might test a few edge cases here and there and move on. In other cases (Air Traffic Control, Medical Software, etc) you have to test for certainty or else you have a lawsuit or even death(s) on your hand.  This post was mostly geared towards the importance of testing for businesses in general, but it did a pretty good job solidifying in my mind how important that testing that I never want to do is. It made me realize developing isn’t just about getting any code out as quickly as possible, and that in the long run good testing will save you time and money.

 

source: http://www.softwaretestingtricks.com/2013/08/Importance-of-Cost-effective-Software-Testing.html

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

WSU Blog #4 for CS-443

CS-443
CS@Worcester
Week-4

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

WSU Blog #4 for CS-343

CS@Worcester
CS-343
Week-4

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Blog 4: Final, Finally and Finalize Response

Hello readers, today I read a short blog about the terms in Java known as final, finally and finalize and how they are all different. It is written by guldencirakblog who wrote for the blog known as the java diary.

The first word he talks about out of the three is Finalize. He talks about how finalize is a method shown as Finalize(), and the method is found in the java.lang.Object and it works as a Garbage Collector system only when an object or variable is still not being used anymore. The method with finalize is protected as well but can also be overwritten when you want to dispose a resource in a program.

The second word he talks about is Finally which is a block that is used with try/catch blocks. Finally is usually found at the end of these blocks because it is the final condition for the try/catch block so it passes the test. Finally is very important for exceptions and is key for Java.

The final word(ha see what I did there) is final. Final is used so things such as variables, methods and classes are not changeable. For example, if a variable is like Final String next, then that string cannot be changed after it is declared. For a class if it has Final before it, it doesn’t allow it to be derived.

Now to the reason I choose this blog entry, not only does it apply to Java but it is concepts that my class are familiar with but I don’t know if everyone fully grasps what each one of them does besides maybe final. This blog has helped me understand each of these terms better and may help me apply them later in future programs. The one I was not very familiar with was finalize, I don’t remember if I have ever used it in a program before but it doesn’t seem like the most difficult method to put into a program. Could be helpful to have just to put certain parts of my programs in there. Finally and Final were terms that I definitely remember using before and I definitely can use again after reading this blog and understanding them more. In our classes though, we don’t really ever use final since it really isn’t never needed in our programs and honestly, I haven’t had that much practice with finally but I remember how to use it. I know some of my friends in my class that may benefit from a little refresher with this blog post. Hopefully, sometime this semester I come across a time where knowing these concepts could be very helpful and I would have to thank this blog post for refreshing my memory. Thank you for reading my blog post, tune in next week for another entry.

Source: https://javadiaryalt.wordpress.com/2017/09/25/final-finally-and-finalize-keywords-in-java/

From the blog CS@Worcester – Benderson's Blog by bendersonsblog and used with permission of the author. All other rights reserved by the author.

Code Coverage Alone Probably Won’t Ensure Your Code is Fully Tested.

For this week’s CS-443 self-directed professional development blog entry I read a blog post written by Mark Seemann, a professional programmer/ software architect from Copenhagen Denmark. The blog post I read is entitled “Code coverage is a useless target measure,” and I found it to be quite relevant to the material we’ve been discussing in class the past couple of weeks, especially regarding path testing and data-flow testing. In this blog post, Seemann urges project managers and test developers not to just set a “code coverage goal” as a means for measuring whether their code is completely tested or not. Seemann explains that he finds this to be a sort of “perverse incentive” as it could encourage developers to write bad unit tests for the simple purpose of just covering the code as the project’s deadline approaches and the pressure on them increases. He provides some examples of what this scenario might look like using the C# programming language.

In his examples, Seemann shows that it is pretty easy to achieve 100% code coverage for a specific class, however, that doesn’t mean the code in that class is sufficiently tested for correct functionality. In his first example test, Seemann shows that it is possible to write an essentially useless test by using a try/catch block and no assertions existing solely for the purpose of covering code. Next, he gives an example of a test with an assertion that might seem like a legitimate test but Seemann shows that “[the test] doesn’t prevent regressions, or [prove] that the System Under Test works as intended.” Finally, Seemann gives a test in which he uses multiple boundary values and explains that even though it is a much better test, it hasn’t increased code coverage over the previous two tests. Hence, Seemann concludes that in order to show that software is working as it is supposed to, you need to do more than just make sure all the code is covered by unit tests, you need to write multiple tests for certain portions of code and ensure correct outputs are generated when given boundary-value inputs as well.

The reason I chose Mark’s blog post for my entry this week was because I thought it related to the material we’ve been discussing recently in class, especially data-flow testing. I think it is important for us to remember, when we are using code based testing techniques, that writing unit tests to simply cover the code are not sufficient to ensuring software is completely functional. Therefore, it’s probably a good idea to use a combination of code and specification based techniques when writing unit tests.

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

PayPal’s Interesting Design Pattern API

PayPal is a massive online American banking and currency handler that allows users to transfer funds electronically. PayPal originally started out as a company that developed security software for handheld devices. This article describes the different design guidelines through the years of developing the API. All of PayPal’s platform services have been connected through RESTful APIs. REstful is an API that uses HTTP requests to GET, PUT, POST, and DELETE data. It is commonly known as the architecture style for designing networked applications. We have learned that, through design patterns, we can optimize and organize our code in efficient ways to make later implementations of other objects easier. I chose this article because it is another look at practical implantation of design principles for large businesses.

From the article, we can see that the basic principles for PayPal’s design foundation are very similar in what we are currently implementing in our code. Some of the principles include that are discussed in the article are Coupling, encapsulation, stability, reusable, contract-based, consistency ease of use, and externalizable. Since these APIs are developed with consumer business in mind, each of the principles follow a catered idea for each. For loose coupling, the services need to be loosely coupled from each other. This makes it so that components in a network can work together, but do not heavily rely on each other. Encapsulation is also important in order to group certain attributes together. This makes it so that we can restrict direct access to certain part of an objects components. The stability principle important in that we need to make the program stable. The code should also be reusable so that it can be used across multiple different instances and by different consumers and users. This is important for team collaboration and organization as well because if multiple people can understand where an issue is occurring, it can be solved a lot faster. For contract-based functionality, it needs to be shared using a standardized service. This makes it better to create a standardization because it loops back to the reusable principle and makes accessibility more seamless. As for ease of use and consistency, these both work hand in hand because since the service needs to follow a specific set of rules and attributes, it also needs to be easy to create for consumers. The last design principle is externizable, which requires that the service can save and restore the contents of its instances.

I learned that these design principles are interesting because they seem to be a great tool to use when designing a program because it offers fundamental guidelines for optimization. I expect to apply these principles in my future practice by remembering the importance of how code should be organized to make it accessible to the consumer and to the programmer.

Source: https://www.infoq.com/news/2017/09/paypal-api-guide

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Acronyms to Remember

Source: https://blog.codinghorror.com/kiss-and-yagni/

This week’s reading is on KISS and YAGNI by Jeff Atwood on Coding Horror. Jeff touches upon and shows enthusiasm towards effective practices of KISS (Keep it simple, stupid!) and YAGNI (You Aren’t Gonna Need It). He mentions that just because you learned something complex that could be applied to your current project, it doesn’t mean that you should implement it when there is a more simpler option available. That is the idea of KISS. Lastly, he mentions that developers should follow YAGNI to combat the mindset of implementing solutions that you don’t need currently.

These two topics about KISS and YAGNI are very interesting because of how people are usually taught to think but when applied to programming, it doesn’t help but make things worse. Choosing to read up on this blog, allows me to see how more experienced developers feel about those who do not understand or value the two practices. Also, this is related to smelly code as it will help fight against dead code! In this case, I can feel that it is indeed a wise choice to pick-up KISS and YAGNI early on. Although, I have yet to write much programs that needed complex solutions. I do remember situations where my implementations were much longer when compared to other students, which could be a result of lesser understanding upon certain fundamental topics or lack of experience. Example being, the other student’s implementation of a loop for a solution is much shorter but does the same thing as my longer loop. It’s not exactly KISS, but it does show that sometimes things can be done in a simpler way.

Overall, understanding or knowing either practice will help save time when it comes down to getting things done. By knowing YAGNI, I will not implement things I don’t need until it is needed. By polluting the code with unused implementations, it will most likely create complications for later functions when it is used. However, if I don’t need it by then, the time spent creating the implementation for the future would be wasted time and not saved time. Then we have KISS which is rather straightforward, but should be a clear reminder that it’s when you can keep it simple, not always keep it simple. These two concepts will help me keep the code clean, and maintainable to a point where implementing newer features will not be as frustrating as when you work with smelly code.

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.