たにーの楽しい闘争

日々の気になる事を書いていきます

在宅勤務の方にワタミの宅食「まごころ御膳」を進めたい理由

サービス

ワタミの宅食を注文してから4か月が経ち、
本当に感謝しているので素晴らしい理由を綴りたい。

課題、要望

在宅勤務が始まって、最初に抱えた課題が昼飯だった。
ワタミの宅食に出会う前は、主に下記の課題があった。

  • 何を食べるか考えるのが手間
  • 自炊は調達して調理して食べるまで早くても30m‐1hかかる
  • 外食もなんだかんだ30m-1hかかる
  • デリバリーは選ぶ事が面倒、1食あたりの平均単価が高い
  • バランスの良い食事がとれている気がしない
  • 毎日美味しいものを食べたい
  • 毎日違うものを食べたい

検証

検証①片道徒歩3分の近所の個人経営のカフェに電話で毎日違うメニューを注文して、取りに行って自宅で食べる。
2週間くらい続けてみたが、下記の点しっくりこなかった。

  • 水曜が定休でその日は注文できない
  • やっぱり取りに行く作業が面倒
  • 家を出てから食べ終わるまで早くても30mくらいはかかる
  • 炭水化物多め
  • 味が普通
  • 値段も普通（800円くらい）

検証②片道徒歩5分のサイゼリヤでランチメニューを食べる。
3日程度続けたが、下記の点がしっくり来なかった。

  • 遠い
  • 家を出てから帰ってくるまで40分‐50分かかる

検証③徒歩0分のイオンで納豆と味噌汁、惣菜1品程度買い、米は冷凍しておいたものを温める。
3日程度続けたが、下記の点がしっくりこなかった。

  • 飽きる
  • 米がなくなったら炊かなければいけない （炊かない場合は包装米飯となるが、それもなんかやだ）

解決

4つめの検証として、
ワタミの宅食をスタートしたが、上記の課題をすべて解決できている事に気づいた。
感動した点を列挙していく。

  • スタッフが毎日同じ時間に届けてくれる
    （私の地域では11時頃）
  • 不在にする場合は、マンションの入口にボックスを置いておけばいいだけ
    （ボックスには保冷剤が入っているため夏でも全く腐らない）
  • 週単位で注文をお休みできる
    (旅行が入っていても問題なく対応ができる)
  • スタッフが良い人
  • 2分温めるだけで食べられるので、スタッフが届けてから食べ終わるまで10分程度しかかからない。
  • 管理栄養士が献立を設計しているため、バランスのとれたお弁当になっている
  • 毎日違うお弁当が届く
  • 美味しい
  • 1食580円（税込）という安さ
  • 万が一、昼に外食してもお弁当の賞味期限が22時のため、晩御飯にスライドできる
  • 家族と外食する時、家族が食べたい物に合わせられるようになった
    (今までは「最近魚食べてないから寿司が良い」とか要望を伝えていたがバランスの良い食事を昼にしているため、ほとんど自分の要望は伝える必要はなくなった)

これからも

在宅勤務が続く限りは、ずっとリピートしようと思う。
素晴らしいサービスを作ってくれてありがとうございます。

www.watami-takushoku.co.jp

「だからあなたも生き抜いて」を読んだ

本

著者の経歴が面白かったので読んでみた。

概要

中学2年の時にいじめを苦に割腹自殺を図る。
その後非行に走り、16歳で「極道の妻」になる。
結局夫とも離婚。
身も心もボロボロになった状態でホステスとして働いていた22歳の時、
小さい頃お世話になっていた父の友人（大平さん）と再会。
この再会をきっかけに中学の勉強からやり直し、宅建、司法書士試験に合格。
次第に人生を取り戻していく。
最終的に大平さんの支えもあり、29歳の時に司法試験に合格。
その後、少年犯罪を担当する弁護士となり、同時に大平さんの養女にもなった。

感想

度重なるいじめ、親からの愛情不足、親友の裏切り等によって、自殺を図る。
ただそれでも状況は変わらない...。
そりゃ、非行にも走るわなと。
それでも生きていれば、いつだって人生はやり直せるという事を証明した本。
ただ極妻時代に人を苦しめる側に回った話はなんとも言えない感情になったが、
この人のあらゆる局面での「覚悟」は勉強になった。

だから、あなたも生きぬいて

【SQLServer】ミリ秒を意識する必要性

SQLServer

今日一瞬ひやっとしたのでメモ。

内容

例えば下記のような状況があったとする。
1. DateTimeOffset型のカラムを更新する。
2. 更新後、AzureのServiceBusに更新した時間をメッセージとして送信する。
（メッセージ送信をトリガーとして動く他システムがあり、そのシステムは受け取った更新時間を条件に1のデータをselectしてまた別のシステムに送るようなケース）

こんな状況で例えば1ではミリ秒は捨てて更新、2ではミリ秒を含んで送信、といった実装もし間違ってしてしまえば更新対象のデータが他システムに連携されず問題になってしまう。
上記のようなケースでは両方ともミリ秒で連携する必要がある。

string strDto2 = DateTimeOffset.UtcNow.ToString("o");//正解  

string strDto = DateTimeOffset.UtcNow.ToString();//不正解

実行結果

2020-09-12T15:13:44.3869652+00:00
2020/09/12 15:13:44 +00:00

因みに、SQLServerでは色々と決まり事が複雑なため特に意識して注意する事が必要そう。
DATETIME型はミリ秒の3桁目は丸め込まれてしまったり、
DATETIME型は時間範囲が「00:00:00 から 23:59:59.997」だけど、DateTimeOffsetは「00:00:00 から 23:59:59.9999999」だったり。

参考

www.earthlink.co.jp

【SQLServer】SELECT TOPやUPDATE TOPを使う時はorder byを必ず付けなければいけない理由

SQLServer

結論

ランダムで取得されてしまうため。
ランダムでも良いのであればorderbyを付けなくても良い。

UPDATE文の書き方に注意

orderbyを使わない書き方

UPDATE TOP (10) HumanResources.Employee
SET VacationHours = VacationHours * 1.25 ;

orderbyを使う場合

UPDATE HumanResources.Employee
SET VacationHours = VacationHours + 8
FROM (SELECT TOP 10 BusinessEntityID FROM HumanResources.Employee
     ORDER BY HireDate ASC) AS th
WHERE HumanResources.Employee.BusinessEntityID = th.BusinessEntityID;

参考

docs.microsoft.com

docs.microsoft.com

技術を選択する上で注意したい事

何となく選んで苦しんでしまうケース

例①
実装に1週間かけた後のパフォーマンステストで性能に問題がある事が発覚し、違うやり方で実装し直す
例②
新しい技術を選んだは良いが、詰まってしまい、メンバーに有識者もいないため、解決するために予想以上の時間がかかってしまう

結論

このようなケースは事前に整理すれば避ける事ができる。 最低でも下記のような点は押さえておきたい。

f:id:tanii0207:20200830183051p:plain

この時に注意しなければならないのが、要件と期限。
例えば18時に起動するバッチ処理で日次の連携件数が100万件以下でその日中に連携されれば良いのであれば、技術Bを選んだほうが安全だと言える。
一方で1hで1000万件処理しなければいけない、等の要件があればAを選ぶしかない。（もちろんBで実現できないかも考える必要がある）

【SQLServer】本番データのバックアップ手順

SQLServer

手順

  1. データの出力件数を確認してバックアップがどのくらいの容量になるのかを確認する
  2. 容量によって出力先を決める（本番環境が望ましいが、空き容量によっては検証または開発とする）
  3. SSMSから本番DBに接続する
  4. オブジェクトエクスプローラーからデータベースを右クリック
  5. [タスク]から[データのエクスポート]をクリック
  6. データソースをSQLServerNativeClient11.0に
  7. サーバー名をエクスポートしたいデータがあるサーバー名を指定する（この時サーバー名は手入力にする。▼のアイコンを押してしまうと固まってしまう）
  8. データベースを指定する（これも手入力が望ましい）
  9. データの出力先（変換先）も手順6.7.8と同じように設定する
  10. すべてのデータをバックアップする場合は、[1つ以上のテーブルまたはビューからデータをコピーする]を押下
  11. 出力したいチェックボックスにチェックを入れ、変換先のテーブル名を変更する。（DBにテーブルやビューが多く混在している場合は注意する）
  12. すぐに実行するを押下し、完了

AzureStorageEmulatorを使ってAppendBlob.CreateOrReplace()を実行するとエラーになる時の対処方法

Microsoft Azure C#

状況

Azure Storage Emulatorのバージョン：5.7.0.0

やりたい事

AzureStorageEmulatorを使ってローカルのタスクテーブルから値を取得し、同じstorageAccountのBlobにAppendBlobを使って取得したレコードをcsvとして吐き出したい。

問題

下記が表示される

Message

{"リモート サーバーがエラーを返しました: (400) 要求が不適切です"}

ErrorCode

"FeatureNotSupportedByEmulator"

HttpStatusCode

"This feature is not currently supported by the Storage Emulator."

検証

今のバージョンではサポートされていない見たいなので、 下記からインストールしてバージョン 5.10に変更して解決

docs.microsoft.com

検証結果

まだ同じエラーが出る

結論

storageの向き先をAzureStorageEmulatorではなく、開発環境（既に発行されているStorageアカウント）にしたら正常に動いた。

AppendBlobはAzureStorageEmulatorではサポートされていないよう。

declined
How can we improve Azure Storage?
  • 187 votes
  • 9 comments

Provide support for append blobs in the Azure Storage Emulator

Currently Append Blobs aren't supported in the Azure Storage Emulator. Attempting an operation on an append blob returns a FeatureNotSupportedByEmulator error (HTTP status code 400 - Bad Request).

feedback.azure.com

教訓

  • 詰まったら文字に起こして頭の中を整理しよう
  • 最新のバージョンを使おう
  • ちゃんとエラーメッセージを細かく確認しよう
  • できれば公式ドキュメント読もう
  • 「サポートされていない」可能性も意識して調査しよう