Webdev:Betterness

Webdev can be boring, let's focus on the good parts

Take Action

• Mozilla webdev should be a paragon of OSS
  • let's release libraries
  • we don't need to make another Rails, but clouserw has volunteered to be DHH
• ozten and lorchard want to share User code. Good, release it!
• Where do we want to be a year from now? How do we change to get there?
  • if we used more Python, we'd be hobbled, but not for long
  • we don't need to be an X-and-only-X shop

Reusable Parts

What libraries do we want to reuse?

• Users: authentication, registration, passwords, permissions?
• Forms: validation, creation?
• Localization: gettext and dynamic content
• Pagination
• Sessions
• Caching
• Unicode? Please tell me that's not a problem these days.
• ORM: must not suck
  • Almost always does suck when you get into the actual meat of abstracting relations.
  • Alternatives:
    • Phrasebook pattern - where SQL is produced by named templates, not unlike HTML in the view. Pulls out all the queries in an app into one spot where they can be tweaked and optimized.
    • Query builder - where SQL is constructed through a DSL of method calls, easing the production of queries but not obscuring the underlying SQL.

Languages

PHP

Pros:

• Familiarity
• Easy to deploy
• Know how to scale it
• Almost all our current sites are written in it

Cons:

• Fugly
  • what?
• Reuse is hard
  • what?
• Not much of a library scene
  • PEAR? PECL?
• So easy to do bad things
  • Isn't this why we have interviews?
  • dd: Easy for good developers to do bad things too
• Difficult to test (also related to codebase)
• Slow to develop/debug
  • Not with proper tools (frameworks, xdebug, etc)
• dd: No good CLI

Python

Pros:

• Libraries
• Objects, classes (for real)
  • Does PHP have fake classes?
• Testing is the hotness
• Read-Eval-Print Loop, live debugging
• Elegant
• ORM that works
  • We could use PHP's DBO. We never have because (as is pointed out elsewhere) ORM's eventually get in your way.
• Scalable, I swear

Cons:

• Less Familiar
• Bad past experience
• Smaller recruitment pool (both employees and volunteers)

Ruby

Discarded because it doesn't start with 'P'.

Frameworks

Cake

we agree, it sucks. wait, what? when did we agree on that?

Symfony

lorchard has instructed me to punch anyone who wants to use it

Zend/Pear

big = scary, but can we poach libs?

Kohana

minimal, favored by ozten, lorchard and rdoherty, something we can build on

Django

the Python framework, full stack, great for getting started, may get in the way after a while

Turbogears

"best-of-breed" framework, glue around small libs, focusing on Restful web & scalability, we own the creator (kdangoor)

Werkzeug

minimal, used in bosley, not for beginners

Cake?

• Do we all agree Cake sucks?
  • +1 lorchard
    • At least the version behind AMO does.
    • Too much magic, not enough made explicit.
      • Always seem to be disabling things to get things done.
      • For example: ORM binding / unbinding / relational magic usually results in abandonment and dropping down to SQL.
    • Code is not-so-great for reading when docs are inadequate or unavailable.

Version Control

We're content sticking with svn. Not changing is simpler, the localizers are familiar with it, works as an upstream for git-svn (used by jbalogh, lorchard, wenzel, ozten)

Git is the dvcs front-runner, full of awesome, non-trivial to get started. Would be nice to have something distributed while we're working on the redesign in parallel, but otherwise we usually work in isolation. Branch-in-place is the way to go.

Hg is used throughout Mozilla, picking up steam in the Python community after Python switched, is the only other vcs Linus would consider using.

Conclusion

Stick with svn for existing projects, go with what makes you happy in future new projects.

Database

MySQL

• It's what we know
• It's what IT knows
• It seems to work
• Good replication
• BUT! What's happening with Oracle?

Postgres

• "Academic" reputation
• The DBMS of choice for relational snobs
• Strong in GIS
• Shaky in replication
• We're learning more with Socorro, but don't have a DBA that knows it

Other?

• CouchDb, Tokyo Cabinet, ...
• Our apps are pretty standard relational CRUD
  • Beyond ORM, consider the actual data needs - including schema, indexing, caching, etc.
    • Just ask Lars.
  • RDBMS (eg. MySQL, Postgres) are not the end-all-be-all for data.
  • Keeping models geared toward intention/purpose rather than relations can help underlying technology stay flexible.

Conclusion

Go with MySQL unless you have good arguments against or an epic beard

l10n and i18n

• Use utf8 everywhere
  • saving your program code
  • database tables / databases
  • web server
  • in your cereal
• Use gettext
  • Use full copy in English for msgid strings
  • Setup cron to auto-compile po and VCS commit mo files
  • Lockdown copy before filing l10n tracking bug
  • Use SVN for your locale directory (localizers preference)
• Use i18n friendly string methods in your programs
• Review designs for common l10n issues

Frontend

• HTML vs. XHTML?
  • HTML because that's what apache servers xhtml as by default, and xhtml doesn't give us much advantages. Browsers choke too easily if we use it properly (send as xml).
• CSS Reset
  • YUI reset ftw!
• CSS Typography
  • YUI fonts ftw!
• JS
  • jQuery
• WebDev:FrontendCodeStandards
• Sass? Makes CSS more readable
  • Not too keen on this, we have lots of contractors, 3rd parties and contributors working on sites. Adding in the extra complexity of install -> edit -> compile -> view may not work.

Working with Designers/Contractors

• Web Design best practices