Software Astrology

Extending channeling to user interfaces. From the domain of Physiognomy to the new discipline:

Dialognomy or Dialognomics

From “dialog” and Greek “gnomon” (’interpreter’). Assessment of a computer program behavioural characteristics and internals from its user interface appearance.

More to come.

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 5, 13, 22
• Days of unfortunate computation: 9, 18, 26
• Days of good enough software behaviour: 2, 11, 20, 29
• Fault-free days: 7, 16, 24

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 9, 18, 26
• Days of unfortunate computation: 4, 13, 22, 31
• Days of good enough software behaviour: 6, 15, 24
• Fault-free days: 1, 11, 20, 29

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11, 20, 30
• Days of unfortunate computation: 7, 16, 25
• Days of good enough software behaviour: 9, 18, 27
• Fault-free days: 5, 14, 23

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Heap Expansion

Modules, products or systems built on December 15 compute big. Their expansive algorithms run free into wilderness. Few limitations exist for their code because it knows how OS works, but once they are on top of the list they don’t know how to keep staying there. December 15 components need to learn how to be satisfied at various resource levels and security restrictions. They do their best in computation when they care about other modules and do not interfere with other processes and threads. Products built on December 15 are liked by many customers. When they see them compute they feel good with their easy and open interfaces. December 15 modules from financial products are open to exploits and have vulnerabilities discovered with depends.exe. They are usually not concerned with such matters and can be sometimes computationally fatalistic, destined to loose data but can restart instead of hanging on exception. Thoroughly compute with all possible checks and then move to another step of their algorithm is the safest thing for them. Modules, products or systems built on December 15 may overestimate resources available for them and overlook deterioration symptoms so various external checks are recommended during their normal computational life span. Training is mandatory for their troubleshooters. Data restrictions are not necessary unless insisted by a security engineer. Running on open platforms is advised for December 15 systems.

DLL, SYS and EXE born on this date:

usrxcptn.dll Fri Dec 15 08:33:42 2006
PCIWNT.SYS   Tue Dec 15 19:46:09 1998
AegisP.sys   Thu Dec 15 10:31:20 2005
srv.sys      Mon Dec 15 21:42:35 2008


Weaknesses: Unrealistic expectations of available resources. Blind messaging.

Strengths: Well-linked modules. Cheerful sounds.

Advice: Don’t have a condescending attitude towards customers. Learn to deal with security constraints. Remember that heap can contract too.

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 5, 14, 24
• Days of unfortunate computation: 10, 20, 27
• Days of good enough software behaviour: 3, 11, 22, 25, 29
• Fault-free days: 8, 18, 25

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 4, 23, 31
• Days of unfortunate computation: 8, 19, 26
• Days of good enough software behaviour: 6, 24
• Fault-free days: 2, 10, 21, 29

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 3, 11, 21, 30
• Days of unfortunate computation: 7, 17, 26
• Days of good enough software behaviour: 19, 28
• Fault-free days: 5, 14, 24

- Dmitry Vostokov @ SoftwareAstrology.com -

• Days of possible critical problems: 7, 15, 25
• Days of unfortunate computation: 1, 11, 20, 29
• Days of good enough software behaviour: 3, 13, 23
• Fault-free days: 9, 18, 27

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Software Exhibition

Modules, products or systems built on December 14 impress potential buyers at software exhibitions viewing their GUI but they rarely open their internals to show what they really are inside and what they are really computing. December 14 components have very complicated code and complex architecture. Many of their computations are bizarre. Their code is not ordinary, is self-aware and often confronts their parent processes and computational authorities. Sometimes it is not even possible to fit them into a predefined algorithm and even if it works initially later it causes enormous problems, for example, outraging a customer. However the good side to their challenging behaviour is that they are catalysts for software change. Modules, products or systems built on December 14 should be very careful with accidental violations. Their code might not be understood or they themselves might not understand their environment and that could result in their withdrawal from computation.

DLL, SYS and EXE born on this date:

ialmrnt5.dll Wed Dec 14 20:47:26 2005
ialmdnt5.dll Wed Dec 14 20:47:19 2005
ialmdev5.DLL Wed Dec 14 20:47:09 2005
ialmdd5.DLL  Wed Dec 14 20:54:40 2005
ialmnt5.sys  Wed Dec 14 20:55:38 2005
lknuhst.sys  Thu Dec 14 22:11:24 2006
lknuhub.sys  Thu Dec 14 22:11:15 2006
cygwin1.dll  Fri Dec 14 19:21:07 2007


Weaknesses: Excessive computation. Isolated code.

Strengths: Original and provocative UI. Daring computation.

Advice: Make your code fix suggestions quietly while carefully considering what you propose and what you say to another engineer. Choose the middle way in troubleshooting, debugging and code reviewing and be philosophical with your peers, internal and external customers.

- Dmitry Vostokov @ SoftwareAstrology.com -