Automatic Code Reuse

            This week I found another MIT article that piqued my interest which explains the modifications a system makes to “transplant” code from one program to another. The article explains that the Computer Science and Artificial Intelligence Laboratory at MIT develop a system where programmers can copy code from one program and using an insertion point, move it over to another program. The interesting part is that the system will make any modifications necessary to integrate the code into the new program like change variable names. They tested CodeCarbonCopy on many open-source image-processing programs with seven of eight transplants working successfully. For this system to work, both programs need the same input file and then the system compares how the programs process the file. Once it finds similarities between variables, it first displays those similarities to the user and then displays the variables that were different. The user then can decide to flag certain variables that are not needed for the transfer and the system will excise any operations that use those variables. The system will also look at precise values in memory that both programs store and uses those values to generate a set of operations that translate the values into a data map. The article also explains that this program is still basic in usability but it does work well with file formats that follow a rigid organization that is easy to read. The researchers are trying to generalize the approach of this software to further allow multiple file formats so code from different file formats can be transferred to one another.

          I chose this article because it really shows the development within AI and computer science today. This option of automatic code reuse will make programs easier to understand and create. The ability to copy code from one program to another is incredible but the best part is that the system can now understand what each variable value means and display the similarities between two programs. This would also allow the system to make a program in multiple languages by reconfiguring the values into the desired language. I think that this jump in technology really can make life easier for programmers but it also brings up the point of stealing code from others. If this program ends up doing what it was originally designed to do then people can take code off the internet and use this program to change it into a new program that they could call their own. That aside, it would be interesting to see how the computer would take on the challenge of creating the software architecture between different languages as the syntax and naming system are different based on the language used. The article showed me that AI technology is really starting to kick off now and about the relationship two programs can have based on the values they store within memory.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

We’re approaching week four in the semester and getting into the processes of testing code. Prior to taking this course, I’ve tested code typically with random input, ad-hoc style. But I am now learning new testing methods as well, which are more systematic and cover larger ranges of potential case failures. That being said, I would like to talk about unit testing in general, and why it is so important.

We do unit testing because we want to ensure that our code works. Sometimes it can be frustrating when we can’t get our code to do what we want it to do. We need to do thorough testing to weed out these problems. For instance, perhaps our code works sometimes, but not always, and we have no idea why.

It can be disheartening when spending hours trying to fix something in your code which seems to magically work for some inputs, but then crashes on others. It seems that simply entering a finite and/or random number of test cases, or simply not running tests frequent enough, we may not ever find out why our code only works sometimes, but not always.

Now that I’ve discussed a few reasons why I feel that unit testing is important, I would like to share a blog that I found on the topic as well.

The Green Machine (TGM): 5 Reasons Why Unit Testing is fun–and Important

As the title suggests, TGM provides additional clarification as to why testing code is an essential part of programming. He also emphasizes that unit testing is fun as well, for a variety of reasons.

For instance, TGM states that unit testing can be rewarding in the sense that “we can execute our code right away and know that it works.” Since one of the most enjoyable aspects of programming is seeing the result of our work, having the capability to test our code at any given point is beneficial. And if for some reason it doesn’t work, we can likely figure out where it went wrong faster if we’re testing in a frequent and consistent manner.

Unit testing can also lead to an overall better understanding of how our code works. As TGM indicates, unit testing helps us figure out how our code will behave under a large range of circumstances. By running frequent tests, we can gather a better understanding of exactly what our code is doing, regardless if the tests pass or fail.

TGM’s blog was an interesting read for me, especially in regard to his insights of how unit testing can be rewarding. I’ve always known that testing code was important for functionality reasons, and now I feel that frequent testing can help make me a better programmer in general. This is due to what TGM indicated about how we can learn more about our code through its behavior during pass/fail tests.

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

https://sandit27.wordpress.com/2008/03/24/what-are-anti-patterns/
This week’s post focuses on Anti-patterns. Patterns defines a common solution to a problem that occurs through different settings. It is a general solution that can be specialized for a given context. In software design, it helps to capture the best practices that can be reused and applied in the development of different types of software.
In CS, anti-patterns are repetitive practices that appears beneficial, but will most likely result in bad consequences that will outweigh the advantages. It is called anti-pattern because the use will produce negative implementations. Two key elements are used to distinguish an anti-pattern:
A repetitive pattern that appears beneficial but ultimately produces negative results that outweighs its advantages.
A refactored solution that has been documented, proven in practice, and repeatable.
Anti-patterns should be diagnosed early. The following are some of the classic Anti-Patterns:
Organizational anti-patterns:
The “I told you so” the ignored warning from an expert is justified.
Mushroom management is when employees are kept uninformed or misinformed.
Project management anti-patterns:
The smoke and mirrors shows how unimplemented functions will appear.
Finally, software bloat is for allowing successive versions of a system to demand more resources.
I chose this topic because I thought a blog post on anti-pattern of function as child component was interesting. The post can be found following this link, http://americanexpress.io/faccs-are-an-antipattern/. The article argued that Function as child component, FACC is an anti-pattern. FACC is a pattern that allows users to pass a render function to a component as child prop. It allows users to pass as children to a component/function.
FACC was argued to be an anti-pattern. The example was a summation function of 2 numbers and returns the result. Clean code practices recommends descriptive names for properties, variables, and functions. So, in this case the best practice is to name it as add or sum, but not children. The function passes render callback functions through a prop named children. The main issue here is that the FACC function uses the prop children to pass in render callbacks. This pattern goes against what is considered best practice, so it is an anti-pattern.
I chose this article because it introduces an anti-pattern in a reactjs function and reactjs articles are always an interesting read. It argues that naming props as children in the FACC function was not the best practice. It goes against what is considered to be the “Clean Code” standards. I thought that this article was worth a blog post because it was an interesting read.

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

Equivalence Class Testing
This week we turn to equivalence class testing. Equivalence class testing is a black box software testing technique that divides function variable ranges into classes/subsets that are disjoint. It is beneficial for two cases:
When exhaustive testing is required.
When there is a strong need to avoid redundancy.
Equivalence class testing selects test cases one element from each equivalence class. This helps to reduce redundancy.
There are 4 types of equivalence class testing:
Weak normal equivalence class testing: The term weak refers to single fault assumption. This is accomplished by using one variable from each equivalence class in the test case.
Strong normal equivalence class testing: The term strong refers to multiple fault assumption. This method uses test cases from each element of the cartesian product of the equivalence classes. The cartesian product guarantees the notion of completeness in that all of the equivalent classes are covered and there is one of each possible combination of inputs.
Weak robust equivalence class testing: This term combines weak with robust, meaning single fault assumption with invalid values.
Strong robust equivalence class testing: This term combines strong with robust, meaning multiple fault assumption with invalid values. The test cases are the cartesian product of all the equivalence classes.
This article talks about redundancy in equivalence class testing. It introduces the following problem: Suppose a there is a UI for creating user accounts. The Username is between 1 and 25 characters, spaces are not allowed. The gender can be Male or Female. It would be impossible to test all combinations of inputs instead we turn to equivalence class testing.

Breaking the conditions down EC reduces the test cases into 5 equivalence classes.

Field
Description
3. User Name
Empty
4. User Name
Length > 25 (no spaces)
5. User Name
Length > 25 (containing a space)
6. User Name
Length >1 and = with >.

I chose this post for its simplicity and example of the UI for creating user accounts. The example helps to connect the concept of EC to test cases that can be validated. So, it helps to break down the problem into different ECs and its product into different test cases. It also demonstrates the advantages of EC in helping to reduce redundancy and test time. I chose this post because it gives a good example of EC testing.

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

So, I was reading a blog called Awesome Testing the other day, (really clever name, I know, it’s what caught my attention) and I saw a whole section of pages titled “TestOps”. Intrigued, I ventured further by reading the posts, which led me to the initial blog post that coined the term, by Seth Elliot. The short and sweet of it is that originally testing can be represented by this diagram:

The tests are created, they are run on the system, the results are obtained, the results are checked against the ‘oracle’, and an assessment is completed. However, the interesting thing is the current trend in software products. The most popular products now a days are not simple programs, but are actually services. Facebook, Amazon, Twitter, etc. With this new change, testing becomes a bit more different. Big Data concepts are used, new features are tested with exposure control and monitors. This becomes the new model:

The testing system becomes a whole architecture testers are serviced with maintaining and using. This whole post was incredibly interesting to me. As someone new to Software Testing, my experience up until now has been discrete test cases and suites. With TestOps however, testing becomes a whole new beast. Using Big Data techniques to test how well a service is doing, not just if it runs correctly was a definite surprise. As someone who is currently dipping their toes into Big Data as I take a Software Quality Assurance course, I didn’t expect the areas to meet like this.

The final paragraphs of the post describing how this development is also blurring the lines between tester and developer is exciting. There was the worry in the back of my head, that software testing and development were two divided areas. That one had to choose one or the other. But knowing how much they will intermingle in the present and future helps alleviate this to a great extent.

It also makes a large amount of sense. As the software being tested becomes much more dynamic, testing must as well. Not just testing if software is working, but working well is quite the interesting distinction that requires more complicated solutions. These tests will require a process similar to software development to create. Choosing the right kind of Architecture, using tools similar to software process management tools to cut down on the time QA requires to make new tests or change existing ones, and the continuous updates and integration.

The incredibly interesting blog post can be found here: https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-two

The original blog post that sent me to it: http://www.awesome-testing.com/2016/07/testops-missing-piece-of-puzzle.html

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Gregory Falco: Protecting Urban Infrastructure Against Cyberterrorism

         This article from MIT shows the story of Gregory Falco who is a PhD student that works with urban planning and computer science. The article talks about the IoT (Internet of Things) where everyday objects are embedded with the basic functions of communications to other devices through the internet. Falco works with getting this project off the ground and around the world to other countries so that everyone can have the positive effects of this technology. He says it will help solve their problems with sustainability issues and social problems. However, there were concerns with security of this new system as it is possible for new technology to be susceptible to hacking. Falco continues to explain in the article that IoT devices usually have little to no real security software as they only have small amounts of memory and low-power processors. This can become a “gate” for hackers to exploit bigger systems as they may all be linked on one network. Falco is working on the industrial controls and embedded systems within the IoT such as automatic switches. He goes into detail of all the dangers this hack could create for a variety of people. IoT devices can control anything from subway switches to insulin pumps which puts a large number of people at risk.

            I chose this specific article because it was really interesting that as technology gets to be smaller, we are running into roadblocks like this. This is a very important roadblock because it shows that we need to develop technology to meet these needs faster or many people could lose lives. I found it was interesting how hackers can exploit the smallest flaw in a system to extract dangerous information. I think that the resource was quite interesting and made me more aware to the dangers of having little no security on devices. I feel that technology needs to have some sort of real security behind it as we are constantly relying on for our life functions such as water grids and electric grids. I learned quite a bit on this material from how much technology is taking over our lives to how insecure and manipulated it can get. This helped show me the side of hacking where even small flaws within a system can be used to hack into a much bigger system. It can be important to learn this sort of material because it really shows you to be careful when designing programs and working with networks to make sure that you know what data to keep private vs public. If you give the user access to public data, they can use it to break the system and cause a lot of damage to the program.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.