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

楽しいエンジニア人生!

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

GitHub ActionsのWarning messageを修正する

気にしてなかったけど

GitHub Actionsで以下のようなWarning messageが出るようになった。

The "master" branch is no longer the default branch name for actions/checkout
Please pin to a specific version or use "main".

f:id:hideaki_kawahara:20200725011723p:plain

これはBLM運動により、GitHubはDefaultのBranchをmainに変更する方針となりました。
www.itmedia.co.jp

現状はGitHubは変わっていませんが、GitHub ActionsのCheckoutプラグインは変更されました。
github.com

確認して対応

CheckoutプラグインではIssuesの303にmainに変更することが書かれています。
変更するのはwork by July 24th. とも書かれており、Issuesもcloseされているので変更済みです。
github.com

それでは対応方法です。
WorkflowファイルのCheckoutプラグインのところを以下のように変更するだけです。
- uses: actions/checkout@master

- uses: actions/checkout@main

今のところCheckoutプラグイン@mainとしてもmaster branchをCheckoutしてくれるけど、その機能が無くなったらmaster branchの名前を変更する必要があるかもしれません。
その辺りは、CheckoutプラグインではIssuesをウォッチしていくしかないかなと思っております。

ファミコンは卓越した性能だったと思う(ゼビウス移植ブームにからめた話)

ファミコンに関するツイートが回ってくる

ファミコンは卓越した性能という、ファミコンに関するツイートが回ってくる。

ファミコンは卓越した性能は、私も同感に思っております。
当時は少年だった私がゲームセンターに行ってて、そこからファミコンがどういう存在だったことを思い出して書いてみます。
私個人の気持ちで正しいかどうかは抜きにして、少年が純粋に思えるところを感じてくれると嬉しいです。

ファミコンの正式名称はファミリーコンピュータですが、ここではファミコンと表記します。

ゲームセンターに行く毎日

当時の私はゲームセンターに行きまくってました。
お小遣いに余裕が有るわけではなかったので、なるべく遊び尽くすために、色々な人のプレイを見て研究してからプレイしていました。
※お金がつきると、電気屋に行ってパソコンを触り、そこでプログラミングを学んでいました。

今も変わりませんが、ゲームは、ちょっとしたことゲームオーバーになってしまうので、長時間プレイするためには研究が大事でした。
そのため、今でも当時の記憶が残っています。

1982年

ファミコンが発売される前年、ゲームセンターの代表的なゲームです。

ゲームセンターのゲームは、ディグダグの地形の鮮やかさ、ザクソンのスクロールするクォータービューの背景など「絵がきれい」という印象と、ディグダグのポンプ音などの「音がリアル」という印象が非常に強かったのを覚えています。

なお、私の家には、遊び飽きたカラーテレビゲーム15任天堂)があり、友達の家にはカセットビジョン(エポック)がありました。
当時の家庭用ゲーム機では、こんなに凄いゲームセンターのゲームが遊べるわけがない、これが当時の率直な感想です。
カセットビジョンで遊んだことはありますが、正直言ってしまえば、当時のゲームセンターのゲームが遊べるとは到底思えなかったです。

1983年

ファミコンが発売された1983年のゲームセンターの代表的なゲームです。

この年に、社会現象を起こしたゼビウスが登場します。
当時はゼビウスを求めてゲームセンターを徘徊する人や、ゼビウスを見付けた!と思ったらコピー基板ゼビオスだ!とか、そんなこともこの年です。

1984

1984年にはゼビウスのファンである細野 晴臣氏が「ビデオ・ゲーム・ミュージック」という業界初のゲームミュージックアルバムを発売し、オリコンヒットチャートにランキングされるなどもありました。

そして1984年はゼビウス移植ブームの始まりでした。
タイニーゼビウスというのがNECのパソコンPC-6001電波新聞社から発売されました。
このタイニーゼビウスは読者投稿で、ハードウェアの制約上完全移植にはならないがゼビウスのテイストを感じさせる内容でした。   

電波新聞社は次に完全移植という触れ込みで、シャープのパソコンテレビX1にゼビウスが移植されました。
X1はキャラクター文字をカラーで定義できるPCGを持っており、これをゼビウスの背景に利用してガタガタしてしまいますが、きれいな背景がスクロールするゼビウスが完全移植されたのです。
※これはハード上の制約ですが、その制約を乗り越える技として、50ライン表示にして4ドットスクロールというのを駆使しています。
実際に、X1版のゼビウスは物凄い完成度で、のちの電波新聞社の移植無双に続いていきます。

その後、開発元ナムコが直接ファミコンに移植されました。
効果音も格段にリアルに再現され、何よりもゼビウスの背景がなめらかにスクロールするのは衝撃で、多くの人がファミコンを購入させるほどでした。
ファミコン版はステージ4などに登場するアンドア・ジェネシスは背景に書き込まれておりスクロールが停止して戦うのですが、何故かアンドア・ジェネシスが登場してからスタートボタンを押すとスクロールが停止せずに先に進んでしまうという仕様があり、これも話題になりました。

当時、X1はX1Csが発売されており価格は119,800円で、ファミコンは14,800円で、価格差もあったためパソコンを持っていない人はパソコンよりもゲームに向いたファミコンを選ぶようになっていきました。

ファミコンが売れる要因は他にも多くありましたが、ファミコンゼビウスが登場したことで、ファミコンの卓越した性能が証明されたのも1つの要因でした。
わかります? 当時、高性能なゲームセンターのゲームがファミコンで動くんですよ!!
少年でも感じる率直な気持ちですが、ゼビウスの移植を通してみるとファミコンは卓越した性能だったと思います。