コロナ禍に巻き込まれた世代を俯瞰するために表を作ってみたのですが、いまいち見にくかったので書き直したという話。
コロナワクチンの接種も有料化しており、すっかりアフターコロナの雰囲気なのですが、
春先に作った表がいまいち見にくいように思えましたので、書き直してみました。クリックすると拡大表示されます。
pdfファイルもありますので、参考までに。
表の見方ですが、『現在年度』が『2024(令06)』の行を見ると、
この年度に『大2』である『2004(平16)』年度生まれの列(世代)は、
上にたどると2020年度に高校1年生ですから、中学の卒業式が急遽中止された世代、ということになろうかと思います。
同様に、『現在年度』が『2024(令06)』の『中1』である『2011(平23)』年度度生まれ』の世代は、
小学校の中~高学年にコロナ禍が直撃した世代、ということが読み取れます。
この表はコロナ禍が小学校に影響を与えた年代までを書いています。また、学年凡例は四年制大学、大学院を想定して書いていますので、
高専系や専門学校、医歯薬系の大学などについては適宜読み替えていただけますと幸いです。
例によってオチとかはないです。
なにかやったら書くブログ
PC-UNIX系でちょこちょことしたことを書こうかなと思います。 当ブログでは Google アナリティクスを利用しています。
2024年10月26日土曜日
2024年3月23日土曜日
Z世代vsコロナ禍
コロナ禍に巻き込まれたZ世代を俯瞰するために表を作ってみました、という話。
そろそろコロナ禍も明けた体というか、 ポストコロナとかウィズコロナとか諸々含めて色々仕切り直しが本格化する時期なのかな、と思います。 で、先日職場の若い人達とざっくり表を作って回顧していたのですが、 その名残をWebにも残しておこうかと思い作成したのが以下の画像です。
二枚ありますが単に転置しただけなのでお好きなほうをご覧下さい。
たとえば『現年度:2020年』の行(または列)を見ると、その当時『M1』である『1997年度生まれ』の世代は、前年度はB4(学部4年)ですから、学部卒の卒業式が急遽中止された世代、ということになります。修士の入学式も中止だったと思います。同様に、『現年度:2020年』当時の『B1』である『2001年度生まれ』の世代は、まさにコロナ直撃世代で、高校の卒業式と大学の入学式が中止、しかもおそらく授業開始が若干遅れたであろう世代かと思います。この世代が学士号を得て卒業するのが『2023年度』であり、つまり今。ご卒業おめでとうございます。
『現年度』の行(または列)をたどっていくと、中学や高校の学修にコロナ禍が直接絡まないのは、いわゆるZ世代の次のα世代、2010年度以降生まれの児童生徒達になるだろうと思いますが、α世代はα世代で少子化や文化の変化が直撃している世代なので、これはこれで考えることが多い気がしますね。
表に乗らない、色々足踏みした人はそれはそれで良い経験でしょうから、頑張っていただきたいです。
オチとかはないです。
そろそろコロナ禍も明けた体というか、 ポストコロナとかウィズコロナとか諸々含めて色々仕切り直しが本格化する時期なのかな、と思います。 で、先日職場の若い人達とざっくり表を作って回顧していたのですが、 その名残をWebにも残しておこうかと思い作成したのが以下の画像です。
二枚ありますが単に転置しただけなのでお好きなほうをご覧下さい。
たとえば『現年度:2020年』の行(または列)を見ると、その当時『M1』である『1997年度生まれ』の世代は、前年度はB4(学部4年)ですから、学部卒の卒業式が急遽中止された世代、ということになります。修士の入学式も中止だったと思います。同様に、『現年度:2020年』当時の『B1』である『2001年度生まれ』の世代は、まさにコロナ直撃世代で、高校の卒業式と大学の入学式が中止、しかもおそらく授業開始が若干遅れたであろう世代かと思います。この世代が学士号を得て卒業するのが『2023年度』であり、つまり今。ご卒業おめでとうございます。
『現年度』の行(または列)をたどっていくと、中学や高校の学修にコロナ禍が直接絡まないのは、いわゆるZ世代の次のα世代、2010年度以降生まれの児童生徒達になるだろうと思いますが、α世代はα世代で少子化や文化の変化が直撃している世代なので、これはこれで考えることが多い気がしますね。
表に乗らない、色々足踏みした人はそれはそれで良い経験でしょうから、頑張っていただきたいです。
オチとかはないです。
2021年12月3日金曜日
最小の makefile を作りたい(改訂版)
小さいCプログラムのための makefile を作りたい、という話。
カレントディレクトリに main.c という簡単な C プログラムがあったとき、これをコンパイルして main という実行ファイルを作ることを考えます。 まあ cc main.c -o main で終わり、なので、
てことになるわけですが、やれここでコンパイル時にデバッグフラグだの、数学関数をリンクするだの言い始めると途端にオプションが増えます。
そんなときによく使われるのが makefile に書かれる変数なのですが、これもまた雑に調べるとオプションを指定する環境変数がごちゃごちゃしていて分かりにくい。 特に LDFLAGS と LDLIBS の扱いで混乱してしまい、困ってしまいました。 リンクするライブラリ(-lmなど)はソースファイルの後に書かなければいけないのですが、 LDFLAGSに書けばいいよみたいな資料が若干見当たり、その通りに書くとコンパイルできない(リンクに失敗する)という…
こんなとき役に立つのが make のデフォルトルールの表示です。 Linux の make (GNU make) には オプション -p があるので、
であることが分かります。一方、FreeBSDのmake (BSD make) はオプションと挙動が違いまして、 となります。このデバッグ出力は標準エラー出力に吐き出されますので注意してください。
いずれにせよ、
オブジェクトファイル .o を作る場合はどうなるのか? については、ルールの表示から探してみて、CFLAGS の付けかたについて考えてみるとよいでしょう。例えば、プログラム中で自作関数などが呼び出された回数や処理時間を計測するプロファイラ gprof を用いる場合は、コンパイラとして gcc を想定し、コンパイル時とリンク時の両方に -pg オプションが必要なので、たとえば
という書き方になります。main()があるソースコードのファイル名は拡張子をつけずに実行ファイル名とお揃いにしておく(prog.c に main()を書くなら実行ファイル名は prog とする)というのがポイントです。 これは、make -pで表示される暗黙のルールから、以下の二つが適用されて、main という実行ファイルが作られる、ということから確認できます。
カレントディレクトリに main.c という簡単な C プログラムがあったとき、これをコンパイルして main という実行ファイルを作ることを考えます。 まあ cc main.c -o main で終わり、なので、
てことになるわけですが、やれここでコンパイル時にデバッグフラグだの、数学関数をリンクするだの言い始めると途端にオプションが増えます。
そんなときによく使われるのが makefile に書かれる変数なのですが、これもまた雑に調べるとオプションを指定する環境変数がごちゃごちゃしていて分かりにくい。 特に LDFLAGS と LDLIBS の扱いで混乱してしまい、困ってしまいました。 リンクするライブラリ(-lmなど)はソースファイルの後に書かなければいけないのですが、 LDFLAGSに書けばいいよみたいな資料が若干見当たり、その通りに書くとコンパイルできない(リンクに失敗する)という…
こんなとき役に立つのが make のデフォルトルールの表示です。 Linux の make (GNU make) には オプション -p があるので、
であることが分かります。一方、FreeBSDのmake (BSD make) はオプションと挙動が違いまして、 となります。このデバッグ出力は標準エラー出力に吐き出されますので注意してください。
いずれにせよ、
- LDFLAGSはソースファイルより前に付く
- LDLIBSはソースファイルより後に付く
- .c ルールはソースファイル foo.c から実行ファイル foo を作る、というルールなので、program: foo.c などとだけ makefile に書いてもルールに合致しないので何も起こらない
ことが分かりますから、
- LDFLAGS にはライブラリの所在を表すパス(-L オプション)などを書く
- LDLIBS にはリンクしたいライブラリの実体なり -l オプションなりを書く
オブジェクトファイル .o を作る場合はどうなるのか? については、ルールの表示から探してみて、CFLAGS の付けかたについて考えてみるとよいでしょう。例えば、プログラム中で自作関数などが呼び出された回数や処理時間を計測するプロファイラ gprof を用いる場合は、コンパイラとして gcc を想定し、コンパイル時とリンク時の両方に -pg オプションが必要なので、たとえば
という書き方になります。main()があるソースコードのファイル名は拡張子をつけずに実行ファイル名とお揃いにしておく(prog.c に main()を書くなら実行ファイル名は prog とする)というのがポイントです。 これは、make -pで表示される暗黙のルールから、以下の二つが適用されて、main という実行ファイルが作られる、ということから確認できます。
(FreeBSDでは cc が clang の時に -pg オプションを付けると、正しく動作しない実行ファイルが出来て困ったので、念のため書き添えておきます。 )
gmake には .c.out ルールが標準で備わっていません。さらに、実行ファイルを作成するルールについても、よく見ると
となっており、実行ファイルに .exe とか .out をつけるようにはなっていません。実行ファイルのファイル名と、ソースコードなどのファイル名が異なるもの(sample という実行ファイルを main.c から作る、みたいな)だと途端にうまくいかなくなるわけです。また、この様子だと分割コンパイルを行う場合も、暗黙のルールには頼りにくいように見えます。
上記の点を踏まえ、さらに分割コンパイルを行うときのMakefile は、たとえば以下のようになろうかと思います。
main()関数を持つ main.c, 他の関数を持つ sub.c, sub.c が持つグローバル変数や関数プロトタイプの情報を他の関数に伝えるための sub.h から、
実行ファイル prog を作る例です。
EXEC が実行ファイル名をあらわす変数ですが、これが prog ではなく main なら、OBJS から EXEC を作る部分の LINK.o のルールは、main.o から main を作る暗黙のルールが適用となるため、不要となるでしょう。さらに、 main.o や sub.o の作成については暗黙のルールを適用できそうな気がします。これらのことを大胆に(ヘッダファイルの依存関係を省略するなどして)反映させると、上のMakefileは下のように若干短縮出来ます。
rm -fの後ろにアスタリスクを含めるのはうっかりミスで全てのファイルを消し飛ばすくらいのハイリスクなのでやめておいたほうがいいと思いますし、ソースコードの依存関係が分かりにくいので、しっかり書いたほうがよいでしょう。
登録:
投稿 (Atom)