my cognition

Cognitiveはよいぞ。電波伝搬はよいぞ。

SF5 AEの有志による調整内容まとめ (thanks @DEADACEBS !!)

ソースはこちら。thanks to @DEADACEBS!! https://twitter.com/DEADACEBS

https://www.youtube.com/watch?v=sb1WiQyWLfQ

いぶき

  • 画面中央のTCがEXクナイのあとつながらなくなるように
  • 空中タゲコンが今より距離を離すように
  • ボム後に補正切りできなくなるように
  • 全ての攻撃が空中追撃を1回のみに

かりん

  • 画面端の投げハメなくなりました
  • 立中K発生7→8F、ガード時-2→-4 
  • 立強K発生10F→12F
  • 立強Pがクラカンするように(?)

バルログ

全体

  • 全てのコマンド投げでスカりの際に15~20Fのスキができるように

通常攻撃

  • しゃがみ強K(c.HK)がカウンターになりやすく
  • 前投げ後の距離が離れ、画面端の投げハメがなくなりました
  • V-Skill 変更点不明。噂レベルは以下の通り。
  • Vスキルで波動抜けするとVメーターが上がるように
  • Vスキルがゲージがたまりやすく
  • 回転中の動きが長く

ターゲットコンボ

  • ターゲットコンボ->Vスキルが、爪有り無しに関係なくVトリガーキャンセルできるように
  • 爪状態 強P強P Vトリガーキャンセルが、ヒット時限定でCAキャンセルできるように。

必殺技

  • 弱クリムゾンテラーがヒット時に距離が離れるように

Vトリガー

  • Vトリガー1が地上、空中ヒットで打ち上げ効果がつき、EXフライングバルセロナアタックで追撃できるように
  • しゃがみ強K > Vトリガー2キャンセルが最速で+1
  • バスタークロー > Vトリガー2キャンセルで有利、(後半の意味はわからず)
  • Vトリガー2のキックが発生15Fよりも遅いかも(強Pオーロラより遅い)
  • 爪屈中P > Vトリガー2キャンセル > 屈中P > Vトリガー2がつながる
  • Vトリガー2発動の停止で強Pオーロラ対空ができるように
  • Vトリガー2が画面中央からの強Pオーロラで拾える位に遠くに飛ばすように(訳注:日本語が怪しい) *(ここでバルログの内容諦めた)

豪鬼

  • 前強Pがガード-2
  • 画面端での前投げが+6ではなくなった。が、有利ではある
  • EX昇竜 > Vトリガーキャンセルが受身可能に
  • ジャンプ中Pが追撃可能に
  • 昇竜 > CAがコンボにならないように
  • Vトリガー1中の残空波動が4つまでに

チュンリー

  • 前強Kクラッシュカウンター始動からのダメージが上がった
  • 空中百裂脚ヒット時+4で屈弱Pがつながるように
  • 気功掌の初段が-2、その他のミニ気功掌が+2で、攻撃的に立ち回れるように
  • EX百裂後の状況がより良く。画面端の気功掌を交えた起き攻めがとてつもなく良い

ララ

  • Vトリガーゲージが3本になった代わりに、VT1が31秒続き、Vトリガーゲージの消費行動をしない限り、Vトリガー状態が継続
  • Vトリガー1中、中段攻撃がヒット時+4、最終持続で+7、最終持続のガードが-3
  • 立中Kの発生6F→7F

ベガ

あまりに多いので既に翻訳してあるものを参照ください・・・

バイソン

  • 全てのレベルのターンパンチがガード時-2で、レベル4以上でないと打撃無敵が付与されない
  • 立強Kクラッシュカウンター> 歩き屈強Pが、ヒット後の距離の関係でつながらなくなるように
  • 屈中K > 屈中K (ストンプコンボ) > Vトリガーキャンセルがガード時-1or-2
  • Vトリガー1の派生をガードした際、距離がより離れないように
  • Vトリガー2は空中で3~4ヒット、地上で2ヒット、スタンゲージ300~

リュウ

  • EX足刀 > EX昇竜で良いダメージ
  • EX足刀は2ゲージ消費

ザンギエフ

  • 弱P後にコンボができなく
  • 弱PからCAまたはVトリガー2にはコンボできる

ユリアン

  • 立強P > 屈強P が繋がらなくなった。ネモさんによるとタメ強Pでは繋がる。
  • 屈強Pの発生7F→8Fで、立弱Pか屈中Pカウンターから繋がらなくなった

キャミィ

  • Vトリガー2はギミックっぽく、VT1より強くない
  • Vトリガーのジャガーキック(?)はガード時不利だが、中段でしゃがみの相手に屈中Pが繋がる
  • Vトリガーグライド > コマ投げ > 屈中K、強Kスパイラルが繋がる

私がTwitterのFavoriteを全て削除した理由と、古いFavoriteを削除する方法。

ご無沙汰しております。私です。

近況

ですが、足を骨折し、だいぶ元気がなくなってましたが、いよいよ完治・・・とまでは行かないですけど、2本足であるけるようになったので元気になりました。 足骨折して、体重も重めなので松葉杖をついて出勤することも出来ず、 ちょっと前までにこんな足の人見たらほぼ間違いなく私です。 f:id:moffumoffu:20171203002158j:plain

Twitterのいいねを削除しました

まずはこれを見てくれ。 f:id:moffumoffu:20171203001356p:plain

そんなわけで、2ヶ月前にこんな告知を出してお気に入りを削除してました。

何故Twitterのいいね(旧 Favorite)を削除したのか

いいねが他人のタイムラインに出るようになったからです。

他人のタイムラインに出るのが嫌な理由

いいねのあて先「ツイート主」であったのが、「ツイート主」+「自分のフォロワー」に変わったからです。

「いいね」はあくまで「いいね」であって、個人の感情を個人に伝えるためのツールだと思っていました。元々、FavoriteとRTで明確にタイムラインに乗せるものと乗せないもので区別をつけており、どちらも満たすものはFav+RTで事足りてました。

ですが、仕様変更でいいいねはこの区別があいまいなものになりました。

いいねを見られることが不快になる

人は不思議なもので、画面に映るようになると、気になるようになります。いいねをした人をたどり、いいねを見ることができるようになります。実際私もたまに見ます。

となると、昔「ツイート主」に対していいねをしたものが、今では「ツイート主」+「自分のフォロワー」に宛てたものと解釈されるようになったと感じます。

そのため、人と人のリプライで笑ったものとか、ゲーム関係のツイートとか、えっちい画像とか、他人に見せたくないけどいいねって思っていたものが見られる可能性が高まり、その状況が不快に思いました。

Twitterのいいねが見える仕様がWebとMobileで違う時期があった

いいねを削除しようと全てのいいねをたどってたときの7月のある日、あることに気がつきました。PC版では表示されず、携帯版では表示される期間があることに気がつきました。

f:id:moffumoffu:20171203010024j:plain ※別のアカウントでつぶやいてた内容なので画像にて

いいねをたどっていただけるとわかるのですが、ハートマークがある期間から白くなっているものがあります。 f:id:moffumoffu:20171203010216j:plain

決定的だったのは、この仕様でした。なんともいえない嫌悪感が発生しました。

古いいいねが削除できない

上記のハートマークが白いものは、いいねを削除することができません。(というよりも、いいねしていない状態と同じように、マウスオーバーするといいねするボタンになっていました。)APIからツイートを指定してUnFavoriteしてもできませんでした。

この状態になったいいねを削除する方法は、「一旦いいねを行い、そのいいねを削除する」という方法でした。しかし、これは他の人にいいねに通知が出まくる行為でありました。

で、結局実行しました。

私の身勝手で、皆様には大変ご迷惑をおかけしました。上記の通知が出るものも含め、約5000件のいいねを全て削除し終えました。 f:id:moffumoffu:20171203011854j:plain

0埋めファイルを作るとき、ddよりもheadが早い!?そんな馬鹿な!?

いきさつ

キッカケは、以下のツイートを拝見したからです。


想定と実行時の違い

脳内イメージでは以下のような感じで、bs=1GBで1回実行のほうが早いんじゃね?って思いました。

f:id:moffumoffu:20170402202113j:plain

しかし、実際にやってみたところ、結果が異なっていました。

そんなわけで、認識とはズレていたので、結局何が早いんだろうというところから、付随して原因までわかったので書きます。

実行環境

  • VMware Workstation 12 Player
  • CentOS 7.2 minimal
    • 割り当てメモリ: 8GiB
    • 割り当てHDD:40GB(事前割り当て)
    • ゲストOS内HDDフォーマット:ext4

結論

大して変わらん!

  • headとddで、0埋めファイルを生成する早さは変わらない
    • 早さに違いがあったのは、ディスクへの書き込みの実行タイミングが、ファイルディスクリプタの変更によってOSに任されたため
      • headでは、OSに任される
      • ddでは、アプリケーションで書き込み完了まで行う
      • OSのI/O処理に依存させないため、時間計測にsyncコマンドを追加した
    • 実体のファイルを作成するので安心
  • 同様の目的を果たすのに、truncateとfallocateコマンドが存在する
    • ファイルの実体は作成されないので、アプリケーションごとにメモリ割り当ての際不都合が発生する場合があるので、オススメできない。
    • 上記2つのコマンドでは、スパースファイルを作成する
    • ファイルを読み出す関数であるread()が呼ばれたとき、仕様として0を返します
    • メモリに割り当てる関数であるmmap()が実行された場合は正直よくわかってません。。。

よく考えたら・・・

リクエストのことすっかり忘れてた・・・

結局、パフォーマンスは変わらないので、/dev/zeroから持ってくる方法であれば、ddでもheadでもいいと思います。(truncateとfallocateは微妙にやりたいことと違う点、また、他にファイル生成の案が出なかったため。)

付記(headとddの違いについて)

  • bsによるメモリサイズの調整は、少なくとも1GB程度のテストファイルでは有意な差は見られませんでした
    • head、dd共に内部では、read関数やwrite関数を呼び出す
      • headでは8KBもしくは4KB単位での操作(bs=8KB,4KBと同等のシステム関数呼び出し)
      • 何万回と呼び出されていても速度に変わりなかった
    • TBなどのスケールだと、チューニングの効果が出るかもしれません

ソースコード

検証に使用したシェルスクリプトを記載しています。汚くてゴメンナサイ。

#!/bin/bash
rm *file -f;

function syori(){
  free -m > /dev/null
  echo 3 > /proc/sys/vm/drop_caches
  free -m > /dev/null
}

#head
echo "------------head---------------"
syori
time bash -c 'head -c 1GiB /dev/zero > headfile;sync;sync;sync'

#dd bs=4MB
echo "------------dd bs=4MiB---------"
syori
time bash -c 'dd if=/dev/zero of=4MBfile bs=4MiB count=256;sync;sync;sync'

#dd bs=1GiB
syori
echo "------------dd bs=1GiB---------"
time bash -c 'dd if=/dev/zero of=1GBfile bs=1GiB count=1;sync;sync;sync'

#truncate
syori
echo "------------truncate-----------"
time bash -c 'truncate -s 1G truncatefile;sync;sync;sync'

#fallocate
syori
echo "------------fallocatte---------"
time bash -c 'fallocate -l 1GiB fallocatefile;sync;sync;sync'


echo "------------syuuryou-----------"
syori

実行ログ(一例)

実行結果は、以下の通りです。time関数により計測しています。
十数回ほど実行しましたが、実行結果毎に1秒以上の差は出ませんでした。

[root@localhost tmp]# ./command.sh 
------------head---------------

real    0m5.736s
user    0m0.024s
sys     0m0.465s
------------dd bs=4MiB---------
256+0 レコード入力
256+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 0.872527 秒、 1.2 GB/秒

real    0m6.139s
user    0m0.002s
sys     0m0.425s
------------dd bs=1GiB---------
1+0 レコード入力
1+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 0.653189 秒、 1.6 GB/秒

real    0m5.760s
user    0m0.002s
sys     0m0.550s
------------truncate-----------

real    0m0.011s
user    0m0.000s
sys     0m0.007s
------------fallocatte---------

real    0m0.013s
user    0m0.000s
sys     0m0.007s
------------syuuryou-----------

謝辞

今回の調査に際して、以下の放送でプログラミング生放送コミュニティを利用させていただきました。コミュニティ運営の皆様、そしてコメントをしていただいた皆様、さらに視聴いただいた皆様、ありがとうございました。

live.nicovideo.jp

標準インストールされているWindows ストアアプリが英語表記になってしまう問題とその対処法

はじめに

・当方で対応したのは0x80070057エラーでアップデートが出来なかった場合です。 ・対処法として考えられるものを列挙したので、マイクロソフト社のソースと一緒にご参考とまで。 ・最終的に、原因特定にはいたっていません。 再起動したら直りました。

対処法

対処法に入る前に1点だけ。ストアアプリはWINHTTP通信を使用するため、そこに起因する問題(netsh winhttp proxyや、FW等々)を事前に疑いましょう。

1. マイクロソフト社公式のトラブルシューティングツールを実行する

まずはコレを試しましょう。

Windows アプリのトラブルシューティング ツールを実行する

尚、コレを試すと「アカウントにログインしていません」と怒られました。(間違いなくそうじゃねえ!)

2. アプリの削除、再インストール

以下に示されている通り、PowerShellを使ってアプリの再インストールを行います。

answers.microsoft.com

万が一ストアアプリを常用している場合は、各アプリが保持している設定などがどう扱われるかをご確認ください。

3. なんかよくわからないけど再起動する!!

上記を実行した結果、結局治らなかったのでとりあえず再起動したところ、再起動毎にいくつかのストアアプリにアップデートがかかり、アップデートが掛かったものから英語表記から日本語表記に戻りました。

結論

Windowsの挙動は不思議なものばかりですね。今回は再起動したら直りましたが、再発する可能性も十分に考えられます。

対処の中で、プロキシのログなども確認しましたが、マイクロソフト社サーバーから403の返事が返ってきてたりこなかったりで謎ですし、端末のIEから通常モードのブラウジングではmicrosoft.comに接続できなかったのにInPrivateだと接続できたりと、謎です。

何かご存知の情報があればコメントしていただければ非常に助かります。

参考情報

Preview版での情報なので実施の際はスルーしましたが、Swayに手順が示されています。情報源は以下より。

answers.microsoft.com

社内のフェデレーションユーザーがOffice365にアクセスできない場合の対処法

クライアント端末を見ると、以下のイベントが記録されます。 CertificateServicesClient-CertEnroll

Microsoft-Windows-CertificateServicesClient-CertEnroll

イベントIDは87が記録されます。

結論を書いておくと、セキュリティ上の制約によりADFSサービスへアクセスはできていたんですが、ADFSサービスからの応答を拒否していました。(こんな事例滅多にないみたいで、イベント87の資料が英語でも日本語でも全然無いので参考になれば・・・)

基本的には、下記ガイドの9ページ~12ページに示される認証フローに従い、障害切り分けを行いました。

Microsoft Office 365 自習書 AD FS によるシングル サインオン環境構築ステップ バイ ステップ ガイド https://www.microsoft.com/ja-jp/download/details.aspx?id=28716

今回は、社内ネットワークに当たるので、以下の①~⑨のどこかということになります。(9ページより引用)

f:id:moffumoffu:20170222002014j:plainf:id:moffumoffu:20170222002017j:plain

ADFSサービスのエラー画面は到達するので、①~④のDNS名前解決までは基本的に問題ありません。そのため、ADFSサービスのログを解析しました。フェデレーションサービスが全てダウンしている場合は、以下のトラブルシュートが参考になります。

フェデレーション ユーザーが Office 365 ウェブリソースにサインインしようとすると、ブラウザーに AD FS Web ページが表示されない https://support.microsoft.com/ja-jp/help/2419389/internet-browser-can-t-display-the-ad-fs-webpage-when-a-federated-user-tries-to-sign-in-to-office-365,-azure,-or-intune

Ad FS 2.0 のエラー: このページを表示できません https://support.microsoft.com/ja-jp/help/3044971/adfs-2.0-error-this-page-cannot-be-displayed

ADFSサービスのログは、サーバーマネージャからも見ることは出来ますが、イベントビューワーで見ることも出来ます。基本的に、正常系から異常系全てのログが混在しているので、必要に応じてフィルタをかけましょう。

blogs.msdn.microsoft.com

ADFSサービスにアクセス ( https://login.microsoftonline.com/ から、メールアドレスを入力した後に表示されるの画面にたどり着いた際)した場合、ADFSサーバにリクエストの受信、リクエストの検証、レスポンスの送信という3つのログが出力されるので、それを元にアクセス元IPなどの情報を集めます。 (メールアドレスを tesutodayo@contoso.com みたいに出鱈目なユーザIDを指定してあげると、ログの解析が楽になります。)

ここでエラーログが出力されていなければ問題ありません。事実、サーバーは「俺は正常にレスポンスを返したぞ」と主張しているので、ADFSサービスからクライアント端末までのどこかでレスポンスが落ちたことがわかります。ロードバランサやプロキシサーバなどを介している場合は、そちらのログを追うといいかもしれません。

そんなわけで、問題を切り分けた結果、クライアント端末しか疑いようが無かったため、色々とセキュリティ関連のソフトウェアをオフにして正常に接続が出来ることを確認しました。灯台元暗しというやつですね。

責任範囲ってどういうことなんだろう。とかの話。

今日起こった話なので、忘れないうちに取り留めなく書きます。

  • 事象:結合試験のあるテストが通らなかった
  • 原因:単体設計書に載っていないあるステータスの変更がなされていないことが原因だった

この二点を考えたとき、まず私の中では 過去の設計書にない部分は私の責任ではない という気持ちでした(現行踏襲で設計するということだったので)。

しかし、プロジェクトチーム全体で考えたとき、 お客様に正常に動くものを納品する という立場で考えると、確かに責任範囲は自身にもあるのだと教わりました。

DevOpsの考え方にも似ていますが、 最終的に何を目標にしているか という意識は確かに大事ですし、犯人探しをしても、対外的にはプロジェクトの責任者が負う形なので仕方がない話です。

しかし、つらみを感じる部分として、 設計書に記載のない内容がシステムの稼動に必要である ということの根本原因は、報告がなされていない設計や変更がある ということのはずです。

これは、システム屋さんとしてはどうにもならない部分(だと思う)ので、私一人では小さなことかも知れませんが、なるべく後の人が困らないように、そういったものは全て伝えられるように頑張りたいと思います。

ほんとにInfrastracture as a Codeしたみ高いですよね・・・

そんなわけで、今日は残業をしてつかれました。おやすみなさい。