Oops. :]

Even that use of syso or alert is a typical anti-pattern to print messages, most coders use them quite frequently. For example, alerts are likely to be used to pause execution of JavaScript code, for debugging.

Let’s see the most common types of forgotten debug messages:

• System.out.println()s: consider your server side code where every dev guy should maintain logs and any kind of messages in a similar fashion (levels, formatting, etc.), then somebody just do a “syso” (and you can’t answer the question why). Then he/she lefts it in and do a svn ci. Nothing bad happens, just some random laughter upon reading logs. Problem here is that the message runs out of context: there is no level, timestamp, nor classname. And hey! It’s just anything but consistent!
• console.log()s: getting closer to the fire right? These messages more likely get sneaked into field of vision if the user knows about Firebug, or Chrome’s dev console. Ehm, embarrassing. No log should be displayed in browsers because they slow down rendering DOM / processing data and they’re totally useless for users. Of course if you run your webapp in a develpoment environtment logs are king to trace where JS exceptions thrown!
• alert()s: no need to get into details here, right? They’re not even the most ugly and archaic solutions for popup messages and dialogs (which are also should be avoided wherever possible) but blocks the UI and networking totally!

So, we should preclude these situations even before they bubble up into the recent build of the system.
If you use SVN, here is an elegant and quick way to prevent codes having a subset of words being commited into your repo.

#!/usr/bin/python

import sys, os, string

SVNLOOK = '/usr/bin/svnlook'
MIN_LENGTH = 8

UNWANTED_WORDS = ['faszom', 'wasd', 'System.out.println', 'alert']

def main(repos, txn):
    log_cmd = '%s log -t "%s" "%s"' % (SVNLOOK, txn, repos)
    log_msg = os.popen(log_cmd, 'r').readline().rstrip('\n')

    diff_cmd = '%s diff -t "%s" "%s" | grep ^+' % (SVNLOOK, txn, repos)
    diff_msg = os.popen(diff_cmd, 'r').read()

    if len(log_msg) < MIN_LENGTH:
        sys.stderr.write ("Please enter a commit message which details what has changed during this commit with length more than " + str(MIN_LENGTH) + " characters.\n")
        sys.exit(1)

    match_of_unwanted_words = [diff_msg.lower().find(unwanted_word.lower()) == -1 for unwanted_word in UNWANTED_WORDS]
    if not all(x == True for x in match_of_unwanted_words):
        sys.stderr.write ("Please avoid words '" + ', '.join(UNWANTED_WORDS) + "' in source code.")
        sys.exit(1)	

    sys.exit(0)

if __name__ == '__main__':
    if len(sys.argv) < 3:
        sys.stderr.write("Usage: %s REPOS TXN\n" % (sys.argv[0]))
    else:
        main(sys.argv[1], sys.argv[2])

Place it to your [repo]/hooks directory and make sure it can be executed by the server user.
You can easily test it by changing the return value @ line 26 to a non-zero value to have an always failing pre-commit hook.

“Startup(-ok) indításának agilis szoftverfejlesztési lehetőségei” címmel egy kisebb kutatás végére teszek pontot, ahol az engem amúgy is folyamatosan izgató szakmai-”saját lábra állás”-sal kapcsolatban vonok le következtetést az eddig khárrierem :] közben tapasztaltakról, a kód művészeti szépségeiről és olyan technológiáról, melyek segítségével minimalizálható a piaci és/vagy anyagi kockázat egy-egy megvalósítani (aztán világuralomra törni szándékozó) ambícióm mögött.

Ugyanis közel sem mindegy, hogy amennyiben rendelkezünk egy bizonyítottan piacérett ötlettel, annak megvalósítása, bevezetése, skálázódása ÉS a tervezés-implementálás viszonyítási rendszerében hol fogunk majd helyet foglalni és főleg, hogy mikor.
Az sem mindegy továbbá, ha van egy gigantikus ötletünk, de elindítására minimális pénz (és főleg idő) áll rendelkezésre olyan mockup-ot tegyünk közzé, amire jó eséllyel ráharap a piac.
Nem én vagyok az első, tudom.

Hurrá.

Hogy valami értelme is legyen a posztnak, álljon itt, hogy miről is lesz szó, címszavakban:

extreme programming, lean startups, trial by error, rapid prototyping, server-side javacript, nodejs, jquery, coffeescript, handlebarsjs, zeptojs, requirejs, backbonejs, typography, minimalism, saas, cloud computing, html5, css media queries, …

That was the time when I realized that the opportunity to script Google Apps is already there since a while, so what else would I need, right?
When you look through the exceptionally nice API docs, you’ll realize that almost everything could be done through the API in Googleworld.

Basics

Apps scrpiting is available by Spreadsheets/Tools/Script manager. As far as I know this is the only way to reach this funcionality.
After we have our script a couple of run/debug interations behind its back, there are two ways to trigger it: timely, and on spreadsheet (or of course Google Forms) submit: Macro Editor/Resources/Triggers.

Now, do something useful.

Use case

szentely.org is our little slice of the world. There is only one rule: don’t break the rules! :]
It is enough to know, for now, that there are more than a dozen of bands who rehearsing regularly, relying on a schedule that should be maintained to track idle sessions when they can go out to practice. Google Calendar is just the easiest way to do this.

But! We have a rule that states that you cannot enter your rehearsal for more than eight days ahead. This is how we try to prevent unfair time-window monopoly.
So, rules should be enforced, right?

Script

function kickOutViolatingRehearsals() {
  // constants

  var CALENDAR_DAYS_LIMIT = 8;
  var NOTIFICATION_MESSAGE = "A következő bejegyzések sértik a Szentély " +
                             "'próba csak 8 napon belül lehetséges' elvét, " +
                             "ezért törlésre kerültek: \n\n";

  // target calendar to check for violations
  var bigroom = CalendarApp.getCalendarById('domain.com_WASD@group.calendar.google.com');

  var today = new Date();
  var threshold = new Date(today.getTime() + CALENDAR_DAYS_LIMIT * 24 * 60 * 60 * 1000);
  var futureInfinity = new Date(today.getTime() + 365 * 100 * 24 * 60 * 60 * 1000);

  // future rehearsals where band members should be notifiend about the violation
  var futureRehearsals = bigroom.getEvents(threshold, futureInfinity);

  if (futureRehearsals.length > 0) {
    var violations = NOTIFICATION_MESSAGE;

    for (var index = 0; index < futureRehearsals.length; index++) {
      var rehearsal = futureRehearsals[index];
      violations += " * " + rehearsal.getTitle() + " - " + rehearsal.getStartTime() + "\n";
      rehearsal.deleteEvent();
    }

    Browser.msgBox(violations);
    MailApp.sendEmail("group-to-notify@domain.com", "violation of rules", violations);
  } else {
    Browser.msgBox("No future rehearsals violating the 8 days limit.");
  }
}

Lines to note:

• line 10: you can get your calendar ID by clicking on the little arrow beside your calendar in the calendars list and choose calendar settings. It’s on the bottom of the page.
• line 29: for the sake of simplicity I’ve used a group mail address to get everybody notified about every issue. If you prefer to notify directly you can use CalendarEvent.getCreators();

And it’s only the top of the iceberg.
Happy hackin’!

For months I had to crossboot to windoze to watch a freakin’ movie because of the ancient, pitchy-patchy graphical windowing shitstem called Xorg/Compiz.

Usually what does one expect when opening a video file in the favourite videoplayer? That it just plays silklike, without LAG, GLITCHES making anybody to PUKE!
No, that would be just too easy, right?!
Googling around – of course – just worthtess: not a single technical answer you can find, everybody just scratching the surface with stupid ideas failing miserably.

Symptoms:

Playing video in SMPlayer, VLC, Totem has tiny rendering lags, just like when there isn’t enough processing power to decode the video thus you have some frames dropped. “Unfortunately” this is not the case on my system having 4 cores of Phenom II at 4.0GHz w/ Radeon HD 6850. What is it then?

Facts:

• ATI Radeon HD 6850: need to install proprietary driver to have the GPU not to cook itself (power management, you know). That means `fglrx’ with hourly crashes of course. Okay, okay, since 8.9 it’s quite stable in my experience.
• Playing video with the open source `radeon’ driver hasn’t got the symptoms above. I tried with VLC on a Ubuntu 11.10 live disc. Smooth like silk.
• Vsync: there is a known problem video vertical refresh sync in Compiz (dragging windows are sluggish, video playback lags a lot). Here are what you can do: Disable Sync to VBlank in compizconfig-settings-manager totally, in Composite plugin set the refresh rate higher and multiple of your screens refresh rate, and finally enable Tear Free Desktop and set Sync to VBlank to always.
• Strange, but if you trying playback with mplayer from the command line you’ll immediately notice a huge difference, because standalone mplayer plays smoothly at last! For me it’s working only with -vo gl and -vsync options enabled. But no matter how hard you’ll try (even with the exactly same parameters) you won’t get the devotional result with SMPlayer, nor with VLC.

Why? This question remains unanswered.
Until then I forced to stick with the command line.

Mplayer .config

1. Intro
2. Black Spiral / Fekete spirál
3. Red Rain Nightfall / Vörös eső alkonyán (a vérem áztatta földek felett)
4. Presentiment / Balsejtelem
5. Frozen Will / Fagyos akarat
6. Bloodrose / Vérrózsa
7. Untitled / Névtelen
8. Embracing a Soul / Lélekölelés – instrumental

Igen, most valóban úgy néz ki, hogy a dalok angol és magyar nyelven is fel lesznek énekelve.

Mégvalami: ha ismered a számainkat és szeretnél egy hasonló ámbár progresszívebb (matekabb), tempósabb zenét játszani és bőgős vagy gitáros vagy, keress meg minket!

The migration is easy, even without touching your currently running server. Thanks to Simon Tokumine everybody can set up the server and PostGIS based on this article in no time.

After I walked through Simon’s guidance, I easily mirrored all of my DBs by running:

pg_dumpall -p 5432 | psql -d postgres -p 5433

You have to be postgres to do this. The v9 server’s port defaults to 5433.

Of course nothing comes without an effort. In our application we use the Java classes of PostGIS to wrap geometries in our logic. Soon after the migration the first test pointed out a problem around the new bytea encoding introduced in PostgreSQL 9.
After looked through the PostGIS mailing lists I found that developers’ve already been taken care of this problem, but unfortunately it’s still persists in the latest stable version (1.5.2).

The workaround is simple: you can fallback in your v9 server to the obsolete (‘hex’) encoding for byte arrays by setting /etc/postgresql/9.0/main/postgresql.conf bytea_output to ‘hex’. If anyone knows any drawbacks falling back to hex encoding, please tell me since I could not find anything serious except performance issues when copying big amount of data.

Well, I faced those questions a couple of days ago.
First I wanted to set a time limit for each query the database runs, but I found it impossible to do in PostgreSQL, so I chose another way. I’ve implemented a Cronjob that is scheduled for run in every minute checking for stuck queries around.

In PostgreSQL there is two different kind of internal command to terminate a query:

• pg_cancel_backend is equivalent to sending SIGINT to the process while
• pg_kill_backend is equivalent to sending SIGKILL to the process

PostgreSQL uses a process per connection, so you can kill a process without much danger of affecting other connections, but pg_cancel_backend is a more graceful way to stop the naughty query.

The script below just does the job.
If someone wants to take control over queries running too long on all existing databases he should run the script from cron not as superuser but as postgres to let pg_cancel_backend to see each user’s query.

Here we go:

#!/bin/sh

# Settings
SECONDS=30
LOGFILE=/tmp/pg_activity.log

# The script must run as postgres, since only postgres user has control over every database.
if [ `whoami` != "postgres" ]; then
    exit 0;
fi

# Selecting relevant columns, getting non-idle queries only where the query runs since at least $SECONDS seconds.
psql -c "SELECT procpid, datname, usename, current_query, xact_start FROM pg_stat_activity WHERE current_query NOT LIKE '%<IDLE>%' AND current_timestamp >= xact_start + time '00:00:$SECONDS'" > $LOGFILE
NUMBER_OF_STUCK_QUERIES=`cat $LOGFILE | grep "([0-9]* row[s]*)" | sed 's/(//' | awk '{ print $1}'`

if [ $NUMBER_OF_STUCK_QUERIES != 0 ]; then
    # Getting the first column from the output discarding alfanumeric values (table elements in psql's output).
    STUCK_PIDS=`cat $LOGFILE | sed "s/([0-9]* row[s]*)//" | awk '{ print $1 }' | sed "s/[^0-9]//g"`
    for PID in $STUCK_PIDS; do
	echo -n "Cancelling PID $PID ... " >> $LOGFILE

	# "t" means the query is successfully cancelled.
	SUCCESS=`psql -c "SELECT pg_cancel_backend($PID);" | grep " t"`
	if [ $SUCCESS ]; then
	    SUCCESS="OK.";
	else
	    SUCCESS="Failed.";
	fi
	echo $SUCCESS >> $LOGFILE
    done

    cat $LOGFILE | mail -s "Stuck PLpgSQL processes detected and killed (SECONDS=$SECONDS)." <to_mail_address> -- -F "<from_name>" -f "<from_mail_address>";
fi

rm $LOGFILE

Download.

As you can see it reports every process and success of termination in email, because it’s good to know about these cases, when your system struggles to finish a query you’ve executed.

That’s all folks!

The answer lies mainly in the professional sound/audio/video engineering world, where almost everything get done on MacOS based software, therefore no one can step aside ignoring this platform and – of course – its own serial bus interface, the Firewire.

I’m sure enough to state that USB2.0 isn’t really capable to stand all the demands audio/video editing puts against it. Everybody noticed already how slow USB connected hard drives can be. That’s because theoretically USB2.0 has a maximal throughput of 480Mbps, but in the real world this number stalls at 190-200Mbps.
Contrarily benchmarks show that FireWire can push out almost the theoretical speeds (400/800MBps) from itself. Here is a neat comparison between the two serial bus standards, if you would like to get more deep knowledge on the topic.

So, where was I? Oh yes, the MOTU 828mk3. I mainly use my laptop for editing and mixing. This machine has got an ExpressCard slot. So, let’s ebay for a 1394 ExpressCard to make some noise with the new stuff. A little time later I’ve found the cheapest one, a JMicron IEEE1394a controller. “Buy it” – I said.

Days passed and the stuff finally arrived. I was swimming in happiness as long as I didn’t get home and tried to listen what quality of the MOTU main outs are. “Hey! Where is the sound?!” – I was yammering. I could see all the outs and ins, Traction played the tracks and there’s nothing! Did I become completely deaf or what?

You know why is that all, except few card costs at least $40-$50? Because the cheaper ones are not based on Texas Instruments’ chipset. Some may think that FireWire is supported in similar manner as USB. It’s not true at all.

The bottom line: get a IEEE1394 card only with TI chipset, or you’ll lose hair and what is more important: time!

Update: the exact Vendor/Device ID is: 197B / 2380. Windows Hardware ID: PCI\VEN_197B&DEV_2380&SUBSYS_2380197B&REV_00

Révén, hogy nagyközségből való vagyok, itt Szegeden kissé meg voltam illetődve, amikor első hosszabb városi bringázásomra került sor. Egyrészt azért, mert nem ismertem maradéktalanul a szabályokat (nem rendelkezem jogosítvánnyal), másrészt mert akárhonnan is próbáltam tájékozódni (fórumokból, vagy a rendőrtől magától), egymásnak teljesen ellentmondó információkkal találkoztam.

Ennek most lett vége, fogtam magam és igyekeztem egy prioritásos listát készíteni a legfontosabb dolgokról, ami a témával kapcsolatos, íme:

1. A szabályok pontos ismerete és betartása: nagy hibának tartom, hogy a közlekedésben részt lehet venni alapvető KRESZ ismeret nélkül. Gyalogosként még érthető, tekintve, hogy a járda-jelzőlámpa-zebra kombó felismeréséhez és helyes használatához általános intelligencia elégséges.
   Nade kerékpárral? Nem is megyek tovább annál a ténynél, hogy a KRESZ-ben a kerékpárra is vonatkozó szabályok vannak, így elengedhetetlen ezeknek ismerete, mielőtt valaki részt kíván venni a balesetmentes közlekedésben. Például megfontolandó lenne bevezetni a KRESZ oktatását általános iskola ötödik osztályától. Később középiskolában a hagyományos B-s jogosítvány megszerzéséhez szükséges ismereteket is érinteném, fakultatívan.
2. Korrekt infrastruktúra és jelzőtáblázás: mondják, hogy Szeged kerékpárbarát város. Nos, nem igazán tudom hová tenni ezt a kijelentést. Mondhatni, hogy az – például Budapestnél lehet, hogy barátibb, bár ott kb. 40-50x ekkora forgalom zajlik – viszont a tapasztalat nem mindig vág ezzel egybe. Tény, hogy igen sok helyre el lehet jutni kerékpárral anélkül, hogy meg kellene szakítani az utat, de legalább ennyi ellenpélda is van. Csak párat említve: a kerékpárút minden további nélkül megszakad, tábla sehol; úttesten nincsen átvezetés felfestve; a táblák szerint az úttestre kerékpárral behajtani tilos, de a járdán szintén tilos; forgalmasabb intézmények előtt közvetlen elvezetett kerékpárút; útfelbontás; bonyolultabb csomópontokban útmutatás teljes hiánya; stb.
3. Kerékpársáv szabadon hagyása: ez az egyik kedvenc pontom. Nem fér a fejembe, mi késztet gyalogosokat az elszeparált bringaúton (tehát külön járda és kerékpársáv fasorral vagy szegéllyel elválasztott úton) való közlekedésre. Még meg-megérteném, amikor csak a sárga csík választja el a közös úttestet, de a dedikált kerékpársávon mit keresnek?
   Az autósok egy másik dilemma tárgyát képezik: felparkolnak (akár naphosszakat) a sávra, mit sem törődve azzal, hogy esetleg teljes szélességében elzárják az utat ezzel.
4. Tolerancia, türelem: mindenki követ el hibákat, így alapvetőnek tartom, hogy  ne az indulat vezérelje az embereket, ha társuk késve/hibásan reagál, természetesen ha ezzel nem veszélyeztet senkit sem. Ha sikerült toleránsaknak és türelmeseknek maradnunk, van esélyünk arra, hogy felismerjük saját szokásainkban és viselkedésünkben is az esetleges hibákat, és kijavítsuk azokat.

Annak ellenére, hogy komoly kultúrális és mentalitásbeli gondokat tapasztalok, még mindig nem jelenthetem ki, hogy az autósok a bunkók. Nem lehet általánosítani. A hibásak nem az autósok, a kerékpárosok vagy a gyalogosok, hanem az egyén!

Ezzel összhangban szerencsére javulást tapasztalok, gyakran pont az autósoktól: elengednek, még ott is ahol én követek el hibát, türelmesek és jórészt betartják a szabályokat. Persze, kivételek mindig vannak és lesznek is, de a tendencia javuló.

Néhány cikk a Rendőrség honlapjáról:

• A kerékpárosok biztonságáért! (Debreceni Rk.)
• Kerékpár-tartozékok és -védelem
• Január 1-étől hatályos módosítások #1 és #2

Érdemes még ellátogatni a Magyar Kerékpáros Klub lapjára is.

Update: egyátalán nem értem ennek a szabálynak a létjogosultságát. A tapasztalat pont az ellenkezőjét diktálná. Csak számomra tűnik fel jobban egy villogó kerékpáros, mint az, aki folyamatosan világít?