まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2015/05

今年も（AKB48 選抜）総選挙の季節がやってきました。

「投票権はCDに付いているもの」と思っている人も多そうですが、実際は少し異なります。確かに CD にもついていますが、AKB48 公式ファンクラブ会員になるか(1)、AKB48 公式スマートフォンアプリ会員になるか(1)、AKB48 オフィシャルネット会員になるか(1)、各ユニットのモバイル会員になるか(4)、各ユニットの動画見放題会員になる(4)ことでも、それぞれ１票を入手することができます。ただしユニット毎のモバイル会員および動画見放題会員になるにはいわゆるキャリア決済が必要なので、MVNO ではない主要キャリアの契約が必要です。　つまりCDを買わなくても、キャリア契約の携帯電話を１台持っていれば最大で１１票入手することができます（逆を言えば、１２票以上入手するにはCDを買うことになります）。キャリア契約を２つ持っている人であれば更に８票入手できる、ということです。

簡単に票を入手するには CD を購入するのが一番簡単です（握手券もついてきます）が、最も手軽に（安く）票を入手するにはユニットのモバイル会員になることです（税込324円）。　その方法を紹介します。


まずキャリア契約のある携帯電話およびスマホでモバイル会員サイトにアクセスします。これは AKB48 公式モバイルサイト（http://www.akb48.co.jp/mobile/）です：
写真 01


「投票はこちら」と書かれたリンクをクリックすると、新規会員登録ページに移動します。ここで契約しているキャリアを選びます。自分の場合は au スマホなので一番下をクリック：
写真 02


ここからは au スマホ／iPhone の場合の例です。他のキャリアの場合はそれなりの方法（苦笑）で進めてください。まず au ID でログイン：
写真 03


で「ご利用上の注意」を読んで「同意」：
写真 04


この先からは課金が開始されます。直後に退会しても月額324円。血の一票と考えれば安いものです、迷わず「購入」：
写真 05


最後に au かんたん決済の規約を確認して「同意する」、と。au 以外の方も同様の方法で決済まで行ってください：
写真 06


はい、これでルビコン川の向こう岸です。もう後戻りできません。そのまま総選挙の「投票受付中」ボタンをクリック：
写真 07


ここからは投票画面です。推しメンを選びましょう。チームから検索してもよし、名前で検索してもよし。ちなみにここは AKB48 のモバイル会員サイトですが、投票はどのユニット所属メンバーであっても（立候補していれば）できます：
写真 08


自分はフレッシュ・レモンに一票！
写真 09


投票完了、簡単でした。物足りない人は（笑） AKB48 以外のモバイル会員サイトに移動して同様の会員登録をすればあと３票投票できます：
写真 10


このまま会員でいてもいいと思いますが、投票のためだけにモバイル会員になった人はここで退会しておくと来月分の課金はされません。退会はトップページの一番下のメニューから「退会方法」を選択：
写真 11


思いとどまるかどうか聞かれるので「退会」：
写真 12


退会理由を書いて「送信」：
写真 13


まだ続きます（苦笑）。ここでキャリア決済の退会も行うのでキャリアを選択：
写真 14


au であれば au 簡単決済からも退会します。「解約する」をクリック：
写真 15


はい、全て終わりました。また来年同じ手順で投票しましょう：
写真 16


投票締め切りは６月５日（金） 15:00 です。投票はお早めに！




 
タグ ：
#akb
#hkt
#nmb
#ske
#vote

（特にクラウド環境で）MySQL データベースを使って運用している皆さん、データのバックアップはどうしてますか？

色々な目的や用途、制限の中で使っているので正解は１つではないと思っています。中には「初めからバックアップ込みの DBaaS サービスを使っている」という人もいるでしょう。コスト的に問題なければそれがベストかもしれません。

自分の場合、ある環境では cron で一日一回 mysqldump で取り出した内容を圧縮してそのままオブジェクトストレージに丸投げ、という方法を採用していたりします。オブジェクトストレージにダンプデータが残っていれば、そこからリストアできる、という考え方です。ケースバイケースではあるし、クラウド業者のオプションとかにも依存はしますが、オブジェクトストレージは手軽に使えて、比較的安価な割にデータポータビリティの高いデータストレージなので、コスパ的にもあっていました。これだけだとダンプにないデータやダンプ後に変更があったデータは救えませんが、そこまでシビアなデータ管理を要求されることもないデータベースであれば、手軽なこの方法はオススメでもあります。

一方、データが失われてからリストアするのにあまり長い時間かかることが許されないような場合や、救えないデータがあってはまずい場合はこの方法は向きません。データベースサーバーを多重化するなどして「最悪、１台死んでもいい」環境を構築することになります。


最近、自分の管理している環境下で MySQL データベース（正確には MariaDB だったけど）の Master-Slave レプリケーション環境を構築する機会がありました。その時の作業を記録しておきます。

まず前提条件として、以下のような環境を想定します：
- MySQL 5.x サーバーが１台稼働中。レプリケーション設定はしていない。
- MySQL サーバーを新たにもう１台追加して、Master-Slave の２台構成にする。
- 現在使っているサーバーを Master、新たに追加するサーバーを Slave とする。
- レプリケーションの対象とするデータベースの名前は mydb とする。

以下、順に説明します。現在稼働中の MySQL サーバーを「A」と呼ぶことにします。このサーバーが Master サーバーになります。また、新たに追加する MySQL サーバーを「B」と呼ぶことにして、このサーバーを Slave サーバーとして運用します：


1. Slave 用 MySQL サーバー環境の構築（B)

Slave サーバーとなる新しい MySQL サーバー環境を構築します。この辺りを参照してください：
CentOS に MySQL をインストール／セットアップする

Slave 側にも MySQL 環境が構築できたら、mysql コマンドでレプリケーションを行う先のデータベースを作成しておきます。UTF-8 指定などは環境に合わせて適当に：
mysql > create database mydb character set utf8;

2. レプリケーション用ユーザーの作成（A）

MySQL コマンドを使って Slave が Master のバイナリログを参照する際に接続するユーザーを作成します。
この例ではユーザー名 repl、パスワード password で、192.168.1.XXX/24 環境からの接続のみ許可されたユーザーとしています：
mysql > GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.0/255.255.255.0' IDENTIFIED BY 'password';

3. Master 用の設定（A）

具体的には Master のバイナリロギングを有効にし、かつサーバーを識別するための ID を /etc/my.cnf 内に追加設定します（MariaDB の場合は /etc/my.cnf.d/server.cnf）：
# vi /etc/my.cnf

[mysqld]
log-bin=mysql-bin
server-id=1001
ここまで設定したら MySQL サーバー（A）を再起動します。


4. レプリケーション用ユーザーの作成（B）

MySQL コマンドを使って Slave 内にデータを複製するユーザーを作成します。この例ではユーザー名 repl、パスワード password としています：
mysql > GRANT ALL PRIVILEGES ON *.* TO 'repl'@localhost IDENTIFIED BY 'password';

5. Slave 用の設定（B）

サーバーを識別するための ID を /etc/my.cnf 内に追加設定します（MariaDB の場合は /etc/my.cnf.d/server.cnf）。この ID はシステム全体でユニークにする必要があるため、3. で設定した内容とは異なるものにします：
# vi /etc/my.cnf

[mysqld]
log-bin=mysql-bin
server-id=1002
ここまで設定したら MySQL サーバー（B）を再起動します。


6. バイナリログ位置の確認（A）

Master 側サーバーの MySQL コマンドで以下を実行して、その結果をメモしておきます：
mysql > FLUSH TABLES WITH READ LOCK;

mysql > SHOW MASTER STATUS;

+----------------------+-----------+--------------+------------------+
| File                 | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------------+-----------+--------------+------------------+
| mysql-bin.000031     |       285 |              |                  |
+----------------------+-----------+--------------+------------------+
この結果の File がバイナリログ名、Position が現在位置です。これらの値は後に使います。

なお、"SHOW MASTER STATUS;" の実行結果が "Empty Set" と表示される場合は、File は ""（空文字）、Position は 4 とみなすことができるので、これらの値を後に使うことになります。

7. スナップショットの作成（A）

続いてこの状態のデータベースのスナップショットを取得します。6. で "FLUSH TABLES WITH READ LOCK" を実行しているのでデータベースにはロックがかかっています。この状態で別のコンソールやターミナルを使って以下のコマンドを実行します：
# mysqldump -u root -p mydb --lock-all-tables > mydbdump.db
これで指定した mydb データベースのダンプを mydbdump.db というファイルに取得することができます。取得後は再度もう一つのターミナルに戻って以下のコマンドを実行し、ロックを解除します：
mysql > UNLOCK TABLES;

8. スナップショットのコピー（AまたはB）

7. で取得したスナップショットファイルを（mydbdump.db）、Slave サーバーとなる B に転送します。SFTP などを使って A から B へ送ってもいいし、B から A に取りに行ってもいいし、全く別の方法でも構いません。スナップショットファイルが B のディスク内にあって、9 のコマンドが実行できさえすればいい、ということです。


9. スナップショットの展開（B）

7. で取得した Master のスナップショットを Slave である B の mydb データベースに展開します：
# mysql -u repl -p mydb < mydbdump.db

10. Master 情報登録（B）

続いて MySQL コマンドで Slave に Master の情報を登録します：
mysql > CHANGE MASTER TO
  MASTER_HOST='192.168.1.XXX',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000031',
  MASTER_LOG_POS=285;
なお、ここで指定する値ですが、MASTER_HOST は A のサーバー名（IPアドレス）、MASTER_USER は複製用（Aの）ユーザー、MASTER_PASS はそのパスワード、MASTER_LOG_FILE は 6. で取得した File の値、MASTER_LOG_POS は同 Position の値です。


11. レプリケーションスタート（B）

最後にレプリケーションを開始します：
mysql > START SLAVE;
これでレプリケーションがスタートする、はず。


スレーブを増やして、３台目以降の MySQL サーバーを構築する場合も同様にして行います。


環境によっては「初めから MySQL をクラスター環境で構築する」という選択肢もあります。そういう場合はこちらを参照してください：
CentOS に MySQL クラスター環境を構築する


タグ ：
#mysqldump
#mysql
#mariadb
#replica
#replication
#slave
#master

IBM Bluemix では IoT デバイスからのセンサー情報を使ったデータフローを定義する Node-RED エディタを提供しています。

特にセンサー情報はそのデバイス機器によって内容やデータフォーマットが異なるため、その内容をデータベースに保存しようと考えた場合はいわゆる NoSQL データベースを使ってテーブルを定義することなく JSON 丸ごと保存、なんてことをやったりします。これはこれで便利ですよね。

ただ保存するまではいいのですが、保存したデータを再利用する際には NoSQL だとクエリーが使えないため、その取り出しに不便に感じることもあります。その解決策の１つとしていったん Claudant に格納したデータを dashDB に複製する、という方法もあります：
Claudant => dashDB の単方向レプリケーション

そのような方法もありますが、もうデータフォーマットがわかりきっていて、NoSQL に格納する理由が特になければ最初からセンサーデータを SQL 型のデータベースに格納してしまってもいいわけです。本エントリではそんな方法のサンプルとして、Node-RED 内で SQL Database(DB2) にセンサーデータを格納する方法を紹介します。


まず Node-RED 側の用意をします。今回はすごくシンプルな形にして、IoT デバイスからのデータを一度整形して、そのままデバッグ出力するだけ、というものです：
2015051901


この中の整形部分（上記の "f" と書かれたノード）の中身は以下のようにしています。メッセージID とペイロードの名前、そして温度情報をそれぞれ ID, MYNAME, TEMP という名前で取り出しています。DB2 側で列名は大文字であることを前提とするため、JSON 側でもここを大文字にすることが肝です：
2015051902


この状態で一度デプロイして動かしてみます。ちゃんと動きますね：
2015051903


デバッグタブの出力内容は（期待通り）このようになっています。この内容を SQL Database のテーブルに格納していきます：
2015051904


では次に Bluemix 側の（SQL Database 側の）準備をします。Bluemix 上に作成した Node-RED プロジェクトランタイムで「サービスまたは API の追加」をクリックします：
2015051905


サービスの一覧から "SQL Database" を選んで追加します：
2015051906


追加が成功するとプロジェクトランタイムの中に SQL Database サービスが表示されます。このアイコンをクリックします：
2015051907


SQL Database の説明画面が表示されます。この中の "LAUNCH" ボタンをクリックしてウェブコンソールに移動します：
2015051908


ウェブコンソールが開いたら、Node-RED からのデータを格納するテーブルを定義する必要があります。そこで "Work with Tables" をクリックします：
2015051909


テーブル作業画面の左側にあるプラスマークをクリックしてテーブルを追加します：
2015051910


画面右のテキストエリアにテーブル作成の DDL を記述します：
2015051911


今回はこのような内容にしました。テーブル名は MYTABLE です：
CREATE TABLE MYTABLE
(
  ID VARCHAR(15),
  MYNAME VARCHAR(20),
  TEMP INT
);


最後に画面下部の "Run DDL" をクリックして、MYTABLE テーブルを作成します。成功すると MYTABLE テーブルが作成され、その定義内容を確認することができます：
2015051912


改めて Node-RED 画面で SQL Database の設定を追加します。ノード一覧の中から左側だけに丸のついた "sqldb"（左右に付いているのは更新用、左側だけのが追加用）を探して、キャンバスにドラッグして追加します：
2015051913


追加した "sqldb" ノードをダブルクリックし、そのサービスとテーブル名を定義します。テーブル名は先ほど作成した "MYTABLE" を指定します：
2015051914


最後にこのようにノードをつなぎます。これでデプロイ！：
2015051915


デプロイが成功するとデバッグタブにセンサー情報が表示されます。同時に SQL Database にも同じデータが格納されているはずです：
2015051916


SQL Database のウェブコンソールに戻り、MYTABLE テーブルの "Browse Data" タブを開くと追加（INSERT)されたレコードが表示されます。センサーデータが直接 DB2 に格納できたことが確認できました：
2015051917


あとは SQL を使って適当にご自由に。










 
タグ ：
#ibm
#bluemire
#nodered
#iot
#db2
#sql
#database

久しぶりのノーツネタです。


ノーツ９のクライアントでカレンダーを開くと、左下にこのようなセレクターが表示されます：
2015051501

ここで選択した形式でカレンダーが表示されます。自分は１週間単位で見ることが多いので、「１週間（勤務日）」で使っていることが多いです。なお「１週間（勤務日）」は月曜から金曜までの５日間を表示（土日は表示しない）、「１週間」だと月曜から日曜までの７日間が表示されます。

最近、自分の勤務が土日も含まれることが多くなってきました。というわけで、勤務用の５日表示では大事な仕事を忘れてしまいかねません。かといって「１週間（勤務日）」を残したまま「１週間」を選ぶのもわかりにくいというか・・・

こんなときこそカスタマイズです！さっそくドミノデザイナーでメールテンプレートを開いて、共有要素 - アウトライン内の NotesCalendarOutline を選択します：
2015051504


その中の「１週間」を書かれたラベルを選択して、ラベルの値を「１週間」から（例えば）「オレの１週間」に変更して保存します：
2015051502


これでノーツカレンダーを開き直すと、「オレの１週間」が選択できるようになり、選択すると７日間分のカレンダーが表示されます。これで安心して週末にも仕事のスケジュール入れられます（涙）。
2015051503




 
タグ ：
#notes
#calendar
#designer
#domino

５月９日～１１日において大阪の朝日放送様主催で行われた ABC ハッカソンに参加してきました：
ABC Hackathon | 朝日放送

このハッカソンは「イベント×IT×モノづくり」をテーマとしたもので、一般的な「プログラミングコンテスト」的な要素は少し薄くなっています。あくまで多くの人が集まるイベントで活用できるハードウェアを作るコンテストであり、そこに IT の要素を組み合わせてイノベーションを起こそう、というものです。なお、この様子は関西地方では朝日放送様のテレビ番組として放送される予定であると聞いています。

私は参加といってもいわゆる「参加者」ではなく、クラウドおよび IoT サービス環境としての IBM Bluemix を利用者に提供したこともあり、その技術サポート要員として参加してきました。

番組の内容に関わることを話すつもりはないのですが、まず参加者の熱意とデバイスのアイデア、そしてそのデバイス（ソフトではなくハード）を３日間で作り上げようとする集中力＆チームワークに感動しました。ハッカソンの規模的にも私がこれまでに参加したハッカソンの中でも最も大規模な開催であったと思います。

そして本戦の中で数社のエンジニアの方をサポートさせていただきました。IBM Bluemix は最初は慣れなくてとっつきにくい環境だったと思いますが、作るモノや利用目的がハッキリしていたこともあり、思いのほか環境に慣れていただくまでも早く、後半ではトラブルがあっても話を一緒に聞いているうちに結局自分で問題を見つけて直してしまう、というレベルにまで達していました。サポート要員として非常に楽でした（笑）。何よりも使って頂いているうちに IBM Bluemix の環境に慣れて、活用されて、応用されていく様子がこちらにも伝わってきて、それが一番嬉しかったです。今後も引き続き IBM Bluemix を活用いただきたく思っています。

そして、実は参加者とだけではなく、他のデバイスや API 提供会社のサポートとして参加されていた方々とも貴重な交流ができました。正直、普段はコンペとなるような関係の会社も参加されていましたが、参加チームの中にはその会社の提供する機能と我々の提供する機能を組み合わせたデバイスを作ろうとする所もありました。我々には思いもよらない使い方でした（苦笑）。ハッカソンに参加されていた皆様は知らないと思いますが、実は主催社チーム同士でもかなり密な交流があったのでした。 (^^; 色々な意味で本当に貴重な３日間でした。


このイベントに参加された方、主催された方、サポートで参加された皆様、お疲れ様でした。そして貴重な機会をありがとうございました。本当に楽しいイベントでした。機会があればまたどこかでお会いしたいです。そしてこのような刺激的なイベントへの参加を認めていただいた自社に感謝します。


 
タグ ：
#hackathon

このページのトップヘ