nDiki : Google

今日のさえずり: Google フォトのアルバムって共有リンクを知っていれば誰でも写真を表示できるの

2018年12月29日

• 06:30 ガラス天井。 DSC-RX0 #RX0 https://t.co/JinRYplCIf
• 06:45 RT @Naney: 銀座は華やかですね。 #SEL50F18 https://t.co/guDNJ7zoBy
• 07:00 RT @p122sho: #shophoto https://t.co/uUBVLquEsB
• 12:15 Google フォトのアルバムの共有って、共有リンクを知っていれば誰でも写真を表示できるタイプのしか無いのね。指定した Google アカウントとだけの共有がしたいのだけれど。
• 21:15 RT @Naney: レイトレーシングのような。 #SEL50F18 https://t.co/EaQ3BiduH6
• 22:00 HITACHI GIZMON #Utulens https://t.co/2IdlX9dWh9
• 23:00 モノづくりの魂を感じた。 / “閉館を惜しむ人たちが集っていたソニー歴史資料館” http://bit.ly/2Q94YIR

Web 日誌 / Web 日記を書き始めてから20年

途中ブランクがあったりするけど、書き始めてからついに20年だ。

いつ始めたか?

個人 Web サイトを作り始めたのが1995年か1996年ぐらい。それから数年経った1999年1月19日にコンピュータ日誌として日付ベースの記事を書き始めた。

当時既に Web 日記を書いている人はいたが、まだ HTML ファイルとして直接書いている人も多かったんじゃないかな。自分は当時マクロプロセッサ m4 を通して静的 Web ページを生成していたので、当初 Web 日誌も m4 マクロで生成していた。

ハイパー日記システムが公開されたのが前年の9月、 tDiary が SourceForge.net に公開されたのは3年後の2002年2月20日であった。その翌年の1月16日にはてなダイアリーベータ版がリリース、さらにその翌年日記機能をもつ mixi がオープンとなる。

そこそこ早い時期から Web 日記 (Web 日誌)を書いていたんじゃないかな。

20年続けて得られたものは?

20年続けて得られたものは以下だな。

• 自分の20年の情報が蓄積されたパーソナルナレッジベースとなった。自分の過去の何かについてはサイト内を Google 検索すればたいがい探せてしまう。
• パーソナルナレッジベースについての知見を得た。
  • 特に個人の情報は「いつ」のことかが重要。
  • 「システムの寿命よりもデータの寿命を特に重視して設計されていなければならない」「ノート・日記はテキストファイルに」「ファイル名中の日付を先頭にする」
• ちょっぴり人の役にたった。
• ちょっぴり収入になった。

20年続けて失ったものは?

一方失ったものは時間。公開している以上、下調べしたり文章を整えたりするのにある程度時間がかかり1週間に数時間は費やしている(1日分で数時間の場合もザラ)。Web 日記を書いていなければ数千時間、他のことができていたであろう。

あ、もちろん無駄な時間だったとは思ってはいない。調べたり考えたり内省したり、日記を書き続けたから今の自分がいるんだよね。

続ける?

Web 日記は趣味だからね。

[ コンピュータ日誌 ]

Deckset カスタマイズ(しようとするけど結局デフォルトで)

スライド作りに久しぶりに Deckset を。普段 Google スライドで使っているデザインに多少合わせようとテーマカスタマイズをしようとしたけれど敗北。

Focus on your ideas, not on designing slides -- https://www.deckset.com/

iA Writer と Ulysses のライブラリ機能の違いで使い分け

最近 Ulysses for Macばかり使っていて出番が減っているライティングアプリ iA Writer for Mac だけれど、ライブラリ機能が Ulysses と違うので使い分けでまた使ってもいいかなって。

Ulysses はテキストファイルしかシートリスト(ファイルリスト)に表示されないのに対して、 iA Writer ではその他のファイルもファイルリストに表示されるのでその存在を意識できる。

画像ファイルやスプレッドシートなどその他のファイルが混在している

• Google スプレッドシートなども一緒に置いてある Google ドライブ上のフォルダ
• Deckset スライドのための画像ファイルがあるフォルダ

のようなフォルダ上の Markdown ファイルの編集には iA Writer の方が便利そう。またちょこちょこ使ってみることにする。

[ Mac アプリケーション ]

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

Developers Summit 2019 2日目 #devsumi

昨日に続き本日も Developers Summit 2019 参加。今日は寒い一日だったのか、途中窓の外に雪が舞う時間もあった。

昨日参加証の読み取り率が低かったので受付で再発行していただいた。

今日はコーヒー確保できず。今度来る時はやはり何か買ってこよう。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【15-D-1】 プロダクトマネージャーという生き方

楽天株式会社 熊谷亘太郎氏

プロダクトマネージャー・カンファレンス 2018 1日目でもトークをお伺いした熊谷氏。今回も発表の骨子は同じだったので、今回は復習となった。

メモ

• 楽天トラベルでのプロダクトマネージャーと開発マネージャーの担当領域
  • 技術仕様やリスクマネジメント、組織関連はなどは開発マネージャー側。
• Positive (問題は解決できるという態度)

Enjoy your work!

11:05～11:50 【15-B-2】 メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと

ヤフー株式会社 山本学(@yamamoto_manabu)氏

Developers Summit 2016 1日目 で myThings の話をされていた山本氏。今回はマネージャーについて知ってもらいたいという内容で、マネージャー予備軍が響く層であろうという感じのセッション。

12:10～12:40 【15-E-3】 Entertainment x Tech～多くのアーティストとファンを繋ぐ技術と組織～

エイベックス株式会社 山田真一氏

• 年約250の新規アーティストサイト、現時点で約500を運営。クラウドシフトはステークホルダーが多く順番に。
• 予期しないバーストトラフィック
• アーキテクチャは社内アーキテクトで、開発は外部パートナーがエイベックスとしての理想の姿。

アウトソーシング中心での体制構築についての取り組みのセッション。「研修に行かせる」「身に付けさせる」のような表現をみると、トップダウンが強めの雰囲気なのかな?

13:05～13:50 【15-A-4】 3周年に突入するAbemaTVの挑戦と苦悩

株式会社サイバーエージェント 山中勇成(@toriimiyukki)氏

GCP 含めバックエンドで使っているものを順番に紹介していくセッション。浅く全部紹介する感じなので全体的に知りたかった人向けのセッションだ。

14:10～14:55 【15-B-5】 Site Reliability Engineering at Google

グーグル・クラウド・ジャパン合同会社 中井悦司(@enakai00)氏

流れるようなトークに酔いしれてしまうセッション。

• 50% ルール
  • 50% 以下で運用業務、50%以上をシステム安定化に関わるプロジェクト活動にあてる。
  • SRE(優秀なソフトウェアエンジニア)が Burnout して退職することを避ける。
• Toil の削減
• 生涯対応では問題解決を最優先。「他人を頼ること」をスキル不足と認識しない文化。
• Postmortem (障害ふりかえり)は Google ドキュメントを使っている。全エンジニアに共有されている。

(Google の) SRE についてちょっとではあるが理解が進んだ。目的がすべて明確で、それに対して合理的に取り組んでいるかのようで改めてすごいなと。

15:15～16:00 【15-A-6】 プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～

合同会社DMM.com 石垣雅人(@i35_267)氏

データ駆動戦略で成長させていくという話。今回はユーザーレビュー機能に関して。

既にあるものを少しずつ伸ばしていくことにフォーカスしている状況なら、施策に対する予測がしやすいので良いよねというところ。

16:20～17:05 【15-E-7】 セキュアな環境でDevOpsを実現する厳選ツール

マクニカネットワークス株式会社 根本竜也氏 株式会社セガゲームス 上田展生氏

前半は厳選ツール = GitHub Enterprise (GHE) (上田氏)。3年前はまだ Subversion を使っていた。そこから GHE と CircleCI Enterprise を導入していったという話。ゲーム会社だけれど Web 企業とは距離感のある企業風土を感じた。

根本氏は商材紹介。営業っぽい感じになってきたので退室。

17:25～18:10 【15-A-8】 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

東京大学大学院 よしおかひろたか(@hyoshiok)氏

よしおか氏視点を交えつつ IT 史と概論を語る前半。途中退室。

Google ドライブ ファイル ストリーム駄目だった

MacBook Pro のリプレースにあたり Google ドライブのローカルへの同期を「ドライブ ファイル ストリーム」にしてみたんだけれど、自分の使い方ではデメリットが多いので即日「バックアップと同期」に戻した。

ドライブ ファイル ストリームにしようと思った理由

• 共有ファイルを気軽にマイドライブに追加してたらどんどんファイルが増えた。
• ファイルのオーナー引き継ぎを何度も受けてどんどんファイルが増えた。
• シンボリックリンクがないので「追加」多用しているのだけれど、これバックアップと同期ではローカルにそれぞれ実体ができて無駄な感じになる。

ドライブ ファイル ストリームなら実体はクラウドストレージ側にあるのでファイル数が多くてもへっちゃらではないか。そう思ったわけです。

ドライブ ファイル ストリームにしたら困ったことに

機能比較で「Microsoft Office や Photoshop などのネイティブ アプリを使用する」とあったので、 Google Chrome 拡張機能の Application Launcher for Drive (by Google) が使えると思ったら使えなかった。ファイルシステム上で開けるという意味だったようだ。この拡張機能がないと「Chrome 上で Google ドライブ検索してからの、ネイティブアプリで閲覧編集」という使い方ができないので劇的に不便になる。

それから Finder (Path Finder でも)ブラウズできないフォルダがあってこちらは致命的な問題。ターミナルで cd していけるのだけれど Finder では駄目。これは駄目。

バックアップと同期に戻す

結局ドライブ ファイル ストリームはやめてバックアップと同期に戻すことにした。 archive フォルダをマイドライブ直下に作ってここは同期しないことにし、いったん全部そこに移動した。

選択同期は面倒なので今まで避けてきたけれどしかたあるまい。今後は作業中のフォルダだけ同期することにする。

今日のさえずり: ドライブ ファイル ストリームだと Application Launcher for Drive が使えないのか……

2019年02月21日

• 06:45 人造のカーブと自然のカーブ。 PowerShot G9 Mark II https://t.co/33oPvVW8Bv
• 07:00 RT @Naney: 鉄橋。 #SEL1670Z https://t.co/kUHU0CnxnM
• 09:42 2019年2月21日 #朝の渋谷 北風チョットサムイ。 DSC-RX0 #RX0 https://t.co/5ljKywcScJ
• 09:44 渋谷クロスタワー。
• 12:32 @tomo_bs18 はい。命日にはたくさんファンが集まる場所ですね。
• 12:45 RT @AtelieSuh: 今日は卒業式だそうです。 そんな時期ですか。 今日も元気に工房 絲(su-)OPENです。 http://atelie-suh.com https://t.co/RcZNizqrCt
• 13:42 Google ドライブ ファイル ストリームだと Google Chrome 拡張機能の Application Launcher for Drive (by Google) が使えないのか……。
• 13:50 「バックアップと同期」を使っている場合と同様に、 Google ドライブでの検索結果からファイルを直接ローカルのアプリケーションで開きたい……。
• 14:45 RT @lenfant_: All To be filled, pure white. #filmphotography #lomography https://t.co/scdUU3HPzH
• 21:19 Google ドライブ ファイル ストリームだと Finder で深い階層のフォルダまで辿り着けない(子フォルダが出てこない)。ターミナルだと cd で辿り着ける。
• 22:44 結局「ドライブ ファイル ストリーム」から「バックアップと同期」に戻した。
• 23:15 RT @Naney: 神社へと続く道。 DSC-RX0 #RX0 https://t.co/boIKzICbwH

今日のさえずり: Google スプレッドシートの「テキストの回転」て任意の角度に回転できるのね

2019年03月19日

• 00:25 RICOH GR III をネックストラップ対角線吊りで使ってみたけど、右手に巻いて使う時に画像モニターに斜めにかかってしまって良くなかった。縦吊りにしてみる。 #GR #GRIII #GR3
• 06:45 ハナ RICOH GR III #GR #GRIII #GR3 https://t.co/UdQEH9bKq0
• 06:48 RT @Naney: TRACK No 2 PowerShot G9 X Mark II https://t.co/bHz6sa0XXO
• 09:51 2019年3月19日 #朝の渋谷 渋谷駅東口歩道橋のあのスロープがいよいよ明日開通。 DSC-RX0 #RX0 https://t.co/Gg4jko8hDQ
• 10:52 @kodamaphoto 渋谷警察署前のエレベーターいつも並んでますよねー。いつも避けて遠回りをしていたので開通嬉しいです。
• 12:45 一番目立っているのはどれ? RICOH GR III #GR #GRIII #GR3 https://t.co/nJiA3nIlHL
• 12:48 RT @ryuuyrryu1: 皆さんお疲れさまです🏢🏠🏠🏢 https://t.co/AgT7JCuHog
• 14:48 RT @Naney: 渋谷ストリームオープンからの初の春が来た。 PowerShot G9 X Mark II https://t.co/BXKiAi3qbf
• 15:50 健歩大会の当選のお知らせメールきたコレ。
• 19:53 Google スプレッドシートの「テキストの回転」て使ったことないなと見てみたら、これ任意の角度に回転できるのね。ちょっと傾けるとちょっと楽しげになるよ。
• 21:45 影 RICOH GR III #GR #GRIII #GR3 https://t.co/mBXRgIkdsv
• 22:29 やはり RICOH GR III のネックストラップは対角線吊りよりも縦吊りの方が自分には合ってた。右手に巻いて使う時に画像モニターにかからなくて良い。 #GR #GRIII #GR3

PC でのワンタイムパスワードのシークレットキー管理に KeePassXC を使う

TOTP アルゴリズムを使っている2段階認証/2要素認証のシークレットキーの管理・ワンタイムパスワード生成はスマートフォンアプリの Google Authenticator とIIJ SmartKey を両用している。メインのスマートフォンが使えなくなった時のために、使っていない古いスマートフォン残しておいてそこにもシークレットキーを登録しているのだけれどこれ面倒。バックアップは PC (Mac)で管理したい。

そう思って調べたところ、普段パスワード管理に使っている KeePassX のフォーク版 KeePassXC が TOTP 生成機能をもっているということを知った。

KeePassX の開発保守が停滞していることもあり KeePassXC にこのタイミングで乗り換えつつ KeePassXC で 2段階認証/2要素認証のシークレットキーの管理をしてみることにした。

• https://keepassxc.org/

クロスプラットフォームで公式サイトでは Linux 用・macOS 用・Windows 用のパッケージが配布されている。

シークレットキーの登録

IIJ SmartKey に登録しているキーについてそれぞれ QRコード生成をし別のカメラで読み取り、その中の secret の値を KeePassXC のエントリに登録していく。エントリを作成し(あるいは既存のエントリを選択し) TOTP の設定をキーを入力し保存すれば OK。

ワンタイムパスワードの生成

もちろんワンタイムパスワードの生成にも対応している。これがあればスマートフォンが手元に無くても要 TOTP 認証のネットサービスにログインできる。便利。

パスワードデータベースファイルの管理

KeePass パスワードデータベースファイル (kdbx) に保存されるので、あとは好きな方法でバックアップ。

[ Mac アプリケーション ]

撮り直したい写真を Google フォトにアップロードしておく試み

撮った写真を整理していると、(その瞬間しか撮れなかった写真はさておき)「ああ、撮り直したいな」という写真が出てくる。その時はまた撮りに行こうと思うのだけれど、別の日に「さて今日は写真をどこに撮りに行こうかと」考えた時にはなぜか思い出せない。

「撮り直し」アルバムとスポットリストを作っていつでも見られるようにしたらどうかと以前から思っていたので、そういう写真をひとまず Google フォトにアップロードしてアルバムに入れておいてみることにした。

Google フォトに入れておくと便利な点

いい精度で撮影場所を推定してくれるのであとでどこで撮ったか思い出しやすい。検索で特定の場所の近くで撮影した写真を探すこともできるので、撮りに出掛ける場所を考える時のも便利。

どこでも閲覧できるというのも Google フォトを使うメリットだ。

Google フォトに入れておくと不便な点

「撮り直したい写真」を入れておくということは Google フォトがちょっと残念な写真だらけになってしまうということ。

スマートフォンでたまに撮った写真のバックアップとして自動的にアップロードする設定にしている以外は今はほとんど使っていないので、とりあえず問題ないのだけれど本格的に Google フォトを使う気になった時にちょっともやもやした気分になりそう。