requinix

"Really simple and optimized" isn't going to do it there. Uptime for a particular service (like a web server) is measured by when the service is accessible. To monitor the service yourself you're going to need something that can evaluate the status of the service. For example, with a web server you'll need something to "ping" the server periodically. Such as a cron job on a one minute timer. When it connects successfully the service is "up", and when it does not the service is "down". Recording that information could go any number of ways. Times 100-200 is not going to be simple, because connecting to that many services could easily take more time than you have between measurements. So that means either multiple "machines" measuring uptime or relaxing your measurement interval. Off hand, one way to store the results is to stick a record in the database per service per minute indicating whether it's online, then using a periodic (daily, weekly) job to summarize that information. Such as calculating uptime for a particular interval, and probably removing the individual measurements for the sake of storage. Or another method would be to say that each per-minute online measurement affords 1 units of uptime (and each day is, eg, 1440 units long), and you can simply accumulate units for each interval: INSERT INTO uptime (machine, service, day, uptime) VALUES (DATE(), 1) ON DUPLICATE KEYS UPDATE uptime = uptime + 1(where the machine+service+day is a unique key and you count uptime as 1=online and 0=offline)

It may be because I'm drunk ( ) but I don't understand what you're asking. Do you want to chart the server's uptime over a period of a week? Does the output from `uptime` help?

Your new server doesn't have short_open_tag enabled. Best practice is to use the full "<?php" so the changes you made were a good thing.

I'm not a fan of putting function or method names in strings (IDEs can't recognize them). And I'm not a fan of conventions like calling "update"+Name methods (too magical for my tastes). I'd still go with the "configuration"-type approach. Unanswered question that would help to be answered: What ways of handling values are there? For example, there's those three types from earlier: #1 was updating a column in a table, don't know about #2 and #3. I ask because my next thought is abstract class Chart { private $fields; public function __construct() { $this->fields = $this->getFields(); } protected function getFields() { return array( "name" => new UpdateType1("name", $this->id, $this->account->id), "title" => new UpdateType2(...), "subtitle" => new UpdateType2(...) ); } public function set($name, $value) { if (isset($this->fields[$name])) { $this->fields[$name]->update($value); } else { error } } } class BarChart extends Chart { protected function getFields() { return array_merge(parent::getFields(), array( "xAxis" => new UpdateType3(...), "yAxis" => new UpdateType3(...) )); } } interface IUpdateType { public function update($value); } class UpdateType1 implements IUpdateType { private $field; private $id; private $accountid; public function __construct($field, $id, $accountid) { $this->field = $field; $this->id = $id; $this->accountid = $accountid; } public function update($value) { // update database } } I forget the name of this design pattern. It's similar to Command.

Do you have to use subclasses? class Chart { private $type; private static $CHARTS = array( "bar" => array("xAxis", "yAxis"), "pie" => array(/* what do you need in a pie chart? */) ); public function set($name, $value) { if ($name == "name") { // all charts have a name // update database } else if ($name == "title" || $name == "subtitle") { // all charts have a title and subtitle // ??? } else if (in_array($name, self::$CHARTS[$this->type])) { // ??? ] } } $chart = new Chart(whatever, "bar"); $chart->set($_POST["attrName"], $_POST["value"]); Sure, you could go the OOP route, but it's making this unnecessarily complicated when all the subclasses do (?) is indicate available field names.

$e = array((poisson($x+1,2.5) * poisson(0,3.5))*100);That puts one value into an array and assigns it to $e. Over and over and over again. What it does not do is append the value into the array that is already in $e. While you could fix the code to append to arrays properly, don't. Wouldn't it be much simpler to just sum the values as you go? Set $e to 0 before the loop, then inside the loop add each value to it.

Have you checked the rest of the documentation? There might be something in there that's relevant. Or you might have to make it force validation on a field (or whatever) manually onblur.

Yeah, the debugger works on one single process - when you start the second script it won't follow along. If you had Xdebug then you could launch that second PHP with the right options to automatically start debugging, implying that you were not debugging the first script, but now it's starting to get complicated. Are you sure you need php://input to work? Would you be able to hack it such that it uses a different path, like "php-dynamic://input", then register your own php-dynamic stream that wraps php normally and your testing library stuff when... testing? That sounds like something I would look into myself.

-- universally(ish) means to stop processing command line arguments and treat the rest as literals. If you did php -f file.php -hthen PHP would think you wanted to see its help. If you did php -f file.php -- -hthen PHP would run file.php and pass it "-h" in $argv[1]. If you used -f with the command then you would need --, but without -f PHP implicitly stops parsing arguments after the filename. php filename args... php -f filename -- args... And no, I don't know why PHP_BINARY doesn't have a value. Are you calling the first script from the command line?

You mean the one that doesn't exist anymore? The one that's been replaced with "FormValidation"? The one that doesn't seem to have any documentation preserved? Fortunately archive.org has a copy from back in September 2014. You know, when the version you're using is from. Try calling revalidateField on "street" and "place" when they get (re?)added to the form.

Which "Bootstrap Validator" are you using?

Bwahaha, I got the command wrong. args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdinSo I was a bit overzealous in using --. The command should be $command="/usr/bin/php" . escapeshellarg($script) . " " .$args;

Output PHP_BINARY . " -- " . escapeshellarg($path_to_second_script) . " " .$argsand make sure it's the correct command.

That code is basically just a fancy wrapper around proc_open. If all you need to do is simply run code/a file then it's, like, 15 lines of PHP to do so...

You want what? Explain how this expiration thing is supposed to work.

Clearly not everything is correct. Check your database information again. Make sure your database users are set up correctly. Look at whatever else is relevant.

It would be nice if you could share what you discovered, since I know that there's something else going on besides PHP "not liking" that zero...

That's an option? That class? You should do that. Yeah it's more code, but it's more flexible and lends itself really well to testing.

Looks like PhpEd has its own debugger they want you to use? If that doesn't work for you then you can look to see if there's a way to get Xdebug working with it instead. (Netbeans user here so I don't know.) As for php://input, that will be empty unless you're running the script through the console with something piped into it. (I think - that might only be for stdin.) I don't think you can give it a value short of implementing your own php:// wrapper, which would suck. I think the best option would be two scripts: one script calls the other through the shell and pipes in the $post data, then the other to fill in $_GET and $_POST and such appropriately. I've used that kind of strategy before with my own code... which is somewhere... I don't quite remember... It's used as part of a unit testing framework, albeit mostly for launching PHP processes under specific configurations. // first script function simulateRequest($method, $url, $get, $post) { $query = http_build_query($get ?: []); $input = http_build_query($post ?: []); // pass most information through argv $args = implode(" ", array( escapeshellarg($path_to_second_script), escapeshellarg($method), escapeshellarg($url), escapeshellarg($query) )); $descriptors = array( 0 => array("pipe", "r"), 1 => STDOUT, 2 => STDERR ); // launch php with the second script and write to it the post data $p = proc_open(PHP_BINARY . " -- " . escapeshellarg($path_to_second_script) . " " . , $descriptors, $pipes); fwrite($pipes[0], $input); fclose($pipes[0]); proc_close($p); } list(, $method, $url, $query) = $argv; parse_str($query ?: "", $_GET); parse_str(file_get_contents("php://input"), $_POST); $_REQUEST = // really you should evaluate this according to request_order // etc. // then continue the startup process Meanwhile $opts = ['http' =>['method' => 'POST','header' => 'Content-type: application/x-www-form-urlencoded','content' => http_build_query($post)]]; $context = stream_context_create($opts); $rawInput = fopen('php://input', 'r'); stream_copy_to_stream($context,$rawInput); is really, really wrong. OH FOR FRICK'S SAKE, why is the indentation broken? Blargh.

Right. You can't use something in the global namespace, but adding a backslash is easier anyways. Doesn't matter. Personally I wouldn't, simply because the code isn't using namespaces so I wouldn't "introduce" namespaces into it. But you can if you want. Consistency, maybe? It's an autoloader for the most common class/file hierarchy: you have a file at /path/to/classes/Foo/Bar/Baz.php containing the class Foo\Bar\Baz. Nothing special with filenames, no sanity checks, just a simple class-to-path conversion method to find the right file. But like I said, if you want to use that method then you should just use the built-in autoloading logic. Because it does the same thing.

PHP needs fully-qualified names to determine what classes are. If you write just "PDO" then PHP will think you want the PDO class in the current namespace; if you're not in a namespace then great, otherwise it won't find the class (unless you happen to have one with that name). Write \PDO. The class will be like "Path\To\Class"; the common answer is to convert backslashes to DIRECTORY_SEPARATORs and look for a matching filename. spl_autoload_register(function($classname) { $path = str_replace("\\", DIRECTORY_SEPARATOR, $classname); require "/path/to/classes/{$path}.php"; });But if that's all you need to do then you might as well use the built-in spl_autoload and put your /path/to/classes in the include path. spl_autoload_register(); // equivalent to spl_autoload_register("spl_autoload") Your autoloader ignores the entire namespace and only uses the class name. It will not be able to handle multiple classes with the same name but in different namespaces, like "Foo\Example" and "Bar\Example".

use (the one for namespaces) helps you not have to repeat fully-qualified names everywhere. That's really all it does. I won't name names, but there are folks out there who write classes like namespace Framework\Database\AbstractRecord\BaseClasses\TableBase; abstract class DefaultTableBaseImplementation {(there'd actually be an interface in there...) To use that in your code you'd normally write class MyDatabaseTable extends \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation {That's rather unwieldy but acceptable on its own. Now imagine you have to reference a number of different classes. Say, traits: class MyDatabaseTable extends \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation { use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableLowercaseNameTraitBase; use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableNoPrimaryKeyTraitBase; use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableIsViewTraitBase; (which demonstrates a different use...) Writing that all out every time sucks and encourages you to copy/paste code (something I hate). With a use statement you can use \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation; // whole class use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode as FBaseTraits; // can have a shorter alias class MyDatabaseTable extends DefaultTableBaseImplementation { // easier to read use FBaseTraits\TableLowercaseNameTraitBase; use FBaseTraits\TableNoPrimaryKeyTraitBase; use FBaseTraits\TableIsViewTraitBase;

Yes it is now available to everyone. But that doesn't mean the original "array()" syntax is obsolete. Nor is it discouraged, nor is "[]" a best practice, nor is really anything true besides there being two array syntaxes available. Frankly, I think [] gets lost in the mess of other symbols too easily. It's sure handy for writing an array but sometimes I like seeing the word "array" for clarity.

No it is not.