This is another video from Joel Spolsky. I found this video through the last blog entry from last week. In this video he talks about the impact of coding in everyday life. He uses a taxi as an example of how coders deal with coding. he mentions if the person tries to make the taxi turn right, instead of the taxi turning right, it might have the trunk pop open or the taxi turn in the opposite direction. The driver will ask what’s wrong and try to figure out the problem. The driver will go online and find another driver had the same problem asked the question then was given the answer.  The driver could use the answer to solve his problem. Before stack overflow, there was a site online where programmers post questions to a coding issue, then would have to pay the company money to see their own answers that they have written up, Stack overflow was created where programmers can write questions to the program they have a problem on and other programmers can answer. Those answers are rated by other programmers who use the site. Those ratings can help a programmer build their reputation as a programmer. This could possible lead to jobs as a programmer in the future. Programmers need every detail of instruction for the program to run properly. Like mentioned before, algorithms are used in software design to run programs on websites. These algorithms allow a site to post certain pictures, articles and other posts, based on what the user is searching for or their feelings towards a certain topic or event.

The video was interesting. Joel uses everyday trends such as Uber and Facebook to explain how coding works in general and how it is used in everyday life now. I picked this video because I really liked the last video, and video was similar to the last one. The last video talked about programming and coding effecting the future of people. This video talked about coding impacting everyday life of today. This gave me a better  idea of how a website work and how a program runs. Again this shows me what expect in the workforce of a programmer. Joel compared the early days of programmers working similar to working at an assembly line. Programmers were hired to create a program write it and run it, and doing it in small cubicles with computers that did not work properly. Now a days programmers work with he company on the spot to make sure the program runs properly and fix and problem as they arise. This gave me a better understanding on how algorithms work on a site and how to use them for when I create a site and run it.

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

In a post by Yegor Bugayenko, Single Statement Unit Tests,

“..I believe, can help us make our tests, and our production code, more object-oriented. Here it is: a test method must contain nothing but a single assert.”

He makes use of the assertThat() that is available from Hamcrest. Benefits to using assertThat() are: Reusability. Classes needed to create test assertions are reusable in other test methods and test cases. Brevity. Shorter and readable code that’s easy to understand. Readability. Using a single assert, the intent of the test will always be apparent. Immutability. No need for setters or getters if we limit use of algorithmic code in tests.

He uses and example method RandomStreamTest from OpenJDK 8, created by Brian Goetz:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
final Random r1 = new Random(seed);
final int[] a = new int[SIZE];
for (int i=0; i < SIZE; i++) { a[i] = r1.nextInt(); } final Random r2 = new Random(seed); final int[] b = r2.ints().limit(SIZE).toArray(); assertEquals(a, b); }

In this example there are two parts, the algorithm which creates two arrays of integers and the assertion which compares them using assertEquals(). The author recommends modifying the code to look like this:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
assertEquals(
new ArrayFromRandom(
new Random(seed)
).toArray(SIZE),
new Random(seed).ints().limit(SIZE).toArray()
);
}
private static class ArrayFromRandom {
private final Random random;
ArrayFromRandom(Random r) {
this.random = r;
}
int[] toArray(int s) {
final int[] a = new int[s];
for (int i=0; i < s; i++) { a[i] = this.random.nextInt(); } return a; } }

The change is the test is that there is only one statement in the method now.

Yegor notes

"The biggest benefit we get when this principle is applied to our tests is that they become declarative and object-oriented, instead of being algorithmic, imperative, and procedural."

I chose this resource because it's an interesting way to design tests and the benefits of using assertThat() might be of use to me in the future. I think it is important to keep up on the best unit-testing practices if I want to write good code to match. I'm also interested in looking more into Hamcrest.

Using assertThat() allows you to write relatively short test cases that are clear what is being tested. Sometimes tests can become bogged down with too many assertEquals() and setters and getters. Using assertThat() allows you to simply compare two immutable objects. I plan on using this, or at least trying to implement it whenever writing tests in the future along with whatever makes writing tests more readable, understable and object oriented.

The post Single Statement Unit Tests: Making tests more object oriented appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.

The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.

In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:

It does this without having to couple the two systems together and eventually creating a huge mess of code.

The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.

I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.

Source: http://gameprogrammingpatterns.com/observer.html

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.

The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.

In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:

It does this without having to couple the two systems together and eventually creating a huge mess of code.

The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.

I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.

Source: http://gameprogrammingpatterns.com/observer.html

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The podcast episode referenced in this blog post can be found here.

This podcast episode from CodingBlocks.NET discusses the SOLID design principles. I chose this episode because SOLID is a fairly early topic in the syllabus and appears to cover several important principles. The podcasters start by introducing SOLID as guidelines for well-designed code, defining “well-designed” as easy to change, easy to read, and easy to maintain. They suggest that you should usually code first and then refactor according to these design principles as the need arises, since following the principles can take a lot of work. Additionally, you probably can’t adhere to every single principle out there, so practicality comes first. Summarizing every principle discussed got long, so I’ll summarize the ones that affected me the most.

The Single-Responsibility Principle is fairly simple – it holds that a class should do one thing and do it well, i.e. objects should only have one reason to change. With this principle in mind, I will check my classes to see if I can think of two or more reasons I might need to modify them, and if I can, I’ll see if I can divide the responsibilities into multiple classes.

The Liskov Substitution Principle states that objects in a program should be replaceable with instances of their subtype. They talk about how making a square a subtype of a rectangle, while intuitive, would actually violate the Liskov Substitution Principle because of a square’s additional restrictions. You ought to be able to set a rectangle’s length and width to two different values, but this is impossible with a square. They conclude that if your subclass requires something a base class doesn’t, chances are you’ve violated this principle. This makes a lot of sense once spelled out, and in the future, I will make sure instances of my subclasses can be used whenever objects of the parent class are expected.

The Interface Segregation Principle holds that more specific interfaces are usually better than large, general interfaces. For instance, using a brake information interface where brakes are concerned would be more efficient than using an entire car interface. The podcasters say that according to this principle, if your interface requires a lot of methods in order to be implemented that often aren’t needed, your code smells. With this in mind, I will examine my interfaces for methods I’m not using most of the time and see if I can make smaller, more specific interfaces.

Additionally, the podcasters note that following the Single-Responsibility Principle and the Interface Segregation Principle make unit testing easier, so I’ll make sure to keep this in mind if I expect to do unit testing or pass my code on to a unit tester.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

For this blog i chose the podcast Making a better tester with Keith Klain from the testinginthepub podcast website. This is a website where there discuss various topics in the software testing field. I picked this podcast because it sounded interesting and seemed like a good starting point into the world of software testing. It discusses some of the downfalls in the testing field and areas to improve as well as an overview of the state of the industry today.

The podcasts starts with the guest of the show Keith Klain discussing one issue that seems to come up a lot in the testing field. This was that the testing teams objectives would not align well with the business side. He talks a lot about how often times when he consults for a company he will see that the testing team is effective, but simply that their goals to not match that of their business counterparts. He then goes on to state how important it is for the testing team to have good communication skills with the business team and to have their goals aligned to make testing as effective as possible.

The next section of the podcast builds where the previous section left off. This section talks about how one of the big things holding the industry back is that a lot of company’s still use very old ways of handling their testing. Most of this includes outsourcing all of their testing to independent firms and testing centers. Keith Klain states that as much as fifty percent of major financial firms and banks still outsource all their testing to large testing centers in other countries. This not only makes it harder to communicate and have everyone on the same page but also since this company’s treat this as an external service and  just get the results back they do not truly understand the data that they get from testing. The podcast also discusses that financial aspect of it ,stating that it is hard to completely phase these practices out because they are so deeply ingrained and these testing centers make a lot of money and employee a large number of people. Keith Klain also states that the reason a lot of these company’s are having a hard time updating their systems to agile or waterfall development is because of how heavily they rely on these large testing centers.

The last section of the podcast talks about the exposure and communication in the testing community. The podcast refers to a recent expo that the hosts had attended which was not testing expo but a more general tech expo. The podcast talks about how a lot of people seem the have misconceptions about what testers are and really do.Keith Klain talks about how the testing community needs to be a little more social in order to draw new people into the community.To finish up the podcast Keith Klain talks about the usefulness of experience reports and documenting some of the experiences you have in your testing job , and how this can be really helpful for figuring out which systems work in different contexts.

In conclusion i found this article to be very interesting and gave a good insight on where the industry is today and where it is going. To me it seemed to be plagued by a lot of the same issues as in other parts of tech, such as technology moving very fast and a lot of non tech companies having trouble keeping up. It also seems like the industry is held up by a lot of old infrastructure that is hard to remove because the amount of money that is tied up, which i would also say is a larger problem in the tech industry. One thing that interests me is seeing how the industry will grow, will the testing teams start working much closer with the development teams and how will this effect performance. If so will we then see a shift into developers writing their own tests and having the whole process be that much more unified, and if so how will this effect performance and the industry.There is a part 2 of the podcast which i am looking forward to listening to.

-Thank you for reading

-Dhimitris

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

The blog that caught my interest this week is Good Programmers Get Off Their Butts by Jeff Atwood on Coding Horror. This post was centered around the author’s experience with UML diagrams and his overall view about its practicality in the field. Jeff finds that spending too much time on the design results in very little time for implementation. Then if there is very little planning, there is also a drag in the time for implementation. Which leads to his overall idea that, even if the design is vague, it is better to write some code than furthering the designing process in UML. His experience with proper designing procedures is a great read for many of us, that have recently learned about UML diagrams.

I chose this blog post because after reviewing countless articles, it seems to conclude that UML diagrams are useful in certain environments/situations and not a definite approach to design. These include being used as documentation or to explain specific code to people. Jeff explains a couple that are concerns of mine. One would be repeatedly updating the UML diagram to keep the design up to date or coming across a large problem in the design during the implementation process and having to scrap the design because of it. I would consider these to be time-consuming tasks and would stall development.

However, his message wasn’t all bleak as he does believe that it is useful from his comment that “Coding without planning is just as futile as coding with too much planning”. This comes back around to having a short design plan, perform the implementation, and then pan out the rest of the design as you go. I do see this as a future tool I could use, as time is a valuable asset. Relying on completing a full UML diagram will show what you need to do in theory, but when it comes down to implementation, not everything will go according to plan. This will result in turning back to the diagram, in attempt to solve the various issues that could arise later. However, if you have a rough idea of what the direction the design should go in, during implementation the process of editing the diagram won’t be so painful as there is little to change. Overall, grasping the concept of UML diagrams and understanding that it is a useful tool in general, but can work against you if you are overdependent on them is great to know for future projects.

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.