Labels

Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Tuesday, July 24, 2012

My Favorite Programming Tools

As a programmer I am using almost every day a number of tools that help me achieve various programming tasks. I would like to share them here with the people interested and of course any feedback about other tools is greatly appreciated.

I use a number of utilities like:
  • Notepad++  - this is a very popular open source text editor for fast editing and file comparison, I find it extremely useful and I use it almost every day. It comes with a number of pluggable components and it has a good community.
    More information at: Wikipedia Notepad++.
  • Putty - I am using this utility mainly for remote access. PuTTY is a free and open source terminal emulator application which can act as a client for the SSH, Telnet, rlogin, and raw TCP computing protocols and as a serial console client.This is the place were one can find this tool: Download Putty. Here are some tips on setting up your Putty options. And here is a tool to wrap multiple Putty sessions in tabs: TTY Plus. 
  • WinSCP (Windows Secure CoPy) is a free and open source SFTP, SCP, and FTP client for Microsoft Windows. Its main function is secure file transfer between a local and a remote computer. Beyond this, WinSCP offers basic file manager and file synchronization functionality. For secure transfers, it uses Secure Shell (SSH) and supports the SCP protocol in addition to SFTP. This is the place to find this utility: Download WinSCP
  • VirtualBox (Oracle VM VirtualBox) is an x86 virtualization software package. I use this tool to create quick development testing environments. To obtain VirtualBox visit the VirtualBox website's download page.
  • soapUI - is an open source web service testing tool for service-oriented architectures (SOA). I use this tool for service testing during development. This tool can be found at: Download soapUI
  • SFK (Swiss File Knife - Windows cmd utility) - is a command line tool for daily tasks. Find and extract text in binary files, list dir tree sizes, filter and replace text, run an instant ftp or http server for easy file transfer, find duplicate files, join many text files into one, create and verify md5 checksum lists, run a command on all files, detab text, create hexdumps from files, trace contents of a tcp connection, find dependencies between files, print colored text to terminal, locate commands in the path, print last lines of a file, convert CR/LF, hex to binary, binary to source code, split and join large files, list the contents of all .zip, .jar, .tar, .gz, and .bz2 files. One can download this utility at: Download SFK
  • QuickPHP - Useful utility for quick PHP UI mockups. It is very easy to install and configure. One can download it from here: Download QuickPHP.
  • GIT - this is my favorite distributed revision control system; fast, simple to use and install.
  • Eclipse - free development environment. I use this application for complex projects.
  • JIRA - this is a great issue tracking system. 
  • Confluence - great collaboration and wiki software. I use this application for all purpose documentation.
  • TeamViewer - software used for remote control, desktop sharing, online meetings, web conferencing and file transfer between computers. This is a great tool. I use this tool for desktop sharing when I need to help members of my team.
  • Dropbox - is a file hosting service that offers cloud storage, file synchronization, and client software. This is a great tool, it is free for 2GB storage and I use it as a virtual USB. I move files between many computers and systems that I use.
I am going to improve this list as I come over other tools that I use every day and I find very good.


Posted by at No comments:
Labels:

Thursday, May 3, 2012

Billing Open Sources Review

I needed to find an open source billing system for one of the projects that I am working on. I've investigated a number of current open source projects.
I was interested in basic functionality like: invoices, orders, customers, estimates, orders, services, pricelists, payment, discounts, currencies etc. I wanted to find a reliable open source project to use and to contribute.

Criteria used to analyze the applications was: open source software evaluation
 
I've looked at SIWAPP, AgileBill, Amberdms Billing System, Freeside, CitrusDB, Bamboo Invoice, Simple Invoices.

SIWAPP is a new PHP project in beta stages and IE is not recommended.

AgileBill has no documentation, only one active developer.

Amberdms does not support all platforms, very little information.

Freeside is a Perl project and it has a bad UI.

CitrusDB is a PHP project maintained by one developer and the coding standards are a joke.

Bamboo Invoice is a PHP project in beta stages, has little documentation  and I could not find the source code.

Simple Invoices this is a PHP project, it does not contains all the functionality I was looking for.

Most of the projects are written in PHP. They are meteoric projects; started with enthusiasm, not very professional and lingering through years.

I could find only one that passed my criterias: JBilling.

JBilling looked very promising from my initial analysis. This project started in 2006, it has a mature well established codebase. It has documentation and coding standards. It is a web application Java based and uses standard Java frameworks. It has a number of developers and the code shows sustained activity.
It contains about 100K lines of Java and SQL code, which means that this is a medium size project. It has a fair amount of comments into the code.
It supports all major browsers and it is OS and database independent. Can run in most of the contemporary application servers that can run with JTA or local transactions, it requires a Message Queue implementation.

I've downloaded and installed the application as documented. The installation was very simple as it required JRE and the instructions were good. I was able to start checking this product functionality in less than 10 minutes.
The UI is very simple and intuitive; I was able to find very easy all the features that I was interested in. This was an unexpected well designed UI for an open source.

My next step was to obtain the latest code and to try to compile and deploy. One thing caught my attention when I was reading the development instructions: it requires Grails 1.3.4 (released sometimes in 2010). The latest Grails version is 2.0.3 released on 3rd April 2012. The latest minor version from version 1 is 1.3.8 released on 29 March 2012.
I was not able to compile using the instructions and the reasons were:
  • Could not find all the dependencies for Grails 1.3.4
  • Upper versions of Grails were not supported
  • The code has dependencies on JbillingAPI and JbillingAPIFactory which are supplied only with EE
Customer care functionality is only available for EE.
This is a Catch 22 situation: the application is open source but it has some crucial missing parts so you have to buy...

So much with the open sources billing systems...

Update May 2013:
JBilling was acquired by AppDirect see article. Since there was no code change.

My personal opinion is: there is no feasible open source billing system and one should check commercial billing systems with extensive API. Check my analysis regarding the commercial billing systems (it is coming soon...).
Posted by at 5 comments:
Labels:

Thursday, April 19, 2012

My Best Programming Resources Online

I have a number of online resources that I consult when I need to gain knowledge or I believe are useful, I have questions or I want latest programming news.
I use only free resources and tools that don't require registration.

Great search engines:

I will add more resources here as I find them.
Posted by at 1 comment:
Labels:

Thursday, March 22, 2012

Open Source Software Evaluation

Recently I had to evaluate a number of open source software to recommend the adoption of a solution suitable for the existing requirements.

During the evaluation I've extracted the following methodology which may be useful for future evaluations:
  • Community support - how much support is provided by the community
  • Access to the latest code - whether the up to date code is available to the community
  • Documentation - how extensive is the documentation if any
  • Coding Standards  - any well established open source software should have coding standards and guidelines for development.
  • Development team - it is important to determine the size of the development team and the number of contributors to determine the adoption 
  • User interface - how intuitive is the user interface to enable the adoption and eventually the success of the solution
  • Functionality - does it cover the requirements and level of sophistication (simple is better)
  • Security - how secure is the solution according to the current standards. In case of web application solution how much it covers the OWASP (Open Web Application Security Project) and WASC(Web Application Security Consortium) guidelines to cover all the latest security aspects and to be able to pass ISO certification if requiredImplementation programming language - to determine the skills required, security level, software robustness (strongly typed language are in general more robust) etc.
  • Technologies -  analyze used technologies to determine their quality
  • Contemporary methodologies and technologies - does the solution uses the latest methodologies and technologies.
  • Adoption - how many success stories from well known organizations
  • Build methodology - how good is the documentation and how easy is to perform a build
  • Debug -  how easy is to debug this software
  • Learning curve - how easy is to learn existing implementation
  • Scalability - how scalable is the solution
  • Testing coverage - how much testing coverage has the solution
  • Responsiveness - how performant is the solution using performance tools
  • Architecture - determine the architectural quality of the software, how many tiers has the application and how decoupled are various components
  • Open issues - determine the amount of open issues (critical and high priority) and how contemporary are the issues (to determine if there is real support for the software). It is important to determine if there is an issue tracking system.
  • Versions/Releases - how many versions per year and how many versions in the last year (to make sure the software is in an active state), latest stable release
  • Installation - analyze installation process to determine how easy is to install
  • Operating System -  platform independence
  • Browser compatibility - in case of web application whether or not all the popular browsers are supported
  • Licensing - this is a very important aspect in case this will be used as a commercial solution
  • Pricing - some of the open sources solutions offer services, software modules for a certain price in addition to the open source solution.
  • Maturity - how mature is the software, for how log has been released (first release date) 
  • API/SDK - does the software provide means to extend the existing functionality without touching the existing code. 
  • Forum - is there any forum for this software to address existing questions 
  • Roadmap - is there any roadmap for the software 
  • Version control system - which version control system is used  if any 
  • Software maintenance utilities - are there any utilities to simplify maintenance 
  • Visible problems - how many issues discovered during the software trial
  • Language -  determine the extent of language support if this is necessary
  • Code quality:
    • Error handling - level of sophistication, detail and how well is done
    • Comments - how extensive is the code commented if any
    • Class/function size
    • General Code Smoke Test - does the code build correctly? Execute as expected? Is it understandable?
    • Resource Leaks - is allocated memory freed? Are objects released more than once
    • Control Structures - are loop ending conditions accurate? No unintended infinite loops?
    • Performance - do recursive functions run within a reasonable amount of stack space? Is blocking system calls used?
    • Reinvents the Wheel -does the code recreate some function that exists in a library included in the code base (or perhaps something from a utility library)
  • Certification program - is there any certification program
  • Commercial manuals - whether or not there are commercial manuals available
  • Online help - whether or not it provides help online
  • Users conference - whether or not community organizes conferences for user
  • Reliance on non-open source software - determine if it requires to function with other software which is not open source (can be a database).
Posted by at No comments:
Labels:

Friday, March 9, 2012

Memory leaks in Java

I would like to discuss here a few points regarding memory management in Java.

As a C++ veteran, one of my favorite subjects is memory management provided for a programming language. One of the reasons why I've adopted Java is that its Runtime provides a state of art garbage collection mechanism.
Memory allocation in C++ was sometimes a burden, always prone to memory leaks and dangling pointers. Even when C++11 introduced better garbage collection through smart pointers, automatic garbage collection in Java becomes a superior concept and programming is achieved at a higher level. This new level means that you don't need to deal with memory management at all or so it seems.

Is it possible to leak memory in Java?

Well the answer here is YES for the following reasons:
  • Java as a garbage collected languages have difficulty to release scarce system resources (database handlers, graphic resources, file handlers etc.), as it is difficult to define (or determine) when or if a finalizer method might be called.    
  • Java uses manual memory management for scarce system resources; any object which manages graphic resources for example is expected to implement dispose method, which releases any such resources and marks the object as inactive. Usually developers are expected to invoke dispose manually as appropriate; to prevent "leaking" of scarce graphics resources.
  • If a program holds a reference to a heap chunk that is not used during the rest of its life, it is considered a memory leak because the memory could have been freed and reused. The garbage collector won't reclaim it due to the reference being held by the program. A Java program could run out of memory due to such leaks.
Let's try next to come up with some specific examples of memory leaks:
  • Not calling the finalize method (depending how Java implements finalizers) to release graphics resources.
  • A database connection which is never released
  • A file handler open and never closed
  • The application creates a long-running threads or thread pool.
  • The thread loads a class using ClassLoader.
  • Caches or reflective utilities some times hold a reference to ClassLoader or a variant of ClassLoader (like WebappClassLoader, ThreadContextClassLoader). When those references cannot be claimed memory leak happens.
  • The class allocates a large chunk of memory, stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the Class instance is enough), but it will make the leak work that much faster.
  • The thread clears all references to the custom class or the ClassLoader it was loaded from.
Posted by at 1 comment:
Labels:

Wednesday, February 29, 2012

Java Exceptions Best Practices

Exceptions were introduced into the Java language to separate the functional code from error-handling code. They allow for clear propagation path of a specific error.
There are two types of exceptions: checked exceptions - compiler enforced exceptions that are instances of the Exception class or one of its subclasses and the unchecked exceptions, runtime exceptions like RuntimeException and its subclasses and Error and its subclasses.
A compiler for the Java programming language checks, at compile time, that a program contains handlers for checked exceptions.

Many times in my carrier as a software developer I had to read, debug, review code from some other developers. Many times I've seen silenced exceptions like:


try {
    someFunction();   // may throw an exception 
} catch (Exception e) {                  
    // do nothing}

I believe this type of code is Evil. Something happens in the code and the developer decides that the best way to go is to do nothing. If this code influences other code there will be no way to know what really happened with the code. If the code does not influence other code it is still no way to know that some functionality was not executed. The least a programmer can do in such situation is to write some minimal information to the log file.
Imagine that you are not able to debug a code that runs in production environment, the only means to investigate a problem is the log files. Every time a checked exception is correctly handled your job will be easier to investigate potential issues.

I have next a number of advices to follow when dealing with exceptions:
  • NEVER SILENCE AN EXCEPTION like in my above example.
  • Only throw checked exceptions (not derived from RuntimeException), if the caller has a chance to handle it.

     class ApplicatioException extends Exception { // classic checked exception
        public ApplicationException (String str) {
            super (str);
        }
     }

     ...
     
     class  Application {
        public void doSomeAction () throws ApplicationException {
            ...
            if (bad) {
                throw new ApplicationException ();
            }
        } 

        public void someOtherAction () {
            try {
              this.doSomeAction();                            
            } catch (ApplicatioException ex) {
              logger.error("doSomeAction failed miserably!"); // log information
            }
        }
     }
     
  • Checked exceptions are an official part of the interface, therefore do not propagate checked exceptions from one abstraction layer to another, because usually this would break the lower abstraction. E.g. do not propagate SQLException to another layer, because SQLExceptions are an implementation detail, that may change in the future and such changes should not affect the interfaces and their callers.
     class DBUtil{
        public static void closeConnection
        (Connection conn){
        try{
            conn.close();
        } catch(SQLException ex){
            throw new DBUtilException(ex); // propagate exception to the next level
        }
     }
  •  Never throw NullPointerException or RuntimeException. Use either IllegalArgumentException, or NullArgumentEception (which is a subclass of IllegalArgumentException anyway). If there isn't a suitable subclass available for representing an exception, create your own.
     class DBUtil{
        public static void closeConnection
        (Connection conn){
           try{
              conn.close();
           } catch(SQLException ex){
               throw new RuntimeException(ex); // never throw an exception like this    
        }
     }
        
  • Only if it is not possible to return special result values cleanly, use checked exceptions to force the caller to decide the situation. The caller should deescalate the situation by catching and handling one or more checked exceptions, e.g. with special result values or by escalating with an unchecked exception, because the situation is an error, that can not be handled.
  • Exceptions that signal programming errors or system failures usually cannot be handled/repaired at runtime -> unchecked exception.
  • Do NOT throw an exception, if you only suppose the caller of your code could have a problem with a special result. Try to return a special result value instead e.g., null, and let the caller decide with a regular if-else-statement. If the caller really has a problem, HE WILL throw an exception on his own.
    class Example{
        public Result exampleAction (){
            Result result = null;
            ...                               // some result processing
            return result;                    // return the result in any form
            }
        }
        
        public boolean processResult () throw ResultException {
            Result result = exampleAction();

            if (result == null) {
                return new ResultException (); // caller has a problem here; unexpected result
            }
            else if (!isValid(result)) {
                return fail;                   // result failure
            }
             
            return success;
        }
     }

  • The intention of exception-handling is to separate real error-handling from the regular part of the code, so don't force the caller to mix it with unnecessary exceptions.
  • Only if your code really has a problem to continue e.g., when a parameter is invalid, feel free to throw an exception!
  •  Don't catch generic exceptions. Sometimes it is tempting to be lazy when catching exceptions and do something like this: 
    try {
    someIOFunction();        // throws IOException 
    someParsingFunction();   // throws ParsingException 
    someSecurityFunction();  // throws SecurityException  
} catch (Exception e) {      // catch all exceptions 
    handleError();           // with one generic handler!
}
    You should not do this. In almost all cases it is inappropriate to catch generic Exception or Throwable. Throwable includes Error exceptions as well. It is very dangerous. It means that Exceptions you never expected (including RuntimeExceptions like ClassCastException) end up getting caught in application-level error handling. It obscures the failure handling properties of your code. It means if someone adds a new type of Exception in the code you're calling, the compiler won't help you realize you need to handle that error differently. And in most cases you shouldn't be handling different types of exception the same way, anyway.
I believe proper exception handling is a good indicator that a programmer understands the programming language he/she uses and is able to do good job.

Posted by at 2 comments:
Labels:
Subscribe to: Posts (Atom)