DEV.SKY. application

In SKY. in parallel with a developed application, in the same virtual Web server, always, application DEV.SKY. is installed which is intended for facilitation and acceleration of the engineering process. Application DEV.SKY. complements the code by the file dev.php and the folder _dev with files inside, and a database with five tables with a prefix _dev_. Code and tables in the database of DEV.SKY. application must NOT be copied during installation of the code of a developed site to a "production" server. The application is used only on a developer's local computer, during development. For each project and for each programmer a separate copy of DEV.SKY. application is used.

Installation is very simple: copy the file dev.php (39 lines) from any of your other projects or download it from the site and run: http://address_of your_project_on_local_computer/dev.php, it will download from the server and run the installation program i_dev.php. In the installation program, fill in the access to the database of a developed application (five tables of DEV.SKY. application will be added to the same database) and install DEV.SKY.

A programmer's work includes a number of works (besides programming) that must be done, and each one finds his own way for implementation of these works – applies various software or other methods which facilitate the process of code creation. DEV.SKY. encapsulates all similar necessary tools in one application and, in addition, it is a client of a SKY. system, which allows to receive and transmit to the server a reusable code. See a brief list of functionality in the table.

Functionality Short summary Status
Codebase browser Code view, search in the local Codebase 90%
j.SKY. Alternative in relation to jQuery javascript framework, makes its first appearance in DEV.SKY., for more details read about j.SKY. in the article 50%
My Snapshots Files snapshorts and the database of a developed application for subsequent determination of changes and automatic building of scripts 90%
Create Scripts Automatic building of change scripts on the basis of files snapshorts and the database 90%
Create Winds Building of console scripts of changes independent (from DEV.SKY.) (a necessary part of a Codebase record analyzer is activated into a script) 90%
Build Scripts Execution of the scripts of changes for the applications deployment and update 99%
Rollback Scripts Cancellation of changes after the applications deployment and updates 50%
Settings Change of DEV.SKY. settings 99%
Help Built-in DEV.SKY. Help 80%
Compare A text comparison utility (diff, is used for building of change scripts and visualization of changes) 90%
Update DEV An update of Codebase local databse with new records out of (download of necessary applications, updates, plug-ins, secondary reusable code, language records) 99%
Submit work Upload of records from local DEV.SKY. to the server (publication of your own work) 99%
Tune Package Syntax check and tuning of packages as a rule of your own ones 99%
My Builds A list of Codebase records for rollback, if it is necessary, and for history 99%
CopyTo Copying or transferring of Packages-Files-Wind_scripts-SKY._archives to a drive-mail- SSH-FTP 40%
Delete files & Recycle bin Deleting of files to the bin, viewing, bin management (used for rollback) 99%
Export Codebase Exporting Codebase records to files or SKY. Archives 99%
Import Codebase Importing export files and SKY. archives 99%
MySQL query A utility to work with a MySQL database 99%
Test Javascript A utility to test javascript 99%
Test PHP A utility to test PHP 99%
XDebug-er A PHP code debugger on the basis of xdebug module of PHP 75%
Test HTML A utility to test HTML code 80%
Visual SKY. app A utility for quick visual creation of a Web application framework 60%
Globals A utility for viewing global data and phpinfo() 99%
Search and replace A tool "search and replacement" on the basis of "domain" (including in the database) 99%
Mass tasks A utility for other tasks on the basis of "domain" (Check php syntax, Fix dummy code, Fix code on move files, Calculate size, MD5 sum, Functions map, Change texts encoding) 10%
Translate MyApp A utility for working with a table _lang (translation) of a user's application and generation of language files, see code of functions t(), translate(..) 90%
Application DEV.SKY. very compact, see the structure of the database tables and code of files now.

Internal structure of a DEV.SKY. core

figure 1


The Codebase entries are the rows in a _dev_codebase table, they have the following properties:

The record groups are combined into packages, information transfer between the server and application DEV.SKY. always goes on in archived packages. The package contains the application DEV.SKY, translations of the application into other languages, the coresky code for its reuse, and other applications. The packages can contain start_id attribut equal to a certain value. It means the whole package is a unit and, if it is executed - then all records of the package must be executed. The package contains start_id attribut equal to 0, it means it contains entries with different purposes. All the Codebase space is divided into areas (by the autoincrement column ID, see "help/Draft"), records1-50000 make a fixed area (particular ID introduces one and the same record on all application installations), over 50000 is a "floating" area – in each installation of DEV.SKY. the records represent different records, therefore at export of records they are normalize according to value 50000, and the first packet record is always equal to 50001. At import (if you detected a value exceeding 50000), the records will be added to a _dev_codebase table into a free space, the current value of auto_increment, with the ID of records and invocations with the command RUN CODEBASE: of other records are corrected, at the same time the ID of one and the same records for the installation, where we had the import, more often does not coincide with the installation where we had export. We cannot refer from the fixed area to the "floating" area, but quite the opposite - we can refer from the "floating" area to the fixed area.

The records from the fixed area are unambiguously identified with help of the ID of a record plus the name-version of a package, for example, [1] or the record ID plus the name of the record + a version, for example, [1] The records in the fixed area can have identical names, but represent different records, for example, f:index.php is an index file for one and another application, therefore in the example ([1] the name is specified for convenience, the record is unambiguously identified with the ID plus a version.

The packets are not unambiguously identified by zero SKY_ID or the name of a packet plus a version. When a programmer created a new packet, SKY_ID is equal to 0. During packet transfer to the server first the query "reserve" – reservation of SKY_ID and a version for this name – is executed. Having received a response, the packet load script inserts the given SKY_ID and replaces a version, afterwards exports the packet to an archive and then passes it to the server.

If the name of a packet is used in the system already, for example, then only the first author of this name (or the users who received the author's permission) can load new versions of this name to the server (packets), i.e. not all users can configure new versions of applications. But all the users can enhance applications of other authors, making updates. For example, any user can create an update of a packet, having named the packet as, where neo is his login on a site (u is the sign of an update). The logins are unique in the server, so it is easy to select the name of a packet to find a free name. If you name an update packet as and this name turns out to be used by another user, the system will not accept the packet, will give an error with a suggestion to rename a packet because the name is reserved by another user (group of users). In the name of a packet it is always desirable to refer to the application for which it is designed, as in examples above, - if this is update of DEV.SKY. , you must write .dev in the end of the name, or another example - neo_ftp.core. The name of a packet tells that the packet contains the records from a user - neo, as coresky (code for reuse) in the area of manipulations with ftp. The author of can put this code in the next version into the content of a packet.

The script for automatic generation of packet records always generates records to the "floating" area and you must almost always pass packets from this area to the server, but not from the fixed area. In the "floating" area the records ID does not anyhow participate in identification of packet records, it serves only for relative placement of records in a packet with respect to each other. Therefore only a unique identification of packets (but not of records in them) makes a difference, and the packets are identified also as packets with records in the fixed area - by a non-zero SKY_ID or the name of a packet plus a version. The authors having location of packets in the fixed area can relocate the work (or include their work into a new version) of other authors to their packets. At the same time authorship of all programmers is kept. If a programmer X changed a file of an author Y, then the record containing the file will indicate Y+X.

During making records in application DEV.SKY these records are marked in "utilities/My builds" like generation of new packets by programmers. In the second case, generation of the second packet is impossible until the first generated packet is passed to a server because it did not receive SKY_ID from a server and for the second packet there is no correct information for completing the lists "includes" and "depends". In the utility "My builds" unique records for a fixed area are marked in the list, and for a "floating" area names of unique packets are marked, and only the last one, the only one, can have SKY_ID equal to 0, and be not transmitted to a server.


There are special tools in DEV for development of applications and a SKY system in general. To create a new application first we create records in Codebase which are abstractly covering an uppercase spectrum of purposes (we generate necessary NULL–site which typically includes the code of the first and second wing), also having executed the search, we generate the necessary code of the third wing. After it we save the current state of the code into a snapshot, having selected a necessary snapshot domain and other parameters. It will allow to automatically generate a script for building of an application in the future. Further on, using utility Visual, we create a base BD application framework (programming is not used) and generate a file framework for administration and the frontal part for application objects, for example VIEW files of controllers and models of news list (for a news website). I will note that in the future it is planned to complement the utility Visual by a recording of macrocommands of completed actions, and to add to the parser a possibility of fulfilment of these macrocommands, i.e. in such a case it will be necessary to save a snapshot of application condition after using the utility Visual and during generation of a script applications, DB and the files received for the current moment of time will NOT be included into an application script, but, instead of them, the links to certain records in Codebase and a macrocommand of the utility Visual will be included.

All the completed Codebase records are marked as completed and saved on the special page of completed records "My Builds". During creation of a snapshot their list is also copied to Snapshot to use them in generation of an application script.

After semi-automatic creation of an application framework and saving of a Snapshot, a unique programming is made by a person, and when the application is ready - the generation of an application script using Snapshot (made changes by a programmer). Concurrently with an application script, a package is created which unites a lot of generated Codebase records into a single unit. Data transfer between the server and client DEV applications in both directions always happens in packets. During work with a server the packets are always archived into a single file (with the help of compression functions Bzip2 PHP) with a special format. The files of such archives have a name suffix *.sky.

The packets can contain not only applications, but updates of applications (corrections, additions). To create an update package it is necessary to save Snapshot after all the current application and other necessary update packets are installed (if they exist and intersect with current work). The author of an application can give other programmers the right of generation of a new version if he wishes so, or do it on his own. But any programmer can create updates for any application. He just needs to register in a SKY. system (to receive the right of making records in Codebase on a server). The updates of applications can be included into a new version of an application by the author, at the same time the author of an update receives the right on the second (third, etc.) authorship, and the author of an application can give him the right of generation of new versions of an application. Any programmer can also do branching-off from any application (besides DEV.SKY.), for example, if there is FORUM.SKY. of general purpose, then its branching-off will be considered to be a new application (a certain specialized forum), at the same time all the authorships of the previous forum do not pass into a new one, but it is desirable to discuss creation of new applications and branching-off with the community if the author plans to place his work on a server. One should consider that transfer of new packets to a server can both raise and reduce a programmer rating in a SKY system.

Thus, in every packet, except other parameters, there are the following ones (we draw your attention to them): app - an application under development, depends – the packets that must be run before of current one (a minimum list), included - the updates which are included into a packet of a new packet, priorun – records of a packet, which are used for generation of a packet.

During generation of a new version of an application into the list "included", a version of an application (must be the first in the list) will always be included, except (possibly updates). On the basis of this version a new version of an application (typically a previous version) is generated. If there were no versions (it is a new application), the word "scratch" must be written. The updates included in the previous version are not written to the new list "included", but following the chain of versions one can make the whole list of updates to "scratch" (the first version of the application). In updates, in "depends", the first in the list must be written a version of DEV, and the second - a version of the application for which the current update is being developed. Generally in any packages (except the first version of DEV.SKY.), in the list "depends", the application will always be indicated as the first, with the version on the basis of which development must be performed (packet execution by a parser).


Check figure 2 below. The word "work" will usually be the last written into the list "included". It will indicate that the packet includes a programmer's work on modification of the application code. If the package is a new version of the application where the available updates are simply integrated (and there were no conflicts), the word "work" will not be written. The macrocommands of the utility Visual which were mentioned above refer to the list "priorun". Significant results can be described by a small amount of information (for example, any macrocode possesses such a property). In general, in the future, after a thorough test of this code development system we plan to significantly increase "priorun" possibilities because, due to automatic correction of the code, a share of work of a programmer is decreased. In the "priorun" list there can be also automatic correction of the code per it compliance with the standards (a simple algorithm used already now) and the search and replacement of the code parts with more optimal ones, etc. The list "priorun" can significantly evolve. We believe that such a system of the code development can in future lead us to communication with a computer by voice like with an intelligent system, and it would be able to execute our complex abstract tasks without special programming by a person.

figure 2

References to records of the Codebase of DEV package are shown in the list "priorun", but in the future the list can be like that, for example: priorun: 2,3,visual,x_fix. The second way of creation of application packets is shown in figure 3. For example, application DEV.SKY. was updated and the programmer integrates a new version of the application app from the start, on a "clean" DEV, at the same time he makes selective coping of the code of the application app.v2, allowing conflicts, and gets app.v3.

figure 3

In the list "included", the auxiliary word "copy" always indicates that integration of a version of application was done on a "new" DEV.SKY.

The packets can have identical names, but in the binding - the name of a package plus a version - all of them are unique, also any packet has a unique SKY_ID which unambiguously identifies the particular packet. SKY_ID (and the version) are assigned by a server during upload of a packet to the server, until this point the SKY_ID field contains zero. Unlike the packets the record name of Codebase plus a version do not identify unambiguously the record. There can be several records with one and the same name and the version, but the CODEBASE_ID unambiguously identifies the record if this value is less than 50000.

During generation of new update packets, the Codebase records are always saved from autoincrement column id of the table _dev_codebase with a valueexceeding 50000, and starting from this value CODEBASE_ID have floating addressing. During creation of export files, the values are normalized to the value 50001, and during import of a record they are brought to a current value of autoincrement column in each particular installation of application DEV.SKY. From the area with ID exceeding 50000, there can be the links to the area with ID less than 50000, but it is not possible in the other way. For more detail do to help page "Draft" in application DEV.SKY.

In general, automatic generation of scripts always adds records only with ID > 50000 to the floating area. The users with a type of profile "root" make primary placement of applications in the area with ID < 50000 (static) using utility MOVE records. For the local Codebase of the application DEV.SKY. the ID from 1 to 10000 are allocated, the code includes: the application itself (DEV.SKY. builds itself), the code for reuse of 1,2,3 wings, the translation of DEV application into other languages (English is the basic language), NULL sites and a couple applications of general purpose ready to be expanded. The static area with the ID from 10001 to 50000 is stored only on the server and contains other applications available for download to DEV.


If you did some useful work, created a packet and want to share your work with a community, register on the site, create your nickname and put it into the account (it will not be possible to change it subsequently), write into the page of settings of application DEV. $u_reg_access_code – your personal access code, $u_sky_inet_login - your login, $u_profile_code – put 6 (type of profile – Registered), $u_my_app, $u_my_rubric – the name and the rubric of an application that is developed – after it in DEV application utilities in the page "Submit your work" open the packet, give its description (in English only), check the packet and optimize it manually. Sometimes definition of a domain does not allow to generate ideal packets and it requires manual adjustment of generated Codebase records. We do not mean the code with errors, but the imperfect code. If everything is good – send a packet to a server. We will give significant attention to moderation, analysis of the quality of code and strive to make in the future moderation and analysis of the code algorithmically without participation of people (and subsequently - it will also include generation of a new code :-), using a voice). The work is evaluated with the rating, ranks which represent certain bonuses in SKY. system (or their absence).


Simultaneously several people may want to perform the update of the same file in an application (which correspond to Codebase records), which would possible lead to uselessness of work of one of the programmers. Therefore before the beginning of work it is recommended to mark the application files as "taken into work" on this site. Other programmers then will be able to see this intention and will grant the right of modification to the one who first marked the records. After the expiration of maximum 3 days the programmer must generate an update packet and upload it to a server, having chosen "in work" in the code status (if work is not finished yet). And it will report that the work is continued, and the authors of an application will be able to see in which way. The latter does not concern the authors of applications and programmers with a high rating, but it is desirable for everyone to mark Codebase records as "taken into work". A mismatch of intentions with real actions can negatively affect the rating of a programmer. After the work is finished, it is necessary "to release" the records previously "taken into work".

For sharing the tasks and defining directions of work, collective discussions of tasks in blogs will also be practiced. It primarily refers to basic application and CORESKY code objects.

In all the packets, in the list "depends" the version of DEV.SKY will always appear the first. Application of DEV like other applications can evolve for a long time and from time to time new versions of DEV as well as of other applications will come out. It is desirable to build new versions of applications on the base of new versions of DEV. It can lead to the conflicts of the code in scripts which the authors of applications must resolve. However, the old versions of DEV (and other applications) are always available for download together with the new ones. And only, if there is no child object of the old DEV (the same concerns other applications as well), the *.sky packet will be deleted physically from the server (but not the information record about it). The packets (*.sky archives) included into other packets and absent in any other lists of "depends" will also be physically deleted.