2017年12月4日月曜日

プライベートの連絡に LINE ではなく Slack に移行した話

概要
環境
なぜ移行したか
LINE を使う上で問題だったこと
移行するのにポジティブな理由
Slack に移行して問題になったこと
最後に

概要

家族の連絡にずっと LINE を使っていたのですが、Slack に移行したのでそのメリットやデメリットを紹介したいと思います
ちなみに移行してまだ 2 週間ほどなので、今後更にメリット、デメリットが分かる可能性はあります (その際は追記でもしようかなと)

この手の記事は他の方もいろいろと紹介しているのでこの記事も参考程度に見てもらえればと思います

環境

LINE アプリ iOS 版 (iPhone5 + mineo Aプラン)
Slack アプリ iOS 版 (iPhone5 + mineo Aプラン)
Slack クライアント macOS 版 (10.13.1)

なぜ移行したか

まず初めにそもそも移行が必須というわけではありませんでした
が、日頃 LINE を使う上で少し問題があり「LINE よりも Slack の方が良さそうなんじゃないか」と思い Slack に移行してみました

移行したと言っても完全に移行したわけではなく、あくまでも家族のやり取りを Slack に移行しただけでそれ以外の友人などとはこれまで通り LINE を使っています

移行する上で問題だったことや逆に Slack になって問題になったことや導入するにあたって問題だったことを紹介したいと思います

LINE を使う上で問題だったこと

まず日頃から使っていた LINE の問題ですがざっくり以下の通りです
(環境によって発生しないケースもあるらしいのであくまで自分の環境での問題です)

新着メッセージ到着時にプッシュ通知が届かないケースがあった (これが一番)
スマホアプリへのログインは 1 アカウント 1 端末しかできない制約がある

それぞれ詳細に説明します

まず 1 つ目のプッシュ通知が届かない問題ですが移行理由としてはこれが一番大きかったかなと思います
いろいろと症状や原因を調べてみると他の人も同じようにプッシュ通知が届かないケースがあり自分だけではないということがわかりました
原因の 1 つに回線や端末、またその組み合わせ等の問題があるようで、もしかすると自分の環境 (iPhone5 + mineo、この環境は家族も同様) が悪かったのかもしれません
アプリを再インストールしたり再ログインをし直したりしてみましたが症状は解消されませんでした

プッシュ通知は届かないわけではないのですが、アプリを開かないと届かないというケースがかなり多かったです
誰かにメッセージを送らないとと思い LINE アプリを起動すると「ブー」と言ってプッシュ通知が届きメッセージを見ると昨日や一昨日のメッセージだったなんてことが結構ありました

リアルタイムで受け取りたいのに、プッシュ通知が届かないとそもそも LINE を使っている意味がないかなーと思った感じです

そして 2 つ目の 1 アカウントでログイン可能なスマホ端末は 1 台までという制約ですがこれも大きな理由の 1 つです
そもそもこの問題がなければ別のスマホに LINE アプリをインストールしてそっちでプッシュ通知を受け取ることができたかもしれません

ご存知の通り Slack アプリではこの制約はありません
いろんな端末に Slack アプリをインストールして 1 つのログインアカウントでそれぞれの端末にログインすることができます
もちろんメンションやチャネルに新規メッセージが来た場合は Slack アプリをインストールしたすべての端末にプッシュ通知が届いてくれます

という感じで LINE で起きていた大きな 2 つの問題は Slack さんを使えば解決できるということが分かり移行した感じです

移行するのにポジティブな理由

上記はネガティブな理由ですがポジティブな理由もあります

作業端末の Mac に Slack クライアントが常駐している
「xx is Typing」の機能が便利
Bot やスラッシュコマンド、拡張絵文字が使える

簡単に詳細を説明します
1 つ目の Mac のクライアントが常駐しているというやつですが自分の場合、普段から Slack をプライベートで使っています
そこに家族チャネルを作ってやり取りするようにしました
なので、家族用のチームを新規で作成するということはしていません
メッセージのプッシュ通知はスマホにも届きますが、Mac のクライアント側にも届きます
作業中は主には Mac とにらめっこしているので返信もそのまま Mac でできます
返信のためにわざわざスマホでアプリを起動する必要がないので楽です
クライアントアプリって話であれば LINE にも Mac 用のクライアントアプリがあるのでそれを常駐させれば良いだけという話ではあるのですが、それだと自分しか解決に至らないのでダメでした

2 つ目の「xx is Typing」は LINE にはない機能で普段家族とメッセージをやりとりするのに必須だとは思っていませんが、あると意外と便利だということに気が付きました
LINE の場合たまーに返信が早すぎて話が前後することがあったのでそれを回避することができます
これは心理的な問題でもあるので必須ではないですが個人的にはあったほうがやりやすいなと思いました

3 つ目の Bot やスラッシュコマンド、カスタム絵文字ですがこれも Slack にしかない機能かなと思います
今のところ家族 Slack で Bot やスラッシュコマンドが必要なケースはほとんどありませんが、今後使っていこうかなと思います (後述)

ポジティブな理由はそんな感じです

Slack に移行して問題になったこと

では逆に Slack に移行して問題になったことを紹介します

スタンプがない
Slack のアカウント取得からアプリの設定をやってあげないと導入は厳しい

それぞれ詳細に説明します
1 つ目のスタンプ問題は言わずもがなかと思います
Slack には絵文字の機能があるのでそれで代用することは可能です
可能ではあるのですが完全に代用というわけにはいきません
絵文字がない場合、普段スタンプのみの会話で済んでいたのが、スタンプがないために文字の会話にせざるを得ません

また、例えば家族用に自分で頑張ったスタンプがある場合にも使うことができません
どうしても使いたい購入したスタンプがある場合も同様です

ただー Slack には Bot やスラッシュコマンドの機能がありこれらを使えば「スタンプっぽいこと」を実現することは可能です
ご存知の通り Slack には画像の URL を投稿するとそこから画像を取得してポストしてくれるという機能があります
これを使って画像をスタンプを配信するサーバなり Bot を構築してあとはそれらを GET するスラッシュコマンド or Bot のコマンドを作成すれば OK です
自分も今試し中なのでやり方や使い勝手が分かれば別記事で紹介したいと思います

そして 2 つ目のアカウント取得ですが、これはやって上げることをオススメします
家族のみんながネットリテラルがある程度あり「Slack アカウント取得したら教えて」というレベルのお願いでやってくれるのであれば何ら問題はないですが「Slack？は？」「アカウント取得？は？」という感じなのであれば正直全部やってあげるのが最善だと思います
もちろん言葉でやり方を説明してやらせることは可能ですが、それでも難しいと思います
いずれやってくれるかもしれませんが導入障壁を上げるだけなので素直にやってあげましょう
メールアドレスの認証はさすがにやってもらうしかないので「自分のアドレスに確認の URL が届いてるからちょっとタップしてもらえる」と言って一緒に画面を見ながらやってもらいました
あとは好きなチームに invite して家族チャネルに invite してあげれば OK かなと思います

たぶん家族 Slack を導入するにあたっての一番の障壁はここだと思うので頑張ってやってあげましょう

最後に

家族の連絡を LINE をやめて Slack に移行したので、そのメリット、デメリットを紹介しました
今のところ問題なく使えているので今後も Slack でやっていこうと思っています
たぶんフリープランだけで事足りると思います
過去のメッセージを全部辿りたい場合やたくさん Bot を入れたいなどあれば別ですが、まぁないと思います

今後も使い続けて更に何か分かればまた紹介したいと思います

2017年11月18日土曜日

「ぶた忍者」アプリサポートページ

概要
アプリ
プライバシーポリシー
- 広告 ID の利用について
リリースノート
- v1.11
- v1.10
- v1.9
- v1.8
- v1.7
- v1.6
- v1.5
- v1.4
- v1.3
- v1.2
- v1.1
- v1.0

概要

このページは「ぶた忍者」アプリのサポートページです
機能改善、バグ報告、各種問い合わせはこちらのコメントまたは Twitter にてご連絡お願いします

アプリ

iOS 版･･･https://apple.co/2yShowP
Android 版･･･提供なし

プライバシーポリシー

広告 ID の利用について

ぶたスラッシュ (以下本アプリ) では Admob を使った広告配信をしております。そのため広告 ID と呼ばれる識別情報が使われております。本アプリでは広告 ID は主に広告の配信と Firebase を使った Analytics での情報収集に利用しております。本アプリの主な機能としては使っておりません。収集データはクラウドに収集され厳密に管理されます。個人で管理するデータベースやサーバでは収集しておりません。各クラウドサービスのプライバシーポリシーは以下を御覧ください。

Admob のプライバシーポリシーについてはこちらを御覧ください。
Firebase Analytics のプライバシーポリシーについてはこちらを御覧ください。

リリースノート

v1.11

細かい修正を行いました

v1.10

スプラッシュスクリーンの表示を廃止しました

v1.9

インターステイシャル広告を廃止しました
ゲーム終了時にバナー広告を表示します

v1.8

スプラッシュスクリーンを修正しました

v1.7

手裏剣の調整をしました

v1.6

iPhoneX 系のデバイスでのバグを修正しました

v1.5

iPhoneX, Xs, XsMax, XR に最適化しました
iOS10 以上のみサポートするように変更しました

v1.4

レート機能を追加しました
これでだいたい完成です

v1.3

ステージ 5 から 8 まで追加しました
遊び方の説明ページを追加しました
登場する敵、アイテムの一覧を確認できるページを追加しました

v1.2

新ステージを追加しました
ステージ 2, 3, 4 で新たに Level16 まで遊べます
ステージ 5, 6, 7, 8 も今後追加予定です

v1.1

Exp が正常に表示されないバグを修正しました

v1.0

リリースしました

2017年8月24日木曜日

「ぶたもり2D」アプリサポートページ

ぶたもり2D の LINE スタンプが登場しました！

概要
アプリ
攻略動画
リリースノート
- v1.22
- v1.21
- v1.20
- v1.19
- v1.18
- v1.17
- v1.16
- v.1.15
- v1.14
- v1.13
- v1.12
- v1.11
- v1.10
- v1.9
- v1.8
- v1.7
- v1.6
- v1.5
- v1.4
- v1.3
- v1.2
- v1.1
- v1.0
プライバシーポリシー
- 広告 ID の利用について

概要

このページは「ぶたもり2D」アプリのサポートページです
機能改善、バグ報告、各種問い合わせはこちらのコメントまたは Twitter にてご連絡お願いします

アプリ

iOS 版･･･http://apple.co/2wGgBl5
Android 版･･･提供なし

攻略動画

Youtube で攻略動画を公開しました

他のステージの攻略動画もあります
ぶたもり2D 攻略動画

リリースノート

v1.22

細かい修正を行いました

v1.21

スプラッシュスクリーンの表示を廃止しました

v1.20

インターステイシャル広告を廃止しました
ゲーム終了時にバナー広告を表示します

v1.19

土台の当たり判定のバグを修正しました

v1.18

コインボーナスの交換に必要なコインの枚数を大幅に減らしました
黄色のぶたが結合できる条件を修正しました

v1.17

ぶたの当たり判定を修正しました
青ぶたが重なるバグを修正しました

v1.16

お手本の動画を表示する際のバグを修正しました

v.1.15

UI の修正をしました

v1.14

ゴールドの条件の文言追加

v1.13

iPhoneX, Xs, XsMax, XR に最適化しました
iOS10 以上のみサポートするように変更しました

v1.12

スコアの計算方法にバグがあったので修正しました
タイトルロゴに文字枠を付与しました

v1.11

スプラッシュ画面を追加しました

v1.10

タイトルのロゴをポップな感じに変更しました
効果音を追加しました

v1.9

iPhoneX に対応しました

v1.8

すべてのログインボーナスを実装しました
すべてのコインボーナスを実装しました
次のバージョンで iPhoneX 対応します、すいません

v1.7

初級、中級、上級ステージを 9 つまで増やしました
コイン制度を導入しました
コインで交換できるアイテムを 3 つ (タイトルレインボー、ログイン、称号) を解放しました
またリファクタリングしました

v1.6

超上級を解放しました
初級、中級のステージを追加しました
コイン制度を導入しました
リファクタリングしました (xcode9 対応)

v1.5

iOS8 以上の端末で動作するように対応しました
タップ時のぶたを落下させる挙動を調整しました

v1.4

ボーナス一覧画面で回数が正しく表示されないバグを修正しました
遊び方からプライのお手本動画を表示できるようにしました
インタースティシャル広告をぶっこみました

v1.3

上級ステージを追加しました
ログインボーナスの要素を追加しました (ストック機能)
※ボーナス一覧で「ストック機能」の達成回数が 7 日になっていますが正しくは「14」の間違いです
実際は 14 回ログイン後に解放されます
次バージョンにて修正予定です

v1.2

データの保存方法を UserDefaults から Realm を使うように変更しました
これでアプリをバージョンアップした際にデータがクリアされないようになりました
タイトルにログインボーナス一覧へのツールチップを配置しました

v1.1

ログインボーナス機能を追加しました
物理エンジンのチューニングを行いました
App プレビューを更新しました
Firebase/Analytics を導入させていただきました

がこのバージョンにアップデートするとスコアが 0 にクリアされてしまうバグが確認されています
現在修正中で次のバージョンからデータがクリアされなくなるため、現在のバージョンでプレイしたデータも次のバージョンにアップデートしたときにクリアされてしまいます
申し訳ございません

v1.0

リリースしました
ステージは中級まで遊べます

プライバシーポリシー

広告 ID の利用について

Admob のプライバシーポリシーについてはこちらを御覧ください。
Firebase Analytics のプライバシーポリシーについてはこちらを御覧ください。

2017年8月10日木曜日

Firebase のリアルタイムデータベース + iOS で「could not cast value of type __NSArrayM」が発生した

P.S 2017/08/15
概要
環境
Firebase の挙動がおかしい、、、
これは仕様なのかバグなのか
最後に

P.S 2017/08/15

公式に質問したところ回答をいただいたので記載します
日本語で質問したんですが、日本語で丁寧に回答いただきました (ありがとうがございます)
一応回答をブログで公開して良いという了承も得ています
結論としてどうやら今回の現象は仕様のようです

開発ご担当者様

お世話になっております。

> リアルタイムデータベースで json 情報を登録する際にキーが数字の json を登録しました 
> コンソール上では問題なく数値のキーとして登録されているのですが、コンソールから json をエクスポートすると null の配列としてエクスポートされてしまいました 
> この現象がバグなのか仕様なのかを知りたいです 

こちらの現象は仕様となります。
キーに文字列が含まれている場合、JSONで返却されます。
数字キーの半分以下に対して、数値が有る場合、ArrayではなくJSONで返却されます。
数字キーの半分以上に対して、数値が有る場合、Arrayで返却さます。

以下に例を記載致します。
例：（screen1.png）
Rand5の中に、登録されているキーは 1,2,5 となっています。最大の数字は 5 であり、すべてのキーは0,1,2,3,4,5（６個）になります。半分のキー（3/6）が登録されているため、Arrayで返却されます。
Rand6の中に、登録されているキーは 1,2,6 となっています。最大の数字は 6 であり、すべてのキーは0,1,2,3,4,5,6（７個）になります。しかし、半分のキー（3/7）が登録されていないため、JSONで返却されます。

詳細資料は https://firebase.googleblog.com/2014/04/best-practices-arrays-in-firebase.html にご参照くださいますようお願い致します。

> In particular, if all of the keys are integers, and more than half of the keys between 0 and the maximum key in the object have non-empty values, then Fire> base will render it as an array. This latter part is important to keep in mind.

また、他にご質問ございますたらご連絡くださいますようお願い致します。
以上、よろしくお願い致します。

公式のブログで紹介していたんですね、、、
さすがにたどり着けませんでした

概要

Firebase のリアルタイムデータベースからデータを取得して Swift 上で処理しようとしたらタイトルのエラーが発生しました
結果的にプログラム側ではなく Firebase 側の挙動 (仕様?) がおかしいということが判明したので紹介します

環境

Firebase (2017/08/10 時点)
Xcode 8.3.3 (8E3004b)

Firebase の挙動がおかしい、、、

どういう挙動かというと本来インポートしたい json データが Firebase にインポートされると null として扱われてしまうという現象になります

実際に確認してみました
まず 2 つの json ファイルを用意します

cat success.json

{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "9" : [ "i" ],
        "20" : [ "" ]
}

cat fail.json

{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "9" : [ "i" ]
}

数字をキーに持つ単純な json ファイルです
値には配列で文字列を持っています

これを Firebase のコンソールからインポートしてみます

success.json

fail.json

はい、コレだけ見るとどちらも予期したとおりにデータが入っています
ちゃんと数字のキーがありその中に配列情報が格納されています
Firebase では配列情報に自動でインデックスが振られるのは仕様です

で、ここからが問題なのですが、そのままコンソールでそれぞれの json をエクスポートしてみましょう
ここでエクスポートできる json は API で取得できる json のフォーマットと同じデータになります

するとなんと

cat success-export.json

{
  "5" : [ "a" ],
  "6" : [ "b", "c", "d" ],
  "7" : [ "e", "f", "g" ],
  "8" : [ "h" ],
  "9" : [ "i" ],
  "20" : [ "" ]
}

cat fail-export.json

[ null, null, null, null, null, [ "a" ], [ "b", "c", "d" ], [ "e", "f", "g" ], [ "h" ], [ "i" ] ]

fail-export.json になぞの null 文字が連なっています！
本当は success-export.json みたいにハッシュでキーが数値で値が配列でエクスポートしてほしいのですが、なぜか配列でかつ null が並んでいて、その後に値の配列が並んだ状態でエクスポートされてしまいます

当然 Swift で取得できる json も上記の null が並んだ json になってしまうのでタイトルの could not cast value of type __NSArrayM が発生していました
本来は NSDictionary で来ることを想定した書き方をしているため該当のエラーが発生します

これは仕様なのかバグなのか

success.json はキーの数字が 5 から 9 と並んだあとに 20 が来ています
fail.json はキーの数字が 5 から 9 と連番で並んでいます
おそらく連番で並んでいるというのが原因 (仕様 or バグ) だと思います

試しに 5 から 8 のあとに 10 を記載したら問題なく json のハッシュ形式でエクスポートできました

cat revised_fail.json

{
        "5" : [ "a" ],
        "6" : [ "b", "c", "d" ],
        "7" : [ "e", "f", "g" ],
        "8" : [ "h" ],
        "10" : [ "i" ]
}

また、10 ではなく a や b などの文字列でも問題なくエクスポートできました
Firebase ではインポートする際の json をリアルタイムデータベースに格納するために自動でフォーマットして格納します
おそらくその際のアルゴリズムで連番の場合には null 埋めするという謎の仕様がありそれに引っかかったんだと思います

ちょっと調べた感じだとその旨が記載されたドキュメントは見つかりませんでした
仕様ということであれば仕方ないので連番を使わないようにするか 05, 06 のように先頭を 0 埋めして登録するしかありません
バグということであれば是非改善してほしいなと思っています

そもそも数値をキーにするなという問題もありますが、、、

最後に

Firebase のリアルタイムデータベースの謎の挙動を追ってみました
おそらく仕様だと思います
が、知らないと完全にハマリます

問い合わせ窓口的なのがあれば問い合わせてみようかなと思っています
結果わからばコメントなどで追記しようかなと思っています

2017年6月27日火曜日

概要

久しぶりの連投です
前回ニフティクラウド DNS に A レコードを追加してみました
アプリケーションで使う場合、手動で毎回 A レコードを登録するのは現実的ではありません
ニフティクラウド DNS の API は AWS の Route53 に互換してるらしいので AWS の Ruby SDK を使ってニフティクラウド DNS が制御できるか試してみました

環境

CentOS 7.3.1611
Ruby 2.3.3p222
aws-sdk-v1 1.67.0

事前作業

ニフティクラウド API のアクセスキーとシークレットキーを事前に取得しておいてください
あとはニフティクラウド DNS に適当にゾーン登録しておくと今回紹介する Ruby のサンプルも動くの良いかと思います

ライブラリインストール

執筆時現在 AWS の Ruby SDK には v1 と v2 があります
今回は v1 を使います
ちなみに v1 は duplicated になっているので、普通に AWS を使う場合は v2 を使ってください
また今回のコードは v2 との互換がないので v2 だと動作しないのでご注意ください

bundle init
vim Gemfile

gem "aws-sdk-v1"

bundle install –path vendor/bundle

グローバルにインストールしても良いですが今回はカレントにインストールします

書き換え

実はそのままでは使えません
ニフティクラウド DNS の API バージョンは 2012-12-12N2013-12-16 となっています
AWS の Route53 のバージョンは 2012-12-12 と 2013-04-01 がありますが、どちらもニフティクラウド DNS のバージョンとは異なります
当然 SDK も 2012-12-12N2013-12-16 のバージョンを受けることができないので、このバージョンを受けれるように修正する必要があります

vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/route_53/client.rb

class Client::V20121212N20131216 < Client
  define_client_methods('2012-12-12N2013-12-16')
end

で新しいバージョン用の class を作成します
このコードは行数が少ないので書き換えやすいと思います

cp vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12.yml vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12N2013-12-16.yml

次にバージョン用の API 定義ファイルを作成します
まず既存のファイルからコピーします
そしてファイルを開いて「2012-12-12」の部分を「2012-12-12N2013-12-16」にすべて置換します

vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/api_config/Route53-2012-12-12N2013-12-16.yml
- %s/2012-12-12/2012-12-12N2013-12-16/

エンドポイントの部分もありますが、これも変更しておきましょう

route53.amazonaws.com -> dns.api.cloud.nifty.com

そして最後に Core のコードを書き換えます
名前からしてかなり行数が長いです
606 行目あたりにある operations メソッドを書き換えます

vim vendor/bundle/ruby/2.3.0/gems/aws-sdk-v1-1.67.0/lib/aws/core/client.rb

def operations(options = {})
  if name.match(/V\d{8}$/)
  then
    @operations ||= []
  elsif name.match(/V\d{8}N\d{8}$/)
  then
    @operations ||= []
  else
    client_class(options).operations
  end
end

elsif が追加されています
要するに「2012-12-12N2013-12-16」のフォーマットを受け付けるようにします
これを追加しないと無限ループが起き「stack level too deep (SystemStackError)」が発生します

これで書き換えは完了です
実際に使ってみます

サンプルスクリプト

vim dns.rb

require 'aws-sdk-v1'

AWS.config(
           :route_53 => {
             :endpoint => 'dns.api.cloud.nifty.com',
             :api_version => '2012-12-12N2013-12-16'
           },
           :access_key_id => 'your-niftycloud-access-key-id',
           :secret_access_key => 'your-niftycloud-secret-access-key'
)

r53 = AWS::Route53.new

hosted_zone = r53.hosted_zones.find {|z|
  p z.name
}

ゾーンの一覧を取得するスクリプトです

動作確認

bundle exec ruby dns.rb –path vendor/bundle/

で実行できます
成功すると登録してあるゾーンの一覧を取得することができます

あとは AWS の Ruby SDK のリファレンスを参考にレコードを登録する関数などを呼び出せば動作すると思います
http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/Route53.html
(と思ったんですが、hosted_zone.rrsets.create を実行してみたら Inappropriate XML でエラーになってしまいました、、、)

最後に

AWS SDK Ruby の v1 を使ってニフティクラウド DNS をコールしてみました
ゾーンの一覧の取得はできたんですが、レコードの登録でつまづきました
たぶん同じように SDK を修正すれば動くようになるとは思いますが、ちょっと辛そうな感じがするのでこれくらいにしておこうと思います

2017年6月26日月曜日

ニフティクラウド DNS にゾーン登録して A レコードで名前解決してみる

概要
環境
ドメインの取得
ネームサーバの登録
ニフティクラウド DNS で認証を行いゾーン登録する
A レコードを登録してみる
動作確認
最後に

概要

適当なドメインを取得してそのドメインをニフティクラウド DNS のゾーンとして登録してみます
その後登録したゾーンに対して A レコードを登録してドメインから IP が引けるか試してみます
今回使用するドメインは無料で取得できるドメインにしました

環境

ニフティクラウド (2016/12/25 時点)
- Region: east-1 (Zone: east-12)

ドメインの取得

ニフティクラウド DNS ではゾーンを登録をする際に認証処理があります
要するにそのドメインがちゃんと自分のものであるかどうかを判断します

今回は whois 認証という方式を使うのですがニフティクラウド DNS の whois 認証で使えるドメインは以下の通りとなっています
http://cloud.nifty.com/spec/dns/dns_zone.htm

ここに記載のドメイン以外で認証することはおそらくできないのでここに記載のドメインを取得してください
今回は無料で取得できる「.tk」ドメインを取得しました

もちろん無料のドメインではなく「お名前.com」などのドメインサービスで取得しても OK です

ネームサーバの登録

取得したドメインのネームサーバを設定します
大抵の場合は取得したドメインサービスの機能でネームサーバを設定することができます
ニフティクラウド DNS の場合認証用のネームサーバ 1 台とリゾルバの 2 台のネームサーバを登録します

※画面は自分が使っているドメインサービスのネームサーバの設定画面です

ここで入力しているネームサーバは次のゾーン登録の手順で表示されるので、それを入力します

ニフティクラウド DNS で認証を行いゾーン登録する

ニフクラコンパネにログインして DNS の画面に進みます

DNS ゾーン管理 -> DNS ゾーン登録

でゾーン名に今回取得したドメインを入力します

すると認証画面になります
ここでネームサーバ 3 台の情報が表示されるのでドメインサービス側の設定でネームサーバを設定してください

そして「認証処理を実行する」をクリックするのですが、DNS の伝搬に少し時間がかかるので待ちましょう
ボタンを押しても伝搬できていない場合は失敗するだけなので、何度もトライすれば OK です
自分の場合 5 分ほどかかりました

で認証が完了するとランダムの文字列が付与されたネームサーバは削除してくださいという旨が表示されるので削除してください
問題なくゾーン登録が出来ると一覧画面に表示されます

A レコードを登録してみる

試しにて自分のサーバをドメインで引けるようにしてみましょう
サーバは何でも OK ですがグローバル IP を持っているサーバが良いかなと思います
登録したドメインを選択し「レコード新規作成」を選択します
タイプを A にし必要な情報を入力していきます

ポリシーには「重み付け」と「フェイルオーバー」の機能がありますがとりあえず今回は 1 台なので特に設定しません
問題なければ確認してレコードを登録します

ニフティクラウド DNS の場合、ゾーン登録は無料です
が、レコード登録は有料で 500円/10レコードになっていました
そして 11 レコード目からの 10 レコードは更に料金が発生します
また、先ほど紹介したレコードのポリシー機能は各レコードを追加する毎に料金が発生するようです
http://cloud.nifty.com/price/ep.htm#dns

とりあえずレコードが登録できれば完成です

動作確認

登録したレコードで IP が引けるか確認してみましょう
かつ、ネームサーバがニフティクラウド DNS のものになっているか確認します
確認は Mac 上の dig コマンドを使っています
また、IP の部分は一部情報をマスクしています

dig test.free-registry.tk

; <<>> DiG 9.8.3-P1 <<>> test.free-registry.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;test.free-registry.tk.         IN      A

;; ANSWER SECTION:
test.free-registry.tk.  86400   IN      A       111.xxx.xxx.xxx

;; Query time: 182 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Mon Jun 26 12:15:19 2017
;; MSG SIZE  rcvd: 55

ANSWER SECTION の部分で登録した IP が引けているのがわかると思います

dig free-registry.tk NS

; <<>> DiG 9.8.3-P1 <<>> free-registry.tk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51457
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;free-registry.tk.              IN      NS

;; ANSWER SECTION:
free-registry.tk.       3600    IN      NS      cdns1.nifty.ad.jp.
free-registry.tk.       3600    IN      NS      cdns0.nifty.ad.jp.

;; Query time: 194 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Mon Jun 26 12:16:50 2017
;; MSG SIZE  rcvd: 85

ANSWER SECTION の部分でニフティクラウド DNS のネームサーバが表示されていることがわかると思います

最後に

ニフティクラウド DNS を使ってドメインから IP が引けるところまでやってみました
ゾーン登録をするのに認証処理が必要なのでハマるとしたらそこかなと思います

スペック表を見る限りレコード数に上限はないので、料金さえ払えば無限にレコードは登録できそうです
一応 API もあるのでこれを使えばプログラムからでもゾーンやレコード登録ができると思います

2017年5月5日金曜日

IT の現場における「カスタマイズ厨とデフォルティスト」について考えてみる

GW 何もやらないとまずいのでブログをポストしようかなと
タイトルのことを考えてみました
あくまでも個人的な意見なので異論、反論はあるかと思いますが、、

はじめに
ユースケース
最後に

はじめに

(かなり長文なので読んでいただける場合はご注意ください)

まず一般的にこれらの言葉 (カスタマイズ厨とデフォルティスト) が普段から使われているとは思っていない
(というかこんな言葉は聞いたことがない)
なので、この記事内で定義することにする

まず「カスタマイズ厨」だが

カスタマイズ厨

何でも自分が好きなようにカスタマイズする
代表的なカスタマイズ対象にはキーボードやエディタ、キーバインドがある
カスタマイズすることで効率性を上げる

という感じとする
一方デフォルティストだが

デフォルティスト

何もカスタマイズしない
基本デフォルトの設定を頑張って使う
「慣れ」を武器に効率性を上げる

とする

この記事ではこの 2 つのタイプについての長所と短所を様々なユースケースで考えてみる

そして初めに言っておきたいのはどちらも「正解」だということ
十人十色、それぞれの人にはそれぞれの考え方や、やり方が存在するものである

とは言えいろいろと考えさせられることがあったのでこの機会に考えをまとめて見ようと思った次第です

ユースケース

以下のケースでそれぞれの長所と短所を考えてみる

オフィス
自宅 (プライベート空間)
リモートワーク
コスト

ちょっとコンテキストがバラバラだがいろいろな観点で見つめてみようという感じ

「オフィス」はオフィスです、所謂仕事中の状態
またもう少し具体化するとオフィスでは自席もありかつオープンスペース的な場所で仕事も可能とする

「自宅」はまさに自宅、普段家にいるときを想定している
仕事中とかではなく休日を過ごす空間にいるときを考える

「リモートワーク」はオフィス以外の場所で仕事をしているケースを想定している
例えば自宅で仕事をしたりコワーキングスペースで仕事をしたりカフェで仕事をしたりなど

「コスト」はちょっと観点を変えてお金や時間について考えてみようと思う

他にもユースケースや観点はあると思うが今回はこれらを対象にする

オフィス

基本的に毎日行くオフィスである
自席があることを想定しているので自分の机があり自分のイスもあるものとする
朝来たらまず直行する自席である

おそらく王道と思われるこのケース
正直このケースのみにしか該当しない場合には「カスタマイズ厨」一択だと思う
一択というかカスタマイズしまくっても何ら問題ないという感じだろうか
(ここで「問題」という表現をしているが自分は少なからずカスタマイズしすぎることに問題を感じている、そのあたりは別のユースケースも踏まえて後述しようと思う)

例えば自分がもっともタイプしやすいキーボードを持ってきてそれで作業してみよう
会社で支給された謎の PC よりかは数段作業効率があがると思う
また、マウスやモニタもそうだ
モニタは追加してデュアルモニタにすれば更に便利になるだろう

自分もかつて HHK を使っていた
静電キーボードはタイプ時に力もいらず押している感がすごいので、気持ちよくタイプできる
これらは所謂周辺機器のカスタマイズ

更にマシンがオフィスで 1 台だけであるならば好きなエディタやアプリをインストールしてカスタマイズしても良いと思う (というか当然すると思う)
設定ファイルをいじってゴリゴリにカスタマイズして自分しか操作できないような環境を作ることもできると思う
もちろん専用機なのだからそうしても問題ない

こんな感じでオフィス固定の場合は何ら問題なくカスタマイズすると思う (自分もそうするだろう、たぶん)

一方、デフォルティストだが、このユースケースでは正直カスタマイズ厨に勝てる点はないと思う
勝てる点がないというかメリットを得るチャンスを放棄しているという感じだろうか
(そもそもカスタマイズしないので放棄も何もないが)

ただ、一つカスタマイズ厨が効果を発揮できないシーンが会議や打ち合わせである
つまり PC を持ち運ばなければいけないシーンである

せっかく接続した接続機器をすべてはずして PC を持ち運ばなければならなくなる
最近だと Bluetooth を使った無線の周辺機器は増えているのでそれを使うことで物理的に外すという行為はショートカットできるが問題はそこではない
周辺機器がなくなることでデフォルトのキーボードを叩かなければならないことである

要するに今まで快適に作業できていた環境がなくなってしまうのである
これは痛い、急に生産効率が下がるのである
とは言え数十分の会議中だけなので、そこまで問題にはならないと思うが
もちろんベストなのはデフォルトのキーボードでもパシパシタイプできることだと思う

このままだとオフィスのところですべて書ききってしまいそうなので次にいく

自宅 (プライベート空間)

これも正直カスタマイズ厨のほうがいいと思う
いやむしろオフィスよりもカスタマイズ厨であることが良いと思う
オフィスの自席に比べてプライベート空間だと更に移動する機会が少ないためである

現に自分も自宅では Mac Book Pro をクラムシェルにして Bluetooth の Magic Keybord と適当なマウスを使って使っていたことがある
ディスプレイも 32 inch の大きいのを使えてかつ、周辺機器は全部無線なのでどこでもカスタマイズした環境で作業できるようにした
ただ、当初は喜んで使っていたが結局 Mac Book Pro 1 台を使いまわす生活に戻った

というのも他の周辺機器や HDD をマシンにつないだり、モニタを別のものマシンやデバイスで使いたい場合に差し替えたりするのが面倒になったからだ
Mac Book Pro にはモニタもキーボードもトラックパッドもデフォルトですべて付いているのである
新型 Magic keyboard のタイプ感が結構好きだったんだが、結局それもデフォルトのキーボードに慣れてしまえば全く不自由はなかった

ということで自分は自宅でもデフォルトの状態で Mac Book Pro を使っている
リビング以外の場所で作業したい場合は、それ 1 台を持ち運べばいいだけなので簡単だ
Mac Book Pro の場合はバッテリーも結構持つのでバッテリーも持ち運ぶ必要はないと思っている (なくなりそうな場合はバッテリーのあるリビングに戻ってきている)

リモートワーク

さて、少し視点を変えて考えてみたい
次はリモートワークという視点で考えてみる

先に言っておこう、もしあなたがリモートワークをしている、もしくはこれからリモートワークをするのであれば少しづつでもいいからデフォルトの環境に慣れておくことをオススメする

リモートワークの定義は様々だが簡単に説明すると「いつでもどこでも好きな場所で働くことができるワーキングスタイル」である
最近日本の企業でも Web 系を中心に取り組んでいる企業が多いと勝手に想像している

前提としてリモートワークを 100%、365 日やっているわけではなく 1 ヶ月に 4 回、週に 1, 2 回ほど出社することを前提に話を進める
もしくは週に 1, 2 度は自宅ではなくコワーキングスペースやカフェなどで働くことを前提に進める

個人的にリモートワークの良い点は「どこでも」かなと思っている
要するにインターネット環境とマシンが 1 台あれば「どこでも」仕事ができるのである
そんな素晴らしくシンプルな条件でありながらもしカスタマイズしまくっていたらどうなるだろうか
キーボード 1 つくらいなら問題ないかもしれないがそのうち移動するのが嫌になってくるだろう
せっかく「どこでも」仕事ができるのにそれを有効活用できなくなってくる

デフォルティストの場合はどうだろうか、基本的に周辺機器はなく PC を基本的に 1 台持ち運ぶだけなので、リモートワークのスタイルには適していると思う
また、(リモートワークとは少し関係ないかもしれないが) 環境が変わった時によくあるケースとしてマシンの配給があると思う
その際に自分なりのキッティングを必ず行う必要があると思うがその点についても触れておきたい

キッティング

環境によっては、オフィスで使用していたマシンをそのままリモートワークで使用できるケースもあると思うが、大抵の場合は専用のマシンを配給されると勝手に想像している
これはもしかしたらリモートワークに限った話ではないが要は新しいマシンを配給され、それをキッティング (セットアップ) する必要が出てくる
その場合に使い慣れていたマシンと同じ設定をまたやらないといけなくなる

最近だと Mac であれば Homebrew、Windows であれば Chocolatey などがあるのである程度簡単にはセットアップできるようにはなった
またそれらでカバーできない範囲や config 系のファイル (.emacs や .vimrc など) は git で管理しているのでそれを wget するだけというようにしている人もいると思う
が、それでも限界はある、ブラウザの設定や GUI 上で行う設定はどうしても手動でやる必要が出て来る

これは正直デフォルティストであってもある程度設定する作業は出てくると思う
大事なのはその時間をいかに短くするかだと思う
ほぼデフォルト設定でいい場合には設定やインストール作業も最小限で済むのですぐに別のマシンに移行できるのである
それがどうだろういろいろとカスタマイズしなければ全く作業にならない人だと中々マシンの移行ができず 1 ヶ月 -> 2 ヶ月と過ぎ結局挫折してしまわないだろうか
これは非常によくない「習慣」だと自分は思っている

移行できず古い環境を使い続けると OS などのバージョンも古いバージョンを使い続けることになる
バージョンアップの大抵の目的は機能追加とセキュリティ強化だろう
macOS も半年から一年に一回はバージョンアップがある
そういったケースでバージョンアップできないほどカスタマイズしているとどんどん新しいバージョンを導入できなくなりセキュリティ的なリスクも高まったくるのである
もちろんセキュリティ以外の問題もあるとは思うが、要するにバージョンアップできない環境やマシンを移行できない環境を作るのは問題だと思う
(ただ、新しいマシンを積極的に導入することが一概に正しいということではないと補足しておく)

コスト

最後にコストについて考える
ここまでいろいろ話す中でコストについても話をしたのでほぼ話すことはないが要するに

デフォルティスト･･･セットアップ作業などにかかる時間は少なくかつ周辺機器なども必要としないため金銭的なコストもかからない
カスタマイズ厨･･･移行時のセットアップが大変、かつお気に入りのキーボードなど環境に数だけ必要になるため金銭的コストが大きい

となることがわかると思う
これについては想像通りだと思う

最後に

そろそろ疲れてきたので終わりとしたい

冒頭にも述べたが結局どちらが勝ち負けという話ではない
結局コーディングをする上ではタイプしやすい、ストレスなく長時間コーディングできる環境が必要だし、オペレーションではミスしない環境が必要になってくる
事務作業でもタイプが速いほうが仕事が早く終わるのでそれに越したことはない

結局どちらにしても安全かつ丁寧に、疲れず作業できる環境が整うのであればどちらでも良いということになると思う
リモートワークにしてもオフィスにしても結局仕事をする上でのゴールは同じである
なので、どこで仕事をしても最も効率的に仕事ができるのであれば、好きなところで働けば良いと思う
それがデフォルティストとカスタマイズ厨の話にもそのまま当てはまるのである

ただ、個人的な意見としてはデフォルティストのほうが良いと思っていて、その要因として実体験も踏まえると以下がデフォルティストのほうが良いと判断しているポイントである

PC 1 台あればどこでもベストなパフォーマンスが発揮できる
移動が楽
設定が楽
最新マシンに交換できるチャンスがあれば真っ先に手を挙げることができる

かなと思う
自分はこれらに魅力を感じたがそうでない場合には別にデフォルティストになる必要はないと思う

そして、ちなみに自分は完全なデフォルトティストではなく「デフォルティストになりたいカスタマイズ厨」という感じかなと
最低限のエディタの設定はしたいし最低限のソフトウェアのインストールは絶対したい
が、その作業を限りなく最小限にしているので、どんなマシンに移行してもとりあえず短時間でセットアップできる
必要なソフトウェアだけインストール、設定されてできればすぐにベストなパフォーマンスで作業ができることを心掛けている

「断捨離」ではないが極力使わないものや無駄なもの・ことを排除する的な考えが個人的に好きなので、そういう意味でもデフォルティストよりなのかもしれない

登録: 投稿 (Atom)