Xiaomi Redmi note 3 proとMi band 2を買った話

potproject.net Advent Calendar 201611日目の記事です。

やべえあと1時間しかない何書こう


Xiaomi Redmi note 3 proを買いました。結構前に。

で、1.5カ月ほど使ってみてのレビューです。中華製品は最初にレビューしても、実際のところ1カ月で壊れたりするので、買ってすぐにレビューせず1カ月間寝かせてみました。

これが買ったとき当時のものです。よく言われるのですが箱が某アレに似ています。というかまんまです。

合わせて買ったものとして、横にあるのはXiaomi Mi band 2というヘルスロギングツール。まあ簡単に言うと時計兼万歩計兼ヘルスケア用品です。

gearbestさんでredmi note 3 proは140ドルくらい。Xiaomi Mi band 2は30ドルです。

Redmi note 3 proのスペックのコストパフォーマンスだけを見るとすごく高いです。

基本的なスペックはROM 16GB,RAM 2GB,SoCはSnapdragon 650、フロントとリアカメラ、あとは指紋認証。
Snapdragon 650はantutu 70000程度のレベルで、日本で3,4万で売ってるP9 Liteあたりよりも性能はいいです。
実際のところ、日本で売られている機種は太刀打ちできないレベルのスペックという魅力があります。スペック至上主義の私としては最高です。
まあ、耐久性とかはどうなるかわかりませんが、そこは国内7位にまで落ちてしまったけどXiaomiさんのブランドということで買いました。

Xiaomi好きなんですよね。コンセプトとかブランド感を醸し出しているのに、中華っぽいところとか。
この前出した炊飯器とかもちょっとほしいくらいです。おどり炊きの創案者が開発にかかってるとかで注目してます。
でも炊飯器なので日本のコンセントで大丈夫かな・・・と思わなくもないですが・・・

結局中国サイトから発送に関してはいろいろ言われていますが、自分に限ってはかなり早い段階で着きました。というより予定通りでした。

gearbestは現在、発送方法としておなじみの「日本郵便(Japan Post)」が選べるようになっています。 (Priority Line選択時

日本郵便の場合、発送は7-10日。しかも送料無料です。1週間で届きます。いい時代ですね・・・。

で、使いごごちですが、AndroidベースのMIUIという某PhoneっぽいカスタムUIが採用されています。実際、これも使ってみたかったということも買った理由です。
かなりよくできてると思います。でもAndroidっぽくないなあと思うのですが。
あとは、指紋認証。この値段帯で指紋認証までついてるというのは本当に驚き。iPhone 6Sを持ってますが、それと同じくらいレスポンスは早いしロック解除できるので使いやすいです。
2カ月が立とうとしてますが、基本アプリの検証機として買ったものなので、壊れる気配はないです。
まあ今まで中華的なパッドを使った経験からすると、大体は突然死なのでわかんないですのよね・・・。

Mi band 2はわりとスマートな時計としても使えます。でも一番役に立ってるかなーと思うのは公式アプリで測ってくれる睡眠時間のロギング。

これはかなりの精度で寝た時間を記録してくれます。一日7時間よく寝る自分にとっては嬉しい機能です。

つーか二度寝とかもちゃんと記録されるし、布団に入っているだけだと記録されないし、どうやって判定しているのかかなり気になります。
ほかにも通知機能だったりとfitbit某製品と同じレベルの機能は備わっています。
今ならセールでこちらは25ドルくらいで売ってるのを見かけます。こういうの欲しいと思ってた人は損はないでしょう。
Xiaomiのアカウント作らないといけないのがちょっとアレですが、それくらい。

最近はモニタも買ったし、グラボも買ったし、スマホも買ったし、社会人の財力で生活レベルがどんどん上がっていきます。

次はMacBookかな。

[JavaScript/ECMAScript2017]async/awaitとPromiseでjavascript直列/並列処理

potproject.net Advent Calendar 201610日目の記事です。

祝!10日連続更新!


ES8にあたるECMAScript2017では、await/asyncが実装されると聞いて。黙っちゃいられねえ。

まだES2017は策定中ですが、なんかEdgeでも動くようになったらしいし(設定は必要)、多分ほぼ確定。内定状態でしょう。

https://tc39.github.io/ecma262/

しかし、やはり標準では動かないので、このコードはbabelでトランスパイルしてnode.jsで動かしてます。ご了承ください。

await/async修飾子は、元々C#で使われていた非同期処理を同期的に記述できる仕組みです。

一時期C#を使っていてユニバーサル Windows プラットフォーム (UWP) アプリを作っていた時があり、

制約がありすぎて普通にWindows formsで作りてえと思いつつその時に使用しておりました。

基本的に使い方はC#もjavascriptも同じです。しかし、当然javascriptにはTask型なんてありませんので、Promiseがそれの代用になります。

つまりは、await/asyncを使うにはPromiseから習得する必要があります。

なので、ここではPromiseに関しても軽く記載しておきます。

Promiseに関しては、非同期の処理を上手く同期的に見せたり、並列処理が出来るメソッドです。

何が違うかというと、書き方が違います。await/asyncは非同期処理を同期的に行うため、結局直列の処理になりますが、Promiseは並列処理が可能です。

今回書くコードは、Promise.allでの並列処理とawait/asyncでの直列処理の比較です。

プログラム的には、1から指定された数まで全て足して出力するだけの処理です。

arr.reduceを使った非同期処理方法とfor文を使った同期処理方法で、それぞれ処理をして表示します。

一応速度も出力します。

//繰り返し回数
const execute_count=10000000;
(async ()=>{
  //await/asyncでの直列処理
  var startTime = new Date();
  var sumtest = await reduce_sum(execute_count);
  var normalsumtest=normal_sum(execute_count);
  var endTime = new Date();
  if(sumtest===normalsumtest){
    console.log("(await/async):" + (endTime - startTime) + "ms ans:"+sumtest);
  }

  //Promise.allでの並列処理
  var startTime2 = new Date();
  var sumexecute=await sum(execute_count);
  var endTime2 = new Date();
  console.log("(Promise.all):"+(endTime2 - startTime2)+ "ms ans:"+sumexecute);
})();

async function sum(num){
  return new Promise((resolve,reject)=>{
    Promise.all([normal_sum(num), reduce_sum(num)])
    .then(function(sum_result) { 
      if(sum_result[0]===sum_result[1]){
        resolve(sum_result[0]);
      }else{
        reject();
      }
    });

  });

}

function normal_sum(num){
  var arr=[];
  for(var i=1;i<=num;i++){
      arr.push(i);
  }
  var sum = 0;
  for(var x=0;x<arr.length;x++){
    sum+=arr[x];
  }
  return sum;

}

async function reduce_sum(sum){
    return new Promise((resolve,reject)=>{
      var arr=[];
      for(var i=1;i<=sum;i++){
        arr.push(i);
      }
      return resolve(arr.reduce(function(prev, current) {
        return prev+current;
      }));
    });
}

結果はこんな感じ。

(await/async):690ms ans:50000005000000

(Promise.all):786ms ans:50000005000000

並列の方が遅い。ほぼ変わらずです。なんで?って感じですが、多分これが正しいと思います。

javascriptはご存知の通りシングルスレッドなので、並列処理だからってスレッドを増やしたりできません。

シングルスレッドということは同時に別の処理をやることはできないので、だから結局のところ疑似並列処理なだけです。

むしろ並列にしたほうが割り込みが入るので、遅くなると思います。

実際トランスパイラしてるというのもあるし、await/async/Promiseの処理時間とかもあるので上の時間は多分あてになりません。

一番の問題は、コードの見やすさです。

await/asyncを使えばメインのコードにコールバックを一切入れることが無くなるため、見やすいんじゃないかなと思います。

自分は積極的にawait/asyncは使っていきたいです。もうコールバック地獄には入りたくない・・・。

[React Native]ネイティブモジュール(Swift)を使う[iOS編]

potproject.net Advent Calendar 20169日目の記事です。


react-nativeをとりあえずすぐ実機で動かしてみる

で、とりあえず実機で動くかの確認は取れました。
で、今回は、React Nativeとネイティブコードの連携をやってみたいと思います。

React NativeはiOSやAndroidを共通のJavascriptで書いてマルチプラットフォームでしかもネイティブに動くよ!というのがウリです。

しかし、当然ながら、SwiftやObjective-Cを使うようなものも必要になります。カメラとかプッシュ機能。

まあメジャーなものは用意されてる場合もあるんですが、マイナーなものは無かったりするので、

自分で作ってね!ってことでネイティブモジュールという機能で補完できるようになってます。

Cordovaを思い出す。しかしこっちは完全ネイティブなのだ。

このあたりを参考にしました。しかしまあやっぱり例によってSwift3.0なので結構コード変えてたりもします。
React NativeでNative機能をSwiftで書いて使うには

Native Modules

Objective-Cは全く分からないのでSwiftです。でもブリッジしなくてはならないので多少はObjective-Cは避けられないんだなあこれが。
原則、React NativeはネイティブモジュールにSwiftを使うように設計されていません。生成されたプロジェクトもObjective-C用で生成されます。

なので、使うにはObjective-CとSwiftを連携させる必要があります。

swiftでモジュールを作成

まずは、モジュールを作成します。ちなみにこれだけだとまだ動きません。
端末の時間を取得してAny(Dictionary)型でコールバックを返します。

どうやらReact Nativeのjavascriptにデータを受け渡す際は必ずcallbackなのかな。
ちなみにPromiseも使えます。

ReactNativeModule.swift

import Foundation

@objc(ReactNativeModule)
class ReactNativeModule: NSObject {

  @objc func callbackMethod(_ callback: RCTResponseSenderBlock) -> Void {
    // システムのカレンダーを取得
    let cal = Calendar.current
    // 現在時刻のDateComponentsを取り出す
    var dataComps = cal.dateComponents([.year, .month, .day, .hour, .minute], from: Date())
    let object = [
      "year":dataComps.year!,
      "month":dataComps.month!,
      "day":dataComps.day!
    ]
    callback([object])
  }
}

配列で返しても大丈夫なの?と思いでしょうが、ちゃんとReact Native側はjavascript Object型で受け取ってくれます。優秀です。  
callbackMethodの第一引数が無名関数がなっているのは、このあたりの問題から。認識してくれないのです。Swift3.0での変更点となります。
Got “is not a recognized Objective-C method” when bridging Swift to React-Native – stackoverflow

Objective-Cでエクスポートする

ReactNativeModuleBridge.m

#import "RCTBridgeModule.h"

@interface RCT_EXTERN_MODULE(ReactNativeModule, NSObject)

RCT_EXTERN_METHOD(callbackMethod:(RCTResponseSenderBlock)callback)
@end

実際はこのObjective-Cが読み込まれます。これが上で書いたSwiftコードの橋渡しになります。

Objective-Cの文法は相変わらず割と理解できていない。

testreactnative-Bridging-Header.h

#import "RCTBridgeModule.h"

RCTBridgeModule.hというObjective-CのコードをSwiftで読み込むために設置。
このあたりに関してはググるといっぱい出てくるため割愛。

React Native側のソースはこんな感じ。画面の更新もしたかったのだが、結構時間掛かりそうで・・・ただログ出すだけ。

index.ios.js

import React, { Component } from 'react';
import {
  NativeModules,
  AppRegistry,
  StyleSheet,
  Text,
  View
} from 'react-native';
var nm=NativeModules.ReactNativeModule;
nm.callbackMethod(function(res){
    console.log(res);
});

これでデバッグ画面からログが確認できました。

ちゃんと{"year":2016,"month":12,"day":9}と出てきます。Any型も受け渡せるのは楽でいいですねえ。

今回、タイトルが(iOS編)です。

これで気づいた人もいるかもですが、明日はネイティブモジュール(Java)を使う[Android編]をやります。多分。

Swift3.0でjsonパラメータをHTTP POST

potproject.net Advent Calendar 2016
8日目の記事です。

Swift3.0です。本当Swift2.x時代が強すぎて検索に全く引っかかってこないのが辛い。


もう結構前になってしまいますが、iOS10が公開され、iPhone7も発売されました。

しかし、相変わらず自分的にはiOS10もiPhone7も興味ありません。

でも、残念ながらiOS開発をしているとiOS10にも対応しなきゃならなくなり、

小規模なアプリを作っていたので、swift2.3からswift3.0に書き直すことに。

しかし、swift3.0はもう2.xの互換性をかなぐり捨てていて、公式でコンバータが用意されるくらいにめっちゃ変更されてます。

まあ大体はコンバートで対処できるのですが、http通信のコードの部分でエラーが出ていました。

調べるとやっぱりここはうまく自動変換ができない模様。

Swift 3 URLSession.shared() Ambiguous reference to member ‘dataTask(with:completionHandler:) error (bug)

で、大体の人が詰まっているようだったswift3.0でHTTPリクエストを送るコードを自分のメモがてら載せときます。

つかswiftは仕様変わりすぎなんだよね・・・

コピペエンジニアには辛すぎる言語だ。ググっても2と3が混合してて辛い。

まず、swift2.3のコード。バックアップ取ってなかったんで再現になりますが。
Swift2.xだとこんな感じです。
参考:http://qiita.com/sushichop/items/ac4ae99b905ce523c2fe

// create the url-request
        let urlString = "http://httpbin.org/post"
        var request = NSMutableURLRequest(URL: NSURL(string: urlString)!)

        // set the method(HTTP-POST)
        request.HTTPMethod = "POST"
        // set the header(s)
        request.addValue("application/json", forHTTPHeaderField: "Content-Type")

        // set the request-body(JSON)
        var params: [String: AnyObject] = [
            "foo": "bar",
            "baz": [
                "a": 1,
                "b": 20,
                "c": 300
            ]
        ]
        request.HTTPBody = NSJSONSerialization.dataWithJSONObject(params, options: nil, error: nil)

        // use NSURLSessionDataTask
        var task = NSURLSession.sharedSession().dataTaskWithRequest(request, completionHandler: {data, response, error in
            if (error == nil) {
                var result = NSString(data: data, encoding: NSUTF8StringEncoding)!
                println(result)
            } else {
                println(error)
            }
        })
        task.resume()

いろいろありますが、これはNSURLSessionDataTaskというものを使ってでHTTP POSTを送るようです。

多分今までのswiftだとこれが主流なのかな?

このNSURLSessionがswift3.0ではURLSessionになり、仕様も変わっています。

URLSession.DataTaskは、第一引数に NSMutableURLRequest型ではなくURLRequest型でないと動きません。

NSMutableURLRequestを受け渡すと、クラッシュします。

requestは明示的に型宣言してないため、コンバートが見逃したということですね。

しかもコンパイル時エラーも起きない。困りますね。

(他のブログだとこれでビルドが通らないらしい。もしかして修正されたのかも?

というか通り抜けてたならAppleさんが悪い・・・俺は悪くない

参考:https://blog.areare.net/archives/8321

URLRequestは、NSMutableURLRequestとほぼ同じように書けます。

というより、内部的にはほぼ同じものらしいので、なんでこれで通らなくなってしまったのかわからん。

let urlRequest = URLRequest(url: requestURL)

これを踏まえて、書きます。

        let urlString = "https://httpbin.org/post"
        var request = URLRequest(url: URL(string:urlString)!)

        // set the method(HTTP-POST)
        request.httpMethod = "POST"
        // set the header(s)
        request.addValue("application/json", forHTTPHeaderField: "Content-Type")

        // set the request-body(JSON)
        let params: [String: Any] = [
            "foo": "bar",
            "baz": [
                "a": 1,
                "b": 20,
                "c": 300
            ]
        ]
        do{
            request.httpBody = try JSONSerialization.data(withJSONObject: params, options: [])
        }catch{
            print(error.localizedDescription)
        }
        // use NSURLSessionDataTask
        let task = URLSession.shared.dataTask(with: request, completionHandler: {data, response, error in
            if (error == nil) {
                let result = String(data: data!, encoding: .utf8)!
                print(result)
            } else {
                print(error)
            }
        })
        task.resume()

こんな感じかな。

初期に公開したコードはやっぱり間違っていました。ごめんなさい。

ちゃんとこのソースのままでjsonをpostできていることを確認しました。

後は、他にもいろいろ変わっているところがありました。

NSJSONSerialization.dataWithJSONObject([AnyObject], options: [options], error: [error])は、

JSONSerialization.data(withJSONObject: [Any], options: [options])に置き換わりました。

errorのコールバックがなくなった分、try-catchを行わないとコンパイルエラーとなります。

他にも、微妙に大文字から小文字へと変数名が変わったり。

iOS開発初心者のSwift3の道は険しい。

Amazon サイバーマンデーセールでそれなりに大きめのモニタを買った

potproject.net Advent Calendar 2016
7日目の記事です。
今回はもうただのブログレビューですが多少はね。


昨日から、Amazon サイバーマンデーセールが始まりました。

最近の大型Amazonセールはプライム超優遇なので、プライム2年生の私毎回楽しみなのです。

しかし、数か月前のプライムデーは割とがっかりだったので、今回はFire TV Stickでも買うかーって感じでした。
実際はStick値引きが微妙なので買わずじまいですが。
買う気はなかったのですが、すごくいい感じのモニタがあったので即買い。

購入したものは、iiyama ディスプレイ モニター XB2783HSU-B1 27インチです。

プライム限定セールで¥19,800。価格.comの最安で¥25,800なのでかなりお買い得だと思います。

iiyamaモニタの大きめのIPS液晶で2万くらいのがほしいなーとまさにぴったりだったので買いました。

モニタを買うのは多分もう5,6年ぶりです。ちなみに前のモニタもiiyamaを使ってました。23インチIPS。

子のモニタは結構特殊なんじゃないかと思うのですが、AMVA+液晶というものです。

視野角の狭かったVAパネルを改良したAMVA+パネルの改良版、という話で、

実際前のIPSパネルと比較してもむしろ前のより視野角が広く思えます。

発色は目にわかるレベルでこちらが上です。

買ったときの値段は古い奴が高いというのに。技術の進歩を感じますね。

あとは、IPSと比べるとバックライトも抑えることができるらしく、目に優しいとかよく聞きます。

自分もかなりブルーライトに弱く、すぐ頭痛くなる時代もあったため、その点で評価して決め手に。

ついでに応答速度もちょっと早いのでゲーム向き。

img_0139

左が今回買ったiiyama XB2783HSU 27インチ。右がサブ機に落ちたiiyama XB2374HDS 23インチ

こうやって並べるとデカい。なんかすげえプロっぽい(何の)

img_0140

ついでに、モニタの右側にUSBハブ機能がついてるのがすごくうれしい。

こういうのでいいんだよこういうので。

次はダブルモニタで捗った的な記事も書きたいです。

Markdownを習得していろんなところで書くTips

potproject.net Advent Calendar 2016
6日目の記事です。

ネタ切れになりそう


このAdvent Calenderを書く時から、書き方を普通のhtmlからMarkdownに変更しました。
Markdown(正式にはMarkdown記法)は、HTMLで書くのだるいから簡素な形で書いたものをhtmlに変更しちゃおうというところです。
最近ではかなり見かけるようになりました。

仕組みとしては単純に、
# おはようございます

<h1>おはようございます</h1>

に変更されるというだけです。
こうやってみるとhtmlは開きタグと閉じタグを付けなくてはならないので、めんどくさいですよね。

Markdownは結構様々なサイトで使われています。というか、使われるようになりましたね。

有名どころでredditgithubなど。日本だとQiitaが有名ですね。

実際、htmlに変わって楽に書こうみたいなものはMarkdown以外にも結構あったと記憶しています。

コーディング向けだけどSlimとかHamlとか、ブログサービスなんかでは独自の記法もあった記憶。

文章書きに関してはMarddownが覇権取ってるっすなあというイメージ。

超簡単チートシート(自分用)

h1,h2,h3,h4,h5 = #,##,###,####,#####
コードの挿入  = ``` console.log("Hello world!"); ```
太字 = ** 太字 **
リンク = [potproject.net blog](https://blog.potproject.net/)
引用 = > 引用
地平線 = ---
改行 = "かいぎょうします。  "(半角空白2回)

わりと改行に関しては当然みたいな感じで書いてないところが多い。ひどい。

知らない人が絶対悩むだろこれと思います。これだけ覚えておけばOK。

WordPressではjetpack Markdownというプラグインがおすすめです。

自分はこれに加えてmarkdown-quicktagsというプラグインも入れてますが、

実際WordpressでMarkdownを書くのはあまりいい方法が無いです。

Markdownはテキストエディタatom.ioで書くのがいい感じです。

大体の記事はこれで書いてます。
Ctrl+Shift+M でリアルタイムプレビューもあり、いい感じ。

mark

スクロールしてくれないのが悲しいけど。ともあれ今後はMarkdownでブログ書きます。

[nginx]Let’s EncryptでSSLのセキュリティをA+にするまで

potproject.net Advent Calendar 2016
5日目の記事です。

nginx advent calenderになりつつある。この頃。
10日目くらいからアプリやガジェット系のネタを入れていく次第です。


先日の記事で、nginxでLet’s Encryptを使ってSSLの設定行いました。

しかし、指摘したようにこれだとセキュリティがイマイチなので、

再度設定し直してセキュリティをさらに向上させようと思います。

まず、現在のセキュリティがどのレベルかを見るため、

Qualys SSL Labs の SSL脆弱性診断を使って、テストしてみます。

bef

こういう結果になりました。特に鍵交換が弱いですね。

この部分に関してはDH鍵交換のデフォルトが1024ビットのため、既に弱くなっているからだとか。

まあ1024ビットでも高い専用機じゃないと解読できないレベルらしいので、

こんなしょぼい個人サイトだったらまあ本来はまず問題はないんですが・・・
2048ビットのDH鍵交換をopensslで作成し、使用します。

DH交換用の鍵作成

openssl dhparam -out /etc/nginx/dhparam.pem 2048

セキュリティを高める鍵だけあって、サーバーによっては生成にかなり時間がかかります。こっちだと2分くらい。

自分も生成中にこの記事を書いてました。

他にも、前に紹介したMozilla SSL Configuration Generatorを参考に、いろいろと設定します。

後、せっかくなのでSSL設定を共通化できるようにSSLだけ設定をまとめることにします。

nginxの場合、 include /etc/nginx/ssl.conf; という風に書けばそのままインクルードして使えます。

/etc/nginx/ssl.conf;

# 共通鍵と秘密鍵
ssl_certificate /etc/letsencrypt/live/[ドメイン名]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[ドメイン名]/privkey.pem;

# セッションの設定
ssl_session_cache shared:SSL:50m;
ssl_session_timeout  1d;
ssl_session_tickets off;

# 2048ビットのDH鍵交換を使う
ssl_dhparam /etc/nginx/dhparam.pem;

# SSLv3を禁止し、TLSを使う
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# SSL暗号化スイートの使用設定
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;

# HSTSの有効化
add_header Strict-Transport-Security max-age=15768000;

# OCSP認証とステープリング(キャッシュみたいなもの)を有効にする
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## OCSPレスポンスを行うRoot CA 証明書(fullchainでOK)
ssl_trusted_certificate /etc/letsencrypt/live/blog.potproject.net/fullchain.pem;

これをインクルードして設定。nginxの再起動も忘れずに。

af

これでA+になりました。やったぜ。

・・・でもこれが原因でレスポンスなんかがめちゃくちゃ遅くなるんだったら戻しますけどね。

セキュリティより可用性の方が大事ですわな。