IWriteAboutIT

my mind blowing bits and bobs..

9 verità che le persone non sanno sui Programmatori

ArgumentChauntelle

I programmatori sanno molto di più di computer e di codice rispetto ad una persona media, ed onestamente alcuni di loro sono spaventosi.

 #Fatto 1

“Sotto il cofano, il software critico che utilizzi ogni giorno (come Mac OS X, o Facebook) contiene un numero terrificante di hack e scorciatoie che si adattano a malapena a lavorare insieme. Sarebbe come smontare un nuovo 747 e scoprire che il condotto del carburante è mantenuto in posizione da un appendiabiti e il carrello di atterraggio è attaccato con del nastro adesivo. “- Ben Cherry

Questa è la cosa divertente del codice, il sito o il programma può funzionare a meraviglia, può funzionare senza problemi, e può essere assolutamente bello sul lato front-end (quello che l’utente vede). Ma, dietro a tutto ciò che lo fa funzionare, avrà tanti errori, e workaround che a malapena funzionano e che non dovrebbero funzionare, ma che per qualche strana ragione funzionano.

#Fatto 2

 “Che circa il 25% delle ore passate a scrivere un’applicazione sono spesi cercando di capire dei modi in cui l’utente finale potrebbe fare qualcosa di sbagliato.” – Brian Humes

 Ora, quel 25% potrebbe essere inferiore, potrebbe essere di più, dipende dalla sviluppatore e cosa si sta facendo. Ogni volta che costruiamo qualcosa, dobbiamo sederci e pensare a come l’utente finale finirà per farlo scoppiare. Cosa clikkeranno, ciò che scriveranno, le domande che faranno, il linguaggio utilizzato, e come ciò che scriviamo potrebbe essere interpretato in modo diverso. Se abbiamo scritto il codice come vorremmo utilizzare il progetto, beh, allora ci sarebbero così tanti problemi perché noi sappiamo come funziona il programma, ma l’utente finale non lo sa.

 #Fatto 3

“Un programmatore non è un tecnico che ripara i PC.” – Ritesh Kumar Gupta

 Un programmatore è colui che si occupa di algoritmi e principi di progettazione, non colui che ripara un computer. Possiamo sapere come funziona al suo interno un computer, come il codice funziona insieme (o meglio incastrato insieme come ho spiegato nel Fatto # 1). Ma, questo non significa che noi sappiamo come risolvere il vostro problema hardware. Questo non significa che noi sappiamo come risolvere il problema che state avendo con Chrome e cosa lo fa andare in crash ogni volta che lo si apre, o perché il computer è sempre surriscaldando e consuma la batteria. I programmatori sanno giusto programmare i computer, non ripararli.

#Fatto 4

“La programmazione è riflettere, non digitare”. – Casey Patton

 La maggior parte della programmazione avviene dormendo, passeggiando in giro, guardando fuori dalla finestra, o facendo qualsiasi altra cosa che aiuta rilassarsi e pensare. Rilassarsi è una chiave importante per la programmazione, non si tratta di sedersi e scrivere un migliaio o più linee di codice, e rilasciare un programma o un’applicazione. Abbiamo bisogno di sederci, passeggiare, e riflettere. Dobbiamo riflettere a come arrivare a quel concetto, risolvere i suoi problemi, trovare un modo per farlo funzionare, cercare di farlo funzionare. Rilassarsi è l’unico modo con cui possiamo risolvere i problemi nel miglior modo possibile.

#Fatto 5

Il contare inizia da zero, non da uno.

 Questo concetto è importante nella vita di tutti i programmatori. Il conteggio inizia da 0, il vostro “1” è il mio “0”, il vostro “10” è il mio “9”. Il motivo di tutto questo è che la programmazione è efficienza, ed anche piccoli miglioramenti in efficienza possono fare grandi differenze in scala.

La numerazione sull’origine zero o indice zero = 0 [1] [2] è un modo di numerazione in cui all’elemento iniziale di una sequenza viene assegnato l’indice 0, piuttosto che l’indice 1 come è tipico nelle circostanze di tutti i giorni.

#Fatto 6

 “La programmazione è meglio effettuarla “nella zona “- un (piacevole) stato d’animo in cui la vostra concentrazione è assoluta sul compito che state effettuando e tutto li sembra facile. Questo è probabilmente molto simile al concetto di “zona” che hanno i musicisti e gli atleti.” – Morgan Johansson

 Vi siete mai chiesti perché i programmatori sono conosciuti come degli animali notturni? Perché rimangano sveglii tutta la notte? Perché ci permette di entrare “nella zona”, ci permette di concentrarsi su di una cosa e non bisogna preoccuparsi di essere disturbato da qualcuno – perché sono tutti addormentati. Si tratta di un lungo tratto della giornata dove nessuno ti sta chiamando o nessuno tenta di parlare con noi. E ‘un grande momento per programmare, e poter riflettere.

 #Fatto 7

 Dormire con un problema, può effettivamente risolverlo.

 Se avete un problema e vi è stato detto di dormirci su, lasciatelo perdere, e mettete la vostra mente a riposo. Per i programmatori è il modo di risolvere un problema, non solo perché ci si allontana da esso, ma perché per qualche motivo ci aiuta a capire il problema con il nostro codice. Molte volte ho incontrato un problema, trascorso ore e ore di lavoro su di esso, solo per cercare di risolvere quello che dovrebbe essere un problema semplice, con una banale correzione. Ma, riposarsi per 20 minuti, un’ora, sei ore, dodici ore, ci si sveglia e subito si conosce la risposta al problema.

 #Fatto 8

Un genitore può uccidere i suoi figli, se il compito a loro assegnato non è più necessario

 Non qualcosa che vorresti sentir dire da qualcuno, giusto? (se dovesse succedere considererei di verificare la salute mentale del soggetto, o segnalarlo alla più vicina stazione di polizia).

Per i programmatori non è una cosa così cruenta come si potrebbe pensare, visto che i programmi sono scritti come una gerarchia. Con il genitore che ha in carico la gestione dei processi figli sottostanti.

Quando un genitore non ha più bisogno di un suo figlio, lo uccidono, Significa che quando un programma non ha più bisogno di fare qualcosa (per esempio inviare una e-mail), uccide le connessioni al server di posta, per cui in realtà sta uccidendo un suo figlio perché non è più necessario.

 Ed infine, #Fatto 9

 Così come voi di solito non siete colpiti quando ci vantiamo di quanto sappiamo di informatica, noi non siamo impressionati da quando vi vantiate di quanto poco voi sapete di computer.

 Seriamente. Basta smettere, per favore è fastidioso. Non ci interessa. Non importa quanto siete orgogliosi di non voler imparare cose nuove. Ora, è comprensibile se state dicendo “Non conosco bene i computer” o “Non sono realmente interessato alla programmazione”, ma vantarsi di quanto non si conoscono i computer è fastidioso. Basta!

Tradotto | macleodsawyer.com

Testing is..

5_testing

Testing is …an infinite process of comparing the invisible to the ambiguous
in order to avoid the unthinkable happening to the anonymous

Nova System: Sketches and Ideas for a New Nova!

tc_novasystem_ltd

It was a cold January of 2008 when TC Electronic, the celebrated Danish audio equipment manufacturer, announced to public, their new floor-based guitar effects processor, the new Nova System. Derived from the G-System it’s all about providing a compact bullet-proof solution without missing  the sound quality of your pedal board. It was of course a huge success. 

After 6 years I still think the Nova System stands out in the Multi-FX market for it’s known qualities, but today, i decided to spend some time and give a tip to TC Electronic to create not a better Nova but surely something the current market trends would deliver in 2014. Something more flexible for the developer and evolutionary for the player.

1

Let’s get to the point TC! Rethink the Nova System, and build a Platform. Same solid hardware with a good effects processor, enought space to store patches, and support to USB, Switch Pedal, Exp. Pedal and of course Midi I/O. The important feature here is connectivity, it should provide Bluetooth or WIFI possibilities to connect to portable devices.

Guitar Players connect throught their devices to their favorite store: Google Play (Android devices), the Apple Store (IOS devices), Windows Store for Microsoft Phone devices and download TC Electronics free app. What I’m suggesting here is that the Customer throught in App purchases improves and extends their Nova Platform with new effects and possibilities, and creating loyalty between customer and the company.

The idea  here is relatively simple, you develop once a 10 years lifecycle platform and then you concentrate on something easy to mantain and evolve. I’m talking about the app software!

I’m not suggesting you to build a mobile app patch Editor, but probably something similar to a Patch market. This could seem something foregone, but nobody needs a Patch editor if you can design a patch quickly on the platform. I’m sorry but the Nova System is quite awkward on that, just think about going through the infinite Az09/special characters just to write the name, it’s an untested design flaw, it’s a user torture, do you guys use it?

What you need here is something simple where the Player can change it’s parameters during play!

To change the Type of Delay during play.. just keep the delay button pressed, rotate the first knob to select (tape, dual, ping pong, analog, clean..) and then press ok to save to bank.

Just Keep it Simple ..and no one needs an editor!

So, you build a platform which supports Modules, so if the user wants an AutoWha, he buys the module on the TC App. What about a Lopper? with G-Switch support? that’s an extra. Keep the platform cheap and charge for the extras.

After various sketches and attempts i really believe this is the right direction: TC Electronic, Good Luck 😉

Developers Life – thecodinglove.com

Ci chiamano Sviluppatori, Programmatori, Developer, Web Designer o banalmente lavoratori al videoterminale. Serve una buona dose di passione per giustificare ore e ore al computer, queste GIF Animate vi faranno senz’altro sorridere.

When I show the boss that I have finally fixed this bug

When the project manager enters the office

When I’m deploying code to production

When I try to fix a bug at 3 in the morning

When my regex returned exactly what I expected

When a friend of mine asks me to fix his website built with Joomla

When I’m told that the module on which I have worked all the week will never be used

When the code that I have not tested on dev works perfectly in production

When the sales people announce they have sold our product to the customer

When I apply a new CSS for the first time

When sysadmin finally gives us the root access

When I launch my script for the first time after several hours of development

When I go off for the weekend while everyone else is still trying to fix bugs

When the app goes into beta and the first bug reports arrive

When the boss is looking for someone to urgently fix a difficult bug

When a thing that worked on Friday no longer works on Monday

When I return to development of my code that wasn’t commented

When a bug goes unnoticed during a presentation

When a newbie suggests to add a new feature to project

When the boss announces a bonus if the project is completed before the deadline

When I realize that I have been blocked for two hours because of a forgotten semicolon

When asked to lend a hand on a Friday afternoon

When the project manager suddenly looks on my screen

When the client tries to click on the mockups

When customer wants to change specification 2 days before pushing to production

When my script finally worked

When I am asked to continue work of a newbie colleague

When I’m told that my code is broken in production

When I find a solution without searching Google

When the intern tells me that “the tests are for those who can not program”

When I manage to replace 200 lines of the algorithm by only 10 lines

mi raccomando aggiungete su Facebook, thecodinglove.com 😉

older Posts »