lunedì 22 luglio 2013
Da molto tempo che mi faccio questa domanda. E non mi sono mai dato una risposta quanto minimo chiara.
Ho cercato di fare un giro largo larghissimo andando a leggere qua' e la', ma non ho trovato qualcosa di preciso in merito alla nostra mansione.
E' un tema scottante, specie poi in Italia, dove le offerte di lavoro pubblicate non hanno mai in chiaro il salario offerto. Ma da un po' di anni a questa parte, la domanda sulla tariffa e' diventata la prima che mi viene posta. Al secondo posto, forse trovano spazio le competenze. E questo la dice lunga su, come nel giro di circa dieci anni, le cose siano cambiate e tutti guardano al prezzo.
Beh visto, che io non so rispondere, perche' non chiedere alla community?
Perche' non metterci la faccia direttamente e fare un piccolo sondaggio?! Si si un sondaggio che abbia una qualche utilita' molto diversa dai soliti snippet di codice o altro.
Dopo tutto scrivere codice C# significa pane, vestiti, sopravvivenza. Che male c'e' a farsi un po' di conti?
Con uno spirito da dilettante ho creato questo piccolo sondaggio
Mi piace riportare questo dato di un sondaggio di
VisualStudio Magazine Aprile 2012
We polled software development professionals who subscribe to Visual Studio Magazine and related eNewsletters (.NET Insight and Redmond Developer News) in November 2011. More than 1,300 subscribers who currently work in the United States participated in the survey and filled out the online questionnaire. The median base salary was $92,000. On average, VSM Salary Survey respondents were college graduates with a four-year degree or higher level of education and more than a decade of industry experience.
Supposto che il Base Salary stia a significare il lordo, corrisponde ad un importo (cambio Dicembre 2011 EUR/USD pari 1,295) 71.042 euro.
Penso che il sondaggio lo abbiamo fatto escludendo i bonus(performance), eventuali stock option, il fondo pensione e l'assicurazione sanitaria.
La domanda che mi sorge spontanea e': quale sarebbe il fattore di conversione (non il tasso di cambio!) per ottenere l'equivalente italiano?
PS: I commenti e/o critiche costruite sono ben accette. Tenuto conto poi che questo post cerchero' di tenerlo il piu' aggiornato possibile
domenica 3 luglio 2011
e va bene mi metto a studiare..
venerdì 17 giugno 2011
Citando il
post di Emanuele:
Per fare un bel gruppo ci vogliono anni ma basta un minuto per distruggerlo...
>> Questo è il team di sviluppo. Nella realtà ognuno è una abstract Entity con metodi private (tutti!)
La qualità è quella che paghi...
>> Non facciamo un discorso di qualità. Qualcosa che funzioni, TDD, DDD fanno perdere tempo
Le gerarchie dovrebbero essere scalate dal basso...
>> Si si installiamo altri 8GB di RAM e l'ASP.Net vedrai come scala
Le persone più importanti nelle gerarchie sono quelle più in basso...
>> Non viviamo in un contesto meritocratico. O scrivi codice o comandi. Perchè devi
aprirti una software factory per conto tuo per comandare. Ma non scriverai codice..
Le bugie, le prese in giro e le sfumature non portano da nessuna parte. Se in un primo momento possono aiutare, prima o poi vengono scoperte...
>> Siamo qui per rubare i soldi a XX (XX = notissimo gruppo finanziario)
Non bisogna mai fermarsi alle apparenze...
>> Barba sempre fatta e camicia stirata. Sei fortunato che puoi venire senza cravatta
Non bisogna mai comprare a scatola chiusa...
>> Colloqui senza test tecnici. Innumerevoli
Non bisogna mai dimenticare che c'è sempre il lato umano...
>> Fatturare e portare i clienti a casa. Ma questi clienti non possono starsene a casa loro ???
La ragione non è mai di uno solo...
>> E
io cosa ci sto a fare?
Ci sono sempre varie sfumature...
>> La sfumatura è che questo lavoro-hobby mi diverte e non mi annoio mai. L'entropia ha anche un suo fascino
Più passa il tempo e le parole di
Codentropy sono sempre più vere: "Non sono stereotipi. Preferisco chiamarli Pattern. Human Pattern nella catena dello sviluppo software"
PS: Non ho mai fatto un post per lamentarmi. Spero di non disturbare troppo questa bacheca
lunedì 16 maggio 2011
ovvero come trasformare Aruba in qualcosa di meno odioso, evitandoci
copia-incolla, trasferimenti FTP.
La possibilità di poter pubblicare il proprio database
tramite
MS
SQL Database Publishing Wizard
(DPW)
mi è sembrato dall'inizio (circa 4 anni fa) qualcosa di
estremamente comodo. Solo che tutto quello che avevo era sempre il
solito file script sql che puntualmente devo generare, ricopiarlo nella
mia cartella Script (se faccio uso di versionamento), poi copia e
incolla sulla interfaccia web myLittleAdmin e poi finalmente eseguire
lo script.
Uffa.. una seccatura spaventosa, se fai piccole e frequenti modifiche
al tuo schema.
Purtroppo in un hosting condiviso a 30 euro all'anno non è
possibile avere molto e non è nemmeno possibile connettersi
tramite Management Studio (SSMS) o giusto per sognare tramite SQL
Compare della Redgate.
Armato di pazienza e un venerdì sera piovoso, ho trovato su
codeplex
SQL Server
Hosting Web Service (and toolkit)
tra questi i sorgenti di DataBase Pushing Services 1.1 (DPS) che
è la parte di codice lato server. DPS espone alcuni
webmethod che vengono chiamati dal client DPW per effettuare la
pubblicazione del DB direttamente.
Ho scaricato il progetto e pubblicato sul mio spazio web
immediatamente; purtroppo vengono generate diverse SoapException che
cercare di risolverle mi ha portato via diverso tempo. Che importa,
fuori infuriava la tempesta.
Ad ogni modo la cosa migliore da fare è quella di aprire i
sorgenti in
VS2010 con target fw2.0 e ricompilare tutto come WebApplication. Non so
ancora come, ma non sono comparsi gli
errori a runtime durante la pubblicazione del mio DB dal DPW.
Ho seguito i passi che ho trovato
Being
your own SQL Publishing Services Host
e nella guida fornita da godaddy
Publishing
a Database Using the Database Publishing Wizard
che a quanto pare fornisce quel servizio sui propri server a differenza
di Aruba.
1) Pubblichiamo sul nostro hostring condiviso e clicchiamo su "More.."
per creare un nuovo provider
2) Click su "New.." per crearne uno nuovo:
3) il bello viene qui: mettiamo in questo caso un nome fittizio,
l'indirizzo del nostro webservice nel mio caso
http://www.kamelasa.com/publish.asmx,
le credenziali ftp che ci passa Aruba
4) Click di nuovo "New.." per inserire i dati di
connessione al database Sql Server; per il nome del server possiamo
inserire l'ip passato da aruba o lanciare il comando select
@@SERVERNAME da mylittleAdmin
Dopo aver seguito i passi indicati qui,
l'unica cosa che ho dovuto modificare è stato quello di far
ignorare modulo http PublishModule commentando dal web.config :
<add
name="Microsoft.SqlServer.Hosting.Service"
type="Microsoft.SqlServer.Hosting.Service.PublishModule" /> per
non avere il problema (per ora) della basic authentication:
Volevo anche il logging e per questo ho passato il path fisico della
cartella
public
con i permessi in scrittura che su Aruba ha la forma
"d:\inetpub\webs\nomedominioxxx" (xxx è il nome del dominio
di primo livello)
Questo tool rimane molto rudimentale, infatti è adatto a
ricreare il database, funzionalità avanzate come il compare
non sono disponibili. Diciamo che è una GUI comoda per
selezionare agevolmente quali oggetti (tabelle, viste, stored
procedure) esportare in maniera veloce. Esiste anche il limite
maxRequestLength che dobbiamo settare nel web.config.
Posso dire che su Aruba forse è possibile far girare tutto
(almeno con SqlServer2005 e fw 3.5), considerato che in rete esistono
dei work-around per funzionare Asp.Net-mvc, Nhibernate e i
MembershipProvider
Comunque tutto questo mi ha dato lo spunto che forse
Open DBDiff
lo potrei modificare facendolo parlare tramite questo protocollo a ws
sviluppato da microsoft
venerdì 11 settembre 2009
Ecco la versione video dell'articolo pubblicato
qui . Ho inserito qualche vignetta di Scott Adams che sono riuscito a trovare in giro, modificandola. Dilbert che esce fuori dal suo cubicle e finisce su una ppt..
NB:
- non sono uno speaker professionista !!
- a causa di settaggi forse errati, stiamo cercando di capire il problema di alcune distorsioni
- volevo ringraziare Igor per l'incoraggiamento
Qui le slides:
Dependency Inversion Principle
mercoledì 9 settembre 2009
In questo primo articolo darò un'introduzione "infantile" al concetto di Inversion of Control(IoC) ed ad una sua implementazione tramite il pattern di Dependency Injection(DI). Sebbene IoC e DI siano considerati sinonimi, mi è sembrato di capire che DI sia una implementazione particolare di IoC, a mano o tramite framework. Comuque, qui non farò riferimento a framework particolari, ma solo al principio di base che dovrebbe condurci a scrivere codice a basso accoppiamento (low coupling).
Per una mia innata prigrizia, mi piace di più usare le immagini per fissare i concetti. Non sto qui ad elencare i motivi biologici.
Già, chi collegherebbe una lampada saldandola ai cavi elettrici nella parete ? A patto che abbia voglia di vincere il
premio Darwin di quest'anno. Il problema è che non sono sicuro del risultato finale ...
DIP in pratica ci spinge a utilizzare e dipendere da interfacce (o astrazioni). Quasi non c'è più niente da dire, vista la banalità della cosa. Pigro sì, ma pragmatico:
- Nessuna classe dovrebbe derivare da un tipo concreto
- Nessuna variabile dovrebbe avere un riferimento ad un tipo concreto
- Nessun metodo dovrebbe fare l'override di un metodo implementato in qualcuna delle sue classi base
Altre due imaginette ci aiutano a capire ancora meglio:
Nella prima una classe consumer ha delle dipendenze con le classi concrete, ovvero ha il comp ci creare uno dei tre tipi facendo ricorso all'operatore new
E' il caso appunto in ciui componenti ad alto livello dipendono da componenti a basso livello
Il verso della dipendenza imita molto quello della tipica programmazione procederale
public class Dependent
{
public IDependent _dependent;
public void DoSomething(string dependent)
{
if (dependent.EndsWith("1"))
_dependent = new DependentClass1();
if (dependent.EndsWith("2"))
_dependent = new DependentClass2();
if (dependent.EndsWith("3"))
_dependent = new DependentClass3();
_dependent.DoSomethingInDependent();
}
}
La seconda invece ci mostra gli effetti della cura dopo aver implementato DIP:
L'iniettore della dipendenza stesso dipende da una astrazione (classe
abstract o tipo
interface). Ovvero possiede un riferimento all'interfaccia tramite un campo privato
Così i tipi concreti che derivano dall'interfaccia, implementandola
Il verso della dipendenza si è
invertita, da questo il nome di Inversione di Controllo (mesi fà mi dicevo: inversione de che ??)
public class Injector
{
private IDependent _dependent;
public IDependent Dependent
{
get { return _dependent; }
set { _dependent = value; }
}
public void DoSomething()
{
Dependent.DoSomethingInDependent();
}
}
Persino il class diagram, uhh:
.jpg)
Martin Fowler in suo
famosissimo articolo ci insegna 3 tipi di DI:
- Iniezione tramite metodi d'interfaccia di Tipo 1
- Iniezione tramite proprietà di Tipo 2
- Iniezione tramite costruttore di Tipo 3
La prima è quella che obbliga a definire un'interfaccia (da non confondersi con l'
astrazione necessaria al DIP) , dalla quale poi l'iniettore dovrà derivare, constringendolo ad implementare i metodi
La seconda invece è la proprietà che si preoccupa di valorizzare il campo privato che rappresenta la dipendenza verso l'interfaccia
La terza invece è quella in cui, il riferimento viene risolto nel momento in cui l'iniettore viene creato, dovendolo passare come parametro.
Forse Martin si era sparato tutti i cofanetti di Spielberg prima di scrivere l'articolo, diciamo che non farei una distinzione così ferrea tra tipi, basta capire quando ci servono.
Delle tre, la prima non l'ho mai usata nè vista usare. Dopo tutto devo scrivere del codice in più. Preferisco la seconda e la terza modalità o un misto delle due, poichè mi risulta comodo per lo "state based unit-testing", cioè posso governare e controllare come viene risolta la dipendenza. Userei solo la seconda o al massimo la prima solo quando ho bisogno di posticipare l'iniezione.
Dimenticavo, appena posso mi comprerò questa simpatica magliettina che fa parte della
campagna anti-if promossa da xplabs.
E' proprio IoC, uno dei mezzi che ci aiutano in questa battaglia. Non per
if stesso ma per un suo abuso, chiaro.
NB: ho fatto anche un versione video, o
screencast, di questo articolo. Devo un attimo sistemare il "montaggio". Ho Sergio Leone in chat che mi sta dando dei validi consigli. Lo pubblico più tardi o al max domani mattina.