Weird discovery: firefox converts $_SERVER, SF doesn’t?
This is definitely up there for me; a very weird discovery about how firefox and safari differ in the way the _SERVER array is returned.
print_r($_SERVER);
exit();
Run that code in a php script; then check the source in both safari and in firefox. For the path, try something like index.php?name=what’sup
The weird thing comes in with the fact that in Safari, the apostrophe isn’t converted/encoded, where as in Firefox, it is. I’m not really sure how I can explain this, and if I’m missing something, but it’s caused me a great deal of frustration and debugging. The only thing I can think of is that safari sends along different headers in the request than Firefox does, and therefore gets different results. I’ll look into it and update this post, but thought it was worth mentioning incase anyone else runs into the same type of problem.
Flexibility: Server side vs Client side
I’ve been told by many people, veterans in their respective industries such as family friends, family members, etc., that when you’re in a technical field, the best type of job security is to specialize. I imagine this would extend to a lot of different areas (entertainment, finance, management, etc.) but especially in the technical/programming arena, I find it’s very true and productive.
What I mean by this is, be very very very good in a very very very specific field/discipline. Be the best out of all the people you know. If you’re a server side developer, don’t try and learn all the server side languages; rather be the best object-oriented php5 developer who knows the ins and outs of PECL and PEAR extensions. Or be the best db admin who can optimize an InnoDB mysql engine better than anyone you’ve met. That way, when anyone is looking for something specific, you’ll be the first person to come to mind.
I’m too obsessive to follow this though. I would hate being really good at one thing, and then just having to depend on someone else to help me out with the other. Because of that, I’m not very very very good in one area, rather I’m pretty good in a bunch of them. But this is actually still making me fall into a very specific niche; namely, if someone is looking for one guy who can configure a linux/apache box, set up and admin a db, set up a server side dev env., do designs in photoshop, turn them into html/css/js, and add in ajax/js techniques to make a more interactive application/website, I’m that guy. If I were to work in a company with other developers, I probably wouldn’t be better than anyone in any specific area. I wouldn’t be the best JS guy, or CSS guy, or DB guy, and because of that I’m probably not suited for a lot of companies, but for my current contract, they needed one guy who can wear 5 or 6 different hats.
So ironically, the fact that I don’t specialize in one specific area, rather 5 or 6 of them, makes me specialized. It makes me the specific person to go to when you need one person who is pretty good in a bunch of areas.
If you read the title, you might wonder what this has to do with it; it’s a segway into my point. On my current project, I’m having to do both client and server side dev., and it’s making me realize something. The server is way more flexible than the client.
—
Here’s why.
—
The server is usually a linux/unix box. It’s role in a web application/site is to fulfill client side requests, push out data, yadda yadda. It normally doesn’t do anything visual. The client, however, is intrinsically visual. It’s supposed to represent a server architecture in a cohesive, logical way. Now when doing client side dev., you have to normally worry about ie6, ie7, ie8, ff3, sf, opera and chrome (not always this, but thats the goal). At times you’ll run into things you can’t do in the others (CSS3, certain types of ajax callbacks, etc.); sometimes they’ll be things that aren’t worth the time, but other times, it just can’t be done. There is no hack or way around it, it just can’t be done. It’s frustrating to say the least, but it’s making me really value and respect the entire web paradigm and the server’s role in it all.
—
How does this relate to my introduction?
—
I find that there is a lot of ego involved in the web industry. A lot of butting heads in terms of how important people/disciplines are in the grand schemes of things. There are the executives/bus.dev. guys, marketing dudes/gals, client side developers, server side developers, operations/db dudes, and creative/design people. That’s generally how I break it down, and with some exceptions, everyone thinks their role is one of the most important ones. They’ll pretend and put on a face that they don’t believe it, but at their core, there is a lot of pretense about their own positions. I suppose that’s normal considering that’s their professional role.
I’ve always maintained (and have a post that should be coming soon) that one of the most important roles, which I’m terrible at and in no way consider myself part of, is in fact the creative/design ones. I’ll leave my reasoning here for another post. My understanding of the flexibility of client vs server side therefore comes from the fact that I don’t specialize in any one area. If I were a operations/db guy, I’d think the db was the most flexible. If I was a pure server side guy, I’d think it was the most flexible, and the same for the client side.
The point I tried to make with my introduction and the conclusion of the server side being the most flexible is that because of my lack of specialization (and therefore abstract specialization) in the full life cycle of a web application, I think I’m in a unique situation to make that judgment. It’s not right or infallible or anything, but I come at it from a unique perspective. My career/financial stability doesn’t hinge on any one area of the cycle. I could find a job doing client side, or server side, or db/operations, maybe even some mild graphic/creative design stuff. Even as far as more on the management and marketing stance, I think I’d be alright. And because of this, I think I’m in a convenient location to sit back, analyze where any bottle necks are in flexibility, and make a call on what makes the most sense and is most accommodating.
And my conclusion? The server side is way more flexible. There is never a point/time when I can’t do something. It might take more time than I’d hope, require more resources (memory, developers, etc.), but at no point do I have to create ‘hacks’. It’s logical and follows procedures and standards. I think this is mainly because it’s been around longer. The server side env. is really just a programming environment. It’s been around, and perfected, since the 50’s. The web client-side has been around, for the most part, for less than 15 years.
That being said, the client side is getting better. With Flash, Adobe Air, Google Gears, and some really cool plugins (Rhino, for one) the client side is trying real hard, and milding succeeding, in become less of a bottle neck for an application. I think with time it will succeed, but as it stands right now, the server side is where it’s at. Fewer headaches, and more logic, make it one of the most time-satisfying parts of the projects I’m doing lately.
Jumping the gun: html5/css3 is not here yet!
On Twitter, I follow a bunch of people in the development arena. JavaScript framework core developers, designers, mysql/php architects, etc. etc. I’d say about 50% of the people I follow are in that arena (the other 50% probably being aggregators or tech news sites/blogs).
A consistent theme I’m finding in the past few months has been css3/html5 posts. They talk about new effects, rules, possibilities, etc. etc. Now I try to be optimistic about web development; I try to practice valid w3c content, semantic markup, everywhere I can. But the age of css3/html5, at least for me, is still so far off. 25% (at the least) of internet users are still using ie6, another 40% are using ie7; that takes us to about 65% of internet users using subpar browsers (ie7 is a step up, but still very much sub-par) that don’t support anything close to css3 and html5.
These browsers are so terrible that I spend about 80% of my client side development time focused on fixing issues I run into there. I write code that is semantic, valid, and based on standards, and then debug it and add in browser-specific fixes for them. Now the reason for bringing up my (and obviously most client side developer’s) hatred for it is because of this sudden (last 4-6 months) pushed towards css3, but even more, html5. Put simply, we’re jumping the gun.
We’re not anywhere near the period of time whereby these standards can be used properly for the vast majority of users. Yes, graceful degradation and progressive enhancement do allow us to make use of them for those vendors that have supplied standards-based browsers, but the time being, maybe only 25-35% of users will get to experience these enhancements. So why put so much effort into transforming your sites and communities to use these standards? Is it worth it?
HTML5 is, believe-it-or-not, a pretty large step forward. While it’s simply an extension of html 4 and more than anything, introduces some different namespaces and tags, I keep coming back to thinking whether we should bother with it right now. It won’t be until IE9 or an IE8 service pack/update that the majority of users will get any use out of it, and for large companies and communities, it represents hundreds/thousands of hours of work, changing your design/style guides, and means often times having multiple code/script bases for different browsers that represent which support html5, and which don’t.
Now I’m coming at this from a freelance/contract developer. I have a task, and it’s in my best interest to make it work in the top 3 browsers (ie6, ie7, ff3) as fast as possible, and as cleanly (the fewer moving parts, the better). I might use some css3, I might use some transparent png’s, but that’s my limit. Going over board with css3 and integrating html5 is not a priority of mine, and would represent extra hours which I couldn’t work into my pricing/rates. I would rather spend my time writing semantic, standards based code, and open sourcing anything and everything I could to help out others; at least until one of the top two browsers supports html5 (ff isn’t there yet, despite many claims that it’s the number 2 browser next to ie7).
This approach by me has it’s problems. Namely, if people don’t push technologies that aren’t yet wide spread, than the major vendors won’t feel as pressured to support them. I understand this, and in many ways, it’s up to the big guys to help push new technologies. But this brings me back to the post’s title. Are we jumping the gun? We’re years away from a top two browser from supporting either css3/html5. So should we spend all this effort, time and money developing for something that most user’s won’t even experience?
There are exceptions to this; if I’m designing an app/site for an intranet where I can control the browser type. Or if it’s for a specific niche (eg. graphic designers, web developers) where I can safely assume or pressure the visitor to use a new-age browser (safari, chrome, ff3). Then maybe I’ll take the time to learn the new semantics, make the site pop like it never could. I’ll spend the extra time, effort and money to create a richer experience. But these are exceptions, not the rules.
These are thoughts/ramblings that have been going through my head for quite some time now. They aren’t polished, they aren’t definite, but they are something that I’ve thought of, and I assume other’s in the community have as well.
While these are my thoughts, and I’ll stick by them for a while, I won’t stop trying to learn about the new technologies. Progressive enhancement, ajax, json, jsonp, and whatever else comes along, I’ll jump into, just like css3/html5, but just like ajax didn’t become popular until XHR became widespread in most browsers, I won’t make use of it (with certain exceptions) until major vendors (m$) decide to give me the tools to do so.
Web/application development is like a restaurant; especially the paying part
Web design/development has always been seen as a service, obviously due to the way it’s delivered. It takes units of time to deliver a set of qualifications that should be met, rather than producing a physical product that is then delivered. The way it normally works is you talk with a client, they have a set of goals/requirements they need met (whether it’s a database being built, a design, or a widget), and you try to deliver them.
This is no different than when you go to a restaurant. You go in, look at the menu (~development services), check out the prices (~rates). You normally learn about the restaurant from a friend (~contact/colleague), and decide ahead of time whether or not you want to eat (~work with) at the restaurant.
So you go in, look over the menu, order your food, wait for it to arrive, and then eat it. Straight forward enough. The difference comes in with the reception of the food (~service/work). If you’re in a restaurant, you’re paying for the service of them preparing the food, not for the actual cost. You don’t go in, order a salad, and they charge you how much the food costs; they charge you for the preparation of the food, and the delivery of it.
So if you go in, eat up your meal, but don’t enjoy the taste or experience, what do you do? Do you walk out without paying the bill? No, you don’t. The reason you don’t is because there is an established trust and relationship between a restaurant patron and the restaurant. When you enter the establishment, and order something from the menu, you are now contracted to pay for the food, regardless of whether or not you enjoyed it.
The reason for this post and analogy is because of how web development services are received. When I develop a design, widget, database schema, PRD, or whatever, I have now started work. We have a contract in place (whether formal or informal) that states/infers that my work warrants monies. I deliver my work to you, and whether or not you are satisfied, you pay me for my time. If you aren’t satisfied, you don’t return, but you pay promptly without complaint about the services. You don’t negotiate, you don’t haggle, you pay.
It’s in my best interest to perform the best way possible; I don’t want you leaving the restaurant (mixing analogy terms now…) thinking the food was terrible, and the service was awful. I want you leaving happy and I want you telling everyone how great your experience was. But if it wasn’t; if you weren’t happy with the food or the service, you don’t just leave or try and argue with the restaurant owner/chef. You can choose not to leave a tip, and choose to go and tell anyone who will listen how terrible the experience was, but you do not leave without paying, and you do not delay your payment.
—
Web development is based on trust, just like a restaurant business. Your patrons approach you to enjoy your services, you perform those services, and they pay you. It’s as simple as that. Clients need to understand that they do not have the luxury of debating and argueing with the services after the fact.
If you go into a restaurant, before you order your food, you can do the following:
- Ask the waiter how good the food is (subjective, obviously)
- Check what the specials are
- Read the menu, see if there is anything you like
- Talk to friends and ask how good the food was, the service was, and how expensive it was
All this being done, you now have a clear idea whether you want to exchange their services/food for your money. Web development should be the same.
The reason’s why it’s not received with the same level of trust as a restaurant is beyond me, and perhaps due for another post, but for now, I think I’ve made a descent enough case towards the problems with clients and their perceptions of web development services (especially the paying part).
php.ini error_log directive: finally fixed my code to make it work
I always ran into an issue whereby if i set the error_log location for an application/server using ini_set(’error_log’,'PATH’) it wouldn’t log it there. It would log it to whatever path was set in my httpd.conf file, whether it was the global error_log path, or one for a specific virtual host.
I searched high and low on the goog’s, but to no avail, I kept running into php.net bug reports about the behaviour not working. Then, I just tried something I should’ve tried a long time ago, set the write permissions properly (for testing, 777) and gave access to every user on my local machine (eg. on a mac, getinfo on the error log, and make it readable and writable by everyone), and success.
I’ve had a lot of headaches around this that usually ended up with me giving up, but I finally found a fix for my case of it 