アカウント名:
パスワード:
だが、あえてバッチ処理した方が望ましい場合もあるわけで。たとえばネットを利用した振り込みとか、不正アクセスに勘付くためにあえてリアルタイム処理できなくしてる銀行もある。
古い技術は全否定するわけではなくて、要件に応じて使い分けることが必要。「新技術の方が優れている」は年中革新しないと気が済まない病に陥ったエンジニアの誤解。
syori.bat とかなら明らかに時代遅れな感じはする。せめてPowerShellかWSLを使えと?
そのバッチではない。
多分ここに書いた人達はメインフレームのバッチ処理がなんなのかすら知らない
batはともかく、そういうダサいファイル名なら現在進行形で再生産されてるからなー。こんなんとか。https://www.city.kita.tokyo.jp/wakuchin.html [tokyo.jp]
ダサいとは思いませんし英語にしたところで問題が解決するとは思えません。分かりやすいことがまず大事なのでは?
わざわざ和英辞書を引くぐらいならローマ字で書けとお師匠に教わった
>わざわざ和英辞書を引くぐらいならローマ字で書けとお師匠に教わった
今どき一々和英辞書引っ張り出すのはかなりのお歳でしょうか。
辞書を引くhttps://www.weblio.jp/content/%E8%BE%9E%E6%9B%B8%E3%82%92%E5%BC%95%E3%81%8F [weblio.jp]分からない言葉を辞書で調べる。
「辞書を引く」が辞書を引っ張り出すことだと思う前に辞書くらい引けば?
辞書を引く以前に、普通に平易な英語くらい分かっておけよと言う意味では?今時、ある程度を英語を抵抗無く使えないと、必要なライブラリのドキュメントも読めないし、トラブルシュートもググれないですよね?
和英辞典を引く=日本語をローマ字表記(分かる)外来語をローマ字読みで表記=typoどころかデタラメ(ダサい)
だと思う
isXxx()とか、setXxx()とか、どういう風なメソッド名にしてるの?xxxNaraba()とか、xxxSettei()、とか?滅茶苦茶読みにくいと思うのだけれども。和英混在させると、さらにカオスだし。
参考までに聞きたいのだけど、そのお客さん内で使われてる用語を当てはめる場合どうしてる?
無理矢理英訳してる(各人で訳語にずれが生じないよう対応表も作っている)?そこだけローマ字としている?
お客さんの使う言葉と、ソースコードを一致させる必要がどこにあるの?
一致させなかったらその対応表を作って保守しないといけないでしょ、それは無駄すぎる。工数増やすとお金になるならそれでもいいけど。
わざわざ対応表なんて作らなくても、データベース定義で使った語彙に併せてコード書けばいいだけでしょうに。
すべてのバッチ処理は「処理」なのでわかりづらい。往々にして無配慮に名前をつけられたあらゆるオブジェクトは、やはりダサいし、わかりづらいというのには同意できるな
すらすらでーでーすらすらじょぶ [ibm.com]
そうやって新しい技術新しい技術と変えてくと逆に不具合のオンパレードになるんだよ。かと言って、ずっとCOBOLのような消えた技術に拘り続けても技術力のある人材不足からの不具合のオンパレードになる。その辺のバランスがうまく取れてないのが銀行業界。
っつかCOBOLって消えてないし。習得難易度が低い上にナレッジも固まってるので、その気になれば技術力のある人材を1年程度で育成できる。
むしろ最近の流行りの言語のように、一見すると簡単だけど使いこなすには相当な素養と経験が必要な言語に中途半端なエンジニア使って乗り換えるから不具合のオンパレードになるのかと。あと一人前に習得する頃には別の言語が主流になってしまうので、なかなか特化した技術者も育たない。
一年程度で促成栽培された人材はまさに中途半端なエンジニアなんだけど・・・
同じ言語を1年使いつづけても習熟しないような、レベルの低い奴を雇うとそういう感想でしょうね。余程パラダイムの異なる言語でも無い限り、充分な習得にそんなに時間のかかるものでもないでしょうに。
COBOLは消えてないけどな
うむ銀行が扱う内容こそCOBOL向きだと思いますねえ言語仕様は安定しているしノウハウの積み上げも済んでる
処理.batじゃあかんの?
そのPowerShellやWSLはシス間に禁じられてしまって、使えるのは.BATしかないのさ。高級言語で記述して変換して、バッチファイルを生成してくれるといいなー、と最近本気で考えている。IFとGOTOと変数があるから何とかなるような気がしている。
そのPowerShellやWSLはシス間に禁じられてしまって
WSLを禁止するのは解るけど、Powershellを禁止するのは意味不明だな。事実だとすれば、ご愁傷様。
高級言語で記述して変換して、バッチファイルを生成してくれるといいなー、と最近本気で考えている。
ネイティブなバイナリか、.Netなマネージドコードでいいのでは?わざわざ.BATに拘る意味が解らない。
基本的に情シスって無能なので「自分に理解できない物」は全部禁止するんだよ。だから仕事の邪魔しかしねぇと言われる。
基本的に情シスの管理対象は無能なので、なぜPowerShellスクリプトがWindowsの既定で無効なのかを考えずにWordファイルを開いてEmotetに感染しちゃうんですよね。だから実行ポリシーで制限するしかねぇとなる。
それが危険だと言うのなら、.BATも禁止しないとダメなんじゃない?Powershellは署名の無いスクリプトを実行できないポリシーを強制できるけど、.BATはそーゆーのは無理だからなあ。
それよりマクロ付きの添付ファイルを禁止する方が良いんじゃない?
AppLocker使えばいい。
なるほど。技術的にできるのは確かだろうけど、運用するのは大変そうだね。これを運用するとなると、情シスもガチガチのルールを設定せざるを得ない。
翻って「高級言語で記述して変換して、バッチファイルを生成してくれる [srad.jp]」何かは、いよいよ使い道が無い。
ネイティブなバイナリが許されるわけがなかろうもん。
ならば、高級言語を.BATに変換するコンパイラは、.BATで書くのか?まあ不可能では無かろうが、そんなニッチなコンパイラをメンテナンスしてくれる人がいたらいいね。
微妙に違うコメントに誤爆してねーか?
スクリプト終了時にカレントを変えられるのはBATだけ(たぶん)
ウソだな。
PS C:\> cat .\mycd.ps1cd C:\WindowsPS C:\> .\mycd.ps1PS C:\Windows>
確かめもせずにそんな事書いて、CMD.exeにしがみついてると、老害呼ばわりされちゃうぞ。
こういう高級言語だろ。わかるよ。Brainfuck Interpreter In Batch [github.com]
OS標準搭載の .NET Framework に含まれるcsc/vbc/jsc ってのはどうだろう。dotnet は進化が止まらないが、OS標準搭載のやつなら、いい加減枯れてるって主張できそう。自分は最近、プリコンパイル型のスクリプトとして、.cmd 以上、C++以下の処理させるのに使ってる。
ボケのつもりなのか、マジで言っているのか判断に困るな。汎用機のバッチ処理と、dosのバッチ処理は全くの別モノなんだけど…。
パラダイムの違う言語が、気持ち悪く見えてしまうことは仕方ない。COBOLプログラマから見て、Javaは気持ち悪く見えるかもしれないね。Bashしかできない人にとって、Powershellが気持ち悪く見えてしまうように。
個人的には、常に新しいものに挑戦できる自分でいようと考えている。じゃないとこの業界、すぐに老害と呼ばれちゃうしね。
私はそれらに加えて、Forth, LISP, Ruby, Elixir, Prolog辺りも使ったことはあるけど、どれも気持ち悪いと言えば気持ち悪かった。でも最終的には、大抵のものは「こんなものかと納得がい」った。
そう言う意味では、PowershellのBEGIN{} PROCESS{} END{}構文は、未だに納得いかないものの一つではあるな。
いや、それとは違うんだよな。しかし、それを書くには余白が狭すぎる。
素直にbash移植してくれた方がありがたかった。WSLに魂売ってるんだし余計な独自性はいらん。
Windowsでは、みんな git のおまけの git bash を使ってるから問題ない。
何故ばれた
じゃあbashでCOMや.NETのオブジェクトを操作したりレジストリやActiveDirectoryなどを管理できるようにしてくれただちに 今すぐ たちどころに
bashはbashの道義(流儀?)があるんで、.Netのオブジェクトを扱うように作り直すのは、無駄が多いんだよ。Powershellを使ってみれば解るよ。
bash使えばいいじゃん。あんなもの有難がる気持ちの方が分からんけど。
構文は、powershellが出来た頃、最前線で一番人気だったperl の真似なんだけどな。WSLとかは、最近だが powershellは20年の歴史ある。
オブジェクトをパイプ/リダイレクトで、オブジェクトをやりとりするので、テキスト経由で処理する Unix的なスクリプトと違って桁数とか改行とかによる実データ見なきゃわからんっていうバグとは無縁なので、スクリプト書くときは Linuxでも普通に使ってる。
命名ルールからperlとは程遠いじゃん
perl使いこなしていればPHPもJavaScriptもrubyも(コーディングルールさえ乗り越えればpythonも)難なく習得できるけどPowerShellは文化が全く違う。
パイプがクソ外部プログラムの出力をパイプで受けたら全出力バッファにためてからでないと処理進めん
それは繋ぐ側のプログラムの仕様次第でしょうに。例えば grep なら --line-bufferd とか使えばいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
バッチ処理は時代遅れ (スコア:5, 興味深い)
だが、あえてバッチ処理した方が望ましい場合もあるわけで。
たとえばネットを利用した振り込みとか、不正アクセスに勘付くためにあえてリアルタイム処理できなくしてる銀行もある。
古い技術は全否定するわけではなくて、要件に応じて使い分けることが必要。
「新技術の方が優れている」は年中革新しないと気が済まない病に陥ったエンジニアの誤解。
Re:バッチ処理は時代遅れ (スコア:0, オフトピック)
syori.bat とかなら明らかに時代遅れな感じはする。
せめてPowerShellかWSLを使えと?
Re:バッチ処理は時代遅れ (スコア:2, 参考になる)
そのバッチではない。
Re:バッチ処理は時代遅れ (スコア:3, すばらしい洞察)
多分ここに書いた人達はメインフレームのバッチ処理がなんなのかすら知らない
Re: (スコア:0)
batはともかく、そういうダサいファイル名なら現在進行形で再生産されてるからなー。
こんなんとか。
https://www.city.kita.tokyo.jp/wakuchin.html [tokyo.jp]
Re:バッチ処理は時代遅れ (スコア:1)
ダサいとは思いませんし英語にしたところで問題が解決するとは思えません。分かりやすいことがまず大事なのでは?
Re:バッチ処理は時代遅れ (スコア:1)
わざわざ和英辞書を引くぐらいならローマ字で書けとお師匠に教わった
Re: (スコア:0)
>わざわざ和英辞書を引くぐらいならローマ字で書けとお師匠に教わった
今どき一々和英辞書引っ張り出すのはかなりのお歳でしょうか。
Re: (スコア:0)
辞書を引く
https://www.weblio.jp/content/%E8%BE%9E%E6%9B%B8%E3%82%92%E5%BC%95%E3%81%8F [weblio.jp]
分からない言葉を辞書で調べる。
「辞書を引く」が辞書を引っ張り出すことだと思う前に辞書くらい引けば?
Re: (スコア:0)
辞書を引く以前に、普通に平易な英語くらい分かっておけよと言う意味では?
今時、ある程度を英語を抵抗無く使えないと、必要なライブラリのドキュメントも読めないし、トラブルシュートもググれないですよね?
Re: (スコア:0)
和英辞典を引く=日本語をローマ字表記(分かる)
外来語をローマ字読みで表記=typoどころかデタラメ(ダサい)
だと思う
Re: (スコア:0)
isXxx()とか、setXxx()とか、どういう風なメソッド名にしてるの?
xxxNaraba()とか、xxxSettei()、とか?
滅茶苦茶読みにくいと思うのだけれども。
和英混在させると、さらにカオスだし。
Re: (スコア:0)
参考までに聞きたいのだけど、そのお客さん内で使われてる用語を当てはめる場合どうしてる?
無理矢理英訳してる(各人で訳語にずれが生じないよう対応表も作っている)?
そこだけローマ字としている?
Re: (スコア:0)
お客さんの使う言葉と、ソースコードを一致させる必要がどこにあるの?
Re: (スコア:0)
一致させなかったらその対応表を作って保守しないといけないでしょ、それは無駄すぎる。工数増やすとお金になるならそれでもいいけど。
Re: (スコア:0)
わざわざ対応表なんて作らなくても、データベース定義で使った語彙に併せてコード書けばいいだけでしょうに。
Re: (スコア:0)
すべてのバッチ処理は「処理」なのでわかりづらい。
往々にして無配慮に名前をつけられたあらゆるオブジェクトは、やはりダサいし、わかりづらいというのには同意できるな
Re: (スコア:0)
すらすらでーでー
すらすらじょぶ [ibm.com]
Re: (スコア:0)
そうやって新しい技術新しい技術と変えてくと逆に不具合のオンパレードになるんだよ。
かと言って、ずっとCOBOLのような消えた技術に拘り続けても技術力のある人材不足からの不具合のオンパレードになる。
その辺のバランスがうまく取れてないのが銀行業界。
Re: (スコア:0)
っつかCOBOLって消えてないし。
習得難易度が低い上にナレッジも固まってるので、その気になれば技術力のある人材を1年程度で育成できる。
むしろ最近の流行りの言語のように、一見すると簡単だけど使いこなすには相当な素養と経験が必要な言語に
中途半端なエンジニア使って乗り換えるから不具合のオンパレードになるのかと。
あと一人前に習得する頃には別の言語が主流になってしまうので、なかなか特化した技術者も育たない。
Re: (スコア:0)
一年程度で促成栽培された人材はまさに中途半端なエンジニアなんだけど・・・
Re: (スコア:0)
同じ言語を1年使いつづけても習熟しないような、レベルの低い奴を雇うとそういう感想でしょうね。
余程パラダイムの異なる言語でも無い限り、充分な習得にそんなに時間のかかるものでもないでしょうに。
Re: (スコア:0)
COBOLは消えてないけどな
Re: (スコア:0)
うむ
銀行が扱う内容こそCOBOL向きだと思いますねえ
言語仕様は安定しているしノウハウの積み上げも済んでる
Re: (スコア:0)
処理.batじゃあかんの?
Re: (スコア:0)
そのPowerShellやWSLはシス間に禁じられてしまって、使えるのは.BATしかないのさ。高級言語で記述して変換して、バッチファイルを生成してくれるといいなー、と最近本気で考えている。IFとGOTOと変数があるから何とかなるような気がしている。
Re:バッチ処理は時代遅れ (スコア:1)
そのPowerShellやWSLはシス間に禁じられてしまって
WSLを禁止するのは解るけど、Powershellを禁止するのは意味不明だな。
事実だとすれば、ご愁傷様。
高級言語で記述して変換して、バッチファイルを生成してくれるといいなー、と最近本気で考えている。
ネイティブなバイナリか、.Netなマネージドコードでいいのでは?
わざわざ.BATに拘る意味が解らない。
Re: (スコア:0)
基本的に情シスって無能なので「自分に理解できない物」は全部禁止するんだよ。
だから仕事の邪魔しかしねぇと言われる。
Re: (スコア:0)
基本的に情シスの管理対象は無能なので、なぜPowerShellスクリプトがWindowsの既定で無効なのかを考えずにWordファイルを開いてEmotetに感染しちゃうんですよね。
だから実行ポリシーで制限するしかねぇとなる。
Re:バッチ処理は時代遅れ (スコア:1)
それが危険だと言うのなら、.BATも禁止しないとダメなんじゃない?
Powershellは署名の無いスクリプトを実行できないポリシーを強制できるけど、.BATはそーゆーのは無理だからなあ。
それよりマクロ付きの添付ファイルを禁止する方が良いんじゃない?
Re:バッチ処理は時代遅れ (スコア:1)
AppLocker使えばいい。
なるほど。
技術的にできるのは確かだろうけど、運用するのは大変そうだね。
これを運用するとなると、情シスもガチガチのルールを設定せざるを得ない。
翻って「高級言語で記述して変換して、バッチファイルを生成してくれる [srad.jp]」何かは、いよいよ使い道が無い。
Re:バッチ処理は時代遅れ (スコア:1)
Re: (スコア:0)
ネイティブなバイナリが許されるわけがなかろうもん。
Re:バッチ処理は時代遅れ (スコア:1)
ネイティブなバイナリが許されるわけがなかろうもん。
ならば、高級言語を.BATに変換するコンパイラは、.BATで書くのか?
まあ不可能では無かろうが、そんなニッチなコンパイラをメンテナンスしてくれる人がいたらいいね。
Re:バッチ処理は時代遅れ (スコア:1)
微妙に違うコメントに誤爆してねーか?
スクリプト終了時にカレントを変えられるのはBATだけ(たぶん)
ウソだな。
確かめもせずにそんな事書いて、CMD.exeにしがみついてると、老害呼ばわりされちゃうぞ。
Re: (スコア:0)
こういう高級言語だろ。わかるよ。
Brainfuck Interpreter In Batch [github.com]
Re: (スコア:0)
OS標準搭載の .NET Framework に含まれるcsc/vbc/jsc ってのはどうだろう。
dotnet は進化が止まらないが、OS標準搭載のやつなら、いい加減枯れてるって主張できそう。
自分は最近、プリコンパイル型のスクリプトとして、.cmd 以上、C++以下の処理させるのに使ってる。
Re: (スコア:0)
syori.bat とかなら明らかに時代遅れな感じはする。
せめてPowerShellかWSLを使えと?
ボケのつもりなのか、マジで言っているのか判断に困るな。
汎用機のバッチ処理と、dosのバッチ処理は全くの別モノなんだけど…。
Re:バッチ処理は時代遅れ (スコア:1)
パラダイムの違う言語が、気持ち悪く見えてしまうことは仕方ない。
COBOLプログラマから見て、Javaは気持ち悪く見えるかもしれないね。
Bashしかできない人にとって、Powershellが気持ち悪く見えてしまうように。
個人的には、常に新しいものに挑戦できる自分でいようと考えている。
じゃないとこの業界、すぐに老害と呼ばれちゃうしね。
Re:バッチ処理は時代遅れ (スコア:1)
私はそれらに加えて、Forth, LISP, Ruby, Elixir, Prolog辺りも使ったことはあるけど、どれも気持ち悪いと言えば気持ち悪かった。
でも最終的には、大抵のものは「こんなものかと納得がい」った。
そう言う意味では、PowershellのBEGIN{} PROCESS{} END{}構文は、未だに納得いかないものの一つではあるな。
Re:バッチ処理は時代遅れ (スコア:1)
いや、それとは違うんだよな。
しかし、それを書くには余白が狭すぎる。
Re: (スコア:0, すばらしい洞察)
素直にbash移植してくれた方がありがたかった。
WSLに魂売ってるんだし余計な独自性はいらん。
Re:バッチ処理は時代遅れ (スコア:2, すばらしい洞察)
Windowsでは、みんな git のおまけの git bash を使ってるから問題ない。
Re: (スコア:0)
何故ばれた
Re: (スコア:0)
じゃあbashでCOMや.NETのオブジェクトを操作したり
レジストリやActiveDirectoryなどを管理できるようにしてくれ
ただちに 今すぐ たちどころに
Re:バッチ処理は時代遅れ (スコア:1)
bashはbashの道義(流儀?)があるんで、.Netのオブジェクトを扱うように作り直すのは、無駄が多いんだよ。
Powershellを使ってみれば解るよ。
Re: (スコア:0)
bash使えばいいじゃん。あんなもの有難がる気持ちの方が分からんけど。
Re: (スコア:0)
構文は、powershellが出来た頃、最前線で一番人気だったperl の真似なんだけどな。
WSLとかは、最近だが powershellは20年の歴史ある。
オブジェクトをパイプ/リダイレクトで、オブジェクトをやりとりするので、テキスト経由で処理する Unix的なスクリプトと違って桁数とか改行とかによる実データ見なきゃわからんっていうバグとは無縁なので、スクリプト書くときは Linuxでも普通に使ってる。
Re: (スコア:0)
命名ルールからperlとは程遠いじゃん
perl使いこなしていればPHPもJavaScriptもrubyも(コーディングルールさえ乗り越えればpythonも)難なく習得できるけど
PowerShellは文化が全く違う。
Re: (スコア:0)
パイプがクソ
外部プログラムの出力をパイプで受けたら全出力バッファにためてからでないと処理進めん
Re: (スコア:0)
それは繋ぐ側のプログラムの仕様次第でしょうに。
例えば grep なら --line-bufferd とか使えばいい。