読者です 読者をやめる 読者になる 読者になる

頭の中は異空間

生活を日々ハックしてよりよくするブログ

ヤマトの輸送量の問題について思うこと

 

ヤマトの配送量の問題がニュースになっています。

news.livedoor.com

news.livedoor.com

 

個人的な提案

宅配BOXだけではすぐにパンクしてしまって不十分なので、再配達の回数に上限を設けるべきだと思います。何度も再配達することは体力以上に「またかよ」と配達員をうんざりさせるはずです。気苦労のほうが耐えないでしょう。再配達を何度も利用出来なければなんとしても受け取ろうと、ユーザが工夫するはずです。※1

他には、即日配達が多すぎると思うのであれば即日配達は企業以外が利用できなくすればいいと思います。生きていて本当に緊急でものが必要になるときなんてそうそうないので。普通は数日間くらい待てます。どうしても当日中にというときなら自分から足を運んででも買いに行くはずです。

ヤマトは特にアマゾンからの圧力もありそうなので、プレッシャーも酷いと思います。少しでも配達員の苦労を和らげないと今後更に人員不足で即日配達が不可能になりそうな予感がします。何も工夫しなければ更に状況が悪化して、ヤマトがアマゾンと関係を解消しアマゾンが日本から撤退、ということも起こりうると思います。もちろん、今後ヤマトの配達員がいなくなればアマゾンが撤退しなくても同じことです。

 

※1 具体的には銀行の窓口が15時で閉まるなら昼休憩中に行く、役所が平日夕方までしかやっていないのなら有給を取ったりシフトをお願いするなど既にやっている人は多いです。

 

極端に不便になってほしくはない

だからといって届くのが毎回1週間先、などとなれば不便すぎるので、いちユーザとしては厳しすぎる規制はしてほしくありません。今は、配送業者とユーザが協力して工夫をする段階に来ているのではないかと思います。個人的には別に即日配達がなくてもそこまで困りませんが、人によっては非常に困るかもしれません。本当にそれがなくなって困る人がどれだけいるか知りませんが、心あるユーザなら即日配達が無くなった程度では騒がないでしょうし。ただ、何でもかんでも不便にすればいいというものでもないので工夫をしたほうが良いと思います。

 

ワガママなだけのユーザの言い分は聞かなくても良いのでは。

以前、こんな記事を書きました。

notwodaily.hatenablog.com

↑では一部の質の悪いユーザが業者を困らせている、という点について最初に触れました。今回もそれが言えそうです。

配送量制限にビシビシ文句をつけてくる人もいそうですが、あまりにも質の悪いユーザは受け付けないくらいでいいと思います。例えばゲーセンでも筐体をフリーズさせれば出禁になるでしょうし。接客業の人気がないのもストレスが半端じゃないのも一部の愚かなユーザのせいなのは間違いありませんし。ルールを守れる心あるユーザ(当たり前のことを当たり前に出来る人)のみに絞れば体力的には厳しくても精神的にはマシになると思っています。アホは自分がアホと気づいていないので(筆者も人のことは言い難い)、散々な目に遭って少しは学んで利口になるべきです※2。運送業に限ったことではないです。

 

※2 それが出来ないからアホなのかもしれませんが(笑)自覚がないのは救いようがありません。

 

まとめると

多少の規制は仕方ないとして、便利なサービスは残ってほしいです。サービスとして破綻する前に手を打ってほしい。まだまだ長く利用したいので。この負荷を緩和する処置が一時しのぎにしかならないかもしれませんが、やらないよりは絶対にやったほうが良いですね。使いやすいサービスにするために、今後は企業とユーザが協力し合うことも必要になってくるのではないかなと思った次第でした。

 

タバコが原因で悪影響が出ているなと思うものをいくつか。

 

タバコに対する規制が厳しくなっていくようです。学校や病院で禁止なのはわかりますが、飲食店まで全面禁止とはなかなかに思い切ったことをするものだな、と思いました。

筆者の周りは喫煙者だらけで、家族でも父と弟が喫煙者であり、友人も多くが(絶対数が少ない)喫煙者です。そんな付き合いをしてきたので嫌煙家ではありません。それに本気で嫌煙家になってしまうと色々と人付き合いで気苦労が絶えないんじゃないかと思います。今後規制が強化されて店などに行きづらくなっていけば、今度はある意味喫煙者に対する配慮をしないといけない場面も出てきそうです。主に友達付き合いや家族づきあい、会社付き合いで。離れた喫煙場所まで行って吸って戻ってくるまで待ってやらないといけない、など(笑)

正直な所、今までの体験からはタバコ自体がどうのこうのというよりも、それを吸っている人の方に問題が有るんじゃないかという考えもあります。そう思う理由をいくつか。

 

マナーの悪い人の存在

タバコを道端にポイ捨てしていたり、歩きタバコしたり、明らかに喫煙場所じゃないところで吹かしてたり。こういうマナー違反が見られれば当然、市民からの声は厳しくなる一方だし、それが続けば規制の対象になっても仕方がありません。一部のお馬鹿さんのせいでせっかくマナーを守っている喫煙者がとばっちりを食うと考えればある意味喫煙者も被害者といえるかも?

 

謎の喫煙休憩

デスクワークの人なら、仕事中に何度も席を立ってヤニを吸いに行く人を見かけたことがあると思います。ぶっ続けで仕事をするよりは休憩が必要なことはわかります。だからと言って用もないのに何度も席を立ったりそれがただの無駄話のためだと擁護しようがありません。しかも筆者の経験上そういう人は大概普段からろくな仕事をしていないので、悪いイメージがどうしてもつきまといます(笑)

 

火災の原因

三国志の著者の横山氏も寝タバコが原因で亡くなられているというのは有名な話です。ポイ捨てが原因で火事になる可能性もあります。

 

においの問題

タバコを普段吸わない人でも、特に居酒屋に行って帰宅して気づいたら着ていた服が物凄くヤニ臭くなっていたことがあると思います。新品のスーツだったりするとがっかりするでしょう。近くの席でプカプカ吹かされてしまってもそこで文句をいうのも難しいので、厄介な問題です。

 

 

健康面ではどうか?

よく受動喫煙があるからテロだと言う話になるかもしれません。確か自分自身もそういう類のtweetをしたことが過去にあります(笑)世界中で約1/10が受動喫煙によって死亡しているという話があるので、少なくともプラスにはなりませんね。多くの人が思っているとおり、身体に悪影響があるのは間違いないでしょう。他にも調べればいくらでも出てきますが、例えば約2年前の記事ですが、ジョンズ・ホプキンスメディスンの記事では早くタバコを辞めたほうが健康に良いと言っています。喫煙をやめることによって肺がんのリスクが低減されるという内容の記事です。引用すると、

According to a 2013 study in the New England Journal of Medicine, quitting before the age of 40 reduces your chance of dying prematurely from a smoking-related disease by 90 percent, and quitting by age 54 still reduces your chance by two-thirds.

の部分ですね。同記事では

The long-term health effects of e-cigarettes are currently unknown and under research, but studies have shown they produce short-term changes similar to traditional cigarettes. Although e-cigarette manufacturers claim their products are safe, their ingredient lists are often unknown and one FDA study found cancer-causing substances in half the e-cigarette samples tested.

とも言っています。電子タバコについての内容です。現時点では健康への影響について、はっきりしたことは言えないとのこと。ただ短期間での影響は従来のタバコと似ているそうなので、長期的にも従来より良いかどうか怪しいですね。

WHOのサイトや厚労省のサイトでも関連する資料を探してみると良いかもしれません。

 

喫煙者がいてもいいと思う理由

これだけデメリットばかり取り上げておいて変な話かもしれません。ただ喫煙者というだけで嫌われるのはやりすぎかなと思うのと、もう一つ理由があります。たばこ税の存在です。ちょうどたばこ税についてJTが解説してくれていました。同記事にもあるように年間で(グラフ的には小さく見えても)兆単位の税収になっていることを見ると結構馬鹿にならない数値です。もし1人も喫煙者がいなくなれば(そんなことはないでしょうが)この税収がなくなってしまうわけなので、それで他の税金負担が増えるのはどうかな、と。

 

まとめると

タバコはまさに、百害あって一利なし、ですね。

それでも、どこまで浸透しているのかわかりませんが、JTも分煙の取り組みをしているし、飲食店を完全に禁煙とまではしなくても良いと思います。今では飛行機内でも完全禁煙ですし喫煙者の肩身は狭くなる一方ですが、本当にマナーを守って周りに配慮出来る人に対しては嫌悪感を出さなくてもいいでしょうとも。飲食店側の立場からすればもし完全禁煙→喫煙者が一部来店しない→客の絶対数が減るので売上も減る→経営難、となるのは想像に難くありません。ということで結局、分煙にするなどキリの良いところで折衷案が出来て落ち着くでしょうけどね。

国庫金送金通知書が来てからやること

f:id:notwo:20170218083428j:plain

フリーランサーなどにはおなじみ、確定申告の時期になってきました。準備をしないといけません。

さて、それとは別に払いすぎた税金のキャッシュバックの手段として、「国庫金送金通知書」なるものが送られてきました。去年の分なので今更なのですが(笑)まあともかく、これが来てから何すりゃいいの?となりがちなので、簡単にメモを書きます。数万円戻ってくることはかなり大きいのでチャンスを逃さないように!

 

 

やること

書類に記載の郵便局に行って金を受け取るだけ。

ただ、この郵便局がどこかが問題です。例えば筆者の場合、ゆうちょ銀行本店品川出張所でした。駅チカなので助かりました。ところが最初にgoogle mapで調べると品川シーサイド無人ATMの出張所を指しており、これでどうやって受け取るんだ?と思ったものです。筆者が馬鹿だったのでしょうか?

 

場所について

記載の場所がわかりづらいなら、最寄りの郵便局でこれ受け取りたいんですが、とでも聞きましょう。案内の人か窓口の人が、どこの郵便局でなら受取可能なのか、親切に教えてくれます。

 

持ち物

  • ハンコ
  • 国庫金送金通知書
  • 送付書に記載のある住所と同一の住所が分かるもの→免許証など

後者の住所については引っ越し後だと残っていない可能性が高いですが、一応受取は可能です。照会に少し時間がかかってしまいますが...要するに本人が特定出来ればいいのです。

それにしてもまだハンコが必要なことに驚きです。もっと画期的なシステムを導入すればお互いに楽になるのに。古き悪しきシステムということですね。

 

注意点

郵便局に行くと、現地で現金手渡しされます。あまり金を持ち歩きたくない人はさっさと口座に入れるなりしましょう。

場所以外には受取の期限があります。送付書が届いてから1年以内にやらないと郵便局での受取が不可能になります。代わりにどうすればいいかは送付書にあるので、絶対になくさないこと。

iphoneが壊れた時に考えるべきこと

iphoneが去年いかれてしまったので、別のに変えました。そして今年また調子が悪くまた変えました。いい加減出費がひどくて嫌になります。通常、どのキャリアの携帯もサポート期間中だろうと本体を無償で交換、というサービスを提供しません。そこはまあ突っ込まないというより仕方ないとして、実際壊れたら購入の流れになるところですが、ここが考えどころです。金を無尽蔵に出せるわけではないので、よく考えて購入しないと泣きを見そうでね。

 

本当にすぐ買い換える必要があるのか?

ここでよく考えたいのが、実際にすぐ買い換える必要があるのか、人によってはなくてもそこまで困らないんじゃないかということ。特に筆者のように友人が少ない人には

高い金を出して買い換えるのが予算的にどうしてもって人は、借金して買う前に踏みとどまるべし。

一人暮らしなら、今やSkypeやLINEというアプリがあるではないですか。自宅デスクトップPCもしくはノートにそれを入れれば、普段外出しない人は事足ります。iPadなどのタブレット端末やMNP済みで電話が出来ないスマホ(SIMの入れ替えをするなら壊れた携帯と同じキャリアに限る。キャリアが違うならネット専用かな...)など壊れた携帯以外にポータブルデバイスを持っているなら、かつポケットWiFiを契約済みならそれを普段持ち歩いて必要な時にネットを見れば良い。電話についてもメールについてもLINEくらい今はネットリテラシーがない人でさえ当たり前に入れてますから、それで出来ればいいと思います。調べてみたら回線契約なしでも電話出来そうだし、やり取りも既読かどうか見れるのでLINEの方が便利。それが難しい場合は、後述のような中古の端末を購入するのが合理的。

実家暮らしなら、実家の電話番号を教えてそこにかけてもらえばOK。もしくは一人暮らしと同様の手段。

今時の人もそうでない人もFacebook/Twitter/LINEを押さえておけばどれかしらやってるはずなので、そこで連絡取ってくれって言うだけ。楽。少し古いですが総務省のサイトにもある通り、今やSNS経由の連絡は劇的に増えているので、使っていて当たり前くらいの感覚になります。だから意外と携帯の電話やメールがなくっても意外となんとかなっちゃいますね。メールについてはGmail, Yahoo mailなどのフリーメール機能もあることですからそちらを利用すればOK

興味があればこの方法でやってみてどうも不便だと感じれば購入したらいいでしょう。

 

買い換えるなら中古 or 新verが出た直後

今や毎年のようにiphoneの新型が発売されています。ITのニュースサイトやそれ関連のサイトを見ると、すでにiphone8の噂が出ています。

news.livedoor.com

gigazine.net

技術の進歩は早い!と実感しますね。さて新たにスマホを購入するなら、新型を欲しくなるかも。でもそれって本当に必要でしょうか?という疑問が。

筆者の場合、必要最低限のスペックと機能がどれかを調べます。つい最近までは譲り受けたiphone4Sを使っており、これが3GでしかもiOSバージョンの問題か知りませんが動作が半端じゃなく遅いのでかなりストレスでした。だからこそ、買い替えを決断しました。iPadMNP済み携帯も持ってますがこれはこれで別の用途に使いたいし、今持っているWifi端末は3月末には解約する予定っていうのもあります。

そこで今回購入したのはこれ

5Sも今は古いと言われるかもしれませんが、ほとんど傷がなく、税込送料込で15000円。中々悪くない買い物でした。

f:id:notwo:20170214005449j:plain f:id:notwo:20170214005457j:plain

6では2万円超えが当たり前だったので控えました。ちょっと探せばこのようにリーズナブルな価格で代替出来るものが見つかります。

もし最新版が良ければ、中古でなくSIMフリーが良さそう。とは言え今のところSIMフリー端末についてはまだ詳細を調べていないためここには書きません。既に他所の多くのブログやニュースサイトに取り上げられているとおり、大手3キャリアによる2年縛りの解除SIMロック解除義務化といったニュースは記憶に新しいです。従来とは大分料金体系も違っているので、購入前には改めて調べなおして損のない支払いプランを選択したいもの。今後もっとリーズナブルなプランを提供する業者が現れることを期待して、それまでは手元のスマホを長持ちさせてみてはいかがでしょうか。

 

そもそも最新でなくても困らない

スマホのトレンドを常に追っかけている人でもなければ常に最新、なんてのは不要かと。今使っている5Sで実用に耐えますし、事足りています。さすがに4S以前は無理がありますが。2017年2月現時点で出ている7も、故障しない限り現役でいられるはず。Androidでも考え方は一緒。買い換えるきっかけは故障以外にはどうしてもそのバージョンで特定のアプリが動かないとか、スマホ自体の動作がおそすぎるとか、最新バージョンのスマホがどうしても欲しい理由があるときに限るかと。多少古かろうが誰かに迷惑がかかるわけでもなし、こだわりがなければ買い換えずにずっと使うことは賢い選択だと思います。

 

まとめると

買う前に調べたり必要な機能が何か洗い出したりやるべきことはあるので、そんなときこそ冷静になろうって話でした。携帯代は削ろうと思えば削れる出費ですし、毎月のしかかってきますので、出来る限り工夫しましょう。

jQuery、JSまわりでよく起こすであろうバグをざっくりと。

f:id:notwo:20170108184111p:plain

焦ったり急いでコーディングしてると忘れがちで結構やらかしている事が多いミス。JSは自由度が高すぎる言語なので決まりをある程度設けないと滅茶苦茶なコードになってしまいますね。前に実際にやらかしたミスや今後も気をつけないと繰り返しそうな凡ミスの例を書き出してみます。

 

バグの温床

data, attr, propでのデータ取得(get)/更新(set)

qiita.com

上記事に分かりやすくまとまっています。それぞれどのような特徴があるかを知った上で使い分ければミスしません。

 

$(this)の中身

関数が入れ子になっていると起こりうる現象。thisの参照先が異なるためにバグの温床になりやすいです。他サイトでも説明されきってる感じですが一応。

// 実際には下記のように書かずに$(".hoge").on('change', ~~~と書きますが分かりやすくするために。
$(".hoge").each(function() {
  // ここの$(this)と
  $(this).find('input').on('change', function() {
// ここの$(this)は違う console.log($(this));
}); };

 

id読み込み時の挙動

id属性はuniqueである必要があるので、idが重複していた場合通常は正しくJSが動作しないはず。

昔のIEではJSの挙動がおかしくなっていましたが、ChromeFireFoxではなんと中で独自に解釈したのか、ID重複後もエラーを吐かずに動作していました。なぜなんだろう。。

最新Ver(現時点で55.0.2883.87 m (64-bit))のChromeで試しにやってみると、・・・

 <body>
<div id="hoge">最初のid</div>
<div id="hoge">2つめのid</div>
<div id="hoge">3つめのid</div>
</body>

に対して

f:id:notwo:20170108193008p:plain

この通り、動くみたいです。最初のidに合致する要素を取ってきています。

しかし異常な挙動であることに代わりはないので、うっかりダブらせてしまったら速攻で削除してやるべし。

 

true/falseの空判定

!!"false"

これはtrueになります。文字列のfalseもtrueもtrueとして扱われるので、わかりづらいです。文字列でfalseになるのは""のみ。関数や変数の中身で判定する時、文字列が返ってくるとわかっているなら必ず === ""の空判定をするべし。

もう一つ、勘違いしやすい判定として

if []

もしくは

if {}

これはfalseになるかと思えばtrue。if文にundefinedやfalse, nullが入れば当然falseとして扱われますが、[]/{}自体は中身が空にもかかわらず1つの空でないオブジェクトとして扱われるのが原因。配列を判定するとわかっていれば

変数.length > 0

連想配列jsonであれば

Object.keys(変数).length > 0

とすれば中身が空かどうか判定出来ます。

最後に、曖昧比較(==)と厳密比較(===)。前者は変数の型を半ば無視して判定するので、本来falseなはずがtrueにしちゃう。例えば

100 == "100"

これはCやJavaなどでは明確にfalseになるのですが、JSでは==を使う限りtrue扱いです。StringとNumberで比較して同一とか何の冗談だと。でも企業のコードでこういうの多いです。PHPとかJSみたいな動的型付け言語では変数の型がわかりづらいことで、バグの温床になります。関数に渡す変数の型が違ったせいでエラーを吐いていた場合、この変数の型違いによるものが起こりうるので、余程の理由(ってなんだ?)がない限りは厳密比較を使うべし。

 

null.~~

例えば要素取得してattributeへアクセスする場合。$("~~")が存在しない場合nullになり、null.attribute名でCannot read propertyとなります。

要素名をtypoによって引き起こすことはテストによって排除出来るので、動的な要素変更があった場合に起こりうるバグです。class名やid属性変更後は特に注意です。

 

find, closest等による要素取得

viewのツリー構造が予めわかっていればfindだけでなくclosest, next等で要素を狙って取得できますが、ツリー構造に変更があった場合はその取得の仕方も変えないといけません。id属性やclass属性で取得していればclass名、id名を変えない限り影響はないのでまだ安心です(変える時は注意)。

 

自由度が高いからと言って好き放題やらない

1つのロジックを作るのにも多くの手段がありますが、実際書き方1つ違うだけでシンプルできれいなコードにもクソコードにもなります。

クソコードの例としては

unkode-mania.net

を見れば大体わかりそうなものです。本当にひどい例です(笑)

そうならないためには、言語ごとに役割を明確にもたせておくのが良いかと。

 

他の酷い例

関数名とreturn内容が合ってなかったり

  // タイトルを返すと書いてあるのにコメントを返している
  function title() {
    ~~(処理)
    return comment;
  };

(残念ながら某所で↑の例を実際に見ました...)

HTMLにif, forなどの複雑な構文を埋め込む(erbとして書きます)

<div class="~~~">
<% if hoge %>
  <% fuga.each do |f| %>
    <span class="~~">xxx</span>
    <% if piyo >
      book = Book.find ~~
      ...
    <% end %>
  <% end %>
<% end %>
</div>

Viewの役割に複雑な構文を突っ込んでいるだけでなく、クエリも走らせています。これでは見づらくて仕方ない。

こういう酷い例を見たら多少リスクを犯してでもついでに直しておいて、次見た時読みやすくしておくのがまともなエンジニアってもんでしょう。リファクタリングで多少のミスが出てもそれが致命的なものでないなら、それは大した傷ではないと思います。寧ろクソコードが新しく生み出され続けることのほうが余程重症なので。

ここではJS、特にjQueryを使った際のバグについて書きましたが、他の言語でも色々ひどい例は見てきたので、また何か酷いのを見つけたら書くと思います(笑)

SESで受信したメールをLambdaを通して転送&S3に保存 - Lambda(Python)/S3/SES

 

SESを設定することでメール送受信が可能になります。ここでは受信したメールをS3に保存し、更に中身を転送してみます。

 

SES

ここではオレゴンのリージョンを選択します。認証済みドメインであればどんなメールアドレスでも使えます。ドメインの認証方法は

notwodaily.hatenablog.com

などを参照。

認証済みドメインを用いて、SESでメール受信する際にS3へ保存するトリガーを設定します。詳細なやり方は

docs.aws.amazon.com

に倣ってできます。

 

S3

メールを保存するためのバケットを用意します。LambdaのIAMで参照出来るようにプロパティでバケットポリシーを設定(Principalを"*"とか設定すればOK)。

この時点で、SESで認証済みのドメインにメールを何かしら送信すればS3に内容が保存されます。実際に試してみると、

f:id:notwo:20170101191043p:plain

 このようになるはずです。

 

Lambda(Python)

S3にメールが保存されたというトリガーを設定してその都度Lambdaの処理を走らせるようにfunctionを作成します。

function

f:id:notwo:20170101192409p:plain
f:id:notwo:20170101192415p:plain

上画像の通りに設定。

ここではS3から保存されたメールのオブジェクトを取得→中身を解析→SESで送信の流れで処理を書きます。解析でやることは主にread()したあとにsubject, body(plain text), body(html), fromの中身を取得することです。html形式とplain text形式の両方が含まれます(相手が対応していない場合はhtmlはないかもしれません)。

メール転送はsend_mailだけ、中身は単純です。ここで注意しないといけないのは、replyおよびSourceにはSESで認証済みドメインしか使えないということ。このため、もしfrom情報を含めたければsubjectかbodyのどちらかに仕込むことになります。

コードは下記。

 

code

from __future__ import print_function

import json
import urllib
import base64
import boto3

s3 = boto3.client('s3')

EMAIL_TO = "送信先アドレス"

def send_mail(from_address, reply, subject, body, html_body):
    client = boto3.client('ses', region_name='us-west-2')
    client.send_email(
        Source="noreplyなど、送信専用アドレス",
        Destination={
            'ToAddresses': [
                EMAIL_TO,
            ]
        },
        Message={
            'Subject': {
                'Data': subject,
            },
            'Body': {
                'Text': {
                    'Data': 'from: ' + from_address + '\n' + 'body: ' + body + '\n' + 'html_body: ' + html_body,
                },
            }
        },
        ReplyToAddresses=[
            reply,
        ],
        ReturnPath="noreplyなど、送信専用アドレス"
    )

def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.unquote_plus(event['Records'][0]['s3']['object']['key'].encode('utf8'))
    try:
        response = s3.get_object(Bucket=bucket, Key=key)
        mail = response['Body'].read().replace('\n','').replace('\r','')

        from_address = mail.split('envelope-from=')[1].split(';')[0]
        subject = mail.split('Subject: ')[1].split('To: ')[0]
        body = base64.b64decode(mail.split('base64')[1].split('--')[0])
        html_body = base64.b64decode(mail.split('base64')[2].split('--')[0])
        reply = "noreplyなど、送信専用アドレス"
        send_mail(from_address, reply, subject, body, html_body)
    except Exception as e:
        print(e)
        print('Error getting object {} from bucket {}. Make sure they exist and your bucket is in the same region as this function.'.format(key, bucket))
        raise e

以上です。細かく解説すると、

bucket = event['Records'][0]['s3']['bucket']['name']

でバケット名を、

key = urllib.unquote_plus(event['Records'][0]['s3']['object']['key'].encode('utf8'))

でファイル名を取得しています。LambdaのトリガーにS3を設定した場合必ずこれで取得できる構造になっています。

肝心の内容は

response = s3.get_object(Bucket=bucket, Key=key)
mail = response['Body'].read().replace('\n','').replace('\r','')

でメールオブジェクトを読み取ったあと、それぞれ

from_address = mail.split('envelope-from=')[1].split(';')[0]
subject = mail.split('Subject: ')[1].split('To: ')[0]
body = base64.b64decode(mail.split('base64')[1].split('--')[0])
html_body = base64.b64decode(mail.split('base64')[2].split('--')[0])

で送信元、タイトル(subject)、本文(body)、本文HTMLの4つを取得しています。元々のメールオブジェクトの中身は改行付きで1つの文字列として扱っておりわかりづらいので、mail = の行で改行を削除しています。そのうえで、ほしい情報を前後の文字列を見てsplit関数でうまいこと取り出しています。ゴリ押しですね...

S3のメールをダウンロードして中身のテキストを確認するとわかりますが、bodyの文字列がbase64エンコードされています。これをbase64デコードするために

base64.b64decode

を用いています。そのため、頭の

import base64

を忘れないこと!

これ以外の情報がほしければ、同様にsplitを使って文字列を切り出して取得する。

 

ここではS3にメールを保存しっぱなしにしていますが、メールが溜まってきたら容量は圧迫されるので、転送完了後に削除しちゃっても良いかもしれません。

情報は能動的に取っていかないと駄目だって話

 

また、失念しました。。受動的に(しかも勝手に)組まれてるスケジュールってかなり合わせづらい。せめて候補日を指定してもらって、そこからこちらが選ぶとかしないとね。自己管理能力がないで諦めて思考停止するのはもったいなさすぎます。

これは改善しないといけないな、と思いついたのと、同時にこれは自分への戒めの意味としても大事なことだから書いておかないと、と思って書いた記事です。

 

強く興味を持つ

好きなことに対しては自然と能動的になり、頭に残る。間違いない。

経験上、忘れっぽい筆者でさえ例えばガキの頃どんなゲームやってたか、とか最近だったらいつ飲酒したか、とかしっかり覚えています。本気で好きなことは忘れるはずがなくて、ネットサーフィンするにしても興味のある情報に関してはどんどんググって賢くなっていける(取る情報によりますが)。

逆に興味が無いことは何百回言われても忘れるし、めんどくさいとしか思わないので言われてもできないことが多いと思います。一方的に「勉強しろ」って言われて手が動く人も珍しいのでは。

 

自分が発信する側にまわる

予定を自分から組んでいって、参加する/しないも相手に促されるんじゃなくて自分からはっきり答える。これがベストかな。

そういう自分から発信する習慣をつけるためにはブログ書くでも良し、イベントやるでもよし、身内で発表会やるでもよし。行動力が試されますけど、よくよく考えてみたらみんな就活やるときだって自主的に情報とって自分から説明会予約したりインターンやったり面接とか試験受けに行くわけで。ということは誰にでも行動力は元々備わっていて、ある程度の危機感というかやらざるを得ない状況に追い込まれたら誰だってやるってことですね。

 

ほんの少しでも能動的な動作が必要

大事な予定があるなら頭に入れるでなくてリマインダーを設定するとか、なんでそれが大事なのか自分の頭で理解する。ほんとうに大事だとわかっていれば忘れるはずがないので。

もし自分が情報を発信する側にまわるなら、やることが厳密になって良いかもしれません。このブログでも書いていることは大したことはないけど、それでも自分から情報を発信していくことで頭の中が整理されるし、アホなことを書くとそれがそのまま晒されて恥をかくことになるので、自分が有名じゃないからってあまり適当なことは書きたくありません。つまり書こうと思ったらそれが正しいか、念入りに調べることくらいはする→正しい知識が身についていくというメリットが生まれます。

 

まとめると

些細な事から改善して、下手なミスをしないように、そしてそんな小さなことで恥をかかないように常日頃から意識しよう、そしてそのために情報は自分から積極的に取る週間をつけようという話でした。