If you get this error:
src/freeglut_internal.h:111:39: fatal error: X11/extensions/XInput.h: No such file or directory
This might save you some time searching for the correct dev packages to install. The package it is in in the Debian repositories is called
x11proto-input-dev, but it contains the file XI.h which contains the correct headers freeglut is including. Symlink the file and you’re good to go.
cd /usr/include/X11/extensions && sudo ln -s XI.h XInput.h
In my previous blog post, I told you about hosting local package repositories for composer. Me, or to be honest, my colleagues, weren’t too excited about the performance gains. So I decided to dig in a bit deeper.
When you’re developing a lot of symfony projects with a relatively large set of dependencies, sooner or later you’ll get annoyed by performance issues. By default, composer uses packagist.org to get package metadata (what versions are available and where to get them from). All packages are part of packagist.org by default, but 9 times out of 10, you’ll only need a fraction of that.
So, to gain performance, I decided to generate a local package repository which only contains the package info for the libraries I regulary use.
If you’re like me, you like gui’s as long as they don’t push you in a direction other than your train of thought. Whenever the tool tends to distract you from the task you are performing, you get annoyed. Stuff like “why am I searching for such an over-obvious functionality”, or “why didn’t they think of making the clickable area a bit bigger”, or simply “aaaarggghhh, it crashed on me again”.
In my most recent blog, I wrote about how I feel that too much of the world’s logic is coming onto the shoulders of PHP, these days. Today, I’m will be showing you why and how PHP’s powers could be harnessed better and more. We, as PHP web developers, should be absolutely fully aware that we’re allowing insane amounts of processing power to do too much work when it’s absolutely unnecessary to do so dynamically.
Some thoughts and ponderings on how “the frameworks out there” might not do it just as right as they should.
The UNIX principle applied?
Something that is currently overlooked in a large part of the PHP community is that not all design patterns are necessarily implemented in PHP code. Your webserver can be considered the front controller of your application too. Routes can be defined using your filesystem and webserver configuration. Not everything has to be Object Oriented to be well organised and well structured. To gain perspective, here are some ideas to think outside the box, and not have OO patterns drive you beyond reason.
First, I saw the documentary Ecstacy of Order. Then I thought of great things, like building 3D Tetris in HTML5 canvas. I started it, just typing away, of course only Vanilla JS. But after a few hours, having the simple Tetris basics covered, I got bored and stopped.
But wait, there’s still hope! I thought I could write a post about me thinking of awesome stuff, getting the basics working and then never finishing it. So I started typing this post, but halfway through, I decided that the basics are good enough. And that the basics are worth posting too.
Sorry if I disappointed you. Have fun reading the code The gameplay is not that interesting.
If you’re getting started with Symfony2, you’ll get something running pretty quickly. The AcmeBundle contains some of the basic features you’ll need when writing a Symfony2 app. The basics lie in the MVC paradigm, so there is some model (Doctrine ORM), some view (Twig templates) and some controllers.
However, none of that is the real core of Symfony2. The most interesting part lies in two main components of the framework. First, the HttpFoundation component and second, the Service container.
.pfx file and need to install an SSL certificate with this? Here’s how I did it. You’ll need to extract the signed public certificate (public key) and the private key without passphrase.
Since PHP5.3 we have closures. The concept behind closures is unbelievably powerful, and even though PHP has struggled with the concept of typing, callables and whatnot, the main concept of closures remains: passing logic in stead of data, or even: as if it were data. In my previous post I argued that functional and declarative programming will prevail over pure OO on the long run. This post proves another example of why.
Posted in Development Tagged FP, phpunit