  |
はてなキーワード: シェルスクリプトとは
標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している？
標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、
入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます
「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう
規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です
すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
メンテナの数、レビューする人数、実際に動作している環境etc
横からだがシェルスクリプトで使用してるコマンドの仕様を把握するのなんて高級言語で使用するAPIの仕様を把握するのと同じぐらい基本的で当たり前のことだよ。manっていうコマンドを使ったり、より簡易的には--helpのようなオプションで確認できるよ。
例えば、ファイルをあっちからこっちにコピーして一時的に待避するだけならシェルスクリプトでcpコマンド書くのがコスト最小でしょ。現実のシステム運用では費用対効果を考えていろんな仕組みを使い分けてるんだよ
シェルスクリプトに使用したコマンドのすべての挙動を把握している？
使用予定のオプションだけでも出力結果のすべてのパターンを把握している？
人が手て使うことを想定された曖昧さの残るコマンドと、高級言語の機械が使うことが前提の曖昧さの少ない機能だと全然違うものだと思うが
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
横からだがシェルスクリプトやばい増田へ。これほど丁寧に解説して貰えるのはありがたいことなのでよく読んで理解しておきなよ
君の好きそうなところだとDockerのコンテナイメージのentrypointは基本的にシェルスクリプトが指定されてて、もちろんいろんな会社がプロダクション環境で動かしてるよ
世界中のITシステムを稼働させている企業は99.9%以上やばいということだな。そうすると公務員が次の選択肢になりそうだが役場から省庁から何とか法人まで探してもシェルスクリプトをプロダクションで使ってないところなんてないよな。小さな村の役場とかならワンチャンあるか。その素晴らしいITスキルを生かして紙とペンで革命を起こすんだ
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
「http リクエストを５０回実行するシェルスクリプトワンライナーをサンプルを表示してほしい。またリクエスト後にhttp レスポンスコードをチェックし500番台だったら実行停止してエラーメッセージを表示するようにしてください。」
ChatGPTにたいして上記の命令からはじめて、１０分くらいの作業時間で動作テストしつつ自然言語のチャットのやりとりでバグを取りつつ非同期実行などの追加仕様を加えてGo言語にリプレイスして出来上がったコードがこれです。
自分でコードはほとんど書いてませんが数行程度の手直しはしました。
注：このコードは結局500番台で全Goルーチン生成抑止/実行停止するわけではないので非同期実行化した際の仕様バグがまだ混入してますが、まあとりあえず動作はします。またGoルーチンを無作為に大量生成してしまうのでこれを抑止するような機能もあった方が良いでしょう。このレベルの仕様バグを解消するには非同期実行時の正しい動作を定義した上であらためて作業した方が手っ取り早そうですがこの文書の目的から外れる作業だし、めんどくさいので放置することにしました。コマンドライン引数周りの細かなバグについても同様です。
【所感】
ChatGPTは平気で嘘つくし、ドメインナレッジにまだ乏しいし、この例だと例えばsyncパッケージ使わない的な単純なバグも平気でしこんでくるのでまだ信用できないやつですが、嘘やバグを見抜ける程度の普通の技術者が監督するなら現時点の水準でも作業量を大幅に削減できるしオーバーテクノロジー感があります。特に小さくて雑なアプリケーションを書いて手法を実証するようなプロトタイピングフェーズなら現時点の技術水準でも大いに役立つでしょう。
我々ITエンジニアは今後１０年くらいのスパンで言うならば課題設定能力、ドメインナレッジの注入、コードレビューの力量とQAの力量、そして役立つアプリケーションが本当に役立つかを実証する能力（ビジネス的？）が問われるようになってくのでしょう。そして最終的には目的の設定と評価のフィードバックループを回し続ける現在のプロダクトマネージャーのようなスキルセットに移行する事になるのでしょう。
YouTuberを始めるにあたって昨日今日と環境構築をしている。
動画のジャンルは内緒として、ひたすら効率良く動画を作ることを志向してる。理想は新規のMarkdownファイルがGitHubのmainブランチにマージされたら自動でYouTubeの自分のチャンネルに動画が投稿される、みたいな状態。
まあそこまでやるのは調べるの大変だし事故とかbanが怖いしまずYouTuberとして大成しないことにはって話なので、どっかで妥協すると思う。てかCI/CD周りちゃんと仕事でやっとけばよかったな。
テキスト読み上げで商用利用するなら今はVOICEVOXが良いのかなと感じた。
ただ、作成した音声に合わせた字幕ファイルを作るのがひたすら面倒くさい。絶対自動出力できそうなのに。
VOICEVOXから直で出してくれたら楽だったんだけど、リップシンク用のファイル出力しか対応してなかった（どっかでやってる人がいるかもしれない）。
VOICEVOX公式のGitHubでissue上げることも考えたけど、俺自身がまだ動画一つも上げてないし、字幕ファイルの需要がどれほどのものかも分からないので、とりあえず変換用のスクリプトを自分で書いてみた。
VOICEVOXのプロジェクトファイルであるvvprojファイルの中身はバイナリではなくただのJSONなので、エディタやエンジンのソースコードを弄らなくても、比較的簡単に字幕ファイルに変換できる。なお今回俺はDenoを使った。
こういうシェルスクリプトみたいな小さい仕事やるのにDenoはまじで楽。
あとは動画作るときに需要ありそうだなと感じたら、SubViewer以外のマークアップに対応させてissue上げるなり俺のrepoに置いとくなりしようかな。
エンジンの実態はhttpサーバーらしいので、上手くやれば意外と労力かけずに理想に近い自動化が実現できるかもしれない。
