とあるエンジニアの生活記録

とあるエンジニアの生活記録

とあるSIerのエンジニアの雑記です。

春から社会人大学院生になります

お疲れ様です。

2022年4月より、都立産業技術大学院大学情報アーキテクチャコースに進学します。

会社員のまま進学しますので、なかなか時間が大変になりそうだなというところもあり今までの振り返りを改めてしようと書いた次第です。

(巷で嫌われている自分語りに近い?笑)

 

略歴

年齢:26歳

性別:男

職業:会社員、システムエンジニア4年目(日系ユーザ系Sier

領域:アプリケーションエンジニア。R&Dをしてたりもする。

居住:東京

出身:関東近郊

学歴:都内中堅私立大学経済学部卒業

所帯:独身

 

いつかどなたかが、キャリアに迷ってしまった際のご参考となれば幸いです。

 

 

動機

今回社会人大学院に進学する動機としては、以下の3つです。

①良いIT技術者に必要な基礎知識を改めて学習する

②体力と能力のストレッチ

③トラウマの払拭

 

①良いIT技術者に必要な基礎知識を改めて学習する

これは文字通りです。

基本情報は持っていますが、それだけではまったく足りないのは同業者の方なら同意いただけるのではないでしょうか。

ソフトウェアというのはハードウェアとも密接に関わりつつも、ネットワークやセキュリティ、ユーザとのインタフェースまでカバーします。この時代にソフトウェアを介さないで制御をするようなものはほとんどなく、さまざまなソフトウェアがますます必要とされていくものと思います。

そんなところに文系学部卒で飛び込んでしまったので、力不足をさまざまな場面で感じます。そんなより高度なソフトウェアやシステムが求められる時代において、若い時期に基礎知識を改めて叩き込むのは悪くない判断だと思料しています。

②体力と能力のストレッチ

独身ゆえ仕事のみに生活を振り切ることもできますが、家庭を持てば仕事に全振りした結果としての成果を出し続けることはできなくなります。

何かを犠牲にし続けることは難しいです。持続可能な仕事スタイルにしなくてはいけないでしょう。そこで、技術者としての基礎体力を鍛えながら仕事をしていくことを選びました。

体力も能力もストレッチすることになりますが、ちょうど良い機会かなと。

(大学院は最悪退学しても生活に影響はないのでいい塩梅のチャレンジと思っています!)

 

③トラウマの払拭

これは非常に個人的、感情的なものになります。

学生時代、実は商社マンになろうと思っていました。そのため、英語が必須と考え留学を志していました。

IELTSのスコアをとり、とある英国の大学に留学することが決まっていた状態で休学してシステムエンジニアの仕事でお金を貯めていました。ですが、当時英国がEU離脱するといういわゆる「Brexit」が起きた影響で、派遣留学ができなくなってしまいました。そのための大学選び(派遣留学なので安い&多国籍企業でのインターンシッププログラムがついていたプランが当時あった)をして、青春の一年を捨ててお金を貯めたというのに...というものでした。

留学のための数年がかりの計画が頓挫した、どうしようもないやるせなさはまさに若き日の挫折そのものでした。(当時付き合っていた彼女に振られたのも追い討ちでしたね笑)

このまま普通に終わってなるものか、という執念を持ちつつ過ごしてきました。

今回こそはと思っています。別に大学院を卒業したからといって何も変わるわけではありませんが、あの時の自分に終わったよ、と言える気がします。

 

目標

学位を取得しつつ、コンピュータサイエンス情報アーキテクチャの知識を身につけて世界の最前線にいるトップTierのエンジニアのみなさまに追いつけずとも、同じ景色を見て同じ語彙で(英語って意味ではないですよ、できたらすごくいいですけど)コミュニケーションできるようになることが狭義での目標です。

広義の目標は、自分の理想とするシステムを作り上げられるだけの力量を身につけて、どのような組織やビジネスを通じてでも社会の発展に貢献できるようになることです。

 

技術者として

現在、ユーザ系企業のシステムエンジニアをしています。プロジェクトマネジメントをやっているかと思いきやコードを書いているタイプの少数派です。

オンプレ基盤もあり、やはりハードもソフトもわかっていないと太刀打ちできない事象が起きます。なので、たまにいるプロパーなのにめちゃめちゃ強い人に憧れていたり。

大学院を意識するようになった転機は、尊敬する上司がITコンサルとして転職していってしまったことでした。仕事がいわゆる上流になってしまったことが引き金となってご転職を決められたようでした。(そんな元上司が同じ現場というか弊社の別部署に派遣された、みたいな話を聞いてその選択はありだなと思いましたが)

日系Sierあるあるなのですが、コード書くのは若手で徐々に上流工程をやっていくのを卒業と称し、コーディングはベンダーに丸投げ、みたいな文化があります。これを繰り返した結果ベンダーさんいないとなんにもできないプロパーエンジニア(笑)が出来上がってしまうシーンが繰り返されてきたのだと思います。

私はこれにはなりたくなかったのです。システム屋がソフトウェアを作れなくなったらオワコンです。

 

人生観

環境は選べないのですが、どう生きてどう死ぬかは選べると思っています。死ぬ時にやりきったなぁと思えたら、最高にイカした人生にできたんだなと思える気がします。

あと周りの人を幸せにできたらいいなと思っています。自分の手の届く範囲が広がれば、よりできることが増えたら、きっと周りを幸せにできるんじゃないか、その延長線上で、社会に何かしらできるんじゃないか、みたいに思ってます。

なのでいいシステムが作れるようになったら、より社会の発展に貢献できるんじゃないかと結構本気で信じています。(いつかこれを見て自分で青いなぁと思う日が来てほしいですね笑)

 

所感

履修、どうしようかな。笑

生活状況などもたぶん参考になるかと思いますので、余裕あれば記事にしようと思います。

 

 

 

みずほ銀行システム統合、苦闘の19年史_読了記<備忘>

毎日毎日、お疲れ様です。

いろいろなことがありますよね。

 

最近はとある資格を取ろうとよわよわエンジニアながら奮闘しています。

その資格、試験のpassが2つ必要でなかなか高額です...(1つ16,500円)。そのうち1つを片方を昨日取り終えました。LPIC101って言います。

ほかの方の合格体験記など読むと圧倒的に僕が費やしている時間が少なく、努力が足りないからいつまでたってもうだつの上がらない技術者なのかな、と合格したのに敗北感を感じています。

 

目標としている段階(Application EngineerだけどなんかかっこいいからLPIC300シリーズ取りたいんです...。)まで到達出来たら記事にするかもしれません。

 

以下HPです。興味のある方はのぞいてみてください。

LPIC | 世界標準のIT資格 | LPI日本支部 | Linux Professional Institute Japan

 

悔しいから勉強時間も実装する時間もめっちゃ増やしてやるわ!と息巻いています。 

 

 

さて、本題です。

本日はみずほ銀行勘定系の構築にあたっての本の感想をつらつら書いていこうと思います。総額にして4,000億円越え超弩級プロジェクトでした。

日本のシステム屋として、この話を知っておかないのはナンセンスかなと。

筆者は若輩金融エンジニアですので、他山の石とする必要があります。

 

www.nikkeibp.co.jp

 

さて、書く前に僕の今回の件の認識を。

学生のころにも少しエンジニアをやっていたのですが(2015年ごろでしょうか)、これはこれは当時大変ネタにされておりました。

完成しないだの、トイレにこもって出てこない方がいるだの、専門学生をタダで動員しただの(??)、パワハラの嵐だの、サクラダファミリアだのいろいろ言われていました。一部内部情報が5chに書き込まれていました。

MHIRさんのリクルートページに「なんでもできるとても優秀なエンジニア(意訳、年収1000万)」が登場したときは「1000万円でデスマーチに参加してくれる強い勇者を募集しているらしい」とか「その給料では期待している人は絶対に来ない」などと書き込まれていた記憶があります。ひどい書かれようでしたが、当時の内情を想像すると募集したくなるのは容易にわかります...。

規模が大きすぎて日本中のエンジニアや、エンジニアもどき(テスターとかドキュメント整理役とか)とか、PMやら何やらをブラックホールのごとく吸い込んでいったために他の現場が人手不足に陥っていたとも聞いています。(慢性的にいつも優秀な方は不足していますけどね...)

遠巻きに(大変だなぁ...)と思っていました。

 

そんな前提で読んだのですが、今の仕事内容を考えるととてもためになりました。

 

目次

 

 

 

 

・合併前:各行の意地の張り合い

皆さんご存じの通り、みずほ銀行はかつて日本の商業銀行のTOP3ともいえる3行が対等合併してできた銀行です。第一勧業銀行、日本興業銀行、富士銀行です。

各行とも平成元年の時価総額で世界のTOP5(1989年07月基準)に入っていました。みずほ銀行を現在のテック企業風に例えると、MicrosoftAmazonAppleが合併してできたIT企業、といえばいいでしょうか。(サウジアラムコはNTTに見立てました、2020年06月基準)

それだけバブルが異常だったのもありますが...。

バブル崩壊後、全国に13行あった都銀を中心に日本の商業銀行は合併を繰り返す歴史を紡ぎ始めました。その中で一番大きな合併がみずほ銀行の誕生でした。

 

興銀マン、なんて固有名詞が出るくらいには鼻息の荒い金融マンたちだったので当然どの銀行のどのシステムを使うかで揉めたようです。

結果として、みずほコーポレート銀行(富士銀行)とみずほ銀行(勧銀と興銀)ができてしまうくらいの惨状だったようです...。

 

通常、銀行の合併時は力関係の大小があるため強い方が飲み込むだけでしたが(東京銀行三菱銀行さくら銀行住友銀行)、対等合併はだめだったのでしょう。

最近まで3人の男性が出てきて対等に話してOneみずほ!みたいなテレビCMを流していましたが、あれは旧行意識の表れ以外の何物でもないと思ってみていました。

・2度の大規模障害

弊害の大きすぎる対等合併のためか、当たり前のようにシステム障害を起こしてしまいました。

1回目は2002年4月、2回目は2011年3月でした。

どちらも口座振替や振り込みなどといった勘定系の中核機能が障害のもととなりました。詳しくは省きますが、一括処理と呼ばれる「一連の処理がすべて終わるまで不完全な処理」であった機構の口座振替処理が終わらず、営業店システムの立ち上げが混乱し、結果として大規模な障害を起こしてしまいました。(本には詳しく説明があります)

 

RDBを基本とし、1件1件トランザクション処理を行う仕組みが決済機能の性質から見ても合理的です。が、ブラックボックス化したシステムを紐解いて勘定系を再構築するという考えが経営陣になく、投資もされなかったようです。

 

・ようやく動き出した勘定系の刷新PJ

2度の大規模障害と金融庁からの圧力によってか、やっと大規模な刷新PJが発足しました。

リテール事業が縮小し続ける中、サラリーマンからのし上がってきた人たちで構成される経営陣としては、大規模な投資は確かに難しいものがありますよね...。

当初予算2000億円だったようです。

NTT、富士通IBM、日立を主軸としたベンダーが集結し始まりました。

結果、4,000億円を軽く超えるプロジェクトになりましたが...。

 

・ホストシステムの残存と目利き

さて、ここからは新勘定系システム「MINORI」を構築するにあたって僕が学ぶべき点だと断定した箇所をつらつらと書いていきます。

ブラックボックス化した勘定系システムを刷新したものの、ホストシステムが残っていると聞いて不思議に思っていました。なぜjavaで構築したのにホストシステムを残したのかとても疑問に思っていたのですが、慧眼を持った方が設計にあたったのだと理解しました。

 

SOAを採用した「MINORI」は、各営業店やスマホからのダイレクトバンキングからのアクセスを受けつけるゲートウェイ部分をホストシステムで構築していました。

ゲートウェイとなるインタフェースを高性能、高信頼性のハードで一手に担うことによって、コンポーネント化した各金融サービスへアクセスすることになります。これによってシステム間の疎結合を実現し耐障害性を大きく向上させています。

クラウド全盛のご時世ですが、個人的にこういったことはハードウェアの知見がたまっていないとこんな設計はできないと確信しています。

(同時に、この情報、本なんかに書いていいのだろうかと不安になりました...笑)

 

・ゼロベースからの要件定義

よくあるシステム構築の話なのですが、SAP導入する企業にあるあるなのが、

「カスタマイズてんこ盛りの現状業務に合わせたSAP導入」です。

 

ユーザからすると、今の業務フローから変更するのは嫌なものですから、そこを変えないようにシステム部に調整をかけます。

で、そのシステム部から委託を受けるSIerはたくさん機能作った方が儲かりますから、乗り気でカスタマイズを受け入れます。

システム部の評価項目としては、ユーザ部の満足度評価なんかが多いので、三方よし、となるわけです。

 

僕個人としては、2重の意味で無駄をしているのでこれ大嫌いなんです。

①現状の業務に改善点があるからSAPを導入して効率化しようとしているのにユーザのわがままでできていない無駄

②カスタマイズ機能の開発、という目先のお金を追ってしまい目的を見誤っている技術者がいる事による無駄(お客様の利益のためにプロとして仕事しろよ、思ってしまう)

 

互いの利益が一致してしまうのでよくある話になっています。

 

 

みずほ銀行は、このいわゆる「現状踏襲」を理想とする要件定義をやめさせるべくユーザ部自身にツールを使わせ、「あるべき」業務フローを作成させました。(MHIRがツールの使用方法の補助に入ったようではありますが)

この経営判断は見事だったと思います。これをもとに要件定義を行っていったようです。

・品質担保に向けた取り組み①

この巨大なシステムを構築するにあたって、コード規約を統一し、しかも守らせるのは至難の業です。僕自身、PMの観点から見ても、一人ひとりコードを書かせていたら絶対に偏りが出てしまうことは避けられないと考えます。

 

みずほは、コードを「書かせない」ことにしたようです。

すべてのコードを、ツールを用いて生成させたのです。(富士通さんのツールです)

手直しも許さなかったとのこと。

 

これにより、品質の偏りなく技術的負債のとても少ない成果物ができたようです。

もちろんエンジニアの皆さんからは不安の声が上がったようですが、性能面などの検証で明らかになったボトルネックはほとんどがRDB周りだったようです。(インデックスがちゃんと張れていないとか、SQLの書き方が悪かった、TABLE設計が悪かったなど)

 

個人的には、UIを生成するノンコードツールは性能が重視される場面で採用するのはいまだ非常に危険だと思っていますが(salesforceなど)、コード生成ツールなら局所的には賛成です。

 

・品質担保に向けた取り組み②

様々な部(基本、MHIR社の部です)で担当するシステムは決まっており、それぞれがそれぞれのシステムを構築する流れでした。

もちろん、それぞれ担う業務が違うためインタフェースなどに対し考え方やとらえ方など違う箇所があり、それがシステムに対し顕出している箇所も多いでしょう。

 

そこに横串確認を通すための組織を設け、原則から外れた実装は許さなかったようです。属人性の排除と原則の徹底によって、技術的負債を作らなかったということになります。

素直に脱帽です。これは本当にすごいことです。

 

・現在のみずほのシステム要員のすごさ

 この誰もがやりたくない、新勘定系構築を乗り越えてきた方たちは、いわば地獄をくぐってきた方たちです。

 

エンジニアって、サイヤ人じゃないですけど修羅場をくぐればくぐるほど強いエンジニアになります。

昨今、テクノロジーを用いて新しい金融サービスを提供する事業者が乱立する中、これだけの修羅場をくぐってきた強いエンジニアをたくさん抱えているみずほは、かなり強いです。多分何でもできます。

事実、「MINORI」開発に携わったMHIRの方はどこに行っても一騎当千、とのことです(本より)

3メガで4位のみずほ、とまで言われてしまうみずほ銀行はいなくなるかもしれません。 

ビジネスを構築できれば、ですが...。

 

以上、読了記兼備忘録でした。

 

若干よいしょしている部分はあると思うのですが、同業としては強いエンジニアをたくさん抱えているみずほさんは怖いですよ...。

 

最後までありがとうございました。

SQLアンチパターン読了記

お疲れ様です。

 

こういうときでもメールの癖は抜けないものですね。

チャットが利点なのはこういう"枕詞"みたいなのをつけなくていいから、

生産性も上がる、というところですよね。

 

チャットにはチャットの良さがあり、メールにはメールの良さがありますからしっかり使い分けしていきたいものです。

(メールが紙媒体の書類のような扱いになってきていますしね)

 

さて本題です。

私自身はApplication Engineerなので業務でさほど考える場面は少ないのですが、

SQLLinuxはどこに行っても使われているものです。

 

ビジネスマンにとっての三種の神器である「英語とITと簿記」は、

僕と同じレイヤの技術者にとっては「RDBLinux(shell scriptとkernel含む)、正規表現」なのではないか?と考えています。

(エンジニアがビジネスマンでないとはどういうことか!みたいなツッコミはおやめください。勿論PJのROIはとても重要だと思っています。)

 

もっともよわよわエンジニアなので、とりあえず「読むべき」とされる本を片っ端から読みまくっています。

今回はそのうちの一冊をサマライズします。

 

www.oreilly.co.jp

 

こちらです。

25個、事例が紹介されていました。

サマっても多分読まないので、「1アンチパターン:1行」で書きます!

(数行で言ってること変えましたごめんなさい)

 

 SQLアンチパターン25

  1. カンマ区切りの属性を格納しない(従属テーブルを使用する)
  2. 親IDが連なる場合は、隣接リストの使用は極力避ける
  3. PrimaryKeyを意味もなく連番にしない
  4. ForeignKey制約を適切に使用する(面倒だから使わない、はありえない)
  5. 可変属性の解決策はとても慎重になる*
  6. ポリモーフィックな動作をさせる際にはとても慎重になる*
  7. 多くの列に属性を格納しない(従属テーブルを使用する)
  8. テーブルサイズの増大には、パーティショニングと正規化で対抗する
  9. 小数データを格納する列にはFLOAT型ではなく、NUMERIC型を使用する
  10. 値を限定する際は列定義でなく、参照テーブル方式を用いる
  11. 大きなサイズのファイルの管理にはBLOB型を用いる(直置きしない)
  12. インデックスは適切に使用する(パフォーマンスに甚大な影響あり)
  13. NULLはNULLとして理解し、扱う(SQLのNULLを理解してクエリを書く)
  14. GROUP BYを複数使用する際、曖昧な表現にならないように注意する
  15. クエリ内にて、RAND()をできるだけ使用しない(ソート処理するため)
  16. 全文検索を行う際には、SQLで実装せず提供されている機能を使用する
  17. 複雑なクエリを1つ実装するより、単純なクエリを複数実装する
  18. 必要に応じて列名やテーブル名などは明記する
  19. PWの格納時、ソルト付与し合わせて最低20字にしてハッシュ化する
  20. 動的なSQLクエリの生成時は基本的にはプリペアドステートメントを使用する
  21. 疑似キーの欠番は埋めない仕様、運用を行う
  22. 返り値があるときはエラーチェックのため無視をしない
  23. バージョン管理とドキュメンテーションは必ず行うこと
  24. モデルをアクティブレコードにしない
  25. コンティンジェンシープランは災害などあらゆる可能性を考慮し作成する

 *...SQL側での制約を行えなくなり、誤ったデータの挿入が容易なため

 

-------------

こんなところでしょうか。

文字にしてみると意外と当たり前のことですね。

しかしなかなかこういったことの言語化は難しいものだと思っています。

べき集は数多くありますが、べからず集はなかなかないですからね。

ただDBを専門的に扱ってきた方たちからすると極めて一般的で、かつ初心者向けの内容と感じられたのでしょうか。

 

Applicationレイヤにいるとこの内容を知らずにキャリアを積んでいる方が多い印象です。PMやOperationsよりの方たちはもうちょっと知っている方が多いでしょうか。

その部分のスキルセットの違いが大きく課題になったりすることもあります。(アプリの実装が悪くて、などはたくさん聞きます)

 

僕個人としてはなんでもできるつよつよエンジニアになりたいです(願望)

 

最後まで読んでいただき、ありがとうございました。

 

 

 

 

Raspberry Pi 4 model B のwifiとHDMI出力について

みなさま、お疲れ様です。

 

このブログは筆者の備忘録です。

なので気ままに書き連ねていきます。ごめんね!

 

今回は厳密な調査やソースがあるわけでなく、筆者のプライベート環境における推察なので最初に謝ります。

 

さて、件名についてなのですが、我が家のラズパイはHDMI出力しているとWi-Fiが切断されてしまいます。

 

少しググってみたところ、こんな記事が。

 

gigazine.net

 

どうやら、こちらでは2560 * 1440 のディスプレイに出力してしばらくするとwlanがダメになってしまう様子。

しかし、私が使用しているのはフルHDの解像度(1920 * 1080)なのです。

 

GW2480 Eye-Care 技術搭載のスタイリッシュディスプレイ | BenQ

 

 

原因は上記のGIGAZINEさんの記事にある通り、周波数の問題だと思っています。

私のラズパイの場合、①USB3.0 *2 で外付けHDD * 2、②有線LAN、③miniHDMIのインタフェースを使っています。

 

WiFiの周波数は家の間取り上、どうしても2.4GHz帯のものを使わざるを得ないため干渉してしまっているように感じられます。

 

事の発端は、電源を誤って抜いてしまった後(そんな間抜けなことする?)、再起動してsshdの自動立ち上げ設定をしていなかったことに気づき、GUIをディスプレイ出力したことです。

 

しかもこのラズパイへのssh接続は鍵のある端末しか認めていなかったため、それは見事なスタンドアロン端末となっていました。

最初は有線LANのIPもわからなくなっていたのでラズパイ壊れたかと思ってげんなりしていました...。

 

 

 

解決策は、ないです。残念なことにファームウェアでの対応は現時点で確認できませんでした。

回避策は、ディスプレイ出力しないで使うことです。僕の技術力では無理デス。

 

いやまぁちゃんとしてNASサーバ買えよって話なんですけどね(笑)

 

(公式フォーラムページのぞいてみましたが、皆さんあの手この手で解決しようとしていらっしゃいました。ただラズパイ4は爆熱なので、公式フォーラムの投稿通りに外付けHDDの上に置いたりして周波数変えようとすると、ほかのハードが逝ってしまいます。おやめください。)

www.raspberrypi.org

 

ちょっと脱線。

私自身、写真が好きなエンジニアとしてしっかり?RAIDを組んで写真を保存しています。(なんかもうお約束な気がしています)

 

もちろん、このラズパイでmdadmをapt-get installしてソフトウェアRAID組みました。Sambaサーバを立ててホームネットワークの端末ならだれでもはいれるようにちゃんと組みました。そしてなぜか管理者は私のwindows機[WSL2]で踏み台sshしないと入れないように組みました。はい、凝り性が裏目に出ました...。

 

スティッキービット立てたりSUID使ってみたりして管理者の真似事もしてみました。Windows端末からアクセスする設定にする際は、ファイルシステムの注意点などあるので気が向いたら別記事にしますね。LPICも勉強中のためそちらも書くつもりです。

 

f:id:imp_a:20200529004339p:plain

lsblk結果。ちゃんとtypeがRAIDになっています。

みなさま、ラズパイのファイルサーバ利用はお気を付けください...。

 

NICについて

こんにちは。

 

今回は完全に自分用になります。

 

IPアドレスについて、コンピュータのOSごとにIPアドレスを持っているのだと勘違いしていましたので備忘録になります。

 

現在、ラズパイサーバを用いて趣味の写真を保存するためのNASを組んで使っています。しかし、自宅のWifi環境はあまりよくなく、Wifi経由で送ると一枚数十MBにもなる写真を転送させるのはSCP転送させても難しいものがあり、結局有線で行えないかと考えました。

 

しかしLANケーブルぶっさしてSSHしてもラズパイ側にはWifi経由でつながってしまい、さてどうしたものかと思っていたら、NICなる単語に出会いました。

 

そう、ネットワークカードです。私は現在24歳で生まれた時からWifiに親しみ、経済学部出身のため、基礎がなっておらず...。

 

詳しく載せてくださっているのがこちらになります。

IPアドレスの基礎知識 - Qiita

 

 

さて本題ですが、IPアドレスはこのNICごとに割り振られるもののため、Wifi経由と有線LAN経由ではIPアドレスが違うのは当たり前でした。

 

f:id:imp_a:20200511233256p:plain

SSH接続_Wifi経由 鍵認証のためPWなどは入れておりません

f:id:imp_a:20200511234231p:plain

SSH接続_有線LAN Wifi経由で接続したときと違うIPですが同じホストに入っています。

速度などの計測は面倒なのでしません...。すいません。

 

ちなみにそれぞれのNIC毎のIPアドレスはラズパイ4+モデルの標準RasbianOSでは「ifconfig」で確認できます。

「ip addr」の方が今はいいのでしょう。身に沁みついてしまってなかなか切り替えられません...。

 

f:id:imp_a:20200511234449p:plain

別のターミナルからログインして表示。僕は「お魚を飼う」のも好きなのでRloginも使います。

 

上記の「eth0」が有線LAN、「wlan0」がWifiNICが持つ情報を表示しています。

それぞれの「inet」がIPアドレスになります。

 

ローカルなのでIPv4ですが、今後グローバルIP取得しようと思ったらIPv6しかないっていうのなかなか僕的には難しいなと(IPv6でできるようになったことまだお勉強してない)

 

実のところアプリエンジニアでコードばっかり書いています。なのでLinuxなどは準備された開発機しか触っておらずしんどい思いをたくさんしていました。

いやいい環境なんですけどね、分業社会ってやつで。

 

ただ幅を広げるためにも今回一念発起してラズパイを使ってちょっとずつ触っています。Javaを極めても上には上がいるので市場価値上がりませんし。

爆熱対策には、保冷剤です()

 

読んでいただき、ありがとうございました。 

windows10_ファイル名を指定して実行_管理者権限_環境変数Path設定_備忘録

タイトルの通り、備忘録になります。

 

 

僕はできるだけキーボード上ですべての操作を完了させたく、

「ファイル名を指定して実行」をできるだけ使っていくスタイルなので

管理者権限でコマンドプロンプトPowerShellを起動する際に

マウス使うのが嫌で嫌で...。

しかし肝心の設定方法をいつも調べるのですが覚えられず。笑

アウトプットすることで忘れなくなることを狙いました()

 

 

今回はwindows環境におけるコマンドプロンプトと、

PowerShellを管理者権限でマウスを使わずに

起動できるようにするための設定方法を紹介します。

 

いわゆるPathを通すフォルダの作成と、

配置するショートカットの設定方法になります。 

 

 

<作業①>環境変数Pathへの追加方法と設定方法 

環境変数そのものについては、こちらを見てください。

このページ見てる時点でそれなりにわかっている方と思いますので。

qiita.com

 

 環境変数は、コンパネ→システム→システムの詳細設計→環境変数で開きます。

f:id:imp_a:20200506161124p:plain

システム

f:id:imp_a:20200506161310p:plain

システムの詳細設計



 

f:id:imp_a:20200506162851p:plain

環境変数

f:id:imp_a:20200506163112p:plain

環境変数の設定画面

 

この設定画面で、今回コマンドプロンプトPowerShellのショートカットを配置するフォルダを指定します。

僕の場合は「C:\path」を作成しました。

 

 

<作業②>ショートカットでの管理者権限起動の設定

これがなかなか覚えられないんです(笑)

 

「winキー + S」で検索画面を開き、「コマンドプロンプト」と検索します。

そしてショートカットの置いてあるフォルダを開いてください。

f:id:imp_a:20200506163908p:plain

コマンドプロンプトの検索画面

で、対象のショートカットを先ほどPathを通したフォルダにコピペします。

f:id:imp_a:20200506164343p:plain

フォルダ

f:id:imp_a:20200506164414p:plain

pathフォルダ

※僕の場合、配置したショートカットの名前を「cmd_adm」に変えています。

 

で、配置したショートカットのプロパティを編集します。

ショートカット → 詳細設計 → 管理者として実行 にチェックボックスをつけます。

f:id:imp_a:20200506164627p:plain

プロパティ

f:id:imp_a:20200506164755p:plain

管理者設定

これでOKです!

PowerShellについても同じ手順を行えば解決です。

この管理者画面どこにあったか忘れちゃうんです(笑)

 

 

「ファイル名を指定して実行」での結果

f:id:imp_a:20200506165247p:plain

実行画面

ショートカットにつけた名前をここでは入力します。

僕の場合は「cmd_adm」と入力します。

(全然関係ないですが、アンスコつけるととある言語の変数みたいな名前に見える病気にかかってしまいました。)

 

UAC(ユーザアカウント制御)の確認画面が上がります。

その後、しっかり管理者として入れていること確認できました。

 

f:id:imp_a:20200506165453p:plain

コマンドプロンプト_管理者として実行

 コマンドプロンプト起動時のディレクトリは個人的にレジストリいじってますので、興味のある方は調べてみてください。(気が向いたら書くかも)

 

今回作ったフォルダはPath通ってますので、今後フォルダ内にショートカットなどを追加していけばキーボードから手を動かさずに作業を快適に行うことができますよ!

 

それでは!