iPX社員によるブログ

iPX社員が"社の動向"から"自身の知見や趣味"、"セミナーなどのおすすめ情報"に至るまで幅広い話題を投下していくブログ。社の雰囲気を感じ取っていただけたら幸いです。

Windows と Emacs でのメモの取り方

初めに

また当番が回ってきました。砂子です。

何を書こうか迷いましたが、自分が行なっているEmacsでのメモの取りかたを 書いてみることにしました。もしかしたら既出の内容かもしれませんが、その 際はご容赦願います。

ある程度Emacsを知っている人向けの解説になります。

未来技術遺産にPC98シリーズが選ばれたのでそちらを書こうとも思いました が、それは次の機会にしましょう。http://sts.kahaku.go.jp/material/

前提

下記環境を前提とします。Windowsは多分7、8.xでも大丈夫です。 Emacsは本家のWindows版のバイナリを利用します。

記事の動作は上記で大丈夫ですが、本家版はIMEでの日本語入力に不具合が あります。ご注意ください。

WindowsEmacsを利用するのには幾つか方法があるのですが、私には強く推 薦できるものはありません。ここでは日本語入力には目を瞑って本家バイ ナリを使用します。

後述するemacsc.exeとemacsclientw.exeはEmacs本家のZIPを展開したbinフォ ルダに存在します。emacs.exeを実行するとEmacsが起動します。

Emacs

Emacs側では3つの事柄の説明が必要です。

  • org-mode
  • emacsclientw.exe
  • elisp

org-mode

org-modeはEmacs拡張機能の一つで独自のフォーマットで記述したテキス トファイルを操作して色々なことを実現します。

本記事で利用するのはメモをとる機能の org-capture とういうものです。 org-modeはEmacsに最初から付属していますから、利用に際して準備は必要 ありません。

emacsclientw.exe

emacsclientw.exeはEmacs本体を外部から操作する手段を提供するプログラ ムです。テキストファイルをコマンドラインからEmacsで編集したりできま す。

このプログラムを利用するためにEmacsの設定ファイルに下記を追加します。

(when (not (server-running-p))
  (server-start))

Emacsを再起動して、設定を反映させたら次のコマンドをコマンドプロンプ トで実行してみてください。

emacsclientw.exe -e "(make-frame)"

Emacsのウィンドウがもう一つ表示されれば設定は成功です。

elisp

上記でも少し触れましたが、Emacsは設定ファイルにelispというプログラ ミング言語を使って拡張します。

今回の目的の為に書いたelispは下記のようなものです。設定ファイルに書 きこんでEmacsを再起動します。

; メモ用のファイル指定とメモのテンプレートを指定
; ファイルは%USERPROFILE%フォルダに作成されます
(setq org-capture-templates
      '(("m" "Memo" entry (file+datetree "~/memo.org" "Memo")
         "* %?")))

; org-capture起動関数
(defun take-note ()
  (progn
    ; Emacsのウィンドウを最前面に移動
    (raise-frame)
    (set-buffer (car (buffer-list)))
    ; メモ用のバッファ表示
    (org-capture nil "m")))

Windows

必要なEmacsの準備は整ったのでWindowsでそれらを利用します。

  • ショートカットの作成
  • ショートカットキーの設定

ショートカットの作成

emacsclientw.exeのショートカットを作成します。作成したショートカッ トの名称を『take-note』とします。

そして、プロパティを開きリンク先の末尾に『 -e "(take-note)"』を追加 します。

これでこのショートカットを実行すると、起動しているEmacsが最前面に表 示されメモが書ける状態になります。

ショートカットキーの設定

ショートカットを作成しただけでは直ぐにメモを取れる状態とはいえませ ん。どのような状況からでも即座にメモを取れるようにショートカットキー を設定します。

そのためにまず作成したショートカットをスタートメニューに移動します。 エクスプローラのアドレスバーで『shell:start menu』でスタートメニュー のフォルダに移動できます。

移動したら再度プロパティでフォーカスをショートカットキーに移動させ、 このショートカットを起動するキーを決定します。ここではShift + Alt + \とします。

これでEmacsが起動している状態でショートカットキーを押せば、即座にメ モを取れます。

また、Windowsキーを押下して『take-note』と入力すればショートカット を実行できます。

結び

いかがだったでしょうか?Emacsをある程度知っていないと分からなかった かもしれません。

しかし、ショートカットを作成してショートカットキーで即座に実行や Windowsキーからキー入力で実行などは応用が効くと思います。

正直ショートカットキーがスタートメニューでだけ有効というのはこの機能 を考えたときに初めて知りました。プロパティにショートカットキーという 項目があったのは知っていたのですが。。。

お仕事がんばるぞい

NEW GAME!」とか「社畜ちゃん」とか、お仕事ネタの作品が最近話題になってますね。
がんばるぞい!が最初に話題になったのはもう2年前ですが・・・。

どうも、オタク方面担当の三浦です。

来週の土日に予定している、今年の慰労会(全体会議&社員旅行)の幹事長まで任されちゃってます。
まぁ行先を大洗を挙げた代償なんですけどね!!
ブログの担当があと1週間遅ければ、慰労会の内容をネタに出来たのになぁ・・・・・・。


今まで大したことを勉強してこなかったせいで、既にネタ切れなのですが・・・。
この前、社畜ちゃんの単行本に載っていたJavaScriptを書いてみました。
大学の時以来だから、5年ぶりくらいに触ったな・・・。

後半を何も見ずにフンフンちやってみましたが、
箱を開けてみたらランダムとif文でおみくじを作る感じでした。
そりゃまぁ参考書でもない漫画に載ってるものなのでそんなレベルなんでしょうけど。
久しぶりにプログラム書きましたが、やっぱり楽しいなぁと。
社畜ちゃんの職場は勘弁ですが。


今の職場はNEW GAME!ほど温い感じではなく、社畜ちゃんほど厳しくはない感じで。
特に不満は無いです、無いですが・・・
可愛い美少女が一杯の職場いいなぁ・・・。

人にモノを教えるということ

ご無沙汰しております。
ishizawaです。

最近急に寒くなってきましたね。
先週体調を崩して熱を出したのは私です。
皆さんも体調には気を付けましょう。

今日は私が最近よく行う新人の教育について整理も兼ねて書こうと思います。

続きを読む

インド出張

インドへ出張

iPXの鹿又です。
また出番が回ってきました。

iPXの私の所属するユニットでは、仕事柄、海外出張があります。
この間には、Kawaguchiさんがアメリカ出張に行ったことを書いていました。
これまで他の人も含め、フィリピン、インドネシア、台湾、ドイツ、アメリカ、中国への出張がありましたね。
いろんな人がいろんな場所に行くことがありますが、私は7月にインドに出張に行ってきました。

行った場所

出張先はインド南部 コインバトールというところで、あるサプライヤの開発部隊のあるところです。
成田空港より飛行機で8時間30分、デリーで一泊、国内線で3時間と、移動だけで20時間ぐらいの長旅になります。
f:id:ipx-writer:20161001233954j:plain

公用語は英語が含まれるため、かなりのお年寄り以外は英語で話せました。
とはいっても、一緒に行った2名と私を含め、英語が堪能にできる人は1人もおらず、意思疎通に苦労するという状態でした。
サプライヤの日本人担当者に会うまでの間、「これはたどり着けるのか?」と心配になってしまいます。
ここに2週間、英語漬けの日々が始まります。

ホテルから撮った写真です
結構綺麗です
f:id:ipx-writer:20161002000541j:plain
f:id:ipx-writer:20161002000558j:plain

小観光

2週間の行程でしたので、土日を挟むわけです。
地元の人に案内いただいて小観光を楽しみました。

寺院

内部は撮影禁止
シヴァ神を祭った寺院
有名な寺院だそうですが、名前はよくわかりませんでした
ありがたいお祈りをいただく (インドの人がよく額に付ける灰と赤いもの)
f:id:ipx-writer:20161002000806j:plain
f:id:ipx-writer:20161002000815j:plain

沐浴場

自然公園に地元の人が使う沐浴場があるということで行ってみました
雨の後なので水量が多い

自然公園の看板

f:id:ipx-writer:20161002001138j:plain

自然公園内

f:id:ipx-writer:20161002001209j:plain
f:id:ipx-writer:20161002001216j:plain

f:id:ipx-writer:20161002001234j:plain
f:id:ipx-writer:20161002001240j:plain

沐浴場

サプライヤの日本人担当者が地元民と沐浴していました
地元の学生が「ネパール人か?」と聞くので「日本人だ」と答えると、やたら一緒に記念写真を撮られました。
f:id:ipx-writer:20161002001342j:plain

おさるさん

人にとても慣れている (悪い意味で)
f:id:ipx-writer:20161002001408j:plain
その他にも、カメレオンやらがいました。
野良象が見えるときもあるそうですが、運はよくなかったみたいです。

ヨガセンター

有名なヨガセンターに行ってみました。
もちろん、内部は撮影禁止
中は沐浴しながらヨガする場所や音厳禁で洞窟内でヨガする場所などがありました。
全員で洞窟内で座って瞑想するヨガをやりました

シヴァ神の大きな胸像 (入口付近)
f:id:ipx-writer:20161002001910j:plain

ショッピングセンター

お土産を購入
f:id:ipx-writer:20161002001444j:plain

ぞうさん

f:id:ipx-writer:20161002000931j:plain

うしさん

f:id:ipx-writer:20161002000947j:plain

地元の祭り

子供がある年齢になるとやる祭りだとか
f:id:ipx-writer:20161002002449j:plain
f:id:ipx-writer:20161002002457j:plain
f:id:ipx-writer:20161002002504j:plain

街並み

f:id:ipx-writer:20161002002552j:plainf:id:ipx-writer:20161002002558j:plain
f:id:ipx-writer:20161002002605j:plainf:id:ipx-writer:20161002002613j:plain
f:id:ipx-writer:20161002002619j:plainf:id:ipx-writer:20161002002625j:plain
f:id:ipx-writer:20161002002633j:plainf:id:ipx-writer:20161002002700j:plain

食事とか

あまり食事の写真を撮りませんでした...
ほとんどはホテルで食事を採り、周辺で食べることはなかったです。
ホテルではビュッフェ形式。
だいたい毎日カレーだったので、日に日に皆が窶れていくのがわかります。
きっと日本人は本場のカレーから栄養は採れないようになっているのだと思います。

カレーとか

種類は豊富
南部ではライスが主食でナンはあまり食べない感じ

f:id:ipx-writer:20161001235624j:plain

ドーサ

ちょっと酸味のあるクレープのようなもの
マサラとかつけて食べる
美味しい
f:id:ipx-writer:20161001235614j:plain

デリー国際空港のラウンジでもカレーが......

日本に帰ってきて

一番初めに食べたのは幸楽苑のラーメンです。
幸楽苑のラーメンが本当に「旨い」と感じました。
カレーもいいですが、慣れた味が一番ですね。
帰国後、まだココイチには行っていません。

サプライヤとの会議はおおむねうまくいきましたが、まだまだ状況がよくなっている感じではありません。
また行くかもしれません。
不満なのは出張ではなく、サプライヤのソフトがいつまでも未完成であるということです....

「安全」と「安心」

約半年ぶりに登場します、加藤です。

今回は「安全」と「安心」について取り上げてみたいと思います。

はじめに

テスラの自動運転車(実際は自動運転ではなく運転支援機能なのですが)が死亡事故を起こしたり、豊洲市場の地下が空洞になっていたり、というニュースが世間を騒がせていますが、どうも一般向けのニュースでは安全と安心を混同したまま語られているように感じます。

では「安全」と「安心」の違いは何でしょうか?
この二つの言葉の意味を説明できますか?

弊社も製造業、特に自動車業界に関わる企業と仕事をさせて頂いていますので、正しく理解している必要があります。

「安全」と「安心」の違い

「安全」の定義はISOの中では用語として定義されています。

Safety
freedom from risk which is not tolerable
(許容できないリスクがないこと)

Risk
combination of the probability of occurrence of harm and the severity of that harm
(危害の発生確率とその危害の重大性の組み合わせ)

(ISO/IEC Guideより引用 https://www.iso.org/obp/ui/#iso:std:iso-iec:guide:51:ed-3:v1:en

ここで重要なのは「許容できないリスク」という表現でリスクの範囲を限定していることです。
リスクの定義も合わせて考えると、確率が低くて重大ではない危害まではカバーしていない、という事が分かります。

「安全」は「完全」ではないのがポイントです。

一方で「安心」については標準的な定義はありませんが、安全と対比しておおよそ以下のように定義されています。

安全:

  • 客観的な事実
  • 科学的に評価が可能
  • 許容できないリスクがない状態

安心:

  • 主観的な感情
  • 科学的に(外部から)評価が出来ない
  • リスクに対する寛容さは個人に依存する

安全はモノサシで測ることが可能ですが、安心は測ることが出来ない上に、安心かどうかの判断は完全に個人にゆだねられています。

「安心」できないのはなぜか?

上記の通り、安全と安心は異なる概念です。

多くの製造業ではISO規格などの品質マネジメントプロセスに則ることで「安全」を担保しています。

一方で一般の消費者にとって重要なのは「安心」です。

消費者に「安心」してもらうためには、製品を提供する側が「安全」であることを正しく説明することが必要です。

しかし、「安心」はは主観的な感情なので、全ての人に安心してもらうことは困難です。

なるべく多くの人に安心してもらうためには、以下のギャップを埋める事が必要となります。

その1:知識量のギャップ

ほぼ全ての事象において、説明する側は専門家であり、説明される側は素人です。
当然ながら、専門家と素人は持っている知識の量が異なる上に、素人の中でも知識量にもバラツキがあります。

また、

  • 知識が無い人は、理解できないので不安に思わない
  • ある程度知識がある人は、中途半端に理解するので不安度が高まる
  • 十分な知識を持った人は、正しく理解できるので不安度は低い

といった傾向があるそうです。

その2:リスク感度のギャップ

安心と感じる基準は個人差があります。
さらに、特に不安度が高い人達には「ゼロリスクを求める」という傾向があります。

上記の「安全」の定義にあるように、基本的にリスクはゼロではありません。
想定できない範囲はもちろんですが、致命的でない問題については許容することがあります。

発生確率の非常に低い現象や危険度の低い現象など、小さなリスクまで対応するにはそれ相応のコストがかかります。
当然、そのコストは製品やサービスの価格にも反映されます。

この2つのギャップを埋めるためには、説明する側が相手のリテラシーを考慮した上で、説明の方法を工夫する必要があります。

消費者の安心を獲得するために

安心というのは信頼の上に成り立つもので、これらは一朝一夕で獲得できるものではありません。

日ごろから

  • 正しい情報発信
  • 的確な顧客サポート
  • サービス、製品力の向上

に継続して取り組むことで、徐々に信頼感が蓄積されていくものです。

 

弊社では上記の取り組みの一つである「製品力の向上」を実現するための支援として、

  • 開発プロセス全体の改善
  • 新たな設計手法の導入
  • 開発業務を支援する仕組み作り

をメニューとして取りそろえています。

SQLチューニング

SDU(System Development Unit)のタキヤマです

半年前にDB関係で何か記事を…と書いていましたが、
海老名/厚木で開催されていた某10周年のまつりが忙しい中
順番が迫っているのを知ったので、何の準備も無いまま書いてみようかと思います。
(まつりの記事書いたら突き返されるかな?)

…とはいったものの、チューニング関係だとやっぱり実際にDB作って計測しながらでないと書くのは難しいので
とりあえず今回はSQLに少し触れてみます。

これもDBの種類やバージョン、データの状態とかオプティマイザの実行計画等々…によって
何が最適なのかは変わってきてしまうのでこう書けば必ず早くなるといったものでもないです。



例えば以下のようなものがあります。


INよりEXISTSを使う ※Oracle, PostgreSQL除く

--【遅】
SELECT * FROM A WHERE A.id IN(SELECT B.id FROM B);
--【早】
SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);

EXISTSでは*を使う

--【遅】
SELECT * FROM A WHERE EXISTS(SELECT B.name FROM B WHERE A.id = B.id);
--【早】
SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);

COUNTはCOUNT(列)を使う ※Oracleを除く

--【遅】
SELECT COUNT(*) FROM A
--【早】
SELECT COUNT(id) FROM A

WHERE句の列に対して演算や関数を使うとインデックスが使用できない

--【遅】
SELECT * FROM A WHERE num * 10 > 100
--【早】
SELECT * FROM A WHERE num  > 100 / 10

ORはなるべくINを使う

--【遅】
SELECT * FROM A WHERE name = 'a' OR name = 'Bb'
--【早】
SELECT * FROM A WHERE name IN ('a','b')

ORDER BY句では列番号を使わない

--【遅】
SELECT id, name FROM A ORDER BY 1
--【早】
SELECT id, name FROM A ORDER BY id

テーブルの結合は絞り込んでから行う

--【遅】
SELECT * FROM A, B WHERE A.id = B.id AND B.num > 100;
--【早】
SELECT * FROM A, (SELECT * FROM B WHERE B.num > 100) C WHERE A.id = C.id;

などなどなどなど
書ききれないくらい色々あったりします。




では最後に
こんな3つのテーブルがあるとします。
主キー、外部キー以外にインデックスは作成しないものとします。
SQLは標準SQLでは無くOracle準拠です

CREATE TABLE item (
	item_id		NUMBER	PRIMARY KEY
,	item_name	VARCHAR(40)
,	price		NUMBER
);


CREATE TABLE customer (
	cstmr_id	NUMBER	PRIMARY KEY
,	cstmr_name	VARCHAR(40)
,	age		NUMBER
);


CREATE TABLE order (
	order_id	NUMBER	PRIMARY KEY
,	item_id		NUMBER
,	cstmr_id	NUMBER
,	order_date	DATETIME
,	FOREIGN KEY (item_id)	REFERENCES item (item_id)
,	FOREIGN KEY (cstmr_id)	REFERENCES customer (cstmr_id)
);


20代の20時~22時の注文のうち、新しいものから順に1000件の中で
売上合計が高い商品順に並べる。

これを以下のようなSQLで検索しようとしたところ
想定していたよりもレスポンスが悪い結果となりました。

ではこのSQLをどのように書き換えたらレスポンスが改善できるでしょうか?

SELECT	NarrowOrder.item_name	as "商品名"
,	COUNT(*)		as "売上件数"
,	SUM(NarrowOrder.price)	as "売上合計"
FROM  (
	SELECT	item_name
	,	price
	FROM  (
		SELECT	item.item_name
		,	item.price
		FROM	order
		,	customer
		,	item
		WHERE	customer.cstmr_id	= order.cstmr_id
		AND	item.item_id		= order.item_id
		AND	customer.age		>= 20
		AND	customer.age		< 30
		AND	TO_CHAR(order.order_date, 'hh24:mi:ss') >= '20:00:00'
		AND	TO_CHAR(order.order_date, 'hh24:mi:ss') <  '22:00:00'
		ORDER BY	order.order_id	DESC
	)
	WHERE	ROWNUM >= 1000
) NarrowOrder
GROUP BY	NarrowOrder.item_name
ORDER BY	3	DESC
;


以下のSQLは一例となりますが、
おそらく先程のSQLと比較すると、
データ量が多ければ多いほどはっきりと差が出てくると思われます。
(実際に試してはいないので説得力は弱いですが)

SELECT	item.item_name	as "商品名"
,	COUNT(*)	as "売上件数"
,	SUM(item.price)	as "売上合計"
FROM  (
	SELECT	item_id
	FROM	(
		SELECT	item_id
		FROM	order
		WHERE	cstmr_id in (	SELECT	cstmr_id
					FROM	customer
					WHERE	age	>= 20
					AND	age	<  30
				)
		AND		TO_NUMBER(TO_CHAR(order.order_date, 'hh24miss')) BETWEEN 200000 AND 220000
		ORDER BY	order_id	DESC
	)
	WHERE	ROWNUM >= 1000
) NarrowOrder
JOIN	item
	ON	NarrowOrder.item_id = item.item_id
GROUP BY	item.item_name
ORDER BY	SUM(item.price)	DESC
;

※1000件の絞込みはOracle12cからインラインビューでROWNUMを使わなくとも
 Order by句の次に「FETCH FIRST 1000 ROWS ONLY」と記載することも出来ます。


ポイントはデータの絞込みと結合の順番になります。


まずはユニークなデータであるcustomerを絞り込んでおき、
対象のデータを減らした上でorderと結合しています。


また、itemの結合をデータ件数の一番多いであろうorderでは無く、
検索条件を満たした上で1000件に絞った状態のNarrowOrderに対して行うようにしています。


注文時間の絞込みについては文字列で行わず、数値で行うようにし、かつBETWEENを使用するようにしています。

※インデックスを作成する場合はorderテーブルにcstmr_idとorder_dateの複合インデックスを作りヒント句で強制、日付型のままBETWEENを使わない方が早くなります



と、ここまで書いてみましたが、実際にはコストベースオプティマイザだと
しばらく使っているうちに統計情報からどんな実行計画が作られるかにもよってくるので
実践でのチューニングは色々と手間が掛かってくるわけです。

次回順番が回ってきた時は、実際のDBを使用したチューニングでもやってみようかと思います(たぶん)


あ、そろそろ今シーズンのスノボ旅行の予約もしないと…
今回も雪まつりと重なりそうなので、次回更新が北海道日記にならないように気を付けます