Tag: python

Dags att växla upp

Behövde tanka Ubuntu Desktop-skivan och jag tänkte att jag lika gärna kan låta arla (fil-maskin) servera Ubuntu-avbilder 24/7. Hur som, för att från min laptop lägga till en torrent på arla gjordes följande:

easy_install -U transmissionrpc
cat > /usr/local/bin/torrent-relay
#!/usr/bin/python

import sys
from base64 import b64encode
import transmissionrpc

HOST = "filserver"
PORT = 9091

filename = sys.argv[1]
metainfo = b64encode(open(filename, 'rb').read())

tc = transmissionrpc.Client(HOST, port=PORT)
tc.add(metainfo)

Konvertera SVG till PNG

Jag har haft stor glädje av Gnome-grafikerna ikoner de sista dagarna då jag gjort presenatationer på olika ämnen (just nu sitter jag och försöker städa upp introbilderna till TDD och JDojo). OpenOffice hanterar dock inte av SVG-filerna snyggt – det ser riktigt illa ut tyvärr. Så, lösningen har varit att konvertera dem till PNG istället (för hand) till 320×320 pixlar – det räcker fint för att det skall se bra ut på projektor.

Det jag ville göra nu var att slippa utföra jobbet för hand, och det lyckades jag inte med (trodde jag). ImageMagick (convert) gjorde nämligen att det blev svart bakgrund istället för transparent. Efter att jag fick igång den interaktiva python-fu-prompten så fick jag ut svart bakgrund där också, och även http://guillaume.segu.in/blog/code/43/svg-to-png/ producerade svart bakgrund … Sedan tittade jag på filerna utan att använda Eye Of Gnome (eog) och upptäckte att det visst var fina bilder med fin transparent bakgrund. Problemet var helt enkelt att jag lurats av eog.

Well well, här är python-koden som behövs för att skripta Gimp:

>>> import sys
>>> import os
>>> from gimpfu import *
>>> image = pdb.file_svg_load(filename, filename, 90, 320, 320, 0) #dpi, w, h, paths
>>> drawable = pdb.gimp_image_active_drawable(image)
>>> pdb.file_png_save2(image, drawable, outfilename, outfilename, 1, 9, 1, 1, 1, 1, 1, 0, 1)

Riktigt trevligt. :)

PyUseCase för ExtJS

Häromdagen var jag på GothPy-möte och fick se och testa på PyUseCase. Efteråt funderade jag på det 18-månadersprojekt (~8 utvecklare) jag nyss avslutat där ExtJS varit GUI-ramverket i applikationen (dvs en Rich Internet Application).

PyUseCase för ExtJS

  1. Det hade varit väldigt användbart.
  2. Jag har inte sett något liknande för webb.
  3. Jag tror inte att det är omöjligt …
  4. … men det kan kräva en hel del kunskap (om Selenium IDE) och kod att få till. :/

Jag har ännu inte kollat på Selenium 2. Jag har inte testkört Bromine utan bara tittat på dess screencast. ** I början av projektet jag satt på pratade vi dock om att det hade varit fint att ta oss till den nivån att man hade selenium-test som verifierade use case. Det närmaste jag såg ett verktyg som skulle kunna stödja det var STIQ, men organisationen ville inte testa detta – att använda Selenium var tillräcklig risk i projektet tyckte man.

** “Management can look at the icons ” 7 minuter in i filmen :)

Versionshantering

Varken STIQ eller Bromine verkar dock versionshantera testen, eller gruppera dem i “detta är use-casen för sprint 10”, och det är något jag känner att jag saknar. Under de 18 månader vi jobbade så byggdes flera funktioner om, så i sprint 10 kanske vi stödde 15 Use case, medan sprint 11 bara klarade 12 eftersom 3 skrevs om.

Sättet vi hanterade det på var att kommentera bort test case från testsviten. Inte snyggt, men eftersom Hudson mailade oss varje gång testen inte fungerade var vi nästan tvungna …

Avslutande tankar

  • Det jag gillar med Bromine är kopplingen till krav/use case.
  • Det jag gillar med STIQ är wiki-hanteringen och att man försöker abstrahera testen till logiska enheter/interaktionssteg.
  • Det jag gillar med PyUseCase (för GTK) är hur inspelningen mappar till logisk enhet/interaktionssteg. Separationen med texttest är inte dum, eftersom valideringsbiten faller bort från stegen som behövs för att utföra use caset. Att ha två representationer av GUI:t (en ASCII-art och en verklig) är dock inte intuitivt för mig och känns som ren duplicering. Kanske är det ett nödvändigt ont man får acceptera för att få rena “use case test”?
  • Med ett UI-ramverk som ExtJS borde man kunna lyssna på komponenter på samma sätt som PyUseCase gör med PyGTK. ASCII-art-rendreringen server side (eller iaf någon logg) är jag tveksam till.

Python and Maemo, where’s that N900

Work in progress! :)

Väntar tålmodigt på att Nokia Online Store skall skicka mig meddelande om att “nu är din beställning skickad” – i Italien verkar utrullningen vara i full gång, i Sverige har den inte börjat ännu. Senaste budet är att i vecka 50 kommer de första beställningarna skickas ut. Vet inte om jag ligger med bland dem.

Nåväl. Jag har jobbat på att få till en applikation som kan visa avgångar och resvägar inom Göteborg med hjälp av Västtrafiks web services. Det har tagit ungefär så lång tid som jag förävntat mig och följande var utmaningarna.

[flashvideo file=http://wendt.se/misc/maemo-vasttrafik-091203-a.flv width=400 height=286 /]

Python

Jag är inte överens om att block-level avgörs av indentering – vilket företag vill betala utvecklare för att sitta och flytta kod till vänster och höger? Jag programmerar mycket hellre med {} och låter ett verktyg formatera koden “vackert”.

IDE – här har jag dock varit lat. PyEclipse skall tydligen vara rätt bra och ge bra stöd (hoppas det finns code completion-stöd för gtk.* med signaler och annat?)

PyGtk (API)

Väldokumenterat. Ihop med GTK+-dokumentationen måste jag säga att det är komplett. Widget-galleriet är också kanon att kunna snegla på.

PyMaemo och Hildon

(API) Hildon C-API

Detta upplever jag vara den svagaste länken i kedjan. Att jobba med en touch-applikation är nytt för mig, och jag gissar att det gäller många andra också, och då behövs vägledning, widget gallerier och tonvis med exempel så att man kan få en känsla för hur man bör bygga bra GUI:n.

Lite vägledning finns (plus Nokias UI guide lines och usability-dokument), men widget galleri och tonvis med exempel saknas – det finns ett tiotal exempel som visar lika många widgets, men inte ett enda “riktigt” program.

Py* för Web Services

Efter att ha prövat ett par bibliotek, alla med olika tillkortakommanden (schematolkning, teckenkodning, …), så stötte jag på suds som fungerar utmärkt om man bara vill ha en väl fungerande klientdel.

PS

Screen captures with XVidCap, konverterat med

ffmpeg -y -i test-0000.mpeg -qscale 5 -an -s 400x240 -f flv test.flv

[flashvideo file=http://wendt.se/misc/maemo-vasttrafik-091203-b.flv width=400 height=286 /]