jQuery ”välj-alla” checkbox

Skulle implementerar en ”välj-alla” låda i jQuery och det är i sig inget märkvärdigt. Lådorna låg kategoriserade eller alla i samma tabell markerad med ett ett id som jag skickade med till funktionen tillsammans med status på lådan och om det är mäster- eller barnlådan som markeras. Funktionssignaturen blev följande toggleChecked(id, status, child).

Det intressanta var beteendet vid funktionsanrop då jag hade glömt att göra id till en sträng då en barnlåda ändrade läge. Jag noterade att onclick-händelsen anropades då jag avmarkerade mästerlådan vid händelse då den var makerad och ett barn avmarkades och detta resulterade i att alla blev avmarkerade. Det visade sig vid avlusning att avsaknaden av ”fnuttar” kring id i html-koden gjorde att hela objektet skickades med, det vill säga det liknandes vid document.getElementById(”id”). jQuery sökningen bled då något i stil med $(”#”+id) -> $(”#input[type="checkbox"]”).attr(..) (har ingen aning hur denna sökning går till, borde ju resultera i ingen träff..) och det resulterade, som sagt, i att funktionen anropades igen. Tyckte det var intressant att det inte kraschade, utan bjöd på en lite överraskning.

mySQL Workbench

Igår på jobbet stötte jag på ett problem, mer en tankeställare kanske, när jag skulle designa en tabell för att hantera regler för ett specifikt ändamål. Denna regel är (i skrivande stund) unikt bestämd av värdet i fyra databasfält och att sätta dem som primary keys (primärnyckel?) var inte aktuellt då det kunde generera en primary key sammansättning på uppemot 800 tecken och alla föremål för ändring om verksamheten ändras. Just i detta fall kan det hända ganska frekvent.

Jag använder mySQL workbench vilket är ett utmärkt verktyg för att på ett grafisk sätt hantera databaser och om antalet tabeller blir stort är det lätt att skapa sig en överblick. Fram för allt möjligheten att gå från databaskod till grafiska tabeller där restriktionerna (primary och foreign key constraints) är visualiserade beroende på dess karaktär (kan inte utveckla detta mer eftersom jag inte vet exakt vilka dessa är :).

Hur som helst i mySQL workbench hittade jag ingen vy för att skapa min lösning, att definiera en unik restriktion för flera kolumner/fält och ha en artificiellnyckel som primary key. Så jag skrev harangen i kommandoraden och löste problemet. Efter kollade jag hur min restriktion såg ut i workbench och det var inte helt intuitivt hur det skulle sättas, enligt min åsikt i alla fall.

Illustration från mySQL Workbench

Illustration från mySQL Workbench om flerkolumn unik restriktion

Jag skrev kommandot [code] ALTER TABLE x ADD UNIQUE (col1, col2, col3, col4) [/code] och detta gav som bilden ovan visar.

Index finns till för prestandaökningen vid uppslagning och flerkolumn unik restriktionen är utav datakaraktär

Tornado webserver och REST

Igår var det dags att sätta sig ner och sätta sig in i webserver Tornado som är skriven i Python. Tornado är en event-baserad, asynkron webserver som klarar av väldigt många anrop, en bit över 8000 per sekund om den är rätt konfigurerad och i en miljö som klarar av att distribuera resurserna. Den utvecklades från början av FriendFeed som senare köptes av Facebook och de vidarutvecklar den fortfarande.

Hur som helst så var det dags för mig att börja på ett skolprojekt och efter en liten stunds läsande av online-resurser och Pascals kod så hade jag fått kläm på det elementära för att skriva färdigt den back-end API med ett REST interface.

I och med detta, för att testa POST/PUT, fick jag för första gången användning av cURL vilket visade sig vara ett välidgt smidigt sätt att testa så att datan på serversidan blev ordentligt omhändertagen.

Så fort API är färdigt är det dags att implementera den del som ska genomföra klassificiering av datan via olika maskininlärningsmetoder. Här kommer NLTK-paketet väl till användningen då det håller allt möjligt inom maskininlärning: sannolikhetsalgorithmer, gömda markovmodeller, beslutsträd, kluster-algorithmer med mera. Gäller bara att hitta det som krävs, plöja igenom API och sedan testa, testa och testa – det vanligaste inom programmering (och kanske den tråkigaste delen enligt många).