レタスのかわをぜんぶむく

ぜんぶむきます

職を転してちょうど1年が過ぎた

なんとなく過去のFacebookメッセンジャーのログを眺めていたら、
現職の社長と入社日の調整のやりとりのログを見つけた。

『使いたいPCやキーボードやマウスはなんですか?』
「えっ、なんでも選んでいいの?めっちゃ高いやつ買ったろ!」

というところから始まり、

「地方からの引っ越しなのでもうちょい待って欲しい!」
『いや、それは都合いいタイミングで良いから落ち着け』

みたいなところで終わってて、どんだけ楽しみだったんだ自分と思って笑ってしまった。

ログの日付が2017年3月10日で、その1ヶ月後の4月10日に入社したので
昨日でちょうど転職して一年になる。思い返すとあっという間だった。

辞めエントリは絶対に書かないと…と思ったまま1年が過ぎてしまったので
時が過ぎて記憶が極端に美化される前に、転職前後に何を考えてたかを思い出して書く。

続きを読む

いつもタブの数が爆発している人へ

One Tab入れましょう。以上。
Web系キラキラ女子エンジニアな先輩に教わってから
2秒でヘビーユーズ。むしろ出会うのが遅すぎた。

Chromeだったらコレ。chrome.google.com

Firefoxだったらコレ。addons.mozilla.org


使う場面としては、例えば、夕方オフィスでMP切れるじゃないですか
あ、19時過ぎた、息抜きにgigazineのヘッドライン見よーつって

f:id:uskey:20150825023304p:plain

これだよ!

ちょっとでも食指が伸びた記事をクリックするとこうなる
アイコンが見えなくなってからが勝負みたいな。

分かる分かるっていう人はこっち側です、ようこそ。
とりあえず一旦全部クリックしてみて、それから考える派ね。

それでも安心。OneTabがあれば、ポチって押すだけでこう。
あ、押すのは右上の水色の漏斗みたいなアイコンです。

f:id:uskey:20150825023739p:plain

OneTab内にリンクがリストされて、他のタブは閉じられる。
しかもかなり便利なことに、一括で戻せたり、
リストをロックしたり、名前をつけて保存したり出来る。

一旦頭冷やして、後でゆっくり読むことも出来るし
なんなら何か調査系のタスクでとりあえずリンク踏みまくって
OneTabで保存して、ちゃんとそれぞれ評価したり出来る。
もちろん全破棄してもいい!

便利!







f:id:uskey:20150825182603p:plain

まぁ既に結構積んでるけどな!

期間指定でやらかし(かけ)た話

既に走ってるサービスだとログとか取り続けていて
いざ何か問題が起きた時にその調査をログベースで対応したりする。


そんでやって参りましたログ調査。
特定の種類のユーザーについて7,8月のユーザー数を見たい。

SELECT count(*)
  FROM users
    WHERE last_login 
      BETWEEN '2015-07-01' AND '2015-07-31';

よし、7月だからこれで良いよね。
単一テーブルだから楽勝楽勝。

と思うじゃないですか。

若干思ってたより少ないなーと思って

SELECT id, last_login
  FROM users
    WHERE last_login 
      BETWEEN '2015-07-01' AND '2015-07-31'
        ORDER BY last_login DESC
          LIMIT 10;

こんな感じでとったら

+---------+---------------------+
| id      | last_login          |
+---------+---------------------+
| userid1 | 2015-07-30 23:59:47 |
| userid2 | 2015-07-30 23:59:35 |
| userid3 | 2015-07-30 23:57:46 |
+---------+---------------------+

ものの見事に31日のログが抜けてる!
なるほどそっちか!

パッと見上手くいきそうなのがすごくあかん。
ということで正しくは下記。

SELECT id, last_login
  FROM users
    WHERE last_login 
      BETWEEN '2015-07-01 00:00:00' AND '2015-07-31 23:59:59'
        ORDER BY last_login DESC
          LIMIT 10;

これで期待した結果になった!
ちゃんと時間まで指定しましょう!

Cornerstoneを捨てて、UTF-8-MACと戦った話

おしごとでGithubを使いはじめて数年。
案件な関係でSubversionと相見えることに。

Cornerstoneの様子がおかしい

www.zennaware.com

前に使っていたCornerstoneというSubversionクライアントを使って作業開始。
しばらく使ってると不思議な挙動に気づく。
自分の担当箇所をいじってコミットしようとすると
全然いじってないファイルが編集済みにマークされている…


無視してコミット出来るっちゃ出来るけど相当に気持ち悪い。
その上、すんげークライアントの動きがまったりしている。


プロジェクトの規模感(ブランチ単位で20GB)もあるから仕方ないけど
作業できなければ、オフィスの二酸化炭素濃度上げてるだけなので
とりあえず作業進めるために、ガワ無い分おそらく速いだろうと思われる
CUI直叩きで作業をすることに決めた。(やったこと無いしどうせなら勉強)

CUI用のSubversionのインストール

Cornerstone自体がSVNクライアントを内包しているようで
外からうまく叩く事が出来なかった。なんと。
これまで使っていたSubversionはCornerstoneと一緒にさよなら。


さくっとMacPortsで入れてみる。

$ sudo port install subversion
--->  Fetching archive for subversion
--->  Attempting to fetch subversion-1.9.0_0.darwin_14.x86_64.tbz2 from http://packages.macports.org/subversion
--->  Attempting to fetch subversion-1.9.0_0.darwin_14.x86_64.tbz2.rmd160 from http://packages.macports.org/subversion
--->  Installing subversion @1.9.0_0

1.9.0系入ってきた!なんか知ってるやつより新しい!
絶対早くなるパターンだ!コレで勝つる!
さっきまで触ってたプロジェクト直下に行って

$ svn info
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Projects/project'
is too old (format 29) to work with client version '1.9.0 (r1692801)' (expects format 31). You need to upgrade the working copy first.

歴史のあるプロジェクトだもんで、リポジトリのバージョンも古い。
調べてみる限りだと、ワーキングコピーだけバージョン上げられるっぽいけど、
他の影響考えたり、検証の手間を避け一旦は現行バージョンまで落とす事に。


まぁ早い話、チキッた
良いの!お仕事だから安全第一。
自分プロジェクトだと、えいやってやるけどね。

複数バージョンをインストール出来るらしい

古いバージョンのSubversionを入れようと思って調べていると
どうやら、古いバージョンのPortFileを直接使えばいいらしい。


MacPortsリポジトリブラウザを開いて
( dports in trunk – MacPorts )
ツリーを開いてSubversionのPortFileを探すとこんなページに行くので
( Portfile in trunk/dports/devel/subversion – MacPorts )
ここから前後へ移動で、インストールしたいバージョンのものを検索。
Subversionについては、前のバージョンに合わせて1.7.xを入れることに。


例えば、ここでお目当てのバージョンが1.7.10だとすれば
リビジョンは106653になるので下記のようなコマンドを実行。

$ mkdir tmpsvn
$ cd tmpsvn
$ svn co -r 106653 http://svn.macports.org/repository/macports/trunk/dports/devel/subversion
$ cd ./subversion
$ sudo port install
 ....
$port installed subversion
The following ports are currently installed:
  subversion @1.7.10_1 (active)
  subversion @1.9.0_0

うむ。入っているしちゃんと動く。少し動作も早くなった感ある。


ただし、日本語ファイルがアレなのはさっきと一緒(アー
どうやらSubversionが古いことが原因ではない模様。

UTF-8-MAC

色々調べているとこんな記事を見つけた。

svnで日本語ファイル名を使ってるとMAC-UTF8では違うファイル名ってことになるのでcheckoutしてきただけで変更扱いになる。

http://docs.komagata.org/4962

まさにコレ。バージョンはあってたけど、
ビルド時のフラグ必要だったっぽい。
仕方ないので、現状の1.7.10は消しちゃう。

先にactiveなバージョンを退避させてアンインストール。
(なんか巻き込み事故あったら怖い

退避
$ sudo port activate subversion @1.9.0_0
--->  The following versions of subversion are currently installed:
--->      subversion @1.7.10_1
--->      subversion @1.9.0_0 (active)
アンインストール
$ sudo port uninstall subversion @1.7.10_1
--->  Uninstalling subversion@1.7.10_1
--->  Cleaning subversion

どうやら、MacPortsではソースからビルドする時と
同じようにオプジョンをつけられるらしい。

オプションの確認
$ port variants
subversion has the variants:
   disable_keychain: Disables support for the Mac OS X Keychain
   mac_os_x_server_mod_dav_svn: Unsupported - attempt to build the subversion apache module with apple supplied apache2
   mod_dav_svn: Install the subversion apache module (mod_dav_svn)
   no_bdb: Build without support for BerkeleyDB repositories
   tools: Install some optional extra subversion tools
   unicode_path: Installs a hack to workaround Mac OS X unicode path issues
   universal: Build for multiple architectures

unicode_path: Installs a hack to workaround Mac OS X unicode path issues

こいつか

オプションつけて再インストール
$ sudo port install +unicode_path
 ....
$ port installed subversion
subversion @1.7.10_1+unicode_path (active)

試してみると、無事日本語問題解決してた。

Macでzcatが上手くいかない件について

サーバ管理をしていると、tar.gzで固められたファイルから
特定の情報を探したりとかする必要がしばしば出てくる。

前はWindowsだったけど今はMacだからローカルで作業余裕
ルンルン(裏声)とか思って、scpで落として来て作業開始したら

知ってるコマンドが通用しねぇ…

やりたかった事としては、圧縮されたログファイルの中身を読むこと。

$ zcat log20150810.tar.gz
zcat: log20150810.tar.gz.Z: No such file or directory

いやいや、tar.gzで良いんだって!別に.Zとか探してないよ!
サーバ上だとちゃんと動く。うーん、と思って調べたら
なんとMacではgz圧縮されたファイルはzcatでは読めない!

んだよ一々解凍してチェックしないといけないのか
と思ったらgzcatというコマンドがあるらしい。

もともと

どうやらzcatというのはcompressというツールで圧縮した際の
.Zファイルと呼ばれる、今ではほとんど見ないエンシェント形式に
対応したcatということで、gzcatはそのgzip版。うーん、闇。

サーバに入ってるCentOSとかだと、zcatで読めるようになっているのは
多分便利だったから短い方のコマンドが採用されたんだろう(適当

同じ名前したパッケージだけど実はパッチ当たってないと特定機能が
無いとか、オプション必要だったとかはとてもよくある話なので
サーバで同じ事するときは事前に確認するの大切だなーと再確認。

オチ

結局集計作業としてやりたかったことはzgrepで普通に出来たので
zcatで先に見ようとしてなければそもそも、こんな問題起きてなかった
というかそこはgzgrepではないのか…

みんなもgzcat使ってみてくれよな!