On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 16 Mar 2012, at 20:53, rene7705 wrote:
> > On Fri, Mar 16, 2012 at 9:45 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> >> On 16 Mar 2012, at 20:36, rene7705 wrote:
> >> > On Fri, Mar 16, 2012 at 9:29 PM, Stuart Dallas <stu...@3ft9.com>
> >> >> On 16 Mar 2012, at 18:57, rene7705 wrote:
> >> >>
> >> >> > Hi Folks..
> >> >> >
> >> >> > I could waste a lot of text on what I've accomplished during the
> >> >> > months, but the easiest thing is if you have a (another) look at
> >> >> > source of) http://mediabeez.ws
> >> >> >
> >> >> > I think you'll like my opensourced work :)
> >> >> >
> >> >> > Feedback is appreciated.
> >> >>
> >> >> I'm also having trouble downloading the ZIP file (Chrome 17.0.963.79
> on OSX - not that the browser will have anything to do with this problem at
> all). The download starts, gets to a few MB and doesn't get any further.
> >> >>
> >> >> And 52MB? Since I can't actually see what it contains it's hard to
> judge, but right off the bat... is your artwork necessary for the thing to
> work? What external libraries are you using?
> >> >>
> >> >> Just from looking around the site there are a few things that jump
> >> >>
> >> >> * The dropdown menus are incredible jittery, certainly nowhere near
> >> >>
> >> >> * The background image gets squished according to the dimensions of
> the browser window.
> >> >>
> >> >> * Your homepage weighs in at massive 2.6MB. Nuff sed!
> >> >>
> >> >> I suggest you take the focus off the way it looks and concentrate on
> what it does. Tabs with animated backgrounds remind me of websites from the
> late 90s. You may have developed an incredible framework here, but I don't
> know because it's buried under >50MB of other stuff that I almost certainly
> don't care about, and that's before I've even been able to download it.
> >> >
> >> > ok..
> >> >
> >> > That being unable to download the zip file correctly is something
> I'll take up with my hosting provider tomorrow.
> >> > I've downloaded it in full and opened it OK in winrar just now, btw.
> >> >
> >> > The zip-file is created with winrar on windows 7, and according to
> Floyd Resler has to get it's extension changed to .rar, then decompressed
> with Stuffit Expander. Also something to look into soon, btw.
> >> That would explain why every zip decompression utility I've tried
> thinks it's corrupt.
> >> > As for my menu being jittery, it's not jittery on any of the windows
> browsers I tested.
> >> > And I have no mac-book available to me, not even from friends and
> family who are all on windows (on my recommendation btw ;)
> >> Are you ready for the shocking truth... not every computer in the world
> runs Windows, so unless you've developed this purely for the friends and
> family you've convinced to do so you may want to rethink your approach to
> >> > As for my files and homepage being Huge, yep, it's made for the
> future or current fast internet connections.
> >> > Frankly, size reduction is not on my agenda. I'll wait for the nets
> to become faster still.
> >> > And the server should spit it out at 2MB/s at least..
> >> That may be so, but when my 100Mbit/s connection finally managed to
> download the file it took about 4 minutes, which is nowhere near 2MB/s.
> Your homepage takes 7 seconds to load - that's unacceptable in the real
> world, especially when you're talking about a server that's (and I'm only
> guessing here) not under heavy load.
> >> Anyway, your comment about waiting for the nets (sic) to catch up so it
> can cope with your bloat has convinced me to not bother looking any further
> into your project, but I wish you the best of luck with it (you're gonna
> need it).
> > Okay, I don't wanna get into an argument here..
> Shame, because I'd love to see you try to defend a position that promotes
> wasting resources "just because they're there." This is not a new thing -
> ever-increasing computing resources have always led to this short-sighted
> view in the inexperienced, but trust me when I say you'll regret it when
> you're paying for the bandwidth being used by thousands of people
> simultaneously using a site that's using your framework. Why do you think
> other libraries such as jquery recommend minifying their code before
> deployment, and then serving it via gzip? Every bit and byte counts,
> especially as you scale up.
minifying them all the time creates too much overhead for me. If you want
them minified you can easily do that yourself.
> Anyway, I'm not trying to get into an argument (it's rare that I do), but
> I do recommend that you take in what I've said on this issue. The size of
> the data you're sending down the pipe matters if you want your library to
> be used for anything serious, and no amount of artwork or pretty pictures
> will distract anyone for long.
The download size will hardly be an issue for site operators, whom i
seriously suspect will be on faster links.
And the usage size doesn't have to be large, as mentioned earlier.
> about 25kb.
> Good for you. You might want to produce a download that doesn't include
> the optional stuff so you can show how small it is, and provide examples
> that show off what it can do using just that code.
Sorry, no, too much overhead for me.
> Incidentally, a little over 2MB of your homepage is the logo. 2MB for the
> logo? Seriously??
Yes, I don't expect my site to get 100's of NEW hits every second, and I
don't have to pay for bandwidth.
> > The artwork for simple animations is about 100kb per button/menu-item
> 100kB is not a simple animation, that's a mini-movie.
> > The fact that I demo how to put video on a button and thus end up with
> nearly a dozen button themes that are about 2MB each, is just taking
> advantage of the fast links that are available in much of the world.
> Make them a separate download. Not everyone is using a "fast link" and
> even those of us who are may not care about those themes, so give us a
> choice as to whether we download them. I certainly don't care about
> scenejs, yet it has decompressed to 19MB!
I might get rid of scenejs, I've fiddled with it and it's very immature atm.
And I'll consider putting my own larger artwork in a seperate download
(might be difficult and not worth my time to me).
> > About me testing only on windows, you're right about that and I'll see
> if I can do something to improve my testing regime. For now i'm dependent
> on your patience and bugreports tho.
> That's not what you said, you basically said that you've tested it on
> Windows and don't care about anything else. Please don't take this as harsh
> criticism, but if you're developing a library for other people to use, you
> need to consider the environments in which they're likely to use it. If you
> don't have the capability to develop/test your library on different systems
> you need to foster a community around your library that can test for you
> and ideally provide patches to fix bugs. I know testing on OSX can be an
> issue due to prohibitive cost, but there's unlikely to be a good reason why
> you can't test on Linux.
I do care about making my software work on other platforms besides windows.
Please provide accurate detailed bugreports, if you want to see a bug
fixed. For all the crying for proffesionality here, I haven't seen a single
one of the critics post actual error messages.
> > And I had no idea winrar made such crappy zip files, I'll look into a
> replacement very soon.
> Winrar did its job and made a rar file. Did you change the extension to
> zip? The best compression utility I've found for Windows is 7-zip, but I
> haven't used that OS for a while so I dunno if it's still the best.
I'll look into 7-zip.
> I took a quick look around your code and I saw some scary stuff in there.
> Taking lib_fileSystem.php as an example brings up the following issues...
lib_fileSystem.php is older code, and I appreciate your bugreports.
I'd appreciate bug fixes even more! :)
> * In the fgetsr function you open the file for reading and writing despite
> only needing to read from the file.
> * In zipExtractUnix you pass arguments onto the command line without
> escaping them. You also assume that there is a command named "unzip" on all
> platforms, where such a utility does not natively exist on any platform
> that I'm aware of (possibly some Linux distributions I'll grant you, but
> they're the exception rather than the rule).
> * Not entirely sure what evalDate is supposed to do (function-level
> comments would be useful) but it's passing variables into eval without any
> checks on what they contain. Rule of thumb: if you think eval is the answer
> you're asking the wrong question.
> * In getFilePathList you're using evalDate, so now I know what it's for,
> and you're definitely asking the wrong question.
getFilePathList will only use evalDate if you ask it to filter on date,
which none of my app code currently does.
> * Your readIniFile function appears to be doing the same thing as PHP's
> parse_ini_file function.
> * There's a PHP function for renaming files, which will let you make your
> renameFile function safe (it's not currently safe because it's another
> example of not escaping arguments on a command line).
> * Strangely you then use PHP's rename function to rename a file in
> moveDirectoryStructure, so you're clearly aware of it.
It's been a long time since I looked at lib_fileSystem.php
But hey, if you want to improve it and send the results back to me I'll
include them, give you credit, and make all of us very happy.
> I've probably missed stuff because this was a quick skim, and I've ignored
> stylistic preferences that bug the hell out of me, but despite those
> caveats there are some very serious, and pretty basic, security issues here.
Not if you realize that the code you found those bugs in is not actually
> I hope you find my feedback useful once you get past my sarcastic tone. I
> tried to control it once, but it wasn't pretty and it didn't end well! :)
I did :)
Just remember one thing: If you see something obviously wrong, why not send
me the fix?