Previously, I've discussed working with date and time values both server- and client-side, and I've covered storing temporal data in databases. This time, we're going to talk about telling time.
I've already talked about working with date and time values on both sides of the web stack. However, in web development, we not only manipulate temporal values, we often need to store them somewhere and retrieve them later. This post discusses the best methods of persisting dates and times in databases.
Date. Let's discuss them.
Time is omnipresent in software development. Pretty much every web application works with it in one way or another. Even the simplest blogging platform stores "when" a post should be published and then displays and sorts them using that information. While you might not run into any issues when developing a blogging platform, any more complex system can easily expose how complicated time actually is. Because time is complicated. And yet, many standard libraries in programming languages only give us a limited arsenal to tackle it.
I love Nette Framework's dependency injection solution. I really do. This post is here to share this passion, explaining why I think it is the best DI solution in today's PHP ecosystem.
If you are developing a library that needs to make HTTP requests, here's how not to make it difficult for your consumers.
If you've ever implemented an HTTP API in PHP, you probably know that there's one thing you have to do over and over and over: parse the request body and validate the resulting structure. Now that we have PSR-15, let's use a middleware for that!
They say you should understand floating-point precision by 35.0000000000014. This post is here to help you: it discusses how floats are (im)precise and why, demonstrates the problems you inevitably encounter when doing math with floats, and presents ways to prevent those problems by using more proper data types and structures.
There's a new buzzword on the PHP block: frameworkless. The activities of PHP communities last year made it possible to build robust applications, uniquely composed of little bits, without relying on a big framework. Let's find out how they work and if it's a good approach.
As the business requirements grow, so does the list of dependencies. Managers ask for a new feature, you just composer-require this thing and that other thing, and wire it into the application. But how do you keep track of new features in the dependencies? Or bugfixes? Or, most importantly, security patches?!