pochi-pの絵日記

2017-09-17 SQLiteでメールのDateヘッダーを変換

[][][]SQLiteでメールのDateヘッダーを変換 SQLiteでメールのDateヘッダーを変換を含むブックマーク

SQLite3では「Tue, 3 Aug 1999 23:10:00 +0900」とか対応日付関数正規表現置換も出来なくて厄介…

「過去のメールからメアドをGREPし、同時にDateヘッダーからやり取りした日付も取得する」という作業をしていました。メールデータはプレーンテキスト、抽出にはとりあえず適当なGREPを使い【ファイルパス、Dateヘッダー、From|To|Cc|BCCヘッダー】を抽出します。*1

抽出済みのデータがこんな感じです。

SELECT file, date_, mail FROM den8wk1_view;
filedate_mail
Y:\Sample\Denshin8\IN\0000.TXTTue, 3 Aug 1999 23:10:00 +0900From: mag2 <mag2from@tegami.com>
Y:\Sample\Denshin8\IN\0000.TXTTue, 3 Aug 1999 23:10:00 +0900To: pochi-p@example.com

目的はメアドの使用順の調査なので、ここから日付順にソートしたりしたい訳です。しかしRFC822で定義されている書式はソート処理に不向きな形式の文字列です。

From:フィールドのフォーマットは,RFC822で定義されている次のフォーマットに従います。

[daytime,] d mon yy hh:mm[:ss] zone

[daytime,] dd mon yy hh:mm[:ss] zone

[daytime,] d mon yyyy hh:mm[:ss] zone

[daytime,] dd mon yyyy hh:mm[:ss] zone

http://itdoc.hitachi.co.jp/manuals/3020/30203D1390/0173.htm

(……FromではなくDateの気がしますが、まあtypoは無視して続けます。)


最終的にソート&閲覧しやすくする為に下記の結果が欲しいです。

filedate_mailyyyymmdd
Y:\Sample\Denshin8\IN\0000.TXTTue, 3 Aug 1999 23:10:00 +0900From: mag2 <mag2from@tegami.com>19990803
Y:\Sample\Denshin8\IN\0000.TXTTue, 3 Aug 1999 23:10:00 +0900To: pochi-p@example.com19990803

DBによっては変換関数があるかもしれませんが、今回使用するのはSQLite3です。標準で実装されている日付関数strftimeでは上記形式に対応していないようです。

正規表現で適当に加工しようにも、SQLite3には正規表現の検索/置換機能は現在実装されていない様です。

という事はSQLite3では自作の関数を別途作る必要があるのでしょうか…。正直面倒過ぎるのでもっと楽に解決したいです。


という訳で、それを力業で何とかするのが今回の課題。さっそく実際のSQLを見ていきましょう。


(1)CASEとLIKEで何とかする

偉い人も言ってます。「正規表現が使えないならLIKEを使えば良いじゃない」と。まあLIKEだけでは置換出来ないのでCASEを使って条件分けしてしまいましょう。力業 is Power!

SELECT
  file
  , date_
  , mail 
  , CASE 
    WHEN date_ LIKE '% 2000 %' THEN '2000'
    WHEN date_ LIKE '% 2001 %' THEN '2001'
    WHEN date_ LIKE '% 2002 %' THEN '2002'
    WHEN date_ LIKE '% 2003 %' THEN '2003'
    WHEN date_ LIKE '% 2004 %' THEN '2004'
    WHEN date_ LIKE '% 2005 %' THEN '2005'
    WHEN date_ LIKE '% 2006 %' THEN '2006'
    WHEN date_ LIKE '% 2007 %' THEN '2007'
    WHEN date_ LIKE '% 2008 %' THEN '2008'
    WHEN date_ LIKE '% 2009 %' THEN '2009'
    WHEN date_ LIKE '% 2010 %' THEN '2010'
    WHEN date_ LIKE '% 2011 %' THEN '2011'
    WHEN date_ LIKE '% 2012 %' THEN '2012'
    WHEN date_ LIKE '% 2013 %' THEN '2013'
    WHEN date_ LIKE '% 2014 %' THEN '2014'
    WHEN date_ LIKE '% 2015 %' THEN '2015'
    WHEN date_ LIKE '% 2016 %' THEN '2016'
    WHEN date_ LIKE '% 2017 %' THEN '2017'
    WHEN date_ LIKE '% 00 __:%' THEN 2000
    WHEN date_ LIKE '% 01 __:%' THEN 2001
    WHEN date_ LIKE '% 02 __:%' THEN 2002
    WHEN date_ LIKE '% 03 __:%' THEN 2003
    WHEN date_ LIKE '% 04 __:%' THEN 2004
    WHEN date_ LIKE '% 05 __:%' THEN 2005
    WHEN date_ LIKE '% 06 __:%' THEN 2006
    WHEN date_ LIKE '% 07 __:%' THEN 2007
    WHEN date_ LIKE '% 08 __:%' THEN 2008
    WHEN date_ LIKE '% 09 __:%' THEN 2009
    WHEN date_ LIKE '% 10 __:%' THEN 2010
    WHEN date_ LIKE '% 11 __:%' THEN 2011
    WHEN date_ LIKE '% 12 __:%' THEN 2012
    WHEN date_ LIKE '% 13 __:%' THEN 2013
    WHEN date_ LIKE '% 14 __:%' THEN 2014
    WHEN date_ LIKE '% 15 __:%' THEN 2015
    WHEN date_ LIKE '% 16 __:%' THEN 2016
    WHEN date_ LIKE '% 17 __:%' THEN 2017
    END yyyy
  , CASE 
    WHEN date_ LIKE '%Jan%' THEN '01'
    WHEN date_ LIKE '%Feb%' THEN '02'
    WHEN date_ LIKE '%Mar%' THEN '03'
    WHEN date_ LIKE '%Apr%' THEN '04'
    WHEN date_ LIKE '%May%' THEN '05'
    WHEN date_ LIKE '%Jun%' THEN '06'
    WHEN date_ LIKE '%Jul%' THEN '07'
    WHEN date_ LIKE '%Aug%' THEN '08'
    WHEN date_ LIKE '%Sep%' THEN '09'
    WHEN date_ LIKE '%Oct%' THEN '10'
    WHEN date_ LIKE '%Nov%' THEN '11'
    WHEN date_ LIKE '%Dec%' THEN '12'
    END mm
  , CASE 
    WHEN date_ LIKE '%, 1 %' THEN '01' 
    WHEN date_ LIKE '%, 2 %' THEN '02' 
    WHEN date_ LIKE '%, 3 %' THEN '03' 
    WHEN date_ LIKE '%, 4 %' THEN '04' 
    WHEN date_ LIKE '%, 5 %' THEN '05' 
    WHEN date_ LIKE '%, 6 %' THEN '06' 
    WHEN date_ LIKE '%, 7 %' THEN '07' 
    WHEN date_ LIKE '%, 8 %' THEN '08' 
    WHEN date_ LIKE '%, 9 %' THEN '09' 
    WHEN date_ LIKE '%, 01 %' THEN '01' 
    WHEN date_ LIKE '%, 02 %' THEN '02' 
    WHEN date_ LIKE '%, 03 %' THEN '03' 
    WHEN date_ LIKE '%, 04 %' THEN '04' 
    WHEN date_ LIKE '%, 05 %' THEN '05' 
    WHEN date_ LIKE '%, 06 %' THEN '06' 
    WHEN date_ LIKE '%, 07 %' THEN '07' 
    WHEN date_ LIKE '%, 08 %' THEN '08' 
    WHEN date_ LIKE '%, 09 %' THEN '09' 
    WHEN date_ LIKE '%, 10 %' THEN '10' 
    WHEN date_ LIKE '%, 11 %' THEN '11' 
    WHEN date_ LIKE '%, 12 %' THEN '12' 
    WHEN date_ LIKE '%, 13 %' THEN '13' 
    WHEN date_ LIKE '%, 14 %' THEN '14' 
    WHEN date_ LIKE '%, 15 %' THEN '15' 
    WHEN date_ LIKE '%, 16 %' THEN '16' 
    WHEN date_ LIKE '%, 17 %' THEN '17' 
    WHEN date_ LIKE '%, 18 %' THEN '18' 
    WHEN date_ LIKE '%, 19 %' THEN '19' 
    WHEN date_ LIKE '%, 20 %' THEN '20' 
    WHEN date_ LIKE '%, 21 %' THEN '21' 
    WHEN date_ LIKE '%, 22 %' THEN '22' 
    WHEN date_ LIKE '%, 23 %' THEN '23' 
    WHEN date_ LIKE '%, 24 %' THEN '24' 
    WHEN date_ LIKE '%, 25 %' THEN '25' 
    WHEN date_ LIKE '%, 26 %' THEN '26' 
    WHEN date_ LIKE '%, 27 %' THEN '27' 
    WHEN date_ LIKE '%, 28 %' THEN '28' 
    WHEN date_ LIKE '%, 29 %' THEN '29' 
    WHEN date_ LIKE '%, 30 %' THEN '30' 
    WHEN date_ LIKE '%, 31 %' THEN '31' 
    WHEN date_ LIKE '1 %' THEN '01' 
    WHEN date_ LIKE '2 %' THEN '02' 
    WHEN date_ LIKE '3 %' THEN '03' 
    WHEN date_ LIKE '4 %' THEN '04' 
    WHEN date_ LIKE '5 %' THEN '05' 
    WHEN date_ LIKE '6 %' THEN '06' 
    WHEN date_ LIKE '7 %' THEN '07' 
    WHEN date_ LIKE '8 %' THEN '08' 
    WHEN date_ LIKE '9 %' THEN '09' 
    WHEN date_ LIKE '01 %' THEN '01' 
    WHEN date_ LIKE '02 %' THEN '02' 
    WHEN date_ LIKE '03 %' THEN '03' 
    WHEN date_ LIKE '04 %' THEN '04' 
    WHEN date_ LIKE '05 %' THEN '05' 
    WHEN date_ LIKE '06 %' THEN '06' 
    WHEN date_ LIKE '07 %' THEN '07' 
    WHEN date_ LIKE '08 %' THEN '08' 
    WHEN date_ LIKE '09 %' THEN '09' 
    WHEN date_ LIKE '10 %' THEN '10' 
    WHEN date_ LIKE '11 %' THEN '11' 
    WHEN date_ LIKE '12 %' THEN '12' 
    WHEN date_ LIKE '13 %' THEN '13' 
    WHEN date_ LIKE '14 %' THEN '14' 
    WHEN date_ LIKE '15 %' THEN '15' 
    WHEN date_ LIKE '16 %' THEN '16' 
    WHEN date_ LIKE '17 %' THEN '17' 
    WHEN date_ LIKE '18 %' THEN '18' 
    WHEN date_ LIKE '19 %' THEN '19' 
    WHEN date_ LIKE '20 %' THEN '20' 
    WHEN date_ LIKE '21 %' THEN '21' 
    WHEN date_ LIKE '22 %' THEN '22' 
    WHEN date_ LIKE '23 %' THEN '23' 
    WHEN date_ LIKE '24 %' THEN '24' 
    WHEN date_ LIKE '25 %' THEN '25' 
    WHEN date_ LIKE '26 %' THEN '26' 
    WHEN date_ LIKE '27 %' THEN '27' 
    WHEN date_ LIKE '28 %' THEN '28' 
    WHEN date_ LIKE '29 %' THEN '29' 
    WHEN date_ LIKE '30 %' THEN '30' 
    WHEN date_ LIKE '31 %' THEN '31' 
    END dd
FROM
  den8wk1_view 

とりあえず上記で2000年以降2017年までの日付に関しては対応可能になりました。

続きを読む

*1:複数件宛先のあるメールも存在しましたが、その辺は事前に加工や情報絞り込みで排除しています。

トラックバック - http://d.hatena.ne.jp/pochi-p/20170917

2017-06-24 SH-06Gがソフトウェア更新に失敗した件と対処法

[][]SH-06Gがソフトウェア更新に失敗した件と対処法 SH-06Gがソフトウェア更新に失敗した件と対処法を含むブックマーク

AQUOS ケータイ SH-06G | ドコモオンラインショップ | NTTドコモ

https://www.mydocomo.com/onlineshop/products/feature_phone/SH06G.html


確か先月頃のお話。

私の家族の何人かはドコモの携帯電話としてSH-06Gを持っているのですが、その内1台だけ何度やってもソフトウェア更新が失敗し続けていました。契約は全てタイプSS バリューのSPモード契約無しです。


ビルド番号 01.00.07 → ビルド番号 01.00.08』への更新作業で、アップデートの検知はして開始操作もできるのだけども、いざアップデートを開始しようとすると「ドコモの電波が受信できない場所、またはローミング中はWi-Fi接続中であってもダウンロードを開始できません」的な*1表示がされて通信に失敗してばかりでした。

モバイルネットワークの有効化・APNの再設定・その他設定を確認&再設定しても上手く行きません。


途方にくれつつふと「この上手く行ってない一台、以前BTテザリングさせたスマホにぶら下げて*2ネット接続させた事あったな」と思い出し、駄目元でBTテザリングにぶら下げてみると無事ソフトウェア更新が成功しました。


ビルド番号01.00.07だけの問題か、それ以外でも起こるのかどうか分かりませんが、もし同様の現象にあった場合は

  • 再びBTテザリングにぶら下がってインターネットが見られる状態にする。
  • BTテザリングをはじめBluetooth関連の設定を初期化?(試してないので効果無いかも)

…等で改善するかもしれません。

またこの問題が出た回線はSPモード契約が無かったので、もしかしたらSPモード契約中であればBTテザリングにぶら下がった経験があっても案外問題無く更新出来るかもしれません。


シャープさん&ドコモさんがこの問題を把握してるのかどうか分かりませんが、私が調べた際は情報が見つけられなかった*3ので参考までにはてダに残しておきます。

*1:細部はキャプチャしてないので微妙に違ってるかも?

*2:後継機種のSH-01Jは無線LANがありWi-Fi運用も出来る様なのですが、SH-06Gは無線LANがありません。しかしBluetoothは付いており、BTテザリングの出来るスマホ/ルーターがあればSH-06GでもSPモード契約無しでインターネットに接続可能なのです。無理にネットに使う必要性も薄いのですが…。

*3:どうしても上手く行かないから危うく修理出すところでした…。

トラックバック - http://d.hatena.ne.jp/pochi-p/20170624

2017-06-18 新しい和歌山市民図書館について質問

[][][]新しい和歌山市民図書館について質問 新しい和歌山市民図書館について質問を含むブックマーク

前置き&簡易まとめ

※2017/06/19 00:59 フロア階数の勘違いが発覚したので画像と文章修正しました。

先日和歌山市民図書館の市駅ビル移転後のイメージ図が公開されたのですが、そのPDFの15頁辺りに非常識な「手の届かない本棚」が描かれており「またツタヤ図書館にされるの?」と騒ぎになりました。

和歌山市民図書館 基本設計 (PDF)

この図書館私の自宅からそう遠くない位置にあるので、直接質問しにいってみました。*1

一番計画に詳しい担当者の方は土日いない(そして私は仕事の都合上会えない)という事で、他の方に対応して頂きました。対応して頂いた方、色々とお話して頂き有難うございました。m(_ _)m

大事な事ですが「私の聞き違い・記憶違い」で当エントリに間違い含まれている可能性はあります。質問と回答も一字一句そのままではありません*2

また一番詳しい担当者の方では無い事、市民図書館の職員の方と決断をする人(和歌山市議会?)が別である為見解にズレがありえる事を考慮の上お読み下さい。

まだ未確定な部分がある為、回答者の方としても「〜な筈」としか言えない部分も多数ある事をご了承下さい。

先に大まかに回答内容等をまとめておきます。

  • 「ツタヤ図書館になる」という結論は現状ない。「ツタヤ図書館にならない」という保証もない。
  • これから公募予定で、随意契約で内密に決まる事はない
  • イメージ図はあくまでイメージ図。あの通りに作るという訳では無い。
  • 移転に際し新しい和歌山市駅を起点に「賑わい創出」するのが第一目標となっている。その目標に合致する計画を持ってきてくれる所であればお任せするし、それを実現出来るのがツタヤさんであればお願いする。(但し今まであった問題点は改善してもらうのが当然かと*3
  • 決断をするのは市(の議会とか上層の人)なので、そちらでベストと判断された場合特殊な何かが採用される可能性は否定出来ない
  • 説明会は今後も2ヶ月に1回ペースくらいで開く予定なので是非来て下さい
  • 新しい図書館の事も大事ですが、現状の市民図書館に対して「こうした方が良い、こうして欲しい」という意見があったらどんどん教えて欲しい。

それでは↓でこちらの用意した質問と回答者さんの回答を書き綴ってみます。


「ツタヤに決まったの?」

質問

和歌山市と関係あるかどうか分かりませんが、各所でツタヤが運営する図書館がいくつかあります。

指定管理者制度が導入されると聞きましたが、市民図書館もツタヤの運営になるんでしょうか?

回答

現状どこに決まった、という話の段階では無いですね。ツタヤさんだったりTRCさんだったり色々お話する事はありますが、佐賀県武雄市の様な随意契約で決まるのではなくて広く公募してその中から条件に合う企業さんにお願いする事になるのではないでしょうか。

今回の市民図書館移転に関して、和歌山市駅をベースに「賑わい創出」をしていくというのが大きなテーマになっています。図書館運営の実績よりもそのテーマに合う条件の企業さんを優先して契約する可能性は高いかもしれません。上がどう判断していくか次第ですね。

もしツタヤさんになるとして、まあ武雄市では3年間実績がありその間改善点とかも貯まっている筈ですから、その辺りをきちんと改善した上で和歌山に来て下さるのであれば和歌山市としても問題は無いかと思います。

公式な市の決定ではツタヤに決まってはいないという事の様です。「ツタヤにならない」とか「CCC担当者を門前払いしてる」訳ではないので不安は残ります……。あと上層部が「賑わい創出」に拘ってるのも心配です。

回答者さん個人としては「CCCも問題の把握・改善が全く出来ない馬鹿では無い、常識的な企業の筈」とやや楽観的に捕らえてる感じですね。そういう常識を毎回悪い方向で裏切ってきたのがCCCクオリティですけど……。


「イメージ図の謎の高所棚は?」

質問

イメージ図の上部の棚、これ本当に作るんですか?

どう見ても手が届かないしタイトル見るのも無理です。司書の方に取って頂くのも司書さんが危険です。当然掃除もし辛い。「手に取れない本」なんて図書館の目的から外れますし、どこかの指定管理者制度の導入された図書館の様に「読める本ではない飾り(ただし本が買えてしまう値段)」を置くのもふざけてます。

何かスペース使いたいのなら、普通にポスターや吊り下げの何かにするか、ディスプレイを埋め込んで新書紹介や図書館や市のイベント紹介映像でも流す方がマトモです。

回答

常識的に考えるとあそこに棚は作らないです。また某市のツタヤ図書館では本ではないダミーを使っていたそうですが、そういうのをお金かけて購入するのも常識では有り得ないです。梯子をかける訳にも行かないし確かに危ないし、掃除もしにくいですね。

イメージ図がこうなった理由ですが、まず図書館の1階と2階の間に裏側で駐輪場が出来るんです。謎の棚の裏のところですね。その為実際に本を配置するスペースは天井が低くなっているんです。イメージ図の作成依頼で「本が沢山おいてあるイメージで」とデザイナーに伝えられています。その建物の構造と本が沢山ある(と印象づける)イメージの組み合わせの結果、あの謎イメージになってしまったのではないかと(そのままだと上半分のせいで「本が沢山」のイメージが薄くなる為か?)。中国の図書館で壁一杯が本棚になってて実際本が取れる所があるらしいですけど、あれはどうやって実現してるかは謎ですね。

多分ウチでは作らないとは思いますけど、上の決定で「これは良い!」と判断されたら導入される可能性もゼロではないです。

各地のツタヤ図書館の暴走は常識的ではないとの認識は回答者の方はお持ちの様です。

イメージ図の経緯はデザイナーさんに面倒な注文がかかった結果の事故、という事ならまあいいんですが……。

フロア構造を図にするとこんな感じで、赤で囲った部分に謎の棚が「本が沢山」のイメージを達成させる都合で設置されてしまったと。フロア構造は冒頭でリンクしたPDFの6頁・14頁でも確認出来ます。

f:id:pochi-p:20170619004946p:image

しかしながら鶴の一声が最優先されるので、イメージ見たりCCCからプッシュされたりした意思決定者が血迷うと実現する可能性があるのが痛いです……。


「人材はどうなる?」

質問

指定管理者制度の導入された図書館で、ベテランの司書さんがリストラされて素人のバイトに置き換えられるところがあると聞きます。

新しい市民図書館になったら、ベテランの方がいなくなってしまうんでしょうか?

回答

元々市民図書館では、常勤の市役所職員と司書資格をお持ちの非常勤職員の方で運営されています。市役所職員は2〜3年で配置転換される形で、司書資格を取る人もいますが全員持っている訳では無いです。非常勤職員の方は1年更新の契約ですね。指定管理者制度で運営する企業によりますが、通常であれば非常勤職員の方はそのまま引き続き運営企業で雇用し、運営企業が切り替わった際も次の運営企業で再度雇い入れる方が多いですね。その方が運営もスムーズにいきますし。ただ実際は運営企業さん次第なので、必ずこうなるという事は現状断言出来ないです。

少なくとも「次の仕事探してね♪」通告は出回っていない模様。


NDCの分類は?」

質問

指定管理者制度の導入された図書館で、図書の分類が標準的な日本十進分類法(NDC)をやめて完全独自の分かりにくい(しかも同運営企業による他の図書館とも互換性のない)ものに変更された事例がありました。新しい市民図書館ではNDCは廃止されてしまうのでしょうか? 運営者が途中変更しても引き継ぎしやすい様に標準的なNDCを継続される方が良いと思いますが…。

回答

常識的に考えればNDCのままというのが運営する側も楽ですし引き継ぎもスムーズですね。

ウチは少し古いですがNDCの第8版を採用しています。新しいのに切り替えたら分類の見直しはあります。

またNDCの分類がそのまま棚の配置になっているとは限らなくて、通信や情報の中にあるコンピュータ関係の本を一部の棚にまとめて配架する事もあります。

新しい市民図書館では2階・3階・4階の3フロア1〜4階の4フロア*4に分かれる為、移動しやすさ・探しやすさを考えて分類した本をどう配架するかは色々と考える必要はあるかと思います。

培われたノウハウや常識は大事ですね(でも鶴の一声がどうなるかは分からない)。


古本買わされるの?」

質問

指定管理者制度の導入された図書館で、運営企業の関連企業から古本の購入を押しつけられた(不良在庫を公費で負担させた?)事例がありました。新しい市民図書館にもそういう運営企業側の押しつけで常識外れな図書購入をさせられるのでしょうか?

回答

流石に古本を押しつけられるというのはありえない(筈)ですね。

ただし運営企業さんの関連会社に限らず、指定管理者制度でない場合でも書籍の購入先となる企業さんとして「(在庫余り気味の)この本買って欲しいな♪」という意図はあるでしょうし「いやいや、ウチが欲しいのはこの本ですね♪」というやり取りは存在するので、そこはまあ色々交渉次第ですね。

変な鶴の一声がなければ大丈夫……?


「貸出カードは?」

質問

指定管理者制度の導入された図書館で、貸出カードを今までの図書館用のものでなく、運営企業の扱うポイントカードに強引に切り替えさせようと誘導するという事例がありました。新しい市民図書館で貸出カードが民間の「??ポイントカード」に切り替えさせられてしまうのでしょうか?

回答

ポイントカードですか。うーん、あのポイントって結局税金から賄うって事ですよねー? そういのは難しいのではないかと。

まあ今まで通り貸出カードが使える様になると思います。

変な鶴の一声がなければ大丈夫……?


「今後の説明会は?」

質問

この前5月末頃にあった「本×人×まち図書館づくりミーティング」は存在を知らなかった為、昼の部・夜の部ともに見に行く事が出来ませんでした。今後新しい市民図書館についての説明会の様なものは開かれる予定はあるのでしょうか? 開かれるのであればそのスケジュールをどこで確認しておけばよろしいでしょうか?

回答

今後も説明会やりますよ! 是非来て下さい。

前回は30人募集で昼の部は20人以上空きがありましたし、夜の部も15人くらいは枠の空きがあったと思います。

開催ペースですが多分2ヶ月に1回くらいはしたいです。そうなると次は7月末辺りになるでしょうか? 理想は毎月開催ですがおそらくそれ位になるかと。

市民図書館のお知らせページでだいたい2週間前位から公表する事になる筈ですので、そちらをチェックして頂くと開催タイミングは分かると思います。市のページに載る事もありますが、市民図書館のページは市民図書館で直接更新出来るので確実かつ迅速にお知らせが載せられる筈です。機会があれば是非とも来て下さい。

説明会についてはとりあえず一安心でしょうか。聞きに行ける方は積極的にご参加下さい。(私が全部行ける可能性は低いです)


その他色々

質問

スラスラとツタヤ図書館の話されてますけど、(回答者の)XXさんは突っ込んでチェックされてるんですか? また他の職員の皆さんも詳しく把握されているんですか?

回答

いやいや全然詳しくはないですよ。 せいぜいニュースになってるのを少し知っているという程度ですね。

他の方と話するのもニュースを見て「この棚は……うーん、ねえ(笑)」とかちょっと話する程度です。

私目線ではかなり詳しく把握している方に思えました。ニュースになるとしても全ニュースが詳細を突っ込んでいる訳でもなし、きちんとアンテナ張ってないと問題点を全部把握してるレベルにはならないでしょうし。


その他コメント

新しい市民図書館も大事ですけど、正直現状の市民図書館に対して「こうして欲しい」「こうしたら便利になる」といった意見を沢山聞いてみたいです!

かなり意欲的に意見求められていましたので、「こうなって欲しい!」という意見のある方は是非伝えてあげて下さい。なお入口あたりに館長へのご意見箱みたいなのが設置されてますので、シャイな方はそこに投函するのでも良いかもしれません。


その他コメント

ネットから貸し出し予約とか出来る様になってるので是非ご利用ください。

最初に一度図書館まで来て頂いて、貸出カードと身分証明書を元に登録を行う必要があります。

丁寧に説明してくれました。機会があれば使ってみようと思います。


その他コメント

もしツタヤさんが来るとしたら、やっぱりスターバックスさんがセットになるんですかね? いっつもセットですし。

和歌山の中にあるツタヤさんって、全部TSUTAYA WAYなんでしたっけ?

極一部に無印TSUTAYAも混ざってた気がします。詳細は(興味ないので)知らないですけど。


終わりに

現状としては「ツタヤ図書館は確定してない。でもなる可能性もゼロでは無い。ツタヤが来るなら現場としては今までの問題点は改善して欲しいけど、上が何を良いと判断するかによってくる。なので風変わりなものは導入されないとは言い切れないという事で、まだまだ安心は出来ない感じ。

これから議員さんや市長さんに働きかけをすればうまく問題を回避出来るかもしれないし、良い案を採用されていく余地もあるかもしれないといった感じでしょうか。是非競合他社さんは「CCCなんて止めた方がイイっすよー! ウチならXXでYYで素晴らしい図書館に出来るし、継続して人を引き込む仕掛けとしてZZを用意してるし『スタバ付けただけ、奇をてらったデザインにしただけ』とは次元の違う真の賑わい創出ってのをお見せしますよ〜」とか猛プッシュして公募に参加されると良い結果になるかもしれません。

もし最悪「武雄市等のツタヤ図書館がそのまま導入」されたとしたら、CCCスレイヤー *5 の皆様から「イヤーッ!」される対象がツタヤから派生して『Tポイントカードを導入しているガスト洋服の青山ファミリーマート等』に限らず巻き添えTSUTAYA WAYオークワのらやサイゼリヤ31アイスクリーム無印良品Seriaまで「グワーッ!」ってなる展開になって和歌山市で該当企業の売上がガタ落ちするかもしれません。関係各所の方々は色々上手く立ち回って、最善の状況に至れるよう頑張って欲しいですね。CCCスレイヤーに当然「慈悲はない」ですしょうから。*6

*1:36kmの道のりを原付2種で法定速度を守りながらのんびり出向きました。

*2:私目線で「分かりやすく書き換えた」が「明後日の解釈で改竄」になってる可能性も否定出来ません。

*3:あくまで回答者の方の意見ですので、「市が今までの問題点を問題視しているという事を意味している」とイコールな訳ではありません。

*4:多分「2〜4階の3フロア」は私の聞き違い記憶違い、実際は1〜4階の筈

*5:ツタヤ図書館によって廃棄された貴重な資料などがオバケ(ビブリオソウル)となって人間と合体しCCCを滅ぼす復讐の鬼となったオフトン大好きな何か?

*6:なお某水素水スレイヤーは毎月300円の差が出たとしても伊藤園のトマトジュース/野菜ジュースは頑なに購入を拒否しているそうだ。

トラックバック - http://d.hatena.ne.jp/pochi-p/20170618

2016-10-05 ADO.NETとA5:SQL Mk-2の仲良しデバッグ

[]ADO.NETとA5:SQL Mk-2の仲良しデバッグ ADO.NETとA5:SQL Mk-2の仲良しデバッグを含むブックマーク

A5:SQL Mk-2を勝手に応援を勝手に応援シリーズ第二弾です。


普段は『自作の「SQL Server sp_executesql stripper for A5:SQL Mk-2」+SQL Server Profiler』と「A5:SQL Mk-2 スクリプト - 流星墓場」で公開されてる「SetParameterジェネレータ」で事足りてるんだけど、SQLServer以外でもC#/VB.NET上のデバッグ時にいつもの擬似命令付きSQLを取得できるようにとやっつけでコード書いてみました。


対応パラメータ形式は現状名前付き(NamedParameterだっけ?)パラメータのみです。ODBCドライバOracleの標準プロバイダを選んだ際の

INSERT INTO TBL1 (col1, col2) VALUES (?, ?)

の記法はまだ対応してません。

確かSystem.Data.SqlClient、System.Data.SQLite、Oracleの拡張プロバイダ(みたいなのがあった気がする)辺りなら

INSERT INTO TBL1 (col1, col2) VALUES (@col1, @col2)

で書けた筈です。


では早速デバッグ用コードをば…。十分なテストをしてないβ版なので取扱いに注意ください。

    'v0.0.1 手抜きβVer 
    'v0.0.2 2回目βVer
    '  Null値対応してない大ポカを修正
    '  DateTimeとTimeの秒とミリ秒の区切りの修正
    '  末尾にSQL区切り";"の出力を追加(A5:SQL Mk-2上なら";;"とかなってても平気なので)
    'v0.0.3 βVer
    '  時刻は24時間表記する時"HH"と大文字にしないとね…。orz
    ''' <summary>
    ''' 使用例
    '''     Dim cmd As New System.Data.SqlClient.SqlCommand()
    '''     cmd.Connection = connectionObject
    '''     cmd.CommandText = "INSERT INTO TBL1 (col1, col2) VALUES (@col1, @col2)"
    '''     cmd.Parameters.Add("@col1", System.Data.SqlDbType.VarChar).Value = "ABC"
    '''     cmd.Parameters.Add("@col2", System.Data.SqlDbType.Int).Value = 1
    '''
    '''     Debug.Print(a5m2cmdParse(cmd)) '実行直前にデバッグ出力
    '''     cmd.ExecuteNonQuery()
    ''' </summary>
    ''' <param name="dbcmd">System.Data.IDbCommandを実装してる???Commandのインスタンス</param>
    ''' <returns>A5:SQL Mk-2でパラメータ設定付で実行する為の文字列 </returns>
    Public Shared Function a5m2cmdParse(ByVal dbcmd As System.Data.IDbCommand) As String
        Dim sb As New System.Text.StringBuilder()
        sb.Length = 0
        For Each p As System.Data.IDataParameter In dbcmd.Parameters
            Dim a5name As String = p.ParameterName.Substring(1)
            Dim a5val As String = String.Empty
            Dim a5type As String = "String"
            Dim isNullValue As Boolean = False
            If IsNothing(p.Value) OrElse IsDBNull(p.Value) Then
                isNullValue = True
            End If
            Select Case p.DbType
                Case DbType.Int16, DbType.Int32, DbType.Int64
                    a5type = "Integer"
                    a5val = If(isNullValue, "NULL", CInt(p.Value).ToString())
                Case DbType.UInt16, DbType.UInt32
                    a5type = "Integer"
                    a5val = If(isNullValue, "NULL", CInt(p.Value).ToString())
                Case DbType.UInt64
                    'a5type = "Integer"
                    a5type = "Currency" '擬似命令でUint64指定が出来ないのでCurrencyで代替
                    a5val = If(isNullValue, "NULL", CDec(p.Value).ToString())
                Case DbType.Decimal
                    a5type = "Currency"
                    a5val = If(isNullValue, "NULL", CDec(p.Value).ToString())
                Case DbType.Byte, DbType.Byte
                    a5type = "Short"
                    a5val = If(isNullValue, "NULL", CShort(p.Value).ToString())
                Case DbType.Single, DbType.Double
                    a5type = "Float"
                    a5val = If(isNullValue, "NULL", CDbl(p.Value).ToString())
                Case DbType.Date
                    a5type = "Date"
                    a5val = If(isNullValue, "NULL", "'" & CDate(p.Value).ToString("yyyy/MM/dd") & "'")
                Case DbType.DateTime, DbType.DateTime2
                    a5type = "DateTime"
                    a5val = If(isNullValue, "NULL", "'" & CDate(p.Value).ToString("yyyy/MM/dd HH:mm:ss.fff") & "'")
                Case DbType.Time
                    a5type = "Time"
                    a5val = If(isNullValue, "NULL", "'" & CDate(p.Value).ToString("HH:mm:ss.fff") & "'")
                Case DbType.AnsiString, DbType.AnsiStringFixedLength, DbType.String, DbType.StringFixedLength
                    a5val = If(isNullValue, "NULL", "'" & CStr(p.Value).Replace("'", "''") & "'")
                    a5type = "String"

                    'Case DbType.Boolean
                    '    'DB毎に実装違いそう

                    '他はもう面倒
                    'Case DbType.Binary
                    'Case DbType.Guid
                    'Case DbType.Object
                    'Case DbType.VarNumeric
                    'Case DbType.Xml
                Case Else
                    a5val = If(isNullValue, "NULL", "'" & (p.Value.ToString()).Replace("'", "''") & "'")
                    a5type = "String"
            End Select
            sb.AppendLine("--*SetParameter " & a5name & " " & a5val & " " & a5type)
        Next
        sb.AppendLine(dbcmd.CommandText)
        sb.AppendLine(";") '区切り追加
        Return sb.ToString()
    End Function

(C#版が欲しいならILSpyでも使って逆コンパイルしてください!)

呼び出し方は

Dim cmd As New System.Data.SqlClient.SqlCommand()
cmd.Connection = connectionObject
cmd.CommandText = "INSERT INTO TBL1 (col1, col2) VALUES (@col1, @col2)"
cmd.Parameters.Add("@col1", System.Data.SqlDbType.VarChar).Value = "ABC"
cmd.Parameters.Add("@col2", System.Data.SqlDbType.Int).Value = 1

Debug.Print(a5m2cmdParse(cmd)) '<-ここ
cmd.ExecuteNonQuery()

の様にSQLもパラメータもセットしおわったSqlCommand等のインスタンス*1を渡して結果文字列を取得するだけです。簡単ですね!

ではデバッグは皆に任せた!

*1: System.Data.IDbCommandインターフェースを実装してる*Commandなら基本何でも可

トラックバック - http://d.hatena.ne.jp/pochi-p/20161005

2016-08-07 定期的なパスワード変更の効果有無まとめ

[]定期的なパスワード変更の効果有無まとめ 定期的なパスワード変更の効果有無まとめを含むブックマーク

自由研究の季節

夏です。今年もまた自由研究の季節がやってきました。何年か前にパスワード定期変更云々という夏休みの自由研究をやりました。このエントリは総当たりに対する防御の視点で書かれたものです。

今回は「総当たり対策」以外の視点でパスワードの定期的変更の効果を検証します。

このまとめは気が向いたらテキトーに項目を追加&編集していきます。まだまだ完成版ではありません。

大前提

ユーザーが自主的に定期的変更するのもいいが、パスワードに関してはまず設定可能文字数を大きくする・使用可能文字種を増やすのが最初の一歩です。

・サイト側がユーザーに定期的変更を強制すると、ユーザーは結果的に強度の弱いパスワードを使いがちなので強制は良くない。*1

・サイト側での保存方法には必ずハッシュ化+ソルト+ストレッチングを設け、秘密の質問の様なゴミは使わない事。

・変更タイミングの基本は

とします。その上で例外的にイベントドリブンの変更が有効なケースの洗い出せれば良いんじゃないかと。

まとめ

とりあえず表形式で書いていこうと思います。

基本「定期的変更より効果のある対策」がある場合は、まずそちらを最優先で対策していくべきです。それをせずに定期的変更を推奨する輩はハイクを読んで頂きたいと思います。イヤーッ!

効果がない事例
事例メモ定期的変更より効果のある対策
他サイト等と同じパスワードを共有しているアカウント 共有中の全アカウントを定期的変更するのは非現実的 そもそも使い回しをしない!
暗号化zipファイル等のパスワード 前回保存した前回のパスワードで暗号化されたファイルを入手されれば全く意味が無い。 ベストアンサーは難しいが、最初から十分な強度のパスワードを設定する、PGP/GnuPG等で設定する、TrueCryptの様なダミーコンテナが利用できるものを併用する辺りが考えられる?
一般的なオンラインバンキングアカウント 攻撃成功時の金銭利益が大きい為、パスワード入手後管理者に気付かれないうちに攻撃者が時間をかけず攻撃する可能性が高い*2 二要素認証ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック取引通知メール
RMTや他ユーザーにアイテム譲渡が可能なオンラインゲームアカウント 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
OpenID等の他サイトログインに利用しているアカウント 定期的変更によるメリットは通常より高いが、対策方法や効果の限界は通常のアカウントと変わらない二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
ストーキングの意味が少ないSNSWebサービスアカウント 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
効果がある時もあるが運任せ過ぎてあるとは言い難い事例
事例メモ定期的変更より効果のある対策
RMTもアイテム譲渡も不可でストーキングの意味もないオンラインゲームアカウント 攻撃者がアカウント削除等悪戯目的であれば削除までにパスワード変更が間に合う可能性は現実的でない。 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
効果がある事例
事例メモ定期的変更より効果のある対策
ストーキングする意味があるSNSやオンラインゲーム 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
ストーキングする意味があるメールアカウント(Webメール)つきまといだけでなく、パスワードリセットや二要素認証に使われているメールアカウントも含む 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック
ストーキングする意味があるPOP3やIMAP4のメールアカウントPOP3/IMAPでアクセス可能なWebメールも含む。つきまといだけでなく、パスワードリセットや二要素認証に使われているメールアカウントも含む。 プロトコル上対策が難しい?? 情報求む!!
継続して社外秘情報を剽窃する事に利益のある社内ネットワーク/PCのアカウント 外部からの侵入を防ぐネットワーク構成、リモート操作をさせないセキュリティパッチ適用マルウェア感染を防ぐセキュリティ対策や実行ソフト制限
確実に口座残高が時間経過で膨らむ人のオンラインバンキング入出金明細をいちいちチェックしてる攻撃者に限る 二要素認証、ログインアラート通知、設定変更通知メール、アカウントアクティビティ表示、誤入力時のアカウントロック、取引通知メール
化石の様な前時代のシステム /etc/passwdにパスワードを格納しているタイプ さっさとリプレイスしろ!

補足

なお『定期的変更タイミング < 攻撃者がパスワードを入手してから攻撃を開始するまでの時間』の図式が期待し辛いものは、運任せ以前のものとして『効果がない』にまとめていこうと思います。何故なら『ではどれぐらいの頻度で定期的に変更すべきか?』の結論を出さない限り、そもそも左辺右辺の比較のしようが出来ないからです。

また『『攻撃者がパスワードを入手してから攻撃を開始するまでの時間』は比較的長い』という主張をするには、『攻撃を遅らせると攻撃者の利益が増える』前提でもない限り性善説(?)頼み過ぎる為ひとまず「効果がない」または「効果がある時もあるが運任せ過ぎてあるとは言い難い事例」に入れていきます。

「こういうのも追加していこう!」「こういう代わりの対策があるよ!」という情報があれば、コメント欄等でご連絡頂ければありがたいです。

*1http://security.srad.jp/story/16/06/27/2030224/

*2:時間をかけるとすれば送金先口座の準備や口座残高の多いアカウントの抽出が考えられるが、前者は前もって準備可能だし後者も下手に怪しいアクセスを増やしてサイトに気付かれるリスクを犯してまでやる価値があるかは疑問なところ。

keijitakedakeijitakeda 2016/08/09 21:27 ツイートで指摘しましたがこちらに反映されないのでコメントにも書いておきます。
「攻撃成功時の金銭的利益が大きい為、パスワード入手後管理者に気付かれないうちに攻撃者が時間をかけず攻撃する可能性が高い」の根拠が怪しいと思われます。
同様のインセンティブが働くクレジットカード番号の悪用は時間をかけて行われるケースが多く確認されていますし被害の発生期間も長期にわたり継続することがわかっています。ですのでこの仮説には無理があると思われます。

pochi-ppochi-p 2016/08/13 00:26 > keijitakeda さん
えー、指摘は見てますがどう書き直すのが正解か決めかねて、現状そこはこのままで放置かなと考えています。
放置な理由としては次の3点の心配&モヤモヤがある為です。

(1)「長期的で少額ずつの攻撃」にて二つの方向性が考えられること。「沢山のアカウントから少額ずつ」or「少数のアカウントからそれなりの額ずつ」の方法がとれ、後者かつ最初のアカウントで選ばれた場合『攻撃者が時間をかけず攻撃する可能性が高い』寄りになる。

(2)記載内容がワーストケースで大げさ表現とも言えるが、少額ずつの被害もベストケース過ぎてどちらを前提にしても偏った内容になってしまう点。かつ攻撃者の手法が恒久的に変わらない訳でもない。だったらワーストケースで書く方が将来的にマシかなというモヤモヤ。

(3)「長期的な少額被害」が、必ずしも万人にとっての少額とはならない。あくまで『攻撃可能金額に比して少額』なだけで、1万円でも盗まれたら不渡りで死ぬとか家賃払えずホームレスとか。これもケースバイケースとなる為、ワーストケースで警告する方がエントリとして良心的なのではというモヤモヤ。


とりあえず指摘されてる箇所についてはこの様な理由から、現状維持でいこうと思います。色々スッキリした際書き直すかもしれません。


あとクレジットカードとオンラインバンキングはあくまで似て非なるものなので、クレカ被害の傾向だけを元に修正するってのも何か違う気がしました。

トラックバック - http://d.hatena.ne.jp/pochi-p/20160807
Connection: close