システム管理者がプログラミングについて知っておくべき理由 104
ストーリー by hylom
プログラミングできない管理者なんて都市伝説だと思ってました 部門より
プログラミングできない管理者なんて都市伝説だと思ってました 部門より
eggy 曰く、
米InfoWorldにて、Why admins shoukd know how to codeなる記事が掲載されている。記事では「プログラマになる必要はないが、コードを書くことができればより難しい問題をより高速に解決できる」とし、システム管理者に対しプログラミングのスキルを持つことの重要性を示している（本家/.、InfoWorld記事）。
システム管理者は開発者ではないため、一日中コードを書いているというわけではないが、何か問題が起きた時に解決するためのツールを開発する必要が出てくる。そのため、使用されているプラットフォームをサポートするスクリプト言語にある程度精通している必要があるとのこと。また理想としては、複数の言語に精通していることが望ましいとしている。
スクリプト…… (スコア:5, おもしろおかしい)
スクリプトなんて書けて当たり前。
本当に必要なのは作ったスクリプトを正しく管理する能力だと改めて思い知らされたばかりのはずでありますが……
Re:スクリプト…… (スコア:2)
「管理しなきゃならんので予算（と人手）ください！」
「今ウマく動いてるのに何で金が要るんだよ」
損害を出さないための予算というのは、実際に損害が出るまでつかんのです。
で、損害が出たら現場担当者の責任。
Re:スクリプト…… (スコア:2, すばらしい洞察)
予算を申請していたという事実があれば、
予算を下ろさなかった人間が責任を被るのです。
Re:スクリプト…… (スコア:2)
Sukoya-5「前の担当者は予算が無いと働けない反逆者でしたが、幸福な担当者である私はきっと上手くやるでしょう」
Re:スクリプト…… (スコア:1)
後がないじゃないですか！
プログラムの書けないシス管 (スコア:2)
Re:プログラムの書けないシス管 (スコア:1)
システム管理者とオペレータをごっちゃにしている印象が.
# システム管理者の重要業務の一つがマニュアル書きであったりする
危険 (スコア:2)
ファーストサーバー：担当者のマニュアル無視を容認、独自プログラムで更新 削除コマンド消し忘れ [itmedia.co.jp]
＞報告書によると、同社のシステムメンテナンスは通常、社内マニュアルに沿って行われるが、不具合を起こした担当者だけは約10年前からマニュアルを無視し、自ら作成した更新プログラムを利用するなど独自方式でメンテナンスを行ない、上長もそれを容認していたという。
>何か問題が起きた時に解決するためのツールを開発する必要
地雷原というか、ソフトウェアの機能安全規格（ISO 26262、IEC 61508、IEC 62304など）からは
真っ向から反目する流れですね。
Re:危険 (スコア:1)
最低限のプログラム能力もなければ、独自プログラムを書くことも出来ないから、
安全だというものでも無いでしょう。
プログラム能力の有無に関わらず、担当者や管理者は大抵、失敗や大失敗の経験がある。
それでも惨事を広げないために、色々対策がなされていて、また失敗を繰り返さない
ためにマニュアルやルールが作られている。
件の事件は、マニュアル無視、上司の容認、システム設計不備、組織の下から上まで
内在していた問題が連鎖して大惨事になったのです。
担当者レベルのプログラミング能力の有無に話を持って行くと、問題の本質を見失うと
思われます。
Re:危険 (スコア:1)
ソフトウェアの安全規格というのは、プログラミング能力というより、
バグを作りこまないためのプロセス管理規格のように感じます。
タレコミ文からプロセスを無視するような独自方法を
編み出せという意図が感じられたのでそのように書きました。
天才的な能力に裏打ちされたのは、うまく行っている間は良いのですが、
問題が起きたときに、重大な結果を招きやすいように感じています。
バグの無いソフトウェアを天才が作り上げる時代は終わり、
凡人がプロセス管理された状態で、一定以上のバグを作りこまないように
進めるというのが、現在の主流に思います。
Re:危険 (スコア:1)
元記事の筆者も、IT忍者という言葉を使っているように、
非正規軍的な活動が念頭にあるのでしょうね。
こういう気分のまま、機能安全規格を必要とするような
ソフトウェアを開発するのは、危険だと思います。
しかし管理される対象も、安定運用が絶対のシステムから、
日々改造されることが競争力の源泉になっているシステムとか、
壊れても被害を許容できる代わりに費用も掛けたくないという
システムもある訳です。
またシステムの安全を確保するために、人的なコストを掛け
るか、ハードにコストを掛けるかというバランスもあります。
この程度の危険思想あるいは退嬰的思想の管理者がいても
システムに依っては良いと思われます。
（私も、元記事の筆者も恐らくは、その程度のシステムの方が
まだまだ大多数だと想像しています）
＞真っ向から反目する流れですね。
そもそも存在する奔放な流れを制する為の規格ですからね。
放置すればすぐ染み込んで来る危険な流れをいかに断つか
ということも「規格」の値打ちかと考えられます。
システム管理者プログラミング (スコア: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:システム管理者プログラミング (スコア:1)
viかどうかはともかく、マウスはだめでしょう。キーボードからマウスに手を持って行く、その移動距離が無駄。
「ターミナルやキーボードの仕様の相違をアプリケーション側で吸収しなければならなかった時代」よりも
ずっと現代は進んでいるはずなのに、マウスなんていう、キーボードから離れたところに置かないといけない
デバイスがいまだにのさばっています。
マウスだけでほとんど用件が済んでしまうような、ウェブ閲覧だけのエンドユーザーならともかく、
システム管理者がそれじゃあ話になりません。
トラックポイントやタッチパッド（親指で操作）なら、まだいいけど。
Re:システム管理者プログラミング (スコア:1)
これがね、なかなか、awkが必要な時があるんですよ。
RubyどころかPerlも入ってない。
ネットにはつながってない（外部と隔離されている）ので
インストールもできない。
けれど、複雑な文字列操作をやるスクリプトを書かなきゃいけない。
そんなときにawkが役に立ちます。
UNIX系のシステムなら、OSに標準装備のスクリプトを動かすために
awkは必ず入っているので、そんな時でも大丈夫なんです。
Rubyがーとかいってるシステム管理者は、たくさんありふれている
ありきたりなLinuxサーバとか管理しているだけの人じゃないかな。
そんな恵まれている楽なサーバだけじゃないんだよね、世の中。
素人は君だよ (スコア:0)
プログラミングに肝心なのは、格好良く書くことではない。
解りやすく、確実に動作することである。
その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が
優れたプログラミンなのである。
まあ、私は昔８ビットのアセンブラーでグラフィックの描画を作っていたけど
１００命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
Re:素人は君だよ (スコア:2)
システム管理者のプログラミング云々にアセンブラを出してくるのは変だし、アンロールした方が解りにくいよね:b
Re:素人は君だよ (スコア:1)
プログラマーとしてはプロでも、システム管理者としてはド素人とお見受けする。
>プログラミングに肝心なのは、格好良く書くことではない。
>解りやすく、確実に動作することである。
格好良く書けと主張した覚えはないけど？
でも、ソースコードを格好よく書くというのは、解りやすく確実に動作するにはとても重要で肝心なところ（二重に強調させてもらうが）。
ちゃんと動いているように見えるからと言って、ぐちゃぐちゃなソースコードは、ちゃんと動くかすらわからない。
となると、それを知らないあなたはプログラマーとしても素人なのかもしれないな。
>その意味からすれば、可能ならば書き並べてループや複雑な手続きを使わない方が
>優れたプログラミンなのである。
例えばだ、5000ユーザの設定をまとめて変更する必要があったとしよう。
1人のユーザの設定変更のコマンドを何行か書き、それを4999回コピーし、ユーザ固有の部分を目視しながらマウス操作でコピーして編集していく。
単純だけど、これは質の悪いプログラムだ。
ちゃんと動くとは思えない。
5000人分のコマンドを手作業でなおしていくと、絶対にミスをする。
これはとても優れているとは言えない。
時間もかなり大きくなる。
それよりも、じっくりしっかりきれいに10行で書いたスクリプトを書き、それを使ったほうが圧倒的に速いし確実だし優れている。
大昔のシステム開発では何行のコードがいくらという価値を持ったのかもしれないが、システム管理者が書くスクリプト、プログラムは自分たちで使うもの。
自分たちが楽をし、ミスをしないために作るもの。
行数が多ければ優れているというわけではない。
楽にならなければ意味がない。
百歩譲って、コマンドを書き並べられたスクリプトが優れているとするなら、そのコマンドを書き並べるスクリプトを書くというのがシステム管理者の正しい姿なんだよね。
コマンドをひたすら書き並べるだけなら、スクリプトにせずにそのまま実行するでしょう？
>まあ、私は昔８ビットのアセンブラーでグラフィックの描画を作っていたけど
>１００命令程度ならループのオーバーヘッドを避けるため書き並べていたのでそう思うのかもしれないが。
そうですね、システム管理者のプログラムとしてはド素人の考えですね、それは。
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:素人は君だよ (スコア: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:エクセルは危険 (スコア:1)
文字列に指定して読み込んでも、妙な変換をすることがありますよね＞MS-Excel。
Re:エクセルは危険 (スコア:1)
で、読み込ませたデータを参照しようと
「=データのセル番地」
と式を書くと、なぜかそのセル番地の書式を自分自身のセルににコピーするから、
「文字列」指定を埋めていると式のセルにその書式指定が感染するんですよね。あの仕様困る。
Re: (スコア:0)
100命令並べたのが1万個あったとして、それがいつも間違いなく動くことを保証してくれるならよいよ。
問題はその業務を何年か繰り返したときにミスが起こらないことであって
単一の業務を確実にこなすことは必ずしも最重要課題にはならない。
ロケットの打ち上げのような一発芸なら君のスタイルも悪くない。
Re:素人は君だよ (スコア:1)
細かいとこを拾うけど、
＞別途用意した可変部分をブロックペースト
『ブロックペースト』であることがとてもとても重要だと思う。
ただの『ペースト』とは危険度がまったく違う。
Excelで書く、って話もあるけど、やっぱり、
可変部分をカタマリのまま扱える、って部分が大きいんじゃないかな。
＃自分だったら、perlで.shなり.batなりを出力しちゃう気がするけど。
Re:素人は君だよ (スコア:1)
オフトピだけど、
ARMの使いこなしで、32bit命令でループがキャッシュはみだすくらいなら16bit命令でキャッシュに収まる方が速いとかいうノウハウを聴いた日にゃ、8bitマイコンのハンドアセンブルで機械語のバイト数をかぞえて相対ジャンプの計算してた時代がぐるっと一周して戻ってきたような気がしたよ。
そりゃそうだ (スコア:0)
「そりゃそうだ」としか言いようがない意見だけど、贅沢を言えばきりが無いよね。
それだけの能力を求めるなら、それなりの待遇を与えよ、ってことでもあるね。
ところで、WindowsだとPowerShellが必須 [blogspot.jp]になりつつあるね。
そもそもシステム管理者とは何か？ (スコア:0)
大規模システムだと、運用管理ソフトウェアで監視するユーザーは、異常発生時にマニュアルに剃って操作をするため、システム管理者権限が必要になるし、マニュアル外の複雑な対処はシステムエンジニアの仕事だと思う。後者の実行部隊は…下忍レベル…はスクリプトのスキルが必要だろう。でも、対外部署の調整をするシステムエンジニアの上忍レベルの人間には不要かもしれない。
一方で、中小規模だと複数の仕事を兼任することになる。つまり、広義にシステム管理者と言っても色んな仕事や役割がある。まずは、システム管理者の役割と仕事などの細分化が必要なのかもしれない。
プログラムの典型的な構造 (スコア:0)
Cみたいなのからシェルスクリプトなんかまで、どれも共通の構造のようなものがあるから、それは理解しておく必要があると思うな。
制御構造だったり、変数とか、色々。
あとは、他のコメントにもあるけど、テキストの編集くらいは。
Re:cobol (スコア:2)
それは書けるうちだと思いますが。
＃それなりに実態を知っているので、それだけできれば御の字だと思う...
--- de FTNS.
Re:トラブルシューティングするのに困らないかな (スコア:1)
確かに似ている (スコア:1)
所詮は中間管理職。
常に前面に立たせられながら、予算や人選など実はあまり権限がない。
Re:かつての若造 (スコア:2)
Ciscoの製品を使う人だと思っていた。