Demystifying REST for myself

To preface this post I would like to say that this is the last blog post I will be writing for a little bit. I hope to return to this blog with a new outlook on the process of writing blogs and hopefully with more freedom in what I can post, the frequency and quality of posts will increase. In this post I have decided to do some research on REST in order to fully understand it so that going forth in my career I have a firm grasp on REST. Before reading this extensive article on bbvaopen4u.com about REST pretty much all I knew is that REST deals with http requests and http stuff.

First thing I learned when reading the post was that REST is more of a blanket term for any interface between systems that allows for the transfer and editing of data over multiple formats. This idea is so important because it vastly increases the scalability and functionality of products being created. It has become the standard in creating web applications and is used by most of the top sites such as YouTube, Twitter, and Facebook. The writer then goes into detail about the features that make REST special and why we all love it. A great feature of rest is the fact that everything is manipulated through the URL, keeping applications very uniform in how they access objects. They also talk about how it is a layered system which helps organize large applications. They then go into the benefits of using REST. Using REST separates the clients and the server which allows for scalability and ease of migration to other platforms. REST is also always independent of type of language being used which also increases options for migration and ease of development.

I enjoyed this read and while I feel as though it could have delved a little deeper into what REST is it was a quick easy read that helped me understand REST. Using REST in our assignments and project I had been emulating what I had seen without truly understanding what REST was. If you are like me and was having trouble grasping the concept of REST I would recommend reading this post.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Music Composition and Programming are More Similar Than We Think

I consider myself a predominantly creative person as opposed to someone who thinks in a very mathematical and literal way. Most people would probably argue that I should be going to school for something along the lines of art or music but I’d argue that programming requires the same amount of creative prowess as both of those majors.

A user on DevDungeon wrote a post about this topic called Similarities Between Music and Programming. This article goes into detail about how the learning process in both music and programming is very similar. They talk about how most people feel like music and programming similarly are things that you are born with a natural gift for and can be difficult to learn. With music there is very much a mathematical science behind the music which can almost always be explained using the concepts learned through music theory. In music there are very many ways to get a similar result and all musicians will think of songs and have vastly different musical ideas. The same could be said for programmers. Many programmers can come up with vastly different solutions to the same problem based on how their brain solves the problem at hand. They also talk about how there is a hypothetical “stage fright” that occurs when just starting out in both fields. New musicians and programmers usually don’t want to share their work because it is very much an extension of yourself and if it is not up to your own standards it is hard to want to share what you’ve made. You can think of collaborating on a program with others as a band of sorts. If all members of the band aren’t on the same page then the outcome will most likely have many issues. They then go on to talk about how music and programming are very hands on and from day one should be taught in a hands on way.

I agree with almost everything said in this post. It was a very enlightening read because I have always taking a liking to the creative arts and seeing the similarities now it makes sense as to why I enjoy programming so much as well. I’d argue that programmers should learn music composition as it would help with the fundamentals of problem solving that are essential for programmers.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Accessibility in VR: The hurdles we have to overcome

It’s no surprise to anyone how huge VR has gotten as an industry and a viral topic in everyday life. While Virtual Reality has been around for many years on recently have companies like Oculus and HTC brought it to the forefront of tech news. With the newest advancement in the industry it is very reasonable for anyone to be able to afford a headset and experience new worlds from the comfort of their own homes. The applications for VR don’t stop at entertainment either, VR can be used for medical procedures, physical, and mental therapy and much more. While this has been the push that VR needed for many years there is a large group of people who sometimes miss out on all of the VR experiences being crafted, those with disabilities. In Thoughts on Accessibility Issues With VR on ablegamers.org, AJ Ryan goes over some ways developers can start the conversation about what measures they should go to to make games accessible. The most alienating feeling is when you are barred from experiences because of a disability and while VR can be a very physical activity there are many ways to increase accessibility.

This Blog post is set up in a list format where each element is another things that developers should be trying to do better in order to accommodate those with disabilities. The first point is that motion controls are cool yet there should always be an option to play with a controller. Another point made is that games shouldn’t require you to stand up in order to play them. Something that is extremely easy to implement yet many developers don’t is full button remapping. This would allow people who use adaptive controllers while playing VR to comfortably experience the games we are developing. These ideas pretty much sum up the overarching theme of the list and that is “when developing games add as many ways to control the game as possible while not barring of ways of playing such as standing/sitting”. If developers spent more time thinking about those who are playing the games and not the game itself it would create a much more inclusive library of games. This article is an essential read for all developers because if developing for accessibility hasn’t crossed your mind you are missing out on a huge subset of people who most likely would love to play the games you are making yet can’t.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Deep Learning AI Programmers Have Come to Take Our Jobs!

From the minds at Rice University comes a very interesting application for deep-learning AI. Bayou is an AI that, with a very small list of keywords, can produce usable blocks of code. It does this by scanning github and learning from all of the open source code on there. What does this mean for all of us computer scientists? This means that an era where AI may be able to aid us in completion of programs is on the way. For a long time this concept has been played with but never in such an efficient manner as Bayou. With other AI programmers sometimes the parameters you would have to enter to get a usable end product would surpass the program itself in length and complexity. While my title is very clickbaity I can guarantee that our jobs are safe for a very long time. This technology is only in infancy and for large programs that interact with many APIs and databases and such the need for a human to parse what needs to be written is still very essential. Bayou is more of a proof of concept that if built out even further can be very useful for speeding up the programming process.

In the post Turning deep-learning AI loose on software development, Jade Boyd makes many fair points about the ethics of Bayou. As programmers being so connected to the internet constantly has made it almost impossible to write programs from scratch. At any slight hitch we are able to search the internet and find someone else’s solution to a problem that we are facing. This point really proves that Bayou shouldn’t be seen as “cheating” rather that it is yet another tool that can give us examples of ways to solve specific problems that we maybe would have otherwise not given thought to.

I believe that applications such as Bayou are a step in the right direction. If we can get AI to write all of the simple parts of programs it would guarantee less simple errors and can also unify the format of the program. Programs can get extremely complex and Bayou wouldn’t replace us rather aid in saving us time and therefore money in the programming process.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Santa Uses Java?

https://dzone.com/articles/whos-been-naughty-whos-been-nice-santa-gives-you-j

 

Since Christmas was just past I was wondering how Santa could handle so much data so quickly. This blog post seems to suggest that through the use of Java and Speedment is how he accesses this database of children and presents. Speedment is a software tool for enterprises that run Java applications and relational databases. It works by creating a virtual data object, retrieving only the data the application needs when it needs it. What it does is reduces the amount of develop time, increases data access, and builds a better infrastructure. How would Santa use Speedment though? Well he would implement Speedment into java code and call on his database of children in order to gather the information he needed.

An Example:

. var niceChildren = children.stream()

. filter(Child.NICE.isTrue())

. sorted(Child.COUNTRY.comparator())

. collect(Collectors.toList());

 

This stream will yield a long list containing only the kids that have been nice. To enable Santa to optimize his delivery route, the list is sorted by country of residence. What is exciting about a Java application like this is you can create code that easily checks on a database. I had created a SQLite program earlier in the year and the way the code was built felt clunky. In the case of Speedment you can do this process smoother. In terms of software development when looking into database access Speedment seems like a valuable tool to implement. Their website has a code generator for different databases, and languages to make sure you can quickly implement it in any program. I believe this is truly how Santa is able to access his list so quickly to make sure he can check it twice.

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

AI at Google: our principles

This is the blog call “AI at Google: our principles” by Sundar Pichai, he is Chief Executive Officer of Google. In this blog he talked about the principles of AI at Google. The main purpose of AI is to help us, its potential to improve our lives. Beyond that, AI to help people tackle urgent problems. These benefits are why Google invests heavily in AI research and development and makes AI technologies widely available to others via our tools and open-source code. This is powerful tool that mean we must be responsibility to get this right. These are seven principles to guide Google’s work going forward. They want to set to concrete standards that will actively govern the research, product development and business decisions.

Objectives for AI applications: Advances in AI will have trans formative impacts in a wide range of fields, including healthcare, security, energy, transportation, manufacturing, and entertainment. They also take into account a broad range of social and economic factors and will proceed where they believe that the overall likely benefits substantially exceed the foreseeable risks and downsides. They recognize that distinguishing fair from unfair biases is not always simple, differs across cultures and societies. They will seek to avoid creating or reinforcing unfair bias. They will continue to develop and apply strong safety and security practices to avoid unintended results that create risks of harm, and will incorporate our privacy principles in the development and use of AI technologies. AI tools have the potential to unlock new realms of scientific research and knowledge in critical domains like biology, chemistry, medicine, and environmental sciences. They aspire to high standards of scientific excellence as we work to progress AI development.

And the applications that they will not design AI for, such as weapons or other technologies whose principal purpose or implementation is to cause or directly facilitate injury to people. Technologies that cause or are likely to cause overall harm or gather or use information for surveillance violating internationally accepted norms.

Look at AI for long term, this is the technology that will stay with us in the future. There are many voices about this subject. Although I don’t have all my trust and believe in company and operation. This is the future we cannot avoid, that’s mean we have to be careful and monitor it to goes right direction. We need to set regulations and principles, I am agreed with these principles by Google. But we need to make sure that they keep their words.

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

Documentation is important

Self-documenting code is one of the biggest myth in the software development industry. It is common for someone to think that their code is pretty much self-explanatory, either because it is so simple or they are the author so they should have known it better than anybody else. However, not all of us can realize the fact that while the code is pretty transparent for ourselves, other would not have the aspect as we do despite how much experienced they are in the field. In this blog post, I would like to reason that code comments have a lot of value and documentation has more value than just explaining how functions / software works.

From that all of us can understand, code documentation is basically a collection of descriptions to explain what the codebase does and how it can be used. It can be a simple explanatory comment that locates above a function or a block of code, or a full fledged developer handbook, usually complete with prescriptive style dos and don’ts overviews of each part of the application, and approaches to the most common types of coding task. Like a lot of people would think, the general reasons why we think our code is “self-documenting” mainly because our applications can be boiled down into functions or objects that have one specific task and that task should be represented by the name of the functions or the objects and for me, this is not true at all, especially with large project with lengthy codes and potentially has functions that is named a little bit similar and have some common traits with each other. What we mostly don’t really think about is that code without comments is basically force the reader to go through the how it is implemented to figure out the why. With that being said, we can see that documentation are important to transfer the knowledge of what that function really do so that people can reuse it by just not knowing how it was implemented and that is fine. Not just giving user the instruction, code comments are also used to provide example usage of the code, provide the trade offs or pros and cons of the current implementation, marking the possible improvements in the code, possibly how to use it effectively with others APIs, and it serves as the most effective communication between authors and readers.

Another flaw of self-documenting code mindset that we usually think is that because we are standing in the developer-only point of view. To be clearer, what I meant is that we only seeing the value of documentation as allowing people to understand how the code works and documentation should be for every possible user. Developers only think about developers when it comes to software. It is true that a vast majority of the software users are end users and by having a good documentation can make the software more approachable by users that are not developers.

Article reference can be found here.

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

Early Testing

https://www.softwaretestinghelp.com/early-testing/

 

This week I read the post from the site linked above. It talks about effective quality assurance strategy in the early stages of a project. Uncaught bugs or fundamental flaws in the foundations of the software life cycle can result in setbacks for the later stages. Ultimately, it is more efficient to test early and test often than to spend resources going back to fix an early issue. If this is the case, sometimes the best solution is to rewrite many built features of a software project just to change the foundation, which is the worst case scenario in a time crunch environment.

There is a balance to be achieved between spending enough time testing early as to not create fundamental mistakes, and spending too much time testing without devoting enough resources to producing a working prototype. Software projects are typically planned on a time based release quarterly, half-yearly, or yearly, depending on the size of the project and the goals in mind. Because time is of the essence, defects need to be organized based on severity, time allocation, and expected collateral impact for the rest of the code.

This cycle can be broken down into steps; the developer creates, the tester tests the creation and ranks severity, the developer responds by fixing the most important issues, and the tester evaluates the fixes. Ultimately, this cycle never ends as long as they are employed. Constantly, there are new features and new bugs, and it is impossible to discover every bug from every new feature, the product is never defect free. In this way, testing is especially important in the early stages of development since it plays better into the long term which we expect to never end.

Now that I’ve summarized why and how early testing occurs, the final segment of the site reviews the primary targets for early testing. To begin, stakeholders determine which features will be the most effective by generating the most revenue, complying with standards, catching up to a competitor, or succeeding a competitor. These selected new features are the focus of early testing since they usually involve many lines of code with a high possibility of intersection. QA and development leaders both need to work together when working on these high priority features in the early stages of development. This collaboration must be stressed as especially important to the work efficiency of the entire project.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Software Testing Principles

I am writing in response to the blog post at https://www.guru99.com/software-testing-seven-principles.html titled “7 Software Testing Principles: Learn with Examples”.

This blog post highlights some useful general guidelines for software testing. In order to write effective test cases, it is important to follow some logical approach toward determining what to test for and how to test it, and this is a guide that describes such a set of principles to follow that are well suited to capture the logic involved in software testing.

The first principle is that exhaustive testing is not possible. I am not sure I believe this. In general it is useful to assume there exists no perfect test, but for simple enough applications where the number of possible interactions are enumerable, I would think that it would be possible to achieve exhaustive testing, much like an exhaustive proof, where every possible path is covered and verified. Maybe I am missing the implausible event that the test is correct but the computer running the tests is corrupted in such a way that certain tests are not run. This is relevant to a point made in this area, which is risk assessment.

The second and third principles make similar points. Always running the same tests will eventually not cover certain issues. If all of the same methods for testing are always applied exactly the same, then eventually there will be some scenario which the particular method is not suited for, and it will miss something. This leads into the later principles: the absence of a failure is not proof of success, and context is important. Developing tests suited for the particular application is necessary to ensure the correlation between tests passing and the program functioning correctly, and just because every test passed does not mean the program is going to work perfectly.

This set of software testing principles can be summarized in a few basic points. Develop test cases that are well suited specifically for the application that is being tested, consider the risk of certain operations causing a failure, and do not assume that everything works perfectly just because every test case passed.

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

Mocking & Mockito

For the final blog entry for this class, I decided to cover a topic that I’ve had personal experience with but wanted to review for further review and understanding, mocking and specifically, mockito. I found an article on toptal.com by Ivan Pavlov about mockito that is a guide for everyday use of the tool, exactly what I was looking for! The article has sections that includes some in depth analysis that could likely be used as a more in depth documentation for several aspects of mockito. The article also includes some insight into what mocks and spies are in the context of testing, unit testing specifically as well as some examples of the mockito tool in action.

For unit tests, we are testing the smallest unit of code possible for validity. The article states that the dependencies are not actually needed because we can create empty implementations of an interface for specific scenarios known as stubs. A stub is another kind of test double, along with mocks and spies, which are the two test doubles relevant to mockito. According to the article “mocking for unit testing is when you create an object that implements the behavior of areal subsystem in controlled ways.” They basically serve as a replacement for a dependency in a unit test. Mockito is used to create mocks, where you can tell mockito what you want to do when a method is called on a mocked object.

A spy for unit testing is another test double used by mockito. A spy, unlike a mock, requires a non-mocked instance to “spy on”. The spy “delegates all method calls to the real object and records what method was called and with what parameters”. It works as you would expect a spy to, it spies on the instance.  In general, mocks are more useful than the spy as they require no real implementation of the dependency as the spy does. The spy is also an indicator that a class is doing too much, “thus violating the single responsibility principle” of clean code.

Mocking with mockito can be used in a situation where you want to test that an object is being assigned a specific value when a method is called on it and certain parameters are met. A mock does not require the implementation of the methods to be written yet as you can assign values when a method is called by the power of mockito. This is why mockito is such a popular testing tool and mocking is such a popular testing strategy, and why I’ll continue to utilize it whenever relevant.

Link to original article: https://www.toptal.com/java/a-guide-to-everyday-mockito

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.