亚洲色成人网站www永久,亚洲欧美人成视频一区在线,亚洲国产成人高清在线观看,亚洲精品久久久久久动漫,亚洲国产精品久久电影欧美

前排提醒,怕來低級黑 中文編程主要是用于變量名,在義務教育普及的年代,沒人想改關(guān)鍵字。 中文編程普及的前提是編譯器支持 UniCode,已經(jīng)實現(xiàn)。但還有很多問題尚待解決,下文說的是重要問題之一。 中文在某些情況下可能優(yōu)于英文,并不是要在任何場景下使用。
重要問題
用更熟練的語言思考,對于提高思考的質(zhì)量和速度都有很好的幫助[1]。
由于中文在編程界不是通用的語言,所以用它編程的重要問題是 —— 沒有辦法和其他國家的人進行交流,老外一看變量名都是方塊字,估計直接勸退了。
軟件界面多語言已經(jīng)很常見了,代碼也可以有這個思路。
讓自然語言和編程語言在寫變量名方面解耦,可以先用母語寫變量名,并用來思考編程問題,發(fā)布的時候,然后再逐漸翻譯,就像現(xiàn)在的軟件那樣。
變量名與自然語言解耦的好處 提升命名質(zhì)量： 專心思考：由于代碼和自然語言解耦,可以用專門時間來思考變量名問題,而不是在思考編程問題,手忙腳亂的時候,同時考慮命名和翻譯兩大問題。 后期修改：后期修改非常方便,當有靈感的時候修改 XML 文件就行,不用打開 IDE 重構(gòu)。 全球協(xié)作：由任何人提出 PR 隨時修改英文變量名,總有人能比你想到更好的,比如英文更好,或者就是剛好有靈感。 提升編程體驗：英文不熟練人,能很好的騰出工作記憶,在編程的時候,更好的專注于編程本身。 隱秘使用：如果周圍的環(huán)境對中文變量名不夠友好,可以自己用中文提交代碼的時候用英文。 全球化支持：同一段代碼不僅有中英雙語,其他國家的人只要是有這個意思,也可以快速的進行翻譯。GUI 軟件常常會支持好幾十個國家的語言,那么代碼也可以。
可能的實現(xiàn)途徑
JetBrains 系的 IDE,都有重構(gòu)的功能,調(diào)用重構(gòu)功能換變量名,應該就能實現(xiàn)。
代碼混淆器,好像會替換變量名而讓軟件功能保持不變,如果有開源的,應該可以利用。
注釋 1 ...
一個是 Leontiev 通過研究發(fā)現(xiàn),在進行外語交流時,有一個把母語思想用外語形式表達之前的一個“過渡階段”,在這個時候才用外語思維。其他時間一般都用母語思維。這也就是說,交流前的深度思維,或者“籌劃階段”,一般都是用母語思維的。但 Leontiev 研究的對象大部分都是使用“翻譯法”學外語的。那么他研究的這種存在“過渡階段”思維的對象,是否是因為用“翻譯法”學外語造成的呢？這一問題成為了 Loentiev 研究結(jié)論的致命傷。
另一個是 John-Steiner 提出的階段性和統(tǒng)一性的理論：外語初學者習慣用母語思維來幫助理解外語,當達到中級階段時,就會盡量避免依賴翻譯而直接使用外語思維來理解外語,但真正到了高級階段,大腦中的母語和外語形成的高度聯(lián)系統(tǒng)一的“語義”系統(tǒng),雙語者可以很自由隨意地使用兩種語言代碼。
研究表明,有經(jīng)驗的翻譯人員在翻譯工作中,已經(jīng)做到了可以表達超出單詞表面意思的直譯,達到深度含義的意譯的翻譯水平,指的就是這個高級階段。許多對雙語流利的人的研究也都顯示：在思考問題時,經(jīng)常會沒有意識到自己剛才到底在用哪種語言思維或可能兩種都使用了。
...
《找對英語學習方法的第一本書》
如果大多數(shù)英語不好的人都會用母語思維,然后再用翻譯形成英語,那么根據(jù)工作記憶有限的事實,直接用母語思考,有可能會減輕負擔,從而提高思考的質(zhì)量。
簡單的查了一下, Multilingual variable name ,和“多語言變量名”,好像沒有發(fā)現(xiàn)類似的項目,所以將這個靈感發(fā)出來,如果有精通寫 IDE 插件,這方面的人,也許會有點興趣吧。

市面上的找了幾個 APP 要么就是太細,要么就是生活記賬繁瑣,所以有了此貼。找一個 UI,一個 Flutter,暫時不需要后段。 感興趣的勾搭詳聊 。（是時候搞點事情了,奧力給?。?vx：d3g2MTAxNjI0NDA=

肯定有一些閑的蛋疼的缺少練手項目的人用來練手吧,也有一些人有好想法沒技術(shù)的吧。請問,開發(fā)這樣一個平臺會有什么問題？問題有沒有什么解決辦法？ 我能想到的就是曝光率不高,沒有人在上面提出想法,或者沒人做。 再或者,開發(fā)水平不夠,項目做一半跑路這樣。導致項目無限期延長,后來的重新造輪子這樣。 至于有沒有利益驅(qū)動,感覺如果摻雜錢,這東西就復雜了,而且不是一個合作的關(guān)系,就是一個雇傭的關(guān)系了,定位 就不一樣了吧。市面上也有很多豬八戒那樣的網(wǎng)站。 歡迎大家討論。

場景：你去采訪別人,問別人你的長相如何。
首先我們定義什么是“長相如何”。常見的有三種評價體系： 形容詞。帥、丑、一般……很顯然,信息量很低,沒什么區(qū)分度。 打分。信息量比 1 稍微高了些,但是一般來說這個分數(shù)是一個正態(tài)分布,絕大多數(shù)人可能擠在 4-6 分這個區(qū)間。（畢竟根據(jù)虎撲網(wǎng)友高圓圓才 7 分,狗頭）仍然存在區(qū)分度不夠的問題。 百分比,即“你比百分之幾的人好看”。這將 2 的正態(tài)分布替換為了均勻分布,區(qū)分度較高。
在這三種體系中,顯然 3 的區(qū)分度是最高的。
那么我們現(xiàn)在面臨的問題是： 讓受訪者給出這樣一個百分比,是很累的,因為受訪者需要遍歷 ta 所認識的人,才能得出你的百分比。因此對方很可能不愿意多想這給問題,或是敷衍你隨便給個數(shù)字,導致誤差很大。 你只發(fā)一張照片給受訪者,那么對方顯然就知道這是你本人的照片,所以得出的結(jié)論是有傾向性的——受訪者可能是一個對陌生人也很友好的人,也可能是一個對陌生人非?？瘫〉娜?
好了終于來到的本文的重點,我要說的方法是——
你把你想采訪的對象想象成一個比較器。你輸入兩張照片,一張是你的,一張是另一個人的,對方只需要輸出誰更好看就行了。 這種方法完美的解決了上面的兩個問題： 對于受訪者來說這是非常輕松的一件事情。 受訪者并不知道哪張照片是你的,可以認為沒有傾向性
采訪的對象可以在各種匿名交友 app 上找。

舉例：缺推廣運營。缺創(chuàng)意想法,缺技術(shù)能力,缺指引方向,缺后臺,缺前端,缺資源,缺渠道等等。
能夠勝任框架,能夠勝任服務器算法,能夠勝任業(yè)務邏輯,能夠勝任前端,能夠勝任后端,能夠勝任代碼邏輯架構(gòu)等等

就是打開 .vue 文件時, 可以把 template / script / style 拆成三個視圖https://imgur.com/rzgmAq7

1 、APP 叫鏟屎官,目前安卓版本已上線,OV 華米商店均可搜索下載,LOGO 是個紫色的爪子2 、iOS 版本正在開發(fā)中,預計國慶節(jié)左右上線 3 、目前是 3 人小團隊,都是利用業(yè)余時間在搞事情 4 、想尋一名后端開發(fā)加入小團隊 5 、要求每周能至少有 20 小時時間參與項目 6 、不是義務勞動 7 、我的 vx：mmirrors （加我請注明來自 V2EX ）

比如有一個 Form 組件,它需要所有子組件都有 name 字段

// 這里寫的時候會報錯,因為沒有 name 字段

還有就是 form 可以限制子組件參數(shù)的類型,比如： interface IUserSchema { username: string sex: 1 | 2 }

// 這里寫的時候會報錯,因為沒有 age 字段

注意,以上都需要在編譯階段就過不了 interface IProps { children?: // 這里的類型需要怎么寫才能實現(xiàn)上面的需求呢? } export const Form: FunctionComponent = ({ children }) => { return

{children}

}

Vue 的項目 github 上最受歡迎的有 vue-element-admin 方案和 vue-admin-template 模板,配備有作者的開源文檔和技術(shù)分享,方案生態(tài)都挺完善權(quán)威。 [其他的項目有 vuetify 、antd-vue 及 iview 也不錯。]
求推薦沒有類似的 React 生態(tài)的經(jīng)典開源項目,相關(guān)的方案、模板和設計哲學都可以,CRA 更偏向?qū)W習和初步的項目搭建。

gitbook 渲染成 html 或者 pdf 的時候,如果 code 段落太長,就會生成滑條。html 還好可以滑動,但是 pdf 滑條沒用,導致渲染不完全。我用對應的 pdf.css 修改了 code 段落自動換行不生成滑條也沒用,搞不定了,求救

自己嘗試著做一個前后端分離的小項目,前端 vuejs 后端 gin, 我之前一直以為前后端路由在服務器上面都開著然后進行訪問。最近試了下 vue.js 的部署,發(fā)現(xiàn) vuejs 直接打包過去不行,網(wǎng)上說是要 npm run build 打包成靜態(tài)網(wǎng)頁。 網(wǎng)上搜了一下,知乎上面有這個問題： https://www.zhihu.com/question/46630687
相關(guān)的是說要用 nginx 。
有沒有不用 nginx 的方法？

抽象了負載均衡的接口 實現(xiàn)了幾種負載均衡的算法,比如 wrr,p2c,aperture 等 測試覆蓋率 95%+
歡迎有興趣的朋友提交 pr 支持其他均衡算法的實現(xiàn) ：）
https://github.com/hnlq715/go-loadbalance

因為經(jīng)常使用終端,之前一直用偏右寫的 node 版本 的,學了點 golang,用 golang 來實現(xiàn)一下,練一下手,golang 的交叉編譯真的方便啊,寫點命令行工具也方便,不依賴環(huán)境,可執(zhí)行文件,跑起來就是爽。
mac 安裝體驗： brew install sakz/tap/fanyi
linux 安裝體驗： source <(curl -sL https://git.io/fanyi-install )
項目地址： https://github.com/sakz/fanyi

我看代碼時看到下面這段有點迷惑,隨便寫個 demotype X struct{ } 請問(*X)(nil)表示什么？ 我看了類型應該時 X 的指針,這個有什么用呢？

目前有這樣一個需求：通過配置文件,反射獲取目標的方法,但最多只能通過 reflect.ValueOf.MethodByName 或者 reflect.ValueOf.Method 得到一個 reflect.Value 類型,雖然直接調(diào)用.Call()能執(zhí)行此方法,但我想將 reflect.Value 類型轉(zhuǎn)為 func()類型,如 f := func; f() 這樣調(diào)用,而不是通過 reflect.Value.Call()調(diào)用。 先不討論為什么要如此放屁脫褲子多此一舉,就想問問大佬們,能轉(zhuǎn)成 func()類型嗎

func Test_TarsSelect(t *testing.T) { trueCount := 0 falseCount := 0 for i := 0; i < 100000; i++ { if TarsThread() { trueCount++ } else { falseCount++ } } fmt.Println("trueCount:", trueCount) fmt.Println("falseCount:", falseCount) } func TarsThread() bool { someChan := make(chan bool) var gotChan bool go SomeFunc(someChan) select { //10 毫秒超時 case <-time.After(10 * time.Millisecond): case gotChan = <-someChan: } return gotChan } func SomeFunc(someChan chan bool) { //休眠 10 微秒 time.Sleep(10 * time.Microsecond) select { case someChan <- true: default: } }
如上所示的代碼,在我這邊執(zhí)行 Test_TarsSelect 的結(jié)果是 === RUN Test_TarsSelect trueCount: 99961 falseCount: 39
一般情況下會認為應該全部為 true 。
如何解釋這種現(xiàn)象呢？ golang 中所有并發(fā)的程序的先后性都是不保證的嗎？
我認為解決辦法是 someChan 初始化時,可以修改為緩沖區(qū)長度為 1 。
另外一個同事認為是將 SomeFunc 中的 default 邏輯去掉,改成 case <- time.After(time.MillionSecond * 10) 。
二者都可以解決問題,你們推薦使用哪一種,或者有更合理的解決辦法嗎？

背景
公司線上有個 tomcat 服務,里面合并部署了大概 8 個微服務,之所以沒有像其他微服務那樣單獨部署,其目的是為了節(jié)約服務器資源,況且這 8 個服務是屬于邊緣服務,并發(fā)不高,就算宕機也不會影響核心業(yè)務。
因為并發(fā)不高,所以線上一共部署了 2 個 tomcat 進行負載均衡。
這個 tomcat 剛上生產(chǎn)線,運行挺平穩(wěn)。大概過了大概 1 天后,運維同事反映 2 個 tomcat 節(jié)點均掛了。無法接受新的請求了。CPU 飆升到 100%。
排查過程一
接手這個問題后。首先大致看了下當時的 JVM 監(jiān)控。
CPU 的確居高不下
FULL GC 從大概這個小時的 22 分開始,就開始頻繁的進行 FULL GC,一分鐘最高能進行 10 次 FULL GC
minor GC 每分鐘竟然接近 60 次,相當于每秒鐘都有 minor GC
從老年代的使用情況也反應了這一點
隨機對線上應用分析了線程的 cpu 占用情況,用 top -H -p pid 命令
可以看到前面 4 條線程,都占用了大量的 CPU 資源。隨即進行了 jstack,把線程棧信息拉下來,用前面 4 條線程的 ID 轉(zhuǎn)換 16 進制后進行搜索。發(fā)現(xiàn)并沒有找到相應的線程。所以判斷為不是應用線程導致的。
第一個結(jié)論
通過對當時 JVM 的的監(jiān)控情況,可以發(fā)現(xiàn)。這個小時的 22 分之前,系統(tǒng) 一直保持著一個比較穩(wěn)定的運行狀態(tài),堆的使用率不高,但是 22 分之后,年輕代大量的 minor gc 后,老年代在幾分鐘之內(nèi)被快速的填滿。導致了 FULL GC 。同時 FULL GC 不停的發(fā)生,導致了大量的 STW,CPU 被 FULL GC 線程占據(jù),出現(xiàn) CPU 飆高,應用線程由于 STW 再加上 CPU 過高,大量線程被阻塞。同時新的請求又不停的進來,最終 tomcat 的線程池被占滿,再也無法響應新的請求了。這個雪球終于還是滾大了。
分析完了案發(fā)現(xiàn)場。要解決的問題變成了：
是什么原因?qū)е吕夏甏豢焖俚奶顫M？
拉了下當時的 JVM 參數(shù) -Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms2048m -Xmx4096m -Xmn2048m -Xss512k -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:+DisableExx plicitGC -XX:MaxTenuringThreshold=5 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection
-XX:+PrintGCDetails -Xloggc:/data/logs/gc.log
總共 4 個 G 的堆,年輕代單獨給了 2 個 G,按照比率算,JVM 內(nèi)存各個區(qū)的分配情況如下：
所以開始懷疑是 JVM 參數(shù)設置的有問題導致的老年代被快速的占滿。
但是其實這參數(shù)已經(jīng)是之前優(yōu)化后的結(jié)果了,eden 區(qū)設置的挺大,大部分我們的方法產(chǎn)生的對象都是朝生夕死的對象,應該大部分都在年輕代會清理了。存活的對象才會進入 survivor 區(qū)。到達年齡或者觸發(fā)了進入老年代的條件后才會進入老年代?；旧侠夏甏锏膶ο蟠蟛糠謶撌且恢贝婊畹膶ο?。比如 static 修飾的對象啊,一直被引用的 緩存啊,spring 容器中的 bean 等等。
我看了下垃圾回收進入老年代的觸發(fā)條件后（關(guān)注公眾號后回復“JVM”獲取 JVM 內(nèi)存分配和回收機制的資料）,發(fā)現(xiàn)這個場景應該是屬于大對象直接進老年代的這種,也就是說年輕代進行 minor GC 后,存活的對象足夠大,不足以在 survivor 區(qū)域放下了,就直接進入老年代了。
但是一次 minor GC 應該超過 90%的對象都是無引用對象,只有少部分的對象才是存活的。而且這些個服務的并發(fā)一直不高,為什么一次 minor GC 后有那么大量的數(shù)據(jù)會存活呢。
隨即看了下當時的 jmap -histo 命令產(chǎn)生的文件
發(fā)現(xiàn) String 這個這個對象的示例竟然有 9000 多 w 個,占用堆超過 2G 。這肯定有問題。但是 tomcat 里有 8 個應用 ,不可能通過分析代碼來定位到。還是要從 JVM 入手來反推。
第二次結(jié)論
程序并發(fā)不高,但是在幾分鐘之內(nèi),在 eden 區(qū)產(chǎn)生了大量的對象,并且這些對象無法被 minor GC 回收 ,由于太大,觸發(fā)了大對象直接進老年代機制,老年代會迅速填滿,導致 FULL GC,和后面 CPU 的飆升,從而導致 tomcat 的宕機。
基本判斷是,JVM 參數(shù)應該沒有問題,很可能問題出在應用本身不斷產(chǎn)生無法被回收的對象上面。但是我暫時定位不到具體的代碼位置。
排查過程二
第二天,又看了下當時的 JVM 監(jiān)控,發(fā)現(xiàn)有這么一個監(jiān)控數(shù)據(jù)當時漏看了
這是 FULL GC 之后,老年代的使用率?？梢钥吹健ULL GC 后,老年代依然占據(jù) 80%多的空間。full gc 就根本清理不掉老年代的對象。這說明,老年代里的這些對象都是被程序引用著的。所以清理不掉。但是平穩(wěn)的時候,老年代一直維持著大概 300M 的堆。從這個小時的 22 分開始,之后就狂飆到接近 2G 。這肯定不正常。更加印證了我前面一個觀點。這是因為應用程序產(chǎn)生的無法回收的對象導致的。
但是當時我并沒有 dump 下來 jvm 的堆。所以只能等再次重現(xiàn)問題。
終于,在晚上 9 點多,這個問題又重現(xiàn)了,熟悉的配方,熟悉的味道。
直接 jmap -dump,經(jīng)過漫長的等待,產(chǎn)生了 4.2G 的一個堆快照文件 dump.hprof,經(jīng)過壓縮,得到一個 466M 的 tar.gz 文件
然后 download 到本地,解壓。
運行堆分析工具 JProfile,裝載這個 dump.hprof 文件。
然后查看堆當時的所有類占比大小的信息
發(fā)現(xiàn)導致堆溢出,就是這個 String 對象,和之前 Jmap 得出的結(jié)果一樣,超過了 2 個 G,并且無法被回收
隨即看大對象視圖,發(fā)現(xiàn)這些個 String 對象都是被 java.util.ArrayList 引用著的,也就是有一個 ArrayList 里,引用了超過 2G 的對象
然后查看引用的關(guān)系圖,往上溯源,源頭終于顯形：
這個 ArrayList 是被一個線程棧引用著,而這個線程棧信息里面,可以直接定位到相應的服務,相應的類。具體服務是 Media 這個微服務。
看來已經(jīng)要逼近真相了！
第三次結(jié)論
本次大量頻繁的 FULL GC 是因為應用程序產(chǎn)生了大量無法被回收的數(shù)據(jù),最終進入老年代,最終把老年代撐滿了導致的。具體的定位通過 JVM 的 dump 文件已經(jīng)分析出,指向了 Media 這個服務的 ImageCombineUtils.getComputedLines 這個方法,是什么會產(chǎn)生尚不知道,需要具體分析代碼。
最后
得知了具體的代碼位置, 直接進去看。經(jīng)過小伙伴提醒,發(fā)現(xiàn)這個代碼有一個問題。
這段代碼為一個拆詞方法,具體代碼就不貼了,里面有一個循環(huán),每一次循環(huán)會往一個 ArrayList 里加一個 String 對象,在循環(huán)的某一個階段,會重置循環(huán)計數(shù)器 i,在普通的參數(shù)下并沒有問題。但是某些特定的條件下。就會不停的重置循環(huán)計數(shù)器 i,導致一個死循環(huán)。
以下是模擬出來的結(jié)果,可以看到,才運行了一會,這個 ArrayList 就產(chǎn)生了 322w 個對象,且大部分 Stirng 對象都是空值。
至此,水落石出。
最終結(jié)論
因為 Media 這個微服務的程序在某一些特殊場景下的一段程序?qū)е铝怂姥h(huán),產(chǎn)生了一個超大的 ArrayList 。導致了年輕代的快速被填滿,然后觸發(fā)了大對象直接進老年代的機制,直接往老年代里面放。老年代被放滿之后。觸發(fā) FULL GC 。但是這些 ArrayList 被 GC ROOT 根引用著,無法回收。導致回收不掉。老年代依舊滿的,隨機馬上又觸發(fā) FULL GC 。同時因為老年代無法被回收,導致 minor GC 也沒法清理,不停的進行 minor GC 。大量 GC 導致 STW 和 CPU 飆升,導致應用線程卡頓,阻塞,直至最后整個服務無法接受請求。
關(guān)注作者
覺得有用的話,請關(guān)注下我的公眾號「元人部落」,作者堅持原創(chuàng)的內(nèi)容技術(shù)分享,也有開源作品,歡迎關(guān)注
開源倉庫為： https://gitee.com/bryan31
公眾號一般周更,每次會分享一些實用的技術(shù),陪你一起成長
關(guān)注后回復“資料”領(lǐng)取 50G 的視頻資料,包括一套企業(yè)級微服務的視頻教學

現(xiàn)在公司項目配置文件 properties 和 yaml 混用。 需要有個轉(zhuǎn)換工具統(tǒng)一轉(zhuǎn)換成 yaml,然后再合并。
求推薦？
不需要網(wǎng)頁在線轉(zhuǎn)換,會累死人,大幾十個文件。

logback 文件如下： %d{ISO8601} %highlight(%-5level) [%blue(%t)] %yellow(%C{1.} [%M#%L]) %X{serialID}: %msg%n%throwable ${LOGS}/info-file.log %d %highlight(%-5level) [%blue(%t)] %yellow(%C{1.} [%M#%L]) : %msg%n%throwable ${LOGS}/dex.log %d %highlight(%-5level) [%blue(%t)] %yellow(%C{1.} [%M#%L]) : %msg%n%throwable ${LOGS}/error.log %d %highlight(%-5level) [%blue(%t)] %yellow(%C{1.} [%M#%L]) : %msg%n%throwable
如果沒有添加
則 RollingFile 和 Console 的日志都能正常輸出,一旦加了這三行,那兩個也不輸出 ur.company 包下的日志了。

定義下 VPS 提供商： 提供虛擬機、VPC 、負載均衡器
提供監(jiān)控虛擬機狀態(tài)的 Web 面板
虛擬機以包月或包年方式計費,用戶自主申請實時開通
那么定義下“使用 VPS 的方式”： 計算負載直接運行在虛擬機上,或者運行在自部署的 K8s 集群中。 數(shù)據(jù)庫直接運行在虛擬機上 很少新建或刪除虛擬機,因為購買包年虛擬機需要走流程 除了 VPC 、負載均衡器、監(jiān)控之外,幾乎不使用其他云組件

服務性,消費性產(chǎn)品初期定位是：前置登陸模式
后期迭代增加了較多內(nèi)容資訊,為了轉(zhuǎn)換流量,改造為后置登陸模式,
平臺內(nèi)部有較多的支付場景：三方,虛擬幣,內(nèi)購（ Apple ）,
產(chǎn)品前期版本都能順利過審,但是近迭代 IOS 一直卡在無游客模式被拒絕,
大家的用戶賬戶體系都是怎樣設計游客模式的？

每個人都渴望成功,但成功并非易事。 成功案例對于一個渴望成功的人,是非常重要的。 每個人都需要一個榜樣。有時候,你發(fā)現(xiàn)自己已經(jīng)很努力了,但就是沒有成功。 為什么？ 因為你缺少一個人生路上的導師,缺少一個適合自己的榜樣。
你身邊一定有不少比較成功,值得你羨慕的人。但是你是否總結(jié)或者分析過他們是怎樣成功的嗎？
希望各位看官能不吝光陰,簡單分析分享下你身邊的那些成功案例。 煩請盡量把重要的時間節(jié)點和里程碑事件和關(guān)鍵信息寫進來。 （太籠統(tǒng)的可能對其他人意義不大,比如 xxx 做短視頻,或者 xxx 寫公眾號等,盡量附帶自己的分析）
希望此樓能蓋得很高,能給所有人帶來幫助。

小碼農(nóng),估計也沒啥希望分到上市公司的股票,但是出于好奇問問各位大佬,大公司上市前分給員工的股票,怎么變現(xiàn),是每年發(fā)一次,分幾年全部發(fā)完這種機制？分完之后就沒了,不會再增發(fā)這樣的？

Flink 的 ValueState 狀態(tài)保存時限是當前還沒有 checkpoint 的數(shù)據(jù)嗎？ 實測當 checkpoint 時間到了,此時程序重啟,那么 checkpoint 之前的數(shù)據(jù)是沒有 state 的,怎么把之前的 state 也找出來,有人知道嗎

一直在玩的游戲~號越買越多,奈何被限制三開,淘寶弄了個多開器,可試用倆小時,試了一下,檢查 ip 和電腦信息,奈何沒錢,每天走貓斷電+軟件修改電腦信息的路子,很麻煩,還得斷電。
倆問題,
1 有沒有軟件層面的可以直接修改 ip...網(wǎng)游加速器是你連接加速器的網(wǎng)絡再連游戲的網(wǎng)絡,這條路子有沒有可能走通。
2 如何學習逆向破解？有哪些資源呢？吾愛破解,看雪論壇？

就是多夢,睡覺喜歡動,手環(huán)監(jiān)測的深睡時間是 50 分鐘,淺睡 7 個小時,早上起來就很累

羅技新出的那個鍵盤套,帶觸摸板的,體驗不佳。觸摸板不跟手,比官方懸浮的差遠了。

一些無聊的事情已經(jīng)發(fā)生了兩次了,根源都是 VPS / VPN 在個人用戶之間的倒賣。為了杜絕這類毫無意義的事情在 V2EX 再次發(fā)生,我們現(xiàn)在確立一條新規(guī)則： - 請不要再在 V2EX 上發(fā)布任何 VPS / VPN 或者其他網(wǎng)絡服務賬號的個人交易 如果你需要買 VPS 或是其他網(wǎng)絡服務,請通過正規(guī)大廠（AWS,Linode,DO）的正規(guī)渠道購買,而不是從個人用戶那里購買。個人用戶之間的交易,你的賬號安全和服務的穩(wěn)定性,無法得到保證。 之后,任何這類的交易信息,將會被移動到 /go/closed -Livid 20140505

回復的內(nèi)容是給一個剛進入職場的安全工作者講解當前安全行業(yè)的趨勢,闡述了各個機關(guān)在安全方面的力度的加強,估計是因為提到了各個機關(guān)和相關(guān)法律,而被認為違規(guī)發(fā)言了。提交回復的時候出現(xiàn)了一個對話框,說是可以發(fā)郵件,但手賤把對話框點沒了,郵箱地址沒記住。。。 請審核解封,如果需要我發(fā)郵件申請的話,還請再告訴我一下郵箱地址吧。

微信 chen_yihuan 活有限,發(fā)帖后時間間隔較長就不用加了,除非你最物美價廉哈哈

之前公司比較安逸,感覺對未來發(fā)展不利換工作了 到了新公司 發(fā)現(xiàn)不想上班了 沒有動力 想辭職

那時我玩 360 同城幫,遇到一哥們重裝系統(tǒng)把朋友的資料覆蓋了。當時他沒說清楚覆蓋到哪了？我以為只是把引導扇區(qū)覆蓋了。 然后掛著磁盤掃描工具,說我還沒吃飯,去吃個飯。然后就找了家餃子店吃餃子去了。 我吃完一盤還不夠,我說能不能再來一盤,他說可以。邊吃邊聊,他問我會寫程序不,我說不會。聊得投機后,他說你要是會寫程序,帶我進他公司。當時自己也挺遺憾的。 后來回到他住處,發(fā)現(xiàn)原來他自己 ghost 一半才發(fā)現(xiàn)裝錯分區(qū)了。把系統(tǒng)寫到資料盤了。我說這我就沒轍了。找專業(yè)公司吧。他說沒事,自己跟朋友解釋。我就尷尬了。事沒辦好還白吃一頓。 我略表歉意的說把錢給他。他說不用,還互相留了聯(lián)系方式。 后面聯(lián)系不多,今天又是佳節(jié),恰巧吃了頓餃子就想起來了。又因為這里是程序員社區(qū),就想看看能不能在這遇到^_^

作為一個開發(fā)者,我試圖為做的小工具里加上廣告,來補貼服務器的費用
作為一個用戶,我試圖用 Adblock 、改 hosts 、代理軟件 REJECT 的方法屏蔽掉令我心煩的廣告
作為一個開發(fā)者,我嘗試對我的工具添加訂閱選項以維持我的更新熱情
作為一個用戶,我盡可能去尋找買斷的方法,甚至不惜改變習慣去尋找免費的替代品
作為一個開發(fā)者,我希望全世界的用戶都能理解開發(fā)不易,等價交換
作為一個用戶,我希望全世界的開發(fā)者都能用愛發(fā)電,造福大眾
考慮在 iPad 上使用 Clip Studio Paint 時有感。
（這款軟件在 PC/Mac 上買斷（ USD 50 ）,到 iPad 上訂閱（月付 USD4.5,年付 USD2/mo ）且對買斷用戶無優(yōu)惠政策）

時代的好人
猛然反應過來,竟然已經(jīng)八月了,而且眼看就要九月.就像少年時候在網(wǎng)吧沉迷游戲,總覺得沒打幾把時間就居然已經(jīng)過了這么久.
工作到了第五個 哦不,已經(jīng)第八個年頭了,我覺得我失去了時間.年少時的時間軸,在每個節(jié)點上都有對應的變化,新的年級新的老師新的同學,甚至新的女朋友都能讓人刻骨銘心,精確到分鐘的記憶,每一秒鐘的時間都是你的選擇,是你自己花出去的.而現(xiàn)在,時間基本上只能精確到月了;疫情之前,時間的結(jié)點在于每個小長假的旅行,年初的盼頭與年尾的回首,基本上被幾個假期和幾次旅行分開;而疫情之后,連這成年人的小小的盼望都幾乎不可能,真挺讓人絕望的.
那剩下的時間呢?對于開發(fā)而言,時間就是進度,時間節(jié)點就是功能點,度量的標準是版本號.精確到月份的時間感,基本上是因為開發(fā)的節(jié)奏就是這么定下來的...
除了時間,失去的還有情感.
我不是說我冷血,指的是"多余的情感".工作的日復一日的訓練是純粹理性的,感性思考約等于"無腦",那是產(chǎn)品經(jīng)理干的事兒.所以不得不收斂起玻璃心,小情緒,像機器一樣"精確",才能離大神越來越近.哦 想多了,能混過 35 歲就成.
互聯(lián)網(wǎng)上帶節(jié)奏的"大 V"也太多了,一件事兒反轉(zhuǎn)在反轉(zhuǎn)幾乎成了公理,情緒可以上當一次兩次,經(jīng)歷的多了,最垃圾的推薦算法都能學會了,誰還會浪費寶貴的"感情"呢?
一個人,失去了時間,又失去了情感,還剩下什么?哦,可能還剩下欲望了.
欲望這個事兒可太重要了.國家要發(fā)展,公司要業(yè)績,網(wǎng)站小編要 KPI,可全靠了欲望在支撐呢.你要被種草,要買買買,新開的網(wǎng)紅店還沒去?你也太 Old School 了,無聊.一幫欲求不滿的資本家誘惑另一波欲求不滿的產(chǎn)品經(jīng)理,想方設法榨干廣大群眾的欲望,更赤裸裸一點,收割注意力.從過去一頁五十個 Title 的文字論壇,到現(xiàn)在能一直向下滑到時間盡頭的小視頻,每一個細節(jié)都在引誘你縱欲,不停的縱欲才能滿足另一波人不斷膨脹的欲望.
更吊詭的是,越是禁欲的人,自制力強的人,才能夠走到頂端,做出更好的產(chǎn)品來讓人更好的縱欲.怎么聽著,都有點陰毛論的感覺呢.haha
所以,這就是時代對一個好人的全部要求了.

13 年本科畢業(yè)當兵去了,15 年才開始做開發(fā),比同學白白少了兩年經(jīng)驗
之前面的網(wǎng)易,就那么臨門一腳
一二三面面試的時的問題基本能答個七七八八
最后 hr 面簡單聊了也蠻多,比如之前在網(wǎng)易的外包經(jīng)歷,現(xiàn)公司的一些情況
等了一周多,給的答復是不符合社招的最低要求 3-3
收到結(jié)果的時候很難受,我目前 20k,就算從薪資角度我也不可能只有個 3-3
更何況去網(wǎng)易的面試部門是個清水衙門,就算是定級 3-3 給的薪資最多也只能有個 20k
思來想去就是學歷、年齡等硬條件了
哎,焦慮,煩躁

對我來說更喜歡 AM 、spotif （ y ）的訂閱模式,如果有喜歡的專輯就會找直郵、代購買實體。
國內(nèi)實體專輯市場連 3%都不到
數(shù)字專輯我也花了很多錢,綁定到平臺,無法下載讓我感覺 我花錢買了個東西,買回來發(fā)現(xiàn)是“出租”,而且可以隨時下架,就像在影碟店租光盤一樣。
這應該是發(fā)行公司要求的,但是這種模式是怎樣產(chǎn)生的？？??

對于我這種良好市民,zf 的唯一作用就是給我付養(yǎng)老金,公司的唯一作用就是幫我交養(yǎng)老金。賺大錢賺足錢自給自足給自己養(yǎng)老？不行：風險因素。個人創(chuàng)業(yè)是不行的,風險太大（更不要說出門被車撞殘這種天災,賺錢的機會都被天災剝奪了）,還是把養(yǎng)老金綁定在納稅人的身上是風險最低的。 https://www.v2ex.com/t/700129?p=2#r_9404039

也就是人們實際有需求的話,會到這個網(wǎng)站上提。供需雙方都可以受益,又不受什么合同的限制。
如果確實有這樣的網(wǎng)站,會遇到什么問題呢?
感覺確實是 有待驗證 ,但也確實是個 點子 啊

VEED 是一個視頻處理工具,你簡單把它想象成網(wǎng)頁版的愛剪輯就好了。這篇文章是 VEED 的創(chuàng)業(yè)經(jīng)歷,原載于他們的博客。倆創(chuàng)始人都是程序員,從一個很小的需求出發(fā),但真是把這工具做到了極致。
它的工具本身沒有太復雜,但是真正切中了一個需求 —— 用戶需要簡單的加字幕、裁剪視頻的工具,而 iMovies,FinalCut 之類太貴且難用。
12 個月的過程中,他們把 Veed 從完全沒人買,做到了 700 萬年復營收... 這篇文章完整記錄了他們從零開始,怎樣收上來第一筆收入（ 35 塊錢）,怎樣一步步一年后成為現(xiàn)在的樣子
我特意去他們推上要了個授權(quán),精翻過來就是想讓大家看到這樣的可能性。起個啟發(fā)作用吧。
不要再一談創(chuàng)業(yè)、互聯(lián)網(wǎng)就是融一千萬做個 APP 了,也許一些大家樂于付費的工具,也是條不錯的路子。我當然知道兩國情況不一樣,但國內(nèi)不也出了面包多,少數(shù)派之類非常棒的產(chǎn)品和團隊么,活得也挺自在的
文章原文請戳 => https://kalasearch.cn/blog/how-veed-achieve-1m-arr/

一、OceanBase 團隊介紹舊的回憶：崢嶸歲月 OceanBase 是由螞蟻金服 /阿里巴巴一群追求夢想追求極致的工程師實現(xiàn)的完全自主研發(fā)的金融級分布式關(guān)系數(shù)據(jù)庫,具備數(shù)據(jù)強一致、高可用、高性能、在線擴展、高度兼容 SQL 標準和主流關(guān)系數(shù)據(jù)庫、低成本等特點。十年來,OceanBase 已經(jīng)支撐了支付寶全部核心業(yè)務數(shù)據(jù)庫,順利承載了期間的雙十一的交易峰值,且在 2019 年業(yè)界公認的 TPC-C 性能評測中,成為第一個排名第一的分布式數(shù)據(jù)庫。 10 月 2 日,據(jù)權(quán)威機構(gòu)國際事務處理性能委員會（ TPC,Transaction Processing Performance Council ）官網(wǎng)披露,中國螞蟻金服自主研發(fā)的金融級分布式關(guān)系數(shù)據(jù)庫 OceanBase,在被譽為“數(shù)據(jù)庫領(lǐng)域世界杯”的 TPC-C 基準測試中,打破了由美國公司 Oracle （甲骨文）保持了 9 年之久的世界記錄,成為首個登頂該榜單的中國數(shù)據(jù)庫產(chǎn)品?！?https://www.zhihu.com/question/349100846 另外,OceanBase 也是個有故事也有愛的團隊,可以從 “支付寶背后的 OceanBase：國產(chǎn)自研分布式數(shù)據(jù)庫這十年 https://www.infoq.cn/article/O8xlkHWaXfYw_MjUyjbY 了解到在如今鮮亮業(yè)績的背后,十年來團隊對技術(shù)的追求和篤定,以及過程中的坎坷和堅韌。新的征程：十年一劍 數(shù)據(jù)庫是各行各業(yè)數(shù)字化轉(zhuǎn)型所需的核心基礎(chǔ)設施,如今 OceanBase 已經(jīng)走出阿里巴巴和螞蟻金服,服務域更廣大的市場,市場前景波瀾壯闊,我們剛剛邁出一小步,未來的征程是星辰大海。希望有技術(shù)熱情的你加入我們,共創(chuàng)數(shù)據(jù)庫產(chǎn)業(yè)的未來！ - 天時：OceanBase 是 100% 自研分布式國產(chǎn)數(shù)據(jù)庫,在國產(chǎn)化趨勢下具備廣闊前景 - 地利：OceanBase 經(jīng)過了十年的金融企業(yè)級穩(wěn)定性和擴展能力的考驗,包括螞蟻核心的交易支付系統(tǒng)數(shù)據(jù)量,和雙十一數(shù)據(jù)量 - 人和：OceanBase 有一支技術(shù)過硬的技術(shù)團隊和具備豐富經(jīng)驗的管理和產(chǎn)品團隊協(xié)同作戰(zhàn) 更多信息請看 OceanBase 官網(wǎng) https://www.oceanbase.com/ ?！?OceanBase：螞蟻爬上舞臺》 https://mp.weixin.qq.com/s/9EA_mHtkBpJ0prPK0hfgjA OceanBase 前端團隊介紹 舊的回憶：開放多元 OceanBase 前端團隊,負責 OceanBase 整體產(chǎn)品的前端方案設計和實現(xiàn),以及前端基礎(chǔ)框架和工程服務相關(guān)設計和實現(xiàn),包括但不限于 Ant Design 、AntV 、Umi 、Dva 、Egg 等開源項目的使用合作,以及 SQL 編輯器等前端重度產(chǎn)品方案研發(fā)實現(xiàn),和聯(lián)合產(chǎn)品團隊、運營團隊、研發(fā)團隊,尋找前端機會價值點對業(yè)務產(chǎn)生增值作用。 在過去的幾年,前端團隊不僅完成了專有云、公有云、客戶端多類型的業(yè)務支持,也在 SQL 編輯器等、圖形化等方面積累了許多經(jīng)驗。目前已經(jīng)有 web 版本 SQL 編輯器,SQL 控制臺等重型應用,和 OCP 等分布式運維管理應用。 新的征程：星辰大海 如今隨著 OceanBase 業(yè)務的對外和商業(yè)化,前端在商業(yè)化這個命題上會有更多的機會和挑戰(zhàn)。不同于常見的 web 應用,OceanBase 業(yè)務不僅面上覆蓋廣泛,也需要在點方面研究深挖,無論是面方面的公有云專有云多端方案部署的完善,重型數(shù)據(jù)庫管理 Web 應用,大量的可視化場景使用,還是在點方面的 SQL 編輯器的 OceanBase 方言,詞法語法特性完善底層研究合作,以及衍生的各層各角色的生態(tài)合作支持,整個面和點的衍生都是比較寬泛的,我們希望能滿足 OceanBase 業(yè)務支撐的前提下,對 SQL 編輯器,多云多端方案,分布式管理、可視化等多個命題攻堅協(xié)同,達到新的高度。 二、職位描述 1. 負責 OceanBase 整體產(chǎn)品的前端方案設計和實現(xiàn)。 2. 負責 OceanBase 前端基礎(chǔ)框架和工程服務相關(guān)設計和實現(xiàn),包括但不限于 Ant Design 、AntV 、Umi 、Dva 、Egg 等開源項目的使用合作,以及 SQL 編輯器等前端重度產(chǎn)品方案研發(fā)實現(xiàn)。 3. 聯(lián)合產(chǎn)品團隊、運營團隊、研發(fā)團隊,尋找前端機會價值點對業(yè)務產(chǎn)生增值作用。 三、職位要求 1. 熟練掌握 JavaScript 、HTML 、CSS 等原生前端基礎(chǔ)技術(shù),熟悉相關(guān)規(guī)范。 2. 熟練掌握 React / Vue / Angular 等常用前端框架以及配套社區(qū)項目（ redux / rxjs / …）。 3. 對前端工程化有一定理解,熟練掌握 Webpack / Grunt / Gulp 等構(gòu)建工具的使用和配置。 4. 了解不同瀏覽器平臺的特性,能夠很好地解決兼容問題,具備良好的 UI 交互實現(xiàn)能力。 5. 具備強烈的技術(shù)進取心,有良好的溝通與合作精神,擁有優(yōu)秀的問題分析及解決能力。 四、加分項 1. 有數(shù)據(jù)庫相關(guān)開發(fā)使用經(jīng)驗。 2. 同時具備 PC/無線 端的開發(fā)能力,有成功的中大型 Web 產(chǎn)品、移動應用開發(fā)經(jīng)驗。 3. 有服務端（ Node.js / Java / PHP / Python 等）相關(guān)開發(fā)經(jīng)驗。 4. 有大數(shù)據(jù)處理（ Hadoop / Hive / Spark / Impala 等）相關(guān)開發(fā)經(jīng)驗。 5. 有機器學習 /深度學習、自然語言處理等人工智能相關(guān)開發(fā)經(jīng)驗。 6. 有優(yōu)秀的獨立開源項目或深度參與過業(yè)界知名的開源項目。 五、劃重點 如今 OceanBase 已成立新公司（螞蟻全資子公司）,業(yè)務上以 OceanBase 為核心,包含數(shù)據(jù)庫管理及分布式管理相關(guān)內(nèi)容,技術(shù)和螞蟻金服保持合作關(guān)系,涉及編輯器、可視化、nodejs,工程化各方面的多方面共建。目前招兵買馬階段,在業(yè)務和技術(shù)上都有較大空間,歡迎咨詢~ 六、工作地 浙江杭州 七、聯(lián)系方式 郵箱： [email?protected] 微信：daolanx