(non) Werkbare dagen bepalen (ook i18n)

[Standeman]

Ik ben op dit moment bezig met een planningstool om automatisch een planning te genereren. Op zich niet zo heel erg lastig maar nu heb ik wat ontworpen waarvan ik het vermoeden heb dat het hier en daar nog wat verbeterd of versimpeld kan worden.

Het probleem waar ik een beetje mee worstel is het bepalen van de werkbare dagen. Wanneer er een taak gepland wordt op een niet werkbare dag (pasen, kerst, talk-like-a-pirate-day) dient de taak de eerst volgende werkbare dag gepland te worden. Dit is klant specifiek en hangt ook af van o.a. het land waar de klant in werkt.

qua DB had ik het volgende bedacht.

NonWorkingDays
customerid	int(11)	id van de customer
date	datetime	datum van de niet werkbare dag (c.q. 25-12-2010)
recurrence	varchar(10)	Herhaalt deze dag zich? Tijdsperiode van de herhaling: null (no recurrence) of Daily / Weekly / Monthly / Yearly?
name	varchar(30)	naam van de feestdag
avoid	boolean	of de planning deze dag moet vermijden

Het principe is vrij simpel. De standaard feestdagen (bijv. de kerstmis) worden vanuit een i18n language file uitgelezen bij het aanmaken van een customer. De customer zelf krijgt een beheerpagina waarin deze kan wijzigen en ook niet werkbare dagen kan toevoegen / verwijderen (gesorteerd per jaar).

Het meest interessante deel is de recurrence kolom. Deze geeft aan of de planner moet kijken naar het jaartal (in geval van null) van de datum of niet. De kolom geeft dus aan of de dag herhaalt moet worden en ook in welke periode (bijvoorbeeld: zondag, weekly / christmasday, yearly)

De bedoeling is dus dat de planner een collectie krijgt van de non-working days voor de tijdsperiode waarin gepland wordt. Wanneer een geplande datum in deze collectie voorkomt zal de taak opnieuw geplanned worden op de eerstvolgende werkdag d.m.v. "brute force".

simpele pseudo code:

code:

while (nonworkingdays.contains(plannedDate))
{
    plannedDate.nextDay();
}

Ik zit me overigens nog te bedenken wat ik met feestdagen zoals pasen / carnaval doe welke elk jaar op een andere datum vallen. Aangezien ik niet voor elke vage feestdag een bepaalde implementatie wil schrijven, zit ik er aan te denken om dit door de user zelf te laten invullen.

[RobIII]

Los van dat ik van recurrence een enum (of hell, een int) zou maken zie ik weinig problemen. Inderdaad zijn dagen als "derde dinsdag van september" niet te vangen hiermee, evenals pasen e.d. wat je zelf al opmerkt. Wat dat betreft zijn datums (al dan niet i18n) gewoon ronduit ruk. Dan hebben we weer een leap-second, dan weer een leap-year, dan weer een pasen die op datum X valt en dan weer op Y. Dat hou je toch en voorkom je niet echt. Het makkelijkst lijkt me om ieder jaar (of een paar jaar vooruit) de definities per land (per klant) te vullen.


Ik zie overigens niet echt een vraag in je topic? Wat is je vraag precies?

Overigens, bedenk ik net, in Outlook (om maar wat te noemen) kun je feestdagen exporteren naar een CSV ofzo als ik me niet vergis. Die data zou je een klant natuurlijk ook gewoon kunnen laten importeren. Als ik me niet vergis is Outlook voorzien van een shitload van die data in heel veel lokales en voor een aantal jaar vooruit, maar dat zou ik even moeten nakijken. Als je uitvindt in welk bestand die gegevens zitten heb je iig al een leuk begin denk ik voor je klanten (moet je wel even uitzoeken in hoeverre het legaal is die data te gebruiken). En er zijn vast ook wel webservices die dit soort gegevens aanbieden waar je ze weg kunt trekken.

[ Voor 34% gewijzigd door RobIII op 12-10-2010 14:12 ]

[Jaap-Jan]

Sommige van die dagen vallen (zoals prinsjesdag) op de 3^e dinsdag van september. Misschien dat je er op die manier rekening mee kan houden.

[F_J_K]

Je hebt inderdaad vage regels zoals pak-em-beet de 3e zondag van augustus, behalve als het volle maan is op de tweede dinsdag van juni.Dat ga je niet voor iedere regio in de wereld vooraf bedenken.

Aanvullen / verwijderen door de klant lijkt me sowieso verstandig. Maar voor de jaarlijkse standaardvulling zou ik kijken of er niet per land waar je actief bent een standaardvulling kan neerzetten die men dan wel moet kunnen overrulen. Zet ergens een te downloaden file of doe een voorinvulling die men kan overrulen. Voor jou amper werk, maar wel leuke klantenbinding
Of je dat overrulen dan ook weer eenmalig doet of jaarlijks (pak-em-beet een bedrijf dat 24x7-diensten draait, behalve in de bouwvak en kerst) is dan nog wel een aandachtspuntje.

Afhankelijk van het soort planning zal je trouwens ook het toch inplannen op feestdagen mogelijk moeten maken IMHO (bijv. bij een rush order die voor de feestdagen af moet zijn).

[ Voor 0% gewijzigd door F_J_K op 12-10-2010 14:14 . Reden: man? men. En ik ben een beetje spuit11 zie ik \o/ ]

[RobIII]

Jaap-Jan schreef op dinsdag 12 oktober 2010 @ 14:11:
Sommige van die dagen vallen (zoals prinsjesdag) op de 3^e dinsdag van september. Misschien dat je er op die manier rekening mee kan houden.

Dat is leuk voor prinsjesdag en misschien nog een paar anderen maar er zijn zat data die elk jaar arbitrair gekozen worden (of door de Paus aangewezen of weet ik het). Net als voor Carnaval zijn die data vaak wel al voor de komende X jaar bekend, maar een patroon zit er vaak niet of amper in.

[F_J_K]

RobIII schreef op dinsdag 12 oktober 2010 @ 14:13:
Dat is leuk voor prinsjesdag en misschien nog een paar anderen maar er zijn zat data die elk jaar arbitrair gekozen worden (of door de Paus aangewezen of weet ik het). Net als voor Carnaval zijn die data vaak wel al voor de komende X jaar bekend, maar een patroon zit er vaak niet in.

Carnaval is niet alleen elk jaar verschillend, het is ook niet per se in elke regio binnen een land gelijk. Ik kwam vroegah vaak in een dorp waar de carnaval een week eerder was dan in de rest van het land.

En dan zijn er nog de kermissen, Nijmeegse vierdaagsen, etc, die zorgen voor dagen die je niet in je planning mee wilt nemen.

[RobIII]

F_J_K schreef op dinsdag 12 oktober 2010 @ 14:15:
[...]

Carnaval is niet alleen elk jaar verschillend, het is ook niet per se in elke regio binnen een land gelijk. Ik kwam vroegah vaak in een dorp waar de carnaval een week eerder was dan in de rest van het land.

Klopt. En wat betreft de data: er zit wel degelijk een 'systeem' in soms, maar het is helaas niet zo makkelijk als "de x-te dag van y". Dat soort zaken wil je, IMHO, iig niet in code gaan steken. Vandaag of morgen bedenkt iemand zich in Rome en kun je je code gaan herzien

[Tylocke]

Standeman schreef op dinsdag 12 oktober 2010 @ 14:04:
Ik zit me overigens nog te bedenken wat ik met feestdagen zoals pasen / carnaval doe welke elk jaar op een andere datum vallen. Aangezien ik niet voor elke vage feestdag een bepaalde implementatie wil schrijven, zit ik er aan te denken om dit door de user zelf te laten invullen.

Ik kan je alleen vertellen hoe we hier te werk gaan met een gekocht planningspakket.

Het pakket werkt met kalenders die de klant kan opgeven per job (default kalender is ook mogelijk). Daardoor is een variatie per regio/land mogelijk.

Deze kalenders bestaan uit standaard vrije dagen (zoals de zaterdag en zondag) en tevens kunnen specifieke dagen worden opgegeven. Komt de planning op één van deze dagen voor wordt deze op één van de 4 manieren gebruikt:

1) Een dag ervoor
2) Of een dag erna
3) Of helemaal niet ingepland
4) Of negeer de kalender en draai op de ingeplande dag

Deze optie wordt ook meegegeven aan de job.

Hopelijk heb je hier wat aan.

[Standeman]

RobIII schreef op dinsdag 12 oktober 2010 @ 14:09:
Los van dat ik van recurrence een enum (of hell, een int) zou maken zie ik weinig problemen. Inderdaad zijn dagen als "derde dinsdag van september" niet te vangen hiermee, evenals pasen e.d. wat je zelf al opmerkt. Wat dat betreft zijn datums (al dan niet i18n) gewoon ronduit ruk. Dan hebben we weer een leap-second, dan weer een leap-year, dan weer een pasen die op datum X valt en dan weer op Y. Dat hou je toch en voorkom je niet echt. Het makkelijkst lijkt me om ieder jaar (of een paar jaar vooruit) de definities per land (per klant) te vullen.

leap seconds / years komen wel goed. Maar datums zijn inderdaad ruk. Ik ben al blij dat ik niets met Hijri, boedhistisch, etc te maken heb i18n slaat eigenlijk voornamelijk op west europa in mijn geval. Tegen de tijd dat we verder dan west-europa gaan, is het budget er ook wel voor om dit aan te passen

Ik zie overigens niet echt een vraag in je topic? Wat is je vraag precies?

Dat is idd niet echt duidelijk. Eigenlijk is de vraag of ik niet aan het over / under engineering ben. Vergeet ik belangrijke zaken of kan het juist simpeler?

Overigens, bedenk ik net, in Outlook (om maar wat te noemen) kun je feestdagen exporteren naar een CSV ofzo als ik me niet vergis. Die data zou je een klant natuurlijk ook gewoon kunnen laten importeren. Als ik me niet vergis is Outlook voorzien van een shitload van die data in heel veel lokales en voor een aantal jaar vooruit, maar dat zou ik even moeten nakijken. Als je uitvindt in welk bestand die gegevens zitten heb je iig al een leuk begin denk ik voor je klanten (moet je wel even uitzoeken in hoeverre het legaal is die data te gebruiken). En er zijn vast ook wel webservices die dit soort gegevens aanbieden waar je ze weg kunt trekken.

Dat is wel goed idee. De software draait op een SaaS platform, dus klanten hoeven niet zelf dingen te gaan zitten pielen met outlook. Webservices van "onbekende" partijen ben ik niet zo fan van. Ik heb al onaangekondigde wijzigingen in de API of het staken van de service meegemaakt.

@de rest
Blijkbaar een goede keuze geweest om klanten regionale feestdagen zelf te laten inplannen. Ik maak wel een soort van copy functie zodat ze makkelijk 2010 naar 2011 kunnen kopiëren, maar dat ze dan alleen nog pasen en de rest mogen invullen

type_o schreef op dinsdag 12 oktober 2010 @ 14:23:
[...]


Ik kan je alleen vertellen hoe we hier te werk gaan met een gekocht planningspakket.

Het pakket werkt met kalenders die de klant kan opgeven per job (default kalender is ook mogelijk). Daardoor is een variatie per regio/land mogelijk.

Deze kalenders bestaan uit standaard vrije dagen (zoals de zaterdag en zondag) en tevens kunnen specifieke dagen worden opgegeven. Komt de planning op één van deze dagen voor wordt deze op één van de 4 manieren gebruikt:

1) Een dag ervoor
2) Of een dag erna
3) Of helemaal niet ingepland
4) Of negeer de kalender en draai op de ingeplande dag

Deze optie wordt ook meegegeven aan de job.

Hopelijk heb je hier wat aan.

hmmm, goede functionaliteit. Die opties zijn ook wel relatief simpel te implementeren.

[ Voor 16% gewijzigd door Standeman op 12-10-2010 14:44 . Reden: quote tag fix ]

[Janoz]

Persoonlijk zou ik een andere benadering kiezen. De niet werkbare dagen wordt over het algemeen vele malen meer gelezen dan geschreven. Alle zoveelste datzodag na de derde volle maan voor pasen achtige functionaliteit zou ik in de beheertool zelf implementeren en uiteindelijk wegschrijven in een heel simpel tabelletje per dag. Eventueel een id opnemen die voor alle herhalende entries hetzelfde is zodat ze allemaal gemakkelijk te verwijderen zijn wanneer ze aangepast worden.

Nadeel is misschien dat er wat extra ruimte nodig is in de tabel, maar dat weegt imho niet op tegen het voordeel dat het vergelijken heerlijk simpel is en dat de logica omtrent het inserten en beheren van de dagen keurig containt is in (de business logic van) een specifieke beheer module. Het wordt bijvoorbeeld erg makkelijk om later nieuwe terugkerende functionaliteit toe te voegen zonder dat het de gehele applicatie raakt.

[FoOnEeN]

Het wordt weer extra leuk als je begint met weeknummers. Er zijn namelijk genoeg jaren met 53 weken (jaja) voor code. Erg leuk als je schedule systeem ineens raar gaat doen op zo'n dag.

Ligt trouwens aan het feit op wat voor dag nieuwjaar is geloof ik. 1 jan = woensdag, dan zijn geloof ik maandag en dinsdag week 53 of zoiets.

Maar dat is eigenlijk een beetje beside the point hier.

Edit:

Nope. De hele week heeft hetzelfde weeknummer. Het wordt niet vanaf een dag midden in de week ineens weeknr 1. In nederland is weeknr 1 de eerste week waarvan de donderdag in het nieuwe jaar valt*. Woensdag 31 december is dan al gewoon week 1.

Ah Janoz dat was het inderdaad, de fijne details waren mij ontschoten na 1-2 jaar .

[ Voor 31% gewijzigd door FoOnEeN op 12-10-2010 16:04 ]

[Standeman]

Janoz schreef op dinsdag 12 oktober 2010 @ 14:45:
Persoonlijk zou ik een andere benadering kiezen. De niet werkbare dagen wordt over het algemeen vele malen meer gelezen dan geschreven. Alle zoveelste datzodag na de derde volle maan voor pasen achtige functionaliteit zou ik in de beheertool zelf implementeren en uiteindelijk wegschrijven in een heel simpel tabelletje per dag. Eventueel een id opnemen die voor alle herhalende entries hetzelfde is zodat ze allemaal gemakkelijk te verwijderen zijn wanneer ze aangepast worden.

Nadeel is misschien dat er wat extra ruimte nodig is in de tabel, maar dat weegt imho niet op tegen het voordeel dat het vergelijken heerlijk simpel is en dat de logica omtrent het inserten en beheren van de dagen keurig containt is in (de business logic van) een specifieke beheer module. Het wordt bijvoorbeeld erg makkelijk om later nieuwe terugkerende functionaliteit toe te voegen zonder dat het de gehele applicatie raakt.

Dus simpel gezegd die recurrence uit die tabel slopen en voor elke land / taal gebied een template maken met de standaard feest / vrije dagen. Voor elk jaar een kopietje maken van die template en die laten aanvullen voor o.a. pasen e.d. Zodat je dan een volledige lijst krijgt met niet werkbare dagen.

Maakt het idd wel een stuk eenvoudiger. Alleen bij wijzigingen (bijvoorbeeld zondag verruilen met maandag) wel weer wat lastiger.

FoOnEeN schreef op dinsdag 12 oktober 2010 @ 14:53:
Het wordt weer extra leuk als je begint met weeknummers. Er zijn namelijk genoeg jaren met 53 weken (jaja) voor code. Erg leuk als je schedule systeem ineens raar gaat doen op zo'n dag.

Ligt trouwens aan het feit op wat voor dag nieuwjaar is geloof ik. 1 jan = woensdag, dan zijn geloof ik maandag en dinsdag week 53 of zoiets.

Maar dat is eigenlijk een beetje beside the point hier.

Heb ik al een keer mogen implementeren voor j2me

[ Voor 4% gewijzigd door Standeman op 12-10-2010 14:59 ]

[Janoz]

Standeman schreef op dinsdag 12 oktober 2010 @ 14:57:
Maakt het idd wel een stuk eenvoudiger. Alleen bij wijzigingen (bijvoorbeeld zondag verruilen met maandag) wel weer wat lastiger.

Zondag lijkt mij een voorbeeld van een herhalende zelfde soort dag die dus overal dezelfde 'refid' heeft waardoor hij in 1x uit de tabel gegooid kan worden.

De complexiteit zet je gewoon in de non workable days beheer applicatie. Deze maakt het vervolgens ook heel simpel om een ical, csv of misschien wel rss import implementatie toe te voegen zonder dat de hele applicatie overhoop moet.

[Janoz]

FoOnEeN schreef op dinsdag 12 oktober 2010 @ 14:53:
Ligt trouwens aan het feit op wat voor dag nieuwjaar is geloof ik. 1 jan = woensdag, dan zijn geloof ik maandag en dinsdag week 53 of zoiets.

Nope. De hele week heeft hetzelfde weeknummer. Het wordt niet vanaf een dag midden in de week ineens weeknr 1. In nederland is weeknr 1 de eerste week waarvan de donderdag in het nieuwe jaar valt*. Woensdag 31 december is dan al gewoon week 1.


* Versimpeling van de regel dat het grootste deel van de week in het nieuwe jaar valt uitgaande van het gegeven dat de week begint op maandag. Daarkomt ook het verschil in weeknummers vandaan. Sommige landen vinden dat een week op zondag begint waardoor het omslagpunt op woensdag komt te liggen.

[creator1988]

Waarom willen mensen dit niet in code? Je gaat nu zover abstraheren dat je imho beter gewoon in code kan houden, aangezien je rule engine een eigen taal wordt die de functies in je code gaat mirroren (alleen dan slechter). Je framework weet bovendien veel meer over locals, regels in bepaalde cultures etc. Ergo: in the end wordt de abstractie zo ingewikkeld dat je alsnog developers nodig gaat hebben om dit allemaal in te regelen.

Doe dit maar eens in je geabstraheerde taal:

code:

class IsEasterSunday : INonWorkingDay
{
     bool IsNonWorkingDay(DateTime dt, CultureInfo culture)
     {
                int Year = dt.Year;

        int Month = 3;

        // Determine the Golden number:
        int G = Year % 19 + 1;

        // Determine the century number:
        int C = Year / 100 + 1;

        // Correct for the years who are not leap years:
        int X = ( 3 * C ) / 4 - 12;

        // Mooncorrection:
        int Y = ( 8 * C + 5 ) / 25 - 5;

        // Find sunday:
        int Z = ( 5 * Year ) / 4 - X - 10;

        // Determine epact(age of moon on 1 januari of that year(follows a cycle of 19 years):
        int E = ( 11 * G + 20 + Y - X ) % 30;
        if (E == 24) {E++;}
        if ((E == 25) && (G > 11)) {E++;}

        // Get the full moon:
        int N = 44 - E;
        if (N < 21) {N = N + 30;}

        // Up to sunday:
        int P = ( N + 7 ) - ( ( Z + N ) % 7 );

        // Easterdate: 
        if ( P > 31 )
        {
            P = P - 31;
            Month = 4;
        }
        var easter = new DateTime(Year, Month, P);

        return easter == dt;
      }
}

[ Voor 3% gewijzigd door creator1988 op 14-10-2010 12:57 ]

[DJMaze]

Lees eens de iCalendar specificatie door http://www.ietf.org/rfc/rfc2445.txt

Verder gebruik ik meestal een "national_holidays" tabel.

code:

CREATE TABLE  bys_holidays (
  `holiday_date` date NOT NULL,
  `holiday_name` varchar(100) COLLATE utf8_bin NOT NULL,
  `holiday_yearly` tinyint(4) NOT NULL,
  `holiday_class` varchar(20) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`holiday_date`),
  KEY `i_holidays_date` (`holiday_date`,`holiday_yearly`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Met data zoals:

code:

2000-01-01 | Nieuwjaarsdag  | 1 | newyearsday
2000-05-05 | Bevrijdingsdag | 5 | bevrijdingsdag
2010-04-04 | 1e Paasdag     | 0 | eastern

En SQL functies zoals (deze klop niet, maar is een hint):

code:

CREATE FUNCTION COUNT_WORKDAYS(dtstart DATETIME, dtend DATETIME) RETURNS double(5,1)
BEGIN

    DECLARE days DOUBLE(5,1);

    SET days = DATEDIFF(dtend, dtstart);

    IF (TIME_TO_SEC(TIMEDIFF(dtend, dtstart))/3600)%24>3 AND (TIME_TO_SEC(TIMEDIFF(dtend, dtstart))/3600)%24<8 THEN SET days = days+0.5; END IF;

    WHILE (dtstart<dtend) DO

        IF DAYOFWEEK(dtstart) = 1 # zondag

        OR DAYOFWEEK(dtstart) = 7 # zaterdag

        OR (MONTH(dtstart) = 1 AND DAY(dtstart) = 1) # nieuwjaarsdag

        OR (MONTH(dtstart) = 4 AND DAY(dtstart) = 30) # konginnedag

        OR (MONTH(dtstart) = 5 AND DAY(dtstart) = 5 AND YEAR(dtstart)%5 = 0) # bevrijdingsdag

        OR (MONTH(dtstart) = 12 AND (DAY(dtstart) = 25 OR DAY(dtstart) = 26)) # kerst

        THEN

            SET days = days-1;

        END IF;

        SET dtstart = DATE_ADD(dtstart, INTERVAL 1 DAY);

    END WHILE;

    RETURN days;

END

Voor een uitgebreid systeem heb je wel veel meer data nodig,
Denk eens aan "elke zaterdag vrij behalve de laatste zaterdag van de maand"

[Janoz]

creator1988 schreef op donderdag 14 oktober 2010 @ 12:57:
Waarom willen mensen dit niet in code? Je gaat nu zover abstraheren dat je imho beter gewoon in code kan houden, aangezien je rule engine een eigen taal wordt die de functies in je code gaat mirroren (alleen dan slechter). Je framework weet bovendien veel meer over locals, regels in bepaalde cultures etc. Ergo: in the end wordt de abstractie zo ingewikkeld dat je alsnog developers nodig gaat hebben om dit allemaal in te regelen.

In code lijkt me juist een slechtere keuze. Het is onmogelijk om op voorhand te kunnen bepalen wat voor de klant nu juist wel, of juist niet een non working day is. Vandaar dat een door de gebruiker te vullen tabel met niet werkdagen een veel betere oplossing is.

Mijn voorstel was om die zo simpel mogelijk te houden (enkel een datum en geen herhalings logica, dat ben ik dan weer wel met je eens) en vervolgens de door jou voorgestelde code eerder in de nietwerkdagenbeheertool ( ) te implementeren.

[creator1988]

Janoz schreef op donderdag 14 oktober 2010 @ 20:05:
[...]

In code lijkt me juist een slechtere keuze. Het is onmogelijk om op voorhand te kunnen bepalen wat voor de klant nu juist wel, of juist niet een non working day is. Vandaar dat een door de gebruiker te vullen tabel met niet werkdagen een veel betere oplossing is.

Mijn voorstel was om die zo simpel mogelijk te houden (enkel een datum en geen herhalings logica, dat ben ik dan weer wel met je eens) en vervolgens de door jou voorgestelde code eerder in de nietwerkdagenbeheertool ( ) te implementeren.

Mweh, dit gaat uiteindelijk zo complex worden dat je toch een dev nodig gaat hebben om de aanpassingen te maken. Kan je het net zo goed in een config bestand zetten dat daarna on-the-fly gecompileerd wordt of in losse assemblies die je snel kan bouwen als een klant erom vraagt.

En wat beats dit qua config vrijheid en makkelijke uitbreidbaarheid door iedereen met een beetje verstand?

XML:

<NonWorkingDay desc="Kerst">
   dt.Day == 25 && dt.Month == 12
</NonWorkingDay>

Kan je compileren bij de eerste run van je applicatie tot:

code:

return dt=>dt.Day == 25 && dt.Month == 12;

en daarna razendsnel valideren. Onze rule-engine voor het valideren van url's in statistiekberichten werkt zo en ik had dat absoluut niet in een database ofzo willen hebben. Op deze manier kan beheer makkelijk regels aanpassen op aanwijzen van dev, en het is prima leesbaar.

[ Voor 17% gewijzigd door creator1988 op 15-10-2010 08:41 ]

[Janoz]

Voor jou oplossing moet, bij aangepaste niet werkdagen, de applicatie opnieuw gecompileerd worden. In mijn oplossing kan gewoon de vulling van de database aangepast worden. Bedenk dat het hier oom saas gaat. Dat is niet even iets wat je zomaar reboot omdat 1 klant een andere niet werk dag heeft.

[F_J_K]

Voor andere doeleinden dan dit zal het verstandig kunnen zijn. Maar inderdaad wil je in een SaaS-omgeving niet opnieuw compileren etc. Zelfs niet als het per klant maar eenmaal per jaar zou gebeuren. Vakantiedagen zijn imho ook geen dingen waar je devvers zich mee bezig zouden moeten houden. Ook lokaal zou ik dat voor zoiets niet willen trouwens (behalve in het kader van job security dan )

Het is - neem ik aan - niet zo dat valideren van vakantiedagen nu zo enorm vaak voorkomt dat het snelheidsvoordelen t.o.v. een (slim ingerichte) DB heeft om het hard in de code te zetten. Als je het 'dom' in een database zet kan je het natuurlijk nog steeds op verschillende manieren configureren: via een webinterface maar ook best door het inladen van een XML-file zoals jouw voorbeeld.

[RobIII]

F_J_K schreef op vrijdag 15 oktober 2010 @ 09:15:
Vakantiedagen zijn imho ook geen dingen waar je devvers zich mee bezig zouden moeten houden.

Die gaat in een Quote-DB ergens

[orf]

Ik ben hier ook bezig met een planningstool. De standaard non werkbare dagen sla ik ook gewoon per jaar op, zonder recurrence. Dat is aan het begin van het jaar vrij gemakkelijk toe te voegen. Het moet toch al in agenda's en dergelijke opgenomen worden dus kan het in één moeite door in de planningstool.

Waar ik meer moeite mee heb zijn de werkroosters van medewerkers, vakantiedagen en ziekte. Medewerkers hebben een contract en een contract heeft een rooster. Een rooster heeft werkdagen en uren en in veel gevallen komen daar leuke dingen bij als halve dagen werken, op oneven weken een dag vrij, studiedagen, vrijdagmiddagborrel (die soms op donderdag wordt gehouden), etc.

Het wordt dan vooral leuk met inplannen op meerdere medewerkers over meerdere contracten.

[creator1988]

Janoz schreef op vrijdag 15 oktober 2010 @ 08:50:
Voor jou oplossing moet, bij aangepaste niet werkdagen, de applicatie opnieuw gecompileerd worden. In mijn oplossing kan gewoon de vulling van de database aangepast worden. Bedenk dat het hier oom saas gaat. Dat is niet even iets wat je zomaar reboot omdat 1 klant een andere niet werk dag heeft.

Nee? Je kan een filewatcher hebben op je configfile die on the fly CodeDOM't?

orf schreef op vrijdag 15 oktober 2010 @ 12:04:
Ik ben hier ook bezig met een planningstool. De standaard non werkbare dagen sla ik ook gewoon per jaar op, zonder recurrence. Dat is aan het begin van het jaar vrij gemakkelijk toe te voegen. Het moet toch al in agenda's en dergelijke opgenomen worden dus kan het in één moeite door in de planningstool.

Waar ik meer moeite mee heb zijn de werkroosters van medewerkers, vakantiedagen en ziekte. Medewerkers hebben een contract en een contract heeft een rooster. Een rooster heeft werkdagen en uren en in veel gevallen komen daar leuke dingen bij als halve dagen werken, op oneven weken een dag vrij, studiedagen, vrijdagmiddagborrel (die soms op donderdag wordt gehouden), etc.

Het wordt dan vooral leuk met inplannen op meerdere medewerkers over meerdere contracten.

Niet logischer om een koppeling te maken naar je HR tool waar dat soort dingen toch al in opgeslagen staan?

[ Voor 50% gewijzigd door creator1988 op 15-10-2010 12:55 ]

[Janoz]

creator1988 schreef op vrijdag 15 oktober 2010 @ 12:54:
Nee? Je kan een filewatcher hebben op je configfile die on the fly CodeDOM't?

Goed, sla jij de niet werkbare dagen maar op in een configuratie bestand. Het was natuurlijk ook een beetje dom van mij om dergelijke data op te gaan slaan in een database. Die zijn daar natuurlijk helemaal niet voor bedoelt.

[orf]

creator1988 schreef op vrijdag 15 oktober 2010 @ 12:54:
[...]Niet logischer om een koppeling te maken naar je HR tool waar dat soort dingen toch al in opgeslagen staan?

Het is een combi. Voor intern gebruik is het HR, planning, verantwoording, stats, management info, uren klokken, etc.