スレ立てるまでもない質問はここで 150匹目
■ このスレッドは過去ログ倉庫に格納されています
質問する前にGoogleで検索しましょう。 http://www.google.com/
プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。
前スレ
スレ立てるまでもない質問はここで 149匹目
https://mevius.5ch.net/test/read.cgi/tech/1526606537/
注意「〜と〜はどっちの方が○いですか？」みたいなのは
このスレの粘着荒らしですので無視してください web系っていつも同じようなことしかやらないイメージなんだがどうなの？ >>334
こええ
人命の重みがわからなくなっちゃうような発展途上国みたいなことになってるんだな >>329
Pascalとか、PowerShell？
PowerShellは知ってるに越したことは無いかもね。 >基礎知識として幾つかの CPU のアセンブラ
どこが基礎だ
もはやガリガリの特化知識じゃん >>336
重いからわざわざ映像をご遺族に許可もらってまで教育資料にしてるんよ。
あれはやるべきだと思うよ。
どんなプロジェクトで「どんな事をやっていた、何歳の、どんな人」が「たったこれだけの理由で」この一瞬でこの世から消えた、って、
聞いたら納得できた気はするけど、その様を見るとあっけなすぎて寒気がする。
起きる事故と人の死の重さを再認識しないと、ネジ一本、プログラム1命令の重さは感じられんよ。
他業種の人はあんまり人命に関わらんから、製造業の極端な例から攻めてくる感じが原始人への教育のように見えるんだと思う。
コメディカルの資格も持ってるけど、そっちでも死んだケースの資料見たよ。 とりあえずこれだけは言える
perlはこれまで手を出さずに済んだしこれからもperlには絶対手を出さないで切り抜ける 製造業ってもっと気楽な仕事だと思ってた
ほらメーカーってよく偽装するじゃん
自動車の制御コードが破滅的なスパゲティだったって事件もあったよね
あー適当でいいんだなーいいなーって
思ったより大変そうなんだね 仕事をきちんとやる上での気楽さとはちょっと違うけど
俺は人の財産や身体の安全に関わるような仕事は決してしないと決めている webはいいけどフロントエンドは絶対仕事にしたくないな
仕事でゴミみたいな言語触りたくない >>345
は？
今やフロントエンドやバックエンド全てJSで済むだろ JSはモダンで使いやすい言語だよ
ただしBabel必須 でもTSエアプだから触ったら手のひら返すかもしれん >>334
使い古しの動画じゃんｗ
人があっさり死ぬわけじゃないんだね Web系と組み込み製品以外何がある？
シミュレータとか金融とか会計しか思い付かん
五個しかないの？ Web、組み込み、シミュレータ、金融、会計の5個って一体何が？
プログラミングの仕事？ うちの会社はクライアントアプリ開発が売り上げの過半で
PC や Mac、iPhone と Android のアプリ作ってる。
技術偏重で自社製品と他所への oem だから面白いけど、
営業が仕事取ってくれば売り上げが増えるような業態じゃないから将来が不安 やっぱり計算機科学という学問は、純粋数学の落ちこぼれがやる学問なのでしょうか？ >>342
それに関しては一部がすまんとしか言いようがないな…。
業種にも寄ると思うけど、いろんなソフトウエアのEULAで、明示的にお前の業種のサポートはねえから別途契約しろって
書かれてる業種はだいたいこんなもんだと思うよ。
スパゲティは適当にやってるからそうなるパターンと、アドレス変えられないとか、適用時にメモリにホットフィックス
しないといけないとかそういうパターンで已む無くそうなってるパターンがある。
>>350
まあ確かに発生頻度は下がってるよ。
死んで安全性上げてきたと言われれば仕方ないけどな。
率としては下がってるけど、まあ死ぬときはあっさり死ぬ。
生で死ぬ瞬間を見たこと無いだけで、周りで死んだ経験が無いわけでも無いよ。
俺も死なないほうがいいともちろん思ってるが、みんな客も自分も死なないように真面目にやってるから死なないんであって
「あっさり死なねえじゃんw」って単に言えるもんでもない。
できればあんまり草生やさんで欲しいわ。 >>321
エレベーターが地獄って聞いた
エレベーターのアルゴリズムはとんでもなくややこしいらしい 東大医学部首席合格者とエドガー・ダイクストラはどっちの方が頭が良いですか？ >>358
エレベーターは楽な方。
安全面に関しては物理的に維持してるし。
ややこしいのは、効率よく人を運ぶアルゴリズムとか、
間違えても人命なんかには影響しない部分だし。 >>350
人は失敗から学ぶモノ。
ロボットなんかは、必要最小限まで「弱く」する事で暴走時の物理的被害を減らすなど、ソフトウェア以外の対策も運用に合わせて考えられてる。
特に、人が死んだのなら同じ失敗は二度と起きないような仕組みが取り入れられる。
今、直接人命に関わるソフトウェアっていえば、車の自動運転とかそっち方面かと。 >>364
かっこ悪いからせめてフェイルセーフとか使って >>365
いや、フェイルセーフの概念知ってる奴には抑も説明不要だろ。。。 C#は物がすぐ作れるからプログラミング入門にお勧めってどっかで見たんだけど
そんなに簡単なの？それとも嘘っぱちでそれ相応学ばないと何も造れない？ >>367
そもそも俺のように人様の安全に関わらない仕事をすればズボラでもなわけだ >>368
人による
かなり簡単な方だができない人にはできない
できる人は質問なんかしないでコード書き始めてるから、
多分>>368にはできない >>368
使い慣れた日本語なら簡単だから、
小説書くのも簡単だよ。
って感じ。 >>380
了解
プログラミングなめてたは
諦める >>372
諦めなくていいけど
人とこうしてプログラミングについて話すことじゃなくて、
1人でああでもないこうでもないああこうかな？と
資料読みながらプログラミングに没頭して徹夜するとか
そういう姿勢が大事よ ただ、簡単！らくらく！入門！なんかはただの客寄せ宣伝文句、これは間違いない
あと誰でもできる！敷居が低い！って風潮作って人件費下げを狙ってる輩もいるかもな 異なるフォーマットで時系列順に記録されたログをまとめて時系列順に表示したいのですが、
18/10/03 10:19:23.992
のように、ミリ秒単位で記録されログと、
18/10/03 10:19:23
のように、ミリ秒が記録されないログ、そして
18/10/03 10:19
のように、秒数すら記録されないログがあります。
これを出来るだけ正確に並び替える手法はないでしょうか？ >>378
文字列処理を繰り返して構文解析し、日時に翻訳する。記述の端数はゼロと見なす。 >>378
不足分を:00.000などで補間してソートする 日時を文字列で比較する場合は桁を合わせないといけないよ。 無いデータを作り出すのはいかんのでは？
0.000秒の保証が無いのに勝手に桁増やすのは正確じゃないと言うよりは嘘データでは？
その嘘で前後関係が変わると0.000って表示されてるのに実際は後ろだったりするじゃん。
俺なら諦めて分まで落として、キーか何かのアルファベット順に表示するかなぁ。
書いてあるのに嘘はいかんと思う。 もともと時系列になっとるもんをソートしなおすなよバカw
主客転倒もはなはだしいわw >>383
単体では時系列でも全体では正しい時系列じゃないんだから。
一部でも信頼できない区間があるならば、信頼できるレベルまで落とすしかあるまい。
有効数字と同じ理屈。 >>385
まじで言っとんのかおまえw
恣意的なキーでソートしなおしたら元々信頼できる時系列が信頼できんもんなるだけやぞw
主客転倒もはなはだしいわw >>378
記されていない部分までの形式が同じなら単なる辞書順ソートで良いのでは？
12:20 (秒が無いが実は12:20:08)
12:20:02 ほげほげ
のように後先がわからないのはもちろんどうしょうもない >>378
ログ形式は変更できないけどログを取るところからやれるなら、
tail -f logfile | ts '%Y%m%d-%H:%M:%.S' >> logfile.mod
などしてタイムスタンプを追加しておくという手もある。 >>386
もともと信頼できないよね。全体では整合性は。
そりゃ一番いいのは全部のログにタイムスタンプが落ちる事だけど。
整合性が担保できないなら、明示的にこの列でソートされてる、って方がよっぽどマシだと思うけど。
その桁が信頼できないなら、ただ偶然そう並んでるだけとしか扱えないんじゃないの？
その単品で有意な情報でも、ある情報と足したら無為になるんなら。
単品では信頼できるのは分かってる。
精度が十分でないものと合わせるとその桁に意味が無くなるのは分かってる？
3.00と3は比べようがない。
どうして勝手に足りない精度を補完するかが謎。 プログラムの話しろよ
無い情報を作ったり無い物を元に並べるとか最初から無理な話 >>389
もともと信頼できる時系列で並んどるよその3つのログは
何を勘違いしてログの順番をごちゃまぜにしようとしとるんだかわからんが精度も問題とちゃうでw
主客転倒もはなはだしいわw 結局のところ、「どうやろうとしても無理が出る」だよな…
切り捨てるにしろ、補完するにしろ、そのままが一番正確だという意見にしろ。 >>391
それぞれ3つは信頼できる時系列で並んでるが、
3つを合わせたものは信頼できる時系列じゃないよ。
本当に理解できないバカなの？ 元の文字列のままにしておけば精度が足りてないことも含めて情報が保存されるけど、
日時だから epoc 秒(or date型)で保存しちゃうぞおじさんが居たらどうもならんな 考え方はepoc秒と同じ
必要な開始時刻から必要な精度までｼﾘｱﾙ値でおとせばｲｲﾜｹだからな
べつに浮動小数のﾕﾘｳｽ通日に一旦変換でもいい
それをｷｰにしてｿｰﾄすればなにも問題ない
上にいるような低学歴知恵遅れは考えが浅はか 低学歴知恵遅れはﾕﾘｳｽ通日が
いろんなとこで実は使われてるのを知らないからな
しょうがない
まともな教育を受けてない でなこういう低学歴知恵遅れが
ﾀｲﾑｿﾞｰﾝいれて時刻を保存したりするﾜｹ
で、ｻﾏｰﾀｲﾑｽﾚでｱﾎが騒ぐわけ
低学歴知恵遅れがｼｽﾃﾑ作ると
日本のﾀｲﾑｿﾞｰﾝがかわるだけで
太陽の軌道計算が変わるからな ﾎﾝﾄなこの板にいるﾔﾂﾗは
自分から低学歴知恵遅れですと
いちいち自白するからな まともな教育を受けてない低学歴知恵遅れの底辺ITﾄﾞｶﾀですと
いちいち自白するﾜｹ
こまったことに ユリウスだかカエサルだかしらねーけどどうでもいいんだよお
どう切るかどう統合するか決めてこれが仕様ですって胸張りゃ済むんだよ >>396
精度が足りないんだよw
半角の人はホントに馬鹿だな。 たとえepochで持ってても、一番低い精度の桁に丸めないとな。
分までしかないなら秒以下を落とさないと。 >>378
Ruby で、時刻でソートしたら、逆順になった
require 'time'
ary = [ "18/10/03 10:19:23.992", "18/10/03 10:19:23", "18/10/03 10:19" ]
ary.map { |str| Time.parse( str ) }.sort!
.each { |tm| puts tm.strftime( "%F %T.%L %z" ) }
出力
2018-10-03 10:19:00.000 +0900
2018-10-03 10:19:23.000 +0900
2018-10-03 10:19:23.992 +0900 >>408
ちゃんとログファイルっぽく時刻の後に空白なりタブなり付けて
辞書順にソートすれば余計なゼロなど付けなくても期待した順になるだろう 普通にsortメソッドのブロックでカスタマイズした大小比較を行うだけだから。
なんで元の日付を書き換えようとする奴らばかりなんだ？
比較関数だけ作ればいいだろう？ >>410
そりゃおまいさんが、実際の出力と内部処理用のデータを混同してるからだ 天才だったらどれだけ良かったか・・・・・・。
自殺をして天才に生まれ変わることってできるのかな・・・・・・。 >>411
内部処理用のデータの話なんかしてないよ？
ログファイルって書いてあるじゃん 個人用のプログラムを書いたはいいものの遅いのでロジック等で他にやりようあるか教えてください
apiであるログ取得してます
apiの制限で100件毎にページングされてたデータを1ページ単位でしか取れません。返ってくるデータはjsonで自分が欲しいのはcsvです。
今のロジックですが9月分のデータが欲しい場合月初から月末日までのログを全量取得してtxt形式（json）で出力（2万件の場合100件取得 txtに追記 次のページ取得）、そのtxtを読み込みcsvに変換する作業をしてます。
1月分のログの数が少ないと良いんですが2万3万という単位のログになるとtxtファイルが大きくなりすぎて参照、出力に時間掛かったりしてるみたいです
なにかいい方法無いですかね APIの呼び出しに時間がかかってるからどうしようもない >>413
ソートは処理に含まれないのか、すまんかったな すいません時間の詳細と言語書き忘れてました
python使ってます インタプリタなんで遅いと思いますが今回はロジックで対応出来るかが知りたいので言語変更はなしでお願いします
時間は2万以上のログで30分前後 txtが大きくなった後半はリクエスト 100件取得 保存を10秒程度でリクエストで2秒 txt読んで追記に8秒以上掛かっててここをどうにかしたいです 何秒掛かっていると言っても、それは処理の時間じゃない！
処理するものが無くて、ただ待っているだけの時間だろ。
処理時間じゃない！
処理するデータが来ないだけ 世界最高の大学はどこですか？
ハーバードかオックスフォードかケンブリッジのどれかですか？
世界最大の大学への入学を目指したいと思います。 追記するのに、テキストを読む必要無くないか？
ファイルを開くときにAPPENDで開いたら済むんでは？ >>417
レコードの処理毎に一々標準入出力使ってテキストファイルの読み書きしてない？
標準入出力は物凄く遅いから、
テキストファイルの読み書きをできるだけ避けるようにしたらどう？ 底辺高校卒でしかもかなりブランクのある者ですけど、
ハーバード大かオックスフォード大かケンブリッジ大に入りたいです。
それぞれの大学に入るにはどうすれば良いのでしょうか？
誰か教えてください。お願いします。 >>421
確かにそのとおりですね…不必要な処理が入ってました
>>423
今それでやってますがなにか他にやりようありますかね？
100分ずつしか取得できないから2万件ログなら200回アクセスしないとダメかなと思ってるんですが… 毎回全部読んで追記して全部書き込みしてるところを
>>421の指摘通り直すだけで他は何もしなくてもいいと思う あとは幾つかのページの範囲に分割して並行して処理して個別のファイルに書き出して
最後にそれら全てを繋げるとか レスくれた方ありがとうございました
気になってた点は早くなり解消しました
ありがとうございます 精度をあげるように変えればしまいだからな
あいかわらず低学歴知恵遅れはいってることが意味不明
低学歴知恵遅れにはそのやりかたがわからないらしいわ
低学歴知恵遅れには問題解決というのがよくわかる 低学歴知恵遅れには問題解決はﾑﾘ
低学歴知恵遅れの底辺ITﾄﾞｶﾀは基本的にいわれたとおりのことしかできない
刺身にﾀﾝﾎﾟﾎﾟのせるような作業精一杯 >>430
低学歴知恵遅れには問題解決と言うのがよくわかって良いのかw
epoch秒に変換する事はできないって精度の問題を、epoch秒で対応すれば良いって結論が出るところを見ると、低学歴知恵遅れには問題解決と言うのがよくわかるとは思えないがw 「9月4日 修学旅行出発」を時刻だから秒単位で記録すればok!って
「9月4日0時0分 修学旅行出発」と書き換えちゃいけない
ことくらい低学歴の俺でもわかるぞ… 流石にわからん奴はいないだろうし
db とかでソートキーとして元の情報とは別途持つイメージなのかな ■ このスレッドは過去ログ倉庫に格納されています
