2014-02-24 05:13:28 +00:00
[ b ] Red Developer Guide [ / b ]
2014-05-06 02:45:30 +00:00
We ' re pretty relaxed when it comes to developers . We don ' t have a lot of rules . Some of us are over - worked and if you want to help we ' re happy to let you help . That said , attention to a few guidelines will make the process smoother and make it easier to work together . We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience . Our primary rule is to respect others . Sometimes this is hard and sometimes we have very different opinions of how things should work , but if everybody makes an effort , we ' ll get along just fine .
2014-02-24 05:13:28 +00:00
[ b ] Here is how you can join us . [ / b ]
First , get yourself a working git package on the system where you will be
doing development .
Create your own github account .
2015-04-01 22:52:02 +00:00
You may fork / clone the Red repository from [ url = https : / / github . com / redmatrix / redmatrix . git ] https : / / github . com / redmatrix / redmatrix . git [ / url ]
2014-02-24 05:13:28 +00:00
Follow the instructions provided here : [ url = http : / / help . github .com / fork - a - repo / ] http : / / help . github .com / fork - a - repo / [ / url ]
to create and use your own tracking fork on github
Then go to your github page and create a & quot ;Pull request" when you are ready
to notify us to merge your work .
[ b ] Translations [ / b ]
2015-05-14 00:59:45 +00:00
Our translations are managed through Transifex . If you wish to help out translating the $ Projectname to another language , sign up on transifex . com , visit [ url = https : / / www . transifex .com / projects / p / red - matrix / ] https : / / www . transifex .com / projects / p / red - matrix / [ / url ] and request to join one of the existing language teams or create a new one . Notify one of the core developers when you have a translation update which requires merging , or ask about merging it yourself if you ' re comfortable with git and PHP . We have a string file called ' messages . po ' which is gettext compliant and a handful of email templates , and from there we automatically generate the application ' s language files .
2014-02-24 05:13:28 +00:00
2014-05-28 07:43:17 +00:00
[ zrl = [ baseurl ] / help / Translations ] Translations - More Info [ / zrl ]
2014-02-24 05:13:28 +00:00
[ b ] Important [ / b ]
Please pull in any changes from the project repository and merge them with your work * * before * * issuing a pull request . We reserve the right to reject any patch which results in a large number of merge conflicts . This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions .
Also - * * test your changes * * . Don ' t assume that a simple fix won ' t break something else . If possible get an experienced Red developer to review the code .
Further documentation can be found at the Github wiki pages at : [ url = https : / / github . com / friendica / red / wiki ] https : / / github . com / friendica / red / wiki [ / url ]
[ b ] Licensing [ / b ]
All code contributed to the project falls under the MIT license , unless otherwise specified . We will accept third - party code which falls under MIT , BSD and LGPL , but copyleft licensing ( GPL , and AGPL ) is only permitted in addons . It must be possible to completely remove the GPL ( copyleft ) code from the main project without breaking anything .
2014-05-06 02:45:30 +00:00
[ b ] Concensus Building [ / b ]
Code changes which fix an obvious bug are pretty straight - forward . For instance if you click " Save " and the thing you ' re trying to save isn ' t saved , it ' s fairly obvious what the intended behaviour should be . Often when developing feature requests , it may affect large numbers of community members and it ' s possible that other members of the community won ' t agree with the need for the feature , or with your proposed implementation . They may not see something as a bug or a desirable feature .
We encourage concensus building within the community when it comes to any feature which might be considered controversial or where there isn ' t unanimous decision that the proposed feature is the correct way to accomplish the task . The first place to pitch your ideas is to [ url = https : / / zothub . com / channel / one ] Channel One [ / url ] . Others may have some input or be able to point out facets of your concept which might be problematic in our environment . But also , you may encounter opposition to your plan . This doesn ' t mean you should stop and / or ignore the feature . Listen to the concerns of others and try and work through any implementation issues .
There are places where opposition cannot be resolved . In these cases , please consider making your feature [ b ] optional [ / b ] or non - default behaviour that must be specifically enabled . This technique can often be used when a feature has significant but less than unanimous support . Those who desire the feature can turn it on and those who don ' t want it - will leave it turned off .
If a feature uses other networks or websites and or is only seen as desirable by a small minority of the community , consider making the functionality available via an addon or plugin . Once again , those who don ' t desire the feature won ' t need to install it . Plugins are relatively easy to create and " hooks " can be easily added or modified if the current hooks do not do what is needed to allow your plugin to work .
2014-02-24 05:13:28 +00:00
[ b ] Coding Style [ / b ]
In the interests of consistency we adopt the following code styling . We may accept patches using other styles , but where possible please try to provide a consistent code style . We aren ' t going to argue or debate the merits of this style , and it is irrelevant what project ' xyz ' uses . This is not project ' xyz ' . This is a baseline to try and keep the code readable now and in the future .
[ li ] All comments should be in English . [ / li ]
[ li ] We use doxygen to generate documentation . This hasn ' t been consistently applied , but learning it and using it are highly encouraged . [ / li ]
[ li ] Indentation is accomplished primarily with tabs using a tab - width of 4. [ / li ]
[ li ] String concatenation and operators should be separated by whitespace . e .g . & quot ;$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';"[/li]
[ li ] Generally speaking , we use single quotes for string variables and double quotes for SQL statements . & quot ;Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes.[/li]
[ li ] Use whitespace liberally to enhance readability . When creating arrays with many elements , we will often set one key / value pair per line , indented from the parent line appropriately . Lining up the assignment operators takes a bit more work , but also increases readability . [ / li ]
2014-05-06 02:33:48 +00:00
[ li ] Generally speaking , opening braces go on the same line as the thing which opens the brace . They are the last character on the line . Closing braces are on a line by themselves . [ / li ]
PostgreSQL support initial commit
There were 11 main types of changes:
- UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but
it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just
copied from Friendica. All of these instances, the LIMIT 1 was simply removed.
- Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit
integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice
to boot). Proper explicit boolean conversions were added. New queries should use proper conventions.
- MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_
func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There
were no true toggles (XOR). New queries should refrain from using XOR when not necessary.
- There are several fields which the schema has marked as NOT NULL, but the inserts don't specify
them. The reason this works is because mysql totally ignores the constraint and adds an empty text
default automatically. Again, non-compliant, obviously. In these cases a default of empty text was
added.
- Several statements rely on a non-standard MySQL feature
(http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten
to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run
a zillion times faster, even on MySQL.
- A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG,
UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_
- INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes
around the value -- assist functions added in the dba_
- NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such
thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are
handled in Zot/item packets automagically by quoting all dates with dbescdate().
- char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the
code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works
better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype
for all text fields in the postgres schema. varchar was used in a couple of places where it actually
seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code
actually validates data, new bugs might come out from under the rug.
- postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted.
bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function
was added to handle this transparently.
- postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax.
Statements were updated to be standard.
These changes require corresponding changes in the coding standards. Please review those before
adding any code going forward.
Still on my TODO list:
- remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting
- Rewrite search queries for better results (both MySQL and Postgres)
2014-11-13 20:21:58 +00:00
[ b ] See Also [ / b ]
[ zrl = [ baseurl ] / help / sql_conventions ] SQL Conventions [ / zrl ]
2014-10-19 23:12:05 +00:00
# include doc / macros / main_footer . bb ;
