Jump to content

dave420

Members
  • Posts

    42
  • Joined

  • Last visited

    Never

Everything posted by dave420

  1. Wouldn't parsing an INI or XML file be rather expensive? Wouldn't it be better to at least cache the output into something more immediately useful, say using var_export?
  2. It would probably be quicker to include the MD5'd ID in the database, if you're going to search it via MD5. Otherwise your DB will have to hash and compare each of the IDs as it searches, which is going to be slower than just comparing strings. Why are you hashing the user IDs?
  3. I'd suggest to get XDebug installed on your server and then take a look at where your scripts are taking the longest, and then seeing what can be improved to bring those times down. If you're repeatedly generating (frying) content when serving a static (baked) file would suffice, then it's worth looking in to seeing if you can bake the currently-fried pages in an efficient manner, paying attention to knowing when the cache is stale, and re-generating it. Of course all of this depends highly on the work your site is performing, which is why I'd suggest profiling the performance to see if it's worth caching, and how to go about that sensibly.
  4. No, I'm just emphasising that they can be used together. $panties->unbunch()
  5. You can definitely have a singleton registry class for storing objects/variables for everything to access - that's a good way to have a site-wide configuration, for example.
  6. Thanks for the response! So you fry everything to order? Have you performed benchmarks on this system - do you know how well it would scale? I find I'm getting more and more obsessed with performance and scalability these days
  7. For that example, why not use a singleton database object? Then it's even easier.
  8. Does anyone here feel particularly strongly about either method for generating content? How about a solution that bakes semi-fried pages, allowing templates and objects to be combined in flat PHP files, ready for use? I'd like to hear the thoughts of you guys and gals, if possible. cheers!
  9. Registries can be made into singletons if you want to have a respository available from anywhere, or not, if you want to pass them around.
  10. Yes - don't use the anchor The anchor is not sent to the server - it's used by the client only. If you want to use pagination, I'd suggest using the query string. You can just put the page number in the query string like this: index.html?2 ... index.html?20 (where no query string means page 1).
  11. I'd recommend you store them in the filesystem - that's what it's there for Make your script create the necessary directories as needed, and do it that way.
  12. Well, you can use mod_rewrite for that, though these days it's usually a better idea to do it in code instead.
  13. It's very easy to do this. You can use the open-source LAME utility to check the MP3 and to re-encode it if needed. It's pretty quick, too, and offers great results. Download it here: http://lame.sourceforge.net/download.php. If you're using Windows, get the binaries here: http://lame.bakerweb.biz/
  14. Have you thought about normalising your database?
  15. Create a boolean variable before the loop, and in the while loop NOT it so it flips on every iteration. Use that true/false value to change the content of a variable, say $colour, and then use that in the TR tag to set the background colour (using CSS). Here's a quick example. <?php $rowState=false; while ($row = mysql_fetch_array ($result)) // loop through the rows outputing them as html table rows { $colour=($rowState=!$rowState) ? "#FF0000" : "#00FF00"; // $row["fieldname"] returns the content for the field in the current row echo "<tr style=\"background-color: $colour;\"><td>" . $row["MANNAME"]. "</td>"; echo "<td>" . $row["prodtype"]. "</td>"; echo "<td>" . $row["proddesc"]. "</td>"; echo "<td>" . $row["prodnar"]. "</td>"; echo "<td>QUALUBE " . $row["prodequiv"]. "</td></tr>"; } ?> I'd suggest using CSS classes instead of changing the background-color directly, just for ease of changing it later.
  16. It sounds rather easy to achieve this. PHP has everything you need to get this working. If the interface is using HTTP, as it would be if it's web-based, you can use the cURL library to log in to the specific IP address. I'd suggest making a script that is run in a scheduler (like CRON on a *nix box), which periodically checks the machines in order. It can save that information into a database, and then you can make a basic website in PHP that accesses that information. The benefit of this method is you will have an accurate history of what each box spat out stored in the database, should you want to graph it or use it in reports, or even generate automated email/sms alerts should something go awry with one of them. You could make a table in the database that lists each machine's IP address (and a friendly name if you want, to make viewing the data more human-friendly), which could also be updatable via a web interface, so should you want to add a new machine to the system, you just enter in its IP address (and name it), click "ok", and it'll be automatically included in the next poll. Does that sound like something you could do? It's easier than it sounds
  17. If you're not going to have metadata stored with the picture, use the directory structure to organise the files. Then simply have PHP go through the selected folder to find out what pictures are in there, and spit out <img> tags however you want to in your design. You can point those <img> tags to a script that spits out thumbnails (obviously caching them after generating them, otherwise your webserver might implode). If you want metadata, I'd suggest using a database, possibly using the filename and path as the key to the entry in the database. The only problem with that is if you move the file from one folder to another, the data won't follow it. To overcome that, you could store a unique ID in the EXIF tags of the picture if PHP can't find one, which could be used as the key instead. If your user wants to update it themselves, the simplest way is to set up their FTP access and let them upload their own pictures. It's easier for you and them.
  18. Have you thought about rewriting every request that's not to an existing asset to a single PHP file, then have that file determine which PHP scripts to include? That way you have a single place where every page request starts from, where you can put your authentication/database/libraries/etc., at a very low overhead.
  19. That's cool! I was too busy trying to see why $blanks wasn't incrementing I'm glad you got it sorted.
  20. I would suggest using the MySQL function FROM_UNIXTIME and pass it the time(), as it looks like you're not inserting the date correctly. If you want it in the format you're showing, I'd suggest putting it in quotes in the query.
  21. It looks like your MP3 is a bit screwy in the ID3v2 headers. If the parser is not returning any data for that MP3, and you know it does have tags, you could try a different ID3 parser to see if one is a bit less strict and will return useable data. You could try getID3() from http://getid3.sourceforge.net
  22. Are you sure your $_POST variable is being filled correctly? I tried it and it works for me...
  23. Well, it's not an exact expression - it still has to be matched against the string, bits of it captured, and then reconstituted in its final form. I ran it through xdebug, and the preg_replace took up most of the time every single time I ran a test. Regular expressions have quite an overhead compared to simply moving three bits of a string around using substr.
  24. Are you sure you're doing <?php $string=serialize(html_entities($_SESSION[var])); ?> and not <?php $string=html_entities(serialize($_SESSION[var])); ?> ?
  25. I'd suggest to spare yourself the trouble and make the array in an actual array, then serialize when you've finished changing the contents. It might even be quicker that way.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.