koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

ランス10-1.1

一週目の感想は↓この記事はメモです。

koudenpa.hatenablog.com


koudenpa.hatenablog.com

の続き。

Game Overは持ち越し? の対象ではないのかな。ロードして進める。

なお、一連のエントリーは普通にネタバレしていきます。


物語の導入部にして、ランスが人間世界の中で特別な存在であることをサラッと示す流れ。

元は一介の冒険者が英雄になるって王道でよい。

f:id:koudenpa:20180223232548p:plain


こんなの、マリスを選ぶしかないじゃん。

f:id:koudenpa:20180223232932p:plain


アールコート他、多数の士官を失ったが~~

どういうことなの。

f:id:koudenpa:20180223233557p:plain

後でイベントで拾われていた。しかし、ネームドキャラの死に方としてはアグレッシブすぎる。「いえーい」を髣髴とさせる。


よい。これよ。英雄のパーティはこうでなくては。

f:id:koudenpa:20180223235815p:plain


攻撃が団子w

f:id:koudenpa:20180224000246p:plain


ゾンビかしら? キャラが増えた懐かしい、と画像をとるのも序盤のうちだけだろうなぁ。

f:id:koudenpa:20180224001005p:plain


現在もアニスさんは行方不明のままです

なんというか、味方ユニットになってもランダムに砲撃してくるだろうという想像しかできない。


こんなんキャラクター選ぶやろ。

f:id:koudenpa:20180224005815p:plain

何で1枚だけしか取れないのだ。

f:id:koudenpa:20180224010102p:plain

HP10%切ってるんだが、どうなるの。

f:id:koudenpa:20180224011139p:plain

シィル必死のヒーリングで生き延びた。2週目は覚えてやがれ。

f:id:koudenpa:20180224011654p:plain

アニスが行方不明になったこと、覚えておきたくなかった。白色破壊光線連射とか困る。

狂気すぎる組み合わせだろう。。。

でも、ランス6では黒色破壊光線を連射していた気がするな。ちがったっけ。

いずれにしても、これは赤選択しかないですね。

f:id:koudenpa:20180224012232p:plain

なお、最後は黒色破壊光線に焼かれました。


To be continue.

ランス10-1

楽しみにしていたランス10をプレイするので、余裕があったら覚書をしながら進めたいと思う。

長い間(といっても6以降からだけれど)追いかけていた、とても思い入れのあるタイトルの完結編なのだ。

硬派ではない(エロゲーだし)けれど、以外にも正統派のハイファンタジーで大好きな作品だ。

ランス君の冒険を見守りたいと思う。 f:id:koudenpa:20180223222702p:plain


マニュアルも事前情報もほどほどにしか読んでいないのでよくわからんけれど、初仲間? はカロリア。 なつかしキャラが出てくるだけでテンションが上がる。

f:id:koudenpa:20180223223818p:plain


ガメオベア。分かっちゃいたけれど、ふつう選ぶだろう。

f:id:koudenpa:20180223230931p:plain

To be continue.


一週目の感想は↓。

koudenpa.hatenablog.com

Azure の サブスクリプション間リソース移動はとても便利だが失敗することもある

ちょっとした機会があって、Azure上のリソースを同一アカウントの別のサブスクリプションに移動した。

Azure Portal上で幾つかのリソースグループを移動させていったのだが「さすがMicrosoftGUIでポチポチで余裕出来る!」と言った感じでなかなか感動した。

f:id:koudenpa:20180221014159p:plain ↑移動ボタンを押して、移動先を選んで、OK、終わり。すごい楽。

そもそも、このリソースグループという管理単位がとても分かりやすく、環境別などの効果的な管理ができてとてもよい。

のだが、動作確認用のリソースグループから移動していって、いざ本命のリソースグループを移動しようとしたところ、その検証でエラーした。

ResourceMoveProviderValidationFailed リソースの移動の検証に失敗しました。詳細を確認してください。診断情報: タイムスタンプ '20180220T111658Z'、 サブスクリプション ID 'x-x-x-x-x'、追跡 ID 'x-x-x-x-x'、要求の相関 ID 'x-x-x-x-x'。 "Code":"Conflict", "Message":"Resource move for 'resourcename' App Service Certificate failed because there are still imported certificates derived from the App Service Certificate in the source subscription. Imported certificates: /subscriptions/x-x-x-x-x/resourceGroups/xxxx/providers/Microsoft.Web/certificates/xxx-JapanEastwebspace","Target":null,"Details":[{"Message":"Resource move for 'resourcename' App Service Certificate failed because there are still imported certificates derived from the App Service Certificate in the source subscription. Imported certificates: /subscriptions/y-y-y-y-y/resourceGroups/yyy/providers/Microsoft.Web/certificates/yyy-JapanEastwebspace"

なじゃらほい。

リソースの移動に関するドキュメントはこの辺りにあり、移動の制限についても書かれている。

docs.microsoft.com

App Service の制限事項

エラーしたリソースグループ内にはApp Service証明書が含まれていはしたのだが、制限にあるアップロードないしインポートした証明書ではないはずなので、なんでエラーするのかイマイチ分からなかった。

メッセージから適当に考えて「証明書以外を移動してから、別途証明書を移動したらどうなるかなぁ」位の当て推量を試行した正常に移動できた。ラッキー。

もし、エラーメッセージでググってきた人がいたらお試しあれ。

Azureのリソースの移動は楽だぞ、というつぶやきと、もしかしたら同じエラーを見る人がいるかも、という理由で書かれた記事でした。

.NET Coreを弄っているとよくあること

使おうと思ったライブラリが .NET Framework 向けのみで .NET Core に対応していない。

これにつきる。気を付けましょう。例えば……

f:id:koudenpa:20180218173117p:plain

依存関係はないといったな? それは嘘だ。

f:id:koudenpa:20180218173145p:plain

パッケージ 'WindowsAzure.ServiceBus 4.2.1-preview' はプロジェクトのターゲット フレームワーク '.NETCoreApp,Version=v2.0' ではなく '.NETFramework,Version=v4.6.1' を使用して復元されました。このパッケージは、使用しているプロジェクトとの完全な互換性がない可能性があります。

ちなみに、下の方にいる WindowsAzure.Storage .NET Core 対応です。 同じ系統の名前なのに!

必ず、依存関係に対応の記載があるライブラリを使用する。 ServiceBus に関しては正解はこちら。

f:id:koudenpa:20180218174835p:plain

余談

僕はただSASトークンでServiceBus Topic の Subscription を作りたかっただけなんだ。

Microsoft.Azure.ServiceBus では、それができない。 というよりは、REST APIではSASトークンでの操作がサポートされていない、かな。多分。

Azure Service Bus 管理ライブラリ | Microsoft Docs

前提条件に、アプリケーションのADアプリとしての登録があって、怪しみは感じた。

(今回は単に自分が面倒だっただけなので、Azureを活用するアプリケーションはADアプリとして登録して、関連サービスを活用できるように認証したほうがいいです。そのADアプリにどんな認可を与えるか? でアプリケーションに対する権限を一元管理できて非常に便利です)

WindowsAzure.ServiceBus では、できる。こちらは、.NET(というよりはWindows)クライアントとして作成されているのだろう。 HTTP以外のプロトコルを使うサービスはライブラリ整備が大変そう。

azure-content-jajp/service-bus-create-topics-subscriptions.md at master · yuesan/azure-content-jajp · GitHub

それぞれのライブラリドキュメントは多分この辺り。

非常に迷いやすいと思うんだよね!

ITエンジニアとしてのちっぽけなプライド

10年以上仕事としてITエンジニアしていると、多少のプライドがあったりする。

なんとなくメモっておく。

  1. ちゃんと読む
  2. ちゃんと動かす

こんなもん。

1. ちゃんと読む

何かしらのプログラムをする際には必ず関連するドキュメントがある。

それは、言語やフレームワークの仕様だったり、関連サービス、システムの仕様や案内だったり、そもそもプログラム対象の仕様だったりする。

当たり前だけれどそれらはちゃんと読む。

2. ちゃんと動かす

自分がエンジニアリングしたものは、自分ができる範囲で動作の確認を行ってから手を放す。

当たり前だけれど作ったものはちゃんと動かす。

事例

仕事をはじめて数年目のころだったと思うのだけれど、BtoBの認証プロキシーサービスのバックエンドで動作するWebシステムの開発に関わったことがある。

これはちゃんと動かす、ということが外部結合テストまでできなかったのだけれど、ちゃんとプロキシーサービスのドキュメントを読んでおいたので、結合時の疎通は無障害で通過した。 (他のチームは疎通まで相当時間かかっているところが多かった)

別に、ドキュメントには大したことが書いてあったわけではない。おぼろげな記憶だけれどこんな感じだっただろうか。

  • 認証されたユーザーの情報がHTTPヘッダに入っている
  • 何だったか忘れたが、公開鍵暗号での暗号文がHTTPヘッダに入っている
  • レスポンスボディを一定のルールで書き換える

そのくらいのことはサラッとやってのけたい、のけてやる、といったところが自分のITエンジニアとしてのプライドなのだ。

サービスレベルについて思ったこと

ConoHaのオブジェクトストレージの特定のオブジェクト(https://object-storage.tyo1.conoha.io/v1/~~)へのHTTPSアクセスをMackerelでURL外形監視してます。

以下の表は去年12月から明けて正月明けの期間のアラートの発生と解消時刻、発生から解消までの秒数をまとめたものです。

アラート内容は全てタイムアウトです。

CreatedDateTime ClosedDateTime OpenSec
2018/1/9 18:13 2018/1/9 19:35 4907
2018/1/8 20:30 2018/1/8 20:48 1068
2018/1/8 20:05 2018/1/8 20:27 1314
2018/1/2 20:50 2018/1/2 21:19 1724
2018/1/2 20:37 2018/1/2 20:47 585
2018/1/2 20:06 2018/1/2 20:34 1673
2017/12/28 20:58 2017/12/28 21:26 1662
2017/12/25 20:38 2017/12/25 20:43 289
2017/12/19 20:08 2017/12/19 20:13 285
2017/12/12 20:04 2017/12/12 20:05 52
2017/12/8 14:33 2017/12/8 14:35 107
2017/12/7 21:58 2017/12/7 22:01 176
2017/12/6 20:03 2017/12/6 20:04 49
2017/12/5 20:03 2017/12/5 20:04 58
2017/12/4 17:33 2017/12/4 17:36 167
2017/12/3 20:03 2017/12/3 20:04 47
2017/12/1 20:04 2017/12/1 20:05 52

この状況について問い合わせたところ、ネットワークは共有なので利用状況に応じてこうしたネットワーク遅延は発生するとのことでした。

これをどう感じるかは人それぞれかと思いますが、自分は今後新規にConoHaのオブジェクトストレージを使用することはないでしょう。

VPSと違ってパブリッククラウドの同種のサービスと比べてコストメリットもほとんどありません。

続きを読む

Node-REDのMackerelノードを作る

この記事は Mackerel Advent Calendar 2017 - Qiita の13日目です。

昨日は hoosoi - Qiita さんの XXX でした。

さて、先日は Node-RED から http request node を使ってサービスメトリックを投げました。

koudenpa.hatenablog.com

API-Key を function node にべた書きするなど相当イケていない形であったことは否定できません。というか、クソ 改善の余地がある実装です。

というわけで、認証情報を秘密にすることを主な目的に Mackerel にサービスメトリックを投げるNodeを作成してみました。

Node-RED日本ユーザ会 : はじめてのノード開発

チュートリアルがあるのでそれに従って作成していきます。

やりたいことは単なるHTTPSリクエストなので、その機能があるノード参考にし パクって作成しました。

github.com

続きを読む