La produttività nel mondo della programmazione

Quando si parla di tecnologia e informatica è difficile sentire parole come “produzione” o “produttività”. Ma se vogliamo parlare di business è importante capire che la produttività è alla base della sopravvivenza di un’azienda e fondamentale per un’ottima collaborazione con i propri clienti.

Cosa significa essere produttivi?

A meno di non far parte di una Onlus, la produttività è una di quelle cose di cui dobbiamo sempre tenere conto per riuscire a sopravvivere.
È brutto da dire ma è così, un’azienda deve fare profitto e per fare profitto bisogna essere produttivi.

Nel mondo della programmazione molti pensano che significhi scrivere del buon codice, leggibile e ben commentato oppure scrivere classi riutilizzabili o ancora riuscire a scrivere velocemente molte linee di codice.

Alcuni pensano di riuscire a raggiungere una buona produttività appellandosi all’opensource, utilizzando codice scritto da altri e sicuramente anche molto collaudato.
La verità è che sì, questi punti aiutano ma ci sono aspetti ancora più importanti.

Come diventare più produttivi

Non si può insegnare con un semplice corso o una guida online. Servono anni di esperienza e la possibilità di lavorare affiancati a persone capaci e in aziende strutturate.
Posso però elencare alcune interessanti nozioni che durante la vita lavorativa riescono a migliorare la produttività.

Scegliere le giuste tecnologie

Sembra banale ma non lo è, per niente. Spesso ci facciamo prendere dalla foga di voler provare nuove tecnologie. Negli ultimi tempi ad esempio ci sono state tante discussioni a riguardo di React o di Swift, tecnologie nuove e innovative.
Però quando si lavora su un prodotto di un cliente o un qualsiasi prodotto che non sia un esperimento dobbiamo farci tante domande sul come produrlo e su quali tecnologie usare.

Conosco bene i framework che decido di usare?
Sono in grado di smontare questo codice in ogni parte per modificarlo in base alle mie esigenze (o le esigenze del prodotto)?
Sono in grado di risolvere qualsiasi problema possa presentarsi durante la vita del prodotto?

Se nelle risposte c’è un solo NO allora forse quella tecnologia non fa al nostro caso.
Perché stiamo lavorando ad un prodotto di un nostro cliente o un nostro prodotto che sarà utilizzato da persone paganti. Ogni nostra scelta si riverserà contro di essi e noi, come produttori, abbiamo il dovere di far funzionare le cose.

Anticipare l’evoluzione del prodotto

Prima di iniziare a mettere le mani sulla tastiera bisogna avere le idee molto chiare. Come diceva un mio ex-collega “la fretta è una cattiva consigliera”. Ed aveva pienamente ragione.
Se il nostro prodotto deve avere la funzionalità X è necessario conoscere benissimo il contesto e tutto lo scenario che si presenterà, ma non basta. Per essere produttivi è necessario riuscire a prevedere ed anticipare come questa funzionalità potrebbe evolversi nel futuro. In questo modo il nostro codice sarà più flessibile e nel momento in cui dovremo fare delle modifiche riusciremo a legarle correttamente e in tempi ragionevoli.

Ho parlato di tempi perché i nostri clienti pagano il nostro tempo. E possiamo tranquillamente dire che il tempo è denaro.
Più produttivi saremo e più profitto riusciremo a costruire e la nostra azienda sopravviverà.

Avere sempre un Piano B

Il problema nasce sempre quando dobbiamo realizzare qualcosa di molto complesso, qualcosa di borderline, cioè che si avvicina molto al limite delle nostre capacità conosciute.

Il programmatore di esperienza, nel momento in cui accade questa situazione, riesce ad analizzare almeno due soluzioni al problema. Una delle due con il 99% di riuscita.
Perché questo? Semplice, non ci possiamo permettere di sbagliare né di perdere del tempo, preziosissimo, a risolvere dei problemi non conosciuti.

Sembra strano? No, se state lavorando ad un prodotto di un cliente o ad un qualsiasi progetto con delle scadenze.

Riuscire a stimare correttamente i tempi di sviluppo

Questa è una delle cose più difficili. In aiuto ci sono tantissimi tool di tracking del tempo che se ben utilizzati possono darci informazioni molto dettagliate.
L’esperienza ha il suo peso. Il mio consiglio è di partire sempre da un buona analisi, cercare di sviscerare ogni singolo dettaglio di ciò che dobbiamo fare così da capire il reale tempo che necessiterà.

Conclusioni

Come avrete notato l’ultimo punto è legato a stretto giro con tutti gli altri, perché una corretta stima del tempo si potrà fare solo quando avremo maestria dei punti precedenti, ecco perché solo con l’esperienza si riuscirà ad essere realmente produttivi.

Riuscire a capire quanto tempo occorre per realizzare qualcosa è alla base di chi vuol costruire un business, che sia un freelance, una piccola società o una grande azienda.

Nel nostro settore tutto è legato al tempo, i costi di produzione sono quasi nulli (se paragonati alla maggior parte degli altri settori) e l’unica variabile è il tempo. Solo che questo non si può aumentare, accumulare, né acquistare. Per questo è fondamentale gestirlo al meglio ed essere molto produttivi.

 

Localizzare la tua app in modo semplice

Localizzare l’app richiede tempo ed è una di quelle scelte che vanno fatte in fase di analisi.

Apple ci da tutti gli strumenti per farlo correttamente. Ho voluto però creare un metodo ancora più semplice per richiamare le stringhe localizzate ed ho messo il codice su GitHub.

Si tratta di una semplice funzione che fa da wrapper a NSLocalizedString.

Prima di questa extension dovevamo scrivere:

NSLocalizableString("chiave da localizzare", comment: "commento")

Lo trovo decisamente lungo da scrivere. Quindi con questa estensione ora possiamo scrivere:

"string.to.localize".localized
//  or
"string.to.localize".localized()

Se vogliamo usare una tabella:

"string.to.localize".localized("TableName")

Se vogliamo aggiungere un commento:

"string.to.localize".localized(comment: "This is the comment")

Se vogliamo passare degli argomenti:

"string.to.localize %@".localized(arguments: [12]) // Print: "string.to.localize 12"

Se vogliamo definire un valore di default:

"string.to.localize %@".localized(value: "No localization found")

Cosa ve ne pare?
Potete scaricare l’extension da GitHub: https://github.com/dimix/Localizable

Swift – Usare i constraint creati da Storyboard via codice

Se anche voi, come me, fate uso intenso di Interface Builder, Xib e Storyboard vi sarete accorti che su xCode manca un metodo per poter riferirsi ad un constraint specifico a meno di non utilizzare @IBOutlet per ogni singolo elemento.

La cosa che più mi disturba è il non poter avere dei riferimenti a quelle proprietà molto utili come la dimensione o la posizione di una View. Mi spiego.
Prima di Autolayout potevamo semplicemente scrivere una cosa del genere (ipotetica):

view.height = 100
view.width = 200

Adesso invece se dobbiamo modificare la dimensione di una View dobbiamo prima creare i constraint, poi connetterli con @IBOutlet e infine possiamo modificarli. Proprio per il concetto di Autolayout è giusto che sia così ma tutti questi passaggi li ritengo troppo lunghi e quindi ho cercato una soluzione più comoda.

Ogni NSLayoutContraint ha un Identifier, quindi è possibile cercare e trovare il contraint assegnando un semplice identificativo da Interface Builder.

UIView ha un proprietà: .constraint che include tutti quelli assegnati, quindi possiamo ciclare e cercarne uno specifico.
Però non basta, perché specifici constraint non stanno all’interno della View al quale sono assegnati ma alla View genitore.

Prendiamo come esempio una UIView chiamata “container”. Se agganciamo un constraint Top, quest’ultimo sarà inserito nella superview.

Quindi è necessario ricercare i constraint in modo più intelligente, andando a interrogare sia le view che le subviews.

Ho creato una extension di UIView che ci permette di fare tutto questo in modo semplice, ma non solo, ho creato un sistema predefinito di chiavi da utilizzare nel nostro progetto: top, bottom, leading, trailing, height, width, xAlign, yAlign. Ed è possibile accedere direttamente a tutti questi constraint tramite delle semplici proprietà.

Il progetto è su GitHub e si chiama StroryboardConstraint. Sono benvenute tutte le critiche e i suggerimenti.

Utilizzarlo è molto semplice, basta includere la extension nel progetto, assegnare gli identificativi tramite Interface Builder e poi accedere alle proprietà:

customView.heightConstraint?.constant = 200
customView.topConstraint?.constant = 20

Si può anche accedere ad un constraint con un identificativo specifico:

view.constraint(withIdentifier: "customWidth", searchInSubviews: true)?.constant = 50

[EDIT]

Ho appena aggiornato la libreria. Adesso non c’è più bisogno di configurare alcun identifier. L’estensione è in grado di riconoscere automaticamente il constraint richiesto.

Inoltre ho aggiunto un nuovo metodo per avere tutti i constraint di un certo tipo ordinati per priorità:

view.constraints(withAttribute: .height)

Spero apprezziate e non esitate a inviarmi i vostri commenti!

Nuove risorse per gli sviluppatori iOS

Apple ha rilasciato nella giornata di oggi nuove risorse molto utili per tutti gli sviluppatori iOS, in particolare per i designer e i grafici.

Si possono trovare nella sezione Resources della guida all’interfaccia grafica di iOS.

Apple ha reso disponibile per il download gratuito un file in formato PSD (Photoshop) e Sketch dove al suo interno si possono trovare tutti gli elementi dell’interfaccia grafica di iOS, da iPhone a iPad. Questa risorsa è davvero molto utile perché permette di poter creare il design di una UI/UX a partire proprio dall’esperienza che Apple ha creato.

Molto utili anche tutti i simboli e le icone di sistema, finalmente ufficiali e in formato vettoriale.

C’è da notare che Apple ha anche rilasciato la stessa interfaccia grafica in una veste “dark”, con sfondo nero e colore primario arancione.
Questa in realtà non è una colorazione di sistema, anche se presente nella UI dell’applicazione Watch.
Infatti gli sviluppatori non possono “attivare” alcuna versione “dark”, per questo è interessante vedere queste risorse perché si potrebbe assumere che Apple possa attivare questa nuova modalità come comportamento di sistema ed aprire pure le API agli sviluppatori.

Insomma, ottime notizie per tutti noi sviluppatori!

 

ImageSlideShow Swift su CocoaPods

Ieri ho pubblicato il mio primo Pod. Si tratta di ImageSlideShow per iOS scritto completamente in Swift che potete trovare sia in versione 2.3 (non-pod) che in versione 3.0.

Come installarlo

Dovete installare CocoaPods tramite linea di comando:

$ gem install cocoapods

È richiesto CocoaPods 1.0.1+, Swift 3 e Xcode 8.

Adesso create il Podfile

Per integrare ImageSlideShow dovete specificare nel Podfile:

source "https://github.com/CocoaPods/Specs.git"

platform :ios, '9.0'

target 'TargetName' do
	use_frameworks!
	pod 'ImageSlideShowSwift'
end

Quindi potete avviare il comando:

$ pod install

Come usarlo

1. Importa il modulo ImageSlideShowSwift

2. Instanzia il controller

ImageSlideShowViewController.presentFrom(self){ [weak self] controller in

	controller.dismissOnPanGesture = true
	controller.slides = self?.images
	controller.enableZoom = true
	controller.controllerDidDismiss = {
		print("Controller Dismissed")
	}

}

Ogni oggetto immagine deve rispondere al protocollo [ImageSlideShowProtocol].
Puoi guardare il progetto Demo per avere un riferimento più chiaro.

Per maggiori informazioni potete sempre andare sul sito GitHub.

Sentitevi liberi di dare feedback e consigli!