In his post over on thePHP.cc site Stefan Priebsch talks about hackathons and why they should possibly be considered harmful. Here he's talking about the ones where a project is given at the start and a product is expected at the end, not just general time for developers to hack together on their own projects.

Last month, at a conference in Bulgaria, I participated in a hackathon for the very first time. The task was to build a small REST API for the tracking of shipping containers and a frontend to visualize a container's GPS position. I would like to share some of my thoughts and experiences (and this is neither going to be about the code we wrote, nor about the fact that we won).

He talks about the team that he was a part of and the different pieces they each contributed. He notes one unfortunate thing though: due to time constraints (3 hours), ramp up time and planning of the application, corners had to be cut to make the deadline.

Going back to the hotel, I realized that during the hackathon, the tight schedule had forced us to do pretty much everything that we all know you should not do. And that we had just experienced a "real" project situation: a tight deadline, not enough communication "because we have no time", rushed technical decisions like just using HTTP "because we have no time", doing things quick and dirty "because we have no time". Does that sound familiar to anybody? Exactly: most teams that I have met (and I have met many of them) experience just this on a day to day basis. And it is wrong.

He suggests that hackathons, in this particular format, should be considered harmful as they reinforce bad decision making and poor development practices. He offers some suggestions that could help to make future events better and an offer to provide guidance for those wanting to make a better event.

Ian Selby, working for a startup and building a lot of code up from scratch came across a problem - the upload of pretty large files via PHP:

I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn’t seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation [...] However, it turns out there are some other php.ini config variables that you may need to look at.

The "usual suspects" list includes changing the max_upload_size value and adjusting the script timeout. The other settings he mentions, though, are things like memory_limit, post_max_size and max_input_time to help increase the default times that PHP uses on most page executions.

Ian Selby, working for a startup and building a lot of code up from scratch came across a problem - the upload of pretty large files via PHP:

I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn’t seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation [...] However, it turns out there are some other php.ini config variables that you may need to look at.

The "usual suspects" list includes changing the max_upload_size value and adjusting the script timeout. The other settings he mentions, though, are things like memory_limit, post_max_size and max_input_time to help increase the default times that PHP uses on most page executions.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.