Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-3735] Onderwerp: optimalisatie Pick-To-Light voor TAOR
[ICT-3735] Onderwerp: optimalisatie Pick-To-Light voor TAOR
[ICT-3535] BLUM POLAND (BPL) aanmaken als Multipersonality
[ICT-3535] BLUM POLAND (BPL) aanmaken als Multipersonality
[ICT-3532] Opzet MP platform Dozon
[ICT-3532] Opzet MP platform Dozon
unittesten voor deze klasse nog niet aanwezig. Dit bevat de clou van heel de zaak en geen idee of alle mogelijkheden door de integratietests worden opgevangen. Hoe dan ook beter om voor "alle" flow...

unittesten voor deze klasse nog niet aanwezig. Dit bevat de clou van heel de zaak en geen idee of alle mogelijkheden door de integratietests worden opgevangen. Hoe dan ook beter om voor "alle" flows een unittest te voorzien

[ICT-3389] [rvTVE] Pickstar voorbereiding
[ICT-3389] [rvTVE] Pickstar voorbereiding
Wordt indien nodig aangevuld in de individuele aanvul method, zie VulAanOverdoos

Wordt indien nodig aangevuld in de individuele aanvul method, zie VulAanOverdoos

De optimizer gaat data zoeken met dikte 3 voor kraft klein en 4.2 voor bv halux. Nadat data gevonden is moeten we er een geheel getal van maken, anders kan het Kraftmachine dit niet interpreteren. ...

De optimizer gaat data zoeken met dikte 3 voor kraft klein en 4.2 voor bv halux. Nadat data gevonden is moeten we er een geheel getal van maken, anders kan het Kraftmachine dit niet interpreteren. Er is dus een verschil tussen voor en na de optimalisatie

Ik snap niet wat je hiermee wilt zeggen. De set BreedtePlano wordt in deze optimizer maximum maar 1 keer gezet per recept?

Ik snap niet wat je hiermee wilt zeggen. De set BreedtePlano wordt in deze optimizer maximum maar 1 keer gezet per recept?

Wat met fouten en standaardgedrag naar nodered? Lijkt mij niet zo heel veel werk aangezien je al een deel kan kopiëren / dezelfde mocks kan gebruiken http://subversion02.vanhoecke.be/static/ogdo0b/...

Wat met fouten en standaardgedrag naar nodered? Lijkt mij niet zo heel veel werk aangezien je al een deel kan kopiƫren / dezelfde mocks kan gebruiken .

Dit allemaal bevat enorm veel logica en komt nogal overweldigend over (net zoals Wim aanhaalt in zijn review hierboven) en maakt het vrij moeilijk om te lezen + onder UT te plaatsen. Ik persoonlijk...

Dit allemaal bevat enorm veel logica en komt nogal overweldigend over (net zoals Wim aanhaalt in zijn review hierboven) en maakt het vrij moeilijk om te lezen + onder UT te plaatsen. Ik persoonlijk zou dit allemaal wat meer afzonderen en toch wat meer onder unittest plaatsen. Zeker omdat als hier ooit een wijziging aan gebeurt, je mooi kan zien waarom iets faalt. (Ik vind het persoonlijk ook moeilijk hoor om hier een goede structuur voor te bedenken, maar indien nodig wil ik gerust eens mee nadenken )

Ik zou dit ook in een aparte method plaatsen (Do ..Swap(...)) opdat dit alles iets beter leesbaar wordt

Ik zou dit ook in een aparte method plaatsen (Do ..Swap(...)) opdat dit alles iets beter leesbaar wordt

Waarom staat deze hier? Is dat ook niet recept specifiek? EDIT: Dit wordt ook in de optimizer aangepast, dus misschien is het logisch om deze naar daar / aparte klasse te plaatsen?

Waarom staat deze hier? Is dat ook niet recept specifiek?

EDIT: Dit wordt ook in de optimizer aangepast, dus misschien is het logisch om deze naar daar / aparte klasse te plaatsen?

Als algemene opmerking voor deze klasse zou ik toch een aantal dingen afzonderen in aparte methods / klasses. Zoals deze kan gerust in een aparte method (Set Prioriteit = ..GeefPrioriteit(MachineTe...

Als algemene opmerking voor deze klasse zou ik toch een aantal dingen afzonderen in aparte methods / klasses. Zoals deze kan gerust in een aparte method (Set Prioriteit = ..GeefPrioriteit(MachineTechnologie).

Lijntje commentaar mag weg?

Lijntje commentaar mag weg?

Is maar een idee, maar aangezien er hier veel 'code duplication' is, kan je dit eventueel in een aparte method steken a la '..GeefParam(Key, Value)

Is maar een idee, maar aangezien er hier veel 'code duplication' is, kan je dit eventueel in een aparte method steken a la '..GeefParam(Key, Value)

Ik zou dit als property in de recepten apart plaatsen en opvullen zoals hieronder. Als dit later zou wijzigen, of er meerdere nodig zijn, moet je die sowieso ergens ophalen lijkt mij

Ik zou dit als property in de recepten apart plaatsen en opvullen zoals hieronder. Als dit later zou wijzigen, of er meerdere nodig zijn, moet je die sowieso ergens ophalen lijkt mij

Ik zou dit en de overigen in een aparte folder plaatsen als dat nog lukt, iets met dto of iets dergelijks. EDIT: Ik zie dat Wim deze opmerking ook bij de 'Doos.cls' heeft geplaatst, negeer deze da...

Ik zou dit en de overigen in een aparte folder plaatsen als dat nog lukt, iets met dto of iets dergelijks.

EDIT: Ik zie dat Wim deze opmerking ook bij de 'Doos.cls' heeft geplaatst, negeer deze dan maar