Webdev:Betterness: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 68: Line 68:
== Frameworks ==
== Frameworks ==


; Cake : we agree, it sucks
; 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
; Symfony : lorchard has instructed me to punch anyone who wants to use it
; Zend/Pear : big = scary, but can we poach libs?
; Zend/Pear : big = scary, but can we poach libs?

Revision as of 14:39, 13 May 2009

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?
  • Difficult to test (also related to codebase)
  • Slow to develop/debug
    • Not with proper tools (frameworks, xdebug, etc)

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 and lorchard, 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

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

Conclusion

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

Frontend

Working with Designers/Contractors