Le leggi sui bytes
Esistono soltanto due byte(s) davvero tutti d'un pezzo: 00000000 e 11111111.Tutti gli altri byte sono dei pappamolla: datevi da fare!
Un byte ospitato(*) presso un sistema operativo esoso richiede più di un byte per essere gestito(*). (*) : memorizzato, spostato, copiato, appartenente ad un processo, utilizzato in qualsiasi operazione logica/aritmetica, masterizzato, etc.
Un GByte è formato da 1.024 MBytes.Un MByte è formato da 1.024 KBytes.Un KByte è formato da 1.024 bytes.Un byte è formato da 8 bit.Ogni bit è formato da 8 Chuck Norris. Questa legge non va commentata, altrimenti i Chuck Norris dentro il mio sistema mi fanno crashare il PC.
L'intelligenza di un software è pari al numero di features che contiene diviso il numero di bytes da cui è composto.Essa è espressa quindi come: featuresint = -------------------- bytes Note ed aggiunteAll'aumentare delle features contenute in un software, aumenta l'intelligenza di ogni singolo byte che compone il software stesso.All'aumentare del numero di bytes utilizzati, l'intelligenza di ogni singolo byte diminuisce.L'implementazione di un elevato numero di features, con un basso utilizzo di bytes, garantisce un'intelligenza elevata.Istanziare un elevato numero di bytes producendo poche features è sinonimo di poca intelligenza (del byte e del programmatore ;-). EsempioL'operazione NOP in assembler è l'operazione più semplice: è composta...
Grande Paradosso delle Virtual MachineChe senso ha impostare uno screensaver su una macchina virtuale hostata tramite Virtual PC, per esempio?
Grande Legge della Virtualizzazione dei bytesUn byte si definisce virtuale nell'istante t quando in quello stesso istante t viene acceduto da un processo virtuale. Note:Tutte le Leggi di Damiani sui Bytes si applicano anche a tutti gli eventuali bytes virtuali presenti nel sistema.
Io byto!Tu byti!Egli byta!Noi bytiamo!Voi bytate!Essi bytano! Good Byting a tutti!
Tutti i bytes nascono liberi. Si definisce libero un byte che non è allocato da alcun processo. Note sulla 16° LeggeDurante i primi cicli di clock di un sistema, i bytes non appartengono ad alcun processo o thread, pertanto si possono definire liberi. Considerazione: maggiore è il numero di bytes liberi in un sistema, migliore è la qualità della vita dei bytes all'interno del sistema stesso. Un byte libero è libero di spostarsi da una cella all'altra della memoria, di cambiare valore, di muoversi da un subsystem all'altro (core della CPU, graphics card, audio card, etc.), di viaggiare lungo i bus (PCI, AGP) e sulle porte...
I bytes estiviUn byte viene definito estivo quando viene
istanziato tra il 21 Giugno e il 20 Settembre.Un byte fa surf quando si sposta lasciandosi
trasportare dal fronte di salita (o di discesa) del clock.Un byte è tanto più abbronzato tanto più il suo valore si
avvicina a 0xFF.I bytes non conoscono file in
autostrada, al massimo litigano con colli di bottiglia da far
paura.I bytes non possono (quasi) mai
superare i limiti di velocità imposti dal sistema: il clock impone la
stessa velocità a tutti.L'unica possibilità che un byte ha di prendersi un cono gelato è quello di
chiedere alle DirectX di disegnargliene uno sulla memoria AGP.Un byte è in topless quando...
Varie ed eventuali sui bytesIl byte non nasce: viene istanziato.Il byte non diventa mai un adulto indipendente: c'è sempre
qualcuno che si occupa di lui. Il byte non
si riproduce: un thread dice al byte di
clonarsi.Il byte non si accoppia: può formare
un byte[2] con chi vuole.Il byte è poligamo per natura: può formare un byte[x] quante volte vuole.Il
byte non ha la patente e non guida: sale sul
bus e si fa portare dove necessario! Il byte non muore:
viene deallocato.
powered by IMHO 1.2
13° Legge di Damiani sui bytesI
bytes soffrono il caldo. Se dovete dichiarare un byte[2] (vedere la 2° Legge di Damiani), dichiarate un byte[3],
assicurandovi di avere sempre byte[1] = 0 per far
passare un po' d'aria.
Un byte sudato e/o accaldato potrebbe non essere del
tutto felice, e di conseguenza potrebbe essere portato a non lavorare in modo
appropriato, causando svariati crash di sistema incontrollati. Sistemi
tradizionali (ventilatori, aria condizionata, etc.) non agiscono direttamente
sui bytes, ma sull'hardware (environment) in cui il byte vive. Per ovviare al problema, e per rendere più felici i
bytes del vostro sistema, fate sempre...
I byte che vivono in sistemi
hardware appartenenti a soci UGIdotNET (chi più, chi meno) sono (comunque) dei
grandi.
powered by IMHO 1.2
1° Grande Teoria del Caos dei
BytesSia A il numero di
esseri umani viventi in un certo istante T.Sia B il
numero di bytes istanziati in un certo istante T.
Non importa il valore del rapporto A /
B:se i bytes decidessero di dichiararci guerra, saremmo
comunque tutti spacciati entro l'istante T +
1.
powered by IMHO 1.3
Articolo 5 dello Statuto dei Diritti del
ByteEvitare il più possibile violenti sbalzi del patrimonio
genetico di un byte.Ad improvvisi cambiamenti
del valore di un byte seguono diversi e svariati
malesseri del byte stesso.
Passare da 0x00 a 0xFF, oppure
da 0xFF a 0x00, sono i casi
estremi, nei quali il byte subisce stress inopportuno,
attacchi di panico, disorientamento, malessere e disturbi
vari. L'Articolo 1 dello Statuto dei Diritti del
Byte impone che il nostro codice deve girare grazie a
byte felici. E' fatto obbligo quindi il rispetto della
legge suddetta.
powered by IMHO 1.3
Un byte si
dice espansivo quando esegue autonomamente
metodi di altri oggetti per comunicare.Un byte si
dice introverso quando - sebbene istanziato
e valorizzato nel codice - ritorna sempre e comunque null.
powered by IMHO 1.3
L'unico patrimonio genetico proprio di un byte è il valore che esso contiene: due
bytes con lo stesso valore hanno lo
stesso patrimonio genetico, e di
conseguenza tendono a reagire - in un'analoga
situazione - con la stessa modalità.
powered by IMHO 1.2
Non accettare mai bytes da
thread sconosciuti.
Se il byte sta per essere eseguito, assicurarsi che il suo thread di
appartenenza sia identificato e non sia sconosciuto. Se il byte sta per essere -
più generalmente - memorizzato in un'area di memoria, assicurarsi che la
suddetta area appartenga e sia sotto il controllo di un thread ben
identificato.
powered by IMHO 1.2
Articolo 4 dello Statuto dei Diritti del ByteL'assembler
prodotto dal vostro codice deve contenere istruzioni NOP (no-operation)
inserite negli address corretti. Dopo un certo numero di cicli di clock
(valutabile di volta in volta a seconda delle necessità), ogni
byte ha il diritto di riposarsi.
Il byte non può lavorare per sempre, sempre a pieno regime e sempre in
piena efficienza.Ogni byte deve incontrare durante la sua
esecuzione istruzioni NOP, per garantire che possa rimanere memorizzato nello
stesso address per un certo numero di cicli di clock. Eventualmente, delegare ad
altri thread il task, in modo da coinvolgere altri bytes nel processo
corrente.
powered by IMHO...
Più il valore di un byte tende a
0x00, più il byte si sentirà depresso
ed insicuro.Più il valore di un byte tende a 0xFF, più il byte si sentirà
sicuro di sè e spavaldo.Se il byte è un ?byte (nullable byte),
ed il suo valore è null, il byte stesso si
sentirà una nullità.
powered by IMHO 1.2
Articolo 3 dello Statuto dei Diritti del ByteQuando
eseguite il vostro codice step-by-step (passo-passo), quando
impostate un breakpoint (condizionale o non), quando esaminate il
valore degli oggetti con il tooltip o con le finestre Watch,
Locals e simili di Visual Studio, i bytes si
sentono osservati e, di conseguenza, si chiudono in loro stessi.
E' necessario limitare il debug in queste condizioni, perchè il byte osservato potrebbe diventare infelice. Per
ovviare all'inconveniente, è consigliabile debuggare tramite
unit-testing che è meno invasivo nei confronti della privacy del byte.
powered by IMHO 1.2
Articolo 2 dello Statuto dei Diritti del
ByteMeglio un byte solo che un byte[2] male accompagnato.
Il vostro codice non deve essere solo efficiente e performante. La 2° Legge di Damiani impone che deve essere
innanzitutto felice. Per garantire questa condizione,
usare strumenti diagnostici per misurare il grado di felicità
(happiness) del vostro codice managed: vedere il namespace
System.Diagnostics.Happiness. I bytes che formano l'array byte[2] devono convivere in modo sereno, pulito, con una
qualità di vita elevata. Se così non dovesse essere, meglio dichiarare un
byte singolo.
powered by IMHO 1.2
Articolo 1 dello Statuto dei Diritti del
ByteSe nel vostro codice vi serve un byte,
dichiarate *sempre* almeno un byte[2].Consumerete almeno il doppio della memoria, ma i bytes si
sentiranno meno soli ed il codice sarà più felice.
powered by IMHO 1.2
Se il vostro sistema crasha molto spesso,
probabilmente c'è un byte innamorato (o desideroso di esserlo) nei vostri banchi di RAM.
powered by IMHO 1.2