すのふら

すのふら

日々の備忘録

《霊魂鳥神-彦孔雀》のバウンス効果後にスピリットモンスターを特殊召喚できない状況

《霊魂鳥神-彦孔雀》の裁定をたまたま見ていたら、①の効果について今まで認識していなかったことがあったので戒めのためにメモする。

f:id:snofra:20181111021233j:plain

儀式・スピリット・効果モンスター
星8/風属性/鳥獣族/攻3000/守2500
「霊魂の降神」により降臨。
このカードは儀式召喚でしか特殊召喚できない。
(1):このカードが儀式召喚に成功した場合に発動できる。
相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す。
その後、手札からレベル4以下のスピリットモンスター1体を召喚条件を無視して特殊召喚できる。
(2):このカードが特殊召喚したターンのエンドフェイズに発動する。
このカードを持ち主の手札に戻し、
自分フィールドに「霊魂鳥トークン」(鳥獣族・風・星4・攻/守1500)2体を特殊召喚する。


①効果で手札からスピリットモンスターを特殊召喚ができない状況


そもそも手札にスピリットモンスターを握っていない

そりゃそうだっていう状況。
その場合も『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』効果は使用可能。

■『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』処理は必ず行いますが、『その後、手札からレベル4以下のスピリットモンスター1体を召喚条件を無視して特殊召喚できる』処理は行わないとする事もできます。(自分の手札にレベル4以下のスピリットモンスターが存在しない場合でも、モンスター効果を発動する事ができます。)
霊魂鳥神-彦孔雀 | カードに関連するQ&A | 遊戯王 オフィシャルカードゲーム デュエルモンスターズ - カードデータベース

つまり手札にスピリットモンスターを握っていない場合は、手札からの特殊召喚は行わないということになる。

これは《霊魂鳥神-姫孔雀》もデッキor手札の違いはあるが同様。


相手の場に存在するモンスターがモンスタートークンのみの場合

《霊魂鳥神-彦孔雀》の①でモンスタートークンのみを選択した場合、処理後にスピリットモンスターを手札から特殊召喚することはできない。

なぜかというとモンスタートークンの取り扱いについてルールと確認すると分かる。

フィールドを離れる時は消滅する(これは除外扱いではない)。
破壊・除外・リリースされる時、「効果でバウンスされる・墓地へ送られる」時はその時点で消滅する。
サクリファイス》等に吸収されたときや《強奪》等でコントロールが移ったときなどは、フィールドから離れずに移動した扱いになり、消滅しない。
当然だが、「消滅」と「破壊」は異なるため、破壊以外の処理を受け消滅した場合は破壊された扱いにはならない
遊戯王カードWiki - モンスタートークン

つまり、モンスタートークンは手札に戻っていないため、「手札からスピリットモンスターを特殊召喚できる」という条件を満たせていないということ。

モンスタートークンのルールで手札に戻らないのであれば、バウンス効果で選択できないのではという疑問も沸く。

「霊魂鳥神-彦孔雀」の『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』処理によって、相手のモンスターゾーンに存在するモンスタートークンを選ぶ事はできます。

質問の状況の場合、相手のモンスターゾーンに存在するモンスターは「黒焔トークン」のみですので、『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』処理によって選んだ「黒焔トークン」は、フィールドを離れる際に消滅し、手札には戻りません。

この場合、『その後、手札からレベル4以下のスピリットモンスター1体を召喚条件を無視して特殊召喚できる』処理を適用する事はできません。
Yu-Gi-Oh! TRADING CARD GAME - CARD DATABASE

裁定上はモンスタートークンをバウンス対象として選択する可能。
結果的に手札に戻らないが、手札に戻そうとすることはできるということなのか。


相手の場に存在するモンスターがEXデッキから特殊召喚されたモンスターのみの場合

これもモンスタートークンと同じで、バウンスされたときにどこに行くのか。という話になる。

結論から言うとEXデッキから特殊召喚されたモンスターをバウンスすると手札ではなくEXデッキに戻るため、処理後にスピリットモンスターを手札から特殊召喚することはできない。
※EXデッキから特殊召喚されたモンスターがペンデュラム効果(通常)モンスターの場合は手札に戻るので、処理後にスピリットモンスターを手札から特殊召喚可能。

「霊魂鳥神-彦孔雀」の『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』処理によって、相手のモンスターゾーンに存在する融合・シンクロ・エクシーズモンスターを選ぶ事はできます。

質問の状況の場合、相手のモンスターゾーンに存在するモンスターは全て融合・シンクロ・エクシーズモンスターですので、『相手フィールドのモンスターを3体まで選んで持ち主の手札に戻す』処理によって選んだ「DDD怒濤王シーザー」「DDD烈火王テムジン」「DDD疾風王アレクサンダー」はエクストラデッキに戻り、手札に戻る事はありません。

この場合、『その後、手札からレベル4以下のスピリットモンスター1体を召喚条件を無視して特殊召喚できる』処理を適用する事はできません。
Yu-Gi-Oh! TRADING CARD GAME - CARD DATABASE


手札に戻るモンスターが含まれていれば①効果後の特殊召喚は可能

上記の説明はあくまで、バウンスされたのがモンスタートークン、EXデッキから特殊召喚されたモンスター「のみ」の場合。

モンスタートークン+効果(通常)モンスターの組み合わせや、EXデッキから特殊召喚されたモンスター+効果(通常)モンスターの組み合わせなど、手札に戻るモンスターが1枚でも含まれていれば、手札からスピリットモンスターを特殊召喚することは可能。

よく聞いているテック系Podcast 5選

通勤時間が結構長い上に歩いている時間が40分強あるので、その時間はテック系のPodcastを聞いていることが多い*1

内容がよくわからなくても、ワードベースで知見を手に入れられたりするのがいいし、何よりスマホから聞けて手軽なのがいい。
すべて理解しなくてもいいし、気に入った回は何度も聞いてもいいっていう敷居の低さも相まって、移動の時にはいつも利くようになった。

テック系のPodcastでおススメありますか?と聞かれたことがあるので、今聞いているテック系のPodcastをメモしておく


engineer meeting podcast

engineer-meeting.tumblr.com

株式会社サイバーエージェント所属の方がやられているPodcast
テック系というよりかはマネジメント色が強め。ゲストも同社がらみの人が多い印象。

1回あたり1時間くらいの長さ。

とりあえずvol.112の曽山さん回は聞いたほうがいい。俺は文字起こしまでした。

snofra.hatenablog.com


omoiyari.fm

lean-agile.fm

LINE社で働いている(た)方がやられているPodcast
アジャイル系とマネジメント系の話をしていることが多いかなー。

1回あたり1時間くらいの長さ。

このPodcastはとりあえずkakakakakkuさんゲスト回は聞いたほうがいい。意識高すぎてどうかしている人の話は面白い。
lean-agile.fm


セキュリティのアレ

podcast - #セキュリティのアレ - ゆるーいセキュリティのポッドキャストですよ。

ソフトバンク・テクノロジーの辻伸弘さんと、株式会社インターネットイニシアティブ(IIJ)の根岸征史さん、piyokangoさんの3人がやられているPodcast
元々@ITでやられていた同名コンテンツPodcastに移ったという感じかな。

主にアノニマス系や、最近会ったセキュリティ系の話題を話している。
これを聞いてセキュリティに興味沸いたので、興味ある人は聞いてみてほしい。

1回あたり1時間くらいの長さ。

「第11回「ビジネスメール詐欺」詐欺に気をつけろ!スペシャル」が最初に聞いた回ということもあるがおススメかなと。
第11回 「ビジネスメール詐欺」詐欺に気をつけろ!スペシャル « podcast - #セキュリティのアレ


Fukabori.fm

fukabori.fm

NTT系の企業に所属する方のPodcast
ほかのPodcastと比べるとマネジメント系からテック系まで様々なジャンルに対して、質問形式で構成されるPodcast

変に雑談も入らず、1つのテーマに沿って話されるので初心者に一番おススメできるPodcastだと思う。

1回あたり1時間くらいの長さ。

おススメ回はkakakakakkuさんゲスト回のリーダーについての話と、AWS Auroraがらみのデータベースの歴史を説明している回かな。

fukabori.fm

fukabori.fm
この回は内容は最高なんだけど、音質が最低なのがな……。


Misreading Chat

misreading.chat

様々な技術系の論文を読んでその内容を報告するという形で共有するPodcast
正直自分の全然知らないジャンルの論文だと終始何言っているかわからないが、触れたことのあるものであれば論文ベースの知見を得られる。
ざっくり説明してくれるので、なんとなく理解できる。

1回あたり30分くらいの長さ。

おススメはJupyter Notebookの利用実態を調査した論文の回。ためになったというよりはあるあるな感じ。
misreading.chat


初心者にRebuild.fmをおススメできるのか問題

テック系Podcast紹介しているサイトどこをみてもRebuild.fmオススメと書いているものばかり。
俺はとしてはこれから聞き始めるぞって人には確実におススメできないなって思っているのがこのPodcastだったりする。

理由としては

  1. 1回あたりの時間が2時間超えるものがある
  2. 1回で語られるテーマが様々あり、雑談ベース

雑談ベースの話で構成されているPodcastはここだけ特別という話でもない。
1回あたりの時間が長い問題はPodcastちゃんと全部聞かなきゃいけないんだと思う最初の思考で挑むと結構しんどいかなと。

体系だってない話を聞くのが基本なので、2時間聞いて役だったなという気持ちがないとまず続かないかなと。

*1:それか月曜と水曜JUNKをラジコで聞いている

『サイバー攻撃の足跡を分析するハニーポット観察記録』を読んだ

ハニーポットを運用した際に遭遇した事象を、ログベースで解説した書籍。

セキュリティは攻撃軸で書かれることが多くて、言っていることは分かるが実際どうなるのかという観点がいまいちわからないことがある。
この書籍は実際に攻撃された結果をログから考察していくので、こういう足跡から追いかけられるのかと学びがある。

CRM脆弱性ガバガバ3兄弟「joomla!」、「wordpress」、「drupal」の知見が得られるという点もよかった。
脆弱性でいつもJVNに指摘されているこいつらを使用したことがなく、またこいつらの脆弱性か……って思っていたので。


ログベースで書かれている書籍のため、ブログを読んでいるに近い感覚になる。
ブログを読んでいるのに近いというのは、遭遇した事象を遭遇したと書いているだけというのが理由のひとつだと思う。

そこから深い考察もないので、そこはもう少し類似パターンを増やしながら傾向をある程度分かるようにしてほしかった。1ケースでは本当にそのキーワードでログを見ればいいのか(参考にはなるが)判断つかない。

これは仕方ないと思うが、共通脆弱性識別子(CVE)の番号が古いので、いまだにこの脆弱性で攻撃されることってあるのか?と疑問に思った。
書籍中の「放置されているwordpress」は十分その可能性はあるよなーとは思ったが。継続して運用されているサイトも最初に構築した後、updateしてないだろうしあり得るのかなー。

ハニーポット運用したいなあと思っているので、近々やりたいなという希望。

Python pandasで「A value is trying to be set on a copy of a slice from a DataFrame.」が出力される

仕事でツールを作ろうと思ってjupyter notebook上で実装していた際、以下のWarningメッセージが出てきた。
(めんどいから)スルーでもいいのかなーとも思ったが、気持ち悪いので対応したのでメモしておく。

pandas version:0.20.1

C:\[install先]\Anaconda3\lib\site-packages\ipykernel\__main__.py:32: SettingWithCopyWarning: 
A value is trying to be set on a copy of a slice from a DataFrame.
Try using .loc[row_indexer,col_indexer] = value instead
 
See the caveats in the documentation: http://pandas.pydata.org/pandas-docs/stable/indexing.html#indexing-view-versus-copy



対応方法

以下の実装を実行すると出力する。

        # あるDataFrameから対象の列だけ抽出する。
        df_tmp = df_mached[["a", "b", "c", "d"]]
        
        # 存在しない列名を指定して、その列を追加して値を代入して列を追加する。
        df_tmp["e"]= "hogehoge"


基本的な対応はこのqiitaの記載のとおりで、copy()する実装を加える。
qiita.com

        # あるDataFrameから対象の列だけ抽出する。
        df_tmp = df_mached[["a", "b", "c", "d"]]
        df_tmp = df_tmp.copy()
        # 存在しない列名を指定して、その列を追加して値を代入して列を追加する。
        df_tmp["e"]= "hogehoge"



そもそもSettingWithCopyWarningって何か。

pandasの公式ドキュメント上だと、

Pandas has the SettingWithCopyWarning because assigning to a copy of a slice is frequently not intentional, but a mistake caused by chained indexing returning a copy where a slice was expected.
Indexing and Selecting Data — pandas 0.23.4 documentation



「スライスのコピーへの割り当ては意図的なものではなく、スライスが期待される場所にコピーされたインデックスを返すことによるミスです。」とgoogle翻訳

おそらく元のDataFrameのスライス上"e"は存在していないのに、直接そこを変更しようとしたからだと思われる。
現にcopy()してあげると、元のDataFrameとは切り離されるので、Warningが出なくなった。

リードとしてスケジュール立てるときの生存戦略

今のプロジェクトで、テストチームリードをやっている。
リードになってかれこれ半年くらい経つが、俺の力不足と外部要因によってテストスケジュールがきちっと出せず、
最初の話だとヌルゲーだと思っていたのにこんなにもサバイバル能力を求められるプロジェクトなのかと戦慄している。

生存戦略をきっちりとっていかないと、降りかかる考慮不足によるスケジュールの引き直し。
遅れるスタート。
完了タイミングはある程度決まっているため間に合わせるための人海戦術、疲弊する俺含め作業者。

万策尽きる俺。

*1


そんな中、計画を立てるときにどう対応するべきだったのか、乗り越えるために考えたことをメモしておく。


俺のロール

俺の具体的なロールとして、データレイク基盤の構築を主にやっていて、基本バックエンド側のデータベースやバッチリソースに触れている。
テストフェイズ別では結合テストに該当するテストを主に担当している。
プロジェクト的には既存の横展開に近い作業で、個別仕様はあるが基本アーキはそのまま流用していく形。
結合テスト含め全体のテスト計画自体は俺はやってなくて、それはもっと上のテストリードが実施している。


きつかった外部要因

一番きつかったのは、

  • カットオーバーまでのマイルストーンが陳腐化している
  • 守れていないVモデル
  • テスト計画がいつまでも決まらない

ガイドラインが全く定められていない状態。

だが、カットオーバーの日時は変わっておらず、そこに何としてでも納めなければならいという点。

マイルストーンが陳腐化されていて、指摘事項のひとつが「今のスケジュールは古い。議事録読んでなぜ拾わないのか」でさすがにそれは痺れた。
俺より上の人は一体何をしているのか?そう思っても仕方ないと思う。*2

それでもなんとかスケジュールは立てねばらない。

Vモデルの仕組みが破綻していて、結合テストの裏で要件定義、設計中で全然個別要件が拾えない。
結合テスト自体は何度か実施しているので、その実績からやっていくしかない。

そんな寄り掛かるところがいまいち見えない状態でやるしかなかった。


スコープ

上で書いている通りテスト計画が未決定の状態で、詳細スケジュールを引かねばならない。

その状況だとスコープが全く見えず、いったいどこからどこまでが結合テストの範囲で、別の領域とどこで合流するのかっていう点が見えない。
また要件が分からないので、合流の要否もまったくわからない状況。

おそらく前回と同じなのではないかという感覚でテストスコープを出したが、やはり別の領域とどこで合流するのか、する必要がないのであればその根拠を示せと言われてそんなの俺が知りたいわ!

ここの指摘背景は、おそらく今回の結合テストではその領域間のつながりがキー。
正解回答は、内部結合テストでは自領域しかしないが、外部結合テストに向けて内部結合テストのデータを流用できるように連携する。

外部結合テストであれば適当にできたデータでもよいが、その工数の削減やデータの構成がよりあるべき姿であるほうがよいということ。
外部結合テストで必要で結構変わる箇所は、特にエンドユーザ・ほかの対向システムに影響がある機能であるので意識すべきだった。

意識できなかったので結合テストが必要で、影響が大きい結構変わる箇所」が一体何なのかを判断できなかったのが問題だった。

スコープは前回と同じだったけど、要件変更で変わって影響を受ける範囲が広範囲であるという点をスルーしていたための指摘。

まあ、要件が決まってなかったんや!って言い訳はできるが、スコープ立てる上で「今回の用件で、自領域以外で影響があるところって今のレベルでわかったりします?」という話を自チームのリードと話せていなかった。

リスクを事前に確認せずに、前回と同じで閉じてしまったことに問題があった。

次回以降も絶対にスコープは決まっていないので、「現状分かっている範囲で外部影響があるのかあるのであれば、どのあたりか」をできるだけ拾っていけるようにしないといけない。


テスト計画が分からないなら素直にいつまでにできそうかどうかは聞こうな、って話でもある。


スケジュール

上で書いている通り全体のマイルストーンがおかしかった。
そもそもそこちゃんと更新しろよって話である。

ただ、俺の落ち度としてはテスト計画を立てている人の議事メモくらい読めよって話。それは単純に俺の怠慢だと思う。

それはさておいて、スケジュールを立てるときにリスクは以下2点なんじゃないかって

  1. テストのデッドラインはいつなのか
  2. テストの期間中の環境面のリスク

結合テストのデッドラインはいつなのか

いつまでテストを引っ張れるのか?って話。

指摘された内容のひとつとして、本当に完了見込みをそこに置くべきなのか?環境融通まで強行してまで引っ張る必要があるのか、ちょっとずらせば環境問題も解決するしwinwinじゃないの?

f:id:snofra:20181029011305j:plain
全体リードはこんな笑顔じゃなかったっす。


その指摘はおそらく環境融通は結局しなければいけないのであれば、OKが出ていたはず(現に出た)。ただ、結合テストをいつまでに絶対に終わらせなければらないのか。

何かあった時のことを考えて結局どこに落とすのか。その理由。
そこからリソースもとに逆算していって、スタートすべき場所があって、それが結果的に環境融通しなければならない状況であれば文句は言われない。

そのいつまでに絶対終わるのかという軸から、ある程度余裕を持たせられる場所を見定められていなかった。


テストの期間中の環境面のリスク

上記でも書いたけど、環境を融通しあわなければならないタイミングがあった。

ただそこについて、どこがリスクで、それはいつ頃で、関係者とは認識合わせたのか。その外堀がきちっと埋められてなかった。

ただその外堀を埋める作業がリッチすぎるんじゃないかっていう話をする人もいたので、正解はいまいちわからないが、俺は外堀でもなんでも埋められて武器になるものは武器にしたほうが結果混沌としないのでよいかなと。
極力自チームの人に時間とりすぎないように考慮は必要だが。


環境

テスト工程が複数あるということは、実施環境も複数面あるということ。単純に作業者の時はDBMSの情報もらって何も考えず接続していた。

実際にスケジュール立てていくと結合テストの環境はどこなのか、結合テストの最中に同環境に相乗りしてくるテストはいないのか、相乗りしてきた場合のリスク。逃げることはできないのかなど。
環境だけでスケジュールがひっくり返るレベルの話だってある。

上記と共に環境の話で絶対に考えなければならないのが、「環境にコストをどこまでかけることが許されているのか」。コスト意識を正しく持てているのかだ。
指摘事項でかなり言われた観点であり、完全にそこは無視して話していた。

具体的な例のひとつが、
複数テストのバッチサーバ同居する。だがユーザ1つしかないので環境変数が同じになる。でもバッチリソースが違うので環境変数の向き先を分けなければならない。という問題。

そうなると当然

  1. 他のテストと同居できないのでバッチサーバ分けて並行で行く案
  2. 他テストと同居できないのでスケジュールをずらす案
  3. 素直にユーザを複数作る案

こんな感じな案がでてくる。


他のテストと同居できないのでバッチサーバ分けて並行で行く案

やろうと思えば一番簡単にできるパターン。ただ、この案は主にコスト面の心配をしなくてはならない。
環境を新しく作りまーす、に対する最初に立ちはだかる壁であり、一番大きな壁のひとつ。

単純に環境同居するから、みたいな簡単に考えただけでは絶対に突破できない。なぜなら金がかかるから。
そりゃあAWSインスタンスはかなり安くなってきた。ただ開発サーバみたいなのとはわけが違って、データ件数やインスタンスの稼働時間*日数で見たときに少なからず金がかかる。

本当にどうしようもないときは通るだろうが、それはリード陣が事前にそのプランで推し進めているはず。
そうではないときにひっくり返したいのであれば、それ相当の理由が必要であることだ。

上記の2や3がどうしても技術的、日程的にに突破できず他案も考えたうえで、どのくらいのコストがかかるのか「インスタンスタイプ(サーバ容量1h当たりのコスト)*稼働日数時間」でしっかり見積もる必要がある。

以前のプロジェクトでサーバを新しく立てたいとき、上記の説明をしてファイナンス的にOKであるかどうかは、レビューしてもらった*3

俺たちはお客さんの金を使って仕事しているということは忘れてはいけない。*4


環境で注意すべき箇所

なんとなくの肌感覚に近いが、環境で注意すべき箇所は以下かなと思っている。

まずはハード*5面や、スケジュール上関連しそうなテスト系の観点

  1. サーバやバッチリソースを共用するのはどこのテストなのか。
  2. サーバ系(DBサーバ・バッチサーバ・ジョブサーバなど)
  3. (対向システムがあれば)対向との接続先サーバ(SFTPサーバやS3のブランチなど)
  4. バッチリソースを共用するなら、configで分割できるのかできないのであれば、どう合流していくのか。

上からさらに詳細レベルに落とす。

  • (DBサーバ)どのテストがどのスキーマを使うのか。
  • (DBサーバ)同じDB、同じスキーマを使用する場合、影響はどの程度あるのか。回避可能か。
  • (ジョブサーバ)接続先はどこか。JP1であれば同じ接続先でイベント連携で拾ってしまう設定していないか
  • (対向との接続先)接続先はどこか。
  • (対向との接続先)サーバは1つだけか。結合テスト用に閉じた接続先環境を構築することはできないのか。できた場合、あるべき接続先に戻したテストは必要か
  • (バッチサーバ)環境変数系(みなし日など)は考慮されているのか
  • (バッチサーバ)接続先はどこか。資源の格納先は確定しているか


最後に

正直このプロジェクトはスケジュールはめちゃくちゃだし、Vモデルも守っていないし、寄り掛かる場所が全然なくて一体どうしたら、って思うことが多い。

計画がプランされていないときの生存戦略は何というか、裏技に近いような感じではいる。

新人の制作も入ったんです。最初に裏道を覚えたらどんどん間違った方法に頼るようになると…

f:id:snofra:20181027153742j:plain

これって裏道だよなーっていつもそう思っている。


じゃあ正攻法って何よって、指摘されているときにいつも言われているこの2点に尽きるんだろうなと。

スケジュールは面倒くさがらず、上から順番に固めていく。どうしてもピンとこないなという観点は少しブレイクダウンして細かくかみ砕いてみてから組んでいくとそんなにずれた工数にならない。

常にコスト意識を持て

めちゃしんどいが、
チャンス貰えるなら…ありがたいです!頑張ります
f:id:snofra:20181029011644j:plain


生きるってつらい!

*1:後半ずっとこんな感じだった

*2:スケジュール資料のタイムスタンプ上、レビューの1週間前でさすがにずれはないと踏んでいたがそこ違うのかーみたいな

*3:ガバガバだったので二つ返事でOKだったが

*4:当たり前の話だが戒めとして書いておく

*5:とは最近言わないか

(基本)応用情報処理試験に向けての情報処理入門書籍の紹介

python触るまでずっとSaaSサービスの運用だったり開発をメインでやってきていて、そのサービスは分かるみたいな感じで応用が利かなくなってきた。

地力を上げるためにいろいろ基礎的な本を読んできたので、どんな本を読んできたのかをメモする。

基本情報技術者試験とか応用情報技術者試験を受けたいけど知識ないって人にもヒントになれば。

俺が絵本から始めないと全然理解できないアホなので、基本は絵本とかマンガとかがメインの紹介になるかと。


不足している知識はどこか

そもそも自分の地力がどこまで充足していて、どこが不足しているのかもわかっていない状況だった。

わからないor応用が利かないなーという感覚が曖昧な感じだったので、そこも明確化したかったので、応用情報技術者試験の試験要項とシラバスを利用。

IPA 独立行政法人 情報処理推進機構:試験要綱・シラバス など

利用した理由は、自分が一覧化するよりも適切に必要な知見が網羅されているし指針もでているので楽。


アルゴリズムとプログラミング


アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

アルゴリズム図鑑 絵で見てわかる26のアルゴリズム

python機械学習してるときも探索木の話が出るんだけど、何ぞやみたいな感じになった。

それはデータ探索やデータ構造のアルゴリズムを上手く理解できていない状態で、機械学習に踏み込もうとしてたってのもあるんだけど、ちゃんと理解したい。

また、ソートアルゴリズムの理解力が全然足りていなかったので、最初の一歩として購入。

絵本なので、読了まで30分~1時間程度で読み終えられる。

以下同名アプリの書籍版。

アルゴリズム図鑑
開発元:Moriteru Ishida
無料
posted withアプリーチ


リスト・配列の簡単なデータ構造からヒープや二分探索木の探索の基礎的な動きがすべてイラストで表現されているので、見て感覚的に分かるのが良い。

あくまで入門ということもあり木構造は二分探索木しかなく、AVL木やB+木のような今主流のものがないのが欠点。
ただ全体的なイメージをつかめるっていうだけでもよい書籍化と。

アプリも入れてみたけど、アプリ版は本で静的に書かれれているものが動的になっているので、よく分かりやすい。

課金アンロックなので全部見るのに金がかかるが、まずお試しでアプリ入れてみてよければ書籍買うor課金するを選べるのではないかと。


このサイトのアルゴリズムエントリ

俺がソートや木構造について調べた記事は以下
snofra.hatenablog.com

snofra.hatenablog.com


CPU・OS


マンガでわかるCPU

マンガでわかるCPU

マンガでわかるCPU

そもそもPCで何が行われているんだ?からスタートしたので、CPUについても1から確認。

単純に俺がオーム社の「マンガでわかる」シリーズが好き*1っていうのもあるんだけど、この書籍は分かりやすくて基本情報受けたいんですっていう新人に取り敢えず貸し出してる。

読了まで30分~1時間程度で読み終えられる。


OSの仕組みの絵本~ソフトウェアの動きがわかる9つの扉

OSの仕組みの絵本~ソフトウェアの動きがわかる9つの扉

OSの仕組みの絵本~ソフトウェアの動きがわかる9つの扉

超絵本。
OS系のキーワードベースで説明しているので、全体像が分かるようになるというよりもOSの最初のステップとして読むための書籍。

基本情報や応用情報のOS系の問題でワードが全然わからなければ読んでもいい本。

値段も技術書の割には安めなのもよい。
読了まで30分程度で読み終えられる。


サーバ


イラスト図解式 この一冊で全部わかるサーバーの基本

イラスト図解式 この一冊で全部わかるサーバーの基本

イラスト図解式 この一冊で全部わかるサーバーの基本

オンプレミス・クラウドのハード面から、FTPサーバやメールサーバ、DBサーバ等のサーバの役割単位で結構網羅的に記載されている。

そもそもサーバとはという人がまず読んでみていい本。

ネットワークやサーバ障害、セキュリティについても記載されているのでサーバの一連の流れが大体書いてある。

この本の一番いいのはサーバ運用管理について書いてある点。
サーバの運用大変なので、windows updateひとつするにも大変なんだよっていうことが書いてある。

1時間くらいで読める。


DB・ストレージ


絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている

絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)

絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)

メモリやストレージ、DB、DBサーバからみたOS、ネットワーク等実践的に書かれている。

今まで書いた絵本に比べると難易度が高く、図もある程度基礎を理解していることが前提になっている。俺も最初読んだとき、全然わからなくて結構読むのがきつかった印象。

読了までざくっと3時間程度で読み終えて、後から振り返られる程度にしておくのが良いかなと。

どこかの理解度が上がるとある程度追えるようになって追えるようとなるほどと思うんだけど、初学者はもうちょっとレベル落とした書籍からスタートしたほうが良いかもしれん。

だとしたらまずは、前の『イラスト図解式 この一冊で全部わかるサーバーの基本』や『マンガでわかるデータベース』。

マンガでわかるデータベース

マンガでわかるデータベース


ネットワーク

全然畑違いな分野だったので、結構念入りに勉強した。

単体で出ている書籍以外では「日経ネットワーク」の2018年5月号を読むのもよい。インターネットの歴史が分かる。


TCP/IPの絵本 第2版 ネットワークを学ぶ新しい9つの扉

TCP/IPの絵本 第2版 ネットワークを学ぶ新しい9つの扉

TCP/IPの絵本 第2版 ネットワークを学ぶ新しい9つの扉

OSのものとほぼ同じように、ネットワークの基礎をワードベースで解説している本。

これを読むとネットワークの概要はなんとなくつかめてくる。
ただ、これだけだとネットワーク理解としてはかなり薄く、応用情報技術者試験の午後試験には耐えられないので、まず第一歩として。

読了まで30分程度で読み終えられる。


マスタリングTCP/IP 入門編 第5版

マスタリングTCP/IP 入門編 第5版

マスタリングTCP/IP 入門編 第5版

ネットワーク系の本といえばこれ。
これを読んで理解できればもうネットワークの業務についても、あれ?っておもうことも少ないのではと思う。

ただ、初学者が最初に読むには結構きついので、ネット上の説明図を駆使しつつ、上の絵本を読みつつ少しずつ進めていくのがよい。

1ヶ月くらいかけてじっくり理解しながら読み進めていくのをおすすめする。


このサイトのネットワークエントリ

俺がネットワークについて調べた記事は以下

snofra.hatenablog.com

snofra.hatenablog.com


セキュリティ

セキュリティは結構読んでいるので、別記事にする予定。

*1:マンガでわかる統計学も名著

俺は何者にもなれない

仕事の大量タスクからくる疲れだったり、目前の目標を見失っているからこんなことを思うんだろうとは思っているのだが、検索流入以外で見ている人がほとんどいないサイトなので、こういうヒットしていないようなエントリは仕事に直接的にかかわることでなければ何かいてもいいだろと思い、今思うこと書く。

俺は20代を自身の学のなさを理解しつつ、それを棚上げにして生活してきた。
そのツケを払わざるを得ない状況になって、まず基本的な知識を去年あたりから勉強している。
CPUやOSの仕組みの絵本を読むところからだ。

プライベート上では家族に仕事に関する勉強を理解されないので、休日はできず電車内や仕事帰り家族が寝静まったときにコツコツとやって、今年で2年目になる。

しかし、それが今の俺にどのくらいリターンがあったのだろうかと思う。

サーバ、セキュリティの知見や情報を収集していても、今の仕事もバッチ開発でSQLしか触れていないし、自身へのupdateが業務知識だけ。
SQLで何か新しいことをやるにしても既存の横展開、テストリードの今のロール、スケジュールに余裕もなく終電まで残業しないと終われない。*1

資格の面でも落ちたり、受験申込したが仕事で受けれなかったり、そもそも勉強している基礎的なハードルも突破できない。

いつも自身をブレイクスルーしなければいけないと思っているが、結果も出ていない今の俺のアプローチではただただ煮え切れないだけなんじゃないかと思っている。

俺がそう考えている間にも俺だけができていたことを周りができるようになっている。自身が下位互換になっているのを肌で感じている。

俺が勉強を始めたのも何者かになりたいと思ったからだった。

結局、俺は何者にもなることができない。

*1:1on1で上司と面談したらSQLのチューニングを極めるとか今のプロジェクト内でやれることあるだろと