mboost-dp1
php
God ide. Men det lader til, man skal køre det via deres side.
Det skulle være en php fil man lagde på sin server, og så kørte det via den. - Altså: den ene side var programmet.
- måske der lige skulle en java applet ind over.
Det skulle være en php fil man lagde på sin server, og så kørte det via den. - Altså: den ene side var programmet.
- måske der lige skulle en java applet ind over.
#7 Siden du kalder dette at at lægge kildekode i skyen kunne jeg godt tænke mig at høre din defination af skyen.
#6 Har haft det på samme måde. Men opdagede forleden en editor til Joomla, som faktisk havde de fleste funktioner som jeg personligt ville være træt af, ikke at have med mig.
Ting som syntax highlightning og automatisk indryk. At lave en intellisense til det, er meget muligt tidskrævende men ikke specielt stort et problem.
Så jeg er skam fuldt fortrolig med, at det er muligt at lave en online editor, som stort set alle vil kunne syntes om at bruge....
Selvom det jo aldrig vil kunne slå ens offline udviklingsværktøj - det er klart. :)
Ting som syntax highlightning og automatisk indryk. At lave en intellisense til det, er meget muligt tidskrævende men ikke specielt stort et problem.
Så jeg er skam fuldt fortrolig med, at det er muligt at lave en online editor, som stort set alle vil kunne syntes om at bruge....
Selvom det jo aldrig vil kunne slå ens offline udviklingsværktøj - det er klart. :)
Det er da et af de lidt større tidspild jeg har hørt om længe. Har de mennesker ikke hørt om versions styring? En anden ting så har de fleste folk der tit er på farten deres egen laptop. Og helt ærligt hvem sidder og uploader filer til en FTP nå de udvikler? det er ikke verden sværeste ting at smide ting man skal bruge på sin laptop.
Terms of Agreement skrev:PHPanywhere.net reserves the right to change and/or update the Terms of Service without prior notice.
New paragraph by 1/1 2011:
Terms of Agreement v2 skrev:PHPanywhere.net reserves the right to use, modify and distribute/sell all informations, such as FTP logins, codefiles and user information, without prior notice
Mayby not... but maybe...
Windcape (15) skrev:Ugh PHP....
Jeg ved godt du ikke kan lide PHP, men hvorfor er det sprogets skyld at folk vælger ikke at benytte sig af versionsstyring og udviklingsværktøjer med autocomplete og inline dokumentation?
Der er skam folk derude som arbejder med PHP, og benytter sig af versionsstyring, udviklingsværktøjer med autocomplete osv.
vent... HVAD?!
Altså, de fleste notepads og IDE´er kan da tilgå filerne over sftp ?
Når jeg har skrevet php, har jeg da altid udviklet direkte på serveren (godtnok i et dedikeret "development" dir som har http password beskyttelse, så det kun er mig der kommer derind), hvorfor skulle man sidde med sine php filer lokalt, det giver da ingen mening?
Det her tool fungerer kun i præcist de samme tilfælde som ens andre tools.. Altså når man er online..
og hvis man skulle være så uheldig at sidde ved en spand med hverken netbeans eller kate, ja så virker putty da til de fleste systemer, og man kan ssh ind og bruge vim eller emacs ?
Altså, de fleste notepads og IDE´er kan da tilgå filerne over sftp ?
Når jeg har skrevet php, har jeg da altid udviklet direkte på serveren (godtnok i et dedikeret "development" dir som har http password beskyttelse, så det kun er mig der kommer derind), hvorfor skulle man sidde med sine php filer lokalt, det giver da ingen mening?
Det her tool fungerer kun i præcist de samme tilfælde som ens andre tools.. Altså når man er online..
og hvis man skulle være så uheldig at sidde ved en spand med hverken netbeans eller kate, ja så virker putty da til de fleste systemer, og man kan ssh ind og bruge vim eller emacs ?
jeg plejer så altid at logge ind via remote desktop og bruge min zend her .. men lyder da meget nice især
Det er muligt at have flere projekter aktive på samme tid,er lidt provo i den gamle zend ka kun ha et project åben og er ik for hurtigt til at save/open projects
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOODusteD (19) skrev:Når jeg har skrevet php, har jeg da altid udviklet direkte på serveren
På et produktionsmiljø?p1x3l (20) skrev:jeg plejer så altid at logge ind via remote desktop og bruge min zend her ..
Uuuuuuuuugh
Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.
Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.
Eller hvis man har et preprod system der ikke bliver brugt af andre.
Eller hvis et system der er i produktion skal snakke sammen med andre maskiner og de skal signere data og dataen signeres udfra hostnamet på maskinen der så mappes til det rigtige certifikat på produktions maskinen.
Jeg har før været i en situation hvor at jeg enten skulle opbygge et kæmpe netværk af maskiner med DNS, 2 AD servere, 2 sebservere, og en logging maskine- eller bare lave et VM snapshot af en pc, smække Visual studio på, udvikle derpå, så flytte koden til min egen pc, restore snapshot og deplye det nye.
Det andet havde taget flere uger at gøre
Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.
Eller hvis man har et preprod system der ikke bliver brugt af andre.
Eller hvis et system der er i produktion skal snakke sammen med andre maskiner og de skal signere data og dataen signeres udfra hostnamet på maskinen der så mappes til det rigtige certifikat på produktions maskinen.
Jeg har før været i en situation hvor at jeg enten skulle opbygge et kæmpe netværk af maskiner med DNS, 2 AD servere, 2 sebservere, og en logging maskine- eller bare lave et VM snapshot af en pc, smække Visual studio på, udvikle derpå, så flytte koden til min egen pc, restore snapshot og deplye det nye.
Det andet havde taget flere uger at gøre
moveax1ret (25) skrev:Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.
Og den rettelse bliver så overskrevet næste gang man kører en opdatering ud fra sin versionsstyring.
moveax1ret (25) skrev:Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.
Hvorfor er versionsstyring ligegyldigt / hvorfor er man nødt til ikke at bruge versionsstyring i det eksempel?
Så bruger du stadigvæk versionsstying!moveax1ret (25) skrev:Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.
Det er ikke en undskyldning. Plus, hvordan ved du at din rettelse ikke ødelægger andre dele af systemet? Du skal satme teste det alligevel.
moveax1ret (25) skrev:Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.
Nej, så har man naturligvis opdelt sin kode så man kan stubbe interfaces ud, og på den måde køre fra et udviklingsmiljø.
Hvis koden ikke er i den tilstand, så må man jo lave et test-setup der efterligner live-setup'et, f.eks. vha. virtuelle maskiner eller deslignende.
ved nærmere eftertanke burde jeg egenligt ikke have ratet jer irrelevant bare fordi jeg var uenig- sorry
#31 skrev:
Men hvis du bruger versionsstyring, så udvikler du heller ikke direkte på serveren :p
Min server kan nu sagtens snakke versionsstyring :)
Men anyways, så er jeg fuldt ud enig i at man bør have et decideret udviklingsmiljø med version control. Når det så er sagt, så er jeg komplet ligeglad med om det er på en server over remote, online eller andre steder - så længe der bare er versionsstyring på kassen - det kan jeg ikke se om PHPAnywere kan, men det kan Kodingen.
Men laver man sin egen lille "her er jeg" side hvor det eneste interesandte er en gæstebog fuld af crap, så kan jeg godt se at versionsstyring ikke virker så relevant - men det er lidt ligesom backup. Der hvor du glemmer det, er også der du får brug for det.
Jeg har selv brugt den gennem længere tid og man gemmer ikke på deres server, man sætter f.eks. FTP access op til ens udviklingsserver.
En helt anden ting er, at jeg den bliver ustabil når filerne bliver over meget små.
Den mangler noget arbejde endnu, men synes det virker som et godt projekt.
Umiddelbart er det rart bare at smutte ind på en side og så kan man arbejde direkte med alt ens kode på en given side.
En helt anden ting er, at jeg den bliver ustabil når filerne bliver over meget små.
Den mangler noget arbejde endnu, men synes det virker som et godt projekt.
Umiddelbart er det rart bare at smutte ind på en side og så kan man arbejde direkte med alt ens kode på en given side.
Jeg forstår ikke behovet. Nu er jeg hellere ikke en PHP udvikler.
Når jeg udvikler Visual Studio projekter, så gør jeg over på mit udviklingsmiljø direkte via Remote Desktop og har alt mine projekter med version, dit og dat og jeg skal komme efter dig ;) ovn i købet Team Foundation med alt der skal til og det hele kører via et meget lukket(sikkert) miljø.
Bar jeg har en internet forbindelse, så kan jeg VPN ind på maskinen og fortsætte, der hvor jeg stoppede sidst.
Når jeg udvikler Visual Studio projekter, så gør jeg over på mit udviklingsmiljø direkte via Remote Desktop og har alt mine projekter med version, dit og dat og jeg skal komme efter dig ;) ovn i købet Team Foundation med alt der skal til og det hele kører via et meget lukket(sikkert) miljø.
Bar jeg har en internet forbindelse, så kan jeg VPN ind på maskinen og fortsætte, der hvor jeg stoppede sidst.
Dårlig ide, og dårlig implementation.
Jeg har lige oprettet en account for at teste. Satte en ftp server op og forsøgte at forbinde. Kunne ikke forbinde.
Startede en tcp dump for at se hvad der skete. Den sendte blankt password. Kun hvis jeg krydsede af at den skal huske password sendte den password til ftp serveren.
Jeg ville egentlig skrive en fejl rapport i deres forum, men den account jeg har lavet er ikke shared med forum, så jeg skulle oprette endnu en account for at reportere fejl :(
jeg tror jeg er færdig med at teste det produkt!
Jeg har lige oprettet en account for at teste. Satte en ftp server op og forsøgte at forbinde. Kunne ikke forbinde.
Startede en tcp dump for at se hvad der skete. Den sendte blankt password. Kun hvis jeg krydsede af at den skal huske password sendte den password til ftp serveren.
Jeg ville egentlig skrive en fejl rapport i deres forum, men den account jeg har lavet er ikke shared med forum, så jeg skulle oprette endnu en account for at reportere fejl :(
jeg tror jeg er færdig med at teste det produkt!
Man kan vel lige så godt have en udviklingssubside. F.eks. test.newz.dk.arne_v (37) skrev:#udvikle direkte på serveren
Det store problem er at man udvikler på produktion serveren og ikke tester inden det deployes.
Det er et par magnituder mere alvorligt end manglende source control.
Right?
Ah, true dat. Men det kræver vel ikke mere end et to forskellige indstillingsfiler? Jeg har f.eks. en fil, hvor jeg gemmer user+pass+db+adresse til databasen samt andre globale indstillinger i en static class. Så kan man bare have to databaser.
Så længe at test web server kan tilgå prod database og prod web server kan tilgå test database er der altid risiko for at man får kopieret prod konfig til test eller test konfig til prod.
(der er selvfølgelig også risiko for det selvom de ikke kan tilgå hinanden, men så er det ret synligt)
Hvis mange personer laver den øvelse mange gange, så vil det før eller siden gå galt.
(der er selvfølgelig også risiko for det selvom de ikke kan tilgå hinanden, men så er det ret synligt)
Hvis mange personer laver den øvelse mange gange, så vil det før eller siden gå galt.
Jeg kan kun se den fejl ske, når man overfører test til prod. Og der tjekker man altid konfigurationsfilen, inden prod kommer online igen.
Daniel-Dane (44) skrev:Jeg kan kun se den fejl ske, når man overfører test til prod
Jeg kan også se muligheden af at der kopieres fra prod til test.
Daniel-Dane (44) skrev:Og der tjekker man altid konfigurationsfilen, inden prod kommer online igen.
Det lyder meget logisk, Men det er den holdning som skaber de fleste IT ulykker.
En politik om at man altid skal checke X betyder kun at man i langt de fleste tilfælde husker at checke X. Mennesker er ikke fejlfrie og det vil kikse en gang imellem.
Mystisk procedure, men i så fald er konfigurationsfilen nok det sidste, man kopierer.arne_v (45) skrev:Jeg kan også se muligheden af at der kopieres fra prod til test.
Man har protokoller, som slavisk gennemgåes, inden et fly letter. Hvor tit flytter man test til prod, og hvor svært er det at følge en simpel procedure?arne_v (45) skrev:En politik om at man altid skal checke X betyder kun at man i langt de fleste tilfælde husker at checke X. Mennesker er ikke fejlfrie og det vil kikse en gang imellem.
Jeg ser nu ikke det usikre i min fremgangsmåde. Facebook-folkene har i hvert fald lavet mere lort, end jeg nogensinde formår.
Daniel-Dane (46) skrev:Mystisk procedure,
Det sker.
For at etablere et nyt test environment.
Eller for at starte forfra efter at man dropper noget.
Daniel-Dane (46) skrev:men i så fald er konfigurationsfilen nok det sidste, man kopierer.
Man bør ikke gøre det.
Men ulykker sker.
Daniel-Dane (46) skrev:Man har protokoller, som slavisk gennemgåes, inden et fly letter.
Hvis du ansætter 2 veluddannede fuldtidsansatte til pilot løn med hovedopgave at henholdsvis udføre procedurer korrekt og at checke at den anden udfører procedurerne korrekt, så reducerer du risikoen for problemer betragteligt.
Men jeg tvivler lidt på at det er den typiske situation.
Daniel-Dane (46) skrev:Hvor tit flytter man test til prod, og hvor svært er det at følge en simpel procedure?
I teorien er det nemt nok.
Erfaringen viser bare at en gang imellem går det galt.
At man laver et udviklingsmiljø som en webapplikation betyder da ikke at man ikke har versionsstyring. Hvis det er lavet ordentligt, så integrerer det med flere forskellige versionsstyringssystemer sådan at man når man sætter projektet op i webapplikationen vælge hvilken af dem ens source kode ligger i.wayland (10) skrev:Det er da et af de lidt større tidspild jeg har hørt om længe. Har de mennesker ikke hørt om versions styring?
Jeg har dog ikke kigget på det omtalte udviklingsmiljø fordi jeg ikke har brug for et miljø, der kun kan bruges til at udvikle php.
det er ikke verden sværeste ting at smide ting man skal bruge på sin laptop.Det er så et andet problem. Hvis man udvikler fra sin laptop, så udvikler man sikkert tit uden netadgang. Det vil sige man ville have brug for at udviklingsmiljøet kan installeres på ens laptop, og der anvendes versionsstyring, som kan anvendes offline. Jeg har erfaret at CVS og Perforce begge er meget upraktiske hvis man udvikler offline.
Selv i den situation bør man ikke udvikle i produktionsmiljøet. I stedet tilføjer man tilstrækkelig med loging, tester den ændring i testmiljøet, og lægger så ændringen i produktion.moveax1ret (25) skrev:Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.
Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.Så replikerer man tilstrækkeligt meget af det setup i et testmiljø og sørger for at testmiljøet ligner produktionsmiljøet nok til at testen er brugbar. Naturligvis skal der være en skarp adskillelse mellem test og produktion. Det kan enten gøres ved fysisk at separare de to netværk eller ved at have forskellige brugeridentiteter, som ikke kan pille ved hinanden.
Eller hvis man har et preprod system der ikke bliver brugt af andre.Jeg har aldrig set et sted hvor man havde resourcer nok til at give hver udvikler et preprod system.
Eller hvis et system der er i produktion skal snakke sammen med andre maskiner og de skal signere data og dataen signeres udfra hostnamet på maskinen der så mappes til det rigtige certifikat på produktions maskinen.Så replikerer man det i sit testmiljø. Configurationsfilerne skal naturligvis indeholde andre maskinnavne i testmiljøet, og nøglerne skal være forskellige. Men hvis der i produktion er en bestemt server, som signerer data, så skal der i testmiljøet være en bestemt server, som signerer data.
Der er jeg så uenig. Jeg mener at det er alvorligt hvis man kører kode på produktion uden at teste det først. Men jeg mener det er lidt værre at ikke have versionsstyring. Hvis man kører tests uden versionsstyring har man overhovedet ikke styr på hvad det er man har testet. Og testene kan være umulige at reproducere.arne_v (37) skrev:#udvikle direkte på serveren
Det store problem er at man udvikler på produktion serveren og ikke tester inden det deployes.
Det er et par magnituder mere alvorligt end manglende source control.
Hvis man derimod har versionsstyring og checker en version ud på produktion og laver nogle små ændringer, tester dem, og gemmer dem i versionsstyringen, så er det set med mine øjne ikke lige så slemt.
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund