無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

個人的なドキュメント管理方法について書いてみる

普段考えていることのメモや、仕事で調べたことを管理しておく、より良い方法を考えたことがある人は多いと思います。
私個人としては、「いつでも」、「どのデバイスでも見れる」ことを関心事として、Webサービスを採用するようにしていました。

回線さえ確保できる環境限定ではありますが、ブラウザの用意さえあれば使えることがとても気軽。今どき回線がない環境にいることは稀なので、これで事足りているということでもあります。

昔は、wri.peを使っていたのですが、最低限の機能しかなかったり検索が辛かったりして、別のサービスに乗り換えるなりしていました。
DropboxGoogle Driveも試したんですが、あれはあくまでデータを管理するツールであって、ドキュメントを書くのに適していませんし。

色々試した結果、今はkibe.laを使っています。
基本的な機能はこんな感じ

  • Markdownで記述できる
  • タグが使え、階層の指定がシンプル
  • 文書検索が強い
  • 文書テンプレート使える
  • 更新履歴が追える
  • Webhookの設定ができる
    https://mottox2.com/posts/134/ のように、CMSとして使うことができたりする
  • 5人までのチームなら(制限付きだが)無料

同じようなツールにesaというものがあり、仕事ではそちらをメインに使ってました。
どちらもできることは同じですが、esaは無料プランがないため、個人使用だとkibe.laの方に軍配が上がりますね。
esaのほうが動作がサクっとした印象で、鳥がかわいい点が押しどころではあるのですが...

仕事で両方使ってみて感じた使い分けですが、

  • 各々が無秩序にメモを残していならesa
    記事の一括階層移動があるので、後から整理するのも多少しんどいくらいで済む
  • 予め秩序立って管理する前提であればkibe.la
    esaよりはコラボレーションに寄ってる感覚ある

なイメージです。なにかの参考になれば。

4年間勤めていたベンチャーを退職しました

今日今から無職です、こんばんは。
正確には有給消化期間中なので、まだ所属はしていますが、明日から出勤しなくなると考えれば、ほぼ無職同然ですね。
次の職場が決まるまではゆるりと生きていきたいと思います。


さて、ここからベンチャーに4年務めて感じたことを書きます。 今色々と動きあって社名を出すことはできないんですが、こんな会社です。

  • どこかに上場している従業員そこそこ多めの企業
  • いろんな事業している会社
  • 売上は最近芳しくなさげ

アバウト過ぎて、該当するのがたくさんありますね。よしよし。
この会社でソシャゲ作ってました。当時の新規タイトルで開発中にJoinして、そこから今まで同じプロダクトに張り付き。
ソシャゲの会社の割には、社内環境がよく、残業も少ない良い会社でした。毎日終電生活していたときより圧倒的にホワイト。

そこでサーバーエンジニアと、Unityエンジニアと、WEBエンジニアの3つの草鞋履いて、ひたすら運用・開発の回し車をカラカラ回してました。
ときにはサーバートラブルに悩まされ、専任がくるまでデータ周りのエンジニアとアナリストの代理やってたり、最後にはKPI改善を走らせるためにゲームプランナーになったりと、色々体験ありました。


さて、前置きが長くなりましたが、4年働いた感想です。

良かったこと

  • エンジニアのレベルは高い。インフラとサーバー両方見れるレジェンドエンジニアが複数いた。
  • 社長がエンジニアで、リリース前後は一緒に開発してました。障害対応の調査など自分が手を出しきれない領域で手伝ってもらい心強い。
  • チームの人数が少なかったので、みな同じ方向を向いて走っていくことができていた。
  • かなりホワイト。深夜まで残ったり徹夜したのリリース周辺や障害発生以外でほぼ0。むしろ20時くらいになったら会社に人が残っていない。
  • ミーティングでお互いの意見を纏めて施策進行していたので納得感は大きかった。

ちょっと改善してほしいなと思ったところ

  • ゲーム部門が売上の多くを占めていたので、施策改善などのチャレンジに二の足を踏みがち。売上安定化させなきゃいけないのでしょうがないね。
  • 次の売上を担うゲームがなかなか出ない。色々動いていたが、自分が所属していた4年間で、刺さっていたやつ含め2本しか出せていない。
  • いきなり大型のタイトルを成功させようとしている。ゲーム開発を成功させるには、比較的リリース数の要素が大きいので、小さいものをポンポン出しても良かったと思う
    • サイゲとかコロプラの配信ゲーム見ると、多くの小さなものをリリースして今がある訳でして。
  • 組織の硬直化。セクションを跨いだ調整が多く、計画は立つもののなかなか進行できない。調整に時間使うくらいなら動...(ry
  • 良くも悪くも人がおとなしい。ガンガン進める人間がここに混ざると多かれ少なかれ軋轢を生む。
    • やめるときに、「早く動きたいのはわかるけどその動きが組織を壊すからやめろ」と直で言われる(´・ω・`)悲しみ
  • チームに刺さる人が多くなってくると、各々見ている方向が変わってきて、一枚板ではなくなってきた。

こんな感じ。得たものは大きいが、振り返ると自分自身も考えることが多かったと反省。
総評的にはすごくいい会社で、働きやすい環境ではありました。
ただ、ガツガツ新規タイトルなり改善を回したい自分にとっては、ちょっとやり辛さを感じていたのも事実でした。

次は、もっと積極的に新しい事業にチャレンジして結果につなげている会社で頑張っていきたいと思います。 それまでは、しばし放置気味だった個人開発をちょこちょこ進めつつ、生きていきたいと思います(`・ω・´)

お疲れ様でした。

GCPで微妙な課金をされている件について

クレジットカードの支払を眺めていたところ、停止した状態のGCPでわずかにお金が掛かっていたようで。

f:id:gdgd-shinoyu:20180530020128p:plain

よくよく調べてみたところ、インスタンスやスナップショットは止まっていましたが、外部IPが生き続けていた模様。 生かしておく意味も今のところないので、サクッと削除して事なきを得ましたが。 これ長く気づかなかったらもったいないですね(´・ω・`)とりあえず、すでに支払われた2ヶ月分はあきらめです。

メニュー - VPCネットワーク - 外部IPアドレス

から、管理ページを表示できます。そこで削除処理すれば終了です。

「みんなのGo言語」は、初学者向けに向いている本であったという話

一年近く前に購入した本です。

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

購入した時に中を軽く見たっきり仕舞っていたものです。 先日掃除した時に発掘しまして、しばらくGo触っていなかったこともあり、これを気にもう一度頭に入れ直そうと思った次第です。

改めて見返してみたところ、初学者が特にハマりやすい環境構築周りの話がしっかり書かれており、 以前苦労して環境作ったことが切なく感じるくらいわかりやすく纏まっています。

本の内容としては、よくある言語解説というより、実用的でを前提に書かれています。 簡単なアプリケーションを作るところから、テストの書き方、ベンチマーク、リフレクションとGoができることを一通り解説されてます。

個人的に一番有益だったのは、CLIツールの作り方が書かれていることですね。 目的がないと学習始められない私みたいな人は、こういう利益に直結する話が書かれていた方がやる気が出ます。💪('ω'💪)

これからちゃんと読み込んで復習していくので、過程で何か面白いこと見つかったら書いていきたいと思います。

理不尽リジェクトの憂鬱

最近職場で使っているMacbook Pro(2017)のトラックパッドがよく反応しなくなる今日この頃です_(:3」∠)_
まとめてキーボードまで反応しなくなるため、発生したら泣く泣く再起動掛けてます。つらみ。

最近はApple様の理不尽リジェクトにビンタされることが多くなりました。
今回のリジェクト理由はこれ。なおUnity5.4で制作したものです。 https://stackoverflow.com/questions/49153684/ios-app-rejected-app-uses-or-references-non-public-apis

Your app uses or references the following non-public APIs:

食らったやつではAvatarKit.framework(_sharedInstance)という内容だったんですが、その他の文面はまるっきり一緒でした。 その辺絡んでそうなアップデート掛けてないし、追加したライブラリもアセットも無いんですがね… 一応、書かれている通り諸々ツールを使って調べるわけですよ。

# 共有ライブラリを調べる
otool -L {app}_dir/{app}.app | grep -e AvatarKit -e _sharedInstance

# obj-cの構成見てみる
otool -ov {app}_dir/{app}.app | grep -e AvatarKit -e _sharedInstance

みつからない。

nm  {app}_dir/{app}.app | grep -e AvatarKit -e _sharedInstance

見つからない

strings {app}_dir/{app}.app | grep -e AvatarKit -e _sharedInstance

見つからない(´・ω・`)Apple様はどこ見て判断したんや…
悩んでたところ、同僚から「アンスコついてないsharedInstanceならstringsでヒットする」と報告もらったわけです。 これは誤認パターンなのでは?という疑念が。

いそいそとXcodeインストールしてる私を尻目に、別の同僚がXcodeProjectからどこのコードが"sharedInstance"なる名前を使っているか調べてくれ、指摘されていたAPIでないことがはっきりしたので、返信へ。

「そんなAPI使ってないし、指定されたツール使っても見つからない。怪しそうなのはAvatarKitじゃない」的な解答をして結果待ちです_(:3」∠)_

調べてみると、同様の事例は結構存在しているみたいですね。
http://sonson.jp/blog/2010/09/23/private-api/
とか

ここまで理不尽なリジェクト食らうと、大変しんどみあります。PWAの進化を期待したいところ。 qiita.com

2018/04/21追記

ダメでした(´・ω・`) 対応せーやとのこと。

しかし、やはり使ってないところで文句言われるの納得行かないので、 向こうの提示したツールでの実行結果や、アプリケーションのアーカイブ自体を投げつけて、 「これで検証したけど出てこない。どう判断したかやり方をおしえてくれ」的な文言で返信しました。

さて、これでどう出てくるやら… これでもダメだった場合、XcodeProjectとして吐き出した後に一括置換する方法で検討しています。 まー仕方ないですね。

仮想通貨に触れてみた雑感(単なる取引の話)

f:id:gdgd-shinoyu:20171207234405p:plain

つまりbitcoin買いました(割と高値で)

一日の値動きがかなり異常であり、おもしろいぶっ飛び方をするので興味本位で買ってみましたが、今現在だと変なバブル感でていてしばらく失速しそうにない印象です。
まあ、いつガラるか分からない値動きでもあるんですが。遊び半分で小額しか突っ込んでますがどうなることやら。

仮想通貨を個人が購入する場合、「販売所」と「取引所」の2種類が選択肢になります。

  • 取引所
    売り買いのマッチングで行われる。株の板と同じような印象。
    仮想通貨の購入数から手数料として少しばかりの仮想通貨を掠められますが、まあ手数料としては許容できる範囲です。ちなみに自分が買った0.02bitcoinの手数料は0.00003bitcointでした。0.7%くらいですかね。
    長所は販売所と比較して、スプレッドがなく売買価格の縛りがないことですね。
    欠点は暴落暴騰時に決済できない可能性があることです(暴落したとき売りたい人ばっかりになるため)

  • 販売所
    個人間の取引ではなく販売所の中で取引されるものです。PTSみたいなもんですかね。
    スプレッドが適用され購入価格と販売価格に差があります(スプレッド分が運営会社の取り分になってるらしい)。つまりそのとき時点のレートでの取引ができません。
    Monacoinも触ったんですが、だいたい±8%分の乖離があります。結構もってかれますね。なので普段は取引所使うようにしてます。 暴落暴騰時にも取引を受け付けてくれるらしいので、何かあったときはこちらのお世話になることがあるかもしれません。

個人的な用途としては、取引所で自由に売り買いしたいので、それが多くできる運用会社を選びたいところ。
オススメであげられていたbitFlyerだと、取引所で選べるものはBitcoinのみですね。ちょっと物足りない…

bitflyer.jp

個人的には、冒頭に貼ったチャートを使えるbitbankがよいかもです。

bitbank.cc

日本円から取引できる仮想通貨が、

  • Bitcoin
  • Ripple
  • Ethereum
  • Monacoin
  • Litecoin

と、そこそこあるのに加えて、APIが公開されているので自動化等も捗りそうです。

もう少し額を増やしてみて、どれだけのパフォーマンスが出るか楽しみなところです( ・`д・´)

Rubyにおいて要素有無判定にはcountよりempty?使おう、というゆるふわ話

弊社では担当プロダクトごとにエンジニアが複数人付く体制でWEBサービスの開発運用やってます。 その過程でコードレビューを実施してるわけなんですが、

とある日、他の人のコード見ていて要素があるかないか、をこう判定しているコードを見つけました。

## items: Array

return false items.count == 0

countだと要素の数え上げしちゃうんでempty?使った方が効率いいっすよ、というレビューコメントを書いたわけですよ。 その時ふと、「本当にempty?のほうが良いのか?」という疑問が(;・`д・)

気になったので、少し深掘りしました。

countを使う場合

rubyソースコードが公開されてるので、それを見ます。 https://github.com/ruby/ruby/blob/trunk/array.c

rb_ary_countっていうものが該当します。

static VALUE
rb_ary_count(int argc, VALUE *argv, VALUE ary)
{
    long n = 0;

    if (argc == 0) {
        VALUE *p, *pend;

        if (!rb_block_given_p())
            return LONG2NUM(RARRAY_LEN(ary));

        for (p = RARRAY_PTR(ary), pend = p + RARRAY_LEN(ary); p < pend; p++) {
            if (RTEST(rb_yield(*p))) n++;
        }
    }
    else {
        VALUE obj, *p, *pend;

        rb_scan_args(argc, argv, "1", &obj);
        if (rb_block_given_p()) {
            rb_warn("given block not used");
        }
        for (p = RARRAY_PTR(ary), pend = p + RARRAY_LEN(ary); p < pend; p++) {
            if (rb_equal(*p, obj)) n++;
        }
    }

    return LONG2NUM(n);
}

予想どおり、forを回してカウントとってますね。

empty?を使う場合。

一方empty?。これも同じソースコード中に定義が存在します。中身こんなんです。

static VALUE
rb_ary_empty_p(VALUE ary)
{
    if (RARRAY_LEN(ary) == 0)
        return Qtrue;
    return Qfalse;
}

RARRAY_LENしか読んでませんね。中身見るとこうなってます。

#define RARRAY_LEN(ARRAY) RARRAY(ARRAY)->len

arrayが持っているlenというメンバに対して値を取得して判定してますね。 empty?では、要素数え上げしてないので、countより計算量は少ないわけですな。

まあ、この程度の数え上げする・しないの話は、全体の影響度からするとごくわずかな違いでしか無いので、普通にWebやってるだけなら気にする必要はないんですが、実際に蓋開けた結果を知っておくのも大事だと思いました。