内閣官房長への出向/カードのランク

民間からでも会社から言われて出向することがあるらしい。

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つにしてしまえばずっとシンプルになります。

以上、ステータスカラムの設計についてでした。