GoogleMaps API multiple markers

I have a database with some records that among other details they also declare a local (Greek) street addresses. The requirement is to retrieve all these records from the database and display them with markers on a Google Map. Before everything, if you want to get an idea on how the API works see the following links:

GoogleMaps API – Getting started
GoogleMaps API – Simple markers

The flow for my task has as follows:

– Connect to database
– Retrieve all the locations from DB
– Convert Greek characters to Latin for avoiding issues with the Web Service request [ code on code.loon.gr ]
– Use GoogleMaps API to retrieve GPS coordinates based on the given location
– Parse JSON response
– Use JavaScript to add the markers layers

Full code on GitHub.

 

Advertisements

Remote cPanel backup via FTP

Here is the scenario:

– Domain that needs to be backed up (public_html, mail, database).
– Only access available via cPanel and FTP.
– Need automated daily full backup.

Solution:

– Take full backup on server and compress its contents (cronjob on remote server)
– Download via FTP the compressed file to the local machine (cronjob on local machine).
– Delete compressed file.

There might be tools that do this, although I didn’t come across any while looking on the web. I implemented a simple solution based on bash scripts that gets the task done.

backup.sh: Goes on the remote server to run as a cronjob.
ftp.sh: Runs locally (on the machine that will store the backup) as a cronjob.
.netrc: Defines the FTP account details (stored in /home/$user/.netrc)

Gmail SMTP relay with Postfix

The following configuration has been performed in Debian but should apply in any Linux distro with Postfix installation. The task quite simple: use Gmail as SMTP relay for outgoing email traffic.

1) At first place I had to install the following packages and turn off sendmail:

apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules
service sendmail stop

2) Then edit the configuration file at /etc/postfix/main.cf by adding the following options at the end of the file:

# Gmail SMTP relay
relayhost = [smtp.gmail.com]:587
smtp_use_tls=yes
smtp_sasl_auth_enable = yes 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_security_options =

3) Create the authentication file at /etc/postfix/sasl_passwd and set the right permissions:

[smtp.gmail.com]:587    <username>@gmail.com:<password>
chmod 400 /etc/postfix/sasl_passwd

Make sure the file is owned by the user who runs the Postfix daemon.
4) Reload Postfix:

service postfix reload

5) Confirm the configuration is actually working by sending a test mail:

echo "Test mail from postfix" | mail -s "Test Postfix" pkritikakos@isbs.gr

The sender of the email should be the given Gmail account. Also, in the “Sent” folder of the Gmail account you should see the email you have sent with Postfix.

If your domain is using Gmail’s infrastructure for handling emails, you can replace @gmail.com with your domain and use the corresponding account details.

NOTE: This configuration will be sending any system message as “username@gmail.com” and therefore is not advised to be used in multi-user environment.

Java HTTP library

Being in need to issue POST requests from within a Java application, and wanting re-usable code, I created a very simple Java library for issuing POST and GET requests to a remote server.

POST source codeGET source code

Usage (POST example):

POST post = new POST();
post.postRequest("http://www.myservice.com/service", "param1=foo&param2=bar", "Mozilla/5.0");

In other words, the arguments are:

post.postRequest(SERVER_URL, PARAMETERS, AGENT);

The output can be manipulated as desired, depending on what you response you except you should use a corresponding element/object.

Converting OS X .plist to XML

The failure of my MacBook Pro seems that it didn’t cost much in terms on data loss, actually all the really crucial data were there. There are though some bits here and there that need to be moved over to my Linux box. One of the most important for everyday use the was the feed list for my RSS Aggregator. I was using the elegant, nice and simple NewsFire which uses binary plists (XML-like) for storing the feed list and I was never bothered exporting the feed list to OPML. The plist command in OS X can convert the .plist file into a .xml file, however I had no other Mac to do this operation or copy over the plist and export in OPML from there. Therefore I had to find a workaround for getting the plist working on RSSOwl or Liferea. Found the Perl plutil for Linux which converted the binary plist to standard XML. RSSOwl managed then to import the XML with all the blogs’ feeds as on NewsFire.

Regarding liferea, it wouldn’t import the XML file as it wasn’t proper OPML. But since RSSOwl imported the XMl file, I exported the feed list as OPML, which would be imported into Liferea or any other application.

An ARM comparison: Raspberry Pi vs OpenRD Client

Bellow there’s a comparison between Raspberry Pi (Model B) and OpenRD Client, two low-power ARM SoC (System on a Chip), running Linux (Rasbian and Fedora respectively). I used the EEMBC CoreMark benchmark with default settings for 100000, 1000000 and 2000000 iterations. For each set, each device keep its performance with the same rate of iterations per second. The difference between the devices is at, an average level of, 520 iterations per second. That translates to 1.4x faster in favour of the OpenRD Client.

While OpenRD Client performs better, in terms of efficiency, Raspberry Pi seems to doing much better. In terms of CPU, Raspbeery Pi uses a 700MHz (with the possibility of setting it up to 1GHz) ARMv11 processor while OpenRD Client an older 1.2GHz Marvell Sheeva (ARMv5TE). ARMv11 supports an FPU unlike ARMv5 and that is one of the reasons that Raspberry Pi performs quite well despite its lower specifications. In terms of memory, Raspberry Pi uses 256MB DDR2 800MHz (newer models have 512MB RAM), in share with its relatively powerful GPU, while OpenRD Client uses 512MB DDR2 800MHz. OpenRD Client also provides Gigabit Ethernet as well as many more I/O interfaces. Also, OpenRD has preloaded OS, unlike Raspberry Pi that boots from an SD card. During this benchmark, Raspberry Pi was running Rasbian “Wheezy” (unofficial Debian port to armhf) while OpenRD Client Fedora 8.


(Raspberry Pi diagram – http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspi_Iso_Blue.png)


(OpenRD Client Hardware Block diagram – http://www.globalscaletechnologies.com/skins/skin_1/images/OpenRD-Client_back.PNG)