Pebble Time Round で使っているミラネーゼループ腕時計バンドのレビュー

Posted 3 days ago by yoosee.
  pebble

Pebble Time Round は時計無精の自分としては大変珍しくほぼ毎日付けているが、それに大きく寄与しているのがミラネーゼループのマグネティックバンド。使っているのは Wearable4U Pebble Time Round Milanese Magnetic Loop Watch Band 20 mm (Black) というやつで $23.99 と値段もお手頃。

これなにが素晴らしいって留め金部分が限りなく薄くてフラットなこと。

Wearable4U Pebble Time Round Milanese Magnetic Loop Replacement Watch Band Strap for Pebble Time Round 20 mm (Black)

個人的な話になるが日常的に腕時計を付けていなかった最大の理由が、キーボードを打つ時に時計バンドの留め金部分が手首と机の間で自己主張してくれて気になってしょうがないからだった。1日のかなりの時間キーボードを打つ身としては、気になっていちいち外すのも毎度邪魔くさいので、結果として腕時計自体を普段はあまりつけなかった。旅行や出張のときくらいだろうか。

このバンドは留め金部分が平たいマグネットで、バンド自体も薄いため、一番厚くなるところでも 4 mm 以下。かつ形状がまっ平らなので、普通の腕時計バンドに比べたら手首下の当たり具合というのだろうか、気になる度合いが大変少ない。

それでも長時間キーボードを打ち続ける際には邪魔に感じることもあるが、まあ1日に1度程度なら外すのもそこまで億劫でもないし、Pebble を充電するいい機会でもある。

標準の革バンドに比べると多少の重みを感じるもののさほどではないし、5月に買ってほぼ毎日つけているが特に錆びたりなんだりという問題もない。ステンレスメッシュのバンドを磁力で固定する形だが、結構強力な磁石なので意図せず外れる事もないし、付け外しも最初は多少癖を感じるものの、慣れれば簡単。これの片側はU字ループになっているが、留め金が引っかかるのでループから外れるということはない。

確か twitter で @miyagawa さんが買ってたのを見て真似させてもらったんだが、よい買い物であった。

日本のアマゾンでも Pinhen MOTO 360 時計バンド マグネットクラスプ ステンレス ウォッチ 交換ベルト バネ棒 20mm として売っているものの商品写真がまるっきり同じなので、保証の限りではないが多分同じOEMの商品ではないかと思う。

ちなみに Pebble Time Round 自体は使いはじめて半年程度がたった今も以前レビューに書いた スタンスと変わらず、「時計」「通知」「ヘルスメーター(歩数計)」が軽快に使えるので日常使いのスマートウォッチとしては全く満足している。時計のフェイスを自分で書いて使えるのも意外と遊びとして楽しく、十二分に元を取った感はある。Time Round の新モデルが出たらどうしようというくらいが今の悩みだけど、買っちゃうかもなあ。

 

英語での数の数え方

Posted 14 days ago by yoosee.
  english

数字の数え方は日本でも中学英語で習うものではあるが、実際に口語で発音する場合には学校のそれとは結構違う流儀があって戸惑うことがある。以下は日常での数の数え方をまとめてみたものだが、話す分にはもちろんこうしたやり方に従わなくても通じれば問題ない。ただ逆に聞き取る際にはこうした話し方をされることを覚えておくと戸惑わずに済む。

numbers

なお以下は個人的な経験則から書いているので英語としての普遍性などは担保しない。一応米国で8年以上仕事と私生活で英語を使っているのでさほど外してはいないとは思うが、ツッコミは歓迎。

数字の数え方

4桁までの数字

基本的な考え方は以下。 Lazy な方向に全力で向いている感がアメリカ人らしい。

  • 4桁までは2桁で区切る。thousand や hundred は長くて面倒なので極力使わない
  • 0 はゼロとは呼ばず、0 がないと意味が取れない場合は仕方なく thousand や hundred を使う

例えば 1,015 は One thousand fifteen と読んでも当然通じるが、Ten fifteen と 2桁で区切って発音する事が多い。3桁の場合も同様で、hundred はあまり使わず、123 は one twenty three のように最初の1桁と後ろの2桁に区切って数える。

3001 や 203 など2桁で区切った上の桁がゼロの場合は three thousands one や two hundreds three などになるが、3011 など 2桁で区切っても通じる際には Thirty eleven などのように呼ぶ。アメリカ人はゼロの概念を解しない、わけではないが、ゼロという表現を使うことは少ない。

5桁以上の数字

1ドルが100円前後相当であり、インチとフィートなど桁が一定上がると呼称が変わる単位系を使っている米国では、5桁以上の数字を日常使うことはさほど多くない。5桁以上でも「2桁で区切る」ルールは可能な限り適用されるが、例えば 12,345 は twelve thousands three hundred forty five のように thousand の桁で一度分解される。123,456 になると one twenty three thousands four hundreds fifty six とする場合と、one hundred …(以下同文) と最初の桁の hundred もちゃんと言う場合に流儀が別れる気がする。好みの問題だろう。

また 5桁以上の数字ではそもそも4桁以下を無視してしまうことも多い。123,456 を about one twenty three thousands で終わらせてしまったり、Million の桁になると 11.4 million のように million を基準に少数点を使ってしまうパターンも多い。なおこうした場合の小数点はあまり省略されず、eleven point four million のように発音される。

なお 1,000 を k (kilo, ケー) で表現して例えば 20000 を 20k - Twenty k と呼んだりするのは IT 系では概ね通じるし一般の人も理解できる人はそれなりに多いが、万民向けではないので注意は必要。

小数点

小数点は特に発音せずに一拍置く場合と、明に発音する場合があり、発音する場合は point と呼ぶ。感覚的には数値の議論では発音することが多いが、値段をドルを言う時などは発音しないことが多いように思う。発音しない場合、例えば 19.99 は Nineteen, ninety nine のように小数点のところで0.5秒ほど溜めてから小数点以下を発音していく。

小数点を明に呼ぶ場合は point を使うことが多いので、例えば 23.4 は twenty three point four のように呼ばれる。バージョン番号などでは dot を使うこともあり、v 2.3.8 は version two dot three dot eight のように呼ばれる。

小数点以下については 2桁で区切れる場合は2桁での数字の呼び方をする(特にドルの小数点以下のセント部分)が、桁数が多い場合には例えば 9.0246 はそのまま Nine, zero two four six のように呼ぶ。こうした場合は 0 を zero と呼ぶ事が多いが、o (オー) で呼ぶ人も少なくない。

個別ケースでの数字の呼び方

部屋番号など

四桁の部屋番号であれば普通に2桁に区切って 1234 号室 は twelve - thirty four と呼ぶか、もしくは単純に one two three four と呼ぶ。またこういう場合のゼロは オー と呼ぶことが多いので、例えば 102 は one o two と呼んだりする。

西暦

西暦も基本的には2桁区切り。1995 は Nineteen ninety five 。例外として 200X 年代は Two thousand X の用に呼ぶ。その流れか、現在の 201X 年代も Two thousand sixteen などのように呼ぶ人もいるが、Twenty sixteen の方が短くて楽なのでそっちを使うことを勧めたい。

日付

日付の呼び方は国によってかなり流儀が違い、米国と欧州では異なるし欧州内でも異なるので詳しくは locale のリソースでも眺めるのがいいと思うが、取り敢えず米国では month date, year が普通なので例えば September 9th, 2016 のようになる。サインに書く日付などでは Sep 9, 2016 と書いたり 9 / 09 / 16 のように書いたりといくつか流儀があるが、month date year の順番は概ね変わらない。

時間

時間、時計の読み方は2桁で区切る原則そのもので特別な話はない。例えば 3:37 pm であれば Three thirty seven pm である。o'clock を付けることは少ない。面倒なので。注意点としては、米国人はゼロの概念を解しないので、0 - zero 時という言い方はせず、朝でも昼でも 12 - twelve であるということくらい。また殆どの人は24時間制ではなく12時間制を使うので、23 - twenty three ではなく 11 (pm) - eleven (pm) を使う。

Check (小切手)

Check では数字とともにその数字の英単語記載を併記するが、この場合は2桁区切りなどはせずに thousand や hundred をフルに使って書くのが普通。セント部分は … and 0/00 のように書く。

数に関する豆知識

ドル

米国では 1 ドルのことを buck (バック) と呼ぶことがある。語源は19世紀の開拓者時代に物々交換に使われた buckskin (鹿革) らしいのだがさておき、CM などで “It’s only for nine bucks!” などと使われる。

電話番号

広告などで米国の電話番号を聞くと 800-GET-BACK などのようになぜか突然途中から電話番号が英単語にすり替わることがある。これ、米国の電話ではプッシュボタンの各数字の横にアルファベットが割当てられていて、例えば 2 の隣には ABC とあるので、そのアルファベットが書かれた数字を押せ、という意味。先ほどの GET-BACK だと 438-2225 となる。

アルファベットではなく数字で呼ぶ際は部屋番号のように個別の数字で呼ぶが、800 は eight hundred と呼ぶので、上記の番号であれば Eight hundred - four three eight - two two two five のように呼ぶ。888 は eight eight eight と呼ぶことが多い。なお 800 や 888 で始まる電話番号は米国のフリーダイヤル。

 

攻めのITを成功させるためには「経営者の確信」が必要不可欠

Posted 22 days ago by yoosee.
  uscompany it business

「攻めのIT」という単語を見かける。既存業務をITに置き換えるなどで効率化をはかるのみでなく、ITを軸として売上や開発・競争力などを強化していくことを「攻め」と呼んでいるようだ。

IT


米国では既に多くの企業が ERP や CRM などを始めとした IT システムの大規模な導入を行っており、日本よりも IT への投資が積極的であり、その分野も「攻め」に重点が置かれていると言われる。この違いはどこから来るのだろうか。

攻めのIT導入に必要な「経営陣の確信」

まず大きく違うのは IT への期待値だろう。米国では「ITが企業を変革すること」に疑問がない。周囲の企業が成功しており、その手段が確立しているのだから、それを導入することで成果が得られることについては、米国経営者にとっては特に疑問を抱く必要もない単なる事実であり、単に予算とやり方の問題である。日本企業とそのマーケットには未だそれがない。ないから確信を持ってITへの投資を決断できない。鶏と卵だ。

大規模なITの導入というのは実のところ「プロセス」「プラクティス」の導入と同義だ。業務プロセスを場合によっては根本から変革し、業界で先行している「うまくいくはずのやり方」に強制的に合わせさせるのがIT導入の意味である。つまりITを業務プロセスに合わせるのではなく、逆に業務プロセスをITにあわせて再構築するのだ。例えば「ITIL・ITSM準拠のITツールを導入する」ことで業務プロセスそのものをそうした業界のベストプラクティスに合わせてしまう。プロセスが主眼であり、ITはむしろ支援と強制力である。

つまりITの導入というのは得てして既存プロセスの破壊になる。それが故に、社内の反発は大きく、コストも決して無視できず、また現在動いているものを大きくいじるのだから業務が破綻しかねないリスクもある。まして日本企業のように、各担当部門が個別に最大限「努力」してしまう文化では、プロセスの破壊は努力の否定に見えかねず、反発は巨大なものになりうる。

これを乗り越えてITシステムを導入させるには、どうしても導入を先導する経営者が揺るぎない確信を持っていないといけない。予算をつけ、社内政治を整理し、反発する現場に導入を受け入れさせる事を「当然必要なこと」として自己正当化できている必要がある。

米国経営者の立ち位置とIT改革の容易さ

米国の経営層は基本的に「経営職(Executive)」という職種である。彼らは会社経営という分野の専門職であり、その方面の専門スキルを持って経営職ポジションに転職し、経営という業務を遂行する。キャリアパスの回で少し書いたように「スキルレベルを上げてクラスチェンジ」ルールは幹部についても同様で、米国企業の幹部、VP 以上や CxO 職は言うならば「企業経営 Lv.3」や「組織運営 Lv.4」などの経営スキル、加えて CIO などの専門経営職は「IT戦略 Lv.3」「ITシステム導入 Lv.2」などの分野専門スキルを持っている。

米国でこうした経営層が新たに雇われた場合になにを期待されているか。例えばよくある例では「既存の問題によって前の幹部が解雇された。新しい人にはそれを解決して欲しい」ので、早々に新しいアクションが求められる。実際こちらの幹部は採用されるとまず前任者の否定から始めることが多い。「あいつのやり方じゃダメだ。俺が正しいやり方を見せてやる」というやつである。

給与の高い彼らは、幹部として雇われてから比較的短期に目に見える成果を上げる必要があり、またその対象も事業部門なり全社なりと広い。何もないところから手っ取り早く何かしらの成果を出す方法がそこらにたくさん転がっているわけでもなく、ゼロから全てを作り上げる時間もコストもない中で、多くのプロ経営者が定石として使うのがITシステムの更新なのだ。

例えば ITIL であったり ERP であったりという業界のベストプラクティスと関連したものは「既存の問題の認識とその解決」がテンプレートとなったものだ。導入手法もある程度確立しており、世間に事例も多く、周囲にも説明がしやすい。特に CIO などは「前職で○○システムを導入することで業務プロセスを改革しコストをX%カット、○○の期間をXX日短縮」のような話が彼らの履歴書に記載される。またそうした定石は、懇意にしている特定のITソリューション導入会社と組んで行うことも多いため、それも含めて手札にできる。そんなわけで米国の会社では「ITシステムによるビジネスプロセス改革」が銀の弾丸として頻繁に持ち込まれるのである。

日本企業でのITシステム導入の難しさ

そもそもの「社内IT」という仕事自体が政治の固まりみたいなものである。というのもITは本質的に社内の業務プロセスをサポートするものであるが故に、その変更は必ず社内の何処かの部署に業務の変更をもたらすわけで、当然ながら変化への反発と逆に推進したい側の意向がぶつかる社内政治の戦場と化すわけだ。

特に日本企業の現場は与えられた状況に我慢し、その条件下で最大限の努力と局所最適化を行ってしまっていることが多く、全体効率のためにプロセスを変更すると言われても「俺達の努力を否定するのか」という感情論・政治論になりやすい。それは米国ですらそうで、ITマネージャーに「政治的にスタッフを守る」「ITチームの正しさをきちんと裏打ちする」役割が求められるという事実が逆説的にそれを裏付ける。

米国の場合はそれでも基本的にはトップダウン組織であることが多いので、CEOやCIO といった経営トップがスポンサーになって導入自体は決断されるし、それに乗れない人は最終的には解雇されることもあるので、力ずくでも意思決定はされる。

一方の日本企業では人事の都合上、外部から明示的にプロを雇える米国と違って経営陣に必ずしもITのプロがいるわけでもなく、それ故の問題としてまず経営陣の理解を得るのに果てしない説明を要し、経営層のスポンサーを得てもトップダウンが弱いため各部を説得して社内合意を得ることにものすごいレベルの政治力が必要になり、その上で導入時には半端なく強い現場をどう説得して進めるかという超人レベルの精神力が必要になる。

人間、周りから強く否定されるような話はどうしたって進めにくいものだし、往々にして妥協案を出したくなるものだ。しかしITシステムの導入目的が既存プロセスの改革であり、そのプロセスはITシステムが規定している場合、そこで妥協してしまうと業務プロセスは改善されず、ITシステムは膨大なカスタマイズを抱えることになる。この辺が日本でIT導入がうまく進みにくい原因のひとつだと思う。

ここを押し切るには、推進する幹部自身がIT導入の正しさを確信している必要がある。そしてその確信は多くの場合、プロとしての膨大な専門知識と過去の成功が支える。組織構造的にどちらも得るのが難しく、現場の反発もより大きい日本企業の経営者がIT導入を確信して進めるのが難しい所以ではなかろうか。

 

Zirconia - Pebble 用ウォッチフェイスをデジタル時計でもうひとつ書いた

Posted about 1 month ago by yoosee.
  pebble

先日書いた Obsidian Watchface と同等機能のもので Zirconia という名前でデジタル時計のウォッチフェイスをひとつ書いた。例によって時間と日付に加えて天気・気温と歩数の表示付き。温度の C/F 切り替えや色の設定もつけている。

Zirconia - Pebble Watchface

先週末に Obsidian の方も天気の取得先を OpenWeatherMap.org から Weather.gov に変えて、そのタイミングで JavaScript 周りも幾つか修正したので、その勢いでデジタル時計も作ってみるかと思い立った。まあ機能はほぼコピペなので、デジタル時計の表示部分でフォントと配置を選ぶくらいしかやることはなかった。本当はもう少しコードを整理すべきなので、それはまた気が向いた時に。

天気の供給元をわざわざ変えたのは OpenWeatherMap があまりに正確性に欠けたから。なぜ普通に拾える NOAA より悪いのか…。WUnderground なども実装はしたものの、API が基本有料サービスなので github に API Key 入れたくないし対処するのも面倒だなということで止めた。本当は Pebble firmware 3.13 から追加された公式の Weather App がさっさと内部APIを公開してくれればよいのだよ…。

なおちょうど公開しようとパッケージを作ったタイミングで SDK4.0 がリリースされたお陰で、特に新しい機能を使っていないのに Pebble 側も Firmware 4.0 に上げないと使えなくなったというのがなんというか不幸な感じ。しかも SDK4 には Pebble 2 “Diorite” 対応はあるけど Pebble Time 2 “Emery” 対応はないのは半端な感がある。

 

Facebook Comment Plugin と Rails Turbolinks の共存

Posted about 1 month ago by yoosee.
  textfi rails

このブログでは Facebook Comment Plugin を使っているのだけど、割と頻繁にそれが表示されないということが起こっていた。少し調べるとどうも Rails4 の Turbolinks の影響らしい。Turbolinks は Rails でページ間遷移をした時にコンテンツを差分だけ部分更新することで読み込みをかなり早くするというありがたいものなのだが、その性質上、document.ready や on.(“page:load”), (“page:change”) などのイベントが食われてしまう。

fb-comment

対策としては jquery と turbolinks を共存させるための jquery-turbolinks というものがあるので取り敢えずそれを追加する。Gemfile に以下を追加。

gem 'jquery-turbolinks'

app/assets/javascripts/application.js に以下を追加。なお jquery の直後、turbolinks の手前に入れる必要がある。

//= require jquery
//= require jquery.turbolinks
...
//= require turbolinks
...

Google Site Search などはこれで直ったのだが、FB Comment Plugin ないし FB SDK の場合は明にイベントを読んであげないといけないらしい。 Turbolinks Compatibility with FacebookRails / Turbolinks を使いつつもフェイスブックの Page Plugin を設置する | Workabroad.jp を参考に、app/assets/javascripts/social.js.coffee を追加。当然 application.js には対応する //= require social.js を加えておく。

$ ->
  loadFacebookSDK()
  bindFacebookEvents() unless window.fbEventsBound
        console.log 'everytime'

bindFacebookEvents = ->
  $(document)
    .on('page:fetch', saveFacebookRoot)
    .on('page:change', restoreFacebookRoot)
    .on('page:load', ->
      FB?.XFBML.parse()
    )
  @fbEventsBound = true

saveFacebookRoot = ->
  if $('#fb-root').length
    @fbRoot = $('#fb-root').detach()

restoreFacebookRoot = ->
  if @fbRoot?
    if $('#fb-root').length
    @fbRoot = $('#fb-root').detach()

restoreFacebookRoot = ->
  if @fbRoot?
    if $('#fb-root').length
      $('#fb-root').replaceWith @fbRoot
    else
      $('body').append @fbRoot

loadFacebookSDK = ->
  window.fbAsyncInit = initializeFacebookSDK
  $.getScript("//connect.facebook.net/ja_JP/sdk.js#xfbml=1")

initializeFacebookSDK = ->
  FB.init
    version : 'v2.7'
    appId  : '1721451128113160'
    status : true
    cookie : true
    xfbml  : true

FB Comment Plugin で記載するように言われる下記は script 部分を全て消去。当該処理は上記にあるので。

<div id="fb-root"></div>
<script>
...
</script>

なお Facebook SDK and rails 4 Turbolinks - Stack Overflow の方法だとうまくいかなかった。document.ready や page:change, page:load 時に FB.init を呼ぶという動作は実質同じなはずなんだけど…。