NOTES FROM USING SPARK in the HADOOP ECOSYSTEM by Rick Morrow Starting EMR on AWS Objective In this lab, you’ll use Amazon Web Services to set up a 3 node Elastic MapReduce (EMR) cluster which you can then use for … Continue reading 
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM Java Build Automation with Maven with Peggy Fisher 1. Get Started with Maven What is Apache Maven? Apache Maven, is a software project management, and comprehension tool, based on the concept of a project object model, or POM. Maven … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM Up and Running with Public Datasets Curt Frye 1. U.S. Census Bureau and Securities and Exchange Commission American FactFinder link: factfinder.census.gov Most US residents know the United States Census Bureau as the government organization that counts the American … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM Fundamentals of Software Version Control Michael Lehman 1. Overview of Software Version Control Overview of software version control Version Control is the process of keeping track of your creative output as it evolves over the course of a … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM Asking Great Questions Dough Rose 1.Introduction One of the most important parts of working in a data science team is discovering great questions. To ask great questions you have to understand critical thinking. Critical thinking is not about … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM Database Fundamentals: Core Concepts Adam Wilbert 1. Understanding Database Storage Models What are databases? Databases are at the core of our modern technology and it’s important to understand exactly what they are and the benefits that they bring … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
NOTES FROM SCRUM: A Breathtakingly Brief and Agile Introduction Chris Sims & Hillary Louise Johnson What is SCRUM? A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty … Continue reading
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
This blog is about so many different things. It’s about things that make you go ‘What’! And then when you don’t want to except those things that’s the part of the blog that’s in the second page it’s called “Oh hell no”! Then it’s like “Hold up”, because maybe I didn’t think that through, maybe I do want to know about it. And then it’s like “huh?? Oh okay.” You know what I mean?
I took that from the show Impractical Jokers https://www.youtube.com/watch?v=kgsP_WAFbu0
I think that that’s the kind of conversations developers have in their day-to-day life.
For example, developers have to learn new tools everyday in order to keep up with the changing field. Some ideas may make you have the first part of the conversation, “what! I have to learn this stuff!.” Then you hear how complex it is and it makes you say, “Oh hell no!” But then you realize that it actually makes sense and that it is not as complex, and that makes you go, “Hold up.” But then as you try to learn the tool you get into some obstacles, making you say “huh?” Then you realize how cool the new tool is and how much it simplifies your job more, and that makes you say “oh okay.”
For example, I just learnt a new tool for testing called the JMockit. JMockit is primarily used to mock objects, not an instance of an object, but objects themselves like classes and interfaces. But the problem is that it is not as simple as you would like it to be. It does not conform to object-oriented rules, and thus it feels so unnatural for a developer to use. This is the part where you have the “what! oh hell no!!” conversation with yourself. One thing that I find annoying is that debugging a JMockit unit test can be very difficult, because the internals of how mock object results are returned are not well documented. For example, if arguments to a mock object invocation do not properly implement “equals(Object other)” then your invocation may not match any expected invocation and will return null instead of your intended result. It is very difficult to step through the mock object framework matching code to find the particular argument that is failing to match. But then there’s so many other pros of using it, so you give JMockIt an open mind. That’s when you go “Hold up.” Sure enough JMockit provides well documentation for other functionalities.
In my opinion JMockit is definitely worth learning. However, the author of unheededwarnings.blogspot.com, Richard, advises that a simpler framework be used if available. But he also says that “JMockit is probably the simplest mock framework to use after you master its unusual API.” So the conversation would end in ” Huh? ? Oh okay.”
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.
In his article, Rohit Sharma goes over the top five most common mistakes users have made when using automation tools for testing.
The first item on his list is when testers “think of automation testing as little more than record and replay.” He goes on to say that proper automation testing is done when a tester has customized the generated script for their specific needs. Sharma also mentions that the record feature should only be seen as an outline and not as the finished script.
Second on the list is when testers do not validate the scripts that they are using. Sharma suggests that using checkpoints, at as many places as possible, can help to remedy this situation.
The third thing is that you don’t want to just validate your visible components when testing. Anything that happens on the back end should also be checked to make sure that your script is properly validating it (the two examples that Sharma gives are communications to a database, and making sure a file was automatically created properly).
Fourth on the list is making sure to remember that automated testing cannot replace human testing. Sharma states that “automation is a great way to augment your testing efforts,” but automation testing only works well “when you know what to look for.” In the case that he states, you could have a web page that generates unreadable text, but, unless you have someone looking out for that, you are unlikely to find it with automation testing.
The last item that Sharma talks about is making creating “inappropriate test cases.” He points out that there are multitudes of paths that a user can use in your application so trying to test all of them would waste time. Instead, try to figure out how to “condense all possible paths to a small sample of highly representative test cases,” so that it covers the majority of your user’s activity.
From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.
This article goes over seven different practices that will help with Test Driven Development when using the Agile approach.
The first thing that should be done is make sure you “avoid functional complexity.” The point of this type of approach is to keep it simple. The article suggests going over with your team to make sure that the test covers all the functionality that is needed.
The second thing is to make sure you have a clear understanding on what it is you are trying to achieve. It’s advised that you follow standard documentation and naming for your tests. This is so that developers are able to come back to it and understand what was the intended purpose for the set of tests.
The third item is that code is not overly complected. You want to make sure that your test is kept simple so that the code is easily readable and has room for any necessary improvements.
Fourth on the list is to make sure you are testing everything repeatedly. Always run tests before and after coding, and after refactoring since you never know when adding something new might break your tests. Also remember that when you refactor, to make sure that the node is still “maintainable and adheres to standards.”
Fifth point that is made is to “maintain code sanctity.” This means that you should be using version control tools to keep your code in check; which is extremely import if you have multiple developers working on the same code.
The sixth thing is making sure that your team is aware and understands how the application works. To do this make sure that the system documentation is clear and that all team members understand how the system and tests work. This will not only make sure that when new code is added, the overall program will not break, but also that new tests will work in the first run.
The last item that the article points out is to “know when to use TDD.” Test Driven Development is not suppose to be used for any testing that will take a long time. Always remember TDD primary function is to be used for projects that can be tested quickly.
From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.