On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.
He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).
I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.
He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).
I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.
He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).
I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.
He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).
I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.
He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).
I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

On bug prevention

I really enjoyed this blog. The main theme more or less was can bugs be prevented? He goes on to talk about how in testing we go at the software from many different angles looks for bugs, but just how often is it that we actually think about preventing them and are they actually inevitable and can they even be prevented in the first place? While bugs are inevitable he believes that they can be somewhat prevented and after reading his blog I believe he is right.
He goes on to explain the general things we can do about prevention such as better communication, trying to make less mistakes in the code, understanding the platform that is being worked on and the list goes on. The main question he asks is this; What can a tester do to help with bug prevention? Testing happens usually after the bug is already in place and it is the then too late to prevent the bug right? Well maybe not. He goes on to say that the testing and the results report can actually influence the teams thought in some areas or things. He says, “For example, something as ‘innocent’ as an email saying: ‘I’m planning some testing of feature X and I wanted to make sure I’m not duplicating work on this. What kind of unit tests have you done on this?’ can gently nudge coders to think about unit-testing their code (and the bug prevention benefits that come from writing code that is unit-testable in the first place).
I really enjoyed this blog as he makes many good points and if I am ever in the tester role I will surely take some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Best Operating System for Developers?

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.

capture

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.

The Art of the Deal: Negotiating your First Job

If you are a college student with basic credentials and are applying for a job or summer internships, you’re at a disadvantage when it comes to negotiation, unfortunately. Because all you care about is to get a job, any job, that pays a little bit more! Then there’s the students that fall into the other category, the ‘exceptional’ category. Joel from the blog joelonsoftware.com, by stackOverflow CEO Joel Spolsky, warns about a tactic, a very common one, used by ‘third-grade recruiters and companies’ called the “exploding offer.” Here’s what happens. They call you for an interview, usually an on-campus one; maybe on their HQ for a second round. You will probably ace it since you are one of the ‘exceptional’ ones. They make you an offer and pressurize you to accept it by making you decide on the offer before finishing all of your other interviews. Career counselors know this, and almost every campus prohibits such tactics by recruiters. But the recruiters don’t care, it seems. Here’s Joel’s explanation: “They know that they’re a second-rate company: good enough, but nobody’s dream job, and they know that they can’t get first-rate students unless they use pressure tactics like exploding offers.”

But now let’s look at how to do the “negotiation” properly.

  1. First, you need to schedule all your interviews close to one-another.
  2. If you happen to get an “exploding offer” here’s how to push back: Say “I’m sorry, I’m not going to be able to give you an answer until January 14th. I hope that’s OK. ” Then you tone-up a little bit.
  3. In the rare case that they don’t accept, accept the offer, but go to the other interviews. Don’t sign anything. If you get a better offer, call them back and tell them that you changed your mind.
  4. Campus recruiters count on student’s high ethical standards. People feel bad when they make a promise to somebody and break it, students are no different. And that’s a commendable behavior, to make good of a promise. But unethical recruiters don’t deserve ethical decision making.

Joel Spolky’s blog was interesting, I think. Since it shows another aspect to your first job that people don’t think about. People are just happy to get a job right out of college and to be making some more $$ bucks $$ than they currently do. And that’s alright, I guess.

Citations.

https://www.joelonsoftware.com/2008/11/26/exploding-offer-season/

 

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

Why every developer should learn R, Python, and Hadoop.

Recently I used R for my course project on data mining. The course didn’t require that we use R, or Python. Instead, the course was thought on WEKA. But here’s why I think it should be done on R or Python in future years.

R is a heavy-duty language – R is a powerful scripting language. It will help you handle large, complex data sets. I was struggling to run WEKA with a dataset of no more than 5 million. Since part of data mining involves creating visualizations to better understand the relations of attributes, R seemed to be the natural best-fit for a course on data mining, and not WEKA. WEKA keeps crashing and the algorithms run comparatively faster on R and Python. This is partly due to the fact that R can be used on a high performance computer clusters which can manage the processing capacity of huge number of processes.  One other thing I liked the most was visualization tool that R is equipped with. The graphs and plots of R are so vivid and eye-catching.

Python is user-friendly- Python, similar to Java, C, Perl, is one of the more easier languages to grasp. Finding and squashing bugs is easier in python because it is a scripting language. Moreover, python is a object oriented language. Python is a performer like R. The other good thing is that if you are planning to do some fun oriented things with something called the Raspberry Pi, then Python is the language to learn.

Hadoop – Hadoop is well suited for huge data. Remember the issue I had with WEKA due to the size of my dataset. That problem can be eliminated by using Hadoop. Hadoop will split the dataset into many clusters and perform the analysis on those clusters and combine them together. Top companies like Dell, Amazon, and IBM that own terra-bytes of data have no choice but to use Hadoop.

You need to learn this three tools at a minimum in order to be a good data scientist and to do a good, thorough analysis on a given data.

 

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

“How was this Tested?”

Testers often find themselves being questioned at some point as to how a problem was tested. There’s a tendency to minimize recorded information when testing especially while running detailed instructional test cases, therefore when the question comes up, we can’t recall what we did or when.

Test cases a helpful, but they are just a model. They represent how tests can be done, but should not be relied solely on. The most important set of artifacts are the records kept during testing. Here are tips to keep in mind when testing..

The records should provide enough evidence to dismay any disbelief that the said tester did not complete accurate testing. Pair up with another individual to have a second pair of eyes and someone to back up your word. Record everything, make a note of everything performed in order to show the complete process.

https://www.stickyminds.com/article/how-was-tested-providing-evidence-your-testing?page=0%2C1

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.