National Competency Standard for Webmaster and Enterprise Architect

I have just got back from a two-day workshop at the National Computer Center. The purpose of the workshop was to refine the gathered inputs from around the country, both from the public and the private sector, and the academe, into a more solid National Competency Standard for Webmaster and Enterprise Architect. Hopefully, once these standards get finalized, it will serve as the guideline, for the curriculum of all the universities and colleges offering IT education and all the public and private agencies/companies’ hiring standards for webmaster and enterprise architect, here in the Philippines. Still, the implementation of these standards will remain as a challenge.

We hope to have more competent IT specialists here in our country.

Posted in Software Development | Tagged , , , , , , , , , , , , , | 2 Comments

We are Damn Blind? Aren’t We?

earthquakes in Indonesia, Haiti and Chile, tsunamis in Hawaii and Mexico, floods and landslides in The Philippines, global warming all over the world..the world is now falling apart..it is not that we don’t know or we are not aware of it..but it is that we are just too proud to admit that nothing is permanent in this world and we are too busy doing our so called “chores”..think about it…act upon it..until we can

Posted in Environment | Tagged , , , , , , , , , , , | Leave a comment

The Difficulty of Estimating Work With So Little Information About Requirements

The morning the other day I received a chat from my college batch mate. She was asking me about how, in our office, we come up with work estimates in the projects that we do. Then she told me that she is having difficulties in coming up with work estimates for their upcoming major project because their client has hardly specified a concrete set of system requirements. Well, I told her that that really is a big problem on their part and on my head, i was thinking from a software quality assurance point of view, there will be no solid way of verifying and validating the system because there is no established set of expectations from the client.

I guess we will all agree that this problem is really common to most software development firms. A very few clients really realize the fact that they are the main stakeholders of the system to be developed, hence, they lack the enthusiasm to roll their sleeves up and think hard of the very specific details of system that they want to have. Later after the project has already been done, the budget, time and effort of the developers already spent, countless sleepless nights for the developers catching those pesky bugs, infrastructure already laid down, will they then say bluntly to the software development firm that what they have now is not what they were expecting to have. Then additional budget will be cashed out for the revisions of unexpected modules and to the dismay of the developers, deletion of some unwanted features (there goes my sleepless nights..sigh T_T).

to be continued…

Posted in Software Development | Tagged , , , , , , , , , , , | 2 Comments

Beware of Uninitialized Primitive boolean Instance Variables

In Java, uninitialized primitive boolean instance variables, or member variables, have the value of false by default. This would seem harmless until we fall into the trap of always-resulting-to-false-condition-and-i-dont-know-goddam-why bug..whew! that was long T_T

Imagine you have this quite big source code with, let’s say, 2000 lines of code and in the top part of your code you have this uninitialized primitive boolean instance variable. Now somewhere along line 1,700ish of your code you have a logic which tries to do something based from the value of your boolean instance variable (which you forgot to update or explicitly assign a value to). It could be something like this:

1.      public class QuiteBigClass {
2.                private boolean bool;  //your uninitialized primitive boolean instance variable with the default value of false
…               //some reeeeally long code goes here
1700                   if ( bool ) {
1701                             //some important code goes here..like committing to the database
1702                   } else {
1703                             //some other code goes here…
1704                   }
…               //some reeeeally long code goes here..again
2000    }

Now, given that we forgot to explicitly assign a value to bool, the if-else statement at line 1700-1704 will always result to executing the else part of the source code because the value of bool is false. It will be easy for us to trace the source of the bug if we only have a couple of few lines but given that we have quite a big source code, it will somehow be difficult for us to trace back the origin of the problem, which is an uninitialized primitive instance variable.

One solution to this problem is to always always and always initialize your instance variables to something, in this case, to either true of false. Also, never never and never forget updating the value of your instance variables somewhere in your source code, that way we know that we are not trying to evaluate something based from a variables default value, but from previous logical conditions.

That’s all for now. Thank you.

Continually learning,

Jep

Posted in Software Development | Tagged , , , , , , , | 6 Comments

int as Default Data Type for Literal Integers

Every literal integer in Java is implicitly of type int by default. Also, any operation done with literal integer operands results to int by default. So the following code will be fine and will definitely compile:

byte b = 5; //byte is made up of 8 bits and int with 32 bits

because the compiler implicitly puts a casting to it like this:

byte b = (byte) 5;

But this won’t compile:

byte a = 5;
byte b = 2;
byte c = a + b;

because any operation done with literal integer operands always have the result of type int by default and the compiler thinks about loss of precision without explicit casting. So to make the above code compile, we put an explicit cast like this:

byte a = 5;
byte b = 2;
byte c = (byte) a + b;

which is like telling the compiler that “Don’t worry, I know what I am doing and am aware about the possible loss of precision thing.”. 😀

Posted in Software Development | Tagged , , , , , , , | Leave a comment

The New Puma Phone

Wooow!! Sweeet!! I found about this phone at Mashable.com and all I can say is “I waaant it!!” Sport + Technology (Just like Apple + Nike)..cooolness 😀

Posted in Random Stuff | Leave a comment

Ad Hoc Functional Testing

I am hoping that we could start doing our ad hoc functional testing this coming week..we are now 2 days delayed..sigh T_T

Posted in Software Development | Tagged , , , , | Leave a comment

Puma Phone: Great For Running in the Sun

Puma Phone: Great For Running in the Sun

Posted using ShareThis

Posted in Random Stuff | Leave a comment

Encapsulation in Object-Oriented Programming

Two of the main features of the Object-Oriented Programming (OOP) paradigm is flexibility and maintainability. It is so desirable for one’s source code to be flexible in spite of changes in its internal implementations. Programmers don’t have to worry about their codes getting broken due to changes in the implementation of the Application Programming Interfaces (API) that they are using. All they have to know is that public methods of a given API behave the way they know it should regardless of its implementation details. Through this sense of flexibility in one’s code, users of such API are guaranteed that their own code will behave accordingly for a very long time. This advantage is offered by OOP through encapsulation. Encapsulation hides the implementation details of an API to accomodate maintainability and flexibility in its use. It serves as a protection for a class’s attributes by forcing client users of the class to access its protected attributes through publicly accessible methods or behaviors.
An example implementation of encapsulation in class would be the following (using the Java programming language):

public class Person {
private String name;
private String age;
public void setName(String name){
this.name = name;
}
public String getName(){
return this.name;
}
public void setAge(int age){
this.age = age;
}
public int getAge(){
return this.age;
}
}

Notice that class Person’s attributes are declared as private to protect them from being accessed directly outside Person. Instead, they are accessed through what we call setters (setName,setAge) and getters (getName, getAge). Clients of this class will have to use setters to set the value of its attributes and getters to determine the value of its attributes. By doing so, we will not be able to see others codes accessing Person’s name and age as follows:

public class Tester {
void testPerson(){
Person person = new Person();
person.name = "Juan dela Cruz";
person.age = 20;
}
}

Instead, Tester will class will use Person class as follows:

public class Tester {
void testPerson(){
Person person = new Person();
person.setName"Juan dela Cruz");
person.setAge(20);
}
}

Also, since Tester class accesses Person’s age through Person’s setAgesetter, we could be sure that Person’s age will not have 0 or any negative value by adding a checker into Person’s setAge method like the following:

//preceeding code removed
public void setAge(int age) throws IllegalAgeValueException{
if (age > 0) {
this.age = age;
} else {
throw new IllegalAgeValueException(); //in whichIllegalAgeValueException is a //custom exception
}
}

Encapsulation in OOP leverages an API’s maintainability and flexibility if used properly. Of course it doesn’t mean that since OOP offers encapsulation the programmer does not have to do anything in order to take advantage of such feature. In order to do so, one has to write his code in an encapsulated manner. :]

Continually learning,
Jep

Posted in Software Development | Leave a comment

Class Immutability

“Classes should be immutable unless there’s a very good reason to
make them mutable….If a class cannot be made immutable, limit its mutability as much as possible.”

– Josh Bloch

I never thought of class immutability and its importance until I read Josh Bloch’s statement quoted on a site about Java practices. There must be something about it that Bloch would quote such a tough statement. And it’s true! A programmer must defend his class’s instance variables from being changed from outside itself (except for instantiating the class, in which case you’ll use a constructor or a static factory), unless there is a very good reason for it. Yeah, that is coolness to the uttermost level. Another point learned. :]

Continually learning,
Jep

Posted in Software Development | Leave a comment