カテゴリー: ネット
朝活(DaiGo)
データサイエンティスト育成スクール
人狼から相手の性格が推定
嘘を見抜く有効な手段
回答が一字一句同じだと嘘かもしれない
顔より体より発言
嘘をついているとあいまいな発言が増える
プレッシャーをかけると嘘をつきづらくなる
発言が短くなる
あまり、発言を訂正しなくなる
同じ言葉の反復が増える
協力的な態度が減る、声が高くなる、表情が硬くなる
顎を上げるしぐさ、口を閉じるしぐさ、瞳孔がひらく
身振り手振りが減る
ダイワリビング 電気 解約
前回までの記事はこちら
やりたいことは
d-roomの電気から楽天電気への切り替え
楽天でんきへの切り替えの目的はスマートメータでの確認
(在宅勤務の増加による、電力消費量の確認)
楽天でんきに切り替えるには以下の対応が必要
楽天でんきのカスタマー対応は最低
————————————————————————-
楽天でんき カスタマーセンターでございます。
先日は楽天でんきへお申込いただきまして、誠にありがとうございました。
お切り替え手続きにつきましてご案内申し上げます。
お客様のお申込みを確認いたしましたところ、現在ご契約中の電力会社として「大和リビングユーティリティーズ株式会社」とご入力いただいておりましたが、
恐れ入りますが、大和リビングユーティリティーズ株式会社様は電力会社ではなく、
大和リビングユーティリティーズ株式会社様のご名義にてどこかの電力会社とご契約されているかと存じます。
楽天でんきはお客様ご自身で電気のご契約をされている地点に限りお切り替えをお受付しておりますので、
大変恐れ入りますが、このままお切り替え手続きを進めることができません。
つきましては、本メールをもちましてこの度のお申込みは一度お取り消しとさせていただきます。
また、楽天でんきへのお申込みをご希望いただける場合は、
お手数ではございますが、下記手順にてご対応頂きますようお願い申し上げます。
①大和リビングユーティリティーズ株式会社様に個人で電気契約をしていいか確認
②了承をいただけた場合は、大和リビングユーティリティーズ株式会社様のご解約日に合わせて、地域の電力会社にてお客様ご自身のご名義にて電気契約
③地域の電力会社での新たなご契約情報にて改めて楽天でんきへ切り替え申込み
——————————————————————————-
#楽天でんき 問い合わせ
内閣官房長への出向/カードのランク
民間からでも会社から言われて出向することがあるらしい。
https://www.cas.go.jp/jp/gaiyou/jimu/jinjikyoku/files/jkj_ukeire_h290224.pdf
https://www3.nhk.or.jp/news/special/kasumigaseki/article/article_190415.html
カードのランクをあげることに執着している人もいるらしい
https://www.travel-rescue-tips.com/jgc-trip-at-home/
https://ameblo.jp/lange-and-sohne/entry-12578009300.html
大和ハウス 電気料金 単価
電気料金について、調べてみた。
D-roomでも配給会社の変更はできる。電話とメールで問い合わせて確認済み。
>電気のご契約につきましては、入居者様には当社の電気配給サービスをご利用頂くようお願いしておりますので、原則他社電力への乗り換えはご遠慮頂いております。
とのことだが…。
検索すると、D-roomの電気料金は高いと情報もあるが、中部電力の電力プランのままのようなのでべらぼうに高いわけではない。
楽天でんきにかえても(使用量によるが)年間数千円程度か。
電気料金=基本料金+電力量料金±燃料費調整額+再生可能エネルギー発電促進賦課金
電力量料金=お住まいのエリアの従量料金×月間使用量(kWh)
燃料費調整額=燃料費等調整単価(燃料費調整単価+離島ユニバーサル調整単価)×月間使用量(kWh)
再生可能エネルギー発電促進賦課金=再生可能エネルギー発電促進賦課金単価×月間使用量(kWh)
※燃料調整費額・再生可能エネルギー発電促進賦課金は各電気事業者一律の料金となります。
燃費調整額
https://miraiz.chuden.co.jp/home/electric/contract/fuelcost/unitprice/index.html
▲4.59円/kwh
再生可能エネルギー発電促進賦課金
https://www.enecho.meti.go.jp/category/saving_and_new/saiene/kaitori/surcharge.html
https://miraiz.chuden.co.jp/home/electric/contract/renewableenergy/price/index.html
2.98円/kwh
#大和ハウス電気 評判
#大和ハウス 電気 解約
#大和ハウス 電気料金 安い
#ダイワハウスでんき
#大和エネルギー 電気料金
#大和ハウス 電気 問い合わせ
#ダイワリビング 電気料金プラン
続きはこちら
http://blog2.konpeitou.biz/2020/11/02/ダイワリビング-電気-解約/
PHPでPubSubHubbubにパブリッシュする
PubSubHubbubについて
インターネット上のpublish/subscribe パターン(出版/購読型などとも呼ばれる)で配信される情報のためのプロトコル。
Publisherはフィードを配信する側で、Subscriberはフィードを購読する側。WordPressで採用する場合はPublisherはWPを採用しているメディアでSubscriberはGoogle。
PubSubHubbubを利用することでメディア側でのコンテンツの更新を能動的にGoogleへ通知し、インデックスしてもらうことができる。
同様のことはPingなど他のプロトコルでも可能だが、PubSubHubbubでは、非常に高速にフィードをGoogle側に受け取ってもらうことが可能となる。
※PubSubHubbubではPublisherとSubscriberの間にHubというものを置いている。細かい点は時間が空いたらまとめる予定。
Google Trendで見たらけっこう前からあったみたいだし、特に最近話題の技術というわけではなさそう。
https://www.google.co.jp/trends/explore#q=pubsubhubbub
特にPubSubでインデックスのサイクル早くしても検索順位が劇的に上がるとかそういったことはなさそうだけど、スクレイピング対策にはかなり有効そう。
例えば、他のサイトのコンテンツを引用して自サイトのコンテンツのように公開しているキュレーション系のメディア(スクレイパー)が、引用元(オリジンメディア)より上位に表示されたり、ひどい場合は引用元がスパム扱いを受ける場合がある。
スクレイパーより先にGoogleにインデックスされることでオリジンメディアであることを主張できる。
スクレイピングの対象になっているようなメディアなら上記のような恩恵に預かれそうだし、そうでないサイトでも入れておいてまず損はなさそう。
PHPでのパブリッシュ実装
基本WordPressなどのCMSならプラグインを導入すればすぐに導入可能みたいだけど、なんらかの事情でPubSubHubbubへのパブリッシュを実装しなきゃいけない場合は下記のような感じでできる)。
下記はPHPでの例。
class Publisher{
/* プロパティとセッター・ゲッター定義 */
private $pubsubhubsub_hub;public function get_pubsubhubsub_hub() {
return $this->pubsubhubsub_hub;
}public function set_pubsubhubsub_hub($pubsubhubsub_hub) {
$this->pubsubhubsub_hub = $pubsubhubsub_hub;
}/* Publish通知をハブに送信 */
public function publish($url) {
$post_data = ‘hub.mode=publish&hub.url;=’ . urlencode($url);
$ch = curl_init();
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_URL, $this->pubsubhubsub_hub);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(‘Content-Length: ‘ . strlen($post_data)));
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
$response = curl_exec($ch);
$info = curl_getinfo($ch);
$result = (204 == $info[‘http_code’]);
curl_close($ch);return $result;
}
}/* ハブに送信 */
$url = ‘http://linuxserver.jp/seo/pubsubhubbub.php’; // ここで通知したいURLを指定
$publisher = new Publisher();
$publisher->set_pubsubhubsub_hub(‘https://pubsubhubbub.appspot.com/’); // ハブのURLを指定
if ($publisher->publish($url)) {
echo “パブリッシュしました。”;
} else {
echo “パブリッシュできませんでした。”;
}
GoogleのPubSubHubbub Hubにパブリッシュするときは下記の規約(?)に従う必要がある。
リクエストメソッドはPOSTで行う
HTTPヘッダでコンテンツタイプに”application/x-www-form-urlencoded”を指定する(“Content-Type: application/x-www-form-urlencoded”)
hub.mode(値は”publish”であること)と、hub.urlのふたつのパラメータが必要。また、値はURLエンコードされていること
下記URLのフォームから手動でパブリッシュすることも可能。
https://pubsubhubbub.appspot.com/publish
UbuntuでのEclipse再インストール
UbuntuでのEclipse再インストール
Ubuntu13.10から14.01にアップグレードするとあるJavaのプロジェクトが動かなくなったのでEclipseを再インストールした。
そのときのメモ。
下記手順でアンインストール。
$ sudo apt-get purge eclipse*
$ sudo apt-get autoremove
$ sudo rm -rf /usr/lib/eclipse
$ sudo rm /etc/eclipse.ini
$ rm -rf ~/.eclipse
`sudo rm -rf /usr/lib/eclipse`を飛ばすとEclipse立ち上げた後の新規ソフトウェアのインストールでコケた。
アンインストールが完了したら下記手順でインストール。
$ sudo apt-get install pleiades
$ vim /etc/eclipse.ini ※末尾に下記の1行を追記
-javaagent:/usr/share/eclipse/plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar
$ eclipse -clean & ※編集完了後に一度-cleanオプションを付加してEclipseを起動。以降は-cleanオプションは不要。
【データ設計アンチパターン】誤ったステータスカラムの設計
Webアプリの開発では、あるテーブルにステータスカラムを持たせるということはよくあります。
今回は、実際に業務で遭遇したBadなステータスカラムの設計を教材として、正しいステータスカラムの設計とは何かを考えていきたいと思います。
ステータスの定義
ステータスとは文字通り、対象の状態のことです。
開発では、操作対象(オブジェクト)のある状態に名前をつけたり値を割り振ったりします。
例えば、記事が公開中であるか、下書き状態であるかです。
ステータスをそのように区別しなければならない理由としては下記があります。
・当該ステータスにおいてのみ、実行させたい処理がある
・当該ステータスでは、実行させたくない処理がある
アンチパターンその1. ステータスを抽出する粒度がおかしい
仮にYahoo!ニュースのようなニュースを配信するメディアがあったとします。
このメディアでは、記者が書いた記事を運営事務局が検閲し、内容に問題がなければ掲載を開始するという業務フローになっています。
このケースで以下のようなデータ設計がされていたらどうでしょうか?
※ステータスにフィーチャーするため、ユーザIDなどの外部キーや記事本文など他のカラムについては記載していません。
まず、edit_statusというカラムについてです。
抽出されているステータスとして「申請中・再申請中」というものがありますが、両者は区別する必要はありません。
なぜなら、申請中というステータスは記者が事務局に「記事の内容を確認してね」という要請を出していますよという状態ですが、それが初回であろうが2回目の申請であろうが事務局が行う検閲という業務フローには影響がありません。
ステータスは抽出しようと思えば、いくらでも作れてしまいます。
例えば、対象を人間変えると「新婚・風邪・食あたり・食事中・休憩中」などなど。
こうなってしまうと際限がなくなってしまいますので、粒度が細かいものはまとめなければなりません。
ではどういった基準でまとめるのかというと、前述した「当該ステータスにおいてのみ、実行させたい処理がある」かどうかです。
例えば勤怠管理のシステムにおいて欠勤理由などを保存する場合「風邪・食あたり」では細かすぎます。「体調不良」というより大きな粒度にまとめてしまうといいでしょう。
制御に利用されないステータスは混乱を招くだけですのでなくすようにしましょう。
アンチパターンその2. ステータスが重複している
上記データ設計にはもう1点悪い箇所があります。
それはステータス保存するカラムが2つあることです。
まずこの実装でステータスを定義する目的は「記事を公開できる状態であるか区別する」もしくは「オペレーション(申請に対する検閲)が必要であるか区別する」ことです。
2つに分けられたステータスを比較したときに、これらを制御し得る値であるが複数存在しちゃっています。
表にしてみると一目瞭然です。
具体的に重複している箇所は以下の通りです。
・「下書き中」「未公開」はどちらかひとつあれば、記事を編集中であるかどうかは判断可能
・「完了」「公開中」はどちらかひとつあれば、記事を公開できる状態かどうかは判断可能
・※「申請中」・「再申請」は前述した通り
このケースだと、statusカラムは1つにまとめちゃって、値は「編集中・申請中・公開中」の3つにしてしまえばずっとシンプルになります。
以上、ステータスカラムの設計についてでした。