Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sams99
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
14 ms
·
91.
▲
by
sams99
13y ago
Spam has completely vanished, got 0 in a month. Quality and length of comments has gone way up. Turns out that the extra click required and registration weeds out a lot of the problem comments. I also find that giving people space, proper p
92.
▲
by
sams99
13y ago
Sam here from Discourse, I use Discourse to drive commenting on my blog and I love it, ever since I did it comment quality has gone way up. eg: http://samsaffron.com/archive/2013/11/22/demystifying-the-ru
93.
▲
by
sams99
13y ago
If you send me a flamegraph using ?pp=flamegraph_embed I can help you figure out why it got slow. I am actively working on getting a long term perf benchmark using the Discourse bench. Server is already provisioned by ninefold. see my talk
94.
▲
by
sams99
13y ago
Yes, would very much appreciate some flamegraphs http://samsaffron.com/archive/2013/03/19/flame-graphs-in-rub... comparing the apps behavior on 2.3 and your latest (and 4.0) Without exact profiling infor
95.
▲
by
sams99
13y ago
you can commit at any point and ship that via private registry
96.
▲
Discourse in a Docker container
(samsaffron.com)
1 points
by
sams99
13y ago
|
0 comments
97.
▲
by
sams99
13y ago
I got so many mixed messages about the IT cost, ranging from 94 million to 650 now, I really wonder how much this huge muddle cost?
98.
▲
by
sams99
13y ago
they actually never open sourced marketplace for some reason
99.
▲
by
sams99
13y ago
"serving up 80 separate assets is insane." in production it certainly is, we minify, concatenate and use a CDN. In dev if you concatenate and do not use source maps you compromise your debugging experience. The "refresh all browsers" is onl
100.
▲
by
sams99
13y ago
MiniProfiler is actually showing server time http://meta.discourse.org/uploads/meta_discourse/833/0abd085... First paint is 380ms in which is not too bad considering my ping time to the Linode is 250ms (even though http keepalive is helpi
101.
▲
by
sams99
13y ago
I work from home so I am cheating :) Stuff lives on the VM but I have a second identical setup on the Mac just in case I decide to take it out somewhere. While at home I ssh from the Mac to my Ubuntu VM. A huge advantage of Linux is that mv
102.
▲
by
sams99
13y ago
I run a local Ubuntu VM for dev, the terminal you are seeing is gnome-terminal running tumx. I have a cygwin X Server running on my Windows box (startx). I then ssh -Y into my Ubuntu machine to get a proper terminal allowing my to fire off
103.
▲
by
sams99
13y ago
Yes, that was the background. Vim vs Sublime just boils down to personal taste both are awesome editors. But... when you compare either to VS ... well startup time is not its strong point, just launched my old VS 2010 copy and it took 5 sec
104.
▲
by
sams99
13y ago
Its a fair point, sublime is an awesome editor, in fact I use it sometimes when I need to search through the project cause I very much like its search feature. I can't put my finger on exactly what, but when I was using sublime even in vint
105.
▲
by
sams99
13y ago
I follow, however, I really want to run all the tests when I kick off the test suite or recover a failed test. It is critical I have the ability to interrupt these huge runs at will (and resume the big testing when my urgent testing is done
106.
▲
by
sams99
14y ago
the big pain at the moment with the MRI GC is that it stops the world, on Discourse we see a 50-60ms stall every few requests. Can totally be mitigated with unicorn and oobgc (we will move to this), still a PITA.
107.
▲
by
sams99
14y ago
do you have any real world demos / benches etc that back you up here?
108.
▲
by
sams99
14y ago
Keep in mind, the only benchmark I really care about is Discourse itself, I am sure that in many micro benchmarks JRuby is faster and/or slower
109.
▲
by
sams99
14y ago
yeah ... we have the exact same problem http://meta.discourse.org/t/how-can-we-speed-up-our-test-sui...
110.
▲
by
sams99
14y ago
not the case for us, Ruby 1.9.3 outperformed latest JRuby for us. Ruby 2.0 completely smoked it (and with GC tuning and tcmalloc even more), we leverage a fair amount of native gems, like the oj json serializer and fast_xs. Trouble is we wo
111.
▲
by
sams99
14y ago
require is way way faster in Ruby 2.0 typically bundle exec rails c will drop from 8 seconds to 4 just by upgrading the vm. optimising this is not an impossible problem its just going to take time, its far from a trivial one.
112.
▲
by
sams99
14y ago
For our use even assembly does not "rip Ruby apart.", looking at our 2 most common pages, topic list page and topic page, 30-50% of the time is still spent in SQL. Ruby 2.0 bring decent launch times to Rails (important for dev) due to the
113.
▲
Show HN: Flame graphs for Ruby on Rails using MiniProfiler
(samsaffron.com)
2 points
by
sams99
14y ago
|
0 comments
114.
▲
by
sams99
14y ago
our mobile story sucks at the moment, we are dying for a mobile friendly skin at the bare minimum, contributions totally welcome. you can get it to work on mobile safari in portrait if you zoom in / out ... but that just too hacky
115.
▲
by
sams99
14y ago
Same here, I find that approach often poisonous, embracing and eliminating the suck is far more productive.
116.
▲
by
sams99
14y ago
It is likely to be way cheaper and way more thorough to have a slew of automated tests... by no means I am saying fire all QA and automated them, but being able to run 10000 ui tests in one hour has some major advantages.
117.
▲
by
sams99
14y ago
Yes, I love this approach, when we reach high scale we are surely going to take a similar approach
118.
▲
by
sams99
14y ago
Bitcoins can be used to purchase marijuana, Bitcoins can be used to buy Dominos Pizza ... coincidence ... I don't think so.
119.
▲
by
sams99
14y ago
see: http://meta.discourse.org/t/lots-of-loading-time-when-browsi...
120.
▲
by
sams99
14y ago
can you please expand on this? not following
More ›