英語罵人臟話技巧

臟話不能直譯,這是學習外語的一大原則。如果硬要直譯,那么說出來的就是不中不英,不倫不類的臟話。所以我們要做的,就是學懂在適當的時候說適當的臟話。

“操你媽”的英文怎樣說? Fuck your mother 可以嗎? 當然不可以。中英文截然不同,不可照字直譯。要說“操你媽”,簡單一句 Fuck you 便可。這不代表老外比我們厚道,而是英文里沒有 Fuck your mother,卻有 Motherfucker。不干人家的媽,卻叫人家干自己的媽,比中文的“操你媽”更加不堪入耳。

又如,“Son of a bitch“就是狗娘養的。而這只母狗,可以是世上任何一只,這就是語法上的概念“不指定”(indefinite)。所以不用“定冠詞”the,而用“不定冠詞”a。

由此看來,初學外語臟話,切忌自由創作。英文中的粗口大都約定俗成,來來去去幾十個說法,自由創作的空間不多。沒學好就亂用,肯定會貽笑大方。

罵人也可以用隱晦的詞語。有人覺得funk,shit太粗俗,但又想宣泄情感,就可以用“the F word“,“EFF“,“Frickin“等等替代。

Shit最常用的代替詞是crap。它可取代任何習語中的shit:

Shit!可說成 Crap! Bullshit可說成 Bullcrap等等。

而fuck最常用的代替詞是screw,它可取代任何習語中的fuck。

1 fuck的用法

Fuck一字的用法千變萬化,它集各種詞性于一身:即是動詞,也是名詞和感嘆詞;加上-ing更搖身一變成為百搭的形容詞和副詞。很多英文日常短語都可以用fucking加強語氣,例如:

Oh my God! 可說成 Oh my fucking God!

None of your business.可說成 None of your fucking business.

Holy shit! 可說成 Holy fucking shit!

fuck up:把事情弄得一團糟,把人弄得頭昏腦漲東西弄得一團糟。可以用委婉的screw up替代,更為文明的說法是mess up。

男人被女友甩后便一蹶不振,就可以說:The relationship totally fucked him up.

也可以用被動態表達:He was totally fucked up.

學生考試沒考好,可以說:I fucked up the exam.

把 fuck和up結合,組成了名詞fuckup。可以用此稱呼經常 fuck up 事情的人:He’s such a fuckup. He fucks up everything.

fuck off:滾開

piss off 和 bugger off也有這個意思,只不過fuck off更加粗俗,所以用時要特別小心。Fuck off的兩個字都是重音,全要重讀,清fuck重off,或是輕off重fuck都不能接受。

當某人面目可憎,又死皮賴臉地纏著你時,不妨請他:Fuck off!

fuck all:nothing

Fuck all是英國人的粗話,意思和nothing相同,是個代名詞(pronoun)。所有含nothing的句子都可用fuck all取代。例如:

1. I know nothing. 可說成 I know fuck all.

2. I did nothing today. 可說成 I did fuck all today.

3. I have nothing to say. 可說成 I have fuck all to say.

2 shit的用法

Shit是不可數名詞Uncountable,所以不能說a shit。講屎時,一個shit就足夠了。若真要指明某個單位或數量的屎,就要和其他uncountable nouns一樣,用量詞Quantifier。一條屎就是a piece of shit,一堆屎就是a pile of shit。

當然,shit除了“屎”的意思,也有“廢物”,“廢人”,“賤人”的意思。

例如,I almost stepped on a pile of dog shit!

字面意思就是:我差點就踩到了一堆狗屎。象征意思就是:He’s a piece of shit. 他是個廢物/賤人。

很多人只知道shit的感嘆詞用法,用以表達憤怒或不滿之情:“Shit!“。其實,shit還有不同的用法和組合。

Holy Shit

直譯是“神圣的屎”。當你發現了一些出人意料的事情,不論是喜是憂,都可以說Holy shit!

例如,驚喜是可以說:“Holy shit! I got an A for English!”

震驚的時候可以說:“Holy shit! I forgot to get my keys.”

如果覺得shit太粗俗,可以隱晦地說:“Holy cow!“,意思相同,卻避免了說臟話。

in deep shit:情況非常糟糕

非常形象的英語(Q吧)習語。試想深陷大便之中的情形,果真是糟糕至極。較文雅的替代說法是:in big trouble.

CSS布局的10點注意

  1. 檢查HTML元素是否有拼寫錯誤、是否忘記結束標記

  即使是老手也經常會弄錯div的嵌套關系。可以用dreamweaver的驗證功能檢查一下有無錯誤。

  2. 檢查CSS是否書寫正確

  檢查一下有無拼寫錯誤、是否忘記結尾的 } 等。可以利用CleanCSS來檢查 CSS的拼寫錯誤。CleanCSS本是為CSS減肥的工具,但也能檢查出拼寫錯誤。

  3. 用刪除法確定錯誤發生的位置

  如果錯誤影響了整體布局,則可以逐個刪除div塊,直到刪除某個div塊后顯示恢復正常,即可確定錯誤發生的位置。

  4. 利用border屬性確定出錯元素的布局特性

  使用float屬性布局一不小心就會出錯。這時為元素添加border屬性確定元素邊界,錯誤原因即水落石出。

  5. float元素的父元素不能指定clear屬性

  MacIE下如果對float的元素的父元素使用clear屬性,周圍的float元素布局就會混亂。這是MacIE的著名的bug,倘若不知道就會走彎路。

  6. float元素務必指定width屬性

  很多瀏覽器在顯示未指定width的float元素時會有bug。所以不管float元素的內容如何,一定要為其指定width屬性。

  另外指定元素時盡量使用em而不是px做單位。

  7. float元素不能指定margin和padding等屬性

  IE在顯示指定了margin和padding的float元素時有bug。因此不要對float元素指定margin和padding屬性 (可以在float元素內部嵌套一個div來設置margin和padding)。也可以使用hack方法為IE指定特別的值。

  8. float元素的寬度之和要小于100%

  如果float元素的寬度之和正好是100%,某些古老的瀏覽器將不能正常顯示。因此請保證寬度之和小于99%。

  9. 是否重設了默認的樣式?

  某些屬性如margin、padding等,不同瀏覽器會有不同的解釋。因此最好在開發前首先將全體的margin、padding設置為0、列表樣式設置為none等。

  10. 是否忘記了寫DTD?

  如果無論怎樣調整不同瀏覽器顯示結果還是不一樣,那么可以檢查一下頁面開頭是不是忘了寫下面這行DTD:http://www.w3.org /TR/html4/loose.dtd”>

Facebook如何管理150億張照片[轉]

Facebook 的照片分享很受歡迎,迄今,Facebook 用戶已經上傳了150億張照片,加上縮略圖,總容量超過1.5PB,而每周新增的照片為2億2000萬張,約25TB,高期,Facebook 每秒處理55萬張照片,這些數字讓如何管理這些數據成為一個巨大的挑戰。本文由 Facebook 工程師撰寫,講述了他們是如何管理這些照片的。原文:http://www.javaeye.com/news/7267-facebook-how-to-manage-the-15-billion-photos

舊的 NFS 照片架構

老的照片系統架構分以下幾個層:
上傳層接收用戶上傳的照片并保存在 NFS 存儲層。
照片服務層接收 HTTP 請求并從 NFS 存儲層輸出照片。
NFS存儲層建立在商業存儲系統之上。

因為每張照片都以文件形式單獨存儲,這樣龐大的照片量導致非常龐大的元數據規模,超過了 NFS 存儲層的緩存上限,導致每次招聘請求會上傳都包含多次I/O操作。龐大的元數據成為整個照片架構的瓶頸。這就是為什么 Facebook 主要依賴 CDN 的原因。為了解決這些問題,他們做了兩項優化:
Cachr: 一個緩存服務器,緩存 Facebook 的小尺寸用戶資料照片。
NFS文件句柄緩存:部署在照片輸出層,以降低 NFS 存儲層的元數據開銷。
新的 Haystack 照片架構

新的照片架構將輸出層和存儲層合并為一個物理層,建立在一個基于 HTTP 的照片服務器上,照片存儲在一個叫做 haystack 的對象庫,以消除照片讀取操作中不必要的元數據開銷。新架構中,I/O 操作只針對真正的照片數據(而不是文件系統元數據)。

haystack 可以細分為以下幾個功能層:
HTTP 服務器
照片存儲
Haystack 對象存儲
文件系統
存儲空間
存儲

Haystack 部署在商業存儲刀片服務器上,典型配置為一個2U的服務器,包含:
兩個4核CPU
16GB – 32GB 內存
硬件 RAID,含256-512M NVRAM 高速緩存
超過12個1TB SATA 硬盤

每個刀片服務器提供大約10TB的存儲能力,使用了硬件 RAID-6, RAID 6在保持低成本的基礎上實現了很好的性能和冗余。不佳的寫性能可以通過高速緩存解決,硬盤緩存被禁用以防止斷電損失。
文件系統

Haystack 對象庫是建立在10TB容量的單一文件系統之上。文件系統中的每個文件都在一張區塊表中對應具體的物理位置,目前使用的文件系統為 XFS。
Haystack 對象庫

Haystack 是一個簡單的日志結構,存儲著其內部數據對象的指針。一個 Haystack 包括兩個文件,包括指針和索引文件:

Haystack 對象存儲結構

指針和索引文件結構

Haystack 寫操作

Haystack 寫操作同步將指針追加到 haystack 存儲文件,當指針積累到一定程度,就會生成索引寫到索引文件。為了降低硬件故障帶來的損失,索引文件還會定期寫道存儲空間中。
Haystack 讀操作

傳到 haystack 讀操作的參數包括指針的偏移量,key,代用Key,Cookie 以及數據尺寸。Haystack 于是根據數據尺寸從文件中讀取整個指針。
Haystack 刪除操作

刪除比較簡單,只是在 Haystack 存儲的指針上設置一個已刪除標志。已經刪除的指針和索引的空間并不回收。
照片存儲服務器

照片存儲服務器負責接受 HTTP 請求,并轉換成相應的 Haystack 操作。為了降低I/O操作,該服務器維護著全部 Haystack 中文件索引的緩存。服務器啟動時,系統就會將這些索引讀到緩存中。由于每個節點都有數百萬張照片,必須保證索引的容量不會超過服務器的物理內存。

對于用戶上傳的圖片,系統分配一個64位的獨立ID,照片接著被縮放成4種不同尺寸,每種尺寸的圖擁有相同的隨機 Cookie 和 ID,圖片尺寸描述(大,中,小,縮略圖)被存在代用key 中。接著上傳服務器通知照片存儲服務器將這些資料聯通圖片存儲到 haystack 中。

每張圖片的索引緩存包含以下數據

Haystack 使用 Google 的開源 sparse hash data 結構以保證內存中的索引緩存盡可能小。
照片存儲的寫/修改操作

寫操作將照片數據寫到 Haystack 存儲并更新內存中的索引。如果索引中已經包含相同的 Key,說明是修改操作。
照片存儲的讀操作

傳遞到 Haystack 的參數包括 Haystack ID,照片的 Key, 尺寸以及 Cookie,服務器從緩存中查找并到 Haystack 中讀取真正的數據。
照片存儲的刪除操作

通知 Haystack 執行刪除操作之后,內存中的索引緩存會被更新,將便宜量設置為0,表示照片已被刪除。
重新捆扎

重新捆扎會復制并建立新的 Haystack,期間,略過那些已經刪除的照片的數據,并重新建立內存中的索引緩存。
HTTP 服務器

Http 框架使用的是簡單的 evhttp 服務器。使用多線程,每個線程都可以單獨處理一個 HTTP 請求。
結束語

Haystack 是一個基于 HTTP 的對象存儲,包含指向實體數據的指針,該架構消除了文件系統元數據的開銷,并實現將全部索引直接存儲到緩存,以最小的 I/O 操作實現對照片的存儲和讀取。

圖片服務器[轉]

現在很多中小網站(尤其是 Web 2.0 站點) 都允許用戶上傳圖片,如果前期沒有很好的規劃,那么隨著圖片文件的增多,無論是管理還是性能上都帶來很多問題。就自己的一點理解,拋磚引玉,以期能引出更具價值的信息。 原文:http://androider.javaeye.com/blog/232434

事關圖片的存儲
把圖片存儲到什么介質上? 如果有足夠的資金購買專用的圖片服務器硬件或者 NAS 設備,那么簡單的很;如果有能力自己開發單獨存儲圖片的文件系統,那么也不用接著往下看了。

如果上述條件不具備,只想在普通的硬盤上存儲,首先還是要考慮一下物理硬盤的實際處理能力。是 7200 轉的還是 15000 轉的,實際表現差別就很大。是選擇 ReiserFS 還是 Ext3 ,怎么也要測試一下吧? 創建文件系統的時候 Inode 問題也要加以考慮,選擇合適大小的 inode size ,在空間和速度上做取舍,同時防患于未然,注意單個文件系統下文件個數別達到極限。

獨立,獨立的服務器
無論從管理上,還是從性能上看,只要有可能,盡量部署獨立的圖片服務器。這幾乎成為常識了(不過在我做過面向 Web 的項目之前就這個問題也被人笑話過)。具備獨立的圖片服務器或者服務器集群后,在 Web 服務器上就可以有針對性的進行配置優化。比如采用傳說中更有效率的 Lighttpd 。

如果不想在幾臺機器間同步所有圖片,只用 NFS 模式共享一下即可。注意軟、硬連接可能帶來的問題,以及 NFS 特定的傳輸速度。

獨立,獨立的域名
如果大部分 Web 頁面必須要載入很多圖片,那么需要注意 IE 瀏覽器的連接數問題(參見對該問題的測試)。

前幾天有個朋友在線上問我,“一些大網站,圖片服務器為什么都用另外一個域名? 比如yahoo.com 圖片服務器用了 yimg.com 的域名?” ,粗糙一點的答案:除了管理方便,便于CDN 同步處理,上面說的 IE 連接數限制也是個考慮因素吧(其他原因我也不知,有請 Yahoo!的同學發言)

雅虎 Web 優化 14 條
關于雅虎 YSlow 工具倡導的 優化 14 條規則,建議每個 Web 維護人員必須倒背如流,當然也應該辯證來看—介紹這 14 條規則的頁面本身也只能得到 70 多分…其中的第九條和上面說的獨立域名之間多少有些矛盾。實際情況要根據自己的 Benchmark 與具體需求而確定了。

有效利用客戶端 Cache
很多網站的 UI 設計人員為了達到某些視覺效果,會在一些用戶需要頻繁訪問的頁面模塊上應用大量的圖片。這樣的情況,研究表明,對于用戶粘度比較高的站點, 在Web 服務器上對這一類對象設置 Expires Header 就是十分有必要的,大量帶寬就這么節省下來,費用也節省了下來。順便說一下,對于驗證碼這樣的東西,要加個簡單的規則過濾掉。

服務器端的 Cache
在國內,CDN 也是有錢才能玩得起。而類似 Amazon S3 這樣的一攬子存儲服務,國內還沒有出現。所以,充分利用服務器端的 Cache 也是有必要的。Squid 作為反向代理服務器,緩沖圖片效果應該說尚可,新浪技術團隊貢獻的 Ncache 據評測,效果更佳。

高解析圖片問題
如果網站存在大量高解析度的圖片,那么有必要考慮部署 IIPImage 或者類似的軟件。

運營問題
很多比較有規模的網站對于用戶上傳的圖片不做任何處理,結果頁面上還能看到很多 BMP 格式的圖片(個人覺得任何網站出現 BMP 格式的圖片都是可恥的)…這完全是運營上的策略之誤了。找個程序員投入一點時間寫個圖片處理模塊,對那些“截屏“得來的圖片做個轉換,投入成本可能遠比存儲上的開銷小,而用戶再訪問該圖片,質量未必能有什么損失,瀏覽速度無疑好多了。哪種處理方式更讓人接受,不言而喻。

我的想法:現在談后面的圖片服務器之類的都是遙遠的事情,但是從獨立域名來講,還不是很明白為什么能減少IE的連接數,看樣子需要研究一下子,在者,當前可以做的事情,就是客戶端cache和服務器端cache以及通過一些程序手段減少連接數。但是bmp的問題,確實不知道。看樣子需要注意的。

但是現在面對具體的設計問題,卻很棘手,我察看了sina,sohu等網站,他們基本上使用的是靜態文本加上將圖片存儲到文本相同目錄這種方式,對于后臺是否進行了數據庫關聯,不得而知,但是從顯示的角度,最起碼這種方式確實是最快的。但是我們是屬于交互式網站,對于信息的交互要求很高,所以這種門戶類型是不適合我們的,因為我們不可能讓每個文章以及對應的回復都產生一個靜態文件,畢竟這個時間很長,用戶根本無法忍受。xici同樣也是采用sina,sohu門戶的做法,但是他對于用戶圖片上傳的地方所做的工作挺好的。他是啟用單獨的子域名來存儲圖片,但是子域名后面的地址是一樣的,問題是,不管是回復還是主貼,他都是最終一個靜態文件,疑惑的就是難道他每一次回復或者發帖都是生成或者從新生成一個靜態文件,亦或者采用模板技術?不知道。

網站排名算法小總結

1.每個網頁標題簡潔,不超過30字。
2.每個網頁核心關鍵詞不超過3個。如果可以,你要學會放棄。
3.最重要的關鍵詞放在標題首位,依次類推。
4.網站的描述,簡潔,明了,最開始和結束部分自然出現關鍵詞。
5.網站導航采用文字導航。
6.網站圖片原創,添加alt標簽,切忌諱亂加。搜索引擎能讀懂圖片。
7.與主題無關內容作成JS或者圖片。
8.網站內容簡潔,信息豐厚。關鍵詞分布其中合理,自然。如果你自己都讀不懂,那就放棄。
9.網站聯系人信息要原創,比如郵箱,電話,姓名等。
10.網站代碼簡潔。
11.與主題相關的JS,框架,做兼容優化。
12.網站設計大方,美觀。
13.網站域名時間超過2年以上,最好是3年。
14.域名最好出行最核心關鍵詞,針對除百度以外搜索引擎有效。
15.如果新域名,聯系人信息一定要公布,切為新信息。
16.空間要穩定,那種經常網站打不開的網站,肯定沒有排名。
17.友情鏈接要找外地的網站。
18.友情鏈接不看PR,看快照,看核心關鍵詞排名,看SITE首頁是否存在。
19.網站外鏈要豐富,新聞類的,行業類的,生活類的,公關類的,越豐厚越好。
20.網站外鏈不在數量,在質量。增加要掌握好節奏。
21.網站外鏈要出現網址,占70%,錨文本要適當。原因自己去想。
22.網站外鏈要首先提高首頁權重,首頁快照在7天內,核心關鍵詞在前3頁,則網站權重及格。
23.網站外鏈要出現在流行度較高的地方。
24.網站外鏈出現的地方,切忌垃圾鏈接,鏈接過多。
25.網站添加流量統計,大概數據要公開。
26.適當刷網站IP和來路,切忌網站流量來自某一個搜索引擎。
27.網站內容要圍繞主題展開。切忌發布無關內容。
28.網站添加XML和HTML格式地圖,有助于各大搜索引擎收錄抓取。
29.網站按規律更新,切忌一個不更新,或者一下更新上百篇。
30.分布好網站內鏈接。核心關鍵詞指向核心關鍵詞頁面。
31.網頁內容中出現關鍵詞加粗效果并不好,避免全加粗加鏈接。
32.每個頁面最好出現一次H標簽,此內容和網友標題一致。
33.網站404頁面。
34.與主題無關頁面,運用Robots.txt禁止。
35.制造網站主題相關的PDF,doc,exe等文檔和軟件提供下載。在這些資源上寫上自己的網站。
36.網站最開始內容,最好一次性完成,切忌收錄后經常更改。
37.網站頁面切忌經常更改主題,和關鍵詞密度,95%被K都是這個原因。
38.網站外鏈切忌同一個賬號,同一個名字去發布。比如博客,全是同一個人的博客。論壇全是同一個賬號。
39.這些工作做完了,你需要等待!一邊持續更新,維持,添加外鏈和內鏈。
40.還是等待,直到網站排名出現。

最好總結5個字:靜,全,真,細,得!