WNZ: Online PHP-udvikling

Arh, en USB stick med Notepad++ portable og .php filerne. Men ok, det her er da nemmere :)

Jeg er fint tilfreds med dropbox/notepad ++ :)

Men det lyder da alligevel som en sjov ting at prøve

Har altid min computer med mig. Hvis jeg skulle træffe at glemme den bruger jeg Dropbox ligesom #2. Men skal prøves :)

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.

Idéen er god :)

Men tror nu stadigt jeg vil benytte min bærbar med EasyPHP og Notepad++ :)

Synes aldrig at online editors er behagelige, ved at flere hoste sites tilbyder dem, så tror nu ikke det vil komme til at erstatte dropbox+notepad++ :)

Jeg ville nu ikke være tryg ved at lægge min kildekode, til mine applikationer i skyen.

#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. :)

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.

PHPanywhere.net reserves the right to change and/or update the Terms of Service without prior notice.Terms of Agreement

New paragraph by 1/1 2011:

PHPanywhere.net reserves the right to use, modify and distribute/sell all informations, such as FTP logins, codefiles and user information, without prior noticeTerms of Agreement v2

Mayby not... but maybe...

Undskyld, at jeg spørger dumt, men vil nogen ikke invitere mig ind i den lukkede klub af folk, som ved, hvad WNZ står for?

weekendnewz

Kodingen.com er da meget federe. Den understøtter tons af sprog inkl. PHP.

Men selvfølgelig, hvis man nu absolut vil kode i PHP, og absolut vil bruge et produkt med PHP i navnet, så er i da velkommen :)

Jeg er fint tilfreds med dropbox/notepad ++ :)prozeantriox (#2)

Hvad skete der for versionsstyring og udviklingsværktøjer med autocomplete og inline dokumentation.

Ugh PHP....

Ugh PHP....Windcape (#15)

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.

Hvad skete der for versionsstyring og udviklingsværktøjer med autocomplete og inline dokumentation.

Ugh PHP....Windcape (#15)

Hørt ville ikke kunne undvære min SVN server og coda som IDE

Måske spørger jeg dumt... Men findes der et IDE (SAAS) som har intellisense til fx php (eller andre sprog)?

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 ?

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

Når jeg har skrevet php, har jeg da altid udviklet direkte på serverenDusteD (#19)

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
OOOOOO

jeg plejer så altid at logge ind via remote desktop og bruge min zend her ..p1x3l (#20)

På et produktionsmiljø?

Uuuuuuuuugh

Når jeg har skrevet php, har jeg da altid udviklet direkte på serverenDusteD (#19)

Dødssynd #1 for en webudvikler :D
Jeg vil nok anbefale dig at få opsat et ordentligt udviklingsmiljø med noget versionsstyring (Git/SVN/Mercurial).

#21 og #22 Det er ikke altid vanvittigt, nogle gange kan man blive nødt til det- og andre gange er det bare ligemeget.

Det er en fin tommelfingerregel, men mere er der altså ikke i det.

Nogle gange bliver man bare nødt til at være pragmatisk.

#21 og #22 Det er ikke altid vanvittigt, nogle gange kan man blive nødt til det- og andre gange er det bare ligemeget.moveax1ret (#23)

Kom med et eksempel.

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 der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.moveax1ret (#25)

Og den rettelse bliver så overskrevet næste gang man kører en opdatering ud fra sin versionsstyring.

Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.moveax1ret (#25)

Hvorfor er versionsstyring ligegyldigt / hvorfor er man nødt til ikke at bruge versionsstyring i det eksempel?

Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.moveax1ret (#25)

Så bruger du stadigvæk versionsstying!

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.

Hvis at et system er kæmpestort og involverer mange maskiner der snakker sammen.moveax1ret (#25)

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.

Hov, jeg snakkede ikke om versions styring, men at udvikle direkte på serveren.............

ved nærmere eftertanke burde jeg egenligt ikke have ratet jer irrelevant bare fordi jeg var uenig- sorry

Hov, jeg snakkede ikke om versions styring, men at udvikle direkte på serveren.............moveax1ret (#29)

Men hvis du bruger versionsstyring, så udvikler du heller ikke direkte på serveren :p

Men hvis du bruger versionsstyring, så udvikler du heller ikke direkte på serveren :p
#31

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 vil nok anbefale dig at få opsat et ordentligt udviklingsmiljø med noget versionsstyring (Git/SVN/Mercurial).Nilks (#22)

Jeg kører da også SVN på mit development dir, og laver en export når siden skal i produktion?

#33 Nu skrev du jo at du arbejdede direkte på serveren, og der må jeg nok være enig med Windcape: Når du arbejder via SVN, arbejder du ikke "direkte på serveren". Der er et lag imellem.

Desuden meldte din historie ikke noget om at du brugte SVN.

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.

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.

#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.

altså ligesom når jeg har et projekt på min server, som er online og giver mig mulighed for at tilgå den med bl.a. PSPad (freeware) overalt? programmet fylder intet og er også online og gratis.
Kræver bare et win miljø.

forstår ikke det nye i det her?

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!

#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.arne_v (#37)

Man kan vel lige så godt have en udviklingssubside. F.eks. test.newz.dk.

Right?

#40

Hvis den ikke er effektivt separeret fra produktions site både i web server og database server er det ikke godt.

Der kan være et sikkerhedshul i test udgaven.

Man kan fejlkonfigurere test environment så den peger på produktions databasen.

Etc..

Murphys law applies.

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.

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.

Jeg kan kun se den fejl ske, når man overfører test til prodDaniel-Dane (#44)

Jeg kan også se muligheden af at der kopieres fra prod til test.

Og der tjekker man altid konfigurationsfilen, inden prod kommer online igen.Daniel-Dane (#44)

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.

Jeg kan også se muligheden af at der kopieres fra prod til test.arne_v (#45)

Mystisk procedure, men i så fald er konfigurationsfilen nok det sidste, man kopierer.

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.arne_v (#45)

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?

Jeg ser nu ikke det usikre i min fremgangsmåde. Facebook-folkene har i hvert fald lavet mere lort, end jeg nogensinde formår.

Mystisk procedure,Daniel-Dane (#46)

Det sker.

For at etablere et nyt test environment.

Eller for at starte forfra efter at man dropper noget.

men i så fald er konfigurationsfilen nok det sidste, man kopierer.Daniel-Dane (#46)

Man bør ikke gøre det.

Men ulykker sker.

Man har protokoller, som slavisk gennemgåes, inden et fly letter.Daniel-Dane (#46)

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.

Hvor tit flytter man test til prod, og hvor svært er det at følge en simpel procedure?Daniel-Dane (#46)

I teorien er det nemt nok.

Erfaringen viser bare at en gang imellem går det galt.

I pity humanity.

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?wayland (#10)

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.

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.

Hvis der er en bug der kun optræder i produktion og ikke kan replikeres i test miljøet.moveax1ret (#25)

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.

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.

#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.arne_v (#37)

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.

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.