✖
市議会へ陳情
個人ではどうにもならない理不尽な事象、できれば解決したいけどどうしよもないってのはまぁよくあると思いますが、もし行政がちゃんと動けば解決するような問題ならば、市議会への陳情というのも1つの手ではあるなとふと気付いたので、実際にやってみました。少なくともネットの片隅で愚痴るよりは実効性があり、市民としての意志表示ができる方法でしょう。
陳情するのは極めて簡単
地域の市議会への陳情にはなんの資格もいらず、議員との繋がりも必要ありません。たくさんの署名なども必須ではなく、完全に個人で出すことができます。議員の紹介があれば請願法に定められた請願とすることができますが、議会運営上は基本的に陳情も請願も同一のものとして扱っていることも多いです (後述しますが地域によって異なります)。
フォーマットはだいたい決まっていて、市のウェブサイトでテンプレートをダウンロードできたりします。
陳情本体は
- 要旨
- 理由
に分けて書くとされています。要旨は端的に「何をしてほしいか」を羅列し、理由でそれを詳しく説明します。要旨に対して採択・不採択・一部採択があるようです。
あと、お役所に出すものなので必要事項は書かないとダメです。
- 宛先 (議長あてに書く)
- 住所
- 氏名
- 電話番号
- 印(直筆なら不要)
だいたい市のウェブサイトに過去の陳情が公開されているので、1年分ぐらい読むと雰囲気がつかめる気がします。こんなの採択されるわけねーだろと思うような微妙な陳情も結構あるので過去ログ読むと気楽になります。
陳情のデメリット
意外とわかりにくいのですが、請願 (紹介議員を必要とする) と違って、陳情は法律で定められていないので、請願法第6条にあるような「何人も、請願をしたためにいかなる差別待遇を受けない。」という明確な保護がない可能性があり、もしかすると不利益をこうむるかもしれません。もし陳情することによって不利益が生じる可能性があるなら、なんとかして議員を探したほうが安全かもしれません。
図書館とか行政コーナーで調べると、どこの誰が陳情したのかは分かってしまうようです。
また、地域によっては陳情の扱いが請願より明らかに低く、書面を配るだけというところもあるようです。
自治体ごとの陳情の違い
全部調べるのはだるいので政令指定都市での陳情の扱いを調べてみました。引用のあとに括弧書きがないのは基本的に陳情と請願を同様に扱うとしている都市です。ちなみに請願は地方自治法で定められているのでどの自治体でも同様です。
- 札幌市 「札幌市議会の場合、「請願」と「陳情」の取り扱いは、全く同じです。」
- 仙台市 「陳情についても市の事務に関する事項で内容が請願に適合するものは,請願と同様に取り扱われます。」
- さいたま市 「提出された陳情書は、陳情文書表に編集のうえ、議場での配付をもって、議会に報告されます。」(請願扱いされない。配るだけ)
- 千葉市 「陳情は、委員会限りの審査となります。」(本会議での採択がない)
- 横浜市 「陳情の場合は、議会が関係行政庁に意見書を提出することを要望するものなど、議会の機関意思の決定に関する陳情については、常任委員会などに付託し、その審査結果を本会議に報告した後、陳情者に通知します。それ以外の陳情(行政への要望に関する陳情等)については、議長が市長等の回答を求め、その旨を陳情者に通知します。」(請願とは違う扱いだがほぼ同様に扱われるケースがある)
- 川崎市「陳情は、市議会議員の紹介を必要としません。請願と同じく委員会で審査を行い、「採択」、「不採択」の結論が出た場合は、その結果を提出者に通知します。」
- 相模原市 「請願は市議会議員の紹介が必要です。陳情には市議会議員の紹介は必要ありません。どちらも取り扱いは同じです。」
- 新潟市 「陳情も請願と同様に審査されますが、郵送による陳情は、所管委員会に付託せず、議会運営委員会への報告にとどめる取り扱いとなります。」(結論の有無)
- 静岡市「また陳情書についても、所管の委員会で審査され、採択されたものは、関係機関に送付するなどして、その実現に努力するよう求めます。」(請願とプロセスが異なる。本会議採択がない?)
- 浜松市 「陳情及び要望は、議員の紹介がなくても提出することができます。陳情が提出された場合は、直接所管の委員会で審査し、採択・不採択が決定されます。採択した陳情は、請願と同様に市長等の執行機関に送付されます。」(本会議での採択がない)
- 名古屋市 「陳情の審査は請願の場合と同様であり、委員会の決定については、請願の扱いと同様のもの、ききおく程度にとどめるものなど、事案に応じた取り扱いをしています。」
- 京都市「陳情は,議員の紹介を必要とせず,受理した陳情は,所管の常任委員会において請願と同じように審査しますが,「採択」又は「不採択」の結論は出しません。」(結論の有無に違い)
- 大阪市「陳情は委員会で審査し、結論 (採択・不採択) を出します。 なお、次の各事項に該当する陳情は委員会に付託されません。」(請願と違い本会議で採択はされない)
- 堺市「提出された請願は本会議と委員会で、陳情は関係する委員会で、それぞれ審議されます。」(本会議での採択がない)
- 神戸市「請願・陳情はどちらも慎重に審査した後、請願は最終的に本会議で、陳情は委員会で採択するかどうかの結論を出します。」(本会議での採択がない)
- 岡山市 「岡山市議会では、議員の紹介があるものを請願、ないものを陳情と呼んでいますが、請願書も陳情書も同じ扱いです。」
- 広島市「関係する委員会に付託・審査の後、その審査結果に基づき、本会議で、「採択」「不採択」の結論を出します。」
- 北九州市「陳情も文書(陳情書)の提出が必要ですが、市議会議員の紹介は必要ありません。また、その内容が請願と同様に取り扱うべきものについて、請願書の例により処理されます。」
- 福岡市 「陳情は、委員会に送付、各委員に配付しますが、採択・不採択の結論は出しません。」(結論の有無)
- 熊本市 「請願は採択、不採択を決定しますが、陳情は採択、不採択の決定は行いません。」(結論の有無)
雑感:調べてみると意外と取り扱いに差があります。大きくわけて「配るだけ(結論を出さない)」「委員会で採択する」「請願と同様」と分かれるみたいです。
考えかた
増田で炎上させられるようなトピックでない限りインターネットでいくら行政に文句を言っても意味はありません。手続きが簡単なので、陳情は「ネットで言うよりマシ」ぐらいのものでまぁそれほど期待せずにやるのが良い気がします。
制度的にDDOS攻撃に弱そうですが、どうなんでしょうね。
そのほか雑多なメモ
住んでるところの市議会に限る話かもしれないので覚書程度に
- 陳情の締切は本会議中に2回ある。ここで委員会付託
- 本会議は年4回
- 内容を市議会の議事課のほうでかなり精査されて文言の訂正をかけてくれる。引用文献の年月が正しいかとかも見てる。
- 訂正は電話で確認される。
- 陳情には図をつけれないらしい。図をつけるなら参考資料を議会に配りにきてねという話をされた。
✖
ネットワーク内の Raspberry Pi の IP アドレスを調べる
いちいちモニタ繋いで確認とかするのは面倒ですが同じネットワーク内なら簡単に調べることができます。
まず ifconfig で所属するネットワークのブロードキャストアドレスを調べます。
$ ifconfig ... broadcast: 192.168.0.255
broadcast 向けで ping を数回打ちます。ARP テーブルを埋めるためなので結果は気にしません。ネットワーク内の接続機器が多いと大量にかえってくるのでほどほどにしましょう。
$ ping 192.168.0.255 ...
arp -a で ARP テーブルを表示し、Raspberry Pi Foundation の OUI ( b8:27:eb) を持つものを列挙します。
$ arp -a | grep b8:27:eb
簡単です。
USB 3.1 Gen2 のハブは現時点ではないみたい
思いたって USB 3.1 Gen2 のハブを探してみたけど、存在していなかった。
ところで、USB 3.0 というのは既に消滅している。過去の USB 3.0 は USB3.1 により置き換えられ USB 3.1 Gen1 となっている。USB 3.0 と USB 3.1 Gen1 は同じなのだ。
ということで単に「USB 3.1 対応」と書いてあるものは、予想に反して合法的に USB 3.0 と同一の製品である可能性がある。Gen2 対応が明記されていなければだめ。
「USB 3.1」と表示されている製品には注意が必要。
- Type-C コネクタを採用しているだけで USB 2.0
- USB 3.1 Gen1 (=USB 3.0)
- USB 3.1 Gen2 (10Gbps)
が混在している。
なぜ USB 3.1 Gen2 のハブ を探していたか
USB 3.1 Gen1 (USB 3.0) は伝送路における基本波が 2.5GHz なため、ISM バンドの 2.45GHz 帯 (2.4GHz〜2.5GHz)で電波障害が起きやすい。Gen2 なら問題ないはずなので、どうせ買うなら Gen2 に置き換えていきたいと思ったのでした。しかしまだ早かった。
USB 3.1 Gen1 = USB 3.0 ?
USB 3.1 Specification Language Usage Guidelines from USB-IF には以下のような記述がある。
✖
Machinekit 用の筐体
昨年の夏ぐらいからずっとやっていた CNC コントローラの Machinekit 化 がようやく一段落しつつあります。夏の時点で「動く状態」ではあったのですが、筐体に入れておらず雑に組んだまま運用していました。
まぁこれで使えてしまっていたので余計に筐体を作るモチベーションが落ちていたのですが、ようやく作りました。
筐体全体の設計
ベース
ベースは1mmのアルミ板を6枚組合せたもので、machinekit化以前から使っていたものを流用しています。アルミ板6枚はアルミ板で作ったアングルで相互に固定されています。1枚1枚はただの板のままなため、NC 切削する際の Z 軸の余裕を考慮する必要がなく都合が良いです。
方針
方針として Beagle Bone Black から出ているコネクタはできるだけ筐体の外に引き出すことにしました。HDMI や LAN や USB などです。また USB に関しては筐体内に4ポートハブを内蔵して、前面・背面に2つずつ引き出すこととしました。パネル用のコネクタはほぼ ebay 経由で入手できます。どうもこういうのは国内だと売ってません。
またスピンドル電圧と電流を表示するためにアナログメーターをつけることにしました。切削抵抗の目安になるのではにか?という意図と、あとは単に格好が良いのでつけたいという感じです。
ほかにも細かいことがいろいろありましたが忘れました。
モデリング
3D CAD の Fusion 360 で収めたい部品を全てモデリングし、CAD 上で部品配置を検討しました。「うっかり干渉して入らない……」ということを防ぎ、穴開け用の CAM としても使う意図です。
あとになって作ってみると、大丈夫だろうと思ってモデリングを省いた部分で案の定干渉して、1つのコネクタ (LAN) を入れることができませんでした。今のところ使っていないので致命的ではありませんが代替方法を考え中です。
穴あけ
穴あけは CNC フライスで行いました。配置検討した Fusion 360 からそのまま穴あけもモデリングして筐体の各面の CAM データを作成し、Gcode を出力して加工しました。
加工は φ1mm のエンドミルで切り込み 0.1mm、フィード 50mm/min でやりました。最近ようやく切り込みは限りなく小さくしてフィードレードをあげたほうが安全(折れにくい)ということがわかってきました。もっと太いエンドミルを使ったほうが早いですが、ちょっと細かいところもあって面倒だったので基本一括 1mm としました。
ただ、φ1mm のエンドミルだと Fusion 360 は φ1mm の穴のパスを作ってくれないので、該当部分だけ φ0.8mm で加工しました。
頑張って組む
配線が結構多いので大変でした。100V を引き込むようにしたので、そのへんははんだ付け後にビニールテープで覆って、うっかり触れないようにしてあります。
電圧計・電流計 (どちらもスピンドル用) をどうしても付けたかったので余計配線が複雑化しました。
その他
筐体前面に出ている LED は BBB の USR LED そのままにしたかったので、光ファイバーで引き出しています。
非常ボタンはもともとツバがついていませんが、これも削り出してつくっています。
感想
かなり初歩的ではありますが 3D CAD を活用して筐体設計もそこそこ簡単にできることがわかりました。あとやはりモデリングは細部まで行うことが大事だという教訓を得られました。
自分用メモ:使いかた
- 主電源を入れる
- 自動的に BBB にも電源が入り、電源 LED が点灯する。起動プロセスに入るので USR LED 4つも明滅する
- 起動するまで少々待ってから、VNC で接続する (Finder で Cmd+K)
- (加工する)
- 電源ボタンを押すと BBB はシャットダウン開始される
- しばらく USR LED が明滅したのち、完全に消灯すれば主電源を切ることができる
追記 スピンドルコントロール
✖
✖
✖
花粉症の薬
OTC が流行ってるけど、あまり手間が変わらないのと3割負担の分比較的安いので常に耳鼻科にいっている。
花粉症のときの症状は、くしゃみや涙も出ることは出るが生活に支障があるぐらい支配的なのは鼻詰まり。
毎回処方されるのは「エピナスチン塩酸塩 (アレジオン) 10mg」「プランルカスト水和物(オノン) 112.5mg」。朝晩に1錠ずつ。
アレジオンはOTCがあるが、オノンはないようだ。10日分が処方される。月初めの再診だと1200円ぐらい。これらだけの場合は診察なし・院内処方ですぐ出してくれるため通うのはそれほど苦痛ではない (開いている時間に制限があるのがネックだが)
✖
✖
✖
✖
技術力とはなんだ
実現可能性を持っているかと、どのぐらいの速度で実現可能かのかけあわせだと思う。実際はこれらは連続しているけど 0→1 と 1→∞ は別モノとして感じるので分ける。
実現可能性ってのはもっというと作業見積りができるかどうか、言い換えると頭の中で完成までの道筋を頭の中に具体的にイメージできるかどうか。これはゼロ・イチで評価できる。とにかくまずはイチにしないとはじまらない。
そして速度。具体的にどうすれば分かっていても、現実的な期間で実現できなければいけない。あらかじめコスト(時間)を払っておけばその後の速度があがる。しかし何度もやらないことに事前コストをたくさん払うのは割にあわない。
広色域ディスプレイの広がり
アップル製品は iPhone も含めて徐々に DCI-P3 という色域をサポートしつつある。特に iPhone7 はカメラで撮影した JPEG の色域が DCI-P3 になっているらしい。
Android でも RAW 撮影が可能になり、スマフォで撮影した RAW を PC などで広色域ディスプレイで現像するのは今でも可能だ。ただし Android は OS レベルのカラーマネジメントが今のところないため、デバイス液晶だけが広色域化してもなかなか対応が難しいのではないかと思う。
DCI-P3 は AdobeRGB とは少し違った色域だが sRGB よりは広い色域になる。
- P3 のほうが赤の彩度が強い
- AdobeRGB のほうが青緑の彩度が強い
ウェブの画像の場合とりあえず sRGB にしとくみたいなことをしがちだけど、プロファイル埋め込みで広色域にしてもいいかもしれない。
色域に応じたメディアクエリの提案も行われているみたいなので (詳しくは調べてない)、いずれは広色域化を考慮したウェブサイト設計が求められる。
✖
✖
✖
VPSのSSD化の効果2
VPSのSSD化の効果 | tech - 氾濫原 の続き。縦軸の最大値が半分になった。微妙にピークがでている期間もあるが概ね 500ms 以内に収まっているっぽい。
Zenfone2 の Android Mashmallow アップデート
OTA では落ちてこないが手動で更新ファイルを落とせばアップデートできるようになっていた。
システムを更新しています的なプログラスバーが全くすすまくてあせったけど30分ぐらい放っておいたら更新された。
公式サイトのダウンロードから OSを選択: Android → ファームウェア → バージョン JP-4.21.40.231 を選択。
ダウンロードして再起動すると更新する通知がでるのでそれをタップする。
まぁもう Zenfone3 をメインにしていて Zenfone2 は二酸化炭素濃度の表示にしか使ってないんだけど…
✖
Lightroom カタログを専用ドライブに
240GB の SSD に Lightroom のカタログを移動した。今まで OS が入っているシステムドライブにそのまま置いていたが、カタログ、とくにプレビューが大きく容量を圧迫していたため、これを解消することを目的とする。
カタログと Time Machine
カタログに付随するものとして Previews.lrdata と Smart Previews.lrdata があり、カタログ自体よりもこれらの容量が支配的になる。しかしこれは Time Machine から除外しても良い。元のファイルがあればいくらでも再生成できるものだからだ。実際これらの lrdata を削除して Lightroom を起動しても何の警告もなく起動し、プレビューは必要に応じて再生成されスマートプレビューはなかったことにされる。
スマートプレビュー
もしドライブを常時接続している場合は恩恵がないので生成しないほうがよさそう。読み込みダイアログで生成するチェックボックスをはずすこと。
これは写真ストレージになっているドライブを頻繁にとりはずして(例えばノートPC単体にして)現像を行いたいときのためのものなので、それをやらないなら特にメリットはない。
.lrcat っていったい何なのか
Lightroom のカタログを SQLite で読んで統計を出したりする
.lrcat っていったい何なのか
カタログファイルの実体である lrcat は SQLite の DB ファイルそのもの。sqlite3 foo.lrcat すると中身を見ることもできる。
部分的に見た結果をメモしておく
# 画像に対応するテーブル? Adobe_images # Exif 情報に対応するテーブル? AgHarvestedExifMetadata # ファイルに対応するテーブル? AgLibraryFile AgLibraryFolder # 画像とファイルのリレーション? select Adobe_images.captureTime, baseName, modTime from Adobe_images inner join AgLibraryFile on Adobe_images.rootFile = AgLibraryFile.id_local; # 画像と exif のリレーション? select * from Adobe_images join AgHarvestedExifMetadata on AgHarvestedExifMetadata.image = Adobe_images.id_local;
たとえば
sqlite> .schema AgHarvestedExifMetadata CREATE TABLE AgHarvestedExifMetadata ( id_local INTEGER PRIMARY KEY, image INTEGER, aperture, cameraModelRef INTEGER, cameraSNRef INTEGER, dateDay, dateMonth, dateYear, flashFired INTEGER, focalLength, gpsLatitude, gpsLongitude, gpsSequence NOT NULL DEFAULT 0, hasGPS INTEGER, isoSpeedRating, lensRef INTEGER, shutterSpeed );
なので (index は省略)、dateYear ごとの focalLength 統計を求めたい場合は
select dateYear, focalLength, count(*) from AgHarvestedExifMetadata group by dateYear, focalLength;
とか、もっとシンプルにレンズ焦点距離の使用頻度なら
sqlite> select focalLength, count(*) as cnt from AgHarvestedExifMetadata group by focalLength order by cnt;
...
24.2|1003
35.0|1037
|1093
200.0|1139
18.0|1153
22.0|1307
24.0|1378
70.0|1928
50.0|1978
30.0|4265
100.0|4522
みたいなことはできる。
レンズ名ごとの撮影枚数 (Lightroom 上でもわかるが) なら
select AgInternedExifLens.value, count(*) as cnt from AgHarvestedExifMetadata join AgInternedExifLens on AgHarvestedExifMetadata.lensRef = AgInternedExifLens.id_local group by lensRef order by cnt;
とか。
今年の統計 (これも Lightroom 上でもわかるが) だけならこんな感じとか
select AgInternedExifLens.value, count(*) as cnt from AgHarvestedExifMetadata join AgInternedExifLens on AgHarvestedExifMetadata.lensRef = AgInternedExifLens.id_local where dateYear = CAST(strftime("%Y") AS NUMERIC) group by lensRef order by cnt;
24-70mm|10
20mm|17
EF50mm f/1.4 USM|75
EF-M22mm f/2 STM|77
EF70-200mm f/2.8L IS II USM|253
EF100mm f/2.8L Macro IS USM|353
35mm|428
E PZ 16-50mm F3.5-5.6 OSS|1260
30mm F1.4 DC DN | Contemporary 016|4083
もうちょっと Lightroom 上で見れない統計を出したいと思ったが思いつかなかったので思いついたら続きを書く
✖
長年の悩みだったレンズ前玉の汚れが落ちた……
5年ぐらい前 (というか買った直後ぐらい)に EF 100mm F2.8 MACRO に傷をつけてしまっていて、ずっとそのことについては心にトゲが刺さったような気持ちだった。まぁとても小さい傷なので画質に問題はないだろうと思いそのまま使っていたし、実際撮影画像見ても一切わからないので、純粋に心のトゲの問題である。
過去に試した方法
傷?汚れ?をつけてしまったあとに試したのはハクバのレンズペンだったが、これでは落ちなかった。
指紋は綺麗に落ちるので、ついてしまったのが落ちないのは汚れではなく傷になってしまっているからだろうとこの時思い込んでしまっていた。
今日、試した方法
ふと思いついて無水エタノールをキムワイプにつけて優しく何度かこすってみたところ、傷だと思っていたものはみるみるうちにあっさり消滅した。つまり傷だと思いこんでいたものは落ちにくい汚れだったというオチであった。
ほかの方法
レンズコーティングがどういうものなのかわからない以上、無水エタノールも絶対に安全とはいえず、界面活性剤タイプが一番安全なはず。
界面活性剤タイプだとフジのがよく使われているっぽい。揮発しないので完全に拭き取らないといけないところが面倒なところ。
しかし調べた感じだとレンズコーティングはそんなに簡単に剥れたりするものではない (溶剤よりも摩擦を心配すべき) っぽい。ので無水エタノールでも良いのではないかという結論にいたった。
無水エタノールはかなり揮発性が高いので余計なものが恒久的に表面に残るという心配がないのは安心。
ペーパーは「ダスパー」というレーヨンでつくられたものが良いらしい。今回は使わなかったが次回からこれを使いたい。
安全な方法
安全な順に
- メーカーに清掃修理依頼を出す
- 乾式のレンズクリーナーを使う
- 界面活性剤タイプの洗浄剤を使う
- 無水エタノールを使う
さらに強力な方法もあるが、プラスチックを侵すので無水エタノールでダメなら諦めたほうがいいと思う。
✖
✖
✖
Android O から広色域ディスプレイがサポートされる
デベロッパープレビューのそのようなことが書いてあった。
アクティビティごとに設定が必要らしい。Lightroom Mobile みたいなアプリが恩恵をうけそうだ。ブラウザは対応するだろうか?
リファラは必ず確認
Google Analytics のリファラデータを API 経由で取得して見ています。
なんでAPI経由かというと、できるだけ新しく貼られたリンクだけをチェックしたいから、です。APIで「90日前〜7日前」と「7日前〜今日」の2種類のリファラのリストを取得し、後者から前者を引いた差分を見ています。
まぁアナルのことはどうでもよくて、みんなもっとブログや日記 (ツイッターではなく) を書くべきです。
✖
✖
江ノ島
✖
✖
サントリー東京・武蔵野ブルワリー
工場見学にいってきた。府中の森に行く途中にあるので存在はしっていたが「本当にここでビールを作っているのだろうか?」と半信半疑だった。どうやらほんとうに作ってるらしい。
見える部分は案外こじんまりしているように感じたが、実際はどれも高さが結構あって、容量はあるようだ。見学はおおむね写真撮影しても良いのだが、動画禁止なのと釜の中は撮影禁止になっていた。しかし釜の中を覗きこむことはできる。止まっていて攪拌用のものが見えたが全く詳しくないのでどこに撮影禁止にする理由があるのかはわからなかった。
酵母室の配管はおもしろくて、大量に圧力センサーか何かが並んで一様に緑のランプを点灯させていた。冒頭の写真。
写真にはないがビールが一時的に溜められるタンクの中を歩く経路がある。宇宙船みたいで面白かった。
原料の麦を食べさせてくれる。ほんとにこのまま「良く噛んで食べてみてください」と言われる。噛んでると結構甘い。あとホップを固めたペレットの匂いもかがせてくれる。ホップの匂いを嗅ぐことはまずないので貴重な体験。鮮度を保つため現地でペレット状に固めて輸入するといっていた。
最後にプレモルシリーズの試飲がある (普通のプレモルとマスターズドリーム・香るエールがある)。3杯までは飲んでいいんだけど、そんなに時間があるわけではないので、3杯飲もうとすると現実的にはキツいと思う。2杯半ぐらい飲んだけど酔っぱらってしまった。そして最初の1杯が一番うまいという。
ちなみに飲まない人はジュース(なっちゃん)が無限。運転手はオールフリーが提供されるみたいだった。案外子連れが多かった。
Safari 10.1 から CSS でも広色域対応
New Web Features in Safari 10.1 | WebKit
Editor’s Draft の CSS Color Module Level 4 を実装する形で Safari に color() が入ったみたい。
color() = color( [ <ident>? [ <number>+ | <string> ] [ / <alpha-value> ]? ]# , <color>? )
Apple はデバイスの DCI P3 対応をすすめてるのでその一貫なのかな。写真はもちろん広色域表示が現状でも可能なんだろうが、これがウェブのCSS色でも可能になる。広色域な画像とサイトのCSS色とを完全に一致させる方法は今までなかったが、これによって実現できるようになる。
Amazon Cloud Drive に写真をバックアップ
Amazon プライムに入っていると無限に写真をアップロードできるので、バックアップのバックアップという位置付けで、たまに Amazon Cloud Drive にもアップロードしています。
Amazon Cloud Drive の定義する無料の範囲の「写真」には RAW ファイルも含まれるため、完全なバックアップとすることができます。そして容量がかさみがちな RAW ファイルのバックアップ先としては、プライム価格に含まれていることで Google Drive など競合サービスよりも圧倒的に安い選択になります。
転送が止まる
「待機中」のまま全てのタスクが止まることがあります。よくわかりませんが Amazon Drive のプロセスを再起動すると継続されます。
たぶんクライアント側のバグなんですがサービス開始当初からずっとなおりません。この挙動のためアップロードを放置しておくことができず、定期的に再起動する操作がいるのでだるいです。
アップロード済みフォルダの再アップロード
観察した限りではアップロードフォルダを再度指定しても再転送は行われず、即座にアップロード完了になるようです。
不要なファイルを除外したい
できないようです。
サイドカー XMP ファイルや動画ファイルはバックアップから除きたいわけですが、バックアップしたいファイルだけを含んだディレクトリ構造をつくるしかありません。
写真以外の無料枠も多少はあるので XMP ファイルぐらいなら上げておいてもそれほど問題ではない気もします。