Sviluppando siti, o applicazioni web spesso ci si trova a leggere il codice sorgente generato dal server. Chi utilizza Firefox come browser di default si trova spesso ad eseguire questa operazione facendo Command+U. Se è necessario analizzarlo a fondo, copia e incolla sul proprio code editor preferito, il mio è BBedit. Velocizzare questa operazione è molto semplice, Firefox nei suoi settings avanzati permette questo ed altro. Per accedervi è necessario:

1. digitare nella barra degli indirizzi

   about:config

2. Nel campo Filter, scrivere source.editor
3. Fare doppio click su view_source.editor.external e cambiare il valore in True
4. Fare doppio click su view_source.editor.path e inserire l’indirizzo completo del vostro editor preferito; nel mio caso usando BBEdit con installati anche i Command line tools:
   /usr/local/bin/bbedit
   Alttrimenti il classico:

   /Applicazioni/BBedit.app/Contents/MacOS/BBedit

5. Se usate un altro editor basta aprire il pacchetto dell’applicativo per trovare il nome del file binario da indicare
6. Cliccare OK e la configurazione è terminata.

D’ora in avanti ogni qualvolta si eseguirà il comand+U l’applicazione inserita mostrerà il codice della pagina. Per tornare alla configurazione originale, è sufficiente tornare al punto 3 e rimettere il valore in false.

Articoli correlati:

1. Firefox 3: il profilo colore
2. Firefox 2.0: come personalizzare i segnalibri/preferiti
3. Firefox: spellchecker

Prima dell’arrivo di Apache2 per creare i virtualhost era sufficiente seguire questo tutorial. Con Mac OS X 10.5 o superiore, o semplicemente utilizzando Apache2 sul proprio computer, la configurazione dei virtualhost va fatta editando non solo httpd.conf.
La procedura passo per passo che nella prima parte è identica all’articolo citato in precedenza, per eseguirla al meglio dotarsi un ottimo editor di codice, BBedit o TextWrangler reperibili qui

1. Aprire il documento:
   

   /private/etc/hosts

2. Appare il documento
3. Il pezzo dopo:
   

   fe80::1%lo0 localhost

   l’ho aggiunto io.

4. Portare il cursore dopo la linea sopra citata e andare a capo;
   il cancelletto
   

   #

   indica commento, quindi dopo di quello sulla stessa riga, si può inserire un commento di richiamo alla modifica

5. Inserire l’indirizzo IP almeno uno spazio e il nome del virtualhost da creare:
   

   127.0.0.1 nomeVirtualhost

6. Salvare il documento è richiesto l’inserimento della password di amministratore essendo un documento di root.
7. Aprire ora il file /private/etc/apache2/httpd.conf
8. Cercare la seguente linea di codice intorno alla 460
   

   # Virtual hosts
   #Include /private/etc/apache2/extra/httpd-vhosts.conf

9. Scommentare ovvero rimuovere il cancelletto della seconda riga prima della scritta include:
   

   Include /private/etc/apache2/extra/httpd-vhosts.conf

10. Salvare e chiudere httpd.conf
11. Aprire ora il file /private/etc/apache2/extra/httpd-vhosts.conf
12. 
    rimuovere il cancelletto qualora ci fosse prima di

    NameVirtualHost *:80

13. Per ogni virtualhost da creare è necessario inserire il seguente codice:
    

    <VirtualHost *:80>
    ServerAdmin email
    DocumentRoot /Users/userName/Sites
    ServerName nomeVirtualHost
    ServerAlias www.nomeVirtualHost
    ErrorLog /private/var/log/apache2/nomeVirtualHost-error_log
    CustomLog /private/var/log/apache2/nomeVirtualHost-access_log common
    </VirtualHost>

    dove al posto del campo email, si può inserire la propria;
    al posto di /Users/userName/Sites il percorso corretto della cartella dove risiede il sito
    nomeVirtualHost va sostituito con il nome inserito nel file hosts

14. salvare il file
15. Riavviare apache2, utilizzando preferenze di sistema o il terminale
16. Digitare in un browser http://nomeVirtualHost per verificare che tutto funzioni perfettamente

Articoli correlati:

1. Leopard – proteggere una cartella con htaccess
2. Virtualhost sul proprio Mac OSX
3. Leopard: abilitare php5

Le ultime versione di Mac Os X montano di default il webserver Apache2. A differenza del suo predecessore la configurazione per proteggere le cartelle con htaccess non avviene più nelle stesso file, httpd.conf, ma su files diversi.
La procedura è sempre abbastanza semplice e veloce, seguite passo per passo i punti che seguono:

1. Se non si dispone di un buon programma per editare codice, scaricarne uno
2. Aprire l’applicazione Terminale
3. eseguire l’autenticazione da amministratore scrivendo il comando
   

   su

4. Scrivere la password di amministrazione del computer
5. Scrivere ora il seguente comando
   

   htpasswd -c /private/etc/httpd/passwords vostrouser -c /private/etc/apache2/passwords vostroUser

6. al posto di vostroUser ovviamente scrivere il vostro
7. ora apparirà:
   

   New password

   scrivere la password scelta per quella cartella.

8. Attenzione a non dimenticarla, usare una password diversa dal login aumenta la sicurezza del computer.
9. Il comando appena eseguito ha creato nella cartella
   /private/etc/apache2/
   il file password nel quale c’è scritto

   vostroUser:password criptata

10. Con il vostro editor di codice preferito aprire ora il file:

    /private/etc/apache2/users/vostroUser.conf
    

11. In fondo al documento, aggiungere una linea di questo genere per ricordare che è stato editato da voi:

    #### Prrotezione cartella sites aggiunta vostroUser#### 

12. sotto mettere questo codice facendo le opportune modifiche
    

    <Directory /Users/vostroUser/Sites>
    Authtype Basic
    AuthName “Ciao, questa e’ un’area riservata!”
    AuthUserFile /private/etc/apache2/passwords
    Require user vostroUser
    </Directory>

13. Io ho il sistema in lingua originale quindi la cartella si chiama Sites.
    Salvare e chiudere
14. Riavviare apache2, o dal terminale con il comando
    

    sudo apachectl restart

    oppure dal pannello di condivisione in preferenze di sistema

15. Da un browser inserire la URL locale protetta…
16. Per accedere ora vanno inserite la username appena inserita e la sua relativa password
17. Per chiudere la sessione del terminale digitare
    

    exit

Articoli correlati:

1. Leopard – Virtualhost (Apache2)
2. Protezione di Sites
3. Ripristino di Apache, php e MySQL da PPC a PPC

Oggi apre agli utenti Google Wave, l’ultima e attesissima (almeno nella Rete) idea di Google. Oltre 100.000 utenti hanno lasciato la loro gmail nel form di prenotazione presente nella homepage in questi mesi e domani finalmente si scoprirà che cos’è e come funziona. O almeno lo scoprirò io, che ho lasciato la mail come tutti e nonostante sia interessatissimo, confesso di non aver capito bene cosa attendermi.

http://wave.google.com/

E così ho cercato qualche info in più che voglio condividere qui.

Innanzitutto cos’è Google wave? Dal sito ufficiale leggo che “Google Wave is an online tool for real-time communication and collaboration. A wave can be both a conversation
and a document where people can discuss and work together using richly formatted text, photos, videos, maps, and more.”

È quindi un tool online per comunicare e collaborare (lavorare aggiungo io) in tempo reale e in tutti i modi. Sembrerebbe ottimo davvero, che dire? Di fatto un tool del genere valido non esiste.

E lo fa tramite delle onde (wave). Geniacci della rete e del marketing: ma in che senso un’onda?

A wave is equal parts conversation and document. People can communicate and work together with richly formatted text, photos, videos, maps, and more.

È, in linguaggio un pò anni 90, un sistema multimediale di comunicare: immagino debba essere davvero immediato e semplice per avere successo. Sfida enorme.

A wave is shared. Any participant can reply anywhere in the message, edit the content and add participants at any point in the process. Then playback lets anyone rewind the wave to see who said what and when.

Questa è molto più difficile! L’onda è condivisa e “liquda”, scomponibile a piacimento da ognuno e cmq leggibile da tutti. Qualcosa che sembrerebbe andare ben oltre la programmazione e sfiorare la filosofia del linguaggio, la sociologia…

A wave is live. With live transmission as you type, participants on a wave can have faster conversations, see edits and interact with extensions in real-time.

L’onda è vero realtime. Questa è facile. Quel che è difficile è capire come faranno con potenziali milioni di utenti che in tempo reale scambiano info e dati in modo personalizzato e libero.

Sul come faranno la faccenda si fa ancora più interessante:
alla base c’è l’ Operational Transformation, un concetto di programmazione ( di matematica? Di fisica? Non l’ ho capito molto bene, confesso! :D ) per il quale i bit, le informazioni, possono essere manipolate, scomposte e ricostruite e questo ne facilita in modo enorme la trasmissione.
Capito? No?
Bene.

Allora leggetevi questa intervista di InfoQ al Core Engineer del progetto Dhanji Prasanna: è una delle cose più interessanti che abbia letto ultimamente. Molto approfondita!

With the consumer release of Google Wave scheduled for the 30th of September, InfoQ had a Q&A with Core Engineer Dhanji Prasanna about some of its less known internals, details about how it’s being developed by the Google engineers and the best practices involved.

InfoQ: With Operational Transformation (OT) being a corner stone of Google Wave, would you like to tell us a little bit about the technologies that implement it?

Dhanji: OT as a concept has been around for some time, mostly in academic form. We have a complete clean-room implementation of OT, customized to the particular needs of Google Wave. It has enabled our editor to be a truly real-time, character-for-character, concurrent editing system. By decomposing edits to a document into streams of mutation operations, we are able to maintain the semantic consistency and integrity of a single line or paragraph while it is being edited simultaneously by several participants. This is at the heart of the real-time collaboration story.

OT in Wave draws in large part from the aforementioned academic papers, and the Jupiter system. One advantage to us using the Google Web Toolkit is that the same OT Java code that runs on the server also runs on the client. This is a particularly important saving for us. You can read more about this technology athttp://waveprotocol.org and play with the actual source code athttp://code.google.com/p/wave-protocol

InfoQ: It seems that you have used GWT and Gears for building the web client? Would you like to tell us why you choose this set of technologies and what were the challenges you had to overcome. Also how are you planning to cope with older browsers?

Dhanji: The Google Web Toolkit has been a great success story for Google Wave. We are able to leverage Java testing, debugging and code development tools, which are very useful and familiar, and delivering this to a browser in a compact, performant and scalable form has been a real eye-opener for us. GWT is able to pluralise a common codebase among a variety of browser and OS permutations, including with minimal effort, mobile browsers. It also optimizes away a lot of code, so we are able to use idiomatic Java but still have it run fast and delivered compactly to the client. We currently use Gears only for one feature, and that is to enable drag-and-drop into the browser (from the desktop). This is a feature we are trying to get added to HTML5 so even browsers that are not Gears-enabled will be able to take advantage of drag-and-drop.

We currently support modern browsers (browsers with similar capabilities as Chrome) and will, in the future support any HTML5 compliant browser fully.

InfoQ: With the growing variety of browser+OS combinations, how do you manage testing, integration and frequent releases for the web client?

Dhanji: We are fortunate that we can draw on a lot of experience in this area that other projects and engineers at Google have. In addition to having a terrific team that focus on testing technology, we use a wonderful open source web-testing library called Webdriver that allows us to mimic user interaction in quite sophisticated ways with the Wave client. Webdriver makes it easy to parallelize such tests among various browsers with simple pluggable options. It has also evolved quite a lot to support our unique Ajax-heavy testing requirements. Apart from this we have an aggressive release schedule that lets us propagate bug fixes and feature updates quickly. But perhaps the most significant safeguard is that we use Wave internally ourselves for nearly everything; eating our own dogfood, so to speak. This really helps us keep on top of high priority bugs and much-needed features as we feel their pain first.

InfoQ: Would you like to give us an overview of the kind of software that someone would find on the typical workstation of A Google Wave Engineer?

Dhanji: Each engineer has their own specific preferences for tools, but apart from the regular version-control, management and build tools that are common between all Google engineers, you will find anything from Eclipse, IntelliJ Idea to vim and emacs as code editors of choice. Command-line unix tools and custom shell and python scripts to manage various repetitive actions are also quite popular: grep being the favorite, perhaps. =)

InfoQ: Would you like to give us a short technical outline of what happens to a message (blip) from the moment a user types it in the web client, until becomes available to every one else that is participating in that wave – humans or robots? What systems need to be bootstrapped, what technologies are utilized and what is the flow of information?

Dhanji: Sure, a message written in the client is transformed into a series of operations that are sent to the server in real time. After authenticating and finding the appropriate user session, the ops are routed to the hosted conversation. Here these ops are transformed and applied against other incoming op streams from other users. The hosted conversation then broadcasts the valid set of changes back to other users, and to any listening robots. This includes special robots like the ones that handle spell checking, and one that handles livesearch (seen in the centre search-panel), as well as explicit robotic participants that people have developed. Robotic participants write their changes in response to a user’s and these are similarly converted into ops, applied and re-broadcast.

The Web client interprets these as appropriate; in the case of spelly, it highlights the misspelled word for correction, for example.

Like other Google applications, the various systems run on a cluster and scale horizontally (Web search for a planet: the google cluster architecture – Micro, IEEE).

InfoQ: How about the licensing of the software that was built for Google Wave? What parts are open source now, what parts are you going to open source in the future and what do you think might be the overall licensing strategy that Google will follow?

Dhanji: We currently provide (as open source) most of the core data model for document transformation and manipulation. This is the same code that runs on our internal systems. We also provide a reference implementation of a server and client that use similar approaches to our internal systems. We intend to open source a lot more of our code base, however it is a big job as we must disentangle the code from proprietary infrastructure, provide appropriate build tools, and ensure that it is properly documented and supported before releasing.

We use the Apache Software License (ASL 2.0). I cannot comment on licensing for products other than Google Wave, as I am not familiar with them.

InfoQ: How appropriate do you think current “best practices”, frameworks and technologies are for building a platform like Google Wave? Do you think that the choices you make in high-end projects like that are a glimpse of what will become mainstream in the future?

Dhanji: There have been many challenges we’ve faced in building Google Wave. We’ve had to learn a lot about the nature of scaling a real-time, character-by-character application that supports both human and robotic participants natively. There is also a large challenge to maintaining a code base with 50+ engineers, to onboarding them and keeping the health of the build constant at the same time.

The core libraries and tools used at Google have proven invaluable, in this effort; some of these are available as open source and we highly encourage their use: Google Web Toolkit (which reduces our client footprint by an order of magnitude), Google Guice (particularly the Servlet extension), Guava Libraries,Webdriver and several others. Many of these are bleeding edge technologies that are continuing to evolve at a fast pace. We’ve been particularly lucky to have the authors of these toolkits work closely with us and accommodate often oblique requirements. Anyone attempting a large project like Wave will find these open source libraries extremely useful.

Per vederlo in azione e chiarirsi le idee manca poco e spero che un pò del mio stupore per questa novità sia arrivato a chi legge.Di recensioni ne leggeremo molte, ma di anticipazioni non ce ne sono state tantissime ;)

Articoli correlati:

1. Google – Yahoo!: 0-1, Google ritira il servizio Google Answers
2. Google Desktop per mac
3. Google Chrome for Mac

Se vi interessa spostare la vostra raccolta di RSS direttamente in Mail di Leopard, ecco un modo molto veloce:

1. Esportare direttamente in un file OPML dal vostro lettore di RSS feed, in uqesto caso (Google Reader)
2. Lanciare dal terminale il seguente comando:
   

   perl -lne 'print $1 if /"(http.*?)"/' google-reader-subscriptions.xml | pbcopy

3. Aprire Mail
4. Andare su Aggiungi RSS Feed
5. Sciegliere Specify a custom feed URL radio button
6. Cliccare nel box e incollare gli indirizzi dei FEED
7. Cliccare Aggiungi

Segnalo anche che spesso il Drag&Drop funziona con altri lettori di news (NetNewsWire) :mrgreen:

Articoli correlati:

1. Mail: creare regole
2. Mail: riconfigurarlo dopo una formattazione
3. E-mail e contatti da Windows a OS X

Riporto volentieri il nuovo prodotto di Giangaetano Vituzzi (THEARTOFWEB.NET) theartofweb@hotmail.comNaiospy è un software “spia” per Mac OS X scritto in perl che permette di vedere e monitorare il proprio desktop via web. Naiospy gira in background ed è una utility unix (darwin) che può essere lanciata usando il terminale o utilizzando cron all’avvio. È possibile vedere cosa sta accadendo al proprio Mac quando non ci si è davanti. Inoltre Naiospy è adatto a quei genitori che vogliono sapere cosa fanno i propri figli online, o preoccupati di proteggere i propri figli dai pericoli della rete. L’idea che sta dietro Naiospy è quella di una videocamera puntata direttamente sul vostro monitor che filma tutto quello che viene fatto sul vostro Mac. Naiospy lavora fotografando degli snapshot del vostro desktop e lo salva sul vostro host in rete. Pochi secondi dopo Naiospy esegue un’altra fotografia, fino ad un massimo di una foto ogni 20 secondi.

Naiospy lavora anche dietro router e proxies perché carica le foto sul vostro spazio utilizzando il metodo HTTP POST. Loggandosi on line al pannello di controllo della “spia” si riesce a capire cosa sta accadendo LIVE o a vedere l’ultima foto caricata. Per poter essere installato lo spazio web necessita di Perl, con la sua cartella cgi-bin, e unix ed apache. Per la sua installazione:

1. Scaricare naiospy.zip e scompattarlo direttamente sulla scrivania
2. Caricare la cartella “_naiospy” nella cartella “cgi-bin” in ascii nello spazio web
3. Settare i privilegi dei documenti .cgi a 755
4. lanciare da Terminale:./naiospyd --host http://www.tuoHost.web

Fatto! ** CRON: è possibile lanciare al boot il demone nayospyd scrivendo un crontab così:

• PATH=/bin:/sbin:/usr/bin:/usr/sbin
• @reboot $HOME/desktop/naiospy/naiospyd –host http://www.tuoHost.web >/dev/null 2>&1

** SERVER: Dal punto di vista server ecco cosa dovreste vedere:

• /cgi-bin/_naiospy/nph-resp.cgi (chmod 755 – ascii mode)
• /cgi-bin/_naiospy/cpanel/naiospy.cgi (chmod 755 – ascii mode)
• /cgi-bin/_naiospy/cpanel/passwd.cgi (chmod 755 – ascii mode)
• /cgi-bin/_naiospy/cpanel/viewer.cgi (chmod 755 – ascii mode)

Per accedere al pannello di controllo basta digitare:

• http://www.tuoHost.web/cgi-bin/_naiospy/cpanel/naiospy.cgi

** CLIENT: i flag di Naiospy:

• $HOME/desktop/naiospy/naiospyd --host http://www.tuoHost.web
• $HOME/desktop/naiospy/naiospyd --stop
• $HOME/desktop/naiospy/naiospyd --version

Il software lo potete scaricare direttamente da versiontracker, oppure usando direttamente il terminale con il comando:

• curl -s http://www.theartofweb.net/download/naiospy.zip >$HOME/desktop/naiospy.zip

Buon Divertimento

Articoli correlati:

1. Creazione di VirtualHost
2. Virtualhost sul proprio Mac OSX
3. Condividere la connessione di Windows Xp con OS X usando Parallels

Con l’aggiornamento a Leopard alcune funzionalità e utilities di mySql non funzionano più.
Per l’installazione completa del paccheto mySQL la procedura da seguire rimane sempre la stessa utilizzata con Tiger.
Però sarebbe comodo che all’avvio mySql partisse lo stesso senza dover ricorrere a comandi via terminale.
Niente di più facile insomma. Al momento sto utilizzando un widget che mi tiene monitorata l’attività di mysql, e altre due applicazioni che trovo estremamente comode:

Passiamo ora al modo più veloce per avere sempre avviato il server MySQL all’avvio.
A fine installazione di MySQL server, installate anche mySQl start-up item, in modo da rendere sempre funzionante all’avvio il server. Potete per il momento evitare di installare il prefPane, tanto non va.
Dunque finita tutta la procedura e avviato mySQL, se avete riavviato ovviamente va fatto da terminale:

sudo /usr/local/mysql/bin/safe_mysqld

Aprendo una nuova finestra del terminale inserite questo codice:

sudo mkdir /var/mysql/

Quindi si andrà a creare un collegamento (symbolic link) alla porta di default:

sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock

Finito tutto come prima ;-)

Articoli correlati:

1. Installare MySQL 5 su 10.4 (Tiger)
2. MacOSX 10.4.4 e mySql che non funziona
3. Ripristino di Apache, php e MySQL da PPC a PPC

Eh sì avete letto bene! Finalmente Leopard è dotato di php5 di sistema e non solo!
Ora anche Apache 2 fa parte di OS X, questo porta parecchi vantaggi e soprattutto aggiorna notevolmente il client di Apple.
Comunque tornando al tema dell’articolo ecco come si fa:

1. Aprire con un buon editor di testo /private/etc/apache2/httpd.conf
2. Scommentare la riga 114, ovvero togliere il # all’inizio delle riga
   LoadModule php5_module libexec/apache2/libphp5.so
3. Non resta che riavviare Apache, usando o Preferenze di Sistema o direttamente da terminale scrivendo: sudo apachectl restart
4. Ora potete tornare a programmare tranquillamente in php

Enjoy

Articoli correlati:

1. Attivare due Php su OS X
2. Leopard – Virtualhost (Apache2)
3. Leopard – proteggere una cartella con htaccess

e’ uscito, e si scarica da qui:

http://desktop.google.com/mac/index.html

gudizio sintetico:
ottimo strumento e bella interfaccia
ma perfettamente inutile per chi ha un sistema Mac con Spotlight.

nota:
Trovo poco accorto collegare un indice l’HD con il web.

voto: 7

qui il thread di discussione nel forum

Articoli correlati:

1. Mactutorials evolution!
2. Arriva Parallels Desktop 1.0 per Mac OSX
3. Arriva Google Wave!

Gli utilizzatori di Safari ed i Web Designers che non sono molto contenti della velocità del browser made in Apple, ora hanno un’ altro strumento per ottimizzare le sue prestazioni.

Grazie al plug-in SafariSpeed 2.0, si potrà eliminare il tempo di attesa di 1 secondo, tempo che è stato settato di default prima di far vedere la pagina che avete scelto di caricare (chiaramente dipende dalla connessione ad internet di cui disponete), disabilitare le “Favicons” (ovvero tutte quelle icone che il sistema carica nella barra degli indirizzi, inviate dai siti che state visitando), disabilitare la cache (ideale ai web designers per testare i siti) e il supporto alla visualizzazione dei pdf, e cambiare l’interfaccia Brushed Metal in quella Aqua.

SafariSpeed 2.0 è shareware e può essere usato fino ad 11 volte prima della necessaria registazione, il cui costo è di $ 8.

Articoli correlati:

1. Le nuove funzioni di Safari 3
2. Mac OSX 10.4: Dashboard è troppo lenta?
3. Safari upload di un file con Drag&Drop