Objective-C vivrà ancora per molto. Nonostante Swift sia il nuovo punto di riferimento per lo sviluppo iOS e OS X, ci sono ragioni concrete per scegliere di continuare a sviluppare in Objective-C, almeno per un po':
- progetti esistenti basati su Objective-C richiedono ancora mantenimento e probabile aggiunta di nuove funzionalità, e anche se è tecnicamente possibile mescolare i linguaggi, la cosa può risultare poco conveniente per via della natura molto dinamica di Objective-C;
- Swift sta cambiando rapidamente, presenta ancora alcuni bug e problemi di performance, e il suo workflow manca ancora di alcune feature fondamentali per i professionisti, mentre Objective-C è un linguaggio maturo, con una community molto vivace;
- alcuni possono preferire un linguaggio più dinamico, e il supporto di Apple su Objective-C è ancora forte;
Personalmente ho la tendenza a preferire linguaggi più statici, e un approccio type-first alla programmazione, ma di tanto in tanto mi piace lavorare in un ambiente più dinamico, quindi, sia per preferenza personale che per esigenze di business, non ho ancora messo Objective-C da parte. Ma dopo poche settimane di Swift, mi è mancata subito una delle sue funzionalità più potenti: gli Optionals.
In locale funzionava
Questo articolo si rivolge a chi ha già una conoscenza base di docker e del suo funzionamento e sta cercando come avanzare al passo successivo, usandolo quotidianamente in sviluppo e in produzione.
Avere un ambiente di sviluppo/test il più simile possibile a quello di produzione aiuta molto nel garantire un corretto funzionamento dopo il deploy.
In uno scenario tipico, lo sviluppatore ha installati sulla propria macchina locale tutti i servizi da cui dipende la sua applicazione, il che comporta quanto segue:
It works on my machine
This post is addressed to people who already have basic knowledge about docker, about how it works and are looking for a way to move to the next step with the goal of using it in development and production day by day.
Having a development/testing environment as close as possible to the production one helps a lot in assuring that things will behave correctly when delivered.
Questo articolo è la sintesi di un talk presentato al SymfonyDay 2015; potete trovare le slide qui.
I test e la loro durata
Sviluppare applicazioni scrivendo test e facendo Test Driven Development è un’ottima pratica, e dà parecchie soddisfazioni. Con l’andare del tempo, si fa crescere la suite di test del proprio progetto, cercando di aumentarne la copertura e l’efficacia e si scrivono nuovi test corrispondenti alle nuove funzionalità che vengono man mano sviluppate.
Data protection is one of the major and recurrent problems in recent years: whether it is private information of users, or the company for which we work, the problem is always the same.
How to protect such data from any attackers who would - and could (!!) - be able to gain possession?
Before arriving at the solution of this problem, however, is right to split the series in at least two branches. In the wwww data can be “obtained” in two different moments: 1) as they pass over the network in packets, or 2) after their storing (eg. database or file) in one or more servers.
