Difference between revisions of "Programming Context"

From Cybagora
Jump to: navigation, search
(Approach)
 
(3 intermediate revisions by one user not shown)
Line 7: Line 7:
  
 
* I want to understand the Linux/OS machine I use and the scripts necessary to execute what I want and I can send by '''intelligrams''' (cross network executable datagrams).
 
* I want to understand the Linux/OS machine I use and the scripts necessary to execute what I want and I can send by '''intelligrams''' (cross network executable datagrams).
* The intelligram approach permits to work along an "'''ASAP'''" ("[application] as a protocol") approach.  
+
* The intelligram approach permits to work along an "'''ASAP'''" ("[application] as a protocol") approach and support very large "industrial" systems where customized hundred of similar structures can replicated and maintained in parallel on the same of different SDNs (Software Defined Network).
  
 
I work on windows (often DOS, I am an old one, since ASAP is windowing ignorant: a remote/networked batch) where I have my tools [I learned it helped spotting flaws more easily to work in two different contexts] in order to :
 
I work on windows (often DOS, I am an old one, since ASAP is windowing ignorant: a remote/networked batch) where I have my tools [I learned it helped spotting flaws more easily to work in two different contexts] in order to :
Line 16: Line 16:
 
=== <br/>Experience ===
 
=== <br/>Experience ===
  
I managed this way several projects with up to 3000 similar sites. I hate non-prompt relation with the machine.
+
I managed this way several projects with up to 3000 similar sites. I therefore hate non-prompt relation with a remote machine. This progressively builds experience towards a rustic and robust networked use inter-applications system ('''netix''').
  
== <br/>The kind of help I need ==
+
== <br/>Basic framework ==
  
I need '''models''' of the scripts for the task I have in mind in my above context, and support (explanation) if I meet difficulties with them and my approach.
+
This approach calls for prompt '''models''' of the scripts for the task in mind, and support (explanation) when a difficulty is met (for example when an application has its own prompt layer).  
  
For example I know I have to use MySQL/PHP because most of the tools use them. But I do not know MySQL (never found a MySQL '''system management''' doc) and I have not developped PHP for years. I try to stay with batch/scripts I can generate.
+
==<br> Wiki centered project ==
  
I am more interested in learning possibly Python, certainly JS and Elixir and NoSQL (CouchDB?) in a structured way, but did not find yet a good method/teacher for that.
+
Mail corresponds to direct one to one exchanges. Wiki is "mail 2.0": it introduces a second generation of exchange where the same text can be worked on and seen by many. The next generation ("mail 3.0") will permit several works on several federated versions of the same topic and be selected/compared by many.
 
+
==<br> Wiki centered project ==
+
  
I have became found of Wikis and want to expand the concept from experiencing first MediaWiki simple, robust, versatile, etc. farming for my own need. I plan to document further on a simple MediaWiki oriented use by people for people (cyberagora). Then to switch the wiki support to a NoSQL + DNS like environment.  
+
Right now MediaWiki is the most appropriate working solution. Cybagora is dedicated to practical R&D in the mail 3.0 architectural line, within the Presentation Layer six framework.
  
This approach is the cybagora concept. But this is '''NOT''' for now.
+
However, this is '''NOT''' for now yet.

Latest revision as of 14:08, 13 June 2014

This page describes the way I conceive systems to those helping me or I cooperate with.

.


Approach

My background is not software development (I am more network software and internet architecture oriented). I have experience in an odd method inherited from learning developping in extending the QNX OS for a personal venture and network design experimentation.

  • I want to understand the Linux/OS machine I use and the scripts necessary to execute what I want and I can send by intelligrams (cross network executable datagrams).
  • The intelligram approach permits to work along an "ASAP" ("[application] as a protocol") approach and support very large "industrial" systems where customized hundred of similar structures can replicated and maintained in parallel on the same of different SDNs (Software Defined Network).

I work on windows (often DOS, I am an old one, since ASAP is windowing ignorant: a remote/networked batch) where I have my tools [I learned it helped spotting flaws more easily to work in two different contexts] in order to :

  • build a database (excel) of the parameters I need for the different sites I micro-industrialize.
  • develop in "rusty" C (I am an old one) program to general a systematic script/intelligram system.
  • load/maintain a copy of the scripts on the remote Linux machine and cron/execute it to carry the tasks on many sites.


Experience

I managed this way several projects with up to 3000 similar sites. I therefore hate non-prompt relation with a remote machine. This progressively builds experience towards a rustic and robust networked use inter-applications system (netix).


Basic framework

This approach calls for prompt models of the scripts for the task in mind, and support (explanation) when a difficulty is met (for example when an application has its own prompt layer).


Wiki centered project

Mail corresponds to direct one to one exchanges. Wiki is "mail 2.0": it introduces a second generation of exchange where the same text can be worked on and seen by many. The next generation ("mail 3.0") will permit several works on several federated versions of the same topic and be selected/compared by many.

Right now MediaWiki is the most appropriate working solution. Cybagora is dedicated to practical R&D in the mail 3.0 architectural line, within the Presentation Layer six framework.

However, this is NOT for now yet.