基本的要求是对给定的一个文本块进行关键字匹配,进行匹配的关键字是多个,而且可能非常多(成千上万),然后输出各个匹配到的关键字的位置。这可用用作关键字的高亮显示,当然也可用进行敏感词过滤。
参考linux命令行fgrep
输入一段文本,输出匹配到的关键字在输入文本中的位置。
例如,关键词列表:
<nav class='paginator' role='toolbar'> | |
<ul class='goto-pages'> | |
<li class='goto-search'> | |
<a href="#search" class="search-pages" title="Toggle Advanced Search">⌕</a> | |
</li> | |
<li class='goto-page'> | |
<a href="/admin/users?page=1" aria-disabled="true" class="first-page disabled" data-page="1" rel="first" title="Go to the first page">⇤</a> | |
</li> | |
<li class='goto-page'> | |
<a href="/admin/users?page=1" aria-disabled="true" class="prev-page disabled" data-page="1" rel="prev" title="Go to page 1">⇠</a> |
Original transcript: http://allisonrandal.com/2012/04/15/open-source-enlightenment/
這幾年來,我慢慢覺得,我們參與開源社群,就像是在一條道路上並肩而行:這不僅讓我們成為更好的程式設計者,也讓我們通過與人合作,而成為更好的人。
您可以將它想成一條修行之道,讓身而為人的我們能夠不斷成長。接下來,我想談談我對開源世界的個人觀點,希望能與您分享。
首先,人是一切開源專案的核心。程式碼是很重要,但最核心的永遠是人。
The list would not be updated for now. Don't write comments.
The count of contributions (summary of Pull Requests, opened issues and commits) to public repos at GitHub.com from Wed, 21 Sep 2022 till Thu, 21 Sep 2023.
Because of GitHub search limitations, only 1000 first users according to amount of followers are included. If you are not in the list you don't have enough followers. See raw data and source code. Algorithm in pseudocode:
githubUsers
jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.
When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).
If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.
If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate
This is just a quick response to http://me.veekun.com/blog/2012/07/28/quick-doesnt-mean-dirty/. I won't bother to write a proper blog post for this, so a Gist will have to do ;)
When I read that article, one thing really striked me: If you want to quickly create a web app in PHP, you do exactly the same. I mean, exactly.
I never used the Silex microframework before, so I took this as a chance to see how it works. I'll just do the same as eevee did, only with a bit less commentary (this is a Gist after all!)
I hope that this will show you that PHP and Python are really similar to work with. Also this should show that just because you're using PHP, doesn't mean that you write dirty code. The similarity in the process and code is really incredible :)
先前在《開源應用程式架構》 一書中,我介紹了 SocialCalc 這個在瀏覽器中運行的試算表編輯器,以取代伺服器為中心的 WikiCalc 架構。SocialCalc 在瀏覽器中執行所有的運算,只有在載入和儲存試算表時才會使用伺服器。
追求效能是 Socialtext 團隊在 2006 年時設計 SocialCalc 的主要目的。重點在於:在 JavaScript 環境下執行客戶端運算,儘管在當年的速度僅有伺服器端 Perl 運算的十分之一,但仍然勝過 AJAX 來回傳輸資料造成的網路延遲:
#!/usr/bin/env lsc | |
# 使用前請先 curl -O http://cpansearch.perl.org/src/DANKOGAI/Unicode-Unihan-0.04/srctxt/Mandarin.txt | |
require! fs | |
c2p = {}; p2c = {} | |
for l in "#{fs.read-file-sync 'Mandarin.txt'}" / /\n/ | |
[code, pin] = l / /\s+/ | |
continue unless code is /^....$/ # BMP |
09:07 -!- Irssi: Join to #webconf.tw was synced in 133 secs | |
09:08 < MouseMs> 大家早安 | |
09:08 < locy69> 早安 | |
09:09 < StarNight> 早安!~ | |
09:10 < MouseMs> [SITCON] 答案填寫單將於9:30開放submit答案 PS:同時也會開放第五題唷 今天的題目都比較簡單 歡迎大家挑戰:) | |
09:13 < bency> 早安 | |
09:13 < BeataLin> 早安! | |
09:21 < SITCON> 今天也有3題等著大家挑戰唷^^ | |
09:23 < kikiqqp_> 今天R0的有線網路有點怪怪的 | |
09:25 < ChAndrew> Good Morning!! |
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: