What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

1. Consistency
2. Productivity
3. Maintainability
4. Modularity
5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

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

The blog post this week discusses my favorite principle in software development, the open and closed principle. The open and closed principle encourages independencies in software development. It states the following as outlined in the article: Class behavior should be open for extension but closed for modifications. This can be separated into two parts. As explained in the article, the first part is about the behavior of a class. Extensions of behavior allows for changes in behavior to be added, deleted or modified without affecting the other behaviors. This is what is meant to be independent. Thus, the 1st part of the statement signifies changes in behavior which signifies changes in source code. The second part of the statement states that class behavior should be closed for modifications. Is this a contradiction? Modifications means changes to source code, which the second statement encourages developers not to change. This means that class behavior should be independent and not need to be modified when other parts of its behavior are changed. So, when extending a class behaviors, the source codes for other behaviors should not be changed. The other definition introduced in the article is: Software entities(classes, modules, functions, etc.) should be open for extension, but closed for modifications. The explanation for the principle is as I have described previous just above that it encourages independence in software methods.

The article, however, expresses confusion for both definitions because the two sides of the principle is a contradiction, however I think it did a pretty good job in its explanations and examples. As explained in the article, the main idea behind the OCP is that the behavior of the system can change by replacing “entities that constitute it with alternative implementations,” but that the other behaviors can be independent and therefore need not be changed. The example given is that for calculating taxes. As stated, take for example the TaxCalculator interface for calculating taxes. In this system, if we replace the UsTaxCalculator with the UkTaxCalculator, this does not require modifications of existing logic, but that it provides for new implementations to an existing interface. Overall, the main idea is that you can add behaviors to systems be adding new code, but the existing ones do not need to be changed. This creates separability so that system behavior can be easily modified and changed.

Finally, I will close this post with a discussion about 3 rules of thumb suggested in the article that can help a developer to determine when to use the open closed principle. The first is to add extension points to classes that implement requirements that are intrinsically unstable due to instability of the system. This helps to clean the code which makes it easier for modifications of system behavior. The second is to not add more preliminary extension points. Finally, the third is to refactor parts of the code and to introduce additional extension points when the parts are unstable.

Overall I chose this article in order to compare my understanding of the OCP with another software developer. In my opinion, the OCP is based on indenpendence of methods, functions and classes. Although the article indirectly refers to this point, still I think it misses to introduce this point directly.

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

Soft Qual Ass & Test

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

For this weeks blog i will be doing a podcast from The testing show on machine learning, which can be found here.  The podcast starts with a discussion of a recent tech story by facebook on their AI chat boxes developing their own language and having to be shut down. To understand this story the podcast goes into some detail about what machine learning is. The guest on the show Peter Varhol defined it as follows: machine learning works on the feedback principal, which is how we can produce better results by looking and comparing the results produced by the machine learning algorithm to the actual results and then feeding that back in to adjust the algorithm and produce incrementally
better results. After this they discuss what they think might of happened with the facebook chat bots, they went through multiple views such as being intrigued , to skeptical , to really questioning if the bots actually developed a language at all or just gibberish.

Although the podcast does not come to some big conclusion , the final view on the topic was the most thought provoking. The last view was disputing if the chat boxes really created their own language , and if so how? In the podcast the hosts were talking about how language is semantic and that it would be impossible right now for a computer to be able to understand semantics ,let alone creating a new language. The host theorizes that the chat bot created a language of gibberish to make up for the fact that it could not fully understand what was being asked of it semantically. I thought this was a really interesting point, i had never considered the semantics of language and shows how far computer scientists have to go for real artificial intelligence.

In the last part of the podcast we dive deeper into how machine learning works and some of the pros and cons. One pro is that we can set up a series of algorithms and iterative processes to achieve something we simply couldn’t do on our own. The example given here is the Facebook chat bot again, they talk about how even if Facebook released the source code for the bots, the algorithms would likely be to complicated to understand for almost everyone, and so it would be hard to verify the results for the chat bots. As maybe you can see from the example , our pro also becomes our con. This is because once we get what seems like a reasonable result from our machine learning algorithm, it becomes very hard to trace our answer back through the code.

The last part of machine learning covered in this podcast is the difference between supervised and unsupervised learning. Supervised learning is pretty straight forward we know the result from out training data and try to get a result close to our known result. Unsupervised learning is more difficult to explain, we don’t know the expected result and are just trying to optimize something. The example given for this is airline ticket sales online, the algorithm is built to maximize profits for the airline company. Roughly 3 times a day online ticket sale prices change, there is no exact formula to how the airliners change their prices, the algorithm is simply trying to optimize the amount of money made.

This was a very interesting listen on a topic which i don’t know a whole lot about, but seems to be the way of the future in tech. I picked this article because it was an interesting topic which comes up all the time in articles and discussion boards and i wanted more information, as well as how to test it. Although the podcast did not get around to talking about how machine learning is tested, there is a second part which was recently released which should go into more detail on that. This first section however gave a good overview on the topic and the issues that may arise, this gives you somethings to think about in terms of how testing will be affected compared to testing a standard algorithm. I enjoyed this article quite a bit and will be listening to the 2nd part to see how to go about testing Machine learning, i will be looking out to see what my expectations for testing using machine learning are before and after listening to part 2 of the podcast.

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

What are the key benefits that Angular and Typescript can offer? Dan Wahlin answers this question in his blog post 5 Key Benefits of Angular and TypeScript by listing his top 5 benefits of using Angular and Typescript. The list is as follows:

1. Consistency
2. Productivity
3. Maintainability
4. Modularity
5. Catch Errors Early

There are several reasons that Angular provides consistency for teams. The first of these that he talks about is how Angular is based on components and services which all start out the same way with the same overall structure. Another reason for consistency in Angular is through services. Any dependencies that a service requires can be injected into its constructor. Angular provides built-in dependency injection that will inject the objects at run-time. Angular also provides a CLI tool that can be used to create initial projects, add different features into an application, run tests, etc.

Angular provides productivity as well. Because Angular provides consistency, developers don’t have to worry about if they’re doing it the “right way” increasing productivity. Consistency also means that when you learn how to write a component you can write a similar one much faster. Using TypeScript to build your Angular application gives you access to editors that have intellisense which will increase productivity by making it easier to discover types and features they offer.

Angular is being built by a dedicated team at Google. This combined with open source contributions significantly improves the maintainability of Angular. Also due to the consistency of Angular, the code that you get will be much easier to maintain in production.

Angular uses modules, which provide a way to organization application functionality and divide it up into features and reusable chunks. Modules can be used to add organization into an application. The use modules properly will improve the division of labor, code consistency, productivity, and maintenance.

Angular built using TypeScript provides many benefits. Since Typescript is not a stand-alone language and instead is a superset of JavaScript, existing JavaScript code can be put into a TypeScript file and the code will work fine. TypeScript provides support for types allowing you to catch errors early because it’s much easier to see when something is used incorrectly. TypeScript code can also be debugged directly in the editor. It also allows you to use classes and other programming techniques.

I chose this blog because we’re using TypeScript and Angular for our final project and it’s useful to know the benefits of using them together. This blog taught me some of the key benefits that using TypeScript and Angular can offer. This will help me as I work on the final project and in the future when I use them again.

Source: https://blog.codewithdan.com/2017/08/26/5-key-benefits-of-angular-and-typescript/

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

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

There was an article I found the other day that took a different approach on types of testing.  The article is from ITpro, a site based out of the United Kingdom (http://www.itpro.co.uk/software-development/29994/types-of-software-testing).  The author breaks down nine different types of testing.  The article doesn’t try to state that the types are exclusive and that you should pick one or two and use those types.  Instead it just breaks down the different types, the different times they are carried out, and who carries out these tests.  Some are performed by the software testers during development and some are performed by the user to test different aspects.  For example alpha testing is performed by the software tester before release to search for all possible issues and errors.  Whereas beta testing is performed by the user in a deployed environment.  It can be as controlled and closed off to as group of a desired size in order to test for real time failures.  The control group is to ensure that it is not widely deployed across an environment and causing business failures.  Beta testing is similar to acceptance testing which is performed by the customer to ensure the product meets all requirements and expectations set by the user and the developer.  There is also a type of testing called security testing.  This type is performed by a special team outside of the standard testing team and usually performed by security consultants.  It is usually done to find out if there are flaws in the software that can allow it to gain access to computers or networks that it shouldn’t be able to and could cause damage to these networks.  Another specialized type is stress testing.  This is performed to push the software to its limits and usually beyond the normal operation that the standard user will put it through.  This is used and needed to get a clearer picture of what your software can do and what the limits are.  The one type that stood out to me the most and struck my interest was smoke testing.  This is done when a new build is sent to the testing team.  Simple tests are performed to find out if it crashes the program indicating bigger issues.  It makes sense to do, before digging deep into tests to just run quick simple tests to see if it can even pass that stage.  It just never occurred to me to make sure to do this step first before fully jumping into alpha testing.  I think that reviewing the different types of tests every once in a while to remember that there is a full spectrum of testing and how important the testing process is to software development.

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

Last week, I wrote my blog on Code Reviews. This week I am writing about how much time we should be spending during Code Reviews. I found an interesting article titled “Don’t Waste Time on Code Reviews” on DZone written by Jim Bird.

According to the article, research shows that reviewers find far more maintainability issues than defects (a ratio of 75:25) and spend more time on code clarity and understandability problems than correctness issues. There are a few reasons for this. Finding bugs in code is hard. Finding bugs in someone else’s code is even harder. In many cases, reviewers don’t know enough to find material bugs or offer meaningful insight on how to solve problems. Or they don’t have time to do a good job. So they cherry pick easy code clarity issues like poor naming or formatting inconsistencies. But even experienced and serious reviewers can get caught up in what at first seem to be minor issues about naming or formatting, because they need to understand the code before they can find bugs, and code that is unnecessarily hard to read gets in the way and distracts them from more important issues.

Code reviews add to the cost of development, and if you don’t do them right they can destroy productivity and alienate the team. But they are also an important way to find bugs and for developers to help each other to write better code. So do them right. Don’t waste time on meetings and moderators and paper work. Do reviews early and often. Keep the feedback loops as tight as possible. Ask everyone to take reviews seriously – developers and reviewers. No rubber stamping, or letting each other off of the hook. Make reviews simple, but not sloppy. Ask the reviewers to focus on what really matters: correctness issues, and things that make the code harder to understand and harder to maintain. Don’t waste time arguing about formatting or style. Make sure that you always review high risk code and high risk changes. Get the best people available to do the job – when it comes to reviewers, quality is much more important than quantity. Remember that code reviews are only one part of a quality program. Instead of asking more people to review code, you will get more value by putting time into design reviews or writing better testing tools or better tests. A code review is a terrible thing to waste.

I would say that the title was somewhat misleading though. I wish the title was less misleading, though – it’s easy to read as “Don’t do code reviews,” which isn’t what the post was saying. I think the title was either poorly worded or it was written that way intentionally as click bait. I think a better title would have been “Don’t Waste Time During Code Reviews”. I was spending lots of time reviewing code that a static code review tools can do. Form now, I would rather use tools like FindBugs and PMD which uses static analysis to look for bugs.

Source: https://dzone.com/articles/dont-waste-time-code-reviews

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.