Awesome PHP has been relocated permanently to its own Github repository. No further updates will made to this gist.
Please open an issue for any new suggestions.
Awesome PHP has been relocated permanently to its own Github repository. No further updates will made to this gist.
Please open an issue for any new suggestions.
This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array
it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array
part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
1. The texture target needs to be GLES20.GL_TEXTURE_EXTERNAL_OES instead of GL_TEXTURE_2D, e.g. in the glBindTexture calls and glTexParameteri calls. | |
2. In the fragment shader define a requirement to use the extension: | |
#extension GL_OES_EGL_image_external : require | |
3. For the texture sampler used in the fragment shader, use samplerExternalOES instead of sampler2D. | |
Everything below here is all in the C code, no more Java. | |
4. In the C code, use glEGLImageTargetTexture2DOES(GL_TEXTURE_EXTERNAL_OES, eglImage) to specify where the data is, instead of using glTexImage2D family of functions. |
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.
This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.
There is a companion feature matrix of various tools. Comments are welcome in the same manner.
由於原本 Pro Git zh-tw 翻譯社群共筆的服務 hackpad 已經停止運作,並被移植到 Dropbox Paper。為了有利於本份資料在社群共享、傳播,故將其從 Dropbox Paper 輸出,並存在 Gist 備存。
相關議題可以參照 progit/progit2-zh-tw 的 #38、#39
很慶幸的,有各位熱心的夥伴參與翻譯,其實就算是單人翻譯的狀況,常常會發生有些專有名詞或者是格式上前後不一的狀況。所以開了一個 pad 專門記錄這些規範以及參考的翻譯對照表。有些是我個人的一些想法,如果夥伴們有其他的意見跟想法歡迎提出來討論。 關於專有名詞翻譯的部分,我能理解部分夥伴會覺得就保留英文即可,但我會希望文件也類似於中文翻譯書般,第一次出現時我們可以以 專有名詞中文翻譯 (英文原文)的呈現方式來表示,讓讀者可以產生中英關聯,之後同份文件再次出現將只會出現中文翻譯。這樣做是因為對於初學者來說不會因為滿滿的英文專有名詞而產生抗拒。當然前提是在於中文的翻譯是否能夠達意,這部分建議參考對岸的一些翻譯,有時候比我們Pro Git的還直觀。但對於像 Laravel, Composer 等是名字、指令等就不強求要中文對照,這類不會有統一翻法更不容易從翻譯中知道用意的,就保留英文即可。如果不清楚該怎麼翻才好也可以留著與大家討論。