2017年09月06日のTweets

< 2017年09月05日のTweets | 2017年09月06日のTweets | 2017年09月07日のTweets >

1. 01:34:28 @neetsdkasu #

   Aイミフ

2. 04:04:56 @neetsdkasu #

   うんこみたいなバグ投げてしまった・・・うぐぅ・・

3. 04:05:47 @neetsdkasu #
   @neetsdkasu

   こんな感じなー（マジうんこ）
   
   readf("%d",&n);
   auto ans = solve(n);
   writeln(n);

4. 04:06:44 @neetsdkasu #
   @neetsdkasu

   未使用変数に対する警告マジで欲しい限り

5. 04:08:13 @neetsdkasu #
   @neetsdkasu

   このバグのせいでファーストサブミットが不正解になってしまった

6. 04:08:48 @neetsdkasu #
   @neetsdkasu

   セカンドサブミット
   
   おめでとうございます！　増井技術士事務所@masuipeoから
   「今週のお題：棒の長さを最小にするモビール」バッジが届きました。 codeiq.jp/badge/3285 @codeiqさんから

7. 04:11:00 @neetsdkasu #
   @neetsdkasu

   まぁユニットテストでsolveのテストケースのチェックしてて、入出力のチェックは怠ったというのが一番悪い、全て俺が悪い

8. 04:13:18 @neetsdkasu #
   @neetsdkasu

   もしかして未使用変数に対する警告のフラグとかあったりすんのか？

9. 04:17:26 @neetsdkasu #
   @neetsdkasu

   コンパイラのコマンドラインスイッチにそんなもん無かった・・・

10. 04:29:40 @neetsdkasu #
    @neetsdkasu

    適当にググってみたが実装されてない理由はよく分からんなあ・・・構文が色々とアレだから解析の限界とかそんなところか？（適当）

11. 04:31:43 @neetsdkasu #
    @neetsdkasu

    そのソース内では使用しないが領域として確保が必要とかいう感じの使い方があるらしいがそれはそれで専用の修飾子みたいなの作るとかでいいんじゃなかろうか・・・

12. 04:32:56 @neetsdkasu #
    @neetsdkasu

    まぁ警告のあるgolangやrustで警告ウザくてプレースホルダにぶっこむみたいな回避手段あるくらいだし、未使用変数の警告なんて意味ないとかそんな結論もあったりするのかもしらんが

13. 04:34:18 @neetsdkasu #
    @neetsdkasu

    なんだろ、デバッグビルド時のみ回避手段が有効でリリースビルドではエラー出るみたいな感じの構文が生まれてこないの何でなん

14. 04:36:22 @neetsdkasu #
    @neetsdkasu

    プレースホルダはうっかりするとそのままにしちまうから、警告は欲しい、いちいち該当の行を表示は要らんからプレースホルダで回避してる回数とかの表示でもいいし、フラグスイッチで該当の行の列挙とか・・・コンパイラに便利求めすぎか

15. 04:39:26 @neetsdkasu #
    @neetsdkasu

    警告とフォーマッタとでgolangよいけど、テスト書くの別ファイルになるし、標準ライブラリが微妙にしょぼいので、こういうキョープロ的なコード書くの微妙、dlangのユニットテストは便利だし標準ライブラリ豊富だけど微妙に使い勝手が悪い

16. 04:43:10 @neetsdkasu #
    @neetsdkasu

    rustは用途が違う感がハンパなくてキョープロで使う気がイマイチ起きない

17. 04:52:15 @neetsdkasu #

    コードIQ、パスワードが180日がどうのこうのってメッセージいい加減に消してほしいのだけど
    おいらはパスワードの定期変更は良くないという説を推奨する派なので変える気は毛頭ない

18. 04:58:07 @neetsdkasu #
    @neetsdkasu

    パスワード使いまわししていない場合におけるパスワードの定期的変更の有効性とは、（サービス側かユーザ側かどちらかで）パスワード漏洩したが、パスワードを不正入手した者がパスワードを悪用しようする時点までにパスワード変更が行われ尚且つ漏洩原因が解決されているという場合のみ・・・？

19. 05:00:46 @neetsdkasu #
    @neetsdkasu

    漏洩原因が未解決だとパスワード変更してもダダ漏れのままだし、漏洩が未発覚の場合、解決はするわけないよなあ、漏洩に気づいてるんならパスワード変更は定期的変更という意味でやるわけじゃないし

20. 05:01:56 @neetsdkasu #
    @neetsdkasu

    まぁパスワード使いまわさない人に限っては定期的変更は意味ない、と結論づけてもいいのではなかろうか（適当）
    じゃあパスワード使いまわす人らに定期的変更を促す場合は有効なのだろうか

21. 05:04:11 @neetsdkasu #
    @neetsdkasu

    使いまわす人はそもそもセキュリティ意識が低い可能性が高そう
    定期的変更を促したところでセキュリティ意識が高まるような気もしない
    リスクレベルは変わらないんじゃなかろうか

22. 05:11:25 @neetsdkasu #

    はあギトラボでのリポジトリ名にAnswer含めてるのありすぎて変更が面倒

23. 05:16:23 @neetsdkasu #
    @neetsdkasu

    ギトラボのウェブ上での変更(コミット)、なんか数十秒くらいの猶予があるっぽい、カウントダウンしてた

24. 05:19:24 @neetsdkasu #
    @neetsdkasu

    猶予じゃなくコミット完了するまでの時間か？

25. 05:37:10 @neetsdkasu #
    @neetsdkasu

    Answerの撲滅完了

26. 06:11:40 @neetsdkasu #
    @neetsdkasu

    解説見てもイミフで問題の意図が結局分からない

27. 06:19:50 @neetsdkasu #
    @neetsdkasu

    Cの解説も理屈がよくわかんね

28. 06:30:12 @neetsdkasu #
    @neetsdkasu

    うーむ、1の後に絶対0が来ないようしたい尚且つ0と1の個数が最大になるようにしたい、順番は変えられないが任意の0と1を消すことが出来る、最大のときの0と1の個数を答えろ、って問題なのか

29. 06:34:11 @neetsdkasu #
    @neetsdkasu

    消した結果が[0,0,0,...,1,1,1]のような形にしかならない、というのが解説の冒頭か、問題はどこの数字を消してそのように整形するかだが・・・
    先頭が0が続く場合はそれ採用で、末尾から0が続く場合は全部消す(ただし全部0の場合は消しちゃダメだが

30. 06:37:16 @neetsdkasu #
    @neetsdkasu

    問題はそのハザマにある1と0をどう消すのか・・・末尾からの最初の1から続く1は全採用だろうけど、その次の0からどうするかか

31. 06:40:39 @neetsdkasu #
    @neetsdkasu

    問題理解したと思ったが解説はまだイミフのまま・・・よくわからんじゃあ

32. 06:44:03 @neetsdkasu #
    @neetsdkasu

    01の境界ごとに前方の1を全部捨て後方の0を全部捨て、を先頭から順番にやればいいのか？

33. 06:48:06 @neetsdkasu #
    @neetsdkasu

    捨てだが、残すをカウントするほうが楽か、前方の0をカウント、後方の1をカウント、もっと楽にするには0か1の総数を数えておいて、前方から0か1をカウントしながら行けば残す個数はカウントしなくても算出できると、

34. 06:49:41 @neetsdkasu #
    @neetsdkasu

    自力で解法を考えたら解説の言ってることを察せるようになったが・・・

35. 06:54:39 @neetsdkasu #
    @neetsdkasu

    解説は01の境界については書いてないが、まぁそこ配慮する必要はないか、カウントするなら走査回数的に配慮必要だが、算出するなら01境界気にする必要ないむしろ境界判定がコストっぽい

36. 07:36:48 @neetsdkasu #
    @neetsdkasu

    Cだめ分からん

37. 10:27:33 @neetsdkasu #

    シェフロング、流石に今回はレーティン下がりそう・・・

38. 10:30:22 @neetsdkasu #
    @neetsdkasu

    SEAFUNC何故か通らねえ・・・どこかバグってんのか、問題読み間違えてんのかわかんねえ・・・

39. 10:48:39 @neetsdkasu #
    @neetsdkasu

    問題を読み間違えてたようだ・・・

40. 10:48:59 @neetsdkasu #

    もう寝よ・・・

< 2017年09月05日のTweets | 2017年09月06日のTweets | 2017年09月07日のTweets >