Alcuni passaggi sono molto significativi, in particolare:
DoD must have software that is easily adaptable to changing mission needs and can be evolved rapidly and delivered quickly at lower costs to meet mission requirements in a timely manner. (Il Dipartimento della Difesa necessita di software facilmente adattabile alle variabili esigenze della missione e che possa essere evoluto rapidamente e consegnato velocemente a costi più bassi, per soddisfare i requisiti della missione in modo tempestivo.)

E anche:
…a monopoly on the knowledge of a military software system and control of the software source code. This is optimal only for the monopoly contractor, but creates inefficiencies and ineffectiveness for the government, reduction of opportunities for the industrial base, severely limits competition for new software upgrades, depletes resources that can be used to better effect and wastes taxpayer-provided funds (..il monopolio della conoscenza di un sistema software militare e di controllo del codice sorgente. Questo è ottimale solo per il fornitore monopolista, ma crea inefficienze e inefficacia per il governo, la riduzione di opportunità per la base industriale, limita gravemente la competizione per gli aggiornamenti software, spreca risorse, che possono essere utilizzate con un risultato migliore, e fondi forniti dai contribuenti).

Che dire? Parole sante!

E per finire un riassunto dei punti chiavi positivi dell’open source:

• Increased Agility/Flexibility (maggiore agilità/flessibilità)
• Faster delivery (consegna più rapida)
• Increased Innovation (maggiore innovazione)
• Reduced Risk (riduzione del rischio)
• Information Assurance & Security (garanzia di informazioni e sicurezza)
• Lower cost (costo più basso)

Gli stralci del documento e il documento sono di proprietà dell’U.S. government e sono rilasciati con licenza Creative Commons Attribution ShareAlike 3.0 (CC- BY-SA). Per maggiori informazioni vedi http://creativecommons.org/licenses/by/3.0/.

• contatti
1. nome
2. cognome
3. indirizzo
4. fax
5. telefono
6. ecc.

Un punto importante da osservare è la granularità dei dati, cioè se devo scrivere – ad esempio – nome e cognome in due campi separati o in uno unico, o se l’indirizzo è compreso di CAP e città e provincia oppure tutto in campi separati.
Questo dipende da quale utilizzo può avere il database. Se devo inviare una mass-mail separando per CAP, oppure inviare delle lettere con scritto “Caro -utente-”, dovrò sicuramente suddividere i campi. In linea di massima, è sempre più sicuro suddividere i campi.

Durante l’elencazione dei campi, risulterà che alcuni hanno una possibilità limitata di scelta: ad esempio, alcuni dipendenti di un’azienda faranno parte dell’ufficio acquisti, altri dell’ufficio vendite e così via. In questo caso è più comodo estrarre il campo e creargli una sua tabella dedicata: ci sarà quindi la tabella “Reparto”, mentre nella tabella “Dipendenti” sarà presente solo un campo collegato.

Un altro punto da valutare è il riutilizzo dei dati: se il contatto diventerà in futuro un cliente, è preferibile riutilizzare i dati già inseriti. Quindi, invece di creare una tabella Contatti e una tabella Clienti, è possibile creare una tabella Partner con i soli dati comuni e delle tabelle collegate con i dati specifici (un contatto non avrà il codice fiscale, mentre un cliente sì), come proposto dal secondo dei testi indicati nel post precedente.
In alternativa, un semplice campo che permette di scegliere: “cliente”, “contatto”, “fornitore”, ecc., se riteniamo accettabile di mettere tutti i campi che servono nella stessa tabella.

Per cominciare, l’extension Toools (sapete che OOo permette di installare, in maniera veramente semplice, dei programmi aggiuntivi, no? guardate il sito delle extensions se ancora non lo avete visto) permette di gestire anagrafiche (clienti, fornitori, pagamenti, ecc.) e di creare documenti (fatture e note di accredito), a parte un gantt di programmazione di attività, che ora non interessa.
E’ quindi molto basilare come gestionale (non ci sono neanche i ddt), ma a qualcuno potrebbe bastare così, e va bene come esempio.

Il primo punto da sviluppare è il database: direi che è utile studiare come strutturare un database, e un testo che ho trovato molto utile è stato questo:

• (link diretto al pdf – parte 1) -en
• (link parte 2) -en
• (link parte 3) -en

Per uno studio più completo è utile integrare un manuale sulla teoria dell’SQL, anche se non strettamente necessario, come il seguente del Ministero del Tesoro: (link diretto al pdf)

Ore 00.26 – fine prima parte (n.b. non c’è una logica nella divisione di questo intervento, a parte l’orario di Morfeo )

Il trigger su PGSQL è il seguente:
CREATE OR REPLACE FUNCTION edil.incr_pos()
RETURNS trigger AS
$BODY$
DECLARE
v_pos RECORD;
rec integer;
BEGIN
SELECT pos INTO v_pos FROM edil.prev_articoli
WHERE id_prev_prodotti = NEW.id_prev_prodotti
ORDER BY pos DESC LIMIT 1;
rec := v_pos.pos+1;
IF rec IS NULL THEN
rec = 1;
END IF;
NEW.pos := rec;
RETURN NEW;
END

e funziona tranquillamente.
Mentre l’equivalente in MySQL no:
CREATE TRIGGER `edil`.`pos_prod`
BEFORE INSERT ON `edil`.`prev_prodotti`
FOR EACH ROW
BEGIN
SET NEW.pos = (SELECT MAX(prev_prodotti.pos) FROM edil.prev_prodotti AS prev_prodotti )+ 1;
END

(certo l’aspetto è un po’ diverso )

Questo dimostrerebbe che MySQL non ha aggiornamenti di sviluppo, ma solo di mantenimento.

Download qui.

Python intanto è stupendo e ricchissimo, spero di avere più tempo per usarlo in futuro. Creare dei servizi a proprio piacimento inoltre è veramente comodo. Ad esempio, lo script seguente sendMail.py (in grassetto i passaggi più importanti per la creazione del servizio) può essere implementato come servizio in OOo:

import smtplib
import uno
import unohelper
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from it.icstools.fastmailmerge import XFMM

# Open a plain text file for reading. For this example, assume that
# the text file contains only ASCII characters.
class MailImpl( unohelper.Base, XFMM ):
def __init__( self, ctx ):
self.ctx = ctx

def sendMimeMail(self, fileUrl):
textfile = fileUrl
fp = open(textfile, ‘rb’)
# Create a text/plain message
msg = MIMEMultipart()
mimetext = MIMEText(fp.read())
msg.attach(mimetext)
fp.close()
me = ‘sergiocorato at gmail.com’
you = ‘icstools at icstools.it’
# me == the sender’s email address
# you == the recipient’s email address
msg['Subject'] = ‘Subject’
msg['From'] = me
msg['To'] = you

# Send the message via our own SMTP server, but don’t include the
# envelope header.
s = smtplib.SMTP(‘smtp.tre.it’,’25′)
s.sendmail(me, you, msg.as_string())
s.quit()
return None

#g_exportedScripts = sendMimeMail,
def createInstance( ctx ):
return MailImpl( ctx )

g_ImplementationHelper = unohelper.ImplementationHelper()
g_ImplementationHelper.addImplementation( \
createInstance,”it.icstools.fastmailmerge.python.MailImpl”,
(“it.icstools.fastmailmerge.acaso”,),)

Creando un file di configurazione a partire da un file .idl (file di puro testo):

#include

module it { module icstools { module fastmailmerge {

interface XFMM
{
any sendMimeMail([in] string fileUrl);
};

}; }; };

Con i seguenti due comandi (i link devono essere ovviamente aggiornati):

/opt/openoffice.org3/basis-link/sdk/bin/idlc -w -I /opt/openoffice.org3/basis-link/sdk/idl/ /home/sergio/…/idl/XFMM.idl

/opt/openoffice.org3/basis-link/ure-link/bin/regmerge /home/sergio/…/XFMM.rdb /UCR /home/sergio/…/idl/XFMM.urd

e pacchettizzando il tutto in un’extension.

Il file manifest.xml dell’extension deve contenere le seguenti righe (i nomi dei file devono essere aggiornati):

manifest:full-path="XFMM.rdb"/>
manifest:full-path="sendMail.py"/>

Per accedere al nuovo servizio da OOoBasic è sufficiente usare questa macro:

mgr = getProcessServiceManager()
oTI = mgr.createInstance(“it.icstools.fastmailmerge.python.MailImpl”)