gizmola

This is what Linux does. When the OS has lots of extra memory available it will use it to cache the filesystem. If more memory is needed it will take memory from cache and allocate it. You can think of it as Linux being proactive in making use of an available resource rather than having it go to waste. In regards to your site, the main question would be what level of CPU usage (top is a good tool to start with) you have, and what else the server is being utilized for. I don't know if you can increase the number of processes that are pulling crypto price data, or processes that are doing other sorts of data or number crunching to make more use of the memory and cpu resources you have. If this server also hosts a website that handles clients and displays data or allows for searching, it might be better to just be satisfied that you have ample headroom, and work on building up your audience. Really nobody could advise you without knowing more about what you are doing, but there is no reason to worry about your cache, until such time as your server becomes IO bound, and you are seeing sluggishness and lots of IOWait, where the machine is doing nothing as it waits on the reading & writing of data.

A couple of comments on your code: function convertTimeFormat($time12Hour){ echo date("H:i:s:A", strtotime("06:40:03 PM")); } First off you are not using the parameter $time12hour. Some smart editors will introspect and alert you to this. You can also typehint your parameter and the return value. Since you require $time12Hour to be a string, it is helpful to add the typehint to the parameter. Also, with functions it is best practice to return a result. You shouldn't echo the result, but instead return it. You can also typehint the return value, which should also be a string. function convertTimeFormat(string $time12Hour): string { return date("H:i:s:A", strtotime($time12Hour)); } Now your example code becomes this: $time12Hour="06:40:03PM"; echo convertTimeFormat($time12Hour); You could also save the function result to a variable,.

Foo/Bar examples aren't helpful in exploring a question like this. I also think you are leaving out a key ingredient when you aren't pairing inheritance with one or more interfaces. Setter/Getter examples are also no helpful when you have __set and __get magic methods available. Where I have seen traits used frequently, is in providing oft repeated exception throwing/handling code. This often includes logging, so you almost always see classes injecting a logger object and then logging out information when exceptions/throwables are caught/thrown. You could also put these routines in a base class, but it's extra work and possibly extra inheritance for something that is necessary but not intrinsic to a specific class hierarchy. Traits and classes are not mutually exclusive nor in my opinion should they be used that way. OOP languages were created in order to help model paradigms and simplify the passing of data, messaging and events between things. Typically it's best to start with OOP, DI and other design patterns, and only when things become particularly odious, or are highly disconnected from the data and behavior you are modeling in the core class hierarchy, would I look for alternatives like a Trait.

They are part of the language. Whenever possible you should always use the built in types and functions unless you have a very good reason not to.

No that is not a php array. That is json. What have you tried? If you don't know where to start, start by turning it into a php array using json_decode. Your actual question doesn't make sense. Average of which values?

Sorry, you are using mysql_query(). It's a waste of time for people to answer questions about mysql_ functions. It was listed as deprecated (which meant you should no longer create NEW CODE with those functions in 2013. As of now, there is no supported version of PHP that has the mysql_ functions. Convert your code to mysqli_ or better yet, PDO, and we'll look at. Probably your issue has to do with your lack of use of WHERE IN ().

The main argument against using 'new' to create objects inside a class, is that it now becomes very difficult to unit test your code, you now have no way of mocking the dependent class. If you use a service container, then you can mock the container itself, so long as you pass the DIC to the class that needs to create the objects internally.

Yeah I missed that key point as well. Your form tag needs to specify method="post"! <form method="post" target=...etc >

Try this: foreach($package->metadata->meta as $meta) { echo "content:{$meta['content']} name: {$meta['name']} <br>"; }

In your form, your form element name= parameters need to match the $_POST[] variable names. They don't match. For example: <input type="text"... name="Name"> and $_POST['name']. The form element name should be name="name".

You need to load the autoloader before you do anything else. It's not optional. The autoloader figures out where your component libraries are and resolves them for you. It should be the first thing you do in your script.

I think you may be confused by the documentation. There is nothing in Gparted about it taking screen shots. Those screen shots were added to the documentation to illustrate the UI.

Hi Slipscream, The journey into development often begins with a story like yours. There is no greater motivation for learning something than wanting to scratch your own itch. Web development is a complicated multi-faceted pursuit that challenges veteran developers in its complexity and scope. When you have questions, we are here.

Nik, This forum has excellent support for code snippets. Just use the <> in the editor, for future reference.

AVI's and MPEG are completely different, so no.

Well, no I don't think that RDBMS's support subtypes, although you can model something involving multiple tables that sorta supports it. I have certainly done this in the past, however, my reason had more to do with wanting to write generic code than it did traditional OOP. For example, I had a model with an entity table that was essentially the base of a class. Entities could be these types: member, channel, vendor, stream. So looking at that, it's not very oop, but relationally it had some major advantages. For example, I required a lot of sophisticated grouping. I had groups that for example, defined for a Member their channels. For a particular channel there could be any number of streams. And for each channel there were groups of admins, moderators, etc. Because I had built this around a base entity table, as soon as I had put in place the grouping tables, and written code to support these things, I already had essentially created what I needed to relate these different types of things together whether that be as members to channels, or channels to streams, or vendors to channels. Then there were assets that could be attached to these things, and again, with a generic set of tables that allowed relation of an asset to an entity, it didn't matter if it was a photo in a stream, or a cover image for a channel, or a video for a product sold by a vendor. Once i created comments and tags, I could comment on or tag anything with tremendous reuse of code and DRY. As for serializer, there are several things it does that are sophisticated, and fit Doctrine really well. First it goes through a complicated object tree and figure out how to turn that into a sensible data structure. There is also support for annotating a model to include/exclude particular attributes in your model. For example, you might not want a rest api to disclose internal key values, and with Serializer, you can annotate your model and serializer will automagically support that for you. Your error was simple, and right off the documentation page really... $output = $serializer->serialize($someEntity, 'json'); echo $output; Of course, if you're just testing this, you want to set the content-type of the page: header('Content-Type: application/json');

ORM's are ORM's -- they can be great if you drink the coolaid and accept their limitations and quirks. I do have to say that I far prefer Doctrine2's Data Mapper pattern to Active Record which is used by most of the other framework ORM's and with Ruby on Rails for example. This is a decent article that touches upon how the Data Mapper pattern is different (and better in my opinion) than Active Record. In general Doctrine2 is more sophisticated and attempts to do much more than the other PHP ORM's. Some of the things you have been attempting to do that involve inheritance aren't even remotely possible in other ORM's without you essentially hacking them. However, relational databases don't provide or support inheritance of any sort, so you are inevitably trying to force a round peg into a square hole. Probably a decade ago "Object databases" were the hot buzzword, and yet it says a lot that none of the many companies and products emerged with anything that gained a critical mass outside of niche applications tightly bound to specific oop languages. Meanwhile RDMBS's continue to dominate persistent data storage.

I am going to guess that you are doing this in order to provide a REST api? Having done this a number of times in the not too distant past, I wired this sort of logic into the controller class. If you subscribe to MVC, which is easy enough to do this via adoption of the symfony framework, then it's fairly easy to create a base controller class that inherits from the Symfony controller class, and into this you can build in things that make your REST api easy to deal with. I mention symfony because you were already using Doctrine if I'm not mistaken, and Symfony already defaults to use of Doctrine. Once you go down this path, then you have the JMS Serializer bundle which handles serialization of complicated object trees into either of json or xml. Even if you don't use symfony, you can still use the Serializer library by itself.

Does your extensions table have a primary key? It would be best to use that to find the row(s) you need to update.

One of my goto linux commands: df -h Gives you the high level filesystem storage availability. du -Sh | sort -rh | head -50 Gives you a report of filesystem use, largest files and directories listed first. The '-50' at the end controls the number of listings. Tweak that as you want/need. Should help you get an idea of where your storage has gone to and what you might be able to delete to clear space.

Json has become ubiquitous in the web development world for a few reasons. When developers started to make heavy use of javascript in order to provide an interactive experience in their web pages, and as Ajax became a prevalent way of supporting interactivity, Json became the preferred way of getting data into javascript heavy apps. Since json is easily converted into javascript objects, this is a lot better than having a server return html or csv or text which then has to be parsed and loaded into javascript objects. Json helped cut out the intermediary steps and required code to either convert javascript objects and data into some other standard before sending it, and provided the same benefit when data was sent in response. As REST Api's became the preferred way of accessing services, more and more of these services defaulted to JSON rather than using the verbose alternative of XML. JSON consumes less network data than JSON, and is certainly simpler to use than xml. Obviously for PHP, json is not a native data type, so you have json_decode() to transform json either into PHP object(s) or PHP arrays() depending on the optional 2nd parameter. It defaults to objects, but often PHP arrays are far simpler to work with given PHP's multitude of array manipulation functions. Conversely, when you need to return json data, json_encode() takes your PHP arrays or objects and turns them into json. Hope this give you some historic context and clarifies a few things.

How dare you sir, besmirch the reputation of the mighty Wordpress!

When you are using PHP as part of a web server through cgi or an apache module, then the http server is handling HTTP (tcp wrapped) connections. This is obviously not what you want. The webserver is in the way, and it is also wired to communicate via HTTP, which is a request/response protocol that is not inherently persistent. So when you create a listening application you have to utilize command line php. Another popular alternative to writing our own socket server, would be to utilize a websocket server. There are some servers out there already, written in PHP. See: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=php+websockets+server&*

Well it appears that whatever you cribbed this from is passing the client_id as a hidden form object. To get things from a POST-ed form, you would use the super global array $_POST. // Add to top $client_ID = $_POST['client_id'];

Ok, but let's look at what you are actually after here. My best guess: foreach($selected_lender as $item) { echo"<br>"; echo $item['types'][6]; echo"<br>"; //echo $item } This is how you would reference an array element of a nested array without otherwise nesting another foreach loop.