Deceiving a Deceiver

In my second blog post for the week (because I procrastinate any and every assignment), I am going to write about the topic of cyber-security today. I stumbled upon an article that was talking about this exact topic. The article is titled “Computer hackers could be thwarted by new ‘deception consistency method”. This title stood out to me because it may be a way to stop computer hackers almost entirely, so I decided to give it a read. The article turned out to be very short and to the point which is admirable, but it does make it a little harder to write about.

The abstract of this article leads of with “Can you deceive a deceiver?” and I absolutely love that phrase because it is like a PG-13 version of another phrase that I won’t mention here for the sake of professionalism. Anyways, the article mentions that the study by Assistant Professor of Computer Science Guanhua Yan and PhD student Zhan Shu at Birmingham University. They want to figure out a way to more effectively against malicious hackers. It was inspired by a data breach of Target in 2013, which cost them around 18.5 million dollars. They explain the concept of cyber deception is and I find it to be an interesting concept. To put it simply, it is putting the hackers in a fake environment to make them think they are in the system, but in reality, they are in some fake system. They mention that the problem with deception currently is that there are “bad lies” that make it blatantly obvious to hackers that they are in a fake environment.

The two decided to develop a deception consistency method, which they then tested on college students who recently completed a cybersecurity course, and the results were very positive. Most of the students were unable to recognize that they were in a fake environment, and that most of them just guessed. While this is a step in the right direction, the is not a “cure-all for things like what happened to Target and Equifax.”. They did say that they would continue to improve the effectiveness of the method to stop the more advanced attacks.

I thoroughly enjoyed this article because I do want to learn more about cyber security in the future. I find it interesting that hackers can be mislead like this, and still think they are in a system. I don’t really have too much prior knowledge on cyber security, but this has definitely raised my interest about the subject. I don’t disagree with any of the information. These two researchers did an excellent job on this study, and I encourage you to take a look at this article.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Top 5oftware Architecture

CS SERIES (13)When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.

If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.

The fives types discussed in the article are:

  • Layered (n-tier) architecture
  • Event-driven architecture
  • Microkernel architecture
  • Microservices architecture
  • Space-based architecture

The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.

Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.

Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.

Article: https://techbeacon.com/top-5-software-architecture-patterns-how-make-right-choice

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

You don’t no smoke

For this weeks blog post I will be looking at smoke testing.

A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something.  The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.

 

http://softwaretestingfundamentals.com/smoke-testing/

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

Copy Pasta: Te AntiPattern

For this week’s blog post I will be taking a look at another antipattern, another very common AntiPattern that creates maintenance nightmares. It usually takes the form of several similar segments of code that are interspersed throughout the software project. Programmers who are learning how to develop software who are following the examples of more experienced developers usually fall prey to this unwillingly. They do this by modifying code that has worked for them before in a similar situation and they think by potentially customizing it to support new data types they can get by but this causes code duplication which may cause positive outcomes but long-term problems. Symptoms of this antipattern include the same software bug that reoccurs throughout the software despite local fixes, lines of code increasing but overall productivity not being affected. Essentially this antipattern re-uses code that you may or may not need adding to your lines of code without any actual assistance being provided from the length. The most common cause of this is a lack of abstraction among developers who are often accompanied by a poor understanding of inheritance, composition, and other development strategies. And is most likely to occur when people are unfamiliar with new technology or tools as a result, they take a working example of something and modify it, trying to adapt it to their specific needs. Some solutions to this involve white box reuse through the developers extending systems primarily though inheritance. On the other hand of this black box reuse has other advantages such as the object is used as-is, through a specified interface where the client is not allowed to alter how the object interface is implemented. In a way this antipattern is very similar to spaghetti code but spaghetti code is not structure for easy component reuse because of this Cut and Paste Programming is the only means available for reusing preexisting lines of code.

https://sourcemaking.com/antipatterns/cut-and-paste-programming

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

Why favor composition over inheritance?

In the early stage of software engineering, there was no such thing is composition or inheritance, it only exist in the context of object-oriented programming. When object-oriented programming was introduced, every one pretty much ignored it until user interface heavily based on it. One of the most popular object-oriented design principles is to favor composition over inheritance.  I have been asking people about the advantages of using composition over inheritance and the answers always suggest that it makes your code so much simpler and increase its flexibility. That is somewhat an acceptable answer, but I thought, to convince you, I would need more than just simpler and maintainability, so I found a this article that provide five reasons and I will summarize it.

Firstly, there are a lot of object-oriented programming languages out there, but let’s take Java for consideration, since a lot of developers (including the new one) know how to use it. With composition, when class A uses the functions of class B, it doesn’t inherit class B, but instead, it sees class B as a variable or an object. This is why it is called “composition”. It is suggested to use composition and that does not mean inheritance is completely useless. While inheritance is referred as IS-A relationship, composition suggests more of a HAS-A relationship. With IS-A relationship, an instance of the sub class to a function as a parameter, which accept instance of the super class, offer somewhat of the flexibility.

On the other hand, the fact that people prefer composition, especially in Java, is that most of the time it does not support multiple inheritance. To be clearer, sometimes you need to use multiple function, but you can only extend one of the two classes that offer these two functions, that would cause a lot of pain to go through. For example, if you want to read and write a file, you probably want to reference the two objects and call the function from there, while it is almost impossible to extend the read and write class at the same time to call their functions. Composition also offers more test-ability than inheritance. While you only need to create a Mock object that represent the composed class for testing, in order to test the sub class, you would need the super class to be available at the same time. Flexibility is the most important one to talk about. Although both allow developers to reuse code, inheritance is more likely to break encapsulation. Because sub class heavily depends on the super class, even a slightest change can alter or break the functionality of the sub class.

There are a lot more reasons to consider composition over inheritance and you probably will discover it by yourself on your way making your own program. However, it is important to keep in mind these reasons so that you would not make a mistake when you start developing.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

The Joel Test: 12 Steps to Better Code

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about his sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. The test form is:

“The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?”

The Joel Test is so easy that to get a quick yes or no to each of the 12 questions. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer. However, please remember that you really shouldn’t use The Joel Test to make sure some formal or important things like your nuclear power plant software is safe. A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time. Certainly, these are not the only factors that determine success or failure. For example, you would not want a great software team working on a product that nobody wants. In contrast, it’s possible to imagine a team of “gunslingers” that doesn’t do any of this stuff that still manages to produce incredible software that changes the world. However, everything often has meaning itself, so, if a team gets these 12 things right, you’ll have a disciplined team that can consistently deliver.

The test addresses generally practical issues that a software team almost needs to work productively in building and testing software products that are feasible to get into market. The issues spread from tools and control to the working environment and habits for typical software team. The technology and environment have rapidly changed over time, but the issues mentioned in The Joe Test are still helpful.

Article: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

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

Gradle Build

Today I will be talking about Gradle! For this I will be referencing a blog on gradle called “Why Build Your Java Projects With Gradle Rather than Ant or Maven?”. This article discusses the pros and cons of building Java projects with Gradle instead of similar programs such as maven and ant. The blog starts by talking about how project builds used to be sort of a simple process that did not have to use fancy applications such as Gradle, ant, maven, or any other build program. Most requirements for builds just entailed packaging and compiling software. As mentioned in the article, as we now are seeing an increase in high tech programming and agile formatted programming, the requirements for building/compiling/packaging software is a much larger process. So why does this blog prefer gradle to another build program such as ant or maven?

One of the top reasons this article prefers gradle is because it is simple and user friendly. One big thing this article mentions is that when using build tools frustration is a common encounter while trying to use these tools. I personally have had this frustrating experience with maven about two or three semesters ago when we were using build tools in our software class. Building with maven was a giant headache and had to be done through linux, so if you happened to be one of the few who don’t primarily run linux (Yes, that is sarcasm) then you had to use a linux subenvironment in windows and run maven through there. However when you ran maven through that, it did not have access to your windows file explorer unless you mounted your C drive every time you wanted to explore files. This was a giant headache for me, and a problem I have not encountered with Gradle. Gradle can be used simply through a git bash terminal or any other terminal on your host operating system, for that matter. I personally enjoy the ease of gradle. Building with gradle is as simple as running “gradle build” on your master branch and it will build and let you know if there are any errors and what they are. You can also run html versions of your test reports to get a very detailed debugging without having to do everything in the terminal. I personally have learned a lot from using gradle and I look forward to using gradle more in the future to build my projects with ease.

Here’s the link: http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

A Review of Code Review

During one of our final Software Testing lectures last week, we were able to participate in a code review, examining and critiquing a given program. I really enjoyed taking part in this activity, because it helped me understand the program on a deeper level. After all, I wouldn’t really be able to spot any places to improve without first knowing what each line of the program was doing!

For this blog post I wanted to take a look at different code review strategies, as well as any advantages or disadvantages that may arise when using this method of software testing. I was reading these posts for more information: https://smartbear.com/learn/code-review/what-is-code-review/ and https://smartbear.com/blog/collaborate/pros-and-cons-of-code-review-methods-infographic/.

Code review is what it sounds like. Team members work together to review written code and notice areas of possible improvement. There are different ways to go about this process, each of which having their own unique advantages and consequences. The articles that I read listed 5 strategies, and they are described as follows:

  • The Email Thread – For this method, a file in need of reviewing is sent to every team member taking part in the code review. This can be helpful when it is difficult to find time in everyone’s schedules to meet. However, long email threads can get complicated for the developers to look through.
  • Pair Programming – For this method of programming, developers sit side-by-side and work on the same code together. This method is great to incorporate code review into the development process but may provide some bias due to emotional connections to the work put in.
  • Meeting-Based – For this method, smaller groups of reviewers meet with printouts of code or code on a projector. Then, they examine, line-by-line, any issues or problems with the program. While this is a very in-depth approach, this also takes a lot of time. Additionally, some development teams are stationed across the world from each other.
  • Over-the-Shoulder – This informal method simply entails another developer standing over the shoulder to the author of the program, as the author walks through each change to the code. This is great for in-person collaboration, but there aren’t really any standardized metrics involved in this method. There is also no traceability to the conversation later.
  • Tool-Assisted – This method involves an external tool (whether browser or IDE based) used by the team to successfully review code while also solving some of the issues above, like keeping track of online comments, noting any change in code, and enforcing any standardized metrics. However, some tools may be costly, or may not fit as easily into the workflow of the development team.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

A* Search Algorithm

Summary

In the article Introduction to A*, Amit goes over two graph traversal algorithms: Dijkstra’s Algorithm and Greedy Best-First-Search Algorithm, providing a great visualization of how these algorithms work as well as cases in which they excel and in which they struggle. A summary of his description of these algorithms are as follows:

  • Dijkstra’s Algorithm – guaranteed to find the shortest path from the starting point to the goal, longer run-time because it visits vertices continuously expanding outward from the starting point until it reaches the goal.
  • Greedy Best-First-Search Algorithm – works with an estimate (heuristic) of how far from the goal any vertex is, selecting the vertex closest to the goal. Not guaranteed to find the shortest path, but runs much quicker than Dijkstra’s Algorithm.

He then explains what the A* Algorithm is, taking advantage of the best of both of these algorithms. This is done by combining the pieces of information that Dijkstra’s Algorithm uses (favoring vertices that are close to the starting point) and information that Greedy Best-First-Search uses (favoring vertices that are close to the goal).

Reaction to Content

This article is the first part of a larger series by Amit about pathfinding, however I believe that reading this article alone is good enough for a quick overview about what the A* algorithm is as well as providing excellent visualizations for the three mentioned algorithms. These visualizations are definitely helpful for understanding how these algorithms work as well as what their potential advantages and downfalls are.

I chose this topic in particular because it’s an interesting part of a subject area that I have interest in (game programming) and also is an important topic in CS in general (graphs and graph traversal algorithms). It’s a useful refresher for some of the topics that I learned in my algorithms course. Also, seeing how a potential algorithm in a game could decide how to best traverse towards a goal taking into account any obstacles in the way is interesting think about.

I think the rest of the series would likely be a good read to get a deeper insight into the A* algorithm.

 

Source: http://theory.stanford.edu/~amitp/GameProgramming/AStarComparison.html

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

Design Patterns: Iterator

I’ve been discussing AntiPatterns quite a bit lately, so I elected to switch it up and talk a bit about Anti-AntiPatterns, aka Design Patterns. As a quick recap: If AntiPatterns are common bad practice traps that developers/teams can fall into, then Design Patterns are good practices which help guide them to either avoid AntiPatterns, or to lean towards a more efficient solution.

One design pattern we’ve used many times in my Data Structures class is the iterator, and personally feel as though it was never fully explained to the class as to what an iterator even really is, let alone why we were writing one. This post from Sourcemaking.com helped a lot in terms of learning what the use of them is.

As covered in the article, there has been a push in recent programming towards something called “Generic Programming”, and the iterator is a core idea within it. An iterator is an attempt to abstract out the traversal of data items in a data structure into a separate thing. The usefulness of this is outlined by an example given in the article:

“As an example, if you wanted to support four data structures (array, binary tree, linked list, and hash table) and three algorithms (sort, find, and merge), a traditional approach would require four times three permutations to develop and maintain. Whereas, a generic programming approach would only require four plus three configuration items.”

– Sourcemaking.com

So essentially, your iterator is an object in itself that handles the job of traversing through the objects in a list. A real-world example of this may be the AM/FM radio controls in your car. The radio stations are the objects in a list, with their station name and frequency (or channel, I suppose) as their data. The iterator would be your “scan” button, which skips over the stations with fuzzy signals in order to reach the next one whose frequency is available to you, while all you did was press the one button. Each station is a data point in your list (your data structure) with a station name and a frequency. You, the driver, don’t need to know anything about the details of the stations you’re scanning over, because the iterator (the scan button) handles that for you when finding the next available station.

The article from Sourcemaking has several really great UML diagrams and other examples to pick apart which help elaborate on the subject even further. I highly suggest visiting their website to read more about it — they have detailed explanations on almost every type of AntiPattern and Design Pattern I’ve looked into so far.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.