nDiki : Google Chrome

2015年12月9日 (水)

今日のさえずり: 宇宙パワーシール届きました!

2015年12月09日

  • 09:57 隕石パワーシール届きました!
  • 10:01 宇宙パワーシールでした!
  • 13:29 Slack 分報、ぼっちる可能性があるのですね。
  • 13:56 真似して Slack に分報チャネル作ってみました。
  • 13:56 Twitter 世代ですから。
  • 13:59 Google Chrome のホームボタンの URL を分報チャネルに設定。
  • 20:54 お腹が空いているせいか家路が寒いです。
  • 21:02 “スマホゲーに「レア」がでてくる理由と、人間が「課金したゲーム」を消せない心理。海外コンサルが教える、ゲームに使われている7つの心理テクニック。 | アプリマーケティング研究所” http://bit.ly/1M2Gmb0
  • 24:25 紀伊國屋書店男前! / “勝手に作った巨大ブックカバーを紀伊國屋書店に引き取ってもらう - デイリーポータルZ:nifty” http://bit.ly/1Y28S3b
  • 24:55 もちだっつを食べている我が本部のみなさま、しろくまはどうなりましたか。
[ 12月9日全て ]

2016年4月17日 (日)

Toggl でタイムトラッキングするだけで時間の使い方が良くなる

image:https://www.naney.org/nDiki/2016/04/17/Toggl-Web.png

GTD では使える時間を基準に行動を選ぶ

GTD では次の行動を「状況」「時間」「エネルギー」「優先度」の順の基準で選びます。

今使っているタスク管理ツール Remember The Milk はタスクに予測時間を設定しておくことができます。そして検索やスマートリストで使える時間に応じたタスクをリストアップすることができます。

タイムトラッキングしてタスクの時間見積もり精度を上げる

ただこの予測時間の見積もりはだいたいこれぐらいかなと思って入力することがほとんどだったりします。もう少しきちんと入力できるようにタイムトラッキングしてどれぐらい時間がかかっているか実測してみることにしました。Remember The Milk にはタイムトラッキング機能が無いので、今回はタイムトラッキングサービスでは有名な Toggl 試してみます。

Toggl

サインアップすると Toggl サイト上でタイムトラッキングできます。Google Chrome 拡張を入れると Remember The Milk のタスクの横にも Toggl のボタンがついて1クリックでトラッキングの開始・終了ができるようになります。Remember The Milk のタスク名がきちんと Toggl のエントリの description に設定されるなど良くできています。これは便利。

スマートフォン向けアプリもあってそちらでもトラッキングの開始・終了ができます。以前ちょっとタイムトラッキングをしてみていた時(2007年前後)は Task Coach を使っていましたが、この頃は特定の PC でしかトラッキングできませんでした。スマートフォンの登場でかなり便利になりましたね。

タイムトラッキングすると時間の使い方が上手になる?

費やした時間を記録してあとで精査することで所要時間の見積もり精度を上げたり無駄な時間を見つけたりすることがタイムトラッキングの大きな目的だと思っていました。

しかし実際にやってみると

  • 「トラッキング中はネットサーフィンなどのような計測している実際のタスクとは違うことはしたくない」という気持ちになって集中してやるようになる。マルチタスキングもしなくなるのでコンテキストスイッチのコストが無くなる。
  • タイマーを設定することをイメージして「そもそもこんなことに時間を使わない方がいいな」と考えるようになり、無駄に思われる行動をやめるようになる。

など、ふりかえりをせずとも即行動に影響が現れたので驚きでした。家計簿をつけたり食べた物を書き留めるのと同じで、無駄に対する意識が高まるようです。

これは楽しいですね。しばらく続けてみることにします。

(画像https://blog.toggl.com/media-kit/ より)

[ 4月17日全て ]

2016年4月18日 (月)

Google KeepGoogle Chrome のホーム ボタンに設定とか【日記】

Toggl でタイムトラッキングしていると別のことをしたくなくなるので、思い浮かんだことを途中で Tweet しておくなども激減してしまいました。良いといえば良いですし、まあでもバランスかなと思います。

それと最近 Google Keep を良く使っているので Google Chrome のホーム ボタンに https://keep.google.com/ をお試しで設定してみました。Google Keep はぱっと見やすいぶん周囲に人がいる時には開きにくかったりするので、そのあたり気になるようならやっぱりやめます。

[ 4月18日全て ]

2016年5月18日 (水)

Evernote Web は今も使いにくかった

Evernote の「展開したカードビュー」を Mac 版で使ってみたらちょっといい感じがしてきました。特にある程度画面が広い場合だと Google Keep 的な使い方ができるかなと。

Evernote Web だとどうかなと思って Web ブラウザでログインしてみましたが、そういえば Web 版にはカードビューは無いのでした。そしてカードビューが無い以前にやはりどうも使いにくいです。いろいろスカスカですし。

最近リリースされた Google ドライブ連携もまだ Evernote for Android および Evernote Web (Google Chrome のみ) だけでしか使えないのですが、Evernote Web だと不便なのでちょっと試しただけでしばらく様子見にしました。Evernote for Mac で使えるようになると良いなと。

[ 5月18日全て ]

2016年6月16日 (木)

タイトルと短縮 URL を好きな形式でコピーできる Google Chrome 拡張機能 Template

URL をシェアする時ははてなブックマークの形式に似せて

 コメント / “{title}” URL

のようにしているのですが、手でこの形式にするのはちょっと面倒です。Google Chrome 拡張機能で良いものが無いかと探したら Template というのがありました。

短縮 URL は Bitly と Google URL shortener に対応しています。私は普段使っている Bitly を選びました。

テンプレートに新しいテンプレートを追加し Content に以下を指定することで希望の形式の文字列でコピーすることができます。

 “{title}” {#shorten}{url}{/shorten}

Toolbar Behavior 設定で Action を Template にしておくと、Toolbar 上のボタン1クリックでコピーできて便利。

[ 6月16日全て ]

2016年10月9日 (日)

家族共用端末としての9.7インチiPad Pro Wi-Fi 32GB

naney:29580391013

昨日の夜に注文した「9.7インチiPad Pro Wi-Fi 32GB スペースグレイ MLMN2J/A」が早速届いたので、家族共用端末として設定しました。iOS 9.3.1 で届いたので iOS 10.0.2 にアップデートしています。

iPad Pro か Air か mini か

予算的には iPad mini 4 か iPad Air 2 ぐらいが良かったのですが、 iPad 2 に慣れているので前者は小さすぎ、後者は発売から年月が経っていてちょっとなという感じで、結局 iPad Pro にしました。カメラの出っ張りが気になっているところですが、しばらくは机に直置きしないでうまく使ってみるつもりです。色は飽きのこないスペースグレイにしました。

ファミリー共有設定

2011年に買っiPad 2 は個人のメインの Apple ID を設定していましたが、今回は新しく Apple ID を作成してファミリー共有することにしました。ちょっぴりアプリ内購入したデジタルコンテンツが移行できないものがあるけれど、それはままいいかっと。

iPad 2 からの移行

アプリの移行については「ゲストプレイのツムツムのデータが移行できない(承知の上)」以外は、困るものは無しです。iPad 2 → iPod touch 5th → Xperia Z5 (の裏アカウント)と流浪してきたチェインクロニクルも、晴れて iPad に戻ってきました。

iPad 2 は「Google ChromeWeb ページを見るだけでもたまに落ちる」「ゲームが途中で落ちる」など力不足で残念な感じになってきていたのですが、使用頻度はここ最近高くなってきていました。 iPad Pro を買ったことでこれでまたリビングライフが快適になりそうです。

薄く軽く綺麗になったけれど新鮮さや興奮をあまり感じなかったのは、もう生活で当たり前のものになっているからなのかもしれません。

[ 10月9日全て ]

2016年10月14日 (金)

Markdown拡張子を md にすると Google ドライブで不便

プライベートな日記プレーンテキストファイルベースに移行した際、いったんファイルの拡張子を txt にしたのですが、 Markdown 形式で書いているのでテキストエディタのファイル形式判別的にも良いかなと思い md への変更を考えました。

試してみたところテキストエディタは OK (EmacsiA WriterJotterPad・Jota+) だったんですが、拡張子が md だと Google ドライブ上に検索用に同期して置いて検索されないし、Google ChromeGoogle ドライブを使っている時にプレビューもできないし不便でした。

やはり txt でいくことにします。

[ 10月14日全て ]

2016年11月6日 (日)

用の MacBook Pro が届いた

10月31日に注文した用の MacBook Pro が午前中に届きました。開梱を見届けつつ一緒に最初の設定を済ませました。

全部で2時間半弱ぐらい。

これでまたそれぞれノート PC がある状態になったので、気にせず使えるようになりました。めでたしめでたし。

[ 11月6日全て ]

2016年12月8日 (木)

LINE の代わりに Google ハングアウト

電話番号の無い iPad Pro でメッセージのやり取りをするのに LINE の代わりとして使えるかなと Google ハングアウトを先日入れて試してみました。

メッセージングの UI は馴染みのある形で違和感なく、絵文字以外にステッカー(LINE でいうスタンプ)もある程度揃っているのでまずまず楽しめます。

PC の Google Chrome からも使えますし「Google ハングアウトでいいんじゃない?」という感触を得ました。

[ 12月8日全て ]

2016年12月9日 (金)

nDiki に貼る写真Flickr ではなく同じサーバに置く

この nDiki写真を載せる際は2005年から Flickr にアップロードしてそれを貼りつけるようにしています。これを今後は普通に画像ファイルを Web サーバ側に置くことにしました。

Flickr写真を置いておくメリットは以下があります。

一方デメリットとしては

  • Flickr にベンダーロックインされている。長期的には一抹の不安。
  • 一度画像URL が変わったタイミングで過去の写真が一部表示できなくなっている(記事側の URL を変更していく必要がある)。今後も同様の自体があり得る。

があります。

Flickr 利用で使い勝手的には問題が無いのですが、長期的に継続する Web 日記のコンテンツとしては他のサービスに依存しすぎないようにした方が良いということで、今後は普通に Web サーバに置くことにしました。

そうするとどのサイズの画像ファイルを用意するかを改めて考える必要が出てきました。

画像サイズ

今までは Flickr で生成されるから適当そうなもの(たいがい長辺 500px のもの)を選んで貼っていました。今後は自分で適切なファイルを作ってアップロードすることになるので画像サイズについてちょっと見直してみました。

Bootstrap 3 でのサイトの幅の見直してコンテナを 970px までに

Bootstrap 3 だと広くても幅 1140px (1170px - 30px) なので画像幅もこれだけあれば十分です。しかし考えてみると nDiki は1カラムなのでラージデバイス(≥1200px)向けのコンテナ 1170px はいささか広すぎます。ということでいったんミディアムデバイス向けのコンテナ 970px までしか広げないようにしました。

 @media (min-width: 1200px) {
     .container {
         width: 970px;
     }
 }

写真は基本 max-width: 100% の .img-responsive で表示しているので、これで最大 940px 幅で表示されることになります。

表示される写真の高さは最大 480px に

幅 940px だと 4:3 なら高さは 705px、3:2 なら高さは約 627px になります。13インチMacBook Pro 上の Google Chrome でこのサイズの写真を貼るとほぼ縦いっぱいになってしまいます。記事中の写真では 480px ぐらいまでかなという印象でした。ということで

 max-height: 480px;

としました。

これだと 4:3 なら 640x480px、3:2 だと 720x480px の画像サイズがあれば十分なことになります。縦位置だと 3:4 で 360x480px、 2:3 だと 320x480px です。

画像ファイルの画像サイズは長辺 1200px に

これで 640x480px (4:3) や 720x480px (3:2) にリサイズして Web サーバに置けば現時点では過不足ないということがわかりました。

ただこれだとデバイスの変化でサイトデザインを見直す時がきた時に解像度不足になってしまいます。Bootstrap のラージデバイス向けのコンテナサイズを考えていったん長辺 1200px で画像ファイルを用意することに決めました。

ついでに .pull-left と .pull-right の画像幅も調整

写真を左右に寄せた際に現状テキスト部分が狭くなりすぎることがあるのでこのあたりも合わせて今回調整しました。

 .img-responsive {
     display: inline-block !important;
     max-height: 480px;
 }

 @media (min-width: 768px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 992px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }

 @media (min-width: 1200px) {
     .pull-left.img-responsive {
         max-width: 50%;
     }

     .pull-right.img-responsive {
         max-width: 50%;
     }
 }
[ 12月9日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィの SNS の企画開発を行うグループでマネージャー・プロダクトオーナーをしています。CS 向上・ユーザーサポート・健全化などにも取り組んでいます。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.055069s / load averages: 0.36, 0.46, 0.44
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker