Smarthome@github

Amikor nekiálltam az építsünk okos házat projektnek, arra gondoltam, hogy az átlagos informatikai projektektől eltérően ez egy egyszerű dolog lesz, buktatók és problémák nélkül, pár hét alatt véget is ér. Annyira bíztam ebben, hogy még repository-t se csináltam, a forrásokat egyszerűen dropbox-on tartottam. Mostanra eljutottam oda, hogy az alapvetések már működnek, és újra se kell írni mindent (amíg nem jön az openhab v3). Igaz az ütemezéssel kicsit megcsúsztam, de hát mégicsak egy IT projektről van szó, ahol még azok sem mindig tudják mit akarnak, akik az általam használt komponenseket fejlesztik…

Jelenleg épp léptető motort programozok, 3D modelleket készítek nyomtatáshoz, integrálok, deriválok, szabadidőmben pedig egy megbízhatóbb MQTT kommunikációs protokol implementációján gondolkozom, az eszközök és az openhab között… Szóval az izgalmak még csak most kezdődnek (legalábbis annyi izgalom, amit az időm enged).

Újdonság viszont, hogy a projekt felkerült a github-ra, így az újabb dolgok már ott is megtalálhatók: https://github.com/voji/smarthome

Oracle adatbázis séma gyors törlése

Le akartam törölni pár nagyobb sémát Oracle alatt, aminek az lett az eredménye, hogy 20 órát futott a DROP USER… Kis olvasgatás után az körvonalazódott, hogy ezt a funkciót nem sikerült jól implementálni, ezért inkább töröljek kézzel mindent, és csak a végén töröljem a már üres sémákat… Nagy nehezen kiizzadtam magamból a lenti scriptet, ami működik is, de mivel az impdb implementációja sem sikerült teljesen ezért a végső megoldás az lett, hogy el kell dobni a teljes adatbázist, és újra kell gyártani nulláról… De ha már megírtam, akkor elmentem, hátha még jól jöhet a későbbiekben…

BEGIN
  FOR r1 IN ( SELECT 'DROP ' || object_type || ' ' || owner || '.' || object_name || DECODE ( object_type, 'TABLE', ' CASCADE CONSTRAINTS PURGE' ) AS v_sql
               FROM all_objects
               WHERE owner in ('SCHEMA1', 'SCHEMA2') AND 
                object_type IN ( 'TABLE', 'VIEW', 'PACKAGE', 'TYPE', 'PROCEDURE', 'FUNCTION', 'TRIGGER', 'SEQUENCE' ) 
                ORDER BY object_type, object_name ) LOOP 
    BEGIN 
     EXECUTE IMMEDIATE r1.v_sql; exception when others then null; 
    END; 
   END LOOP; 
  END; 
/ 

DROP USER CUSTOMER SCHEMA1 CASCADE;
DROP USER CUSTOMER SCHEMA2 CASCADE;

Indie game dev infograph

Ritkán adódik alkalom arra, hogy belelássunk egy-egy független játék készítésének költségeibe, és bevételeibe, pedig ezek elég jó támpontot nyújthatnak azoknak, akik ilyesmiben gondolkoznak. Nem is tudom mit tehetnék hozzá, beszéljenek helyettem a számok…

 

 

Svn pre-commit hook and conflict markers

Előfordul néha, hogy a nagy lelkesedésben conflict makereket tartalmazó fájlt commitolnak a fejlesztők a repository-ba. Ez nem túl gyakori hiba, de azért tud kellemetlen lenni. Keresgettem egy kicsit, de nem találtam nekem tetsző script-et, ezért írtam egyet.

 

SVNLOOK=/usr/bin/svnlook
for x in `$SVNLOOK changed "$REPOS" -t "$TXN"`; do
 if [ "$updated_file" == true ]; then
    mimetype=`$SVNLOOK propget "$REPOS" svn:mime-type -t "$TXN" "${x}" 2>/dev/null`
    #ignore binary files
    if [ -z ${mimetype} ]; then
      if $SVNLOOK cat -t "$TXN" "$REPOS" "${x}" | grep -qE '^+?(<<<<<<<|>>>>>>>)'; then
        echo "Commited conflict marker detected, commit rejected!" 1>&2 && exit 1
      fi
    fi
    updated_file=false
    continue
 else
    if [ "$x" = "U" ]; then
      updated_file=true
    fi
 fi
done
set -e

Új mame, régi frontend

A mame-t minden játéktermi gépen edződött fiatal ismeri (aki valamiért mégsem, gyorsan kezdjen ismerkedni vele :). Zseniális emulátor, de a fejlesztők a minél tökéletesebb emuláción kívül nem sok mindennel foglalkoznak (szerencsére), ezért sokan gyártottak hozzá különböző front-end-eket.

Ellenben az utóbbi időben az újabb mame verziókkal valahogy semmilyen front-end nem akart működni. Ennek az az oka, hogy a mame v.162 óta megváltozott a generált gamelist.xml fájl formátuma, aminek tartalmára a front-end-ek erősen támaszkodtak. A változás miatt az újabb mame verzió által generált xml fájlon már nem nagyon igazodnak ki.

Erre jelenthet megoldást az alábbi parancs:

</pre>
sed -e "s/machine+/game+/g" -e "s/<!ELEMENT machine/<!ELEMENT game/g" -e "s/<!ATTLIST machine/<!ATTLIST game/g" -e "s/<machine/<game/g" -e "s/<\/machine/<\/game/g" < gamelist.xml > gamelist_of.xml
<pre>

Ez az új formátumú mame gamelist.xml-t konvertálja át a régi formátumra.

A problémáról az alábbi linken írnak a Mala front-end kapcsán, de ugyanúgy érinti a Maximus Arcade felhasználókat is:

http://forum.arcadecontrols.com/index.php/topic,145865.0.html

 

 

XML fájlok szerkesztése parancssorból

Egyre több program tárolja az adatokat XML formátumban, ami kezelése nem egyszerű a hagyományos parancssori eszközökkel (grep, sed, és társai). Az XML formátum kezelésére viszont léteznek már újabb eszközök, mint például az XmlStarlet. Ez gyakorlatilag egy parancssori XML szerkesztő tool, melynek segítségével könnyedén nyerhetünk ki, vagy adhatunk, módosíthatunk adatokat az XML formátumú fájlokban.

A használata során nem árt képben lenni az XPATH fogalmával, és formátumával. Ehhez jó kiindulási alap lehet az W3Schools leírása. A munka során jó szolgálatot tehetnek még az online XPATH teszterek, generátorok.

Egy sok xml-t módosító (alap) script valahogy így néz ki a gyakorlatban:

#!/bin/sh
WORKSPACE=/cygdrive/t/work/

for x in `ls -d ${WORKSPACE}/*/`;
do
  PROJ_FILE=${x}build.xml
  if [ -f ${PROJ_FILE} ]
    then
    echo Processing build file: ${PROJ_FILE}
    xmlstarlet ed -O -P -a "/project" -t attr -n default -v "rebuild_release" ${PROJ_FILE}
  fi
done

A futtatás során a megadott könyvtár alkönyvtáraiban található build.xml fájlok tartalma az alábbi képpen módosul:

Eredeti tartalom:

<?xml version="1.0" encoding="UTF-8"?>
<project name="ac">
	<import file="../build/common.xml"/>

Tartalom a módosítás után:

<?xml version="1.0" encoding="UTF-8"?>
<project name="ac" default="rebuild_release">
	<import file="../build/common.xml"/>

A példa nem vizsgálja, hogy az XML tartalmaz e már default attribútumot, de ezt igény esetén egy újabb xmlstarlet query-vel és egy if-el könnyedén ellenőrizhetnénk. Jelen működés alapján, ha kétszer futtatnák le a fenti kódot, akkor az xml-ekben 2x kerülne beszúrásra a default tag.