Sphinx does indeed a very good job and is continuously improved. It is very fast and with small memory footprint.
We also built https://techusearch.com which uses Sphinx indexes (think of a SaaS version of Elasticsearch backed by Sphinx).
HN user
Senior Software Engineer - https://github.com/georgepsarakis/
Sphinx does indeed a very good job and is continuously improved. It is very fast and with small memory footprint.
We also built https://techusearch.com which uses Sphinx indexes (think of a SaaS version of Elasticsearch backed by Sphinx).
Interestingly enough, there is one unofficial API http://pygments.appspot.com/, but supports an outdated version (1.5).
Great work! Do you consider PyPy support also?
Sure you can :). Naturally transfers via SSH "suffer" from the encryption overhead but prevent MITM/network sniffing etc. The author points out that (only) in a trusted LAN you could use this solution to make things go faster.
I guess the title should be a little more mild - scp isn't going away, or rsync via SSH for that matter.
pigz does parallel compression, taking advantage of multiple cores. I am not really sure if you can achieve this with scp.
Thumbs up for pv which shows the progress bar. Using parallel compression may have serious impact on CPU resources, so it needs to be balanced.
Have you also done any testing with ssh + gzip?
Also, as you note at the end, the security concerns are not trivial.
Great read! An effort on a DSL using PLY (Python LEX-YACC implementation): https://github.com/georgepsarakis/quick-bash .
It is actually a transcompilation to Bash from a functional language, using Python for the intermediate processing.
Probably you can, if you implement upload callbacks which can be passed through the success_action_redirect parameter. Not sure though.
It says that it only stores metadata locally not objects themselves (although it could probably have an option for that too and serve as a general S3 cache).
Nice effort, Redis is perfectly fine but I believe that the storage layer should be somehow more separated in case someone wants another type of storage, e.g. in-memory SQLite is adequate and already installed in most systems.
Taking a quick look at the source code directory structure https://github.com/jquery/jquery/tree/master/src, I believe that you could create a minimal, customized build containing only features that you actually want. For example only element selection (which is very convenient and fast IMO) and AJAX.
CSS selectors are much easier to remember than XPath. Python's BeautifulSoup allows you to select elements with selectors and is very convenient. XPath is a bit more verbose and most people already are familiar with CSS syntax.
Nice post! You mentioned that you implemented this wrapper for backups. Apart from creating a virtual file system for sandboxing perhaps, isn't this generally slower? Maybe I am not getting the exact purpose of this task.
This app proves also very helpful if you use Nginx: https://github.com/andreiko/django_graceful
OK, thanks for answering!
Is this version compatible with 1.4.2 or will it require a full data dump/restore?
Nice analysis. Hope you don't mind me adding that by omitting terms of the Taylor series you do have some loss of precision, however small. Also, solving linear equation systems may even introduce instability as the following must be preserved: http://en.wikipedia.org/wiki/Diagonally_dominant_matrix
I suppose someone could incorporate a procedure which strips down unnecessary strings from code files ("minifies"), especially comment blocks, during the deployment process, thus maintaining a nice development codebase while not having questions over performance.
Yes, definitely breaking into smaller paragraphs will make it far more readable.
You could also consider Google AppEngine https://developers.google.com/appengine/docs/python/
Are you using MySQL in your example?
> id is an incremental value, I choose 11 as a length
for this primary key but this value is defined
by the number of pages you’ll need to index
This is a bit confusing. You'd generally be better off with INT UNSIGNED as it doubles the range for auto-increment columns.Also the visited field would be better to be represented by a timestamp, choosing the right datatype does matter in large tables.
Nice to know about the Dropbox integration. Really good work, keep it up!
Just to clarify: I am not the creator of this app, just came across it while searching how to create simple diagrams and thought it might be helpful sharing it.
Nice project. Considering a stream of tweets how can you find the beginning and the end of a sentence/message?
Are there any speed & size comparisons between Tny and JSON?
Nice effort. Just a few remarks:
- You should certainly use Requests http://docs.python-requests.org/en/latest/
- The Story class seems somewhat redundant. You could possibly use collections.namedtuple as a container for properties or simply a dictionary. The print_story method could just be the __str__ special method.
- JSON output would be useful.
Nice job. Another addition: Stripe Python API https://github.com/stripe/stripe-python . The documentation is on https://stripe.com/docs/api/python.
Much more time may be wasted if you end up hiring someone that doesn't fit the job description.
Minifying+concatenating is the most appealing solution for desktop browsers which employ a rather large cache on static files, considering that a web server is also fine-tuned to take advantage of caching (e.g. http://httpd.apache.org/docs/2.2/mod/mod_expires.html). I am not sure though that this is the best approach for mobile devices; having to serve a relatively large JS/CSS file with (possible) network interruptions may increase page load time.
I particularly focused on this section http://www.brokenthorn.com/Resources/OSDev18.html . Although not mandatory for development, having a grasp of these concept does give a better insight. Well done!
Seems like a nice idea, since it usually is a repetitive kind of task. May I ask why you chose Flask over Django?