De Devschuur Coffee Corner - Iteratie 2

[Dido]

Zou je verwachten dat not-online.nl online is of juist niet

* Dido is confused

[lauwsa]

Flowmo schreef op donderdag 17 januari 2013 @ 14:25:
[...]

Binnen garantieperiode? Dan ligt bewijslast aan hun kant, niet bij jou.

wsitedesign schreef op donderdag 17 januari 2013 @ 14:23:
[...]


Wow, dat is wel redelijk grof naar de klant toe... Viel het nog onder garantie (ik ga ervan uit van wel)? Probeer eens contact met de fabrikant op te nemen zou ik zo zeggen.

Het is een best complex verhaal, in Nederland kan je "garantie" krijgen zo lang de levensduur van het product. Ik had het product 2,5 jaar terwijl er 2 jaar garantie op zat. Ik had aangegeven dat ik een problemen had en dat ik op de “extra garantie” beroep wil doen. Ze reageerde hier niet op, ik kreeg uiteindelijk mijn zin door via een andere instantie om bemiddeling te vragen. Ik had uiteindelijk alles naar mijn mening bewezen, hun vonden dat dit niet genoeg was dus ik dacht: Laat het maar maar bij zitten.

Toen ik mijn product weer ophaalde zag ik dat ze een “reparatie” geprobeerd hadden uit te voeren. Ik zei dat ik hier geen akkoord voor gegeven had en dat ik dit dus niet vond kunnen. Uiteindelijk waren we het er over eens als er wat mis zou gaan dat hun het dan zouden oplossen.

1 week later begon mijn videokaart heel veel kuren te vertonen. Ik kreeg bijvoorbeeld een wit scherm met strepen er door heen. Ik dus weer terug mailen naar Zercom, geen reactie voor een paar weken. Nog een mail, weer niks. Ik dus er heen gegaan, kreeg ik te horen dat ik ze maar moest aanklagen.

[CodeCaster]

Soultaker schreef op donderdag 17 januari 2013 @ 14:35:
Ah zo. Dat is niet eens zo'n slecht idee. Dan zou de browser de waarde van Accept-Language op website-basis moeten aanpassen (anders weet de server nog niet wat 'ie voor taal moet serveren), maar dat is niet onredelijk. Ik ben voor!

Dank.

Hoe bedoel je jouw "per website aanpassen"-opmerking? Stel een gebruiker heeft in zijn browser de volgende instellingen:

Primaire taal: Nederlands
Tweede voorkeur: Engels
Derde voorkeur: Frans

Dan wordt de volgende header opgebouwd naar iedere website (willekeurige q-waarden, nader te bepalen):

code:

Accept-Language: nl;q=1.0, en;q=0.8, fr;q=0.5

Wanneer nu een willekeurig document met deze headers wordt opgevraagd, moet de server berekenen welke representatie het beste past. Stel dat voor dat document de volgende talen met bijbehorende rating beschikbaar zijn op de server:

code:

en-US;q=1.0
fr-FR;q=0.8
da-DK;q=0.5
nl-NL;q=0.5

Een algoritme moet worden uitgedacht (volgens mij staat dat niet gespecificeerd in 2616, maar zie hier hoe Apache het implementeert), maar een eenvoudige vermenigvuldiging van Accept-language en Content-languages (waarbij niet-vermelde talen een rating van 0 krijgen) levert het volgende op:

code:

en-US = (en;q=0.8 * en-US;q=1.0) = 0.8
nl-NL = (nl;q=1.0 * nl-NL;q=0.5) = 0.5
fr-FR = (fr;q=0.5 * fr-FR;q=0.8) = 0.4
da-DK = (0 * da-DK;q=0.5) = 0

Hierbij zal dus de Engelse versie worden gepresenteerd, omdat de server vindt dat de Nederlandstalige een lagere qvalue (en dat kan afhankelijk zijn van bijvoorbeeld de kwaliteit van de vertaling) heeft.

Bij gelijke resultaten (stel dat en-US een qvalue van 0.625 had, waardoor de berekende waarde hiervoor net als bij nl-NL 0.5 zou worden) wordt de volgorde uit de request aangehouden, en zou het resulterende document als nl-NL worden geserveerd.

In ieder geval kan de browser nu een menu tonen met de opties, omdat hij aan de hand van de Content-languages-header kan zien dat er meerdere talen beschikbaar zijn:
[quote]
Toon deze pagina in de volgende taal:
• en-US
• fr-FR
• da-DK
• nl-NL

[ Voor 19% gewijzigd door CodeCaster op 17-01-2013 15:20 ]

[StM]

Ik zou het meer zien als iets van een browser doet de eerste keer eerst een OPTIONS request, krijgt terug welke talen er zijn, kan vragen aan de gebruiker welke taal hij wilt of dit bepalen aan de hand van de settings en stuurt nu de echte request met een Accept-Language die hoort bij de taal die de voorkeur heeft.

Reageert de server niet op de OPTIONS dan valt het systeem terug naar de oude manier.

[ Voor 12% gewijzigd door StM op 17-01-2013 15:00 ]

[CodeCaster]

Ik weet niet of je zat te spieken tijdens mijn vorige edit (ik noemde ook even een aparte request), maar daarmee verdubbel je in één klap het aantal HTTP-requests dat browsers wereldwijd sturen. Dat is geen optie.

kan vragen aan de gebruiker welke taal hij wil

Daar wil je de gebruiker niet mee lastigvallen. De browser weet al welke taal de gebruiker het meest waardeert (op basis van systeeminstellingen en eventueel in de browser ingestelde voorkeuren) en de server serveert op basis hiervan het meest passende document. Wil de gebruiker een andere taal, dan moet die daar zelf actie voor ondernemen.

[ Voor 75% gewijzigd door CodeCaster op 17-01-2013 15:06 ]

[Firesphere]

Ik voel me een beetje alsof ik net inception heb geschreven...
Klant wil een contactformulier. Prima
Klant wil onderaan een mailto-link. Onder een contactformulier. Nou ja, het zal wel...
OP FACEBOOK!

[StM]

Je hebt alleen iedere pagina een request nodig als niet de hele site in alle talen beschikbaar is en je geen terugval mogelijkheid hebt. Als je afspreekt de OPTIONS slechts eenmalig te doen op / en deze info cached dan hoeft de server niet de beste optie te gaan berekenen maar kan deze gewoon naar de client luisteren en accept-languages volgen die de client aanpast aan zijn behoeften en beschikbaarheid van de volgens de server aangeboden talen.

Minst brekende manier om het te implementeren imo

[CodeCaster]

Volgens mij breekt mijn suggestie niets, omdat content negotiation nu al werkt. Ik voeg alleen een extra header toe, zodat de server aan de browser kan vertellen dat er behalve zijn berekende voorkeurstaal ook nog andere talen beschikbaar zijn. Je krijgt dus altijd, met één request, het "best passende" document te zien.

Wanneer de gebruiker hiervoor kiest, kan de browser hierna een verzoek sturen met een andere Accept-language-header, namelijk een waarin alleen die specifieke taal wordt genoemd of waarin die taal een hogere qvalue dan de rest krijgt, en deze taal eventueel cachen voor de site / sessie / whatever zodat opvolgende requests in de geselecteerde taal worden weergegeven (indien beschikbaar).

Om dit te laten werken, moeten servers (beter gezegd, CMS'en en dergelijke) dus weer helemaal afstappen van geolocatie op IP-adres (maar ook van vlaggetjes ) en juist weer de language-headers correct gebruiken.

[ Voor 88% gewijzigd door CodeCaster op 17-01-2013 15:19 ]

[StM]

En wat als de taal voor die specifieke pagina niet bestaat? Je zal andere talen moeten weigeren als jij de voorkeur geeft aan de half vertaalde west Friese versie van de pagina (Q 1 voor jezelf maar Q 0.2 op de server). De site is echter maar voor de helft beschikbaar in die taal. In mijn geval switch je dan gewoon om naar Engels of Nederlands. Ik vind dat de client in control moet zijn over welke taal zijn voorkeur heeft en niet dat de server aan de hand van de voorkeuren van de gebruiker de beste versie naar zijn interpretatie terug gaat sturen. En die kan dan terug vallen op de volgende voorkeurstaal mocht het voor die pagina niet bestaan.

Het enigste is dat je 1 extra request nodig hebt om de client te vertellen welke talen er allemaal mogelijk gaan zijn tijdens zijn bezoek. En dan bv de Content-languages q waarde koppelen aan het percentage van de site dat correct vertaald is volgens de beheerder.

[Soultaker]

CodeCaster schreef op donderdag 17 januari 2013 @ 14:55:
Hoe bedoel je jouw "per website aanpassen"-opmerking?

Momenteel is het al zo dat een client taalvoorkeuren van de gebruiker naar de server stuurt, en dat de server op basis daarvan gecombineerd met de beschikbare talen een keuze maakt van de taal waarin 'ie een resource serveert (met een soortgelijk algoritme als je beschrijft). Welke taal de server gekozen heeft is te zien aan de Content-Language.

Als ik het goed begrijp stel jij voor dat de server niet alleen de gekozen Content-Language, maar ook alle beschikbare talen terugstuurt. Dat is natuurlijk alleen zinning als de client daar ook wat mee doet: bijvoorbeeld door de beschikbare talen ergens met een icoontje weer te geven zodat de gebruiker een custom taal kan kiezen voor die website. Dat is dan de in-browser equivalent van de vlaggetjes/dropdownboxes die je nu op veel websites ziet.

De browser moet de gekozen waarde dan ook weer meesturen in volgende requests, dus bijvoorbeeld door de Accept-Language header in volgende requests binnen dezelfde site aan te passen aan de gekozen taal. Ik ga er vanuit dat die keuze websitespecifiek is, want als het een globale preference is, dan kun je net zo goed de oorspronkelijke Accept-Language waarden gebruiken.

Het voordeel zou dan zijn dat er een door de browser gestandaardiseerde manier is om de taalvoorkeur in te stellen, in plaats van dat elke site zelf maar wat aanmoddert met sessies en cookies en vlaggetjes en aparte pagina's. Dat kan nu ook al (mits websites de Accetp-Language header respecteren, wat ze doorgaans niet doen, helaas) maar met jou systeem zou je veel makkelijker die taal per website kunnen kiezen.

StM schreef op donderdag 17 januari 2013 @ 15:22:
En wat als de taal voor die specifieke pagina niet bestaat?

Dat probleem heb je nu ook al; dan serveert de server de default-taal (meestal Engels).

Het enigste is dat je 1 extra request nodig hebt om de client te vertellen welke talen er allemaal mogelijk gaan zijn tijdens zijn bezoek.

Dat hoeft helemaal niet; de website mag best iets gokken (zoals nu ook al gebeurt — vaak is die gok dan Engels) als de client de keuze maar makkelijk kan aanpassen. Aanpassen kost een extra request, maar dat geldt ook voor het huidige systeem met icoontjes op de webpagina zelf.

[ Voor 16% gewijzigd door Soultaker op 17-01-2013 15:30 ]

[jbdeiman]

Wat nou als je in je browser een set aan voorkeuren aan kan geven in een bepaalde volgorde? De pagina/ server kan dan toch zelf kijken welke van de talen als eerste in de voorkeur staat, en deze alvast teruggeven.
Dat in combinatie met informatie over de overige beschikbare talen voor de betreffende pagina kan al heel veel helpen. Dan in de browser bewaren welke keuze gemaakt is voor een bepaalde website (of bij inloggen bij het gebruikersaccount) en je hebt een naar mijn idee vrij volledig systeem waarbij het ook niet nodig is dat er veel meer verkeer heen en weer wordt gezonden.

Bij de aanvraag krijg je meteen al binnen wat de voorkeursset is van de browser en de server kan daar (eventueel) op reageren.

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 15:22:
En wat als de taal voor die specifieke pagina niet bestaat?

Het enigste is dat je 1 extra request nodig hebt om de client te vertellen welke talen er allemaal mogelijk gaan zijn tijdens zijn bezoek.

Hoe gaat één OPTIONS-request op de root van de site jou vertellen welke subresources wel en niet vertaald zijn?

Je zal andere talen moeten weigeren als jij de voorkeur geeft aan de half vertaalde west Friese versie van de pagina (Q 1 voor jezelf maar Q 0.2 op de server).

Dat wordt door het algoritme opgelost. Er is daardoor voor iedere resource die bestaat per definitie een versie met die het beste "past". Als er maar één taal bestaat, is het die versie die geretourneerd wordt. Als de gebruiker bij wijze van spreken alleen vraagt om "nl-NoordOostFries", maar de server heeft van dat document alleen een en-US, dan krijgt de gebruiker een 406 (Not Acceptable) waarbij wordt vermeld dat alleen een en-US beschikbaar is, of gewoon de en-US-versie.

En ja, dat kan tot gevolg hebben dat je de ene klik in het Fries zit te lezen, de volgende in het Duits en weer een volgende in het Engels, maar dat is geen probleem dat op een andere manier is op te lossen.

De site is echter maar voor de helft beschikbaar in die taal. In mijn geval switch je dan gewoon om naar Engels of Nederlands. Ik vind dat de client in control moet zijn over welke taal zijn voorkeur heeft en niet dat de server aan de hand van de voorkeuren van de gebruiker de beste versie naar zijn interpretatie terug gaat sturen. En die kan dan terug vallen op de volgende voorkeurstaal mocht het voor die pagina niet bestaan.

Dat is juist hoe het nu overal zo'n beetje werkt, zie:

Soultaker schreef op donderdag 17 januari 2013 @ 15:26:
Momenteel is het al zo dat een client taalvoorkeuren van de gebruiker naar de server stuurt, en dat de server op basis daarvan gecombineerd met de beschikbare talen een keuze maakt van de taal waarin 'ie een resource serveert (met een soortgelijk algoritme als je beschrijft). Welke taal de server gekozen heeft is te zien aan de Content-Language.

Maar dus (vaak) op de "verkeerde" manier, namelijk niet door de Accept-language-header maar vaak door geolocatie, of door handmatige acties met vlaggetjes, cookies en zelfs hele subdomeinen of -directories. Dit komt doordat de Accept-language-header een beetje een ondergeschoven kindje is en niet gemakkelijk door de gebruiker te bewerken, laat staan per website.

---

Als ik het goed begrijp stel jij voor dat de server niet alleen de gekozen Content-Language, maar ook alle beschikbare talen terugstuurt. Dat is natuurlijk alleen zinning als de client daar ook wat mee doet: bijvoorbeeld door de beschikbare talen ergens met een icoontje weer te geven zodat de gebruiker een custom taal kan kiezen voor die website. Dat is dan de in-browser equivalent van de vlaggetjes/dropdownboxes die je nu op veel websites ziet.
[...]
Het voordeel zou dan zijn dat er een door de browser gestandaardiseerde manier is om de taalvoorkeur in te stellen, in plaats van dat elke site zelf maar wat aanmoddert met sessies en cookies en vlaggetjes en aparte pagina's. Dat kan nu ook al (mits websites de Accetp-Language header respecteren, wat ze doorgaans niet doen, helaas) maar met jou systeem zou je veel makkelijker die taal per website kunnen kiezen.

Klopt.

De browser moet de gekozen waarde dan ook weer meesturen in volgende requests, dus bijvoorbeeld door de Accept-Language header in volgende requests binnen dezelfde site aan te passen aan de gekozen taal. Ik ga er vanuit dat die keuze websitespecifiek is, want als het een globale preference is, dan kun je net zo goed de oorspronkelijke Accept-Language waarden gebruiken.

Ah, zo. Dat moet inderdaad per site worden onthouden.

[ Voor 5% gewijzigd door CodeCaster op 17-01-2013 15:43 ]

[Ook al Bezet]

CodeCaster schreef op donderdag 17 januari 2013 @ 12:57:
[...]

Mijn vraag is: is dat wel een probleem, of is het vergelijkbaar met negerzoenen? Ik heb ook al aangegeven dat het inderdaad aan mij kan liggen dat ik het probleem niet zie, ik kom namelijk niet uit een land waarbij de vlag niet representatief is voor de taal die er voornamelijk wordt gesproken en kan me ook niet goed inleven in de situatie waar dat wel het geval is. Bijvoorbeeld bij China / Taiwan, wat wordt aangehaald in jouw link, kan ik enigszins inkomen, maar dan nog: ze spreken Chinees in Taiwan, een taal die zo heet omdat hij zijn oorsprong vindt in China, wat is er volgens die logica mis met een Chinese vlag? Dat "Taiwanese users especially may be offended by the use of the Chinese flag."? Hebben ze dat aan Taiwanezen gevraagd, of is het de ongevraagde en misschien incorrecte interpretatie van wereldverbeteraar?

Zoals Soultaker al aanhaalt is het Chinees dat ze op het vasteland gebruiken sowieso niet zo geschikt voor Taiwanezen, het schrift is daar wat anders. Maar, dat ze zich beledigd zouden voelen is niet zo heel vreemd, die rode vlag is immers van de Volksrepubliek China, niet van de Republiek China (beter bekend als Taiwan). Het is een beetje alsof je iemand uit de DDR een vlag van de BRD zou voorschotelen, al leken die veel meer op elkaar.

[Dido]

Ook al Bezet schreef op donderdag 17 januari 2013 @ 15:36:
Het is een beetje alsof je iemand uit de DDR een vlag van de BRD zou voorschotelen, al leken die veel meer op elkaar.

Ach, meegemaakt dat voor onze Belgische gebruikers de Duitse vlag gekanteld gebruikt werd. Zelfde kleuren toch? Vinden ze vast niet erg.

[Rutix]

Moet nog steeds lachen als ik deze zien XD http://thejoysofcode.com/...en-the-network-ping-sucks

[StM]

CodeCaster schreef op donderdag 17 januari 2013 @ 15:31:

Hoe gaat één OPTIONS-request op de root van de site jou vertellen welke subresources wel en niet vertaald zijn?

Niet, maar in jouw geval vlieg je ook van vertaling naar vertaling. In beide gevallen val je gewoon terug op de next best taal, alleen in jouw geval bepaald de server dit per resource en bij mij voor de website globaal door de client.

[...]

Dat wordt door het algoritme opgelost. Er is voor iedere resource die bestaat per definitie een versie met de hoogste qvalue. Als er maar één taal bestaat, is het die versie die geretourneerd wordt. Als de gebruiker bij wijze van spreken vraagt om "nl-NoorOostFries", maar de server heeft van dat document alleen een en-US, dan krijgt de gebruiker en-US.

En ja, dat kan tot gevolg hebben dat je de ene klik in het Fries zit te lezen, de volgende in het Duits en weer een volgende in het Engels, maar dat is geen probleem dat op een andere manier is op te lossen.


[...]

Dat is juist hoe het nu overal zo'n beetje werkt, zie:

Dat is juist niet hoe het nu werkt. Ik wil het achterliggende systeem in tact laten maar toevoegen dat de client op basis van extra informatie van de website kan selecteren wat zijn voorkeurstaal voor DIE website is. Die kan automatisch aan de hand van instellingen of via een taalkeuze wat voor die website de prioriteit van de betreffende taal boost de juiste pagina laten serveren.

Combineer mijn OPTIONS systeem met per resource ook nog eens die header en je kan het als client helemaal exact bepalen wat je wilt hebben. Enigste is dat in sommige gevallen je een resource 2x op moet halen.

Naar mijn mening hoort de server zich niet te bemoeien met welke content jij wilt hebben. Iets waar je juist dit systeem voor bedenkt

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 15:41:
In beide gevallen val je gewoon terug op de next best taal, alleen in jouw geval bepaald de server dit per resource en bij mij voor de website globaal door de client. [...] Naar mijn mening hoort de server zich niet te bemoeien met welke content jij wilt hebben. Iets waar je juist dit systeem voor bedenkt

Het is nog altijd de server die de resources bevat. De client kan wel heel hard roepen dat 'ie alleen Nederlands praat, maar als de server alleen Engels spreekt, kun je kiezen tussen een 406 gooien of toch Engels serveren:
 

quote: http://tools.ietf.org/html/rfc2616#section-10.4.7

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.

[StM]

Ja, alleen in jouw geval heeft de website zowel Nederlands als Engels maar vind het algoritme de combinatie van prioriteit van de client en kwaliteit te laag en stuurt alsnog de Engelse versie.

[Haan]

Voor de mensen die niet in de HK (kunnen) komen: outsourcen als een baas

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 15:48:
Ja, alleen in jouw geval heeft de website zowel Nederlands als Engels maar vind het algoritme de combinatie van prioriteit van de client en kwaliteit te laag en stuurt alsnog de Engelse versie.

Oh, zo. Dat zal dan een optie moeten worden in de browser: "Forceer voorkeurstaal ongeacht de kwaliteit", waardoor de browser in dat geval alleen een Accept-language: nl stuurt. Dan ben je er toch?

Als er dan helemaal geen Nederlandse versie beschikbaar is, krijg je de "best guess" van de server (want nogmaals, één request op de root zegt niets over onderliggende resources, zie bijvoorbeeld blogspot.com). Je wil sowieso geen twee requests doen voor één resource, laat staan met user-interactie ertussen ("Ik heb geen Nederlandstalige gevonden, wel een goede Engelse en een brakke Duitse, welke wil je?").

[ Voor 30% gewijzigd door CodeCaster op 17-01-2013 15:56 ]

[StM]

CodeCaster schreef op donderdag 17 januari 2013 @ 15:53:
[...]

Oh, zo. Dat zal dan een optie moeten worden in de browser: "Forceer voorkeurstaal ongeacht de kwaliteit", waardoor de browser in dat geval alleen een Accept-language: nl stuurt. Toch?

Waarom zou je dan opeens als client specifiek om een bepaalde taal moeten gaan vragen als je al om die taal
met een hogere prioriteit vroeg? Alleen maar omdat de server zo verrekte eigenwijs is.

Ik wil de huidige content negotiation gewoon volledig laten zoals het is echter de client de mogelijkheid geven om slimmere verzoeken naar de server te sturen (waar hij dus wat extra informatie voor nodig heeft, hoewel de brute force methode van gewoon bij het eerste verzoek de voorkeurstaal(en) sturen en daarna slim er op inspelen uiteraard ook kan). En de server heeft die (ALS het beschikbaar is uiteraard) maar gewoon te honoreren.

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 15:56:
Waarom zou je dan opeens als client specifiek om een bepaalde taal moeten gaan vragen als je al om die taal met een hogere prioriteit vroeg? Alleen maar omdat de server zo verrekte eigenwijs is.

Die server heeft daar in dat geval een reden voor, namelijk dat de vertaling slecht (bijvoorbeeld automatisch) of slechts gedeeltelijk is gedaan. De qvalue die de server aan nl-NL geeft is niet voor de grap lager dan die van en-US.

Als een qua kwaliteit vergelijkbare zowel Nederlandstalige als Engelstalige versie beschikbaar zijn, krijgen deze beide een qvalue van 1 en bepaalt de server aan de hand van de qvalue van de Accept-language-request-header (in jouw geval dus nl) welk document geretourneerd wordt.

Als er verschillen in kwaliteit zijn en hierdoor niet de versie in de voorkeurstaal van de gebruiker wordt geserveerd, dan ziet de browser door de Content-languages-header wel dát er andere talen beschikbaar zijn dan de ontvangen versie, en kan dit aan de gebruiker melden.

Als de gebruiker dan, ondanks de (volgens de server) mindere kwaliteit toch de voorkeursversie wil, klikt 'ie in z'n browser op Taal -> Nederlands en doet de browser een nieuwe request met enkel nl als Accept-language, eventueel dus met een "Onthoud dit voor deze site" of "Vraag altijd alleen de Nederlandstalige op" (zie vorige post). Dit kan net zo goed standaardgedrag zijn, door een browser na een verse installatie alleen de ingestelde taal van de gebruiker te verzenden (dus alléén nl).

[ Voor 38% gewijzigd door CodeCaster op 17-01-2013 16:08 ]

[Soultaker]

StM schreef op donderdag 17 januari 2013 @ 15:56:
Waarom zou je dan opeens als client specifiek om een bepaalde taal moeten gaan vragen als je al om die taal met een hogere prioriteit vroeg? Alleen maar omdat de server zo verrekte eigenwijs is.

In theorie zou het huidige systeem op basis van globale preferences kunnen werken, maar in de praktijk blijkt dat websites nogal inconsistent zijn in de kwaliteit van vertalingen, en gebruikers hun voorkeuren niet altijd goed hebben ingesteld.

Zowel gebruikers als websitemakers willen dus van taal kunnen switchen; dat is het gegeven waarop de discussie gebaseerd is.

CodeCaster probeert een manier te verzinnen om dat te faciliteren die consistenter en gebruiksvriendelijker is dan wat nu gebeurt. Je kunt wel antwoorden dat het aanpassen van de taal helemaal niet nodig zou moeten zijn, maar daarmee ontken je de realiteit, dat daar wél grote behoefte aan is, zelfs (of misschien zelfs vooral) bij serieuze websites.

[StM]

Soultaker schreef op donderdag 17 januari 2013 @ 16:05:
[...]

In theorie zou het huidige systeem op basis van globale preferences kunnen werken, maar in de praktijk blijkt dat websites nogal inconsistent zijn in de kwaliteit van vertalingen, en gebruikers hun voorkeuren niet altijd goed hebben ingesteld.

Zowel gebruikers als websitemakers willen dus van taal kunnen switchen; dat is het gegeven waarop de discussie gebaseerd is.

CodeCaster probeert een manier te verzinnen om dat te faciliteren die consistenter en gebruiksvriendelijker is dan wat nu gebeurt. Je kunt wel antwoorden dat het aanpassen van de taal helemaal niet nodig zou moeten zijn, maar daarmee ontken je de realiteit, dat daar wél grote behoefte aan is, zelfs (of misschien zelfs vooral) bij serieuze websites.

Het verschil tussen CodeCaster en mij is dat ik de controle bij de client wil leggen aan de hand van meer informatie van de server waarna de client zijn accept lijstje anders kan prioriteren en CodeCaster de voorkeur geeft om aan de hand van het accept lijstje van de client de server het beste resultaat er bij te laten zoeken.

Beide zullen waarschijnlijk hetzelfde resultaat in de praktijk hebben alleen zal bij CodeCaster de wensen van de client overruled worden door de server en zal in mijn geval in bepaalde gevallen een resource 2x opgehaald moeten worden. Echter bij mij bepaald de client nog altijd wat er geserveerd gaat worden als het beschikbaar is.

En bij beide zal de gebruiker via de browser van taal kunnen switchen ipv op de website.

[ Voor 14% gewijzigd door StM op 17-01-2013 16:09 ]

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 16:07:
[...]


Het verschil tussen CodeCaster en mij is dat ik de controle bij de client wil leggen aan de hand van meer informatie van de server waarna de client zijn accept lijstje anders kan prioriteren en CodeCaster de voorkeur geeft om aan de hand van het accept lijstje van de client de server het beste resultaat er bij te laten zoeken.

Dat snap ik, maar het hele principe van content-negotiation is nou net dat de client aangeeft wat 'ie wil en dat de server op basis daarvan bepaalt welke resource(representatie) daar het beste bij past, op basis van gegevens over die resource die enkel bij de server beschikbaar zijn.

Deze gegevens kunnen wel eerst naar de client worden gestuurd na een OPTIONS / PROPFIND / HEAD-request voor die resource, maar dat zorgt zoals je zelf al zegt voor een extra roundtrip, die ik het liefst wil voorkomen.

Misschien ga ik maar eens een poging doen een serieus mailtje op te stellen ook. Eens kijken wat Julian Reschke en consorten hierover te zeggen hebben.

[ Voor 11% gewijzigd door CodeCaster op 17-01-2013 16:14 ]

[StM]

Het alternatief wat ik daarvoor noemde is om het eerste request zoals nu te laten dat de Accept-Languages voor alle websites hetzelfde is op basis van instellingen of indien de website reeds bezocht is de opgeslagen voorkeur hergebruiken. Daarna kan de client dan op basis van de extra meegestuurde informatie de prioritering gaan finetunen. Bijvoorbeeld door met kleuren de kwaliteit van een bepaalde vertaling in de browser te tonen. Als je ziet dat Nederlands dan rood wordt kan je als gebruiker naar een andere taal switch of instellen in de browser dat hij dan bijvoorbeeld als het even kan naar het Engels moet gaan.

[Verwijderd]

Rutix schreef op donderdag 17 januari 2013 @ 15:39:
Moet nog steeds lachen als ik deze zien XD http://thejoysofcode.com/...en-the-network-ping-sucks

En nog een pareltje

Overigens niet dat me dat ooit is overkomen hoor ...*kuch*

[PrisonerOfPain]

Vanochtend om 10 uur m'n checkout aan gezet en die is net klaar...

[kenneth]

Kan je nog net voor half zes Get latest version doen

[PrisonerOfPain]

Net al gedaan, die viel wel mee. De Stream waar ik op zit word niet zo heel veel naar gepushed. De integrate van de laatste game changes doe ik morgen wel, pff.

[PdeBie]

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 16:38:
Vanochtend om 10 uur m'n checkout aan gezet en die is net klaar...

say wut??
Die moet je me even uitleggen.


Deze is overigens ook briljant:
http://thejoysofcode.com/...ysics-engine-and-it-rocks

[PrisonerOfPain]

pdebie schreef op donderdag 17 januari 2013 @ 16:50:
[...]


say wut??
Die moet je me even uitleggen.

Hij was bijna een halve TB groot

[Otherside1982]

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 16:51:
[...]


Hij was bijna een halve TB groot

Zo weten wij meteen dat we **LEAKED** Battlefield 4.torrent van 2GB niet moeten downloaden, dat kan nooit de complete game zijn

---

Bugs proberen oplossen terwijl de testers volop bezig zijn is demotiverend: vanmorgen stonden er 19 issues open, nu 23, terwijl ik er wel al opgelost en afgesloten heb

[ Voor 22% gewijzigd door Otherside1982 op 17-01-2013 17:24 ]

[Pizzalucht]

Een checkout van een halve TB... Die past amper op mijn laptop

[PrisonerOfPain]

Pizzalucht schreef op donderdag 17 januari 2013 @ 17:29:
Een checkout van een halve TB... Die past amper op mijn laptop

Fun fact: het was sneller om de hdd te formatteren dan om de oude data van de vorige gebruiker met Shift+Delete te verwijderen.

[CodeCaster]

StM schreef op donderdag 17 januari 2013 @ 16:16:
[...]

Wil je het nog eens uitleggen met een scenario, want ik begrijp het nog steeds niet.

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 17:34:
[...]


Fun fact: het was sneller om de hdd te formatteren dan om de oude data van de vorige gebruiker met Shift+Delete te verwijderen.

Als 'ie vijf miljoen random accesses moet doen om bestanden in de MFT als verwijderd aan te merken gaat dan langzamer dan in één keer een schone MFT wegschrijven ja, lijkt me.

[Firesphere]

{hele lange query om een stapel objects op te halen} WHERE `ParentID` = {ID}

* Firesphere bekijkt de code nog eens heel goed.
Nergens in m'n hele code heb ik een ParentID gedefinieerd...

Hoe de hell komt het framework op het idee om een ParentID in de where te zetten

[CodeCaster]

Erft je model over van IChildEntity?

[PrisonerOfPain]

CodeCaster schreef op donderdag 17 januari 2013 @ 17:38:
Als 'ie vijf miljoen random accesses moet doen om bestanden in de MFT als verwijderd aan te merken gaat dan langzamer dan in één keer een schone MFT wegschrijven ja, lijkt me.

Inderdaad het verschil was ongeveer een 1-1.5 uur aan bespaarde tijd

[.oisyn]

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 16:51:
[...]


Hij was bijna een halve TB groot

En dan heb jij waarschijnlijk nog de mazzel dat de server gewoon in hetzelfde pand staat.

[Firesphere]

CodeCaster schreef op donderdag 17 januari 2013 @ 17:44:
Erft je model over van IChildEntity?

Nee, sterker nog, in de test-omgeving werkt het prima en wordt er ook geen ParentID meegegeven in de query. Wel een TabID, dat klopt. Ik heb't idee dat de live versie een mixup heeft.
In other words: Ik Het pareltje van Pankrates te pakken

[PrisonerOfPain]

.oisyn schreef op donderdag 17 januari 2013 @ 18:30:
[...]


En dan heb jij waarschijnlijk nog de mazzel dat de server gewoon in hetzelfde pand staat.

Gelukkig wel

[MLM]

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 16:51:
[...]


Hij was bijna een halve TB groot

SSDs voor source code, het is het waard
Ik mag hopen dat je halve TB niet alleen source-code is, dan mag je ook nog wel ff compilen morgen

[Avalaxy]

Aangezien hij games doet gok ik heel veel hele grote textures (en eventueel geluidsbestanden)?

[PrisonerOfPain]

MLM schreef op donderdag 17 januari 2013 @ 19:19:
[...]


SSDs voor source code, het is het waard
Ik mag hopen dat je halve TB niet alleen source-code is, dan mag je ook nog wel ff compilen morgen

Een full recompile duurt minder dan 10 minuten, daar word best wat tijd en moeite in gestoken om dat zo te houden. Art builden daarentegen

Avalaxy schreef op donderdag 17 januari 2013 @ 19:32:
Aangezien hij games doet gok ik heel veel hele grotes textures (en eventueel geluidsbestanden)?

MLM ook, maar inderdaad vooral mesh/texture/audio en een hoop metadata.

[armageddon_2k1]

Eindelijk eens een eigen domeintje en VPS geregeld. Heb nu bij DirectVPS een trial-vps van 7 dagen om te kijken hoe het bevalt. Ga denk ik wel een eigen VPSje regelen als de trial afloopt. Dat ga ik denk ik doen bij TransIp, omdat ik daar goede ervaringen mee heb.

Heerlijk, mijn eigen GitLab draaien en lekker mijn projectjes hosten en testen.

[PrisonerOfPain]

@MLM ik zit een beetje door je linkedin heen te klikken, blijkbaar zijn we collegas

[MLM]

PrisonerOfPain schreef op donderdag 17 januari 2013 @ 19:36:
@MLM ik zit een beetje door je linkedin heen te klikken, blijkbaar zijn we collegas

Mja ach, de meeste art-assets heb ik niet in mijn working copy staan. Maar goed, volgens mij zit jij op een wat andere schaal project, dus dat gaat ook niet meehelpen met omvang van je dependencies.

@PoP: Ik zal eens in de Communicator graven morgen

[ Voor 4% gewijzigd door MLM op 17-01-2013 19:55 ]

[PrisonerOfPain]

MLM schreef op donderdag 17 januari 2013 @ 19:53:
[...]
Mja ach, de meeste art-assets heb ik niet in mijn working copy staan. Maar goed, volgens mij zit jij op een wat andere schaal project, dus dat gaat ook niet meehelpen met omvang van je dependencies.

Ik moet wel, zeker aangezien we als engine team ook nog verantwoordelijk zijn voor meer dan een titel.

@PoP: Ik zal eens in de Communicator graven morgen

Cool

[dcm360]

armageddon_2k1 schreef op donderdag 17 januari 2013 @ 08:20:
Ik hoop dat die route van eergister niet je woon/werk verkeer is toch?

Gelukkig niet zeg Mn woon/werkverkeer is tussen Delft en Rijswijk, dat is wel goed vol te houden dagelijks. Eergisteren was een rondje langs diverse studentenverenigingen.

[Kips]

zo, laatste dagje van de week alweer! dagen gaan snel zo met het project waar ik aan mag werken... en gisteravond te horen gekregen dat ik voor het tentamen van vorige week een 8.1 had; wordt een prima weekend

[Hoogie2004]

Voor de geinteresseerden met een twitter account. Gratis dag Pluralsight access:
http://blog.pluralsight.c...ree-pluralsight-day-pass/

Even pluralsight volgen, je twitternaam invullen en je krijgt een DM op twitter met een code voor 1 dag gratis toegang (te gebruiken wanneer je wilt)

[ Voor 4% gewijzigd door Hoogie2004 op 18-01-2013 08:23 ]

[kenneth]

Hah! Ik wilde net dit weekend een abonnement afsluiten omdat ik één screencast wilde zien. Dank

[.Gertjan.]

Hoogie2004 schreef op vrijdag 18 januari 2013 @ 08:20:
Voor de geinteresseerden met een twitter account. Gratis dag Pluralsight access:
http://blog.pluralsight.c...ree-pluralsight-day-pass/

Even pluralsight volgen, je twitternaam invullen en je krijgt een DM op twitter met een code voor 1 dag gratis toegang (te gebruiken wanneer je wilt)

Gratis? De Hollander in mij heeft direct geregistreerd Fijn dat je de token kunt gebruiken wanneer je wilt. Vaak is het een vaste dag en zul je zien dat je die dag geen tijd hebt. Door het gebrek aan tijd (oa om rond te hangen op Tweakers) ben ik ook de mooie aanbieding van Resharper misgelopen eind vorig jaar

Ben net een kwartiertje bezig en mijn tijdtracker geeft al 41 gewerkte uren aan voor deze week... Een normaal mens zou zeggen "yes, klaar voor deze week", de ondernemer in mij zegt: "tijd om wat extra te cachen en klanten weer wat extra blij te maken door in te lopen op de planning"

Misschien vanmiddag even een paar uurtjes er tussen uit om met de camera het mooie winterlandschap vast te leggen.

[Ryur]

Bleg, nu al tijden aan het CSSen (mijn werkdag begon om 4 uur, doe ik zowat altijd).
Ik haat het echt, ben er echt niet in thuis. Binnenkort maar eens tijd vrij maken om goed te leren.

Gelukkig is dit voor een schoolproject, dus ik laat het nog geen eens zo netjes eruit zien (ook geen complete Wireframe enz gemaakt wat ik normaal wel doe).

.Gertjan. schreef op vrijdag 18 januari 2013 @ 09:57:
[...]
Om 4 uur?

Ja meestal begin ik tegen 4 uur/5 uur. Heb ik altijd er een halve werkdag opzitten als de werkdagen beginnen voor de meeste personen. En wanneer het ongeveer lunchtijd is, dan heb ik al mijn dag erop zitten.
Meestal ga ik 's middags door voor mezelf als ontplooi-activiteiten. Of soms ga ik verder als ik een deadline heb.

[ Voor 40% gewijzigd door Ryur op 18-01-2013 10:09 ]

[.Gertjan.]

GoTCoast schreef op vrijdag 18 januari 2013 @ 09:40:
Bleg, nu al tijden aan het CSSen (mijn werkdag begon om 4 uur, doe ik zowat altijd).
Ik haat het echt, ben er echt niet in thuis. Binnenkort maar eens tijd vrij maken om goed te leren.

Gelukkig is dit voor een schoolproject, dus ik laat het nog geen eens zo netjes eruit zien (ook geen complete Wireframe enz gemaakt wat ik normaal wel doe).

Om 4 uur?

Goed CSS leren klinkt leuk, maar door de "vrije-interpretatie" van de diverse browsers blijf je toch altijd een beetje aan het klooien.

Het lastigste aan CSS vind ik het structureren van je document. Meestal wordt het echt een zooitje doordat je aan het einde je nieuwe logica toevoegt. Werken met LESSCss vind ik overigens wel een stuk prettiger, dan mik je boven een aantal definities en gebruik je ze door je document. Dat is vooral handig als je een project oplevert welke per implementatie een stukje maatwerk heeft (zoals kleurtje, sizes, logos).

[ZpAz]

Mwah, sinds IE6 en IE7 de deur uit zijn is het al een stuk beter te doen. Tenzij je hele fancy dingen met vendor-prefixes gaat doen, maar dan vraag je er ook wel een beetje om natuurlijk

[PdeBie]

half dagje maar vandaag
heerlijk!!!

Vanmiddag vrij genomen om wat privé dingetjes te doen.

[TheNephilim]

.Gertjan. schreef op vrijdag 18 januari 2013 @ 09:57:
[...]


Om 4 uur?

Goed CSS leren klinkt leuk, maar door de "vrije-interpretatie" van de diverse browsers blijf je toch altijd een beetje aan het klooien.

Het lastigste aan CSS vind ik het structureren van je document. Meestal wordt het echt een zooitje doordat je aan het einde je nieuwe logica toevoegt. Werken met LESSCss vind ik overigens wel een stuk prettiger, dan mik je boven een aantal definities en gebruik je ze door je document. Dat is vooral handig als je een project oplevert welke per implementatie een stukje maatwerk heeft (zoals kleurtje, sizes, logos).

Laatst ook maar eens begonnen met LESS. Werkt prima, maar ik merk dat ik er toch langer over doe. Zeker met CSS is het vaak 'wijzigen, kijken.. wijzigen, kijken' en dat past niet altijd in (mijn) LESS workflow Het handmatig uploaden duurt namelijk te lang vaak. Maarja, dat komt vast nog eens goed als ik er eens langer mee bezig ben.

[.Gertjan.]

ZpAz schreef op vrijdag 18 januari 2013 @ 10:09:
Mwah, sinds IE6 en IE7 de deur uit zijn is het al een stuk beter te doen. Tenzij je hele fancy dingen met vendor-prefixes gaat doen, maar dan vraag je er ook wel een beetje om natuurlijk

Meh, aangezien ik afgelopen week er achter kwam dat zelf het alom geprezen Firefox steken laat vallen heb ik het idee dat het nog niet helemaal goed zit
Firefox had schijt aan de CSS property voor het box model en vereiste een -moz prefixed versie ...

Grotendeels heb je wel gelijk hoor, vooral IE 9 en IE 10 werken lekker mee. Maak maar weinig mee dat een site die ik ontwikkeld heb met vooral Chrome goed werkt in IE9 of IE 10. IE 8 heeft soms nog wel eens zijn kuren.

Je merkt het vooral als je strakke sites moet bouwen. Wanneer mensen komen met rounded corners of de eis dat content moet meegroeien. Dan loop je nog wel eens tegen browser issues aan. De tijd dat je voor iedere browser de margins/paddings moest corrigeren ligt gelukkig wel grotendeels achter ons... Ook jQuery helpt een heel eind daarin, ik weet nog wel dat je vroeger voor iedere browser weer net op een andere manier met javascript en de DOM moest omgaan.

[Ryur]

TheNephilim schreef op vrijdag 18 januari 2013 @ 10:13:
[...]


Laatst ook maar eens begonnen met LESS. Werkt prima, maar ik merk dat ik er toch langer over doe. Zeker met CSS is het vaak 'wijzigen, kijken.. wijzigen, kijken' en dat past niet altijd in (mijn) LESS workflow Het handmatig uploaden duurt namelijk te lang vaak. Maarja, dat komt vast nog eens goed als ik er eens langer mee bezig ben.

LESS is wel leuk ja, ben alleen een aanhanger van de concurrent SASS/SCSS.
Werk nogal veel in Ruby On Rails en daar is SASS/SCSS juist beter ondersteund dan LESS.

Weet eigenlijk helemaal niet hoe die 2 talen het doen in een 'normale' taal buiten RoR om. Lijkt me lastig met dat extra geparse.

---

Als jullie straks een ontploffing horen uit de richting van ongeveer Enschede. It's me; die helemaal gek wordt van CSS!

[ Voor 7% gewijzigd door Ryur op 18-01-2013 10:16 ]

[OkkE]

.Gertjan. schreef op vrijdag 18 januari 2013 @ 09:57:
Om 4 uur?

Dat vind ik behoorlijk vroeg ja...

Goed CSS leren klinkt leuk, maar door de "vrije-interpretatie" van de diverse browsers blijf je toch altijd een beetje aan het klooien.

Goed CSS leren is in mijn ogen voornamelijk het kennen van de browser bugs en quirks en op een gestructureerde manier kunnen werken. Of je het dan uiteindelijk oplost met een extra div of een :after vind ik minder belangrijk.

Het lastigste aan CSS vind ik het structureren van je document. Meestal wordt het echt een zooitje doordat je aan het einde je nieuwe logica toevoegt. Werken met LESSCss vind ik overigens wel een stuk prettiger, dan mik je boven een aantal definities en gebruik je ze door je document. Dat is vooral handig als je een project oplevert welke per implementatie een stukje maatwerk heeft (zoals kleurtje, sizes, logos).

LESS (of Sass of Stylus) maakt het inderdaad al een stuk overzichtelijker. Waar ik zelf ook een fan van ben is OOCSS en BEM. Herbruikbare standaard CSS classes die je uitbreid en aanpast d.m.v. extra classes en een logische/overzichtelijke naamgeving.

[Erwin537]

LESS lijkt me vooral leuk worden als je themas gaat maken voor webapplicaties/websites. Lekker makkelijk kleurtjes aanpassen e.d.

[.Gertjan.]

GoTCoast schreef op vrijdag 18 januari 2013 @ 10:15:
[...]

LESS is wel leuk ja, ben alleen een aanhanger van de concurrent SASS/SCSS.
Werk nogal veel in Ruby On Rails en daar is SASS/SCSS juist beter ondersteund dan LESS.

Weet eigenlijk helemaal niet hoe die 2 talen het doen in een 'normale' taal buiten RoR om. Lijkt me lastig met dat extra geparse.

Volgens mij kun je die ook gewoon gebruiken buiten RoR. Ik weet niet of hij on-the-fly kan parsen (LessCSS kan indien gewenst met JS de boel afhandelen).

SASS heb ik ook wel eens bekeken, voor het nesten van blokken leek mij wel handig. Maar voor het simpele werk waar ik LESS voor inzet voldoet LESS prima Zeker als je de mix-ins gebruikt kom je een heel eind

TheNephilim schreef op vrijdag 18 januari 2013 @ 10:13:
[...]
Laatst ook maar eens begonnen met LESS. Werkt prima, maar ik merk dat ik er toch langer over doe. Zeker met CSS is het vaak 'wijzigen, kijken.. wijzigen, kijken' en dat past niet altijd in (mijn) LESS workflow Het handmatig uploaden duurt namelijk te lang vaak. Maarja, dat komt vast nog eens goed als ik er eens langer mee bezig ben.

Ik werk daarom meestal met de "on-the-fly" versie. Dan hoef ik alleen de LESS file aan te passen en javascript parst het wel Vroeger gebruikte ik de compiler, maar die krijg ik niet echt lekker meer aan de gang op mijn machine (vroeger was het een commandline tooltje). De parser is zelfs op trage pc's met grote stylesheets redelijk snel

Nadeel is wel dat caching geregeld de kop op steekt. Zeker als je files include in je LESS, maar ook IE heeft er een handje van om de (hoofd)LESS file gewoon vrolijk uit de cache te lepelen. Maar afgezien daarvan kan ik gewoon mijn oude workflow hanteren

[Pyr0wl]

Als je op OS X je devwerk doet, kan je perfect LESS.app gebruiken! Als je je less files aanpast in je IDE/Texteditor naar keuze, zal de applicatie dat in de gaten krijgen en compiled die automatisch alles naar een leuke CSS file, best wel handig

[ Voor 7% gewijzigd door Pyr0wl op 18-01-2013 10:27 ]

[Ryur]

Pyr0wl schreef op vrijdag 18 januari 2013 @ 10:27:
Als je op OS X je devwerk doet, kan je perfect LESS.app gebruiken! Als je je less files aanpast in je IDE/Texteditor naar keuze, zal de applicatie dat in de gaten krijgen en compiled die automatisch alles naar een leuke CSS file, best wel handig

Hmm.. LESS.app kan je gebruiken, maar CodeKit is de opvolger ervan. Met veel betere ondersteuning (helaas wel betaald t.o.v. Less.app)

OkkE schreef op vrijdag 18 januari 2013 @ 10:43:
[...]

CodeKit

$25 voor bedrijfssoftware die ik dagelijks gebruik vind ik een koopje.

Heb CodeKit gekocht en geinstalleerd, helaas nog weinig mee gedaan.
Staat op mijn lijstje om binnenkort mee te werken (zoals zoveel)

[ Voor 26% gewijzigd door Ryur op 18-01-2013 10:44 ]

[OkkE]

GoTCoast schreef op vrijdag 18 januari 2013 @ 10:28:
[...]

Hmm.. LESS.app kan je gebruiken, maar CodeKit is de opvolger ervan. Met veel betere ondersteuning (helaas wel betaald t.o.v. Less.app)

CodeKit

$25 voor bedrijfssoftware die ik dagelijks gebruik vind ik een koopje.

[Pyr0wl]

GoTCoast schreef op vrijdag 18 januari 2013 @ 10:28:
[...]

Hmm.. LESS.app kan je gebruiken, maar CodeKit is de opvolger ervan. Met veel betere ondersteuning (helaas wel betaald t.o.v. Less.app)

Bwoa, als je enkel met LESS/CSS werkt kan je perfect uit de voeten met de LESS app. Als je meer wilt, en ook effectief nodig hebt, is $25 maar een klein bedrag

[Struikrover]

Ik bescheur me eens in de zoveel tijd weer even over die PHP constante, die soms tevoorschijn floept, met die absurd lange naam. Volgens mij is het de '::', maar ik ben z'n naam altijd kwijt (duh) . Wie schiet me even te hulp?

EDIT: Die ene dus waarbij je de eerste keer dat je hem tegen komt zoiets hebt van 'WTF, dit _moet_ een grap zijn'

@ hieronder: Jaaa, thanks

[ Voor 24% gewijzigd door Struikrover op 18-01-2013 10:47 ]

[azerty]

De 'Paamayim Nekudotayim' bedoel je? (http://php.net/manual/en/....paamayim-nekudotayim.php)

Wiki verklaart overigens perfect waarom het zo noemt:

quote: http://en.wikipedia.org/wiki/Scope_resolution_operator

In PHP, the scope resolution operator is also called Paamayim Nekudotayim (Hebrew: פעמיים נקודתיים, pronounced [paʔaˈmajim nəkudoˈtajim]), which means "twice colon" or "double dot twice" in Hebrew.

The name "Paamayim Nekudotayim" was introduced in the Israeli-developed[1] Zend Engine 0.5 used in PHP 3. Although it has been confusing to many developers who don't speak Hebrew, it is still being used in PHP 5, as in this sample error message:

[ Voor 77% gewijzigd door azerty op 18-01-2013 10:49 ]

[Erwin537]

Waarom kijkt backbone JS bij het onderscheidt maken tussen een PUT en een POST alleen naar het aanwezig zijn van een lowercase id? Ik heb ID in mijn model staan, dus doet hij altijd een POST Gelukkig kan ik met ASP.NET MVC en Entity snel de database aanpassen

[Alex)]

Ik ben bezig met wat performance-optimalisatie van een SharePoint-site. Dit nadat bleek dat het laden van de homepage in een ander deel van de wereld maarliefst 20 seconden duurt.

YSlow:

Grade F on Make fewer HTTP requests

This page has 41 external Javascript scripts. Try combining them into one.
This page has 17 external stylesheets. Try combining them into one.
This page has 21 external background images. Try combining them with CSS sprites.

Heel leuk dat al die Javascriptreferences door SharePoint worden geregistreerd d.m.v. RegisterSod en ik dat zo te zien niet kan overriden

[Barryvdh]

Pyr0wl schreef op vrijdag 18 januari 2013 @ 10:44:
[...]
Bwoa, als je enkel met LESS/CSS werkt kan je perfect uit de voeten met de LESS app. Als je meer wilt, en ook effectief nodig hebt, is $25 maar een klein bedrag

Ik gebruik de PHP versie, ook makkelijk, kan ik gewoon in mijn normale IDE werken overal, zonder extra software. Compileert alleen als het aangepast is.

[Haan]

Alex) schreef op vrijdag 18 januari 2013 @ 11:01:
Ik ben bezig met wat performance-optimalisatie van een SharePoint-site. Dit nadat bleek dat het laden van de homepage in een ander deel van de wereld maarliefst 20 seconden duurt.

YSlow:

[...]


Heel leuk dat al die Javascriptreferences door SharePoint worden geregistreerd d.m.v. RegisterSod en ik dat zo te zien niet kan overriden

Performance-optimalisatie en SharePoint in één zin is natuurlijk sowieso al behoorlijk tegenstrijdig

[ Voor 6% gewijzigd door Haan op 18-01-2013 11:48 ]

[Alex)]

Haan schreef op vrijdag 18 januari 2013 @ 11:47:
[...]

Performance-optimalisatie en SharePoint in één zin is natuurlijk sowieso al behoorlijk tegenstrijdig

Het laden van default.aspx en het versturen hiervan duurt zo'n 750 ms. Ik heb hierop een performancetest gedaan met dotTrace, het meeste werk lijkt uit de Microsoft.SharePoint-namespace te komen wat buiten mijn invloed valt.

Ik probeer de laadtijd te versnellen door het aantal HTTP-requests te minimaliseren... maar SharePoint lijkt zich daar niet echt voor te lenen. Als alles via de ScriptManager zou lopen zou ik hier nog op kunnen inhaken (door een custom scriptmanager) maar die RegisterSod()-calls gooien roet in het eten wat dat betreft.

RegisterSod voegt een URL naar een .js-file toe aan een clientside array die op zijn beurt wordt gebruikt om een berg <script />-tags toe te voegen aan de DOM...

[Korben]

Haan schreef op vrijdag 18 januari 2013 @ 11:47:
[...]

Performance-optimalisatie en SharePoint in één zin is natuurlijk sowieso al behoorlijk tegenstrijdig

La-ten-cy. RTT is nogal lang naar de andere kant van de wereld, en als je 100 resources op je pagina hebt zit je al snel aan het maximum aantal requests per domein.

Alex) schreef op vrijdag 18 januari 2013 @ 11:01:
Ik ben bezig met wat performance-optimalisatie van een SharePoint-site. Dit nadat bleek dat het laden van de homepage in een ander deel van de wereld maarliefst 20 seconden duurt.

Misschien kun je RequestReduce proberen? Werkt als een HTTP-module, dus zou om de SharePoint-beperkingen heen moeten kunnen werken.

[Flowmo]

Web Workbench voor Visual Studio FTW. On-save Sass compilatie. Bestandje uploaden, klaar Werkt heerlijk!

[Alex)]

Korben schreef op vrijdag 18 januari 2013 @ 11:52:
[...]

La-ten-cy. RTT is nogal lang naar de andere kant van de wereld, en als je 100 resources op je pagina hebt zit je al snel aan het maximum aantal requests per domein.


[...]

Misschien kun je RequestReduce proberen? Werkt als een HTTP-module, dus zou om de SharePoint-beperkingen heen moeten kunnen werken.

Bedankt voor de tip!

Het lijkt er niet op dat dit overweg kan met RegisterSod(), waardoor er helaas alsnog vele JS-scripts over de lijn gestuurd worden. En om nou RegisterSod() en z'n aanverwante functies te gaan overriden...

[.oisyn]

Weet iemand een tool waarmee je een bestand kan weergeven gegeven een bepaalde datastructuur (zoals C struct definities oid)?

[BtM909]

Verwijderd schreef op donderdag 08 november 2012 @ 09:56:
[...]
Ik vind stille werkruimtes ook beter maar met een koptelefoon opzitten lijkt mij ook zo asociaal...

Daarom heb je dus ook The headphones rule

[Korben]

Alex) schreef op vrijdag 18 januari 2013 @ 12:20:
[...]

Bedankt voor de tip!

Het lijkt er niet op dat dit overweg kan met RegisterSod(), waardoor er helaas alsnog vele JS-scripts over de lijn gestuurd worden. En om nou RegisterSod() en z'n aanverwante functies te gaan overriden...

Heb je het geprobeerd? Omdat het een HTTP-module is, werkt het rechtstreeks op de uiteindelijke output van je request handler (lees: pagina), dus het enige probleem zou kunnen zijn dat de URL's niet herkend worden.

[Rutix]

BtM909 schreef op vrijdag 18 januari 2013 @ 12:43:
[...]

Daarom heb je dus ook The headphones rule

Die regel heb ik ook. Als ik een koptelefoon op heb wil ik niet voor onzinnige dingen gestoord worden .

[Hydra]

Rutix schreef op vrijdag 18 januari 2013 @ 12:55:
[...]

Die regel heb ik ook. Als ik een koptelefoon op heb wil ik niet voor onzinnige dingen gestoord worden .

Bij m'n vorige baan zat ik op de kamer met een andere consultant die er nogal een handje van had om telefoongesprekken gewoon met de klant op speaker te doen. En dan later klagen als ik met oordopjes in zat omdat 'ie de muziek nog kon horen (je hoorde wat vaag geruis hoogstens). Zucht.

Nu heb ik gelukkig m'n eigen kamer. Kan ik doen wat ik wil.

[Otherside1982]

.oisyn schreef op vrijdag 18 januari 2013 @ 12:31:
Weet iemand een tool waarmee je een bestand kan weergeven gegeven een bepaalde datastructuur (zoals C struct definities oid)?

Ik ben onlangs zoiets tegengekomen, en heb het even terug opgezocht: 010editor, die editor heeft Binary templates waarmee je de datastructuur kan definieren. Het lijkt goed op C/C++ structs. Er zitten blijkbaar zelfs templates in voor WAV, BMP, ZIP.

[R4gnax]

Erwin537 schreef op vrijdag 18 januari 2013 @ 10:48:
Waarom kijkt backbone JS bij het onderscheidt maken tussen een PUT en een POST alleen naar het aanwezig zijn van een lowercase id? Ik heb ID in mijn model staan, dus doet hij altijd een POST Gelukkig kan ik met ASP.NET MVC en Entity snel de database aanpassen

In plaats van je C# code te vernachelen zou je ook gewoon een goede JSON serializer kunnen gebruiken die de C# PascalCase conventie naar de JavaScript camelCase conventie omzet tijdens het serializeren. Just sayin'.

[Hydra]

R4gnax schreef op vrijdag 18 januari 2013 @ 13:27:
[...]


In plaats van je C# code te vernachelen zou je ook gewoon een goede JSON serializer kunnen gebruiken die de C# PascalCase conventie naar de JavaScript camelCase conventie omzet tijdens het serializeren. Just sayin'.

^^ with stupid. Zelf ook Json.net gebruikt en dat werkt als een tierelier.

[RobIII]

Hydra schreef op vrijdag 18 januari 2013 @ 13:33:
[...]


^^ with stupid. Zelf ook Json.net gebruikt en dat werkt als een tierelier.

Ik snap dan ook niet waarom ze dat projectje bij MS niet gewoon overnemen en de zut opnemen in de BCL. Daar hoort 't IMHO gewoon (ergens ) in thuis. Het staat al zo goed als dag 1 permanent in de top (zeg) 10 meest populaire NuGet packages. De JSON implementatie van MS (voorzover je dat zo mag noemen, het doel is dan ook wel een tikkie anders) is ronduit ruk.

[ Voor 14% gewijzigd door RobIII op 18-01-2013 13:40 ]

[Erwin537]

R4gnax schreef op vrijdag 18 januari 2013 @ 13:27:
[...]


In plaats van je C# code te vernachelen zou je ook gewoon een goede JSON serializer kunnen gebruiken die de C# PascalCase conventie naar de JavaScript camelCase conventie omzet tijdens het serializeren. Just sayin'.

Cool, thanks.. daar zal ik eens naar gaan kijken dan.

Hydra schreef op vrijdag 18 januari 2013 @ 13:33:
[...]


^^ with stupid. Zelf ook Json.net gebruikt en dat werkt als een tierelier.

Als beginner mag je stupid zijn

[Korben]

RobIII schreef op vrijdag 18 januari 2013 @ 13:39:
[...]

Ik snap dan ook niet waarom ze dat projectje bij MS niet gewoon overnemen en de zut opnemen in de BCL. Daar hoort 't IMHO gewoon (ergens ) in thuis. Het staat al zo goed als dag 1 permanent in de top (zeg) 10 meest populaire NuGet packages. De JSON implementatie van MS (voorzover je dat zo mag noemen, het doel is dan ook wel een tikkie anders) is ronduit ruk.

Maar er zijn wel meer dingen die in de BCL zouden mogen (zoals NLog, CommonServiceLocator, Glimpse, ELMAH, SharpZipLib en noem maar op), maar als je toch weet waar je de correcte implementatie kan vinden, why bother? MS gaat het niet ondersteunen.

[Grijze Vos]

Json.NET -is- door MS opgenomen in de webstack. Het wordt alleen geen onderdeel van de BCL, omdat dat de release cycle van Json.NET zou vernaggelen.

[Korben]

Grijze Vos schreef op vrijdag 18 januari 2013 @ 14:02:
Json.NET -is- door MS opgenomen in de webstack. Het wordt alleen geen onderdeel van de BCL, omdat dat de release cycle van Json.NET zou vernaggelen.

Sauce? Ik heb daar niks van gehoord namelijk.

[GateKeaper]

Korben schreef op vrijdag 18 januari 2013 @ 14:03:
[...]

Sauce? Ik heb daar niks van gehoord namelijk.

Waarschijnlijk bedoeld hij "in MVC4".

http://forums.asp.net/p/1...elease+Candidate+released

Json.NET: We now use and support the popular Json.NET serializer for handling of JSON data. Json.NET is the default JSON serializer used by ASP.NET Web API and it includes support for data contracts, anonymous types, dynamic types, Dates, TimeSpans, object reference preservation, indenting, camel casing and many other useful serialization features.

[.oisyn]

Otherside1982 schreef op vrijdag 18 januari 2013 @ 13:16:
[...]

Ik ben onlangs zoiets tegengekomen, en heb het even terug opgezocht: 010editor, die editor heeft Binary templates waarmee je de datastructuur kan definieren. Het lijkt goed op C/C++ structs. Er zitten blijkbaar zelfs templates in voor WAV, BMP, ZIP.

Ja zoiets ja . Jammer dat het niet gratis is.

[Jan_V]

Korben schreef op vrijdag 18 januari 2013 @ 14:03:
[...]

Sauce? Ik heb daar niks van gehoord namelijk.

Is onlangs ook in een podcast van DNR of Hanselminutes behandeld.

[JohnStaakke]

Zo, de hele dag bezig geweest een DEV omgeving op te zetten voor iOS development met Xcode, Sencha Touch2, Phonegap, NodeJS en Socket.IO. Wel alles helemaal zoals ik het wilde, netjes verpakt, alles op een VMware image gezet zodat mijn collega`s hem zo over kunnen nemen en kunnen runnen.

[Otherside1982]

.oisyn schreef op vrijdag 18 januari 2013 @ 14:37:
[...]


Ja zoiets ja . Jammer dat het niet gratis is.

HexEdit is wel gratis, en open-source. Structuur is te definieren in XML en via GUI, en er zitten een aantal templates bij.

Ik heb deze alvast bij mijn verzameling tooltjes op mijn USB stick gezet

[Firesphere]

Zijn er nog mensen die zin hebben om iemand met een ipad/iphone gigantisch over de zeik te zien gaan?

[Verwijderd]

Firesphere schreef op vrijdag 18 januari 2013 @ 15:26:
Zijn er nog mensen die zin hebben om iemand met een ipad/iphone gigantisch over de zeik te zien gaan?

Duh

[Avalaxy]

Firesphere schreef op vrijdag 18 januari 2013 @ 15:26:
Zijn er nog mensen die zin hebben om iemand met een ipad/iphone gigantisch over de zeik te zien gaan?

Als het slopen van deze ipad/iphone ook tot de aanbieding behoort wel. Anders niet.

[Firesphere]

Verwijderd schreef op vrijdag 18 januari 2013 @ 15:28:
[...]


Duh

Je moet wel het device te pakken zien te krijgen, maar moet je applock profiel installeren, dan werkt de home-button niet meer. Je moet dan een hard-reboot, dan naar settings, dan het profiel weggooien.

Na installatie harde reboot, en de eerste app die je opstart, daar zit je in vast.

http://enterpriseios.com/...tore_Demo_Mode_for_kiosks

Daar dus. Ik kon er wel om lachen in ieder geval Eigenaar van de telefoon iets minder.

[ Voor 20% gewijzigd door Firesphere op 18-01-2013 15:31 ]