Arabic Email Addresses

Most human language scripts are written from Left to Right (L➡︎R). Arabic is written Right to Left (L⬅︎R). An email address written in the Latin script would be displayed L➡︎R — username@domain-name. An Arabic email address, on the other hand, would normally and without intervention be displayed L⬅︎R as domain-name@username.

Letʼs take a fictitious Arabic email address — خالد@الدوحة.قطر

• خالد is the username Khalid
• الدوحة is the 2nd level domain name Doha
• قطر is the Top Level Domain (TLD) Qatar. This part is not fictitious as قطر is a valid ccTLD.

Your browser should be displaying the email address خالد@الدوحة.قطر in L⬅︎R order which is not an order familiar to most L➡︎R readers and so requires some effort to parse.

When text has mixed L➡︎R and L⬅︎R characters it is referred to as Bidirectional (bidi) text. There is a complex Unicode algorithm specifically to determine  display order of bidi text unicode.org/reports/tr9/ If you read this report you will see something called Directional Isolates.

In the html world there are tags and attributes specific to bidi. One such tag is <bdi> which is bidi isolate. Using such html bidi isolation one can incorporate Arabic email addresses that are natural to read for both L➡︎R and L⬅︎R readers. These addresses can be written such that their overall text direction adheres to the text direction of the context. This context may be the direction of the whole html document or some subpart such as a paragraph.

First we will setup our html with a L➡︎R context for L➡︎R readers. The below paragraph (p) is setup with dir (direction) to ltr (left to right). The email address has 3 components: username, 2nd level domain name and TLD. Each component is direction isolated. This gives an email address whose overall direction is L➡︎R. The text of each component is, as it should be, L⬅︎R. I posit that this is much easier for a L➡︎R reader to comprehend. It is now obvious, for instance, to determine which is the username and which is the TLD.

The html code
<p dir="ltr"><bdi>خالد</bdi>@<bdi>الدوحة</bdi>.<bdi>قطر</bdi></p>
displays the address as

خالد@الدوحة.قطر

 

But how will the address be displayed if the context is changed to rtl (right to left). The code correctly displays the whole address in L⬅︎R order, both overall direction and text direction of each component. Thus we have also catered for L⬅︎R readers without changing relevant address display html code.

The html code
<p dir="rtl"><bdi>خالد</bdi>@<bdi>الدوحة</bdi>.<bdi>قطر</bdi></p>
displays the address as

خالد@الدوحة.قطر

Just in case your browser cannot, as yet, handle bidi isolates here are the 2 contexts in image format.

Oracle Forms Exception Handling: NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS

Oracle Forms Exception Handling: NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS

EXCEPTION block in PLSQL Oracle Forms is used to track the exceptions. Following is the PLSQL code snippet which uses NO_DATA_FOUND, TOO_MANY_ROWS and OTHERS exceptions. If the SQL SELECT query does not return any data, NO_DATA_FOUND exception is fired. If the SQL SELECT query returns more than one row where it was expected to return only one row, TOO_MANY_ROWS exception can be used to track this kind of exception. If you are not sure what kind of exception can the code throw, use OTHERS exception.

DECLARE
  DEPARTMENT_NAME VARCHAR(60);
BEGIN
  SELECT DEPTNAME INTO DEPARTMENT_NAME FROM DEPT WHERE DEPTNO = 20;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    MESSAGE('No data found');
  WHEN TOO_MANY_ROWS THEN
    MESSAGE('More than one row found');
  WHEN OTHERS THEN
    NULL; -- don't do anything and just return from the procedure
END;

Difference between WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers

Difference between WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers

WHEN-VALIDATE-ITEM and KEY-NEXT-ITEM triggers are very close to each other and create a lot of confusion. Following are three differences between them to clear the picture a little bit.

1. Whenever the user changes the value in the item and tries to move out of that item using ENTER or TAB or MOUSE, WHEN-VALIDATE-ITEM trigger is fired. But, in case of KEY-NEXT-ITEM trigger, if user moves out using MOUSE, it will not fire. So, the validation written on this trigger will not fire. Better use, WHEN-VALIDATE-ITEM trigger in this case as it also works with MOUSE.

2. KEY-NEXT-ITEM trigger fires before the WHEN-VALIDATE-ITEM trigger.

3. KEY-NEXT-ITEM trigger will fire every time you move to the next field from that field but WHEN-VALIDATE-ITEM will fire only when you have acutally made any changes to that item. If you have made no changes in the item, it will not fire when you move out this item.

Personally, I prefer to use WHEN-VALIDATE-ITEM trigger in many situations.

Oracle Forms Tutorials: WHEN-VALIDATE-ITEM trigger

Oracle Forms Tutorials: WHEN-VALIDATE-ITEM trigger

Consider that you have an oracle form on which there is a datablock which uses EMP table. EMP table has a column called SALARY. Now there is a contraint on the SALARY column that it should be greater than or equal to $1000. Your requirement is that whenever any user fills salary in the Oracle Forms ITEM (say ITEM_SALARY) and tabs out from that item, a validation should fire and if the value filled is not valid, it should give you an error message and does not let the cursor go to the other item. In these situations WHEN-VALIDATE-ITEM trigger is used. Following is the PLSQL code you should write on the WHEN-VALIDATE-ITEM trigger of the ITEM_SALARY item.

IF :ITEM_SALARY < 1000 THEN

    MESSAGE('ERROR: Salary must be at least $1000 or more.');

    RAISE FORM_TRIGGER_FAILURE; -- To keep the cursor in the item

END IF;

You should also go through this video on YOUTUBE by Edward Honour.

In this video, he tries to pick the department name when the user enters the department number. If department number does not exist in the database, he shows the error message and does not let the cursor to go to the other item using FORM_TRIGGER_FAILURE trigger. He has used NO_DATA_FOUND exception for showing the error message. Following is the code used in this video:

BEGIN

SELECT DEPT_NAME INTO :BLOCKNAME.ITEMNAME FROM DEPT WHERE        DEPT_NO = :BLOCKNAME.ITEMNAME2;

EXCEPTION

WHEN NO_DATA_FOUND THEN

MESSAGE('Invalid Department Number');

RAISE FORM_TRIGGER_FAILURE;

END

5 Things you should never discuss your manager

5 Things you should never discuss your manager

An employee should be fair and transparent with his manager, but few revelations can spoil your bonding with your manager. Try never ever talking about these things to your manager:

1. Your doubt on manager' decisions - At times, you may want to raise questions on his judgement. Do yourself a favour - give it a pass. You may not know what business pressures he/she is living through.

2. Snooping on manager's life - Every employee wants to check what his or her manager is doing in social life. Don't blow your cover by admitting to doing it unashamed.

3. Office gossip - Never share office hearsay with your manager without checking its truthfulness. Sharing something random that you heard in the cafeteria and reacting to it may get him or her thinking that you are not mature or trustworthy.

4. Your personal secrets - Your life and its constant struggles are for you to handle. Pouring it all out in front of your manager will put you in a vulnerable position.

5. Your expectations from the manager - The manager is mandated to put forward his/her expectations from you. But it does not mean you to go and tell the manager how you evaluate his/her skill sets!

Emoji by Name

Here is a method for typing Emoji by name but not by English name. This method is for writing Emoji by Chinese name. OSX provides a Pinyin Input Method for writing Chinese. Pinyin is a romanization of Chinese. When writing in pinyin a candidate window pops up which lists all possible Chinese characters 汉字 and Emoji.

Candidate Window - Frequency

Candidate Window — Emoji

Here is a small sample of the Emoji which can be typed using this Pinyin Input Method. Each line below starts with the pinyin followed by the Emoji. The pinyin can have multiple meanings, multiple candidate Chinese characters and hence multiple Emoji. Hopefully for the examples I have given below you will be able to work out the meanings from the Emoji. Some of the below pinyin represent objects and some represent emotions.

1. ai — ❤️ 😘 💗 💓 😍
2. bei shang — 😢 😭
3. che — 🚗 🚘
4. hou — 🐒 🐵
5. hua — 🌹 🌼 💐 🌷 🌸 🌺
6. ka fei — ☕️
7. kai xin — 😄 😺 😃 😆 ☺️
8. mao — 🐱 🐈 ⚓️
9. niu — 🐂 🐃 🐄 🐮
10. pi jiu — 🍺 🍻
11. sheng qi — 😠 😡 💢 😾
12. shu — 🌲 🌳 🌴 🐭
13. shui guo — 🍉 🍊 🍇 🍈 🍌 🍍 🍎 🍑 🍒 🍓 🍅 🍆 🍋 🍏 🍐
14. tuo la ji — 🚜
15. xiang — 🐘
16. xiao — 😊 😄
17. xie — 👟 👠
18. xue ren — ⛄️ ☃️
19. yin yue — 🎵 🎷 🎶 🎸 🎹 🎺 🎻 🎼 🎤 🎧 📯
20. yu — 🐟 🐠

Environment: OSX El Capitan v10.11.2

Unicode Regular Expressions

I have long been familiar with processing Unicode characters with RegExp (Regular Expressions). I was also aware that RegExp could be used to match Unicode characters based upon their Unicode assigned character properties. I had not yet though coded such property based RegExp. A few days ago I decided to explore this area.

An interesting property, for example, is the script to which a character belongs. e.g. \p{Hangul} will match with any character which belongs to the Hangul script. Hangul is the script used to write Korean.

I started with Perl and here is my simple Perl program:

#!/usr/bin/perl
if("노팅엄"=~/^\p{Hangul}+$/){print "korean\n";}else{print "not korean\n";}

...and this code did not work. I know that 노팅엄 is Korean hangul but my code disagreed. After much searching I discovered I needed to include the statement use utf8 which instructs Perl to use Unicode UTF8 encoding. So my working version of the code is:

#!/usr/bin/perl
use utf8;
if("노팅엄"=~/^\p{Hangul}+$/){print "korean\n";}else{print "not korean\n";}

...and now onto PHP using PCRE Perl Compatible RegExp. My initial RegExp was:

preg_match('/^\p{Hangul}+$/','노팅엄')

...and this did not work! We have already established that 노팅엄 is Korean hangul but my PHP code disagreed with me. After I investigated further I discovered there is a u modifier which directs the code to use Unicode UTF8 encoding. So add the u modifier and we now have a working code!

preg_match('/^\p{Hangul}+$/u','노팅엄')

For several years now, my standard practice is to save text files as Unicode UTF8 encoded files. This includes code files. One still, though, has to repeatedly and explicitly tell systems, programs, functions, utilities, processes to use Unicode. We seem still to be a long way from a total Unicode environment with everything being seamlessly and natively Unicode.

Environments: Perl v5.18.2; PHP v5.5.29