ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
[1]  «  1  2  3  4  5  6  7  »  [71]

What is needed to REST in Symfony2

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed. The following is not an exhaustive unordered list and also not detailed enough but just something to illustrate where I feel there is still work left:
read on (comments 6)

Good design is no excuse for wasting time

Symfony 1.x I would put into a category of frameworks focused on RAD, aka rapid application development. There are many other frameworks I would put into this category like CakePHP, Yii, CodeIgniter. All of these frameworks have their roots in the pre 5.3 days of PHP. I say this mostly because there has been a considerable shift in development methodology since then towards more decoupling and application of design patterns. As such these older RAD frameworks to me cut corners to be able to focus on the use cases they wanted to focus on. Now this is a quite legitimate approach, we all know that in order to make a solution truly generic it takes a considerable increase in effort and complexity. So focusing on 80% of what web developers need to do on a daily basis makes sense. This is mostly achieved by providing either base classes or the ability to use configuration files and conventions to reduce the amount of code needed to achieve functionality. However these frameworks tend to become quite painful when dealing with those other 20%. At that point they can actually become a hinderance and so you start to loose some of the benefits you gained for the 80% you worked on before. With Symfony2 we took a different approach. I would not call it a rapid application development framework. All it really does is add some more high level abstractions but it stays short of providing an out of the box solution. You still need to write the code and that code tend to be very explicit.
read on (comments 9)

Where have all the core devs gone?

Symfony2 is without a doubt a very lively open source project. No small part thanks to Github, there is a flurry of tickets and more importantly pull requests coming in daily with dozens merged every week. These changes cover everything from small typos, to bigger refactorings, new test cases, documentation, performance optimizations. What even more positively stunning is that while there are a bunch of "usual suspects" the bulk of all of this comes from people that just submit the occasional change. Which means we have managed to make the community very inviting for new contributors. Something many other open source projects struggle with. So in a way one could say all is well. However I think its also important to define a direction for a project as a whole. I guess at a high level we are fine there too. We rarely have fundamental issues with determining what should go into Symfony2 and what should not. But what I feel is severely lacking is a prioritization and focus what should be happening within the next few months.
read on (comments 7)

On predictable PHP release cycles

There is currently a vote going on to include Zends Optimizer+ opcode cache into PHP core. I am very happy with finally adding an opcode cache to the core distribution if only because it then forces to actually ensure that there is a working opcode cache together with every new release. What troubles me though is that its being proposed very late in the game for PHP 5.5, therefore causing a likely delay of 5.5 of at least about 2 months in the best case scenario if it were included. The other option of including it in 5.6 does not seem to be as popular at this point. This saddens me quite a bit since I believe that predictable release cycles would carry several advantages. First and foremost it will ensure that developers that propose a new feature will have a better idea of when their feature will be part of a release. This can encourage developers to actually bother with sharing code and it also prevents developers from getting disgruntled if their feature is deemed not yet ready for the upcoming release or even more importantly prevents half baked solutions from being pushed in just to prevent an unknown further wait time. Furthermore it makes it easier for PHP end users, especially larger frameworks and application maintainers, to plan their releases. Finally it poses the chance that distributions will better schedule the freeze time for PHP versions, rather than the current rather random choice they tend to do.
read on (comments 7)

Liip is where I want to be!

This summer I took 2 months off to figure out what I want to do in the coming years. After over 5 years in Switzerland it seemed prudent to take a step back from the daily routine to ponder things. I wrote a lengthy blog post about the options I was considering a while back and as I never really gave an update on the results I just wanted to point out that I decided to stay with Liip. I wrote up a long blog post about what I did during those 2 months over on the Liip blog. Just wanted to post this since I have been asked quite a bit by people about this.
read on (comments 0)
[1]  «  1  2  3  4  5  6  7  »  [71]