SXC - flaivoloka

Top 25 kodefejl du ikke skal lave

Via MITRE - , redigeret af Net_Srak , indsendt af arne_v

Er man programmør, så ved man, at det er uundgåeligt, at der engang imellem også sniger sig en fejl eller to med i det, man laver. Nogle fejl er dog værre at lave end andre.

Hos CWE (Common Weakness Enumeration) har man kigget på, hvilke fejl man helst skal undgå, og har samlet dem på en top 25-liste.

Generelt for flere af fejlene på listen gælder det, at de kan udnyttes af uvedkommende til at opnå adgang til ting, der ikke var meningen, og at det er forholdsvis nemt at udnytte fejlene.

Selv betegner CWE listen som et værktøj, udviklere kan bruge til at undgå de mest kritiske fejl og derved sikre bedre kode. Den er udarbejdet sammen med SANS Institute, MITRE og en lang række sikkerhedsvirksomheder i USA og Europa.

Følg linket til kilden for at se hele listen.





Gå til bund
Gravatar

#1 Daniel-Dane 21. feb. 2010 18:22

* SQL Injection blandt top 3 *

EDIT:
Jeps. Det havde jeg ikke regnet med!
You are in control of your breathing, your arms have weight, you are controlling your blinking, and you can feel your tongue in your mouth.
Gravatar

#2 ghostface 21. feb. 2010 19:25

#1 der er da forhåbentlig heller ingen der idag laver almindelige SQL queries. De fleste seriøse projekter benytter vel Stored Procedures eller Prepared Statements som netop ikke har den svaghed.

I have ascended to a higher plane of sarcasm. Please send all Complaints to: /dev/null Have a Nice day
Gravatar

#3 krainert 21. feb. 2010 19:31

#2
Nu er jeg ikke professionel web-koder, men der er vel intet i vejen med anvendelsen af queries direkte, så længe brugerens input først gennemtjekkes og kritiske karakterer escapes - eller hvad?
I hvert fald interessant liste!
Gravatar

#4 Windcape 21. feb. 2010 19:40

#2

Stored Procedures er heldigvis ved at dø still ud. Og tak for det, så slipper man for at have en DBA ansat. ORM er en meget bedre løsning.

#3

Jo, det er meget i vejen. Fordi du risikere for nemt at lave et forkert check, eller glemme at lave et check.

Man kan ligeså godt bruge (prepared) statements, da de typisk mapper til direkte din SQL Driver, så du er helt sikker på at dataen bliver valideret korrekt (type mæssigt, du skal stadigvæk sanitisere dine string inputs!).


http://about.me/windcape
Gravatar

#5 Windcape 21. feb. 2010 19:41

Personligt synes jeg det er interassant hvor højt buffer overflow scorer.

Men så kan man også lære at man ikke skal bruge C/C++ medmindre det er absolut nødvendigt!
http://about.me/windcape
Gravatar

#6 arne_v 21. feb. 2010 19:41

#2

Alle bør bruge prepared statements (som i MS verden er kendt som parameters).

Men bemærk at stored procedures i teorien godt kan kaldes uden brug af parameters og dermed være sårbare overfor SQL injection. Det ses stort set aldrig i praksis, men det kan altså lade sig gøre.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#7 c03 21. feb. 2010 19:42

#5
ja.. eller lære at programmere? selvfølgelig kan man lave fejl, men jeg stopper jo ik med at køre bil fordi der er andre der kører galt =)
Gravatar

#8 arne_v 21. feb. 2010 19:42

krainert (3) skrev:
men der er vel intet i vejen med anvendelsen af queries direkte, så længe brugerens input først gennemtjekkes og kritiske karakterer escapes - eller hvad?


Prepared statement / parameters er bedre end diverse eksplicit escaping.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#9 ghostface 21. feb. 2010 19:43

Nu bruges databaser til meget andet end websites og skal altid sikres imod injection uanset om det så er en person og hans egen applikation (xkcd har en berømt strip netop omkring dette: http://xkcd.com/327/)
Og jo du kan godt bruge diverse features (php har sin "real escape string") men hvorfor bruge diverse funktioner/metoder der fjerner eller escaper problematiske tegn når alle gængse databaser understøtter en form for prepared statement?
Ud over at beskytte din database ultimativt (ved fx. kun at give adgang til at eksekvere Stored Procedures og ikke selv lave queries) så betyder det også at alle apps og websites der bruger en given procedure vil blive opdateret når den ændres på databasen.

#4 Vi har aldrig brugt stored procedures så meget som vi gør nu i den virksomehd jeg arbejder i. Det spatiale SQLServer 2008 understøtter finder man bare ingen andre steder. Enhver virksomhed som arbejder med geografiske eller geometiske data vil langt hellere ligge det ansvar på databasen end hente unødigt store (for de kan virkelig blive store) data op og behandle dem i applikationen.

Noget så simpelt som at finde ud af om et punkt ligger i et multipolygon er noget der langt mere effektivt håndteres på databasen.
I have ascended to a higher plane of sarcasm. Please send all Complaints to: /dev/null Have a Nice day
Gravatar

#10 arne_v 21. feb. 2010 19:44

Windcape (4) skrev:
Stored Procedures er heldigvis ved at dø still ud. Og tak for det, så slipper man for at have en DBA ansat. ORM er en meget bedre løsning.


SP'ere er ikke ved at uddø.

ORM er godt men ikke til alle formål.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 Windcape 21. feb. 2010 19:44

arne_v (6) skrev:
Men bemærk at stored procedures i teorien godt kan kaldes uden brug af parameters og dermed være sårbare overfor SQL injection.
Afhænger det ikke af databasen? Jeg kender ikke nogen måde at definere Stored Procedures i MS SQL uden at angive type.

c03 (7) skrev:
#5
ja.. eller lære at programmere? selvfølgelig kan man lave fejl, men jeg stopper jo ik med at køre bil fordi der er andre der kører galt =)
Der er jo en grund til at man laver f.eks. servostyring til biler, selvom folk bare kunne lære at kører bedre.

Nyere managed sprog med typecheck, overflow checks, exceptions etc. er måske langsommere til den promille af programmer som kræver superhøj hastighed (som f.eks. spil), men til det meste software, så er det bedre at bruge sprog som Java/C#, fordi at man sikre sig imod visse ting.
http://about.me/windcape
Gravatar

#12 Windcape 21. feb. 2010 19:46

arne_v (10) skrev:
SP'ere er ikke ved at uddø.
I webapplications er de ihvertfald ved at udgøre en forsvindende mængde i nyere projekter (legacy software tæller ikke!)

arne_v (10) skrev:
ORM er godt men ikke til alle formål.
Rigtigt nok, men often har jeg set folk har brugt f.eks. Stored Procedures, hvor ORM havde været mere en optimal løsning.

Målet var i begge tilfælde at fjerne direkte SQL kald fra ens kode / business logic.
http://about.me/windcape
Gravatar

#13 arne_v 21. feb. 2010 19:47

#5

Der er også andre sprog end C/C++ som ikke checker array index bl.a. Fortran.

Men C står bag en meget stor del af de buffer overflow der er fundet.

Problemet er ikke nært stå stort i C++ forudsat at der kodes rigtig C++ og ikke C med erklæringer midt i koden og // kommentarer. STL string, STL vector, undgå pointere etc. har altså en effekt.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#14 Windcape 21. feb. 2010 19:53

ghostface (9) skrev:
Ud over at beskytte din database ultimativt (ved fx. kun at give adgang til at eksekvere Stored Procedures og ikke selv lave queries) så betyder det også at alle apps og websites der bruger en given procedure vil blive opdateret når den ændres på databasen
Problemet med dette har jo så været at faktisk få lavet den ændring.

Kode kan ændres og testes i et test miljø, hvor databasen typisk kun findes i et produktionsmiljø, og derfor skal ændres i real-time.

Hvis man har muligheden for at lukke ned om natten og lave ændringer, er det nok ikke et så stort problem. Men der er altså mange systemer i dag hvor du ikke har den mulighed!

Så hvis performance ikke er ens vigtigste prioritet, så vil jeg nok undgå Stored Procedures, og abstrahere SQL delen væk i min kode, og fokusere mere på input validering og meningsfulde fejlbeskeder til brugeren.
http://about.me/windcape
Gravatar

#15 Windcape 21. feb. 2010 19:56

Jeg har lyst til at tilføje nr. 26

#26 - Don't hire offshore contractors in India/Philippines to write your input validation.
http://about.me/windcape
Gravatar

#16 GrillBiller 21. feb. 2010 20:01

hvad er der nu galt med goto?

:D
Gravatar

#17 arne_v 21. feb. 2010 20:03

Windcape (11) skrev:
Afhænger det ikke af databasen? Jeg kender ikke nogen måde at definere Stored Procedures i MS SQL uden at angive type.


Du undervurderer hvad der kan laves med en SP.

Demo:


using System;
using System.Data;
using System.Data.SqlClient;

namespace E
{
public class Program
{
public static void Test(string par)
{
using(SqlConnection con = new SqlConnection(@"Server=ARNEPC3\SQLEXPRESS;Integrated Security=SSPI;Database=Test"))
{
con.Open();
SqlCommand q = new SqlCommand("SP_TABLES " + par, con);
SqlDataReader rdr = q.ExecuteReader();
while(rdr.Read())
{
Console.WriteLine(rdr[0] + "." + rdr[1] + "." + rdr[2]);
}
}
}
public static void Main(string[] args)
{
// lidt setup
using(SqlConnection con = new SqlConnection(@"Server=ARNEPC3\SQLEXPRESS;Integrated Security=SSPI;Database=Test"))
{
con.Open();
SqlCommand cre = new SqlCommand("CREATE TABLE supervigtig (id INTEGER IDENTITY PRIMARY KEY, txt VARCHAR(50))", con);
cre.ExecuteNonQuery();
}
// lidt sjov
Console.WriteLine("As intended:");
Test("NULL, DBO");
Console.WriteLine("SQL injection:");
Test("NULL, DBO; DROP TABLE supervigtig");
Console.WriteLine("Verification:");
Test("NULL, DBO");
Console.ReadKey();
}
}
}


Det er et SP kald - og der er SQL injection. Med SQLServer.

Nej - det er ikke pæn kode, men ....
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#18 arne_v 21. feb. 2010 20:06

Windcape (11) skrev:
Nyere managed sprog med typecheck, overflow checks, exceptions etc. er måske langsommere til den promille af programmer som kræver superhøj hastighed (som f.eks. spil), men til det meste software, så er det bedre at bruge sprog som Java/C#, fordi at man sikre sig imod visse ting.


Der er vel kun 4 ud af 25 (3, 12, 14 og 18) som relaterer sig specielt til ikke checkende sprog som C.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#19 arne_v 21. feb. 2010 20:11

Windcape (12) skrev:
I webapplications er de ihvertfald ved at udgøre en forsvindende mængde i nyere projekter (legacy software tæller ikke!)


Det er jeg ikke så sikker på.

SP'ere har aldrig været populære i DB2, MySQL etc. verdenen.

Men i MS SQLServer, Oracle etc. verdenen er de stadigt vidt udbredte.

Muligvis mere i de lidt komplekse løsninger. Men for store Oracle databaser er det mere reglen end undtagelsen at finde 2000 PL/SQL SP'ere + 1000 Java SP'ere.

Windcape (12) skrev:
Rigtigt nok, men often har jeg set folk har brugt f.eks. Stored Procedures, hvor ORM havde været mere en optimal løsning.

Målet var i begge tilfælde at fjerne direkte SQL kald fra ens kode / business logic.


Hvis det er eneste formål, så er det et rigtigt dårligt argument.

Men der er mange andre argumenter:
- sikkerhed
- support af multiple applikationer i forskellige teknologier



The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#20 arne_v 21. feb. 2010 20:14

#19

Bemærk iøvrigt at brug af ORM *ikke* udelukker brug af SP'ere.

Den kendte .NET ORM LLBLGen genererer selv SP'ere og tillader brug af eksisterende SP'ere.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#21 arne_v 21. feb. 2010 20:16

Windcape (14) skrev:
Problemet med dette har jo så været at faktisk få lavet den ændring.

Kode kan ændres og testes i et test miljø, hvor databasen typisk kun findes i et produktionsmiljø, og derfor skal ændres i real-time.

Hvis man har muligheden for at lukke ned om natten og lave ændringer, er det nok ikke et så stort problem. Men der er altså mange systemer i dag hvor du ikke har den mulighed!


Der bør også være en full size database i test.

Et dump fra production, et dump fra production med sensitive data x'et ud eller rene kunstige data.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#22 KS 21. feb. 2010 20:44

intet nyt på den liste....de samme ting som har været på listen de sidste 15år......alle kan mere eller mindre koges ned til "ringe input validering"
Gravatar

#23 mgX 21. feb. 2010 20:54

lock(this);

Gravatar

#24 myplacedk 21. feb. 2010 21:10

Windcape (14) skrev:
Kode kan ændres og testes i et test miljø, hvor databasen typisk kun findes i et produktionsmiljø, og derfor skal ændres i real-time.

Er det noget du kan dokumentere, eller snakker du om de projekter du selv deltager i?

De der "halve" testmiljøer (hvor man bruger produktions-databasen) har jeg kun set hos amatører, som prøver at finde ud af hvad et testmiljø er, og stadig er langt fra målet.
Gider du lige sætte navn på bagsiden af mit Möbius pandebånd?
Gravatar

#25 røvskæg 21. feb. 2010 22:32

Er der backup på newz ?'; DROP TABLE forum;
Gravatar

#26 FeedMe 21. feb. 2010 22:44

"Er man programmør, så ved man at det er uundgåeligt, at der en gang i mellem også sniger sig en fejl eller to med i det man laver. Nogle fejl er dog værre at lave end andre."

Jeg er åbenbart programmør.....
Gravatar

#27 arne_v 21. feb. 2010 23:05

mgX (23) skrev:
lock(this);


??
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#28 arne_v 22. feb. 2010 00:10

KS (22) skrev:
intet nyt på den liste....de samme ting som har været på listen de sidste 15år......


Jo. Men man har jo ikke fundet en løsning på problemet i løbet af de 15 år.

Problemet er ikke at gøre det rigtigt en gang.

Problemet er at gøre det rigtigt 100000 ud af 100000 gange fremfor de sædvanelige 99995-99999 ud af 100000 gange.

Og med:
- en flok udviklere af blandet kvalitet
- udviklere som har både gode og dårlige dage
- lidt stress og sidste øjebliks panik i projekter
så er det en ikke-triviel opgave at løse.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#29 Windcape 22. feb. 2010 00:48

myplacedk (24) skrev:
De der "halve" testmiljøer (hvor man bruger produktions-databasen) har jeg kun set hos amatører, som prøver at finde ud af hvad et testmiljø er, og stadig er langt fra målet.
Men deri ligger problemet.

Jeg kender rigtige mange udviklere hvor netop databasen ikke har et test miljø for sig selv.

"amatører" er vist et begreb som kan dække over alle virksomheder der ikke laver mission critical systemer (som f.eks. Bankerne).

http://about.me/windcape
Gravatar

#30 Windcape 22. feb. 2010 00:49

røvskæg (25) skrev:
Er der backup på newz ?'; DROP TABLE forum;
Du glemte -- (der ud-kommentere resten af koden, ellers for du syntaxfejl.)
http://about.me/windcape
Gravatar

#31 arne_v 22. feb. 2010 01:25

Windcape (29) skrev:
"amatører" er vist et begreb som kan dække over alle virksomheder der ikke laver mission critical systemer (som f.eks. Bankerne).


Det bruges et stykke under bank niveauet.

Jeg vil tro at de fleste bare lidt større administrative systemer.

Et administrativt system til at holde styr på firmaets kuglepenne med en Oracle database nederst og en 25-50 brugere vil typisk have det.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#32 Windcape 22. feb. 2010 01:42

arne_v (31) skrev:
Jeg vil tro at de fleste bare lidt større administrative systemer.
Det kan godt passe.

Jeg tror måske det afhænger mere af hvad slags services / produkter de enkelte firmaer/afdelinger arbejder på.

Umiddelbart har jeg dog mødt flere udviklere hvor test ikke er normal procedure, end jeg har mødt dem hvor det er standard.
http://about.me/windcape
Gravatar

#33 arne_v 22. feb. 2010 02:00

#skummel database brug

Når vi nu er igang, så er der en anden lille finesse.

Jeg vil illustrere med Java kode - men problem stilling findes i alle teknologier.

Først forsøger udviklerne med:


Statement stmt = con.createStatement();
stmt.executeUpdate("INSERT INTO t VALUES('" + s1 + "','" + s2 + "')");


Men nu søger tech lead'en i kode efter " Statement", ".createStatement", ".executeUpdate(""" etc. og finder den og udsteder et direktiv der skal bruges PreparedStatement.

Nu forventer tech lead'en at de gør det rigtigt:


PreparedStatement pstmt = con.prepareStatement("INSERT INTO t VALUES(?,?)");
pstmt.setString(1, s1);
pstmt.setString(2, s2);
pstmt.executeUpdate();


Men i.s.f. at gøre det rigtigt laver udviklerne:


PreparedStatement pstmt = con.prepareStatement("INSERT INTO t VALUES('" + s1 + "','" + s2 + "')");
pstmt.executeUpdate();


Bande svovle eder og forbandelser !!

Prepared statement beskytter kun hvis alle værdier sættes rigtigt.

Og man er stort set nødt til at se hele koden igennem for at finde den slags.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#34 arne_v 22. feb. 2010 02:03

#33

Undtagen hvis man bruger H2 databasen. Den kan nemlig et ekstra lille trick.

Tilføj ";ALLOW_LITERALS=NONE" til connection URL og så vil alle forsøg på brug af værdier i selve SQL strengen fejl. Statement eller PreparedStatement er ligegyldigt.

En feature som andre databaser godt kunne tage til sig !!

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#35 Windcape 22. feb. 2010 02:28

#33

Er der virkelig udviklere som hader prepared statements så meget at de ikke vil gøre det rigtigt?
http://about.me/windcape
Gravatar

#36 myplacedk 22. feb. 2010 05:26

Windcape (32) skrev:
Umiddelbart har jeg dog mødt flere udviklere hvor test ikke er normal procedure, end jeg har mødt dem hvor det er standard.

Nogle gange er det næsten som om vi lever i hvert vores paralelle univers, som rører hinanden på newz.dk. ;-)

Jeg kan ikke mindes faktisk at have mødt en udvikler*, som ikke synes det er naturligt at teste inden man sætter det i produktion.

*) Glade amatører undtaget. Bare fordi man kan kastet lidt sand, cement, grus og vand i en trillebør, er man jo ikke murer.
Gider du lige sætte navn på bagsiden af mit Möbius pandebånd?
Gravatar

#37 myplacedk 22. feb. 2010 05:28

Windcape (35) skrev:
Er der virkelig udviklere som hader prepared statements så meget at de ikke vil gøre det rigtigt?

Der er masser af udviklere som kun forventer at de skal overholde det de får at vide, og ikke intentionen af det. I eksemplet får han at vide at han skal bruge prepared statements, og det gør han så. Løsningen er den som kræver mindst viden og arbejdsindsats.

Den slags ser jeg ofte hos pressede udviklere. Og det er pokkers svært at rydde op i.
Gider du lige sætte navn på bagsiden af mit Möbius pandebånd?
Gravatar

#38 Windcape 22. feb. 2010 05:32

myplacedk (36) skrev:
Jeg kan ikke mindes faktisk at have mødt en udvikler*, som ikke synes det er naturligt at teste inden man sætter det i produktion.
Du er vist heller ikke typen som snakker med andre udviklere på irc og forums hele natten lang, men i stedet sover og går på arbejde hvor du snakker med dine kollegaer ;-)

(og ja, folk på IRC har også jobs, så det er ikke tilfældige amatører som snakker om deres hobbyprojekter).
http://about.me/windcape
Gravatar

#39 Windcape 22. feb. 2010 05:41

Og hvis vi skal have "real life" erfaringer, kunne vi jo tage min årgang som pt. skriver speciale. Mange af de virksomheder folk arbejder hos har ringe/ingen test procedurer.

Det afhænger af teknologien, specielt i afdelinger der arbejder med web er test et ukendt begreb, hvor det er mere standardiseret andre steder i form af unit tests.

Men fra unit tests, til et rigtigt test miljø, build server, og nightly builds, der er lang vej, og det er langt fra alle virksomheder som gør i det (min erfaring er det modsatte).

Følgende checkliste burde implementeres http://www.codinghorror.com/blog/2006/04/are-you-f...
http://about.me/windcape
Gravatar

#40 coday 22. feb. 2010 07:10

Er jeg den eneste der lader som om at man fortår det hele der bliver skrevet her inde men faktisk ikke aner en skid ?? :P
Gravatar

#41 myplacedk 22. feb. 2010 08:15

Windcape (38) skrev:
Du er vist heller ikke typen som snakker med andre udviklere på irc og forums hele natten lang

Njah, det er nu mere IM.

Windcape (38) skrev:
(og ja, folk på IRC har også jobs, så det er ikke tilfældige amatører som snakker om deres hobbyprojekter).

Jojo. Men hvis de spørger om hjælp på IRC, så er projektet nok ikke så pokkers meget over hobbyniveau. Normalt ville man vel spørge en kollega. ;-)

Windcape (39) skrev:
Mange af de virksomheder folk arbejder hos har ringe/ingen test procedurer.

Så er jeg overrasket. Det lyder overhovedet ikke som de virksomheder jeg har kendskab til. Og det unkluderer altså også webudviklere. Og for den sags skyld mit eget énmands "hobbyfirma" fra før jeg overhovedet var uddannet.

Windcape (39) skrev:
Men fra unit tests, til et rigtigt test miljø, build server, og nightly builds, der er lang vej

Jojo, der er mange niveauer i at lave test-miljøer og build-procedurer, og jeg vil absolut ikke påstå at alle har samme behov. Men et komplet test-miljø og automatiseret build vil være en god investering for langt de fleste.
Gider du lige sætte navn på bagsiden af mit Möbius pandebånd?
Gravatar

#42 Zagadka 22. feb. 2010 08:34

Som det påpeges en del gange ovenfor så har du seriøse problemer i forhold til at skulle lave al escaping selv for det er helt utroligt så opfindsomme som brugere kan være når det drejer sig om at lave dumme ting.

Desværre kan der være performance problemer med at bruge prepared statements til alt, for at klargøre et sådant og derefter eksekvere det kan nemt tage længere tid at bruge et query direkte.

Generelt anbefaler jeg brug af prepared statements i tilfælde af brugerinput og direkte queries kan overvejes når brugerinput ikke er involveret.

Som en service til dem der bruger Java kan tilføjes at et PreparedStatement objekt skal lukkes med close() metoden ellers får du en memory leak af dimensioner. Min gamle kode havde en leak på 1 GB/uge.
Gravatar

#43 Windcape 22. feb. 2010 08:43

myplacedk (41) skrev:
Jojo. Men hvis de spørger om hjælp på IRC, så er projektet nok ikke så pokkers meget over hobbyniveau. Normalt ville man vel spørge en kollega. ;-)
Du vil blive overrasket ;-)

IRC er ikke så anderledes fra StackOverflow
http://about.me/windcape
Gravatar

#44 decx 22. feb. 2010 14:36

Det skræmmende ved StackOverflow er faktisk at en masse dumme spørgsmål ser ud til at blive lavet af folk der har ansvaret for en DB, kode, projekt i en eller anden virksomhed. Men sådanne ting giver os jo DailyWTF, not all bad.
Gravatar

#45 arne_v 22. feb. 2010 16:21

Windcape (35) skrev:
Er der virkelig udviklere som hader prepared statements så meget at de ikke vil gøre det rigtigt?


Kik rundt i din klasse.

Udvælg den 1/4 som er ringest til programmering.

Hvis det er gode tider i IT branchen, så får de allesammen job i IT branchen.

Forestil dig et del projekt som 3 af dem bliver sat til at lave alene.

Svar nok?

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#46 arne_v 22. feb. 2010 16:29

Windcape (39) skrev:

Og hvis vi skal have "real life" erfaringer, kunne vi jo tage min årgang som pt. skriver speciale. Mange af de virksomheder folk arbejder hos har ringe/ingen test procedurer.

Det afhænger af teknologien, specielt i afdelinger der arbejder med web er test et ukendt begreb, hvor det er mere standardiseret andre steder i form af unit tests.

Men fra unit tests, til et rigtigt test miljø, build server, og nightly builds, der er lang vej, og det er langt fra alle virksomheder som gør i det (min erfaring er det modsatte).


Der er masser af tools til at teste web også.

Jeg vil tro at de fleste større IT organisationer tester.

Men for den lille IT organisation <10 mand er det nok et noget mere broget billede.

Windcape (39) skrev:

Følgende checkliste burde implementeres http://www.codinghorror.com/blog/2006/04/are-you-f...


Jeg er absolut ikke imponeret af den Joe Spolsky liste.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#47 arne_v 22. feb. 2010 16:41

Zagadka (42) skrev:
Desværre kan der være performance problemer med at bruge prepared statements til alt, for at klargøre et sådant og derefter eksekvere det kan nemt tage længere tid at bruge et query direkte.


Hvis den samme query skal udføres mange gange, så vil PreparedStatement ofte være hurtigere!

Zagadka (42) skrev:
Som en service til dem der bruger Java kan tilføjes at et PreparedStatement objekt skal lukkes med close() metoden ellers får du en memory leak af dimensioner. Min gamle kode havde en leak på 1 GB/uge.


Det er en fejl i JDBC driveren.

JDBC specs er helt klar:


An application calls the method Connection.close to indicate that it has finished
using a connection. All Statement objects created from a given Connection object
will be closed when the close method for the object is called.



All Statement objects will be closed when the connection
that created them is closed.



These comments about closing Statement objects apply to PreparedStatement
and CallableStatement objects as well.


Men det er en god ide altid at kalde close eksplicit altid.

Fordi:
1) det skader aldrig
2) det hjælper ved fejl i driver implementeringen
3) det hjælper også ved at release resourcer tidligere hvis connection ikke closes umiddelbart efter af man er færdig med statement

Citat far spec igen:


However, it is good coding practice for applications to
close statements as soon as they have finished processing them. This allows any
external resources that the statement is using to be released immediately.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login