javisantana

-- You need to create plpython languaje in the database
-- createlang -U postgres plpythonu DATABASE_NAME
-- this small trigger prevents an user exceeds a database size. Once the user exceeds the quota
-- the database size is checked every time an update or insert are performed until the user deletes some data
-- If the server is restarted the quota is checked the fist time user executes some update or insert

CREATE OR REPLACE FUNCTION check_quota() RETURNS trigger AS
$$
    c = SD.get('quota_counter', 0)
    if c%1000 == 0:

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

adamstegman

[{"fn":".gitattributes","sha1":"2ae3f36a1ff15605cb6db9b70d35f6595739eeda","size":13},{"fn":"CONTRIBUTING.md","sha1":"6a90de418a4c2555fbd54528a86e9221d49e8b5e","size":149},{"fn":"app","sha1":"0","size":4096},{"fn":"app/commands","sha1":"0","size":0},{"fn":"app/commands/.gitkeep","sha1":"da39a3ee5e6b4b0d3255bfef95601890afd80709","size":0},{"fn":"app/config","sha1":"0","size":4096},{"fn":"app/config/app.php","sha1":"7ac2822addf6a99aeb8e56c523881c0cb43a6389","size":7543},{"fn":"app/config/auth.php","sha1":"922ff60f01800bccda3710d12801088e2cc97ca6","size":2182},{"fn":"app/config/cache.php","sha1":"0fa647fde37e95f33274baeaeda3cd593332fdfc","size":2844},{"fn":"app/config/compile.php","sha1":"06302bbd25af958b94a09521dad19b2a6fbe1492","size":462},{"fn":"app/config/database.php","sha1":"31566c6431343c795cbed1fac8711cf052dacc28","size":3447},{"fn":"app/config/local","sha1":"0","size":0},{"fn":"app/config/local/app.php","sha1":"1f3d9474a5129dbe565ec76a392426216ae73030","size":465},{"fn":"app/config/mail.php","sha1":"76af

wojteklu

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules