夕飯アルゴリズムを考えた

バランスよく見える夕食を作る基本アルゴリズム

1. 基本は1汁2菜
2. 平日は肉(牛・豚・鶏)系と魚系を交互に出す
3. 赤・黄・緑・茶・白の彩りを意識する
4. 冷凍野菜や乾物などのお助け食材を常備する

1つ目「1汁2菜」

ご飯と味噌汁、主菜、副菜ですね。夜食べすぎると次の日に響きますし、一つのおかずに使う食材を増やせば胃も心も、見た目も満たされる気がします。

ご飯はたまに十五穀米を混ぜたり、炊き込みご飯にしたり、ゆかりなどのふりかけをかけて味付きご飯にすると家族に喜ばれます。

汁物は基本、味噌汁ですが、バリエーションを増やすために白だしやめんつゆを使ったお吸い物も作ります。

主菜、副菜は一応バランスを考えます。主菜があっさりしたもの、少量の場合は副菜はがっつりしたり。主菜が脂っこい場合は副菜はさっぱりさせたり似たモノは出しません。

2つ目「肉と魚を交互に」

肉と魚は基本交互に作ります。焼いたり、煮たり、炒めたり、肉は種類を変えればいろんな味や調理法で作れます。これで平日はなんとか持ちこたえられます。土日はお好み焼きやチャーハン、鍋、適当です。食材と調理法についてはまた今度詳しく話しましょう。

3つ目「彩り」

赤・黄・緑・茶・白って5色も？！と思うかもしれませんが、赤か緑どちらかがあれば4色でもバランスよく見えます。赤、緑を出すために、トマトやブロッコリーが常備してあります。彩りについてはまたどこかで詳しく話しましょう。

4つ目「お助け食材」

アルゴリズムに従っても面倒なときありますよね。そんな時はすぐに食べられる食材を何種類が準備しておきます。焼くだけのフライや胡麻豆腐なら何にも考えずにひょいと出せます。ツナ缶があれば卵と炒めて副菜一品。わかめやひじきがあれば和え物にしてこれまた一品。カット済みの冷凍野菜、ブロッコリーやごぼうがあればサラダに加えたり、きんぴらにしたり、主菜に加えて炒めたり。お助け食材についてもまたいつか詳しく話しましょう。

[APEX]認証方式をLDAP認証にする

• 概要

APEX4.0@Oracle11gではデフォルトのままではLDAP認証できない。

10gでは何の問題もなくWEB画面で設定するのみで認証できたがナゼ・・？

原因は不明でLDAP API作って実装しました

• 経緯

SQL/PLUSで直接LDAP認証を試みてみる。

DECLARE
retval PLS_INTEGER;
my_session DBMS_LDAP.session;

BEGIN
retval:= -1;
my_session:= DBMS_LDAP.init('ldap.host.com',389);
retval:=DBMS_LDAP.simple_bind_s(my_session,'uid=my-id,ou=ldap,ou=host,c=com',my-password');
END;

エラーが…

ORA-31202: DBMS_LDAP: LDAP client/server error: Invalid credentials

いろいろ調べてみると…。

セキュリティーの為、UTL_TCP, UTL_HTTP, UTL_SMTP, UTL_MAIL, UTL_INADDRといったPL/SQLパッケージのメソッドを実行するには、ACLベースの権限を付与する必要がある。
ACL を付与するには、DBMS_NETWORK_ACL_ADMIN パッケージで行う。
存在するACL は、DBA_NETWORK_ACLS ,DBA_NETWORK_ACL_PRIVILEGES ビューで参照可能。

とのこと。
おそらくLDAP通信にてUTL_TCPあたりのパッケージを使っているのだろう。

sqlplusにてDBAでログイン

SQL> conn test/test@xe as sysdba

現在の状況を確認

select * from dba_network_acls;
select * from dba_network_acl_privileges;

APEXでLDAP認証できるように、ACLを作成（ldap.xmlは任意のACL名？、スキーマ名はEDU、ldap.host.comはホスト名）

begin
-- ACLを作成
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('ldap.xml', 'ACL for ldap', 'EDU',true,'connect');
-- ユーザーにACLで定義した権限を割り当て
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE('ldap.xml','EDU',true,'resolve');
-- ACLに対応する接続先を割り当て
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('ldap.xml','ldap.host.com');
end;
/

正常に設定されると以下のメッセージが表示される。

PL/SQL procedure successfully completed.

ACLを削除するときは以下のプロシージャを実行します。

DBMS_NETWORK_ACL_ADMIN.DROP_ACL('ldap.xml');

と、これでうまくいくはずだったのですが結局できず…
以下のファンクションを作って対処することになりました…
むむぅ・・・

-----

create or replace function LDAP_AUTH(p_username in varchar2, p_password in varchar2)
return BOOLEAN
is

userdn varchar2(4000);
userpassword varchar2(4000);

retval PLS_INTEGER;
my_session DBMS_LDAP.session;

begin
-- 認証対象のユーザのDN
userdn:= 'uid=' || p_username || ',ou=ldap,ou=host,o=com';
userpassword:= p_password;

retval:= -1;
my_session:= DBMS_LDAP.init('ldap.host.com',389);
retval:= DBMS_LDAP.simple_bind_s(my_session, userdn, userpassword);

 if (retval = -1) then
   return false;
 else
   return true;
 end if;

end;

[APEX]オートナンバー機能を実現するにはシーケンスを作成してからトリガを作成すること

• 概要

APEX　Oracle11gシーケンスオブジェクトを作成してからトリガを作成すること

APEXでテーブル定義をエクスポートしたが、中途半端にしかエクスポートされてないんだなとはまった話

• 経緯

今、コメントを登録するためのアプリケーションをAPEXで作っています。

WEBインターフェースから必要な項目を入力するとOracleのテーブルにインサートされます。
対象のテーブル「COMMENT」テーブルにはIDとして自動で連番を振るようにしています。
つまり、オートナンバー機能を持たせています。

開発用（10g）のAPEX（3.x）から運用用（11gXE）のAPEX（4.x）にテーブル定義をエクスポートしてみたが、
トリガはエクスポートされるものの、シーケンスオブジェクトはエクスポートされねえんだな。

ずいぶんはまった。

シーケンスオブジェクトがないのにトリガを作成しようとすると
以下のエラーになります。

Compilation failed, line 3 (18:35:12) The line numbers associated with compilation errors are relative to the first BEGIN statement. This only affects the compilation of database triggers.
PL/SQL: ORA-02289: sequence does not existCompilation failed, line 3 (18:35:12) The line numbers associated with compilation errors are relative to the first BEGIN statement. This only affects the compilation of database triggers.
PL/SQL: SQL Statement ignored

• 対応策

シーケンスオブジェクトを作成する

create sequence "＜シーケンス名＞"
start with ＜開始番号＞
increment by ＜カウントアップ数＞
maxvalue ＜最大数＞
minvalue ＜最小数＞
nocache ＜事前にメモリにキャッシュしておくか＞
nocycle ＜繰り返し有無＞
noorder ＜設定どおりの順序でナンバリングするか＞
/

create sequence "TEST_SEQ"
start with 1
increment by 1
maxvalue 100
minvalue 1
nocache
nocycle
noorder
/

トリガを作成する

create or replace TRIGGER  "＜トリガ名＞"
BEFORE INSERT ON "＜トリガを作成するテーブル名＞"

FOR EACH ROW

BEGIN
 IF :NEW.＜列名＞ IS NULL THEN
   SELECT ＜シーケンスオブジェクト名＞.NEXTVAL INTO :NEW.＜列名＞ FROM DUAL;
 END IF;
END;

create or replace TRIGGER  "TEST_ID"
BEFORE INSERT ON "TEST_TABLE"

FOR EACH ROW

BEGIN
 IF :NEW.ID IS NULL THEN
   SELECT TEST_SEQ.NEXTVAL INTO :NEW.ID FROM DUAL;
 END IF;
END;

11gから直接シーケンスオブジェクトにアクセス（値を挿入）できるようだが
うまくいかなかったのであきらめることにした。

動かなかった
原因はおいおい考えるとして…間違っているSQLをメモ。

NEW."ID" := TEST_SEQ.NEXTVAL

To protect a cutting board from a stachybotrys chartarum

Stachybortrys chartarum likes a cutting board that it is wet, warm, fertile.

The following should be done after using a cutting board.

1. Washing it very well with a soap.
2. Dry it at well-ventilated place.
3. sometime marinate it bleach.

----
黒カビは濡れていて、少し暖かくて、栄養がたっぷりのまな板が大好きだ。
まな板を黒カビから守るには以下のことをする。

1. 洗剤でよく洗う
2. 風通しのいいところで乾かす
3. 時々漂白剤に漬け込む

6 Tips for making a user manual (1)

ユーザーマニュアルについての悪いうわさがある。アメリカでのある調査、、
「あなたを混乱させる可能性のある技術的なものってなに？
という質問に対しなんとユーザーマニュアルがトップに！
企業はもう一度マニュアルについて考えなおしてみてもいいかもしれない。（Philip Hodgson posted）

ってことでマニュアルってたしかに難しい。
私も先日自社製品に関わるマニュアルを書いてみたけど
24ページの仕様をまとめるのに1ヶ月ぐらいかかったし、
改善の余地があるんじゃないかと今なおあれこれ試行錯誤しています。
その中で感じたコトと今回この記事を読んでまさにこれと同じコトやってた！
と思ったので少し深く読み込んでいきたいと思います。

ということで今回はマニュアルのユーザービリティについての話です。

----

ベストプラクティスとしての原則だったり、
『読む』ということに関する人間の知覚や認知、心理などの側面だったり、
また、世にあるあらゆるマニュアルやドキュメントをテストした結果と基にまとめています。

    * General guidelines
    * How to create a great first impression
    * How to enhance findability
    * How to give instructions
    * How to design individual pages
    * How to design the physical manual

では一つ目からみていきましょう。

General Guideline for user manuals
（ユーザーマニュアルの一般的なガイドライン）

• 物理的に存在するユーザーマニュアルを製品に添えて提供すること：PDFで読ませてはいけない
• あらゆる点で製品を網羅した説明がなされているか確認すること
• １ページに収まる量のクイックスタートが含まれていること
• 手順をステップバイステップで説明すること
• どんな機能があるのか伝えること、特に何のためにその機能があるのかも伝えること、
• どのように使うのか説明することは適切ではない
• マニュアル作成者は製品のデザインチームのメンバであること
• ユーザーマニュアルは製品の開発タイムラインと並行して作成すること。
• 出荷ギリギリのプレッシャーの下では作成しない
• マニュアル作成者は製品を実際に持っていて、製品を理解していて、そして実際に製品を使いながらマニュアルを作成すること
• 弱視や視覚障害を持った方へ配慮すること代替的なマニュアルとして点字、大きな文字、音声などを提供する
• ユーザーマニュアルと実際の利用者（障害者を含む）に製品のユーザーテストをおこなってもらうこと

このガイドラインで注目すべきは5つ目です。
「何のためにその機能があるのかを伝えること」
これは私も間違えてしまうことでその機能の使い方ばっかり書いてしまうんですよね。

例えば、GUI画面のマニュアルを書く時、画面項目の説明を中心に書きます。
これはワークフローの申請タイプです。申請タイプは「新規登録」「更新」「セルフメンテナンス」から選択できます。
ってかんじでね。新規登録用のワークフローを作成したいユーザーはこの説明を見てあぁ、これか、って思いますが
そうではない人はこれだけを見てもどの申請タイプがどう働くのかわかりませんよね。

でもいつも製品を作るときって勢いが重要なときもあって、
なんとなくのコンセプトで作ってしまうことがあるし、
ユーザーからのフィードバックを何の気なしに受けて製品に反映させてしまうこともあるので
実際に製品が完成してみると仕様が変わっていることもよくあります。
トータルで見るとちぐはぐな仕様になっていることもしばしばあります。

そんな中でマニュアルを作成しても一貫性のないものになってしまい余計ユーザーは混乱してしまうかもしれません。

そこで仕様を一度マニュアルとして明文化してみるといいかもしれません。
設計書とは違います。もっとユーザー目線で記述されるものです。
初めて製品を見た人が「これを使うとこういうことができるんだ」というのがわかるようなものです。

私は以下の流れで書くことが多いです。
誰が、いつ、何のために使う機能か。
その機能を使うと何が出来るのか、を明らかにします

アカウント情報変更機能はログインユーザーが自身のアカウント情報を変更するため機能です。
アカウント情報に変更が生じた場合、WEBブラウザから自身のアカウント情報を変更することができます。
変更内容は管理者ユーザーが承認後、反映されます。

そして、必要に応じてどのようにその機能を使うか、を明らかにします。
ここに記載される内容はリファレンスマニュアルとしての内容を含むと思います。

XX設定画面に表示されるツリーを展開し、変更可能なアカウント情報を設定します。

誰が、いつ、何のために使う機能かを明文化するには少なくとも製品仕様について十分理解している必要があります。
また、マニュアルを作成する人は製品開発チームの一人であり、プロダクトオーナーと開発者との架け橋になることも大切かなと思います。ビジネスの目標に対するプロダクトを作るためのプロダクトオーナーとそれを遂行する開発者、双方の思いをユーザー目線のワンクッションを挟むコトができるのがマニュアル作成者なのですから。



では次回は「How to create a great first impression（偉大なる第一印象を与える方法）」についてみていきたいと思います。


原文：http://www.userfocus.co.uk/articles/usermanuals.html

The UX Job Title Generator

 とても興味深いw記事があったので和訳してみたいと思います。

 Many thanks David Travis!
----

あなたの肩書きはなんですか？


私はUXにかかわる人々の職種についてちょっとした調査のためTwitterで聞いてみました。
（John Knight、何人かから提供されたデータを含む）結果を基にUX肩書きジェネレータをここに発表します。


もちろん、肩書きはUXチームにとって必要とされるスキルの決定するのに利用されるものではありません。

私はこれを’レオナルドダヴィンチのように設計する方法’の延長のようなものと考えています。


使い方：一番左の列から年功（例えば’Lead’）を選択します。真ん中の列から実践にもっとも近いもの（'ユーザーエクスペリエンス’）を付け加えます。最後に役割にもっとも近いもの（’デザイナー’を選択します。このジェネレータで882種類のUXに関する職種が生成できます。

UX職種ジェネレータ,Ver1

年功	実践	役割
シニア （原：Senior）	ユーザービリティ （原：Usability）	アナリスト （原：Analyst）
ジュニア　※4 （原：Junior）	ユーザー中心設計 （原：User Centered Design）	アーキテクト （原：Architect）
ヘビーウェイト　※３ （原：Heavyweight）	ユーザーエクスペリエンス（UX) （原：User Exprience）	チャンピオン　※１ （原：Champion）
ミドルウェイト　※３ （原：Middleweight）	ヒューマンファクター （原：Human Factors）	コンサルタント （原：Consultant）
チーフ （原：Chief）	ビジュアル （原：Visual）	デザイナー （原：Designer）
リード （原：Lead）	コンテンツ （原：Contents）	デベロッパー （原：Developer）
	インフォメーション （原：Information）	ディレクター （原：Director）
	インタラクション （原：Interaction）	エキスパート （原：Expert）
		マネージャー （原：Manager）
		プラクティショナー　※２ （原：Practitioner）
		プロフェッショナル （原：Profesional）
		リサーチャー （原：Reasercher）
		スペシャリスト （原：Specialist）
		ストラテジスト （原：Strategist）

データについて

51人がTwitterを使って調査したところ、259の職種がリストアップされました。（もし調査に参加してくれた人がいたら、ありがとう！）。たくさんの職種が重複しているか、似ていることがわかりました。いくつか年功に関する修飾子（ヘビー級、ミドル級、奇妙ですがライト級は除外して）を足しました。これは求職広告で見たものです。また、いくつか実践に関する語で、実際に存在するのに漏らしていた語（ユーザー中心設計やヒューマンファクター、Twitterの世界は実に偏ったサンプルに偏っています）を足しました。


謝辞

JohnKnight（ユーザビリティニュースの編集者でヘッドロンドンのUXアーキテクト）に感謝をこめて。彼の、UXにおけるコンピテンシーの発表を共有することができました。このコラムのタイトルは彼のUXの役割における分析を参考にしています。


-David Travis

原文：http://www.userfocus.co.uk/articles/ux_job_title_generator.html

----

表の中についてはカタカナ表記で和製英語っぽいほうがしっくりしたので日本語には訳しませんでしたが、日本語でイメージしやすいよういくつか補足します。（あくまで個人の見解です）

※1　勝者！というイメージがありますが推進派、支持者という意味もあるようです。ユーザービリティ推進者というような語になるのでしょうか・・・

※2　実践者、という意味です。

※3　あまりなじみません…。有力者という意味があるようですから名誉会長とか名誉教授的な超大御所な感じを出したいときに使うのも手ですｗ

※4　ちょっと若手、ってイメージなので「補」って入れるといいかもしれません。例えばUXデザイナー補、という感じにするとアシスタント的な意味合いが出るような気がします。

このデータを基にいくつか魅力あふれる肩書きを検討したいと思います。
それは次回以降で…