Month: June 2018
打水程式
「打水程式」的電腦簽賭程式,利用兩個網站間對同一場比賽的不同賠率,自動找出同時押注兩隊均可獲利的比賽,從中賺取差價,獲利率幾乎百分之百。利用不同簽賭網站對同一場比賽訂定的賠率不同,從中賺取差價,早在國外及大陸地區風行多年,並有簽賭集團專門藉此牟利。早期均是靠人力坐在電腦前分析各個簽賭網站的賠率,稱之為「打水」,負責分析者稱為「打水員」,後來則演進為以電腦程式自動在簽賭網站之間找出可獲利的比賽,稱為「打水程式」。 舉例來說,一場A隊對上B隊的比賽,甲站對A隊開出賠率1:1,對B隊開出賠率1:0.9;乙站對A隊開出賠率1:0.8,對B隊賠率1:1.1。如同時下注甲站A隊10000元,乙站B隊9500元,比賽結束後,如A隊獲勝,甲站可贏10000元,乙站輸9500元,可獲利500元;若B隊獲勝,則甲站輸10000元,乙站可贏10450元,仍獲利450元。 弱盤打水:高勝率、高風險、高報酬 打弱盤才是近年打水的主流,目前台灣的球公司普遍都是這種打法,一般沒接觸打水的玩家很難將打弱盤和打水畫上等號,其實許多人在說的「假球理論」、「十賭九輸理論」、「明燈理論」,都是指向「弱盤理論」。打弱盤並不是打雙邊,而是只打單邊,就是永遠站在人少的那一邊;就單一場比賽來看打弱盤是打單邊,然而將整個投注模式放大後,打弱盤即是囊括了所有不公平盤底下得利的那一邊,「假球理論」指的是熱門投注球隊故意放水坑殺散戶,「十賭九輸理論」指的是注碼多的一方會輸球,「明燈理論」指的是賭桌上投注最多的那個賭客通常是其他賭客的明燈,跟他反向投注就會贏錢。 用比較科學點的角度來看,A隊在初始的平衡盤口讓B隊1分,但因為A隊是投注熱門,經過大量投注後變成讓B隊1.5分,此時買B隊等於比平衡盤多了0.5分的受讓,那勝率自然會拉高,所以打弱盤在理論基礎上並沒有什麼太大的缺陷,若能做到場場投注弱盤,也就是永遠站在55%以上勝率的那一方,那將時間軸拉長後確實是穩賺不賠的生意。 當然就短時間內來看,打弱盤的風險一定是所有水單中最大的,單邊投注就會佔到輸贏,而不是真的只賺水錢或分洞,但時間拉長後和別的水單並無二致,只是打弱盤會有更高的勝率,和折損更少的賠率損失,只要資金夠充裕可以承受一時的勝負擺盪,打弱盤無疑是報酬最好的打水方式。 什麼是足球打水?對於初次接觸的朋友可能會感到很陌生,足球打水本質上是利用了平台與平台之間的對賭,自己從中賺取利潤。比如意甲比賽我們在A平台上下注AC米蘭獲勝,在B平台上下注尤文圖斯獲勝,這樣不管最終是尤文圖斯贏,還是AC米蘭贏,我都能買中。因為賠率的關係,除去下注的金額,我們還能有盈利,這個過程我們就稱為足球打水。足球打水為什麼能夠獲利呢?這裡面有一個很關鍵的因素——賠率,上一段中也有提到。賠率是菠菜平台經過嚴密計算綜合得出的,這就跟保險公司確定保險範圍和收費一個道理。一般情況下,一場比賽,根據兩隊交戰歷史紀錄,兩隊最近狀態,主客場勝率等,會確立3個賠率。我們先來簡單了解下賠率,後面我們在說打水套利的公式是怎樣的。 賠率計算公式:a÷b=c cc×10%=d 這裡面d就是最終計算出來的賠率 a是基數,值為100 b是莊家分析師分析出來的百分比概率 c是a / b的結果 舉個例子: 世界杯中巴西與阿根廷的比賽,莊家通過分析得出巴西勝出的概率為40%左右。那麼就用這個公式來計算如下: 第一步100÷40=2.5 第二步2.5-2.5×10%=2.25 那麼,莊家開出巴西的賠率會在2.25左右。 如莊家通過分析得出打平的概率為31%左右,那麼就用這個公式來計算如下: 第一步100÷31=3.22 第二步3.22-3.22×10%=3 那麼,莊家就會開出平局的賠率會在2.89左右。阿根廷獲勝的賠率也可以按照相同的方法計算出。 上面就是賠率的簡單計算過程中,不過賠率並不是固定不變的,Bet公司會根據球隊的狀態已經下注的情況,動態調整比賽賠率,因為賠率有了動態的變動,我們才有足球打水的機會。那麼足球打水套路公式是怎樣的呢? 計算方法:上盤,假設回水1%,下注2000,水位1.00,輸贏都是2000。下盤,假設回水1%,下注2020,水位0.98,如果下盤贏就賺2020*0.98,2020*0.98 + (2000+2020)*1% – 2000=19.8,賺19.8塊;如果下盤輸,2000+ (2000+2010)*1% -2020=19.8,一樣賺19.8塊。 足球打水之所以能夠盈利,就是因為不同Bet平台有賠率變動的時間差,抓住這些時間差,我們足球打水就能夠獲利。
發現左一個可以玩殘你嘅咪記大bug
發現左一個可以玩殘你嘅咪記大bug,如果你寫sharepoint兼用typescript但係又想用jquery, 你好可能會用: import * as $ from ‘jquery’; 如果嗰畫面得一個webpart,甘你會無事,如果有多個webpart(見下圖),你reload幾次就會撞到有一次某幾個webpart無哂野,因為jquery撞左,網上有啲友話係config.json個externals加返jquery呢一招我試過唔得。但我撞到有一招係work嘅:
佛教根本就放唔落人類的道德
佛教根本無一本書講明做好人一定有好報,無一位過去嘅論師可以或嘗試過論證呢一點,龍樹無,無著無,世親無,十大弟子都無。佛教的根本立命之題就係世界是無常,呢種無常係終極嘅無常,甘仲點可能做好人一定好有報呢。如果宇宙真係做好人一定會有好報,甘呢個宇宙就應該被一個更大嘅機器所包住,再由呢個機器去維護呢個宇宙做好人一定有好報呢條一定會發生嘅定律。宇宙根本唔係為人類而設甘點可能有一條定律為人類而設計呢?人嘅行為會帶來後果,好壞嘅後果全部都係自己懲罰自己,呢點係唯一公平嘅地方。因為呢個宇宙唔會為左你而設立機制去懲罰,你自己就係懲罰你自己嘅唯一機制。
Autoconf不能跑得很快的原因
Autoconf不能跑得很快的原因是因為它會為每一個feature去compile一個很小的測試程式去測試那個feature能不能被正確編譯出來,在底層系統的世界,因為歷史原故,我們不能好簡單的判斷在你的dev machine裏有libXXX.1.2.3.so就認為你的代碼能正確地編譯出來,因為好多時library的作者更改了代碼但沒有升級版本號。如果要令你的c/c++程式能誇平台編譯,版本號也是沒有絕對意義,因為同一個版本的library在linux和在unix上有着實質的不同。最誇張的例子就是有些庫在linux上是存在,但在unix上是不存在,所以autoconf要為每一次編譯去逐個測試,所以實在快不來,這一點和java/nodejs世界的build system有非常大的不同。
spfx code to check list exists, create list and add a drop down column
A workable and deployable package.json for spfx 1.5 with office fabric react
Simplest websocket with nodejs example
1. express –view=ejs myspp 2. var server = http.createServer(app); 3. Source : myapp
Add and remove attachments to an item in a compose form in Outlook
太失望,Redis比H2慢很多很多
插一百萬行record, Redis比H2慢太多,H2只需要七秒,redis用了40秒,為什麼用c++寫出來的redis會比用java寫出來的h2慢這麼多的? NoSQL不是比傳統database爽快的嗎?
Solved: vscode [tslint] ‘ should be ” (quotemark)
To solve “[tslint] ‘ should be ” (quotemark)” when developing spfx webpart using visual studio code, do these: open config/tslint.json add { “$schema”: “https://dev.office.com/json-schemas/core-build/tslint.schema.json”, // Display errors as warnings “displayAsWarning”: false, // The TSLint task may have been configured with several custom lint rules // before this config file is read (for example lint rules […]
SPfx on-premises solution is lagging behind to SPO
極嚴重, sharepoint framework個generator仲停留緊係1.1.0俾on-premises, 而sharepoint online已經去到1.5.0, 兩個世界再次被split開而咪記班友無意慾修正。千其唔可以sell啲客一個solution做哂sharepoint online同埋未來嘅sharepoint 2019, 死硬 !!! https://github.com/SharePoint/sp-dev-docs/issues/1883
最為強大嘅programming法門
Programming就係體驗佛教空性嘅其中一種法門, 但要用它來體驗空性, programmer必需揭而不捨地向程式嘅本質進發, 呢一種就係最為強大嘅programming法門, 與真理接軌嘅修練方式.
放工去圖書館之Redis
IT人嘅朵與Framework guideline
一本由framework作者寫的framework設計手則書,內容由作者的角度講出設計framework的重點,思路同手則,如果要寫一份doc去形容自己出黎嘅framework可以參考下呢本書的鋪排: 第一章 : 什麼是好的framework,作者們由自己嘅經驗去給一個定義今大家知道這一次他的設計會顧及那些方面,包括”設計要簡單”,”整合性強”,”設計一致”,等等。 第二章:principle, 架構設計需知 第三四五六七章:落地嘅架構 IT人嘅朵 呢本書集合哂.net framework嘅猛人,人地講自己嘅介紹時會有以下幾點: 做嘅project用左啲乜野技術,例如有位叫Jan Gray嘅人話自己搞compiler包括左semantics, runtime object model, precompiled headers, PDBs等等技術。而香港IT人係linkedin上面係唔會講到甘深入,通常係甘二講下個project名就算數。 人地會講清楚係咩team到負責咩野,例如係c# language design team負責xml部份嘅parser設計,而香港人剩係會話係咩team帶緊幾多百人,間公司好幾global,係啲乜乜實實IT協會嘅人,睇完根本都唔知佢係邊一種技術嘅專家(其實係無) 人地係會有佢個blog條link,香港人有blog? 人地會話係msdn雜誌到做過編輯,香港人就連msdn都唔會睇,哈哈
Autotool太複雜
Autotool太複雜,個人認為它阻礙了system programming的發展應該給斷除。AutoTool由三大組件所構成:autoconf, automake和libtool。Autoconf是由autoconf, autoreconf, autoheader, autoscan, autoupdate, ifnames, autom4te, m4指令所合成,automake由automake和aclocal指令合成,libtool則由libtool, libtoolize, ltdl等指令所構成。它們之間也沒有一個統一個使用標準,就是說你可以自己去判斷用那些指令去構建你的build system,所以學習難度非常之大也不統一。所以根本學唔掂,你可以隨便git一個開源項目試下改一下它的autoconf就會知道。
Remove the “Logging” menu from putty
Below are the steps to remove the “Logging” menu from putty Download windows source from putty website, don’t clone from the github because it missing Makefile.vc. Search for “Windows source archive” in https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html Comment out line 1488 to 1543 in config.c which in the root folder (see below image) cd windows nmake -f Makefile.vc If everything […]
Dynamics 365 crm language bug
Change the language from chinese back to english, some texts are still in chinese, no way to solve !