Author Archives: shatos

Radiology Module Update

This week I worked on an issue for the Radiology module in which I found dead and unused code that could be deleted to save space and increase efficiency. It might not be a difficult issue, but it helped me learn about the process of working on and testing an issue. There is nothing I would change about my process, fortunately everything went pretty well. I am in the middle of testing my edits, and I expect to receive working results as I searched for each line I was intending on deleting to see if it was used anywhere other than where it was initiated.

Overall, there were only 2 steps, but each step took a while to work on. Step 1 was just to search for each line in the messages.es file in the repository to see if it is needed or does absolutely nothing. If it is not used, just delete it. For safety reasons, I copied each line that was being deleted into another notepad file just in case we deleted a line that was actually needed. Second step is the testing to see if it still works. I am still in this process, but I will make another post that goes through the details of testing in the radiology module.

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

Radiology Module Update

This week I worked on an issue for the Radiology module in which I found dead and unused code that could be deleted to save space and increase efficiency. It might not be a difficult issue, but it helped me learn about the process of working on and testing an issue. There is nothing I would change about my process, fortunately everything went pretty well. I am in the middle of testing my edits, and I expect to receive working results as I searched for each line I was intending on deleting to see if it was used anywhere other than where it was initiated.

Overall, there were only 2 steps, but each step took a while to work on. Step 1 was just to search for each line in the messages.es file in the repository to see if it is needed or does absolutely nothing. If it is not used, just delete it. For safety reasons, I copied each line that was being deleted into another notepad file just in case we deleted a line that was actually needed. Second step is the testing to see if it still works. I am still in this process, but I will make another post that goes through the details of testing in the radiology module.

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

CS Review: Strings

Tokenizers:

  1. StringTokenizer tokenizer = new StringTokenizer(“Example String Here”, delimiter (blank if space));
  2. while(tokenizer.hasMoreElements()){
  3.         Integer i = Integer.parseInt(tokenizer.nextElement().toString());
  4. }

Substring:

  1. String full = “Full Text”;
  2. String sub = full.substring(5,9);
  3. System.out.println(“Will print the word ‘Text’:  ” + sub);

Split:

  1. String full = “This is the full text”;
  2. String[] = full.split(” “); //or regular expression
  3. string.trim();

Character At:

  1. char c = string.charAt(7);

Replace:

  1. String s = “Hello”;
  2. s.replace(‘H’, ‘J’);//turns Hello to Jello
  3. s = “Hello”;
  4. s.replace(“Hello”, “Jello”);//also turns to Jello

Character Array:

  1. char[] cha =  new char[str.length()];
  2. for(int i=0;i<str.length();i++){
  3.         cha[i] = str.charAt(i);
  4. }
  5. //toString for printout

 

 

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

CS Review: Strings

Tokenizers:

  1. StringTokenizer tokenizer = new StringTokenizer(“Example String Here”, delimiter (blank if space));
  2. while(tokenizer.hasMoreElements()){
  3.         Integer i = Integer.parseInt(tokenizer.nextElement().toString());
  4. }

Substring:

  1. String full = “Full Text”;
  2. String sub = full.substring(5,9);
  3. System.out.println(“Will print the word ‘Text’:  ” + sub);

Split:

  1. String full = “This is the full text”;
  2. String[] = full.split(” “); //or regular expression
  3. string.trim();

Character At:

  1. char c = string.charAt(7);

Replace:

  1. String s = “Hello”;
  2. s.replace(‘H’, ‘J’);//turns Hello to Jello
  3. s = “Hello”;
  4. s.replace(“Hello”, “Jello”);//also turns to Jello

Character Array:

  1. char[] cha =  new char[str.length()];
  2. for(int i=0;i<str.length();i++){
  3.         cha[i] = str.charAt(i);
  4. }
  5. //toString for printout

 

 

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

CS Review: Input/Output

There are a few basic types of input/output sources that are usually used.

Buffered File In:

    1. String file = “file.txt”;
    2. FileReader fReader = new FileReader(file);
    3. BufferedReader bReader= new BufferedReader(fReader);
    4. String s = bReader.readLine();
    5. bReader.close();

Buffered File Out:

    1. String fileOut = “fileOut.txt”);
    2. FileWriter fWrite = new FileWriter(fileOut);
    3. BufferedWriter bWrite = new BufferedWriter(fWrite);
    4. bWrite.write(“Anything”, offset, length);
    5. bWrite.close();

Standard In (Usually a Keyboard):

    1.  InputStreamReader cin = new InputStreamReader(Sytem.in);
    2.  char c = (char) cin.read();

Standard Out (Console):

    1. System.out.print(“System.out is already setup”);

 

 

 

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

CS Review: Input/Output

There are a few basic types of input/output sources that are usually used.

Buffered File In:

    1. String file = “file.txt”;
    2. FileReader fReader = new FileReader(file);
    3. BufferedReader bReader= new BufferedReader(fReader);
    4. String s = bReader.readLine();
    5. bReader.close();

Buffered File Out:

    1. String fileOut = “fileOut.txt”);
    2. FileWriter fWrite = new FileWriter(fileOut);
    3. BufferedWriter bWrite = new BufferedWriter(fWrite);
    4. bWrite.write(“Anything”, offset, length);
    5. bWrite.close();

Standard In (Usually a Keyboard):

    1.  InputStreamReader cin = new InputStreamReader(Sytem.in);
    2.  char c = (char) cin.read();

Standard Out (Console):

    1. System.out.print(“System.out is already setup”);

Scanners:

  1. Scanner in = new Scanner(System.in);
  2. int i = in.nextInt();

 

 

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

Clean Coder ch.5: TDD

The author is very much in favor of Test Driven Development, but while I am not opposed to it, I do not feel that it is always necessary. TDD is excellent for more difficult program projects, especially those with a lot of closely working parts, but when you have a program that is made up of many simple pieces, TDD seems to slow me down. I end up writing tests eventually, but when I do write the tests later on, I have a full view of what my program is doing, making it easier to write needed test cases. Starting by creating tests is a great idea, and I do use it from time to time, but it is just one style, and each style has its strong moments and its weak points. As a final note I will say that I should use this more than I do, and that sometimes I do need to slow down.

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

Clean Coder ch.5: TDD

The author is very much in favor of Test Driven Development, but while I am not opposed to it, I do not feel that it is always necessary. TDD is excellent for more difficult program projects, especially those with a lot of closely working parts, but when you have a program that is made up of many simple pieces, TDD seems to slow me down. I end up writing tests eventually, but when I do write the tests later on, I have a full view of what my program is doing, making it easier to write needed test cases. Starting by creating tests is a great idea, and I do use it from time to time, but it is just one style, and each style has its strong moments and its weak points. As a final note I will say that I should use this more than I do, and that sometimes I do need to slow down.

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

Clean Coder ch.4:Coding

This chapter was full of excellent tips and many hard truths. I would love to believe I work better by listening to music, but it is not the case. Recently, I have stopped listening to music while doing work and I get things done much faster. The writer of Clean Coder knows that it is usually distracting as well, and advises others not to multi task as it either leads to distraction or what he calls “entering the zone”. He makes the point that entering the zone is not a good thing because while you may get more done when you are extremely concentrated, you may make bad decisions that will later cause you to go over that code again to make changes. This is a valid point, but for me personally, I seem to always be in either one of two states: concentrated or distracted. If I am focusing on something, every thing else is a blur. If you talk to me in this state, I probably will not hear you. And if I stop and go do something else, it takes a bit for me to concentrate again.

Some of the other points he made was the distractions of worrying, interruptions, and writers block. These are all real life situations that get in the way of our thinking, and we need to find our own ways of combating these inhibitors. Worrying causes us to always be thinking of our situation than what we need to work on right now. Interruptions can cause us to snap at others for breaking our concentration. And writers block is the inevitable situation we find our selves in from time to time that stunts our productivity. His solution was pair programming, and while this is a good thing to keep in mind, we can’t always work with someone else. Sometimes we do not have access to another person for insights.

Lastly, he also goes through the debugging process in detail, explaining why debugging is so important. Debugging is not a waste of time or something that just has to be done, it is a part of programming and is just as costly as the program itself. Debugging is what tells you the quality of your code. Without it, you are basically taking a test without finding out how you did on it. Lastly, he mentions how time allotment and scheduling is important as well, and how bad pacing can cause late submissions. Being late is what we strive not to do, but when it does happen, we need to alert others as soon as we realize our blunder.

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

Clean Coder ch.4:Coding

This chapter was full of excellent tips and many hard truths. I would love to believe I work better by listening to music, but it is not the case. Recently, I have stopped listening to music while doing work and I get things done much faster. The writer of Clean Coder knows that it is usually distracting as well, and advises others not to multi task as it either leads to distraction or what he calls “entering the zone”. He makes the point that entering the zone is not a good thing because while you may get more done when you are extremely concentrated, you may make bad decisions that will later cause you to go over that code again to make changes. This is a valid point, but for me personally, I seem to always be in either one of two states: concentrated or distracted. If I am focusing on something, every thing else is a blur. If you talk to me in this state, I probably will not hear you. And if I stop and go do something else, it takes a bit for me to concentrate again.

Some of the other points he made was the distractions of worrying, interruptions, and writers block. These are all real life situations that get in the way of our thinking, and we need to find our own ways of combating these inhibitors. Worrying causes us to always be thinking of our situation than what we need to work on right now. Interruptions can cause us to snap at others for breaking our concentration. And writers block is the inevitable situation we find our selves in from time to time that stunts our productivity. His solution was pair programming, and while this is a good thing to keep in mind, we can’t always work with someone else. Sometimes we do not have access to another person for insights.

Lastly, he also goes through the debugging process in detail, explaining why debugging is so important. Debugging is not a waste of time or something that just has to be done, it is a part of programming and is just as costly as the program itself. Debugging is what tells you the quality of your code. Without it, you are basically taking a test without finding out how you did on it. Lastly, he mentions how time allotment and scheduling is important as well, and how bad pacing can cause late submissions. Being late is what we strive not to do, but when it does happen, we need to alert others as soon as we realize our blunder.

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