Very nice! It seems about as simple as it could be. One suggestion though, my resolution is quite high and I hate looking to the extremities of my monitor. I don't know how you could solve it nicely but just some feedback!
There's just one little glitch : In IE9, icons are not shown correctly and a javascript error is raised whenever you try to perform an action , or visit a url you just "generated"
Very cool! You've easily written the best UI for this kind of thing I've yet seen (though a language syntax picker would be nice).
Quick question though, why redis vs something disk based? Are you worried that if this sees a lot of usage you'll hit memory limits? Seems like a great application for a disk based KV, or just plain SQL.
You can set the language by just changing the extension in the URL, if it guesses wrong.
the open source project also has an optional disk store you can use in place of redis (http://github.com/seejohnrun/haste-server), but my hosted version uses the redis store.
I haven't tried reproducing this, but it sounds like he's setting redirects based on GETs. A bad idea all-around, and not only for breaking the back button in this case.
There's no affordance suggesting what to do. If I start typing, I only get two lines of visible text. If I enter more than two lines, the top line(s) scrolls out of view. this doesn't seem to be intended behavior given all the "white" space on the page. When saved, a multi-line bin seems to work normally.
In a quick check, it seems all resources are loading. Safari 5.1.1; OS X 10.7.2. (Tried with extensions, e.g., AdBlock, off too.)
definitely a good idea, i'll try to think of a way to add it but keep the minimalist approach. I'll file a ticket on github for this and get to it very soon
In chromium on linux, I can only ever see two lines of text at a time. If I type more than two lines, they scroll off the top of the screen. When I move back up with the arrow keys, I can see those lines again, but I still only see two lines; those further below just disappear until I move back down.
For some reason, node.js programmers are better than average designers, so their websites look slick - but that has nothing to do with running the website on node.js...
Okay, they know javascript, that helps...
But it makes node.js feel slick... a great marketing trick.
The syntax highlighting will be constantly improving given changes to highlight.js (another OSS project), and a possible move to pylons. Thanks for the feedback, and I'll take a look at the Java highlighter and see what I can do to make it better. Any obvious things you'd like to see in the highlighting?
Since the author is using Redis for a system like that, I wanted to do some math about how many documents it can store for gigabyte.
Assuming a 64 bit instance (that is more memory hungry) and that the average paste size is 512 bytes, every 2 million documents require 1GB (just tested with redis-benchmark).
This means that if you have a paste every minute, in order to use 1 GB of memory you need to wait 4 years.
Many problems that at a first look appear to be hard to treat with an in-memory DB at a closer look appear quite addressable.
That said this is the kind of problem where the working set is very small compared to the whole set of documents stored, and where documents are rarely written and often accessed in a read only fashion, so a *SQL DB would work super well for that use case.
I Redis server could form a very good addition in order to perform real time stats about the accesses to the document: number of times the document was read, a sorted set for latest created documents, top documents for this month by page views, and so forth.
I think it would be a really interesting project to get together a way to gather statistics like this. I'm particularly interested in seeing things like average reads per doc, interval between reads, etc (like you mention).
Thanks for the research, and look forward to more coming out in the way of statistics soon!
More related to the central topic of redis as a store for this, I think it really depends on the read per write ratio. Gathering stats like this would be very useful, and its very easy to write a SQL adapter for haste-server, since its just a set/get and optional expire
In theory in a pastebin-alike site you can have a lot of writes for the analytics. think about a pastebin page appearing on HN or other very busy site, if you want to do real time stats Redis will handle the load without issues.
What about a Redis feature where you could mark a key as swappable? Hot keys could stay in memory, cold keys could stay on disk. This would work great with append-only mode, in essence like BitCask.
70 comments
[ 3.0 ms ] story [ 89.3 ms ] threadmore info: http://hastebin.com/about.md
There's just one little glitch : In IE9, icons are not shown correctly and a javascript error is raised whenever you try to perform an action , or visit a url you just "generated"
Quick question though, why redis vs something disk based? Are you worried that if this sees a lot of usage you'll hit memory limits? Seems like a great application for a disk based KV, or just plain SQL.
You can set the language by just changing the extension in the URL, if it guesses wrong.
the open source project also has an optional disk store you can use in place of redis (http://github.com/seejohnrun/haste-server), but my hosted version uses the redis store.
Thanks again!
Also, while I am entering a file, the edit box is only two lines long, and I can't see the handle to resize it. This is Safari 5.1.1 on Snow Leopard.
Looks nice!
will be fixed tonight
However, when I type/paste i can see only the last line of text, it's somehow confusing. Why not to make textarea take whole height?
There's no affordance suggesting what to do. If I start typing, I only get two lines of visible text. If I enter more than two lines, the top line(s) scrolls out of view. this doesn't seem to be intended behavior given all the "white" space on the page. When saved, a multi-line bin seems to work normally.
In a quick check, it seems all resources are loading. Safari 5.1.1; OS X 10.7.2. (Tried with extensions, e.g., AdBlock, off too.)
The current design targets users who're familiar with other bin sites, and is less friendly to new users.
Would be useful if there was an option to enable line numbering. Not sure if this would go against the minimalist style you're going for though.
Okay, they know javascript, that helps...
But it makes node.js feel slick... a great marketing trick.
dillinger.io
Dillinger is also 100% open source:
github.com/joemccann/dillinger
i'm definitely gonna check out dillinger
---
You can even take this a step further (on OSX) and cut out the last step of copying the URL with:
`cat something | haste | pbcopy`
After running that, the STDOUT output of `cat something` will show up at a URL which has been conveniently copied to your clipboard.
That's all there is to that, and you can install it with `gem install haste` right now.
-----
Out of curiosity, why is that only possible on a Mac OS X setup with the Ruby gem? Is it only because Ruby is pre-installed?
gem install haste cat something | haste | xsel
I'll add that to the /about.md page tonight
Thanks - glad you like it! :)
The favicon is a great point and I'll get one together ASAP
https://github.com/jashkenas/coffee-script/wiki/Text-editor-...
EDIT: Sorry, I should post this as a Github issue instead...
Assuming a 64 bit instance (that is more memory hungry) and that the average paste size is 512 bytes, every 2 million documents require 1GB (just tested with redis-benchmark).
This means that if you have a paste every minute, in order to use 1 GB of memory you need to wait 4 years.
Many problems that at a first look appear to be hard to treat with an in-memory DB at a closer look appear quite addressable.
That said this is the kind of problem where the working set is very small compared to the whole set of documents stored, and where documents are rarely written and often accessed in a read only fashion, so a *SQL DB would work super well for that use case.
I Redis server could form a very good addition in order to perform real time stats about the accesses to the document: number of times the document was read, a sorted set for latest created documents, top documents for this month by page views, and so forth.
Thanks for the research, and look forward to more coming out in the way of statistics soon!