De Devschuur Coffee Corner - Iteratie ➑

[Douweegbertje]

Soundless schreef op donderdag 27 november 2014 @ 09:40:
[...]


Duurde ff voor ik het zag
Dit werkt trouwens op een Windows bak omdat daar de variabelen case-insensitive zijn. Heb ik een aantal jaar geleden meegemaakt

Dat gaat niet op voor variabelen hoor..

[Soundless]

Douweegbertje schreef op donderdag 27 november 2014 @ 10:06:
[...]


Dat gaat niet op voor variabelen hoor..

Ik weet zeker dat dat iig toen nog wel het geval was. Kon je zo een paar scripts schrijven op Windows en als je dan niet goed had opgelet werkte het live op een Linux servertje niet meer omdat je een hoofdletter had in je variabele naam ipv een kleine letter. Kan zijn dat het nu niet meer zo is. Ik let sindsdien wel goed op mijn hoofdlettergebruik in code.

[.oisyn]

Bv202 schreef op donderdag 27 november 2014 @ 09:06:
tot ik gisteren een mail ontving waarin stond dat IT-consultants geen internet mogen gebruiken...

[Douweegbertje]

Soundless schreef op donderdag 27 november 2014 @ 10:09:
[...]

Ik weet zeker dat dat iig toen nog wel het geval was. Kon je zo een paar scripts schrijven op Windows en als je dan niet goed had opgelet werkte het live op een Linux servertje niet meer omdat je een hoofdletter had in je variabele naam ipv een kleine letter. Kan zijn dat het nu niet meer zo is. Ik let sindsdien wel goed op mijn hoofdlettergebruik in code.

Je filename bijv (en dus URL) , of een table van mssql, misschien als je zelf apache draait op windows. In elk geval zeer zeker niet met IIS.

[dcm360]

Oja, verschil tussen hoofdlettergevoeligheid van tabellen met MySQL, wat leuk is dat. Kloon ik 1 op 1 de database van MediaPortal van een MySQL-server op Windows naar een MySQL-server op Linux, kan MediaPortal de tabellen die nota bene door het programma zelf gemaakt zijn niet meer vinden.

[Soundless]

Douweegbertje schreef op donderdag 27 november 2014 @ 10:13:
[...]


Je filename bijv (en dus URL) , of een table van mssql, misschien als je zelf apache draait op windows. In elk geval zeer zeker niet met IIS.

Was inderdaad niet met IIS maar met Apache. Ik vind het handiger om te werken met Apache als ik het uiteindelijk ook in een omgeving met Apache moet draaien.

[Afvalzak]

Soundless schreef op donderdag 27 november 2014 @ 09:40:
[...]


Duurde ff voor ik het zag
Dit werkt trouwens op een Windows bak omdat daar de variabelen case-insensitive zijn. Heb ik een aantal jaar geleden meegemaakt

Helaas, die case is een typefout inderdaad

edit:

2e guess is correct

[ Voor 4% gewijzigd door Afvalzak op 27-11-2014 10:33 ]

[alienfruit]

Hehe, geen internet. Dat is hetzelfde als Stackoverflow blokkeren Dat deden ze bij een klant ook.

[ Voor 19% gewijzigd door alienfruit op 27-11-2014 10:43 ]

[dcm360]

PHP:

<?php
$helloworld  = "Hello world!";
echo $helloWorld;

code:

Notice: Undefined variable: helloWorld in F:\server\webroot\caseTest.php on line 5

Nou, die hoofdletterongevoeligheid van variabelen in Windows valt me toch wat tegen...
En het is niet alsof ik een recente PHP en Apache op mijn pc heb, ik zou zeggen beiden minstens 3 jaar oud.

[ Voor 17% gewijzigd door dcm360 op 27-11-2014 10:53 ]

[Afvalzak]

alienfruit schreef op donderdag 27 november 2014 @ 10:42:
Hehe, geen internet. Dat is hetzelfde als Stackoverflow blokkeren Dat deden ze bij een klant ook.

Zeker bang dat de medewerkers goede oplossingen gaan zoeken?


Wel grappig hoe een typo in mijn code voorbeeld een hele discussie veroorzaakt

[ Voor 13% gewijzigd door Afvalzak op 27-11-2014 10:57 ]

[.Gertjan.]

dcm360 schreef op donderdag 27 november 2014 @ 10:52:

PHP:

<?php
$helloworld  = "Hello world!";
echo $helloWorld;

code:

Notice: Undefined variable: helloWorld in F:\server\webroot\caseTest.php on line 5

Nou, die hoofdletterongevoeligheid van variabelen in Windows valt me toch wat tegen...
En het is niet alsof ik een recente PHP en Apache op mijn pc heb, ik zou zeggen beiden minstens 3 jaar oud.

Hopelijk maak je een grapje....
De afhandeling binnen de taal staat totaal los van je OS. Het zal het Windows niet boeien of je CASETest.php of caseTEST.php doet (een linux bak wel), maar de parser van PHP is verantwoordelijk voor het boven beschreven stukje hoofdlettergevoeligheid...

[dcm360]

Als je het niet doorhad: wat posts boven mij leek het niet bepaald om een grapje te gaan...

[.Gertjan.]

dcm360 schreef op donderdag 27 november 2014 @ 10:58:
Als je het niet doorhad: wat posts boven mij leek het niet bepaald om een grapje te gaan...

* .Gertjan. veegt de slaap uit zijn ogen...

Sorry

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 10:59:
[...]

* .Gertjan. veegt de slaap uit zijn ogen...

Sorry

Blame me for the idioticy

dcm360 schreef op donderdag 27 november 2014 @ 10:52:

PHP:

<?php
$helloworld  = "Hello world!";
echo $helloWorld;

code:

Notice: Undefined variable: helloWorld in F:\server\webroot\caseTest.php on line 5

Nou, die hoofdletterongevoeligheid van variabelen in Windows valt me toch wat tegen...
En het is niet alsof ik een recente PHP en Apache op mijn pc heb, ik zou zeggen beiden minstens 3 jaar oud.

Wat gegoogle levert ook geen resultaten op behalve dat ze zeggen dat functies wel case-insensitive zijn maar dat zal het niet geweest zijn want dat is niet echt Windows specifiek. Zat het dan toch in de includes?

[dcm360]

Ik weet wel vrij zeker dat het alleen gaat om bestandsnamen (en dus ook includes). Als variabelenamen op Windows case-insensitive waren en op Linux case-sensitive dan had me dat een jaartje of 10 geleden waarschijnlijk een hele berg frustraties opgeleverd.

[.Gertjan.]

dcm360 schreef op donderdag 27 november 2014 @ 11:15:
Ik weet wel vrij zeker dat het alleen gaat om bestandsnamen (en dus ook includes). Als variabelenamen op Windows case-insensitive waren en op Linux case-sensitive dan had me dat een jaartje of 10 geleden waarschijnlijk een hele berg frustraties opgeleverd.

Het zou kunnen dat functies niet case-sensitive zijn (op geen enkel platform), maar variabelen wel. We hebben het tenslotte over PHP, de taal waar je variabele variabelen kan hebben

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:17:
[...]


Het zou kunnen dat functies niet case-sensitive zijn (op geen enkel platform), maar variabelen wel. We hebben het tenslotte over PHP, de taal waar je variabele variabelen kan hebben

PHP doesn't need no stinkin' rationale!

Bron: http://stackoverflow.com/...s-in-php-case-insensitive

[ Voor 1% gewijzigd door Soundless op 27-11-2014 11:29 . Reden: faillink ]

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 11:18:
[...]


[...]

[url src=http://stackoverflow.com/questions/2749781/why-are-functions-and-methods-in-php-case-insensitive]bron[/url]

http://php.net/manual/en/language.variables.basics.php

Variables in PHP are represented by a dollar sign followed by the name of the variable. The variable name is case-sensitive.

http://fr.php.net/manual/en/functions.user-defined.php

Function names are case-insensitive, though it is usually good form to call functions as they appear in their declaration.

Het is niet logisch, maar wel verklaarbaar dus. helloWorld is een var en dus case-sensitive.

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:21:
[...]


http://php.net/manual/en/language.variables.basics.php

[...]


http://fr.php.net/manual/en/functions.user-defined.php

[...]

Het is niet logisch, maar wel verklaarbaar dus. helloWorld is een var en dus case-sensitive.

>_> Ik zie dat mijn link van net nogal fout was. Ik vroeg niet echt om een bron
Link is ondertussen gefixt

[ Voor 11% gewijzigd door Soundless op 27-11-2014 11:30 ]

[TheNephilim]

Stel dat je een prototype maakt; met een ontwerp uitgewerkt in HTML/CSS/etc, even praktisch dus. Naast dat een grafisch vormgever een ontwerp maakt... maak de frontender een..?

Ik kan niet op het woord komen en dat frustreerd me

[.oisyn]

Soundless schreef op donderdag 27 november 2014 @ 11:28:
[...]

Wel verklaarbaar?

Ja, het is wel verklaarbaar. PHP is namelijk begonnen als HTML template parser die de inhoud van bepaalde custom HTML tags verving door de output van functies. Omdat HTML tags niet case-sentive waren, waren functies dat ook niet. Uiteindelijk is PHP langzaam aan uitgegroeid tot script-taal, maar die regel is nooit veranderd.

.edit:

Soundless schreef op donderdag 27 november 2014 @ 11:28:
[...]


>_> Ik zie dat mijn link van net nogal fout was. Ik vroeg niet echt om een bron
Link is ondertussen gefixt

Ah dat verklaart

[ Voor 39% gewijzigd door .oisyn op 27-11-2014 11:34 ]

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 11:28:
[...]


>_> Ik zie dat mijn link van net nogal fout was. Ik vroeg niet echt om een bron
Link is ondertussen gefixt

Het waargenomen gedrag is dus verklaarbaar Verder wil ik mij niet bezighouden met PHP, tenzij een klant er grof geld voor aanbiedt

[Soundless]

.oisyn schreef op donderdag 27 november 2014 @ 11:31:
[...]
Ja, het is wel verklaarbaar. PHP is namelijk begonnen als HTML template parser die de inhoud van bepaalde custom HTML tags verving door de output van functies. Omdat HTML tags niet case-sentive waren, waren functies dat ook niet. Uiteindelijk is PHP langzaam aan uitgegroeid tot script-taal, maar die regel is nooit veranderd.

Dus jou verklaring is gebaseerd op iets van 19 jaar terug? PHP is al lang geen HTML template parser meer in case you didn't notice..

Er is geen reden geweest om dit in de afgelopen 19 jaar niet te veranderen. En nee backwards compatibility is geen geldige reden...

[.oisyn]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:33:
[...]

Het waargenomen gedrag is dus verklaarbaar Verder wil ik mij niet bezighouden met PHP, tenzij een klant er grof geld voor aanbiedt

Ik wil wel een korrel 24 schuurpapier over een euro heen halen, is dat grof genoeg voor je?

Soundless schreef op donderdag 27 november 2014 @ 11:35:
[...]


Dus jou verklaring is gebaseerd op iets van 19 jaar terug?

Sinds wanneer is dat mijn verklaring Het staat nota bene op die bron-pagina waar jij mee kwam . En een verklaring is niet hetzelfde als een goede reden.

PHP is al lang geen HTML template parser meer in case you didn't notice..

Dat is het enige waar PHP goed in is imho, in case you didn't notice

[ Voor 41% gewijzigd door .oisyn op 27-11-2014 11:37 ]

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 11:35:
[...]


Dus jou verklaring is gebaseerd op iets van 19 jaar terug? PHP is al lang geen HTML template parser meer in case you didn't notice..

Er is geen reden geweest om dit in de afgelopen 19 jaar niet te veranderen. En nee backwards compatibility is geen geldige reden...

Ik voel een nieuw discussie-topic opkomen...

Probleem is dat er helaas heeeeeel erg veel brakke code is gemaakt in de oude versies. Het slopen van backwards compatibility zorgt dan voor heel veel problemen. Zeker bij een parsed taal als PHP, je ziet de fouten pas bij het oproepen van de betreffende pagina of soms zelfs pas bij het uitvoeren van de betreffende functie.

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:37:
[...]

Ik voel een nieuw discussie-topic opkomen...

Probleem is dat er helaas heeeeeel erg veel brakke code is gemaakt in de oude versies. Het slopen van backwards compatibility zorgt dan voor heel veel problemen. Zeker bij een parsed taal als PHP, je ziet de fouten pas bij het oproepen van de betreffende pagina of soms zelfs pas bij het uitvoeren van de betreffende functie.

Er worden elke (?) versie wel functies gedeprecate. Hierdoor is je oude code dus ook niet perse voor altijd herbruikbaar.
http://php.net/manual/en/migration55.deprecated.php

Hoezo is het case-sensitive maken van functie namen wel 'erg' maar het deprecaten van functies niet? Het is toch uiteindelijk hetzelfde? Iig voor de developer.

[Soundless]

.oisyn schreef op donderdag 27 november 2014 @ 11:35:
[...]

Sinds wanneer is dat mijn verklaring Het staat nota bene op die bron-pagina waar jij mee kwam . En een verklaring is niet hetzelfde als een goede reden.

[...]

Omdat je zegt:

Ja, het is wel verklaarbaar. PHP is namelijk begonnen als HTML template parser die de inhoud van bepaalde custom HTML tags verving door de output van functies.

Ik lees hier: 'Ja het is wel verklaarbaar want PHP is begonnen als HTML template parser.'

Dat is het enige waar PHP goed in is imho, in case you didn't notice

lol


sht, double post...

[Korben]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:37:
[...]

Ik voel een nieuw discussie-topic opkomen...

Probleem is dat er helaas heeeeeel erg veel brakke code is gemaakt in de oude versies. Het slopen van backwards compatibility zorgt dan voor heel veel problemen. Zeker bij een parsed taal als PHP, je ziet de fouten pas bij het oproepen van de betreffende pagina of soms zelfs pas bij het uitvoeren van de betreffende functie.

Is er geen linter voor PHP?

[Gleighton]

Met depricated functions weet je iig als je van versie A naar B gaat wat er stuk gaat, dan hoef je daar alleen maar even op te zoeken in je sourcecode. Dat heb je met case sensitive functions niet direct.

[wackmaniac]

code:

php -l

[Soundless]

Gleighton schreef op donderdag 27 november 2014 @ 11:44:
Met depricated functions weet je iig als je van versie A naar B gaat wat er stuk gaat, dan hoef je daar alleen maar even op te zoeken in je sourcecode. Dat heb je met case sensitive functions niet direct.

Ik denk dat de meesten de deprecated functions niet uit hun hoofd kennen. Ze runnen de code, krijgen een warning/error en gaan dan pas zoeken.

Als je een melding krijgt met function 'foO' does not exist omdat die 'foo' heet en jij hem ergens aanroept met 'foO', kun je ook snel zoeken. Het is imo dus nog steeds net zo als met deprecated functions.

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 11:42:
[...]


Er worden elke (?) versie wel functies gedeprecate. Hierdoor is je oude code dus ook niet perse voor altijd herbruikbaar.
http://php.net/manual/en/migration55.deprecated.php

Deprecated is niet altijd verwijderen Sommige frameworks hebben behoorlijk lang hun deprecated items nog in de source staan. JQuery heeft volgens mij ook een aantal versies nodig gehad om $.browser van deprecated naar undefined te zetten

Maar eens, functies worden gedeprecate, maar compiler/parser gedrag aanpassen is toch echt wel iets anders. Stel je voor dat je je variabelen niet meer met een a mag beginnen ofzo.

Daarnaast is het bij een parsed taal behoorlijk klote dat je niet pre-compiled werkt, wijzigingen in het parsingframework breken meteen je applicatie, terwijl een compiled app pas problemen oplevert als je een nieuwe compile doet tegen een nieuw framework.

.oisyn schreef op donderdag 27 november 2014 @ 11:35:
Ik wil wel een korrel 24 schuurpapier over een euro heen halen, is dat grof genoeg voor je?

Ik denk eerder aan geld met een grote bek Beetje een gevalletje als dit:

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 11:50:
[...]

Deprecated is niet altijd verwijderen Sommige frameworks hebben behoorlijk lang hun deprecated items nog in de source staan. JQuery heeft volgens mij ook een aantal versies nodig gehad om $.browser van deprecated naar undefined te zetten

Maar eens, functies worden gedeprecate, maar compiler/parser gedrag aanpassen is toch echt wel iets anders. Stel je voor dat je je variabelen niet meer met een a mag beginnen ofzo.

Daarnaast is het bij een parsed taal behoorlijk klote dat je niet pre-compiled werkt, wijzigingen in het parsingframework breken meteen je applicatie, terwijl een compiled app pas problemen oplevert als je een nieuwe compile doet tegen een nieuw framework.


[...]

Dit kan toch ook, net als bij deprecated functions, opgevangen worden en gemeld worden dmv warnings?

Versie 5.5.1: functions case insensitive
Versie 5.5.2~5.5.5: Warning voor functions die case-insensitive gebruikt worden.
Versie 5.5.6: functions case sensitive


Dit is ook wel een leuke

I also remember a quotation from Rasmus in a PHP conference in Paris saying more or less: "I'm definitely not a good programmer, in terms of following strict coding rules or standards, but I can say that if you rely on case sensitivity to recognize one function name from another, you're in kind of serious trouble!"

Zelfde bron als een x aantal posts hierboven

[ Voor 16% gewijzigd door Soundless op 27-11-2014 11:55 ]

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 11:53:
[...]

Dit kan toch ook, net als bij deprecated functions, opgevangen worden en gemeld worden dmv warnings?

Versie 5.5.1: functions case insensitive
Versie 5.5.2~5.5.5: Warning voor functions die case-insensitive gebruikt worden.
Versie 5.5.6: functions case sensitive

Ik denk eerder dat je pas kunt deprecaten bij 6.0 of 5.6, dit zijn namelijk major updates. Als je in je minor updates dit soort dingen doet blokkeer je mensen in hun mogelijkheid tot upgrade bij beveiligings issues. Dit is de reden waarom jQuery bijvoorbeeld 1.9 en 2.0 nog blijft ontwikkelen. In 2.0 hebben ze een hoop legacy eruit getrokken, maar ze blijven 1.9 ook nog onderhouden voor oudere browsers.

Dit is ook wel een leuke

[...]

Zelfde bron als een x aantal posts hierboven

Bij variabelen zie je dat onderscheid vaak wel. Bijvoorbeeld lokaal+private = klein, public/consts hoofdletter. Als je met je functies niet te nauw kijkt, zal je dat vast ook niet doen met de variabelen en dan gaat het dus wel mis.

[Tjolk]

Oldie, maar wellicht leuk in deze discussie: Sitepoint interview met Rasmus Lerdorf in 2002

[Soundless]

.Gertjan. schreef op donderdag 27 november 2014 @ 12:02:
[...]

Ik denk eerder dat je pas kunt deprecaten bij 6.0 of 5.6, dit zijn namelijk major updates. Als je in je minor updates dit soort dingen doet blokkeer je mensen in hun mogelijkheid tot upgrade bij beveiligings issues. Dit is de reden waarom jQuery bijvoorbeeld 1.9 en 2.0 nog blijft ontwikkelen. In 2.0 hebben ze een hoop legacy eruit getrokken, maar ze blijven 1.9 ook nog onderhouden voor oudere browsers.

Natuurlijk ging mijn hele punt niet over of je het 5.5.6 of 5.6 moet noemen. Ik ben het hier namelijk zeker wel met je eens

[...]

Bij variabelen zie je dat onderscheid vaak wel. Bijvoorbeeld lokaal+private = klein, public/consts hoofdletter. Als je met je functies niet te nauw kijkt, zal je dat vast ook niet doen met de variabelen en dan gaat het dus wel mis.

Mij gaat het erom dat ze, net zoals met vele andere dingen, niet consistent zijn. Als je case-insensitive wilt zijn, prima. Maar doe het dan overal. Dus ook met variabelnamen, etc.

[.Gertjan.]

Soundless schreef op donderdag 27 november 2014 @ 12:07:
Mij gaat het erom dat ze, net zoals met vele andere dingen, niet consistent zijn. Als je case-insensitive wilt zijn, prima. Maar doe het dan overal. Dus ook met variabelnamen, etc.

Ben ik absoluut met je eens! Maar helaas zijn beslissingen genomen in het verleden erg lastig terug te draaien zonder je community tegen de haren te wrijven.

Zodra je iets publiceert zit je er redelijk aan vast (behalve als je Facebook/Twitter heet, dan pas je gewoon je API's aan zonder alternatieven en ontsluit maar de helft zodat gebruikers bijna verplicht zijn de sites of FB/Twitter tools zelf te gebruiken).

Misschien is het hele variabelen verhaal door iemand anders gebouwd die het nuttig vond om ze case-sensitive te maken zonder dat hij overlegd heeft met de afdeling functions. Dat is de meest voorkomende verklaring voor afwijkende standaarden/eigenschappen binnen een pakket/api/framework.

[.oisyn]

Soundless schreef op donderdag 27 november 2014 @ 11:44:
Ik lees hier: 'Ja het is wel verklaarbaar want PHP is begonnen als HTML template parser.'

Ja, dat is dan toch een verklaring waarom ze case insensitive zijn? En nee, er is geen goede reden dat ze dat nu nog steeds zijn, louter een verklaring.

[ Voor 3% gewijzigd door .oisyn op 27-11-2014 12:38 ]

[RayNbow]

Kunnen we het over een gezelliger onderwerp hebben? Haskell bijv.?

[ZaZ]

Als een verklaring altijd een goede reden zou zijn, zou het een stuk aangenamer worden met verkeersboetes en ga ik voortaan altijd een verklaring opgeven.

[Mercatres]

.Gertjan. schreef op donderdag 27 november 2014 @ 12:11:
[...]
Zodra je iets publiceert zit je er redelijk aan vast (behalve als je Facebook/Twitter heet, dan pas je gewoon je API's aan zonder alternatieven en ontsluit maar de helft zodat gebruikers bijna verplicht zijn de sites of FB/Twitter tools zelf te gebruiken).

Tweetdeck
Het was zo goed voordat het werd overgenomen... (nog altijd eigenlijk, maar toch niet meer hetzelfde).

[WernerL]

RayNbow schreef op donderdag 27 november 2014 @ 12:47:
Kunnen we het over een gezelliger onderwerp hebben? Haskell bijv.?

Haskell ook ooit eens mee moeten werken tijdens mijn studie. Een tijdje terug wat sourcecode teruggekeken.. Ik had er wat moeite mee om te begrijpen hoe ik bepaalde zaken ook alweer aanpakte..

Als er 1 taal is waar je onleesbare constructies in kunt bouwen is het die taal wel.

_{Mijn Haskell kennis heeft de stap naar Scala dan wel makkelijker gemaakt dus ik zou Haskell dankbaar moeten zijn, maar Scala vind ik stiekem toch leuker.}

[RayNbow]

Ik heb beperkte ervaring met Scala (twee Coursera courses), maar Haskell vind ik toch leesbaarder en minder druk overkomen.

[WernerL]

Haskell is wel korter ja maar het wordt lastig wanneer je eigen infix operators gaat introduceren zoals <*> bijvoorbeeld. Dan is het totaal niet duidelijk wat er nou precies gebeurd zonder de implementatie van de infix operators te bekijken.

En als je maar lang genoeg niets met Haskell doet moet je weer na gaan denken wat bepaalde syntatic sugar doet.

[VanWilder]

Mmhm, @work aan de discussieaangegaan of dat de volgende website waar we aan beginnen werken zonder javascript zou moeten werken.. Het is alleen zeer erg de vraag of er tegenwoordig nog mensen zijn die zonder javascript rondsurfen en of we dus de werkuren daarvoor kunnen verantwoorden.

Mensen hier die nog zonder JS rondsurfen?

[dcm360]

Als ik mijn videodrivers sloop wil ik nog wel eens met Lynx op zoek gaan naar een oplossing, maar afgezien daarvan...

[StM]

Jup, noscript en in principe zet ik JS niet aan voor vreemde websites.

[VanWilder]

StM schreef op donderdag 27 november 2014 @ 13:16:
Jup, noscript en in principe zet ik JS niet aan voor vreemde websites.

Mag ik ook vragen waarom? Uit safety? Of een andere reden?

[StM]

Voornamelijk uit veiligheid ja. En de reductie in laadtijd van 90% is ook niet onaangenaam.

[Styxxy]

ElkeBxl schreef op donderdag 27 november 2014 @ 08:06:
Het is VRIJDAG!!!

Morgen dagske congé gepakt [...]

Idem hier; maar dan wel 5 weken lang. Had nog vakantiedagen staan die ik moest opgebruiken voor het einde van het jaar. Zalig gevoel om een vrijdag te hebben op donderdag .

[markvt]

StM schreef op donderdag 27 november 2014 @ 13:21:
Voornamelijk uit veiligheid ja. En de reductie in laadtijd van 90% is ook niet onaangenaam.

Op een oude pc javascript uit en je kan weer fatsoenlijk internetten

[ElkeBxl]

Styxxy schreef op donderdag 27 november 2014 @ 13:26:
[...]

Idem hier; maar dan wel 5 weken lang. Had nog vakantiedagen staan die ik moest opgebruiken voor het einde van het jaar. Zalig gevoel om een vrijdag te hebben op donderdag .

High five!

[wackmaniac]

Keuze aan de klant laten lijkt mij.

[RayNbow]

WernerL schreef op donderdag 27 november 2014 @ 13:08:
Haskell is wel korter ja maar het wordt lastig wanneer je eigen infix operators gaat introduceren zoals <*> bijvoorbeeld. Dan is het totaal niet duidelijk wat er nou precies gebeurd zonder de implementatie van de infix operators te bekijken.

(<*>) :: Applicative f => f (a -> b) -> (f a -> f b)?

[OkkE]

VanWilder schreef op donderdag 27 november 2014 @ 13:11:
Mmhm, @work aan de discussieaangegaan of dat de volgende website waar we aan beginnen werken zonder javascript zou moeten werken.. Het is alleen zeer erg de vraag of er tegenwoordig nog mensen zijn die zonder javascript rondsurfen en of we dus de werkuren daarvoor kunnen verantwoorden.

Mensen hier die nog zonder JS rondsurfen?

Hier die discussie ook al een paar keer gehad. Ik ben in principe een voorstander van “het moet zonder JavaScript werken”, maar mijn collega's vinden dat minder van belang.

[ Voor 3% gewijzigd door OkkE op 27-11-2014 13:40 ]

[Verwijderd]

OkkE schreef op donderdag 27 november 2014 @ 13:39:
[...]

Hier die discussie ook al een paar keer gehad. Ik ben in principe een voorstander van “het moet zonder JavaScript werken”, maar mijn collega's vinden dat minder van belang.

Die lijken dan nogal op mijn collega's: "Als ze willen dat het werkt moeten ze JS maar niet uitzetten".

[StM]

Ach, in 9 van de 10 gevallen wordt het belang van een bepaalde website schromelijk overschat. Er is bijna altijd wel een alternatief

[Soundless]

Verwijderd schreef op donderdag 27 november 2014 @ 13:42:
[...]

Die lijken dan nogal op mijn collega's: "Als ze willen dat het werkt moeten ze JS maar niet uitzetten".

Vind ik persoonlijk ook. Je kan wel extra tijd gaan besteden om de site te kunnen gebruiken zonder JS maar dit is het meestal niet waard.

[WernerL]

Verwijderd schreef op donderdag 27 november 2014 @ 13:42:
[...]

Die lijken dan nogal op mijn collega's: "Als ze willen dat het werkt moeten ze JS maar niet uitzetten".

Lekker simpele gedachten. Luie collega' s heb jij. Ik zie geen reden om een website javascript afhankelijk te maken eigenlijk. Dan ben ik sowieso geen fan van Javascript over-use.

[Geerrrt]

Ik zou toch geen webapplicatie willen devven zonder javascript

[Douweegbertje]

Anno 2014, waarbij javascript in vrijwel elke website is verwerkt en javascript in feite een onderdeel is van de webstandaard zou ik niet eens weten waarom je daar een discussie over moet houden. Ik zie hier wat dingen dat je dan lui bent als je het niet doet, of dat er voor jouw website 10 andere zijn.

Onze applicatie hier kan gewoon niet zonder javascript, althans het is het nooit waard om het zonder javascript te doen. Even simpel gezegd; ik kan nu gewoon AJAX gebruiken. Het is een 'script', en met scripts kun je uiteindelijk meer bereiken.

Ik ben het wel eens dat je niet perse voor elk dom dingetje JS moet gebruiken, of zelfs jquery. Vele websites zouden technisch gezien zonder veel of zelfs geen moeite zonder JS werken. Bijvoorbeeld middels css :hover in plaats van een identieke JS call.

In elk geval, zolang ik gewoon in mijn html '<script>' kan doen, geen meuk van 3e partijen hoef in te laden (flash bijv.) dan gebruik ik het gewoon wel zonder uberhaubt na te denken of het compatibel is met al mijn bezoekers. Los daarvan zitten we hier met programmeurs, maar mijn bezoekers van mijn websites hebben allemaal 100% javascript aan.

WernerL schreef op donderdag 27 november 2014 @ 13:45:
[...]


Lekker simpele gedachten. Luie collega' s heb jij. Ik zie geen reden om een website javascript afhankelijk te maken eigenlijk. Dan ben ik sowieso geen fan van Javascript over-use.

Lekkere simpele gedachte; jij maakt zeker nog < IE6 proof websites met de usability wat men -nu- wilt? Geen JS, geen png, geen html5, werkbaar op een resolutie van ~ 680, met toch o.a. wat responsive materiaal voor elk device wat we nu tegenwoordig hebben waarbij je daarna nog rekening houdt met de ontwikkelkosten die marktconform de rest is?

[ Voor 22% gewijzigd door Douweegbertje op 27-11-2014 13:59 ]

[Sebazzz]

Wij ontwikkelen hier webapplicaties in Web Forms dus de discussie wel-of-geen-Javascript is snel over hier

[VanWilder]

Zonder al te specifiek te gaan, gaat het hier om een echte website en geen webapp. Ik zie ook niet in waarom de gemiddelde gebruiker js zou uitzetten. Maar wat als bijvoorbeeld om de ene of andere reden er een fout in de javascript file zit.. Dan stopt ineens de javascript powered navigation met werken? Da's not done. De basis zou toch op z'n minst zonder javascript moeten werken.

Heeft Tweakers geen gegevens over hoeveel % van de bezoekers hier geen js aan hebben?

[.Gertjan.]

Sebazzz schreef op donderdag 27 november 2014 @ 13:57:
Wij ontwikkelen hier webapplicaties in Web Forms dus de discussie wel-of-geen-Javascript is snel over hier

Argh, de hel van __doPostBack()
De sites die ik nog heb in WebForms probeer ik zoveel mogelijk te voorzien van fatsoenlijke links ipv die achterlijke doPostback dingen...

Mijn visie op JS is dat de site in principe moet laden zonder JS en de basis functies werken, wil je fancy zooi, dan moet je JS maar aangooien. Zelfde voor CSS eigenlijk, fancy dingen hebben een nieuwe browser nodig en mensen met oude browsers krijgen een werkende maar wat minder mooie versie...

Kost wat extra moeite, maar scheelt een hoop gezeik...

[Douweegbertje]

VanWilder schreef op donderdag 27 november 2014 @ 13:59:
Zonder al te specifiek te gaan, gaat het hier om een echte website en geen webapp. Ik zie ook niet in waarom de gemiddelde gebruiker js zou uitzetten. Maar wat als bijvoorbeeld om de ene of andere reden er een fout in de javascript file zit.. Dan stopt ineens de javascript powered navigation met werken? Da's not done. De basis zou toch op z'n minst zonder javascript moeten werken.

Heeft Tweakers geen gegevens over hoeveel % van de bezoekers hier geen js aan hebben?

En een fout in je html in je <a href sloopt je menu ook, moet dan je menu alsnog gaan werken? Nogal een vreemde redenatie dat je pure html wilt als fallback als je JS code een fout heeft.

[EddoH]

VanWilder schreef op donderdag 27 november 2014 @ 13:59:
... Maar wat als bijvoorbeeld om de ene of andere reden er een fout in de javascript file zit.. Dan stopt ineens de javascript powered navigation met werken? Da's not done. De basis zou toch op z'n minst zonder javascript moeten werken.

Dat is natuurlijk een beetje vreemd argument tegen JavaScript gebruiken. Wat nu als er een fout in de HTML is geslopen? Voor de zekerheid maar geen HTML gebruiken?

edit: spuit 11..

[ Voor 3% gewijzigd door EddoH op 27-11-2014 14:04 ]

[VanWilder]

Je hebt zeker een punt. Maar een fout in de html gaat zeker door het testing team worden opgepikt. Javascript is hier in veel complexer en kan bijvoorbeeld door een variable input stuk gaan.

[WernerL]

Douweegbertje schreef op donderdag 27 november 2014 @ 13:55:


Lekkere simpele gedachte; jij maakt zeker nog < IE6 proof websites met de usability wat men -nu- wilt? Geen JS, geen png, geen html5, werkbaar op een resolutie van ~ 680, met toch o.a. wat responsive materiaal voor elk device wat we nu tegenwoordig hebben waarbij je daarna nog rekening houdt met de ontwikkelkosten die marktconform de rest is?

Nee IE6 ondersteun ik niet meer, maar websites (dus niet applicaties) zijn over het algemeen behoorlijk statisch. Ik kan geen enkele geldige reden bedenken waarom Javascript noodzakelijk zou moeten zijn voor de werking van een website.

Responsive design is prima voor elkaar te krijgen met media queries, daar heb je geen JS voor nodig.

[Dido]

EddoH schreef op donderdag 27 november 2014 @ 14:03:
Dat is natuurlijk een beetje vreemd argument tegen JavaScript gebruiken. Wat nu als er een fout in de HTML is geslopen? Voor de zekerheid maar geen HTML gebruiken?

Natuurlijk. Eerst een volledige fallback naar HTML 1.0, en als zelfs dat niet werkt serveren we een plain text ASCii file.
Mocht dat ook falen, dan kan de gebruiker ons servicenummer bellen en wordt de tekst van de website voorgelezen.

* Dido werkt nu aan de back-up implementatie daarvan, maar heeft nog problemen met de bevestiging van kleitabletten aan de postduiven.

Auto's hoeven ook niet meer met een zwengel startbaar te zijn, toch?

[EddoH]

Die kun je in ieder geval nog wel aanduwen

[ Voor 7% gewijzigd door EddoH op 27-11-2014 14:07 ]

[VanWilder]

[jip_86]

StM schreef op donderdag 27 november 2014 @ 13:21:
Voornamelijk uit veiligheid ja. En de reductie in laadtijd van 90% is ook niet onaangenaam.

En dan ben je die vervolgens weer kwijt met uitzoeken waarom die website zo raar doet en dat te kunnen omzeilen, of valt dat mee?

[Comgenie]

Voor "Webapplicaties" ga ik er altijd vanuit dat de gebruikers Javascript aan hebben staan. Normale websites (informatie, foto's. etc.) werkt wel prima zonder Javascript. Vooral omdat daarvan vaak het belang is dat deze goed door Google kunnen worden opgenomen terwijl de webapplicaties meestal achter een inlog muur zit.

[Dido]

Comgenie schreef op donderdag 27 november 2014 @ 14:10:
terwijl de webapplicaties meestal achter een inlog muur zit.

Gewoon inloggen met JS. Weet je zeker dat alles na de inlog op JS kan vertrouwen

[.Gertjan.]

Dido schreef op donderdag 27 november 2014 @ 14:11:
[...]

Gewoon inloggen met JS. Weet je zeker dat alles na de inlog op JS kan vertrouwen

En anders in de css:

Cascading Stylesheet:

body { visibility: hidden; }

en in de pagina's:

HTML:

<script>
    $(document).ready(function() { $("body").css("visibility", "visible"); });
</script>

Zien ze niet eens de login pagina

[wackmaniac]

Vaak kan je AJAX-aanroepen wel unobtrusive maken en kan je veel effectjes tegenwoordig met css wel regelen. Als javascript dan toch echt onontbeerlijk is, dan toon ik een melding dat de pagina beter werkt met javascript.

Andere optie is gewoon js-only maken en wachten tot ze komen klagen dat niet alles werkt.

[Soundless]

wackmaniac schreef op donderdag 27 november 2014 @ 14:15:
Vaak kan je AJAX-aanroepen wel unobtrusive maken en kan je veel effectjes tegenwoordig met css wel regelen. Als javascript dan toch echt onontbeerlijk is, dan toon ik een melding dat de pagina beter werkt met javascript.

Andere optie is gewoon js-only maken en wachten tot ze komen klagen dat niet alles werkt.

Dus we kunnen er wel vanuit gaan dat iedereen een HTML5/CSS3 compatible browser heeft maar we kunnen er niet vanuit gaan dat iedereen JS aan heeft staan?

[Martijn19]

Ben blij dat ik alleen webapps/sites maak voor een technische doelgroep dat moderne browsers heeft met dus JS aan.

[Dido]

wackmaniac schreef op donderdag 27 november 2014 @ 14:15:
Andere optie is gewoon js-only maken en wachten tot ze komen klagen dat niet alles werkt.

Laten klagen via een feedback-optie op de site, die uiteraard niet werkt zonder JS

Semi-related, ik heb daadwerkelijk ooit geklaagd bij XS4ALL omdat die, toen ik ze belde naar aanleiding van een storing, een langdradig bandje afspeelden waarop me verteld werd naar hun website te gaan om te controleren of er eeen storing was
(Ja, dat hebben ze aangepast)

Martijn19 schreef op donderdag 27 november 2014 @ 14:21:
Ben blij dat ik alleen webapps/sites maak voor een technische doelgroep dat moderne browsers heeft met dus JS aan.

Totale noobs op een afgeschermd netwerk die pre-installed clients hebben waar ze niets (blijvend) kunnen aanpassen helpt ook. Heerlijk, totdat een of andere overzealous sysadmin dus in een policy overal JS eruit dondert.

(De sharepoint-jongens waren particularly not amused)

[ Voor 30% gewijzigd door Dido op 27-11-2014 14:25 ]

[Gleighton]

[...] De actuele storingen zijn te vinden op: h-t-t-p-dubbele-punt-w.w.w.-x-s-vier-a-l-l-punt-en-el-schuine-streep-storingen-punt-h-t-m-l [...] Zoiets?

[Dido]

Gleighton schreef op donderdag 27 november 2014 @ 14:24:
[...] De actuele storingen zijn te vinden op: h-t-t-p-dubbele-punt-w.w.w.-x-s-vier-a-l-l-punt-en-el-schuine-streep-storingen-punt-h-t-m-l [...] Zoiets?

je vergeet schuine-streep-schuine-streep

Maar daar kwam het wel bijna op neer. Handige was dat hun DNS de geest had gegeven en me niet eens meer naar hun homepage kreeg.

[Gleighton]

Shit, je hebt gelijk ja. Nouja bijna weekend dan maar.

[TheNephilim]

Bah, internet is traag hier

--- Edit ---

Ah, er is iemand wat aan het uploaden

[ Voor 50% gewijzigd door TheNephilim op 27-11-2014 14:32 ]

[Soundless]

TheNephilim schreef op donderdag 27 november 2014 @ 14:29:
Bah, internet is traag hier

Als je JS uitzet gaat het blijkbaar 90% sneller

[dcm360]

Hm, zou het rare gevolgen hebben als de tikfout 'bmw' in plaats van 'btw' opgelost wordt door de vertaling aan te passen? Welnee...

[incaz]

@javascriptdiscussie: ik zet het steeds vaker uit omdat het zo misbruikt wordt voor allemaal zaken die de pagina minder leesbaar maakt. (Irritante scrollende zaken, balken die te onpas in beeld komen, popups voor weet ik wat.)

En als het niet werkt, probeer ik eerst een andere site te vinden die wel leesbaar is.

[mbarie]

In mijn ogen is javascript simpelweg noodzaak om een goede gebruikersvriendelijke webapplicatie te bouwen. Er zijn veel interacties die er baat bij hebben en veel aangenamer verlopen door een beetje scripting.

Dat gezegd hebbende zijn er helaas erg veel sites die het misbruiken. Mijn werkgever heeft er af en toe ook een handje van Javascript in te zetten om die paar extra clicks binnen te halen ten koste van de ervaring en leesbaarheid. Maar ze lijken een omslag gemaakt te hebben (in wat mij betreft de goede richting). Time will tell .

[ Voor 6% gewijzigd door mbarie op 27-11-2014 15:23 ]

[Otherside1982]

Otherside1982 schreef op donderdag 27 november 2014 @ 09:21:
Leuk probleempje, ik roep een functie op met een parameter met de waarde 1. In die functie zitten er verschillende if/else stukken waarbij er getest wordt of die parameter = 1. Volgens de debugger is die parameter 1, maar toch wordt de else tak uitgevoerd.

Oorzaak gevonden, ook al begrijp ik het niet echt. Het gaat om bestaande code die een query opbouwt, uitvoert en het resultaat in excel zet. Ik was enkel geinteresseerd in de opgebouwde query, dus had ik even snel een

Delphi:

raise Exception.Create(query.SQL.Text);

toegevoegd. Blijkbaar verandert die raise exception iets, want zonder die toevoeging werkt de code prima. Met de raise exception veranderde de waarde van de parameter blijkbaar, in de callstack stond dan ipv 1 de waarde 15666680, terwijl de debugger nog steeds waarde 1 toonde.

[mbarie]

Bugger

[alienfruit]

Hmm, ORM layer gooit de records niet weg maar zet gewoon de foreign columns op NULL

[wackmaniac]

Klinkt als een stukje topsoftware

[_Moe_]

wackmaniac schreef op donderdag 27 november 2014 @ 16:26:
Klinkt als een stukje topsoftware

Had hetzelfde idee

[Firesphere]

TheNephilim schreef op donderdag 27 november 2014 @ 14:29:
Bah, internet is traag hier

--- Edit ---

Ah, er is iemand wat aan het uploaden

Hoe kan uploaden de download vertragen?

[mbarie]

ADSL heeft daar toch o.a. last van?

[Dido]

Firesphere schreef op donderdag 27 november 2014 @ 16:30:
Hoe kan uploaden de download vertragen?

Acknowledgment van je received packages moeten geupload worden tijdens downloaden. Dus als iemand je upload dichtduwt kan het zijn dat je download beinvloed wordt.

[TheNephilim]

Inderdaad DSL hier... dus dan heb je dat soort dingen nog!

Er is laatst iemand geweest voor glasvezel, maar dat wordt weer veel te duur natuurlijk...

[alienfruit]

Ik wilde glasvezel aanleggen bij ons in het huis alleen mocht niet van de huisbaas. Aansluiting koste ook 5.000euro ofzo, lol. Niet dat hij het hoefde te betalen

[ Voor 13% gewijzigd door alienfruit op 27-11-2014 16:54 ]

[mbarie]

nou ja, als jij het betaald kan ik niet inzien waarom hij daar moeite mee heeft .

[alienfruit]

Er moesten gaten worden geboord etc.

[Douweegbertje]

alienfruit schreef op donderdag 27 november 2014 @ 16:56:
Er moesten gaten worden geboord etc.

Dan nog, win win situatie voor de huisbaas. Geen kosten, maar wel vernieuwing.