On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: > On 16 Mar 2012, at 20:53, rene7705 wrote: > > On Fri, Mar 16, 2012 at 9:45 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: > >> On 16 Mar 2012, at 20:36, rene7705 wrote: > >> > >> > On Fri, Mar 16, 2012 at 9:29 PM, Stuart Dallas <stuart@xxxxxxxx> > wrote: > >> >> 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 > last > >> >> > months, but the easiest thing is if you have a (another) look at > (the > >> >> > 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 > out... > >> >> > >> >> * The dropdown menus are incredible jittery, certainly nowhere near > production-ready. > >> >> > >> >> * 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 > testing. > >> > >> > 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. > The javascripts are currenlty being served unminified via gzip, because 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. > > > Rest assured, all the javascript for my animated widgets combined is > 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 > theme. > > 100kB is not a simple animation, that's a mini-movie. > Exactly. _animated_JavascriptWidgets it's called. > > > 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. > Ok, cool. > > * 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). > Ok > > * 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 being used. > > 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?
