De Devschuur Coffee Corner

[D-Raven]

Alex) schreef op vrijdag 04 december 2009 @ 21:14:
[...]

Why not?

Omdat je daarna niet meer zonder kan

[Sebazzz]

Soms heb je van die dingen

Voor een spel, wat simpel gezegd een soort tetris achtig iets is, met een raster waarover blokjes bewegen. Een belangrijk punt is dat de blokjes soepel bewegen. Dit heb ik in Silverlight opgelost met een Canvas waarover de blokjes soepel bewegen. Intern houd in gewoon een .NET grid array bij waarbij de Y en X van de blokjes staat afgerond naar de bovenste virtuele gridlijn. Het probleem is als blokjes moeten schuiven naar links of rechts, of moeten draaien, dat je minstens twee cellen aan de zijkant van het blokje moet checken. Gevolg is dus extra complexiteit. Hier had ik geen trek in dus bij een draai of verschuiving lijnde ik het betreffende blokje naar de bovenste dichtstbijzijnde cellijn uit. Alleen de draaiing en verschuiving was daardoor niet vloeiend, maar ik wist geen betere manier.

Zegt vandaag een klasgenoot tegen mij 'Kan je niet gewoon na het draaien en verschuiven het uitlijnen ongedaan maken?'. Dat was dus de oplossing. Dat ik daar nooit op ben gekomen

[Haan]

dubbelpost

[ Voor 87% gewijzigd door Haan op 05-12-2009 10:39 ]

[Haan]

Alex) schreef op vrijdag 04 december 2009 @ 21:14:
[...]

Why not?

Omdat je anders na 30 dagen blijft balen dat je geen licentie hebt

(note to self, eerst kijken of er nog meer pagina's in het topic zijn voordat je reageert, en niet vergeten op de edit knop te klikken )

Sebazzz schreef op vrijdag 04 december 2009 @ 21:34:
[...]

Type maar wat brakke onzin in je C# code. Bij mij althans, checkt ie live op fouten. Ook als ik int x=0 declareer en nooit gebruik. Ik weet niet of het live compileren is, maar ik kan mij voorstellen dat ie de C# compiler gebruikt om fouten te detecteren.

Dat klopt, maar wat R# doet, en dat is heel handig, is ook checken of je parameters in bijv. string.Format("{0} blaats: {1}", user, text) wel allemaal aanwezig zijn. Dus als je string.Format("{0} blaats: {1}", user) typt, krijg je daar meteen al een warning op dat je nog een parameter mist.

[ Voor 55% gewijzigd door Haan op 05-12-2009 10:44 ]

[Matis]

D-Raven schreef op vrijdag 04 december 2009 @ 23:29:
[...]


Omdat je daarna niet meer zonder kan

Ik begin nu te begrijpen wat je bedoelt Wat een geweldig stukje software is het toch *jammer* dat ik na mijn afstudeerstage weer met c++/QT in Elipse/QT-IDE op Linux aan de gang mag

[Alex)]

Haan schreef op zaterdag 05 december 2009 @ 10:39:
[...]

Omdat je anders na 30 dagen blijft balen dat je geen licentie hebt

Ik heb (gelukkig) een personal license... ik denk alleen dat ik die niet mag gebruiken op mijn werklaptop?

[ Voor 20% gewijzigd door Alex) op 05-12-2009 15:35 ]

[Matis]

Alex) schreef op zaterdag 05 december 2009 @ 15:35:
Ik heb (gelukkig) een personal license... ik denk alleen dat ik die niet mag gebruiken op mijn werklaptop?

Nee, dat moet je niet riskeren, beter installeer je ook VS op een privelaptap/pc en bewerk je je project gewoon op je laptop met R#. Dan weer committen en verder editen in op je werklaptop

Zo doe ik het momenteel ook met de trail. Gewoon in een virtualbox draaien en op die manier kan ik het net uitzingen tot het einde van mijn stage

[Matis]

Momenteel ben ik een beetje begonnen met programmeren, nu is die docent helemaal verzot op design-patterns, nu heeft hij voorgesteld om een facade pattern te gebruiken. Leuk en aardig, maar ik ging bij mezelf eens te raden wat een criteria is om een facade te gebruiken. Allereerst dacht ik dat het dat het verstandig was om een getInstance te gebruiken bij een klasse die realtime kan veranderen (ik heb een OPC client die realtime zou moeten kunnen switchen tussen diverse OPC-servers, met maar 1 instance per keer). Tevens lijkt het me gemakkelijk als je een lege constructor hebt, dan hoef je IMO ook niet te klungelen met setters/getters in aparte functies.

Nu gaat het bij deze PoC niet om performance, maar om mijn kwaliteiten in het programmeer-wereldje te tonen.

Hoe is jullie visie mbt het gebruiken van design-patterns (en deze in het bijzonder?). Ikzelf vind eigenlijk dat een pattern nut moet hebben en niet het implementeren om het te implementeren

[Haan]

Matis schreef op maandag 07 december 2009 @ 09:23:
Hoe is jullie visie mbt het gebruiken van design-patterns (en deze in het bijzonder?). Ikzelf vind eigenlijk dat een pattern nut moet hebben en niet het implementeren om het te implementeren

Helemaal mee eens.

Maar ik kan me voorstellen dat je tijdens je studie wel eens een opdracht moet doen waarbij je verplicht gebruik moet maken van een bepaald design-pattern, om te leren.

[Matis]

Klopt, we hebben van de Gang of Four alle Structural Patterns geïmplementeerd, maar dat was meer om de werking te leren, zonder dat het toegevoegde waarde had. We gebruikte toen alleen dummy-klassen en methodes.
Functioneel heb ik er dus weinig ervaring mee, moet ik eerlijk bekennen. De werking begrijp ik en kan ik tevens doorgronden. De noodzaak/performance mbt het implementeren van een DP is me helaas niet echt geleerd. Wel heb ik een keer een adapter/interface module geschreven voor een fictieve of echte GPS uitlezer, maar daar is het ook wel bij gebleven

Edit; ik zie zojuist dat ik Facade heb getypt, maar ik bedoelde Singleton!

[ Voor 7% gewijzigd door Matis op 07-12-2009 09:41 ]

[whoami]

Sebazzz schreef op vrijdag 04 december 2009 @ 21:34:
[...]

Type maar wat brakke onzin in je C# code. Bij mij althans, checkt ie live op fouten. Ook als ik int x=0 declareer en nooit gebruik. Ik weet niet of het live compileren is, maar ik kan mij voorstellen dat ie de C# compiler gebruikt om fouten te detecteren.

Ik had die optie niet aan staan.
Nu even aangezet, maar zoveel extra's biedt dat je niet, vind ik.
R# gaat veel verder, duid bv ongebruikte parameters in een method aan, etc ...

[Alex)]

Een viewstate van 267 KB is volgens mij een beetje erg veel...

[Snake]

Alex) schreef op maandag 07 december 2009 @ 11:46:
Een viewstate van 267 KB is volgens mij een beetje erg veel...

Yes quite.

In .NET 4.0 is viewstate opt-in http://weblogs.asp.net/de...viewstate-management.aspx

Maar ik doe liever MVC ipv Webforms

[curry684]

Snake schreef op maandag 07 december 2009 @ 12:27:
[...]

In .NET 4.0 is viewstate opt-in

Nou tegen 7.0 zal het dan wellicht al een keer lichtelijk geschikt zijn om internetsites mee te bouwen

* curry684 vindt ASP.NET fantastische technologie en heeft er jaren met plezier mee gewerkt, maar mensen die er internetsites mee bouwen hebben vrijwel altijd een plaat voor hun kop. Voor webapplicaties, intranetstuff e.d. prachtig spul.

[creator1988]

Je kan prima een website bouwen in ASP.Net met geen/minimale viewstate, en met HTML die er precies uitziet zoals hij er uit moet zien, alleen doet nauwelijks iemand dat. Dat het met MVC nu wel goed gaat, is omdat het daar nu vanaf het begin beter uitgelegd wordt, de foute manieren zijn er gewoon ingeslopen bij de early adopters van ASP.Net en daarna verkeerd uitgedragen. Helaasch.

[Snake]

curry684 schreef op maandag 07 december 2009 @ 12:37:
[...]

Nou tegen 7.0 zal het dan wellicht al een keer lichtelijk geschikt zijn om internetsites mee te bouwen

* curry684 vindt ASP.NET fantastische technologie en heeft er jaren met plezier mee gewerkt, maar mensen die er internetsites mee bouwen hebben vrijwel altijd een plaat voor hun kop. Voor webapplicaties, intranetstuff e.d. prachtig spul.

Webforms ook gemaakt als de HTML counterpart van Winforms. Drag en drop, events, ed... Allemaal dingen die het stateless zijn van HTML opvangen, zodat Winforms developers gemakkelijk ASP.NET kunnen doen.

Maar dat geeft natuurlijk extra data. Iets wat drag en drop developers sowieso niet snappen.

ASP.NET MVC is krachtiger op dat gebied, je staat dichter bij de HTML. Maar dat geeft een steilere leercurve.

Voordeel van ASP.NET MVC is ook meer controle, qua URLs vooral. Wat voor belachelijke links dat ASP.NET soms genereerd. En dan meestal nog met Javascript zodat ge niet die pagina kan bookmarken :x

Nadeel van ASP.NET MVC (vind ik) is dat je moeilijker events aan buttons kunt hangen, je moet echt wel weten waar je mee bezig bent.

offtopic:
Iemand Scott Gu gezien vrijdag in Brussel?

[ Voor 3% gewijzigd door Snake op 07-12-2009 12:51 ]

[Alex)]

Er gaat 1,2 MB aan raw HTML over de lijn... en scripts en CSS zijn external. o.O

Arme browser...

[ Voor 10% gewijzigd door Alex) op 07-12-2009 12:59 ]

[curry684]

creator1988 schreef op maandag 07 december 2009 @ 12:40:
Je kan prima een website bouwen in ASP.Net met geen/minimale viewstate, en met HTML die er precies uitziet zoals hij er uit moet zien, alleen doet nauwelijks iemand dat.

Nogal logisch, omdat je dan alle RAD-voordelen van ASP.NET overhoop gooit en ineens 5 keer zo lang bezig bent als met een omgeving die er wel voor geoptimaliseerd is zoals PHP, Ruby e.d.

En let it be said dat ik PHP een ranzige kuttaal en -omgeving vind

[Snake]

curry684 schreef op maandag 07 december 2009 @ 13:14:
[...]

En let it be said dat ik PHP een ranzige kuttaal en -omgeving vind

QTF

[creator1988]

curry684 schreef op maandag 07 december 2009 @ 13:14:
[...]

Nogal logisch, omdat je dan alle RAD-voordelen van ASP.NET overhoop gooit en ineens 5 keer zo lang bezig bent als met een omgeving die er wel voor geoptimaliseerd is zoals PHP, Ruby e.d.

En let it be said dat ik PHP een ranzige kuttaal en -omgeving vind

Nee, het is een manier van werken. Het blijft een prima RAD omgeving mits je maar weet waar je mee bezig bent. Daar helpen 'kom-bij-ons-werken-en-je-haalt-je-MCPD-in-een-week-in-India-ook-al-weet-je-geen-fuck-en-dan-dumpen-we-je-als-medior-bij-een-bedrijf' toko's niet echt aan mee, dan krijg je dat soort verneukte pagelifecycles, viewstates van 300 kb etc.

[ Voor 9% gewijzigd door creator1988 op 07-12-2009 14:32 ]

[Alex)]

Ook leuk, een configfile waar men nog nooit heeft gehoord van attributen. Dat geeft dus dit soort juweeltjes:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Schermen>
    <Scherm>
        <SchermTitel>Informatie over klant</SchermTitel>
        <ObjectNaam>Klant</ObjectNaam>
        <Positie>1</Positie>
        <Velden>
            <Veld>
                 <Titel>Klantnummer</Titel>
                 <Attribuutnaam>CustomerNumber</Attribuutnaam>
                 <Type>Getal</Type>
                 <Vereist>true</Vereist>
            </Veld>
        </Velden>
    </Scherm>
</Schermen>

Dat kan volgens mij veel korter en overzichtelijker:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Schermen>
    <Scherm SchermTitel="Informatie over klant" ObjectNaam="Klant" Positie="1">
        <Veld Titel="Klantnummer" Attribuutnaam="CustomerNumber" Type="Getal" Vereist="true"/>
    </Scherm>
</Schermen>

[Verwijderd]

Alles in attributen zetten vind ik niet per se een stuk overzichtelijker eigenlijk.

[Matis]

Dat zijn wel twee uitersten Persoonlijk prefereer ik een mix tussen die twee

ctor

Waar ik me meer aan stoor is de inconsistentie tussen de talen

[ Voor 33% gewijzigd door Matis op 07-12-2009 14:47 ]

[Snake]

Dan toch liever de eerste. More to the point. En XML moet per definitie niet human readable zijn.

XML is gemaakt om data te transporteren tussen systemen, zodat zij via een uniforme manier met elkaar kunnen praten.

[Erkens]

Alex) schreef op maandag 07 december 2009 @ 14:43:
Ook leuk, een configfile waar men nog nooit heeft gehoord van attributen. Dat geeft dus dit soort juweeltjes:

XML:

<!-- knip -->

Dat kan volgens mij veel korter en overzichtelijker:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Schermen>
    <Scherm SchermTitel="Informatie over klant" ObjectNaam="Klant" Positie="1">
        <Veld Titel="Klantnummer" Attribuutnaam="CustomerNumber" Type="Getal" Vereist="true"/>
    </Scherm>
</Schermen>

Sowieso snap ik niet waarom je voor configfiles XML wilt gebruiken, dat is voor een gebruiker niet handig te editen (kans op fouten veel groter dan een simpele key/value bestand). Maar als je het dan zo met die attributen gaat oplossen dan snap je niet helemaal hoe je met XML om moet gaan.
In jouw voorbeeld zou ik bijvoorbeeld alleen "positie", "type" en "vereist" in een attribuut zetten, mits ik het juist heb dat deze config bedoeld is om een invulscherm mee aan te geven?

[Sebazzz]

Snake schreef op maandag 07 december 2009 @ 14:52:
Dan toch liever de eerste. More to the point. En XML moet per definitie niet human readable zijn.

XML is gemaakt om data te transporteren tussen systemen, zodat zij via een uniforme manier met elkaar kunnen praten.

XML:

<document>
    <data type="base64">sdaggq4aeert2343rfertgesfergsf==</data>
</document>

[Snake]

Erkens schreef op maandag 07 december 2009 @ 14:58:
[...]

Sowieso snap ik niet waarom je voor configfiles XML wilt gebruiken, dat is voor een gebruiker niet handig te editen (kans op fouten veel groter dan een simpele key/value bestand). Maar als je het dan zo met die attributen gaat oplossen dan snap je niet helemaal hoe je met XML om moet gaan.
In jouw voorbeeld zou ik bijvoorbeeld alleen "positie", "type" en "vereist" in een attribuut zetten, mits ik het juist heb dat deze config bedoeld is om een invulscherm mee aan te geven?

Waarom niet? Configfiles moet je niet handmatig aanpassen. Dan gaan er gekke dingen gebeuren.

[Erkens]

Snake schreef op maandag 07 december 2009 @ 14:58:
Waarom niet? Configfiles moet je niet handmatig aanpassen. Dan gaan er gekke dingen gebeuren.

Dan moet je capabele systeembeheerders in dienst nemen
Het is niet voor niets een config file.

[ Voor 7% gewijzigd door Erkens op 07-12-2009 15:15 ]

[Snake]

Sebazzz schreef op maandag 07 december 2009 @ 14:58:
[...]

XML:

<document>
    <data type="base64">sdaggq4aeert2343rfertgesfergsf==</data>
</document>

Natuurlijk, je maakt afwegingen he.

[whoami]

Alex) schreef op maandag 07 december 2009 @ 14:43:
Ook leuk, een configfile waar men nog nooit heeft gehoord van attributen. Dat geeft dus dit soort juweeltjes:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Schermen>
    <Scherm>
        <SchermTitel>Informatie over klant</SchermTitel>
        <ObjectNaam>Klant</ObjectNaam>
        <Positie>1</Positie>
        <Velden>
            <Veld>
                 <Titel>Klantnummer</Titel>
                 <Attribuutnaam>CustomerNumber</Attribuutnaam>
                 <Type>Getal</Type>
                 <Vereist>true</Vereist>
            </Veld>
        </Velden>
    </Scherm>
</Schermen>

Dat kan volgens mij veel korter en overzichtelijker:

XML:

<?xml version="1.0" encoding="utf-8"?>
<Schermen>
    <Scherm SchermTitel="Informatie over klant" ObjectNaam="Klant" Positie="1">
        <Veld Titel="Klantnummer" Attribuutnaam="CustomerNumber" Type="Getal" Vereist="true"/>
    </Scherm>
</Schermen>

doet me denken aan deze discussie:
[Discussie] Stelling: XML attributen zuigen!

En, daarbij, waarom zou - in jouw voorbeeld - het gebruik van attributen zoveel beter zijn ?

[ Voor 3% gewijzigd door whoami op 07-12-2009 15:27 ]

[whoami]

Erkens schreef op maandag 07 december 2009 @ 14:58:
[...]

Sowieso snap ik niet waarom je voor configfiles XML wilt gebruiken, dat is voor een gebruiker niet handig te editen (kans op fouten veel groter dan een simpele key/value bestand). Maar als je het dan zo met die attributen gaat oplossen dan snap je niet helemaal hoe je met XML om moet gaan.
In jouw voorbeeld zou ik bijvoorbeeld alleen "positie", "type" en "vereist" in een attribuut zetten, mits ik het juist heb dat deze config bedoeld is om een invulscherm mee aan te geven?

Een key/value bestand zorgt er dan wel weer voor dat een config-file van een complex iets als een WCF service bv, dan echt wel onoverzichtelijk / onduidelijk gaat zijn ... Ik bedoel: het is onmogelijk om op deze manier een aantal settings die logisch bij elkaar horen te gaan groeperen, als je begrijpt wat ik bedoel.

En daarbij, enkel devvers / sysadmins / etc... wijzigen config files manueel

[.oisyn]

Snake schreef op maandag 07 december 2009 @ 14:52:
En XML moet per definitie niet human readable zijn.

Wat een kul. Kun je die definitie hier quoten die volgens jou zegt dat het niet human readable moet zijn?

En het lijkt me duidelijk dat XML tov een INI file het voordeel heeft dat het nesting ondersteunt. Configuratie is niet altijd samen te vatten met simpele key/value pairs.

[ Voor 25% gewijzigd door .oisyn op 07-12-2009 15:36 ]

[Soultaker]

Mag ik ook het exacte tegendeel quoten?

Extensible Markup Language
Origin and Goals
[..]
The design goals for XML are:
[..]
6. XML documents should be human-legible and reasonably clear.

JSON > XML anyway.

[ Voor 3% gewijzigd door Soultaker op 07-12-2009 15:38 ]

[Snake]

Soultaker schreef op maandag 07 december 2009 @ 15:37:
Mag ik ook het exacte tegendeel quoten?

[...]


JSON > XML anyway.

Auch daar ga ik lekker in de mist

Ik vind JSON niet zo leuk omdat het geen namespaces ondersteund.

Maar voor client <> server (en dan vooral icm javascript) is het handiger.

[.oisyn]

Snake schreef op maandag 07 december 2009 @ 15:41:
Maar voor client <> server (en dan vooral icm javascript) is het handiger.

Dat "vooral icm javascript" is dan weer een beetje een onzinnig argument. Javascript heeft standaard geen functionaliteit om een object te serializen naar json, en bovendien wil je liever ook geen eval() gebruiken om het te deserializen. Feitelijk moet je in Javascript dus net zoveel moeite doen om JSON te gebruiken als in elke andere programmeertaal

[Soultaker]

De truc is dat je JSON kunt valideren met een simpele reguliere expressie. Uit de RFC:

Generally there are security issues with scripting languages. JSON is a subset of JavaScript, but it is a safe subset that excludes assignment and invocation.

A JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all the characters not enclosed in strings are in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.

JavaScript:

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
  text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');

Overigens garandeert dat nog niet dat de JSON tekst gedecodeerd kan worden, dus als je dat wil verifiëren zul je inderdaad zelf een parser moeten schrijven (zoals in de meeste andere talen).

Maar ja, JSON parsen is vergeleken met XML triviaal, omdat je niet met achterlijke dingen als encodings, embeded DTDs, external entities, enzovoorts rekening hoeft te houden.

edit:
Overigens heeft XML ook wel z'n toepassingen. Voor interoperabiliteit is het gebruik van namespaces wel fijn (Hoewel dat technisch gezien geen onderdeel is van de basisstandaard en ook vaak voor problemen zorgt; probeer bijvoorbeeld in XQuery maar eens een document te processen dat tags uit twee verschillende namespaces bevat, of uitvoer genereert in een andere namespace dan de invoer. Dan kun je alles gaan prefixen met namespaces.)

Maar als vervanger voor .ini files en andere simpele niet-document-centric datastructuren is JSON i.m.o. veel beter geschikt dan XML.

[ Voor 21% gewijzigd door Soultaker op 07-12-2009 16:11 ]

[Erkens]

whoami schreef op maandag 07 december 2009 @ 15:29:
Een key/value bestand zorgt er dan wel weer voor dat een config-file van een complex iets als een WCF service bv, dan echt wel onoverzichtelijk / onduidelijk gaat zijn ... Ik bedoel: het is onmogelijk om op deze manier een aantal settings die logisch bij elkaar horen te gaan groeperen, als je begrijpt wat ik bedoel.

True, zolang het een eenvoudige structuur is (max 1 groep diep) dan kan je nog prima een "ini-file" gebruiken, daar heb je groepen en de daarbij horende key/value zooi.

Als het complexer wordt dan is XML wel te overwegen waard, zolang het de leesbaarheid maar ten goede komt.

En daarbij, enkel devvers / sysadmins / etc... wijzigen config files manueel

En dat betekend dat je het ze "moeilijk" mag maken?

[user109731]

.oisyn schreef op maandag 07 december 2009 @ 15:51:
[...]
Javascript heeft standaard geen functionaliteit om een object te serializen naar json, en bovendien wil je liever ook geen eval() gebruiken om het te deserializen. Feitelijk moet je in Javascript dus net zoveel moeite doen om JSON te gebruiken als in elke andere programmeertaal

ES5 introduceert JSON.stringify en JSON.parse. Dit zit al in de laatste versies van o.a. IE, Firefox en Chrome. Maar in de praktijk zul je idd ook nog even een scriptje nodig hebben voor de oudere versies.

[ Voor 11% gewijzigd door user109731 op 07-12-2009 17:55 ]

[Verwijderd]

Voor mensen met een Android telefoon en wat programmeer ervaring/kennis. Ik hoef geen kant en klare oplossing, maar een denkrichting zou wel handig zijn . Ik snap namelijk niet hoe ze het doen.

Als je naar shopping.google.com gaat, kun je ervoor kiezen om met een knop de barcodescanner van je telefoon te openen, de barcode te scannen en vervolgens terug te keren naar de webpagina. Ik neem aan dat de trigger hiervoor van de webpagina komt. De code is vervolgens weer te gebruiken op de website.

Ik heb de developer.android.com afgezocht, en daarop wordt aangegeven hoe je van de barcodescanner gebruik kan maken vanuit andere Android applicaties, maar niet vanaf een website. Het puur starten van de scanner lukt ook nog wel (http://code.google.com/p/zxing/wiki/ScanningViaIntent), maar om dan vervolgens met een code terug te keren naar een site niet. Weet iemand hoe Google dit doet op hun shopping site?

[.oisyn]

Soultaker schreef op maandag 07 december 2009 @ 16:07:
Maar ja, JSON parsen is vergeleken met XML triviaal, omdat je niet met achterlijke dingen als encodings, embeded DTDs, external entities, enzovoorts rekening hoeft te houden.

Ik weet niet of je nu specifiek op mij reageert, maar ik ging louter in op de opmerking van Snake dat het juist met javascript handig was om mee te werken, terwijl het met javascript (pre ES5 ) niet makkelijker is dan in elke andere taal. Daarmee wil ik niet zeggen dat je net zo goed XML kunt gebruiken, ik heb helemaal geen waardeoordeel gegeven over JSON tov XML.

[Verwijderd]

Persoonlijk vind ik XML een draak van een standaard. Het designgoal mag dan wel geweest zijn dat het human readable is, m.i. is die chaos van <> en het herhalen van waardenamen absoluut niet human readable, en is dat design goal dus niet gehaald. Ik vind een simpele ini file met eventueel wat comments een stuk duidelijker leesbaar en makkelijker te editen. Als je echt dingen als nesting nodig hebt kan XML handig zijn, maar dan vind ik JSON er al een stuk netter uitzien en makkelijker leesbaar.

Overigens zie ik dat het gebruik van XML nogal een hype is tegenwoordig en het vaak gebruikt wordt voor simpele config files waar dingen als nesting niet gebruikt worden en een simpele ini file ook zou voldoen.

Mijn € 0,02

[BtM909]

Even stomme vraag van een niet C# figuur: bestaan er geen kalender-controls waarmee je vooraf kan opgeven welke data(ranges) wel / niet selecteerbaar zijn

Of m'n Google skills laten me faliekant in de steek of ik kan 't echt niet vinden

[Matis]

BtM909 schreef op maandag 07 december 2009 @ 20:17:
Even stomme vraag van een niet C# figuur: bestaan er geen kalender-controls waarmee je vooraf kan opgeven welke data(ranges) wel / niet selecteerbaar zijn

Of m'n Google skills laten me faliekant in de steek of ik kan 't echt niet vinden

SCRPTRQST

Ik weet dat het mogelijk is, ik heb het zelf eens gebruikt, maar ik zal even zoeken voor je

[BtM909]

Nee is geen scriptrequest... Ik programmeer niks, ik laat het ook niet doen, maar vroeg het me af omdat ik een beetje door controls heen aan 't kijken ben en me afvraag of zulke basale dingen niet in een control hoeven te zitten.

* BtM909 blijft zo ver mogelijk weg bij C#

[Matis]

Oh, nja het kan wel, probleem is alleen dat ik geen VS op mijn laptap heb staan

Wat voor control eigenlijk? De MonthCalendar ?

Je hebt iig de

MonthCalendar.MaxDate en de MonthCalendar.MinDate .

C#:

// Set the maximum visible date on the calendar to 12/31/2010.
this.monthCalendar1.MaxDate = new System.DateTime(2010, 12, 31, 0, 0, 0, 0);

// Set the minimum visible date on calendar to 12/31/2010.
this.monthCalendar1.MinDate = new System.DateTime(1999, 1, 1, 0, 0, 0, 0);

[ Voor 96% gewijzigd door Matis op 07-12-2009 20:30 ]

[Sebazzz]

BtM909 schreef op maandag 07 december 2009 @ 20:22:
* BtM909 blijft zo ver mogelijk weg bij C#

Misschien moet je het eens proberen, je zal het een fijne omgeving willen.

[BtM909]

Matis schreef op maandag 07 december 2009 @ 20:23:
Oh, nja het kan wel, probleem is alleen dat ik geen VS op mijn laptap heb staan

Wat voor control eigenlijk? De MonthCalendar ?

Nee, mijn idee is eigenlijk (wat ik dus gewoon wel in JS heb ): een date component waarbij ik een array opgeef van data die selecteerbaar is (geen min-max range dus). Stel je kan alleen een werkweek boeken, dan kan je alleen maar maandagen selecteren. Stel je kan maar 3 werkdagen boeken, dan kan je alleen maar ma, di of woensdag boeken.

Ik was ff aan 't rondkijken wat voor soort opties je meer zou kunnen toevoegen en m'n oog viel toevalligerwijs op wat C# components, maar geen van alle lijkt dit te hebben

[Matis]

Oww, in C++ zit die mogelijkheid wel volgens mij, daar maak je een array met dagen aan die wel geselecteerd mogen worden.

edit; mijn excuses, ik was abuis met de AnnuallyBoldedDates / BoldedDates

[ Voor 24% gewijzigd door Matis op 07-12-2009 20:50 ]

[Sebazzz]

BtM909 schreef op maandag 07 december 2009 @ 20:40:
[...]

Ik was ff aan 't rondkijken wat voor soort opties je meer zou kunnen toevoegen en m'n oog viel toevalligerwijs op wat C# components, maar geen van alle lijkt dit te hebben

Dan wordt dit dus de oplossing:

C#:

public MyMonthSelector : MonthSelector {
    // hier wat
}

Maar ik gok dat men op CodeProject ook wel wat heeft. Je zal niet de eerste zijn die tegen dit probleem aanloopt.

[Alex)]

Verwijderd schreef op maandag 07 december 2009 @ 19:58:
Overigens zie ik dat het gebruik van XML nogal een hype is tegenwoordig en het vaak gebruikt wordt voor simpele config files waar dingen als nesting niet gebruikt worden en een simpele ini file ook zou voldoen.

Tsja, verzin jij maar eens een bruikbaar en ook nog leesbaar alternatief is voor een configuratiebestand voor invoerschermen, waar je panelen kunt definiëren waarin velden staan die weer gemapt zijn naar een OR-mapper? INI wordt dan toch wel snel onleesbaar imo, omdat ieder veld ook nog meerdere settings heeft.

[Sebazzz]

Alex) schreef op maandag 07 december 2009 @ 20:49:
[...]

Tsja, verzin jij maar eens een bruikbaar en ook nog leesbaar alternatief is voor een configuratiebestand voor invoerschermen, waar je panelen kunt definiëren waarin velden staan die weer gemapt zijn naar een OR-mapper?

Wezz heeft het over config files waarbij géén nesting nodig is. Niet over waar jij het over hebt, hierbij is wel nesting van toepassing.

[Verwijderd]

Alex) schreef op maandag 07 december 2009 @ 20:49:
[...]

Tsja, verzin jij maar eens een bruikbaar en ook nog leesbaar alternatief is voor een configuratiebestand voor invoerschermen, waar je panelen kunt definiëren waarin velden staan die weer gemapt zijn naar een OR-mapper? INI wordt dan toch wel snel onleesbaar imo, omdat ieder veld ook nog meerdere settings heeft.

Verwijderd schreef op maandag 07 december 2009 @ 19:58:
Als je echt dingen als nesting nodig hebt kan XML handig zijn, maar dan vind ik JSON er al een stuk netter uitzien en makkelijker leesbaar.

Het is maar net welk deel van mijn post je citeert.

[creator1988]

Sebazzz schreef op maandag 07 december 2009 @ 20:47:
[...]

Dan wordt dit dus de oplossing:

C#:

public MyMonthSelector : MonthSelector {
    // hier wat
}

Maar ik gok dat men op CodeProject ook wel wat heeft. Je zal niet de eerste zijn die tegen dit probleem aanloopt.

In ASP.Net kan je DayRender overriden om deze te disablen, dat kan dan toch ook wel met die MonthSelector??

[ Voor 3% gewijzigd door creator1988 op 08-12-2009 09:57 ]

[Megamind]

Heeft iemand verstand van beurs correlaties

Ik heb iemand die vraagt of ik dat kan berekenen, heb een tabel met huidige en historische beurs gegevens, maar ik snap niet helemaal wat een correlatie op de beurs inhoud...

[Sebazzz]

Daarom moet je naast je opleiding informatica ook altijd een opleiding accountancy doen.

Om toch nog even nuttig te doen: http://www.usmarkets.nl/w...en-geluk-op-de-beurs.html
Het verschijnsel dat alle beurzen min of meer in dezelfde richting bewegen wordt correlatie genoemd. Dus een samenhang. Zie ook Wikipedia: Correlatie

[ Voor 63% gewijzigd door Sebazzz op 08-12-2009 19:36 ]

[Megamind]

Sebazzz schreef op dinsdag 08 december 2009 @ 19:33:
Daarom moet je naast je opleiding informatica ook altijd een opleiding accountancy doen.

Opzich is wiskunde ook wel handig

Correlation(r) = NΣXY - (ΣX)(ΣY) / Sqrt([NΣX2 - (ΣX)2][NΣY2 - (ΣY)2])

Ok, dat snap ik nog, maar tussen welke waardes?

Edit: ik denk dat ik het snap. Als het goed is kan je die formule gebruiken tussen 2 sluit waardes van beursnotaties over een periode de correlatie te berekenen.

Niet goed idee om die dan in een db op te slaan 7.500 records voor 1 dag

[ Voor 25% gewijzigd door Megamind op 08-12-2009 19:42 ]

[mithras]

Megamind schreef op dinsdag 08 december 2009 @ 19:36:
[...]

Ok, dat snap ik nog, maar tussen welke waardes?

Dat moet je zelf bepalen Lineair gecorreleerd betekent een coefficient van 1, niet gecorreleerd een coefficient van 0. Daartussen moet je een zelfgestelde grens trekken waarin je aanneemt dat boven die waarde het gegeven als gecorreleerd wordt gekwantificeerd

[Verwijderd]

T*ring, wat is het ontbreken van fatsoenlijke collapse/expand mogelijkheden in de VBA editor... IRRITANT!!!

[ Voor 3% gewijzigd door Verwijderd op 09-12-2009 11:02 ]

[YopY]

Bah hardcoded url naar databasepagina in een XSLT die voor meerdere sites gebruikt moet worden straks.

D'r zit een leuke JSP functie in waarmee je een link naar een DB pagina kunt laten genereren, maar da's hier geen optie, daar ik geen link tussen een record en een pagina aan kan geven.

beuh. Moet ik later nog maar naar kijken / de developers vragen.

[Sebazzz]

Zeg waar is het boekentopic gebleven. Het is echt on-vind-baar via de search
Dan maar hier...

Omdat ik steeds meer in .NET programmeer, wil ik een .NET specifiek boek met guidelines enzo kopen (en lezen). Is dit een goed boek? Framework Design Guidelines: Conventions, Idioms, And Patterns For Reusable .Net Libraries. Het boek is wel van oktober 2008, dus misschien een beetje outdated. Zijn er boeken die wat meer bij de tijd zijn, en even goed of beter?

[ Voor 13% gewijzigd door Sebazzz op 10-12-2009 11:14 ]

[BtM909]

Sebazzz schreef op donderdag 10 december 2009 @ 11:11:
Zeg waar is het boekentopic gebleven. Het is echt on-vind-baar via de search
Dan maar hier...

PRG FAQ

[Verwijderd]

Sebazzz schreef op donderdag 10 december 2009 @ 11:11:
Zeg waar is het boekentopic gebleven. Het is echt on-vind-baar via de search
Dan maar hier...

Omdat ik steeds meer in .NET programmeer, wil ik een .NET specifiek boek met guidelines enzo kopen (en lezen). Is dit een goed boek? Framework Design Guidelines: Conventions, Idioms, And Patterns For Reusable .Net Libraries. Het boek is wel van oktober 2008, dus misschien een beetje outdated. Zijn er boeken die wat meer bij de tijd zijn, en even goed of beter?

Ik vond het wel aardig, maar niet heel erg nuttig eerlijk gezegd. .NET coding guidelines in een boek samengevat.
Persoonlijk zou ik het geld dan liever uitgeven aan een meer in-depth technisch boek, om bijvoorbeeld IL en de CLR beter te leren kennen.

[Sebazzz]

BtM909 schreef op donderdag 10 december 2009 @ 11:23:
[...]

PRG FAQ

Ik zal het onthouden voor de volgende keer. Maar die search hier is brak.

Verwijderd schreef op donderdag 10 december 2009 @ 11:30:
[...]

Ik vond het wel aardig, maar niet heel erg nuttig eerlijk gezegd. .NET coding guidelines in een boek samengevat.
Persoonlijk zou ik het geld dan liever uitgeven aan een meer in-depth technisch boek, om bijvoorbeeld IL en de CLR beter te leren kennen.

Zoals?

[Verwijderd]

Ik ben laatst begonnen aan "CLR via C#" van Richter, maar ik weet nog even niet zo goed wat ik er van moet vinden (ben er ook nog niet heel erg ver in).
Heb je "Pro C# and the .NET Platform"? Dat vond ik een fijn boek, niet superdiepgaand, maar wel een goede summary. Verder heb ik op het moment alleen nog wat basic boeken (op het gebied van C#/.NET/ASP/MVC/Ajax) in de queue staan...
Wellicht vind je het leuk om eens wat naar patterns te kijken, een meer abstracte benadering van software ontwikkeling? Een standaard werkje: http://www.amazon.com/Des...oks&qid=1260442437&sr=8-1 maar ik vond het een erg prettig te lezen boek.

[ Voor 30% gewijzigd door Verwijderd op 10-12-2009 11:54 ]

[Sebazzz]

Nee het laatstgenoemde boeken heb ik niet, maar zo te zien is het 't wel waard om aan te schaffen. Wat betreft CLR via C#, wat is het punt van het boek? Ik heb nog geen inkijkexemplaar kunnen vinden.

edit: ik zie dat je ge-edit hebt

[ Voor 9% gewijzigd door Sebazzz op 10-12-2009 12:41 ]

[Verwijderd]

Ik ben nog bezig met Part I, wat voornamelijk in gaat op assemblies, versioning, deployment et cetera.
De rest ben ik nog niet aan toe gekomen, helaas.

[AtleX]

Hmm, een form ChildForm die overerft van ParentForm openen in de designer van VS2008 zorgt ervoor dat de constructor van ParentForm wordt aangeroepen, aangezien je daar nog weleens wat acties uitvoert zorgt dat dus voor problemen. Iemand enig idee hoe ik dat kan voorkomen/oplossen?

[edit]
Zelfs het Load event wordt afgevuurd, terwijl dat in ChildForm niet gebeurd. Wil VS niet dat je forms laat overerven oid?

[ Voor 19% gewijzigd door AtleX op 11-12-2009 14:04 ]

[CodeIT]

AtleX schreef op vrijdag 11 december 2009 @ 13:51:
Hmm, een form ChildForm die overerft van ParentForm openen in de designer van VS2008 zorgt ervoor dat de constructor van ParentForm wordt aangeroepen, aangezien je daar nog weleens wat acties uitvoert zorgt dat dus voor problemen. Iemand enig idee hoe ik dat kan voorkomen/oplossen?

[edit]
Zelfs het Load event wordt afgevuurd, terwijl dat in ChildForm niet gebeurd. Wil VS niet dat je forms laat overerven oid?

Volgens mij heb je een property DesignMode (yep, http://msdn.microsoft.com...component.designmode.aspx) op je control zitten die je kunt gebruiken. Je kunt ook het proces opvragen waar het in runt (in de editor is het 'devenv', maar dat vind ik zelf niet zo'n chique oplossing).

[AtleX]

DesignMode did the trick.

[Verwijderd]

Hmm, ik zit even met iets en kom er even niet uit vandaag...
Ik heb een datagrid, deze wordt gevuld met een DataTable.
Hier wil ik enkele filters op toepassen, ik heb 2 checkboxen, 'hide type A' en 'hide type B'.
Wanneer ik de eerste aanvink wordt er een filter toegepast op het datagrid, waardoor type A verdwijnt. Vervolgens vink ik de tweede aan, waardoor (beter gezegd, dat zou ik willen) type B verdwijnt. Maar type A komt weer terug. Ik begrijp uiteraard wel waarom het gebeurt, telkens als ik een filter uitvoer wordt de volgende code uitgevoerd:

C#:

if (checkBox1.Checked)
            {
                ((DataTable)dataGridView1.DataSource).DefaultView.RowFilter = "Type <> 'A'";
            }   
            else
            {
                ((DataTable)dataGridView1.DataSource).DefaultView.RowFilter = "";
            }

Wanneer ik de andere checkbox aantik voert hij opnieuw het filter uit, maar houdt dan uiteraard geen rekening met criteria van vorige checkboxen. Allemaal heel logisch, maar wel vervelend.
Is hier misschien een mooi pattern voor?
Hmm, ik kan wel een extension method voor DataTable schrijven natuurlijk

[ Voor 4% gewijzigd door Verwijderd op 11-12-2009 14:54 ]

[Sebazzz]

AtleX schreef op vrijdag 11 december 2009 @ 13:51:
Hmm, een form ChildForm die overerft van ParentForm openen in de designer van VS2008 zorgt ervoor dat de constructor van ParentForm wordt aangeroepen, aangezien je daar nog weleens wat acties uitvoert zorgt dat dus voor problemen.

Dat is ook de reden dat je childforms van abstracte forms niet kan bewerken.

[whoami]

AtleX schreef op vrijdag 11 december 2009 @ 14:28:
DesignMode did the trick.

Keep in mind that 'DesignMode' altijd false returned als je 'm gebruik in de constructor.

[Cartman!]

code:

2009-12-14T09:00:47+01:00 ERR (3): Code 5: Hyves Api temporary unavailable., method: auth.accesstokenByLogintoken

zucht zo kan ik toch niet testen mensen

[Verwijderd]

Hyves is bezig met onderhoud.

[Cartman!]

Wel relaxt als je daar geen mailtje van krijgt Inmiddels lijkt het gelukkig weer te werken.

edit: die trac pagina's van ze zijn ook zo onduidelijk... sommige pagina's kun je enkel vinden met 1 linkje in die hele site of soms niet eens...

[ Voor 44% gewijzigd door Cartman! op 14-12-2009 09:18 ]

[creator1988]

Een api of website zou nooit down mogen zijn door onderhoud.

[Matis]

creator1988 schreef op maandag 14 december 2009 @ 10:45:
Een api of website zou nooit down mogen zijn door onderhoud.

Tja, daar heb je een punt, maar in sommige gevallen moest zelfs T.net eraan geloven

[AtleX]

creator1988 schreef op maandag 14 december 2009 @ 10:45:
Een api of website zou nooit down mogen zijn door onderhoud.

Want?

[ Voor 94% gewijzigd door AtleX op 14-12-2009 10:49 ]

[creator1988]

Je website is je core business, zowel voor Tweakers, als voor Hyves. Ergo: als je website plat is betekent dat, dat je bedrijf eigenlijk plat ligt, bovendien kan het adverteerders schaden, en dan ben je nog verder van huis. Wij releasen in ieder geval altijd gewoon overdag, zonder downtime, en al ontploft het datacenter, dan zijn we zo weer up. Geplande downtime doen we in ieder geval nooit aan.

Zoals Marktplaats bijvoorbeeld regelmatig 's nachts offline is, dat is voor ons onvoorstelbaar. Al doet Marktplaats wel dingen wat meer op een aparte manier, wij sticken vrij dicht op standaardoplossingen.

edit: het realtime gedeelte qua reacties etc. maakt het wel lastiger om je productieomgeving te upgraden, maar zelfs dat zou niet onoverkomelijk moeten zijn.

[ Voor 31% gewijzigd door creator1988 op 14-12-2009 11:18 ]

[AtleX]

creator1988 schreef op maandag 14 december 2009 @ 11:14:
Je website is je core business

En daar ga je al de mist in. Niet elke website is essentieel voor een bedrijf. Je generaliseert in je eerste opmerking en vervolgens ga je het hebben over sites als Hyves en Tweakers. Minstens 90% (wild guess) van de sites draait gewoon op shared hosting spul en kan prima een uurtje downtime hebben. En daarnaast ben je niet zomaar zo groot dat je een dik failover cluster hebt. Als T.net groot onderhoud doet, zoals het vervangen van de DB-server of verhuizen naar een ander datacenter, moet de boel gewoon plat. Een fatsoenlijk drievoudig uitgevoerd systeem in verschillende datacenters die dat op kan vangen kost geld, veel geld. Er zijn maar weinig mensen of bedrijven die daar het geld voor over hebben.

[creator1988]

AtleX schreef op maandag 14 december 2009 @ 11:23:
[...]

En daar ga je al de mist in. Niet elke website is essentieel voor een bedrijf. Je generaliseert in je eerste opmerking en vervolgens ga je het hebben over sites als Hyves en Tweakers. Minstens 90% (wild guess) van de sites draait gewoon op shared hosting spul en kan prima een uurtje downtime hebben. En daarnaast ben je niet zomaar zo groot dat je een dik failover cluster hebt. Als T.net groot onderhoud doet, zoals het vervangen van de DB-server of verhuizen naar een ander datacenter, moet de boel gewoon plat. Een fatsoenlijk drievoudig uitgevoerd systeem in verschillende datacenters die dat op kan vangen kost geld, veel geld. Er zijn maar weinig mensen of bedrijven die daar het geld voor over hebben.

Juist een DB server zou minimaal dubbel uitgevoerd moeten zijn, en dus makkelijk te vervangen, zeker als je dit weliswaar overdag, maar niet op een piekmoment doet. Daarnaast als je website zodanig onderdeel is van je bedrijfsvoering dan heb je in een ander datacenter een fallback (virtual of fysiek, maar virtual bursting lijkt de nieuwe trend) die je ook bij verplaatsing naar een nieuw DC kan gebruiken. Dat hoeft niet veel te kosten (< 5K pm) als je het niet gebruikt. Kan je mooi een testomgeving opzetten.

En nee, bakker Jansen zal het inderdaad niet boeien, maar die zal ook geen API aan gaan bieden.

[Haan]

Ik ben het met je eens dat je van T.net en Hyves kan zeggen dat de website de core business van het bedrijf is. Maar ook daar zijn gradaties in Het is zowel bij T.net als Hyves niet zo dat er talloze mensen afhankelijk van de site zijn om transacties uit te voeren, downtime levert hooguit irritatie bij de gebruikers op.
Vergelijk dit bijvoorbeeld met Amazon.com of E-Bay waar dat wel zo is, hier kan downtime miljoenen dollars kosten en zal er dus wel geïnvesteerd worden in dure oplossingen om de site ten alle tijden in de lucht te houden.

[farlane]

creator1988 schreef op maandag 14 december 2009 @ 10:45:
Een api of website zou nooit down mogen zijn door onderhoud.

World Of Warcraft is elke woensdag een aantal uur offline voor onderhoud. Als je klanten het van te voren weten is er niets aan de hand imho.

[ Voor 11% gewijzigd door farlane op 14-12-2009 13:57 ]

[Sebazzz]

farlane schreef op maandag 14 december 2009 @ 13:56:
[...]

World Of Warcraft is elke woensdag een aantal uur offline voor onderhoud.

Dat heeft met een sociaal-maatschappelijk aspect te maken

[Otherside1982]

Ik ontdek net dat een collega alle forms in onze nieuwe applicatie is aan het aanpassen want "de labels en controls zijn volledig verkeerd". De helft van die forms had ik al afgewerkt en ze werken gewoon goed. Wat is nu de fout? De labels hebben nog allemaal namen als Label1 ipv NaamLabel, en de controls heben namen als NaamEdit ipb NaamDBEdit.

De reden dat hij dit doet is omdat de klant er anders opmerking over zou geven. Blijkbaar is die specifieke naamgeving vermeld in een document dat de "Standaard" (gewoon een framework) bespreekt.

Ik begrijp wel dat je wat afspraken maakt over code en standaarden gebruiken, maar je kan ook overdrijven. Zeker als alle code al zo geschreven is, is het toch zot om daar tijd in te steken!

Weeral een ergernis erbij, voor wat betreft werken bij deze klant, nummer 736

/rant

[Sebazzz]

Niet iedere control hoeft een goed naampje te hebben, vind ik. Pas als je er zelf met de code aan gaat komen, moet het een naampje hebben. Wat dat betreft is WPF wel makkelijk, niets heeft een naam tenzij je er een naam aan geeft (x:Name).

[BM]

Labels etc geef ik ook zelden een naam, tenzij zoals Sebazzz al zegt, je er vanuit code aan gaat zitten. Labels die vaste tekst bevatten.... het zal me worst wezen hoe die heten

[Haan]

Ik weet niet, als je iets schrijft voor een klant en alles staat vol met Label1, Label2, Label3 etc. kan ik me wel voorstellen dat dat een beetje knullig over kan komen. Zeker als de klant expliciet aangeeft wat de eisen zijn, dan ben je vanaf het begin gewoon al niet goed bezig geweest door je er niet aan te houden.

[Snake]

Haan schreef op maandag 14 december 2009 @ 17:50:
Ik weet niet, als je iets schrijft voor een klant en alles staat vol met Label1, Label2, Label3 etc. kan ik me wel voorstellen dat dat een beetje knullig over kan komen. Zeker als de klant expliciet aangeeft wat de eisen zijn, dan ben je vanaf het begin gewoon al niet goed bezig geweest door je er niet aan te houden.

In WPF hebben controls standaard geen naam. Dus het is absoluut geen zootje

[Haan]

Snake schreef op maandag 14 december 2009 @ 18:50:
[...]

In WPF hebben controls standaard geen naam. Dus het is absoluut geen zootje

Dat weet ik, maar het ging hier over Forms, niet over WPF.

[Woy]

Haan schreef op maandag 14 december 2009 @ 18:57:
[...]

Dat weet ik, maar het ging hier over Forms, niet over WPF.

Dan zet je de GenerateMember property gewoon op false.

[NMe]

creator1988 schreef op maandag 14 december 2009 @ 10:45:
Een api of website zou nooit down mogen zijn door onderhoud.

plan: Tweakers.net & GoT userbase-merge (afgerond)

Succes om dat voor elkaar te krijgen zonder downtime.

[afraca]

Was voor mijn profielwerkstuk even wat rond aan het kijken op het interwebs, en zo ook howstuffworks.com , en omdat hij wel vervelend langzaam ging, en ik niks beters te doen had, even (in opera) right click -> validate, oei oei, dan krijg je komische resultaten, 600 errors en 480 warnings

[ Voor 3% gewijzigd door afraca op 15-12-2009 02:22 ]

[MueR]

Die valt an sich nog best mee. Hun developer moet alleen even leren dat ie een & ook netjes als & schrijft in urls. Het gros van de errors en warnings komt daar uit. De enkele <br> ipv <br /> ook, maar dat kan brakke CMS software zijn. De enige die ik niet snap zijn die omni en omnivars properties, maar misschien is dat iets interns. Ik heb ergere gezien, al is 600 errors vrij spectaculair.

[AtleX]

600 HTML validation errors? Wat te denken van Javascript errors?

Op de site van Samsung, 2,5 jaar terug.

[HuHu]

afraca schreef op dinsdag 15 december 2009 @ 02:09:
Was voor mijn profielwerkstuk even wat rond aan het kijken op het interwebs, en zo ook howstuffworks.com , en omdat hij wel vervelend langzaam ging, en ik niks beters te doen had, even (in opera) right click -> validate, oei oei, dan krijg je komische resultaten, 600 errors en 480 warnings

Wordt Opera daar al langzaam van ?

[Matis]

Met hem ^^

Het feit dat je browser langzamer wordt ligt toch niet per definite aan foutieve websites. Ik kan me een site voorstellen helemaal blanco en toch 100% CPU

[Otherside1982]

BM schreef op maandag 14 december 2009 @ 16:48:
Labels etc geef ik ook zelden een naam, tenzij zoals Sebazzz al zegt, je er vanuit code aan gaat zitten. Labels die vaste tekst bevatten.... het zal me worst wezen hoe die heten

Dat is dus ook mijn redenering Er zijn wel andere details die ik belangrijker vind zoals: juiste shortcuts op de labels zodat je de focus in het bijhorende veld kan zetten, correct TAB-order, propere uitlijning, ...

Haan schreef op maandag 14 december 2009 @ 17:50:
Ik weet niet, als je iets schrijft voor een klant en alles staat vol met Label1, Label2, Label3 etc. kan ik me wel voorstellen dat dat een beetje knullig over kan komen.

Haan schreef op maandag 14 december 2009 @ 18:57:
Dat weet ik, maar het ging hier over Forms, niet over WPF.

Er is meer in de wereld dan .NET he , in mijn geval gaat het over Delphi. Daar wordt ook de term Form gebruikt. Verschil met bvb C# is wel dat de Form definitie in een apart bestand zit, het enige dat je van die Label1 en Label2 in de code ziet is een variable declaratie "Label1: TLabel;". Echt onoverzichtelijk wordt het daardoor niet (In C# wellicht ook niet omdat het daar in een collapsed region zit?).

Zeker als de klant expliciet aangeeft wat de eisen zijn, dan ben je vanaf het begin gewoon al niet goed bezig geweest door je er niet aan te houden.

Akkoord, maar tot nu toe heb ik al 4 projecten opgeleverd en nog nooit de opmerking gekregen dat mijn Labels niet de juiste naam hebben. En die bewuste regel had ik blijkbaar niet gezien op het moment dat ik voor deze klant begon te werken. Ik kan er nu wel in de toekomst rekening mee houden maar ik vond het gewoon nogal zot dat mijn collega even 2 à 3 uur bezig was om de volledige applicatie te doorlopen om die labels aan te passen.

[AtleX]

Ik geef altijd al m'n labels enzo een duidelijke naam, dan kan ik er recursief doorheen loopen voor internationalisation.

[Sebazzz]

AtleX schreef op dinsdag 15 december 2009 @ 10:33:
Ik geef altijd al m'n labels enzo een duidelijke naam, dan kan ik er recursief doorheen loopen voor internationalisation.

Je maakt niet gebruik van de internationalisatiemogelijkheden van .NET zelf, of in ieder geval niet van de Windows Forms editor?