Forwarding emails using filters in Google Mail

Automatic email forwarding for certain emails can be quite handy. Here is a quick guide how you create forwarding filters in Google Mail.

To start off with we need to add a new forwarding email address and verify that we are allowed to forward emails to this address. In order to do this open up Google Mail settings and click the Forwarding and POP/IMAP tab.

Open forwarding settings
Open forwarding settings

Within the upcoming tab click on the Add forwarding address button and enter an email address in the new dialogue.

Enter forwarding email
Enter forwarding email

As soon as the new forwarding email address is added the owner should get an email containing a verification code. With this code one can verify that one is allowed to forward emails to this address. The code can be entered within the Forwarding and POP/IMAP tab.

Enter verification code
Enter verification code

After verification emails can be forwarded to this address. Google Mail provides two options for forwarding emails. First option is to forward all emails to a certain address. The second option is to define filters which identify certain emails and forward these to a specific email address. The later option is of interest for us.

In order to create a new filter navigate to the settings Filters tab. Here one can see existing and create new filters.

Create new filter
Create new filter

Creating a filter is very simple. First of all one has to define the filter criteria, which can also be done by simply typing search terms into Google Mail’s email search field.

Define filter criteria
Define filter criteria

Secondly, one has to define which actions should be applied to emails matching the defined filter criteria. In order to forward emails one has to check the Forward it to action and select the desired destination email address.

Define actions
Define actions

After creating the filter all actions, including Forward it to, should be applied to emails matching the filter criteria.

 

git svn – Subversion repository moved, what should I do?

As I prefer Git as version control system I often end up working with it as client for Subversion (SVN) repositories. Recently, I had to interact with a SVN repository which was moved to another location after my initial cloning.

As Git stores the SVN URL and includes it into the SHA-1 hash calculation you can end up having the following problem as soon as you change the repository URL and try to push your changes to the remote repository:

Unable to determine upstream SVN information from HEAD history.
Perhaps the repository is empty. at /usr/libexec/git-core/git-svn line 519.

The problem is that by changing the SVN repository URL calculated SHA-1 hashes differ and Git cannot determine the proper commit to push to. In order to overcome these problems you can add the rewriteRoot option to your configuration file and afterwards change the URL:

git config --replace-all svn-remote.svn.rewriteRoot http://old.repository.com/url
git config --replace-all svn-remote.svn.url http://new.repository.com/url

Next time you try to push your changes they will be pushed to the new repository destination (newURL) but Git pretends it to be the old repository destination (oldURL).

Simple SVN to Git repository migration

Recently I wanted to migrate an existing Subversion (SVN) repository trunk to a new Git repository. Here is a short description how you can do it in four simple steps.

First of all, create a new bare repository:

$ mkdir NewGitRepo
$ cd NewGitRepo/
$ git init --bare

Secondly, checkout the old SVN repository using Git and enter the repository folder. For this post I created a sample SVN repository on my local hard drive:

$ git svn clone file:///some/file/path/OldSVNRepo/trunk ./OldSVNRepoGit
$ cd OldSVNRepoGit

Thirdly, add your new Git repository as additional remote branch to the checked out SVN repository:

 $ git remote add origin /some/file/path/NewGitRepo/

Finally, push SVN contents to new Git bare repository:

$ git push -u origin master
Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (12/12), 1016 bytes, done.
Total 12 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (12/12), done.
To /some/file/path/NewGitRepo/
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

As stated in the heading, this is just a simple way. Additional information regarding this topic can be found in the Pro Git book by Scott Chacon:

http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git

SoapUI: Setting all web service endpoints for a test suite

When working on SOA projects I am used to create some developer test suites for myself in order to do some initial web service QA. For this purpose SoapUI is a commonly used functional testing tool. Depending on the project these “small” test suites can actually become quite big. That is fine as long only one service endpoint has to be tested, however most likely you end up with several endpoints for different development stages (development, integration, production). Gladly SoapUI provides a functionality to set web service endpoints for all service request. Only problem is to find this functionality 😉

To demonstrate the functionality I took a standard global weather service and created a small SoapUI project.

Global Weather Service
Global Weather Service

Within the project I created some requests and test suites for both operations. Furthermore, I added some additional endpoints to the GlobalWeatherSoap Interface. You can access this view by double clicking the respective web service interface.

GlobalWeather service interface
GlobalWeather service interface

In order to set the endpoint required for the next test run, you have to select it from the list and click the Assign button in the top menu. As result an additional dialogue opens which provides several options.

Assign endpoint dialogue
Assign endpoint dialogue

In this example we want to set the new endpoint for all requests and test requests, therefore this option has to be selected. Afterwards all requests point to the new endpoint and the test suite can be executed.

Assigned endpoints
Assigned endpoints

Working with XMind and iThoughts using Google Drive as file share

In my daily work I like to create mind maps for many tasks, such as meeting minutes or brainstorming before starting a new task. For my mind maps I use XMind on my Mac and iThoughts on my iPad. Of course there is the requirement to share mind maps between my devices. Therefore, I had a look into both products in order to find a way to work with my mind maps on both devices.

In general, I use Google Drive as my cloud provider and did not want to install additional software on my Mac. Unfortunately, iThoughts does not support Google Drive syncing at the moment. However, you can send your mind maps to other apps and the Google Drive App is one of those you can choose. After trying around a little bit I developed a small workflow that seems to work and I am going to describe it in this blog post.

The following steps will be executed in the workflow description:

  1. Create a mind map in iThoughts on the iPad
  2. Upload mind map to Google Drive
  3. Open mind map from Google Drive Folder using XMind
  4. Edit mind map in XMind
  5. Save mind map to Google Drive
  6. Open edited mind map in iThoughts

Workflow by example

First of all create a new mind map in iThoughts:

Edit mind map
Edit mind map

Afterwards it has to be sent to Google Drive App in order to upload it to the shared drive:

Send to App
Send to App

The native format for XMind is .xmind, so this file type and Open in Google Drive have to be selected:

Send to Google Drive
Send to Google Drive

Afterwards Google Drive App should open and ask for permission to upload the file. As soon as permissions are provided the upload should start:

Uploading file
Uploading file

After the upload is finished the mind map should be stored in Google Drive folder and it can be opened using XMind:

Mind map opened in XMind
Mind map opened in XMind

Now it is time to make some more changes in XMind:

Edited mind Map
Edited mind map

Afterwards the mind map has to be saved to Google Drive again. If Google Drive Mac App and its Google Drive Folder are used the mind map just has to be saved in XMind and it gets uploaded. Another possibility would be to upload the new version using the Google Drive website.

Next step is to open the mind map in iThoughts, therefore the iPad Google Drive App has to be opened, the file selected and send to iThoughts:

Open file in iThoughts
Open file in iThoughts

Here a problem within the workflow was encountered. If the mind map is sent to iThoughts and its name includes spaces they get removed. In the case described the mind map was called “Google Drive Test Map.xmind” but it ended up in iThoughts as “GoogleDriveTestMap”. Therefore, it is a good idea to choose names without spaces.

Finally, the edited mind map can be opened in iThoughts again and it displays the changes made in XMind:

Edited mind map in iThoughts
Edited mind map in iThoughts

Change SQL Developer language setting

As a standard SQL Developer uses the system OS language in order to determine it’s own language setting. In my case this is normally German. Unfortunately the German translations rather confuse than help me to understand the UI. Therefore, I tend to switch the UI language to English each time.

This can be done quite easily by adding a new line to the $SQLDEVELOPER_INSTALL_DIR\ide\bin\ide.conf file:

AddVMOption -Duser.language=en

Probleme beim WordPress Update 3.2.1 mit 1und1

Es gab ein paar Probleme beim Update auf die neuste WordPress Version (3.2.1) auf meinem 1und1 Webspace. Das automatische Update endete immer in einem Fatal Error: Out of Memory. Um das Update dennoch durchführen zu können, reichte es alle Plugins zu deaktivieren. Nun ist die Seite auch wieder up to date 😉