[melkjug feedback] melkjug.org Instance

[Luke Tucker]

Hey David,

Sorry to hear your experience was so drastically negative! but thanks
for the honest feedback :) We'll do our best to fix things up in the
javascript department as soon as we can. It's a relatively small open
source project, so we're going with release early and often even if
it's... significantly less than perfect :) I hope when we get it in
better shape you'll give us another shot. If you have any interest in
lending us a hand in tuning things up, check out the project website
at http://melkjug.openplans.org

Thanks again,

- Luke

I was really excited by the concept of tunables, up until I noticed
the entry page takes over a second to load on my December 2007
MacBook in Europe.
On investigating I see 20, yes 20 Javascript source files. No way am
I using this. :)
Forgetting the effects all those files have on latency (not to
mention they're at the start of the HTML rather than the bottom --
where they don't prevent the rest of the page from rendering), I'm
sure the app is nice and all that, but I use wireless waay too much.
Guaranteed 1 time in 4 I try to login one of those files will stall.
Its 100 times worse when using 3G Internet.
Perhaps I'm sad for rating apps like this, but I've come to
understand it's the difference between a good day, and wanting to
throw my computer out the nearest window.
All the best!
David.

--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235524105429
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Robert Marianski]

One easy way to do this is through a piece of middleware that the vudo
guys wrote: repoze.squeeze. It scans for resources at a particular url,
and tries to aggregate the patterns of resources into one. It uses the
assumption that for a given url, you usually bundle the same resources
together. AFAIK, it uses some kind of heurisitic based approach, so it
readjusts itself if the pattern of resources changes, and tries to
squeeze as much as possible together.

You can probably do better by statically aggregating them yourselves for
production deploys, but just sticking in repoze.squeeze into the
pipeline should be much easier ;) gzipping the aggregate should help
things too.

http://svn.repoze.org/repoze.squeeze/trunk/README.txt

Robert

Post by Luke Tucker
Hey David,
Sorry to hear your experience was so drastically negative! but thanks
for the honest feedback :) We'll do our best to fix things up in the
javascript department as soon as we can. It's a relatively small open
source project, so we're going with release early and often even if
it's... significantly less than perfect :) I hope when we get it in
better shape you'll give us another shot. If you have any interest in
lending us a hand in tuning things up, check out the project website at
http://melkjug.openplans.org
Thanks again,
- Luke

I was really excited by the concept of tunables, up until I noticed
the entry page takes over a second to load on my December 2007 MacBook
in Europe.
On investigating I see 20, yes 20 Javascript source files. No way am I
using this. :)
Forgetting the effects all those files have on latency (not to mention
they're at the start of the HTML rather than the bottom -- where they
don't prevent the rest of the page from rendering), I'm sure the app is
nice and all that, but I use wireless waay too much. Guaranteed 1 time
in 4 I try to login one of those files will stall.
Its 100 times worse when using 3G Internet.
Perhaps I'm sad for rating apps like this, but I've come to understand
it's the difference between a good day, and wanting to throw my
computer out the nearest window.
All the best!
David.

--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235524105429

--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235538609155
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Joshua Bronson]

Thanks for the tip Rob! I've created a ticket and noted this:
http://trac.openplans.org/melkjug/ticket/370

Post by Robert Marianski
One easy way to do this is through a piece of middleware that the vudo
guys wrote: repoze.squeeze. It scans for resources at a particular url,
and tries to aggregate the patterns of resources into one. It uses the
assumption that for a given url, you usually bundle the same resources
together. AFAIK, it uses some kind of heurisitic based approach, so it
readjusts itself if the pattern of resources changes, and tries to
squeeze as much as possible together.
You can probably do better by statically aggregating them yourselves for
production deploys, but just sticking in repoze.squeeze into the
pipeline should be much easier ;) gzipping the aggregate should help
things too.
http://svn.repoze.org/repoze.squeeze/trunk/README.txt
Robert

Post by Luke Tucker
Hey David,
Sorry to hear your experience was so drastically negative! but thanks
for the honest feedback :) We'll do our best to fix things up in the
javascript department as soon as we can. It's a relatively small open
source project, so we're going with release early and often even if
it's... significantly less than perfect :) I hope when we get it in
better shape you'll give us another shot. If you have any interest in
lending us a hand in tuning things up, check out the project website at
http://melkjug.openplans.org
Thanks again,
- Luke

I was really excited by the concept of tunables, up until I noticed
the entry page takes over a second to load on my December 2007 MacBook
in Europe.
On investigating I see 20, yes 20 Javascript source files. No way am I
using this. :)
Forgetting the effects all those files have on latency (not to mention
they're at the start of the HTML rather than the bottom -- where they
don't prevent the rest of the page from rendering), I'm sure the app is
nice and all that, but I use wireless waay too much. Guaranteed 1 time
in 4 I try to login one of those files will stall.
Its 100 times worse when using 3G Internet.
Perhaps I'm sad for rating apps like this, but I've come to understand
it's the difference between a good day, and wanting to throw my
computer out the nearest window.
All the best!
David.

--

http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235524105429

Post by Luke Tucker
To unsubscribe send an email with subject "unsubscribe" to

--
http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235538609155
To unsubscribe send an email with subject "unsubscribe" to

[David Wilson]

Hi Luke,

Sorry it came across that way, I only meant it as constructive
criticism. I would say though that one of the best things you can do
to make Melkjug more usable is to reduce its load time (as is well
known in the industry).

If you like, I could try to contribute a Makefile that will
concatenate your sources, and call minify or Y! Compressor. I'm using
something similar to this for a personal project already. I guess it
might be a bit harder if you share the same source files across
multiple physical pages (my app doen't do this), but I'd be willing to
give it a shot when I get a free minute.

Again, sorry if what I said sounded harsh. :)


David.

Post by Luke Tucker
Hey David,
Sorry to hear your experience was so drastically negative! but thanks for
the honest feedback :)  We'll do our best to fix things up in the javascript
department as soon as we can.  It's a relatively small open source project,
so we're going with release early and often even if it's... significantly
less than perfect :)  I hope when we get it in better shape you'll give us
another shot.  If you have any interest in lending us a hand in tuning
things up, check out the project website at http://melkjug.openplans.org
Thanks again,
- Luke

I was really excited by the concept of tunables, up until I noticed the
entry page takes over a second to load on my December 2007 MacBook in
Europe.
On investigating I see 20, yes 20 Javascript source files. No way am I
using this. :)
Forgetting the effects all those files have on latency (not to mention
they're at the start of the HTML rather than the bottom -- where they don't
prevent the rest of the page from rendering), I'm sure the app is nice and
all that, but I use wireless waay too much. Guaranteed 1 time in 4 I try to
login one of those files will stall.
Its 100 times worse when using 3G Internet.
Perhaps I'm sad for rating apps like this, but I've come to understand
it's the difference between a good day, and wanting to throw my computer out
the nearest window.
All the best!
David.

[Joshua Bronson]

Hey David,
I'm Josh, the other full-time Melkjug developer, Luke's on vacation at the
moment. Thanks for the offer, we'd love to see your Makefile if you have a
chance. I created a ticket
<http://trac.openplans.org/melkjug/ticket/370>for this issue a few
days ago and it's currently slated for our 0.5.1 (next)
release, so I was planning on putting some time into this anyway after
knocking out a few of the more important things on my plate. Feel free to
update the ticket directly with an attachment, and in general to make as
much use of our Trac instance <http://trac.openplans.org/melkjug>, mailing
list<http://www.openplans.org/projects/melkjug/lists/melkjug-development-list>,
OpenPlans project <http://www.openplans.org/projects/melkjug/summary>, and IRC
Channel <irc://irc.freenode.net/#melkjug> as you like. Thanks again for the
feedback, and look forward to seeing you around!

Josh

Post by David Wilson
Hi Luke,
Sorry it came across that way, I only meant it as constructive
criticism. I would say though that one of the best things you can do
to make Melkjug more usable is to reduce its load time (as is well
known in the industry).
If you like, I could try to contribute a Makefile that will
concatenate your sources, and call minify or Y! Compressor. I'm using
something similar to this for a personal project already. I guess it
might be a bit harder if you share the same source files across
multiple physical pages (my app doen't do this), but I'd be willing to
give it a shot when I get a free minute.
Again, sorry if what I said sounded harsh. :)
David.

Post by Luke Tucker
Hey David,
Sorry to hear your experience was so drastically negative! but thanks for
the honest feedback :) We'll do our best to fix things up in the

javascript

Post by Luke Tucker
department as soon as we can. It's a relatively small open source

project,

Post by Luke Tucker
so we're going with release early and often even if it's... significantly
less than perfect :) I hope when we get it in better shape you'll give

us

Post by Luke Tucker
another shot. If you have any interest in lending us a hand in tuning
things up, check out the project website at http://melkjug.openplans.org
Thanks again,
- Luke

I was really excited by the concept of tunables, up until I noticed the
entry page takes over a second to load on my December 2007 MacBook in
Europe.
On investigating I see 20, yes 20 Javascript source files. No way am I
using this. :)
Forgetting the effects all those files have on latency (not to mention
they're at the start of the HTML rather than the bottom -- where they

don't

Post by Luke Tucker

prevent the rest of the page from rendering), I'm sure the app is nice

and

Post by Luke Tucker

all that, but I use wireless waay too much. Guaranteed 1 time in 4 I try

to

Post by Luke Tucker

login one of those files will stall.
Its 100 times worse when using 3G Internet.
Perhaps I'm sad for rating apps like this, but I've come to understand
it's the difference between a good day, and wanting to throw my computer

out

Post by Luke Tucker

the nearest window.
All the best!
David.

--
It is better to be wrong than to be vague.
— Freeman Dyson