Amazon Cloud Fail

Ouch. I am not glad to see this one. You’ve heard of it by now: Amazon’s cloud services collapse.

And oh yes, I’ve been recommending this kind of service to my clients. Fortunately, they chose Rackspace. Knock on wood….

You can watch the digital history of the event from its beginnings. See “Amazon Server Troubles Take Down Reddit, Foursquare & HootSuite” at Mashable.com: http://mashable.com/2011/04/21/amazon-aws-server-problems/,

then follow to “AWS is down: Why the sky is falling” at http://justinsb.posterous.com/aws-down-why-the-sky-is-falling for a little technical discussion.

Next take the trail to CNN: “Learning from Amazon’s cloud collapse” at http://www.cnn.com/2011/TECH/web/04/22/amazon.cloud.mashable/index.html?hpt=Sbin

Executive Summary: This cloud stuff is in its infancy. There are going to be some (painful) teething pains. Don’t bet your career on this stuff yet, but be a cautious entrant to the game, not a bystander. Ironically, one of the best ways to do this is a free trial of Amazon’s Elastic Compute Cloud.

[UPDATE:

“As technical problems interrupted computer services provided by Amazon for a second day on Friday, industry analysts said the troubles would prompt many companies to reconsider relying on remote computers beyond their control….

…The Amazon interruption … was the computing equivalent of an airplane crash. It is a major episode with widespread damage. But airline travel … is still safer than traveling in a car — analogous to cloud computing being safer than data centers run by individual companies.”

– Amazon’s Trouble Raises Cloud Computing Doubts, at http://www.nytimes.com/2011/04/23/technology/23cloud.html?_r=2

]

 

 

Hitchhiking and security

For your consideration: the following argument.

Hitchhiking

Test question: how many things are wrong with this argument?

Extra credit: how many arguments in the real world does this resemble?

Surprise! “If you have something to hide from the government, don’t use Dropbox”

If you’re old enough to remember him, think of Gomer Pyle as I say this:

Surprise, surprise surpise!

All that stuff you drop in DropBox? Even if it’s encrypted? The Federal Government Sez: All your data are belong to us. See the article and the great graphic at http://www.zdnet.com/blog/government/if-you-have-something-to-hide-from-the-government-dont-use-dropbox/10283?tag=nl.e620.

If you haven’t been a student of mine, let me emphasize: the exact same thing is true of your Yahoo or Google email account. Unless you’re paying for (some degree of) privacy on these services, your email is being indexed. And it’s searchable. Not by you, though. Only by other paying customers: advertisers. Please, do think about that.

I’ve had some trouble communicating this to people and organizations that transfer sensitive, or potentially sensitive in the face of a lawsuit, information. Unfortunately people are largely behind the curve on this issue, and won’t believe there’s a problem until somebody gets stung, hard. Which won’t be long, I’ll go out on a limb to predict.

(Thanx and a hat tip to info insider Herbbie)

Put a dynamic image on the PHP page

Put a dynamic image on the PHP page

What we’re doing in this task:

We’re inserting some more complex content in the page, in the form of an image and a table.

We’re using PHP instructions to determine what image gets displayed.

1. In Dreamweaver, open simple.php and go to Design view.

Create the static version of the page:

1. Insert a simple table, one row, two columns.

2. In the left cell, insert coffeemaker_widget.gif (in the widgetpix folder).

3. In the right cell, type “Automated coffeemaker”.

4. Upload and preview (be sure to upload the widgetpix folder as well!).

Make the image dynamic:

5. Go to Code view.

6. At the top of the page, add a variable declaration for a $widget variable, assigned the value of coffeemaker. Your code above the HTML tag should look like this:

<?php

$user = “George”;

$widget = “coffeemaker”;

?>

In the <img> tag, put PHP instructions in place of just the word “coffeemaker”:

7. In the <body> section of your code, find the <img> tag. It looks like this:

<img src=”images/coffeemaker_widget.gif” width=”200″ height=”187″>

8. Change it to look like this (new code is in purple):

<img src=”images/<?php echo $widget ?>_widget.gif” width=”200″ height=”187″>

9. Go back to design view.

See how the image now appears with a special dynamic image icon? In Dreamweaver, the lightning bolt always means there’s server-generated (PHP) code present.

10. Select the dynamic image and examine the Property inspector. See how the PHP code shows up as part of the Src field?

11. Select the text in the right-hand table cell (Automated coffeemaker) and go back to Code view.

12. Change the code for this text so it uses the PHP variable:

Automated <?php echo $widget ?>

13. Upload and view the served page to see how this code gets translated back to usable HTML.

14. Back in Dreamweaver: Add another table row.

15. Copy the dynamic image to the second row.

16. Go to Code view.

17. Add a PHP line changing the value of the variable. Your code for between the table rows should look like this:

<tr>

<td><img src=”images/<?php echo $widget ?>_widget.gif” width=”200″ height=”187″></td>

<td width=”100%”>Automated <?php echo $widget ?> </td>

</tr>

<?php

$widget = “mixer”;

?>

<tr>

<td><img src=”images/<?php echo $widget ?>_widget.gif” width=”200″ height=”187″></td>

<td>Automated <?php echo $widget ?> </td>

</tr>

18. Upload and browse.

Why did we do this?

We saw that PHP code can even be plugged inside an HTML tag, to replace an attribute.

We learned about dynamic images, and how Dreamweaver displays them.

We saw how changing a variable and repeating the code that displays it can create multiple different items on the page.
This is the essential mechanism used for displaying multiple items from a database (what we’ll be doing in our following
exercises).

Put PHP code inside other HTML tags

What we’re doing in this task:

We’re integrating PHP-generated content even more tightly into the HTML content of the page, and learning the power of re-using variables.

1. In Dreamweaver, open simple.php and go to Design view.

2. We want to include the user’s name in the welcome statement, so change the heading to look like this:

Welcome to My Simple Page, User!

3. Go to Code view.

4. Select the entire second PHP tag (echo $user), and Edit > Cut.

5. In the heading, select the word User and delete it; then paste the PHP code in its place.

The result should look like this:

<h1>Welcome to My Simple Page, <?php echo $user ?>!</h1>

6. Upload and view the page … check the source code.

Back in Dreamweaver … we can use this code anywhere:

7. Go to Code view

8. In the <title> element, we want the page title to be “George’s Simple Page” … so change the code to insert the php tags …

<title>George’s Simple Page</title>

<title><?php echo $user ?>’s Simple Page</title>

9. Upload and preview again

Why did we do this?

We learned that php tags and instructions can be inserted anywhere within the HTML, in place of static data.

We learned the value of defining information at the top of the page, and then using it multiple times in the page.

Put PHP code above the HTML tag

What we’re doing in this task:

We’re adding PHP code to be processed before any of the HTML page is read.

We’re learning how Dreamweaver will structure the PHP code it writes for us.

1. In Dreamweaver, open simple.php and go to Code view.

2. Move the variable declaration to its own PHP tags, above the HTML tag. So the code for your page looks like this (PHP code is bold):

<?php

$user = “George”;

?>

<html>

<head>

<title>Simple Page</title>

</head>

<body>

<h1>Welcome to My Simple Page!</h1>

<?php echo $user ?>

</body>

</html>

3. Note that the variable declaration can be anywhere, as long as it’s before the echo statement that calls on the variable.

4. Note also that the echo statement can be displayed on one line, and without a semicolon.

This is perfectly allowable, and very simple statements are often written this way … whatever makes the code easiest to read, multiple lines or one line.

Because there’s only one statement, we can remove the semicolon also.

5. View the page in Design view. Note that the code above the HTML tag is not displayed anywhere here; just the code in the body tag.

6. Upload and view … the page should work the same as it did before.

Why did we do this?

We learned that pages can have as many PHP tags as they need.

We learned that the different sections of PHP code share information.

We learned that it’s perfectly valid — and common practice — to put PHP code entirely outside the HTML tags; things that will be used in the rest of the page are often placed here, so they’re sure to get processed before they’re used.

We learned that PHP tags can be “inline” or multiline.

Create and use a PHP variable in the simple page

What we’re doing in this task:

We’re learning about the concept of variables and how they’re used.

We’re learning what variables look like in PHP.

We’re expanding what we know about the echo command (it can use variables).

1. In Dreamweaver, open simple.php and go to Design view.

2. Select the PHP icon.

3. In the Property inspector, change the code to this:

$user = “George”;

echo $user;

(Note that when you’re working in the Property inspector, Dreamweaver doesn’t show you the PHP tags; also, there’s no color coding to help you spot problems.)

4. Go to Code view and make sure your code looks right … and see the color coding.

5. Upload and view the served page; check the source code to see how PHP instructions have been translated into HTML code.

Why did we do this?

We learned what variables are — they are core to the whole PHP scripting functionality.

We learned how to recognize PHP variables in source code (they always start with $).

We learned how to use the Property inspector to view and edit PHP code.

Put a PHP command into the simple page

What we’re doing in this task:

We’re seeing how PHP instructions work within the HTML structure of a page, and how to embed the PHP code.

We’re also learning another very simple PHP command: echo

1. Change the file extension of simple.html to simple.php

(Windows users: it’s important that your computer show file extensions, so you can see exactly what type of file you’re dealing with.)

2. Open simple.php.

3. Go to Code view.

4. Change the body code to look like this (new code is in boldface):

<h1>Welcome to My Simple Page!</h1>

<?php

echo “Hello from PHP”;

?>

5. Look at the page in Design view.

The PHP icon shows where the PHP code is.

6. Select the icon, and the Property inspector shows you what’s inside the PHP tags. (You can edit it from here if you want.)

7. Preview in browser (local); you won’t see the dynamic content properly.

8. Upload and preview the served page.

You see the hello message on the page.

9. In the browser, view source. Note how the PHP code has been stripped out and replaced.

(That’s part of the whole HTTP request process.)

Why did we do this?

To see how PHP and HTML code work together, and how they are processed together.

To see what PHP code looks like in Design view.

To learn about the echo command. This command is used a lot. It’s how PHP puts information into the HTML page.

Create a PHP information page

What we’re doing in this task:

We’re making our first PHP page.

We’re seeing how the .php file extension works.

We’re watching the HTTP request process work for PHP pages (as discussed earlier).

We’re making sure we can connect to the PHP engine (the application server software) on the server.

And we’re also learning how to create a simple test page that you can use with any web server, to see if PHP is installed and running.

1. Create a new page, named phpinfo.php

2. Open the file and go to Code view.

3. Select and delete all code there.

4. Type in this new code:

<?php

phpinfo();

?>

5. Preview locally (by pressing F12). What do you get?

6. Upload the page to the remote site and view it as a served page. The URL will look like this:

http://192.168.1.109/~webuser00/dwphp/test.php

We have contacted the PHP server … what about this file made that happen?

A. The .php File Extension

Try changing the file name to phpinfo.html and uploading it and viewing it.

B. The PHP tags

Try changing the file name back to phpinfo.php, deleting the opening and closing tags, and uploading for viewing.

C. And of course valid PHP

Try putting some random stuff in there, and see what you get back — this is often what happens when there’s an error .

Also try simple case sensitivity or spacing errors, to see color coding in action.

With all of those things in place, the HTTP server passed what was inside the tags to the PHP server.

(NOTE:Dreamweaver color coding supports this, only showing up when everything is in place.)

Why did we do this?

If you get the PHP info page, that means PHP is running on the server and that you have successfully connected to it.

It tells you lots of things about PHP that we don’t need to worry about … but specific configuration information that you might need when you’re a more advanced PHP developer.

We can also see how the dynamic process works:

send PHP instructions

get processed HTML back

And we can see what elements a PHP page needs (the file extension, the PHP tags)

And we need a valid PHP function … and we’ve seen what some valid PHP code looks like:

a function has ()

a line ends with ;

code is case sensitive

Create a simple page

Create a simple page

1. In Dreamweaver, create and open a new file, called simple.html.

Put very simple content into it:

Page title: Simple Page

Contents: a Heading 1 formatted line, “Welcome to a Simple Page”

Test the page: Preview in Browser (F12)

Note that the URL in the browser’s address field starts with the protocol “file://”. This tells your browser to get a file from the local file system.

2. Upload the page to your remote site.

3. View the served page.

Do this by going to the browser and typing in the following URL:

http://192.168.1.109/~webuser00/dwphp/simplepage.html

By typing in the HTTP protocol (http://), you’re sending an HTTP request to the HTTP server software (on lab server, this is Apache)

Remember the discussion earlier on web page processing: a lot more is happening behind the scenes when you send an HTTP request than when you send a file request.

Why did we do this?

To see the difference between previewing served pages and previewing locally;

to make sure our site can be served;

and to demonstrate how to send an HTTP request that will serve our pages back to us.