Overloading del costruttore

1
2
3
4
5
6
7
8

public class OverloadResolver {
public OverloadResolver(Object param) {
System.out.println("Construttore con parametro Object");
}
public OverloadResolver(Object[] param) {
System.out.println("Costruttore con parametro Object[]");
}
}

Qualcuno sa cosa succede se faccio questa chiamata:

1
2
3
4
5

......
public static void main(String[] args) {
OverloadResolver or = new OverloadResolver(null);
}
......

Cioè se richiamo quel costruttore con parametro null, cosa viene richiamato nella classe di sopra ? Dai dai dai che lo sapete……e ditelo !!!!!! (magari qualcuno commenterà….chi lo sa!!!)

Ottimizzare le performance di un sito-web

75 milioni di richieste al giorno, ovvero quasi 900 richieste/secondo, credo sia una immensa soddisfazione per un programmatore web di alto livello, e cioè sviluppare un’applicazione web, fatta bene, che possa soddisfare quei numeri lì. E’ chiaro che un sito web pronto al decollo, non farà mai tutte quelle richieste al giorno, dovrà passare un pò di tempo, in cui dovrà essere pubblicizzato, finire al meglio sui motori di ricerca, e quant’altro. Ma è altrettanto chiaro che, se l’obiettivo, volente o nolente (vedi siti che sono diventati famosi dall’oggi al domani), è quello di cercare di sviluppare un’applicazione web che possa reggere ritmi del genere. Le cose più importanti da capire durante lo sviluppo , se si vogliono ottimizzare le prestazioni web, sono che bisogna gestire le differenti punte di traffico, discriminando tra le operazioni di lettura (READ) che sono molto economiche, e le operazioni si scrittura (WRITE) che sono molto costose, ovviamente in termini di performance. Per operazioni di READ, intendiamo l’accesso a parti statiche che sono state già memorizzate e sono disponibili all’uso immediato. Per operazioni di WRITE intendiamo le operazioni di aggiornamento di un record di un database, o l’inserimento di un record, più in generale consideriamo una qualunque operazioni che comporta un calcolo prima che l’output venga rediretto all’utente.

Lo schema in figura mostra 2 cluster di database (supponendo di utilizzare MYSQL), uno per gestire le richieste di READ, ovvero ogni richiesta dell’utente di visualizzare le pagine. Tutte le pagine sono servite da memCached. Le richieste di WRITE invece, vengono gestire dall’altro cluster, e attraverso la replicazione di MYSQL gli aggiornamenti vengono trasmessi dal cluster di WRITE a quello di READ. Seguono alcuni trick per ottimizzare le prestazioni:

• READ cluster, per velocizzare usa dei precompilati scritti in C, e non perl/php script.
• READ cluster, usa UltraDNS per il load balancing.
• WRITE cluster, minimizza il numero delle query ed il tempo di connessione per gestire le richieste.
• WRITE cluster, usa il più possibile i processi offline.
• Usa la replicazione per avere scalabilità e affidabilità del servizio.

I-Phone senza un paio di cosette

Come tutti sanno, venerdì 30 giugno sono iniziate le vendite dell’ I-Phone il super mega telefonino, anche se chiamarlo telefonino è restrittivo, che fa un milione di cose, tra cui telefonare, collegarsi alla rete internet e riprodurre contenuti multimediali. C’è gente che l’ha comprato e ovviamente testato, e subito son saltate fuori delle cose che mancano che sicuramente verranno messe a posto nella seconda release dell’I-Phone.

1. Manca la gestione degli MMS. Per un telefonino moderno è una grossa mancanza….inviare un MMS non vuol dire solo scambiare delle foto.
2. Non c’è la possibilità di scambiare iCal o vCard, i contatti della rubrica per intendersi, attraverso bluetooth o MMS o email.
3. Manca il supporto per iCal o VCard.
4. Il supporto di gestione delle email, non renderizza correttamente l’HTML. La prova è stata fatta con Google Calendar. All’arrivo di un invito, il software visualizza il soggetto e un attachment non utilizzabile. Integrare uncontenuto multipart/alternative all’interno di un multipart/mixed sembrerebbe chiedere troppo.
5. Il Bluetooth non supporta il dialup network, print service e OBEX exchange.
6. VPN L2TP supporta solo il metodo secret shared identification e non il Machine Certificate.
7. Dato l’enorme spazio a disposizione, si potrebbe pensare di usare l’IPhone come un contenitore temporaneo di file da usare all’occorrenza, ma non è possibile dal momento che non si possono traslocare i file come si fa con una normale USB pen.
8. Nessuna gestione del testo. Se bisogna rimuovere del testo, è necessario premere il tasto di eliminazione molte volte. Non c’è la possibilità di usare il taglia/copia/incolla per selezionare, ad esempio, ed elimare il blocco selezionato.
9. Manca IChat, Jabber, AIM, sono presenti i supporti per email e SMS. Non è possibile visualizzare i contenuti Flash ne quelli J2ME.
10. L’applicazione Mail non supporta un insieme di configurazioni, tra cui IMAPS, STARTTLS, scegliere SMTP/IMAP port.
11. La modalità panomarica è disponibile solo per alcune applicazioni. Sarebbe bello averla anche in Mail e SMS.
12. Non c’è la possibilità di configurare i numeri veloci. Ad esempio mappando un numero alla pressione di un determinato tasto, oppure collegarsi direttamente ad un determinato sito web cliccando su un tasto predefinito.
13. Manca il supporto FLASH.
14. Manca il supporto J2ME. Ad oggi con il supporto a J2ME si possono fare molte cose, scrivere programmi per il cellulare che inviano/ricevono SMS, inviano/ricevono EMAIL, si collegano alla rete, etc etc
15. Safari e AJAX non funzionano esattamente bene.

Detto ciò, non oso minimamente dire che l’IPhone non è un buon prodotto, ma al contrario per quanto mi riguarda rappresenta il futuro. E se anche ad ora, esistono telefonini di altri competitor che sono in pratica dei piccoli personal computer, l’IPhone ha quel qualcosa in più che ad ora nessuno possiede. Già solo l’interazione che si può avere usando il touchscreen multi-touch è sicuramente una bella esperienza. Come tutte le cose che nascono, sicuramente manca di qualcosa, in fondo siamo alla versione 1.0, e come ben sanno i programmatori, c’è molto da migliorare nelle versioni future.