Stefan Karlsson skrev för någon dag sedan om nostalgin när han nyligen kom i kontakt med Basic (http://blogs.itmaskinen.se/post/2008/09/15/Nostalgi-e28093-Back-to-Basic.aspx).

Men många produkter, till och med nyutvecklade, använder sig av basic. Ett exempel är den grafritaren som alla gymnasieelever som ska läsa matte C eller högre måste köpa, en Texas Instruments Ti 83/84 plus (http://education.ti.com/educationportal/sites/US/productDetail/us_ti83p.html). Mååånga timmar ägnade man under sin gymnasietid åt att sitta och skriva små Basic-applikationer till den som skulle hantera alla olika matematik- och fysikformler och kunna räkna ut de återkommande casen.

Ofta ser man sqler som använder sig av IN() på ett eller annat sätt. Tex:
Select Id from tblA where Id IN(Select Id from tblB)

Visst är det smidigt, det många dock inte vet är att IN() kan vara en riktig prestandaätare. Jag tänkte därför visa en alternativ lösning som ger exakt samma resultat och även presentera lite prestandaskillnader. Istället för IN() kan vi använda oss av en helt vanlig Inner Join, och istället för Not IN() så kan vi använda oss av en Left Join och sedan kontrollera ifall en post saknas eftersom vi då får Null-resultat om det inte finns någon relaterad post.

Sqlen som jag visade i början skulle alltså även kunna skrivas såhär för att ge samma resultat:
Select Distinct tblA.Id From tblA Inner Join tblB On tblA.Id = tblB.Id

Vi måste förutom att lägga till en Inner Join även lägga till en Distinct, eftersom vi bara vill ha ut en post från tblA och inte en post för varje relaterad post som finns i tblB.

Båda Sqlerna kommer alltså att plocka ut posterna från tblA där det finns en relaterad post i tblB. Skillnaden är dock prestandan.

Jag körde de båda frågorna på en mssql 2000 databas via SQL Query Analyzer för att kunna se hur lång tid den behövde för att köra frågorna. Både tabellen A och B hade ungefär 150 000 poster i sig.

Den sqlen som använde sig av IN() tog exakt 2 minuter och 19 sekunder att köra. Den sqlen som istället använde sig av en Inner Join tog 1 minut och 35 sekunder. Man kan sen lista ut att om man har stora frågor, mer komplexa, med flera IN() så kommer självklart prestandaskillnaden bli ännu större mellan dessa två sqler.

Jag vill dock poängtera att det enbart är Select i IN() som man ska undvika. Skickar man in hårda id-nummer till databasen så fungerar det utmärkt (tex: IN(1,43,24)). Det är också viktigt att det här testet inte ses som vetenskapligt på något sätt. Utan med rätt indexering, cache etc så är det möjligt att man kan få helt andra siffror.

Hittade en väldigt intressant artikel på IDG idag som handlar om vikten av att välja rätt vid systemering och utveckling i projekt, speciellt i senare teknologier som .Net. Större ramverk innebär naturligtvis fler beslut som man kan ta fel. Trenden med kompetentare ramverk gör även att utvecklarens roll mindre och mindre blir att skriva kod - istället blir våran roll som utvecklare att välja rätt lösning på rätt ställe.

Själva artikeln handlade kanske snarare om hur .Net anses splittrat när Microsoft bygger på ramverket med ny funktionalitet och låter gamla klasser etc ligga kvar för att göra det bakåtkompatibelt. Men det argumenterar ju än mer för hur viktigt det blir att utvecklaren vet hur han ska lösa problemet på bästa sätt, inte bara lösa det.

Länk till IDG: http://www.idg.se/2.1085/1.179115

Dagarna efter att webbläsaren släptes kunde man hitta ganska rikligt med artiklar om alla säkerhetshål och buggar som fanns i webbläsaren. Bland annat hål som gjorde att man kunde exakivera kod på klientens dator. Trist kan man tycka, och kanske något klantigt. Men det är fortfarande bara en beta och det är precis sådana här saker som man riskerar att utsätta sig för när man använder produkter som inte är färdiga.

Något som däremot är tråkigt är när integritetskränkande funktioner byggts in medvetet. Våra webbläsare börjar bli morgondagens trojaner. Som ett exempel har det framkommit att Google Chrome inte enbart loggar foruminläggen vi postar och adresserna vi besöker - utan allt vi skriver in. Om vi alltså börjar skriva in "www.aftonblad" och sedan ångrar oss, suddar ut och stänger ner webbläsaren så har ändå Google fått information om att vi skrivit in "www.aftonblad".

Eftersom de hela tiden skickar iväg information om vad vi skriver i realtid så kan de se var vi tänkte gå in, men ångrade oss. De kan se vilka inlägg vi påbörjar men aldrig slutför. De kan se vilka stavfel vi gör och sedan rättar till osv...

Ingen är säkert förvånad. Det går lite i Googles linje. Något som däremot verkligen gör mig förvånad är att det känns som om detta är något även andra webbläsare velat göra och att de bara legat och väntat på att någon annan ska ta den första smällen och få all kritik.

Idag publicerade nämligen IDG en artikel som avslöjar att IE8 kommer innehålla liknande funktioner...

Källa: http://www.idg.se/2.1085/1.178967

Ps. Än så länge är det enbart bevisat att Google Chrome loggar det du skriver in i addressraden i realtid utan att du postar iväg det. Att det sker även i alla andra textfält på webbsidor är min egen spekulation. Ds.
Pss. Kör du Google Chrome på Windows XP? Skriv in about:internets" i addressraden så får du ett exempel på hur dålig humor utvecklare kan ha =) Dss.

Många underskattar helt klart Access. Visst kan jag hålla med om att det är en värdelös databas om man kör applikationer med mycket samtidiga anslutningar, men det är nog en av de få bristerna den verkligen har. Mycket annat går att göra även om det inte finns grafiska gränssnitt för det.

Det är tex väldigt vanligt förekommande att folk tror att man inte kan skapa Stored Procedures i Access. Förmodligen enbart för att när de var 14, finniga, tankade musik via Napster och med hjälp av Access försökte förstå skillnaden mellan databaser och excel så stötte de aldrig på stored procedures. Strax innan man upplystes om vad stored procedures är så förkastar man Access och går över till något coolare - MySql eller MsSql. På så sätt reflekterar man aldrig över vad som verkligen saknas i Access och vad som man inte gjorde pga okunskap.

Testa själva får ni se. Skapa en enkel procedure, typ:
CREATE PROC sp_Insert (@i  INT) AS Insert into tblSP(Pr0n) Values(@i)

Och kör den:
EXECUTE sp_Insert @i=1

I access så behöver man inte använda @ framför sina variabler, men man kan och jag gör det för att det blir lite mer konsekvent och oberoende av vilken typ av databas man kör.

Källor:
http://www.aspemporium.com/tutorials.aspx?tid=4
http://www.devcity.net/Articles/18/msaccess_sp.aspx
http://www.devcity.net/Articles/34/msaccess_sp2.aspx

För några veckor sedan så hade jag turen att få träffa Magnus Fröderberg, chefredaktör för tidningen "Kamera & Bild" och en väldigt duktig frilandsfotograf (http://www.kamerabild.se/bloggar/magnus_froderberg_31.html). Med orden "Det är bara ett första utkast, inget är klart" räckte jag över min laptop till honom med min början på en sida för att enkelt och stilfullt visa upp mina bilder (http://showcase.fiskpinne.se/). Han klickar på en miniatyrbild och med ajax laddas den upp förstorad utan sidomladdning, snyggt och coolt tyckte jag. När han tittat klart på bilden och ska se nästa, så trycker han på "Back" i webbläsaren. Eftersom ingen sidomladdning skett mellan översikten och förstoringen så kommer han inte tillbaka till översikten, utan trillar istället in på den siten som var öppen i fliken innan min hemsida laddades. "Ja den verkar lite buggig" säger Magnus.

Vi utvecklare har fått en hel uppsjö med verktyg för att enkelt implementera AJAX-funktioner på våra webbplatser. Vi kan idag enkelt bygga webbapplikationer där innehållet laddas dynamiskt utifrån de val besökaren gör. Men om man bortser från de webbplatser som har utvecklare som målgrupp, så vet de flesta inte vad AJAX är eller vad det innebär. De flesta kommer, likt Magnus, att använda bakåtknappen i webbläsaren för att se innehåll som tidigare existerat på sidan men ersatts med nytt. De flesta reflekterar inte över skillnaden på när information byts ut med AJAX eller när det sker genom en sidomladdning.

Och varför ska besökarna behöva bry sig? Ska man behöva kräva att alla på webben ska kunna de tekniska begreppen? Nej att surfa ska för gemene man vara enkelt. Det ska bara funka. De senaste åren har fokus legat på att ge oss utvecklare det vi ville ha och lära oss hur vi bygger morgondagens webbsidor. Nu är morgondagen här och det är viktigt att alla surfare får de verktyg som de behöver för att kunna använda sig av funktionaliteten som vi byggt.

Jag är faktiskt förvånad över att ingen webbläsare har kommit ännu som klarar av att hantera AJAX fullt ut. AJAX-hysterin har bland oss utvecklare pågått i flera år och fortfarande står jättarna Internet Explorer, Firefox, Opera, Safari helt handfallna. När tänkte de inse att surfarna verkligen behöver webbläsare som kan backa även genom ajaxanrop, cacha ajaxdata och fullt ut kunna hantera sidor med AJAX precis som klassiska rena html-sidor? Fram tills den dagen webbläsarna kommit ikapp kommer vi inte kunna använda AJAX, i mer än en mycket begränsad skala, utan att göra våra besökare förvirrade och irriterade.

I .Net är det många som förespråkar att man använder parametrar istället för att bygga ihop sql-frågan som en sträng, likt man gjorde under ASP-tiden. Det finns många anledningar till varför det sättet förespråkas, men förmodligen är säkerhetsaspekten och översiktligheten över sql-frågorna de argumenten som man hör oftast och som väger tyngst.

Något som många däremot verkar ha missat är att man kan göra det på samma sätt även i ASP med ADODB.Command.

Se mer här: http://www.webdeveloper.com/forum/showthread.php?t=157786

Så har google kommit med sin webbläsare. Egentligen inte speciellt förvånande, ännu ett sätt att lyckas logga internetanvändarnas surfvanor för att kunna effektivisera reklam och tjänster.

Många pratar sig varm om hur enkel och smidig den är att använda och hur snabb den är. Visst, efter att installerat den så kan jag också konstatera att den är smidig och snabb. Men vilken BETA är inte det? Det känns som det något klassiska scenariot "Hej vi har skapat ett program, det har inga speciella funktioner - men visst är det snabbt!". Sen tillkommer allt lull-lull, och övertaget i uppstartstider, renderingstider för html och exakiveringstider för javascript försvinner.

Jag är inte alls förvånad över att den går snabbt idag. Installerade webbläsaren och öppnade 5 flikar; "Ny flik", "Välkommen till google Chrome", Aftonbladet.se och 2 st idg-artiklar. Öppnade aktivitetshanteraren för att se hur resurssnål den var, och blev mycket negativt överraskad.

Grattis Google. Ni har lyckats skapa en snabb webbläsare som enbart äter ca 150 - 200 mb ram och 95% CPU när den har hela 5 flikar öppna. Jag kunde varken arbeta i outlook eller firefox samtidigt, utan att de hängde sig. Av nyfikenhet kollar jag upp hur mycket min firefox 3.0.1 tar i systemresurser; 3% CPU och 319 mb ram. Men då sitter jag också med 51 flikar öppna med varierande innehåll. Personligen så märker jag dessutom ingen skillnad i hastighet mellan Firefox och Chrome.

Google Chrome har egentligen bara två saker som folk tror är nytt: Varje flik körs som en egen process så om en kraschar så kraschar inte hela webbläsaren samt en porn-mode som ser till så ingen historik, temporary files etc sparas under tiden man har den påslagen. Vi som är lite proaktiva på webbläsarfronten vet att båda dessa "nyheter" redan finns i IE8 som finns ute som BETA 2.

Så vad är egentligen nytt? Ja, designen är kanske lite annorlunda från de redan etablerade webbläsarna. Men det är nog det enda.

Tvärt om finns det goda anledningar till varför man INTE ska köra Google Chrome. Här kommer ett utdrag från licensavtalet som man godkänner när man installerar webbläsaren:

11.1 Du behåller upphovsrätten och alla andra rättigheter som du redan har för innehåll som du skickar, lägger upp eller visar på eller via tjänsterna. Genom att skicka, lägga upp eller visa innehållet beviljar du Google en evig, ouppsägbar, världsomspännande, royaltyfri och icke-exklusiv licens att reproducera, anpassa, ändra, översätta, publicera, distribuera och offentligt utföra eller visa allt innehåll som du skickar, lägger upp eller visar på eller via tjänsterna. Denna licens har det enda syftet att göra det möjligt för Google att visa, distribuera och göra reklam för tjänsterna och kan återkallas för vissa tjänster enligt definitionen i tjänsternas ytterligare villkor.

11.2 Du samtycker till att denna licens ger Google rättighet att göra sådant innehåll tillgängligt för andra företag, organisationer eller enskilda med vilka Google har relationer med syfte att tillhandahålla syndikerade tjänster, samt att använda sådant innehåll i samband med tillhandahållandet av dessa tjänster.

11.3 Du är medveten om att Google, i och med utförandet av erforderliga tekniska steg för att tillhandahålla våra användare tjänsterna, kan (a) överföra eller distribuera ditt innehåll över olika allmänna nätverk och i olika media; och (b) göra sådana ändringar av ditt innehåll som är nödvändiga för att forma och anpassa innehållet efter tekniska krav för anslutande nätverk, enheter, tjänster eller media. Du samtycker till att denna licens tillåter Google att vidta dessa åtgärder.

11.4 Du bekräftar och garanterar Google att du innehar alla de rättigheter, all den makt och befogenhet som krävs för att bevilja ovanstående licens.

Tack för den. Ni gör det ogenomförbart för alla som har någon form av anställning att kunna använda webbläsaren eftersom mina surfvanor, det jag skriver i företagets webbmail, bloggar, forum etc påstår ni ha er rätt att sprida till eventuellt konkurrerande företag. Åtminstone jag matar ogärna det totala kontrollsamhället med silversked, och google har redan gått för långt.