Too much news in just three weeks…
I'm now managing a small team of 3 developers and sysadmin — great guys, seems to be a good team, so far at least :)
I didn't think that managing role would require so much work, but it's fair — responsibility is so much higher.
We've got our own quite room with AC, new furniture and decend sound system, each web-developer has a fresh modern PC (Intel Core 2 Duo + 2GB RAM) with a dual 19″ monitor configuration. During the day we listen to sky.fm new age channel which keeps us from talking to ourselves loudly and makes the atmosphere a little bit more comfortable.
Me and two php developers started a reasonably small PHP/MSSQL WEB2.0 web-app project (200 man hours approximately), and our sysadmin started doing things that have been planned for ages but I never had time to look at them or research, and that's so cool to get things done in time!
I've signed for a fogbugz 45 days trial — that's an awesome piece of project management software with evidence-based scheduling approach to estimating and project release date prediction. I'll prepare a separate post about this when we get our web-app project done, but the only thing I can tell for now — it just rocks! We are going to buy a server license as soon as our trial expires :)
As we have Windows on servers and workstations, I decided to set the following list of software to be our company-wide standard for PHP development:
- Windows XP Professional — our OS standard, the most cost-effective system with such a small price for such a great level of integration
- Eclipse PDT as a PHP IDE. It's free, has got all the basic IDE features and a good subversion SVN plugin Subclipse. It's definetely not Visual Studio 2005, but still very good
- VisualSVN Server — free and easy-to-use subversion-based SVN server which has MMC snap-in and that's very handy in the complex AD environment we have
- previously mentioned fogbugz — genuine project-management and bugtracking software
- PHP5.2 (FastCGI) + Windows Server 2003 IIS6
- Freemind — free and simple mindmapping tool for brainstorming and technical specification drafting.
So without the FogBugz (and Windows XP which would be installed anyway) the whole PHP development infrastructure costs nothing! Awesome! And FogBugz pricing is very reasonable for such a functionality!
So the project has started, well see how it goes and that's going to be my trial as a manager.
We are also trying to move away from virtual hosting to our own dedicated servers to get as much control over our environment and to gain as much integration opportunities as possible.
So as we have 3 geographically remote offices (London, Moscow and Volzhsky), I had the goal of joining the offices into one secure transparent network with failover capability.
We got D-Link DFL-800 firewall installed in each office. This is a hardware firewall with 2 WAN ports and VPN client/server support. Each office has got 2 internet channels from separate ISPs and all three firewalls are connected to each other with 2 VPN channels — one on first ISP and another on the second ISP, so even if 3 links fail, network link between the offices is still alive.
Routing is configured in a way that any machine from any network can access any other machine in any other network as if it was sitting just next to it.
Next thing I had to do was moving the website from virtual hosting (protechweb.co.uk) to a dedicated server. Next post describes the process I followed.
While writing the post about forms values persistence, I noticed that browsers handle back button in different HTTP situations differently.
HTTP 1.1 spec says the following:
13.13 History Lists User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.
So it clearly recommends UA authors to separate history list and cache behaviour. So if user navigates through the history list (using Back or Forward buttons), HTTP spec recommends to show the exact response that the user saw before, regardless if it's stale or expired.
I've tested 4 major browsers — IE, FF, Opera and Safari, and here is the summary table:
|Expires in the future +
Conditional GET validators
|no request||no request||no request||no request|
|Expires in the future||no request||no request||no request||no request|
|Conditional GET validators||no request||no request||no request||no request|
|no HTTP caching headers||no request||no request||no request||full request|
|Expires in the past||no request||no request||no request||full request|
|Cache-Control: no-store||full request||full request||no request||full request|
|Cache-Control: no-store +
Expires in the past
|full request||full request||no request||full request|
|Page served with||IE8||FF||Opera||Safari|
So we can see that only Opera follows HTTP 1.1 recommendation.
Obviously IE and FF don't produce a request when HTTP caching is not explicitly prohibited which is against the HTTP spec recommendation, but this was done intentionally asauthors usually prohibit caching for a reason and don't want users to view those pages without revalidating.
And Safari just does the full request whenever the page is not cached explicitly.