[Clarence]

Ursprungligen postat av ConnyWesth

Med "färdigtestade komponenter" menar jag komponenter som man själv har utvecklat och "paketerat" till "färdigtestade komponenter". Exempel på såna kan vara DLL-filer men finns även andra varianter, men absolut vanligast är DLLer i Windows världen.

Källkod som du kopierar från ett projekt till ett annat är inte att betrakta som "återanvändning" av färdigtestade komponenter, eftersom du då öppnar upp risken att någon (du själv inräknat) går in och gör ändringar i en källkodsfil men inte i de andra 150....

Källkoden är fortfarande hur öppen man vill att den ska vara, "open source" har inget motsatsförhållande till begreppet "färdigtestade komponenter".

Du kan aldrig vara 100% säker mot misstag. Har du kompilerad komponent så är du inte helt säker på om personen som skapade den verkligen inte gjorde några bakåtinkompatibla ändringar trots att de endast ändrade patch version när de gjorde sin buggfix.

Med en bra arbetsstruktur har du dina bibliotek i VCS. Du har versionering av dina bibliotek. Du uttrycker explicit vilken major + minor du vill ha och uppgraderar bara patch. Externt inladdade bibliotek ligger separat och vill man göra en ändring i dom vet man att man gör ändringarna i bibliotekets källa och uppgraderar sin version utefter vad man gjort. Liksom med kompilerade komponenter går detta åt helvete om någon gör något helt galet. Att göra någon ändring i biblioteken i sitt egna projekt är precis lika dumt som att göra en ändring i en kompilerad komponents källkod för att sedan bara kompilera om och inkludera med samma version i sitt projekt.

Ursprungligen postat av ConnyWesth

Python verkar väldigt känsligt för kolumnpositioner på källkodsraderna, det är som att gå tillbaks till Cobol, som också var extremt känsligt för källkodens kolumnpositioner.

Python tillbaks till Cobol. Hoppas du inte på allvar menar att språken är jämförbara på annat sätt än så väldigt ytliga sätt som det du tog upp. Tittar du på hur Python faktiskt används så får du fram lite av dess goda egenskaper direkt, men eftersom du inte kan göra det för PHP så kanske det är svårt även med Python.

[Conny Westh]

Ursprungligen postat av Clarence

Du kan aldrig vara 100% säker mot misstag. Har du kompilerad komponent så är du inte helt säker på om personen som skapade den verkligen inte gjorde några bakåtinkompatibla ändringar trots att de endast ändrade patch version när de gjorde sin buggfix.

Med en bra arbetsstruktur har du dina bibliotek i VCS. Du har versionering av dina bibliotek. Du uttrycker explicit vilken major + minor du vill ha och uppgraderar bara patch. Externt inladdade bibliotek ligger separat och vill man göra en ändring i dom vet man att man gör ändringarna i bibliotekets källa och uppgraderar sin version utefter vad man gjort. Liksom med kompilerade komponenter går detta åt helvete om någon gör något helt galet. Att göra någon ändring i biblioteken i sitt egna projekt är precis lika dumt som att göra en ändring i en kompilerad komponents källkod för att sedan bara kompilera om och inkludera med samma version i sitt projekt.

Jag tänker mest på hur det funkar på de stora företag jag jobbat, både som anställd och konsult (mest försäkringsbolag, banker offentliga myndigheter och konsultbolag som gör uppdrag hos dessa), då har man omfattande kvalitetstester där man efter vissa bestämda tidpunkter "låser" alla kodändringar och går in i en testprocess inför varje release, vi pratar inte om utvecklarnas tester här utan om beställarens acceptanstester och produktionstester. Då får ingen gå in i den levererade koden och göra ändringar under testfasen.

Givetvis pågår arbetet i den övriga utvecklingen, men man har en uppsättning binärfiler som ska med i n viss release som inte får ändras.

Du får tänka på att det är många personer involverade (både utvecklare, kravställare, produktionstekniker, supportpersonal m.m.) alla måste vara synkroniserade på samma kodbas. Om något ändras så måste hela testet göras om från början. Därför vill man ha järnkoll på detta.

Ursprungligen postat av Clarence

Python tillbaks till Cobol. Hoppas du inte på allvar menar att språken är jämförbara på annat sätt än så väldigt ytliga sätt som det du tog upp. Tittar du på hur Python faktiskt används så får du fram lite av dess goda egenskaper direkt, men eftersom du inte kan göra det för PHP så kanske det är svårt även med Python.

Jag håller just nu i min utvärdering på att växla mellan PHP, Python, Ruby, (kommer nog Scala och Erlang också) och jag blev smått irritaterad på att Python hade den fula egenskapen att vara känslig för källkodens kolumnpositioner, det är ingen positiv egenskap tycker jag. Det tog en stund innan jag fattade vad som var fel dessutom ....

Python är ju trots allt betydligt trevligare än PHP och Ruby betydligt trevligare än Python. Även om Python och Ruby i övrigt har snarlik syntax.

Jag upptäckte dock att Python har ändrat Syntax så man måste sätta ut paranteser på print(), i alla exempel jag hittar på internet så har man INTE parenteser så i stort sett ingen exempelkod funkar utan handpåläggning.

Nåväl jag ska inte klaga så mycket på Python för jag håller på att testa språket.

Jag har laddat ner Open Cobol (som stöder både Cobol 85 och Cobol 2002, men tyvärr har jag ingen körbar version i Windows-miljön (man måste sätta upp och kompilera med MinGW eller GCC och det har jag inte orkat, det är en massa inställningar man ska göra innan man kan kompilera och just nu orkar jag inte med det). Jag har kör den binära i Ubuntu och det funkade ju klockrent.

Det finns en gigantisk kodbas med installerad Cobolkod som är i produktion, främst inom stora företag som Banker, försäkringsbolag, myndigheter, stora börsnoterade industriföretag. Dessa proggram rullar på i sina dagliga batchar och har så gjort sedan slutet av 1950-talet/början av 1960-talet när de första Cobol-liknande dialekterna dök upp (tror Cobol blev officiellt 1963...). Det kommer ta tusentals/kanske miljontals manår att ersätta den kodbasen... Så de byts ut modul för modul och inte förrän det inte går att köra vidare.

Det funkade enkelt att länka ihop en vanlig ANSI C modul i Open Cobol.

Jag hittade en bra Tutorial för Python som jag gått igenom och testkört alla exempel. Jag fick bra koll på hur syntaxen är uppbyggd. Enkel filhantering, felhanering m.m. Har inte testat Databasacess med Python ännu.

Ruby känns betydligt större (ur teknisk synvinkel) och mer välgjort än både PHP och Python, mycket mer väl genomtänkt objekthantering. Känns som Ruby har betydligt bättre inkasling, arvsmekanismer m.m. Verkar mer okänslig för kolumnspositioner.

Har dock inte fått require("namespace") att funka, men Load("filename") funkade bra.

Hittade en riktigt bra webbplats ruby-doc.org som har gigantiskt med exempelkod, som jag håller på att traggla mig igenom.

[lunarmys]

Ursprungligen postat av ConnyWesth

Jag håller just nu i min utvärdering på att växla mellan PHP, Python, Ruby, (kommer nog Scala och Erlang också) och jag blev smått irritaterad på att Python hade den fula egenskapen att vara känslig för källkodens kolumnpositioner, det är ingen positiv egenskap tycker jag. Det tog en stund innan jag fattade vad som var fel dessutom ....

Så det är en dålig egenskap att kräva att programmeraren indenterar/formaterar rätt?

[Conny Westh]

Ja, programspråket ska ha en tolerans mot struntsaker, men skrika högt när man gör allvarliga fel.

Just kritiska kolumnpositioner har jag nog bara sett i Python och Cobol om jag minns rätt.

De flesta andra programspråk brukar vara flexibla mot såna triviala fel, Men i Python och Cobol så har kolumnpositionerna betydelse så då gick det inte att vara snäll för Python i det läget. ....

[Clarence]

90% av indenteringen ser likadan ut i välskriven kod som i Python kod (notera att du oftast har valmöjligheter i var du bryter raderna i python). Sen att du tycker det är en struntsak huruvida din kod är lätt läsbar eller ej, det låter jag dig stå för (det finns ca 43243242342 undersökningar som visar på att en konsekvent indentering leder till bättre läsbarhet). Själv tycker jag inte om att de ersatt andra avgränsningstecken med tvånget av indentering - men det tror jag är för att mina ögon är så vana vid C/PHP/Java/C#/etc-tecknena. Men det är ett tydligt val som faktiskt går väldigt bra ihop med faktiska egenskaper hos programmerare.

Sen vet jag inte om du är medveten om att en versions-taggning i din VCS leder till precis samma sak som en kompilerad binär. Det är en förhållandevis självklar process om man har acceptanstester eller liknande för varje lanserad version. Binären är lite svårare att ändra i annat än byta namn och i värsta fall göra den oidentifierbar eller obrukbar, taggningen är lättare att följa då man kan ta sig en titt i historyn om någon ändrat något (en tagg är en tagg är en tagg, den SKALL ej förändras. För versioner under arbete använder man branches.)

[tartareandesire]

Ursprungligen postat av ConnyWesth

Jag tänker mest på hur det funkar på de stora företag jag jobbat, både som anställd och konsult (mest försäkringsbolag, banker offentliga myndigheter och konsultbolag som gör uppdrag hos dessa), då har man omfattande kvalitetstester där man efter vissa bestämda tidpunkter "låser" alla kodändringar och går in i en testprocess inför varje release, vi pratar inte om utvecklarnas tester här utan om beställarens acceptanstester och produktionstester. Då får ingen gå in i den levererade koden och göra ändringar under testfasen.

Sådana tungrodda företag och organisationer är knappast typiska för modern webbutveckling utan är extremfall där man inte sällan har extrema säkerhetskrav men även där försöker man idag banta organisationer och spara pengar. Den typen av utveckling kan hur som helst aldrig motiveras ekonomiskt i en mer normal verksamhet.

Ursprungligen postat av ConnyWesth

Du får tänka på att det är många personer involverade (både utvecklare, kravställare, produktionstekniker, supportpersonal m.m.) alla måste vara synkroniserade på samma kodbas. Om något ändras så måste hela testet göras om från början. Därför vill man ha järnkoll på detta.

Arbetar man med versionshantering så använder samtliga samma kodbas oavsett vilket språk det handlar om.

Ursprungligen postat av ConnyWesth

Ruby känns betydligt större (ur teknisk synvinkel) och mer välgjort än både PHP och Python, mycket mer väl genomtänkt objekthantering. Känns som Ruby har betydligt bättre inkasling, arvsmekanismer m.m. Verkar mer okänslig för kolumnspositioner.

Återigen, objekthanteringen ligger inte i PHP utan hos användaren. Det känns som att du hela tiden förväntar dig att PHP ska fungera som ett strikt ramverk som tvingar dig göra si eller så. PHP är inget ramverk men du kan testa till exempel Symfony 2 om du önskar. Fullgott stöd för objekt, arv, inkapsling, abstraktion osv. finns numera i PHP. Du kan ställa precis vilka krav du vill i din utveckling men det är du själv som utvecklare som sätter gränserna och inte språket. Detta är mycket användbart i modern agil webbutveckling där flexibilitet är viktigare än begränsningar.

[Conny Westh]

Ursprungligen postat av Clarence

90% av indenteringen ser likadan ut i välskriven kod som i Python kod (notera att du oftast har valmöjligheter i var du bryter raderna i python). Sen att du tycker det är en struntsak huruvida din kod är lätt läsbar eller ej, det låter jag dig stå för (det finns ca 43243242342 undersökningar som visar på att en konsekvent indentering leder till bättre läsbarhet). Själv tycker jag inte om att de ersatt andra avgränsningstecken med tvånget av indentering - men det tror jag är för att mina ögon är så vana vid C/PHP/Java/C#/etc-tecknena. Men det är ett tydligt val som faktiskt går väldigt bra ihop med faktiska egenskaper hos programmerare.

Jag är för egen del ganska petig med indentering och placering av klamrar och parenteser i koden, men det stämde inte överens med vad Python anser trots att koden var tydligt indenterad/strukturerad. Men en teckenposition (dvs ett mellanslag för lite eller för mycket) hit eller dit så blev det körfel i runtime....

Python skrek högt om jag använde {tab} i stället för {space} för indenteringen, jag var tvungen att slå på automatisk omvandling till {space} för {tab}-tecknen för att det skulle gå att köra koden. Om jag minns rätt så är inte ens Cobol lika kinkig om man använder {tab} eller {space} vid indentering.

Ruby verkar vara betydligt mer generös med definitionen och toleransen av whitespace....

Jag har dock fortfarande problem med require i Ruby, får det bara inte att fungera.... Filerna ligger i samma katalog. Jag har PATH till Ruby Bin-katalog, alla annan kod jag testkör med Ruby funkar klockrent "load" funkar men inte "require". Vad gör jag för fel? Jag kör version 2.0.0p195 från 2013-05-14.

# File: Trig.rb
# Date: 2013-07-01
# Purpose: Trogonometry, include this namespace with require...

=begin
    This is a multiline comment in Ruby
=end

module Trig
  PI = 3.14159265358979

  def Trig.sin(x)
   # ..
   return x
  end
  def Trig.cos(x)
   # ..
   return x
  end
end

# File: TrigTest.rb
# Date: 2013-07-01
# Purpose: Trogonometry, Test to include Component with require...

=begin
    This is a multiline comment in Ruby
=end

#load "Trig.rb"
#load "Action.rb"

require("Trig")
require "Action"

y = Trig.sin(Trig::PI/4)
wrongdoing = Action.sin(Action::VERY_BAD)
puts(Trig::PI)

shit jag hittade felet, jag ska köra require_relative.... Då funkar det som jag tänkt....

[Clarence]

Ursprungligen postat av ConnyWesth

Jag är för egen del ganska petig med indentering och placering av klamrar och parenteser i koden, men det stämde inte överens med vad Python anser trots att koden var tydligt indenterad/strukturerad. Men en teckenposition (dvs ett mellanslag för lite eller för mycket) hit eller dit så blev det körfel i runtime....

Python skrek högt om jag använde {tab} i stället för {space} för indenteringen, jag var tvungen att slå på automatisk omvandling till {space} för {tab}-tecknen för att det skulle gå att köra koden. Om jag minns rätt så är inte ens Cobol lika kinkig om man använder {tab} eller {space} vid indentering.

Python gnäller väl bara om du blandar space-indentering och tabb-indentering? Och gör du det kan du få en rejäl röra mellan olika editorer då en tabs representation inte är fast medans spaces är det. Sen går det väl också lätt att stänga av denna varning om du vill skriva dålig kod.

Sen bör du ändå följa PEP8 om du skriver Python. Vilken säger åt dig att använda spaces (för att dess representation är konsekvent). Du ställer helt enkelt in din editor att använda spaces när du trycker på tab. Denna best practice återfinns i många style guidelines för en mängd språk.

Att du får runtime errors med rent felaktig indentering är väl rätt självklart. Om alla dina avgränsare är indentering så kan man väl förvänta sig att de är korrekta. Annat är väl ungefär som att tycka att ) ska kunna ersätta } i C# när det ändå inte finns någon starting (.

[Conny Westh]

Just nu håller jag på med Ruby, gillar det bättre, men nu så har jag ett nytt dilemma, vilken databas API-ska jag använda? Har kollat på en del olika men RDBI verkar vara den senaste jag hittat, dock verkar den lite personberoende då det verkar vara 1 person som heter Eric Hollenbe som gör 99% av allt jobb.

De senaste 3 åren verkar det inte hänt så mycket i det projektet.

Frågan är om det finns ett annat API för databaser som är lämpligare?

[Linuus]

Ursprungligen postat av ConnyWesth

Just nu håller jag på med Ruby, gillar det bättre, men nu så har jag ett nytt dilemma, vilken databas API-ska jag använda? Har kollat på en del olika men RDBI verkar vara den senaste jag hittat, dock verkar den lite personberoende då det verkar vara 1 person som heter Eric Hollenbe som gör 99% av allt jobb.

De senaste 3 åren verkar det inte hänt så mycket i det projektet.

Frågan är om det finns ett annat API för databaser som är lämpligare?

Vad använder du för databas?
Postgres: http://rubygems.org/gems/pg
MongoDB: http://rubygems.org/gems/mongo
MySQL: http://rubygems.org/gems/mysql