NAV_MENU
賽は投げられた。人事尽くして天命待つと言うか、転がりだした物は止められないというか。まぁ、ちょとは覚悟しとけよ。
基本的に毎日更新。出来なかったときは遡ってやります。多分。きっと。出来たら良いな

現在、移転作業中に付き、縮退運転中!。過去ログへのリンクはデータ移行後に何とかします

痛ましいな

中国道事故、死亡の2人は母娘 津山、タイヤに相次ぎ乗り上げ


 18日夜、津山市坪井上の中国自動車道上り線で起きた大型トレーラーと軽乗用車が絡む事故で、2台が路上に落ちていたタイヤに相次ぎ乗り上げたことが原因だったことが19日、岡山県警の調べで分かった。先に乗り上げた軽乗用車は追い越し車線で停車し、乗っていた親子2人が路肩付近に避難していた際、横転した後続のトレーラーにはねられて死亡した。



ニュースだとガードレールの外側にいたとかいう話もしてたけど
どっちなんだろう

JAFとかは、停止した車両(とか要因物)から進行方向に向かって後方で待機って呼び掛けてるよね
http://qa.jaf.or.jp/drive/highway/07.htm

こういう貰い事故を避けるために
タイヤは目視できなかったとしても、もうちょっと避難場所何とかならなかったのかと思うことと
警察も通報があったのなら先に安全確保の指示した方が
よかったんじゃないかと思ったりした



雨よく降る

空梅雨だっただけに梅雨以上に雨が降る
完全に秋雨前線にやられてるな

しかも通勤時間帯には傘さすかささないか迷うあたりの雨量で悩ましい


仕事ー

久々の仕事

なんかいろいろ頭痛い
風邪かしらん?


雨がよく降る

仕事休みなので家でのんびり。
半分くらい寝てたけど

こうも雨が降ると滅入るな

空気中の水蒸気ってこんなに含まれてるのかって思うたびにびっくりするわ


昨日の疲れが酷い

金曜日アルコール入れてロクに寝てないから当然か
雨じゃなかったら観光してるはずだったのに
雨だから問題ないんだけど

京都も残念ながら1日雨だった…


高知へ

始発の新幹線で一路岡山、
岡山で南風に乗り換えて高知へ

昼前に大学着
先生と話して、15時頃に切り上げる
明日は観光するつもりで、ちょっと荷物持ってきたけど
天気崩れて、翌日も雨予報なので日帰りに変更

17時前に高知駅で買い物して18時に南風のって
そのまま30分ほど待ち

高知駅のコレ

アカンやろ

で5時間後帰ってきた
5時間かかるか…
岡山の連絡時間が掛かるようになってんのよね


飲んできたー

チェコ時代にお世話になった先生と飲んできた

結構思い込みと勘違いで食わず嫌いって多そうな感じ
しゃぶしゃぶなべを勧めて、スープだと感じ違いしてた模様

あと伝統的な和食って言うので、サンプル見せたら、ヘルシーすぎる
寿司・天ぷら・刺身・・・
それ日本人はそんなに頻繁には食べないから
どっちかって言うとハレの料理だもんな


雲行き悪い感じ

週末天気崩れそうだ

明日人に合う用事が出来たので休み申請して休むことに


Linuxの挙動はよくわからん

CentOS7なんだけど
ぶっちゃけsystemdは最悪や


[root@localhost ~]# umount -f /tmp
umount: /tmp: target is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))


何のための-fオプションなんだか
強制的にアンマウントしろよ
クソ

FreeBSDだとサクッとアンマウントできる

root@test1:/root # umount /tmp
umount: unmount of /tmp failed: Device busy
root@test1:/root # umount -f /tmp
root@test1:/root #


今日も頭の悪いのに遭遇

そこそこ満員電車にかかわらず
最後に乗ってきて床に荷物置いて
荷物撮るのに屈む頭の弱い大学生

尻を後ろに突き出して屈むんだが
あれってゲイで誘ってるんですかね?

そういう属性はないので知らんけど

ほんと邪魔でしゃーない


なんか肩が痛い

風邪かな
ちょっと気をつけようと思う物の、この時期寒かったり暑かったりでかなんわ


近所で花火大開



下半分くらいが家の影に隠れて見えないけど
まぁ見えた


下鴨神社

最近リラックマが仕事選ばなくなってきてるなー




意表を突かれた



これ見てから



これ見ると
途中で???ってなった
てっきり旅行でのカメラのCMだと思ってたので…


フラッシュメモリ高騰してるらしい

来週でいいかって思ってたら700円も値段上がっとる
又上がりそうなので、諦めて買ってきた

先週買っとけば25000円切ってたのに…



なんか失敗した感じ


頭の悪いの増えたな

寿司詰めの電車車内で、カバンを床に置いてそれを取ろうとかがむヤツにケツで押されて
バランス崩してソイツの背中に肘をついちまったワイ

床に置くのはいいけどどっか手に持っとけよ
朝から気分悪かったわ


PostgreSQLで後方一致LIKE検索でインデックスを使わせる

とりあえずテストデータ作成

test=# CREATE TABLE test (id TEXT,value TEXT);
CREATE TABLE
test=# INSERT INTO test (id,value) SELECT uuid_generate_v1mc() ,GENERATE_SERIES(0,1000000);
INSERT 0 1000001
test=# INSERT INTO test (id,value) SELECT uuid_generate_v1mc() ,GENERATE_SERIES(0,1000000);
INSERT 0 1000001


とりあえず、前方一致のLIKE句付き、後方一致のLIKE句付きのクエリを流してみる


test=# EXPLAIN ANALYZE SELECT id FROM test WHERE id LIKE '5e1f%';
QUERY PLAN

---------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..43692.03 rows=200 width=37) (actual time=0.327..186.813 rows=354 loops=1)
Filter: (id ~~ '5e1f%'::text)
Rows Removed by Filter: 1999648
Total runtime: 188.301 ms
(4 行)

test=# EXPLAIN ANALYZE SELECT id FROM test WHERE id LIKE '%5e1f';
QUERY PLAN

---------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..43692.03 rows=200 width=37) (actual time=16.878..297.931 rows=28 loops=1)
Filter: (id ~~ '%5e1f'::text)
Rows Removed by Filter: 1999974
Total runtime: 298.472 ms
(4 行)


インデックスを作る
LIKE検索でもインデックスが使えるようにvarchar_pattern_ops付なのが味噌。
後者は後方一致を実現するための関数インデックス


test=# CREATE INDEX test_id_ptn_idx ON test (id varchar_pattern_ops);
CREATE INDEX
test=# CREATE INDEX test_id_ptn_reverse_idx ON test (reverse(id) varchar_pattern_ops);
CREATE INDEX


前方一致のLIKEを投げる

test=# EXPLAIN ANALYZE SELECT id FROM test WHERE id LIKE '5e1f%';
QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on test (cost=4.88..113.98 rows=200 width=37) (actual time=0.597..2.106 rows=354 loops=1)
Filter: (id ~~ '5e1f%'::text)
-> Bitmap Index Scan on test_id_ptn_idx (cost=0.00..4.83 rows=28 width=0) (actual time=0.559..0.559 rows=354 loops=1)
Index Cond: ((id ~>=~ '5e1f'::text) AND (id ~<~ '5e1g'::text))
Total runtime: 3.718 ms
(5 行)

インデックスが利いた。

後方一致の場合

test=# EXPLAIN ANALYZE SELECT id FROM test WHERE id LIKE '%5e1f';
QUERY PLAN

---------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..43692.03 rows=200 width=37) (actual time=20.272..305.338 rows=28 loops=1)
Filter: (id ~~ '%5e1f'::text)
Rows Removed by Filter: 1999974
Total runtime: 305.948 ms
(4 行)

当然利かない

関数インデックスを使うように下記のクエリを投げる

test=# EXPLAIN ANALYZE SELECT id FROM test WHERE reverse(id) LIKE reverse('%5e1f');
QUERY PLAN

---------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on test (cost=395.06..16726.74 rows=10000 width=37) (actual time=0.211..0.451 rows=28 loops=1)
Filter: (reverse(id) ~~ 'f1e5%'::text)
-> Bitmap Index Scan on test_id_ptn_reverse_idx (cost=0.00..392.56 rows=10000 width=0) (actual time=0.070..0.070 rows=28 loops=1)
Index Cond: ((reverse(id) ~>=~ 'f1e5'::text) AND (reverse(id) ~<~ 'f1e6'::text))
Total runtime: 0.644 ms
(5 行)

インデックスが使われた

解説

関数インデックスってのは、値を関数で処理した結果をインデックスとして作成するので
同一関数表記でWHERE句に定義されれば、その関数を処理することなく、関数インデックスに作成された値が検索される

よくある使い方は、下記のような大文字小文字の区別なしに検索するときに使う
式インデックス

当然入力値に対して、同じ値を返さない関数は使えない

で、今回reverse()関数で文字列の前後を入れ替えたインデックスを作っているので
内部的には前方一致になって後方一致のLIKE検索にもかかわらず、インデックスが使えるというわけでした


変な使い方だと
長い文字列をキーとする様なテーブルで
小さくコンパクトなインデックスを作りたい場合にも使える

CREATE INDEX test_id_md5s_idx ON test (decode(substring(md5(id),1,8),'hex'));


使うときは下記のようにする

SELECT * FROM test WHERE decode(substring(md5(id),1,8),'hex') = decode(substring(md5('ID-TEXT'),1,8),'hex') AND id = 'ID-TEXT';

md5ハッシュの前方32bit分だけをインデックス化してるので、インデックスサイズは小さい
これを検索すると、オプティマイザは、値をハッシュ化したインデックスで絞り込んだ後、
id = 'ID-TEXT' で再チェックして値を出力する

ハッシュを使って絞り込んだ段階で32bitなので、42億分の1まで絞り込めてるので、読み込むブロックは比較的少なく意外と高速です

md5をそのまま使うなら

CREATE INDEX test_id_md5s_idx ON test (decode(md5(id),'hex'));


SELECT * FROM test WHERE decode(md5(id),'hex') = decode(md5('ID-TEXT'),'hex') AND id = 'ID-TEXT';

こういう感じで

decode(md5(),'hex')としているのは、md5の戻り値がbase16なので、これをデコードしてバイナリ値とした方がインデックスでの占める量が半分になるため
そのままインデックス化すると16進数32バイトテキストだけど、decodeすると16バイトで済む
substringで先頭8バイト切り出した場合は32bitなので4バイト、INTEGERのインデックスと大差なくなる(厳密にいうとBYTEAなのでちょっと違う)

欠点はユニークインデックスとかプライマリキーに設定できないので
ユニークを求める場合は、別の手段でユニーク性を確保する必要があるってことかな
INSERTするときに NOT EXISTS を使って下記のようにしてやるとか

INSERT INTO test (id,value) SELECT 'ID-TEXT',1234567890 WHERE NOT EXISTS (SELECT true FROM test WHERE decode(substring(md5(id),1,8),'hex') = decode(substring(md5('ID-TEXT'),1,8),'hex') AND id = 'ID-TEXT');


DBの正規化してUUIDとかIDを振ってやる場合に同一のValueのレコードを持ちたくない場合に有用。Valueと同じ容量のIndex持ちたくない


物理的に壊れたHDDからデータを復旧する【上級者向け】

これは、2012年ごろに某所で公開されていたものですが
某所もつながらなくなり、原稿料ももらってなかった(笑)ので
元原稿も見つかったことなので、そちらからやや加筆修正しての再公開になります。

当時の日記はこのあたり
HDD壊れた
HDD復旧1台は
HDDサルベージ失敗
HDDデータサルベージ
続HDDデータサルベージ
続々HDDデータサルベージ
続々々HDDデータサルベージ



最初に


本稿は、きわめて上級者向けの内容になっております。
自作パソコンを組み立てた事がある、パソコンのパーツを交換した事がある程度の方は対象としておりません。
最低でも、ハンダゴテを握った事がある、電気回路に対してある程度の知識がある、HDDの構造と記録原理等を理解されている方が対象です。
そういうわけもありますので、基本的に細かい説明はありません。
本稿はあくまで、成功例があるという例の提示に過ぎませんので、本稿を元に作業された結果については、筆者は一切の責を負いません。悪しからず。
ただ、下記の考え方に納得できるのであれば、運が良ければデータを取り戻せるかもしれません。

  • すでにデータを失ったから、もう失うものは無い

  • すでに最悪の状況だから、これ以上悪くなることは無い

  • 恋人は排他的に占有しない限り、それは失恋したも同然」って考えの人でもOK :-p

  • 「BLOGのネタが出来た!」lol


上記の考え方に納得できない人は(納得できない人は、自分で何をやっても後悔します。他人に任せても、失敗に終わった場合、任せた事を後悔すると思いますが、他人に責任転嫁に出来るのでオススメ)、何もせずにデータサルベージ会社へご依頼ください。

fig-1

概要


モータがスピンアップしない壊れたHDDから、データをサルベージするのが目的。
HDDがOSから認識できる人は、この記事は役に立ちません。
電源事故によりHDDの基板焼損、HDDのモータが回転しない(HDDから回転音が聞こえない)、重度の物理障害の発生
ターゲットHDDは、WDC WD10EADS。
このモデル、一時期バカ売れしてたので、中古市場にも潤沢に出回っていて、同一ロットの入手が比較的簡単。
今回の作業環境、および、破損したHDDはFreeBSD8.2R + ZFS の環境で利用していたものである。
データサルベージの項では、コマンドやデバイス名がLinux等お使いの環境では異なる事があるので、注意されたい

準備するもの



  • HDDを分解するのに必要なドライバ、トルクス(ヘックスローブ)って名称のものが一般的
    (3.5インチHDDの場合 T-8,T-6くらいがあれば事足りると思うが、T-7やT-5が使われている事も)

  • 壊れたデータ入りのHDD 1台 HDD_X

  • HDD_Xと同一モデルのHDD (製造年月日、生産日が同じもの) 1台 HDD_A

  • HDD_Xと同一モデルのHDD (製造年月日が異なっても構わない) 1台 HDD_B データサルベージ先 壊れたHDDより大容量だと、モデル等は問わないが、意味がわかってないと、同一モデル手配するほうが無難

  • HDD_Xと同一モデル(または同一シリーズ)のHDD (壊れていても構わない) 1台 HDD_C 構造チェック用なので慣れていれば不要

  • 壊れたHDD以上に、十分な空き容量のあるローカルストレージ

  • 適当なUNIXライク環境(KNNOPIX等でもたぶんOK)

  • エアブロア等塵を吹き飛ばす道具、エアスプレーでもOK

  • カッターナイフ

  • マジックか、ラベル等、HDDを識別しやすくするためのもの

  • テスター 無くてもいいけどあったほうが原因究明は楽になるかも

  • ハンダゴテ 弱電用のリーク電流の少ないもの。fig-2ではガス触媒式を用意。 今回は不要だった。

  • ピンセット、ドライバ等工具類、非磁性のものだとベター



fig-2

手順


最初に


1.HDDにラベリングする。同一モデルばかりなので、混ざると厄介。特にHDD_XとHDD_Aは混ざると区別付かなくなるので注意。区別付くなら不要
2.作業前にHDD_Cを使って、手順、および構造の確認
やったことのある人は省略可、ただしモデル毎に仕様(プラッタ枚数等)が異なる場合があるので、確認のためしておいたほうがいいかも。(本モデルも、前期ロットは3枚プラッタ、後期は2枚プラッタだった)
状況確認

2. 壊れたHDDを分解するが、とりあえず、基板をはずして、目視で状況を確認する

2-1. 今回電源事故なので、テスターで当たりをつける。電源系でショートモードで問題が起きていたら、
デカップリング用のチップコンデンサ、回路保護用のダイオードを外すだけで動くかもしれない。
参考画像(fig-3)
これはHGSTのドライブ、5Vラインのダイオードがショートモードで焼けていたので、除去して通電してデータ回収。中央下部の空ランドが除去したダイオード跡

fig-3
でも今回はモータコントロール用と思わしき、ICチップが焼けていた(fig-4)。
コントローラが焼けたのみで、HDDのモータやヘッドのほうは無事かもしれない(希望的観測)。

fig-4
ここまで確認してから、部材を集めましょう。

修理 その1 基板交換



物理的な部分は生きているのだから、制御回路だけ取り替えれば、いけるんじゃない? 当然、焼けたICチップを交換すると言う方法もあるにはあるが、今回は、他の部分に影響が出ている事を鑑み、基板ごと交換することとした。
(注:一部のHDDは、基板スワップで起動すると、データに致命的な問題が起きる可能性があります。)

3. HDD_A から、基板を取り外す。
3-1. HDD_Xから基板を取り外す
3-2. EEPROMが乗っている場合はHDD_Aの基板にHDD_XからEEPROMを取り外し取り替える。(基板上のファームウェアとプラッタ上の情報が紐付けられている場合があるため)(fig-4 中央ネジ穴の左にある、8つのパターンがEEPROMのパターンぽいが、基板上の記号だとオペアンプらしい。このモデルはEEPROMがもともと付いてないようなので、そのまま交換)
3-3. HDD_XにHDD_Aから取り外した基板を取り付ける
3-4.通電してスピンアップして、なおかつ、PCに接続し、BIOS等で正常に認識すれば、項目「データサルベージ」へ
3-5. EEPROMを交換した場合は、元に戻す
3-6. 基板も元に戻す

修理その2 プラッタ交換



モータがスピンアップしない場合は、モータもやられている可能性が高いので、
スピンドルモータの交換だが、今回は基板もやられているので、プラッタを交換することにする
HDDは、塵を嫌うので、クリーンボックスやクリーンルームがあれば、利用することが望ましい。
本当は、普通の部屋で開けてはならない。でも壊れたHDDなので今回は問題なし。運が良ければデータくらいは吸い出せます。たぶんね。
HDD_Xのデータ入りのプラッタの埃への暴露時間が短くなるので、交換先のHDD_Aから先に作業すると良いかもね

4-1. HDDを蓋を開けるので、ネジの位置を確認し、密閉用のシールやラベルを剥がすか、切り取る(fig-5,fig-6)。

fig-5

fig-6

4-2. ネジを緩める。パッキン用のゴムが付いていて、密着しているので、ネジをとっても外れないことが多いので、確実にネジがないことを確認後、マイナスドライバ等でこじ開ける(fig-7)。

fig-7

4-3.ボイスコイルモータ(VCM)の上部磁石をはずす(fig-8,9)

fig-8

fig-9

4-4.プラッタの間にある整流板?(WD以外では見たことが無い)のネジを緩める。(fig-10)

fig-10

4-5.ヘッド保護のために名刺や画用紙の切れ端を折りたたんで隙間を保持する。(fig-11)

fig-11

4-6.ヘッドの稼働域を制限しているピンをはずす。ヘッドが自由に動くようになるので、ランプエリアからヘッドを退避(fig-12)

fig-12

4-7.ランプエリアを外す(fig-13)

fig-13

4-8.スピンドルからプラッタを外す為に、スピンドルのネジを抜く(fig-14)

fig-14

4-9.プラッタを固定していた部品を外す(fig-15)

fig-15

4-10. プラッタ類を完全に取り去る。 この際、スペーサの位置関係等を把握しておくこと。注:ここまで終わったら、外した蓋をとりあえず被せておきましょう。(fig-16,17,18,19,20)(ちなみにfig-16 は下部に指紋が付いてしまってますが、これは失敗です。指紋つけた場合はアセトンで洗えばいいかも。)

fig-16

fig-17

fig-18

fig-19

fig-20

4-11. HDD_Xでも上記の作業を行い、プラッタを取り出し、上下、裏表、順番が同じようになるように(プラッタの角度方向の同期は取る必要は無いと思う)、プラッタを取り去ったHDD_Aに組み付ける。この際プラッタのヘッド接触エリアには絶対に触れないこと、持つときは側面を持つこと。
この際、1枚入れるたびに、埃をブロア等で飛ばすと良い

4-12.逆の手順で、組みつけていく。ネジは対角で適当なトルクで締めましょう。(fig-21)

fig-21

4-13.ヘッドをランプに載せた後、ヘッドの位置を制限するピンを差し込む(fig-22)

fig-22

4-14.この後VCMの磁石を乗せ、蓋を閉めるが、蓋を閉める前に、一度全体をブローしておくと良い。左上のエアフィルタも付け忘れないように。写真では付け忘れた(fig-23)

fig-23

4-15.蓋を載せ、ネジを締める(fig-24)

fig-24

とりあえず、これでプラッタ交換作業は完了

データサルベージ


5-1. サルベージ元のHDD_X(プラッタ交換している場合はHDD_A’)と十分な空きスペースを持つHDDを接続し、HDDのディスクイメージを作成する
(直接操作しないのは、基板スワップや、プラッタ交換をしている以上、どんな不具合が後々発生するかわからないため。データコピーの間だけ使えればいい程度でしかない)

5-2. ddコマンドか、不良ブロックがある可能性があるのであれば、dd_rescue等を使う良い。ここでは、 dd_rescueを使う(なお、/dev/ad4はターゲットのHDDをつないだブロックデバイス)
# dd_rescue -A /dev/ad4 /mount/data/rescue.img

(-A オプションは、不良ブロックで読み取れなかったブロックを'0x00'でパディングするオプション)

5-3. 読み込みする。時間がかかるので、暫し休憩。1TBで最短4時間程度

5-4.完了したら、元のHDDを外し、HDD_Bを接続し、イメージを書き戻す
# dd_rescue -A /mount/data/rescue.img /dev/ad4


5-5. 書き戻すにも時間がかかるので、再び暫し休憩。
(注:判る人には判ると思うが、Disk to Diskで作業すれば、イメージの作成は省略可能である。ただし、後々の事を考えて、作成しておくほうが無難)

5-6. 物理的なサルベージ完了
物理的には問題はない状況なので、5-2の作業時点で不良ブロックが検出されていなければ、HDD_Xを利用していた読み書きできるOSにHDD_B接続すれば問題なく利用できるはずである。
この後の問題は、論理障害となるため、fsckやchkdsk等を駆使して、データを回収することになる。
5-2で不良ブロックが検出されている場合、一部のファイルの内容が破損している可能性があるため、重要なデータを回収し、中身をチェックしたほうが良い
今回は、物理的に壊れただけであるので、論理障害については発生してないので、本稿はここにて終了

追記


吸い出したイメージから復元したHDDではなぜかマウントできなかった(最終セクタあたりのメタデータのコピーに失敗したのかもしれない)ので、
私はプラッタを交換したHDDをそのままマウントしたが、イメージコピー2回と直接のデータ回収作業で約60時間程度で、HDDは壊れた事を記載しておく。
手元に残ったのは、一部メタデータ不足でマウントできないHDDイメージと、直接吸い出した、HDDデータ全体の40%である。
HDDイメージをマウントできればほぼ100%回収できたと想像されるので、少し残念な結果となったが、初めて(かつ、クリーンボックス外)の作業としては、重要と思わしきデータはほぼ回収できたので、結果には満足している。


なんかなー

たまたま動いてることと正しく動いてることの区別がつかないのはなんでだろう
仕様上は、B列を基準にソートするのが正しいんだけど
A列を基準にソートしても結果は同じになるんだけど
B列でソートしようとしたらDBの構造上、手間掛かりますやんとか言われて

なんと言ったらいいのやら
A列の並び順がたまたまB列と同じになってるだけで
そのA列の並び順は保証されてないんだけど
なんで理解してくれないのか…


水戸神社の例祭

還幸祭なんだけど、雨降ってる模様
相変わらず、毎年雨ってすごいな

豊作祈願とかなので雨であることが望ましいんだけど
毎年毎年雨ってすごすぎるわ


なんかしんどい

と言うわけで一日布団の上でゴロゴロしてた
風邪かもしれんなー
ちょっと注意しようっと


近所のお祭り

近所の水渡神社のお祭りなんだけど久々の土曜日なので
ちょっと見に行く

昔と変わらんな

久々に見た感じ


バルス!

久々のラピュタやってるので見てたりするけど
年々放送時間が長くなってる気がする

ノーカットになってるのかしらん?


赤組スピーチ

梅田のヨドバシの前で赤組がスピーチしてた

安保ってお前らみたいなのが居るから要るんだろうが
政党名から赤組の名前先に外せよ

拍手は定期的に上がるけど、タイミングが同じなんだよね
ドンだけサクラ投入してるんだろう?


ヒラマサオリンピックの地図

日本列島無くてワロタ

【2018平昌五輪】公式HPの世界地図に日本がない 「ひどい」「わざとか」日本人の怒りの投稿続々


平昌五輪の公式ホームページに掲載されている世界地図から日本がなくなっていることが27日、分かった。日本のツイッター上では「これはひどい」「陰湿すぎ」「政治利用するな」といった怒りの投稿が相次ぎ、なかには「ボイコットすべきだ」といった意見も上がっている。



話題になって炎上したらすぐに差し替えられててさらに笑う
これだけフットワーク軽いと言うことは意図的に組織ぐるみでやってたって証拠だからなー


フリーテル死亡

と言うことで通信事業は楽天に買収されることになりました

しかし売り上げ100億円に対して営業赤字が53億円ってスゲーな

最初の頃は結構真っ当だったけど、昨年末あたりから色々おかしくなったもんな
KIWAMIもまぁまぁ価格を考えるとお買い得、品質を考えるとまぁまぁだったのに
昨年末のアップデートでゴミと化し
Android7にアップデート歌ってた物はアップデートされず
雷神は発売日前日にエラッタがばらまかれ、エラッタが出るくらいだったらすぐにファームウェア出るだろって思ってたら、半年以上音沙汰無しで
出たと思ったら文鎮化する不具合有りで1日で公開停止になって早1ヶ月半

同じく事し2月に端末ロック導入してチェック出来るWEBページ公開するって言ってたにもかかわらず、公開されないので、端末はどこも買い取ってくれないっていうステキさ

ことごとく、ユーザを裏切り続ける以下略

考えてみれば昨年の今頃にはキャッシュフローヤバかったのかもね

端末の製造販売はプラスワンに残るらしいけど、近々精算されそうな予感


もう迷惑な

特急が行った後それを追いかける形で急行が出るんだけど
丹波橋駅を出発しない急行

次の(桃山御陵前)駅で前の電車止まってるとか行ってるし
停車駅でも無いところで特急止めるってすげーな

で5分ほどしたら動き出したんだけど
駅員さん2人くらいに囲まれながら2人のオッサンが口論してた
クソ迷惑な


小型の水循環ポンプ

名刺箱の半分くらいの水循環ポンプを買ってみる
それでも1時間あたり200Lの送水量があるのな

されこれを水苔育てる為に半腰水になってる水苔にくみ出してぶっかけてみる
循環してるけど高層湿原の環境が再現出来るかどうかやなー



日本橋徘徊

SDメモリ買おうか買わないか悩む
SANDISKのUHS-IIの250MB/s書き込みの128GBメディア
クソ高い

でも64GBだと心許ないんよねー

悩ましい