Author Archives: Sudarshan

The Clean Coder, Chapter 3 and 4 (Week 2)

The third chapter of this book is about when and how to say yes and commitment. I liked the section on commitment speech vs. noncommitment speech. We should avoid language that shows or may signal that we are not commited to doing something. For example, using words like I need to do this, I hope to get this done, or I should get this done by Friday signals to the other person that you might not do it at all.

There are three parts to making a commitment
1. You say you’ll do it.
2. You mean it.
3. You actually do it.

The secret to recognizing commitment when somebody says something, according to the author, is to look for the words I Will. When somebody uses the words I Will when commiting to something, it shows that they are commited to doing it. And using these words also forces you to fulfil you promise, because you might feel embarassed for not fulfilling you promise.

I personally plan to use the words I Will when I commit to something. This way it forces me to fulfil my promise and also avoids people thinking that I am not commited to doing something.

The second chapter of the book is about when to code, when not to code and what to avoid while coding. This chapter is about the author’s personal beliefs about the matter. I persoanlly don’t agree that 3AM code is bad, I am a night person and most of my best works and ideas come at night. My brain usually does not work 100% during the day, it only starts to work from 8PM to 2AM.

I do however agree with him on the HELP section. Building software is not an easy task; it is the responsibility of developers to help each other and it is a violation of professional ethics to not help others or receive help.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Reflections, Week 1

I spent this week learning JavaScript and Angular 2. I found a nice website that has video lessons on JavaScript (https://javabrains.io/topics/corejs); I listened to almost all of the videos.

I found learning Angular 2 quite annoying. I have become so used to Java that it is going to take me some more time to really get used to Angular 2. After searching for a while, I found a channel on youtube about Angular 2 that I liked (https://www.youtube.com/playlist?list=PL6gx4Cwl9DGBYxWxJtLi8c6PGjNKGYGZZ). I watched the first few videos and plan to watch the rest by end of this week.

I also plan to learn TypeScript this week; from what I have learnt TypeScript is a super set of JavaScript and adds features like class based object orientation and type checking to JavaScript and it is also really important in Angular 2.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapter 1 and 2 (Week 1)

I read the the introduction, chapter 1 and chapter 2 of the The Clean Coder by Robert C. Martin. I found the introduction funny because the author basically quit the job he did not like while he was making $7,200 a year and and a few months later got the same job back for $6,800 ! I guess the lesson to learn here is the importance of wisdom.

The second and third chapters were about professionalism and when to say no to something (how to be a professional). Being a professional means that you care about the product you build and take responsibility for any problems that may arise. The author explains that to be a professional you must not create bugs in your software and if you make an error, you must apologize. Never release any code that you know to be faulty. And the software you write must be flexible.

The author also talks about the importance of learning. It our responsibility as professionals to make sure we are marketable. We have constantly to learn and strive to improve ourselves.

I found the second chapter interesting. The author explains why it is important to say no to a request by your boss and why not to use the word try. I think following this idea is hard in practice. What if you boss insist you complete something within a certain time limit (which is not possible)? It is very easy to just comply, but it is hard to say no given the fact that your boss has the authority to fire you. But I guess being a professional is not easy, you have to put the software that you produce over everything else.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Clean Code – Chapter 1 and 2 (Week 1)

I read the first 2 chapters of this book almost 16 months ago and I did not quite understand the significance of clean code back then. This week I decided to listen to the video version of clean code (available in SafariBooksOnline). The video version made it much easier to understand and I had a few good laughs.

In the first chapter Uncle Bob explains why clean code is important. He tells us the story of Sword Inc, a software company that failed because they produced bad code. When code is not clean the productivity of the development team decreases as time increases. The reason for this loss of productivity is that the developers build a mess as they develop the product. And the software product eventually fails becuase when the management demands new features within a certain deadline, the development team is not able to deliver because they just can’t.

The management tries all sorts of things (like increasing developers) to improve productivity, but nothing works. According to Brook’s law, adding more man power to a late project makes it later.

Finally the management turns to the developers for a solution. The developers solution is to redisgn the entire system! Management does not want to do this since it is expensive. The mangement however, after some time, decides to do it. But even this would not solve the problem. Eventually the company would loose customers because when they replace the new product for the old (more feature rich) product, customers leave for better products.

The only way to solve this problem is to stop running away from it and clean the mess.

So what is bad code? You know that a software systems contains bad code if it is rigid, is fragile, lacks seperability and is opaque. Uncle Bob goes on to explain that bad code is the fault of developers not management, not anybody else.

The second chapter is all about making your code more readable with the help of better naming strategies.

I can relate to this chapter and the Sword Inc company failure. Last semester I wrote software for a class project. Since we only had a limited amount of time and a bunch of requirements to fulfill, I rushed through the development process. As a result of my rushing, the code lacks the properties of clean code. If I had to use the code again or implement a new requirement, I would be lost.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Software Capstone (CS-448), Introductory Post

Hi everybody, I am excited about this course. I am currently working on setting up my JavaScript development environment using Visual Studio Code.

There will be a blog in the future regarding this topic; so stay tuned!

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Pass by object reference

Python’s passes parameters by object reference. What does that mean? Let’s first explore the pass-by-reference and pass-by-value parameter passing paradigms.

Pass-by-reference:

In pass-by-reference, the variable is passed directly into the function.

capture

The new variable points to the same object as the old variable. We just created a new reference to point to the same object.

Pass-by-value:

In pass-by-value, the function receives a copy of the argument objects passed to it and is stored in a new location in memory.

Capture1.PNG

The new variable points to a different object (a copy of the old object).

Pass-by-object-reference:

Python is different than languages like Java(pass-by-value)  in that it supports both pass-by-value and pass-by-reference. Variable in Python are not like the variable we know from other programming languages: variables in Python are object references. The value stored in a python variable is the memory address of the value, not the actual value. It is the memory address that is passed into a function, not the actual value. This means Python’s functions support call by object-reference semantics.

Based on the type of the object referred to, the actual call semantics used will differ. If the variable refers to a mutable value, call-by-reference is used. If variable refers to a immutable value, call-by-value is used.

 

References:

  1. http://robertheaton.com/2014/02/09/pythons-pass-by-object-reference-as-explained-by-philip-k-dick/
  2. Head First Python, 2nd Edition by Paul Barry

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Coverage Testing

One of the trickiest things about software testing is knowing when we have tested enough. We could spend hours testing the software and believe that we have done a good job and later find have a bug show up that was triggered by an input that we did not think to test.

One way that we could quantify the amount of testing done is to use a coverage metric. The coverage metric is a score that based on the number of functions tested in the source code.

I used the EclEmma code coverage plugin for Eclipse and I used the code from my previous blog. The following was the output of the code coverage.

 

capture

One thing that I noticed was that the coverage metric only tests to see if a particular method was traversed by a test case and not whether the test case passes. One of the test cases could have failed and the test coverage metric would stay the same. Obviously!

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Mutation Testing

This week I decided to play around with mutation testing and the pitest system for mutation testing.

So what is mutation testing? The idea is to mutate your code and check to see if your tests still pass. If your tests fail that means that your tests were able to detect the mutant. In mutation testing terms this means that the mutant was killed. The quality of your tests can be gauged from the percentage of mutations killed.

If the test cases pass after the mutation, that may indicate an issue with the test suite. The whole idea of mutation testing is to test the effectiveness of the tests.

I decided to run the pitest tool on the tictactoe example I found on the Test-Driven java Development book by Alex Garcia.

I have attached a link to the code and the corresponding pitest results (https://drive.google.com/drive/folders/0B586m1QhLSUXQzBlWHVZNkxnMmc?usp=sharing). The mutation coverage was 95% and all the mutations were killed. I wonder why all of the mutations were killed?

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Exploring Software

Imagine you are giving a large software system to test, how do you test the system? Where do you start? Chapter 4 of the exploratory software testing book (by James Whittaker) answers this question.

The author uses the metaphor of the tourist. Suppose you visit a city like London. How do you go about touring the city? Do you walk around? Use the bus? Use a guide? There are many ways to travel a city and so does exploring a large software system. There has to be some sort of structure to help us achieve our goals.

The following are the goals of exploratory testing:
1) Gain an understanding of how an application works, what its interface looks like and what functionality it implements.
2) To force the software to exhibit its capabilities.
3) To find bugs.

The author develops a tourist guidebook for software to help us explore software. The author separates software functionality into overlapping districts as follows:
1. business district (The main part or “where stuff gets done” in the software systems)
2. Historical district (Legacy code)
3. Tourist district (Many cities have districts where only tourists go. Software is similar in                                       that novice users will use certain features that experienced users would                                        not.)

4.  Hotel district (Every tourist needs a place to rest. Software is actually quite busy when it                                     is “at rest”, and testing tours need to test those features)
5. Seedy district (Places where illegal and bad stuff happen. Seedy tours find places of                                              vulnerability in the software)

The author goes on to explain how to test each of these “districts” and what kind of bugs they might release.

Tours is mechanism to organize a tester’s thinking about how to approach exploring an application and in organizing actual testing. The tours help testers make the myriad decisions about which path to choose, inputs to apply, or parameters to select.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Exploratory Testing

This week I was reading a book by James A. Whittaker called Exploratory Software Testing. The book, obviously, is about exploratory software testing.

The second chapter starts with a quote by Alan J. Perlis: There are two ways to write error-free programs: only the third one works. Basically he means that there is no way to write error free programs!

So if there is no way to write error free programs, is there a way to prevent bugs in programs? He goes on to discuss that all bug prevention techniques are generally developer-oriented like writing better specs, performing code reviews, running static analysis tools and performing unit tests. He argues that all of these techniques suffer from some fundamental issues: the “developer makes the worst tester” problem, the “software at rest” problem, and the “no data” problem. The “software at rest” problem brings to light the fact that code reviews and static analysis techniques try to test programs when there are at rest (not running). The problem with this approach is that most bugs only surface when they are running. What is the point of testing software when you cannot identify bugs?

The author goes on to argue that manual testing is more powerful than automated testing. Manual test techniques like exploratory testing allows the full power of the human brain to be used on finding bugs. This chapter is a prelude to the rest of the book which discusses the methods and wisdom used for exploratory testing.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.