Przeniosłem skrypt ftpmount do github’a:
Równocześnie zmieniłem sposób konfiguracji, a raczej tylko domyślną nazwę pliku konfiguracyjnego. Teraz jest szukany plik:
Wersje do pobrania.
Do pracy z hostingiem gdzie mamy tylko ”’ftp”’ przydaje się montowanie dysku poprzez właśnie ftp. Służy do tego program ”’curlftpfs”’ (np apt-get install curlftpfs).
Odpalamy go jako:
curlftpfs ftp://user:pass@host/ ./mountpoint
Do tego potrzebujemy uprawnienia grupy ”’fuse”’ więć jako ”root” musimy sobie ją dodać od naszego użytkownika.
Jeżeli mamy dużo połączeń do zarządzania przyda się mały skrypt:
* ftpmount
sterowany konfiguracją w pliku ”’config.ini”’:
[hostone.pl] host=ftp.hostone.pl user=userone pass=passone # jak nie podamy tego wpisu, program się zapyta o hasło mountpoint=hostone.pl [hosttwo.pl] host=ftp.hosttwo.pl user=usertwo mountpoint=hosttwo.pl
Wtedy wystarczy nam:
* ./ftpmount hostone.pl # montujemy połączenie
* ./ftpmount -u hostone.pl #odmontowywujemy połączenie
* ./ftpmount -l # lista dostępnych konfiguracji połączeń
home.pl obsługuje pythona jako cgi (pliki .py) więc tego będziemy się trzymać. Instalację wykonamy w katalogu /py
hardcoded ale działa 
wrzucamy to do /py i ruchamiamy poprzez www
cat install.py
#!/usr/bin/env python
import os
os.system("wget http://www.djangoproject.com/download/1.0.2/tarball/")
os.system("tar zxf Django-1.0.2-final.tar.gz")
os.system("rm Django-1.0.2-final.tar.gz")
os.system("mv Django-1.0.2-final tmp")
os.system("mv tmp/django django")
Lokalnie wołamy
django-admin.py startproject pytest
i wrzucamy katalog pytest przez ftp na home do katalogu /py .
cat dispatch.py
#!/usr/bin/env python
import os, sys
import django.core.handlers.wsgi
def run_with_cgi(application):
environ = dict(os.environ.items())
environ['wsgi.input'] = sys.stdin
environ['wsgi.errors'] = sys.stderr
environ['wsgi.version'] = (1,0)
environ['wsgi.multithread'] = False
environ['wsgi.multiprocess'] = True
environ['wsgi.run_once'] = True
if environ.get('HTTPS','off') in ('on','1'):
environ['wsgi.url_scheme'] = 'https'
else:
environ['wsgi.url_scheme'] = 'http'
headers_set = []
headers_sent = []
def write(data):
if not headers_set:
raise AssertionError("write() before start_response()")
elif not headers_sent:
# Before the first output, send the stored headers
status, response_headers = headers_sent[:] = headers_set
sys.stdout.write('Status: %s\\r\\n' % status)
for header in response_headers:
sys.stdout.write('%s: %s\\r\\n' % header)
sys.stdout.write('\\r\\n')
sys.stdout.write(data)
sys.stdout.flush()
def start_response(status,response_headers,exc_info=None):
if exc_info:
try:
if headers_sent:
# Re-raise original exception if headers sent
raise exc_info[0], exc_info[1], exc_info[2]
finally:
exc_info = None # avoid dangling circular ref
elif headers_set:
raise AssertionError("Headers already set!")
headers_set[:] = [status,response_headers]
return write
result = application(environ, start_response)
try:
for data in result:
if data: # don't send headers until body appears
write(data)
if not headers_sent:
write('') # send headers now if body was empty
finally:
if hasattr(result,'close'):
result.close()
# Change this to the directory above your site code.
sys.path.append("/py")
# Change mysite to the name of your site package
os.environ['DJANGO_SETTINGS_MODULE'] = 'pytest.settings'
run_with_cgi(django.core.handlers.wsgi.WSGIHandler())
i odpalamy to by www 
na razie tyle …
Dokładam paczkę z plikami do testu:
unzip py.zip; ftp na home.pl; open http://server.home.pl/py/dispatch.py/admin
Za dnia piszę najczęściej w php i zazdroszczę pythonowi pylinta.
Z ciekawości zagooglałem i znalazłem rozwiązanie dla PHP sprawdzające Coding Standard:
pear install PHP_CodeSniffer phpcs --standard=Zend SomeTest.class.php
phpcs -i podaje dostępne standardy:
Mi najbardzie odpowiada Zend co widać po wynikach lintowania, najczęściej 0 ostrzeżeń i błędów .
phpcs pozwala także tworzyć swoje własne standardy kodowanie oraz – co bardzo mnie cieszy – podpiąć go jako precommit hook do svn’a.
W Netbeans 6.5 pojawia się support dla php5. W/g informacji na stronie netbeans oznacza to:
Temat, który najbardziej mnie interesował to jak zadziała debugging przy pomocy Xdebug. Postanowiłem sprawdzić to z istniejącym projektem bazującym na frameworku Symfony.
# xdebug, jako zend_extension. ścieżke zmienić należy oczywiście na odpowiednią dla Twojej instalacji zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so xdebug.remote_enable=on
W tym momencie w uruchomionej przeglądarce (u mnie firefox 3.x netbeans otwarł główny kontroler projektu wraz z parameterm XDEBUG_SESSION_START=netbeans-xdebug. W tym samym momencie w edytorze netbeans podświetlony został pierwszy wiersz kontrolera … i już.
Możemy teraz ustawiać watche, breakpointy, poruszać się step out, step in, step up wybierając opcje z menu ‘debug’ lub używająć skrótów klawiszowych.
Dzięki krótkiemu testowi widać, że podstawowy debug działa i można sobie poużywać. Oczywiście jeżeli lubimy php5 i lubimy netbeans lub któreś z nich musimy używać
