Apple’s Safari web browser was upgraded to version 4 yesterday and with it came an update to the developers tools first introduced in Safari 3.1. The new version is set to give Firefox’s FireBug plugin some very serious competition. Not only does the Development environment look and perform very well, it’s also very full featured.

In the toolset we find inspection of HTML and CSS, JavaScript debugging, page load profiling tools and a Databases inspection tool presumably for HTML 5’s offline storage support. There are also tools to disable caching, spoof user agents and more from the handy Develop menu.

Inspecting Pages

When designing a new web page frequently plenty of time is spent making minor changes, updating the server and then checking the results in the web browser. This three stage process slows down the design process and hampers the creative flow. Page inspection tools allow you to review and edit your page live in the browser, allowing you to easily try out different CSS rules or HTML edits until you know what you want. And what you see is literally what you get – your preview is the actual web browser.

Safari 4’s “Web Inspector”, shown with Develop / Show Web Inspector, is Apple’s take on page inspection. Reminiscent of Firebug’s equivalent, the inspector area attaches to the bottom of the Safari window. On the left hand you get the HTML for the page and on the right hand you get the full hierarchy of CSS affecting the currently selected element. By choosing the magnifier icon you can click on any element in the page – a headline, an image, a paragraph – and bring it into focus in the HTML view. The same can be done by selecting tags in the HTML source code directly.

When an element is selected it is outlined in blue in the page. A light blue box shows the dimensions of the element itself and a darker blue box behind it outlines the element with margins included. This is helpful when an element is not positioned where you want it or it’s the wrong size. The blue boxes will let you know if the problem is with the margins or if there is something else going on.

Once you have a theory of what you’d like to change you can go in and edit the effective CSS directly using the Styles panel on the right hand side. For instance you could tweak the font-size by double clicking the font-size value and typing in a new number. A set of checkboxes also allow you to toggle individual CSS rules on or off to see how that affects the page as a whole. A great tool for hunting down what CSS rule is doing what. For each section in the Styles panel you also get the responsible selector and the CSS file it comes from, making it easy to copy your changes back to the original style sheet when you are done with your edits.

The CSS editor is well designed but it does not seem to allow adding new CSS rules live, a feature available in FireBug.

What’s Taking so Long?

Another important consideration when designing a website is the page load time. Safari 4 boosts a slick looking Resources inspector which gives the developer a breakdown not only of how long each JavaScript, CSS or image file took to load but also when each download started. All of this is shown in the context of the whole page load from the first millisecond to the last.

By laying the load time out in a timeline various sources of delay can be tracked. For example in the screenshot above the main document takes just short of half a second to load. We can also see that the CSS file request goes out even before the main HTML is finished loading, as Safari finds the CSS link in the header almost immediately. For each bar the semitransparent section is the latency – the time until the first byte of the response. So in the above case we can see that the latency makes up the majority of the load time. We can also see that the two images used on the page are loaded concurrently and that they start loading immediately when the CSS has been retrieved. Finally the colorful bar on top breaks the total load time down by type and lets us know the whole page finished loading in 1.2 seconds.

Individual resources can be inspected, allowing the developer to review the size and contents of each resource. In the same section the request and response headers can be reviewed. This is useful for the web server administrator in order to determine compression status and cache expiration headers. Strangely enough POST parameters don’t seem to show up which could be a serious problem for debugging.

Breaking Into the Source

In the web 2.0 age, JavaScript is almost as important as the HTML and CSS that make up a page. Luckily Safari 4’s JavaScript debugging facilities give you a window into your code as it runs. You can set breakpoints, step through source code and inspect the call stack and variables as you go along.

When a page has been loaded the Scripts tab shows the various JavaScript resources available on the page, by source filename. When a file has been selected the JavaScript is displayed with syntax highlighting and line numbers. Clicking on a source line number sets a breakpoint. Once the targeted code executes Safari automatically launches into single step mode, allowing for the usual controls: Step Over, Step Into and return (called Step Out). At each step you can also inspect the values of the variables available in the scope.

There is also a Console feature which not only shows console messages and errors generated by your JavaScript during runtime but allows you to run commands live. Need to see what happens if a certain variable has a different value? Just set it using the console and watch the results unfold in the active web page.

Step Behind the Scenes

Safari 4’s Develop menu reveals additional tools and utilities useful for debugging and inspecting a web page. Enable or disable caches, images, CSS or JavaScript to see what the page looks like in a degraded state. This allows you to make sure the web page looks good even without images for instance, a great utility for making sure your website is accessible for persons with disabilities. Toggling JavaScript is also an obvious boon when you need to make sure your software runs in text browsers or where JavaScript has been disabled for security or performance reasons. There is also a “Snippet Editor” which seems to allow easy previewing of HTML snippets.

There are some flaws. Two were mentioned above: there does not seem to be a way to inspect POST data, important especially when debugging AJAX, and it does not seem possible to add new CSS rules dynamically as you could in FireBug.

There is also a selection bug: when the Web Inspector is revealed, selecting any text on the page causes the window to immediately scroll to the bottom. This subsequently selects all text on the page below where you started to select. Another bug is that if an element is selected such that the blue outline boxes show up, switching tabs sometimes left the outline hanging around in the other tabs too, now not highlighting anything in particular. Finally the JavaScript debugger seems to freeze up JavaScript in every Safari page – not just the one you are working with. This makes it hard to work with say an online reference in a different window.

A more minor flaw is a missing feature. There is no page optimization analysis tool such as Yahoo’s YSlow or Google’s Page Speed. These tools help analyze pages for performance problems. For example they check for additional compressibility in images and for correct headers.

These flaws aside the Development tools found in Safari leave little to be desired. All the features you expect are there and the package is polished far beyond what’s ordinary for web development. Apple has clearly been looking to FireBug when picking their features and that’s a good thing. FireBug has for a long time been setting the standard for these kinds of tools, but has been suffering from engineers’ syndrome: heaps of features but with little mind to UI design and detail polish. Safari 4’s development environment meets nearly all the same requirements and does it in style, bringing an excellent choice to the web developer’s toolbox.

Read more about the new developer tools at Apple’s What’s New page.

Author: Alexander Ljungberg Tags: Apple, CSS, development, FireBug, FireFox, HTML, JavaScript, Mac OS X, performance, review, Safari, web

Today when I logged into Google Docs I discovered that I had a new document. With Google Doc’s collaboration feature, this is nothing shocking. What was weird was the following:

• I don’t know the person who shared the document
• I never received any notification regarding the document

When looking closer I saw something really interesting. The document was shared with ‘Everyone.’ I immediately became curious about this and tried to replicate this myself, which I unfortunately failed.

I have no idea what the person sharing the document did to accomplish this, but it’s a quite serious problem. Somehow I do not think the person sharing the document intended to share it with ‘Everyone.”

After talking to a few other Google Docs users, the document does not appear to be shared with everyone. Please let us know if you see the same document in your Docs too.

Author: Viktor Petersson Tags: Google Docs, security, web

You guys may have noticed a minute or so of downtime for the blog in the hour that passed. Sorry about that. We had a huge spike in traffic recently and the blog slowed to a crawl for a while, running in an old VM with too little memory as it was. Today we moved it to a new snappier server and did a bunch of other optimizations so that won’t happen again.

Anyhow, we hope you will enjoy the faster page loads!

Author: Alexander Ljungberg Tags: blog, maintenance, performance

Recently we hooked up with Zendesk for our support system. We hooked up its Remote Authentication API so that our customers could use their YippieMove logins in our support system as well. Jon Gales provided a great recipe for doing this in Django which we kicked off with, making some minor updates too. Only one problem remained: if an account had international characters in the first or the last name, Chinese, Japanese, and so on, the code would error out.

Here’s what the error looks like in practice:

Traceback (most recent call last):

File "/usr/local/lib/python2.5/site-packages/django/core/handlers/base.py", line 86, in get_response
response = callback(request, *callback_args, **callback_kwargs)
...
hash = md5('%s %+s%s%s%s' % (first, last, u.email, settings.ZENDESK_TOKEN, timestamp)).hexdigest()

UnicodeEncodeError: 'ascii' codec can't encode character u'\xef' in position 2: ordinal not in range(128)

The problem is that md5().hexdigest() only works on byte strings. If you give it a unicode string it will try to .encode('ascii') it, which works fine as long as there are no international characters in the string.

The solution is simple: just explicitly UTF encode the source string. The Zendesk documentation did not mention what encoding they use themselves but my first guess would have been UTF-8, which turned out to be right. So with that in mind here is our current version of Jon Gales’ Zendesk Remote Authentication snippet for Django:

@never_cache
@login_required
def authorize(request):
  try:
    timestamp = request.GET['timestamp']
  except KeyError:
    raise Http404

  u = request.user

  from hashlib import md5

  first = u.first_name
  last = u.last_name
  if not first and not last:
    first = "Yippie"
    last = "Mover"

  data = u'%s %+s%s%s%s' % (first, last, u.email, settings.ZENDESK_TOKEN, 
    timestamp)
  hash = md5(data.encode('utf-8')).hexdigest()

  url = u"%s/access/remote/?name=%s %s&email=%s&timestamp=%s&hash=%s" % (
    settings.ZENDESK_URL, first, last, u.email, timestamp, hash)

  return HttpResponseRedirect(url)

Notice that we feed a unicode URL to HttpResponseRedirect – Django is smart enough to do the right thing when encoding the URL.

Author: Alexander Ljungberg Tags: code, Django, internationalization, python, Zendesk

New Playing With Wire writer Lore Dionne Candelaria takes a look at the history of email and what led to its enormous impact on our modern lives.

Ever since the dawn of human existence, it has been an instinct of man to try to find ways to reach out and to be able to be heard. Speech and language proved to be the most important tools of the ancient human. Humankind has used these tools to survive and to exchange thoughts; which later evolved into other forms that made use of written symbols, drawings, runes and many other variations. The natural next step in this desire to innovate was the attempts to conquer distance — man wanted to still be in touch besides being apart. Carrier pigeons and smoke signals paved the way for a line of development aiming for an infinite means of communication. Thus came the discovery and birth of technologies like the telegraph, telephone, and ultimately, the e-mail system.

Before we can talk about the creation of electronic mail, we should first understand the beginnings of the internet itself. Many people have probably heard that the Internet began in some military computers in the famous Pentagon, that it was called Arpanet, and that the year was 1969. The theory goes on to suggest that the network was designed to survive a nuclear attack. True enough, the Internet was designed in part to provide a communications network that would work even if some of the sites were destroyed by nuclear attack. In 1969, the US Department of Defense wanted a communication system that could not be destroyed in the event of an emergency. They linked computers over telephone lines so that if one computer failed to work, the others could still communicate with each other. This system was called then as ARPANET.

ARPANET (Advanced Research Projects Agency Networks) was the network that became the basis for the development of the INTERNET. It was developed under the direction of the U.S. Advanced Research Projects Agency (ARPA). In 1969, the idea became a modest reality with the interconnection of four university computers. The initial purpose was to communicate with and share computer resources among mainly scientific users at the connected institutions. ARPANET took advantage of the new idea of sending information in small units called packets that could be routed on different paths and reconstructed at their destination. The main concept in packet switching was the idea of making use of circuits that are switched like in the old type of typical telephone circuit, where a dedicated circuit is tied up for the duration of the call and communication is only possible with the single party on the other end of the circuit.

The starting point for host-to-host communication on the ARPANET was the 1822 protocol which defined the way that a host sent messages to an ARPANET IMP. The message format was designed to work unambiguously with a broad range of computer architectures. Essentially, an 1822—message consisted of a message type, a numeric host address, and a data field. To send a data message to another host, the sending host would format a data message containing the destination host’s address and the data to be sent, and transmit the message through the 1822 hardware interface. The IMP would see that the message was delivered to its destination, either by delivering it to a locally-connected host or by delivering it to another IMP. When the message was ultimately delivered to the destination host, the IMP would send an acknowledgment message (called Ready for Next Message or RFNM) to the sending host.

So, how exactly did email evolve from the classic ARPANET? The answer comes from the name of Raymond Tomlinson. Tomlinson, born in 1941, is a programmer who implemented an email system in 1971 on the ARPANet. Email had been previously sent on other networks. Before internetworking began, email could only be used to send messages to various users of the same computer. Once computers began talking to each other over networks, however, the problem became a little more complex—they needed to be able to put a message in an envelope and address it. To do this, they needed a means to indicate which mails go to whom in a way that the electronic posts understood. This is the same as the conventional postal system: they need a way to indicate an address for a particular mail. The AUDOTIN was the first system able to send mail between users on different hosts connected to the Arpanet. To achieve this, Tomlinson used the @ sign to separate the user from their machine, the “commercial at” symbol to combine the user and host names, providing the naturally meaningful notation “user@host”—that is the standard for email addressing today. This has been used in email addresses ever since. These early programs had simple functionality and were command line-driven, but established the basic transactional model that still defines the technology: email gets sent to someone’s mailbox.

The first important email standard was called SMTP, or simple message transfer protocol. SMTP was very simple and is still in use – however, as we will hear later in this series, SMTP was a fairly naïve protocol, and made no attempt to find out whether the person claiming to send a message was the person they purported to be. Forgery was (and still is) very easy in email addresses. These basic flaws in the protocol were later exploited by viruses and worms, and by security frauds and spammers forging identities. But as it developed, email started to take on some pretty neat features. One of the first good commercial systems was Eudora, developed by Steve Dorner in 1988. When Internet standards for email began to mature the POP (or Post Office Protocol) servers began to appear as a standard; before that, each server was a little different. POP was an important standard which allowed users to develop mail systems. These were the days of per-minute charges for email of individual dialup users. For most people on the Internet in those days, email and email discussion groups were its main uses. There were many hundreds of these on a wide variety of topics, and as a body of newsgroups, they became known as USENET.

With the World Wide Web, email started to be made available with friendly web interfaces by providers such as Yahoo and Hotmail. Usually this was without charge. Now that email was affordable, everyone wanted at least one email address, and the medium was adopted by not just millions, but hundreds of millions of people. This only proves how emailing has reached new horizons in helping people to connect with the virtual world.

Though it is undeniable that emailing has gone a long way since it was first conceptualized, conceived and born, it now faces more problems than ever. While one cannot question the importance of email and instant messaging nowadays, one question remains: what is in store for electronic mailing in the future? In this age when everyone is aware of the emergence of so many communication options, does email still makes sense? What’s worse, e-mail has become a tool for criminal hackers ready to show off their technical skills. Recently, organized crime has become more of a force in the spam arena. They developed a series of get-rich-quick schemes and have also leveraged spam as an entry point into collecting and then misusing individuals’ personal financial information. As a result, it is estimated that spam represents 80% to more than 90% of all e-mail messages. Consequently, some businesspeople are flocking to these new communications options to rid themselves of the tedious task of constantly hitting the delete button. Can one still trust the reliability of emailing in connecting and communicating with other people?

The answer lies on the platform that emailing has founded. The flaw that makes email so easy to abuse for spam and other nefarious activities is also it’s strength: it’s easy to get an e-mail address and nearly everyone has one. E-mail will continue to be a popular communication option precisely because it is so popular. Emailing continues to be a communications option that generates billions of messages each year.

Yes, new communication channels have emerged, they appeal to different sort of users, and they will be in use at times instead of e-mail. However, e-mail still has the broadest range of supporters and will continue to be the primary communications media for most businesspersons for the foreseeable future; especially now that there is a boom in the online business industry. Email has proven to be an efficient marketing and advertising medium. The increase in electronic commerce or e-commerce has once again pressured the mail developers to improve and better the functionalities of email systems.

For sure things will change and just like all else, e-mail will surely evolve, but its use as a communication medium is still unparalleled. It was after all created on top of technology built to survive.

Author: Lore Dionne Candelaria Tags: Email, history, internet