De Devschuur Coffee Corner

[Remus]

Herko_ter_Horst schreef op zaterdag 29 augustus 2009 @ 14:48:
[...]

Het lijkt mij dat die commando's ook ergens vandaan komen én dat er niet oneindig veel commando's zijn. Ik zou dan (aan beide kanten van de socket) een Command enum verwachten:

Java:

public enum Command {
 EXPLODE {
  public void execute() {
   explode();
  },
 FOO {
  public void execute() {
    bar();
  };
  public abstract void execute();
}

Heb je niet eens meer een switch nodig, aangezien elk Command zichzelf kan uitvoeren:

Java:

String commandString = readNext(); // bijv. "explode"
Command command = Command.valueOf(commandString.toUpperCase());
command.execute();

Dat werkt wat minder lekker bij een stateful protocol waar je afhankelijk van de huidige staat bepaalde commando's wel of niet accepteert (al kan je natuurlijk ook controleren tegen een EnumSet met acceptabele commands) of het gedrag afhankelijk is van de huidige state.

[roy-t]

stijn1989 schreef op zaterdag 29 augustus 2009 @ 01:00:
Leuk zo'n koffie-klets-hoekje. Laat ik maar ook even een bijdrage leveren. Twee jaar terug had ik een idee voor een nieuwe UBB schrijfwijze: [ b]woord\[/ b] is nu woord.{b}. Ik heb er een google project erover opgericht.

http://code.google.com/p/dotted-ubb/

Een positief of negatief woordje over de stijl mag

Leuk dotted ubb, maar eigenlijk krijg je nu het VB vs C style stukjes idee.
IF
...
End IF.

vs

If
{
}

en
[ b ]lalala[/ b ] versus [lalala].{b}. Het aantal tekens dat je nodig hebt is nagenoeg gelijk (7 vs 6).

Verder vind ik het zelf onhandig dat je eerst ziet dat er iets gaat gebeuren met een stuk en dat je pas aan het einde ziet wat. (oh dus dit lange stuk staat in bold). Voor het parsen maakt dat natuurlijk niet veel uit, maar als mens denk ik wel.

Waarom heb je eigenlijk niet gekozen voor {b}.[lalalal] of {b}[lalala]? Vooral dat laatste scheelt weer die nutteloze punt. Andere opties zijn natuurlijk functie(opties){affected} hoewel je dan problemen krijgt als iemand foo() wil schrijven waar foo ook een stijl functie is.

Achja, ubb zoals het er nu is werkt best aardig geloof ik (niet dat dat een goede reden is om het niet proberen beter te maken).

[farlane]

Herko_ter_Horst schreef op zaterdag 29 augustus 2009 @ 15:47:
De vraag is of het zó nuttig is dat je de taal ervoor moet uitbreiden.

Dat is natuurlijk waar, maar Java staat (bij mij) voor een taal die het "eenvoudig" probeert te houden, wat inherent betekent dat je in de taal zelf dingen verwerkt zit die ook met veel/wat programmeerwerk zelf te bouwen zijn.

[HuHu]

roy-t schreef op zaterdag 29 augustus 2009 @ 21:24:
[...]


Leuk dotted ubb, maar eigenlijk krijg je nu het VB vs C style stukjes idee.
IF
...
End IF.

vs

If
{
}

en
[ b ]lalala\[/ b ] versus [lalala].{b}. Het aantal tekens dat je nodig hebt is nagenoeg gelijk (7 vs 6).

Verder vind ik het zelf onhandig dat je eerst ziet dat er iets gaat gebeuren met een stuk en dat je pas aan het einde ziet wat. (oh dus dit lange stuk staat in bold). Voor het parsen maakt dat natuurlijk niet veel uit, maar als mens denk ik wel.

Waarom heb je eigenlijk niet gekozen voor {b}.[lalalal] of {b}[lalala]? Vooral dat laatste scheelt weer die nutteloze punt. Andere opties zijn natuurlijk functie(opties){affected} hoewel je dan problemen krijgt als iemand foo() wil schrijven waar foo ook een stijl functie is.

Achja, ubb zoals het er nu is werkt best aardig geloof ik (niet dat dat een goede reden is om het niet proberen beter te maken).

Het wordt wel korter/handiger als je ook dit gaat ondersteunen: [lalala].{b,i} zodat je lalala krijgt.

[roy-t]

HuHu schreef op zondag 30 augustus 2009 @ 12:39:
[...]

Het wordt wel korter/handiger als je ook dit gaat ondersteunen: [lalala].{b,i} zodat je lalala krijgt.

Daar had ik dan weer niet aan gedacht, maar dat kun je natuurlijk ook in bb implementeren [b,i,u] ... [/] .

[wackmaniac]

Hoewel ik het idee van dotted UBB wel aardig vind, weet je toch al dat het niet gaat aanslaan; UBB is al zo ingeburgerd, dat sla je er met geen stuk hout meer uit. Is er niet een tijdje terug al iets nieuws geprobeerd met de naam Textile? Dat heb ik ook maar op enkele weblogs teruggezien en die zijn inmiddels allemaal weer over naar standaard ubb.

[Anoniem: 26306]

Uiteindelijk zal het geen zak uitmaken als je écht user friendly gaat doen. Dan heb je namelijk gewoon een wysiwyg editor die onder water het een en ander zal opslaan met UBB code of whatever.

[creator1988]

Hoe stack overflow het oplost vind ik wel netjes.

Code indention bijvoorbeeld gewoon 4 spaties ervoor, benadrukken door *piet* (wordt <em>piet</em>), en voor extra benadrukken **piet** (<strong>).

Verder gewoon intelligente dingen als, heb je een paar regels met sterretjes dan wordt het auto een lijst, dito met 1. 2. etc. Voelt heel natuurlijk aan.

[HuHu]

creator1988 schreef op zondag 30 augustus 2009 @ 21:57:
Hoe stack overflow het oplost vind ik wel netjes.

Code indention bijvoorbeeld gewoon 4 spaties ervoor, benadrukken door *piet* (wordt <em>piet</em>), en voor extra benadrukken **piet** (<strong>).

Verder gewoon intelligente dingen als, heb je een paar regels met sterretjes dan wordt het auto een lijst, dito met 1. 2. etc. Voelt heel natuurlijk aan.

Ja, dat zei wackmaniack dus: Textile.

[Cartman!]

En als je dit ook moet wilt gaan ondersteunen?

Dan wordt het toch al snel lastig voor gewone gebruikers denk ik.

edit: ik vind t wel erg leuk bedacht overigens

[ Voor 16% gewijzigd door Cartman! op 31-08-2009 09:21 ]

[Voutloos]

Wat Cheatah zegt. Uiteindelijk is het absolute onzin om al je gebruikers een suffe syntax aan te leren.

[Anoniem: 196208]

Cartman! schreef op maandag 31 augustus 2009 @ 09:19:
En als je dit ook moet wilt gaan ondersteunen?

Dan wordt het toch al snel lastig voor gewone gebruikers denk ik.

edit: ik vind t wel erg leuk bedacht overigens

Hoezo zou het lastig worden? Je kan (als eindgebruiker) toch gewoon kiezen welke je wilt gebruiken, textile of UBB?

[creator1988]

De vraag is: hoe moeten gebruikers denken: zoals ze willen dat de tekst eruit komt te zien (dus dingen als [ b] tags) of willen ze duidelijk maken wat ze bedoelen (dus *emphasis*). Ik denk dat we er gebaat bij zijn om het tweede te gebruiken

[Voutloos]

creator1988 schreef op maandag 31 augustus 2009 @ 09:39:
De vraag is: hoe moeten gebruikers denken: zoals ze willen dat de tekst eruit komt te zien (dus dingen als [ b] tags) of willen ze duidelijk maken wat ze bedoelen (dus *emphasis*).

Goede vraag, maar dan is sterretjes ook niet het antwoord, want zo komt het er dus helemaal niet uit te zien. Sterretjes zijn ook maar suffe conventie variant nr 42. Als je direct wilt zien hoe het eruit ziet, gebruik je een wysiwyg...

[mithras]

creator1988 schreef op maandag 31 augustus 2009 @ 09:39:
[...] of willen ze duidelijk maken wat ze bedoelen (dus *emphasis*) [...]

Daarom:

Boudewijn schreef op zaterdag 29 augustus 2009 @ 01:53:
Waarom niet een latex stijl, a la : \textbf{woord-dat-dik-moet}

Boudewijn schreef op zaterdag 29 augustus 2009 @ 02:04:
Daarom ,metadata + tags gebruiken a la LaTeX.

* Boudewijn LaTeX-fanboy is.

QFT

Maar imho is een wysiwyg altijd nog het beste. Al die markup is leuk, maar dat kost alleen maar moeite voor de gebruiken om het uiteindelijke resultaat je voor te kunnen stellen. Of je gaat met die Hyves achtige preview boxen aan de slag
Gewoon lekker tinyMCE (of een variant), dat is echt voor de gebruiker het meest eenvoudige

[ Voor 22% gewijzigd door mithras op 31-08-2009 09:58 ]

[Cartman!]

Anoniem: 196208 schreef op maandag 31 augustus 2009 @ 09:38:
[...]


Hoezo zou het lastig worden? Je kan (als eindgebruiker) toch gewoon kiezen welke je wilt gebruiken, textile of UBB?

Ik bedoelde te zeggen dat in UBB dat voorbeeld heel simpel te snappen is voor iemand maar [tekst].{b} in zo'n geval ineens erg lastig zal worden:

code:

[En als je dit [ook].{i} [moet].{s} wilt gaan ondersteunen?].{b}

Geef mij dan maar UBB...

[Amras]

UBB is wat mij betreft prima om opmaak te specificeren, maar ik kan me goed voorstellen dat niet iedere eindgebruiker er handig mee is. Een goede WYSIWYG editor is dan inderdaad een uitkomst. Het nadeel is dat die dingen vaak gruwelijke HTML uitspugen (<b>..</b>, <font>..</font>, inline styles, etc.). Of weet iemand een mooie editor die nette HTML gebruikt?

[farlane]

Ik mis iemand om mee te sparren hier ( op software design gebied ). Meer koffie helpt misschien ...

[creator1988]

Waar werk je?

[farlane]

creator1988 schreef op maandag 31 augustus 2009 @ 10:29:
Waar werk je?

Hardware/Software design/implementatie club(je) in het oosten des lands.

[ Voor 3% gewijzigd door farlane op 31-08-2009 10:41 ]

[Haan]

farlane schreef op maandag 31 augustus 2009 @ 10:22:
Ik mis iemand om mee te sparren hier ( op software design gebied ). Meer koffie helpt misschien ...

Al bijna een jaar hetzelfde gemis hier, maar morgen komt daar eindelijk verandering in in de vorm van een senior developer waar ik hopelijk een hoop van kan leren

* Haan neemt in de tussentijd ook nog maar een bakkie

[ Voor 7% gewijzigd door Haan op 31-08-2009 10:51 ]

[RobIII]

Amras schreef op maandag 31 augustus 2009 @ 10:21:
Of weet iemand een mooie editor die nette HTML gebruikt?

Ik heb wel goeie ervaringen met TinyMCE maar een beetje "rommel" ontkom je vrees ik niet aan.

[whoami]

farlane schreef op maandag 31 augustus 2009 @ 10:22:
Ik mis iemand om mee te sparren hier ( op software design gebied ). Meer koffie helpt misschien ...

Ik ook.

[curry684]

RobIII schreef op maandag 31 augustus 2009 @ 11:05:
[...]

Ik heb wel goeie ervaringen met TinyMCE maar een beetje "rommel" ontkom je vrees ik niet aan.

MCE is heilig, zeker met de MCE image manager erbij, enige nadeel is dat ie well-formed XHTML uit poept wat HTML4 sites breekt op <br>, en XHTML Strict niet realistisch bruikbaar is voor CMS-based sites, en je dus met XHTML Transitional blijft zitten waar de overheid weer over miept met z'n webrichtlijnen

Iemand al ooit gecheckt trouwens wat de webrichtlijnen checker vindt van HTML5 doctype?

[ Voor 3% gewijzigd door curry684 op 31-08-2009 11:23 ]

[RobIII]

curry684 schreef op maandag 31 augustus 2009 @ 11:16:
[...]

MCE is heilig, zeker met de MCE image manager erbij, enige nadeel is dat ie well-formed XHTML uit poept wat HTML4 sites breekt

Ik meen dat ik dat in een backend fixte door gewoon /> te vervangen door >. Volgens mij komt er dan HTML4 strict uit MCE. (Even uit de blote bol; weet niet of er nog meer zut uit kwam die ik overzien heb of nog andere "fixes" uitvoer(de)).

[Amras]

RobIII schreef op maandag 31 augustus 2009 @ 11:05:
[...]

Ik heb wel goeie ervaringen met TinyMCE maar een beetje "rommel" ontkom je vrees ik niet aan.

Thanks! Zal binnenkort eens een poging wagen.

[Voutloos]

ckeditor ziet er ook wel leuk uit. Iemand daar al ervaring mee?

[jbdeiman]

Een beetje rommel is ook niet erg, en die web-richtlijnen zijn vind ik persoonlijk met een korreltje zout te nemen. (niet letterlijk krijg je zo'n dorst van ) Ook wanneer je je een niet (volledig) XHTML stricte website hebt kan die verder prima aan de richtlijnen voldoen en ook prima gebruikersvriendelijk zijn.
De overheid heeft dat soort dingen wel vaker, typisch geval van een klok en een klepel, het kan prima minder strict, maar de overheid slaat weer eens helemaal door. Een groot deel van de overheids-websites voldoet zelf ook niet (volledig) aan (X)HTML strict. Het belangrijkste van richtlijnen is dat een website voor alle bezoekers goed te bezoeken moet zijn, (mits redelijk uiteraard)

[hostname]

Ik meende me te herinneren dat TinyMCE standaard met een plugin xhtmlxtras kwam. Als je die uitschakelt produceert hij volgens mij ook gewone HTML.

[R4gnax]

curry684 schreef op maandag 31 augustus 2009 @ 11:16:
[...]

MCE is heilig, zeker met de MCE image manager erbij, enige nadeel is dat ie well-formed XHTML uit poept wat HTML4 sites breekt op <br>, en XHTML Strict niet realistisch bruikbaar is voor CMS-based sites, en je dus met XHTML Transitional blijft zitten waar de overheid weer over miept met z'n webrichtlijnen

Iemand al ooit gecheckt trouwens wat de webrichtlijnen checker vindt van HTML5 doctype?

???

Wij maken in ons custom-built CMS anders toch expliciet gebruik van well-formed XHTML, o.a. om het mogelijk te maken een custom "cms://" protocol (wat verwijst naar andere content pagina's opgeslagen in het CMS) op anchor tags m.b.v. een XML parser uit te lezen en dynamisch te herschrijven naar een clientside bruikbare url.

Als de template markup om je CMS-based content heen al valide XHTML Strict is, dan zie ik niet in waarom ingevoegde CMS content (die óók valide XHTML Strict is) een probleem zou zijn. Je kunt als je dat echt wilt uiteraard je X(HT)ML content parsen naar een XML DOM-tree en die gebruiken om gewoon zelf een valide HTML4 Strict document te genereren : gewoon een kwestie van serializeren met een correct geschreven HTML4 serializer. Het performance probleem waarover dan al snel gerept wordt kun je heel eenvoudig afvangen door gewoon gedegen gebruik te maken van output caching..

[curry684]

Verstuur je XHTML Strict ook braaf als application/xhtml+xml en escape je braaf alle CDATA secties in CDATA elementen?

Zo nee moet je geen Strict gebruiken, de validator liegt op dat punt extreem grondig en laat stapels dingen door die een validating XML parser niet slikt.

[ Voor 14% gewijzigd door curry684 op 31-08-2009 11:47 ]

[curry684]

RobIII schreef op maandag 31 augustus 2009 @ 11:23:
[...]

Ik meen dat ik dat in een backend fixte door gewoon /> te vervangen door >. Volgens mij komt er dan HTML4 strict uit MCE. (Even uit de blote bol; weet niet of er nog meer zut uit kwam die ik overzien heb of nog andere "fixes" uitvoer(de)).

Da's een tagsoup oplossing voor een tagsoup probleem, en niet iets waar ik me structureel van afhankelijk van wil maken

[RobIII]

curry684 schreef op maandag 31 augustus 2009 @ 11:48:
[...]

Da's een tagsoup oplossing voor een tagsoup probleem, en niet iets waar ik me structureel van afhankelijk van wil maken

Ach, als het (valid) HTML4 strict oplevert en werkt... beetje pragmatisch kan ook geen kwaad

[Creepy]

Voutloos schreef op maandag 31 augustus 2009 @ 11:32:
ckeditor ziet er ook wel leuk uit. Iemand daar al ervaring mee?

Wij gebruiken hier (nog) de FCKEditor. En daaraan merk je dat het een wat oudere codebase is die wat "onfixbare" problemen heeft. We hebben zelf al moeten rommelen in de code en de plugins om het 1 en ander werkend te houden in o.a. Firefox 3 en IE 8.

Ik moet nog kijken naar de nieuwe CKEditor (=FCK 3.0) en daarnaast nog eens kijken naar MCE. Het wordt alleen een klus om onze bestaande uitbreidingen op FCK 2.x om te zetten..

[curry684]

Ik vond FCK 2.x migreren naar MCE eigenlijk best e-z klusje, zo gepiept bij ons. Tis vooral een kwestie van veel serverside code deleten omdat je ineens vrijwel alles clientside doet

[creator1988]

Ik vind eigenlijk al die editors verschrikkelijk werken. Werkte vroeger zelf veel met radEditor; die was nog wel redelijk. Voor de rest vind ik http://xstandard.com/ wel erg goed, maar die werkt met een clientside component.

[mithras]

curry684 schreef op maandag 31 augustus 2009 @ 11:16:
[...]

MCE is heilig, zeker met de MCE image manager erbij, enige nadeel is dat ie well-formed XHTML uit poept wat HTML4 sites breekt op <br>, en XHTML Strict niet realistisch bruikbaar is voor CMS-based sites, en je dus met XHTML Transitional blijft zitten waar de overheid weer over miept met z'n webrichtlijnen

Iemand al ooit gecheckt trouwens wat de webrichtlijnen checker vindt van HTML5 doctype?

TinyMCE kan gewoon HTML4 maken ipv XHTML hoor! De configuratie-optie element_format omzetten naar html en voila

Daarnaast: ik gebruik een simpele config waar er geen <font> meer in voorkomt. Alles netjes <h1>, <p> etc. Dat is deze config (het is een ini formaat zodat het makkelijk te configureren is bij mij):

[editor]
scriptPath = "/js/tiny_mce/"
scriptFile = "tiny_mce.js"
mode = "textareas"
element_format = "html"
forced_root_block = "p"
theme = "advanced"
width = "580"
height= "300"
plugins= "paste, table"
theme_advanced_resizing = true
theme_advanced_resizing_use_cookie = false
theme_advanced_toolbar_location = "top"
theme_advanced_buttons1 = "formatselect, bold, italic, underline, strikethrough, |, justifyleft, justifycenter, justifyright, justifyfull, |, bullist, numlist, |, outdent, indent, blockquote, |, undo, redo, cleanup, removeformat, pasteword, code "
theme_advanced_buttons2 = "link, unlink, anchor, |, image, hr , sub, sup, charmap, |, forecolor, backcolor, |, tablecontrols"
theme_advanced_buttons3 = ""
theme_advanced_blockformats = "p,h1,h2,h3,blockquote,dt,dd"

[ Voor 43% gewijzigd door mithras op 31-08-2009 14:42 ]

[curry684]

mithras schreef op maandag 31 augustus 2009 @ 14:36:
[...]
TinyMCE kan gewoon HTML4 maken ipv XHTML hoor! De configuratie-optie element_format omzetten naar html en voila

Hey, geinig, maar niet zo vreemd dat ik die niet kende daar ie pas in 3.2 zit Ik heb 'r ruim voor september 2008 een keer diep naar zitten spitten.

Overigens blijft de hamvraag natuurlijk in hoeverre HTML5 doctype inmiddels productiegeschikt is

[ Voor 5% gewijzigd door curry684 op 31-08-2009 14:43 ]

[mithras]

Maar tinyMCE maakt toch gewoon html4

Of is de vraag of je zelf geschreven html (zeg: templates) al in html5 kan gieten voor productie? Mja, zelf schrijf ik een html5 doctype waarbij ik me dus aan de html5 standaarden hou. Echter gebruik ik niet de elementen die er nieuw bij zijn gekomen, vanwege de ontbrekende ondersteuning in de meeste browsers.

[Anoniem: 313723]

Damn, ik zit hier op m'n werk te staren naar oude Progress-code... En opeens krijg ik een mega-creatief idee voor een website! En ik moet nog een uur voor ik naar huis kan...
Heel vervelend dit, want nu zit het zo in m'n hoofd dat ik me niet meer kan concentreren op het programmeerwerk wat hier gedaan moet worden

[AtleX]

Hoe denken jullie over CPU- & geheugengebruik versus snelheid? Ik ben, zoals sommigen wel weten, bezig met een nieuwe versie van T.net Photo Poster die een stuk meer kan dan de oude. In ruil daarvoor is vooral het geheugengebruik een stuk hoger, bij forse mappen in een photoalbum kan het oplopen tot zo'n 100-150MB.

Dat komt voornamelijk omdat ik bovenop de diskcache nog een memory cache heb om bijvoorbeeld bij het tonen van een fullsize afbeelding ook alvast de afbeelding voor de geselecteerde afbeelding laad en daarnaast nog de 2 erna. Dit doe ik voornamelijk om sneller door afbeeldingen te kunnen bladeren. Het werkt behoorlijk goed, want ik kan snel bladeren door alle afbeeldingen in een map zonder dat het 'traag' aanvoelt.

De cache wordt beheerd door een soort clean-up service die elke 30 seconden draait. Als ik snel blader en in die 30 seconden 30 keer de volgende afbeelding bekijk heb ik dus na 30 seconden (30 + 1 afbeelding voor de eerste + 2 na de laatste) 33 afbeeldingen in de cache zitten die elk maximaal 2MB per stuk (filesize) zijn. Een System.Drawing.Image in .NET gebruikt behoorlijk wat geheugen aangezien hij afaik de image decompressed, dus ik kom dan uit op zo'n 80MB (wilde gok) alleen al voor de cache.

Ik ruil dus nu geheugen voor snelheid, wat ik niet zo'n heel slechte ruil vind. Alleen die 150MB. Ik heb zelfs een keer een piekgebruik van 300MB gehad, en dat vind ik voor een 'handige tooltje' een beetje veel. Hoe denken jullie daarover? Ik heb de laatste tijd wat advertenties van Dell, Packard Bell, etc. gelezen en volgens mij wordt er geen enkele computer meer verkocht met minder dan 2GB geheugen. Ik kan er denk ik ook wel vanuit gaan dat de gemiddelde Tweaker 2GB of meer heeft? Is bijvoorbeeld 300MB dan echt teveel? Bij normaal gebruik kom je trouwens niet vaak boven de 50-60MB uit, aangezien de garbage collector en mijn memorycache housekeeper dan de boel wel in het gareel kunnen houden.

[ Voor 4% gewijzigd door AtleX op 31-08-2009 15:02 ]

[Woy]

Kun je die memory cache niet gewoon optioneel maken? Dan kunnen de mensen die het geheugengebruik te hoog vinden het gewoon uit zetten, dan leveren ze alleen wat snelheid in.

[zwippie]

Niks mis met 300MB toch?
Zolang er maar alternatieven zijn voor je programma, zodat iemand met een Pentium 2 met 128 MB RAM ook gewoon foto's kan blijven uploaden.

[AtleX]

Woy schreef op maandag 31 augustus 2009 @ 15:08:
Kun je die memory cache niet gewoon optioneel maken? Dan kunnen de mensen die het geheugengebruik te hoog vinden het gewoon uit zetten, dan leveren ze alleen wat snelheid in.

Ja, dat zou kunnen maar dan krijg je zo'n zinloze optie als "Memory cache (meer geheugengebruik, snellere applicatie) aan/uit" waarvan vrijwel niemand weet wat het voor gevolgen heeft. Ik zal 'm standaard aan moeten zetten, want anders krijg ik klachten over het tragere laden van afbeeldingen. Geen enkele user zal 'm uitzetten, want snelheid == geil. Dan bouw ik functionaliteit voor 1 of 2 power-users die hun geheugengebruik zo laag mogelijk willen houden, en dat vind ik een beetje zonde van de moeite.

zwippie schreef op maandag 31 augustus 2009 @ 15:09:
Niks mis met 300MB toch?
Zolang er maar alternatieven zijn voor je programma, zodat iemand met een Pentium 2 met 128 MB RAM ook gewoon foto's kan blijven uploaden.

Nou, alleen T.net users met een fotoalbum (en dus genoeg Karma) kunnen er gebruik van maken en ik betwijfel of er iemand op T.net is die nog serieus een P2 met 128MB geheugen gebruikt als werkpaard. Daarnaast vereist TPP2 .NET 3.5 en daar heb je minimaal Windows XP voor nodig geloof ik. Mochten er dan toch nog fanatiekelingen zijn die zo'n systeem gebruiken dan uploaden ze hun afbeeldingen maar via het formuliertje dat T.net aanbied.

edit:

En 300MB is niks? Het gaat hier over een tooltje van 7 files en in totaal 157KB. 300MB is dan ineens bijna 1957 keer zoveel.

[ Voor 53% gewijzigd door AtleX op 31-08-2009 15:25 ]

[Woy]

AtleX schreef op maandag 31 augustus 2009 @ 15:12:
Ja, dat zou kunnen maar dan krijg je zo'n zinloze optie als "Memory cache (meer geheugengebruik, snellere applicatie) aan/uit" waarvan vrijwel niemand weet wat het voor gevolgen heeft. Ik zal 'm standaard aan moeten zetten, want anders krijg ik klachten over het tragere laden van afbeeldingen. Geen enkele user zal 'm uitzetten, want snelheid == geil. Dan bouw ik functionaliteit voor 1 of 2 power-users die hun geheugengebruik zo laag mogelijk willen houden, en dat vind ik een beetje zonde van de moeite.

Ik ben het er mee eens dat er waarschijnlijk niet veel mensen gebruik van zullen maken, want de meeste mensen hebben zat geheugen. Ik ging er echter van uit dat het niet veel werk was om het optioneel te maken.

[AtleX]

Woy schreef op maandag 31 augustus 2009 @ 15:14:
[...]
Ik ging er echter van uit dat het niet veel werk was om het optioneel te maken.

Dat is het ook niet, want als die instelling gewoon de cache size beperkt tot 0 ben ik snel klaar. Die staat default op 2x de housekeeper timeout (30 seconden) en dus cache ik maximaal 60 fullsize afbeeldingen. Indien een afbeelding niet in de memory cache staat komt 'ie uit de disk cache, dus dat zou geen probleem moeten zijn.

[Woy]

AtleX schreef op maandag 31 augustus 2009 @ 15:17:
[...]

Dat is het ook niet, want als die instelling gewoon de cache size beperkt tot 0 ben ik snel klaar. Die staat default op 2x de housekeeper timeout (30 seconden) en dus cache ik maximaal 60 fullsize afbeeldingen. Indien een afbeelding niet in de memory cache staat komt 'ie uit de disk cache, dus dat zou geen probleem moeten zijn.

Als je dan gewoon een instelling voor de cache size hebt, kunnen mensen er ook nog voor kiezen om nog een grotere cache te nemen, mochten ze het leuk vinden.

[compufreak88]

Ik ben vandaag begonnen met mijn stage applicatie ontwikkeling. Ik zou eerst voortbouwen op een nieuwe versie, gebasseerd op CodeIgniter en Google Gears, maar ik mag nu eerst nog wat uitbreiding op de oude versie (spaghetti code) doen.

[curry684]

mithras schreef op maandag 31 augustus 2009 @ 14:47:
Maar tinyMCE maakt toch gewoon html4

Nee legacy MCE maakt juist XHTML.

Of is de vraag of je zelf geschreven html (zeg: templates) al in html5 kan gieten voor productie? Mja, zelf schrijf ik een html5 doctype waarbij ik me dus aan de html5 standaarden hou. Echter gebruik ik niet de elementen die er nieuw bij zijn gekomen, vanwege de ontbrekende ondersteuning in de meeste browsers.

Nee de vraag stond stuk hierboven al letterlijk - of iemand al eens getest heeft wat de automatische webrichtlijnenchecker van de overheid van HTML5 doctype vindt. Want een niet-strict doctype gebruiken rekent dat stomme ding gewoon een harde error op, niet eens "moet handmatig gecontroleerd worden op terechtheid".

[Anoniem: 313723]

Poeh, ik ben net door een potentiële nieuwe werkgever verzocht een stuk code te sturen.
Maar mijn hemel, wat moet ik in godsnaam sturen om een goede indruk achter te laten
Het moet er een beetje spiffy uitzien natuurlijk... Ik zat zelf te denken aan een stukje chronologie... Een CMS'je wat ik jaren geleden in elkaar heb gezet, wat echt rammelt aan alle kanten, tot wat code die nu bruikbaar is, om zo de 'groei in capaciteit' goed weer te kunnen geven...
De baan zelf is PHP gerelateerd, dus ik dacht een paar lapjes waaruit blijken dat ik de 'best practices' in de vingers heb.
Wat vinden jullie? Ik vind het vooral spannend aangezien het mijn eerste échte sollicitatie is

[ Voor 17% gewijzigd door Anoniem: 313723 op 31-08-2009 16:34 ]

[boe2]

Je cms'je is geen slecht idee dan. Kuis het wel eerst wat op: Alles netjes declareren, overal extra commentaar bij om te tonen dat je weet wat je doet, uitkijken voor onlogische constructies die je meestal wel terugvindt in code van jaren oud terwijl jij ondertussen veel meer ervaring hebt

[momania]

Anoniem: 313723 schreef op maandag 31 augustus 2009 @ 16:32:
Wat vinden jullie? Ik vind het vooral spannend aangezien het mijn eerste échte sollicitatie is

Ik vind het raar dat je code moet opsturen. Op locatie even een uurtje pair-programming doen met een van de developers lijkt mij veel doeltreffender (zo doen wij dat op het werk iig ook)

[mithras]

curry684 schreef op maandag 31 augustus 2009 @ 15:58:
[...]

Nee legacy MCE maakt juist XHTML.

Ja ok, maar niet als je een up-to-date tinyMCE gebruikt en hem goed configureert. Je gaat natuurlijk niet uit van legacy

[...]

Nee de vraag stond stuk hierboven al letterlijk - of iemand al eens getest heeft wat de automatische webrichtlijnenchecker van de overheid van HTML5 doctype vindt. Want een niet-strict doctype gebruiken rekent dat stomme ding gewoon een harde error op, niet eens "moet handmatig gecontroleerd worden op terechtheid".

Ik heb nu mijn eigen site door de check gegooid en daar komen 7 fouten uit. 4 daarvan gaan over de doctype, één over dat ik geen css2.1 gebruik (que ), één over missende alt attributen bij images (nu weer toegestaan bij html5) en één over het missen van lang="nl", maar W3C geeft zelf aan dat het ook met een meta-tag mag. Imho dus een beetje waardeloze test

Maar om antwoord te geven op je vraag ( ), de Webrichtlijnen checker kan dus niet met de html5 doctype omgaan.

[Creepy]

curry684 schreef op maandag 31 augustus 2009 @ 14:20:
Ik vond FCK 2.x migreren naar MCE eigenlijk best e-z klusje, zo gepiept bij ons. Tis vooral een kwestie van veel serverside code deleten omdat je ineens vrijwel alles clientside doet

Dat klinkt heel goed, aangezien we inderdaad van dat soort zaken afwillen. Dan is het daarna alleen nog en kwestie van goed testen met de gegenereerde HTML of daar nog wat aan verbouwd moet worden of niet. Met FCK 2.0 was het namelijk zo dat sommige stukjes HTML browser afhankelijk zijn (e.g. #FFFFFF tegenover RGB(255,255,255).. en raad eens wat er gebeurd met RGB() in sommige e-mail clients........)

[jbdeiman]

Of geef inderdaad het CMS-je mee, (of iig een onderdeel daarvan) en en van je nieuwste bestanden. Goed becommentariëren en ook zorgen voor "schone code" (geen onzin dingen en geen stukken weggecommentariserde code.

Zorg ervoor dat je ook zelf nog weet wat je code doet, bij je cms weet wat knel-/ verbeterpunten zijn. Geef ook duidelijk aan bij je cms dat dat oudere code is en dat je daarin aangeeft wat je nu anders gedaan zou hebben.

Mag ik tevens vragen waar je gesolliciteerd hebt? (ik begin volgende week in zwolle op proef)

[djc]

Creepy schreef op maandag 31 augustus 2009 @ 14:15:
Ik moet nog kijken naar de nieuwe CKEditor (=FCK 3.0) en daarnaast nog eens kijken naar MCE. Het wordt alleen een klus om onze bestaande uitbreidingen op FCK 2.x om te zetten..

Heb je wel eens naar WYMeditor gekeken? Ik wil daar binnenkort eens mee gaan spelen, daar het concept me wat geschikter lijkt om niet-technische gebruikers te dwingen in het door mij opgelegde layout-stramien te blijven (en dus goed te werken met semantische HTML).

[Anoniem: 313723]

Mag ik tevens vragen waar je gesolliciteerd hebt? (ik begin volgende week in zwolle op proef)

Ver, ver uit de buurt van Zwolle

Ik vond het persoonlijk ook een rare manier van doen, ik praat liever even met iemand. Twee-weg communicatie werkt natuurlijk een stuk prettiger. Maar, u vraagt wij draaien.
Aangezien ik wil laten zien dat ik gedegen informatica onderwijs genoten heb én met mijn anderhalf jaar .NET medior PHP niveau aankan, wil ik snippets uit verschillende categorieën toesturen.

A) Een stukje algemene algoritmiek zoals zoek- en sorteeralgoritmen;
Een stukje datastructuren, een eigen implementatie van enkele veel gebruikte datastructuren;
C) Een stukje security binnen een webomgeving, hoe om te gaan met XSS en SQL-Injection (bijvoorbeeld).

Uiteraard tot in de puntjes van duidelijk commentaar en toelichting voorzien én in een eenduidige duidelijke stijl geschreven.

[ Voor 6% gewijzigd door Anoniem: 313723 op 31-08-2009 17:29 ]

[curry684]

mithras schreef op maandag 31 augustus 2009 @ 16:51:
[...]
Ja ok, maar niet als je een up-to-date tinyMCE gebruikt en hem goed configureert. Je gaat natuurlijk niet uit van legacy

Ik zeg dus net dat er niet van op de hoogte was dat de huidige versie van MCE die property had toegevoegd...

En legacy mag je natuurlijk wel vanuit gaan als het heden ten dage nog steeds default behaviour is.

Maar om antwoord te geven op je vraag ( ), de Webrichtlijnen checker kan dus niet met de html5 doctype omgaan.

Thanks, kostte even wat moeite

De CSS-errors die hij aangeeft komen overigens hierdoor.

[R4gnax]

creator1988 schreef op maandag 31 augustus 2009 @ 14:36:
Ik vind eigenlijk al die editors verschrikkelijk werken. Werkte vroeger zelf veel met radEditor; die was nog wel redelijk. Voor de rest vind ik http://xstandard.com/ wel erg goed, maar die werkt met een clientside component.

radEditor van Telerik? Da's geinig: dat is precies de editor die wij willen gaan dumpen, omdat we alle issues die dat onding met zich mee brengt beu zijn.

Ik zou wel willen uitweiden, maar er staat vanavond voor mij eerst nog een slepende strijd met asp.net's validation framework op het menu. Iemand hier toevallig kaas gegeten van het schrijven van je eigen (template-bare) validationsummary control?

[Creepy]

djc schreef op maandag 31 augustus 2009 @ 17:28:
[...]
Heb je wel eens naar WYMeditor gekeken? Ik wil daar binnenkort eens mee gaan spelen, daar het concept me wat geschikter lijkt om niet-technische gebruikers te dwingen in het door mij opgelegde layout-stramien te blijven (en dus goed te werken met semantische HTML).

Van de wymeditor website:
No font or text formatting, sizes or colors

Daar gaan een hoop van onze klanten niet blij van worden

Voor het in een opgelegd stramien blijven gaan we ook niet een editor kant en klaar voor de complete contect gebruiken. De content is weer ingedeeld in blokken en die blokken kan je bewerken met een editor (fck, MCE, whatever). De blokken kan je weer drag'n'droppen, verwijderen, toevoegen, vanuit een RSS feed inlezen etc.

[ Voor 22% gewijzigd door Creepy op 31-08-2009 20:16 ]

[InZane]

mithras schreef op maandag 31 augustus 2009 @ 14:47:
Of is de vraag of je zelf geschreven html (zeg: templates) al in html5 kan gieten voor productie? Mja, zelf schrijf ik een html5 doctype waarbij ik me dus aan de html5 standaarden hou. Echter gebruik ik niet de elementen die er nieuw bij zijn gekomen, vanwege de ontbrekende ondersteuning in de meeste browsers.

Mij ontgaat hier de logica een beetje.
Waarom schrijf je in godsnaam een HTML 5 doctype en maak je verder helemaal geen gebruik van de mogelijkheden omdat veel browsers het nog niet ondersteunen (gek he)?
Waarom dan niet gewoon een HTML 4.01 doctype?

[creator1988]

Lekker aan het klooien met statistiekverwerking. 3 miljoen berichtjes per uur.

[user109731]

InZane schreef op dinsdag 01 september 2009 @ 09:32:
[...]
Waarom schrijf je in godsnaam een HTML 5 doctype en maak je verder helemaal geen gebruik van de mogelijkheden omdat veel browsers het nog niet ondersteunen (gek he)?

Ik gebruik ook vaak een HTML5 doctype, maar dat is meer uit gemakzucht. Vergelijk (HTML5):

HTML:

<!DOCTYPE html>

met (HTML 4.01):

HTML:

<!DOCTYPE HTML PUBLIC
  "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

De eerste tik ik in 2 seconden, voor de tweede moet ik óf heel hard nadenken óf 'm ergens copy/pasten

[jbdeiman]

Anoniem: 313723 schreef op maandag 31 augustus 2009 @ 17:28:
[...]

Ver, ver uit de buurt van Zwolle

Ik vond het persoonlijk ook een rare manier van doen, ik praat liever even met iemand. Twee-weg communicatie werkt natuurlijk een stuk prettiger. Maar, u vraagt wij draaien.
Aangezien ik wil laten zien dat ik gedegen informatica onderwijs genoten heb én met mijn anderhalf jaar .NET medior PHP niveau aankan, wil ik snippets uit verschillende categorieën toesturen.

A) Een stukje algemene algoritmiek zoals zoek- en sorteeralgoritmen;
Een stukje datastructuren, een eigen implementatie van enkele veel gebruikte datastructuren;
C) Een stukje security binnen een webomgeving, hoe om te gaan met XSS en SQL-Injection (bijvoorbeeld).

Uiteraard tot in de puntjes van duidelijk commentaar en toelichting voorzien én in een eenduidige duidelijke stijl geschreven.

Dit zijn inderdaad voorbeelden die je kan laten zien, een stukje code opsturen is vooral vaak bedoeld om te zien of je gestructureerd te werk gaat en of je met je werkwijze/ niveau (daarom ook raadzaam iets ingewikkelds op te sturen of iig met geavanceerdere technieken) het mogelijk maakt je snel in het team in te passen.
Vaak kan je al veel halen uit een stukje code, maar daarop gaat niet alles gebaseerd worden. Het is gewoon een eerste inschatting om niet in gesprek te hoeven gaan met iemand die er niets van bakt. Ik vind het helemaal niet raar, maar vind wel dat er best een extra "test" in een persoonlijk gesprek gedaan mag worden.

[Anoniem: 261819]

Vanavond maar eens kijken of ik een pixel shader plugin systeem kan maken voor mijn emulator. Het gaat allemaal wat langzamer dan ik wil, gewoon omdat ik maar een amateur programmeur ben. De meeste mensen hier zijn van beroep ook programmeur ?

BTW: koffie lust ik niet, geef mij maar een blikje taurine

[creator1988]

Professionele devs doen de hele dag niet zoveel. Creatief proces etc. dus vandaar dat we hier zitten,.

[Anoniem: 261819]

Ik ben ook maar een hobby programmeurtje, dus heb inderdaad geen idee wat professionele devs een hele dag doen Ik zit in een totaal andere IT beroepstak die helaas niet gerelateerd is met software engineering/development. Was gewoon nieuwsgierig hoeveel mensen hier de kost winnen met software development.

[ Voor 15% gewijzigd door Anoniem: 261819 op 01-09-2009 11:49 ]

[Remus]

JanDM schreef op dinsdag 01 september 2009 @ 10:22:
[...]

Ik gebruik ook vaak een HTML5 doctype, maar dat is meer uit gemakzucht. Vergelijk (HTML5):

HTML:

<!DOCTYPE html>

met (HTML 4.01):

HTML:

<!DOCTYPE HTML PUBLIC
  "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

De eerste tik ik in 2 seconden, voor de tweede moet ik óf heel hard nadenken óf 'm ergens copy/pasten

Weet je zeker dat dat de uiteindelijke HTML doctype gaat zijn? HTML 5 is nog heftig in ontwikkeling en waarschijnlijk hadden ze nog geen zin om een officiele doctype op te stellen. De doctype is namelijk incompleet (al is het een artefact van SGML).

[creator1988]

Anoniem: 261819 schreef op dinsdag 01 september 2009 @ 11:48:
Ik ben ook maar een hobby programmeurtje, dus heb inderdaad geen idee wat professionele devs een hele dag doen Ik zit in een totaal andere IT beroepstak die helaas niet gerelateerd is met software engineering/development. Was gewoon nieuwsgierig hoeveel mensen hier de kost winnen met software development.

Hmm volgens mij iedereen die hier regelmatig post is wel fulltime dev behalve 1.

[Erkens]

Remus schreef op dinsdag 01 september 2009 @ 11:52:
[...]


Weet je zeker dat dat de uiteindelijke HTML doctype gaat zijn? HTML 5 is nog heftig in ontwikkeling en waarschijnlijk hadden ze nog geen zin om een officiele doctype op te stellen. De doctype is namelijk incompleet (al is het een artefact van SGML).

quote: http://www.w3.org/TR/html5-diff/#doctype

The HTML syntax of HTML 5 requires a DOCTYPE to be specified to ensure that the browser renders the page in standards mode. The DOCTYPE has no other purpose and is therefore optional for XML. Documents with an XML media type are always handled in standards mode. [DOCTYPE]

The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax. DOCTYPEs from earlier versions of HTML were longer because the HTML language was SGML-based and therefore required a reference to a DTD. With HTML 5 this is no longer the case and the DOCTYPE is only needed to enable standards mode for documents written using the HTML syntax. Browsers already do this for <!DOCTYPE html>.

[Haan]

Anoniem: 261819 schreef op dinsdag 01 september 2009 @ 11:48:
Ik ben ook maar een hobby programmeurtje, dus heb inderdaad geen idee wat professionele devs een hele dag doen Ik zit in een totaal andere IT beroepstak die helaas niet gerelateerd is met software engineering/development. Was gewoon nieuwsgierig hoeveel mensen hier de kost winnen met software development.

Vooral veel koffie drinken Zeuren over onduidelijke specificaties die door functioneel consultants op papier worden gezet, af en toe een paar regeltjes code schrijven en in mijn geval regelmatig een potje pool spelen, omdat de pooltafel tegenover m'n bureau staat

Nee maar zonder gekkigheid er wordt natuurlijk ook wel hard gewerkt hier, en gestresst als er bepaalde deadlines naderen

[Anoniem: 142961]

Anoniem: 261819 schreef op dinsdag 01 september 2009 @ 11:48:
... dus heb inderdaad geen idee wat professionele devs een hele dag doen ...

Zoals creator1988 al impliceert: in de koffiehoek hangen teneinde het creatieve proces te stimuleren.

Daarnaast doen wij ook:

- wachten op compilatie, wachten op batch verwerkingsalgoritme en meer van die strekking (teneinde algoritmes te kunnen testen natuurlijk);

- includen van bugs teneinde werkverschaffing te creëren (noodzakelijk in barre tijden);

- ...

[momania]

Bij ons is het vooral zeuren over de gebruikers/de business/muppets die we moeten uitleggen waarom bepaalde keuzes beter zijn en beter aansluiten op hun business die ze zelf af en toe niet meer lijken te begrijpen

Ik hou me vooral bezig met trading applicaties/systemen en als je dan de meest basale dataflow probeert uit te leggen aan een trader staat hij al te klapperen met z'n oren

[ Voor 29% gewijzigd door momania op 01-09-2009 12:16 ]

[whoami]

Salon-devvers en pantoffelprogrammeurs hier in de coffeeshop.
Zouden beter een beetje meer devven, of posten in interessante topics in PRG, zoals deze \[.NET] Visual inheritance met een rare quirck

[Anoniem: 313723]

Haan schreef op dinsdag 01 september 2009 @ 11:59:
[...]

Vooral veel koffie drinken Zeuren over onduidelijke specificaties die door functioneel consultants op papier worden gezet, af en toe een paar regeltjes code schrijven en in mijn geval regelmatig een potje pool spelen, omdat de pooltafel tegenover m'n bureau staat

Nee maar zonder gekkigheid er wordt natuurlijk ook wel hard gewerkt hier, en gestresst als er bepaalde deadlines naderen

Een pooltafel! Geniaal! Bij ons hebben ze alleen tafelvoetbaltafels en die staan op de begane grond

[momania]

whoami schreef op dinsdag 01 september 2009 @ 12:17:
Salon-devvers en pantoffelprogrammeurs hier in de coffeeshop.

He, ik heb vakantie ja! Laat me met rust

[creator1988]

Ja en ik wacht op de compiler, DUS

En wij hebben geen vertier want het is allemaal volgebouwd met bureau's.

[momania]

Wachten op de compiler?

't Is 2009 hoor

[Anoniem: 196208]

Anoniem: 313723 schreef op dinsdag 01 september 2009 @ 12:18:
[...]

Een pooltafel! Geniaal! Bij ons hebben ze alleen tafelvoetbaltafels en die staan op de begane grond

Niks mis met tafelvoetbaltafels! Die hadden ze ook op mijn stage en dat versterkt de onderlinge competitie tussen de verschillende devteams (en de competitie van de devteams tegen mij
natuurlijk ). Bij poolen kan je maar met 1 vs 1, of je moet werken met afgevaardigden c.q. beurtenwissel.

[creator1988]

Oude bedrijf hadden we van die arcadekasten. Ook heel vet.

[Anoniem: 313723]

Nee, er is ook niets mis mee, maar je moet toch íets te zeuren en met dat als achterliggende filosofie mis ik een pooltafel

[Janoz]

We mogen hier dan wel tafelvoetbal tafels op de begane grond hebben... Hier op de 2e verdieping zijn beide koffieautomaten kapot. Maar eens even kijken of degene op de begane of de 3e het nog wel doen, en anders moet ik mijn contacten bij Landal maar eens even aanspreken....

[InZane]

We zijn hier voorzien van een pooltafel, een flipperkast en een Wii, maar eigenlijk gun ik me er bijna nooit tijd voor

[momania]

Hier tafelvoetbal tafel, pool tafel, PS3 en stepjes (voor als je heel snel bij de koffie wilt zijn )

[Cartman!]

Hier ook een pooltafel, relaxte bank en een 50" plasma + Wii. Soms staat er weleens een Xbox360 of PS3 als iemand die zelf meeneemt. Gebruik t niet zo vaak allemaal eigenlijk.

[boe2]

creator1988 schreef op dinsdag 01 september 2009 @ 11:33:
Professionele devs doen de hele dag niet zoveel. Creatief proces etc. dus vandaar dat we hier zitten,.

Stored procedures testen die minstens een halfuur duren om uit te voeren

[AtleX]

Gisterenavond ben ik nog even verder gegaan met mijn cache systeem, en na wat tweaken kom ik op het volgende uit:



Ik heb de standaard grootte van de memory cache beperkt tot 10. Dat blijkt de beste grootte zijn, een cache met een capaciteit van 30 blijkt zelden meer dan 10 items te bevatten namelijk. Om de boel op te ruimen wordt er via een Timer (elke 60000 ms) een Housekeeper()-methode aangeroepen die items die sinds de vorige clean-up niet meer bekeken zijn eruit gooit. Bij een fillfactor kleiner dan 0.8 wordt er trouwens niet opgeruimd.

In de grafiek is te zien hoe ik na het starten van TPP2 een aantal items in de cache laad. Vervolgens laat ik de applicatie een minuut idlen waarna de housekeeper de boel opruimt en het geheugen daalt tot een fatsoenlijk niveau. Piekverbruik bij deze run was trouwens zo'n 115MB zoals ook te zien is in de tooltip in het screenshot.

Dit lijken me wat betere waardes dan zo'n 150-300MB geheugen gebruiken.

[ Voor 18% gewijzigd door AtleX op 01-09-2009 13:35 ]

[djc]

Creepy schreef op maandag 31 augustus 2009 @ 20:14:
Daar gaan een hoop van onze klanten niet blij van worden

Dat gedeelte kan je uiteraard wel via CSS toegankelijk maken, het voorkomt alleen dat users als gekken <i> en <b> in je content droppen.

[R4gnax]

djc schreef op dinsdag 01 september 2009 @ 13:47:
[...]
Dat gedeelte kan je uiteraard wel via CSS toegankelijk maken, het voorkomt alleen dat users als gekken <i> en <b> in je content droppen.

Inderdaad. Een beetje zoals Word tegenwoordig óók met definieerbare styles werkt en het direct manipuleren van font grootte en bold, italic, underline, etc. eigenlijk niet meer van deze tijd is. En daar zit dan gelijk het probleem: de mogelijkheid er toe is er nooit uit gehaald.

Het is een stukje opvoeding van gebruikers wat gewoon nooit uitgevoerd is en/of zal worden, zolang grote bedrijven als Microsoft gebruikersgemak op het niveau van 'for dummies' boven correct gebruik blijven stellen. Vechten tegen de bierkaai enzo.

[creator1988]

* creator1988 wacht met smart tot ajax eindelijk eens een nieuwe verdediger presenteert

[kaesve]

hm, ik word hier plaatstelijk (als amateur-freelance-webdevver) totaal gestoord door wordpress die ineens het vertikt <p> toe te voegen aan nieuwe posts, alle handmatig toegevoegde <p> tags en <br /> verwijdert en bovendien alle gecopy-paste text tussen verscheidene (soms zelfs meerdere keren per regel) <span style="font-family: 'Verdana';"><span style="font-size: x-small;"> tags zet.. het ergste is dat ik hier pas net voor een deadline achter kom en het niet alleen 1 install van wordpress is..

hoe kun je dat nou stylen? ;-;

verder, hoe drinken jullie je koffie? als ik het zwaar heb drink ik graag mijn koffie uit een halve liter soepkom (wel met oortje om vast te houden).. gewoon 3 scheppen koffie erin, heet water erbij.. en ik kan er weer even tegenaan :0

[Creepy]

djc schreef op dinsdag 01 september 2009 @ 13:47:
[...]
Dat gedeelte kan je uiteraard wel via CSS toegankelijk maken, het voorkomt alleen dat users als gekken <i> en <b> in je content droppen.

De klanten moeten gewoon de knoppen gebruiken om tekst italic of bold te maken of zelf kleurtjes toe te kennen. Wat dat in HTML wordt zal de meesten een worst zijn. Maar een editor die dat direct beperkt en alles via CSS moet laten lopen gaat voor die klanten gewoon niet werken.

[creator1988]

kaesve schreef op dinsdag 01 september 2009 @ 16:54:
verder, hoe drinken jullie je koffie? als ik het zwaar heb drink ik graag mijn koffie uit een halve liter soepkom (wel met oortje om vast te houden).. gewoon 3 scheppen koffie erin, heet water erbij.. en ik kan er weer even tegenaan :0

Zwaar = espresso, espresso, espresso

[Remus]

kaesve schreef op dinsdag 01 september 2009 @ 16:54:
verder, hoe drinken jullie je koffie? als ik het zwaar heb drink ik graag mijn koffie uit een halve liter soepkom (wel met oortje om vast te houden).. gewoon 3 scheppen koffie erin, heet water erbij.. en ik kan er weer even tegenaan :0

Het zal wel vloeken in de kerk zijn, maar ik begin met een 'echte' koffie, daarna eigenlijk alleen decaf (maar wel goede decaf!). Gek genoeg merk ik - na een korte afkickperiode - niet zo veel verschil met voorheen, toen ik flink wat koffie achterover sloeg.

[R4gnax]

Creepy schreef op dinsdag 01 september 2009 @ 16:57:
[...]

De klanten moeten gewoon de knoppen gebruiken om tekst italic of bold te maken of zelf kleurtjes toe te kennen. Wat dat in HTML wordt zal de meesten een worst zijn. Maar een editor die dat direct beperkt en alles via CSS moet laten lopen gaat voor die klanten gewoon niet werken.

Ben ik niet met je eens. Een WYSIWYG editor voor een CMS moet het de klanten mogelijk maken om paragrafen, titels, genummerde lijsten, bulleted lijsten, opvallende tekst, etc. te maken in een opmaak die consistent is met de look&feel van hun website. Dat dit doorgaans gerealiseerd wordt door de styling compleet 100% vrij te geven en via UI elementen alle onderdelen ervan (kleur, letter grootte, letter dikte, etc.) voor de klant los instelbaar te maken, levert uiteindelijk alleen maar ongerief op.

Wij hebben al bij meerdere klanten meegemaakt dat we (full service, vandaar...) artikelen achteraf op kunnen gaan zitten schonen. Het varieert dan van het opruimen van ranzige html gevormd door 10 keer achter elkaar italic en bold aan of uit te zetten tot inconsiste groottes voor titels tussen verschillende artikelen (of zelfs binnen hetzelfde artikel). In die gevallen werd het gewoon zo'n puinhoop dat de klant er zelf niet meer uit kwam. Dat kan ik me ook levendig indenken, want het wordt dan zo'n troep dat je niet anders kunt dan de WYSIWYG omzeilen en met de hand de HTML direct bij te werken. Dat kun je onmogelijk van een klant eisen: hij/zij kiest net voor een kant-en-klaar managed oplossing omdat daarvoor (uitgebreid) verstand van HTML, CSS, enz. niet nodig is.


Sinds dat soort problemen een aantal keer voorgevallen zijn, zijn we begonnen voorgebakken formatting voor 'titel', 'hyperlink', 'opvallende tekst', enz. aan te bieden in dezelfde trend als Word werkt met styles. Een aantal klanten die ook echt in de WYSIWYG editor werken (en niet alles eerst in Word opmaken en dan naar de editor copy-pasten) viel dat al meteen op als zijnde 'handig', voor zover ik vernomen heb. In ieder geval hebben we geloof ik sindsdien geen massale verzoeken meer gehad om WYSIWYG-gegenereerde rommel op te schonen...

[wackmaniac]

Hier een laffe cappuchino met suiker / zoetstof, sorry Maar dan natuurlijk wel in mijn allercoolste Office Space "Is this good for the company" mok!

Even helemaal off topic; ik moest vandaag denken aan een flash-movie die ik al een flinke tijd geleden heb gezien, maar waarvan ik de titel niet meer weet of hoe ik die in godsnaam weer zou kunnen vinden. Was een video die een side scrolling game voorstelde met als klap op de vuurpijl een enorme Walter Sobchak die met een gun in zijn hand uitschreeuwt: "You are entering a world of pain!". Iemand een idee?

[ Voor 14% gewijzigd door wackmaniac op 01-09-2009 20:33 . Reden: linkje erbij ]

[zwippie]

kaesve schreef op dinsdag 01 september 2009 @ 16:54:
verder, hoe drinken jullie je koffie? als ik het zwaar heb drink ik graag mijn koffie uit een halve liter soepkom (wel met oortje om vast te houden).. gewoon 3 scheppen koffie erin, heet water erbij.. en ik kan er weer even tegenaan :0

Water koken, filterhouder met nummertje 4 op een forse mok zetten, 2 scheppen Kanis en Gunnink erin, water opgieten, even laten zakken, nog wat water opgieten, ook langs de randjes, 3 scheppen suiker er in, goed roeren en...

Mmmmm.

[Creepy]

R4gnax schreef op dinsdag 01 september 2009 @ 19:22:
[...]


Ben ik niet met je eens. Een WYSIWYG editor voor een CMS moet het de klanten mogelijk maken om paragrafen, titels, genummerde lijsten, bulleted lijsten, opvallende tekst, etc. te maken in een opmaak die consistent is met de look&feel van hun website. Dat dit doorgaans gerealiseerd wordt door de styling compleet 100% vrij te geven en via UI elementen alle onderdelen ervan (kleur, letter grootte, letter dikte, etc.) voor de klant los instelbaar te maken, levert uiteindelijk alleen maar ongerief op.

Dat ben ik met je eens. Maar ik persoonlijk vindt het idioot dat je klanten moet aanleren om een stijl te gebruiken als ze alleen maar tekst bold willen hebben bijv. Dan ben je bezig met semantische HTML en dan ga je een CSS style gebruiken terwijl het eigenlijk een em of strong tag had moeten zijn. Dus ja: wij geven de klant het knopje met de B erop die dat regelt..

Wij hebben al bij meerdere klanten meegemaakt dat we (full service, vandaar...) artikelen achteraf op kunnen gaan zitten schonen. Het varieert dan van het opruimen van ranzige html gevormd door 10 keer achter elkaar italic en bold aan of uit te zetten tot inconsiste groottes voor titels tussen verschillende artikelen (of zelfs binnen hetzelfde artikel). In die gevallen werd het gewoon zo'n puinhoop dat de klant er zelf niet meer uit kwam. Dat kan ik me ook levendig indenken, want het wordt dan zo'n troep dat je niet anders kunt dan de WYSIWYG omzeilen en met de hand de HTML direct bij te werken. Dat kun je onmogelijk van een klant eisen: hij/zij kiest net voor een kant-en-klaar managed oplossing omdat daarvoor (uitgebreid) verstand van HTML, CSS, enz. niet nodig is.

Hier worden met enige regelmaat zaken opgeschoont. Dat komt omdat we nu per pagina (eigenlijk per e-mail aangezien we geen websites beheren en geen CMS'en maken ) een volledige editor hebben. Het gaat mis omdat klanten niet altijd de structuur begrijpen. Maar ze willen wel werken "net als in Word" op het moment dat ze de content aan het vullen zijn. De opmaak die door elkaar gaat lopen is een technisch probleem en dit is ook gewoon op te lossen. Mocht dat niet lukken dan zijn er genoeg editors die een knop hebben om de geselecteerde tekst direct van alle opmaak te ontdoen. Dat soort opmaak problemen kan de klant dan ook prima zelf oplossen.

Sinds dat soort problemen een aantal keer voorgevallen zijn, zijn we begonnen voorgebakken formatting voor 'titel', 'hyperlink', 'opvallende tekst', enz. aan te bieden in dezelfde trend als Word werkt met styles. Een aantal klanten die ook echt in de WYSIWYG editor werken (en niet alles eerst in Word opmaken en dan naar de editor copy-pasten) viel dat al meteen op als zijnde 'handig', voor zover ik vernomen heb. In ieder geval hebben we geloof ik sindsdien geen massale verzoeken meer gehad om WYSIWYG-gegenereerde rommel op te schonen...

Hier willen we de klant eigenlijk niet eens bezig zien met de opmaak. De klant krijgt een template en kan daarin gewoon direct teksten aanpassen die direct in de juiste stijl staan. Om de structuur problemen op te lossen gaan we ervoor zorgen het daadwerkelijk bewerken van de content in losse blokken (artikelen..) gebeurd. Maar klanten willen nu eenmaal af en toe iets bold maken, underlines, of zelf een stukje tekst rood maken.

[Creepy]

Maaruh, na die veel te lange posts is het tijd om de koffie mok weg te zetten en te gaan doen

[BalusC]

Aargh, ik was voor een website die al in prod is aan het devven (nieuwe features enzo). Om de aanpassingen te controleren cq testen na een deploy F5'te ik dus even de webbrowser. Geen veranderingen .. Toen maar ff de source bekeken, ook niks .. CTRL+F5'en dan maar. Noppes .. Nouja, testserver helemaal platleggen, cache legen en opnieuw herstarten. Niks ..

Was ongeveer zo een half uur bezig totdat ik me realiseerde dat ik de prod site zat te F5'en ipv de test

Zucht