切迫早産での入院生活を振り返って
切迫早産で約2ヶ月入院していました。入院の経緯についてはこの記事をご覧ください。
貴重な体験だったと思うので書き残しておきます。
入院生活について
入院中は陣痛が始まらないように、24時間点滴を打ち、ベットで過ごしていました。
立ったり座ったりする動作は控え、お風呂も週3回でした。
点滴には副作用があり、無気力、火照り、点滴痛、発疹に悩まされました。
この副作用は胎児にも少なからず影響があるので、子供に申し訳なく辛かったです。
早産になる方が点滴の副作用よりもリスクなので仕方ないと理解しつつも、自分の体質を恨む日々でした。
子供への影響が心配でしたが、問題なく成長してくれているので一安心です。
気にかけながら成長を見守りたいと思います。
入院中は4人部屋で過ごしていて、患者の入れ替わりはありましたが常に同室の人がいる状況でした。
物理的には一人っきりになれる時間がほとんど無く常に緊張した状態でした。
暇だし孤独感がハンパないなので交流したいと思いつつ、なんと話しかけたらいいのか分からず、最後まですれ違ったときに挨拶をするだけでした..。
たらればですが、同室の人と仲良くなれればもうちょっと明るく過ごせたのかなと思います。
入院中にやったこと
音楽を聴く
日頃は何かと忙しく、音楽は何かをしながらでしか聴けていませんでしたが、入院中は音楽だけを聴いて過ごすことができました。
じっくり音楽を楽しむことができてよかったです。
応援ソングを聞いて励まされていました。歌の力は偉大ですね。
病室での生活は季節感がないので夏ソングを聞いて季節を感じていました。
動画視聴
私が入院していた病院はポケットWifiの利用禁止かつ病室にフリーWifiが届かなかったので、フリーWifiを利用できる部屋に移動して動画をダウンロードしていました。
座ってるだけでも具合が悪くなる状況でこの作業は負担があったので本当に見たいものだけしか視聴できませんでした。
もし、入院がわかっていたら予めダウンロードしておくといいかもしれません。
大部屋の場合は他の患者が寝ているかもしれないので音を立ててはいけません。面白い動画を視聴する際は笑ってしまうのを堪える必要があるので大変でした。堪えるのが下手くそすぎて、一度看護師に泣いてると勘違いされて心配されました。
映画などの長時間ものは、2時間毎にある看護師の点滴チェックで視聴を中断されるため、あまり捗りませんでした。
読書
技術書や漫画を読みました。
ちょうどワンピースの無料配信があったのでイッキ見しました。入院中は巻数の多い漫画などの読破に向いてるかもしれません。
起きてる時間のほとんどをスマホ見て過ごして見飽きたときもあったので、紙ベースの本の読書は気分転換にもなり良かったです。
電子書籍派の私ですが、紙の本の良さを改めて感じました。
プログラミング
何もせず日々を過ごすのも飽きてくるので、能動的にできるものとしてプログラミングをしました。
夫と共同開発しているものがあったので、その開発を進めていました。
腕にある点滴が気になって集中できなかったのと長時間座っての作業ができなかったので、進捗はそこまで出せませんでした。今も完成を目指してコツコツ開発してます。
少しでも集中することで気が紛れたり、1週間以内にここまで実装するという目標を設定して頑張れたのは楽しかったです。
ゲーム
点滴があると気になって集中できず捗りませんでした。
点滴が気になる人には、連打必須のアクションゲームよりノベルゲームのほうが良さそうです。
泣く
一般的にストレス解消方法として涙を流すと良いと言われていますが、実際に泣くと少し気持ちがスッキリしてました。
しかし、大部屋では静かに過ごす必要があるので静かに泣く必要がありました。
また、点滴をチェックしに来た看護師に心配されるので泣くタイミングを考える必要があり大変でした。別に心配されたいわけではなく、エシディシのように泣いてスッキリしたいだけなのです。
大泣きしたいときはトイレに篭って泣いていました。トイレで泣くのは少し惨めでより泣けてきました。
いや〜。入院は辛いものですね。
Twitter監視
日頃も時間泥棒のTwitterですが、入院中はより時間を泥棒してくれました。
なかでも同じ切迫早産で入院している人のツイートは励みになりました。
同じ不安を抱えながら入院生活を乗り越え退院した旨のツイートを見たときは顔を見たこともない他人ですが嬉しくなりました。
私もいつかは同じように退院できると希望が持てました。
Twitter以外にも先人の入院ブログも励みになるのでよく読んでいました。先人には感謝です。
この記事も、少しぐらいは誰かのためになれるといいなと思います。
リアルに戦友が作れなくてもインターネット上で作れるので、この時代に生きてて本当良かったと思います。
日記を書く
毎日、日記を書いていました。
入院中の不安や悩みが書き出すことで、自分がなぜこのような感情を抱いているのかを客観的に見ることができて、ちょっとは心のモヤモヤを軽減できました。
最後に
退院して半年以上経過し、今は子供の成長に喜び、笑顔に癒やされ、幸せを感じる毎日です。
「喉元過ぎれば熱さを忘れる」とはよく言ったもので、入院生活に感じていた苦悩も今は大した事ないように思えます。1年後にはほとんど忘れてるんじゃないでしょうか。入院時の自分は色んなことに悩んで嘆いていたのですが、忘れてしまうものなのですね。
妊娠、出産を乗り越えた過去の自分に本当に感謝です。過去の自分のおかげで今が幸せです。
また将来の自分にも感謝してもらえるように、今を全力で生きていきたいと思います。
子宮筋腫持ちが切迫早産になった話
切迫早産や子宮筋腫を患って色々勉強になったので、そのことをブログに書きたいと思います。
現在、切迫早産で入院中です。
切迫早産とは、胎児が正期産前に生まれてくる可能性が高い状態のことを言います。
胎児はお腹の中にいる期間が長いほど生存率が高く、
22〜23週で生まれた場合の生存率が約66%なのに対して、30週以降になると生存率が約98%になります。
また、在胎週数が短いと身体の発達が未熟なため、障害が出現する可能性が高くなります。
なので早産を避けるために、入院しています。
切迫早産の原因はさまざまありますが、
私の場合は11cmほどの筋腫が子宮にあり、それにより子宮収縮が強くあり、早産のリスクが高いので入院しています。
この筋腫自体は妊娠前からあり、その頃は5cmほどでした。
産婦人科の先生に相談したところ、「経過観察」か「筋腫を切除する」かの二択を説明されました。
筋腫があったとして妊娠や出産は可能で、
筋腫を切除した場合は妊娠、出産時にその切除部分が破れる可能性(子宮破裂)があるとのことでしたので、
私は経過観察を選択しました。
妊娠中に筋腫の大きさが変化するかは人によって様々でしたが、私は大きくなったということです。(残念)
ちなみにですが、この筋腫は悪性の場合もあり、その場合の死亡率は高いので、自己判断せず経過観察する必要があります。私は良性でした。
子宮筋腫は女性の約4人に1人、切迫早産は約5人に1人がなると言われているそうです。
ですが、どちらも確実な予防方法や治療方法はありません。
今の医療が無ければ、私は妊娠や出産ができなかったと思うので感謝しつつ、今後のさらなる発展を願います。
私の現在の状態ですが、入院前にあった子宮収縮は落ち着いており胎児も問題なく成長しています。
まだ正期産まで週数があるので入院は続きます。
無事出産できるように安静にしつつ日々を過ごしたいと思います。
最後まで読んでいただきありがとうございました。
私信
この入院は緊急入院だったので、夫、親族、友人、会社の皆様にたくさん助けていただきました。
出産はこれからでまだまだ助けを頂きたく機会があると思いますので何卒よろしくお願いします..！
参考文献
知っておきたい早産のこと 早産を避けるためにはどうしたらいいの？ ｜民間さい帯血バンクナビ
婦人科豆知識：子宮筋腫と妊娠・出産 ｜ さがらレディスクリニック
PHPerKaigi 2020に参加しました！！
PHPerKaigi 2020に参加しました！！
PHPerKaigi2020楽しかったです！！！
以下、小学生の感想です！！！！！！
セッションについて
E2Eテストに向き合う
Puppeteerは使っていたのですが、Puppeteerチームの動向は追っていなかったので勉強になりました。
クロスブラウザやPWAでもE2Eテストができるようにぜひ頑張っていただきたいです。
PHPとEventSauceで始めるイベントソーシングアプリケーション
コマンドとイベントの違いがわかりやすかったです。
コマンド(命令形)→「光あれ」、イベント(過去形)→「光あった」
静的解析の育て方
すごいあるあるネタでした。自分のチームでも静的解析を育ていきたいと思います。
PHPerがこれから「型」とお付き合いしていくために
型システムは、安全性と効率、柔軟性はトレードオフ。
私が携わっている既存システムでは、PHPの柔軟性に頼っている実装もあるので、PHPDocを充実化していこうと思いました。
ぼっちからはじめるレガシーカルチャー改善ガイド 〜はじめの一歩編〜
えもい発表でした！「許可を得るな謝罪せよ」という言葉は流行っていますが、
それをしても許される人になるために信頼貯金は必要ですよね。
Webアクセシビリティを支えるための技術
Webサービスに携わる人間として、すべての方に、Webの機能を提供できるような実装、設計をしたいと思いました。
ページ速度保証の取り組みは「速度の高速化」に気を取られがちだったので、「タイムアウトの適切な設定」は目からウロコで、取り組んでいきたいと思いました。
PHPer Code Golf by pixiv
PHPerKaigi2020のイベントとして、PHPに特化したコードゴルフが開催されました。
以下が、コードゴルフが遊べるサイトです。
PHPerKaigi2020のためにサイトを開発されたそうです。
セッション周りは自作されたそうで結構たいへんそうでしたが、それが出来ちゃうのはすごいなと思いました。
問題は「Hello World」「FizzBuzz」「配列を展開せよ」が出題されました。
私は、PHPerトークン集めのためにコードゴルフとは言えないコードを提出...。
コードゴルフの解説は、PHPer Code Golf by pixiv 賞をとった方の記事があるので、そちらをご覧ください。
PHPerチャレンジ
PHPerチャレンジでは7位に入賞しました。
みなさまに会場内にあるコードを教えてもらったから獲れた賞だと思います。
一緒に探してくださった方ありがとうございましたー！
そして、コード入力締め切り1時間前に出題された「配列を展開せよ」を諦めずに解いてよかった！
あれで4000点稼げました。
PHPerKaigi 2020 前夜祭
今年見た映画「名探偵ピカチュウ」
『今年観た映画2019』https://adventar.org/calendars/4598 の12月18日 担当です！！
名探偵ピカチュウ
2019年公開
公式サイト
meitantei-pikachu.jp
予告動画
www.youtube.com
あらすじ
子供のころポケモンが好きだったティム(ジャスティス・スミス)は、ポケモンに関する事件の捜査から戻らないままだった父親のハリーが、事故で亡くなったと同僚のヨシダ警部(渡辺謙)から知らされる。人間とポケモンが共存する街、ライムシティにある父親の部屋を訪れたティムは、人間の言葉を話す名探偵ピカチュウに遭遇。ピカチュウは、ハリーが生きていると確信していた。
引用 ： シネマトゥデイ
感想
父親の亡くなったというところから映画はスタート！
ポケモン映画にしては暗くないか..！！と心配しましたが.....
大丈夫でした！ピカチュウかわいい！！画面がハッピーすぎる！！
ピカチュウが画面に出るだけでかわいいくて笑顔になってしまうのですが、
ちょっとおじさんぽいところもあって、そのギャップに更にキュンキュンしてきます。
事件の内容は父親の生死に関する事とちょっと重いものですが、
ポケモンのかわいさ＆コミカルさがマッチしていて、
軽すぎず重すぎというちょうどいい感じになっていました。
笑って泣けるいい映画でしたー！
また、生身の人間とポケモンが共存している世界が違和感なく描かれており、
見終わったあとに、世界のどこかにポケモンがいるのではないと思わせてくれました。
帰り道は「リザードンが空に飛んでないかなー」とか「マンホールの下にベトベトンがいたりして..」とか
ついついポケモンを探してしまいました。
子供ころに感じていたわくわくを思い出させてもらいました。
ポケモンがいる世界にはやくならないかなーと思っていたら、
12/17日に、ポケモンGOが相棒機能(マップ上をポケモンと一緒に歩ける機能等)をリリース発表！！
映画でみたポケモンがいる世界！そう遠くないかもしれませんね！楽しみです！！
その機能の予告がまたエモくて最高でした。時間があったら映画と合わせて見てください。
映画じゃなくてポケモンの話になってしまいました。。。
そろそろ、おわりだよー！
PHPerKaigi 2019に参加しました！！
3月29日から31日に開催されたPHPerKaigi 2019に参加してきました。
PHP歴は1年未満の見習いPHPerだったので、参加する前は場違いじゃないかと不安でしたが、行ってみるとすごい楽しめました！！
登壇内容も実用的なものが多くすぐに使えそうな情報が多くてよかったです。 仕事に取り入れてみたいと思います。 自分用の覚書に近い内容ですが、簡単に見たトークの振り返りをします。
3月29日 前夜祭
PHP でも Raspberry Pi がしたい！
PHPでもRaspberry Piがしたい！ @ PHPerKaigi 2019 - Speaker Deck
Raspberry Piは2012年発売で今年で7周年らしいです。 PHPで実装するとWebから簡単にRaspberry Piを制御できるのがいいですね。 デモ面白かったので、私もRaspberry Piで遊びたくなりました。
「質」の良いユニットテストを書くためのプラクティス
「質」のいいユニットテストを書くためのプラクティス / practices to write better unit test - Speaker Deck
Public Methodに対してテストをして、Private Methodに対してはテストをしないそうです。 Private Methodにテストをする時点で設計を考えなおすべきとのことです。 テストを書く時点で設計を見直すということは考えたことがなかったので、勉強になりました。
3月30日
フレームワークを作りながらLaravelのアーキテクチャを学ぶ
フレームワークはパーフェクトPHPの7章を参考にして作ったそうです。 パーフェクトPHPを持っているの読んで勉強します。
Laravelを使ったことなくファサードを知らなかったのですが、使うときは下記の特性に気をつける必要があります。
抽象化って何？
抽象化って何？ (What is abstraction?) - Speaker Deck
抽象化にはレベルあり、そのレベルが異なると不思議な文章になります。 プログラミングにおける抽象化においても、抽象レベルを統一するのが大事です。 「適切な命名」「 抽象度の統一」「 狭い範囲」を指針にプログラミングの抽象化を行うといいそうです。
たった1人のAPI開発 BEAR.Sundayで解決した課題たち
たった1人のAPI開発 BEAR.Sundayで解決した課題たち / PHPerKaigi2019_TrackB_1445 - Speaker Deck
プロダクトの理想と制約を掲げて選択していくことが大事とのことです。 コミュニケーションコストを下げるために、モックやドキュメントを用意するという考え方は勉強になりました。 BEAR.SundayのApi.Docを使ってみたいと思いました。
RESTのちから
RESTの力 / The Power of REST - Speaker Deck
URIがRESTだと思っていたので驚きました。 内容が濃くまだ自分自身の考えに落とし込めていないので、RESTの勉強をしたいと思いました。 発表のまとめがすごいかっこよかったです。
Swooleでフレームワークを高速化 - もう動作が遅いなんて言わせない！
Swooleはイベントループ式なので同じプロセスで各リクエストを行え、いちいちプロセスを起動しなくていいのがメリットです。 LaravelをSwooleサーバーで実行したら3倍の速度があったらしいです。 ですが、プロセスが生き続けてるので状態をリセットする必要があり、静的状態の扱いが難しいらしいです。
PHPerのための計算量入門
PHPerのための計算量入門 / Basic Knowledge of Time Complexity - Speaker Deck
負荷試験をやりましょうーて話でした。 大学の講義でアルゴリズムのときに計算量(O)とか算出していましたが、開発をするときにやってませんでしたね。 実際のコードを例に計算量オーダーを下げる方法を説明してくださったので、実務で使うときのイメージがつきました。
小学生の感想文かよと思える振り返りで申し訳無いです。 今回のPHPerKaigiの内容を完璧に理解はできませんでしたが、PHPを深く知れるキーワードは知ることができたと思います。
3月31日振り返りと全体のまとめは後日書きます！
指定ディレクトリ以下の「Shift-JISコード」を「UTF-8コード」に変換するスクリプト
Webサイトを十数年近く運用していると、昔作成したWebページを久しぶりに開いてみると文字化けしてたりってありますよね..？
大体の場合が、メタタグの文字コードがShift-JISなので文字化けしているので、UTF-8に変換すると治ります。
だけど、Shift-JISコードのHTMLファイルが、どのディレクトリにどれだけあるか分からないというカオスな状態......あったり.....基本はなかったりすると思います。私はありました。
いちいち、HTMLファイルを調べて、「Shift-JISコード」を「UTF-8コード」に書き換えるのは苦行だったので、
指定したディレクトリ以下の「Shift-JISコード」と「UTF-8コード」を変換するスクリプトをpython2とシェルで作りました。
pythonだとこんな感じ。
#coding: UTF-8 import sys import shutil import os import re import nkf argvs = sys.argv # コマンドライン引数リスト argc = len(argvs) # 引数の個数 # 引数チェック if (argc != 2): print 'prease type "python %s directory_path"' %argvs[0] sys.exit() r_path = argvs[1] # 指定ディレクトリ target_word = 'charset=Shift_JIS' # ファイル内の置換元文字列 new_word = 'charset=UTF-8' # ファイル内の置換後文字列 r_ext = '.html' # ファイルの拡張子を指定 # 指定ディレクトリ以下のファイル情報を取得 def find_all_files(directory): for root, dirs, files in os.walk(directory): yield root for file_name in files: yield os.path.join(root, file_name) if __name__ == "__main__": # ディレクトリ内から該当文字列を検索 for file_name in find_all_files(r_path): root,ext= os.path.splitext(file_name) if ext == r_ext: # 指定拡張子で検索 # 検索初期化 re_flag = False line_list = [] with open(file_name,'r') as f_in: # ファイル内を一行ずつ検索 for l in f_in.readlines(): line = nkf.nkf('-w8',l) # 文字コードはUTF-8にする if target_word in line: # 置換元文字列があった場合 re_flag = True # フラグON new_line = line.replace(target_word,new_word) # 置換 line_list.append(new_line) # 書き込み else: # 置換元文字列がない場合 line_list.append(line) # 書き込み # 置換元文字列があった場合 if re_flag: print file_name # 編集ファイル名表示 # バックアップ作成 bnk_f = root + "_bnk.html" shutil.copyfile(file_name,bnk_f) # ファイル書き込み with open(file_name,'w') as f_out: for row in line_list: f_out.write(row)
シェルスクリプトだとこんな感じ。短い。
if [ $# -ne 1 ]; then echo "prease type sh chang_content.sh directory_path" exit 1 fi for file_name in `find $1 -type f -name '*.html'` do sed -i -e 's/Shift_JIS/UTF-8/' ${file_name} # テキストの書き換え nkf --overwrite -wLu ${file_name} # 文字コードを変換 done
次は、文字化け修正後の確認・表示崩れのチェッカーを作成することですかね..？
diffコマンドでもいいのか？しっかり目視したらいいのか？難しいところ。
本当は、カオスなWebサイト構造をどうにかしたいよ〜ひぃ〜ん。
スペシャルさんくす
nkfについてアドバイスをくれたあっとんさん(@_atton)
pythonのコードレビューをしてくれたまえけん(@maeken2010)
に感謝！感謝です！
参考にしたページ
Pythonで再帰的にファイル・ディレクトリを探して出力する - Qiita
追記
あっとんがブログに書いてくれてました！
attonblog.blogspot.jp
