[PHP] leeg scherm, geen error reporting

zaterdag 5 oktober 2013 18:13

Het makkelijkste wat je kan doen is op je eigen PC een web server incl. PHP installeren die hetzelfde is als de versie die je hoster draait, hier kan je dan "development instellingen" op zetten zodat je kan zien wat er misgaat met je code. Op deze manier kan je zonder dat je site stuk/down is ontwikkelen en pas als het lokaal werkt de site "deployen".

Overigens houdt je hoster ongetwijfeld een error log bij die je vast wel kan benaderen in een of ander control panel.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

Acties:

Verwijderd

Topicstarter

Ik kan inderdaad een error log bekijken via het control panel, maar die geeft slechts een zeer beperkt aantal errors. Als ik opzettelijk een ; weglaat wil ik gewoon de keiharde melding voor mijn neus dat er een parse error was.

De work-around die je zegt van zelf een heel systeem op te zetten om de boel te 'copy-cat-en' heb ik geen zin in. Ik werk al jaren gewoon rechtstreeks op de server(s) waar het boeltje moet draaien, dit om migratie problemen te vermijden. En zoals ik zei, ik heb begrepen dat PHP vanaf 5.2 of 5.3 default eigenlijk geen error-reporting doet uit security overwegingen, maar er moet toch een manier zijn om alles weer 'even' aan te zetten tijdens het ontwikkelen en het daarna weer netjes 'uit' te zetten ?

zaterdag 5 oktober 2013 20:08

Acties:

Barryvdh

Heb even getest, bij mij worden syntax errors ook niet getoond, maar krijg ik een wit scherm. Misschien dat je error_reporting waarde niet kan aanpassen, omdat PHP zover niet komt (crash voordat script uitgevoerd wordt).
Maar syntax errors worden opgepikt door je IDE toch?
Misschien een te nieuwe versie gebruikt met ontwikkelen?

Als niks werkt kan je natuurlijk altijd gewoon een exit('klaar'); neerzetten en kijken hoever je hem in het script kan plaatsen zonder dat je een wit scherm krijgt

zaterdag 5 oktober 2013 22:47

Acties:

zaterdag 5 oktober 2013 22:51

Quia Ego Sic Dico.

Verwijderd schreef op zaterdag 05 oktober 2013 @ 18:13:
De work-around die je zegt van zelf een heel systeem op te zetten om de boel te 'copy-cat-en' heb ik geen zin in. Ik werk al jaren gewoon rechtstreeks op de server(s) waar het boeltje moet draaien, dit om migratie problemen te vermijden.

Dan doe je het al jaren gewoon fout. Je wíl op je liveserver helemaal geen errors geven, want de gemiddelde error geeft kwaadwillenden doorgaans meer dan genoeg houvast om je systeem open te breken... Zet nou gewoon een aparte server op met dezelfde versie van PHP en Apache, en dan heb je nergens gezeik mee. Dat is niet "lastig" maar gewoon een goede manier van werken.

Zie ook de documentatie:

quote: http://www.php.net/manual...on.php#ini.display-errors
This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).

Ook niet onbelangrijk:

Although display_errors may be set at runtime (with ini_set()), it won't have any affect if the script has fatal errors. This is because the desired runtime action does not get executed.

En ten slotte: uit je phpinfo blijkt dat je display_errors @ runtime uit staan. Die .htaccess alleen zou genoeg moeten zijn, maar zo niet, dan moet je volgens mij ini_set('display_errors', 1); hebben. Geen idee of "on" ook werkt, maar volgens mij niet.

Verder: Waar hoort mijn topic?
WEB >>PRG

[ Voor 32% gewijzigd door NMe op 05-10-2013 22:51 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

RedHat

offtopic:
Hoe doe je dat als je op een locatie werkt met strenge policy en waar standaard proxy is ingesteld? Dan kun je toch nooit localhost benaderen vanuit een browser of wat dan ook.

Ik zou in ieder geval dit even nalezen:
http://php.net/manual/en/function.error-reporting.php

Hier staat ook vermeld, wat nme al zegt, dat je 1 moet gebruiken ipv on.

Maar goed, je zult dus hoogstwaarschijnlijk met parameters in php.ini oid moeten gaan stoeien, want 9 van de 10 x worden die parameters in je PHP bestand geen eens uitgevoerd bij een fatal error en heeft het setten ervan dus ook geen zin.

[ Voor 54% gewijzigd door RedHat op 05-10-2013 22:54 ]

zaterdag 5 oktober 2013 22:55

Acties:

unglaublich

RedHat schreef op zaterdag 05 oktober 2013 @ 22:51:

offtopic:
Hoe doe je dat als je op een locatie werkt met strenge policy en waar standaard proxy is ingesteld? Dan kun je toch nooit localhost benaderen vanuit een browser of wat dan ook.

Ik zou in ieder geval dit even nalezen:
http://php.net/manual/en/function.error-reporting.php

Hier staat ook vermeld, wat nme al zegt, dat je 1 moet gebruiken ipv on.

Verwijzing naar localhost aan de hosts file toevoegen. Bijvoorbeeld

127.0.0.1 lokaal.web

Dan kan je vanuit je browser er komen. Anders moet je gewoon even de intranet instellingen aanpassen.

zaterdag 5 oktober 2013 22:58

Acties:

RedHat

unglaublich schreef op zaterdag 05 oktober 2013 @ 22:55:
[...]

Verwijzing naar localhost aan de hosts file toevoegen. Bijvoorbeeld

127.0.0.1 lokaal.web

Dan kan je vanuit je browser er komen. Anders moet je gewoon even de intranet instellingen aanpassen.

Mind de locatie met 'strenge policy'. Daar kun je geen HOSTS file aanpassen of wat dan ook

Heb het zelf ooit eens ondervonden en kon met geen mogelijkheid onder proxy zooi uitkomen. Booten van USB was de oplossing maar toch, zou dus best kunnen zijn dat TS hetzelfde probleem heeft

zaterdag 5 oktober 2013 23:00

Acties:

zondag 6 oktober 2013 00:05

Quia Ego Sic Dico.

RedHat schreef op zaterdag 05 oktober 2013 @ 22:51:

offtopic:
Hoe doe je dat als je op een locatie werkt met strenge policy en waar standaard proxy is ingesteld? Dan kun je toch nooit localhost benaderen vanuit een browser of wat dan ook.

offtopic:
Zwaar offtopic, maar als je op de locatie waar je werkt je werk niet optimaal kan doen vanwege een IT-policy, dan moet je met de afdeling ICT gaan praten over het opzetten van een interne server (wat gewoon een repurposed oude desktop kan zijn). Je hebt gewoon een developmentomgeving nodig, en als je enigszins professioneel aan het klussen bent heb je bij voorkeur ook aparte omgevingen voor testen en voor staging.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

Voutloos

Boolean settings als volgt in .htaccess is netter:
php_flag display_errors on

{signature}

zondag 6 oktober 2013 00:23

Acties:

zondag 6 oktober 2013 12:09

Verwijderd schreef op zaterdag 05 oktober 2013 @ 18:13:

De work-around die je zegt van zelf een heel systeem op te zetten om de boel te 'copy-cat-en' heb ik geen zin in. Ik werk al jaren gewoon rechtstreeks op de server(s) waar het boeltje moet draaien, dit om migratie problemen te vermijden.

Gewoon zorgen dat je dev omgeving dezelfde versies gebruikt als op de server. Ik zie niet wat voor migratieproblemen dat zou opleveren? Ja er kunnen verschillen optreden maar daarvoor heb je een staging/acceptatie omgeving waarin je de laatste tests doet. Ik bedoel: als jij een foutje maakt in je code, laat je dan je de bezoekers minutenlang naar een foutmelding kijken terwijl jij scrambled om uit te zoeken wat er mis gaat en uit alle macht de error probeert op te lossen terwijl je die lokaal of op de staging al had kunnen vinden en oplossen? Dat vind ik niet erg netjes en lijkt me ook behoorlijk stressvol voor jou?

En zoals ik zei, ik heb begrepen dat PHP vanaf 5.2 of 5.3 default eigenlijk geen error-reporting doet uit security overwegingen, maar er moet toch een manier zijn om alles weer 'even' aan te zetten tijdens het ontwikkelen en het daarna weer netjes 'uit' te zetten ?

Volgens mij kan de hoster bepalen welke ini-settings jij kan aanpassen. Dus als de hoster heeft bepaald dat er nooit errors getoond worden (slimme hoster!) dan ben jij de sigaar.

RedHat schreef op zaterdag 05 oktober 2013 @ 22:51:

offtopic:
Hoe doe je dat als je op een locatie werkt met strenge policy en waar standaard proxy is ingesteld? Dan kun je toch nooit localhost benaderen vanuit een browser of wat dan ook.

Het is de taak van een werkgever om te zorgen dat jij je werk goed kan uitvoeren. Of dat nou localhost is, een server-bak ergens in een kast doet er niet toe, maar om dan maar live op een webserver te gaan ontwikkelen "omdat proxy blabla" vind ik echt iets te ver gaan.

Wellicht ten overvloede, maar ik zou de TS ook willen aanraden om versiebeheer te gebruiken in combinatie met deployment tools (ik noem een beanstalk, die doet beide).

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

Acties:

xzaz

OTAP mensen OTAP.

Schiet tussen de palen en je scoort!

zondag 6 oktober 2013 14:09

Acties:

Verwijderd

Topicstarter

Wowowowowow mensen.. rustig....

Ten eerste gaat het niet over mission-critical websites en/of andere dingen. Het ook niet over hobby gedoe, het gaat over, hoe moet ik het zeggen, "middleclass" websites die belangrijk zijn, maar geen top-of-the-bill security en wat dan ook vragen.

Ik ontwikkel dingen op aanvraag en freelance, en dat zijn voornamelijk reclame/grafisch gerichte sites. Veiligheid is uiteraard belangrijk, niemand wordt graag gedefaced, en script kiddie gedoe als sql injectie en dergelijke zijn uiteraard ook niet gewenst.

Dus ik probeer uiteraard met zoveel mogelijk dingen rekening te houden, maar werk inderdaad al jaren op de server waar het uiteindelijk op moet komen. En nee, het komt uiteraard niet 'public' zolang het niet af is. Maar eenmaal het concept werkt en (voor zover dat met zekerheid te zeggen is) bugfree is, dan gaat het 'live'. Waarom het zogezegd dan zo fout moet zijn omdat ik niet op een apart dev systeem werk, mar rechtstreeks op de definitieve plaats is de eerlijke gezegd een beetje een raadsel...

Waarom sommige mensen hier zo hard tekeer moeten gaan is me eigenlijk niet duidelijk...

Om nog even te reageren op sommige nuttige tips, die optie voor display_errors on heb ik ook al getest in een versie met 1 ipv on, en de paar andere tips werken dus ook niet. Want die had ik via Google ook al allemaal gezien.

En syntax fouten zie ik uiteraard in mijn IDE maar ik haalde het als voorbeeld aan dat ik zelfs die domme dingen gewoon weer graag, net zoals 'vroeger' keihard voor mijn neus krijg.

Ik begin meer en meer het gevoel te krijgen dat men bij de laatste PHP versies alles zo dichtgezet heeft uit veiligheidsoverwegingen dat er blijkbaar op geen enkele manier nog (tijdelijk) full error reporting mogelijk is zonder toegang te hebben tot je php.ini. En die heb ik niet. Op zich is dat een pluspunt voor de hoster in kwestie, ze houden het clean en het zekere voor het onzekere, maar het is lastig 'werken' zo..

En de opmerking dat er geen output komt omdat het over een 'fatal error' gaat zie ik ook vaak voorbijkomen op Google...

Je ziet dat ik al de nodige moeite heb gedaan om het probleem zelf op te lossen, maar ik loop overal tegen dezelfde problemen aan.. de voorgestelde oplossingen werken niet. En om mijn hoster te gaan lastigvallen op php.ini mss aan te passen lijkt me ook niet direct een optie, want ik kom zelfs meldingen tegen op Google van mensen die hun PHP upgrade terugdraaien omdat het OOK niet werkt met de settings in php.ini aan te passen.

Verder zie ik ook dat allerlei CMS systemen en andere kant-en-klaar-oplossingen patches of how-to's opstellen om een migratie naar 5.2 of hoger mogelijk te maken, want er blijken wel heel veel dingen helemaal spaak te lopen over, voraal, die sterk verhoogde en aangepaste default security aanpassingen..

Iemand nog tips om het (tijdelijk) terug aan te kunnen zetten om achter alles weer dicht te zetten door de betreffende commando's simpelweg eruit te halen als de site 'live' gaat ?

Alvast bedankt voor de zinvolle en begripvolle reacties...

zondag 6 oktober 2013 14:25

Acties:

EddoH

Backpfeifengesicht

Je probeert nu wanhopig om vooral niet mee te gaan met de beveiligingspolicy van php en/of je hoster en je star aan je oude werkwijze vast te houden. Neem gewoon wat wijs advies aan van de ervaren devvers hier en doe je dev werk op een daarvoor bestemde development omgeving. Dit scheelt je én frustratie, en je leert weer eens wat over best practices betreft web development.

Ook al zijn je websites niet mission critical, als je eens een klant binnenhaalt die wel kennis van zaken heeft sla je geen modderfiguur omdat je je development op de productieomgeving doet

zondag 6 oktober 2013 14:30

Acties:

SoulWar1

Old habits die hard, maar ik zou toch adviseren lokaal een webserver installeren. Zoals je zelf al aangeeft is het lastig werken zo en dat is niet zonder reden. Productiemachines zijn nu eenmaal meer dicht getimmerd en niet geschikt om op te ontwikkelen. Daarnaast mis je ook tools zoals xdebug, die mij al een hoop tijd hebben bespaard bij het opsporen van bugs.

En voel je niet te snel aangevallen, want zo 'hard' gaat het er niet aan toe...

Know Thyself

zondag 6 oktober 2013 16:30

Acties:

zondag 6 oktober 2013 16:36

Ik sluit me aan bij de rest. Ontwikkelen doe je op een ontwikkelomgeving en niet op je productieomgeving. Je werkt zeker ook niet met versiebeheer?

Acties:

zondag 6 oktober 2013 16:46

Admin Devschuur®

^ Romeinse Ⅲ ja!

Begin gewoon eens bij stap 1:

PHP: blaat.php

ini_set('display_errors', 1);
error_reporting(-1);

echo 10 / 0;

Mikker deze blaat.php in je webroot en roep die eens aan. Krijg je dan nog steeds een wit scherm? Zo niet, dan zit er ergens in je code iets waardoor deze settings overschreven worden.

(Overigens zijn dit typisch fouten die een IDE niet voor he gaat aanwijzen; syntactisch is alles nemelikk in orde)

Los daarvan: werken / testen / devven in een productieomgeving (al is 't in een /temp bij wijze van) is gewoon not-done. Zorg voor op z'n minst een fatsoenlijke ontwikkelomgeving (OTAP is nog beter, maar misschien wat overkill in sommige situaties). En gebruik inderdaad versiebeheer.

[ Voor 54% gewijzigd door RobIII op 06-10-2013 17:26 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

zondag 6 oktober 2013 16:47

Quia Ego Sic Dico.

Verwijderd schreef op zondag 06 oktober 2013 @ 14:09:
Wowowowowow mensen.. rustig....

Ten eerste gaat het niet over mission-critical websites en/of andere dingen. Het ook niet over hobby gedoe, het gaat over, hoe moet ik het zeggen, "middleclass" websites die belangrijk zijn, maar geen top-of-the-bill security en wat dan ook vragen.

Niet alleen je website is at risk, maar de hele server. Zal je hoster leuk vinden.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

zondag 6 oktober 2013 16:52

Als je direct op de live server werkt klinkt het ieder geval wel als hobby gedoe

Acties:

Aionicus

Cartman! schreef op zondag 06 oktober 2013 @ 16:47:
Als je direct op de live server werkt klinkt het ieder geval wel als hobby gedoe

hangt ervanaf , wij werken ook op de "live" server , alleen wel op een aparte poort / aparte ontwikkel omgeving, niets mis mee aangezien dat alleen "lokaal" aan te spreken is.

als je direct in je live omgeving dit soort dingen gaat wijzigen , ja dan is het hobby achtig , maar om nu zelf een webserver te gaan installeren als de hosting al een goed alternatief heeft waar niemand bijkan (tunneltje etc).

zondag 6 oktober 2013 18:07

Acties:

zondag 6 oktober 2013 19:27

Quia Ego Sic Dico.

Mja, maar dat is niet wat hier speelt. De topicstarter bagatelliseert zijn gebrek aan security en heeft daarmee met een public-facing website niet alleen zijn sites blootgesteld aan risico's maar potentieel ook andere sites op diezelfde server.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

Aionicus

NMe schreef op zondag 06 oktober 2013 @ 18:07:
Mja, maar dat is niet wat hier speelt. De topicstarter bagatelliseert zijn gebrek aan security en heeft daarmee met een public-facing website niet alleen zijn sites blootgesteld aan risico's maar potentieel ook andere sites op diezelfde server.

excuses dat had ik niet gelezen , ik had alleen het stukje gelezen waarbij men aangaf dat ontwikkelen op een live server ten alle tijde no no is . daar haakte ik even op in. dat terzijde, php'n zonder error reporting = hell XD

zondag 6 oktober 2013 20:26

Acties:

Verwijderd

Topicstarter

Djeezes... ondergaat men hier een publieke test/vernedering over kennis en/of je wel voldoet aan jullie eisen ?

Ik stel hier gewoon een vraag waarover op heel het internet veel te doen is, maar waar 101 niet werkende oplossingen voor gegeven worden. Daarom mijn poging om het hier eens te proberen.

Maar ipv. constructieve antwoorden in het genre van 'neen, dat kan niet zonder zware ingrepen' of 'neen, dat kan niet zonder heel de security-opzet onderuit te halen' moeten er hier wat verwijten, beledigingen en andere dingen naar een persoon zijn hoofd gegooid worden.

Excuse me om geen admin expert te zijn. Ik weet wat ik moet weten, ik bedoel, ik verdiep me in wat ik nodig heb en ik denk niet dat ik een full-blown webserver expert moet zijn omdat ik als bijberoep nu en dan wat leuke dingen maak op aanvraag waar de mensen heel tevreden over zijn. Ik maak geen dingen die moeten voldoen aan bepaalde security levels, maar die gewoon vlot cross-browser moeten werken en uiteraard niet vol gaten zitten...

Ondertussen kan ik dus concluderen dat mijn oude hoster qua security blijkbaar losser of te los was, want het probleem waar ik nu tegenop loop blijkt dus 'normaal' te zijn.

Goed dan moet ik een andere oplossing zoeken, of mijn hoster eens contacteren of ze nergens een bak hebben hangen waarop ze zelf op 'spelen' om daar in een veel lager beveiligde omgeving te kunnen testen en ontwikkelen... Hiervoor zelf een extra systeem voorzien heb ik de tijd, de plek en vooral de zin niet in om me daar eerst een eind mee bezig te houden.

Maar zoals Aionicus ook zegt : waarom zou ontwikkelen op een live server ten alle tijden des duivels zijn ? En PHP'n zonder degelijke error reporting is inderdaad redelijk... vervelend om het beleefd uit te drukken.

zondag 6 oktober 2013 20:34

Acties:

Barryvdh

Heb je ook de .htaccess optie geprobeerd? Toevoegen aan .htaccess (of zelf aanmaken) in de root van de webfolder werkt bij mij wel, ook bij syntax fouten.

code:

1
2
3

php_value error_reporting 30719
php_value display_errors 1
php_value display_startup_errors 1

zondag 6 oktober 2013 20:35

Acties:

zondag 6 oktober 2013 20:42

Admin Devschuur®

^ Romeinse Ⅲ ja!

RobIII in "[PHP] leeg scherm, geen error reporting"
Dit al geprobeerd?

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

zondag 6 oktober 2013 20:46

Verwijderd schreef op zondag 06 oktober 2013 @ 20:26:
Djeezes... ondergaat men hier een publieke test/vernedering over kennis en/of je wel voldoet aan jullie eisen ?

Tja. Je kunt je ook afvragen of als een hoop ervaren professionals hier je vertellen dat hoe je het doet heel erg verkeerd is en dat hosters error reporting met hele goeie redenen uitzetten, je misschien niet gewoon iets minder eigenwijs moet doen en primair lokaal moet ontwikkel. Hoe zegmaar iedereen het doet

Volle error reporting vindt je vooral bij beun-de-haas hosters. Of switchen dus, of je misschien gewoon in 2013 begeven.

https://niels.nu

Acties:

Verwijderd

Topicstarter

@Barryvdh ; al getest, brengt geen soelaas, dit staat al in de .htaccess

php_value error_reporting 30719
php_value display_errors 1
php_value display_startup_errors 1

RewriteEngine on
RewriteBase /
nog wat stuff....

@Roblll :

Om op je eerdere posting te reageren, als er geen fouten zijn werkt alles goed en ik mag alle suggesties die ik al heb gehad mee in mijn code zetten, dat geeft geen fouten, het blijft werken. Haal ik echter 1 ; weg uit een regel, dan schiet er alleen een wit scherm over.

Ik ga nu je link eens doornemen.. alvast bedankt.. maar ik begin het vermoeden te krijgen dat de instellingen zoals ze nu staan bij die (nieuwe) hoster niet 'on the fly' in je code uit te zetten of te omzeilen zijn...

zondag 6 oktober 2013 20:49

Acties:

MichielioZ

Je hoeft trouwens ook helemaal niet een "full-blown webserver expert" te zijn om lokaal een server te draaien. Even easyphp, xampp of wamp installeren en op "start" klikken, zo simpel is het meestal...

Iedereen wil terug naar de natuur, maar niemand wil lopend...

zondag 6 oktober 2013 20:52

Acties:

Verwijderd

Topicstarter

Hydra schreef op zondag 06 oktober 2013 @ 20:42:
[...]

Tja. Je kunt je ook afvragen of als een hoop ervaren professionals hier je vertellen dat hoe je het doet heel erg verkeerd is en dat hosters error reporting met hele goeie redenen uitzetten, je misschien niet gewoon iets minder eigenwijs moet doen en primair lokaal moet ontwikkel. Hoe zegmaar iedereen het doet

Volle error reporting vindt je vooral bij beun-de-haas hosters. Of switchen dus, of je misschien gewoon in 2013 begeven.

Ik kan gerust leven met het feit dat ik mijn manier van werken mss moet aanpassen, maar kan dit dan ook niet op een normale manier gemeld worden ? En dat error-reporting uitzetten een goeie zaak is weet ik ook wel. Vroeger was dat iets waar je zelf voor moest zorgen voor zover je dat in je eigen code kon regelen, standaard staat het nu blijkbaar helemaal uit. Ook geen probleem mee, ik stelde alleen de vraag of het tijdens het coden opzettelijk (deels) kon aangezet worden, om daarna weer netjes uit te laten.

En ik doe niet eigenwijs maar ik vind het vrij kort door de bocht dat veel mensen hier het maar wat normaal vinden van een extra eigen systeem op te zetten om op te ontwikkelen om het achteraf ergens op een hosting te dumpen. Die logica ontgaat me totaal. Tenzij het over zware, mission critical toepassingen gaat, maar daar gaat het hier niet over. Er zijn genoeg types of soorten websites die uiteraard allemaal liefst zo secure mogelijk zijn om geen potentiele 'holes' te zijn om een server of hele hoster neer te halen. Maar je gaat me ook niet wijsmaken dat IEDEREEN die een beetje website maakt thuis een eigen full-blown server heeft draaien omdat het not-done zou zijn om gewoon rustig te ontwikkelen op de hosting zelf....

zondag 6 oktober 2013 20:59

Acties:

Barryvdh

Ben het er ook wel mee eens dat het wel verstandig is om op een losse server te ontwikkelen, maar er zijn genoeg mensen die gewoon op de server werken hoor. Gewoon een 'work-in-progress' pagina ervoor zetten als je ontwikkelt, en als de website af is veranderd er meestal niet zoveel meer. Even een kopietje maken, aanpassen, testen en vervangen is ook zo gedaan. (Zo beginnen de meeste php programmeurs vanuit hun hobby)
Een WAMP setup-je is zo opgezet, maar een linux servertje opzetten met hetzelfde OS, php versie en extensies enzo, is heus niet zomaar voor iedereen weggelegd. En als je net een afwijkende setup hebt, kan je ook errors krijgen.
(Al wordt het natuurlijk wel steeds makkelijker met tools als Vagrant/puphet etc. om even snel een VM op te zetten)

zondag 6 oktober 2013 21:17

Acties:

zondag 6 oktober 2013 21:24

Quia Ego Sic Dico.

Verwijderd schreef op zondag 06 oktober 2013 @ 20:26:
Excuse me om geen admin expert te zijn. Ik weet wat ik moet weten

Blijkbaar niet.

Je bent nu kennelijk beledigd maar in plaats van goedbedoeld (en downright goed) advies op te volgen ga je nu op hoge poten lopen klagen dat mensen zeggen dat je het verkeerd aanpakt. Sorry, maar dan zit je verkeerd op een serieus forum waar mensen je helpen met je problemen. Je probleem is hier dat je je liveserver aan het verkrachten bent, niet het feit dat je liveserver geen meldingen geeft. Dát is juist goed.

Nou kun je er zelf voor kiezen om dit advies te negeren maar je zou ook eens aan je hoofd kunnen krabben en denken "hee, misschien weten deze mensen die dagelijks dit soort werk doen daadwerkelijk waar ze het over hebben." Je geeft zelf al aan er niet veel van te weten. Neem dan nou maar van ons aan dat je fout bezig bent en je potentieel niet alleen jezelf veel geld zou kunnen kosten, maar anderen ook.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

zondag 6 oktober 2013 22:02

Jammer dat de TS zich zo aangevallen voelt, dat is absoluut niet mijn bedoeling en volgens mij ook niet van de anderen. Het is natuurlijk prima dat je je eigen manier hebt van werken, maar als je wilt blijven groeien in je werk moet je mijns inziens ook commentaar van anderen ter harte nemen om te kijken of je ervan kan leren.

Verwijderd schreef op zondag 06 oktober 2013 @ 20:26:
Maar zoals Aionicus ook zegt : waarom zou ontwikkelen op een live server ten alle tijden des duivels zijn ? En PHP'n zonder degelijke error reporting is inderdaad redelijk... vervelend om het beleefd uit te drukken.

Obviously heeft Aionicus het over een ontwikkelomgeving, aangezien hij zegt:

hangt ervanaf , wij werken ook op de "live" server , alleen wel op een aparte poort / aparte ontwikkel omgeving, niets mis mee aangezien dat alleen "lokaal" aan te spreken is.

en wat er verder mis mee is:

1) wat al gezegd is: veiligheid, als jij bijvoorbeeld eventjes te lang error reporting aanlaat staan en een gebruiker kan bijvoorbeeld SQL statements of server-paden zien, kan hij/zij daar potentieel erg veel schade mee aanrichten aan jouw site of danwel aan de server.

2) Je kan niet debuggen. Dit heb je zelf ontdekt. Op mijn werk staat altijd op alle live sites en test/acceptatie-omgevingen (die draaien op dezelfde machine) de error reporting uit. Gaat er iets mis krijgt de gebruiker ofwel een wit scherm of een customized 500 internal server error pagina en gaat er automatisch een mailtje naar ons toe met de error, maar willen we echt debuggen dan doen we dat toch echt lokaal.

3) Uptime: Het zijn zo te horen geen high profile sites maar dat betekent toch niet dat je de bezoekers maar zomaar errors mag tonen als jij aan het ontwikkelen bent? Ik vind dat gewoon niet zo beleefd. Dingen die live staan moeten gewoon werken en als je een foutje hebt gemaakt waardoor er iets niet werkt dan moet je gewoon binnen 2 seconden een rollback kunnen doen naar een vorige versie die nog wel werkte (zie hieronder).

4) workflow. Ik weet niet hoe jij je code op de server krijgt maar ik hoop met grote hopen dat je niet via een FTP-client PHP-bestandjes heen en weer sleept... dat is zo zonde van je tijd. Ik zou je nogmaals willen aanraden om http://beanstalkapp.com/ eens te bestuderen. Je kan er gratis één repository met deployment op aanmaken, dus dan kan je eens ervaren hoeveel fijner dat is. Je kan het FTP/SSH-proces automatiseren, zodat je wanneer je een site af hebt, of een nieuwe versie van de site hebt je slechts op één knop hoeft te drukken om deze op de live server te zetten, natuurlijk pas nadat je in je ontwikkelomgeving hebt geverifieerd of alles goed werkte.

Verwijderd schreef op zondag 06 oktober 2013 @ 20:52:
[...]

Ik kan gerust leven met het feit dat ik mijn manier van werken mss moet aanpassen, maar kan dit dan ook niet op een normale manier gemeld worden ? En dat error-reporting uitzetten een goeie zaak is weet ik ook wel. Vroeger was dat iets waar je zelf voor moest zorgen voor zover je dat in je eigen code kon regelen, standaard staat het nu blijkbaar helemaal uit. Ook geen probleem mee, ik stelde alleen de vraag of het tijdens het coden opzettelijk (deels) kon aangezet worden, om daarna weer netjes uit te laten.

Als de tips die je daartoe in dit topic hebt gekregen niet helpen, dan rest je nog maar één ding. Naar je hoster toe gaan en vragen hoe zij het hebben ingesteld.

En ik doe niet eigenwijs maar ik vind het vrij kort door de bocht dat veel mensen hier het maar wat normaal vinden van een extra eigen systeem op te zetten om op te ontwikkelen om het achteraf ergens op een hosting te dumpen. Die logica ontgaat me totaal.

Misschien heb je het niet goed begrepen, je hoeft geen extra hardware-systeem in te richten. Je kan gewoon webserver-software op je PC installeren die zoveel mogelijk hetzelfde is als wat de hoster draait. Bijvoorbeeld met Apache, PHP en MySQL. Ik snap niet waarom de logica je zou ontgaan.... ik weet niet hoe ik het je beter kan uitleggen waarom het handig is..... Als je een presentatie moet geven ga je toch ook niet de inhoud daarvan realtime tijdens de presentatie bedenken, maar doe je dat van te voren, maak je er een powerpoint van en oefen je voor de spiegel. Waarom zou je dan websites wel 'realtime' bouwen?

Ik heb aan sites gewerkt waar 500 mensen per maand komen, en aan sites waar 100.000 mensen per maand komen. In beide gevallen was het bij die bedrijven not-done om direct op de live server code aan te passen. De enige aanpassingen die gedaan mogen worden gebeuren via een commit in het versiebeheer-systeem gevolgd door een deploy.

Tenzij het over zware, mission critical toepassingen gaat, maar daar gaat het hier niet over. Er zijn genoeg types of soorten websites die uiteraard allemaal liefst zo secure mogelijk zijn om geen potentiele 'holes' te zijn om een server of hele hoster neer te halen.

Mission-critical websites hebben vaak inderdaad "OTAP", Ontwikkeling, Test, Acceptatie en Productie. Dat dat overkill is voor jouw situatie ben ik met je eens. Maar OP (Ontwikkeling en Productie) is best wel heel erg geaccepteerd en echt niet zo vreemd. Natuurlijk zijn er mensen die dat niet doen, maar dat betekent niet dat zij handig of slim bezig zijn.

Maar je gaat me ook niet wijsmaken dat IEDEREEN die een beetje website maakt thuis een eigen full-blown server heeft draaien omdat het not-done zou zijn om gewoon rustig te ontwikkelen op de hosting zelf....

Je hebt met 10 minuutjes een ontwikkelomgeving op je eigen PC draaien, waar je naar hartelust met php.ini kan spelen en alle errors kan zien. Ik zie niet wat je tegenhoudt.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

Acties:

zondag 6 oktober 2013 22:02

Je hoeft ook geen server admin te zijn om n ontwikkelomgeving te hebben, kijk eens naar xampp of wamp. Bestandje downloade, installeren en klaar. Dat je zo aangevallen reageert geeft denk ik juist aan dat je weet dat je qua kennis achterloopt, helemaal niet erg maar ik raad je aan om te luisteren naar alle goedbedoelde adviezen.

Acties:

Verwijderd

Topicstarter

Ik heb al gezegd dat ik voor 99% akkoord ben met de argumenten die jullie aanhalen waarom het beter is, maar mijn vraag was of het te omzeilen was zonder al het extra werk, en dat kan dus... zonder verder de security van de server aan te tasten want er moet NIETS aan de server settings veranderd worden. En dat het op zich geen wereldramp is om een test-omgeving op te zetten weet ik, maar het gaat me om het principe dat iedereen dat blijkbaar 'normaal' vindt en dat ontwikkelen 'on site' blijkbaar sinds kort des duivels is.

Ik vraag me af hoe jullie trouwens een bug proberen reproduceren op een werkende site waar dan een dbase van 950MB (and growing) achterhangt (heb er zo eentje) en die de mist ingaat in een zeer rare samenloop van omstandigheden. Heel veel kans dat je dat niet eens kan reproduceren op je test omgeving thuis omdat deze nooit 100% identiek is aan de omgeving waarin ze dan bedoeld is om te draaien. Dan moet je toch ter plekke kunnen debuggen ?

Nu.. voor diegene die het interesseert, er is een workaround voor die heel simpel is en waardoor je geen dubbele omgevingen moet opzetten : gewoon een wrapper om het geheel maken..

PHP:

<?php
     error_reporting(E_ALL);
     ini_set("display_errors", 1);
     include("corefile.php");
?>

Reden waarom het zo wel gaat is dat error_reporting(); geen invloed heeft op de verwerking van het script WAARIN het commando staat maar WEL invloed heeft op de error reporting van code die ERNA geparsed wordt....

Gaat de code public, gewoon de wrapper weghalen en error reporting nog eens extra uitzetten.

Exact wat ik zocht...

[ Voor 43% gewijzigd door Verwijderd op 06-10-2013 22:33 ]

zondag 6 oktober 2013 22:04

Acties:

zondag 6 oktober 2013 22:10

Toch gewoon die kop in t zand steken, neem nu van ons aan dat dit niet de manier is hoye je moet werken...

Acties:

zondag 6 oktober 2013 22:15

Admin Devschuur®

^ Romeinse Ⅲ ja!

Voel je vooral niet aangevallen, maar ook hier schittert een gebrek aan kennis.
Sowieso is dit geen "wrapper" noch "workaround", is het nogal wiedes dat error_reporting pas in werking treedt nadat de betreffende regel is uitgevoerd en tot slot zou ik (buiten de webroot) een config.php maken met daarin iets als:

PHP: config.php

1 2	define('_ERRORREPORTING', E_ALL); define('_DISPLAYERRORS', 1);

En dan in je code iets doen als:

PHP:

1 2	error_reporting(_ERRORREPORTING); ini_set("display_errors", _DISPLAYERRORS);

In je productieomgeving ("live") had je eenzelfde config.php staan met daarin:

PHP: config.php

1 2	define('_ERRORREPORTING', 0); //of iets dergelijks define('_DISPLAYERRORS', 0);

Had je nou een aparte ontwikkelomgeving en productieomgeving gehad dan zaten alle verschillen in de configs van de betreffende sites en kon je gewoon alle overige bestanden na wijzigen gewoon 1-op-1 naar productie overgooien zonder bang te zijn dat je nog iets vergeet er uit te halen dat alleen maar voor ontwikkeldoeleinden dient.

[ Voor 5% gewijzigd door RobIII op 06-10-2013 22:14 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Verwijderd

Topicstarter

NMe schreef op zondag 06 oktober 2013 @ 21:17:
[...]

Blijkbaar niet.

Je bent nu kennelijk beledigd maar in plaats van goedbedoeld (en downright goed) advies op te volgen ga je nu op hoge poten lopen klagen dat mensen zeggen dat je het verkeerd aanpakt. Sorry, maar dan zit je verkeerd op een serieus forum waar mensen je helpen met je problemen. Je probleem is hier dat je je liveserver aan het verkrachten bent, niet het feit dat je liveserver geen meldingen geeft. Dát is juist goed.

Nou kun je er zelf voor kiezen om dit advies te negeren maar je zou ook eens aan je hoofd kunnen krabben en denken "hee, misschien weten deze mensen die dagelijks dit soort werk doen daadwerkelijk waar ze het over hebben." Je geeft zelf al aan er niet veel van te weten. Neem dan nou maar van ons aan dat je fout bezig bent en je potentieel niet alleen jezelf veel geld zou kunnen kosten, maar anderen ook.

Wat ik weet is dat ik op mij Windows systeem een simpele ontwikkel-omgeving kan opzetten die nooit 100% identiek kan en zal zijn aan de Linux based hosting waar alles uiteindelijk op moet draaien. Er zijn voorbeelden genoeg te vinden van verschillen en ongelijkheden in die 2 soorten setups.. Dat is voor mij al reden genoeg om niet direct op die manier te werk te gaan, je zit immers niet op een 100% gelijke omgeving te werken en de kans dat je 'perfect' werkende website op je ontwikkelomgeving na het overzetten op je 'public server' de mist ingaat is niet onbestaande... Wat heb je daar dan aan ?

zondag 6 oktober 2013 22:15

Acties:

zondag 6 oktober 2013 22:19

Admin Devschuur®

^ Romeinse Ⅲ ja!

Verwijderd schreef op zondag 06 oktober 2013 @ 22:15:
[...]

Wat ik weet is dat ik op mij Windows systeem een simpele ontwikkel-omgeving kan opzetten die nooit 100% identiek kan en zal zijn aan de Linux based hosting waar alles uiteindelijk op moet draaien. Er zijn voorbeelden genoeg te vinden van verschillen en ongelijkheden in die 2 soorten setups.. Dat is voor mij al reden genoeg om niet direct op die manier te werk te gaan, je zit immers niet op een 100% gelijke omgeving te werken en de kans dat je 'perfect' werkende website op je ontwikkelomgeving na het overzetten op je 'public server' de mist ingaat is niet onbestaande... Wat heb je daar dan aan ?

Daar hebben ze nou VM's voor uitgevonden (of ontwikkelservers of... )

Een VM'etje is in een half uurtje ingericht en als je daar een snapshotje van maakt kun je die zo vaak vernachelen als je wil en ben je in een paar minuten weer back-in-business. En met tools als Vagrant / puppet etc. heb je nóg minder werk.

Onderdeel van developer zijn is dat je voor jezelf een goede omgeving kunt opzetten, de juiste tools beheerst zoals een timmerman zijn gereedschappen beheerst en niet bang bent om iets nieuws te leren.

Geloof me (en ons): er zitten hier zat lui die dagelijks hiermee te maken hebben en echt wel vaker met dat bijltje hebben gehakt. Je hoeft ons niet te vertellen dat er verschillen zitten in een PHP/Linux omgeving en een PHP/Windows omgeving

[ Voor 30% gewijzigd door RobIII op 06-10-2013 22:20 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Verwijderd

Topicstarter

RobIII schreef op zondag 06 oktober 2013 @ 22:15:
[...]

Daar hebben ze nou VM's voor uitgevonden (of ontwikkelservers of... )

.. en dan ben je weer op het punt dat je alsnog een hele server moet gaan opzetten onder een ander OS.. VM of niet ...

zondag 6 oktober 2013 22:23

Acties:

zondag 6 oktober 2013 22:23

Admin Devschuur®

^ Romeinse Ⅲ ja!

Verwijderd schreef op zondag 06 oktober 2013 @ 22:19:
[...]

.. en dan ben je weer op het punt dat je alsnog een hele server moet gaan opzetten onder een ander OS.. VM of niet ...

Tjeez, Debian (of andere distro) iso'tje downloaden, setup doorlopen, PHP en Apache installeren, mogelijk nog met een paar commando's en je bent klaar om te gaan. Desnoods nog even wat finetunen naar eigen wens (zo vind ik samba altijd wel makkelijk om files snel over-en-weer te kopiëren) en klaar.

Maar goed, je moet 't natuurlijk allemaal zelf weten. Maar je doet net alsof 't heel wat is. Als je regelmatig wat devwerk doet (en dat haal ik uit je posts

) dan is 't een eenmalige investering van, nou, zeg, een middagje en je hebt er daarna alleen maar profijt van. Zelf weten hoor.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

Verwijderd

Topicstarter

RobIII schreef op zondag 06 oktober 2013 @ 22:10:
Voel je vooral niet aangevallen, maar ook hier schittert een gebrek aan kennis.
Sowieso is dit geen "wrapper" noch "workaround", is het nogal wiedes dat error_reporting pas in werking treedt nadat de betreffende regel is uitgevoerd en tot slot zou ik (buiten de webroot) een config.php maken met daarin iets als:
PHP: config.php
1
2
define('_ERRORREPORTING', E_ALL);
define('_DISPLAYERRORS', 1);
En dan in je code iets doen als:
PHP:
1
2
     error_reporting(_ERRORREPORTING); 
     ini_set("display_errors", _DISPLAYERRORS);
In je productieomgeving ("live") had je eenzelfde config.php staan met daarin:
PHP: config.php
1
2
define('_ERRORREPORTING', 0); //of iets dergelijks
define('_DISPLAYERRORS', 0);
Had je nou een aparte ontwikkelomgeving en productieomgeving gehad dan zaten alle verschillen in de configs van de betreffende sites en kon je gewoon alle overige bestanden na wijzigen gewoon 1-op-1 naar productie overgooien zonder bang te zijn dat je nog iets vergeet er uit te halen dat alleen maar voor ontwikkeldoeleinden dient.

Met de 'wrapper' die ik aangaf hoef je alleen je .htaccess aan te passen, in mijn geval mijn corefile, van waaruit alles start. Jij moet 2 dingen aanpassen, ik 1 filename. Op de manier die ik aangaf heb je dus nog minder kans om iets te vergeten...

Ik begrijp echt niet waarom sommige mensen er een sport van maken om alles moeilijker te maken dan het is...

zondag 6 oktober 2013 22:25

Acties:

Douweegbertje

Wat kinderachtig.. godverdomme

Verwijderd schreef op zondag 06 oktober 2013 @ 22:19:
[...]

.. en dan ben je weer op het punt dat je alsnog een hele server moet gaan opzetten onder een ander OS.. VM of niet ...

Kijk ik snap dat het ontzettend irritant is dat je een vraag stelt, en vooral geen antwoord krijgt maar allemaal loze comments over "oh dit is slecht" en "ja maar dan moet je echt nog een server erbij nemen voor ontwikkelen" en ga zo maar door. Hierbij wil ik dus ook even tegen andere graag zeggen: geef nou eens die jongen eerst een antwoord op zijn vraag en ga daarna eens de good-guy uit hangen om met allerlei tips en andere werk mogelijkheden aan te komen.
Lekker alles verbeteren en "tips" geven kunnen zoveel mensen, maar blijkbaar even fatsoenlijk antwoord geven niet?

In elk geval om even terug te komen op je reactie:

Ja wil je nou programmeur zijn of niet? Zet anders "beunhaas" achter je naam en ga dan verder. Dit is een beetje het zelfde als een monteur:
"Ja waarom heb ik een brug nodig als ik gewoon een krik kan gebruiken?"
Of... iemand die een huis gaat bouwen:
"Ja waarom heb ik een fundering nodig, hij staat toch nu ook? "

Uiteindelijk moet je ook "investeren" in zowel tijd, eventueel geld en andere zaken.

zondag 6 oktober 2013 22:25

Acties:

zondag 6 oktober 2013 22:26

Verwijderd schreef op zondag 06 oktober 2013 @ 22:02:
Ik vraag me af hoe jullie trouwens een bug proberen reproduceren op een werkende site waar dan een dbase van 950MB (and growing) achterhangt (heb er zo eentje) en die de mist ingaat in een zeer rare samenloop van omstandigheden. Heel veel kans dat je dat niet eens kan reproduceren op je test omgeving thuis omdat deze nooit 100% identiek is aan de omgeving waarin ze dan bedoeld is om te draaien. Dan moet je toch ter plekke kunnen debuggen ?

Sowieso als eerste de database downloaden en lokaal proberen altijd. Als dat niet lukt kan je een testomgeving op de server maken. Bijvoorbeeld test.domeinnaam.nl in plaats van www.domeinnaam.nl, natuurlijk wel met een (sterk) .htaccess password ervoor. Hier zou je dan errors wél kunnen tonen, veilig, zonder dat bezoekers er last van hebben.

Verwijderd schreef op zondag 06 oktober 2013 @ 22:15:
[...]

Wat ik weet is dat ik op mij Windows systeem een simpele ontwikkel-omgeving kan opzetten die nooit 100% identiek kan en zal zijn aan de Linux based hosting waar alles uiteindelijk op moet draaien. Er zijn voorbeelden genoeg te vinden van verschillen en ongelijkheden in die 2 soorten setups.. Dat is voor mij al reden genoeg om niet direct op die manier te werk te gaan, je zit immers niet op een 100% gelijke omgeving te werken en de kans dat je 'perfect' werkende website op je ontwikkelomgeving na het overzetten op je 'public server' de mist ingaat is niet onbestaande... Wat heb je daar dan aan ?

Klopt er zijn zeker verschillen, hoewel die steeds minder worden, maar dat vind ik geen goede reden om het dan maar te laten. Je kan 95% van de ontwikkeling gewoon doen op een lokale ontwikkelomgeving. Die laatste 5% zijn vaak uitzonderingen waar je niet snel tegenaan zal lopen.

Verwijderd schreef op zondag 06 oktober 2013 @ 22:19:
[...]

.. en dan ben je weer op het punt dat je alsnog een hele server moet gaan opzetten onder een ander OS.. VM of niet ...

En het probleem daarmee is wat precies? Behalve dat het een uurtje tijd kost?

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

Acties:

zondag 6 oktober 2013 22:29

Admin Devschuur®

^ Romeinse Ⅲ ja!

Verwijderd schreef op zondag 06 oktober 2013 @ 22:23:
Jij moet 2 dingen aanpassen, ik 1 filename. Op de manier die ik aangaf heb je dus nog minder kans om iets te vergeten...

Ik hoef niets aan te passen. Als ik klaar ben op "dev" kan ik gewoon alle files in de webroot naar "live" mikkeren (we laten even de OTAP buiten beschouwing, versiebeheer deployments etc. die ik normaliter gebruik, dat alles nog makkelijker maakt).

Wat je misschien ontgaat: ik heb een config.php in mijn dev-omgeving staan en een config.php in de live omgeving. Beide bestanden bevatten verschillende "instellingen" voor de betreffende omgeving. Als je spul live gaat gooien overschrijf je natuurlijk de config van "live" niet met de config van "dev". Vandaar (o.a.!) dat je die config buiten de webroot plaatst en dus alles binnen de webroot gewoon blind kunt overgooien.

Verwijderd schreef op zondag 06 oktober 2013 @ 22:23:
Ik begrijp echt niet waarom sommige mensen er een sport van maken om alles moeilijker te maken dan het is...

In dit geval ben jij dat

[ Voor 11% gewijzigd door RobIII op 06-10-2013 22:27 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Acties:

zondag 6 oktober 2013 22:41

Je doet ook geen moeite om het te proberen. Als jj op een antieke werkwijze wilt blijven hangen moet je dat doen maar dan zou ik hier niet meer om advies komen vragen.

Ik ontwikkel bijna altijd op windows en kom zelden prolemen tegen. In het geval van specifieke eigenschappen pak ik Vagrant om het in een VM te draaien.

In principe hoef ik nooit code aan te passen voor verschillende omgevingen, adhv de hostname laadt het script de juiste config met productie als default.

Acties:

Verwijderd

Topicstarter

Cartman! schreef op zondag 06 oktober 2013 @ 22:29:
Je doet ook geen moeite om het te proberen. Als jj op een antieke werkwijze wilt blijven hangen moet je dat doen maar dan zou ik hier niet meer om advies komen vragen.

Ik ontwikkel bijna altijd op windows en kom zelden prolemen tegen. In het geval van specifieke eigenschappen pak ik Vagrant om het in een VM te draaien.

In principe hoef ik nooit code aan te passen voor verschillende omgevingen, adhv de hostname laadt het script de juiste config met productie als default.

Die indruk had ik ondertussen al ja... je kan hier best geen simpele vraag stellen in de hoop een simpele oplossing te krijgen. Of de kwaliteit van die oplossing kan je dan nog een hele boom opzetten over hoe (on)veilig ze wel is, dat is dan weer een heel andere discussie, eentje waar ik ook gerust voor opensta. Ik leer graag bij.

Maar na 2 pagina's en zelf verder te zoeken heb ik ondertussen een simpele tussenoplossing om verder te kunnen zonder alle andere "hints" en "tips" dat het anno 2013 nu eenmaal zo is dat je ontwikkelt op systeem A en je afgewerkte code dan overzet op eindsysteem B. Doe je dat niet dan ben je een idioot.

Tja, dan ben ik tot nader order maar een idioot wat niet wegneemt dat ik bepaalde small-size oplossingen voor @home ontwikkeling wel eens zal bekijken.

En verder vind ik de opmerking dat ik 'ouderwets' werk redelijk ergerlijk. Ik heb door de jaren een bepaalde werkwijze opgebouwd die ik mss inderdaad eens moet herbekijken (ben er een klein jaartje tussen uitgeweest door prive redenen, op wat onderhoudswerkjes na) en blijkbaar is er veel veranderd in die tijd.

Dus ik ben zeker geen dwarsligger, maar neemt niet weg dat sommige mensen blijkbaar liever eerst een dag bezig zijn met het opzetten van een test-setup, alvorens ze hun 5 lijnen code beginnen schrijven die ze nodig hebben....

zondag 6 oktober 2013 22:45

Acties:

zondag 6 oktober 2013 22:46

Je denkt in problemen, het installeren van xampp kost 5 minuten en je kan beginnen met ontwikkelen. Ik vermoed dat je ook niet werkt met versiebeheer, daarvoor kan ik je BitBucket aanraden, kost niks.

Acties:

Voutloos

Verwijderd schreef op zondag 06 oktober 2013 @ 22:41:
Dus ik ben zeker geen dwarsligger, maar neemt niet weg dat sommige mensen blijkbaar liever eerst een dag bezig zijn met het opzetten van een test-setup, alvorens ze hun 5 lijnen code beginnen schrijven die ze nodig hebben....

Voor die dag je setup inrichten, win je elke andere dag een uur terug, plus dat je geen flater kan slaan met downtime, foutmeldingen en passwords richting bezoekers.

Makkelijkste keuze ooit.

{signature}

zondag 6 oktober 2013 22:55

Acties:

SoulWar1

Verwijderd schreef op zondag 06 oktober 2013 @ 22:41:
[...]
Die indruk had ik ondertussen al ja... je kan hier best geen simpele vraag stellen in de hoop een simpele oplossing te krijgen.

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

Know Thyself

maandag 7 oktober 2013 08:56

Acties:

maandag 7 oktober 2013 09:19

Ts is het soort developer die de rest van ons een slechte naam geeft. In de tijd die het hem gekost heeft zn rants te schrijven had ie al lang een vm op zn ontwikkel-pc kunnen inrichten.

@ts: het is niet 'sinds kort' dat ontwikkelen op productie not done is, dat is altijd al zo geweest. Alleen absolute prutsers doen het rechtstreeks op P. Hoe jij hier als een bij gestoken reageert op goed bedoelde adviezen vind ik volkomen bizar.

En ja, dit is misschien wat onvriendelijk maar ik heb het idee dat het anders niet doordringt.

https://niels.nu

Acties:

Pizzalucht

Snotneus.

@Sync4489
Wat doe je eigenlijk als je iets uit de code hebt gehaald (of gesloopt) en je geen CTRL+Z meer kan doen?

maandag 7 oktober 2013 13:15

Acties:

Verwijderd

Topicstarter

Ik sloop nooit zomaar dingen, als ik zaken herschrijf dan bewaar ik altijd alles extra apart, naast de up-to-date backups.

En dat ik geen expert ben geef ik volledig toe, ik zou niet weten hoe ik all-round expert kan worden, want er komt tegenwoordig zoveel bij kijken dat je niet ALLES meer kan kennen.

Ik code al 15 jaar websites en/of toepassingen via het net, je mag mijn manier van werken mss ondertussen wat 'ouderwets' noemen, en ik zal de opties om een aparte omgeving op te zetten eens bekijken, maar ik blijf van het idee dat dat overkill is omdat ik geen "mission critical" dingen maak die super-security vereisen. Wat niet wil zeggen dat ze een open deur voor misbruik moeten zijn.

Maar al die dingen hangen uiteindelijk helemaal niet samen. Na mijn start met ColdFusion op een Windows server ben ik 2 jaar later overgegaan (en de ondertussen lopende sites vertaald) naar PHP op een linux bak.

Het ene kost redelijk wat aan licenties, het andere was gratis. In 1999 was elke besparing meegenomen want hosting was toen zondermeer nog stukken duurder, als je dan kon besparen op je server terwijl er geen verlies van functionaliteit (intengedeel; PHP samen met postgresql was stukken sneller dan een IIS met ColdFusion en een MS dbase erachter) was door gebruik van een ander OS op dezelfde hardware was de keuze snel gemaakt. En het snel overgaan op PHP nam ik er graag bij.

In de jaren daarna ben ik nu en dan op vraag van klanten dingen blijven maken. Meestal commerciele maar vrij static gfx sites, en wat webshops.En ondanks het feit dat ik hier nu als knoeier, idioot of prutser omschreven wordt, draaien sommige van die webshops al jaren probleemloos, met daarbij horende tevreden klanten.

Het zijn mss geen bol.com alike websites, maar sommige staan stand-alone op een server ipv. shared hosting omdat ze te druk bezocht worden en er vaak tot 5000 en zelfs 6000 bestellingen per maand op gebeuren. Voor bepaalde mensen hier mss peanuts, maar hobby sites kan je ze dus ook niet noemen.

Enkele jaren geleden is 1 van mijn webshops zelfs als schoolvoorbeeld op een info-avond van UNIZO gebruikt. Dit is een Belgische vereniging van zelfstandig ondernemers. Het zegt niets over de technische achtergrond, daar kennen die mensen niets van, maar ze noemden het een schoolvoorbeeld van gebruikersgemak, overzichtelijkheid, snel, en logisch in elkaar zittend. Doorsnee genomen kan je er in 3 klikken vinden wat je zoekt, wat zo een beetje de stelregel is voor een shop of de mensen haken sneller af volgens studies. Verschillende andere bedrijven zijn toen bij mij komen aankloppen om hun duur betaalde webshop te laten aanpassen of simpelweg herschrijven door mij. Ik heb er een deel moeten afwijzen want ik kan er geen 20 tegelijk doen.

En ja, 3 daarvan heb als project aangenomen, en van de grond af netjes een produkt afgeleverd waar die mensen nog steeds heel tevreden over zijn. Het uiterlijk is door de tijd al enkele malen veranderd, kwestie van de klanten eens een nieuw kleurtje of wat aangepaste layout te geven, maar de core bleef gelijk en bolt nog steeds zoals het hoort. Wel heb ik van alle grote, nog lopend sites, alle dbase handelingen vervangen door PDO. Met het oog naar de toekomst. Die vervanging heb ik onsite gedaan, uiteraard in een duplicaat die naast de werkende site stond en waarin ik rustig alles kon aanpassen en testen. En eenmaal alles in orde was of zou moeten zijn, heb ik op een nacht alles van het oude naar het nieuwe gezet, zonder de oude te verwijderen. Moest het fout lopen kon ik in no-time terug naar de oude situatie. Het is op geen enkele site nodig geweest. Dit moet iets van een 2 jaar geleden geweest zijn. Net voor ik om prive redenen geen nieuwe prive projecten maar kon beginnen. Sinds enkele weken bestaat die mogelijkheid weer en probeer ik de draad weer terug op te pikken. Dat er in die periode het een en ander veranderd is was ik me al van bewust, dus eerst mezelf wat 'bijwerken'..

En een groot deel van die projecten had ik ook samen in hosting beheer. Kwestie van een mooie deal te maken met een hoster. Diegene die ik had heb ik jaren goed mee samengewerkt tot die er genoeg van had en zich heeft laten overnemen door een andere. Vanaf dan niets dan problemen. Niet door mijn code, maar verschillende malen tijdlang offline omdat die overnemer het niet zo nauw nam met het betalen van zijn facturen aan het datacenter waar hij inzat.

Dus sinds begin dit jaar een nieuwe overstap naar weer een andere, en hier loopt het als een trein. Alleen ben ik sinds eind vorige week dingen aan het testen voor een nieuw project en kwam ik dat 'blank page' probleem tegen waarvan ik eerst ontdekte dat het 'normaal' was in een recente PHP setup, maar waarvoor ik dan een mogelijk 'work-around' zocht. Die dus bestaat.. tot 'ongenoegen' van veel 'experts' hier..

Waarom ik me hier zit te verantwoorden weet ik eigenlijk niet, en ik zeg het nogmaals, mss moet ik mijn manier van werken eens op de schop nemen en herbekijken, daar heb ik genoeg reacties op gehad.

Maar neemt niet weg dat het hier blijkbaar niet meer kan om een simpele, duidelijk gedocumenteerde vraag te stellen, en daar een simpele, to the point reactie op te krijgen.

Ik heb hier in andere draadjes en op andere vragen ook al dat soort reacties zien voorbijkomen en ik kan alleen maar zeggen dat ze ergerlijk en arrogant overkomen. Niet iedereen is pro, niet iedereen werkt voor een groot bedrijf waar ze zomaar wat extra (dure) hardware kunnen eisen, en niet iedereen heeft een baas boven hem die hij van zijn stoel kan praten door wat ingewikkelde termen of dingen naar zijn hoof te gooien..

Dat dit forum niet dient om te vragen op welke knop men moet drukken kan ik begrijpen, maar als ik hier een vraag post waar je 1001 klachten en vragen over kan vinden op google omdat heel veel mensen tegen dat probleem aanlopen sinds een upgrade naar PHP 5.x dan kan je natuurlijk makkelijk zeggen dat het vooral aantoont dat veel ontwikkelaars rommel afleveren.

Maar als je dan alles wat doorneemt op Google en je ook allerlei patches en aanbevelingen ziet passeren voor gekende, grote en veel gebruikte CMS/blog en andere pakketten (die dus OOK tegen bepaalde problemen opliepen na de 5.x upgrades) dan lijkt het me vrij arrogant om het nog steeds op de ontwikkelaars alleen te steken. Er staat veel rommel online, ben ik het volledig mee eens. En verder ben ik ook helemaal geen voorstander van gelijk welk 'handig' CMS of kant-en-klaar webshop pakketje omdat je daar belachelijk veel tijd aan kan verspillen als er daar iets fout mee loopt. Maar niet al die dingen zitten echt verkeerd in elkaar. Er zijn pakketjes bij die echt wel degelijk en netjes geschreven zijn.

Al die zelf-verklaarde experts weten wss zelf maar al te goed wat voor ellende het kan zijn als je problemen in een ander zijn code mag gaan proberen oplossen.. Wat niet wegneemt dat er wel meer goede ontwikkelaars rondlopen buiten henzelf..

Bottom line : ja ik werk momenteel nog steeds recht op de doel-server. Ik ga de aangehaalde opties voor een lokaal ontwikkelsysteem eens bekijken, maar ik blijf het niet logisch vinden, behalve in professionele omgevingen waar ontwikkelen en testen en nog een deel andere procedures een must zijn alvorens live te gaan. Maar verder lijkt het mij eigenlijk geen bal uit te maken hoe je iets maakt. Als het maar netjes gemaakt is, correct geschreven is, en doet wat het moet doen.

En super-de-luxe uitgeruste autodealer is ook geen garantie dat je wagen beter of sneller hersteld raakt. Je bent soms beter af met het door een mechanieker laat doen die perfect weet waar hij mee bezig is, maar het thuis in zijn eigen garage doet..

De tools zijn 1 ding, de persoon die ze gebruikt en toepast zijn volgens mij nog steeds het belangrijkste...

maandag 7 oktober 2013 13:44

Acties:

Merethil

Toch wel knap gezien 5.3.x vanuit 2009 stamt en je dus echt een flinke tijd eruit bent geweest.
Vind het wel gek dat dit je nog nooit eerder overkomen is.

Laatst had ik zelf hetzelfde probleem en na twee google searchqueries en een kwartiertje prutsen inclusief een restart van Apache was ik klaar. Nu zeg je zelf niet bij php.ini te kunnen komen (een probleem in mijn ogen bij je hoster, maar oké) maar zelfs dan kan je in PHP dingen setten.

Snap niet hoe je met 10+ jaar (gok ik, want je hebt het over 15 maar een deel daarvan deed je blijkbaar met IIS / ColdFusion) dit nog niet bent tegengekomen. Andere hosters hebben zo nu en dan ook error_reporting uitstaan om te voorkomen dat je dat aan klanten serveert, nooit ondervonden?

maandag 7 oktober 2013 14:45

Acties:

kwaakvaak_v2

RobIII schreef op zondag 06 oktober 2013 @ 22:23:
[...]

Tjeez, Debian (of andere distro) iso'tje downloaden, setup doorlopen, PHP en Apache installeren, mogelijk nog met een paar commando's en je bent klaar om te gaan. Desnoods nog even wat finetunen naar eigen wens (zo vind ik samba altijd wel makkelijk om files snel over-en-weer te kopiëren) en klaar.

Opzetten??? Je bedoelt gewoon met https://puphpet.com/ een build script voor virtualbox bakken en uitvoeren. Weinig magic aan hoor

Driving a cadillac in a fool's parade.

maandag 7 oktober 2013 16:05

Acties:

maandag 7 oktober 2013 16:18

Dat je nog steeds roept over "onlogisch" en "veel werk" en "omslachtig" etc bewijst dat je meer bezig bent om je te verdedigen dan simpelweg even een zoekterm uit het topic op te zoeken. Het kost je hooguit n kwartiertje om met XAMPP aan de gang te gaan en je kan je lokaal helemaal uitleven.

Ondanks sommige wat overdreven op de man reacties van sommige users hier vind ik dat de TS eigenlijk de enige is die zichzelf als expert ziet vanwege de uitgebreide verdediging en voorbeelden waarom het eigen werk zo goed is. Dat je alleen tevreden klanten hebt is mooi maar wellicht heb je gewoon mazzel gehad dat er nooit iets gigantisch is stuk gegaan tijdens het ontwikkelen. Bovendien zegt het niks over de code die je schrijft of je klant tevreden is natuurlijk

Acties:

Exception

Mijn ervaring met een witte pagina is een simpele 500-error in Firefox. Chrome geeft netjes een melding.

maandag 7 oktober 2013 16:20

Acties:

mrc4nl

Procrastinatie expert

Exception schreef op maandag 07 oktober 2013 @ 16:18:
Mijn ervaring met een witte pagina is een simpele 500-error in Firefox. Chrome geeft netjes een melding.

in dat geval zou je met firebug dan je antwoordheader moeten kunnen bekijken

ora et labora

maandag 7 oktober 2013 18:23

Acties:

Aloys

Heb je al eens in je apache logs kunnen kijken (ipv php logs)? Mogelijk dat daar een nuttige foutmelding staat, iets met een misconfiguratie ofzo?

maandag 7 oktober 2013 18:23

Acties:

Merethil

Het is gewoon jammer dat je google niet juist hebt kunnen aanzwengelen. Zoals ik aangaf, zelfde probleem heb ik in een paar searchqueries via google gevonden.
Daarnaast is het gewoon gek dat je al jaren ervaring hebt en geen testomgeving gebruikt, da's gevaarlijk voor de websites waarmee je werkt en je kan van geluk spreken dat het nog niets noemenswaardigs aan problemen heeft opgelost.

Er zitten hier een hoop mensen die erg goed zijn in wat ze doen. Communiceren kunnen ze ook goed in zijn maar niet als iemand zich al na één reactie aangevallen voelt. Een testomgeving opzetten is development-101 en een kwestie van best practice vanwege de kans dat je iets sloopt door een onoplettendheid of een nieuwe toevoeging die niet helemaal werkt zoals gepland in je hoofd.
Natuurlijk hoeft dit niet altijd, maar als je, zoals je zegt, al 15 jaar in het vak zit zijn er vast mogelijke momenten geweest waar het handig op was. Als je dat had gehad had je waarschijnlijk nu niet met je vraag gezeten (tot een paar reacties geleden toen je de oplossing vond).

Ik begrijp je frustratie over hoe sommige mensen hier reageren maar let ook zelf op dat je jezelf niet als "enige expert" gaat bestempelen aangezien er hier mensen zijn die, overduidelijk, meer ervaring hebben met dit geheel. Niet omdat jij een hobbyist zou zijn, maar omdat zij er hun dagtaak van hebben gemaakt en op een professionele manier alles aangepakt hebben (of het nou vanwege interesse of vanwege bedrijfsleven is).
Ik ben zelf nog niet zo heel lang aanwezig op de arbeidsmarkt als developer maar heb genoeg meegekregen in mijn afgelopen twee jaar om te weten wat de belangen zijn van scheiding van Dev en Prod, zie de waarde er van in en merk dat het me veel heeft opgeleverd.
Vooral de mogelijkheid tot alles proberen en het direct kunnen afvangen van alle errors is gewoon een heel handig en vooral groot punt in dit alles.

De "kritieken" die je benoemd begonnen opbouwend maar al snel, door je eigen insteek en de verschillende meningen van anderen, is dit veranderd naar voor jouw gevoel "aanvallend" omdat je jouw "ouderwetse" manier beter vond: Dit hoeft niet zo te zijn en er zijn talloze redenen genoemd waarom, onder andere in dit geval, jouw manier niet de beste is. Het is niet erg eens toe te geven dat iemand anders (of een ander niveau developers, lager óf hoger) gelijk heeft en een waarheid aan het licht heeft gebracht die jij nog niet zo voor je zag.

Sinds welke versie PHP is trouwens error_reporting automatisch uitgezet?

maandag 7 oktober 2013 22:10

Acties:

maandag 7 oktober 2013 22:52

Verwijderd schreef op maandag 07 oktober 2013 @ 18:07:
[...]

Dat is natuurlijk ook een manier... mijn 'ouderwetse' manier onderuit proberen halen door nu te stellen dat ik al jaren 'mazzel' gehad heb...

Mazzel of nooit kritische klanten gehad misschien. Ik ken geen enkele klant die het tof vind als ik ga rotzooien op zn live site.

Ik heb blijkbaar het een en ander bij te benen na dik 20 maanden ertussenuit geweest te zijn, ik zie niet in waarom ik een probleem zou hebben om dat toe te geven. Het ging vroeger al hard, het gaat blijkbaar nog harder.

Ik denk dat het ding juist is dat we hier elkaar helpen te professionaliseren, iemand die daar (in eerste instantie) niet voor open staat wordt duidelijk gemaakt dat er echt slimmere iplossingen zijn.

Maar waarom sommige mensen daar zo gefrustreerd op moeten reageren doet me trouwens ineens weer beseffen waarom dit forum in de begin periode leuker was dan nu. Toen kon je nog zelfs nog een domme vraag stellen zonder belachelijk gemaakt te worden.

Niemand verplicht jou een vraag te stellen en niemand verplicht ons om een pleister te adviseren voor de behandeling van een gebroken been.

Nu mogen er blijkbaar enkel extreem ingewikkelde vragen gepost worden waar dan bepaalde 'experts' zich in vastbijten en voor de rest moeten mensen het dus zelf maar uitzoeken..

Er wordt verwacht dat je gaat nadenken en dingen ook zelf opzoekt. Sites als stackoverflow staan vol met vragen en antwoorden die tegenwoordig makkelijk te vinden zijn. Vroeger was dat wel anders.

Ach ja.. forums genoeg als het moet.. helaas spijtig dat het hier zo enorm veranderd is. Tweakers used to be fun... nu blijkt het eerder een elite-clubje te zijn voor de 'selected few'...

Niet perse denk ik maar als de iedereen met goede tips in de haren gaat strijken dan maakt het de kloof enkel groter.

Zonde...

Dat is een beetje mijn gedachte als ik lees over jouw werkwijze zegmaar. De meesten hier weten hoe het beter kan en het feit dat we dit uitleggen, de een vriendelijker dan de ander, zegt genoeg dat we willen dat je er iets aan hebt en jezelf beter kunt maken.

Acties:

pedorus

Verwijderd schreef op zondag 06 oktober 2013 @ 22:02:
Ik vraag me af hoe jullie trouwens een bug proberen reproduceren op een werkende site waar dan een dbase van 950MB (and growing) achterhangt (heb er zo eentje) en die de mist ingaat in een zeer rare samenloop van omstandigheden. Heel veel kans dat je dat niet eens kan reproduceren op je test omgeving thuis omdat deze nooit 100% identiek is aan de omgeving waarin ze dan bedoeld is om te draaien. Dan moet je toch ter plekke kunnen debuggen ?

Dan hoop je het probleem in de logs terug te vinden, en (na wat tunen) is dat bijna zonder uitzondering het geval. 950 MB is natuurlijk 3x niks, dat past zelfs in het geheugen van iedere moderne pc, en kun je dus gewoon lokaal downloaden. Als het echt een forse database is, dan kan een ssh-tunneltje helpen.

Het risico van geen eigen database is bijvoorbeeld dat test data de productie data vervuilt. Het voordeel van een lokale IDE en ontwikkelomgeving is dat daadwerkelijk debuggen ook kan (met breakpoints, variable inspection enzo). Overigens is remote debugging in geval van nood ook wel mogelijk, maar dat vereist veel meer setup.

Hydra schreef op maandag 07 oktober 2013 @ 08:56:
@ts: het is niet 'sinds kort' dat ontwikkelen op productie not done is, dat is altijd al zo geweest. Alleen absolute prutsers doen het rechtstreeks op P.

Deze stelling is veel te stellig. Zeker bij startups moeten soms shortcuts genomen worden, en dat zijn echt geen prutsers die dit doen.

En OTAP enzo klinkt leuk, maar juist de configuratie van de P omgeving die net iets anders is dan de A omgeving kan soms toch daadwerkelijk ervoor zorgen dat dingen platgaan. En dat gebeurd dan bij bedrijven die miljarden uitgeven aan IT, maar toch meer downtime kennen dan Jan de Beunhaas die direct op P ontwikkelt.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

dinsdag 8 oktober 2013 08:50

Acties:

dinsdag 8 oktober 2013 13:16

pedorus schreef op maandag 07 oktober 2013 @ 22:52:
Deze stelling is veel te stellig. Zeker bij startups moeten soms shortcuts genomen worden, en dat zijn echt geen prutsers die dit doen.

En OTAP enzo klinkt leuk, maar juist de configuratie van de P omgeving die net iets anders is dan de A omgeving kan soms toch daadwerkelijk ervoor zorgen dat dingen platgaan. En dat gebeurd dan bij bedrijven die miljarden uitgeven aan IT, maar toch meer downtime kennen dan Jan de Beunhaas die direct op P ontwikkelt.

Sorry hoor maar juist als startup kun je je niet permitteren risico's te nemen. Daarnaast heb ik het nergens gehad over grote OTAP straten (die in grote projecten gewoon nodig zijn) maar over het niet rechtstreeks op productie ontwikkelen. Het risico op ernstige fouten (where clause vergeten in een delete statement im maar wat te noemen) is aanwezig en de impact van dergelijke fouten is enorm. Ik ken bedrijfjes die zo werken (heb 13 jaar geleden bij zon bedrijf gewerkt) en dat zijn over het algemeen geen mensen die het erg nauw nemen met best practices.

https://niels.nu

Acties:

pedorus

Hydra schreef op dinsdag 08 oktober 2013 @ 08:50:
Sorry hoor maar juist als startup kun je je niet permitteren risico's te nemen.

Ehh, hoog risico is een kenmerk van een startup... Wikipedia: Startup company

Ik denk niet dat Google resources had voor een testomgeving bijvoorbeeld toen ze nog een startup waren. Dat is toch een kwestie van compileren, beetje uittesten op devmachine, en maar uitproberen in de productie dan. Het scheelt ook dat sommige werkzaamheden nu eenmaal niet zoveel risico met zich meebrengen als je het in de productieomgeving doet. Denk aan het bijklussen van een klein wordpress-templateje op een site met enkele tientallen bezoekers oid.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

dinsdag 8 oktober 2013 13:27

Acties:

dinsdag 8 oktober 2013 13:44

pedorus schreef op dinsdag 08 oktober 2013 @ 13:16:
[...]
Dat is toch een kwestie van compileren, beetje uittesten op devmachine, en maar uitproberen in de productie dan

Dat is toch een enorm verschil met developen op je productieserver, daar gaat het nu net om.

Acties:

dinsdag 8 oktober 2013 13:55

Cartman! schreef op dinsdag 08 oktober 2013 @ 13:27:
[...]

Dat is toch een enorm verschil met developen op je productieserver, daar gaat het nu net om.

Idd. Daarnaastgeloof ik er weinig van dat een startup geen geld zou hebben voor een aparte testserver. Welke serieuze it-er heeft er nu geen oud bakkie ergens over? Een staging/test server die productie-like is, is een pre maar natuurlijk niet 100% noodzakelijk.

https://niels.nu

Acties:

pedorus

Sommige schaalzaken kun je nu eenmaal niet op de eerste de beste machine uittesten; kun je het er nog over hebben natuurlijk in hoeverre testen bij het ontwikkelen hoort.

Bij talen als php, perl, enz speelt dit waarschijnlijk niet, maar daar kun je sneller wat pagina's erbij zetten op de server om iets uit te proberen. Als je niet vreemde dingen doet (plain sql van het type delete from ... bijvoorbeeld), valt het risico erg mee. Het andere voorbeeld was dan ook sterker.

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten

dinsdag 8 oktober 2013 15:04

Acties:

dinsdag 8 oktober 2013 15:13

Het probleem is dus dat "vreemde dingen doen" over het algemeen geen bewuste keuze is. Natuurlijk gaat het 99 van de 100 keer goed, maar dat zijn nog steeds kansen die je niet wil nemen

Daarnaast is het niet gebruiken van sourcecontrol ook gewoon een grote beun-de-haas indicatie.

https://niels.nu

Acties:

woensdag 9 oktober 2013 21:19

Quia Ego Sic Dico.

Verwijderd schreef op maandag 07 oktober 2013 @ 18:07:
[...]

Dat is natuurlijk ook een manier... mijn 'ouderwetse' manier onderuit proberen halen door nu te stellen dat ik al jaren 'mazzel' gehad heb...

Tsja, dat heb je ook. Jouw manier van werken gaat alleen goed bij gratie van het geluk dat er niemand voorbij is gefietst die kwaad in de zin heeft.

Maar waarom sommige mensen daar zo gefrustreerd op moeten reageren doet me trouwens ineens weer beseffen waarom dit forum in de begin periode leuker was dan nu. Toen kon je nog zelfs nog een domme vraag stellen zonder belachelijk gemaakt te worden.

Niemand maakte je belachelijk tot je je hakken in het zand zette en zei dat je het lekker tóch zo bljift doen...

Nu mogen er blijkbaar enkel extreem ingewikkelde vragen gepost worden waar dan bepaalde 'experts' zich in vastbijten en voor de rest moeten mensen het dus zelf maar uitzoeken..

Waar lees je dat? Wij verwachten alleen eigen inzet en dat probleem speelt hier niet, want dat toon je wel. Daarnaast: c'est le ton qui fait la musique. Je ging zelf keihard tegen goedbedoeld advies in omdat je het dacht beter te weten. Zelf weten, maar dat moet je hier niet doen als je niet tegen kritiek kan. Wij hebben de ervaring die jij mist wél.

Ach ja.. forums genoeg als het moet.. helaas spijtig dat het hier zo enorm veranderd is. Tweakers used to be fun... nu blijkt het eerder een elite-clubje te zijn voor de 'selected few'...

Zonde...

Grappig, want in 2003 werd daar ook al over geklaagd. En je bent zelf pas net geregistreerd.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Acties:

Verwijderd

Topicstarter

NMe schreef op dinsdag 08 oktober 2013 @ 15:13:
[...]

Grappig, want in 2003 werd daar ook al over geklaagd. En je bent zelf pas net geregistreerd.

Net niet grappig. Ik gebruik exact dezelfde alias als meer dan 10 jaar geleden toen ik hier ook al member was. Ik ben toen 'gebanned' geweest na een zeer uit de hand gelopen discussie toen Tweakers een zoveelste commerciele site werd, welke netjes knikte naar de eisen van de uitgeverij of grote groep die het toen overgenomen heeft. 2 jaar geleden is men mijn, toen nog steeds geblokkeerde, account plotseling tegengekomen, heb toen het aanbod gehad van de toenmalige reden gewoon te vergeten en men wilde me gewoon weer actief zetten. Ik heb dat eerst geweigerd, maar heb me sinds kort toch weer terug geregistreerd.

Wel ben ik het hier wat blijven volgen om met momenten bepaalde problemen en de oplossingen te lezen, en nu liep ik na een hele tijd 'on hold' gestaan te hebben zelf tegen een dom probleem aan. Met heel deze waslijst aan reacties die voor 99% niet eens meer rechtstreeks met de vraag te maken hebben.

Dus de link die je aanhaalt over het klagen toen heb ik van heel dichtbij meegemaakt, want ik was ooit al member sinds, ik kan er een jaar naast zitten, 1999 ongeveer. Vrij kort na de oprichting dus. Ik ben jaren actief geweest op the good old Tweakers van vroeger, voor het werd zoals het nu is... Ik durf zelfs te zeggen dat ik al lid was hier toen een groot deel van de huidige generatie amper kon fietsen...

woensdag 9 oktober 2013 21:50

Acties: