Lo segno come appunto personale.

E' possibile modificare l'owner di un oggetto di SQL Server utilizzando la stored procedure:

sp_changeobjectowner [ @objname = ] 'object' , [ @newowner = ] 'owner'

The First Rule of User Experience

For your software to succeed, it must be intentionally designed to help the user achieve their goals.

First Corollary

If you don’t know the user or their goals, any success you have will be purely coincidental.

The basic equation for a developer career looks like this:

C = G + LT

C is Cluefulness. It is defined as an overall measure of your capabilities, expertise, wisdom and knowledge in the field of software development. It is the measure of how valuable you are to an employer. It is the measure of how successful your career is. When you graph your career, C is on the vertical axis.

G is Gifting. It is defined as the amount of natural cluefulness you were given "at the factory". For each individual, G is a constant, but it definitely varies from person to person.

L is Learning. It is defined as the rate at which you gain (or lose) cluefulness over time.

T is Time. It is on the horizontal axis of your career graph.

Erik Sink ha scritto un post molto interessante (e che condivido assolutamente) relativamente al fatto che il segreto degli sviluppatori con alle spalle una carriera eccezionale, stia nella derivata prima dell'equazione sopra citata.

In base alla sua equazione, la carriera di uno sviluppatore è determinata da tre variabili, delle quali, solamente una è controllabile: L = Learning; ogni giorno si fanno delle scelte che modificano il suo valore, che ne siamo consapevoli o meno.

Il segreto sta nel concentrarsi nella derivata prima della funzione, ossia nel tasso di crescita del suo valore nei confronti di una variabile.

Concentrarsi solamente su C o sulla percezione che gli altri hanno del nostro valore C, è una perdita di tempo. La chiave per avere una grande carriera è la concentrazione su L, che è la derivata prima dell'equazione rispetto al tempo T, ossia il tasso di crescita di C al trascorrere del tempo.

Il valore istantaneo di C in un determinato momento non è significativo, l'unica questione importante è il fatto che il valore del tuo C stia aumentando o diminuendo... o se sia semplicemente bloccato.

Sembra ovvio, ma non lo è per la maggior parte delle persone. Per molti sviluppatori L è zero, quindi qualsiasi valore positivo di L può elevarti rispetto alla massa. Se rendi il tuo L positivo, ti aspetta una grande carriera; il valore iniziale di G non ha più importanza perchè il tuo C sta aumentando giorno dopo giorno e le tue opportunità future saranno migliori.

Il segreto sta quindi nell'apprendimento costante, e la migliore esperienza che si può fare nell'ambito del lavoro quotidiano è imparare dai propri errori.

Rendere pubblici i propri errori per condividere l'esperienza con i propri colleghi è molto difficile: è molto più semplice sistemare tutto e fare in modo che nessuno si accorga di quanto è successo. Ma questo approccio comporta la perdita di enormi opportunità per aumentare il nostro fattore C.

La pratica di imparare costantemente non è comunque priva di rischi: scegliere di avere un alto L rende vulnerabili nei confronti dei propri responsabili. Pubblicizzare i propri errori può portare a far si che il nostro reponsabile pensi che siamo degli idioti, può sfociare in punizioni o addirittura in un licenziamento. Un'altra situazione da evitare è l'essere bollati come problematici: alcuni manager preferiscono, in maniera più o meno conscia, avere team a derivata zero, in cui la situazione è stagnante e in cui nessuno può minacciare la sua posizione. Tali rischi sono reali e possono comportare conseguenze importanti.

Da ciò deriviamo il primo assioma ed il punto di partenza per prendere le redini della propria carriera:

Non lavorare per un capo
che ostacoli la tua pratica
di costante apprendimento.
Non farlo.

Corollario:

La prossima volta che avrai un colloquio di lavoro, pretendi che la gerarchia di potere sia ribaltata: il manager che sta cercando di assumerti sta valutando se sei la figura adatta per il lavoro; tu dovresti valutare se lui è adatto ad essere il tuo manager.

Tempo fa ho realizzato un sistema per automatizzare alcune attività di uno sportello comunale, in modo che i cittadini potessero usufruire di alcuni particolare servizi in orari extra lavorativi.

Al fine di misurare l'effettiva efficacia dell'azione, dopo qualche mese, ho dovuto effettuare una statistica per ottenere la suddivisione percentuale fra i servizi fruiti durante gli intervalli di apertura e di chiusura del comune. I dati dovevano essere quindi filtrati in base all'intervallo orario ed in base al fatto che il giorno considerato fosse o meno un giorno feriale.

La cosa è piuttosto semplice, ma può diventare un pò più triviale nel momento in cui si volesse scrivere del codice in grado di funzionare con impostazioni internazionali del server diverse.

L'occasione mi ha permesso di leggere SQL Server: Determining Whether a Date is a Business Day di Baya Pavliashvili su Informit.com; si tratta di un articolo molto interessante su come le impostazioni internazionali impattino sulle funzioni relative alle date di SQL Server. Nell'articolo viene proposta un'implementazione di una funzione fn_isbusinessday che ritengo poco elegante (i GOTO proprio no!).

Ryan Farley nel suo post Determining if a Date is a Weekday in T-SQL ne ha dato un'interpretazione, a mio avviso, migliore.

Di seguito il codice:

create function fn_IsWeekDay
(
    @date datetime
)
returns bit
as
begin
    declare @dtfirst int
    declare @dtweek int
    declare @iswkday bit
    set @dtfirst = @@datefirst - 1
    set @dtweek = datepart(weekday, @date) - 1
    if (@dtfirst + @dtweek) % 7 not in (5, 6)
        set @iswkday = 1 --business day
    else
        set @iswkday = 0 --weekend

    return @iswkday
end
if dbo.fn_IsWeekDay(@date) = 1
begin
    --do some magic here ;-)
end
--or 
select a.SomeFieldsForCalculation from table a
where dbo.fn_IsWeekDay(a.SomeDateField) = 1