Google Translation seems to have some difficulties with half-width katakana in google translate.
My text “ｸﾞ-ｸﾞﾙｲﾝｸ ﾌﾘｺﾐ” reads as “Go-goruinku furikomi”, which I’d translate as “Google Inc Bank transfer”. I’m just wondering how google reached a translation of “¸ – ¸ Ý Ù ² ¸ Ø º Ì Ð”.
Sending mailing to your customers and/or visitors is often an important way to bring additionnal revenues for your company. Regulary sending emails (between one week and one month between each batch) is important so people don’t forget about you and know about your latest offers. Add some discounts and stuff in the mail to ensure people will have a good reason to read them, and you’re done.
Now the question is “who should receive your mailing”. People usually thing it’s OK to just buy an email address database and send them ads everyday to let them know about you, and your offers they all really need. This is most likely going to result into your company name becoming a keyword to detect spam, which is probably not what you are expecting.
Even if you let them a choice to “opt out” from your mailing, most people will not optout in fear this will just reveal their email is valid and read, and trigger more spam. So your list will be full of people who will not opt out, but instead click “report as spam” button. This is most likely not what you want.
Now, you know you can only send mailings to people who have subscribed of their own will on your website. “Their own will” cannot be verified simply. As far as I am concerned, there are two solutions. For a visitor you have to send an email notifying him he asked to subscribe to your list, and that he must click some link to actually receive it. Including a link to privacy policies can be a good idea too.
Next comes real customers, people who have actually bought on your site and asked to receive your mailing (not with a pre-accepted subscription). For them, as they are more likely to trust your “optout” link, you can probably skip the double optin step.
Don’t forget that you also need to send mails from times to times. One full month without mail is a no-go, as customers will have forgotten about you and their subscriptions, and will immediatly suspect spam.
Sending mailings is an important communication job, and you need to have news and stuff to put in your mailing. Make it interesting for your subscribers, and send mailing regulary (every two weeks sounds like a good idea). If you can’t include a “new cool products” part, try to include news from other activies from your company or special offers. Sending the same newsletter everytime is a no-go.
Anyway remember that spam (any unwanted email, even if it’s unwanted because the subscriber forgot he was subscribed) is not good for your subscribers, not good for your image, and not good for Internet as a whole.
I’ve been fighting with apache during the past few days to try to accomplish something that has never been done until now.
Apache has some nice included modules, for example mod_vhost_alias. This module allows someone to configure vhosts by just creating directories however it has some limitations:
I decided to do something better, even with the people on #apache-modules (freenode) saying it’s not possible. It was even no possible to do this cleanly, however looking in apache’s code allowed me to reach my goal without too many problems, but with some really dirty parts.
To reach my goal I needed to use some functions from Apache2′s core. I just wanted to say that I am really sorry, and won’t do it again (maybe). The functions I used are not meant to be used the way I used them, however I had no choice has there is no publicly available function to change the document root, or to inject configuration directives in the current request.
Anyway don’t do this at home, kids!
One of the keys to play with core config dynamically is to fetch it. This is the way to modify ap_document_root. I just return DECLINED after completing my dirty work to let apache think it still has to do its work. Yes this is dirty. But it works.
Ever wanted to do bad things in a per-config context? Now you can. I won’t comment this too much, but I’ll just say that it saved me big time (this one is not part of CORE_PRIVATE, so you can use it freely I guess).
The final step was to make logging easier. I decided to throw all the logging info through a udg socket which is then collected by a daemon, stored locally, and transferred to the logging server at the same time.
If you got a credit card, you most likely got an expiration date written on it, which you must give to any website you want to pay to. On many websites, submitting transaction to the credit card processor costs money, and to avoid paying money for nothing something that will fail anyway, many stores will apply some checks beforehand, including luhn check and expiration check.
Now here’s the thing, as far as I can tell, when we implemented our store, our credit card processors didn’t give us any information about expiration date. The documentation explains how to submit a transaction, and not how to check for credit card informations validity (probably because they want us to submit it to them – and pay – in every case). I guess it’s the case for many other online stores. Now here’s the catch: I believe most shops do not know the exact rule behind the expiration date. Some will consider a card expired on the first day of the expiration month, some on the last day…
They are both wrong. I my card is expiring this month, I asked my credit card company and was told that my VISA card is expiring 30 days after the last day of the month written on it. An “expired card” is still valid for 30 days, however it will not work on some online shops which implements extra checks by themselves.
Now I’m stuck for one month on a card which doesn’t work on some stores, and started receiving “please give us your new card” emails from some subscriptions I have.
Anyway this “30 days after” rule isn’t documented anyway in the doc from our credit card processors, so I guess writing about it somewhere can be a good idea.
You are currently browsing the archives for January, 2010
