なんとなく1年を振り返って
今年も色々あったなあ

  • サイボウズの技術顧問になった
1番大きな変化はなんといってもこれでしょう。
 パラレルキャリアがクローズアップされた時期と重なったこともあり、SNS等でも大きく
取り上げられましたし、朝日新聞にも WEBRONZA: 「一生に、何社で働く? 一度に、
何社で働く?」 http://webronza.asahi.com/science/articles/2017103000014.html 
にて取り上げられました

  • 青色確定申告を始めた
前述の理由により確定申告が必須になり、あわてて個人事業主登録と青色確定申告の申請をしてきました。
確定申告ソフトは最初MF確定申告にしようと思ってたんだけど、とても不愉快な思いをすることがあって
(具体的には過去のデータが消えて、サポートが復活を拒否した)、ちょっと事業の会計管理という重要部分を
おまかせするパートナーとしては厳しい感じだったんで、freeeにしました。freeeいいですよ、いろいろ
不満もあるけど。
送ったバグレポート、なにも直してくれないけど。

それにともなって、税理士さんと契約しました。最初、税理士紹介ドットコム.com‎ で
探してたんですが、ITほぼ使えない化石おじさんしか紹介されない(そういう人に
かぎって高い)ので、結局、
freeeの税理士紹介サービスを利用。どういう仕組み
かしらないけど、freeeが紹介してくれる税理士は世間よりもだいぶ提示してくる
金額が低かった。(3社相見積とって3社とも税理士紹介ドットコムの半分以下の提示)
わたしはいま、STC国際税務会計事務所 という所を使っていますが、
導入サポート業務:5万円/年間
確定申告業務:5万円
という格安の金額でお願いしております(この業界、客の売上に応じて
単価変わる慣例みたいなので、僕と違ってちゃんと儲かってる人は
もっと高いかも)。
やりとりはだいたいメールで、こっちが不明点を質問して答えて
くれるのと、向こうがfreeeをのぞいて(freeeには税理士に自分の
アカウントを公開する機能あり)間違いを突っ込んでくれるのの
双方向でやりとりしてます。
導入サポート業務の名目で、freeeの使い方ヘルプと開業手続きヘルプと、
普通の税務顧問としての経費処理の間違いツッコミ処理を全部
やってくれてます。
特に開業当初はふだんのルーチンとは違うお金の使い方をすることが
多いので、税理士まじお得と思った。自力でやって溶かす時間
考えたら余裕で元取れる。
今の担当者、若いけど仕事が丁寧なので助かってます。もし、興味が
ある人がいたら紹介も出来ますよ。

  • 勤務先が変わった
所属が、富士通から富士通研究所に変わり、あわせて勤務地が(静岡県)沼津から川崎(中原)へ転勤となった。
社内のことはあまり話せないが、内部のポジションもいろいろ変わった
本部長だの役員だのに報告しに行く機会がやたらと増え、気苦労が増えた。

  • セキュリティキャンプの講師に復活した
例年そうだけど、今年は特にあたまのおかしい(褒め言葉)講義が多くて聞いてて楽しかった。
しかし、体力的にはきつい。10代の無限の体力うらやましすぎる

  • #pyspa slackに参加した
プロシンでたまたま知り合ったところてんさんに紹介されてJoinしました。

この記事自体も pyspa advent calendarに影響されてだ
https://adventar.org/calendars/2258

最近は #kane チャンネルに入り浸っていて、よく確定申告の悩みとか吐露しあってる。
自分が相当カネレベルが低いので正直助かる。

  • 人生で初めて芋煮をたべた
うまい。あんなうまいものだとは思わなかった。東北の人間はあんな隠し玉かくしもっててずるい。
そして、仙台と山形でまったく違うたべものなのさらにずるい
12月に山形の天童にいってもう一回食べた。

  • 人生ではじめてFP(ファイナンシャルプランナー)に相談にいった
前述のpyspaに紹介されて、恵比寿にあるFPに人生相談にいき始めた
ブロードマインドという会社です。保険とか投資信託の積立のバランスとか幅広く相談になってくれます。
自分がいかに今までなにも考えずに生きてきたか痛感。
いま担当してくれてる人は、とてもたよりになる人なので、興味がある人がいたら紹介します。


  • ソーシャルレンディングに参加してみた
最大手のmaneoを使ってます。いまのところ、手間に見合わない感じかなあ



なんとなくサラっと書いたけど、本業変わって、住んでる場所変わって、副業もふえて、ってやっぱり大きな変化だよなあと、再認識した。
ほんとに個人的な備忘録なのでこのへんで。

https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html

目玉は

- explicit_bzeroのサポート (OpenBSDからの輸入)
- getentropy と getrandom の追加(いままではsyscallを直接呼ぶしかなかった)
- malloc_get_state と malloc_set_state functions の削除(うわさのemacs専用関数です。つかうのはemacsビルド時だけなのでemacs開発者は./configureを再実行してね)
- GDBのpretty printでmutexとcondition variableがきれいに表示されるように(なんでglibcに関係するんだろう?)
- pthreadの condition variableのアルゴリズムが変更され、順序が強く保証されるように
- pthread_rwlockがよりスケーラブルに

最初の2つが一番影響大きそう





 

6年ぐらい前に、execle, execlp が man では async-signal-safe にリストされてるけど間違ってるよという
チケットを切ったんだけど、ずっと放置されてて

https://bugzilla.kernel.org/show_bug.cgi?id=25292 

6年後に対応してもらえましたよ。実装がなおったんだよね。
glibc 2.24 からexec系 syscall がまともになりました。

https://sourceware.org/bugzilla/show_bug.cgi?id=19534

みんな、Adhemerval Zanella に感謝しよう。

これ結構ひどくて、multi thread で forkした場合は以降は async-signal-safe しか呼んではいけないので
exec呼んだらデッドロックリスクがある(かつmanには書いてない)という、たいそう罠な仕様だったのさ。
アーメン

 

うちでは最低8GBないとまともに動かない感じだなあ。
 ここをセコくチューニングしても負荷があがったら途端に破綻するので、このまま行くべきかな


まあ、端的に言うとここに全部書いてあった。

 MySQLでToo many connectionsが出た時の対応 http://qiita.com/kenjiszk/items/c3d46ac837845281e62b

% mysql -u root -p  

mysql> show variables like "%max_connections%";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.01 sec)

設定変えるときは /etc/my.cnf に

[mysqld]
max_connections        = 1000
と書けばいいっぽいが、Ubuntuだと設定ファイルの階層がちょっと違っていて
/etc/mysql/mysql.conf.d/max_connections.cnf みたいな新規ファイルを作り、
[mysqld]
max_connections        = 1000
と書くのがよい。

これで終わり・・・・・と思うだろ?

% mysql -u root -p  

mysql> show variables like "%max_connections%";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 214   |
+-----------------+-------+
1 row in set (0.01 sec)

なんだよ、214って。幸いなことに同じことにあたった人がいたのですぐに解決

MySQL Max_connections stuck on 214? https://codepoets.co.uk/2015/mysql-max_connections-stuck-on-214/

Increasing File Descriptors and Open Files Limit CentOS 7 https://naveensnayak.wordpress.com/2015/09/17/increasing-file-descriptors-and-open-files-limit-centos-7/


ようするに process の rlmit が低すぎるので上げてあげればよろしい。
/etc/security/limits.conf を設定するのは Ubuntu 16.04 では動かなくて(そして必要もなくて)

/lib/systemd/system/mysql.service

の [Service] セクションに
LimitNOFILE=65535
などと足してやればいい。

%
/lib/systemd/*/*.service は上書きしてはいけないらしいです。

systemdで既存のunitを編集する2つの方法 http://qiita.com/nvsofts/items/529e422bb8a326401c39

このへんのページ参照
%

sudo EDITOR=emacs systemctl edit mysql.service
とかして、設定ファイル編集画面を立ち上げて

[Service]
LimitNOFILE=65535
と書いて、セーブ&exit。

おわったら、

% systemctl restart mysql
して、また最初の設定値確認の方法で、ただしく動いていることを確認する。


追記 2016/12/13: はてぶに大層有益な情報がのってたので転載
tmtms: Ubuntu の systemd の設定で root じゃなくて mysql ユーザーで起動するようになってて mysqld 起動後に setrlimit で fd の上限をあげられないからかな。大昔に調べてた→ http://tmtms.hatenablog.com/entry/20090605/1244215294


↑このページのトップヘ