Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

たまたまとあるツイートのリプで見かけたので記録しておく。

1つめの検索結果に出てくる Happy Elements北京市に本社を置く中国のモバイルゲーム開発会社だ。検索結果には他のゲームの名もあるし、大正ロマンというのは江戸に並んで日本的なもののイメージを描くのに便利であるため、ゲームで多用されるのかもしれない。ゲーム以外だと、茎(STEM)のショートムービーに代表されるように椎名林檎大正ロマン的な雰囲気を歌詞に多用する。頽廃的で個人主義的な恋愛など、描きたいことに共通点があるのかもしれない。

大正ロマンが描かれること自体に問題性は無いのだけれど、軍のイメージが流入することも多いっぽいのが問題をややこしくしている。どうやら憲兵を描いて大正ロマンの看板を掲げたのかな、検索結果にも「憲兵」というのがあってそれが批判対象にもなっている。僕からすると、椎名林檎の次にイメージがあるのは「花子とアン」で、柳原白蓮大正ロマンWikipediaの項目に加筆したりしたくらいなので、大正ロマン憲兵のようなものに抗する側のものという印象をもっていて、大正ロマンの一環として理解するのには違和感を抱く。しかし、日本語を読めない人が勝手に付けたイメージではなくて大正ロマン風と評されることの多い「千本桜」についてもたびたび指摘されるように、イメージとしてコンタミが生じているのもなんとなくは知っているから、全くの勘違いとも言い切れないのがややこしいところだ。

それにしても、おそらく韓国の方々が問題視している三一運動との同時代性についても、大正ロマンとかかわりの深い大正デモクラシーの代表的思想家吉野作造"『中央公論』などに朝鮮総督府の失政を糾弾し、朝鮮の人々に政治的自由を与え、同化政策を放棄せよとの主張を発表した"くらいなので、さすがに批判した側とされた側をいっしょくたにするのはどうなんよと思う。

ここまで知識を共有してもPC的判断は割れるだろうけど、そこに答えを出すことには興味ないので、ここまで。概念が作られたり再構築される過程やその検出に興味があるので、記録しておく。

翻訳本をMendeleyで入力してBibTeXで使いたいから、Notesに原著情報書くことにした

翻訳のある本を原著で読んで、引用したい場合、社会学のレポートでBibTeXを使う手順 - 503 Service Unavailable にある

@BOOK{Esping-Andersen1990,
  title = {The Three Worlds of Welfare Capitalism},
  author = {Esping-Andersen, Gosta},
  year = {1990},
  publisher = {Princeton University Press},
  jtitle = {福祉資本主義の三つの世界},
  jauthor = {岡沢 憲芙 and 宮本 太郎},
  jyear = {2001},
  jpublisher = {ミネルヴァ書房},
  isbn = {9784623033232},
  url = {http://amazon.co.jp/o/ASIN/4623033236/}
}

みたいに入れてもよいと思うけど、この書き方は「翻訳のある外国語文献の場合は、原書の情報に加え、以下のフィールドを追加。」と紹介されている通り*1、厳密にいうと、英語で原著を読んで邦訳があることを読者に教えてあげるねって書き方なので、原著がメインに押し出されてるんだよね。翻訳書を読んで原著読んでないのにこの書き方するの、僕は結構気が引ける。

あと、jってなんやねんというのがありまして。LaTeX tiny Tips で配布されてる bst ファイルで定義されているだけで、もちろんBibTeXの一般語彙ではないです(ジャワ語(Javanese)に翻訳された本とか、ロジバン語(Lojban, ISO639がjboなんだよねw)に翻訳された本(!?)とか考えると、jtitleのjがJapanのJなら汎用性を持たない構造だなと分かるわけです)。

使えるんだからいいじゃないか!というのも一理あるんだけど、中途半端に流通したりすると、QA: 文献リストの邦訳論文について ←こういう混乱が生じるわけです。BibTeXにはちゃんと情報入れたのに、なんで邦訳の情報が表示されないのと。外部環境とセットにならないと明白にならないセマンティックスをデータに入れてしまうとこうなる。

根本的な問題を言うと、BibTeXが悪い。ありがちな、翻訳書をどう書くかという問題について、スマートな解決策を持っていないフォーマットなのだから、BibTeXが悪い。というかそもそも語彙についてW3CIETFみたいな標準化団体を持たない世界なのでやんぬるかな。

しかし、その悪いBibTeXを使うときに、(1)無理くり構造化する (2)構造化をあきらめて備考的に原著情報を書く という2つの選択肢があるので、(2)でええやんと思います。

@book{Nancy1999jp,
author = {ナンシー, ジャン=リュック and バイイ, ジャン=クリストフ},
isbn = {9784787210401},
pages = {121},
publisher = {青弓社},
title = {遠くの都市},
translator = {小倉, 正史},
year = {2007},
annote = {原タイトル: Los Angeles ou la ville au loin
原著者名: Jean Luc Nancy
原出版社: Fayard
原著出版年: 1999}
}

Mendeley で入力しているときには Tools>Options から Translators という項目が追加できるので、翻訳者は追加できます。他の情報はNotesに入れるとannoteとして出力されます。こういう微妙な対応関係は Mendeleydesktopの属性とBibTeX属性の対応 - 発声練習 に書かれている。

碌な代替がないから僕はBibTeXの方がplain textよりは好きなんだけど、ちなみにRISは

  • TA Translated Author
  • TT Translated Title

の2つの項目を持ってはいる。EndNote XML は知らない。ORCIDとか出てきたらAuthorにもID与えたいよねとか考えると BibTeX後方互換性のあるまともな標準化が必要なのかも? jtitle の代わりに original-title 、あとoriginal-isbn みたいなID参照系の語彙が広まってくれればいい、というだけの話なのかもしれない。

その他参考:

*1:だから、このブログには何も問題がない

Spatial Data の LOD を書く

地理情報に関わるLODを書こうとしたときに、語彙がいくつかあって、どれをどのように使うかという選択に迫られる。Spatial Data on the Web Best Practices にそのベストプラクティスが書いてあるのだけれど、いくつか補足をしようと思う。

Feature と Geometry を区別する

f:id:cm3ak:20190102040236p:plain

この区別は上の箇所に書かれている。緯度経度を直接持つような情報は Geometry クラスが期待され、人のような空間位置が一定でないものは Feature クラスが期待される。w3cgeo:SpatialThing はそのどちらもになりうるためセマンティクスに混乱があること、それゆえ、この文書では "SpatialThings" として geosparql:Feature のセマンティクスを想定しているということが書かれている。

例として、都道府県の例を考えてみる。都道府県は空間位置が一定だからGeometryだろうか?そうではない。Polygonで領域を描いたもの、都道府県庁の位置を代表点としてPointで表現したものなど、複数のGeometryを持つ Feature として定義でき、rdfs:subPropertyOf geosparql:hasGeometry となる defaultGeometry という述語で、領域表現を特別扱いすることができる( schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf では "It is Usually the most detailed geometry." と書かれている、この例は私が仕事で使う際に考えたもの)。

文書内には、他に灯台の例が "6. Spatial Things, Features and Geometry" に書かれている。灯台は、ヘリの操縦者からは「高い障害物」として高さと正確な位置が重要になり、水兵からすれば「航路標識」として光の種類とだいたいの位置が重要になる。そういう個々の観点での特徴のまとまりが Feature なのである。

f:id:cm3ak:20190102045600p:plain

A. Applicability of common formats to implementation of best practicesの2つめの表。dcterms は緯度経度を書くような Geometry を扱えず、他は Feature と Geometry それを結ぶ述語は上図のようになっている。但し、すでにみたように、w3cgeo にはセマンティクスの混乱が見られるので、ちゃんと書きたい場合には vcard 以下の語彙を使うことになる。

それにも関わらず、w3cgeo を最もよく見かけるのは、Feature に対して、単一の緯度経度標高のみの属性を書きたいことが圧倒的に多く、その目的で使う分には便利だからだ。文書内ではセマンティクスの混乱についての指摘以外でw3cgeo は2つの例で使われている。

<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587> 
  a geosparql:Feature, bag:Pand ;
  rdfs:label "Pand 0363100012169587"@nl;
  
# Detailed geometry  
  
  geosparql:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;
  bag:geometriePand     <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;
  
# Centroid

  w3cgeo:lat  "52.37509"^^xsd:float ;
  w3cgeo:long "4.88412"^^xsd:float ;
  
# Bounding box

  georss:box "52.3749,4.8838 52.3753,4.8845"^^xsd:string .

詳細な Geometry を書く geosparql:hasGeometry と並置して、w3cgeo:lat と w3cgeo:long を代表点として書いている。

:myPointOfInterest a w3cgeo:SpatialThing ;
    dcterms:description "Anne Frank's House, Amsterdam."
    w3cgeo:lat "52.37514"^^xsd:float ;
    w3cgeo:long "4.88412"^^xsd:float ;
    .

これは w3cgeo を使えば測地系がWGS 84であることが前提できるという話で書かれているだけだが、上と同様に代表点を記述している。

w3cgeo を使うもう一つの理由は、vcard、georss、geosparql、locn は主に次に説明するgeo URI と呼ばれるものや、Well-known text Literal を使うことが多く、LODとして構造化できないという問題があるため、構造化して書きたければ w3cgeo か schema.org の2つになるということである。これは、

As part of the vocabulary, an RDFS datatype is defined for encoding detailed geometry information as a literal value. A literal representation of a geometry is needed so that geometric values may be treated as a single unit. Such a representation allows geometries to be passed to external functions for computations and to be returned from a query.

という事情でそうなっている(GeoSPARQL - A Geographic Query Language for RDF Data | OGC

緯度経度情報をつかって何をしたいかというと、計算して絞り込んで可視化するといったことになるのだが、計算の部分では領域の被覆をチェックするなどgeosparqlなどの発展的なSPARQLを使いたくなる(=WKT Literal とかで表現しておきたい)一方、可視化の部分では緯度と経度に切り分けて取り出したかったりするのだが、GitHub - mapbox/wellknown: GeoJSON-emitting WKT parser for browsers and node とかでパースすることと組み合わせれば、それで問題は無いはず。

geo URI と geohash

vcard では geo URI をつかうと書かれているが、それでは1D~3Dは使えない。

f:id:cm3ak:20190102093445p:plain

RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI)

7.3. GML 'Circle' とか 7.4. GML 'Sphere' って項目があるからてっきりそのくらいの形は扱えるのかと思いきや、geo:%lat%,%lon%;u=%unc% という表現形式で、緯度経度とメートルで範囲を表したuncertaintyが指定できるだけなので、基本点しか表現できないと思ったほうが良い。

vcard が元々名刺のような情報を書くことを考えれば当然かもしれない。自宅や会社の位置を書くのに Polygon で書ける必要があるだろうか?

似たように点でしか表現できないが緯度経度をidentifier化できるものに

geohash.org

がある。あまり使いどころが多いように思えないが、リンクになっていることで、それぞれのフォーマットに dereferenceable になるのは良いかもね。

f:id:cm3ak:20190103030229p:plain

  • osm: open the location in OpenStreetMaps
  • gmaps: open the location in Google Maps
  • gc: go to the nearest geocaches in Geocaching.com
  • gpx: go directly to GPX download page
  • garmin: go directly to Garmin download page
  • text: show coordinates as plain text
  • url: show Geohash URL as plain text
  • maxlen: maximum length of the Geohash

次に述べるような「フォーマット」じゃないけれど、よくあるサービス用のURLを生成してくれるのは嬉しい。

データフォーマット

f:id:cm3ak:20190103023334p:plain

A. Applicability of common formats to implementation of best practices の1つめの表から抜粋)

Well-known text フォーマットは既に述べたとおりで、Supported by most triple storesそしてGeoJSONに変換できる強みがあるので、今の文脈だと最も利便性が高いだろう。3Dサポートが必要になった時には、GMLを使う。この2つで十分じゃないかな。他にHTMLはウェブでの発見性という利便性が強調されていたけど、LODの Content negotiation 使えばそれで問題ないわけだし。

結局語彙はどれを使うべきか

  • データフォーマットでWKTGML使うなら、語彙はgeosparqlを中心につかえばよい。
    • ウェブでの表示は GeoJSON に変換して表示する
    • WKT は多くのtriple storeで演算がサポートされているようだ。
  • 構造化で簡単に緯度経度だけ付記したければw3cgeoでの記載を伴わせる。
  • ISA Programme Location Core Vocabulary locn は何でも使えるようにしてあるが、逆にわざわざ使う場面は少ないかも。多様な形式で書かれたデータを変換など事前にせず雑多なままデータ化したいときに便利かもしれない。
  • vcard と georss は名刺情報や更新される地理情報を書くときなど、用途次第では周辺ツールの対応があって有効かも。

ResourceSync について最近あったQA

口頭でどこかで答えたりしたことをメモっておいてツッコミ可能にしておく。

ResourceSyncって何?(ツイッター的140字)

ResourceSyncとは:OAI-PMHの後継と目されている静的連携のためのプロトコルで、sitemapsを拡張したもの。メタデータだけじゃなくてコンテンツも同期の対象にしうるとこと、情報発信側からのプッシュが可能なことが特徴。まだ普及していないが幾つか実装はある。詳しくは http://current.ndl.go.jp/ca1845 参照

ライブラリとかソフトウェアの実装状況は?

は上の記事にも載ってるけど、一番使いやすそう。他、時期的に上に漏れてる話として僕が把握しているのは

(こういうのは Scrapbox とかで Wiki 的にupdateすべきだ…)

resumptionToken の代替は?

OAI-PMHでは、3.5の Flow Control に resumptionTokenを使ってちょっとずつリソースを取ってくる実装がmust指定されている 。今こういうのは必要なくなっているのかというと、確かに回線は安定したし、太くなったし、必要は薄れているんだけれど、ResourceSync は zip で固めたコンテンツも流すんだから、その分ダウンロードが途中で切れるとかいう問題も発生しうると思う。最も大事なのは、ResourceList も複数に分けることができるのだから、ある程度は適切なサイズになるように設計すること。そして、適切なサイズのダウンロードに失敗するようなら、もう一度取りに行けばいい話。

一応、巨大ファイルの断続的ダウンロードについての解決策も、もう一つ低レイヤーの解決策が普及してきていて、HTTP range requests を使えばよいと思う。

増分同期で from で指定したいのはこっちが前回いつとりに行ったかじゃない?

ResourceSync にも Resource List の at や Change List の from といった情報があるがこれは情報を出す側の視点であって、取りに行く側からはどれを取りに行ったらいいかが OAI-PMH より複雑、というのはそれはそう。差分を処理したいときには、Change List Index から順に辿っていって、ダウンロードが必要か必要じゃないかを1つ1つ判別しつつクロールしていくことになる。resync/resync at master · resync/resync にも from オプションがあったりして、そういう利便性はライブラリレベルで解決されるべきだし、そういう方向性になっている。基本的にコストをハーベストする側に載せているので、ハーベストする側が実装を工夫する必要があるケースは他にもあると思う。

PubSubHubbub の実装は必須なの?

まず、PubSubHubbub (PuSH)じゃなくて、今は WebSub に名前変わってる。それを使う Change Notification と Framework Notification が "Additional" Specifications になっているので、必須じゃないです。Hub になるとこをどこが担うの?とか組織連携的な課題があるので、研究実験や必要性を検討した上で必須だという結論に至った実装でない限り、実装は後回しで良いんじゃないかな。

だったら OAI-PMH から移行する動機は?

  • 十分な大きさの画像サムネイルを同期したいでしょ?
  • アーカイブ」ならEADが大事だったりするし、メタデータの構造やファイルフォーマットはもっと自由に書きたいでしょ?
  • もう、グーグルに拾われないとそもそも流入が望まれないのでSEOも運営上大事で、sitemaps 互換なのでSEOにもなる。

(僕はデジタルアーカイブや研究資源データベースに関する相談で聞かれるので、そういう偏りのある回答ではある)

sitemaps から、連携の必要性に応じて増築していって、ある時点で整理するという形でもよいかも。

ジャパンサーチがOAI-PMHでデータ取るって聞いてるんだけど

tl;dr OAI-PMHは必須じゃないし、ResourceSync ベースでもなんとかなりそうだよ。

僕も、OAI-PMHとウェブサイトから手動でアップロードの2つだって聞いてる。でも、ジャパンサーチ(仮称)の連携フォーマット(案) の冒頭の方に、「連携を容易にするため、原則、ファイルベースでの連携を行う(OAI-PMH は必須としない)」と強調されているように、ファイルベースになるなら ResourceSync も親和性が高いのではと期待はできる。「複数のファイルをzip形式で圧縮したファイルにも対応する。」となっているが、余計なファイルが含まれているとエラーになるようなので、ジャパンサーチ専用にファイルを生成する必要はでてきそう。それが特定の Resource List Index から自動生成できるだろうから、Resource List Index の URL を入れると、必要なファイルが返ってくるというものを誰かが作れば済む話ではある。「連携機関のメタデータモデルをそのままの形で受け入れる。メタデータモデルは原則として自由であるが、最低限の必須項目(①オリジナル(ソース)データの一意の ID、②名称/タイトルの 2 項目)がある等の制約を設ける。」というのも先ほどの自由なメタデータ記述を阻害しないように設計されている。

学術や官公庁の外注ではオープンソースソフトのクラウドサービスを組み合わせるべきという話

表題の基本的な理由は以下の通りだ

  • 年々厳しさを増すセキュリティ対応の要請に対して、自前のシステムや自前でのオープンソースホスティングが高コストになりつつあり、それがクラウドサービスの値段を超えることが多い
  • モノリシックに作ると、何らかの理由でリプレイスする際に全体をリプレイスする必要があり、高コスト。また、プロトコルやファイルフォーマット対応が遅れがちであるため、データの移行も困難になりがち。
  • どこも若手の人的資源が足りておらず、それをメンテナンスに関わるあまり生産性の無い業務に割くのは愚か。
  • 日本のIT業界も人材が足りておらず、0からなんでも作ってクオリティを担保するようなことは不可能。できるところに集中して取り組むような、体制でプロダクトを作るべき。

ある業者にサービスのクラウド化を勧めたときに、「やっぱ時代はクラウドなんですかねー」と言われてしまったので、「そういう流行の話をしているのではなくて、同じお金をお互いにとって有効に使いましょうという話です。たとえば、個々の機関の個別のセキュリティ対応とかになると、そちらのエンジニアも碌に技術が身につかず楽しくもない作業をさせられて、こちらも学術的に何の売りにもならないところに高額を払うことになる。クラウドならそれをそちらのサーバ側の更新で済ませて、そういう作業は月額料金に反映させることでセキュリティ対応コストは各機関で分担することができる。その分、他の新しいことを外注できると、そちらもウリになる技術が増え、こちらも学術的成果が増えます。」と説明してしまった。

「しまった」と言っているのは、業界の歪な構造もわかるからである。ちょっと最近読んで感動したレポートがあって、MRI | 所報 No.55 | 図書館システムを取り巻く課題と今後の展望 ここにもOSSクラウドの話が書かれている。2012年。その中にこういうくだりがある。

年間のシステム関係費は100万未満から3,000万円以上まで著しい差があり、かつ、万遍なく分布していることは注目される (中略) 図書館システムについては、「図書館側の予算額に応じて費用を請求する」ということがまことしやかに囁かれるが、その疑念を強める結果である。

これは企業側の搾取だとは言い切れないし、図書館側の無能とも(図書館単体では)言い切れない。このレポートも三菱総研という「企業」が書いているので前者はよくわかっていて、「金額的な「相場観」をほとんど持っていない可能性」などを指摘している。これは上側は当然、下側もそうで、自治体は過度な緊縮財政で「出費を抑えました!」と吠えたりすることがあるが、出すべきところに出さないと業務は持続可能に回っていかないのは当然なので、もちろんどこかに適正な額というのが存在するはずであり、下がれば下がるほど良いというものではない。また、業務のクオリティというのは測りにくく、この適正な額を発注側が推測するのは事実上不可能である。図書館側の無能とも言い切れないというのは、ウィルダフスキー『予算編成の政治学』 とかを念頭に発言しているが、図書館単体ではそれを推し量る情報と能力と推し量った時に得られる利得という環境を持ち合わせていないという構造的な問題であって、各図書館の発注金額を共有することによって、この予算編成の実践そのもののサイクルの中でより適正に発注できるようにするといったような、図書館群としての工夫をしない限り、単体では「ちゃんと相場観を身につけましょう」とレクチャーしたところでそれは難しいであろう(もちろんこの素晴らしいレポートはそんなことは言っていないし、「ユーザ会」の結成といった提言をあとで出したりしている)。

話をもどすが、こういう状況が学術や官公庁の発注で生じている中で、出せるところから取るということを企業側もやらざるを得ず、それとクラウドでありがちな月額〇〇円というオープンプライスの提供は相容れないのだ。学術の話に至っては、「選択と集中」という政治的ストラテジーがその問題をさらに加速させている。

解決策の一つはクローズドプライスでクラウド提供することだ。例はあるだろう、僕が最近見たのは LYRASISがArchivesSpaceのホスティングでまずは連絡を とやっているのとか。ちなみに、カスタマイズは別料金ってのは多くがやっている(そもそもカスタマイズすべきではないけど)。しかし、ここまでの碌でもない状況を踏まえてあえてクローズドプライスに乗ってバラバラの金額を出すことができたとして、その状況がオープンになると、まあ、昨今だと市民の皆様に叩かれる。東大、京大の無駄遣い!となる。市の税金や科研費とか使うと、オープンにせざるをえない(し、オープンにすること自体は良い効果がたくさんある)ので、漸次的に解決するのではなく、この解決策を捨てて根本的解決に至らねばならなさそうだ。

  • 公共の利益にかなうような利用に対して、長めの無料期間を設定することで、少額しか払えないような組織がその無料期間の業績を元に予算申請できるようにする
  • Bountysource 的な仕組みで、システムの課題を各機関側が出して企業にハントさせる。ハントされなかった場合に予算執行できないのが問題になるので、なるべく細かい問題に落とすこと、問題を練るフェーズを設けることが必要になる。これによって、他の組織にとっても問題になってる課題を多く予算配分されてる機関が出せばよいということになる。

くらいが思いつくところ。

「ノン・カスタマイズを基本としてシステムを構築することを目指すべき」ってさっき上げた報告書にも書かれていて、これは周りでも最近よく聞くんだけど、特に引くようなソフトウェア工学箴言とかもなく、こういうマネジメントレベルの話をもっとだれかちゃんと偉い人が語って、バズらせて、みんなが参照するようにならないといけないと思う。報告書、図書館システムにとどまらず結構一般的ないいこと言ってると思うので、公益事業によるシステム外注の6箇条みたいな形で

  • メンテナンスや追加発注などを含めPDCAサイクルをまわす
  • ノン・カスタマイズのシステムをAPIなどを活用して組み合わせ、独自開発の部分は絞り切る
  • 同業者で情報交換をする
  • OSS 利用を検討する
  • システムの共同化を検討する
  • クラウド利用を検討する

あたりはもっと広まってほしい。

その他参考:

Docomo キッズケータイ F-03J を大人が4カ月使ってみたレビュー

f:id:cm3ak:20180430210828p:plain

背景

  • ケータイなくしたので、新しいケータイとして買った。スマホは持っていない。
  • iPad miniWiFi で普段使っている。家にもインターネット引いてるし、職場でもWiFi 使えるし、外でも WiFiルーター 持ってる。050の電話番号も別途持ってはいる。
  • 事前に感じていた必要性は、「SMSによる認証を可能にすること」「個人の電話番号として書くことができ、快適に話せる電話番号を持つこと」

Pros

  • かわいい
  • 機能が絞られているので、電話以外でダラダラいじることがない。
  • 本体代も維持費も安い。契約を新規契約にすれば本体代がタダ(契約手数料とかがあるので初期投資は3261円、月額989円)。

f:id:cm3ak:20180430205636p:plain

  • SMSの受け取りができるので、international なウェブサービスでよく用いられる SMS による認証が可能。050の電話番号でできないのはこれ。
  • 通話音質はもちろん良い。WiFi による050通話はまだまだこの点がなー。
  • 端子は microUSB なので lightning ケーブルみたいに断線のたびにお高い出費を要求されない(100均で質のいいのが売っている、lightning も最近100均で売っているが質が悪い)
  • アラーム機能がある
  • Bluetooth でつなげば iPad などから電話帳などを管理、追加できる(「親子のきずな」という名前のアプリを用いる)

f:id:cm3ak:20180430210902p:plain

  • 電源のオートオン、オートオフ機能はないが、「本体設定」>「音・バイブ」>「マナーモード設定」>「自動 設定」で、マナーモードの自動オンオフがあるので、夜中にかかってくる電話に起こされることはない
  • 電池の持ちがよい。平均20日くらい持つ。

Cons

  • このキッズケータイというよりストレート型全般のデメリットだが、カバンに入れておくと勝手にボタンが押されて発信していることがある。メニューキー長押しでロックがかけられるが、かけ忘れやロックすら勝手に外れることがある。他の人のYahoo!知恵袋やブログでは警察に勝手にかかってしまったとの報告も(機種が違うかもしれないが、緊急電話へのショートカットキーがあるのでかかりやすい)。僕も旅行会社等に3回、ある先生に1回、かかってしまった…。今は、ケースを使うことで対処している。個別連絡先のショートカットキー登録はしていない。

f:id:cm3ak:20180430210256p:plain

  • 「〇〇の人は1を、それ以外の人は3を」…みたいなのができない。意外と登場機会がある
  • 入力は中央のキーを方向キーとして使い数字や文字を選ぶ方式
    • 文字入力は面倒すぎるのでできないと思ったほうがいい
      • 最近は LINE や Facebook Messenger を連絡手段として使うことが多く、WiFiの通じる環境ならば問題ない。
  • 電話をかけるたびに電話帳に登録する必要があり、それも面倒。意外と機会がある
    • 何かのサービスに係る電話、例えば飲食店の予約で1度切り、しかも取れるともわからない電話番号登録するのはありえないが、出張先でそういう需要に見舞われたとき、職場の固定電話はなく、これを使わざるをえない。
    • 人との待ち合わせ
    • ここらへんは、Wifiで用いる050電話を用いるとマシ。

IP電話や通話アプリについて

キッズケータイとは別にパソコンやiPadで電話することも増えている。こういう手段についての記事は世の中には山ほどある。

050の電話番号が手に入り、一般の電話番号にもかけられるもの

2019年4月加筆時点でも音質は総じて良くないが私が使っているものをあげておく。

  • SMARTalk 基本利用料無料で使った分だけ後払いというのがよい。
  • My050 基本利用料無料でプリペイド式なので先にまとめて購入する必要があるが、050では一般的に掛けられないフリーダイヤルが使えるという利便性がある。

専用のIDで掛け合うもの

  • LINE: プライベートではいまや基本ツールで欠かせない。ポケットWiFiでは音質は良くないが家のWiFiだと音質も十分
  • WeChat: 中国の友人とはこれを使う
  • Skype: Windows に組み込まれたこともあって使っている。大学の業務で遠隔会議にもよく使う(Polycomが用意できない環境も多いので)
  • discord: 特殊なポートを使うため大学では使えず、なんとなく使わなくなったが、同時通話機能の質が高かった。
  • Google Hangout: たまに指定があれば使う

その他

  • ネットができないので MyDocomo の登録が携帯からできないが、契約時にショップでやってもらえる。
  • dカードでの引き落としにしたら、dカードの年会費はタダになってポイントがたまる。クレカをあまり無駄に持つのは(管理が行き届かなくなって)良くないけれど、僕はちょうど必要性が生じていたので契約した。
  • 大学入学時に親名義の携帯を譲り受けて以来、名義変更を行っていなかったので、今回「親から独立している」ことを理由に名義を自分のものにしつつ、「キッズ」ケータイを契約するという冗談のような手続きをした。

東京でスーツケースを預ける

I'll write in Japanese first. At the end of this entry, there is short information of ecbo.io, which is IT integrated service for making cafes your coin lockers available in Tokyo area.

海外旅行スーツケースサイズのコインロッカーはそれほど多くない。新宿西口にそれなりにあるが渋谷は絶望的で、またカプセルホテルやラブホは荷物を預かってくれないことが多いなど、東京は大きなスーツケースを持った海外旅行者には不便な街である。

そこで、カフェなどにスペースを一律料金でレンタルさせて、検索・予約・支払いの仲介をサービスとして立ち上げたのが ecbo (cloak.ecbo.io) で、非常に良いセンス。考え方がリクルートっぽい(人と人を仲介する効率化を図っているので)と思ったが、代表取締役社長は90年生まれでUberでインターンということで、新世代ですね。

僕は試しということで1200円分-300円のクレジットと呼ばれるクーポン(みなさんも僕のプロモコード ecbocloak-7TOkNLu4 を入れていただくと300円引きになる)で利用した。900円中、店に入ってたのは840円なので(こういうの気になるので店員の手元を覗く癖があるw)60円がマージンとして ecbo に行っているようだ。1/15は設定料金として変なので、おそらく、元値1200円の5%=60円がマージン料金で固定されているのだろう。

僕にとっては、さしてスーツケースの大きさを気にせず預けられるのが何よりものメリットだ。3連続で出張とかになるとかなり嵩張るので。コインロッカーと同じ価格帯と言っているが、大きいスーツケースで600円は安い。

僕が使った時、システム不具合でチェックインができず、チャットで質問して待たざるを得なかった(先進的なウェブサービスは問い合わせがチャットになっていることが多く、大好きだ)。そういう時に、とりあえず預けられるとか、ワークフローを定義することで、店や客がストレスなくサービス利用できるよう検討することを進言させていただいた。

en

ecbo cloak (in English) is the service for storing your luggage in local shops and cafes, in the same price range as a coin locker. You have to register credit card number, then you can search, reserve and pay for ecbo cloak online.

This is my Promo(tion) Code: ecbocloak-7TOkNLu4

You can get 300 JPY discount by inputting this code

f:id:cm3ak:20171120101853p:plain