シェルと環境変数とパスについて
概要
会社の先輩にシェルのパスの通し方について教えて頂いた。
より理解を深めるために自分でも調べてまとめた。
教わったこと
- コマンドを実行する＝シェルがパスを使って実行ファイルを検索し、見つかったら実行する
which <コマンド名>でそのコマンドに通っているパスがわかる- シェルの設定ファイルに記述することでコマンドにパスを通せる
疑問に思ったこと
- 設定ファイルに記述していないコマンドにもパスが通っているのはなぜ？
調べてわかったこと
- シェルは各種環境変数の中身に従って処理を行っている
- シェルの設定ファイルでは、ターミナル立ち上げ時の各種環境変数を設定することができる
- シェルはコマンド実行時、$PATHという環境変数に従ってディレクトリを検索し、該当した実行ファイルを実行している
検索パスについて
通っているパスの確認
- PATHの中身は
echo $PATHで確認できる。
% echo $PATH /Users/horimoto/.rbenv/shims:/Users/horimoto/.rbenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
:は区切りを意味しており、上記で通っているパスは以下になる。
/Users/horimoto/.rbenv/shims /Users/horimoto/.rbenv/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin
パスの優先順位
- シェルはコマンドの実行ファイルを探すとき、$PATHに入っているパスを左から順に検索する
- 先にヒットしたファイルを実行する
疑問への回答
Q : 設定ファイルに記述していないコマンドにもパスが通っているのはなぜ？
A : デフォルトで$PATHに入っているパスがあるから
Web-CABのコツについて
この記事はフィヨルドブートキャンプ Part 1 Advent Calendar 2022 - Adventarの4日目の記事です。昨日はksmさんのRubyとRailsのデバックとコンソールと仲良くする話でした。
フィヨルドブートキャンプの今年のアドベントカレンダーはこちら。
- フィヨルドブートキャンプ Part 1 Advent Calendar 2022 - Adventar
- フィヨルドブートキャンプ Part 2 Advent Calendar 2022 - Adventar
はじめに
naomichi-hと申します。フィヨルドブートキャンプを卒業し、現在就活中です。
就活の中で、webテストであるWeb-CABを初めて受ける機会があったのですが、これが割と準備必須なテストで、コツを知らないと受からない人もいるだろうなあと思い、記事を書くことにしました。
ちなみに自分のWeb-CABの結果は、体感で八割弱くらいで、受けた企業からのフィードバックでは満点評価でした（満点評価はフィヨルドブートキャンプ初らしいです）。
何をしたか
Web-CABを受けるまでにやったことは以下です。
- Web-CABについてネットで調べる
- 一冊本を買う
- 例題アプリをやりまくる
- 一科目ずつ十分に慣らしてから受験
これらについて説明していきます。
Web-CABについてネットで調べる
概要について調べました。
ちょっと調べると色んな記事が出てきますが、肝心の例題は全然出てきません。
しかもたまに間違った情報が載っていたりします（受験時間など）。
ここで時間を使うより、信頼性の高い本を一冊買った方が良いです。
一冊本を買う
Webテスト2【TG-WEB・Web-CAB・WEBテスティングサービス】完全対策 2024年度版 就活ネットワークの就職試験完全対策
を買いました。
あまり例題は載っていませんが、受験時間や問題数などの情報を正しく知ることができます。
ここから始めるのが良いと思います。
例題アプリをやりまくる
https://apps.apple.com/jp/app/cab-web-cab-一問一答/id1582479100
このアプリをダウンロードしてひたすらやりました。
実際のところこれが一番役に立ちました。
試しにやってみるとすぐに気づくと思いますが、普通に解くと時間が全然足りません。
なので、いかに素早く解けるようになるか？を軸に取り組むと良いです。
ここについては後述します。
一科目ずつ慣らしてから受験
Web-CABは一科目ずつ受験することができます。
なので、一科目ごとに自分の中で十分に慣らしてから受けると良いです。
四則逆算を解いて慣らす→四則逆算を受験→法則性を解いて慣らす→…というような感じです。
こうすることで思考を絞れるので、スピードアップにつながります。
素早く正しく解くために
Web-CABはそもそも全問正解できるように設計されていないため、普通に解くと時間が全然足りません。少しでも素早く正しく解くためには、このテストをメタ的に捉える必要があります。四則逆算、法則性、命令表、暗号それぞれについて解説します。
四則逆算
全50問。一問当たり10.8秒。徐々に難しくなっていきます。五択式。
「四則」逆算なので計算は和、差、積、商の四つ。
出てくる数字は整数、小数、分数、指数の四種です。
このうち厄介なのは割り算と小数なので、パッと見て暗算しにくいと感じたら、さっさとこれらを掛け算と分数に変換するとスムーズにできることが多いです。
また、二桁同士の掛け算、五桁以上の足し算や引き算が出てくる場合、概算や近似が有効です。
回答に桁の違う数字が並んでいたら概算で解けるチャンスだと見てやっていました。
電卓が使用可能とのことですが、正直電卓を使っている時間がありません。手元に手書きできるメモを用意し、暗算で解いていくのが基本になると思います。
法則性
Web-CABが難しいと言われる原因その１。
初見は全然解けませんでした。
まずは勝手を覚えるのが先決だと思います。例題を解きましょう。
解き方のコツとしては、「法則性を言語化する」こと。
言語化できないままなんとなくで回答すると引っかかる問題がいくつかあります。
例題を解くときに、「言語化→回答」の流れを意識してスムーズにできるようになると良いと思います。
言語化した法則性のストックが自分の中に出来ていると、自然と解くスピードが上がります。
命令表
一番時間的な余裕があるので、ここでしっかり取っておきたいです。
出てくる主な命令は、
- 上下反転
- 左右反転
- 図形交換
- 図形削除
- 命令削除
- 並べ替え
の六種です。
解き方は、
- 命令削除があれば削除
- 上から順に命令に従う
- 最後に並べ替えがあれば並べ替える
で全部解けるはずです。
この解き方に慣れさえすれば八割以上いけるはず。
あと実際の試験でのコツとしては、もし回答の選択肢に自分が思ったものがなかった場合、解き直すより適当に回答して次に行った方がいいです。どうせ全問は解けないですし、その問題は解き直してもまた同じようになる可能性が他の問題と比べて高いので、その問題を解き直すより、新しい問題に行った方が効率が良いです。
暗号
Web-CABが難しいと言われる原因その２。
これも慣れないと全然解けません。
コツとしては、「ひとつの暗号につき、変化はひとつのみ」と捉えると落ち着いて向き合えます。
それが色の変化なのか、図形の変化なのか…どちらにせよひとつのみです。暗号の変化を言語化した時に、「色が変わって、形が変わっている。」のような二つの変化になってしまったら何かがおかしいと考えていいです。
Web-CABを受けるにあたっての注意点
OSについて
Web-CABはMac OS非推奨です
Macしか持っていない人は仮想環境でWindowsを動かすか、ネットカフェ等でWindows PCを借りる必要があります。
自分は自前のWindows PCを使って受験しました。
受験の期限ギリギリで気づくと大変なので注意しましょう。
命令表の記号
本番は例題アプリのものとは全く違う記号で出てきます。これを知っておかないと、初見でびっくりするかもしれません。身構えておきましょう。
終わりに
この記事を書いている現在、内々定を頂いて、内定の承諾書が送られてくるのを待っている状態です。
本当にフィヨルドブートキャンプの方達にはお世話になりました…。
もしWeb-CABについてもっと具体的に教えてほしいという要望があれば、TwitterにDMを送ってくれれば、お答えしますのでお気軽にどうぞ！
正規表現忘備録
はじめに
Ruby技術者認定試験の例題に触ってみたところ、正規表現について見事にど忘れしていることがわかった。
忘れてしまった時用のメモ。
正規表現リテラル
/で囲むことによって正規表現オブジェクト（Regexpオブジェクト）を生成できる
regexp = /foo/
regexp.class
=> Regexp
このRegexpクラスこそがRubyで正規表現を扱うためのクラス。
Regexpオブジェクトを扱うメソッド例
-
String#sub
- str.sub(pattern, replacement)
- 正規表現のパターン(pattern)にマッチした最初 の部分を文字列(replacement)に置換する。
str = "Hello! world!" str.sub(/Hello/, "Help") => "Help! world!" -
String#gsub
- str.gsub(pattern, replacement)
- 正規表現のパターン(pattern)にマッチした全ての部分を文字列(replacement)に置換する。subと違い、パターンにマッチしたもの全てを置換する。
str = "Good boy, Good boy, You are Good boy" str.gsub(/Good/, "Bad") => "Bad boy, Bad boy, You are Bad boy"
メタ文字
https://www.megasoft.co.jp/mifes/seiki/meta.html
メタ文字を組み合わせることで様々なパターンを表現できる。
まとめ
- Rubyでは/で囲む（正規表現リテラル）ことによって正規表現オブジェクト（Regexpオブジェクト）を生成できる。
- RegexpクラスはRubyで正規表現を扱うためのクラス
- メタ文字を用いることで様々なパターンを表現できる。
参考
DevOps時代のセキュリティ事情に参加しました。その感想。
感想
まだ実務に携わっていないので、ピンとこないお話も結構あったけれど、多くの学びがあった。
箇条書きにすると、以下のようなことを知った。
- 開発手法が変わることにより、開発者の関わる範囲、責任が増している
- DevOps時代の今、セキュリティについて考えないといけないのはインフラ部分だけではなく、むしろCI/CDパイプラインや開発者の端末、OSSなどの脆弱性が狙われている。
- セキュリティを学ぶための基礎として、最低でもネットワークの知識は必要。できればコンピューターサイエンスも欲しい。
- セキュリティについて実践的に学びたいなら、まずは攻撃を知ること。抽象的に知るのではなく、実際に環境を作って攻撃を行うことでわかることがたくさんある。
- 防御は難しい。
お話を聞いていて印象的だったのは、ソーシャルエンジニアリングについての言及が多かったこと。
セキュリティと言うと、ついPC越し、ネットワーク越しにハッキングされるイメージがあったけれど、脆弱性はありとあらゆるところにあるんだな…と考えさせられた。
DevOps時代の今、開発を行うなら、セキュリティとは無関係ではいられないことをしっかり認識できたのが、一番の収穫だったと思う。
Intellij系のIDEと.ideaディレクトリについて
はじめに
私はエディタにrubymineを使っているのだが、新規にプロジェクトを作成しようとすると、.ideaというディレクトリが勝手に生成させるのが気になっていた。
前に少し調べたとき、「.ideaディレクトリ配下にはIntellij系のIDEのIDE情報が入る」という情報を見て、ふ〜ん。エディタの設定的なのが入ってるのかな？ぐらいの理解で、個人開発ならあんま気にしなくてよさそうだなあと思い、gitignoreに/.ideaを追加していたのだけど、今回また目にしたことで、ちゃんと理解したい気持ちが湧いてきた。
そこで調べた。
Intellij系IDEとは
- JetBrain社が提供する開発統合環境
- rubymine、pycharm、phpstormなど、扱う言語に向いたものがある
.ideaディレクトリについて
によると、Intellij IDEはデフォルト形式として、ディレクトリベースのプロジェクトの場合、IDEは.imlファイルと、プロジェクトの設定を保存する.ideaディレクトリを作成する。
.imlファイルについて
によると、.imlファイルは、モジュールの構造設定ファイル。
IDEでは、ひとつのプロジェクトは一つ以上のモジュールからできていおり、それらを管理する。
どう扱えばいいのか？
によると、「ユーザー固有の設定を保存するファイル以外は共有するべき。」とある。
つまり、
以外はだいたいコミットしたほうがいいとのこと。
ただし、.gitignoreでどう設定するかはチーム内で要協議だと思われる。
感想
.ideaディレクトリへの理解が深まった。
ide使ってチーム開発するときは、このへんも要確認だなあ。
とりあえず個人開発では、
.idea/**/workspace.xml
.idea/**/statistics.xml
.idea/**/tasks.xml
を.gitignoreに記述して開発を行おうと思う。
gitについて理解を深めた
はじめに
rubygemにのせるコードが大体できたので、いざ作成だ！と思ってgithubにリポジトリを作成し、ローカルのリポジトリをpushしよう…としたとき、参考に見ていたサイトに気になる単語を見つけてしまった。
「pushに-uをつけることで、上流ブランチを設定します。」
…上流ブランチ？
なんだっけそれ…。よし、調べよう！
こういうことをしているから全然作成が進まないのだけど、気になるものは仕方ない。
とうわけで調べた。
上流ブランチとは
一言で言うと、「普段チェックアウトして使っているローカルの各ブランチが参照先として設定しているリモート追跡ブランチ」となる。
リモート追跡ブランチは名前の通り、リモートブランチの変更をトラッキングしているブランチで、「ローカルリポジトリの中にある」
そして、デフォルトでは、普段チェックアウトして使っているローカルの各ブランチの上流ブランチは、origin/[ブランチ名]となっている。
例を出してまとめると、ローカルにmainブランチがあるとき、ローカルにorigin/mainという、リモートのmainブランチを追跡しているリモートブランチもまた存在し、デフォルトでは、ローカルのmainブランチの参照は、ローカルにあるorigin/mainとなっている。
（ぶっちゃけこんな説明より参考先の図を見た方が100倍わかりやすいです。）
参考：
Git で「追跡ブランチ」って言うのやめましょう \- Qiita
【Gitをしっかり理解】追跡ブランチとリモートブランチは別物！ \| shin>>media
感想
push pull fetch mergeのような、他のブランチを参照するコマンドの挙動がよくわかるようになった。
git学びたてのとき、「git pullは、git fetchとgit mergeの合わせ技！」
「git fetchはリモートブランチのコミット情報をローカルブランチに持ってくる！」
「git mergeはローカルブランチにもってきた情報を反映する！」
「それらをあわせて、git pullでリモートの情報をローカルに反映するんだ！」
という情報を見たことがある
でも、自分はここに違和感を感じていた。
「じゃあgit pullだけでいいんじゃないの…？」と。
この疑問を、今回解消することができた。
つまり、git fetchはリモート追跡ブランチに情報を取得するコマンドで、git mergeは、ローカルブランチと、リモート追跡ブランチを統合するコマンドだった。
思いがけず重要な学びを得ることができた。
gitの理解を深めたことで、より開発に自信を持って取り組めるようになったと思う。
自動化大好きエンジニアLT会 - vol.9に参加しました。その感想。
感想
さまざまなエンジニアの方達の「自動化」に関するお話が聞けてとても興味深かった。（発表の半分ぐらいはわからなかったけど、いくつかキーワードを聞けただけでも参加してよかった。例えば、キーワード駆動テストなんて初めて聞いた。）
中でも、mihoshimaさんが発表されていた、社内ドキュメントの管理にlintとgitを導入し、さらにwebサイトとして公開するというやりかたに感動した。
私は以前、有機化学系の研究室と、化粧品メーカーにいたのだけど、そのどちらでも、研究資料、データ、発表資料、マニュアル…そのすべてがNASにアップされ、自由に更新可能となっていた。
いま思えばとんでもないのだけど、研究室の方は、やろうと思えば一学生がそのデータを全部破壊することだってできたと思う。
会社の方はさすがに各データに権限が割り振られていたし、既存製品の処方に関してはNASではなく、社内の処方データ管理システムで管理されていたけれど、それでも知りたい情報が書かれた資料やマニュアルを探すのは、かなり骨の折れる作業だったのを覚えている。
探しまくってもだいたい見つからないので、結局知っている人を探して聞きにいくことになるのだけど、その人が社内にいなかったら一旦その作業を止めて帰ってくるのを待つということを、よくしていた。（その合間に他の実験とかをしていた。）
ちょくちょく「これではいかん！」と社内プロジェクトが立ち上がって資料やマニュアルを整理整頓するような動きを見せるのだけど、結局そのうち誰も管理しなくなって、似たような名前のワードやエクセルファイルが増殖しまくり、もとの状態に戻っていた。
おそらく業界問わず、似たようなことはさまざまな会社で起こっているのではないか。（少なくともメーカーに就職した私の大学時代の友人たちからは似たような事案を聞く）
こういう問題への解決策として、gitを導入し、htmlとして公開することで解決したのは目から鱗だったし、感動した。
ただ、これができたのはやはりgitが身近なitエンジニアだからだよなあ…とも思う。
gitの学習コストがもっとずっと低くて、pcをあまり触らない人でも簡単に扱えるものだったら、いろんな業界で需要がありそうな話だなあ…と思った。
