Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 9 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Auch wenn ich nicht wirk­lich ‚viel‘ code, aber so ab und zu fällt ja doch mal was an … In den letz­ten Jah­ren v.a. aber eher Klein(st)beiträge zu bereits bestehn­dem Code Ande­rer, statt eige­ner Projekte.

2010 ver­such­te ich mei­ne ers­ten Schritt(ch)e(n) mit Git und such­te dafür eine geeig­ne­te Platt­form. – Nur Kom­man­do­zei­le mit eige­nem Git-Ser­ver war mir damals IMHO zu umständ­lich und wohl auch zu ner­dy. ‚Damals‘ gabs zwar schon Git­hub (und dort hat­te ich auch seit 2009 einen unge­nutz­ten Account), aber als F(L)OSS-Verfächter woll­te ich mehr Com­mu­ni­ty und fand letzt­lich Gito­rious, wo ich mir einen Account zuleg­te. (So jeden­falls mei­ne Erinnerung …)

Bei Gito­rious gab es anfäng­lich kei­nen Issue-Tra­cker und die Inter­ak­ti­on über Web­ober­flä­che war, im Gegen­satz zu Git­hub, sehr beschränkt. So kam es im Lau­fe der fol­gen­den fünf Jah­re zur vor­ran­gi­gen Nut­zung mei­nes Github-Accounts.

Im letz­ten Jahr gab es Bedarf für die Zusam­men­ar­beit meh­rer Per­so­nen ein einem Pro­jekt (etwas bug fixing im Code von POLYKON) – dabei soll­te das erst ein­mal nicht in der Öffent­lich­keit pas­sie­ren. Somit schied Git­hub (auf Grund der Kos­ten) aus und ich fand Bit­Bu­cket und erstell­te auch dort einen Account.

In Sum­me hat­te ich bis dahin also drei Accounts bei unter­schied­li­chen Anbie­tern für Git-Repo­si­to­ries gesammelt …

Git­Lab-Logo

Letz­te Woche woll­te ich mal wie­der bei Gito­rious schau­en, was so los ist und stell­te fest, dass Git­Lab den Laden über­nom­men hat und man emp­fiehlt, die eige­nen Gito­rious-Repos auf Git­Lab umzu­zie­hen. Dann habe ich mich also mal bei Git­Lab umge­schaut und schwupps, war der vier­te Account geklickt … 😉

War­um nun noch einen vier­ten Account?

  • GitLabs Web­in­ter­face ist schnell
  • Git­Lab bie­tet nicht­öf­fent­li­che Repos an
  • Git­Lab bie­tet eig. alle (von mir benutz­ten) Fea­tures wie Git­hub (und ist sogar bes­ser ;))
  • Git­Lab gibts in der Com­mu­ni­ty Ver­si­on kostenlos
  • und jetzt der Knal­ler: per Klick konn­te ich (mit etwas Recher­che) alle Repos aus den ande­ren drei Accounts importieren
  • wenn die But­ze iwann (vllt.) mal zu macht, dann kann ich/man das immer noch sel­ber hosten
  • das Icon ist süüüß … 😉

Zusam­men­ge­fasst: Aktu­ell schrumpfe/konsolidiere ich mei­ne Git-Platt­form-Accounts. Gito­riuous is schon weg und gleich kommt noch der Bit­bu­cket-Account dran. Bei Git­hub wer­de ich dann wohl nur noch wg. der Issue- und Pull-Request-Zwe­cke sein, die eige­nen Pro­jek­te kom­men dort auf jeden Fall weg.

Mal schau­en, ob sich das Auf­räu­men lang­fris­tig als klug erwei­sen wird …

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

…gehö­ren mir!

Letz­te Woche bin ich über unhosted.org – „Per­so­nal data free­dom; A move­ment to sepa­ra­te web apps from user data“ – gestol­pert. Und die haben die Web-App „Lib­re Docs“ auf Basis von Ether­pad Lite geschaf­fen, die das von Lib­re Docs zur Ver­fü­gung gestell­te Ether­pad nutzt, die erzeug­ten Daten bzw. Doku­men­te jedoch in der Cloud ablegt/speichert. Und der Ober­knal­ler dar­an ist, dass die­se Cloud-Schnitt­stel­le mit­tels der Java­script-Cli­ent-Biblio­thek remoteStorage.js, die die Rea­li­sie­rung einer W3C-Spe­zi­fi­ka­ti­on ist, umge­setzt wur­de und somit auch mei­ne eigen Cloud benutzt wer­den kann.

Wie jetzt, mei­ne eige­ne Cloud…!? – Na die, die ich mit own­Cloud auf mei­nem Web­space betrei­be und in der ich schon meine(n) Kalen­der (Cal­DAV), mein Adress­buch (Card­DAV) und ein paar Datei­en (Web­DAV) mit­tels Desk­top (Thun­der­bird & Ubun­tu) und Smart­phone (Android) ver­wal­te und synchronisiere.

Also ich kanns nur emp­feh­len und bedan­ke mich jetzt schon mal bei allen Betei­lig­ten der oben genann­ten Projekte! 🙂

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

POLYKON – die Daten­bank für Poly­me­re als Kon­ser­vie­rungs- & Restau­rie­rungs­mit­tel ent­hält struk­tu­rier­te Infor­ma­tio­nen zur che­mi­schen Ein­ord­nung, den Eigen­schaf­ten und der Ver­wen­dung zahl­rei­cher Poly­me­re, die in der Restau­rie­rung ein­ge­setzt wur­den und wer­den. Sie haben die Mög­lich­keit mit Hil­fe der Schnell­su­che oder der erwei­ter­ten Suche nach Pro­duk­ten, Poly­mer­ty­pen oder Anwen­dungs­bei­spie­len zu recherchieren.

So steht es unter polykon.fh-potsdam.de geschrie­ben und ich bin sehr froh, dass wir es so (schön) geschafft haben! (Aus der v1.0 von heu­te wird aber bestimmt in den nächs­ten Tagen noch ne v1.5 oder so…)

Dan­ke an Alle!

Ich wer­de dann jetzt mal mit der Doku­men­ta­ti­on begin­nen… *puhhh*

PS:
Der Code-‘Wahnsinn’ gehört da hin… 😉

PPS:
Die URL www.polykon.fh-potsdam.de funk­tio­niert nicht!

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

…ich bin kein PHP-Pro­gram­mie­rer, aber für mei­ne B.A.-Arbeit mache ich es (mehr recht als schlecht) & bekom­me dabei manch­mal fast ne Krise…

So zum Bsp. in den letz­ten bei­den Tage. – Da wur­de aus einer klei­nen 40zeiligen Funk­ti­on (die die gewoll­ten Grund­funk­tio­na­li­tä­ten lie­fert) ein klei­nes Mons­ter mit 164 Zei­len… – Aber jetzt isses halt echt viel schö­ner & die Bedar­fe Aller sind befriedigt… 😉

Außer­dem noch schnell nen Link zu dem Pro­jekt RIPS: http://rips-scanner.sourceforge.net.
Damit kann man off­line PHP-Code auf Feh­ler & Schwach­stel­len prü­fen las­sen… – Sehr nett! (Aber bit­te nicht nur dar­auf verlassen. ;))

*sound­jetzt­gehts­ins­bett-wink*

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

An die­ser Stel­le soll es heu­te mal kurz um ein Pro­blem­chen und des­sen ‘Lösung’ gehen, wel­ches mich ges­tern (fast) den gan­zen Tag beschäf­tigt hat.

Ich hat­te die Auf­ga­be zu lösen, mit­tels eines HTML-For­mu­lars und PHP ein Bild (als BLOB) in einer MyS­QL-Daten­bank abzu­le­gen. – Eigent­lich ja nicht all­zu schwie­rig, denn Anlei­tun­gen & Code-Schnip­sel dazu gibts im Netz wie “Sand am Meer”…

Am Ende ent­schied ich mich für die Vari­an­te, die hoch­ge­la­de­ne Datei ohne file hand­ler (fopen, fread, fclo­se) in die DB zu hexen. Denn man kann recht ein­fach mit­tels mit­tels der glo­ba­len PHP-Varia­ble “$_FILES” auf die (mit­tels POST) hoch­ge­la­de­ne Datei zugrei­fen.

if (isset($_FILES['bild']) && is_uploaded_file($_FILES['bild']['tmp_name']) && $_FILES['bild']['size'] > 0) {
$mimetype = $_FILES['bild']['type'];
$blob = bin2hex(file_get_contents($_FILES['bild']['tmp_name']));

Da ich beim Insert immer die Mel­dung bekam, dass ich einen Feh­ler in der SQL-Syn­tax habe, wenn ich für den BLOB mysql_real_escape_string(file_get_contents($_FILES['bild']['tmp_name'])) oder addslashes(file_get_contents($_FILES['bild']['tmp_name'])) (wie bspw. hier beschrie­ben) benutzt habe, habe ich letzt­lich die Funk­ti­on bin2hex() für das Spei­chern der binä­ren Daten (des Bil­des) in der MEDI­UM­B­LOB-Spal­te der DB verwendet. 

Nach ein paar Test-Uploads stell­te ich dann jedoch fest, dass grö­ße­re Bil­der nicht hoch­ge­la­den wer­den kön­nen – wg. der Begren­zung auf dem Ser­ver. Also habe ich etwas gesucht und die dafür zustän­di­gen PHP-Ein­stel­lun­gen bzw. ‑Varia­blen gefun­den. Die­se spuck­ten mir aller­dings aus, dass mei­ne max. Upload-Grö­ße 32MB beträgt, was bei einem Upload von einem ca. 1,5MB gro­ßen Bild jedoch nicht ’stimm­te’. Denn da kam dann dann die MyS­QL-Mel­dung “Got a packet big­ger than ‘max_allowed_packet’ bytes” und der Daten­satz wur­de nicht in die DB geschrieben.

‘Gut, dass die MyS­QL-Mel­dung so aus­sa­ge­kräf­tig ist’, dach­te ich mir und such­te erneut nach einer Lösung… – Und sie­he da, auch dazu gibt es Lösun­gen, wie bspw. die­se. Ärger­lich war nur, dass ich den gan­zen Tag der Mei­nung war, dass der MyS­QL-Para­me­ter “max_allowed_packet” dyna­misch zur Lauf­zeit des Ser­vers per PHP beein­fluss­bar ist. *gml*
Dies kam zum Bei­spiel auch daher, dass das Aus­le­sen des Para­me­ters (mit mysql_query("SHOW VARIABLES LIKE 'max_allowed_packet'")) und das Neu­set­zen des Wer­tes (mit­tels mysql_query("SET max_allowed_packet=16777216;")) zwar anstands­los funk­tio­nier­te, aber lei­der den Upload nicht ver­bes­ser­te. Trotz des neu gesetz­ten Wer­tes (auf 16MB), war die Upload­gren­ze in Wirk­lich­keit immer noch beim Stan­dard­wert 1MB.

Lan­ge Rede, kur­ze Erkenntnis:
Das Ändern des MyS­QL-Wer­tes “max_allowed_packet” zur Lauf­zeit per PHP funk­tio­niert (i.d.R.) nicht. (Man kann, wenn man MyS­QL-Root-Rech­te mit sei­nem Log­in hat, ver­su­chen, den glo­ba­len MyS­QL-Para­me­ter zu ver­än­dern.)
Man muss/sollte/kann die Ein­stel­lung ser­ver­sei­tig vor­neh­men und ent­we­der dau­er­haft den Ein­trag max_allowed_packet=16MB; in der my.cnf machen oder mit MyS­QL-Root-Rech­ten den Wert mit­tels SET max_allowed_packet=16777216; zur Lauf­zeit ändern (dann ist die­ser bei einem Neu­start aller­dings wie­der weg).

Außer­dem ist anzu­mer­ken, dass die BLOBs in der DB irgend­wie (ca.) dop­pelt so groß sind/werden, wie die Ori­gi­nal-Datei­en. – Aus einem Bild mit 991K wird bspw. (bei mir) ein BLOB mit 2.03MB. *strange&doof* (Bit­te jetzt kein Bas­hing, ob es über­haupt sinn­voll ist, Bil­der direkt in der DB zu spei­chern. – Es muss die­ses Mal so sein!)