Kevin's Blog

IT, Scala, Java, Web, Ubuntu

Tag: Software Development (page 2 of 2)

Eclipse – “Too many open files” Problem

If your OS is Linux and you are using Eclipse, you might possibly see the following error messages or similar after installing lots of plug-ins in Eclipse. In my case, it usually happened after installing TPTP (I’m using Ubuntu Linux 9.04 Jaunty Jackalope Desktop 64bit by the way).

Plug-in org.eclipse.jst.server.tomcat.core was unable to load class org.eclipse.jst.server.tomcat.core.internal.TomcatLaunchConfigurationDelegate.
 /eclipse_installed_path/eclipse/configuration/org.eclipse.osgi/.lazy.15 (Too many open files)


Problems occurred while trying to save the state of the workbench.
 Could not read master table.
 /your_workspace/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources (Too many open files)

or error in opening zip file

This is because there are too many files opened and these are more files than the number of open files allowed . So Eclipse cannot open more files and displays the errors above.

Let’s see the number of open files.

$ lsof | wc -l 


$ lsof | wc -l 

In my case, it was 8965.

What about the number of files Eclipse opens. To see it, use

$ lsof | grep eclipse | wc -l 

In my case,

$ lsof | grep eclipse | wc -l 

2094 files are opened.

Now check the limitation of open files

$ ulimit -a 
core file size          (blocks, -c) #
data seg size           (kbytes, -d) #
scheduling priority             (-e) #
file size               (blocks, -f) #
pending signals                 (-i) #
max locked memory       (kbytes, -l) #
max memory size         (kbytes, -m) #
open files                      (-n) 1024
pipe size            (512 bytes, -p) #
POSIX message queues     (bytes, -q) #
real-time priority              (-r) #
stack size              (kbytes, -s) #
cpu time               (seconds, -t) #
max user processes              (-u) #
virtual memory          (kbytes, -v) #
file locks                      (-x) #

or just use

$ ulimit -n 

To change it, open the file /etc/security/limits.conf and put a greater number than 1024 depending on the number of open files you checked with lsof | wc -l just before.
For example,
Open the file

$ gksudo gedit /etc/security/limits.conf 
add these lines
*                soft    nofile          9216
*                hard    nofile          9216

I just chose some big number that is 9216 (9 * 1024) as it’s greater than 8965

Log out and in then check with ulimit. It should show like this.

$ ulimit -n 

You may try this

$ ulimit -n 9216 

yet I don’t believe it changes the limit for open files permanently. So you’d better modify /etc/security/limits.conf file.

If it is still not changed. Restart the computer and check again. If it still doesn’t show the changed value, open /etc/pam.d/common-session file and add session required

Open the file to edit

$ gksudo gedit /etc/pam.d/common-session 

Add the following line

session required

Log out and in. Now it should work!

$ ulimit -n 

Communication with Users

I have developed Team Contribution Tracking (TeCTra) system for UTS. It is an Ajax web application the back-end of which is built using Java. A few months ago, a new function to get feedback from users was added to TeCTra.

TeCTra User Feedback Function

TeCTra User Feedback Function

About a half month ago, I’ve got a feedback email from a user. This is sent through the function above.

TeCTra User Feedback Email

TeCTra User Feedback Email

TeCTra User Feedback Email

TeCTra User Feedback Email

This feedback is about the usability of TeCTra. What he/she points out is that the button to create a new task in the time sheet tab is positioned too close to the remove button so users may click the remove button by mistake when they want to click the add task button.
As the image below shows, the last remove button is too close to the new task button. So as mentioned in the feedback, users might click the remove button by mistake.

The last remove task button is too close to the new task button.

The last remove task button is too close to the new task button.

We, the development team of the TeCTra, had a discussion about this and other issues then decided to move the buttons to the right-hand side. Since the front-end is developed by my friend, Sverre, he changed the positions of the remove buttons. My boss, Dr. Richard Raban, also brought other issues so I and my friend took care of all of these and deployed a new version of TeCTra.

Now the remove buttons are all right-justified so users will not click it by chance when they want to click the new task button.

Now the remove buttons are all right-justified so users will not click it by chance when they want to click the new task button.

It is good to have an issue tracking system so that the users of software can easily report bugs they found or require new functions they want. This might be good enough yet it is even better if the application itself has issue tracking and feedback functions as I’ve learned from the user feedback function. Thus I am thinking to implement feedback and bug reporting functions which directly add a new ticket to an issue tracking system from my next application development. So it does not only send a feedback email to the developer but also add an issue to the issue tracking system.

eXtreme Programming (XP)

Originally Posted in another blog of mine on the 3rd of August in 2007.

This post is about my knowledge and understanding of eXtreme Programming (XP) acquired from my study at UTS. In august, 2008, I took the subject named eXtreme Programming as I would like to become a better programmer and developer.

XP is the one most prominent methodology of Agile methodologies. It is, according to Avison and Fitzgerald (2006), used to support quicker development for small and medium size system and application development. They also affirm that XP is more rapid in software development than step-by-step methodology such as waterfall model. In XP, there are often customer meetings to get user requirements and to apply immediately these into the system development, thus it can guarantee the certain level of quality.

There are 4 values of XP which are:

  1. Simplicity
  2. Communication
  3. Feedback
  4. Courage

and 12 practices which are:

  1. The Planning Game
  2. On-site Customer
  3. Small Releases
  4. Simple Design
  5. Pair Programming
  6. Testing – Test First
  7. Refactoring
  8. Collective Ownership
  9. Coding Standards
  10. Continuous Integration
  11. 40 Hour Week
  12. Metaphor

The followings are what I’ve understood from the lecture.

■ XP Values

  • Simplicity: choosing simple design, and small release can produce the system quickly with satisfying the customers’ requirements for the current iteration of the project.

  • Communication: good communication through the pair programming and frequent customer meetings can deliver a good result.

  • Feedback: From testing, customer meetings & stories, pair programming and small timeboxes to repeat project process, enough feedback can be gained to improve the quality of the system.

  • Courage: When it is certain that the changes made by a programmer do not bring about some unexpected problems, the programmer can be confident to refactor and redesign the system to make it better (Testing can be the key of this).

■ XP Practices

  • The Planning Game: At the beginning of the project, customers write what functionalities they want the system to have on the ‘story cards’ then developers and programmers estimate the time required to make each function, and write it down on each card. After that, the customers choose the cards which have what they want the system to have in one week. Those are probably the most important or essential functions in customers opinion.

  • On-site Customer: The customers are sitting next to the developers, thus the developers can easily ask what the customers really want. As the customers do usually not know what they want at the beginning of the project, but they will know as the project is progressed, their requirements can be changed frequently. If they are near the developers, the developers can easily make conversation with them so it can increase the quality of the system (software). Good communication => High quality software.

  • Small Releases: The software is often released rather than the one final software is released at the end of project. Thus, the customers can know what the software will look like and if it fulfills what they want. The developers can also get the feedback from the customers which can help the developers to make the system as what it should be. It can bring about another benefit. As each time releases working version of software, the developers and customers can, somehow, have the software with the certain functionalities when the project is cancelled.

  • Simple Design: Design the system as simple as possible but works. It can prevent from over-engineering. This can also deliver business value quickly so the customers can get what they want early. In this case, both customers and developers can have more time and money to reconsider what are more required. The developers can always refactor the existing code and simple design can help them to do so, for “simple design” does NOT mean “bed design”. It might mean simple to maintain, simple to understand and simple to redesign.

  • Pair Programming: Two programmers share one computer to programme. When they work together, one think tactically about the part of the programme which he/she is about to code whereas the other one thinks strategically about how that part fits into the whole programme. With pair programming, The one can learn from the other one who is more experienced, and vice versa. This practice can cause better communication and feedback, and those can heighten the quality of the software. As both know about the programme they are working on, it can increase truck factor which means reducing the risk of the project failure.

  • Testing – Test First: The tests are created first before starting coding. First with all those tests, the programmers can know what functions they need to make. They can also know whether their programme fulfills the requirements or not. They can code the programme pass each test, and passing all the tests means completion of the software. It can also help to check if any changes, made after the programme is passed the tests, cause any problems or unforeseen results.

  • Refactoring: Refactoring is changing the existing code to improve its design and readability. It can make simple design possible, and can help the programmers easily change the programme as customers require. It is easy to refactor with tests. After refactoring, if the programme is still passed all the tests, it may mean the changes did not break any existing code. (The recommended book to read for refactoring is “Refactoring, Improving the Design of Existing Code” written by Martin Fowler and published by Addison Wesley. ISBN: 9780201485677, $79.95).

  • Collective Ownership: There is no owner of any particular code so anyone can change any code. It can improve productivity and reduce the risk of the truck factor. Tests and coding standard make it possible.

  • Coding Standards: Every programmer follows one agreed coding standard, including indentation, capitalisation, names and so on, can improve speed and help the programmers communicate with each other. They also can focus on the real issues rather than focus on reformatting others’ code to make these understandable.

  • Continuous Integration: Team members integrate and test frequently what they made rather than waiting all of them finish the parts assigned and put them all together to test. If they wait until all the members finish coding, they will face many problems to make the programmes work.

  • 40 Hour Week: No overtime! Overtime rather decreases than increases the productivity. I’d like to quote the words from Jason Statham, performing in the movie ‘Transporter’, which is my favourite.

    “I can’t think straight when I’m tired. After a good night’s sleep…I always see things better.”

  • Metaphor: Using a simple metaphor to describe what the system is like can help to understand the programme and communicate with it. (Metaphor is probably the least popular XP practice)

※ References

Avison, D., Fitzgerald, G., 2006, Information system development – methodologies, techniques and tools, 4th edn, McGraw – Hill Education, Berkshire

Wells, D. 2001, Extreme Programming: A gentle introduction. viewed 03 August 2007, <>

Newer posts

© 2019 Kevin's Blog

Theme by Anders NorenUp ↑

%d bloggers like this: