国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

記一次作死 —— 被 Leetcode 封禁

dackel / 1085人閱讀

摘要：不過好消息是，在事件發(fā)生的二十四小時以后，我發(fā)現(xiàn)我的賬號解禁了，哈哈哈哈。

本文最初發(fā)布于我的個人博客：咀嚼之味

從昨天凌晨四點起，我的 Leetcode 賬號就無法提交任何代碼了，于是我意識到我的賬號大概是被封了……

起因

我和我的同學(xué) @xidui 正在維護一個項目 xidui/algorithm-training。其實就是收錄一些算法題的解答，目前主要對象就是 Leetcode。我前幾天正好做到 #17 Letter Combinations of a Phone Number。題目也蠻簡單的，我寫好以后提交了一下，發(fā)現(xiàn)跑出來的結(jié)果是 152 ms —— “哇哦，你打敗了 2.44% 的提交”。好差！！我瞬間滿臉黑線。而之前提到的項目中正好有另一個同學(xué)寫的關(guān)于這一題的解答，我趕緊去參考了一下，感覺空間復(fù)雜度比我小很多，但時間復(fù)雜度應(yīng)該差不多呀，然后注釋中有這么一句：

I think this is an O(n^3) solution, but still runs faster than 100% submissions

不信邪的我把這位同學(xué)的代碼復(fù)制過來提交了一下，得到的結(jié)果是 —— 160ms...“哇哦，你打敗了 2.44% 的提交哦！” ╮(╯_╰)╭

看了看 Discuss 里的解法，感覺復(fù)雜度似乎也差不多，于是我決定研 (Zuo) 究 (Si) 一下 Leetcode OJ 服務(wù)的穩(wěn)定性如何。

過程

打開 Chrome 的開發(fā)者工具，發(fā)現(xiàn)只有 submit 和 check 兩種 ajax 請求，response 內(nèi)容大概是這樣的：

// `submit` response
{ "submission_id": 46823974 }

// first `check` response
{ "state": "STARTED" }

// second `check` response
{
  "lang": "javascript",
  "total_testcases": 25,
  "status_code": 10,
  "status_runtime": "152 ms",
  "run_success": true,
  "state": "SUCCESS",
  "total_correct": 25,
  "question_id": "17"
}

所以只要先模擬一個 submit 的 POST 請求，拿到 submission_id 后，再用這個 id 模擬 check 的 GET 請求，直到拿到最終的結(jié)果。

我直接把之前發(fā)送的兩個 ajax 請求用 Curl 的形式保存下來：（感謝 Chrome ╰(￣▽￣)╮)

然后我寫了個 Nodejs 的小程序，每隔一分鐘調(diào)用上面保存的兩個腳本來進行一次提交，并把當(dāng)次的執(zhí)行速度保存到 Mongodb 中。代碼我就不貼啦，有興趣的話可以到 zry656565/Leetcode-Benchmark 看看。

結(jié)果

這個程序大概是在十一點左右的時候開始運行的。本以為一分鐘一次的頻率并不高，結(jié)果第二天起來一看，從凌晨四點多開始就沒有數(shù)據(jù)了，自此我這個賬號就提交不了代碼了。。

當(dāng)然啦，采集到了 300 多條數(shù)據(jù)也不能白費了，畫個圖出來看看吧。任意一個節(jié)點所提交的程序片段都是同一個，大概最終的結(jié)果是這樣的：

(⊙o⊙)…本來想著是不是能找到某個 Leetcode 的服務(wù)器稍微穩(wěn)定一點的時刻，不過似乎并不存在這樣的時刻呢。呵呵，然并卵。不過好消息是，在事件發(fā)生的二十四小時以后，我發(fā)現(xiàn)我的賬號解禁了，哈哈哈哈。

完。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/78195.html

相關(guān)文章

  • 一次作死經(jīng)歷

    摘要：今天作了一波，解決過程還是比較曲折的，特此記錄一下。第一次體驗到了設(shè)置的好處，只需修改一點就好了還是啟動不了的程序本以為配置完環(huán)境應(yīng)該就完事大吉了。 今天作了一波，解決過程還是比較曲折的，特此記錄一下。 作死行為 今天下午一時興起，改了一下硬盤名，當(dāng)時想著應(yīng)該不會有問題，畢竟以前該磁盤的掛載點是一堆亂七八糟的字符，和那個1TB卷（這名字看著真不得勁）的硬盤名看著毫無關(guān)系。 （以下為修改...

    Eastboat 評論0 收藏0

  • 記一次 Booking 線上面試中遇到的小問題

    從事 Android 開發(fā)工作要滿 5 年了，雖然明白自己技術(shù)很一般，但是也總是期望能夠有機會進入更好的平臺發(fā)展。這不，因為機緣巧合有了一次 Booking 的面試邀請（是在 hackerrank 上），然后開始臨時抱佛腳 （leetcode 走起），最終選擇了一個周末去完成線上測試，結(jié)果我完全沒預(yù)料到。本以為會被某道題的邏輯繞昏，結(jié)果哪知道被標準輸入這個東西卡得死死的，現(xiàn)在就記錄一下這次非常糟...

    lykops 評論0 收藏0

  • 記一次Node項目的優(yōu)化

    摘要：相關(guān)環(huán)境由于是一個幾年前的項目，所以使用的是這樣的。一些小提示本次優(yōu)化筆記，并不會有什么文件的展示。將異步改為了串行，喪失了作為異步事件流的優(yōu)勢。 這兩天針對一個Node項目進行了一波代碼層面的優(yōu)化，從響應(yīng)時間上看，是一次很顯著的提升。 一個純粹給客戶端提供接口的服務(wù)，沒有涉及到頁面渲染相關(guān)。 背景 首先這個項目是一個幾年前的項目了，期間一直在新增需求，導(dǎo)致代碼邏輯變得也比較復(fù)雜，接...

    dreamans 評論0 收藏0

  • 【FAILED】記一次Python后端開發(fā)面試的經(jīng)歷

    摘要：正確的思路是等概率隨機只取出共個數(shù)，每個數(shù)出現(xiàn)的概率也是相等的隨機輸出把一段代碼改成，并增加單元測試。代碼本身很簡單，即使沒學(xué)過也能看懂，改后的代碼如下但是對于單元測試則僅限于聽過的地步，需要用到，好像也有別的模塊。 在拉勾上投了十幾個公司，大部分都被標記為不合適，有兩個給了面試機會，其中一個自己覺得肯定不會去的，也就沒有去面試，另一個經(jīng)歷了一輪電話面加一輪現(xiàn)場筆試和面試，在此記錄一下...

    kohoh_ 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<