アカウント名:
パスワード:
若いシステム管理者がサーバメンテナンスのスクリプトを書いていたので肩越しに覗いてみましたよ。
テキストエディタ(Windowsの)の機能をフルに活用し、大量のコマンドをコピペコピペ、置換置換…というように並べて作ってましたね。
萎えた。
そこは、あーしてこーして、awkをちょちょいと振りかければ10行で書けるだろ?その方が作るのも早いし簡単。
せめてエディタはviでやったほうが、編集も早いよ。マウスでドラッグして選択とかやってられんだろ。
というわけで、プログラムとまでは行かないにしろ、スクリプト言語くらいはシステム管理者は使えた方がいいと思う。
シェルスクリプトを書けるか書けないかで、仕事の効率は10倍くらい違うことも。ていか、シェルスクリプトも書けないのにシステム管理者をさせてるのが悪い。
Windowsサーバの管理者も、Power Shellとか使えたほうがいいんじゃないかな。
システム管理者ってわけじゃないけど、あるシステムのクラウドへの移行作業で、同僚が手作業に固執して困ったことが。手作業でも可能な作業時間・費用をもらってたけど、スクリプトでやった方が短時間ですむだろうし、ミスも少ないだろうに。自分の仕事を盗られる様で嫌だったのかなあ。彼はプログラミングは得意じゃないみたいだし。
もっとも、最終的には私がスクリプトを組んで作業しましたけどね。
ところで、
Windowsサーバの管理者も、Power Shellとか使えたほうがいい
PowerShellな。「Power」と「Shell」の間は空白無し。
手作業に固執する人って少なからずいますね。普段そのシステムを管理していて、イレギュラーな調査を頻繁に行っている人に多い印象です。手作業に固執されてしまう状況に遭った時にはその人に理由を訊くようにしていますが、こんな理由が出てきたのを覚えています。
・慣れないスクリプトによる自動化作業より慣れた手作業の方が信頼できる何か想定外の事態があった時に違和感を感じやすいのは慣れた作業の方だとの話。
・手作業だと各作業を目検できるので想定外の事態を把握しやすいこれはスクリプトでやってもポイント決めて検証すれば同様かと思いました。
・「スクリプトを使用する」という要因によってトラブルが発生する可能性を増やしたくないスクリプトの信頼性より人間の信頼性の方を高く評価している場合ですね。# 私は自分が一番信頼できませんが。。
システム管理者じゃないですが、多数(数百人)の人が入力した情報を集計するような作業をしたことがあります。締め切り日に向かって順次入力されていく情報のアップデートを知りたかったこともあり、手作業はもとより頭になく、スクリプトを使った作業を行いました。その基本路線は正しかったと思っています。
ただ、中には書き方に関する指示を無視したり(例えば名前とふりがなを逆に入力するとか)する人がいて、そういうのはスクリプトに例外処理を作り込むことで対応しましたが、そのチェックの手間が膨大なものでした。(1)正しく処理できているかどうかをチェック(2)正しく処理できていない項目を見つけたときには、例外処理を追加(3)例外処理が変な副作用を起こしていないかチェックを繰り返し行いました。世の中には、こちらには想像もつかないような、きわめていろんな変な入力の仕方をする人がいるものだと思いました。
1回限りなら手作業の方が早かったかもしれません。でも何百件もあると、手作業だと、総数を数えるだけでも数えるたびに異なる結果になったり。
今時の若造はawkなんて知ってるはずありませんよ勧めるならRubyぐらいにしとかないと年寄り扱いされます#ターミナルやキーボードの仕様の相違をアプリケーション側で吸収しなければならなかった時代じゃないんだからviはもう卒業してくれ
個人的にはRubyを勧めたい気持ちはよく解るんだけど、そうできない事情もあるんだよ。と言うのは、UNIX系で、Rubyがインストールされていない環境があるから。そう言う環境でも、awkが入っていないことはまず無い。インストールされてなきゃ、入れればいいじゃないか、ってのも甘い。ポリシ・規約でインストールできない場合があるから。自宅サーバじゃなくて、仕事だからね。
起動コマンド名を変えて提供されている場合が多いでしょうから、その場合はお目こぼししてもいいと思う。← Cygwin 標準のviコマンドとか
// ksh由来の 'set -o vi' と正反対の設定については宗教戦争モノなのかなあ?
Perlにawkスクリプトを流せばいい
# だめだ、つまらん
viかどうかはともかく、マウスはだめでしょう。キーボードからマウスに手を持って行く、その移動距離が無駄。
「ターミナルやキーボードの仕様の相違をアプリケーション側で吸収しなければならなかった時代」よりもずっと現代は進んでいるはずなのに、マウスなんていう、キーボードから離れたところに置かないといけないデバイスがいまだにのさばっています。
マウスだけでほとんど用件が済んでしまうような、ウェブ閲覧だけのエンドユーザーならともかく、システム管理者がそれじゃあ話になりません。
トラックポイントやタッチパッド(親指で操作)なら、まだいいけど。
まあ、さすがにawkはないわな・・・。viの悪口は許さないけど。
これがね、なかなか、awkが必要な時があるんですよ。RubyどころかPerlも入ってない。ネットにはつながってない(外部と隔離されている)のでインストールもできない。けれど、複雑な文字列操作をやるスクリプトを書かなきゃいけない。
そんなときにawkが役に立ちます。
UNIX系のシステムなら、OSに標準装備のスクリプトを動かすためにawkは必ず入っているので、そんな時でも大丈夫なんです。
Rubyがーとかいってるシステム管理者は、たくさんありふれているありきたりなLinuxサーバとか管理しているだけの人じゃないかな。そんな恵まれている楽なサーバだけじゃないんだよね、世の中。
>#ターミナルやキーボードの仕様の相違をアプリケーション側で>吸収しなければならなかった時代じゃないんだからviはもう卒業してくれ
これ、中より下くらいのシステム管理者が勘違いしやすいところだけど、viは低機能で基本的なエディタで、大抵のUNIX系環境に標準で入ってるから使えって言われていると思っている?
確かにそういう面もあるけれど、それだけじゃない。viのコマンドを駆使すると、すごく効率よくスクリプトやテキスト編集ができるんだよ。そこらのテキストエディタと比べても、かなり高機能多機能な
プログラミングに肝心なのは、格好良く書くことではない。解りやすく、確実に動作することである。その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が優れたプログラミンなのである。まあ、私は昔8ビットのアセンブラーでグラフィックの描画を作っていたけど100命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
システム管理者のプログラミング云々にアセンブラを出してくるのは変だし、アンロールした方が解りにくいよね:b
プログラマーとしてはプロでも、システム管理者としてはド素人とお見受けする。
>プログラミングに肝心なのは、格好良く書くことではない。>解りやすく、確実に動作することである。
格好良く書けと主張した覚えはないけど?でも、ソースコードを格好よく書くというのは、解りやすく確実に動作するにはとても重要で肝心なところ(二重に強調させてもらうが)。ちゃんと動いているように見えるからと言って、ぐちゃぐちゃなソースコードは、ちゃんと動くかすらわからない。
となると、それを知らないあなたはプログラマーとしても素人なのかもしれないな。
>その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が>優れたプログラミンなのである。
例えばだ、5000ユーザの設定をまとめて変更する必要があったとしよう。1人のユーザの設定変更のコマンドを何行か書き、それを4999回コピーし、ユーザ固有の部分を目視しながらマウス操作でコピーして編集していく。
単純だけど、これは質の悪いプログラムだ。ちゃんと動くとは思えない。5000人分のコマンドを手作業でなおしていくと、絶対にミスをする。これはとても優れているとは言えない。時間もかなり大きくなる。
それよりも、じっくりしっかりきれいに10行で書いたスクリプトを書き、それを使ったほうが圧倒的に速いし確実だし優れている。
大昔のシステム開発では何行のコードがいくらという価値を持ったのかもしれないが、システム管理者が書くスクリプト、プログラムは自分たちで使うもの。自分たちが楽をし、ミスをしないために作るもの。行数が多ければ優れているというわけではない。楽にならなければ意味がない。
百歩譲って、コマンドを書き並べられたスクリプトが優れているとするなら、そのコマンドを書き並べるスクリプトを書くというのがシステム管理者の正しい姿なんだよね。コマンドをひたすら書き並べるだけなら、スクリプトにせずにそのまま実行するでしょう?
>まあ、私は昔8ビットのアセンブラーでグラフィックの描画を作っていたけど>100命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
そうですね、システム管理者のプログラムとしてはド素人の考えですね、それは。
同意。ただし、大昔のシステム開発なら、いかにコンパクトに書くかがむしろ重要だった。贅沢な環境じゃなかったんだよ。だいたいコーディングシートに手書きしているのに同じ事を何度も書いてたまるかっての。そこだけは認識しといてもらいたいね。
1回しか実行しないプログラムやクエリであれば、Excelで作ってしまうのが楽で確実です。
その手のものなら、UNIXではbashなどのシェル、WindowsならPowerShellを使う方が楽。コピペすら必要ない。例えば、bashなら
for user in $(cat users.txt); do echo "command_for_user -option1 -option2 $user"; done
とか。伝統的には、awkを使って、
awk '{print "command_for_user -option1 -option2 ",$1}' users.txt
とか。結果を一旦バッチファイルに保存して実行しても良いし、パイプで/bin/shに食わせてもいいね。もちろん、もっと現代的な言語で書いてもいい。PowerShellなら、
Get-Content .\users.txt | ForEach-Object {"command_for_user -option1 -option2 $_"}
とかな。既定のエイリアスを使って、
cat .\users.txt | foreach {"command_for_user -option1 -option2 $_"}
と書くと、ストローク数が減るし、UNIX風に見える(笑)。
ストローク数云々は冗談だけど、手数を減らすのはミスを防ぐのに効果的。僕は、できる限りマウス操作は避けるようにしてる。
私は全くの他業種だけれども、一回しか使わないのなら知っている方法だけでやるのが早いし楽だと思う。そういう意味で色々手段はあるけれど最初に思いついたのがExcelなら、それでやってしまう方が実際には手数も多いし面倒だとしても結果早いのではないでしょうか。(システム管理者ならCUIに抵抗が無いだろうし、どんなマシンにも入っている訳ではないExcelはちょっと変なのかな?)今回のネタ的にはある程度広く浅くプログラミングが出来た方がもっとスマートな手段を使えるようになるって事だろうけれど。あと、どんな仕事でも多少知っている人の方が無茶振りしなさそうでいいなぁ。
私は全くの他業種だけれども、一回しか使わないのなら知っている方法だけでやるのが早いし楽だと思う。
素人システム管理者であれば、それでいいと思います。でも、システム管理を生業とするのであれば、このくらいのスクリプトは書けた方が幸せになれるでしょう。「一回しか使わない」という状況が、その後何回も発生するだろうからです。
どんなマシンにも入っている訳ではないExcelはちょっと変なのかな?
それもありますね。客先の環境を管理する場合、いつもExcelが利用できるわけではありませんからね。そう言う意味では、Rubyも同じで、Rubyが利用できない環境も未だに結構ある。なので、Rubyしか使えない、と言うのでは困る場合がある。Bashでやる方法も知っておいた方がいい。
PowerShellに関して言えば、Windows Server 2008 R2以降で標準搭載なので、これを前提にしていてもいいかも知れない。けど、cmd.exeのバッチファイルもできた方がいいね。
むしろ、素人システム管理者であれば、その後同じような状況が発生した時点で、この作業は、スクリプトにすれば楽になると考えるんじゃないのかな。こういうことが素人から抜け出すきっかけだったりしたりしません?スクリプトにするという考えが出てくるぐらいの知識は必要ですけど。
「その後も何回」なら一回じゃないじゃん。
作業の集合{Pi}に対して、Pi=Pjとなるのは、i=jのときのみ。各作業Piは、どれとして同じ作業ではないので、各Piは一回しか行わない作業。つまり、
「一回しか使わない」という状況が、その後何回も発生する
ってこと。そんな経験あるでしょう?
私はawkとかperlも使いますが、Excelもよく使ってます。
shとかawkを使う欠点はデータフォーマットですね。元データが単純なテキストとは限らないんですよ。1カラム中に空白が入ったりする場合もあるのでshのforは無理。場合によっては改行を含むデータもあったりするし。
改行がないデータなら、CSVにして awk 'BEGIN{FS="\",\""}… とする手抜きも出来るけど、先頭と末尾の"は残るし、ダブルクオート有りと無しが混在するCSVには無力。それをマジメに処理しようとしたらもはやワンライナーは無理。
そういったデータの元はExcelだったりする場合が多いので、下手に「スクリプト系で処理しやすいデータ形式に変換する」よりは、Excel上で処理した方が早いし間違いが少ない。
でもまあ、UNIX系で処理しやすいデータの時にはawkとかperlとかを使います。さすがに最近はsedはあまり使わなくなったかな。
結局は適材適所ということだと思う。
> 僕は、できる限りマウス操作は避けるようにしてる。Excelの大半の操作はキーボードでも可能ですし、Excelでそういったデータ→コマンド列への変換を行うときは、マウス操作なんかしないですね。全部キー操作で処理してます。
まず。
僕は、できる限りマウス操作は避けるようにしてる。
Excelの大半の操作はキーボードでも可能ですし
まったくExcelを使わない、って言っているわけではないです。キーボードショートカットは、Excelに限らず、よく使ってますよ。TeraTermにコピペするときだって、キーボードショートカットですし。
1カラム中に空白が入ったりする場合もあるのでshのforは無理。
その程度なら、「無理」は言い過ぎだと思いますよ。デリミタが決まってるんだったら、なんとでもなりますから。awkの「-Fデリミタ文字 」オプションとかあるんだし。
場合によっては改行を含むデータもあったりするし。
そう言うのは確かに難しいですね。私もExcelを使うかもしれない。でも、そう言う場合だと、Excelでコマンド列を生成するのも結構大変だと思うな。
> デリミタが決まってるんだったら、なんとでもなりますから。awkの「-Fデリミタ文字 」オプションとかあるんだし。
そのあたりは元コメントでも書いてますが、デリミタに何を使うかが問題。定番のCSV(コンマ区切り)の場合、"a","b","c"のような、各カラムがダブルクオートされてる場合、FS='","'にしておけば、とりあえず分割できますが、最初が「"a」、最後が「c"」になってしまいます。さらに、ExcelなんかのCSV出力はクオートが必要なときだけクオートするので、a,"b,c",dみたいなデータになっちゃいますから、もはやawkでワンライナーなんて不可能です。
#ま、データをどうにでも選べるときは、CSVなんかではなく、TSV(タブ区切り)を使いますけど。こっちなら改行とかタブが入らない限りは簡単に処理できますし。でも、ExcelのTSV出力はそれはそれでトラブルが多いんだよなぁ。
で、私はどうしてもそんなデータを扱うときは、Perlで Text::CSVを使ったりしますが、はっきりいって、Excelで直接扱うより手間がかかります。定例処理として長期的な再利用がわかってる時ぐらいしか、そこまでやる気にはなれません。
> > 改行を含むデータもあったりするし。> そう言う場合だと、Excelでコマンド列を生成するのも結構大変
改行を含むカラムはコマンド列では使わない場合が多いですね。そういう場合に、「スクリプト処理用の、改行を削除したデータ」を生成するというワンクッションを入れるぐらいなら、Excelのままで処理、って感じで。
あと、元コメではコマンド列の生成だけでなくSQLの生成も例にあげてますけど、SQLの生成時には、改行を含むデータをそのまま出力させる必要がある場合も多いです。
みたいなデータになっちゃいますから、もはやawkでワンライナーなんて不可能です。
まあ、それは無理でしょうねえ。できる方法でやればいいじゃないですか。
しかし、私の経験から言うと、システム管理や構築の仕事では、そう言う難しいデータを元に作業することよりは、MS-Excelの入っていない環境で仕事することが多いです。
自分はpythonを使っていますが、CSV形式のファイルの扱いで困った事は無いですね。pythonのcsvモジュールは下記の特徴があり使いやすいです。・標準モジュールのため別途インストールする必要はない・SJIS、改行、"の有無など問題なく読み書きできる(excelとの相互運用が楽)・通常のファイルの読み書きと近しいコードで利用でき、難しくない
pythonはその特性上ワンライナーは苦手ですが、インタラクティブにコードが実行可能なので、ワンライナーのような試行錯誤や、そこそこの長さの手元のコードをサーバ上にスクリプトを置かず端末からのコピペで実行できたりします。
RHEL/CentOS系ならばyumでpythonが必要なため、perl/rubyがインストールされていない程の最小限な構成でも利用できます。また別の使い方としてはtelnetコマンドがインストールされていない状況で簡単にHTTPサーバやSMTPサーバとの疎通確認ができます。
$ python>>> import urllib>>> urllib.urlopen('http://www.example.com/')>>> import smtplib>>> smtplib.SMTP('mx.example.com')
# 最近はtelnetコマンドは標準でインストールされませんねぇ。
> echo '"a","b,c","d"'|awk -F \,\" '{print $1,$2,$3}'|tr -d \"> これはどう?
CSVには・全てのカラムがクオートされているとは限らない・ダブルクオート文字そのものは、ダブルクオート二つで表現されるといった変態さがありますので。
「a,"b,""c",d」という行を処理して、「a」「b,"c」「d」という3カラムの抽出が期待されます。awkのFS指定とtrで処理するのは無謀です。
awkとtrのパイプ実行に比べて可読性は低くなるけどsedでガッチリ書けということですね。 orz
シェルスクリプトレベルで、処理が難しいCSVがあるのは、よく解るんだけど、いずれにせよ、そう言う難しいデータをCSVで処理しようってのが間違ってる気もするね。XMLやYAML、JSONとか(S式とか(笑))、他に扱いやすいフォーマットもあるんだから、そっちの方向で考えた方がいいんじゃないかなあ。MS-Excelの入っていない環境も珍しくは無いことを考えると、実機で作業する前にどう段取りするかが重要になってくるから、他にもっと便利なツールがあるんじゃない?
エクセルはデータファイルを読んだ瞬間に入力データを黙って変換することがあったりするんだよなあ.他人ごとながら,「楽で確実」とお思いなのがちょいと心配.
# 郵便番号相当のデータが謎の年月日に変換されていたことがあって,あとで気づいて死ぬかと思った.
文字列に指定して読み込んでも、妙な変換をすることがありますよね>MS-Excel。
で、読み込ませたデータを参照しようと「=データのセル番地」と式を書くと、なぜかそのセル番地の書式を自分自身のセルににコピーするから、「文字列」指定を埋めていると式のセルにその書式指定が感染するんですよね。あの仕様困る。
30行程度なら書き並べたくなる気持ちも分からなくはないが、じっくりしっかりきれいに10行でまとめてくれないか
プログラマーとしてはプロとか勘弁して
100命令並べたのが1万個あったとして、それがいつも間違いなく動くことを保証してくれるならよいよ。
問題はその業務を何年か繰り返したときにミスが起こらないことであって単一の業務を確実にこなすことは必ずしも最重要課題にはならない。
ロケットの打ち上げのような一発芸なら君のスタイルも悪くない。
本気かどうかわかりにくいネタはやめれ
8ビットの頃と現在とを同一視するのはどうかと・・・
システム開発においてもっとも高価な資源がマンパワーであると言われるようになって、もう20年以上が経過しているはずです。小型コンピュータでは性能の向上が大型システムに比べて遅れたので、比較的最近でも、おっしゃるようなループを展開したコードも必要とされたケースがありました。恐らく、現在でも極限の性能を要求する局面では行われている事でしょう。ですが、それを全ての局面で金科玉条のごとく振り回すのは問題です。
あ、もちろん、1回限りの使い捨てコードなら話は別です。対象となるデータ量が100件程度で本当に1回限りの処理であるならば、ループが正しく動くか確認するより実証済みの1行コードを大量コピーして別途用意した可変部分をブロックペーストした方が効率的ですから。# まぁ、それも常に、ではありませんが。
結局のところ、現時点ではもっとも高価な資源であるマンパワーの節約こそが職業プログラミングに求められる事なのですから、その目的を達成するためにどちらがより適切か、というだけの話です。
細かいとこを拾うけど、
>別途用意した可変部分をブロックペースト『ブロックペースト』であることがとてもとても重要だと思う。ただの『ペースト』とは危険度がまったく違う。
Excelで書く、って話もあるけど、やっぱり、可変部分をカタマリのまま扱える、って部分が大きいんじゃないかな。
#自分だったら、perlで.shなり.batなりを出力しちゃう気がするけど。
オフトピだけど、ARMの使いこなしで、32bit命令でループがキャッシュはみだすくらいなら16bit命令でキャッシュに収まる方が速いとかいうノウハウを聴いた日にゃ、8bitマイコンのハンドアセンブルで機械語のバイト数をかぞえて相対ジャンプの計算してた時代がぐるっと一周して戻ってきたような気がしたよ。
> あ、もちろん、1回限りの使い捨てコードなら・・・効率的ですから。
自分で言っておいて、たった今ループを使って一発物のスクリプトを書いたところですよ。対象データ量はたったの10件。
業務の一環なのか、お勉強なのかわからないけど、そこで萎えちゃダメだと思うのだが。
その若いシステム管理者の勉強不足なのもあるけど、会社、部署、先輩等が持っているノウハウを伝えてなかったんでしょ。(まぁ、伝えていてもそうなんだったら、萎えるのはわかる。むしろ、イラっとくる)
コピペみたいなスクリプトを書くのにスクリプトを使おう。マジで何か効果があるコマンドを実行する代わりに、そのコマンドをテキストに吐き出すスクリプトを作る。そうすればミスに気が付きやすいし、デバッグも容易。単純なものならファイル名のリストを元に、正規表現を駆使して作るのもあり。
個人的には以下の記事に書いてある原則を守るようにしてるエレガントに作っても引継ぎに時間かかると困るのは自分だし
・パイプで処理する・関数を使わない・分岐は避ける・繰り返しは避ける・処理はその場所で完結させる・上から下へ読めるようにする・論理的な美しさよりも書き換えやすさを重視する・ほかのファイルはインクルードしない
http://www.atmarkit.co.jp/ait/articles/1208/17/news110.html [atmarkit.co.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
システム管理者プログラミング (スコア:1)
若いシステム管理者がサーバメンテナンスのスクリプトを書いていたので
肩越しに覗いてみましたよ。
テキストエディタ(Windowsの)の機能をフルに活用し、大量のコマンドを
コピペコピペ、置換置換…というように並べて作ってましたね。
萎えた。
そこは、あーしてこーして、awkをちょちょいと振りかければ10行で書けるだろ?
その方が作るのも早いし簡単。
せめてエディタはviでやったほうが、編集も早いよ。
マウスでドラッグして選択とかやってられんだろ。
というわけで、プログラムとまでは行かないにしろ、スクリプト言語くらいは
システム管理者は使えた方がいいと思う。
シェルスクリプトを書けるか書けないかで、仕事の効率は10倍くらい違うことも。
ていか、シェルスクリプトも書けないのにシステム管理者をさせてるのが悪い。
Windowsサーバの管理者も、Power Shellとか使えたほうがいいんじゃないかな。
Re:システム管理者プログラミング (スコア:2)
システム管理者ってわけじゃないけど、あるシステムのクラウドへの移行作業で、同僚が手作業に固執して困ったことが。
手作業でも可能な作業時間・費用をもらってたけど、スクリプトでやった方が短時間ですむだろうし、ミスも少ないだろうに。
自分の仕事を盗られる様で嫌だったのかなあ。
彼はプログラミングは得意じゃないみたいだし。
もっとも、最終的には私がスクリプトを組んで作業しましたけどね。
ところで、
Windowsサーバの管理者も、Power Shellとか使えたほうがいい
PowerShellな。「Power」と「Shell」の間は空白無し。
Re:システム管理者プログラミング (スコア:1)
手作業に固執する人って少なからずいますね。普段そのシステムを管理していて、イレギュラーな調査を頻繁に行っている人に多い印象です。手作業に固執されてしまう状況に遭った時にはその人に理由を訊くようにしていますが、こんな理由が出てきたのを覚えています。
・慣れないスクリプトによる自動化作業より慣れた手作業の方が信頼できる
何か想定外の事態があった時に違和感を感じやすいのは慣れた作業の方だとの話。
・手作業だと各作業を目検できるので想定外の事態を把握しやすい
これはスクリプトでやってもポイント決めて検証すれば同様かと思いました。
・「スクリプトを使用する」という要因によってトラブルが発生する可能性を増やしたくない
スクリプトの信頼性より人間の信頼性の方を高く評価している場合ですね。
# 私は自分が一番信頼できませんが。。
Re:システム管理者プログラミング (スコア:1)
システム管理者じゃないですが、多数(数百人)の人が入力した情報を集計するような作業をしたことがあります。
締め切り日に向かって順次入力されていく情報のアップデートを知りたかったこともあり、手作業はもとより頭になく、
スクリプトを使った作業を行いました。その基本路線は正しかったと思っています。
ただ、中には書き方に関する指示を無視したり(例えば名前とふりがなを逆に入力するとか)する人がいて、
そういうのはスクリプトに例外処理を作り込むことで対応しましたが、そのチェックの手間が膨大なものでした。
(1)正しく処理できているかどうかをチェック
(2)正しく処理できていない項目を見つけたときには、例外処理を追加
(3)例外処理が変な副作用を起こしていないかチェック
を繰り返し行いました。
世の中には、こちらには想像もつかないような、きわめていろんな変な入力の仕方をする人がいるものだと
思いました。
1回限りなら手作業の方が早かったかもしれません。でも何百件もあると、手作業だと、総数を数えるだけでも
数えるたびに異なる結果になったり。
Re:システム管理者プログラミング (スコア:1)
今時の若造はawkなんて知ってるはずありませんよ
勧めるならRubyぐらいにしとかないと年寄り扱いされます
#ターミナルやキーボードの仕様の相違をアプリケーション側で吸収しなければならなかった時代じゃないんだからviはもう卒業してくれ
Re:システム管理者プログラミング (スコア:3, すばらしい洞察)
個人的にはRubyを勧めたい気持ちはよく解るんだけど、そうできない事情もあるんだよ。
と言うのは、UNIX系で、Rubyがインストールされていない環境があるから。そう言う環境でも、awkが入っていないことはまず無い。
インストールされてなきゃ、入れればいいじゃないか、ってのも甘い。ポリシ・規約でインストールできない場合があるから。
自宅サーバじゃなくて、仕事だからね。
Re:システム管理者プログラミング (スコア:2)
Re:システム管理者プログラミング (スコア:1)
起動コマンド名を変えて提供されている場合が多いでしょうから、その場合はお目こぼししてもいいと思う。← Cygwin 標準のviコマンドとか
// ksh由来の 'set -o vi' と正反対の設定については宗教戦争モノなのかなあ?
Re: (スコア:0)
Perlにawkスクリプトを流せばいい
# だめだ、つまらん
Re:システム管理者プログラミング (スコア:1)
viかどうかはともかく、マウスはだめでしょう。キーボードからマウスに手を持って行く、その移動距離が無駄。
「ターミナルやキーボードの仕様の相違をアプリケーション側で吸収しなければならなかった時代」よりも
ずっと現代は進んでいるはずなのに、マウスなんていう、キーボードから離れたところに置かないといけない
デバイスがいまだにのさばっています。
マウスだけでほとんど用件が済んでしまうような、ウェブ閲覧だけのエンドユーザーならともかく、
システム管理者がそれじゃあ話になりません。
トラックポイントやタッチパッド(親指で操作)なら、まだいいけど。
Re: (スコア:0)
まあ、さすがにawkはないわな・・・。
viの悪口は許さないけど。
Re:システム管理者プログラミング (スコア:1)
これがね、なかなか、awkが必要な時があるんですよ。
RubyどころかPerlも入ってない。
ネットにはつながってない(外部と隔離されている)ので
インストールもできない。
けれど、複雑な文字列操作をやるスクリプトを書かなきゃいけない。
そんなときにawkが役に立ちます。
UNIX系のシステムなら、OSに標準装備のスクリプトを動かすために
awkは必ず入っているので、そんな時でも大丈夫なんです。
Rubyがーとかいってるシステム管理者は、たくさんありふれている
ありきたりなLinuxサーバとか管理しているだけの人じゃないかな。
そんな恵まれている楽なサーバだけじゃないんだよね、世の中。
Re: (スコア:0)
>#ターミナルやキーボードの仕様の相違をアプリケーション側で
>吸収しなければならなかった時代じゃないんだからviはもう卒業してくれ
これ、中より下くらいのシステム管理者が勘違いしやすいところだけど、
viは低機能で基本的なエディタで、大抵のUNIX系環境に標準で入ってるから
使えって言われていると思っている?
確かにそういう面もあるけれど、それだけじゃない。
viのコマンドを駆使すると、すごく効率よくスクリプトやテキスト編集が
できるんだよ。
そこらのテキストエディタと比べても、かなり高機能多機能な
Re: (スコア:0)
素人は君だよ (スコア:0)
プログラミングに肝心なのは、格好良く書くことではない。
解りやすく、確実に動作することである。
その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が
優れたプログラミンなのである。
まあ、私は昔8ビットのアセンブラーでグラフィックの描画を作っていたけど
100命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
Re:素人は君だよ (スコア:2)
システム管理者のプログラミング云々にアセンブラを出してくるのは変だし、アンロールした方が解りにくいよね:b
Re:素人は君だよ (スコア:1)
プログラマーとしてはプロでも、システム管理者としてはド素人とお見受けする。
>プログラミングに肝心なのは、格好良く書くことではない。
>解りやすく、確実に動作することである。
格好良く書けと主張した覚えはないけど?
でも、ソースコードを格好よく書くというのは、解りやすく確実に動作するにはとても重要で肝心なところ(二重に強調させてもらうが)。
ちゃんと動いているように見えるからと言って、ぐちゃぐちゃなソースコードは、ちゃんと動くかすらわからない。
となると、それを知らないあなたはプログラマーとしても素人なのかもしれないな。
>その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が
>優れたプログラミンなのである。
例えばだ、5000ユーザの設定をまとめて変更する必要があったとしよう。
1人のユーザの設定変更のコマンドを何行か書き、それを4999回コピーし、ユーザ固有の部分を目視しながらマウス操作でコピーして編集していく。
単純だけど、これは質の悪いプログラムだ。
ちゃんと動くとは思えない。
5000人分のコマンドを手作業でなおしていくと、絶対にミスをする。
これはとても優れているとは言えない。
時間もかなり大きくなる。
それよりも、じっくりしっかりきれいに10行で書いたスクリプトを書き、それを使ったほうが圧倒的に速いし確実だし優れている。
大昔のシステム開発では何行のコードがいくらという価値を持ったのかもしれないが、システム管理者が書くスクリプト、プログラムは自分たちで使うもの。
自分たちが楽をし、ミスをしないために作るもの。
行数が多ければ優れているというわけではない。
楽にならなければ意味がない。
百歩譲って、コマンドを書き並べられたスクリプトが優れているとするなら、そのコマンドを書き並べるスクリプトを書くというのがシステム管理者の正しい姿なんだよね。
コマンドをひたすら書き並べるだけなら、スクリプトにせずにそのまま実行するでしょう?
>まあ、私は昔8ビットのアセンブラーでグラフィックの描画を作っていたけど
>100命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
そうですね、システム管理者のプログラムとしてはド素人の考えですね、それは。
Re: (スコア:0)
同意。
ただし、大昔のシステム開発なら、いかにコンパクトに書くかがむしろ重要だった。贅沢な環境じゃなかったんだよ。
だいたいコーディングシートに手書きしているのに同じ事を何度も書いてたまるかっての。
そこだけは認識しといてもらいたいね。
Re: (スコア:0)
> 1人のユーザの設定変更のコマンドを何行か書き、それを4999回コピーし、ユーザ固有の部分を目視しながらマウス操作でコピーして編集していく。
>
> 単純だけど、これは質の悪いプログラムだ。
> ちゃんと動くとは思えない。
> 5000人分のコマンドを手作業でなおしていくと、絶対にミスをする。
> これはとても優れているとは言えない。
> 時間もかなり大きくなる。
>
> それよりも、じっくりしっかりきれいに10行で書いたスクリプトを書き、それを使ったほうが圧倒的に速いし確実だし優れている。
1回しか実行しないプログラムやクエリであれば、Excelで作ってしまうのが楽で確実です。
例えばユーザIDをA列に格納し、A列を参照するコマンド(クエリ)をB列に書いてオートフィル。
あとはB列をコピペすれば完成。
Re:素人は君だよ (スコア:2)
1回しか実行しないプログラムやクエリであれば、Excelで作ってしまうのが楽で確実です。
その手のものなら、UNIXではbashなどのシェル、WindowsならPowerShellを使う方が楽。コピペすら必要ない。例えば、bashなら
とか。伝統的には、awkを使って、
とか。結果を一旦バッチファイルに保存して実行しても良いし、パイプで/bin/shに食わせてもいいね。もちろん、もっと現代的な言語で書いてもいい。
PowerShellなら、
とかな。既定のエイリアスを使って、
と書くと、ストローク数が減るし、UNIX風に見える(笑)。
ストローク数云々は冗談だけど、手数を減らすのはミスを防ぐのに効果的。僕は、できる限りマウス操作は避けるようにしてる。
Re:素人は君だよ (スコア:2)
私は全くの他業種だけれども、一回しか使わないのなら知っている方法だけでやるのが早いし楽だと思う。
そういう意味で色々手段はあるけれど最初に思いついたのがExcelなら、それでやってしまう方が実際には手数も多いし面倒だとしても結果早いのではないでしょうか。
(システム管理者ならCUIに抵抗が無いだろうし、どんなマシンにも入っている訳ではないExcelはちょっと変なのかな?)
今回のネタ的にはある程度広く浅くプログラミングが出来た方がもっとスマートな手段を使えるようになるって事だろうけれど。
あと、どんな仕事でも多少知っている人の方が無茶振りしなさそうでいいなぁ。
Re:素人は君だよ (スコア:1)
私は全くの他業種だけれども、一回しか使わないのなら知っている方法だけでやるのが早いし楽だと思う。
素人システム管理者であれば、それでいいと思います。
でも、システム管理を生業とするのであれば、このくらいのスクリプトは書けた方が幸せになれるでしょう。
「一回しか使わない」という状況が、その後何回も発生するだろうからです。
どんなマシンにも入っている訳ではないExcelはちょっと変なのかな?
それもありますね。
客先の環境を管理する場合、いつもExcelが利用できるわけではありませんからね。
そう言う意味では、Rubyも同じで、Rubyが利用できない環境も未だに結構ある。なので、Rubyしか使えない、と言うのでは困る場合がある。Bashでやる方法も知っておいた方がいい。
PowerShellに関して言えば、Windows Server 2008 R2以降で標準搭載なので、これを前提にしていてもいいかも知れない。
けど、cmd.exeのバッチファイルもできた方がいいね。
Re: (スコア:0)
素人システム管理者であれば、それでいいと思います。
でも、システム管理を生業とするのであれば、このくらいのスクリプトは書けた方が幸せになれるでしょう。
「一回しか使わない」という状況が、その後何回も発生するだろうからです。
むしろ、素人システム管理者であれば、その後同じような状況が発生した時点で、
この作業は、スクリプトにすれば楽になると考えるんじゃないのかな。
こういうことが素人から抜け出すきっかけだったりしたりしません?
スクリプトにするという考えが出てくるぐらいの知識は必要ですけど。
Re:素人は君だよ (スコア:1)
「その後も何回」なら一回じゃないじゃん。
作業の集合{Pi}に対して、Pi=Pjとなるのは、i=jのときのみ。各作業Piは、どれとして同じ作業ではないので、各Piは一回しか行わない作業。つまり、
「一回しか使わない」という状況が、その後何回も発生する
ってこと。
そんな経験あるでしょう?
Re:素人は君だよ (スコア:1)
私はawkとかperlも使いますが、Excelもよく使ってます。
shとかawkを使う欠点はデータフォーマットですね。
元データが単純なテキストとは限らないんですよ。
1カラム中に空白が入ったりする場合もあるのでshのforは無理。
場合によっては改行を含むデータもあったりするし。
改行がないデータなら、CSVにして awk 'BEGIN{FS="\",\""}… とする手抜きも出来るけど、先頭と末尾の"は残るし、ダブルクオート有りと無しが混在するCSVには無力。それをマジメに処理しようとしたらもはやワンライナーは無理。
そういったデータの元はExcelだったりする場合が多いので、下手に「スクリプト系で処理しやすいデータ形式に変換する」よりは、Excel上で処理した方が早いし間違いが少ない。
でもまあ、UNIX系で処理しやすいデータの時にはawkとかperlとかを使います。
さすがに最近はsedはあまり使わなくなったかな。
結局は適材適所ということだと思う。
> 僕は、できる限りマウス操作は避けるようにしてる。
Excelの大半の操作はキーボードでも可能ですし、Excelでそういったデータ→コマンド列への変換を行うときは、マウス操作なんかしないですね。全部キー操作で処理してます。
Re:素人は君だよ (スコア:1)
まず。
僕は、できる限りマウス操作は避けるようにしてる。
Excelの大半の操作はキーボードでも可能ですし
まったくExcelを使わない、って言っているわけではないです。キーボードショートカットは、Excelに限らず、よく使ってますよ。TeraTermにコピペするときだって、キーボードショートカットですし。
1カラム中に空白が入ったりする場合もあるのでshのforは無理。
その程度なら、「無理」は言い過ぎだと思いますよ。デリミタが決まってるんだったら、なんとでもなりますから。awkの「-Fデリミタ文字 」オプションとかあるんだし。
場合によっては改行を含むデータもあったりするし。
そう言うのは確かに難しいですね。私もExcelを使うかもしれない。
でも、そう言う場合だと、Excelでコマンド列を生成するのも結構大変だと思うな。
Re:素人は君だよ (スコア:1)
> デリミタが決まってるんだったら、なんとでもなりますから。awkの「-Fデリミタ文字 」オプションとかあるんだし。
そのあたりは元コメントでも書いてますが、デリミタに何を使うかが問題。定番のCSV(コンマ区切り)の場合、
"a","b","c"
のような、各カラムがダブルクオートされてる場合、
FS='","'にしておけば、とりあえず分割できますが、最初が「"a」、最後が「c"」になってしまいます。
さらに、ExcelなんかのCSV出力はクオートが必要なときだけクオートするので、
a,"b,c",d
みたいなデータになっちゃいますから、もはやawkでワンライナーなんて不可能です。
#ま、データをどうにでも選べるときは、CSVなんかではなく、TSV(タブ区切り)を使いますけど。こっちなら改行とかタブが入らない限りは簡単に処理できますし。でも、ExcelのTSV出力はそれはそれでトラブルが多いんだよなぁ。
で、私はどうしてもそんなデータを扱うときは、Perlで Text::CSVを使ったりしますが、はっきりいって、Excelで直接扱うより手間がかかります。定例処理として長期的な再利用がわかってる時ぐらいしか、そこまでやる気にはなれません。
> > 改行を含むデータもあったりするし。
> そう言う場合だと、Excelでコマンド列を生成するのも結構大変
改行を含むカラムはコマンド列では使わない場合が多いですね。
そういう場合に、「スクリプト処理用の、改行を削除したデータ」を生成するというワンクッションを入れるぐらいなら、Excelのままで処理、って感じで。
あと、元コメではコマンド列の生成だけでなくSQLの生成も例にあげてますけど、SQLの生成時には、改行を含むデータをそのまま出力させる必要がある場合も多いです。
Re:素人は君だよ (スコア:1)
みたいなデータになっちゃいますから、もはやawkでワンライナーなんて不可能です。
まあ、それは無理でしょうねえ。できる方法でやればいいじゃないですか。
しかし、私の経験から言うと、システム管理や構築の仕事では、そう言う難しいデータを元に作業することよりは、MS-Excelの入っていない環境で仕事することが多いです。
Re:素人は君だよ (スコア:2)
自分はpythonを使っていますが、CSV形式のファイルの扱いで困った事は無いですね。
pythonのcsvモジュールは下記の特徴があり使いやすいです。
・標準モジュールのため別途インストールする必要はない
・SJIS、改行、"の有無など問題なく読み書きできる(excelとの相互運用が楽)
・通常のファイルの読み書きと近しいコードで利用でき、難しくない
pythonはその特性上ワンライナーは苦手ですが、インタラクティブにコードが実行可能なので、ワンライナーのような試行錯誤や、そこそこの長さの手元のコードをサーバ上にスクリプトを置かず端末からのコピペで実行できたりします。
RHEL/CentOS系ならばyumでpythonが必要なため、perl/rubyがインストールされていない程の最小限な構成でも利用できます。また別の使い方としてはtelnetコマンドがインストールされていない状況で簡単にHTTPサーバやSMTPサーバとの疎通確認ができます。
$ python
>>> import urllib
>>> urllib.urlopen('http://www.example.com/')
>>> import smtplib
>>> smtplib.SMTP('mx.example.com')
# 最近はtelnetコマンドは標準でインストールされませんねぇ。
Re:"a","b","c" (スコア:1)
> echo '"a","b,c","d"'|awk -F \,\" '{print $1,$2,$3}'|tr -d \"
> これはどう?
CSVには
・全てのカラムがクオートされているとは限らない
・ダブルクオート文字そのものは、ダブルクオート二つで表現される
といった変態さがありますので。
「a,"b,""c",d」という行を処理して、「a」「b,"c」「d」という3カラムの抽出が期待されます。
awkのFS指定とtrで処理するのは無謀です。
Re:"a","b","c" (スコア:1)
awkとtrのパイプ実行に比べて可読性は低くなるけどsedでガッチリ書けということですね。 orz
Re:"a","b","c" (スコア:1)
シェルスクリプトレベルで、処理が難しいCSVがあるのは、よく解るんだけど、いずれにせよ、そう言う難しいデータをCSVで処理しようってのが間違ってる気もするね。XMLやYAML、JSONとか(S式とか(笑))、他に扱いやすいフォーマットもあるんだから、そっちの方向で考えた方がいいんじゃないかなあ。
MS-Excelの入っていない環境も珍しくは無いことを考えると、実機で作業する前にどう段取りするかが重要になってくるから、他にもっと便利なツールがあるんじゃない?
Re:素人は君だよ (スコア:1)
シェルの機能でループさせるときも、ほんとに大丈夫か見るべく、一旦、echoを入れて実行されるコマンドをずらっと表示させて確認とかするし。
エクセルは危険 (スコア:1)
エクセルはデータファイルを読んだ瞬間に入力データを黙って変換することがあったりするんだよなあ.
他人ごとながら,「楽で確実」とお思いなのがちょいと心配.
# 郵便番号相当のデータが謎の年月日に変換されていたことがあって,あとで気づいて死ぬかと思った.
Re: (スコア:0)
Excelだと、プログラミングに詳しくない人に検証資料として出しても受け入れられやすいという利点はありますね。
Re:エクセルは危険 (スコア:1)
文字列に指定して読み込んでも、妙な変換をすることがありますよね>MS-Excel。
Re:エクセルは危険 (スコア:1)
で、読み込ませたデータを参照しようと
「=データのセル番地」
と式を書くと、なぜかそのセル番地の書式を自分自身のセルににコピーするから、
「文字列」指定を埋めていると式のセルにその書式指定が感染するんですよね。あの仕様困る。
Re: (スコア:0)
30行程度なら書き並べたくなる気持ちも分からなくはないが、
じっくりしっかりきれいに10行でまとめてくれないか
Re: (スコア:0)
プログラマーとしてはプロとか勘弁して
Re: (スコア:0)
100命令並べたのが1万個あったとして、それがいつも間違いなく動くことを保証してくれるならよいよ。
問題はその業務を何年か繰り返したときにミスが起こらないことであって
単一の業務を確実にこなすことは必ずしも最重要課題にはならない。
ロケットの打ち上げのような一発芸なら君のスタイルも悪くない。
Re: (スコア:0)
本気かどうかわかりにくいネタはやめれ
Re: (スコア:0)
8ビットの頃と現在とを同一視するのはどうかと・・・
システム開発においてもっとも高価な資源がマンパワーであると言われるようになって、もう20年以上が経過しているはずです。
小型コンピュータでは性能の向上が大型システムに比べて遅れたので、比較的最近でも、おっしゃるようなループを展開したコードも必要とされたケースがありました。
恐らく、現在でも極限の性能を要求する局面では行われている事でしょう。
ですが、それを全ての局面で金科玉条のごとく振り回すのは問題です。
あ、もちろん、1回限りの使い捨てコードなら話は別です。
対象となるデータ量が100件程度で本当に1回限りの処理であるならば、ループが正しく動くか確認するより実証済みの1行コードを大量コピーして別途用意した可変部分をブロックペーストした方が効率的ですから。
# まぁ、それも常に、ではありませんが。
結局のところ、現時点ではもっとも高価な資源であるマンパワーの節約こそが職業プログラミングに求められる事なのですから、その目的を達成するためにどちらがより適切か、というだけの話です。
Re:素人は君だよ (スコア:1)
細かいとこを拾うけど、
>別途用意した可変部分をブロックペースト
『ブロックペースト』であることがとてもとても重要だと思う。
ただの『ペースト』とは危険度がまったく違う。
Excelで書く、って話もあるけど、やっぱり、
可変部分をカタマリのまま扱える、って部分が大きいんじゃないかな。
#自分だったら、perlで.shなり.batなりを出力しちゃう気がするけど。
Re: (スコア:0)
Re:素人は君だよ (スコア:1)
オフトピだけど、
ARMの使いこなしで、32bit命令でループがキャッシュはみだすくらいなら16bit命令でキャッシュに収まる方が速いとかいうノウハウを聴いた日にゃ、8bitマイコンのハンドアセンブルで機械語のバイト数をかぞえて相対ジャンプの計算してた時代がぐるっと一周して戻ってきたような気がしたよ。
Re: (スコア:0)
> あ、もちろん、1回限りの使い捨てコードなら・・・効率的ですから。
自分で言っておいて、たった今ループを使って一発物のスクリプトを書いたところですよ。
対象データ量はたったの10件。
Re: (スコア:0)
業務の一環なのか、お勉強なのかわからないけど、
そこで萎えちゃダメだと思うのだが。
その若いシステム管理者の勉強不足なのもあるけど、会社、部署、先輩等が持っているノウハウを
伝えてなかったんでしょ。
(まぁ、伝えていてもそうなんだったら、萎えるのはわかる。むしろ、イラっとくる)
間を取って (スコア:0)
コピペみたいなスクリプトを書くのにスクリプトを使おう。マジで
何か効果があるコマンドを実行する代わりに、
そのコマンドをテキストに吐き出すスクリプトを作る。
そうすればミスに気が付きやすいし、デバッグも容易。
単純なものならファイル名のリストを元に、正規表現を駆使して作るのもあり。
Re: (スコア:0)
個人的には以下の記事に書いてある原則を守るようにしてる
エレガントに作っても引継ぎに時間かかると困るのは自分だし
・パイプで処理する
・関数を使わない
・分岐は避ける
・繰り返しは避ける
・処理はその場所で完結させる
・上から下へ読めるようにする
・論理的な美しさよりも書き換えやすさを重視する
・ほかのファイルはインクルードしない
http://www.atmarkit.co.jp/ait/articles/1208/17/news110.html [atmarkit.co.jp]
Re: (スコア:0)
個人的には以下の記事に書いてある原則を守るようにしてる
エレガントに作っても引継ぎに時間かかると困るのは自分だし
・パイプで処理する
・関数を使わない
・分岐は避ける
・繰り返しは避ける
・処理はその場所で完結させる
・上から下へ読めるようにする
・論理的な美しさよりも書き換えやすさを重視する
・ほかのファイルはインクルードしない
http://www.atmarkit.co.jp/ait/articles/1208/17/news110.html [atmarkit.co.jp]