Storie dalla Sala Macchine

Mamma mia, che paura! Appena letto l'inizio ho pensato subito a $spediamodatiacaso e a UL+SL, nonche' agli studenti-unni che avevano fatto la stessa cosa da me.

Solo che poi io ho spedito tutti a quel paese e ho rifatto completamente il tutto in maniera funzionante. Senza .NET. E senza usare piu' di qualche KB di memoria... -- Luca Bertoncello

"che io avrei scritto in perl in dieci minuti probabilmente, loro ci hanno messo due mesi e mezzo e .NET."

Non ti si addicono queste considerazioni da sempliciotto. E' evidente che il problema è la persona che scrive il codice, e non lo strumento che stava usando (come lasci invece tu intendere)

-- Anonymous coward

 

"che io avrei scritto in perl in dieci minuti probabilmente, loro ci hanno messo due mesi e mezzo e .NET."

Non ti si addicono queste considerazioni da sempliciotto. E' evidente che il problema è la persona che scrive il codice, e non lo strumento che stava usando (come lasci invece tu intendere)

Mi saprai spiegare come mai quelle persone lì che scrivono quel codice in quel modo, usano quasi sempre .net e quasi mai perl?

-- ringo

Se han sviluppato tutto in ambiente Microsoft o con tecnologie Microsoft è

naturale che i tempi siano n volte superiori a soluzioni *nix...



Ma una curiosità 20Gb di dati testuali!? Quanti poll per unità di tempo, per

quanto tempo sono conservati, quanto son grossi i dati e quanti cavolo di

sensori sono? Vogliono la face recognition di tutti i volti che passano il

tutto in base64?



Vabbé se qualcuno paga almeno da il suo contributo all'economia........

-- Kim Allamandola

Se han sviluppato tutto in ambiente Microsoft o con tecnologie Microsoft è
naturale che i tempi siano n volte superiori a soluzioni *nix...

Ma una curiosità 20Gb di dati testuali!?

20 Gb di database (almeno, erano 20... adesso sono molti di piu') Cosa ci sia in quel database non lo so e non lo voglio sapere.

-- Davide Bianchi

Ovviamente tra il dire ed il fare c'e' di mezzo "e il".

Nonostante sia ormai abusata, questa mi fa sempre cappottare dalle risate . E di lunedì mattina, ci vuole!

Ciao

C.

--
cecchino

«tra il dire ed il fare c'e' di mezzo "e il".» (cit.)

 

Cmq il problema dei 2 mesi e mezzo non dipende da .NET, ma dai rimbamba...Per un servizio di quella difficolta' l'unico linguaggio che richiede piu' di 10 minuti e' il Klingon.

-- Anonimo cordarto

A me sembra che abbiano un problema di ascolto in polling... Ho avuto un problema simile qualche settimana fa con un thread di una mia applicazione che faceva richieste continue sulla porta e il processore mi schizzava al 90% e più.. Ahò, era la mia prima volta con TCP/IP di windows Però mi ero messo a cercare l'errore e dopo un paio d'ore l'avevo trovato, perlomeno...

-- Programmatroto

...mi sembra davvero strano che esista ancora un mercato del software custom...

-- http://limacat.blogspot.com

> dobbiamo parlare di suicidio?

In effetti, se fossi un servizio/applicazione scritto in quella maniera, penserei seriamente anche io al suicidio...

-- Anonymous coward

"Ovviamente tra il dire ed il fare c'e' di mezzo "e il"



e aggiungerei: "Una rondella non fa primavera" .... (by Elio e le storie tese).



Lorenzo

-- Anonymous coward

Ciao Davide,



ma in che ambiente operativo è stato installato tutto l'ambaradam?



E quanta RAM ha il server?

Te lo chiedo perchè un mio cliente sosteneva che per un server, che gestisce 100 utenti con tutti i servizi del caso, erano sufficienti 4GB di RAM. Io ne consigliavo 16 come minimo..



Pensavo di andare a lavorare nei campi, credo avrei meno pensieri..

Ciao

Lorenzo

-- Anonymous coward

ma in che ambiente operativo è stato installato tutto l'ambaradam?
E quanta RAM ha il server?

quello che hanno richiesto e quanta ne hanno richiesta/sono disposti a pagare. Se loro chiedono un server con Windows X e Ram Y, noi forniamo un server cosi' fatto. Se poi scoprono che per far funzionare l'applicazione c'e' bisogno di Windows X+10 e Ram 20 * Y non dovrebbero essere problemi miei...

-- Davide Bianchi

Certo, non e` colpa loro se nel tuo server non ci sono 8 bazillotera di ram.

 

Ma quando una storia inizia con .NET, so gia` che va a finire male per forza.

-- Il massimo danno con il minimo sforzo

Qua ci sono almeno due vittime: la programmazione e .net... Se il servizio o quel che è deve fare solo quel che hai descritto in mezza giornata lo scrivi, lo testi e lo installi, senza bisogno di 8 tonnellate di dll!

E.... a che caspita serve un server ftp per un web service?

Se riesci a darmi una risposta logica mi dedico all'agricoltura...

-- --
Carlo

Qua ci sono almeno due vittime: la programmazione e .net... Se il servizio o quel che è deve fare solo quel che hai descritto in mezza giornata lo scrivi, lo testi e lo installi, senza bisogno di 8 tonnellate di dll!

E.... a che caspita serve un server ftp per un web service?

Se riesci a darmi una risposta logica mi dedico all'agricoltura...

 

Carlo

Uhm... io la butto lì...

Hanno implementato il... coso... con un sottoprodotto di un'architettura pipe&filter (che qui chiameremo $pippe_e_filtrini), in cui ogni .dll è un filtro, ed è implementato come plug-in. Questi plugin saranno pensati per essere aggiunti, rimossi e modificati a runtime (in realtà non funziona, ma ci hanno provato). Il modo più facile per fare questo è semplicemente ricaricare da zero tutta la catena di dll a ogni richiesta (e qui ci aiuta Windows, che, almeno, non carica la dll una volta per ogni thread che la richiede).

Ovviamente, ogni .dll sarà completamente indipendente, e avrà le sue dipendenze (altre .dll) necessarie per funzionare.

Tutto questo viene caricato ex novo a ogni richiesta. Probabilmente Windows vorrebbe anche tenerle in cache, ma non ci riesce, perché tutta la ram è occupata da altra spazzatura.

Questo potrebbe spiegare le dll...

Per quanto riguarda il ftp, magari hanno associato ad ogni dll un account ftp sul server, e le varie dll comunicano tra loro passandosi dei file tramite ftp. Così si causa anche un comodo surplus di scritture sul disco.

--
BluNotte

Ti e' mai venuto il dubbio che per come lavorate voi non possiate fare altro che attirare idioti di questo rango? Voglio dire le mie webapp consumano le risorse che gli servono e non bruciano ram a caso e non si inchiodano ogni 10 minuti, questo sta a dire che quando devo mettere su una web application o pago un hosting/shell su webfaction o un dedicato se il cliente mira ad avere 120.000 contatti al giorno o 300gb di roba, pago una giornata al sistesta di fiducia che installa il sistema operativo, configura i servizi etc (si potrei farlo io, ma mi sembra giusto che ogniuno faccia il suo di mestiere), assieme configuriamo apache, python e io mi configuro la mia webapp e da li saluti e baci (gli aggiornamenti me li faccio da me).

Ora che voglio dire, che non ho bisogno di un servizio come il tuo di hosting, assistenza, guidato_per_manina e cazzi e mi viene il dubbio che chi ne ha bisogno...

-- Riccardo Cagnasso

"il servizio in questo caso non e' stato la causa del problema, in questo caso il servizio e' stato solo una vittima della mancanza di memoria".

 

Della serie: "piuttosto di ammettere che e' colpa mia, mi taglio i coglioni e poi li taglio a tutti coloro che proveranno ad addossarmi colpe  che, si: sono mie, ma trovero' il modo di riversarle su altri."

-- Anonymous coward

E' sempre bello leggere le storielle del Lunedi. Sembra di vivere in un mondo di utenti ed utonti in un rapporto di 1 a infinito.

 

Quello che non capisco è come mai le aziende sono piene di utonti e rimangono cmq a galla... farò approfonditi studi in tal senso e poi scoprirò che è il nero che tiene a galla tutti. Me lo ha appena detto la mia palla di cristallo.

-- Anonimo lettore

Quello che non capisco è come mai le aziende sono piene di utonti e rimangono cmq a galla... 

Me lo chiedevo anche io e poi ho capito: poiche' sono TUTTE piene di cialtroni, esse sono TUTTE catorci allo stesso modo. In una mercato dove tutti sono allo stesso livello, (altissimo o bassissimo non importa) ecco che e' facile sopravvivere in quanto i tuoi avversari sono al tuo stesso livello, pr cui per i tuoi clienti non avrebbe senso cambiare.

 

Corollario "della mediocrita' diffusa".

Sul mercato non importa essere meglio degli avversari, l'importante e' non essere peggio.

Corollario "del miglioramento inutile"

Se per avere un cliente in piu' del tuo avversario devi sbatterti il doppio del tuo avversario, lasciagli pure il cliente.

 

-- Anonymous coward

"il servizio in questo caso non e' stato la causa del problema, in questo caso il servizio e' stato solo una vittima della mancanza di memoria".

Come dire: "è morto per mancanza di fiato" 

Comunque un'apllicazione come quella anche con .NET si scrive in mezz'ora, ma sai come si dice dalle mie parti: "fare e sfare è sempre lavorare"

-- Andrea Ballarati

Mah, nella mia azienda, pur essendo un po' scalcagnati nelle IT operations, abbiamo una regola aurea, non derogabile "non si fanno rilasci al venerdì".

Per il resto, non vedo che altra risposta potevi aspettarti da $massadirimbamba se non "throw more hardware to your software".

 

Nella mia azienda, qualche settimana fa si è impianto un DB a causa di un tablespace pieno. Risultato, un'applicativo $chemuovesoldisuinternet è rimasto fermo per 12 ore con più di 500 clienti bloccati ed incazz**** (per non parlare dei nostri manager).

Dopo aver chiesto lumi a $softwarehousechemalauguratementesiimprovvisaanchesysadmin, che da SLA deve mantenere quell'applicativo effettuando anche un controllo mensile dei tablespace., mi sento rispondere che all'ultimo controllo, 5 giorni prima, guarda caso era tutto ok (unica informazione presente nel loro rapporto mensile).

Gli faccio allora notare che era un po' strano che dopo 5 giorni un tablespace (non settato per autogrow) "miracolosamente" si riempisse. Mi rispondono allora che non tenevano di mese in mese la percentuale di saturazione del tablespace e che la avrebbero inclusa dal mese successivo "per trasparenza" (mepensa: che mene frega della trasparenza, siete pagati per mantenere il sistema up and running e se un tablespace si riempie avete già fallito).

Finita la pazienza, vado ad armarmi di LART e passo in audit tutti i controlli che avevano effettuato (nella mia azienda abbiamo un tool che "fotografa" ogni singola schermata di una sessione remota). Guarda caso, il tabelspace era già al 100% alla data del loro ultimo controllo, ma non avevano considerato la situazione critica perchè guardando la videata dell'enterprise manager avevano erroneamente interpretato l'informazione SEGMENT MANAGEMENT = AUTO come autogrow del database (da notare che il database era stato installato ed è amministrato da loro).

Taglio corto allla morale, visto che storie simili le avrete già vissute tutti: "non discutere mai con un idiota: la gente potrebbe non notare la differenza"

 

PS: Evitate pure qualsiasi discussione filosofica se i database è meglio gestirli con autogrow oppure meno, ciascun amministratore è libero di fare come crede a patto che riesca a svolgere in modo efficente ed efficace il compito che gli è affidato (ed aggiungo: evitando quindi a me, che faccio il project manager, di dovere entrare nei dettagli ed occuparmi dei $sarcassi per cui sei invece pagato tu).

 

-- Alberto

> Taglio corto allla morale, visto che storie simili le avrete già vissute tutti: "non discutere mai con un idiota: la gente potrebbe non notare la differenza"

No, la morale era "Non discutere mai con un idiota, prima ti abbassa al suo livello, poi ti batte con l'esperienza di anni".

-- Adriano

E il bello che puoi anche configurare Enterprise Manager per segnalarti quando è "quasi pieno" e "ormai è pieno tranne un pelino".... probabilmente per loro "threshold" significa "tre soldi"...

-- Anonymous coward

@ Alberto

Una domanda, come si chiama il software per "fotografare" le sessioni remote?

 

Grazie.

-- Anonymous coward

> Una domanda, come si chiama il software per "fotografare" le sessioni remote?

 

Noi utilizziamo questo prodotto: http://www.observeit-sys.com/

 

-- Alberto

> La ditta incaricata di scrivere tutto l'accrocchione (da ora in poi $massadirimbamba) fa' apparire $brancodipaguri come un mostro di efficienza e di intelligenza.

Ed ecco che anche il mito di $brancodipaguri crolla miseramente sotto i colpi della realtà.

-- ARM_

> Ovviamente tra il dire ed il fare c'e' di mezzo "e il".

Ehm, forse c'è "ed il"

-- Massy

>> Ovviamente tra il dire ed il fare c'e' di mezzo "e il".

> Ehm, forse c'è "ed il"

"ed" al posto di "e" si usa se la parola segente inizia per "e", l'uso davanti ad altre vocali è improprio. Es. "Il vecchio e il mare" o in Leopardi (Zibaldone) "[..] altro il doloroso altro anche il brutto e il vile"  mentre Manzoni giustamente scrive (Promessi sposi) "Addio, monti sorgenti dall'acque, ed elevati al cielo [..]"

-- Andrea Ballarati

E dato che un disegno vale più di 1000 parole:

http://marketingroi.robinsonmaites.com/wp-content/uploads/2010/06/cutting-off-branch.jpg

 

Buona settimana

-- Alberto

Secondo me l'hanno scritto in Brainfuck xD

-- Anonymous coward

> Eccerto, lui e' stato la "vittima" della mancanza di memoria, il fatto che sia lui che si ciuccia via tutta la memoria ne fa' anche il carnefice, dobbiamo parlare di suicidio? Sgrunt. 

Visto che frequenti gli ambienti del peak oil, dovresti essere familiare con la storiella del lievito

-- Flavio

> La ditta incaricata di scrivere tutto l'accrocchione (da ora in poi $massadirimbamba) fa' apparire $brancodipaguri come un mostro di efficienza e di intelligenza. 

Letta questa, ho avuto davvero paura...

Però c'è una domanda che mi assilla: cos'è (o almeno cosa è nella testa dei rimbamba) l'utenza "guru"???

-- Chronicles of a Broken Heart

Bella l'utenza guru... immagino sia quella usata per le "guru meditation" dato l'articolo.

-- Anonymous coward

> Bella l'utenza guru... immagino sia quella usata per le "guru meditation" dato l'articolo.

che, data la qualità enunciata del software, immagino sia il processo eseguito più frequentemente su quel PC

 

-- Alberto

C'è uno schema provato che viene utilizzato da questa gente: 

http://www.n2h.it/blog/wp-content/uploads/2007/02/soluzione.png

-- Keeper