Web development
From WhyNotWiki
Web development edit (Category edit)
Contents |
[edit] Links / Reference / Resources
Architecture of the World Wide Web, Volume One
The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support.
[edit] Tools
[edit] Integrated development environments (IDEs)
[edit] Aptana
| Description: | Aptana is a robust, JavaScript-focused IDE for building dynamic web applications.
|
|---|
http://www.aptana.com/download_all.php Aptana: Download
Highlights include the following features:
- Code Assist on JavaScript, HTML, and CSS languages, including your own JavaScript functions
- Outliner that gives a snapshot view of your JavaScript, HTML, and CSS code structure
- FTP/SFTP uploading, downloading and synchronization
- JavaScript debugger to troubleshoot your code
- Error and warning notification for your code
- Support for Aptana UI customization and extensions
- Cross-platform support
- Free and open source licensed under the Eclipse Public License, v1.0.
http://www.aptana.com/docs/index.php/About_the_Eclipse_Workbench About the Eclipse Workbench - Aptana
Editors - Aptana has three Editors: JavaScript, HTML, and CSS. These Editors are where you will be doing the actual coding for your web development. Aptana blends these three editors together so well that you don't need to worry about which you're using. If you enter into <script> tags inside an HTML document, you'll suddenly have access to all the code completion of a Javascript editor....
[Has a nice screenshot]
[edit] Sessions
http://www.troubleshooters.com/codecorn/ruby/rails/rapidlearning_rails.htm :
By far the toughest part of web programming is that the HTTP protocol, which is the protocol used by the web, is stateless. That means that every web page starts knowing nothing of web pages that came before it. Programs cannot be written under such circumstances.
For that reason, programmers from the dawn of time have found various ways to pass information between web pages:
- Passing info in the URL
- Passing info in form variables
- Passing info in cookies
All persistence kludges, and that's what they are, kludges to compensate for HTTP statelessness, are ugly, and every single page on the website must pass state info, even if such pages have no dynamic content, or else state is lost. URL passing is a horrible security faux pax. Passing in form variables means every single page on the website must pass state info, even if such pages have no dynamic content, or else state is lost. Passing in cookies has privacy implications, and some people turn off cookies on their browser.
The best a framework can do for you is to shield you, the application programmer, from the drudgery of maintaining state. [...]
http://comments.gmane.org/gmane.comp.lang.ruby.rails/26374 Michael Schuerig | 22 Oct 02:17
- Session management using cookies has one notable drawback: a user can't
have to concurrent sessions. At least not when using the same browser instance. This can at times result in confusing behavior when what the user does in one window affects how the application behaves in another window.
http://comments.gmane.org/gmane.comp.lang.ruby.rails/26374 Michael Schuerig | 22 Oct 03:22
- I really mean the same user -- username, password and all. And, well,
there is a problem, at least in my case. I'm keeping some context of where the user has been in the session to enable navigation. Say, the user has just run a query, then I allow them to go through the found records one by one. To do this, I keep a list of ids in the session. Now, if the user opens another window, runs another query, the context of the first window is lost.
- To my mind, it's a sensible expectation from a user's point of view, to
be able to open two windows, and, say, in one of them step through all employees matching some criteria, and in the other stepping through projects matching entirely different criteria.
- Ideally, a user needs to log in just once, but then can open as many
windows as they like, each with its own conversational state.
http://shiflett.org/articles/the-truth-about-sessions Chris Shiflett: The Truth about Sessions
- HTTP, the protocol that powers the Web, is a stateless protocol. This is because there is nothing within the protocol that requires the browser to identify itself during each request, and there is also no established connection between the browser and the Web server that persists from one page to the next. When a user visits a Web site, the user's browser sends an HTTP request to a Web server, which in turn sends an HTTP response in reply. This is the extent of the communication, and it represents a complete HTTP transaction.
- Because the Web relies on HTTP for communication, maintaining state in a Web application can be particularly challenging for developers. Cookies are an extension of HTTP that were introduced to help provide stateful HTTP transactions, but privacy concerns have prompted many users to disable support for cookies. State information can be passed in the URL, but accidental disclosure of this information poses serious security risks. In fact, the very nature of maintaining state requires that the client identify itself, yet the security-conscious among us know that we should never trust information sent by the client.
[edit] Philosophy
[edit] Keep the HTML clean
Yummy... Clean, structured, meaningful, simple HTML.
I'd rather make the CSS a little more complicated if it can make the HTML simpler (but I'd like to keep the CSS simple too). Bottom line: HTML simplicity is a little more valuable to me than CSS simplicity.
[edit] Use CSS context selectors liberally
Don't make a new class/id for an element when you can just select it using its parent's class/id as context! There, you just saved yourself from creating dozens of classes/ids that you only use once in your stylesheet! Doesn't it feel great?
[edit] HTTP status codes
http://aboutawebmaster.com/articles/redirects-3.php.
[...] Every time your web browser requests a web page, the web server will respond with a numbered code called an HTTP Status Code. [...] So what does all of this have to do with redirects? A few of those codes are used to indicate that a document has moved. These are the ones that will help us with our redirection issues. The W3C has a detailed breakdown of all the HTTP status codes including 301 and 302 redirects.
The 301 and 302 redirects are used to automatically redirect a web request. They do this in a somewhat similar fashion as a meta refresh, but add context to the redirection. The end result is that when a person uses a bookmark or types in the old URL, they are automatically redirected to the new URL, but with no intermediate page. The lack of an intermediate page means that only the HTTP header is sent back to the client to let them know about the redirection. The small size of the http header helps to speed up the process to the point where most often, it is a near instantaneous redirection, with very little to no sense of lag for the end user.
The context that a proper HTTP redirect provides comes from the specific status code it returns. A 302 redirect is used when the resource in question exists under a different URL temporarily, but you want people to continue to use the original URL with which the request was made. For example, if you have a daily column on your site, you might want to maintain a URL such as http://mysite.com/column/current/. In this case, we want the URL to redirect to the permanent URL of the article, http://mysite.com/column/37.html but tomorrow, we'll want to change the target of the "current" URL redirect to http://mysite.com/column/38.html. We want people to continue using the http://mysite.com/current/ URL to get the current column, whatever that might be. Hence, a temporary redirect.
The 301 redirect is a permanent redirection. It indicates that the resource has moved permanently and people should update their information for this URL. While the casual surfer who has your site bookmarked will be seamlessly redirected, the more technically savvy members of your audience will get an extra bit of information, notifying them that they should update their links and other information. Some of those technically oriented audience members are the search engine robots. Modern search engines will read a 301 redirect and update all associated properties of the old document to its new location. Any inbound links to the old URL will have their search engine ranking values attributed to the new page.
http://aboutawebmaster.com/articles/redirects-4.php.
Now that you have an idea as to what redirects are all about, a common question to ask yourself is, "How long do I need to keep these redirects in place?" A better question is why would you ever remove the redirects? In almost all cases, there is no good reason to get rid of them. Though some people will update their URL information based on your redirects, many will not. Take for instance the casual web user who has your website bookmarked. As soon as you remove your redirect, you will break their bookmark the same as if you had never put a redirect in place at all. The same goes for the multitude of web pages that have been abandoned and link to your site. They will live on un-maintained and you will lose back-links.
...
[edit] Post/Redirect/Get
http://en.wikipedia.org/wiki/Post/Redirect/Get
- Post/Redirect/Get (PRG) is a common design pattern for web applications, to help avoid duplicate form submissions and allow applications to behave more intuitively with browser bookmarks and the reload button.
- After a web user submits a form to a server, the server typically generates an HTML page as a response. To the user, this looks look an ordinary web page, but because it was generated by an HTTP POST request, it cannot be bookmarked, and attempting to reload/refresh the page in the browser could cause the form information to be resubmitted, possibly with unexpected results (such as a duplicate purchase).
- To avoid this problem, many web applications use the PRG pattern — instead of returning an HTML page directly, the POST operation returns a redirection command (using the HTTP 303 response code (sometimes 302) together with the HTTP "Location" response header), instructing the browser to load a different page using an HTTP GET request. The result page can then safely be bookmarked or reloaded without unexpected side effects.
Rails uses 302 currently. But a feature request was submitted (http://dev.rubyonrails.org/ticket/1923) to change it to use 303.
http://www.megginson.com/blogs/quoderat/archives/2006/05/31/firefox-vs-prg/
- Post/Redirect/Get (PRG) is a common web-application design pattern, where a server responds to an HTTP POST request not by generating HTML immediately, but by redirecting the browser to GET a different page. At the cost of an extra request, PRG allows users safely to bookmark, reload, etc.
[edit] Photos
http://huddletogether.com/projects/lightbox/ -- Lightbox JS is a simple, unobtrusive script used to overlay images on the current page.
[edit] Previews of links
[edit] Snap Preview
http://www.snap.com/about/spa1B.php "Snap Preview Anywhere adds value to your site by powering it with the largest library of high quality site previews... for any link on your site for free!"
http://blog.snap.com/2007/01/31/what-snap-preview-anywhere-can-do-for-you-and-why-it-does-not-suck/
[edit] Metaphor
ouput, print, display, write, render, draw, show, put, dump, echo, or emit? There are so many choices! So let's choose just one and be consistent!
[edit] REST
Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
[edit]
Ryan Daigle (2007-03-14). REST & ActiveResource (http://ryandaigle.com/assets/2007/3/14/REST_ARes.pdf).
[edit] Grammar Abused
GET http://addressbook/contacts/destroy/1Implied action [destroy] conflicts with HTTP method [GET]
[edit] Nouns
Represent Resources with URIs (Uniform Resource Identifier)
- ‘contacts’ = http://addressbook/contacts
- Different representations of the same resource (html, xml, json)
- contacts.html, contacts.xml etc...
...
[edit] Misc. Advice
http://blog.guykawasaki.com/2007/01/the_top_ten_stu.html How to Change the World: The Top Ten Stupid Ways to Hinder Market Adoption
1. Enforced immediate registration. Requiring a new user to register and provide a modicum of information is a reasonable request—I just think you should do it after you’ve sucked the person in. Most sites require that registration is the first step, and this puts a barrier in front of adoption. At the very least, companies could ask for name and email address but not require it until a later time.
A good example of a site that does the right thing is Netvibes. It allows you to do a high level of customization without registering. (Thanks to Glenn Kelman)
2. The long URL. When you want to send people an URL the site generates an URL that’s seventy characters long—or more! When you copy, paste, and email this URL, a line break is added, so people cannot click on it to go to the intended location.
Here’s an URL for a billiard table copied and pasted from the CostCo site. Just how many billiard-table models could CostCo be selling?
http://www.costco.com/Browse/Product.aspx?Prodid=11197553&search=billiard%20table&Sp=S&Mo=8&cm_re=1-_-Top_Left_Nav-_-Top_search&Nr=P_CatalogName:BC&Ns=P_Price|1||P_SignDesc1&N=0&whse=BC&Dx=mode+matchallpartial&Ntk=All&Dr=P_CatalogName:BC&Ne=4000000&D=billiard%20table&Ntt=billiard%20table&No=0&Ntx=mode+matchallpartial&Nty=1&topnav=&s=1The justification often goes like this: “We create a long URL because people with Crays might break our code and see private pages. Seventy characters that can be twenty-six lower case letters, twenty-six upper case letters, or ten numbers ensures that no one can break our code since the possible combinations outnumber the quantity of atoms in the universe.” This is what keeps sites like TinyUrl and SnipURL in business.
Also, speaking of URLs, it’s good to have an easy naming convention for URLs. MySpace, for example, creates easy-to-remember URLs like http://www.myspace.com/guykawasaki.
Test: Can people communicate your site’s URLs to others over the phone?
Extra credit: People using Verizon and can do this despite its coverage.
3. Windows that don’t generate URLs. Have you ever wanted to point people to a page, but the page has no URL? You’ve got a window open that you want to tell someone about, but you’d have to write an essay to explain how to get that window open again. Did someone at the company decide that it didn’t want referrals, links, and additional traffic? This is the best argument I can think of for not using frames.
4. The unsearchable web site. Some sites that don’t allow people to search. This is okay for simple sites where a site map suffices, but that’s seldom the case. If your site has a site map that goes deeper than one level, it probably needs a search box.
5. Sites without Digg, del.icio.us, and Fark bookmarks. There’s no logic that I can think of why a company would not want its fans to bookmark its pages. And yet many companies don’t make this possible. When my blog hits the front page of Digg, page views typically increase by a factor of six or seven times. It’s true that the Digg effect wears off quickly, but some new readers stick around and that’s a good thing.
6. Limiting contact to email. Don’t get me wrong: I love email. I live and die by email, but there are times I want to call the company. Or maybe even snail mail something to it. I’ve found many companies only allow you to send an email via a web form in the “Contact Us” page. Why don’t companies call this page “Don’t Contact Us” and at least be honest?
7. Lack of feeds and email lists. When people are interested in your company, they will want to receive information about your products and services. This should be as easy as possible—meaning that you provide both email and RSS feeds for content and PR newsletters.
8. Requirement to re-type email addresses. How about the patent-pending, curve-jumping, VC-funded Web 2.0 company that wants to you to share content but requires you to re-type the email addresses of your friends?
I have 7,703 email addresses in Entourage. I am not going to re-type them into the piece-of-shiitake, done-as-an-afterthought address book that companies build into their products. If nothing else, companies can use this cool tool from Plaxo or allow text imports into the aforementioned crappy address book. When do you suppose a standard format will emerge for transferring contacts?
9. User names cannot contain the “@” character. In other words, a user name cannot be your email address. I am a member of hundreds of sites. I can’t remember if my user name is kawasaki, gkawasaki, guykawasaki, or kawasaki3487. I do know what my email address is, so just let me use that as my user name.
10. Case sensitive user names and passwords. I know: user names and passwords that are case sensitive are more secure, but I’m more likely to type in my user name and password incorrectly. One of the funniest moments of a demo is when a company’s CEO can’t sign into her own account because she didn’t put in the proper case of her user name or password. I’ve seen it happen.
11. Friction-full commenting. “Moderated comments” is an oxymoron. If your company is trying to be a hip, myth-busting, hypocrisy-outing joint, then it should let anyone comment. Here’s an example of one such policy:
Q. Who can leave comments on GullyHagA. Anyone who has been invited, either by us or by a friend. The invite system works like Gmail. We’ve invited a bunch of our favorite execs, bloggers, and friends to comment, then given them invitations to share with their friends and colleagues. That way, the burden of inclusion, and exclusion, is shared.The concept that people have to be invited to post comments is pathetic—if you hold yourself out as a big cojones company, then act like it. Even the concept that one has to register to post a comment is lousy. There have been many times that I started to leave a comment on a blog but stopped when I realized that I’d have to register.
12. Unreadable confirmation codes. Don’t get me wrong: I don’t support spam or robots creating accounts. A visual confirmation graphic system is a good thing, but many are too difficult to read. For example, this is what I got when trying to create a Yahoo! account. Is that an uppercase “X”? Is the last character an “s,” “5,” or “S”? Maybe this only affects old people like me, but it seems that all one merely has to prove is that you’re not a robot so a little bit of fuzziness should be good enough. For example, if the code is “ghj1lK” and someone who enters “ghj11K” is close enough.
13. Emails without signatures. There have been many times that I wanted to immediately call the sender or send him something, but there’s no signature. Also, when I book an appointment with a person, I like to put in his contact information in case I need to change it. Communication would be so much easier if everyone put a complete signature in their email that contains their name, company, address, phone, and email address.
On a corporate level, communication would be so much easier if companies stop sending emails with a warning not to respond because the sender’s address is not monitored. I don’t mean they should not include the warning. I mean they should monitor the address.
14. Supporting only Windows Internet Explorer. Actually, I’m not nearly as vehement about this as you might think. Supporting Macintosh, Safari, and other Windows browsers is a lot of work, so this is your call. If you define your market as only the people who use Windows Internet Explorer, so be it. You may have to really invest some effort into this one, but all the other items in this list are stupidly simple.
[edit] The challenges of
Daniel F. Savarese (2007-03). Rails: A Development Gem: Ruby on Rails speeds development with Oracle Database. (http://www.oracle.com/technology/oramag/oracle/07-mar/o27rails.html).
Web application development presents a set of challenges different from those encountered in the development of self-contained desktop or server software. Whereas the interconnections between program modules in self-contained software are determined largely at compile time, the interactions between modules in a Web application occur almost exclusively at runtime. Apparently disconnected HTML pages, application servers, and databases can find themselves combining suddenly into a coherent program at the command of a client Web browser.Orchestrating such interactions involves multiple software entities, from the Web server or application server that parses HTTP requests to the database that stores persistent session data. Web application development frameworks (c) hide many aspects of these complex interactions from the programmer, converting HTTP requests into servlet method invocations and managing client sessions transparently. Although Java servlets, JavaServer Pages (JSPs), and the entire suite of Web-oriented Java 2 Platform, Enterprise Edition (Java EE) APIs do a comprehensive job of facilitating the construction of Web applications, sometimes you may want to choose an alternative framework.
[edit] Dynamic web sites
For such sites, you should be using a web application framework like Ruby on Rails or PHP...
Or use a CMS...
[edit] Static web sites
Do not even think about using Microsoft Frontpage.
Dreamwaver? Maybe...
[edit] Static web site management systems
Static web site management systems edit
These are tools for generating sites, based on content files and templates. I haven't tried any of them yet, but I think these might actually be worth looking into.
[edit] webgen
| Homepage: | http://webgen.rubyforge.org/ |
|---|---|
| Source code: | gem install webgen |
| Project/Development: | http://rubyforge.org/projects/webgen
|
| Implementation language: | Ruby
|
webgen (http://webgen.rubyforge.org/).
[edit] About webgen
webgen is used to generate web pages from page and template files. You create one or more template files in which you define the layout of your page and where the content should go. After that you create page files in which you only define the content.
When webgen is run it combines the template with each of the page files and generates the HTML output files. During this process special tags are substituted so that, for example, a menu is generated. Actually, this website was generated with webgen and, for example, the menu that you can see was created dynamically. For more information look at the documentation!
[edit] ZenWeb
| Homepage: | http://www.zenspider.com/ZSS/Products/ZenWeb/index.htm
|
|---|---|
| Implementation language: | Ruby
|
http://www.zenspider.com/ZSS/Products/ZenWeb/index.html
ZenWeb provides tools for complete website design and creation, simple paragraph to HTML generation with embellishments, and a rich set of tools for page and website creation, modification, and customization.
ZenWeb extends traditional web tools by being site oriented instead of page oriented. This allows you to focus on the quality and consistancy of the whole system instead of only being able to focus on a page at a time.
It is based around a sitemap. This sitemap defines the structure of your site and allows you to focus on the whole website in a single view. Pages know their relationships to others (children, parents, siblings) as a consequence and all navigation tools are automatically created by ZenWeb.
Comments:
- Written in Ruby; uses rake commands to do content generation (after changes to the configuration)
[edit] Diagramming user interfaces
(move to more general topic)
http://jjg.net/ia/visvocab/ Jesse James Garrett: Visual Vocabulary for Information Architecture
| Implemented in | Ruby + |
| Description | [Oops! No type defined for attribute] |
