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.
In this article, Ran Rachlin goes over the four warning signs that may signal that your current beta testing process might be in trouble.
The first point that he talks about is if your beta testing is having huge delays. The main way Rachlin says to over come this obstacle is to set strict deadlines for the team (this includes testers). He also points out to make sure that the objectives for the deadline are clear and reasonable; this is to make sure that everyone is on the same page and no one gets worried about what needs to be done. The other thing that this step includes is to make sure that constant contact is made with the testers so that communication is not lost and you receive better feedback.
The second item Rachlin touches upon is making sure that you don’t underestimate how much time it will take to go through testing. If you are on a tight deadline to get your product out, he recommends a few things that you should do. One is to make sure you have experienced tests for your product. Two is to stay in contact with the testers (as mentioned above), and inform them of the “time crunch” they are dealing with. These steps will help make sure that the testers know what they are doing before hand and are aware of the challenges they need to overcome.
The third thing is to be aware of the well being of the testers you’ve hired. If you’re testers become frustrated with the product they are working on, this can hinder the speed of testing the application. Again it helps to keep contact with the testers to make sure they are on track with the work, but you also want to make sure that they feel appreciated for the work they are doing; especially if they are in a time crunch. It may also help to give incentives near the end of a deadline to encourage testers to finish early or for a job well done. Although you should always have backup plan just in case things become too much for the testers that you have.
The last point that Rachlin makes is to ask yourself “Are we testing the target market and devices?” He says that you must make sure of two things; that you make sure the testers you have are from the target market and that you are using the “most popular devices and carriers in this target market” for your tests. If all of these issues are addressed, you should have minimal issues with they beta testing process for your app.
From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.
This is a frequent question among newbies to the tech industry.
Obviously it is going to depend on what kind of development you are up to. If you are making a Linux application, you’ll need a Linux OS; if you’re making a windows application, you’ll need a windows OS; if you’re making a mac application, you’ll need a mac OS.
But then the question becomes, what is the best OS overall?
I’ll try and compare the different OS’s using a benchmark. Let’s get to it.
In my personal opinion I’d say that that is you are into web developing, probably Windows is the best to go with as you can check on all reasonable common web browsers that you can’t on a Linux, including Mac which is a version of Linux.
For Linux, it’s good to learn the command line interface because it is very powerful without all the GUI. People underestimate the GUI and how it lowers productivity with higher response times. But that is not a good reason to switch to Linux as Windows has a command line too, and an advanced PowerShell which is on par with Bash.
For Mac users it is the best if you are into android development. You can write your code in Objective C which is good for android devices. I recently heard on a presentation that Java is a battery drainer for android applications. Thus people prefer to use Mac.
And even yet, Linux differs from the different distributions there is. For example, Solaris, which is a UNIX, performs very well Java compared to other Linux’s. It’s probably due to the fact that SOLARIS is made by Sun microsystems, but now owned by Oracle.
Diagram taken from: http://www.phoronix.com/scan.php?page=article&item=intel_atom_os&num=1
But in the real world it all comes down to economics. You can make a lot of money selling software for Windows, and when people give away open source on Linux, there’s hardly any monetary gain in making Linux application. The only time Linux is used in the real world is to as a large server warehouse, where they want to be cheap and avoid paying for licenses.
Works cited.
https://www.quora.com/Which-is-better-for-programmers-in-general-Windows-Linux-or-Mac
From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.