Ricerca collaboratore (con riflessione)

Il giorno 14 novembre 2013 15:02, Andrea P. [email protected] ha
scritto:

ben venga questo tipo di insofferenza :stuck_out_tongue:

E chiamala, se vuoi, passione, voglia di conoscere, imparare, ricerca,
orgoglio professionale …

‘Sta insofferenza l’ 'na roba negativa (le parole sono importanti …
cit.
Nanni Moretti :slight_smile:

S.

Il giorno 14 novembre 2013 16:14, maurizio de magnis <
[email protected]> ha scritto:

ho usato il termine insofferenza perch si avvicina di pi al concetto: “se
ti senti comodo usando uno strumento, significa che non lo stai usando
abbastanza” :slight_smile:

Specie se ne usi uno solo.
E sempre quello per tutto (il famoso martello :slight_smile:

La perenne ricerca del miglioramento pu essere vista come una
maledizione ( utopico pensare di raggiungere la perfezione, un asintoto)
ma anche come uno stimolo positivo: c’ sempre qualcosa da migliorare :slight_smile:

Pomeriggio filosofico :stuck_out_tongue:

S.

Ciao,
io sono un programmatore java…e sarei molto interessato a programmare
con
ruby…il fatto che non posso offrire lo stesso livello di
professionalit…sarei un programmatore junior…quindi nella pratica
finisco a lavorare sempre in ambito java…ma resto molto interessato a
quel
linguaggio…che considero uno dei migliori, forse il pi elegante…tra i
linguaggi esistenti!
Lucs

Il giorno 11 novembre 2013 17:43, Alessio C. [email protected] ha
scritto:

Come me,a con C#, il problema il tempo.


Riccardo

2013/11/14 Andrea P. [email protected]

insofferenza intesa, IMHO, come ricerca.

+1 :slight_smile:
ho usato il termine insofferenza perché si avvicina di più al concetto:
“se
ti senti comodo usando uno strumento, significa che non lo stai usando
abbastanza” :slight_smile:
La perenne ricerca del miglioramento può essere vista come una
maledizione (è utopico pensare di raggiungere la perfezione, è un
asintoto)
ma anche come uno stimolo positivo: c’è sempre qualcosa da migliorare
:slight_smile:

@Luca e @Riccardo,

per carit, il tempo tiranno, e bisognerebbe inventare le giornate da
48h, si sa :slight_smile:

per non questo il punto. come faceva notare Maurizio, se sei abbastanza
flessibile con la mente, ed hai un discreto background, lo switch del
linguaggio un problema relativo.

chiaro che, salvo casi eccezionali, non bastano solo una manciata di
ore. tuttavia vi chiedo:

  • sul serio non riuscite ad allocare 2-4h ore settimanali per dedicarvi
    al cazzeggio su ruby?

  • avete un minimo di background su un determinato settore (es: sviluppo
    web, cio il 90% delle applicazioni ruby)?

se conoscete bene lambito di un problema (web development?) e sapete
come risolverlo in un altro linguaggio (Java, C#, ), farlo nel
linguaggio X solo questione di sintassi.

ovvio, col tempo, lo studio e la pratica raffinerete la tecnica e
cercherete di applicare la X way, che sia Ruby, Go, Python, Node o
quello che preferite, tutti ne hanno una, tranne PHP >:-]

se proprio vi sta a cuore, almeno provatece! :slight_smile:

A.

Il giorno 14/nov/2013, alle ore 16:42, Luca R.
[email protected] ha scritto:

Ciao,
io sono un programmatore java…e sarei molto interessato a programmare con
ruby…il fatto che non posso offrire lo stesso livello di
professionalit…sarei un programmatore junior…quindi nella pratica
finisco a lavorare sempre in ambito java…ma resto molto interessato a quel
linguaggio…che considero uno dei migliori, forse il pi elegante…tra i
linguaggi esistenti!
Lucs

Hai ragione Andrea, ma una cosa sono le prove, lo studio…un’altra la
concreta possibilit di iniziare una collaborazione che abbia come
requisito la conoscenza di Ruby…e una collaborazione che sia
conveniente
per entrambe le parti…per parlarci chiaro…io dovrei accontetarmi
almeno
dei 2/3 dello stipendio…e la controparte valutare un tempo n di
(auto)formazione che ovviamente…come ha scritto qualcuno in questo
thread…dipende dalle abilit del singolo…ci vorrebbe complessivamente
pi coraggio…ma da entrambe le parti! Con molta difficolt uno rinuncia a
uno netto che con fatica si conquistato.
Se qualcuno mi dicesse ti diamo gli stessi soldi e per un anno programmi
soltanto in Ruby…prendo l’occasione al volo!

Il giorno 14 novembre 2013 17:03, Andrea P. [email protected] ha
scritto:

Io ho imparato il Go in una settimana e ho appena finito il mio primo
progetto pagato.
Il consiglio, se possibile, di trovare un lavoretto tipo side project
con scadenze non troppo pressanti.

Ovviamente, never quit your day job!


Luca P.
[email protected]

ma ancora parliamo di imparare un linguaggio?
se uno ha la forma mentis da programmatore pu scrivere anche in
vatteloapesca.

il problema sono i frameworks/full-stack-fk, non i linguaggi, quindi
realmente dipende dal contesto dove deve essere inserito.

Prendi un programmatore java ad esempio e mettilo a fare qualcosa che
non
ha mai fatto. che ne so con JSP e Servlet tanto per dirne una… se non
li
ha mai visti avra il blocco dello scrittore comunque.

Tra parentesi, uno sviluppatore ruby on rails o python/django che gli
fai
fare servlet e jsp se le mangia a colazione, perch sono pi simili a
quello che ha sempre fatto.

ciao

Infatti io consiglio il Go come secondo linguaggio a tutti,
compattissimo, estremamente self-contained e praticamente non servono
librerie.
Ovviamente il Java forse il peggiore da quel punto di vista, il Ruby si
colloca a met, ovviamente dipende se ti arrangi o lavori con qualcuno.


Luca P.
[email protected]

ma ancora parliamo di imparare un linguaggio?
se uno ha la forma mentis da programmatore pu scrivere anche in
vatteloapesca.

Io uso groovy da due mesi, sono pagato per programmare in groovy e prima
di sto progetto sinceramente non sapevo neanche che esistesse

I miei feedback su groovy:

  • lento
  • compila in java quindi e lento
  • non dovrei dirlo ma groovy e lento e anche un poco ricorsivo

D.

2013/11/14 Luca P. [email protected]

Infatti io consiglio il Go come secondo linguaggio a tutti,
compattissimo, estremamente self-contained e praticamente non servono
librerie.

Ciao,
per curiosit, che tipo di lavori ci fai/fate con Go?

2013/11/14 Davide R. [email protected]

I miei feedback su groovy:

  • lento
  • compila in java quindi e lento
  • non dovrei dirlo ma groovy e lento e anche un poco ricorsivo

[cit]
Non ci posso credere, uguale, uguale, uguale!
[/cit]

Aggiungerei bruttino a piacere…

2013/11/14 Luca P. [email protected]

In generale, stiamo esplorando soluzioni alternative al Ruby per le

applicazioni di telefonia dove Adhearsion (http://adhearsion.com) non ce
la fa come performance.

Ah Adhearsion, dov’ che l’ho visto… ah si, come success case sulla
pagina di Celluloid :smiley:

p.s:
curioso che sul sito citano JRuby come alternativa a MRI e non come
interprete consigliato… non dovrebbe fare una bella differenza come
performance usando Celluloid?

Verissimo, infatti nei deployment pi intensivi usiamo JRuby.
La documentazione potrebbe essere leggermente out of date, grazie per
averlo segnalato.

Tanto per dirvi un numero, in alcune specifiche applicazioni la
differenza tra MRI e JRuby 25x :slight_smile:


Luca P.
[email protected]

Questo un crawler massivamente parallelo per il recupero di link di
varia natura, ma in realt veramente solo un progetto-hobby che
incidentalmente mi pagano.

In generale, stiamo esplorando soluzioni alternative al Ruby per le
applicazioni di telefonia dove Adhearsion (http://adhearsion.com) non ce
la fa come performance.

Come team, ci siamo scelti un linguaggio a testa da valutare, e a me il
Go piace molto come filosofia.


Luca P.
[email protected]

Ciao Andrea, concordo, il problema non il linguaggio, almeno per come
la
vedo io che mi sento l’animo del surfista :slight_smile:

E’ da un po’ che provo a ritagliare il tempo e pi o meno si riesce,
comprato libri, andato in giro e frequentato la comunit Ruby, il
problema
poi riuscire a mettere in piedi un sistema che ti permetta di mantenere
la famiglia… al momento riesco con il lavoro che faccio, facendo il
passaggio su altro significa lasciare il lavoro attuale e riuscire a
portare a casa la pagnotta diventa un’incognita… il problema
principale
quello, trovare il coraggio e buttare il cuore oltre l’ostacolo.
Ultimamente mi stanno passando tante idee per provarci seriamente.

2013/11/14 Andrea P. [email protected]

ore. tuttavia vi chiedo:

ha scritto:

Lucs


Riccardo

L’esperienza quello che ottieni quando non ottieni quello che desideri.

On Nov 14, 2013 6:27 PM, “Luca P.” [email protected]
wrote:

Verissimo, infatti nei deployment pi intensivi usiamo JRuby.
La documentazione potrebbe essere leggermente out of date, grazie per
averlo segnalato.

Tanto per dirvi un numero, in alcune specifiche applicazioni la
differenza tra MRI e JRuby 25x :slight_smile:

Scusate se mi inserisco con un domanda un po’ OT, avete mai valutato
rubinius come alternativa a MRI? Riguardo JRuby che tipo di stack usate
per
il deploy delle vostre apps?

Grazie
Andrea

OT ma ormai ha un senso :slight_smile:

Rubinius ha al momento un serio problema di direzione del progetto
(Rubinius X? Rubys is dead?!?!), abbiamo anche interagito a suo tempo
con Evan P. ma alla fine lavorare con Nutter e gli altri stato pi
proficuo e alla fine siamo rimasti su JRuby.

Non mi sento di dire che non lo useremo mai, ma visto che i risultati
che otteniamo con JRuby sono sufficienti e ci danno la solidit della
JVM, non so se lo faremo nel futuro prossimo.

Le applicazioni girano con "-J-Xmn1024m -J-Xms4096m -J-Xmx4096m
-J-server, su Java Sun 7 64 bit, senza invokeDynamic perch con le
allocazioni e il threading spinto di Celluloid tende a generare
eccezioni random di dead actors.
Non essendo app web lo stack composto solo da Adhearsion e FreeSWITCH
1.2.x o Asterisk 11.x, in un caso con Kamailio a fare da SBC.
In tutti i nostri deploy leventuale web app a corredo gira sotto Unicorn
con Nginx davanti, almeno che io sappia, ma su CRuby.

Tutto il testing stato sviluppato (da me, due cocomeri) basandolo su
SIPp, monitorando le macchine con vmstat e jvmtop.
I parametri JVM scartati sono stati i vari di tuning GC e invokeDynamic.
In entrambi i casi salivano le prestazioni ma il sistema tendeva
allinstabilit dopo alcune ore di utilizzo.

Per lungo tempo siamo stati bloccati su JRuby per un bug di Nokogiri,
per il resto non abbiamo dovuto fare nulla se non riscrivere un parser
specifico interno da C a Java.

Concludo la sbrodolata dicendo che al momento per le parti performance
critical ci stiamo rivolgendo, piuttosto che ad implementazioni
alternative, ad altri linguaggi come Elixir e Go, anche se non so dire
se alla fine otterremo risultati migliori.


Luca P.
[email protected]

Propongo di spostare la discussione in un thread a parte, che ho un paio
di domande da farti :slight_smile:


Luca P.
[email protected]