Run Multiple Google Chromes with different profiles on a Mac

UPDATE: Google Chrome Beta (starting from v16) now supports multiple profiles. It allows almost the same thing that this article describes below. See the announcement about it in the Google Chrome blog.

If you have multiple accounts in different sites (GMail, Picasaweb, etc) and ever wondered how you can be logged in into both in your favourite Google Chrome browser, then I have a nice solution for you.

Of course you can use the Incognito mode to enter the credentials of a second account, but it is not preserved accross sessions. After a while providing the credentials over and over becomes boring.

I've read a little on how to run multiple Google Chrome instances on a Mac and found this wiki. I used it for myself and shared the link. While this is a good starting point, my friends started to complain that things did not work as they expected, so I decided to write my own tutorial on how to run multiple Google Chrome instances on one Mac:

Step 0: Install Google Chrome

I guess you already have Google Chrome installed. If not, install it from here. From now I will assume that it is in your /Applications folder.

Step 1: Create a shell script to launch a custom Chrome instance

Copy the following text into a file and name it as /usr/local/bin/custom_chrome.sh (or download it from here):

#!/bin/sh
if [ -z "$1" ]; then
  echo "Usage: $0 profile_name"
  exit 1
fi
PROFILE_NAME="$1"
GOOGLE_CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
USER_DIR="/Users/$USER/Library/Application Support/Google/Chrome/${PROFILE_NAME}"

exec "$GOOGLE_CHROME" \
  --enable-udd-profiles \
  --user-data-dir="$USER_DIR"

Make this file executable: in Terminal, run: sudo chmod +x /usr/local/bin/custom_chrome.sh

Step 2: Create your own Google Chrome application

Let's create a new profile "corp" and name your new application "Google Chrome (corp)".

For this, you have to open the terminal and do the following steps:

$ sudo bash

Password: your_password

# cd /Applications

# APPNAME="Google Chrome (corp)"

# mkdir -p "$APPNAME.app/Contents/MacOS"

# cd "$_"

# echo -e '#!/bin/sh\nexec /usr/local/bin/custom_chrome.sh corp' > "$APPNAME"

# chmod +x "$APPNAME"

# cd /Applications

# chown -R your_username "$APPNAME.app"

# exit

Now you have another Chrome instance with a profile which is independent of the main application profile!

Step 3: Make a custom icon for this application

The default icon of a new application is not really nice, so you can either copy the icon from Chrome, or download a custom one.

Google Image Search for "chrome icon" gives you a bunch of beautiful icons. In this article, I used the Chromium logo, the image from this techreviews page, a neon-style icon and an icon from this forum post.

To install a custom icon, the first, you have to select the application in Finder, then click on "Get Info":

Now open your selcted icon with your browser, and drag the image into the Icon in the "Get Info" page:

Note, that Google Chrome sometimes changes its icon back to the original icon when it is running and as far as I know the only way to change it back is to restart the browser.

Step 4: Enjoy the result of your work

Now you can drag your new Google Chrome (corp) application to your Dock and watch it running parallelly with the original application.

Parallel::ForkManager 0.7.6 (#perl, #forkmanager) and publicity

I've put out a new Parallel::ForkManager release: 0.7.6 with small changes:

• Added datastructure retrieval from child processes. (Ken Clarke)
• Using CORE::exit() instead of exit() for mod_perl compatibility.

The new version is available in the project page and (sooner or later) from CPAN.

I did some research about the module publicity and found the following things:

• The most interesting story is that Nathan Patwardhan ported this module to ruby.
• It is mentioned in the perfaq8 man page.
• An introduction article about it in www.perlmonks.org from 2003.
• An article and discussion: Use Parallel Processing For Faster Perl Scripts.
• A blog post about Parallelization in PERL by Michael S. Williamson.
• The following RPM-based Linux distros have packages: Fedora, AltLinux, Redhat EL, Mandrake, Mandriva, PCLinuxOS, PLD.
• The following Linux distros also have packages: Ubuntu, Debian, Gentoo.
• Other unix packages: OpenBSD, FreeBSD.
• Someone actually had a talk about it in Madison, WI.
• There is a module which plugs in P::FM to App:CLI. I don't exactly know what it is, but seems cool. :)
• Still in CPAN, there is a project called Archer, which seems to support it, too.
• Other modules popped up which uses P::FM or mention it in their doc: Parallel::Prefork and Parallel::Forker, Parallel::ForkControl, Proc::Queue, Parallel::Loops, MyCPAN::Indexer::Dispatcher::Parallel, Parallel::Simple (the author even wrote a review of the module, scroll down to the SEE ALSO section).
• A hell lot of other discussion threads in www.perlmonks.org

Enjoy!

Emaily 0.7.1: Simplified email delivery, more stability (#emaily #googlewave)

Emaily 0.7 was announced last week, and it turned out that there are some cases where it still does not behave the way like it should. Today I'm happy to announce the fruits of some hard fixing and planning work, Emaily 0.7.1. The changes are the following:

Incoming emails are not distributed

In earlier versions, when a wave received a reply from an email user, and it has more than one email users and the incoming email did not have all email recipients listed in Cc: or the To: fields, then Emaily decided to deliver the email to the missing recipients. This was intended to be a feature, but it is very annoying in some cases, so we decided to disable the incoming email-distribution entirely. If a reply comes to a wave from email, it is not sent to any other email recipient (unless it is edited by a wave participant, in that case, it behaves like a new and edited blip).

This is not a problem if the communication is between one wave user and one email user, and less disturbing in some cases when there are more email users, especially when one participant is a mailing list.

Emails are sent out to every participant at once

Previously we sent out emails to each recipient separately, so that email participants did not see the participants of the conversation. The spirit of the wave is that every participant is visible for the others, so now we've changed this behavior. Every outgoing email now has all email and wave participants in their To: field.

An advantage of this is that combined with the previous feature is that if email participants use the "reply all" feature of their email client, then everyone will get every part of the conversation in a multi-participant conversation without the need of control from Emaily.

Manual send is disabled

Manual send will require some rework, and is more confusing than helpful, so we removed it temporarily. Now every message you finish in a wave will get delivered automatically after about 30 seconds.

Redirecting emails, mailing lists

With these changes, it is now safe to redirect your emails to wave: you don't need to worry that your nice wave robot sends out emails when you did not want to.

You can even subscribe to a mailing list with your emaily email address. If some other Emaily user is a member of the same mailing list, then you'll have a common wave created from the emails coming from the mailing list, so you can even discuss things faster (realtime), than members of the mailing list.

Enjoy the newest version of Emaily!

Emaily release: 0.7: Stability improvements (#emaily)

Emaily has reached its new milestone today: 0.7. We've been working on Emaily for a long time with no announced release, so I thought an update would be due.

Recently our efforts was split into developing and extending Emaily as a robot and working with the Wave team on some other cool thing which I cannot tell right now. But yes, it is related to emails. ;)

Stabilization

On the Robot side, we managed to finally stabilize it, so that we feel it is now reliable and usable with basic functionality. We think that we fixed all the errors we saw recently in our console and for now, you have a reliable email to Wave and Wave to email gateway. We do expect standard emails to arrive properly (normal means not too big, not specially crafted, etc.) and that wave updates are sent out reliably.

Email recipient handling vs. Wave participants

Email is different than Wave on how it deals with recipients/participants. Thus, any integration effort between these systems has to have tradeoffs. We figured out our way of handling email recipients, and we think that this approach handles some very common cases, though definitely not all.

One of the goals of the robot is to be as transparent as possible without being confusing. Starting from this release, when someone answers to an email which was sent out from Emaily and adds more email recipients to the reply email, then the robot will add these people to the conversation. Starting from that point, these people will get all updates on that wave and they can even reply. There is no current way of unsubscribing from a wave from email, but wave participants can remove any email participant, so you just need to ask someone.

The same works if this is a new email which arrives to your Wave. If there were more recipients, you will see them as wave participants, so when you answer, everyone will get the answer.

Future

There has been a lot of work done recently on the most requested features also: rich text emails and attachments. Actually they are almost ready.

Two weeks ago, we had a 4-day hackaton, where a team of 6 people worked on Emaily, and the biggest achievement was the development of these features. They require some polishing before release, but they are definitely around the corner!

The Emaily Team in the Hackathon

Class::Date 1.1.10

Class::Date 1.1.10 is released. This is a new release after a long time. (You don't need to change something which is perfect do you? :) )

Project link: http://code.google.com/p/perl-class-date

Changelog entry:

1.1.10  Sun Jul 18 13:27:39 CEST 2010
 - Remove the deprecated UNIVERSAL::import (Vladimir Timofeev)

RITMO 2010, a Google Wave based conference, Email integration panel

Recently there was a Google Wave based conference called RITMO 2010. You can imagine it like a virtual conference, where people are not gathered in crowded rooms, but sit in their comfortable chair in their home or workplace and discuss the conference topics through Google Wave.

This conference had a panel about Wave-Email integration. Mr. Ray and Emaily was invited. Here is the wave, you have to scroll down to 75% if you are interested in the past, present and future of Emaily:

Happy New Year and state report from the HQ #emaily #googlewave #wave

Happy New Year (well, better late than never) and Hi everyone who is interested in what's up with Emaily recently:

• As you might know, we, the developers of Emaily are Google Employees, we are doing Emaily in our 20% time. (GURU is helping us, he is not :) )
• We are back from Christmas Holidays.
• I am back from Sydney, where I met the Google Wave team, and we established a very good relationship.
• We are now testing an upcoming version of the Wave API in Emaily and because it is not released yet, we cannot share the source code from the point where started using it. This requires a big work, so please don't expect bugfixes in the meantime. Once we ported to the new API, many strange bugs will disappear at once (like phantom people on the wave which is created form an email, receiving email inconsistencies, etc.). So you probably won't see the progress, but there is!
• AppEngine is pretty limited for what we want to achieve, so we are thinking of rearchitecting Emaily into an application, which uses more of the internal Google services. For example if we run on AppEngine, we are not allowed to send and receive emails from your GMail account, just with a strangely encoded email address. We cannot use your GMail profile avatar in waves when you receive an email, etc. The consequence of that is that we once we start doing that, we probably won't continue the open-source version of Emaily. We simply don't have enough people to support the open source version. We prefer using our time to develop new features instead.
• Wave itself is very heavily under development, and we also need to rewrite our code sometimes, which leads to inefficiency in our developmet and that also make the progress slow.
• The good news is that more and more people are interested in the project inside Google, and we now have 4 developers working on the project.

Thanks for everyone who participated in the development by helping us or reporting bugs, or even testing features! We very appreciates that, and we hope that Emaily will deliver a much better user experience that it delivers today!

Cheers,

Balázs

Magyar billentyűzetkiosztás Androidhoz (Nexus One-hoz is)

Sziasztok!

Az AnySoftKeyboard fejlesztői elkészítették nekünk a magyar billentyűzetkiosztást Android telefonokhoz. Egyelőre még csak teszt verzióban létezik, de innen letölthető. Nálam működik.