Kom ihåg mig?

Utvärdering av Phalanger 3.0 (.NET Kompilator för PHP5 med inslag av PHP6)

 
Ämnesverktyg Visningsalternativ
Oläst 2013-07-02, 04:12 #11
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Conny Westh Conny Westh är inte uppkopplad
Klarade millennium-buggen
 
Reg.datum: Aug 2005
Inlägg: 5 166
Citat:
Ursprungligen postat av Clarence Visa inlägg
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.

Citat:
Ursprungligen postat av Clarence Visa inlägg
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.

Senast redigerad av Conny Westh den 2013-07-02 klockan 04:22
Conny Westh är inte uppkopplad   Svara med citatSvara med citat
 


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 
Ämnesverktyg
Visningsalternativ

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 06:17.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017