Author Archives: rydercsblog

9 Anti-Patterns You Should Be Aware Of

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

This blog post covers 9 anti-patterns that are common in software development.

Premature Optimization – Optimizing before you have enough information to make conclusions about where and how to do the optimization. This is bad because it is hard to know exactly what the bottleneck will be before you have empirical data.
Bikeshedding – Spending excessive amounts of time on subjective issues that are not important in the grand scheme of things. This anti-pattern can be avoided by prioritizing reaching a decision when you notice it happening.
Analysis Paralysis – Over-analyzing so much that it prevents action and progress. A sign that this is happening is spending long periods of time on deciding things like a project’s requirements, a new UI, or a database design.
God Class – Classes that control many other classes and have many dependencies and responsibilities. These can be hard to unit-test, debug, and document.
Fear of Adding Classes – Fear of adding new classes or breaking large classes into smaller ones because of the belief that more classes make a design more complicated. In many situations, adding classes can actually reduce complexity significantly.
Inner-platform Effect – Tendency for complex software systems to re-implement features of the platform they run in or the programming language they are implemented in, usually poorly. Doing this is often not necessary and tends to introduce bottlenecks and bugs.
Magic Numbers and Strings – Using unnamed numbers or string literals instead of named constants in code. This makes understanding the code harder, and if it becomes necessary to change the constant, refactoring tools can introduce subtle bugs.
Management by Numbers – Strict reliance on numbers for decision making. Measurements and numbers should be used to inform decisions, not determine them.
Useless (Poltergeist) Classes – Classes with no real responsibility of their own, often used to just invoke methods in another class or add an unneeded layer of abstraction. These can add complexity and extra code to maintain and test, and can make the code less readable.

I chose this blog because anti-patterns are one of the topics on the concept map for this class and I think they are an interesting and useful concept to learn about. I thought this blog was a very good introduction to some of the more common anti-patterns. Each one was explained well and had plenty of examples. The quotes that are used throughout the blog were a good way of reinforcing the ideas behind each anti-pattern. I will definitely be keeping in mind the information that I learned from this blog whenever I code from now on. I think this will help me write better code that is as understandable and bug-free as possible.

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

Lesser–Known Java Syntaxes

https://blog.joegreen.pl/lesser-known-java-syntaxes.html

Today I stumbled across an interesting little blog post on lesser-known Java syntax. The author gives examples of code that doesn’t look like it would compile, but is surprisingly still legal syntax. For example, a two-dimensional array is usually declared like this:

int[][] arrayOfIntArrays;
However, since the brackets can be placed after either the type or identifier when declaring a regular array:

int[] intArray;int intArray[];

A two-dimensional array can also be declared like this:

int[] arrayOfIntArrays[];

An interesting (although hard to read) application of this is that a single and multidimensional array can be declared on the same line:

int[] intArray, arrayOfIntArrays[];

This line of code declares an array intArray and a two-dimensional array arrayOfIntArrays. The second one is two-dimensional because the brackets are placed after both the type and identifier just like the previous example. The fact that another array is declared on the same line does not change anything. Although it is not very practical, it is still a very interesting use of syntax that compiles just fine. Similar syntax can be used when specifying the return type of a method. A method that returns a two-dimensional array would usually look like this:

int[][] fun();

But since brackets can be added to the end of the method signature, it can also look like this:

int[] fun()[];

Taking all of this to the extreme, a method that takes an array of arrays as a parameter and returns an array of arrays can be written like this:

int[] fun(int[] arrayOfIntArrays[])[];

Next the blog discusses the receiver parameter, which is a syntactic device for an instance method or inner class’s constructor.

class MyClass {
    public void method(MyClass this, int argument) {
    }
}

This code compiles and generates the same bytecode without MyClass this as a parameter. Currently the only use of this syntax is to annotate the argument.

The most commonly taught way to initialize an array is like this:

int[] intArray = new int[]{1, 2, 3};

However, the type of the array does not have to be specified twice. Instead, an array can be declared like this:

int[] intArray = {1, 2, 3};

But splitting this line of code into two lines will not compile. If the array is declared without being initialized, the new int[] must be included when the array is initialized.

I selected this blog post because I think it is very interesting and useful to see examples of code that don’t look like they should compile, but they do because there is nothing wrong with the syntax. It’s important for a software developer to know the ins and outs of the language they are developing in and knowing little quirks like this helps give a better overall understanding of the language. The more syntax you know the less caught off guard you will be when reading other people’s code, as nobody uses the exact same syntax in every situation.

I learned specific syntax from this blog that I will now understand if I ever see. These examples helped me better understand Java syntax in general, which will make it easier to read other people’s code and will make me less prone to errors.

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

Builder Pattern

http://marxsoftware.blogspot.com/2013/10/too-many-parameters-in-java-3-builder-pattern.html

This blog post details a way to reduce the number of parameters required for a constructor: the builder design pattern. In this pattern an object called a builder receives each parameter step by step and returns the resulting constructed object at once. This blog post explains the pattern by using detailed code examples. First a Person class is shown without the builder pattern to demonstrate how too many parameters in a constructor can become a problem. Then a PersonBuilder class is shown which conveys the idea behind a builder class. Each variable is set in a setter method, then a createPerson method returns a new Person with the values from the setter methods as parameters. With this implementation, the values of a Person are set with methods as opposed to the parameters of the Person constructor. There is a lot more code, but it is much more readable than having a very large parameter list. The next few code examples show how a builder class can be nested and enhanced with the use of custom types and parameter objects.

The biggest advantages of the builder pattern are usability and readability. Parameters are reduced and are provided in easy to read method calls. This approach also lets you acquire an object in a single statement and state. Also, it is even easier to apply an IDE’s code completion feature. The biggest drawback is that the number of lines of code are essentially doubled. Despite the fact that it is easier to read, the code is much more verbose. The author included examples of client code instantiating a Person with and without builders, which I thought was a good way to highlight the difference using a builder makes.

Instantiating with builders:

final Person person1 = new Person.PersonBuilder(
   new FullName.FullNameBuilder(
      new Name("Dynamite"), new Name("Napoleon")).createFullName(),
   new Address.AddressBuilder(
      new City("Preston"), State.ID).createAddress()).createPerson();

Without:

final person = new Person("Coltrane", "Rosco", "Purvis", null, "Hazzard", "Georgia", false, true, true);

As you can see, the builder implementation is extremely verbose but it is easier to read and harder to make a mistake. The more parameters there are, the more true this is.

I selected this blog after looking up design patterns in the gang of four book that we haven’t covered in class. I thought this blog did a good job explaining why this pattern would be used and the benefits and drawbacks of using it. I chose this topic because design patterns are one of the most useful things to learn as a software developer and if we end up covering this one in class I will be well prepared. I will definitely be applying what I’ve learned from this blog, as I’m sure every programmer knows how frustrating long parameter lists can be. I’m glad that now I know a design pattern that alleviates this problem.

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

Builder Pattern

http://marxsoftware.blogspot.com/2013/10/too-many-parameters-in-java-3-builder-pattern.html

Instantiating with builders:

final Person person1 = new Person.PersonBuilder(
   new FullName.FullNameBuilder(
      new Name("Dynamite"), new Name("Napoleon")).createFullName(),
   new Address.AddressBuilder(
      new City("Preston"), State.ID).createAddress()).createPerson();

Without:

final person = new Person("Coltrane", "Rosco", "Purvis", null, "Hazzard", "Georgia", false, true, true);

As you can see, the builder implementation is extremely verbose but it is easier to read and harder to make a mistake. The more parameters there are, the more true this is.

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

CS 343 Blog – 10 Java Coding Tips – 10/2/17

http://blog.stoneriverelearning.com/10-java-coding-tips-every-programmer-should-know/

This blog details 10 tips aimed at beginning Java programmers.

Get the basics right – Learning Java can be frustrating if you try to learn too many things in too little time. It is better to have a solid understanding of the basics before you try more advanced techniques
Don’t just read – The only way to get better at programming is to actually code. Reading books is useful but that alone will not turn you into an expert programmer
Understand your code and algorithm – Before you start coding, realize it on a piece of paper. The best way to solve a problem is to break it down into sub-parts and devise a solution for each sub part.
Do not forget to allocate memory – Memory allocation in Java using the ‘new’ keyword is a necessity. Not using it will create a null pointer exception
Avoid creating useless objects – Creating an object uses up memory and processor speed. It is good practice to not create an object until it is needed
Interface is better than abstract class – There is no multiple inheritance in Java, but you can use an interface if you want to implement something similar. Usually it is more useful to use an interface rather than an abstract class
Standard library is a bliss – Java has a rich set of standard library methods that make programming easier and more efficient
Prefer primitive classes over wrapper classes – Wrapper classes are often slower than primitive classes and comparing wrapper classes does not give desired results as it compares objects instead of the values
Dealing with strings – It is always better to instantiate a String object directly without using the constructor
Code, Code, Code – The only way to get better is to keep learning and coding

I chose this blog because most people in this class are beginner Java programmers and it is interesting to learn about tips that you might otherwise not know about.

I thought that most of these tips were too basic and it seems like this blog post was more aimed at people that are just starting to learn Java. However, there were a couple interesting code examples.

public class vehicles {

public List getvehicles(){

if(null == vehicles){ // this ensures that the object is initialised only when its required

countries = new ArrayList();

}

return vehicles;

}

In this example, the object is initialized only when it is required. This is similar to the singleton example we did in class where the Singleton object was instantiated in an if statement in the getInstance() method.

String slow = newString ("This string is making the system slow"); //slow instantiation

String fast = "This string is better"; //fast instantiation

This example taught me something that I didn’t know before: that the second line is a faster way to instantiate a String.

I thought this was a good blog post but I wish that it had more examples of code as the ones in this blog were interesting.

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

CS 343 Blog – New Theory on Deep Learning – 9/25/17

https://www.quantamagazine.org/new-theory-cracks-open-the-black-box-of-deep-learning-20170921/

This article from Quanta Magazine details a new theory on how the artificial intelligence algorithms behind deep neural networks are so successful. The theory, presented by computer scientist and neuroscientist Naftali Tishby, argues that deep neural networks learn by a procedure called information bottleneck. The theory states that a network gets rid of extraneous details in input data and only retains details most relevant to general concepts. In experiments, Tishby tracked how much information each layer of a network retained about the input data and output label. He found that layer by layer, the networks converged to the information bottleneck theoretical bound. This is the theoretical limit that represents the absolute best the system can do at extracting relevant information. Tishby’s discovery is an important step in figuring out exactly how neural networks work and gives a better understanding of which kind of problems can be solved by real and artificial neural networks.

I selected this article because artificial intelligence is an important and growing field in computer science. It will also have profound effects on society as systems like deep neural networks become more advanced. I think that as artificial intelligence continues to evolve it will become more important as a software developer to understand how A.I. systems work.

I thought that this article was very well written and did a good job of making a very complex subject understandable. From this article I learned the basics of how a deep neural network works. I think it is very interesting how the design is inspired by the architecture of the human brain. I also thought it was interesting how we aren’t even sure exactly how deep neural networks learn, and the information bottleneck theory that is detailed in the article could end up being a very important advancement in this technology. Naftali Tishby’s quote in the article summarizes the basic idea of this theory: “The most important part of learning is actually forgetting.” Tishby believes this is a fundamental principle behind learning whether you’re an algorithm or a conscious being. I think this is a very interesting viewpoint on learning that I did not know about before this article. Tishby believes that deep neural networks learn by receiving a large amount of input and then “forgetting” information that is not relevant until there is an optimal balance of accuracy and compression in the final layer. Overall I think this idea is very intriguing and is something that I would like to learn more about.

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

Introduction

This is my first post for CS-343 Software Construction, Design, and Architecture.

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

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: