情シスは何度でも甦るさ。

OracleDB/Ruby好きの情シス部員がお送りします

iPhoneアプリを独学で作るまで(継続中)

会社のシステムでiPhoneアプリを作ることになりそう

うちはしがないアパレル中堅企業なのだが、店頭用のシステムのリプレースにおいて、iPhoneアプリで作ることになりそう。

んでもって、そんなノウハウ無いので、開発会社の言いなりになるのは嫌だし、何より新しい言語勉強したい欲があったので、自分で勉強することにした。

最終目標としてはアプリをリリースするところまで。(アプリの内容は問わない!)

その経緯を現在進行系で書いていく。

2017年8月「絶対に挫折しないiPhoneアプリ開発「超」入門」を読む

https://www.amazon.co.jp/dp/B01MQPA946www.amazon.co.jp

今から勉強するならswiftだし、ということで、swift3に対応してて、人気が高そうな書籍を漁ったところ、この本にした。

8月に入って、仕事が暇になってきたので、仕事から帰って1、2時間で、50ページ程度を進めてめていく。

最初は、Xcodeの使い方がわけわからんかったが、この本が懇切丁寧なのもあって、なんとなーく理解できた。

swiftの言語についても、デリゲートを覗いては、書いて有ることはほぼ理解できた。(初心者向けだから当然か)

ただ、UIKitとかのiOSフレームワーク周りが全くの謎。

こういう画面を作りたい時に、どういうクラスを使うのか、どういう書き方でやるのかが全く謎。

最後のアプリもなんとなく書いて動いたけど、その点が理解できず。。。Visual Studioだと、フォームにコンポーネントをペタペタ貼ってけば、アプリができるが、それと同じように頭の中でイメージ化することができない。

これは、色んなアプリを作ってみて、iOSコンポーネントやそのお作法を学習する必要があるのだろうなー、と思ってみたものの、そういう2冊目に、適した本が見つからない・・・。とりあえず、何か探してみるか。

ただ、アプリ作成→そこで使った言語仕様やXcodeiOSの機能の説明。というサイクルで手を動かしながら学ぶ形式は名前の通り挫折しにくい構成であり、評判どおりかなり良い書籍だと思った。

なお、メリカリで1500円で売れた。

2017年9月「TECHNICAL MASTER はじめてのiOSアプリ開発」を読む

Amazon CAPTCHA

2冊めの本を色々迷った挙句、こちらを購入する。

理由は、1冊目でようわからんと感じたUIKit周りの説明がされていると目次から読み取れたのと、一つのアプリに機能を徐々に追加していくという実用的な流れだったから。

というわけで、本やり終わったらまた追記するぜ

zabbixのデータが増えすぎ問題

去年、監視のために導入したzabbix(ver2.4)ですが、対象サーバが、120台くらいあり、テンプレートの監視項目をそのまんま適用してたら、高負荷状態になり、画面ももっさり、監視ももっさりしてきてしまった。

導入後に、zabbixサーバ自体のメンテを怠ってたのは知っていて、いつか対応しなきゃね。って話を、導入した協力会社の人としてたんだが、その人がいなくなってしまい、対応できるのが他におらず、対応することに。

STEP1. 監視項目の見直し

まず、アイテム(監視項目)の減少。 テンプレートの監視項目をすべて適用しているので、一旦、最低限必要なものを覗いて、監視項目を無効化してまわる。
最低限必要なものとは、PING監視と、ディスク容量監視と、アプリケーションログの監視。

3600ほどあった有効な監視項目を1600ほどに削減。(有効になってても実際に監視に使ってない項目もある)

STEP2. データ容量の見直し

過去データを削除するが、対象テーブルの特定。

サイズを調べてみる。(こちらの記事を参考:データベースとテーブルのサイズを確認する方法 - ふってもハレても

table_name engine tbl_rows rlen allMB dMB iMB
history_uint InnoDB 136449572 74 14039 9748 4291
history InnoDB 17177763 69 1734 1131 603
trends_uint InnoDB 14692072 80 1134 1134 0
events InnoDB 3087769 72 444 212 232
history_log InnoDB 700203 202 173 135 38
trends InnoDB 2045698 74 146 146 0

hisutory_uintの1.3億レコードにびびるが、色々、サイトを見て回ると、データを圧縮しつつ、データファイルをテーブルごとに分割すると良いよとのこと。 mysqlのバージョン的にも適合するので、これでいくことに。

httpd、zabbix-server、mysqldのサービスを止めて、my.cnfを書き換える。

/etc/my.cnf

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

character-set-server=utf8

#ここから追加
ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so
innodb_file_per_table
innodb_file_format=Barracuda
#ここまで

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

mysql起動し、alter tableで対象のテーブルを再構成していく。
history_uintは、でかいので後回しに。

alter table

alter table history ENGINE=INNODB ROW_FORMAT=Compressed;
alter table trends ENGINE=INNODB ROW_FORMAT=Compressed;
alter table trends_uint ENGINE=INNODB ROW_FORMAT=Compressed;
alter table history_log ENGINE=INNODB ROW_FORMAT=Compressed;
alter table events ENGINE=INNODB ROW_FORMAT=Compressed;

再度、データサイズをチェック

table_name engine tbl_rows rlen allMB dMB iMB
history_uint InnoDB 156635215 65 14047 9751 4296
history InnoDB 16962930 33 774 534 239
trends_uint InnoDB 15694129 34 523 523 0
events InnoDB 3073469 31 204 92 111
history_log InnoDB 746147 94 86 67 18
trends InnoDB 1963177 37 69 69 0

データファイルが別ファイルになっているか確認

ls -lh /var/lib/mysql/zabbix/*.ibd
-rw-rw---- 1 mysql mysql 212M  7月 24 15:21 2017 /var/lib/mysql/zabbix/events.ibd
-rw-rw---- 1 mysql mysql 792M  7月 24 15:21 2017 /var/lib/mysql/zabbix/history.ibd
-rw-rw---- 1 mysql mysql  92M  7月 24 15:21 2017 /var/lib/mysql/zabbix/history_log.ibd
-rw-rw---- 1 mysql mysql  64K  7月 24 15:57 2017 /var/lib/mysql/zabbix/history_uint_new.ibd
-rw-rw---- 1 mysql mysql  76M  7月 24 15:21 2017 /var/lib/mysql/zabbix/trends.ibd
-rw-rw---- 1 mysql mysql 536M  7月 24 15:21 2017 /var/lib/mysql/zabbix/trends_uint.ibd

大体サイズは半分になってる。 しかし、最大のテーブル、history_uintがやっかい。なにせ1.5億レコード。

えい、ままよやってまえ!

alter table history_uint ENGINE=INNODB ROW_FORMAT=Compressed;

週末流しっぱにしてたが、60時間たってもSQL終わらず。。。 あえなくKILL。こりゃtruncateしちゃうか。と考えるが、英語のサイトで、別テーブル作成して、任意の期間のデータをコピーして、リネームする手順が紹介されてた。

CLEANING UP THE ZABBIX DATABASE

CREATE TABLE history_uint_new LIKE history_uint;
INSERT INTO history_uint_new SELECT * FROM history_uint WHERE clock > '[timestamp]';

20日間ほどのデータを退避しようとしたが、そもそもSELECTが終わらねえ。うーん。 なので、空のテーブルのまま、TABLEを切り替えることに。(意味なし)

table 切り替え。再度、zabbixを起動して、問題なければDrop table実行

ALTER TABLE history_uint RENAME history_uint_old;
ALTER TABLE history_uint_new RENAME history_uint;    
DROP TABLE history_uint_old;

で、3週間くらいたった。

table_name engine tbl_rows rlen allMB dMB iMB
history_uint InnoDB 37300965 28 1496 997 499
trends_uint InnoDB 14785949 36 509 509 0
history InnoDB 7749555 40 423 299 124
events InnoDB 2530589 31 172 76 95
trends InnoDB 1704568 36 59 59 0
history_log InnoDB 339517 102 43 33 10

サイズは、対応前の15%程度。 大丈夫そうなので、必要なサーバに関しては、リソース系の監視項目を追加しようと考え中。

csvからiCalファイルを出力するExcelマクロを作った

会社でグループウェアを移行することになった。 そこで、スケジュールデータをどう移行するかという話になったのだが、

グループウェアCSVをエクスポートできる
グループウェアiCalファイルのみインポートできる

ということで、うまく噛み合わず。

じゃぁ、旧グループウェアCSVをエクセルを経由して、iCalにしてしまえ。ということで、iCalを吐くマクロを作った。

www.dropbox.com

ちなみに、必要項目は最低限しか対応しておらず、繰り返しとかの予定は持ってけません。
あと、Excel2016 on Windows10で動いたけど、他の環境では試してまへん。