Oct

8

Is there any need for the Applet anymore?

Filed Under Software Development, Computers & Tech on October 8, 2005 | Leave a Comment

Now that the worst of the ‘browser wars’ finally seems to be behind us and now that JavaScript can easily communicate with servers to get data without page re-freshes via AJAX one has to wonder if there are any real uses left for applets. My conclusions would be that yes there are still some uses for applets on the web but they are few and far between. Anyone who uses an applet in this day and age should have a bloody good reason to do so because your browser should not have to load a JVM just to view a web page unless that JVM is providing something spectacular that actually adds something to your page and that cannot be done with the core web technologies (XHTML, CSS, JS, AJAX).

Read more

Tagged with: •

Oct

6

A DISTINCT quirk in PostgreSQL

Filed Under 42 (Life the Universe & Everything) on October 6, 2005 | Leave a Comment

I was doing some NASTY SQL coding this evening (or squealing as Smiler would say) and I got bogged down quite a while trying to get DISTINCT and ORDER BY working in the same query. The PostgreSQL error message was not entirely clear and I must have misinterpreted it about 5 times before I finally figured out what it was so desperately trying to tell me!

Turns out that even if you don’t actually want to select the field you are sorting on in a query that uses the DISTINCT keyword you still HAVE to include it in your SELECT list or PSQL will have kittens!

BTW, I am aware that it is considered a ‘bad smell’ by some hard-core SQL programmers to use to DISTINCT key word and I generally agree with their logic (why go to the effort of selecting a load of extra rows that you are just gonna prune off in the end?). However, I can’t for the life of me figure out how to get rid of the DISTINCT in the query below, any insights you may have would be appreciated (looks at Bon)!

SELECT DISTINCT a.id AS assignmentId, a.name AS assignmentName, a.team_id AS teamId, 
  t.name AS teamName, a.completed AS assignmentComp, a.last_updated_at AS lastUpdated
FROM ((student_team st INNER JOIN teams t ON st.team_id = t.id) 
  INNER JOIN assignments a ON t.id = a.team_id) 
  INNER JOIN projects p ON t.project_id=p.id
WHERE a.completed='true'
ORDER BY a.last_updated_at DESC LIMIT 5;

Tagged with: •

Oct

4

The CORRECT way to install Sun Java on Debian/Ubuntu

Filed Under System Administration, Computers & Tech on October 4, 2005 | Leave a Comment

This little guide is just a greatly padded out version of instructions I got from Misha but since we have quite a few Ubuntu users and quite a few Java programmers in MiNDS> this should come in quite useful.

Basically this is the Debian way of installing the Sun JSDK so that it can be managed with dpkg and hence easily upgraded or removed at a later date.

Firstly, since Ubuntu IS a distribution of Debian really I will just refer to Debian in these instructions but the instructions also apply to Ubuntu and in fact it was on Ubuntu that I tested this. Also, these instructions assume that you are logged in as a user who has access to root via sudo.

The way this will work is that we will use a Debian package called java-package to turn the binary Linux installer we get from Sun (or IBM and others too) into a proper Debian package (.deb) and then we will use Debian’s package manager (dpkg) to install that Debian package.

The first step in the process is to install the java-package program that will allow us to create the .deb file. To do this simply type:

sudo apt-get install java-package

If you are asked for a password it is for sudo and you should enter your own login password.

The next step is to go to java.sun.com and download the Linux binary installer for the JSDK that you want to install. DO NOT DOWNLOAD THE LINUX RPM FILE!

The next step is to use java-package to turn this binary file into a Debian package, to do this move into the folder where you downloaded the binary file from java.sun.com.

NOTE, if you are doing this in the college on your machine for your 4th year project you will have to copy the binary file to /tmp and work from there because local root does not have access to your NFS mounted home directory.

For this step you will need fakeroot, if you don’t have it installed install it with apt-get like so:

sudo apt-get install fakeroot

Once you have fakeroot installed and you are in the right directory start the packaging with the command (replacing file_from_sun.bin with the actual name of the file you got from Sun):

fakeroot make-jpkg file_from_sun.bin

This will now appear to run the Sun installer but rather than installing it into your system it is extracting it to a temporary fake root file system and then creating the .deb file from the files in that fake file system. During this stage you will be asked to agree to the Java license agreement.

When the above command completes (will take a few minutes) a .deb file will have been created in your current folder. This is the file that we will now install with dpkg as follows (replacing name_of_deb_file.deb with the actual name of the .deb file created):

sudo dpkg -i name_of_deb_file.deb

And hey presto you are finished, when ever you want to get rid of that JDK all you have to do is (replacing name_of_deb_file_without_The_extension with the name of the generated .deb file but with the .deb extension left out, e.g. sun-j2sdk1.5):

dpkg --purge name_of_deb_file_without_The_extension

You can then install a new JSDK in the same was as described above or just leave your system Java free (heaven knows why you’d do something mad like that!)

Tagged with: • • • • •

Oct

3

The easiest way to turn a Mac into a Mail Server

Filed Under System Administration, Computers & Tech on October 3, 2005 | Leave a Comment

So, you have a mac server running OS X and your boss tells you it needs to act as a mail server too. The HARD way to do things is to compile your own postfix and then manually configure it. If you are a Unix whiz then this will of course be the kind of stuff you do in your sleep but if you’re just a pleb like the rest of us then you will be interested in this neat bit of software.

Using Post Fix Enabler it took me a whopping 30 seconds to get my machine running properly as a mail server (note things were made quite a bit quicker by the fact that I had to use another server as a smarthost). Yes, it costs just under $10 but it is money well spent!

Tagged with: • •

Oct

3

Beating Bugzilla into submission on OS X

Filed Under Computers & Tech, System Administration on  | Leave a Comment

I had been warned that Bugzilla was a pain to install but when I read the instructions on their webpage I thought it all looked pretty simple, turns out it WAS a pain to install!

The trouble was caused by two things:

  1. CPAN modules refusing to build on OS X
  2. Bugzilla making ridiculous assumptions that just don’t stand up to reality, namely:
    1. You will always want to use /usr/bin/perl
    2. sendmail will always be in /usr/lib/sendmail

For details on how I resolved these issues read on.

Firstly, getting Perl to behave itself. The simplest solution to this problem is not to use Perl that comes with OS X but to use DarwinPorts or Fink to get Perl in order. I used DarwinPorts because I have had bad experiences with Fink and really like DarwinPorts. Anyway, it worked like a charm, all the modules I needed were available via DarwinPorts and installed with no issues at all. One thing to note is that this does not patch up the Perl in /usr/bin but rather installs a whole new Perl in /opt/local/bin. One slight annoyance was that to get DBI::MySQL I also had to install a copy of MySQL from DarwinPorts. This is fine because you don’t actually have to USE it, just have it there. As it happens the guys at MySQL have an excellent binary distribution of the MySQL server these days so there is no need to get it from DarwinPorts. I also already had other databases installed and running on my MySQL install so I was in no humor to have a second MySQL server running just for Bugzilla! The one complication here is that the default location for the MySQL socket in the DarwinPorts Perl is the location the DarwinPorts MySQL server uses and not the one the default MySQL server uses. Since I am not using this MySQL I had to tell Bugzilla not to use the default socket but the one I was actually using. You do this by editing localconfig. In my case I had to set the following:

$db_sock = '/private/tmp/mysql.sock';

Now, you can probably imagine how using DarwinPorts’ Perl caused the first of the assumptions made by the Bugzilla installer to break down. The Perl that comes with OS X is at /usr/bin/perl and is used by loads of stuff on the system (so I can’t replace it with a symlink to the right Perl), the Perl from DarwinPorts is at /opt/local/bin/perl. Although I explicitly ran the installer for Bugzilla with this Perl in the hope that it would be smart and realise that it should use that Perl for everything, it still set all the shebang lines to #!/usr/bin/perl and hence although Bugzilla passed the installer’s tests with flying colours, it crashed in a heap when you tried to use it because it went running off to the wrong Perl!

I figured that if the shebang lines were not generated by setting them to the Perl running the installer then there MUST be a configuration option to allow you to specify what Perl should be used. I tried looking really hard but with no joy. I looked on the online documentation, no joy, I tried their mailing list, not even a reply so I took the bull by the horns and wrote my own Perl script to change all the shebang lines for me:

#!/opt/local/bin/perl

use strict;

print "\n\n";

# get the files in the directory
opendir(THISDIR, ".");
my @files = readdir(THISDIR);
closedir(THISDIR);

#loop through the files
foreach my $file (@files){
  # skip files that are not cgi files
  next unless $file =~ m/\.cgi$/;

  print "Processing file: $file\n";

  # get the contents
  open(CGIFILE, "$file");
  my @contents = <CGIFILE>;
  close(CGIFILE);

  # write it back out but with the correct shebang line
  open(CGIFILE, ">$file");
  if($contents[0] =~ m/^\#\!/){
    print CGIFILE "#!/opt/local/bin/perl\n";
  }else{
   print CGIFILE $contents[0];
  }
  for(my $i=1;$i < scalar(@contents); $i++){
    print CGIFILE $contents[$i];
  }
  close(CGIFILE);
}

print "\n\n";

This got Bugzilla up and running and talking ot the DB but desepite the fact that I had sendmail up and running on the server Bugzilla now had a hissy-fit each time you tried to add a bug or do anything that caused it to try to send an email. This is where the second retarded assumption made by the Bugzilla peeps was the culprit. firstly, their error reporting sucks donkey dick and was of no use at all so into the code I dived. After some poking around inside the source tree I figured the problem must lie within Bugzilla/BugMail.pm and sure enough in the last function of that file (line 868 of 876) I found this: 

open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i")

Yup, they had hard-coded in the location of sendmail! Again, there is no way to set the location of sendmail in any config file I could find so I had to manually edit this line to look like this: 

open(SENDMAIL, "|/usr/sbin/sendmail $sendmailparam -t -i")

Once that was done all was fine and Bugzilla is now working but I really shouldn’t have had to jump through so many hoops to get it working!

Tagged with: • •

« go back