人生100年!生涯エンジニア人生!

楽しいエンジニア人生!

#技術書典 9 お品書き 迷惑メール徹底対策

技術書典9

技術書典9がオンラインで開催します!
期間は2020年9月12日(土) 10:00 ~ 2020年9月22日(祝)23:59 です。

既刊と新刊を頒布します。

サークル名:ブライトシステム

techbookfest.org

新刊:迷惑メール徹底対策 (頒布価格500円)

techbookfest.org

既刊:迷惑メールにされないメール設定方法 G Suite編 ダウンロード版(頒布価格500円)

techbookfest.org

特に新刊はメールを利用したことがある全ての人におすすめの書籍となっております!

  • ときどき届く迷惑メールにイラッときませんか?
  • 何で俺のメールアドレスを知っているんだよ!と思ったことありませんか?
  • 迷惑メールの対応方法を徹底解説!
  • そもそもメール使ってないけど・・・でも気になる?
  • オマケでメールの歴史まで学べちゃう!

よろしくおねがいします。

記名式Suicaの利用が無くなるとロックがかかる話(PASMOも) リモートワークあるある

結論

リモートワークになって半年すぎる時期になってきたので注意喚起です。
2020年3月からリモートワークになって、全く使用していない記名式SuicaPASMOがありませんか?

長期利用の無い記名式SuicaPASMOで列車から降りて改札を通ると閉まってエラーとなることがあります。
同様にお店で利用時も使用できませんとエラーになることがあります。
慌てずに駅で駅員さんにに「ロックがかかってしまいました、解除してください。」と言えば駅員さんが記名式SuicaPASMOのロックを解除してくれます。

無記名Suicaではロックされません。

どういうこと?

記名式SuicaPASMOなどの交通系ICカードでは、長期利用が無いときは個人情報保護のため自動的にロックがかかります。

公式には、そのようなことは発表していませんが、規約には、そのことを言っているのかな?という記載がありますので見てみましょう!
まずは「東日本旅客鉄道株式会社Suica電子マネー取扱規則」です。

www.jreast.co.jp

第6条 Suica電子マネーが利用できない場合の(5)に以下のようなことが書いてあります。

(5)ICカード等の発行事業者の定めるものに加えて、Suica電子マネーの利用又はSuica電子マネーのチャージのいずれかの取扱いを行った日の翌日を起算として、当社の定める一定期間これらの取り扱いが行われなかった場合。ただし、発行者が別に定めるところにより発行する記名人式のICカード等に限ります。

わかりにくいですが「ICカード等の発行事業者の定めるもの」とは列車利用のことです。
そして「当社の定める一定期間これらの取り扱いが行われなかった」とは半年という方が多いのですが、恐らく26週間の182日間だと思います。

26週間の根拠を探します。
東日本旅客鉄道株式会社ICカード乗車券取扱規則 第1編 総則」を見てみます。

www.jreast.co.jp

第14条 SF利用履歴の確認の(2)に26週間の文字があります。

(2)26週間を経過した利用履歴は、確認することはできません。

利用履歴は交通系ICカードに記録されますが、私は過去にカード式SuicaからモバイルSuicaに乗り換えているのですが、そのとき長期利用の無かったカード式Suicaを間違ってかざしてしまいロックを知りました。
その際にロック解除するとき駅員さんに「過去の利用履歴を確認することができなくなりますが、よろしいでしょうか?」と確認されています。
私はロック解除前に印字できますか?と聞こうと思ったけど、時間が無かったので聞いてないですけど、自動券売機では無理っぽい気がします。(誰か検証してください)

PASMOは?

PASMO電子マネー取扱規則」で確認しましょう。

www.pasmo.co.jp

利用制限 第5条の6.(2)に以下のようなことが書いてあります。

(2)記名PASMO又は当社が別に定める無記名PASMOにおいてはカードの使用又は電子マネーのチャージのいずれかの取扱いを行った日の翌日を起算日として、当社の定める一定期間これらの取扱いが行われなかったとき。

Suicaと異なり、PASMOでは無記名式でもロックがかかるようです。
一定期間については記載がありませんが、恐らくSuicaと合わせているような気がします。

まとめ

  1. 多くの方で2020年3月からリモートワークになり2020年9月で182日経過します。
  2. 列車利用、チャージ、電子マネー決済が182日以上無い記名式SuicaPASMOでは利用時エラーになりロックされる。
  3. ロックされたら駅にて駅員さんにロック解除を申し出る。(お店ではできません)
  4. 利用履歴は消えてしまう。(未検証)

10年間使用していないときは失効する

なお10年間使用していないSuicaの取扱に関しては公式に発表してます。
www.jreast.co.jp

PASMOは規約に記載してあります。
PASMOの失効 第12条に以下のように記載があります。

www.pasmo.co.jp

PASMOの交換、使用又はバリューのチャージのいずれかの取扱いを行った日の翌日を起算日として、10年間これらの取扱いが行われない場合には、PASMOは失効する。

CalorieMate to Programmer #うちこむ人にバランス栄養 msg19 をLinuxのコマンドでTranslateする

概要

『CalorieMate to Programmer #うちこむ人にバランス栄養』というプロモーションがありました。   www.otsuka.co.jp

その中には色々なプログラム言語でのメッセージがあります。

www.otsuka.co.jp

msg19のメッセージが、ちょっと変わっていてバイナリーコードです。
最初はプログラムコードかな?と思ったのですが、トップページから言語メッセージを表示すると画面下の「Translate」が出てきます。
その「Translate」を押下すると、BALANCED FOR HUMAN.と出ます。
バイナリーコードの正体は文字コードでした。

でも、エンジニアなので自分で作ったコードで、バイナリーコードをTranslateしたいですよね!!

手順

mac OSまたはWindows Subsystem for Linuxで動かすことを想定してます。

www.otsuka.co.jp

CUIモードに入って、バイナリーコードを取得します。
cd messagesと打ってからcat msg19.mdと打てばデータが取れます。
以下のようなデータが取れます。

 01000010 01000001 01001100
 01000001 01001110 01000011
 01000101 01000100 00100000
 01000110 01001111 01010010
 00100000 01001000 01010101
 01001101 01000001 01001110
 00101110

これをローカルマシンにコピーしてファイル化します。
そして、以下のコマンドを打ちます。

cat msg19.md | for n in `xargs`;do echo "obase=16;ibase=2;$n" | bc | xxd -r -p ;done;echo

BALANCED FOR HUMAN.と表示されました!

解説

やっていることは、こんな感じです。

  1. xargsで改行とスペースで区切られた標準入力を読み込み、スペースで区切られた1行の文字列に変換する。
  2. それをforに送り込むことで配列となり、ループするときに変数nに配列から抽出された文字列が入る。
  3. echoでbcコマンドに必要な文字列を追加する。
  4. bcコマンドで、2進数から16進数に変換する。
  5. xxdコマンドで16進数から文字列に変換する。

xargsでスペースで区切られた1行の文字列に変換しています。
forを使うことでスペース区切りは配列と認識され、nという変数にはループするごとに順番に配列から取得されていきます。
この仕組みを使うことで、パイプでつなげたbcコマンドやxxdコマンドを実行できるようにしています。

bcコマンドは色々なことができるのですが、今回はibase=2;を指定して2進数から、obase=16;を指定して16進数変換に使用しました。(順番は変えないでください)
xxdコマンドで文字列に変換すると書きましたが、このコマンドはデータを数値にダンプするもので、それをオプションの-rで逆変換しています。 (-pはプレーンフォーマットであることを明示するオプションです)
※xxdコマンドは16進数から逆変換できるのですが、2進数から逆変換ができないので、bcコマンドで2進数を16進数に変換します。

カロリーメイトCUIで遊んだら、本物のCUIでも遊んでね💖

Perl

cat msg19.md | for n in `xargs`;do echo "$n" | perl -e 'print pack("B*",<>)';done;echo

bcコマンドとxxdコマンドをPerlのpackに置き換えます。
バイナリーコードを文字に変換するのでpackを使います、2進数のバイナリーコードなので"B*"を指定します。
標準入力は<>で取得してます。

書いてて思いましたが、Perlのオプションを使うと、もう少し短くなりますし、Shellのforが不要になります。
やってみました、こんな感じです。

cat msg19.md | perl -ane 'foreach(@F){print pack("B*",$_)}END{print"\n"}'

-nでwhileモード、-aでオートスプリットモードで、@Fには配列が入っているので、それをforeachで取り出し$_をpackして表示するだけです。

Ruby

cat msg19.md | ruby -ane '$F.each{|value|print [value].pack("B*")};END{puts}';

Perl版と発想は同じです。
Rubyは$Fに配列が入ります。

PHP

cat msg19.md | php -R 'foreach(explode(" ",trim($argn))as$value){echo pack("H*",base_convert($value,2,16));}' -E 'echo"\n";'

PHP5でも動きます。

PHPはオートスプリットモードが無いので、その部分は実装しないといけないので、標準入力を$argnで受け取り、explodeを使って配列にしていきます。
packは2進数変換が無いので、代わりに16進数に変換するためbase_convertを使用します。
行頭のスペースが配列に入ってしまうので、trimします。

Vue.js版

こちらは、今までとは逆に文字列をバイナリーコードに変換します。
実際に動いているのは、こちらになります。
msg19.netlify.app

ソースはこちらです。
github.com

bootstrap5 とかも使ってます。

Python

cat msg19.md | python -c 'import sys;import struct;[([(print(struct.pack("B",int(value,2)).decode(),end=""))for value in list])for list in[line.split()for line in sys.stdin]];print()'

Python3で動きます。

PythonPHPと同じでオートスプリットモードが無いので、その部分は実装しないといけないので、事前にimport sysをしておいてから、標準入力をsys.stdinで受け取り、splitを使ってlistにしていきます、そのlistを更にforで回していきます。
文字列をintの第2引数で2進数を指定して数値化してからpackにかけます。
packは事前にimport structしてから実行します。
packの実行結果はバイナリーデータのままなので、decodeして文字列化します。
printは、そのままだと改行されてしまうのでend=""で改行を抑止します。

Python版は物凄くややこしくなっています。

CUIモード

おまけ CUIモードが楽しかったです。
www.otsuka.co.jp 暇があったら、やってみましょう!

view-sourceにも遊び心がありました。
Developer toolのconsoleにもメッセージがありました。
以下ネタバレなので、コマンド探しをしたい人は見ないでください。
なお、helpコマンドと、helpコマンで紹介されているコマンドは記載してません。

続きを読む

エンジニア成長戦略とイノベーター理論

イノベーター理論とは

エンジニア成長戦略を語る前に、イノベーター理論を簡単に説明します。

エヴェリット・ロジャース氏が、「Diffusion of Innovation」という著書の中で提唱しました。

革新的な新商品を受容する消費者層をその受け入れる順番とされて、その早さの順番に名称が付いています。

  • イノベーター(革新者)
  • アーリーアダプター(初期採用者)
  • アーリーマジョリティ(前期追随者)
  • レイトマジョリティ(後期追随者)
  • ラガート(遅滞者)

よく見かける図をGoogle Spreadsheetで描くとこんな感じです。(うまく描けない)

f:id:hideaki_kawahara:20200731115403p:plain

キャズム理論とは

そして、イノベーター理論に必ず出てくるのが、その商品が普及するかどうかの分岐点になる「キャズム理論」です。

f:id:hideaki_kawahara:20200731123922p:plain

キャズム理論では、イノベーターとアーリーアダプターが市場開拓者となり、キャズムを乗り越えることが市場を牽引する鍵となります。

エンジニア成長戦略に当てはめてみる

成長しようと思い立ったとき、自分のキャリアのために、採用しようとするテクノロジーが、どの分類に入るのか考えます。

雑に考えると、こんな感じです。
(具体的なフレームワークや言語名を出すと荒れるので、言葉を濁してます)

ここで注意したいのは「人気」というキーワードです。

今年の「人気開発言語」とか、そういうのよく見かけると思いますし、実際に「人気開発言語」では開発している人が多く、仕事も多いで、「人気な市場」となっています。

その「人気」の区分を「イノベーター理論」に当てはめてみると、「アーリーマジョリティ」に属していると思います。

ここでキャズム理論を思い出してください、「アーリーマジョリティ」はキャズムの遅い側に属していることになり、そのあとに来るのは「レイトマジョリティ」です。

「アーリーマジョリティ」と「レイトマジョリティ」は市場の68%もあり、各区分は大体5年は維持されるので、2つの区分を合わせれば10年で、この「人気の世界」に属していれば10年生きていけます。

仮に25歳ぐらいから「アーリーマジョリティ」で仕事を始めたとして10年後は35歳になっていて、そのとき「レイトマジョリティ」に飽きている可能性が高く、そうなると自分のキャリアを考えていることが多く、ここに「エンジニア35歳限界説」が存在すると私は考えます。

エンジニア35歳限界説を乗り越えろ

エンジニア35歳限界説を感じたら、エンジニアマネージャーの世界に行く方が多く、開発から少し身を引く感じになりますが、そんな方でも、またエンジニアを続ける人も殻を破るためにも、キャズムを超えて「アーリーアダプター」に踏み込んでみましょう。

アーリーアダプター」では「人気の世界」では無いので、ググっても情報は非常に少ないですし、開発は大変かもしれませんが、そういうのが好きな人には楽しいと感じると思います。

「エンジニア35歳限界説」を感じるとか、開発が楽しくないとか、ステップアップしたいと思ったとき、自分の居る位置が、どの区分に居るのかを確認して、「アーリーアダプター」に居ないとき、「アーリーアダプター」を考慮したエンジニア成長戦略を考えましょう。

疲れたら・・・

アーリーアダプター」に疲れたら、「アーリーマジョリティ」に戻っても良いと思います。

一度、「アーリーアダプター」行けたなら、「アーリーアダプター」と「アーリーマジョリティ」の間にあるキャズムキャズムじゃなくなります、気楽に渡れる橋がかかります。

Git 2.28.0 でdefault branchをmaster以外に変更する方法 init.defaultBranch を試す (2020年10月1日GitHubはdefault branchの強制変更)

git 2.28.0がリリースされた

BLM運動に対応したgit 2.28.0がリリースされました。
github.blog

gitのdefault branchを自由に変更できるという対応です。(他にも色々なバグフィックスもあります)
gitのdefault branchはハードコーディングされているということだったので設定を追加することで対応したようです。

default branchの設定が無いときはmasterのままで、default branchの設定が有るときは、その設定値になります。
どうなるのか?せっかくだから試してみました。

なお、GitHub ActionsのCheckoutプラグインは変更済みです。
kawahara-ci.hatenablog.com

git 2.28.0を試してみましょう!

適当なディレクトリーでgit initを実行します。
その後.git/HEADファイルを確認するとmasterのままです。
f:id:hideaki_kawahara:20200729175039p:plain

git branch --show-current で確認します。
masterのままですね。

f:id:hideaki_kawahara:20200731083404p:plain

gitのバージョンを2.28.0にアップデートします。
f:id:hideaki_kawahara:20200729173328p:plain

.gitディレクトリーを消しておいてから、git 2.28.0リリースブログに記載の通りgit config --global init.defaultBranch mainを打って設定を変更します。
そしてgit initを実行して、その後.git/HEADファイルを確認するとmainに変わりました!

f:id:hideaki_kawahara:20200729175216p:plain

git branch --show-currentで確認します。
mainに変更されています!!

f:id:hideaki_kawahara:20200731082802p:plain

~/.gitconfigファイルも設定が変わっていることが確認できます。
f:id:hideaki_kawahara:20200729183315p:plain

git config --global init.defaultBranch mainを使用しないときはgit init後にgit branch -M mainとしてください。

変わったことを確認したら、GitHubでrepositoryを作成してみます。
2020年7月29日の時点ではgit push -u origin masterのままです。
f:id:hideaki_kawahara:20200827171425p:plain

GitHubにpushしてみましょう。
試しにgit push -u origin masterと実行してもエラーになりますが、git push -u origin mainと実行すると成功します。
f:id:hideaki_kawahara:20200729180657p:plain

※なお、既存リポジトリーに対してgit initしてReinitializedしてもgit branch --show-currentの内容も.git/HEADファイルの内容は変更されません。
変更するときはgit branch -M mainを使います。

今すぐ、brunchを変える必要性は低いですが、将来的にはbrunchはmainに変わっていくだろうと思いますので、git 2.28.0 にバージョンアップしたらgit config --global init.defaultBranch mainと設定を変更しておくと良いと思います。

2020年10月1日以降に訪れた方へ

git push したらnew branch としてmasterが作られた!
f:id:hideaki_kawahara:20200827133925p:plain

そんな事がありましたか? 2020年10月1日に、GitHubではmaster branchがmain branchに強制変更されております。
慌てずにmain branchにmergeして、git fetch して git checkout main して git pull しましょう。

2020年8月27日更新 GitHubはdefault branch強制変更を表明

上で「将来的にはbrunchはmainに変わっていくだろうと思います」と言いましたが、default branchがmaster branchのときはmain branchに強制的に変更されることが発表されました。

github.blog

今後のためにもgit 2.28 をインストールしてdefault branchの変更設定をしておくことをオススメします。

登録済みRepositoryをmainに変更する

右側のメニューからSettingを選びます。
f:id:hideaki_kawahara:20200827122025p:plain

SettingからRepositoryを選びます。

f:id:hideaki_kawahara:20200827115343p:plain

Change default branch name now を押下すると自分の所有しているRepositoryを一気に変更します。
参加しているグループも一気に変更するので、変更するときは事前にグループでお話をしてからにしましょう。
以下のRepository個別対応が、今のところオススメです。

Repository個別対応

変更するRepositoryを選びます。
branch を押下する。
f:id:hideaki_kawahara:20200827120153p:plain

main と入力して、Create branch: main を押下する。
f:id:hideaki_kawahara:20200827120222p:plain

main に切り替わりました。
f:id:hideaki_kawahara:20200827120423p:plain

しかしdefaultには切り替わっていません。

f:id:hideaki_kawahara:20200827120532p:plain

branchesを押下すると、一番上にdefault branchがあるので、Change default branchを押下します。
f:id:hideaki_kawahara:20200827120758p:plain

mainを選択してください。
f:id:hideaki_kawahara:20200827120939p:plain

Updateを押下します。
f:id:hideaki_kawahara:20200827121022p:plain

確認画面が出ます。
f:id:hideaki_kawahara:20200827121107p:plain

完了です。
f:id:hideaki_kawahara:20200827121149p:plain

なお、コマンドでは既存Repositoryのdefault branch変更はできません。
コマンドラインでできるのはbranchの追加か、branch名の変更だけです。
branch名の変更をコマンドで行うときは以下のとおりです。

git branch -M main
git remote set-head origin main
git push -u origin main  

GitHubでデフォルトbranchをmainに変更したら。
以下のコマンドでmasterが消せます。

git push origin :master

おまけ

2020年8月27日にGitHubのサイトを確認するとbranchの新規作成後のメッセージでgit branch -M masterが追加されていました。
2020年10月1日からはgit branch -M mainに変わるでしょう。

2020年7月29日のスクリーンショットです。
f:id:hideaki_kawahara:20200729172708p:plain

2020年8月27日のスクリーンショットです。 f:id:hideaki_kawahara:20200827171425p:plain