午後問8(情報システム開発)についての投稿を受け付けるスレッドです。

設問1
（１）H、S、T社
（２）20220510 1800 G0030110 8

設問2
ア、エ

設問3
エ（Webスクレイピング）

設問4
a ヘッダレコード部のデータレコード件数
b ファイル内のデータレコード件数

設問5はわからなかった…
設問1（1）もあまり自信はないです。

問1合ってると思います
問5は、既に統合空席情報ファイルがあれば初期化する、と書きました

No2さんと設問3までは一緒で、
4aはクライアント側のハッシュ値 4bはホストサーバー側のハッシュ値
5は「ターミナルの運行計画のデータの空席数を全てnullにする」にしました。

No2さんの4は件数の部分が正しく転送されているかの保証はできていないような気がするので違うかな...?と個人的に思いました。自分のハッシュ値も同じような文章になって自信がないですけど...

設問4
a 転送前のファイルサイズ
b 転送後のファイルサイズ
終わった…
aとbで同じこと聞くわけないよな…

古い空席記号って0パディングされた数字が表示されるってことじゃないのかな？
だからそこ直したいんだけど文章が思いつかずint型に直すとか書いた(←アホ)

ファイルサイズやハッシュ値のほうが厳密な確認ですね。ただ、受信側の処理で確認できますかね…？

自分は「ヘッダレコードに件数を含めることにした」っていう記述がなんとなくヒントかなと思い、書いちゃいました。
途中までしか遅れていない場合、レコード件数が合わなくなるはずなので。（最後の行の途中までしか送れていない、というケースまでは想定できていません）

1はH社だけにしちゃいました

高速バス、観光バスは定員制なので空席の把握が必要ですが、S、Tは路線バスのみなので必要ない
と考えてました

けどこれ結合便コードの話なんでよく考えたらSとTも使いそうですね…

あ！確かにそういう考えならあってますね！！なんか模範解答な気がしてきました。

わたしも問4はななしさんと同じです。
問2は分からずア、イにしました。

件数があっていてもデータが破損してたら発車日とかのデータが変わってたりしそう...とか思っちゃいました
a,bが違うものになっていてしっくりくる解答が欲しいです笑

設問4はななしさんが合ってると思います

>ななさん
S、T社を含めるのかor含めないのか、まだ自分も腑に落ちてないです。
ファイル連携されないのは確かですが、コードの有無まではわからず…

あーでもftpでls -lコマンド叩けるから転送前のファイルサイズ分かると思われる
模範解答じゃないかもだけど

問１
1 S社，T社
2 20220510 1800 G0030110 8
問２
ア，エ
問３
イ
問４
a データレコード
b  運航計画から生成したデータレコード
問５
ターミナルの運用計画に設定する空席数すべてnullを設定する

にしました。。。微妙です。。。

問4はヘッダーレコードのデータレコード件数とデータレコードの件数の一致を確認するですねー
実務でもこのチェックやりますねー

ですよねええ…
でも最後の行の途中で転送ブッチする可能性もあると思うの(泣)

たしかに転送途中にネットワーク切断とかで0バイトチェックやカラムチェックが必要なシーンはありますけど、それは転送したファイルが”誤った状態であることを確認するチェック”で設問で問われていることは”ファイル全体が正しく転送されたことを確認する必要があるという指摘”なので、
正しいことを確認するのはヘッダの件数とデータ件数をチェックすることになります。

最後の行の途中でブチンした時は行数カウントだけじゃ「ファイル全体が正しく転送されたことを確認」できませんよね？
でも設問では恐らくそこまで厳密には聞いてなさそうな気もするし取り敢えず結果を待ちます。
私は開発で外部転送機能を追加する時は必ずファイルサイズ確認しろって言われるんですよね…

ファイルサイズとタイムスタンプにしました。
内容が違っても、同じサイズになる場合がありますよね？

問4わからず最後のデータのコードと運行計画の最終便のコードが等しいこと、って書いてしまったけど
1点でいいから途中点もらえないかしら

5は、同じ数の空席が続く場合はnullを設定して'-'を表示されるようにするとしました。

>俊郎さん
>内容が違っても、同じサイズになる場合がありますよね？
ありますねえ…何も言えねえw

5は、常に空席情報が全量送られてくる前提で｢一律nullにする｣にしたんですが、そのあたりの情報出てましたっけ……？

たにとさん

自分も初期値気になったので目を皿にして読みましたがなかったと思います
初期値にnullを挿入する、とだけ書きましたが……

言いたいことは分かりますよ
確かに件数チェックのみでは最後で途切れた場合ファイル全体が正しいかは確認できないですね。
ただCSVできているので、列が正しいかのチェックをすればそのファイルは通さないですよね
しかもこのチェックをやらないとすると、わざわざヘッダーにレコード件数を入れること自体が過分な設計だし、文脈的にもおかしいと思うんですよねー

もちろんファイルサイズで確認できるのが一番ですが、E社との調整でE社の場合E社が送信なので、
送信元ファイルのファイルサイズ読みに行くなら、E社と再調整しなければいけないとか、
E社は送信のみって認識しているから、こっちからファイルサイズ読みにいって、E社がディレクトリやサーバー変えたら即障害とか自分なら考えちゃいますねー

設問４ですが、文章に書いてある「ファイル全体が正しく転送されたことを確認」を考えると
ヘッダーのレコード件数と転送されてきたファイルのレコード件数比較だと確認できない気がして
"サイズ"と"文字数および行数"にしたんですが、２０字には程遠いんですよね…

>らあぼさん
ありがとう。通信の向き先完全に見落としてたわ…
E社→C社に送信してるならC社がいちいちE社に確認しに行くのはしんどすぎるね。
一律csvヘッダ記載のレコード件数と行数比較で済ませるわなぁ…
減点でも良いからワンチャン、ファイルサイズも点数くれねえかな(遠い目)

CSVじゃ、RFC4180だと改行も許可しているから、wc -l（行数カウント）じゃ本来なんの保証にもならんですね。そこがCSVは難しい（サードパーティライブラリを使えば別）点なんですが・・・。

改行コードは空席情報ファイルが発車日、発車時刻、統合便コード、空席数、座席数で構成されているから連携されては来ないでしょう。
備考欄とかが存在するなら要注意ですが。
（もちろんIF定義で連携されないことを確実に合意する必要はありますよね）

>改行コードは空席情報ファイルが発車日、発車時刻、統合便コード、空席数、座席数
そうでしたか、本文をpdfが公開されてから見たので一般論で話してしまって申し訳ないです。
それでも昔そんな枠に改行も無断でぶちこまれてぶちギレましたねえ
gawk5でFPATで金額のカンマとかを処理して改行をいくつかフィルタかまして処理して・・・とかほんとCSVはろくな目に遭いませんね

ファイル全体が正しく送信されているかチェックなんですよね？文字変換コードとファイルの形式って描きましたが、×っぽいですね…  最後は－を表示するって書きました

設問5は「一定時間空席情報が取得できなかったら空席数を0をする」って書いちゃいました…表1見るとnullが妥当ですね…忘れてた
部分点くれないかなー

＞それでも昔そんな枠に改行も無断でぶちこまれてぶちギレましたねえ
それはその災難でしたね...
IF定義きっちりしてればとは思いますが、おそらく会社やシステム間の力関係、予算、スケジュール様々な理由でそうなってしまったことでしょう。
心中お察しいたします

問４のa.b.ですが、
a.C社が受信したファイル数
b.事業者が格納・送信したファイル数
では×ですかね。。。

今回後半の記述部難しいですよね
こんなはずじゃなかった…

何より表が多く文字数も多く時間もなくて読みきれなかったのが悔やまれる…

うわーファイルの定義にヘッダーレコードがあることを認識せずに問4答えてしまった...。
違和感覚えながら「転送元のファイル」と「転送後のファイル」を比較するって書いてしまいました。問題のテーマから類推して、きちんと問題文でのファイル定義を読み直しにいくべきでした。時間的余裕はあまりなかったものの。。

ここで聞いても意味ないし望み薄なのもわかってるんですが、最後まで転送できてるかどうかを確認するためなら最終便のデータを比較するとかじゃダメですかね……

問1ですが
ST社は路線バスであり空席情報は必要ないと考え、
H社のみとしてしまいました。

大原やTACもST社を含めていますが、
何故必要なのか説明できる方いらっしゃいますでしょうか

路線コードの重複がないかチェックが必要でしょう。

うーん、文から察するに、
空席情報のためにレコードの検討をしていて、
その中で重複の確認をしているから
空席うんぬんが不要な路線バスは調べる必要ない気がするんだよなあ。。
。。ここで何言っても仕方ないか。。

H社こそデータがないとでてるんだから、いらないかなと思って
STと回答しました。

自分もSTにしたけど、見直したら、HSTだね。

Hも他のバスと路線コードが重なっていたら、IDのルールを変えないといけない。

統合便コードは新バスターミナルシステム全体で使用するものなので、重複がないかチェックする必要があります。空席情報のためのレコード検討のなかですが、統合便コードのみはシステム全体での確認が必要ということです。