3,035
edits
Webdev:Betterness: Difference between revisions
→Goals
(→Goals) |
|||
| (20 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
'''Webdev can be boring, let's focus on the good parts''' | '''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 == | == Take Action == | ||
| Line 36: | Line 42: | ||
Cons: | Cons: | ||
* Fugly | * Fugly | ||
** what? | |||
* Reuse is hard | * Reuse is hard | ||
** what? | |||
* Not much of a library scene | * Not much of a library scene | ||
** PEAR | ** PEAR | ||
** PECL | |||
** ezcomponents | |||
** Zend Framework components | |||
* So easy to do bad things | * 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) | * 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 | * Slow to develop/debug | ||
** Not with proper tools (frameworks, xdebug, etc) | ** 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 === | === Python === | ||
| Line 48: | Line 68: | ||
* Libraries | * Libraries | ||
* Objects, classes (for real) | * Objects, classes (for real) | ||
** Does PHP have fake classes? | |||
* Testing is the hotness | * Testing is the hotness | ||
* Read-Eval-Print Loop, live debugging | * Read-Eval-Print Loop, live debugging | ||
* Elegant | * Elegant | ||
* ORM that works | * 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 | * Scalable, I swear | ||
** *dd* Everything is scalable | |||
Cons: | Cons: | ||
* Less Familiar | * Less Familiar | ||
* Bad past experience | * Bad past experience | ||
* Smaller recruitment pool (both employees and volunteers) | * 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'. | Discarded because it doesn't start with 'P'. | ||
== 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 | ||
* *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? | ; Zend/Pear : big = scary, but can we poach libs? | ||
; Kohana : minimal, favored by ozten and | * *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 | ; 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) | ; 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 | ; 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 == | == Version Control == | ||
| Line 99: | Line 136: | ||
* CouchDb, Tokyo Cabinet, ... | * CouchDb, Tokyo Cabinet, ... | ||
* Our apps are pretty standard relational CRUD | * 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 === | === Conclusion === | ||
Go with MySQL unless you have good arguments against or an [http://www.flickr.com/photos/termie/3393701864 epic beard] | Go with MySQL unless you have good arguments against or an [http://www.flickr.com/photos/termie/3393701864 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 == | == Frontend == | ||
* HTML vs. XHTML? | * 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 | * CSS Reset | ||
** YUI reset ftw! | |||
* CSS Typography | * CSS Typography | ||
** YUI fonts ftw! | |||
* JS | |||
** jQuery | |||
* [[WebDev:FrontendCodeStandards]] | * [[WebDev:FrontendCodeStandards]] | ||
* [http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html Sass]? Makes CSS more readable | * [http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html 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 == | == Working with Designers/Contractors == | ||
* [https://wiki.mozilla.org/Webdev:Web_Design_Best_Practices Web Design best practices] | * [https://wiki.mozilla.org/Webdev:Web_Design_Best_Practices Web Design best practices] | ||