ARCでメモリリークを起こさないようにするために
先月objective-cなるプログラミングを始めた自分にとって
objective-cはARCを使っていますというのは
そういうものなんだふーん。
って感じだったんですが
思っていた以上にこれは重要なことのようです。
よくよく調べてみるとARCかどうかに関係なくメモリ管理については注意が必要なようです。
特にメモリを沢山使うゲームのようなアプリでcocos2dを使わないでメモリ管理をする今回のようなケースにおいては特に重要だと思っています。
例えば「autoreleaseされたインスタンス」です。
実際にはautoreleaseというキーワードはソースコードの中で使いませんが、
一般にオブジェクトをインスタンス化した瞬間にautoreleaseされたオブジェクトと認識されるようです。
具体的には以下のようなケースです。
for (int i = 0; i < 100; i++) {
NSData* data = [NSData dataWithContentsOfFile:@"..."];
}
このようにループの中で新しいインスタンスを生成すると
ループ(スコープ？)の外に制御が移っても
このインスタンスのメモリが解放されずに残ってしまうらしいのです。
(制御が移るっていう言い方が正しいのか分かりませんが)
http://qiita.com/amay077/items/95a4139e6f553d8a56a1
この場合、以下のように@autoreleasepool{}でくくってやれば解放されます。
for (int i = 0; i < 100; i++) {
@autoreleasepool {
NSData* data = [NSData dataWithContentsOfFile:@"..."];
[NSThread sleepForTimeInterval:0.5];
}
}
あとは個人的にハマったのは
importされているクラス側でimportしてしまう等の「循環参照」の問題です。
これについては次回書きます。
他にも
・[UIImage imageNamed:@"..."]を使用しない(イメージデータが保存されたまま解放されない)
等の注意点もあるようです。
もしARCでなかったら手動でメモリを管理しなければならないので
ARCの導入によって一見便利になった一方で、
こうしたメモリ管理も十分に気をつけて開発しなければいけませんね。
続きます。
CAEmitterLayerでゲームオーバーエフェクトを実装してみる
非エンジニアでプログラム初心者のニートが30日間でゲームを作るという企画を勝手に進めています。
前回までのあらすじ
・iOS Developer登録(申請篇、アクティベート篇、完結篇)
・主人公決定！
年始からプログラミングを始めて既に30日が経過している気がしますが、
そこらへんは軽くスルーして引き続き開発を続けています。
今回はプレーヤーが敵機に衝突して
ゲームオーバーになったときのエフェクトについて作成しました。
エフェクトにはパーティクルというものがあるということを
グーグル先生に教わりました。
勉強してみた私なりの解釈では
パーティクルとはエミッターと呼ばれる放出機から爆発の炎のエフェクトや
煙のエフェクトを表現するための描画システムです。
具体的なエフェクトの設定はこちらのサイトが参考になりました。
まず、基本のやり方を踏襲して簡単なエフェクトクラスを作成してみました。
詳細な設定は上記サイトに記載してありますが、
ざっくりやったことを書いてみます。
まず最初にQuartzCoreヘッダーをインポートします。
#import "QuartzCore/QuartzCore.h"
まずはエミッターオブジェクトを
CAEmitterLayer *particleEmitter;
のように宣言してやります。
エフェクトクラスの初期化部分はこうしました。
particleEmitter = (CAEmitterLayer *) self.layer;
particleEmitter.emitterPosition = CGPointMake(0, 0);//CGPointMake(frame.origin.x, frame.origin.y);//CGPointMake(0, 0);
particleEmitter.emitterSize = CGSizeMake(frame.size.width, frame.size.height);
particleEmitter.renderMode = kCAEmitterLayerAdditive;
CAEmitterCell *emitterCell = [CAEmitterCell emitterCell];
emitterCell.birthRate = myBirthRate;//火や水に見せるためには数百が必要
emitterCell.lifetime = 0.5;
emitterCell.lifetimeRange = 0.5;
emitterCell.color = [[UIColor colorWithRed: 0.5 green: 0.1 blue: 0.1 alpha: 0.1] CGColor];
emitterCell.contents = (id) [[UIImage imageNamed: @"Particles_fire.png"] CGImage];
emitterCell.name = @"fire";
emitterCell.velocity = 50;
emitterCell.velocityRange = 20;
emitterCell.emissionLongitude = M_PI_2;
emitterCell.emissionRange = M_PI_2;
emitterCell.scale = 0.3f;
emitterCell.scaleRange = 0;
emitterCell.scaleSpeed = 0.5;
emitterCell.spin = 0.5;
particleEmitter.emitterCells = [NSArray arrayWithObject: emitterCell];
次にエミッターを返す部分です。
+ (Class) layerClass //3
{
//configure the UIView to have emitter layer
return [CAEmitterLayer class];
}
パーティクル表示中で放射方向を変えたい場合は
以下のようにします。
-(void)setEmitDirection:(float)_direction{
[particleEmitter setValue:[NSNumber numberWithDouble:_direction]
forKeyPath:@"emitterCells.fire.emissionLongitude"];
}
これを外部から呼び出してやれば、
エフェクトを表示しているUIViewControllerからでも任意方向にリアルタイムで
放射方向を自由に変更出来ます。
また感の良い方なら分かるかもしれませんが
同様に色を変える場合はキーパスを以下のように指定して、
@“emitterCells.fire.color
更にバリュー値はid型に変換してあげてこのようにしてあげます。
setValue:(id)[[UIColor colorWithRed: 0.5 green: 0.1 blue: 0.1 alpha: 0.1] CGColor]
まずは簡単な主人公が死んだ時の死亡エフェクトを作りました。
死亡エフェクトは中央が白、爆発のふちになる程、赤くなるようにしました。
実際の様子が⬇です。
地味ですね。。真ん中に赤い火の玉のようなものが表示されるだけです。
いろいろ色や形を変えてみたりしました⬇
少しエフェクトっぽく見えてきたでしょうか。
そのプログラムと合わせて実際にプレーヤーが敵機に衝突した時に
この赤いパーティクルを表示させてみました。
衝突検知はコチラでやったものを採用しています。
あと、迫力を出すために自動で縦スクロール中の背景イメージも
一旦停止させて横方向に振動させるようアニメーションしてみました。
どうでしょうか。。
動画撮影と合わせたシミュレーション上での実行結果なので
若干画面がカクカクしていますが、実機では結構滑らかに実行できていました。
NSTimerで推奨される時間間隔について
前回、アニメーション中に衝突検知をするために
NSTimerを用いていると書きましたが、
今回は少し詳しく書こうと思います。
タイトルは正確には
「NSTimerで非推奨となってしまう時間間隔について」
ですね。。
まず、教科書通りのNSTimerの呼び出し方を書きます。
NSTimer *tm = [NSTimer scheduledTimerWithTimeInterval:0.3f target:self selector:@selector(doNext:) userInfo:nil repeats:YES ];
これによって
doNextメソッドが0.3秒間隔で永遠に呼び出されるわけです。
前回の記事でアニメーション中の衝突検知を
このNSTimerで行っていると書きましたが、
実際には敵機とビームの進行速度と衝突検知の時間間隔次第では
ビームが敵機をすり抜ける可能性もあるので、
この数字がどこまで短くできるのか気になります。
少し調べてみました。。
日本語の解説ページがあまりなかったのですが、
こちらのハウツーサイト(英語)では以下のように書かれています。
なぜこの質問を選んだのか突っ込まれるかもしれませんが、
「nstimer second interval」で検索して最上位だった記事です。
<質問>
ナノ(0.000000001)秒間隔で処理を実行する方法について
<解答>
NSTimerはナノ秒間隔で処理を実行することはできなくて、恐らく(それを無理矢理やったとしても)期待される結果を得ることはできない。
最も短い実行間隔は0.1ミリ秒で、それよりも短い間隔を指定すると0.1ミリ秒に設定される。
(その後はOSの実行間隔より短くなることは出来ないとか、システムビジー状態ではそれより遅くなる的なことが書いてある)
0.1ミリ秒ってめちゃくちゃ速い気がしますが、
この解答には11って数字が着いていて
たぶん11人が参考になったってことだと思います。
なのでこの数字も全く見当違いってことでもなさそうです。
あとはコチラ(英語)が参考になりました。
この中では、NSTimerは極めて限定的な機能しか持たず、
プログラムの実行状況にもよるが最低0.05秒から0.1秒間隔が推奨されている、とありますね。
(※それにしても回答者の歪んだgif画像の人はいろんなところに出てきますね。すごいです)
結論として0.05秒間隔より短いタームで実行すると良くないことが起こりそうですね。
それより短い間隔で何か処理を実行する場合は別の方法を考えなければならないようです。
animateWithDurationで敵が迫り来る感じを出す
前回までに
主人公を表示させて動かしたり、ビームを出すことなどをしてきましたが、
今日は敵機を襲来させてみました。
まだ敵に対してダメージを与える機能は実装できてませんが、
ビームと敵機の衝突判定部分を作ってみました。
当たってはいるけどダメージがない感じです。
衝突したビームは消滅するようにしてみました。
敵機については主人公やビームと同じくそれぞれオブジェクトとして作成し、
時間推進演算メソッドを定義し、そのメソッドの中で
ビームや主人公との衝突検知や
機体の生成と同時に進行方向へのアニメーション開始も実行しています。
この時間推進演算メソッドではゲームクラス側で
一定間隔で定期的に呼び出されるようにしていますので
その時間間隔における敵機の進行幅が向かって来るビームの進行幅より
大きければうまく衝突が検知できないので少し工夫が必要でした。
//敵機のアニメーションの開始 [UIView animateWithDuration:gTime delay:0.0 options:UIViewAnimationOptionCurveLinear animations:^{ self.point.center = CGPointMake(self.point.x, self.point.y+[UIScreen mainScreen].bounds.height); } completion:^(BOOL finished){ [self die]; }];
動画をアップしましたけど敵が迫り来る様子が少し出せたかなーと思います。
注意したのは時間推進演算メソッドを呼び出す駆動エンジンとしてNSTimerを用いた部分でした。
このNSTimerオブジェクトは定期的に任意のメソッドを呼び出すものですが、
その呼出し間隔は0.5秒が推奨されていて
それより短い間隔で呼び出す場合は別の仕組みを考えなければならないようです。
これについては次回書こうと思います。
iOSフォント
今回はiOSで使用できるフォントについて調べたので
備忘録の意味合いも兼ねて列挙してみました。
列挙しただけですが、意外にも結構大事な要素だったりします。
色々試してゲームアプリではポップな感じとか
ニュースアプリだと少し新聞調にしたりとか。。
私はAmericanTypewriter-Boldとかにしようと考えています。
@"Hiragino Kaku Gothic ProN W3",
@"HiraKakuProN-W3",
@"Courier",
@"Courier",
@"Courier-BoldOblique",
@"Courier-Oblique",
@"Courier-Bold",
@"Arial",
@"ArialMT",
@"Arial-BoldMT",
@"Arial-BoldItalicMT",//1
@"Arial-ItalicMT",
@"STHeiti TC",
@"STHeitiTC-Light",
@"STHeitiTC-Medium",
@"AppleGothic",
@"AppleGothic",
@"Courier New",
@"CourierNewPS-BoldMT",
@"CourierNewPS-ItalicMT",
@"CourierNewPS-BoldItalicMT",//2
@"CourierNewPSMT",
@"Zapfino",
@"Zapfino",
@"Hiragino Kaku Gothic ProN W6",
@"HiraKakuProN-W6",
@"Arial Unicode MS",
@"ArialUnicodeMS",
@"STHeiti SC",
@"STHeitiSC-Medium",
@"STHeitiSC-Light",//3
@"American Typewriter",
@"AmericanTypewriter",
@"AmericanTypewriter-Bold",//o
@"Helvetica",
@"Helvetica-Oblique",
@"Helvetica-BoldOblique",
@"Helvetica",
@"Helvetica-Bold",//o
@"Marker Felt",
@"MarkerFelt-Thin",//4
@"Helvetica Neue",
@"HelveticaNeue",
@"HelveticaNeue-Bold",
@"DB LCD Temp",
@"DBLCDTempBlack",
@"Verdana",
@"Verdana-Bold",
@"Verdana-BoldItalic",//o
@"Verdana",
@"Verdana-Italic",//5
@"Times New Roman",
@"TimesNewRomanPSMT",
@"TimesNewRomanPS-BoldMT",
@"TimesNewRomanPS-BoldItalicMT",
@"TimesNewRomanPS-ItalicMT",
@"Georgia",
@"Georgia-Bold",
@"Georgia",
@"Georgia-BoldItalic",//o
@"Georgia-Italic",//6
@"STHeiti J",
@"STHeitiJ-Medium",
@"STHeitiJ-Light",
@"Arial Rounded MT Bold",
@"ArialRoundedMTBold",
@"Trebuchet MS",
@"TrebuchetMS-Italic",
@"TrebuchetMS",
@"Trebuchet-BoldItalic",
@"TrebuchetMS-Bold",//7
@"STHeiti K",
@"STHeitiK-Medium",
@"STHeitiK-Light"
【objective-c】プレーヤーによる攻撃オブジェクトの作成
前回までに
・iOS Developer登録(申請篇、アクティベート篇、完結篇)
・主人公決定！
ということを行ってきました。
objective-cの作法を学ぶこと以上に
成果物の作成にフォーカスするという私のポリシーに反し、
オブジェクト指向について継承関係やcompositionについて学ぶなど
かなり遠回りしてきました。
今回は主人公からビームを出すためにやったことをまとめました。
前回定義したビームクラスを少し拡張します。
ビームクラスについては以下の属性(グローバル変数)を持たせます。
・位置座標(CGPoint型)
・サイズ(int型)
・パワー(攻撃力：int型)
・生死フラグ(Boolean型)
・イメージ(UIImageView型)
そして主な動作(メソッド)としては以下です。
・初期化メソッドinit(上記属性の設定)
・時間経過メソッドtimePass(位置座標の変化や特殊効果の描画の追加等を実施)
ゲーム側の仕様としてはユーザーが画面をタッチしている間中ビームが出ているようにしたいので
プレーヤーオブジェクトにおいてビームオブジェクトを格納する可変長配列を定義します。
弾丸を格納する弾倉という意味でmagazineと定義しました。
こんな感じです。
NSMutableArray *magazine = [[NSMutableArray alloc]init];
宣言したらプレーヤークラスのhファイルとmファイルのそれぞれに
generateBeamメソッドの宣言と定義を記述してやり
そのメソッドの中で下のように弾倉に弾丸を格納しました。
hファイル側
-(void)generateBeam;
mファイル側
-(void)generateBeam{
[magazine addObject:(BeamClass *)beamObject];
}
このようにhファイルで定義してやることにより、
プレーヤークラスをコンポジションとして保有しているオブジェクトから
このgenerateBeamメソッドを呼び出すことができます。
呼び出す時は、以前の記事で書いた(プレーヤークラスがタッチされている間中に呼び出される)メソッドonFlickedFrameにおいて
[Player generateBeam];
として呼び出します(Playerはプレイヤーオブジェクト)。
すると、弾倉に弾丸が充填され、ビームが生成されますので
この弾倉から個別にビームを取り出してやります。
そのためにはビームを取得するメソッドが必要なのでPlayerクラスのhファイルとmファイルそれぞれで
hファイル
-(BeamClass *)getBeam(int num);
mファイル
-(BeamClass *)getBeam(int num){
return [magazine objectAtIndex:num];
}
と定義してやります。引数のnumは何番目のビームを取り出すかを表しています。
magazineにビームインスタンスを格納するときに
先ほどaddObjectで新しいものが最後に格納されるように書きましたが、
insertObject:atIndexで第二引数をゼロにしてやれば新しいものが最初に格納されるようにすることも可能です。
ここら辺はやりやすい方でいいかなと思ってますが、ゲーム側の設定次第では後者の方が若干取り出しやすいかもしれません。
ゲーム側でNSTimerオブジェクトを使って定期的に呼び出されるメソッド(例えばupdateTimeとする)を定義してやり、
そのupdateTimeメソッドの中で
[Player getBeam:xxx];
を呼び出してやればxxx番目のビームを取得することができます※。
※この表現は若干正確ではなく、
Playerオブジェクトの状態変化を行うメソッド(例えばupdateStatusとする)を定義し
そのupdateStatusメソッドの中で各ビームインスタンスの位置情報を更新してやるようにすれば
[Player updateStatus];
の一行で、定期的に全てのビームクラスの位置情報を変化させることができます。
ビームインスタンスの位置情報の更新は例えばこういう感じにしてみました。
-(void)updateStatus{
for(int i = 0;i < [magazine count];i++){
[[BeamClass objectAtIndex:i] timePass];
}
}
timePassはこの記事の一番最初に書いたビームクラスのメソッドです。
timePassの中では下から上にビームを動かすために
x座標は変化させずに、y座標だけ少しずつ小さくしていき、
またUIImageView型の位置座標を更新してあげます。
今回はこんな感じにしました。
-(void)timePass{
point = CGPointMake(point.x, point.y - 10);//CGPoint型のビーム位置
image.center = point;//UIImageView型のビームイメージ
}
以上で大体完了したと思います。
ビームクラスを拡張している間に
以前、こちらの記事に書いたデザイナーさんにお願いしていた背景画像の裏地ができたという報告があり、
せっかくなのでこれを背景画像にセットしてプレーヤーとビームを描画してみた動画が以下です。
シミュレータ上の見え方です。
画面上のカーソルの位置が指の位置で
カーソルが丸になった時はタップした時です。
タップと同時にビームが前に出ている様子が分かります。
まだまだ見た目はしょぼいですが、なんとなく基本動作は見えてきました。
動画ではビームのテストだけだったのでプレーヤーに動きはありませんが、
こちらの記事に書いたソースコードをがっちゃんこすれば
画面内を自由に動けるようになっています。
ゲームの根幹が出来てきました。
次回は背景がスクロールさせたり、敵オブジェクトを配置してみようと思います。
続きます。
ニートの増加は社会にとって望ましいこと〜私がニートを選択した理由〜
今の私の立場は社会的に言えばニートです。
ウィキペディアによればニートとは15歳以上34歳以下の非労働力人口のうちで学校に行っている人と主婦を除いた求職活動をしていない人と定義されています。
バッチリ私は当てはまっております。
よく会社員の方からしたらニートであることは、胸を張って言えることはでないと言われます。
人によってはニートは国民の三大義務である勤労、納税、教育のうち
前の二つを果たしていないのだから監獄行きであるとまで言う人がいます。
そこまで言わなくても、選挙権や生存権ですら剥奪しろと言われたこともあります。
なぜそこまで言われなければならないのでしょうか。
批判されている方に共通するのが、税金を払っていないからと言われることです。
勘違いしてはならないのですが、ニートは雇用されていない人であって
生産活動をしていない人ではないということです。
生産活動をしている中で何かしらのサービスを提供していれば
ユーザーからお金を徴収する時に納税しなければなりません。
それに何か買って食べたり、
住む場所を確保するのにも消費税とか払っています。
なので、生きるためには勤労も納税もしなくてはならないので
これらの批判の対象にはなりません。
私はこれからニートが増えることは回避不可能だと思っていますし
それどころか、むしろニートが増えることは望ましいことだと思っています。
その理由について幾つか私なりの考えを述べたいと思います。
少し長いですがお付き合い頂ければと思います。
最近、貿易収支が過去最大の赤字になったというニュースをよく見かけます。
国内の人口が減少し、長引く不景気で企業は労働者への賃金に回さず、会社内で資金を貯める傾向にあります。留保金というやつです。
リーマンショックやギリシャショックなどの海外発のリスクが翌日には世界中に波及するような世界で
企業がお金を手元に置いときたい気持ちは理解できます。
その結果、景気が回復しても労働者への利益の分配は以前のような水準には戻りにくくなっています。
お金を払う人が少なくなって、一人当たりのお金の量が減ってくれば消費も増えません。
先日日本の大手薬品会社の海外生産率が50％を超えたということが話題になりましたが、
こうした流れの中で日本の製造業(に限らず非製造業も)が海外に進出するのは自然な流れで
また日本人の海外への出張者数よりも外人の日本への出稼ぎ労働者の方が増えているので
(現状唯一黒字を確保している)所得収支も減少し、
海外のサービス業者が日本国内に参入しているのでサービス収支も基本的には減少傾向にありますから
残念ながらこのままいくと経常収支はあと15年以内に赤字になります。
※経常収支＝一国の全ての収入と支出の差し引きの金額。「貿易収支」「サービス収支」「所得収支」「経常移転収支」を足した値。
これは財布みたいなものです。(最後の経常移転収支は微々たる金額なのでここでは話してませんが。)
現状黒字を保っている経常収支が赤字になると、
対外的には経済活動が行えていないという評価になるので
海外からの投資は減少し、国への信用力が低下することにより円の価値は猛烈な勢いで下落します(ハイパーインフレ)。
国が発行する借金の借用書である国債価格は暴落し、
銀行は保有している資産のほとんどを失うことになります。
(銀行は安定運用が社内ルールで義務づけられているので)
国債への投資比率が７割を超えているメガバンクを中心に破綻します。
銀行から預金を引き出せなくなると同時に
保有している現金の価値は紙くず同然になるのでモノやサービスは買えません。
経済循環が機能不全となり日本は滅びます。
以上は極端な例ですが、
経常収支の赤字がある程度の確実性をもって見えてきた時か
GDPの伸び率がマイナスになるのが見えてきた時
(というか今それがある程度確度を持って見えつつあるんですが)
それに似たようなことは起こりえます。
そうなれば中小企業はもとより、
今安定していると思われている大企業で行われている年功序列型の給料体系、
終身雇用制度は跡形もなく消え去ります。
そうなった時にどういう人材が必要とされるか。
会社に守られて、流れ作業で一部のプロセスしがやってこなかった会社員か、
もしくは雇用はされてないけど、
自らの手で 企画、開発、保守運営、販促や営業活動等の一連の作業をこなせる個人事業をやってきた人か。
よく○×一筋何十年とか誇らしげに言う人いますけど恐らくそういう人は淘汰されて行くでしょう。
インターネットやテクノロジーの発達に伴い、
一つのことしかやってこなかった人は自動化の波で職からあぶれる可能性が高まります。
最近ではDeep Learningという人工知能の一種で人間の複雑な思考プロセスを真似できる技術が確立されつつあります。
昨日もGoogleがこの技術を開発しているDeepmindという会社を4億ドルで買収しました。
そういえばニュース記事を自動で要約する技術を開発したSummlyというアプリが数千万ドルでヤフーに買収されてちょうど一年になります。
世界中で人工知能や遺伝的アルゴリズムといった技術の買収合戦が活発化しているので、人間しかやれないことというのは少なくなっています。
テクノロジーを悪者にするか自分ができることを増やして行くかは自分次第です。
その決断の期限が15年以内に起こりえると思います。
(私は国家の陰謀論とか悪趣味なものは信じてませんし、好きではないのですが)
国の破綻に関する議論がアベ政権になってから公表されていないことに驚きます。
そうならないように努力するしかないでしょというのが公式見解なんでしょうけど、
明確な対応策が出せていないのが事実なんだと思います。
政府は2020年までに国の財政収支を黒字化するために消費税を3％上げましたが、
この黒字化達成が困難であると発表がありました。
今回の増税3％分は年金や医療などの社会保障に当てると言いましたが、
高齢化が進めば社会保障費は増える一方です。
これもまた残念な話ですが、消費税が5%から三倍の15％になっても受けられる社会保障費は現状の水準より悪化することが予想されています。
払う金額は増えるけど貰える額は少なくなるということです。
今40代後半くらいの会社員の管理職は”逃げ”切れることを知っています。
逃げ切れば国が赤字になろうが数年会社にしがみついて退職を迎えることができれば
年金を貰えるか分かりませんが、多少は生き延びることはできると思います
(それがクールな人生かダサい人生かは置いといても)。
しかし今の20代、30代は15年経ってもまだ働き盛りです。
温室育ちのサラリーマン生活から突然会社の外に放り出されても遅いです。
サラリーマンにありがちな、真面目に一生懸命働くのが一番とか、今の仕事が楽しいから続けたいと言っている時代ではなくなっています。
さらに残念なことに大企業ほど面白いサービスやプロダクトを生み出せないのも事実です。
不必要に高精細な液晶ディスプレイを開発したり、
特殊なエフェクトばかりを重視して開発されたゲームには見向きもされていません。
規模のメリットが機能していた化石産業はもはや斜陽産業に成り下がっています。
会議室で同じような格好のスーツ着て仕事している人たちは、
高度に複雑化して変化の早い時代にとっくについていけなくなっているからです。
だからこそ会社に属さなくても自由な発想で面白いプロダクト作っていける人が今後必要とされてるんだと思います。
それでもいろいろ理由をつけて会社を離れるのが怖いという人もいます。
もちろん人それぞれでリスク許容度が異なって当然だと思いますが、
彼らはそれ以上にいろいろな計算とか想像力が欠如しているんだと思います。
会社員生活や老後の生活に直結する今後の労働形態の在り方や社会構造の変化、
あとは死ぬまでに自分がどんな成果を残して生きた証を残せるかと言ったことについての。
それでもいろいろ理由を付けて会社に属していないと不安だと言う人もいます。
そういう人には、
ごちゃごちゃ言わずにやってみろ
と言いたいです。
