The Joel Test

Posted: March 13, 2011 | Author: | Filed under: development | Tags: , | Leave a comment »

by Joel Spolsky, source http://www.joelonsoftware.com/articles/fog0000000043.html

12 steps for better code:

Joel Spolsky speaking with demonstration atten...

Image via Wikipedia

 

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

 

Enhanced by Zemanta

Never trust a programmer who says he knows C++

Posted: September 30, 2010 | Author: | Filed under: development | Leave a comment »

From http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/

I’ve been in an interviewing mindset for awhile and I’ve come to realize something important about C++ in particular. C++ is a “two peak” language. That is to say C++ is the only language I know of where two very different sets of programmers consider themselves well versed in the language. Let me show you in fake graph form:

Programmers (especially those coming from C) can very quickly get up to speed in C++ and feel quite proficient. These programmers will tell you that they know C++. They are lying. As a programmer continues in C++, he goes through this valley of frustration where he fully comes to terms with the full complexity of the language. The good news is that it’s really easy to tell the difference between C++ programmers pre- and post- valley (in an interview, in this case). Just mention that C++ is an extremely large and complex language, and the post-valley people will give you 127 different tiny frustrations they have with the language. The pre-valley people will say “Yea, I guess. I mean, it’s just C with classes.”.

Hurl it!

Posted: September 23, 2010 | Author: | Filed under: development, WedDev | Tags: , | Leave a comment »

Hurl is a service located at http://hurl.it that helps debug your APIs. Make HTTP requests, very cool.

Applying default namespace in gsoap with SOAP_XML_DEFAULTNS

Posted: September 21, 2010 | Author: | Filed under: development | Tags: , , , | 3 Comments »

This article tries to explain the use of default namespace and shows how to implement a process that controls this behavior using the gsoap framework and the appropriate output flag.

Namespaces in XML is a method that breaks the XSD schema in name partitions. It is a method to avoid the element name conflicts.  In order to use namespaces in SOAP/XML we need to define a prefix. The namespace prefix separates a table that belongs in the HTML grammar with a table that belongs in the kitchen grammar.  Therefore we have two tables: the <html:table> and the <kitchen:table>.  The namespace prefix is defined by the xmlns attribute. For example xmlns:html=http://a.random.and.unique.URI”.  This leads to an XML file like the following


<root xmlns:html="http://a.random.and.unique.URI”>
<html:section1>
<html:newsection>somevalie</html:newsection>
</html:section1>
<html:newtype>10</html:newtype>
<html:table>
<html:tr>
<html:td>tabledata1</html:td>
<html:td>tabledata1</html:td>
</html:tr>
</root>

Every element inside the XML file is prefixed with the ‘html’ and this namespace is defined somewhere in the root element. Imagine now this XML file with more than one namespace.


<root xmlns:html=http://a.random.and.unique.URI” xmlns:kitchen=”new.uri.com/somewhere">
 <html:section1>
 <html:newsection>somevalie</html:newsection>
 </html:section1>
 <html:newtype>10</html:newtype>
 <html:table>
 <html:tr>
 <html:td>tabledata1</html:td>
 <html:td>tabledata1</html:td>
 </html:tr>
 <kitchen:table>food_here</kitchen:table>
</root>

Our XML document now contains entries from two namespaces but it is very easy to choose the correct value by reading the prefixes. If you are looking for food, you must search somewhere in the kitchen.

Now imagine that you are not mixing the HTML with food. You need the first XML file. Looking at that envelope it is pretty clear that the word “html’ dominates the file. It is everywhere. Time for some economy then.

Defining a default namespace for an element saves us from using prefixes in all the child elements. It has the following syntax:
xmlns=”http://a.random.and.unique.URI”


<root xmlns:=”http://a.random.and.unique.URI”>
 <section1>
 <newsection>somevalie</newsection>
 <section1>
 <newtype>10<newtype>
 <table>
 <tr>
 <td>tabledata1<td>
 <td>tabledata1<td>
 <tr></table>
</root>

Default namespace means that every element that is nested in the <root></root> section and is not prefixed belongs to that namespace. This policy makes the document more clear and it saves us from enough traffic between the two peers. In this tutorial we will show with code how to use gsoap in order to produce SOAP envelopes with the default namespace in the result.

First create the header file.


//gsoap ns service name:        swap
//gsoap ns service style:        literal
//gsoap ns service encoding:        document
//gsoap ns service namespace:        http://cateof.wordpress.com
//gsoap ns service location:        http://cateof.wordpress.com:42
//gsoap ns schema namespace:        urn:swap
//gsoap <ns> schema elementForm:     qualified

struct ns__inside {
int x1;
int y1;
};

struct ns__outside {
int x2;
int y2;
};

int ns__swap(struct ns__inside request, struct ns__outside *result);

Second create the source code:


#include "soapH.h"
#include "swap.nsmap"
#include <stdlib.h>
int main(int argc, char **argv)
{ SOAP_SOCKET m, s; /* master and slave sockets */
 struct soap soap;
 soap_init(&soap);
 if( argc>1 && atoi(argv[1])==1)
 soap_omode(&soap, SOAP_XML_DEFAULTNS);
 m = soap_bind(&soap, NULL, 4242, 100);
 if (!soap_valid_socket(m))
 {
 soap_print_fault(&soap, stderr);
 exit(-1);
 }
 fprintf(stderr, "Socket connection successful: master socket = %d\n", m);
 for ( ; ; )
 {
 s = soap_accept(&soap);
 fprintf(stderr, "Socket connection successful: slave socket = %d\n", s);
 if (!soap_valid_socket(s))
 { soap_print_fault(&soap, stderr);
 exit(-1);
 }
 soap_serve(&soap);
 soap_end(&soap);
 }
 return 0;
}

int ns__swap(struct soap *soap, struct ns__inside req, struct ns__outside *res)

 printf("in request x1=%d and y1=%d\n", req.x1, req.y1);
 res->x2 = req.y1;
 res->y2 = req.x1;

 return SOAP_OK;

}

You need to follow the usual gsoap steps to create a process that accepts connections at port 4242, in detail

  1. soapcpp2 the_header_file
  2. g++ swap.cpp soapServer.cpp soapC.spp -o testServer -lgsoap++

Now depending on the arguments passed in the executable you can see two different result SOAP envelopes. If you run the executable with two command line arguments, and the second is 1, the SOAP_XML_DEFAULTNS option will be enabled and the output will be like that


<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Body SOAP-ENV:encodingStyle="document">
<outside xmlns="urn:swap">
 <x2>0</x2>
 <y2>0</y2>
</outside>
</Body>
</Envelope>

On the other hand if you don’t apply this flag in the omode the produced XML looks like the following


<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="urn:swap" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAP-ENV:Body SOAP-ENV:encodingStyle="document">
 <ns:outside>
 <x2>0</x2>
 <y2>0</y2>
 </ns:outside>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

In general it is a good practise to use default namespace in XML output. Looks more clear and send less traffic. In order to use this feature with gsoap, you need one of the latest versions.

New hobby. DIY electronics with Arduino

Posted: September 3, 2010 | Author: | Filed under: development, DIY, ideas, multimedia | Tags: , , , | 1 Comment »

Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software.

It’s intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.

This is the official Icon introduced for the l...
Image via Wikipedia

Arduino can sense the environment by receiving input from a variety of sensors and can affect its surroundings by controlling lights, motors, and other actuators. The microcontroller on the board is programmed using the Arduino programming language (based on Wiring) and the Arduino development environment (based on Processing). Arduino projects can be stand-alone or they can communicate with software on running on a computer (e.g. Flash, Processing, MaxMSP).

The boards can be built by hand or purchased preassembled; the software can be downloaded for free. The hardware reference designs (CAD files) are available under an open-source license, you are free to adapt them to your needs.

Arduino received an Honorary Mention in the Digital Communities section of the 2006 Ars Electronica Prix. The Arduino team is: Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, and David Mellis. Credits

Related articles by Zemanta
Enhanced by Zemanta

Almost a masterpiece. The pragmatic programmer in 70×2 lines

Posted: September 3, 2010 | Author: | Filed under: development | Tags: , , | Leave a comment »

Some documents are so inspirational. Almost perfect. From codinghorror.com

Copied from http://www.codinghorror.com/blog/files/Pragmatic%20Quick%20Reference.htm

  1. Care About Your Craft
    Why spend your life developing software unless you care about doing it well?
  2. Think! About Your Work
    Turn off the autopilot and take control. Constantly critique and appraise your work.
  3. Provide Options, Don’t Make Lame Excuses
    Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
  4. Don’t Live with Broken Windows
    Fix bad designs, wrong decisions, and poor code when you see them.
  5. Be a Catalyst for Change
    You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
  6. Remember the Big Picture
    Don’t get so engrossed in the details that you forget to check what’s happening around you.
  7. Make Quality a Requirements Issue
    Involve your users in determining the project’s real quality requirements.
  8. Invest Regularly in Your Knowledge Portfolio
    Make learning a habit.
  9. Critically Analyze What You Read and Hear
    Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
  10. It’s Both What You Say and the Way You Say It
    There’s no point in having great ideas if you don’t communicate them effectively.
  11. DRY–Don’t Repeat Yourself
    Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
  12. Make It Easy to Reuse
    If it’s easy to reuse, people will. Create an environment that supports reuse.
  13. Eliminate Effects Between Unrelated Things
    Design components that are self-contained. independent, and have a single, well-defined purpose.
  14. There Are No Final Decisions
    No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.
  15. Use Tracer Bullets to Find the Target
    Tracer bullets let you home in on your target by trying things and seeing how close they land.
  16. Prototype to Learn
    Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
  17. Program Close to the Problem Domain
    Design and code in your user’s language.
  18. Estimate to Avoid Surprises
    Estimate before you start. You’ll spot potential problems up front.
  19. Iterate the Schedule with the Code
    Use experience you gain as you implement to refine the project time scales.
  20. Keep Knowledge in Plain Text
    Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.
  21. Use the Power of Command Shells
    Use the shell when graphical user interfaces don’t cut it.
  22. Use a Single Editor Well
    The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
  23. Always Use Source Code Control
    Source code control is a time machine for your work—you can go back.
  24. Fix the Problem, Not the Blame
    It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.
  25. Don’t Panic When Debugging
    Take a deep breath and THINK! about what could be causing the bug.
  26. “select” Isn’t Broken.
    It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.
  27. Don’t Assume It—Prove It
    Prove your assumptions in the actual environment– with real data and boundary conditions.
  28. Learn a Text Manipulation Language.
    You spend a large part of each day working with text. Why not have the computer do some of it for you?
  29. Write Code That Writes Code
    Code generators increase your productivity and help avoid duplication.
  30. You Can’t Write Perfect Software
    Software can’t be perfect. Protect your code and users from the inevitable errors.
  31. Design with Contracts
    Use contracts to document and verify that code does no more and no less than it claims to do.
  32. Crash Early
    A dead program normally does a lot less damage than a crippled one.
  33. Use Assertions to Prevent the Impossible
    Assertions validate your assumptions. Use them to protect your code from an uncertain world.
  34. Use Exceptions for Exceptional Problems
    Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
  35. Finish What You Start
    Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
  36. Minimize Coupling Between Modules
    Avoid coupling by writing “shy” code and applying the Law of Demeter.
  37. Configure, Don’t Integrate
    Implement technology choices for an application as configuration options, not through integration or engineering.
  38. Put Abstractions in Code, Details in Metadata
    Program for the general case, and put the specifics outside the compiled code base.
  39. Analyze Workflow to Improve Concurrency
    Exploit concurrency in your user’s workflow.
  40. Design Using Services
    Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.
  41. Always Design for Concurrency
    Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.
  42. Separate Views from Models
    Gain flexibility at low cost by designing your application in terms of models and views.
  43. Use Blackboards to Coordinate Workflow
    Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
  44. Don’t Program by Coincidence
    Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
  45. Estimate the Order of Your Algorithms
    Get a feel for how long things are likely to take before you write code.
  46. Test Your Estimates
    Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.
  47. Refactor Early, Refactor Often
    Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
  48. Design to Test
    Start thinking about testing before you write a line of code.
  49. Test Your Software, or Your Users Will
    Test ruthlessly. Don’t make your users find bugs for you.
  50. Don’t Use Wizard Code You Don’t Understand
    Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
  51. Don’t Gather Requirements–Dig for Them
    Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
  52. Workwith a User to Think Like a User
    It’s the best way to gain insight into how the system will really be used.
  53. Abstractions Live Longer than Details
    Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
  54. Use a Project Glossary
    Create and maintain a single source of all the specific terms and vocabulary for a project.
  55. Don’t Think Outside the Box–Find the Box
    When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
  56. Start When You’re Ready.
    You’ve been building experience all your life. Don’t ignore niggling doubts.
  57. Some Things Are Better Done than Described
    Don’t fall into the specification spiral—at some point you need to start coding.
  58. Don’t Be a Slave to Formal Methods.
    Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.
  59. Costly Tools Don’t Produce Better Designs
    Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
  60. Organize Teams Around Functionality
    Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.
  61. Don’t Use Manual Procedures
    A shell script or batch file will execute the same instructions, in the same order, time after time.
  62. Test Early. Test Often. Test Automatically
    Tests that run with every build are much more effective than test plans that sit on a shelf.
  63. Coding Ain’t Done ‘Til All the Tests Run
    ‘Nuff said.
  64. Use Saboteurs to Test Your Testing
    Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
  65. Test State Coverage, Not Code Coverage
    Identify and test significant program states. Just testing lines of code isn’t enough.
  66. Find Bugs Once
    Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
  67. English is Just a Programming Language
    Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
  68. Build Documentation In, Don’t Bolt It On
    Documentation created separately from code is less likely to be correct and up to date.
  69. Gently Exceed Your Users’ Expectations
    Come to understand your users’ expectations, then deliver just that little bit more.
  70. Sign Your Work
    Craftsmen of an earlier age were proud to sign their work. You should be, too.
Enhanced by Zemanta

Java 4-ever

Posted: June 25, 2010 | Author: | Filed under: development | Tags: | 1 Comment »

as seen on http://jz10.java.no/java-4-ever-trailer.html. A masterpiece.

Installing bugzilla at OpenSUSE

Posted: April 18, 2010 | Author: | Filed under: development, Προγραμματισμος | Tags: , , | 3 Comments »

Bugzilla is a Web-based general-purpose bugtracker and testing tool originally developed and used by the Mozilla project, and licensed under the Mozilla Public License. Released as open source software by Netscape Communications in 1998, it has been adopted by a variety of organizations for use as a defect tracker for both free and open source software and proprietary products.  In this tutorial we will show how to install bugzilla at your linux box. My Linux version is OpenSUSE 11.0. In order to start we need to grab the latest GA version from the bugzilla official web site. Put your pointer at http://www.bugzilla.org/download/ and grab the latest tar.gz, store it somewhere on your local hard drive. We need several things preinstalled in our Linux box, but the first and most important is apache2 web server. Most of todays linux systems come with Apache installed. For OpenSUSE the default htdocs storage is under /srv/www.

Step 1. tar xzvf bugzilla-3.6.tar.gz
Step 2. cp -r bugzilla-3.6 /srv/www/htdocs/
Step 3. cd /srv/www/htdocs/
Step 4. mv bugzilla-3.6/ bugzilla
Step 5. chgrp www /srv/www/htdocs/bugzilla
Step 6. chmod g+x /srv/www/htdocs/bugzilla

In steps 1-6 we untar the bugzilla archive in our local drive. We copy the directory under our web server directory and we give rights to our ‘www’ group.

Some important things that we need to check before installing.

Step 7. Check to see if perl is installed in your system. The command perl -v will show the version of Perl, if any. If you don’t have Perl, follow a tutorial on how to get and install it in Linux.

Step 8. Setup your MySQL database in order to accomodate the bugs database. If you are not familiar with MySQL and it’s installation procedure and the first step to fine tune it please visit a previous post at this blog that explains this things in detail. Go to http://cateof.wordpress.com/2010/04/18/opensuse-and-mysql-the-first-steps/ for further details.

Step 9. Once you are OK with MySQL (bugzilla works with Postgres and Oracle as well) create a database user in order to access the bugs database. bugzilla creates a database called ‘bugs’ and it needs a user to access it. You can do it by using the root mysql user, however this is not too clever. Follow the tutorial I mentioned on Step 8 and create a user called ‘netuser’ that has access to everything in your databases, therefore the netuser will have permissions to change everything in the bugs DB.

Step 10: change your directory to /srv/www/htdocs/bugzilla and execute ./checksetup.pl –check-modules.  This is the step that you will spend some time. Every PERL module checks for prerequisites and requires additional software to be installed. After the first parsing of this script you will be notified for the missing dependencies.  In order to finish soon with this obstacle type the perl install-module.pl –all, in order the script to connect to the Internet and grab the additional modules from the PERL repo.

Step 11: Run ./checksetup.pl. Now the script will respond with a message that every module is OK, however you need to change some of your paramets in apache and bugzilla.

Step 12: Create a backup of localconfig file. Type cp localconfig localconfig.back

Step 13: Edit this file with the following editor and make some changes.  You must change 3 variables:

  • $webservergroup = ‘www’; //it was ‘apache’ by default
  • $db_user = ‘netuser’; //it was bugs by default
  • $db_pass = ‘a_password’; // it was blank by default

Step 14:  Take a backup (cp httpd.conf http.conf.back) at your httpd.conf apache2 configuration file and make some changes with your favorite editor. At the end diffing the two files you must have the following changes:

dhcppc2:~ # diff /etc/apache2/httpd.conf /etc/apache2/httpd.conf.back
152,153c152,153
<     #Options None  //comment out the Options None
<     AllowOverride All // and make AllowOverride to All from None
—
>     Options None
>     AllowOverride None
167c167
< DirectoryIndex index.html index.html.var index.php index.cgi // add index.php and index.cgi also
—
> DirectoryIndex index.html index.html.var

Step 15: At /etc/apache2 copy default-server.conf to default-server.conf.back. Make the following changes (I have pasted the output of the command diff default-server.conf default-server.conf.back.

dhcppc2:/etc/apache2 # diff default-server.conf default-server.conf.back
7c7
< AddHandler    cgi-script      .cgi  //this line must be placed after the DocumentRoot “/srv/www/htdocs” line
—
>
22c22
<       #Options None //comment out Options None
—
>       Options None
26c26
<       AllowOverride All // change All to None for AllowOverride
—
>       AllowOverride None

Step 16: Enable mod_perl and restart apache. This is done with the following command

  • a2enmod mod_perl //enable mod perl
  • rcapache2 stop // stop apache
  • rcapache2 start // start apache
  • chkconfig -a apache2 //make apache start everytime the system starts (optional)

Step 17: Increase the max_allowed_packet at your MySQL configuration. Edit /etc/my.cnf and change max_allowed_packet to max_allowed_packet = 4M. This will permit 4meg attachments at your bugs. Restart mysql with /etc/init.d/mysql restart.

Run ./checksetup.pl at the bugzilla directory. Everything should work fine. Open your web browser and point to http://localhost/bugzilla/. Ready to go…

MySQL at OpenSUSE. The first steps.

Posted: April 18, 2010 | Author: | Filed under: development | Tags: , , | 7 Comments »

This tutorial assumes that you have already installed OpenSUSE at your box and your capable of doing simple things with it, ie move around or use the everyday commands. So before we begin let’s check if MySQL is installed on your OpenSUSE machine:

dhcppc2:~ # rpm -qa | grep mysql
libmysqlclient_r15-5.0.51a-27.1
libmysqlclient16-5.1.36-61.1
libqt4-sql-mysql-4.4.0-4.1
libgda-3_0-mysql-3.1.2-42.1
libmysqlclient_r16-5.1.36-61.1
php5-mysql-5.2.5-66.1
qt3-mysql-3.3.8b-44.1
mysql-client-5.0.51a-27.1
kamailio-mysql-1.4.0-9.23
ruby-mysql-2.7.4-84.1
perl-DBD-mysql-4.006-41.1
mysql-5.0.51a-27.1
bytefx-data-mysql-1.9.1-6.
mysql-connector-java-3.1.12-239.1
libmysqlclient15-5.0.51a-27.1

I strikedthrough some software modules that are not needed by default. For sure we need to have mysql and myslq-client in our systems. If these packages are not installed you can downloaded them from the OpenSUSE repositories or leave this duty to yast. Yast will do it for you.  But usually mysql comes pre-installed and probably you will overcome this small obstacle. However when we install MySQL, this does not mean that this module in running in our system as well. If you are planning to use MySQL often a good habit is to configure your system to launch MySQL at the startup. First find out that MySQL is not running and second that is not configured to run at the startup.

dhcppc2:~ # ps -ef | grep mysql

The ps command will respond with the process id, if MySQL is up. In order to see if the process runs on startup execute the following:

dhcppc2:~ # chkconfig –list | grep on

acpid                       0:off  1:off  2:on   3:on   4:off  5:on   6:off
alsasound              0:off  1:off  2:on   3:on   4:off  5:on   6:off
auditd                     0:off  1:off  2:off  3:on   4:off  5:on   6:off
avahi-daemon     0:off  1:off  2:off  3:on   4:off  5:on   6:off
avahi-dnsconfd   0:off  1:off  2:off  3:on   4:off  5:on   6:off
consolekit              0:off  1:off  2:on   3:on   4:off  5:on   6:off
cron                          0:off  1:off  2:on   3:on   4:off  5:on   6:off
...

....
wondershaper     0:off  1:off  2:off  3:off  4:off  5:off  6:off
xdm                        0:off  1:off  2:off  3:off  4:off  5:on   6:off
xend                       0:off  1:off  2:off  3:on   4:off  5:on   6:off
xendomains        0:off  1:off  2:off  3:on   4:off  5:on   6:off

chkconfig is a small but very useful command at the administrator’s command vocabulary.  Most of the times this list does not contain mysql by default. This means that we need to enable mysql to run at the system startup. This is done by invoking the chkconfig command with the following syntax:

dhcppc2:# chkconfig –add mysql
mysql                     0:off  1:off  2:on   3:on   4:off  5:on   6:off

In case you need to see more things about the chkconfig command, here is a nice article at LinuxJournal.com.

Now type the following commands to first check if your service is running and the fire it up:

dhcppc2:/etc/init.d # rcmysql status
Checking for service MySQL:                                           unused
dhcppc2:/etc/init.d # rcmysql start
Starting service MySQL                                                done

The service is up and ready to be configured. Enter the following at your prompt:

dhcppc2:~ # mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we’ll need the current
password for the root user.  If you’ve just installed MySQL, and
you haven’t set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on…

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.

You already have a root password set, so you can safely answer ‘n’.

Change the root password? [Y/n] n
… skipping.

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n]
… Success!

Normally, root should only be allowed to connect from ‘localhost’.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n]
… Success!

By default, MySQL comes with a database named ‘test’ that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n]
- Dropping test database…
… Success!
- Removing privileges on test database…
… Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n]
… Success!

Cleaning up…

All done!  If you’ve completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

The above dialogue with MySQL will help you configure your system and run a secure database server. If you are running this command for the first time, ie you haven’t configured anything yet, this dialogue will be a little bit different at the beginning. You will be prompted to enter a root password. Give the password that will protect the MySQL root account. This password it may be different from the system’s root password. Now restart your server:

dhcppc2:~ # rcmysql restart
Restarting service MySQL
Shutting down service MySQL                                   done
Starting service MySQL                                                done

Now that you have installed MySQL and have started it, you are ready to test your application. This is a simple process that is intended to verify that the MySQL server is running and that the mysql administrative database has been properly initialized. So first verify which version of MySQL is running:

cateof@dhcppc2:~> mysqladmin version -p
Enter password:
mysqladmin  Ver 8.41 Distrib 5.0.51a, for suse-linux-gnu on i686
Copyright (C) 2000-2006 MySQL AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version          5.0.51a
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/lib/mysql/mysql.sock
Uptime:                 26 min 0 sec

Threads: 1  Questions: 34  Slow queries: 0  Opens: 23  Flush tables: 1  Open tables: 17  Queries per second avg: 0.022

Information about the MySQL installation displays, including information about the version number and the edition of the MySQL server. Next, verify whether the MySQL databases have been properly installed and configured. You achieve this by running the mysql command line utility to access the databases.

cateof@dhcppc2:~> mysql -p

Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.0.51a SUSE MySQL RPM

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| openser            |
+--------------------+
3 rows in set (0.00 sec)

mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> SHOW TABLES;
+---------------------------+
| Tables_in_mysql           |
+---------------------------+
| columns_priv              |
| db                        |
| func                      |
| help_category             |
| help_keyword              |
| help_relation             |
| help_topic                |
| host                      |
| proc                      |
| procs_priv                |
| tables_priv               |
| time_zone                 |
| time_zone_leap_second     |
| time_zone_name            |
| time_zone_transition      |
| time_zone_transition_type |
| user                      |
+---------------------------+
17 rows in set (0.00 sec)

mysql> SELECT User,Host from Users;
ERROR 1146 (42S02): Table 'mysql.Users' doesn't exist
mysql> SELECT User,Host from user;
+-----------+-----------+
| User      | Host      |
+-----------+-----------+
| openser   | %         |
| openserro | %         |
| openser   | localhost |
| openserro | localhost |
| root      | localhost |
+-----------+-----------+
5 rows in set (0.00 sec)

Now let’s create a new user that have access to this database outside this Linux box. You need to go to your prompt and type:

dhcppc2:~ # mysql -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 17
Server version: 5.0.51a SUSE MySQL RPM

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> CREATE USER ‘netuser’@'localhost’ IDENTIFIED BY ‘a_password”;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO ‘netuser’@'localhost’ WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER ‘netuser’@'%’ IDENTIFIED BY ‘a_password”;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO ‘netuser’@'%’ WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

This sequence of command will create a user called netuser that can access the database either from the console or outside the box, eg via a client from a  Windows machine. More on creating users can be found at http://dev.mysql.com/doc/refman/5.1/en/adding-users.html.

implements ActionListener

Posted: April 14, 2010 | Author: | Filed under: development | Tags: , | Leave a comment »

Implementing interface ActionListener forces us to define a method with the first line

public void actionPerformed( ActionEvent actionEvent )

in our class. This method’s task is to process a user’s interaction with an object (a button for example). When the user performs the action (for example pressing the button), this method will be called automatically in response to the user interaction. This process is called event handling. The event is the user interaction (pressing the button) and the event handler is method actionPerformed.

← Older Entries
Follow

Get every new post delivered to your Inbox.