basyura's blog

あしたになったらほんきだす。

Vivaldi + リーダービュー

本を読むのは kindle のみになっているので決まったフォーマットで読むことになる。個性がなくなるとかあるのかもしれないのだけど僕としては読みやすくて良い。特に行間を大きめにして読みたい。

Web 上はいろいろなサイトがあってフォントも違えばフォントサイズも違うし色や配置もかなり違う。たまに読みたいのだけど文字が小さいとか文字色と背景色が微妙で見づらいサイトにぶつかる。よく見るサイトに関しては Stylus でスタイルを書くのだけど、たまに見るサイトはめんどう。そこでリーダービューにすると統一されたビューで表示される。読みやすくなって大変良い。行間も指定できる。Vivaldi を常用していて Ctrl+1 でリーダービューに切り替えられるようにしている。

会社で資料を作る際などには行間をかなり意識するのだけど、周りを見ると僕だけっぽい。詰め詰めで書かれていて辛いことがよくあるのだが気にしすぎに思うので自分が関わる範囲で可能な場合はこそっと直すようにしている。それはそれで面倒で辛いのだけどやってしまう。

YAPC::Tokyo 2019 に行ってみた

Perl は書けないんだけど。学生の頃に楽天のスペースでとほほをみながら cgi で動くしょぼい掲示板を作ったぐらいな記憶。仕事でプログラムを書くようになってからも Perl は読み書きがほぼできず Ruby に流れた。

一番面白かった。「選択肢を持つ側から権力が働く」が刺さりまくり、最近感じる理不尽感はこれなんだよなぁと納得。

既に買って読んでた。もう一度読み直してみる。

Perl の事は全然頭に入らなかったけど・・・ Go もいいけど、Ruby がやっぱしっくりくるというか書きやすいよなぁとか考えながら家に帰ったらずっと保留にしてた仕事用の Go 製ユーティリティを形にできた。スピーカーも参加者も初めて見る感じではあったけど刺激をもらえたようだ。

3 周ぐらいして markdown を Vim で書くに落ち着いてからの OneNote

いまだに仕事のメモ管理がしっくりこず、vim、onenote、evernote、wiki を行き来しまくっている。ちょっと前までは evernote のローカルブックに書いて inbox 形式で管理する方法にしていた。検索も evernote クライアントで検索していたのでそれほど困ることも無かった。ただ、肝心のエディタ部分が微妙で特に行間を設定できないのが不満。Mac アプリではそれほど気にならないのだけど windows アプリは狭く感じる。フォントサイズも 10.5 とか指定したい。関連プロセスがいくつも立ち上がってるのも不満。画像が貼れるし、テーブル形式も使えるのはいいのだけど。最近はテンプレート押しっぽいけど使わないし (それじゃない感) これ以上は良くならないんだろうなという不満の方が急激に高まってきた (今までは諦めで使ってた)。

typora がいいぞ、というエントリを見かけたので久々に触ってみたのだけど動作が非常に怪しい。カーソルが動かなくなったり、改行できなくなったり、テキストで見た場合におかしな改行ができてたり。おすすめできるほど使ってるのかは疑問。

ただ、これを気に markdown で管理するのもいいなと現実逃避気味に要件を改めて考えてみた。

  • ファイル名で検索できる
  • テキストを検索できる
  • 見出しが出せる
  • 複数のクライアントから見れる
  • エディタが強力であってほしい

エディタに関しては、仕事で画像を貼り付けるケースはほぼない。テーブル形式もほぼ使わない。なると、セクションとリストが書ければ困ることはほぼない。markdown 形式のテキストで管理すれば幅が広がるのだけど、エディタが強力かどうかとなると結局 vim に落ち着いてしまった 。vs code や atom や他の markdown エディタを使ってみる手もあるのだけど、試す元気がなかったとも言う。

いまだにちょっと古い unite.vim を使っているので、ファイルを探したいときは Unite fileUnite file_rec/async 、テキストを検索したい場合は :Unite grep 、見出しだけ表示したい場合は Unite outline を使えばいいし、ターミナルからも同様にファイル検索やテキスト検索もできて便利。

テキストは git で管理して、社内の gitlab にプライベートなリポジトリを作って push しておけばバックアップとしても機能するし、gitlab 上で markdown を html 形式で表示してくれる。テキスト検索もできるしファイル名検索もできて便利なことにも気がついた。gitlab 上で直接プレビュー見ながら編集して commit し、手元で pull すればいいのも楽。ローカルでコミットし忘れるケースがあるのでファイル単位にタイマーで commit & push してしまってもよいなと思っているところ。

いつものことながらファイルが少ないうちは便利に感じるので増えてきたときにどうなるか。最近は打ち合わせとレビュー、調整ばかりで PG する時間がほとんどないのもあって vim で書いてると楽しくなってきてよい。

からの・・・ OneNote にまた戻る。一番いいところはフォントサイズに 10.5 を使えるところだろうか。結局、添付やテーブル表示が欲しくなったりするところで vim だと・・・となってしまう。リンクの表示も書きやすいし (テキストにリンクが貼れる)。OneNote はタブやセクションを自分で整理しないと破綻するのが嫌だったのだけど、逆に整理することが強要される。結果、探し (分かり) やすくなるような気がする (思い込み)。これで vim キーバインドが使えたらいいんだけど。中途半端 emacs キーバインドを keyhac でやってる。Mac only な Bear が Windows でも使えて貼り付けた画像のサイズを変えられてテーブルがかけるようになると最強だと思うのだが。hash tag の階層もいい感じだし。

結局ぐるぐる。

Kindle 端末を全部買ってみた結果

全部は言いすぎだけど、いま持ってるもの。

Kindle Paperwhite (第7世代)

Kindle Paperwhite(第10世代)

Kindle Oasis (第8世代)

Kindle Oasis Wi-Fi バッテリー内蔵レザーカバー付属 ブラック

Kindle Oasis Wi-Fi バッテリー内蔵レザーカバー付属 ブラック

Kindle Oasis (第9世代)

Kindle Oasis、電子書籍リーダー、防水機能搭載、Wi-Fi、32GB、広告つき

Kindle Oasis、電子書籍リーダー、防水機能搭載、Wi-Fi、32GB、広告つき

voyage と Kindle Paperwhite (第6世代) は後輩にあげた。Kindle Touch は眠ってる。

Paperwhite が一番気に入っていて、ディスプレイの感じとザラザラした感じが良い。重さ以外は。 Paperwhite が気に入り過ぎてしまったので、次に出てきた Voyage はディスプレイのテカテカ感がダメですぐに使わなくなった。Oasis 第 8 世代は期待していたのだけど高すぎて踏み切れずスルー。Oasis 第 9 世代は購入した。画面サイズが大きくなったので技術書系には良い。小説系は上下の視線移動がちょっと辛くて表示範囲を狭めてしようしてみたりしたがしっくりこず。結局技術書系は Oasis 第 8 世代、小説系は Paperwhite 第 7 世代で落ち着く。

待ちに待った Kindle の新型である第 10 世代が登場したのだけど・・・ダメダメ過ぎる。ディスプレイが今までの Paperwhite と違うのは我慢するとして、重心がおかしいのか片手で持ってると激しく疲れるのが致命的。

f:id:basyura:20190114153401p:plain

こんな持ち方でいられるの数分だから。

慣れるかと思って一ヶ月ぐらい我慢してみたけどやっぱりだめだった。防水のためのアレコレが入ったせいなのか。端末を持ってて水没の危険にあうことは年に一回もあるのか?だから優先順位違うし、風呂に入って使ってる身としては壊れたこともないので余計なお世話に近い。防水入って喜んでる人たちは何を気にしててどういう使い方をしたいのかが気になる。Paperwhite 第 7 世代相当でそのまま薄くなって軽くなるのをずっと期待していたのだけど夢は絶たれたらしい。

結局、技術書系と小説系で使い分けるに落ち着いたのだけど、どうせ使い分けるならで Oasis 第 8 世代が気になりはじめる。既に Amazon では売っていないのだけど 初めてのメルカリで購入。だいたい半額だった。購入も楽だったし、ほぼ新品だったのでよかった。これがアタリで小説系は Oasis 第 8 世代、技術書系は Oasis 第 9 世代で使い分けることで落ち着いた。Oasis の使い分け。

Oasis 第 8 世代はカバーなしだとバッテリの持ちが激しく悪い。これに限ったものではないけど Wi-Fi をオンにしていると一日で切れる。Wi-Fi オフでも二日程度。読まない時はカバーにセットする運用で一週間持つかなという感じ。まさに運用でカバー。

Paperwhite を買ってから 5 年ちょい。あまり変わってない印象なのが残念。

新年

年末に 1 日だけ家で仕事をしたけど、年末年始の年休をゆっくり過ごしたのは何年ぶりだろうか。年末年始、盆、GW と稼働を入れるのはそろそろなんとかならんもんだろうか。

一昨年の忙しさが最悪で去年も忙しかった。去年は調整ごとがほとんどだったので働いてる割にアウトプットを出した実感がなかった。経営層から来る指示の行き当たりばったり感が更にやる気を削ぐ。戦略とは。

去年と同様、今年もゆっくりしたいという思いが強いのだけど年末年始とゆっくりしてる割にゆっくりしてるだけで何かをしたいとかという感情が弱すぎてやばい。ドラクエビルダーズ2が面白くてまったりやっているのだけどそれぐらい。何が食べたいというのも特にないし、どこに行きたいというのも特にないので単純な刺激が返ってくるゲームや YouTube で時間が過ぎていっている状態。非常に良くない。パソコンを開いて何か PG してみるかと思いたってちょっとやると直ぐに集中力が切れる。何かを勉強しようかと取り組み始めてみても直ぐに飽きる。

そもそも集中力を継続するだけの体力が無いのが一番の問題な気がするので何かしら運動するかな。

休み明けから仕事が忙しいのはもう分かっているのだけど、働けるんだろうか。そしてなんでいつもドタバタな指示が降りてくるんだろうか。戦略とは。

2018 年振り返り

諸事情による組織変更に伴って 4 月ごろからチームを横断して改善を進めるチームに参加することになった。現状を分析してボトルネックを見つけて改善案を提示し、担当を決め、担当とあーでもないこーでもないと進め、レビューを通してリリースする立場になった。

長年 PG 中心の活動をしていたのだけど、今年は例年に比べると実装量は 1 割以下だったように思う。コードレビューはするし、状況によってはデバッグもするし、良い案がないか試してみることはあるけれど “実装した” という手応えはなかった。今年は “特別な” 年なので割り切ってやっているけど、来年もやるのは勘弁してほしいと思っている。

複数案件が同時に動くし割り込みもあるし判断を求められるし上からはワーワー言われることもあるので忙しい上に精神的にもしんどかった。戦略とは、と何回思ったことか。打ち合わせが多すぎて1日中椅子に座ったままになっていることもザラだったので運動不足をあからさまに実感する。

気がつけば関わりたくないとずっと距離をとっていたオフショアにどっぷり。コミュニケーションに疲れる毎日。実際のところは知らないけど、基本的に良い人達なので真面目にやってくれる。それなりに信頼関係を築けたのはいいけど、メリットがあるのかというと正直よく分からなかった。「この人なら任せられる」というのがなかったのが大きいと思うが、今までの関わり方を知らないのでどっちもどっちなのかもしれない。「ここはどういうことなのだろうか?」という意図を聞くことがよくあるのだけど、こちらの質問を理解していないのかわざとなのかひたすら主張が続いて時間が過ぎることが多々あったのが一番辛かった。ある程度誘導しつつ簡潔に質問することを心がけた。できあがるコードがあまりにひどいのでレビューしまくった結果、意識を変えてくれたようなのは大きかった。「こういうときはこうした方がいい、こういう時はこう書いたほうがいい」といったことは一気に横展開していくので、パワーはすげーなと思った。来年はテックリード的なめだつ人が出てきたらいいのだけど。

国内の若者がよく活動してくれたのは良かった。最近の若者は自分が若者の頃よりできるやつばっかりだよなと改めて思う。経験値があるのでまだまだわかいもんにh(略

今年はプロジェクトのためと割り切って活動しているのもあってスキル向上が感じられないのが一番辛い。打ち合わせスキルが多少上がったぐらいか。とはいえ何もしないのも辛いので、ログを収集するツールを go で書いてみたり、解析するツールを C# で書いて kibana に突っ込んで可視化してみたりを現実逃避気味にやってプロジェクトに投入してみたりした。社内の GitLab を docker に移行してみたりとか。

去年の振り返りと、今年の抱負をみると「のんびりする」がキーワードだったのに、今年も疲れたなぁ。働き方改革とは何だったのか。

golang - elasticsearch

go で elasticsearch に接続。

package main

import (
    "context"
    "encoding/json"
    "fmt"

    "github.com/olivere/elastic"
)

func main() {
    client, err := elastic.NewClient(
        elastic.SetURL("http://127.0.0.1:9200"),
        elastic.SetSniff(false))

    if err != nil {
        panic(err)
    }
    defer client.Stop()

    ctx := context.Background()
    termQuery := elastic.NewMatchQuery("hoge", "fuga")
    searchResult, err := client.Search().
        Index("log-*").
        Query(termQuery).
        From(0).Size(10).
        Do(ctx)

    if err != nil {
        panic(err)
    }

    fmt.Println("total:", searchResult.Hits.TotalHits)

    for _, hit := range searchResult.Hits.Hits {
        var dict map[string]interface{}
        err = json.Unmarshal(*hit.Source, &dict)
        if err != nil {
            fmt.Println(err)
            continue
        }
        fmt.Println(dict)
    }
}

json.Unmarshalstruct を指定すれば map を使わなくていいんだけど @timestamp でフィールド名を定義してるので struct が定義できない難点。そもそも @timestamp でフィールドを定義するのが一般的なのかよく分かってない。

まだまだ ruby で書いてるほうが楽だけど、vim-go のサポートが嬉しい。