Webdev:Betterness

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

Goals

• Evaluate possible libraries to be extracted from finished projects for re-use
• Create two PHP libs in SVN for re-use
• Create better a query library for AMO to take load off the database
• Release two public projects that can be re-used by web developers in the community
• Finishing up webdev blog and portfolio/project pages

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
  • ezcomponents
  • Zend Framework components
• So easy to do bad things
  • Isn't this why we have interviews?
  • dd: Easy for good developers to do bad things too
  • Isn't thiswhy we have code review?
• Difficult to test (also related to codebase)
  • Legacy code is always difficult to test
  • phpunit for unit testng
  • PHPUnderControl etc for continuous integration
• Slow to develop/debug
  • Not with proper tools (frameworks, xdebug, etc)
  • Never ever heard this as a criticism before???
• dd: No good CLI
  • What are you looking for? We do plenty of cli php

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
  • *dd* Everything is scalable

Cons:

• Less Familiar
• Bad past experience
• Smaller recruitment pool (both employees and volunteers)
  • *dd* This is becoming less of a case as python gains ground (thanks to Google AppEngine).

PRuby

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

• *dd* As PHP goes, I actually like it, but would not do any new projects with it.

Zend/Pear 

big = scary, but can we poach libs?

• *dd* libs are very poachable

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

• *dd* very good for re-use - encouraged from the very start of building apps
• *dd* you can swap out parts you don't like fairly easy - since its just python :)

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

• dd* We can experiment with CouchDB and TokyoCabinet for lower-risk projects.

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