Pythonhack och NixOS

Jag hackade nyligen ihop ett program som läser in ett API och presenterar detta som en ATOM/RSS-feed. Det blev inte snyggt, men nu kan jag följa en blogg som normalt saknar ett RSS-flöde i min RSS-läsare.

Det trixigaste var att lyckas förstå hur en kör ett program som detta i NixOS, men utan att behöva stöka allt för mycket. Jag ville att skriptet ska köras varje timme och jag ville använda några förpaketerade paketberoenden. I korthet, Nix-Writers fixade biffen!

{ pkgs, ... }:
let
  python-hack = pkgs.writers.writePython3 "pythonhack" {
    libraries = [ pkgs.python3Packages.feedgen pkgs.python3Packages.requests ];
  } (builtins.readFile "/path/to/script.py");
in {
  systemd.services.python-hack = {
    description = "hack hack hack";
    serviceConfig = {
      Type = "oneshot";
      User = "foobar";
      ExecStart = python-hack; # samma namn som i let-blocket
    };
  };
  systemd.timers.python-hack = {
    wantedBy = [ "timers.target" ];
    partOf = [ "python-hack.service" ];
    timerConfig.OnCalendar = "hourly";
  };
}

Det är nog lite hackigt att använda writers-funktionaliteten såhär, det är nog tänkt att användas för att skriva programkod direkt i nix-filen, istället för att bara läsa in källkoden från en fil som här ovan. Men det fungerade, och det var relativt enkelt att sätta ihop.

Huawei E3372 & Linux

Det här är mest en anteckning till den framtida Oscar, och eventuella andra intresserade.

Jag har ett USB-modem jag använder med mina datorer hemma, ett Huawei E3372. Det startar först upp som en CD-enhet för att dela med sig av sina drivrutiner, och behöver sedan instrueras att byta läge till ett vanligt modem.

För detta skapade jag en udev-regel som gör det jobbet åt mig, ersätt sökvägar med vad som är korrekt för din Linux:

ATTR{idVendor}=="12d1", ATTR{idProduct}=="14fe", RUN+="${pkgs.usb_modeswitch}/bin/usb_modeswitch -v 12d1 -p 14fe -V 12d1 -P 1506 -J"

Du kommer behöva programmet usb_modeswitch, som verkar finnas paketerad för de flesta distros.

Alla ID:n och liknande fås av att köra en lsusb. Innan modemet bytt läge:

Bus 002 Device 016: ID 12d1:14dc Huawei Technologies Co., Ltd.

Efter att den bytt läge:

Bus 001 Device 006: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard

För mig startade inte modem-manager (som krävs, och är en del av network-manager) automagiskt, så jag lade till en extra udev-regel för att fixa detta när modemet (i rätt läge) ansluts:

ATTR{idVendor}=="12d1", ATTR{idProduct}=="1506", RUN+="${pkgs.systemd}/bin/systemctl restart modem-manager.service"

Nu behöver jag bara be network-manager att koppla upp sig på 4G. Klart!

Ringtestning

Jag gissar att samma problem lär uppkomma under polarnatten. Det är inte konstigt att folk inte är bekanta med polarnätter och midnattssolen, men åtminstone någon som inte är en junior testare borde veta något om att dagslängd förändras under året och att löjliga edge cases borde testas här.

guetzli

I brist på andra sätt att prokrastinera har jag börjat bekanta mig med verktyget guetzli (”Perceptual JPEG encoder”), som är en riktig rackare på att göra JPEGs mindre i storlek. Som med mycket annan häftig alternativt skrämmande teknik idag är det Google som har finansierat detta projekt.

Originalbilden är ca 4 megapixel, är ca 1.7 megabyte stor i sitt ursprungliga utförande. Den innehåller rätt mycket fin textur och är rätt skarp, trots att den är tagen på frihand. Originalbilden är förresten att ta i, originalbilden är på 24 megapixel och jag har exporterat en nedskalad version som jag sedan använt här.

Jag lät guetzli tugga sig igenom originalbilden på den lägsta tillåtna kvalitetsnivån 84, väntade ut processen och jämförde produkten med originalet.

  • Original: 1.7 megabyte
  • Guetzli, kvalitetsnivå 84: 784 kilobyte
  • Guetzli, kvalitetsnivå 95: 1.2 megabyte

Det är en rätt stor skillnad!

När jag sedan jämförde bilderna vid 100% förstoring tog det mig först en liten stund att se skillnaden — men nu är den rätt solklar för den lägsta inställningen, men inte för den förinställda.


Vad är då nackdelen med guetzli? Tid, samt CPU- och minnesåtgång på maskinen som kör programmet. Det tog 11 minuter att exportera bilden på 84% på min bärbara dator, och när jag lät en lite mer kraftfull maskin göra jobbet tog det fortfarande lång tid:

  • Kvalitet 84, 7 minuter 37 sekunder
  • Kvalitet 87, 8 minuter 6 sekunder
  • Kvalitet 90, 8 minuter 36 sekunder
  • Kvalitet 93, 9 minuter 6 sekunder
  • Kvalitet 95, 9 minuter 31 sekunder

Ovan för en bild på 4 megapixel! Just nu processar samma dator en bild på 24 megapixel vid ett par olika kvalitetsinställningar, men jag tänker inte vänta ut att den körningen går klart innan jag hittar på något annat. 🙂


Jag väntade ut bilden innan jag publicerade detta. Det tog drygt en timme (!) per variant.

  • Originalbilden, ca 12 megabyte
  • Kvalitetsnivå 95, 7.4 megabyte
  • Kvalitetsnivå 90, 4.8 megabyte
  • Kvalitetsnivå 84, 4 megabyte

Jag vet inte vad som är rimligast av nivåerna ovan. Jag har bara märkt att mina bilder just nu är rätt stora och att jag borde minska ner dessa lite. Jag blev lite nyfiken på att sätta upp ’objektiva’ kvalitetsmått likt det som beskrivs i guetzlis Wikipedia-sida...men det är ett äventyr för en annan kväll.