We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.
Storing information locally on a user's computer is a powerful strategy for a developer who is creating something for the Web. In this article, we'll look at how easy it is to store information on a computer to read later and explain what you can use that for.
The main problem with HTTP as the main transport layer of the Web is that it is stateless. This means that when you use an application and then close it, its state will be reset the next time you open it. If you close an application on your desktop and re-open it, its most recent state is restored.
This is why, as a developer, you need to store the state of your interface somewhere. Normally, this is done server-side, and you would check the user name to know which state to revert to. But what if you don't want to force people to sign up? This is where local storage comes in. You would keep a key on the user's computer and read it out when the user returns.
We who work on the Web live in wonderful times. In the past, we did of lot of trial-and-error learning, and the biggest hurdle was getting people to understand what we were on about. Over time, companies like Google, Yahoo, Skype, Facebook and Twitter managed to get the geeky Web into the living rooms of regular people and into the headlines of the mainstream press.
Now more than ever are there opportunities on the Web for you, as a professional, to be seen and to be found. I am a professional Web spokesperson for a large company, and I spoke at 27 conferences in 14 countries last year. I write for several magazines and blogs and have published a few books. When people ask me how I got to where I am now, my standard answer is: by releasing stuff on the Web and by listening and reacting to feedback. And you can do the same.
In this article, I'll introduce you to the fundamentals of PHP. We'll focus on using PHP to access Web services and on turning static HTML pages into dynamic ones by retrieving data from the Web and by showing different content depending on what the user has entered in a form or requested in the URL. You won't come out a professional PHP developer, but you'll be well on your way to building a small page that uses Web services. You can find a lot of great PHP info on the Web, and most of the time you will end up on PHP.net itself. But I was asked repeatedly on several hack days and competitions to write this quick introduction article, so here it is.
PHP is a server-side language that has become a massive success for three reasons: it is a very easy and forgiving language. Variables can be anything, and you can create them anytime you want. It is part of the free LAMP stack (Linux, Apache, MySQL, PHP) and thus available on almost any server you can rent on the Web. And it does not need a special editor, environment or build process. All you do is create a file of the .php file type, mix PHP and HTML and then put it on your server for rendering.
Lately I have been getting bored and annoyed with people getting up in arms against Web standards and the ideas of progressive enhancement, claiming that they hold us back from creating a rich, beautiful Web. There are also claims that these tools limit us from pushing the boundaries of what is possible with today’s technologies.
The problem with claims such as these is that they are based on a misunderstanding of standards and progressive enhancement and ― at least to me ― on arrogance and ignorance about what our job on the Web is. The Web is out there for everybody and is a product and a medium like any other.
For example, I am a big film buff and love good movies. I also understand, though, that in order to fund great movies we have to make money from terrible ones that appeal to the lowest common denominator or rehash ideas that were successful in the past.
I thought I could not be out-geeked. With a background in radio, and having dabbled in the demo scene on the Commodore 64 and hung out on BBSes and IRC for a long time and all the other things normal kids don't quite get, I thought I was safe in this area.
Then I went to my first WhereCamp, an unconference dealing with geographical issues and how they relate to the world of Web development. Even my A-Levels in Astronomy did not help me there. I was out-geeked by the people who drive and tweak the things that we now consider normal about geo-location on the Web.
Pulling out your phone, find your location and getting directions to the nearest bar is easy, but a lot of work has gone into making that possible. The good news is that because of that effort, mere geo-mortals like you and me can now create geographically aware products using a few lines of code. So, let's give the geo-community a big hand.
If you look at some of the code that has been released, though, we do seem to have taken a step backwards. In gaining easier access, we also became a bit sloppy with our code. Finding clearly structured, easy-to-maintain jQuery code is quite tough, which is why many plug-ins do the same thing. Writing one yourself is faster than trying to fathom what other developers have done.
Almost every movie has a scene in which a character pull the protagonist aside and says, "There's something you should know about [insert another character's name here]." Most of the time, we find out some dark secret about a supposed friend of the protagonist or that the main ally is actually an evil overlord. This is that moment, and I am here to tell you a few things about our friend in the Web 2.0 world: AJAX.
We seem to have AJAX licked. The Web technology is ubiquitous, and libraries and frameworks make it dead easy for us to create highly interactive Web applications and to spice up our static pages and blogs.
Having this much choice makes it easy for us to pick and choose, which is where things go wrong. In most cases, we measure the quality of a solution by its convenience to us. Our main reasons for picking one solution over another are: Does it do what I need it to do? Does it look cool? Does it sound easy to use? Would I want to use it? Does it use the framework I'm committed to?