Monthly Archives: November 2019

10 Software Testing Trends

Hello again everyone and welcome to my fourth entry for the semester on this blog. today we are going to talk about some software testing trends. As the title of this post suggests, we will be talking about ten of them today. The article was written by Ulf Eriksson (Really cool name) and i started this article by skimming and it seems to be very short and concise, which means it’ll be easier for me to write about. I will only be writing about the five i found the most interesting.

So obviously, this article is going to be about trends that everyone should be seeing in 2019. Ulf leads off with mentioning the “evolution of new testing approaches” (Eriksson) due to new developments with Agile and DevOps. He then begins his list with discussing Agile. He says that Agile is being used in more and more comapanies. He then talks about what Agile is and how it works, but if you’re reading this you probably know what agile is so I won’t bore you with that. The next part caught my eye because it has to do with machine testing. I don’t know much about machine testing, but it still has my interest. Ulf describes how it is used as follows: Test suite optimization (redundancy), predictive analytics(key parameters), log analytics(automatic executing), traceability (test coverage), and defect analytics(identifying high risk areas). The next trend is the adoption of DevOps. This part was very short and it talks about continuous integration and continuous delivery. Another trend was shortening the delivery cycle. This section talks about how new technologies are being used in order to speed up the deliveries. This is interesting because this will always be a trend. New technologies are coming out everyday, so it is impossible for this trend to die down. Ulf also discusses big data testing as a trend, and I chose to write about this because it isn’t my concentration so it is interesting to read about this considering I am not studying it. Basically this kind of testing makes sure the large amounts of data are being verified correctly. In other words, this tests the quantity and quality of data.

I would have loved to write about every trend on this list, but this blog would be way too long and I would lose all my reader(s) about halfway through. However, Ulf Eriksson did a great job with this article. He didn’t go into much detail about every trend because some of them should have already been known. However, the lesser know trends were explained very well. This article was a very interesting read because I’m in quality assurance testing now, and it is nice seeing topics I learned in class in articles. I would recommend this to any testers out there.

https://dzone.com/articles/10-software-testing-trends-to-watch-out-for-in-201

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.

Front End Decisions…Back End Decisions…Decisions.

Activity 12 was a good activity to start learning about Angular front-end development, especially with making REST API calls. However, lack of a strong HTML / CSS background may leave some people a bit behind when trying to build something a little more robust. The Tour of Heroes angular tutorial can be pretty useful for a really comprehensive, step by step guide on building a working front-end of a particular style. This could be useful with our upcoming final project to design a single-page web app. I think my plan, for now, will be to start simple, and build on the project as I have more time. I would be interested in eventually implementing the sort of “Second page” that Tour of Heroes has.

For front-end ideas, I did download Professor Wurst’s STEM-TV project and run it. While I appreciated the lecture he gave on the app, I do feel a POGIL style exercise may be beneficial for future classes to really get into the meat of it.

The back-end for my project has been something I’m wracking my brain over. I would like to try to utilize some of google sheets’ REST API features if possible. I am going to experiment with that line of thinking and see where it takes me. I have data that I have actually built myself based on games of Rocket League. I don’t think the data is particularly interesting, but it’s personal and fun.

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

First STUBS now others…

Last time I have learned abut Stubs in programming, this time I came to find out that there is more to it then I thought. For the Testing class we had to read this article by Martin Fowler and learn about apparently different kinds of Stubs, but Mocks are not Stubs…..

The article is a little bit lengthy but it is a good source of information if you want to, or have to learn more about testing, it also had a plenty of examples and explanations how the differences between stubs and mocks and dummies and fakes look like. When it comes down to it remembering these definitions from Fowler is the minimum of work:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
  • Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Stubs

When it comes to testing software I am definitely all for it but at the same time I am for it by doing it the “old school” way. Even at work this mentality stands, but recently the more I learn about testing the more I understand the need for it.

Having learned more about the subject of testing I feel like I can talk a little bit about it. Stubs is the part I been educated on recently and it is a bit confusing but that will probably go away with time and practice. Anyway Stubs. Those in programming are (according to Wikipedia): a piece of code used to stand in for some other programming functionality. A stub may be a temporary substitute for yet-to-be-developed code. I do know how to use those but until now I didn’t know what they are called and that is cool in its own way. Everybody knows how to use some fake code that is there just to run something for a time or to fool rest of the code into working. Now you know what to call it to. A STUB!!!

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Angular CDK and Popover

With CS 343’s final project beginning, I have looked into some ways of displaying data. For this week, I will focus on Angular’s CDK. In Netanel Basal’s article “Creating Powerful Components with Angular CDK,” Basal describes the process of making an overlay in angular. He starts with creating a Popover service, Popover being a component from the CDK. This component is used for creating popup overlays, such as info that pops up while the mouse is hovering over something. Basal then creates the PopoverRef and its Injector. The PopoverRef is then injected into a ComponentPortal which is then attached the origin page. Portals dynamically render UI to the page. For the portal, the author creates a custom component to receive the contents to be displayed and how to render them. The article then covers three types of content the PopoverComponent can receive: text, template, and component. With that, the article’s example is completed. Now let us get a little more in-depth.

Let’s start with the Popover service. This service creates an
open() method that creates the overlay, its contents, and its injector. This
service is injected into the Popover component, where the open() method is
utilized in a show() method in the app component that is called on when a
button is clicked in the root component HTML. From what I understand, this
service handles the creation of all the parts needed to make the popover with an
open() method.

Next up is the PopoverRef, a class that receives a
overlayRef, content, and data, and creates a close() method to dispose of the
overlay. It seems that this class is used for the storage of the parent
overlay, the content, and the data, and the close() method that removes the popover.

Since Basal wanted to use a custom component, he needed to
create an Injector for it. The injector is created in the Popover service in a
createInjector() method, which converts the custom injector to a PortalInjector.

The author then attaches the soon-to-be-created Popover
component to the overlayRef in the popover service. This is done by overlayRef’s
attach() method, where a new ComponentPortal containing the PopoverComponent is
attached to the overlayRef.

The Popover component’s job is simple, just to inject the
popoverRef and render its contents. This article’s example provides multiple
rendering methods depending on content type. The three content types being template,
component, and text.

For all three types, a show() method is added to app
component that injects PopoverComponent and creates a Popover from popover service.
The only difference between the content type’s show() is what the content in
Popover is set to. This method is called on in the app component’s HTML where
it is attached to a button.

Reading through this article and examining its code has helped me towards learning how to create popup overlays. I feel I have a more solid grasp of how angular components interact with each other. I will undoubtedly use knowledge I gained from the article, “Creating Powerful Components with Angular CDK” by Netanel Basal, in my final project.

Article Referenced:
https://netbasal.com/creating-powerful-components-with-angular-cdk-2cef53d81cea

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

What’s your Angle – Or – How to configure your Angular app to deploy on Heroku

So, you’ve built this really awesome Angular app, now what? Oh, you want to deploy it using Heroku. Easy peasey but there are a few gotcha’s to look out for. Running an Angular app locally we just run: ng serve -o But Heroku doesn’t work that way it needs to know how to serve up the app. We need to install a couple of packages and modify our project to make this work. The following steps should get the app up and running on Heroku just fine. First let’s make sure you are running the latest version of Angular CLI and the Angular Compiler CLI. Open a terminal session in the root folder of your project and run this: npm install @angular/cli@latest @angular/compiler-cli –save-dev So what did we just do? We installed (or updated) Angular CLI and the Angular CLI Compiler to the latest version the –save-dev added the necessary entries to the package.json which we now need to modify. Open the package.json with your favorite editor and scroll down to the devDependencies section. Move these two entries up into the Depencies section: “@angular/cli”: “^7.3.9”, “@angular/compiler-cli”: “^7.2.15”, Pay attention to the formatting and make sure you have commas where commas are needed etc. Notice the ^ symbol before the version numbers? That indicates that the version number shown is the lowest version that can be used but higher versions are allowed. Since this is an Angular app we also want to move the typescript entry up from the devDependecies to the Dependencies section. In my package.json it looks like this: “typescript”: “~3.2.2”, Now we need to tell Heroku how to build the app when it’s deployed. In the scripts section of the package.json add the following line: “postinstall”: “ng build –aot –prod” This tells Heroku to use the Ahead Of Time compiler and make the app production ready. This will create the /dist folder where all the javascripts and html are launched from. Ok now back in terminal type in: npm -v followed by node -v Make a note of the version numbers for both. We need to create an entry at the bottom of the package.json to tell Heroku what engines to use. Format the engine entry like this: “engines”: { “node”: “8.9.0”, “npm”: “6.10.2” } Paste this into the package.json right after the devDepencies section. Be sure to add a comma after the closing } for the devDepencies section. My package.json is pasted way below as an example. Since we can’t run ng serve on Heroku we need to a way to serve the app. We’ll install Express server to handle that for us. Back in terminal run: npm install express path –save This will install Express and create the entry in the package.json for us. Verify that the entry has been created in package.json it should like similar to mine: “express”: “^4.17.1”, Now go back to terminal and type in: touch server.js This creates an empty server javascript file. Open server.js with your favorite editor and paste the following into it: //Install express server const express = require(‘express’); const path = require(‘path’); const app = express(); // Serve only the static files form the dist directory app.use(express.static(__dirname + ‘/dist/your-app’)); app.get(‘/*’, function(req,res) { res.sendFile(path.join(__dirname+’/dist/your-app/index.html’)); }); // Start the app by listening on the default Heroku port app.listen(process.env.PORT || 8080); Replace your-app with the name of your app.
(you will use the name of the sub-folder located in /dist ) Now back in package.json modify (or add) the start entry located in the scripts section to this: “start”: “node server.js” Now save your changes and push them back Gitlab: git add .
git commit -m “updates to deploy to heroku”
git push Following your push check your pipelines and see if the deployment to Heroku was successful. If so go to Heroku and check out your awesome app! If not rewind, start from the top , and double check everything. My package.json: { “name”: “my-app”, “version”: “0.0.0”, “scripts”: { “ng”: “ng”, “start”: “node server.js”, “build”: “ng build”, “test”: “ng test”, “lint”: “ng lint”, “e2e”: “ng e2e”, “postinstall”: “ng build –aot –prod” }, “private”: true, “dependencies”: { “@angular/animations”: “^7.2.15”, “@angular/cli”: “^7.3.9”, “@angular/common”: “^7.2.15”, “@angular/compiler”: “^7.2.15”, “@angular/compiler-cli”: “^7.2.15”, “@angular/core”: “^7.2.15”, “@angular/forms”: “^7.2.15”, “@angular/platform-browser”: “^7.2.15”, “@angular/platform-browser-dynamic”: “^7.2.15”, “@angular/router”: “^7.2.15”, “bootstrap”: “^3.3.7”, “core-js”: “^2.6.10”, “express”: “^4.17.1”, “rxjs”: “~6.3.3”, “tslib”: “^1.10.0”, “typescript”: “~3.2.2”, “zone.js”: “~0.8.26” }, “devDependencies”: { “@angular-devkit/build-angular”: “^0.13.9”, “@angular/language-service”: “^7.2.15”, “@types/jasmine”: “~2.8.8”, “@types/jasminewd2”: “^2.0.8”, “@types/node”: “~8.9.4”, “codelyzer”: “~4.5.0”, “jasmine-core”: “~2.99.1”, “jasmine-spec-reporter”: “~4.2.1”, “karma”: “~4.0.0”, “karma-chrome-launcher”: “~2.2.0”, “karma-coverage-istanbul-reporter”: “^2.0.6”, “karma-jasmine”: “~1.1.2”, “karma-jasmine-html-reporter”: “^0.2.2”, “protractor”: “~5.4.0”, “ts-node”: “~7.0.0”, “tslint”: “~5.11.0” }, “engines”: { “node”: “8.9.0”, “npm”: “6.10.2” } } #CS@Worcester #CS448

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

What’s your Angle – Or – How to configure your Angular app to deploy on Heroku

So, you’ve built this really awesome Angular app, now what? Oh, you want to deploy it using Heroku. Easy peasey but there are a few gotcha’s to look out for. Running an Angular app locally we just run: ng serve -o But Heroku doesn’t work that way it needs to know how to serve up the app. We need to install a couple of packages and modify our project to make this work. The following steps should get the app up and running on Heroku just fine. First let’s make sure you are running the latest version of Angular CLI and the Angular Compiler CLI. Open a terminal session in the root folder of your project and run this: npm install @angular/cli@latest @angular/compiler-cli –save-dev So what did we just do? We installed (or updated) Angular CLI and the Angular CLI Compiler to the latest version the –save-dev added the necessary entries to the package.json which we now need to modify. Open the package.json with your favorite editor and scroll down to the devDependencies section. Move these two entries up into the Depencies section: “@angular/cli”: “^7.3.9”, “@angular/compiler-cli”: “^7.2.15”, Pay attention to the formatting and make sure you have commas where commas are needed etc. Notice the ^ symbol before the version numbers? That indicates that the version number shown is the lowest version that can be used but higher versions are allowed. Since this is an Angular app we also want to move the typescript entry up from the devDependecies to the Dependencies section. In my package.json it looks like this: “typescript”: “~3.2.2”, Now we need to tell Heroku how to build the app when it’s deployed. In the scripts section of the package.json add the following line: “postinstall”: “ng build –aot –prod” This tells Heroku to use the Ahead Of Time compiler and make the app production ready. This will create the /dist folder where all the javascripts and html are launched from. Ok now back in terminal type in: npm -v followed by node -v Make a note of the version numbers for both. We need to create an entry at the bottom of the package.json to tell Heroku what engines to use. Format the engine entry like this: “engines”: { “node”: “8.9.0”, “npm”: “6.10.2” } Paste this into the package.json right after the devDepencies section. Be sure to add a comma after the closing } for the devDepencies section. My package.json is pasted way below as an example. Since we can’t run ng serve on Heroku we need to a way to serve the app. We’ll install Express server to handle that for us. Back in terminal run: npm install express path –save This will install Express and create the entry in the package.json for us. Verify that the entry has been created in package.json it should like similar to mine: “express”: “^4.17.1”, Now go back to terminal and type in: touch server.js This creates an empty server javascript file. Open server.js with your favorite editor and paste the following into it: //Install express server const express = require(‘express’); const path = require(‘path’); const app = express(); // Serve only the static files form the dist directory app.use(express.static(__dirname + ‘/dist/your-app’)); app.get(‘/*’, function(req,res) { res.sendFile(path.join(__dirname+’/dist/your-app/index.html’)); }); // Start the app by listening on the default Heroku port app.listen(process.env.PORT || 8080); Replace your-app with the name of your app.
(you will use the name of the sub-folder located in /dist ) Now back in package.json modify (or add) the start entry located in the scripts section to this: “start”: “node server.js” Now save your changes and push them back Gitlab: git add .
git commit -m “updates to deploy to heroku”
git push Following your push check your pipelines and see if the deployment to Heroku was successful. If so go to Heroku and check out your awesome app! If not rewind, start from the top , and double check everything. My package.json: { “name”: “my-app”, “version”: “0.0.0”, “scripts”: { “ng”: “ng”, “start”: “node server.js”, “build”: “ng build”, “test”: “ng test”, “lint”: “ng lint”, “e2e”: “ng e2e”, “postinstall”: “ng build –aot –prod” }, “private”: true, “dependencies”: { “@angular/animations”: “^7.2.15”, “@angular/cli”: “^7.3.9”, “@angular/common”: “^7.2.15”, “@angular/compiler”: “^7.2.15”, “@angular/compiler-cli”: “^7.2.15”, “@angular/core”: “^7.2.15”, “@angular/forms”: “^7.2.15”, “@angular/platform-browser”: “^7.2.15”, “@angular/platform-browser-dynamic”: “^7.2.15”, “@angular/router”: “^7.2.15”, “bootstrap”: “^3.3.7”, “core-js”: “^2.6.10”, “express”: “^4.17.1”, “rxjs”: “~6.3.3”, “tslib”: “^1.10.0”, “typescript”: “~3.2.2”, “zone.js”: “~0.8.26” }, “devDependencies”: { “@angular-devkit/build-angular”: “^0.13.9”, “@angular/language-service”: “^7.2.15”, “@types/jasmine”: “~2.8.8”, “@types/jasminewd2”: “^2.0.8”, “@types/node”: “~8.9.4”, “codelyzer”: “~4.5.0”, “jasmine-core”: “~2.99.1”, “jasmine-spec-reporter”: “~4.2.1”, “karma”: “~4.0.0”, “karma-chrome-launcher”: “~2.2.0”, “karma-coverage-istanbul-reporter”: “^2.0.6”, “karma-jasmine”: “~1.1.2”, “karma-jasmine-html-reporter”: “^0.2.2”, “protractor”: “~5.4.0”, “ts-node”: “~7.0.0”, “tslint”: “~5.11.0” }, “engines”: { “node”: “8.9.0”, “npm”: “6.10.2” } } #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

REST – INSOMNIA(c)

This week let’s take another peek at the FoodKeeper API. We’ll review the endpoints and how to submit a request to retrieve data. Before we jump into this you need to download and install a REST client. I highly recommend Insomnia, the app not the sleep disorder, (download it here) I’ll wait… Now that you have Insomnia installed let’s talk about endpoints. Last week we covered the four primary HTTP verbs used with REST. Did you have a chance to visit https://www.restapitutorial.com despite the name of the website these aren’t tutorials on how to make REST calls but more like development guidelines for developers writing REST API’s.

So why did I recommend it? Because understanding how a good RESTful API is designed will make it easier to craft your REST calls. So the 4 basic HTTP verbs (POST, GET, PUT and DELETE) are CRUD (Create, Read, Update, Delete) operations. · POST = Create · GET = Read · PUT = Update · DELETE = Delete Kind of makes sense, right? These also make up the endpoints you access with your REST client. In JAVA we add an annotation to the class and the getter and setter methods to define the endpoint. For the FoodKeeper API we are using the Spring Framework (https://spring.io/) to help setup the Rest components. After all the imports are declared the class must be annotated with @RestController so that the compiler knows how to process it. Each endpoint must be annotated to reflect what it does. A POST endpoint would be annotated like this: @PostMapping(“/list/new”) The part in parenthesis indicates the URL path that you would pass as part of the REST Client call and is the actual endpoint. Let’s look at an online example. In a new tab on your browser go to: http://dummy.restapiexample.com/ The site lists 5 public endpoints you can practice against: · GET /employee · GET /employee/{id} · POST /create · PUT /update/{id} · DELETE /delete/{id} Note the curly braces with id in between them – this indicates that you will be passing a value.
Open your REST client, in Insomnia you would type in the URL in the White field in the top center of the screen and select the REST Method to the left of it: Click the Send button and watch the Right hand column you will see it populate with employees. This is the first entry in the list that was returned for me: Play around and get familiar with your REST Client and hit some of the other endpoints at

http://dummy.restapiexample.com/ TIP: For the endpoints above with {id} just append the url string with a number like this: http://dummy.restapiexample.com/api/v1/employees/6821 All right go play and learn something! #CS@Worcester #CS448

From the blog Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Behavior-Driven Development (BDD)

Once again, Martin Fowler has some comments on this week’s topic, but this post will mainly reference Dan Terhorst-North’s post, which better describes the reason and motivation for creating Behavior-Driven Development. BDD arose from TDD and it is better to think of it as an extension of TDD.

BDD tests follow the pattern “Given-When-Then” (notice the similarity to Arrange-Act-Assert). Mockito can define this pattern, but the BDDMockito aims to follow the same human-readable principles. The idea is simple: given a precondition, if some other condition occurs, then something else should have happened. Fowler’s example includes checking the state of an object, so clearly BDD is not simply testing the behavior of an object. However, it is a very important part.

Terhorst-North mentions that BDD picks up where TDD left off. I have seen some evidence that BDD has influenced TDD, such as describing tests as a sentence like “testFailsForDuplicateCustomers()”, which can be seen in many TDD test examples. Imitation is the highest form of flattery, so clearly this is a good approach. Or maybe, BDD is just more consistent in this naming because they put it in the specification.

Regardless, BDD developed out of Agile processes. It aimed to make writing tests part of the entire process and help future developers work well together in doing so. This is where many of Terhorst-North’s ideas stemmed from, and his main point, and the motivation behind the name BDD, is that “‘Behaviour’ is a more useful word than ‘Test’”. If you describe each test as a behavior, you know how to define the test, and you know when the specification has changed enough to warrant deletion of a test.

“What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails. . . either you introduced a bug, the behaviour moved, or the test is no longer relevant.”

Daniel Terhorst-North, “Introducing BDD”

Real mastery of a subject is when it becomes simple. BDD is the next step to understanding testing on an intuitive, subconscious level. It wasn’t immediately obvious that tests don’t need to be difficult to write, but Terhorst-North managed to figure out a way to make it so. It is another part of the iterative process that is technology. Next time I encounter a difficult concept, I think asking three questions, in order, might help: Am I misunderstanding the concept? Do I just need more practice? Or is this method flawed?

Someone saw a flaw in TDD and developed BDD to improve it. This came only through thorough understanding, practicing, and identifying problems. This is applicable to any career, to provide real value.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

FPL&S 2: Uploading Files Through an API

I must say, this project has gotten much more complicated than I was expecting, even last week. Not difficult necessarily, but requiring much more knowledge of the framework that I expected. But after a steep hill over the course of the week, the good news is the features of Angular are much more powerful and exciting than I had thought. While the project specification requires communication with a REST API, which will be used for the database, I also require remote file storage. Since I will be using Google Firebase for both of these services, and file storage has a much simpler API which I’d prefer to use with mobile, I opted to not use the REST API for file storage.

Understanding the Firebase Storage API was the first step, but after reading through much of Google’s documentation for the web API, I still had difficulty translating everything to Angular and TypeScript. But luckily, Google is kind of a big deal these days, so David East from Angular posted a short tutorial that helped me bridge the gap.

The most mindblowing portion of completing this task was the concept of an async pipe, which I will explain shortly. You can’t get through a CS degree without learning and performing asynchronous tasks, but this syntax was completely alien to me. Take this HTML from David East’s post:

<label for="file">File:</label>
<input type="file" (change)="upload($event)" accept=".png,.jpg" />

This demonstrates Angular’s ability of event binding. The (change) syntax is binding a change in input to the upload() method in the Component, while also passing the event DOM, from which you can get the File using TypeScript. My needs were a bit different, but this same syntax can be used to simply store the file when the input is changed. Then, a separate upload button’s (click) event can trigger an upload within in the Component:

<button class="btn" (click)="submit()">Upload</button>

From there, my Component uses Typescript to communicate with the AngularFireStorage service, and even update a progress bar. This is where the async pipe comes in:

<progress max="100" [value]="(uploadProgress | async)"></progress>

More binding! This time, we’re using square brackets to bind the value property of the HTML progress tag to an Observable<number> object, which we can get within the Component from the AngularFireStorage service. This Observable will update the progress bar as the file uploads if we pipe it through an async task, as shown above. This subscribes to the Observable (or Promise) and automatically unsubscribes when the Component is destroyed.

I highly recommend reading over Angular’s template syntax documentation to get better acquainted with these concepts.

After completing this portion of the project, I’ve determined I’ve been thinking too much in terms of JavaScript, because I’ve found some of TypeScript’s rules to be a hindrance. Some of the examples noted above have shown me that if I get back to an object-oriented, strongly-typed mindset, I will be able to work quicker on future tasks. Essentially, this is just a matter of getting practice with a new language and framework.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.