Thursday, September 25, 2014

GitHub für den pragmatischen Einsteiger

Situation

Man hat Quellcode für ein Perl-Skript oder ein CPAN-Modul, der der Öffentlichkeit zur Verfügung steht.

Diesen Quellcode möchte man gerne mit einer Versionsverwaltung verwalten.  Außerdem möchte man anderen Menschen eine einfache Möglichkeit bieten, den Quellcode einzusehen, eventuell Patches zu schreiben, oder eigene Software auf Basis des Quellcodes zu entwickeln.

In diesem Artikel wird Windows vorausgesetzt.


Git und GitHub als Mittel der Wahl

 Als Versionsverwaltung bietet sich Git an. Git ist eine freie Software zur Versionsverwaltung [1]. Im Idealfall verwendet man Git nicht nur, weil es gerade Mode ist, sondern auch aus einem anderen Grund. Davon werden auf Wikipedia auch direkt welche ausgeführt. Die Quellcodes werden dann in einem sog. Repository abgelegt.

Nun soll der Quellcode auch anderen Mensche zur Verfügung stehen. Hier kommt GitHub ins Spiel. GitHub ist eine Plattform zur Verwaltung von Git-Repositorys. Sobald ein Repository auf GitHub angelegt wurde, können dort Quellcodes abgelegt werden. Diese wiederum können durch Dritte einegsehen und genutzt werden, sozusagen als Kollaborationsplattform [2].


Anwendungsfall Patch

Jedes Git-Repository auf GitHub hat eine eigene Webseite. Da kann der Quellcode eingesehen werden.
Ein Repository kann außerdem geforkt werden. Das erstellt eine Kopie des gesamten Repositories für den Nutzer, der klont. Dann kann ein anderer quasi mit dem Quellcode machen was er will, ohne dass die Original-Quellcodes irgend etwas davon mitbekommen.

Möchte man Quellcode in das Repository zurückspielen, so erstellt man einen Pull-Request. Das ist eine Anfrage an das Original-Repository auf GitHub, mit der Bitte die Unterschiede zwischen dem Stand der Quellcodes im Haupt-Repository und den Quellcodes im geforkten Respoitory zu übernehmen.

Das alles muss man nicht von Hand machen, In der Windows-Welt gibt es dafür ein wunderbares Werkzeugt: GitHub für Windows


Genug Theorie, einfach mal machen

  1. GitHub-Account erstellen
  2. GitHub für Windows installieren
  3. Ein Repository aussuchen und forken
  4. GitHub für Windows öffnen und das geforkte Repository auf den loakeln Rechner "klonen":
  5. Änderungen durchführen, z.B. einen Bug beheben
  6. Änderungen synchronisieren. Das bedeutet, dass die Änderungen die auf dem lokalen PC durchgeführt wurden in das geforkte Repository (nicht das Original-Repo) eingefügt werden:
  7. Auf GitHub den "Create Pull Request"-Button drücken
Jetzt erhält der Besitzer des Original-Repositorys eine Nachricht, dass jemand Quellcode zum Einpflegen vorgeschlagen hat.


Quellen / Referenzen

  1. http://de.wikipedia.org/wiki/Git
  2. https://github.com/
  3. https://windows.github.com/

Saturday, June 21, 2014

Audiodateien mit Perl abspielen (Windows only)

Wie man mit Perl und SDL MP3-Dateien abspielt, hatte ich in der Vergangenheit bereits in einem Blogeintrag beschrieben: MP3s mit Perl abspielen

Das sympathische an der Lösung mit SDL ist, dass sie plattformunabhängig funktioniert.

Wer nur auf Windows arbeitet kann aber auch andere Wege nutzen. So gibt es für Windows das Media Control Interface - kurz: MCI. Mir sind dazu bislang zwei Module auf CPAN untergekommen. Beide sind zugegebenermaßen über die klassische CPAN-Suche nicht immer so einfach zu finden, daher hier mal die Links dazu:
Von den kleinen Versionsnummern sollte man sich nicht schrecken lassen. Die Module funktionieren - soweit ich das bislang getestet habe - so wie sie sollen.

Die Dokumentation von Win32::MCI::Basic fällt derzeit sehr spartanisch aus. Eigentlich steht ja alles drin, was man braucht. Die beiden Befehle und ein Verweis auf die Microsoft-Dokumentation zum Thema. Leider gibt es (noch) kein Code-Beispiel.

Hier wäre dann eins:

#!/usr/bin/perl
use strict;
use warnings;
use Win32::MCI::Basic;
use File::Spec;

=comment

Let Perl play a sound file using Windows MCI.

Sources (all downloaded 2014-06-21):

http://search.cpan.org/dist/Win32-MCI-Basic-0.02/Basic.pm
https://metacpan.org/pod/Win32::MultiMedia::Mci
http://www.perlmonks.org/bare/?node_id=295558
http://msdn.microsoft.com/en-us/library/windows/desktop/dd757151%28v=vs.85%29.aspx
http://social.msdn.microsoft.com/Forums/es-ES/92803129-24c3-42d0-b32a-17d05606a151/win32-mci-api-for-playing-media?forum=vblanguage

=cut

# define your Audio file here. Tested with WMA and MP3
my $file_wma = File::Spec->catfile( $ENV{WINDIR}, '\Media\Alarm01.wav' );

run_or_die("open \"$file_wma\" alias myaudio");
run_or_die("play myaudio wait");
run_or_die("close myaudio");

print "done\n";

sub run_or_die {
    my $command = shift or die('Missing MCI command');

    my ($APICallReturnValue, $lpszReturnString) = mciSendString($command);
    printf("API Call Return Value: %s, that other string: %s\n", $APICallReturnValue, $lpszReturnString);
   
    die mciGetErrorString($APICallReturnValue) unless $APICallReturnValue == 0;
   
    return;
} # /run_or_die


Statt WAV-Dateien kann man auch MP3s reinwerfen und sie werden abgespielt. Läuft etwas schief, dann wird der Return-Code auf etwas anderes als 0 gesetzt.Der Return-Code kann dann mit dem Befehl mciGetErrorString in die dazugehörige Fehlermeldung umgewandelt werden.

Was es mit dem $lpszReturnString auf sich hat, habe ich leider noch nicht verstanden. Wer es weiß, darf gerne einen Kommentar hinterlassen.

Monday, May 19, 2014

Konfigurationsdateien für Perl-Programme ablegen

Und wieder einmal stehe ich vor der Frage: wohin mit der Konfigurationsdatei für mein Perl-Programm?

Ganz konkret geht es um minicpan - einem kleinen Programm zur Erstellung eines lokalen CPAN-Mirrors. Der ist ganz praktisch, wenn man unterwegs ist, mal kein Internet hat oder einfach keinen Bock darauf hat, schon wieder auf das Herunterladen der Module zu warten.

Wie minicpan auf Windows eingerichtet wird, wird auf diesen beiden Webseiten ganz gut erklärt:

Das Prinzip ist einfach. Es gibt schon alles, was für einen lokalen CPAN-Server benötigt wird: ein Modul CPAN::Mini und ein Programm namens minicpan. Wird das Modul CPAN::Mini installiert, dann steht auch minicpan zur Verfügung.

minicpan arbeitet mit einer Konfigurationsdatei. In dieser Konfigurationsdatei wird u.A. eingetragen, von welchen CPAN-Server die Module geladen werden sollen und wo die Module auf der lokalen Festplatte abgelegt werden:

# Hier werden die Module auf der Festplatte abgelegt:
local: D:/www/MINICPAN/

# remote = der Server, von dem die Module gezogen werden
# Kann z.B. einer aus dieser Liste sein: http://www.cpan.org/SITES.html
remote: http://mirror.optusnet.com.au/CPAN/


Die Konfigurationsdatei wird auf Windows über eine Umgebungsvariable CPAN_MINI_CONFIG bekannt gemacht. Der Wert der Umgebungsvariable ist der Pfad zur Konfigurationsdatei. Ist das geschehen, reicht ein Kommando aus, um einen lokalen CPAN-Spiegel zu erzeugen:

minicpan -f

Anschließend muss das Repository noch im Helferlein cpan eingetragen werden, damit die Module auch aus der lokalen Kopie installiert werden. In cpan kann man dazu die folgenden zwei Befehle ausführen:

conf urllist file:///D:/www/MINICPAN/
conf commit

Zurück zur ursprünglichen Frage: wohin mit der Konfigurationsdatei? Klar kann die irgendwo liegen. Aber gehört sie da auch hin? Leider habe ich keine Referenz gefunden, in der konkret drin stand, wo die Dateien hin müssen. Aber es gibt eine Seite von Microsoft, in der die diversen Orte für Konfigurationsdateien beschrieben werden (Hinweise auf eine bessere Seite sind gerne willkommen): Accessing app data with the Windows Runtime (Windows Runtime apps)

Da steht sozusagen, dass Konfigurationsdateien, die nur für das lokale Gerät und den lokalen Benutzer gedacht sind, in %localappdata% rein sollten:

Local app data

Local app data should be used for any information that needs to be preserved between app sessions and is not suitable type or size wise, for roaming app data. Data that is not applicable on other devices should be stored here as well. There are no general size restriction on local data stored. Location is available via the localFolder property. Use the local app data store for data that it does not make sense to roam and for large data sets.

Das wiederum ist ganz praktisch, denn das Modul File::HomeDir nennt genau den Pfad zu %localappdata% als Ort für my_data, also Daten einer Applikation für den aktuellen Benutzer:

my_data

The my_data method takes no arguments and returns the directory where local applications should stored their internal data for the current user.

File::HomeDir ist generell ein ganz interessantes Modul. Es erlaubt plattformunabhängig die richtigen Verzeichnisse für Benutzerdaten zu finden. Hier ein kleines Beispiel für den  Nutzer root:


Quellcode:

#!perl

use strict;
use warnings;
use File::HomeDir;
use Tkx;

my $mw = Tkx::widget->new(".");
my $row = 0;
my @mnames = <my_home my_desktop my_documents my_music my_pictures my_videos my_data>;
foreach my $method_name ( @mnames ) {
    my $namel = $mw->new_ttk__label(-text => $method_name, -justify => 'left');
    $namel->g_grid(-row => $row, -column => 0, -sticky => 'we');
   
    my $vall = $mw->new_ttk__label(
        -text => File::HomeDir->$method_name,
        -justify => 'left',
    );
    $vall->g_grid(-row => $row, -column => 1, -sticky => 'we');
   
    $row++;
}

Tkx::MainLoop;


Sollte man nun also auf die Idee kommen, Windows-Nutzern eine kleine Applikation zur Konfiguration des lokalen CPAN-Mirros zu schreiben - idealerweise mit einer Möglichkeit die Module zu definieren, die überhaupt gespiegelt werden sollen, einer Möglichkeit eigene Module per CPAN::Mini::Inject einzubauen - dann weiß man jetzt auch, wo die Konfigurationsdatei dafür liegen muss.