almost daniel » code

javascript architecture: the front and back of it

daniel — Sun, 14 Mar 2010 16:50:25 +0000

UI Architecture: all the stuff that it takes to process, package, deliver, and communicate with the client (templating url routing, data validatiion, formatting, ajax). “Between the front and back end”: stuff between presentational javascript and the backend logic. The middle end gives a web 2.0 app performance.

We need to talk about this because of issues with performance and optimization, the MVC model spaghetti code failure (outputting html if a condition exists: the mixture of model code inside view template, too tight coupling between presentation layer and model layer), “don’t repeat yourself” (DRY: repeating code over and over again, i.e., duplicating validation in the client and the server, “any time there is more than one copy of something, one copy is always wrong”), and role separation (wearing multiple skillset hats and mixing contexts–markup/css switch to javascript switch to backend app–without being able to focus on one context at a time).

This isn’t another framework, it’s an optimized/reworked “alternate pattern” of MVC in an attempt to solve some of the weaknesses/problems of MVC. Can we decouple the view from the existing architecture stack?

CVC + JavaScript puts the power of UI architecture in the hands of front-end engineers.

[ session description ]

Presenter(s): Kyle Simpson
Date: 14 March 2010
Tag(s): #frontandbackofit; #jsarch
Sites: Getify; Demo of HandlebarJS; Speaker Feedback; BikechainJS; HandlebarJS

Traditional: CVC

The MVC model doesn’t have a clear space for client-based JS app (a JS version of the app that is not just the presentation logic, but a representation of the app inside the client).

New: “Clients Views Controllers” (CVC)

Application Layer (black box): doesn’t do anything with the presentation layer, no markup; only concerned with state management/session records and representing the data in a standard format: JSON API. Multiple other layers can talk to JSON API, so make it primary communication interface with application layer.

Web Server Layer: translates protocol request to hand off to rest of stack.

UI Controllers Layer (server): written in javascript, takes care of url routing, data validation. Allows more reuse of code/less rewriting in server/client layers.

View Layer (server/client): written in javascript, view engine decoupled from application, portable to client because of JS to run in browser.

“look up state, hands off to controllers, choose a view”

Clients

Everything is a client of everything else. Each layer is decoupled, modular, scalable.

Views

Templating, portable, DRY, platform agnostic, uses core web tech.

Controllers

Task oriented. Controlled by front-end engineer. Less dependence on backend architecture. Small, independent.

JavaScript on a Server

node.js is a wrapper around the V8 JS engine. Some Python dependencies for build, but not for execute. V8 is just a shared lib. a different way to process web requests: asynchronous events instead of firing a thread for every request. narwhal is a wrapper around the rhino JS engine. Others: javascriptcore, spidermonkey.

Reference implementation: BikechainJS is Kyle’s wrapper around V8. Loads modules to create a hosted environment to run JS. HandlebarJS is a templating engine that uses text/html templates and accepts JSON data input where you cannot call any methods/math. The only logic you can do is to use application “state” for template selection. Compiles templates into JS the first time a template is parsed. Environment agnostic (server or client).

Standards

How do I read/write files, i/o, execute processes, conduct network requests? CommonJS is a standards community. Very young.

web framework battle royale

daniel — Sat, 13 Mar 2010 18:44:42 +0000

Web frameworks make building websites easier. Common tasks are abstracted for faster development. Here is an analysis of five different frameworks: Zope (Python), Rails (Ruby), Sinatra (Ruby), Seaside (Smalltalk), and Symfony (PHP).

[ session description ]

Presenter(s): (lots)
Date: 13 March 2010
Tag(s): #frameworkbattleroyale

This was a fast-paced session, so I’m just going to summarize the frameworks discussed with links so I can research more at a later date.

Symfony has tutorials to get you going. Can be installed with PEAR. Free books.
seaside is a very different kind of language. Squeak/Smalltalk
Sinatra is a ruby-based framework require Sinatra, read the readme.
rails is a ruby-based framework. it has the little red book, fast to get up and going.
zope is a framework for frameworks, hard to decide which framework to go with. poor documentation is improving.

designers and developers:why can’t we all just get along?

daniel — Tue, 17 Mar 2009 17:46:09 +0000

I arrived at this session and it was SRO and full. I got some final ideas (after making it inside with 15 minutes to go):

When designers push their vision out to “version 10″, it can cause tension with developers who are usually starting from the other end (i.e., Agile). Developers want to start small (and efficient/elegant) and progressively build toward a design. Balance is key.
The best possible thing a designer can do for a developer is to share the problem and challenges, not just ask for a composed feature. That way the designer is asking to partner on the solution with the developer. Happiness ensues.
The best possible thing a developer can do for a designer is to communicate principles and needs to designers to create a more common ground. For example, talking to designers about considering both real-time interactivity and asynchronous actions.
The best possible thing both can do is hang out with each other outside the office.
Build trust.

For the rest of the notes, I depend on my trusty Michigan friend, daniel slaughter. He takes amazing notes.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

designing our way through web forms

daniel — Sun, 15 Mar 2009 21:30:46 +0000

Forms suck. Creating a style guide for form design is difficult.

Presenters: Christopher Schmitt – Heat Vision; Eric Ellis – Bank of America; Kimberly Blessing – Comcast Interactive Media
Date: Sunday, March 15
Sites: web form elements research; jquery validation; moz monkey

The Luke W. mantra: forms stand in the way of what we want to do.

Conversations

Conversations are rooted in trust. Good forms should be structured on trust. Think about people/relationships, and context. The way you speak to your users impacts their excitement/enjoyment. The way you label your forms focused on a label that makes sense to the user not just to you.

Expectation: Apparently expectation is obvious.
Flow: Can a user look at a page in a matter of seconds and understand the pattern of interaction.
[Managed] Noise: Forms that are not initiated or expected; noise is anything that inhibits the user’s ability to complete the task. Marginilization over removal.
Order: Important things (the task) first, then the rest should be add-on. But make sure I have completed something soon.

Progressive Engagement

Lead a user down a path and show them questions only if they are necessary to the context and the type of user you are (if I already know about you, don’t ask me to fill it in again).

HTML5 Form Elements

Slider
Input date (calendar) drop-down
Input time
Placeholder

Web Form Management

Forms get re-purposed most often. How can you manage all the different form purposes simplistically in a common application pattern library? An editorial style guide for web forms: how do we speak to our customer or about our services?

Pull together the people who care about standards and build a style guide from the ground up.

Validation

Client-side validation doesn’t get it all, and can expose your validation methods to DoS. Split validation between client/server: format v. required. Server-side response for validation errors at top so screen readers see it force.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

core conversation:should i build my startup on ruby on rails?

daniel — Sun, 15 Mar 2009 20:23:40 +0000

What are the most important qualities of a programming language when you are starting from scratch?

how easy to get a prototype out?
will it scale? or do i need to scale right now?
what existing code libraries are out there and do they support my industry?
what kind of talent is out there?
do i already know the language?
does the language encourage good developer habits?
is the language well accepted by a large community/industry?

Date: Saturday, March 19
Sites: Ruby on Rails

CSS3: what’s now, what’s new, and what’s not?

daniel — Sun, 15 Mar 2009 19:54:23 +0000

Let the W3C be with you. Woo! Cross-browser compatibility problems should end.

Presenters: Molly Holzschlag – Opera Software; David Baron – Mozilla; Hakon Wium Lie – Opera Software; Sylvain Galineau – Microsoft
Date: Sunday, March 15
Sites: david baron; molly holzschalg; Jonathan Snook

CSS3 doesn’t really exist: the standard is being modularized so parts of “CSS3″ can be implemented in browsers before others. But where is Apple?

Modules: Now

selectors: :nth-child(odd), :nth-child(even)
color: opacity vs. rgba()
borders: border-image, -moz-border-image
rendering properties: -moz-column-count, -moz-column-rule; text-shadow; -moz-box-shadow; -moz-border-radius; word-wrap: break-word; font-size-adjust (specify the font size by the x-height of the characters. e.g., 20px * 0.45); @font-face (downloadable font specification where you define rules for each font and style): src: url(“font.ttf”)
media queries: @media screen, projection {}; @media print {}; @media (min-width: 22em) { }; @media all and (property) { }
Transformation/Paths: -moz-transform, -webkit-transform; svg clip-path, svg mask, svg filter

Modules: Future

width: calc(50% – 8px)
h1 { content: url(decorative.png); }
new layout systems for user interface?

Internet Explorer + CSS

IE must implement 2.1 completely, correctly, and optimally. IE8/02.27 does.

CSS3 in IE8

The future includes opacity of color, backgrounds, borders, selectors, web fonts, media queries, and multi-column.

Communicate: www-style (at) w3.org

Opera + CSS

CSS3 is ready for demo with backgrounds, borders, fonts, transitions, selectors, media queries, and generated content for paged media. Microsoft needs to adopt TrueType and OpenType.

Printing (Paged Media)

Use HTML and CSS to build PDF documents for printing. Some features: Leaders and auto page-number based on pagination, footnotes, page headers, and page numbers. Yes Software.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

Feedback

When you deal with open standards, you want a single standard to be implemented correctly in a number of different engines/ways because each implementation is taking a different perspective (mobile devices vs. rich devices). Otherwise you have stagnation. Competition on a standards level is a core problem.

Using floats for layouts doesn’t hit the mark. A true layout module is needed. Jonathan Snook. We need layout modules based on other system user interface design history. HTML5 separation of elements may clash with semantic coding.

version control: no more save as…

daniel — Sun, 15 Mar 2009 16:17:38 +0000

Version control can save your life and make you happy.

Presenters: Matt Mullenweg – Automattic/WordPress; Karen Nguyen – Yahoo!; Zach Nies – Rally Software Development; Joe Pezzillo – joepezzillo.com, @metafy; Derek Scruggs – SurveyGizmo
Date: Sunday, March 15
Sites: phpadvent article; trac; cornerstone; versions; Beanstalk; mecurial

Teams

Fosters a collaborative environment: when you are working on the same files, multiple people could step on each other’s toes. Branching and merging lets you work on your own and then bring something unique back to the main project.

Bits and Bytes

Version control has always been a little scary because of the command line format. Three words really matter when it comes to version control:

Update – applies latest changes from the repo to your local working directory
Status – shows you what has changed in your local working directory
Commit – applies your local changes back to the repo

VC allows you to work on non-live servers, get it working, and push a fix out to a live server only when you know it is working. You can also rollback to a previous version.

Tools

Version control is built into many web dev systems (xcode, coda, dreamweaver), as well as some third party tools: cornerstone (gui with a timeline, filemerge-like comparisons), versions (easy to set up/use, beanstalk integration). Beanstalk (remote hosted repository, integrates with basecamp, fogbugz, lighthouse, twitter).

Git – vc with branching made easy, gitx, github, social coding, fork central, gists

Branching may be good for maintaining a pro version or lite version, mu version vs. normal.

mecurial (Hg) – distributed version control, bitbucket.org

Binaries, Company Size, Cross-repo dev

No negatives to putting binary files into repositories. You can be guaranteed that you are working with the same version of the file.

In small companies, developers often drive the decision to use version control due to familiarity and specific needs.

Large companies, there is usually a version control culture already in place.

Multiple version control repo types with multiple groups causes delay and problems. Time is money, so you should find something that is easy for IT, QA and dev teams to use. It should provide security and disaster recovery. It should be cost effective (would putting some money into it save money later?). Can you get great reports of how you are using vc, and does the vc repo have a high adoption rate? What is administering a vc repo like? The downside to switching to a single vc repo (if you have multiple now) is a high IT cost for infrastructure and migration. Developers feel switching would impact productivity during migration due to reconfiguration, etc. QA usually doesn’t get a chance to check things out since there really can’t be any dev downtime for vc repos.

Cool Things (yay matt!)

Matt decided to show a live version commit to wordpress.com.

svn diff
deployment system to multiple production servers (deploy), svn makes it easy.
post commit hooks (svn email, trac)
sparse checkups
sync multiple computers and backup your svn repo (snapshots)
automate checkins for a backup-like situation, break things up into multiple commits

Hosting

The providers make it easy to get going quickly.

Branching

Love it or leave it? Version control is a channel of your development processes. Branching tends to slow down the project, and really is only useful when you are starting over from scratch.

There were a lot of great questions at the end with awesome information, like WordPress’s deployment strategy, but I ran out of power and was too comfortable to go find an outlet. Sorry!

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.

tables don’t kill people, they just kill accessibility.

daniel — Tue, 24 Feb 2009 23:22:02 +0000

At least, tables (can) kill accessibility in web portals.

Accessibility in a portal has always been a challenge. It has to do (initially) with boxes.

Many early portals used quite hideous tables to layout the screen. Hey, a portal is a set of boxes, right? Oracle Portal still enforces a level of table-as-layout. Tables aren’t evil, but as layout devices they make it difficult to control keyboard interaction on a screen. You have to really implement them right to keep them accessible.

But my main problem with tables as a way to arrange a set of boxes is that the boxes (portlets) on a page are not always neat, tabular data in common rows and columns. Tables are for arranging tabular data. That means there are common relationships among the data sets.

A portlet is too complex an interaction to always fit as “tabular data”. The ways I want to navigate a table of numeric data is usually different from the way I want to interact with a portlet or group of portlets. For example, do I have to tab through every portlet (and inside through the inner elements) on the screen in order to get to the one I want (with the keyboard)? Or can I jump through HTML headers like every other well-formed webpage I encounter?

The other problem with tables is styling. Think about how difficult it is to style your own profile at MySpace. Nested tables to the nth degree. Portals are susceptible to this trap as well. Taking a beautiful Photoshop design of a portal interface and then attempting to style unclassed table cells (when tables themselves tend to break certain CSS layout rules–or better yet, when there is inline CSS inside a table definition that you cannot override!) is an exercise in insanity. I mention this because the level of design control I have over my content is usually closely related to the level of accessibility I can ensure in a page.

So the first accessibility challenge for portals is having enough control over the page layout interface to display portlets on a page in a way that is semantic and easy to interact with via a keyboard. The second is having enough freedom to make it look great.

FormPress 0.2 released

daniel — Thu, 03 Apr 2008 20:31:38 +0000

The second update for the beta of FormPress has been released. This version introduces a new “Required Fields” feature as well as many maintenance updates.

Turning WordPress into a fancy form processor

daniel — Wed, 21 Nov 2007 16:33:22 +0000

Yes, I know. Five+ years of development. An approach to open-source content management that is at the same time refreshing and inspired. One of the top blogging tools in the world.

And now, WordPress processes my forms for me.

Preempting Genius

The WordPress Plugin API provides hooks into the execution of its code via Actions. As someone views a page on your site, a chain of events is triggered until the requested page is displayed. All along this chain, WordPress notifies itself that it is completing certain Actions.

Plugin developers can use the fact that WordPress has just triggered one of its core functions and execute one of the plugin functions as well. In this way, your plugin can insinuate itself quite deeply inside the main WordPress package.

The earliest Action hook that I could find is named init. The WordPress Codex describes this Action:

Runs after WordPress has finished loading but before any headers are sent. Useful for intercepting $_GET or $_POST triggers.

Translation: Runs after WordPress loads its function environment but before it has displayed anything in the user’s browser. Use our software for your own nefarious goals.

Amazing. They suggest that you use this to turn their software into something else entirely. With a minimum of 8 lines of code, I subverted my favorite open-source software into a simple forms processor that had the power (and data set) of my entire WordPress tool behind it.

The Method

Using WordPress Actions is basically a two step process:

Write a PHP function that you want to be triggered at some point in the WordPress execution chain.
Use the add_action() function to inform WordPress of a) the core function you want to piggy-back on, and b) the name of the function you wrote in step 1.

Write the Function

I wanted people to be able to use my WordPress as the action URL in HTML forms. Something like:

I needed a function that could check for a particular attribute each time my site is accessed, and if the attribute is there, preempt everything else WordPress does (such as loading my actual site) and instead process the form that is (hopefully) being submitted.

function form_submit() {
 $form_ID = $_REQUEST['form_submit'];
 if ( !empty($form_ID) ) {
  form_do_submit($form_ID, $_REQUEST);
  exit;
 }
}

Note: I’m only checking to see if some value got passed in “form_submit”. A well-written function would validate the information and only process the form if useful information was being passed. I could even go so far as to make sure that the origin of the submission is allowed. But that is for another post.

The form_submit() function checks to see if the query item “form_submit” was passed to WordPress. In this case, the value of the query item is the form ID number that I will use in processing. If the query item “form_submit” was submitted, I execute a the function form_do_submit() (I put it in its own function just for cleanliness of code) that actually processes the submitted $_REQUEST object (i.e., the contents of the form the user just submitted).

And here is the beautiful part: While I am processing the submitted form, I can use any WordPress function I want. I can store and retrieve data from the WordPress database. This proves quite useful.

Let WordPress in on the Secret

Now, to tell WordPress when I want it to execute this function, I use the add_action() function to my plugin’s main execution space. This ensures that I will always trigger my query check each time my plugin is loaded no matter what.

add_action('init', 'form_submit', 1);

As soon as WordPress loads its environment, my form_submit() function is executed. The ‘1’ just tells WordPress to execute my function as early as possible (a ‘10‘ would have told WordPress to execute my function as late as possible).

Jump Ship

Why does WordPress run my function and not load my website? The handy exit command I put in my form_submit() function. As soon as I’ve processed my form, I just tell WordPress to take a coffee break. And we’re done!

The Code

Here is the code in my plugin’s main file:

function form_submit() {
 $form_ID = $_REQUEST['form_submit'];
 if ( !empty($form_ID) ) {
  form_do_submit($form_ID, $_REQUEST);
  exit;
 }
}

add_action('init', 'form_submit', 1);