brand new note

ジャズ屋が技術の話をするところ

大学の授業から先の学びって

独学はきつい?

独り言になりますが、Cを始めプログラミングの独学はなんだかんだいって辛いものがあります。学ぶだけでいつまで経ってもものができないとか、専門用語が多いとか。プログラミングの単位取るのがめちゃくちゃ辛いとか、なにがなんでも学ばないといけない環境に身を置くとか、そんなことをするのが習得には最も良いと思うんですが、実際そうでもないなという学生の為に今やっていることを書いておこうと思います。まだ自分の実装力は0.00001くらいです。

授業でやったもの

標準入出力、配列、条件分岐、繰り返し、関数、若干のポインタ

この程度です。正直そこから先の学び方はあんまり教えてくれません。プログラミングの使いどころが分からず諦める人や自分のようにいつまで経っても「やりたい」が「できる」に変わらない人も多いような気がします。こういう場合、「実際そんなに作りたいものがない」という理由が挫折を生む原因の大部分を占めている気がしています。じゃあ諦めるしかないのか。。。

いまやっていること

自分の場合、今はサーバやネットワークが専門なのでlinuxを触る機会がこの1、2年でかなり増えてきました。普段使いのPCをwindowslinuxの2台持ってどちらにも対応できるように練習中です。Cはvimで書いてます。windowsの場合vidual studioを使う方も多いですが、個人的にはこちらの方がエディタの練習もできていいかなと。

またlinuxカーネルはCで実装されているので、これをいつか読み解きたいというのが今のモチベーションになっています。こうなると「何かを作りたい」という欲求よりも「仕組みを知りたい」という「わりと勉強寄り」なところがあるので、サーバエンジニアを目指したいとか、モノ作りが好きというより授業を真面目に受けるタイプだ、とかいう人によってはこういうはまり方もありかなという気がしています。作りたいもの作る欲求がある人はもっと別な方法で勉強できると思いますし...

カーネルのソースを見てみると関数、ポインタ、マクロあたりを(授業のレベルをはるかに超えたところで)学べるので、自分はしばらくこれらと格闘することになるかと思います。まださっぱり分かりませんが「非常に美しいコード」との事ですし、何よりlinuxひいてはコンピュータの仕組みをがっつり学べる所に魅力を感じます。メモリ管理とかプロセススケジューリングとかも学べます。

使うサイト

普通に授業受けてるだけだとこのへんのサイトの使い方は教えてくれないんです。レベルが低いだけと言われればそれまでですが、学生であっても早いうちからこのへんは知っておくべきだと思います。エンジニアを目指すならできるだけ早く専門用語が飛び交う所に身を置いた方がいいです...ネット上だけでも。

  • qiita

プログラマのための情報共有サイト。プログラマだけでなく全てのエンジニアが活用していると言ってもいいと思います、Cに限らずここ1、2年は疑問があった時は気づいたらここを読んでます。

Login - Qiita

  • terarail

エンジニアのための質問サイト。最近使い始めました。悩んだらここに疑問を書くと強い人が解決してくれます。インフラは未知数ですがプログラミングの疑問解決はここです。

teratail【テラテイル】|思考するエンジニアのためのQAプラットフォーム

自分が作るアプリケーションや作業したものをここに上げる練習はしていて損はないと思います。最初はきついですが雑誌やネット上の記事を頼りにするといいと思います。もちろん使っている方の身近で教わるのが一番の近道です。

The world's leading software development platform · GitHub

  • paiza転職

AtCoderとかでプログラミングをやるのもいいですが、難しいと感じたらここの問題からやってみるのもいいと思います。わりと最初の達成感は大事なので、できる問題から解きましょう。。。

ITプログラマー・エンジニア転職のpaiza転職

  • その他

あとはドットインストールとか、個人でやっているようなプログラミング学習サイトは探せば沢山あるので、まずやること、やる言語を決めましょう。始めたらものを作るでもいいですしアプリケーションなりカーネルなり、他人の書いたソースを読み解くでもいいです。分からないにぶつかって解決する、を楽しんで続けるのが難しいんですが、一番大事です。

おわりに

こういうところを教えてくれる人が周囲にもっと早くいたらよかったなーと思って書いていたら愚痴みたいな自戒みたいな文になってしまいました。。。精進します。なにかの参考になれば。

gitの使い方

ネットワークとサーバを専門にするとほとんど開発やgitの仕組みを理解できないままなので、基本的なところをコードの書ける後輩に教えていただきました。

qiitaの方がよっぽど参考になるからあまり見る人はいないよね、と仮定して自分用のメモだと思って随時追記していきます。でも誰かの参考になったら嬉しい。というかうちの学科はそもそも授業でgithub使わn

基本的なところ

gitとgithub

gitは手元(ローカル)で使うプログラム/ファイル管理ツール。gitで編集したものをgithub(web上のソース公開ツール)に上げることによりソースの共有ができる。バージョン管理の概念がまず最初にあって、大人数で開発をするときに各々が差分を適切に投げ、また最新の作業ファイルを投げたweb上から引っ張ってきてローカルで作業をする。これはどこでも言われているところだと思う。

gitの使い方

  • 1: コードを書く。なんかつくる。
  • 2: git add する。つくったものをステージングエリアに乗せる、という。ここでファイルはいわば下書きの状態で、まだ細かい編集はしやすい。
  • 3: git commit する。いわば清書。
  • 4: git push origin master する。web上のgithubリポジトリに作ったものを投げること。

で、そもそもgithub上に「リポジトリ」を作っていないとだめで、git init かweb上の操作で作る必要がある。リポジトリは1つのアプリケーションに必要な素材を入れていく作業部屋のようなもの。上記手順は投げるまでの基本動作。

origin、master

originは「リモートリポジトリ」のことで、すなわち作ったものを投げる場所のこと。反対に、「ローカルリポジトリ」もあって、これは手元の作業環境、すなわちaddしたりcommitしたりする場所のこと。 masterは「master branch」のこと。github上にはbranchという概念があって、バグを直したりする際複数人で作業が同時にできるよう、一時的にmasterという「作ったものの大本」をコピーしてそこで作業するやり方がある。これを「ブランチを切る」とかいう。直したらmasterとマージする。

一人で作業する分には同時並行することはないのでbranchはあまり使われないらしい。

pull

pushの反対で、大人数で開発するとき使う。他の人も含めて作られた最新版のアプリケーションを編集するときは、作業開始時に自分の手元(ローカルリポジトリ)にある作業ファイルを更新しなければいけない。ここでリモートリポジトリからgit pullをして手元の作業環境を最新版にする。古いものとの差分は自動で更新してくれる。

言ってみれば上の手順0ともいえる大事な部分である。でも一人で作業する分にはあまり重要ではないのかな?

初期設定

qiita.com

とりあえずここに書いてあるコマンドを打ち込んでおいた。 git status とか見ながら自分のアカウントのリポジトリにpushまではできた。 作ったものをいっこいっこ上げるだけじゃなく複数のプログラムがひとつの「もの」を作り上げるようなイメージがあるんだけど、そこまではまだ達していない(2/18)。

実際に打つコマンド

git init 
git add .
(git status)
git commit -m "description"
git push -u https://github.com/自分のユーザ名/リポジトリ名 master

つくってるもののディレクトリに入った状態でコマンドを入力する。git add . すると現在いるディレクトリの中のもの全てがステージングエリアに乗るが、ファイル指定も可能。git statusでaddしたもののリストを確認でき、間違えたらgit reset HEAD . すれば元に戻る。commit する際は-m で説明を入れておく。日付とかでいいのか。最後のところはgit push origin masterでもいいけど、おそらく複数のリポジトリを管理している場合は初回のみ一度どのリポジトリに入れるか指定したくなるので、こうなる。pushする際はgithubアカウント名とパスワードの入力を促されるので入力する。

やって覚えた必要事項

  • 昔cloneしたコードをもう一回読みたくて掘り出したら、「おれがもらってきたこのコード、元々誰が書いてくれたんだっけ」ってなった。解決するには「git remote -v」。つまりgitリポジトリのoriginのURLを確認できる。(5/8)

その他参考リンク

Rust製gitラッパー "rusgit" - Qiita

gitリポジトリのoriginのURLを確認する - Qiita

コマンドを自作してみる

くそみたいなコマンドを自作することによりLinuxシステムを身近に感じる練習。

事前知識を先に挙げておく

内部コマンド

組み込みコマンド、ビルトインコマンドともいう。bashにそもそも備わっているコマンド。 cd,cpコマンド等。

rm -rf /* しても消えない。

またtypeコマンドを使うと、typeの次に打つコマンドが内部か、外部コマンドかを判別してくれるので実験してみるといい。

外部コマンド

/binディレクトリ配下に格納されるコマンド。 新しいコマンドのインストール先もこことかになる

rm -rf /* すると使えなくなる。

$PATH

環境変数の一つ。外部コマンドの参照先を表す。 echo $PATH すると見られる。

たとえば上記で出力された/usr/local/bin や /usr/bin に移動すると、コマンドを司るファイルが無数に存在する。言い換えれば、ここで自作したコマンドを動作させるようなスクリプトを書けば良い。 ただ、このディレクトリ下に直接作ったコマンドを投げ続けるといらない一時的に使うだけのコマンドが溜まってしまうので、そうならないように~/.local ディレクトリにスクリプトを作ってシンボリックリンクで$PATHに飛ばすのが美しいみたい。参考は以下。

qiita.com

つくったもの

ファイルの数だけ○ンシャイン○崎が叫ぶコマンドlsikzk f:id:frazz:20180217232630p:plain

標準出力と標準エラー出力の話

実行結果をログに残そうとして、標準出力とか標準エラー出力ってなんだろうってなったのでメモ。基礎の基礎ですね…。

事の発端はntpdate

ntpdateコマンドは、ntpサーバから時刻情報を取得し表示するコマンドです。この出力結果をログに追記するよう作りかけのスクリプトを改良していたのですが、うまく書き込みされなかったというのが発端です。

そのときはスクリプト内に「2>&1」を追記したら解決したのですが、その意味をよく理解しないまま「あ、動いた」で流れてしまいました。なので「ntpdateコマンドのデフォルトは標準エラー出力なのか??」などと考えてましたが、そうではないです笑

https://teratail.com/questions/1285

ここの「2>&1って何だ」という疑問の記事を読んで解決しました。

詰まった当時は標準出力と標準エラー出力スクリプト内で一緒くたになっており、ファイルに書き込まれる分と画面に出力される分がばらばらになって、うまく行かなかったようです。

同じテキストやログファイルに色んなものを出力するには、このへんを頭に入れてリダイレクトしないとうまく記録できないので注意が必要です。

せっかくなのでntpdateの説明

ntpdateコマンドの実行結果(ubuntu)と参考サイトは以下になります。 f:id:frazz:20171107213829p:plain

コマンドが使えない方は sudo apt install ntpdate とかして入れてみましょう。

ntpサーバのIPアドレスはインターネットマルチフィード(MFEED)を使ってみます。誰でも使えるntpサーバは他にもあるので、試す方は参考サイトを見てみるといいと思います。

時刻情報を取得してテキストファイルに入れているだけですね。ここで「標準出力できてんじゃん!」と気づきました(遅い)

時刻同期にはすぐに同期するstepモード(-bオプション)と徐々に同期していくslewモード(-Bオプション)というのがあるらしく、ここではslewモードを使いました。ケースによって使い分けるんだと思います。

syslogに出力する-sオプションっていうのもありますが、ちょっと試した感じではちゃんと出力できませんでした。syslogをちゃんと理解していないからでしょうか…次の課題になりそうです。

ssh先の端末出力は操れない?

色々あって親となるサーバからssh先の標準出力を動かせないかなーと試行錯誤していたんですが、できなかったという話です。 まあセキュリティ的に無理だろうということは1秒考えれば分かるのですが、色々回り道したことをメモします。

いじったもの

ttyコマンド

f:id:frazz:20171023231536p:plain

今自分は端末の何番を使ってコマンドを打っているのかが見られます。画像なら2番ですね。/dev/pts配下は端末を制御する場所になっているので、コマンドやログの出力結果をどの端末にリダイレクトするか、みたいなことができます。以下が参考になりました。

ttyとかptsとかについて確認してみる - Qiita

ssh -t とは

ssh 端末 出力」 みたいな検索をしていたのでたどり着いたんですが、今回は関係ありませんでした。 多段sshというのかな? 初めて知ったんですが、「踏台サーバの先にあるいじりたいサーバ」に一発で入りたいときには、踏台ぶんの端末を一時的に割り当てる-tオプションが使えるそうです。

sshで踏み台経由時のショートカット - Qiita

sshの実行結果は大体実行元が出力する

$ ssh [user@IP_address] [command]

このcommand部はもちろんssh先のものとして実行されるんですが、コマンドを打った時のプロセスは親のサーバにまとめて入っています。

何もしなければ実行結果の標準出力も親サーバにまとめて入ってきます。ログファイルを生成しても、保存されるのは親となるサーバです。これを実行先のサーバで出力したいというイメージがあったんですが、どうやってもできませんでした。かろうじて操れたのはwallコマンドくらいです。

なので実行結果をログに残して、親サーバの端末を実行先のサーバ分複製し、保存したログを端末毎に出力させて事なきを得ました。

$ ssh [user@IP_address] [command] > hoge[x].log
$ cat hoge[x].log > /dev/pts/[y]

本当は間にlogの成型とかありますが、解決策のイメージはこんなんです。

おわりに

この一件でsshとか端末の仕組みとかログ成型とかに慣れてきた感じはしますが、我ながら理解しづらい文章になってる気がします。ご指摘あればよろしくお願いします。

Linuxのリソース確認コマンドについて

Linuxのリソース確認に関する個人的なまとめ。

細かい内容は随時追記します。

リソースって何

簡単に言うとコンピュータが計算とか命令をするための資源です。大まかにはメモリやCPU、ネットワークI/O(入出力)のことを指します。これらの使用率や処理速度を、Linuxディストリビューションではコマンドを打って確認することができるわけです。

何のために見ればいいのか

大まかには以下の理由が挙げられます。

  • 新しく中古で買ったノートPCに適当なイケてるOSを入れてスペックを確認したい!

  • PCやサーバの動作が重い時に何が原因なのかを切り分けたい!

  • リソース監視ってマシンを操ってる感じがしてイイ!


...真面目に言うとサービスが動いているサーバやコンピュータの調子を見るためにこういったコマンドでリソース不足がないかどうかを確認します。アプリケーションが暴走してCPU使用率が100%に貼り付いていたり、サービスがアクセス過多に陥ってネットワークI/Oがいっぱいいっぱいになったり、いらないプロセスが増えてメモリが圧迫されているのを観察できれば適切な対処ができます。

コマンド

オプションは他のサイトを参考にしてください。今のところはいったいこのコマンドはなんなのか、といった意味合いでの説明しかできませんので、そのへんの方の参考になればと思います。

mpstat

f:id:frazz:20180316122807p:plain CPU使用率を詳し目に見ることができます。CPUにはユーザモードとカーネルモードという動作モードがあって、idleが使われていない部分、userがユーザモード(ざっくりいうとOSやプロセスが使っている部分)、sysはカーネルシステムコールを発行している部分です。

vmstat

f:id:frazz:20180316123343p:plain メモリ、I/O、CPU使用率を簡単に見ます。表記が省略されてて逆に読みづらいので自分はあまり使ったことないです。

dstat

f:id:frazz:20180316124626p:plain 最初は入っていない場合があるのでyum install dstatで入れます。CPUやディスクI/O、ネットワークインターフェースのトラフィックを1秒毎に観測できます。画像では指定していませんが、インターフェースを指定したい場合は-iオプションとかつけます。

iftop

f:id:frazz:20180316130311p:plain これも最初は入っていない場合があるのでyum install iftopとかして入れます。画像では出ていませんが、ネットワークのインターフェースを指定するとリアルタイムにトラフィックIPアドレスと共に確認できます。右下の3つの数字は左から2,10,40秒間隔でのスループットの平均値になります。TXが送信、RXが受信です。

top

f:id:frazz:20180316130550p:plain CPU使用率、ロードアベレージ、プロセスの推移をリアルタイムで確認できます。実はリモートデスクトップをしたい場合に踏み台サーバでtopコマンドを動かしっぱなしにしておくと接続が切れない、といった小技としても使えます。

sar

f:id:frazz:20180316130854p:plain 何も指定しなければ直近のCPU利用率を10分間隔で出力します。-rオプションでメモリも確認できます。出力の時間間隔の設定やリアルタイム出力もオプションで指定可能です。

free

f:id:frazz:20180316131058p:plain メモリの空き領域を確認できます。totalが物理メモリの総量、availableが実質的に空いているメモリ量です。swapはスワップ領域で、ストレージの一部をメモリ領域に見立てた部分です。これは物理メモリとは異なります。メモリ不足が起きてしまったときに一時的にあふれた分の処理を行います。

参考

この記事だけ見て納得しても、もっと深い話が分からないと自分で実行した時に何の面白みも感じられないかもしれません。いろいろ記事や本を読んで理解を深めるといいかもです。自分も勉強中です。

qiita.com

medium.com

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

第31回シェル芸勉強会にお邪魔してきた

先日ちょっと憧れだった技術系の勉強会に初参戦しました。

シェル芸とは

主にUNIXオペレーティングシステムにおいて「マウスも使わず、ソースコードも残さず、GUIツールを立ち上げる間もなく、あらゆる調査・計算・テキスト処理を CLI端末へのコマンド入力一撃で終わらせること」

こういう説明をされるととってもロマンがあって面白そうじゃないですか…?

情報を学んでる人はみんなゲームとか作れる、みたいに思われがちですが、自分はネットワークメインで勉強していて実装力が0なので、Linuxのコマンドをガンガン打ったり、ごりごりスクリプトを書いたりアプリを作ったりすることはできません。そこで手を動かす技術に慣れる為の取っ掛かりとして "シェル芸" を始めるに至りました(就職しろ)

学んだこと

今回の参加で得た知見をまとめてみます。

プログラミング言語でありコマンド(?)。幅広いOSで動作。ウェブアプリやシステム管理、テキスト処理に強く、正規表現が使えます。テキスト処理はgrepsedawkを少しかじってただけで、perlは今回初めて触りました。コマンドの使い勝手による論争はあるみたいですがワンライナーの強い味方です。で、perl -pe で始めるとsedっぽく使えるよ、という話がこちら。理解不足ですが良記事な感じはします。

環境に依存しないワンライナーを書くならsedよりperlの方がいい - Qiita

このデータをテキストに直して端末上でこう編集したい!みたいな時にコマンド内で使う技が正規表現です。本場のシェル芸人は正規表現を打ち込むスピードが違う。こういう技術を身近に感じたいなぁと思います。

サルにもわかる正規表現入門

分かんない。はやくサルになりたい。

  • awkのNFとgensub

awkのNFは文字列を後ろから見るとき使います。awk '{print $NF}' なら、そのファイルの各行の末尾を出力。NF==2とかにすれば、末尾から2つを出力できます。 gensubは指定した文字列を特定の文字列に変換できる組込み関数です。subやgsubの上位互換?とりあえず組込み関数って言葉と便利なものがあるということは分かりました。

awkで末尾から数えてn番目のフィールドを取り出す。 - Qiita

  • sort

行を並び替えて整理するコマンド。オプションで並び替える順番を変えられます。これは都度覚えればいいのかな。

  • uniq

重複した文字列を削除するコマンド。-dで逆に重複したものだけ残すことができます。sortと組み合わせて使ったりします。

  • xxd

バイナリを16進数に変換するコマンド。-rで逆も可能です。一人前のシェル芸人になるには文字コードとか解析したりしないといけないらしいので、個人的にこの辺は必修科目です。

  • fold

文字列を指定した文字数で改行するコマンド。テキストの見栄えが良くなるってことなんでしょうか。割と便利そうです。

  • だいぶレベルが高い

勉強できるだけでなく、技術好きな方に実際に会って刺激を受けられるのいうのは貴重です。問題を解くだけでなくLT等で普段聞けない話が聞けるのも楽しみですね。自分が無限に実力不足だということを実感出来ます。しんどい。

第31回シェル芸勉強会 3/3(LT) - YouTube   LTはこちら。

おわりに

今回こういったイベントに出向いてみて、技術に対する親近感が結構沸いたのではないかなと感じました。こうした機会は研究でも段々増えているので、今後吸収できる知識量を増やしていければと思います。あと、次回のシェル芸勉強会は12月らしいです。予定が合えば行こうかな…