De Devschuur Coffee Corner

[eamelink]

En, iemand de Typesafe Stack al geprobeerd?

Zal wel niet met al die MS hippies hier

[.oisyn]

std::stack<int>

Zo, een typesafe stack

[RayNbow]

.oisyn schreef op vrijdag 13 mei 2011 @ 21:00:
std::stack<int>

Zo, een typesafe stack

Is dit veilig?

C++:

#include <iostream>
#include <stack>

int main ()
{
  std::stack<int> mystack;
  std::cout << mystack.top() << std::endl;

  return 0;
}

[Gamebuster]

sorted.bits schreef op vrijdag 13 mei 2011 @ 17:51:
Voor mijn iOS (objective-C) heb ik nog niet iets gevonden eigenlijk.

Doxygen

[ Voor 22% gewijzigd door Gamebuster op 13-05-2011 21:14 ]

[CoolGamer]

RayNbow schreef op vrijdag 13 mei 2011 @ 21:09:
[...]

Is dit veilig?

C++:

#include <iostream>
#include <stack>

int main ()
{
  std::stack<int> mystack;
  std::cout << mystack.top() << std::endl;

  return 0;
}

Zo typesafe als het maar kan.

[Gamebuster]

Ik ben niet zo'n C++ pro, dus ik vraag even na of ik de grap snap:

mystack.top() geeft toch een pointer naar een int terug, waarbij die pointer ook een int is? Of zit de grap ergens anders

[CoolGamer]

Gamebuster schreef op vrijdag 13 mei 2011 @ 21:21:
mystack.top() geeft toch een pointer naar een int terug, waarbij die pointer ook een int is? Of zit de grap ergens anders

mystack.top() geeft geen pointer, maar een reference naar een int. Dit voorbeeld is typesafe, maar er zit een andere fout in. Je mag top niet aanroepen op een lege stack. Wat er dan gebeurd is niet gedefinieerd in de specificatie. Een logische uitkomst van deze code als je hem draait zal een crash zijn.

[RayNbow]

Zelf ben ik meer fan van dat het type van een operatie het eventueel falen weergeeft.

[YopY]

Hop. Vandaag Euler opdrachten 1 en twee gefabriceerd in Scala, samen met tests gemaakt met ScalaTest. Vooral de laatste is interresant - hiermee kun / moet je met een combinatie van 'literate programming' en gewone strings beschrijven wat je verwacht. Het is jammer dat je dit eigenlijk tweemaal moet doen, eenmaal met tekst en eenmaal met een 'expect'-aanroep, maar mogelijk zijn er alternatieven waar deze duplicatie niet nodig is. Ook is de 'expect'-formattering niet zo 'vloeiend' als bijvoorbeeld Hamcrest matchers Voorbeeldje:

Java:

// dit is scala, geen java, maar d'r is nog geen scala formatter op t.net.
class SomeTest extends Spec {
  describe("The isEven method") {
    it("should return true when passing 2") {
      expect(true) { isEven(2) }
    }
    it ("should return false when passing 3") {
      expect(false) { isEven(3) }
    }
}

Dit levert, als je het (in mijn geval) met JUnit binnen Eclipse draait, een net 'testverslag' op dat eigenlijk gewoon de verwachtingen beschrijft, met teksten als:

code:

The isEven method should return true when passing 2
The isEven method should return false when passing 3

Vind ik leuk. Maar eens blogpostje erover schrijven (kunnen ze wel waarderen @ werk).

Misschien zou het 'expect' gedeelte herschreven kunnen worden naar een soort van Hamcrest notatie:

Java:

  describe("The isEven method") {
    it("should return true when passing 2") {
      expectThat(isEven(2)).returns(true)
      // of, indien scala's syntax optioneel is (ben ik nog niet helemaal achter):
      expectThat isEven(2) returns true
      // en voor volledig 'literal programming':
      Expect that calling isEven(2) returns true
      Expect that calling isEven with 2 returns true
      Expect that calling isEven with 2 will return true
    }
}

mja, Bewaar ik wel voor de blogpost, . Wordt hem waarschijnlijk pas maandag.

[FragFrog]

Nou moe. App wil wel een registry entry aanmaken als ik'm gewoon draai, maar niet als'ie als commit actie aangeroepen wordt bij installeren. Uiteraard ook geen foutmeldingen, key wordt domweg niet aangemaakt Ah well, tijd voor avondeten, stomme desktopapplicatie bekijkt't maar

.oisyn schreef op vrijdag 13 mei 2011 @ 16:28:
Haha I win

Gefeliciteerd

[Hoogie2004]

Goeiemorgen allemaal.

Steaming cup of coffee for everyone!

[defcon84]

Tnx hoogie, is hoog nodig

[Devilly]

Hoogie2004 schreef op maandag 16 mei 2011 @ 07:39:
Steaming cup of coffee for everyone!
[afbeelding]

Koffie stinkt! (Lees: ik heb nooit koffie geproefd, omdat ik denk dat die geur die er van af komt niets goeds kan betekenen. )

[defcon84]

heh ik vind het op zich wel lekker ruiken

[Hoogie2004]

Devilly schreef op maandag 16 mei 2011 @ 08:05:
[...]


Koffie stinkt! (Lees: ik heb nooit koffie geproefd, omdat ik denk dat die geur die er van af komt niets goeds kan betekenen. )

Koffiepoeder kan je ook snuiven (ofwel, heel hard ruiken ) voor je dosis cafeïne (denk ik...)

[Devilly]

Als ik dan toch cafeïne nodig heb, ga ik wel voor de Golden Power.

[eamelink]

Verwijderd schreef op vrijdag 13 mei 2011 @ 17:23:
Wat een weekje, Requirements die op laatste moment wijzigen en twee product owners die allebei wat anders zeggen

Wijzigende requirements is geen probleem, maar hoe kan je in vredesnaam twee productowners accepteren

[EddoH]

Hoogie2004 schreef op maandag 16 mei 2011 @ 07:39:
Goeiemorgen allemaal.

Steaming cup of coffee for everyone!
[afbeelding]

Hmm, een kop koffie waar sigarettenrook van af komt..no thanks

[Hoogie2004]

EddoH schreef op maandag 16 mei 2011 @ 08:39:
[...]


Hmm, een kop koffie waar sigarettenrook van af komt..no thanks

Het ging meer om de symboliek ofcourse. Kan jullie moeilijk koude koffie voorzetten....

[Makkelijk]

eamelink schreef op vrijdag 13 mei 2011 @ 20:27:
En, iemand de Typesafe Stack al geprobeerd?

Zal wel niet met al die MS hippies hier

Looks nice. Ik hou van Scala dus dat is al 1/3*100%

[ Voor 5% gewijzigd door Makkelijk op 16-05-2011 08:45 ]

[EddoH]

Hoogie2004 schreef op maandag 16 mei 2011 @ 08:41:
[...]


Het ging meer om de symboliek ofcourse. Kan jullie moeilijk koude koffie voorzetten....

Een mooi gebaar, karma +100!

[defcon84]

Devilly schreef op maandag 16 mei 2011 @ 08:23:
Als ik dan toch cafeïne nodig heb, ga ik wel voor de Golden Power.

dat stinkt pas!

[RomeoJ]

Devilly schreef op maandag 16 mei 2011 @ 08:23:
Als ik dan toch cafeïne nodig heb, ga ik wel voor de Golden Power.

Nee, dat stinkt niet gelukkig

[Rutix]

PrisonerOfPain schreef op vrijdag 13 mei 2011 @ 18:26:
[...]


Enige nadeel is dat een Doxygen build hier op z'n minst 2 uur duurt.

Wut Een Doxygen build heeft nog nooit 2 uur geduurd XD. Maarja zo'n build kun je ook gewoon 's avonds runnen of gewoon laten generen via de continuous integration ofzo .

Maar tijd voor koffie!

[Woy]

eamelink schreef op maandag 16 mei 2011 @ 08:24:
[...]

Wijzigende requirements is geen probleem, maar hoe kan je in vredesnaam twee productowners accepteren

2 is altijd nog beter dan geen ( Officieel is die er wel, maar in de praktijk valt dat erg tegen )

[ Voor 11% gewijzigd door Woy op 16-05-2011 09:25 ]

[Johan.B]

Rutix schreef op maandag 16 mei 2011 @ 09:20:
Maar tijd voor koffie!

Pff maandag morgen en de koffie is ... op

[PeterSelie]

Koffie op?

¿qué pasó?

[Rutix]

Johan.B schreef op maandag 16 mei 2011 @ 09:29:
[...]


Pff maandag morgen en de koffie is ... op

Ik moest ook naar de andere koffieautomaat omdat die ene nog bijgevuld moest worden .

[TJHeuvel]

Wat een slechte werkomstandigheden mensen, laat de arbo dat maar niet horen!

[Rutix]

CyCloneNL schreef op maandag 16 mei 2011 @ 09:49:
Wat een slechte werkomstandigheden mensen, laat de arbo dat maar niet horen!

Ik heb er niet bijgezegt dat de andere automaat 15 cm verder is

[Johan.B]

SoaDmaggot schreef op maandag 16 mei 2011 @ 09:47:
Koffie op?

¿qué pasó?

Geen idee, de nieuwe koffie is onderweg maar dat zeggen ze al dagen.

[sig69]

Johan.B schreef op maandag 16 mei 2011 @ 09:29:
[...]
Pff maandag morgen en de koffie is ... op

Dan had ik direct rechtomkeerd gemaakt en vanaf thuis gewerkt... Gelukkig is dat een situatie die bij ons nooit voor zal komen.

[.oisyn]

Rutix schreef op maandag 16 mei 2011 @ 09:20:
[...]

Wut Een Doxygen build heeft nog nooit 2 uur geduurd XD.

Maar uit hoeveel miljoen regels C++ bestaat jouw codebase?

[FragFrog]

sig69 schreef op maandag 16 mei 2011 @ 09:57:
[...]

Dan had ik direct rechtomkeerd gemaakt en vanaf thuis gewerkt... Gelukkig is dat een situatie die bij ons nooit voor zal komen.

Een tijdje terug was het koffiezetapparaat bij ons stuk

Twee uur later stond er een of ander nieuw fancy espresso apparaat Toch prettig, een werkgever die snapt hoe developers werken.

Doxygen draait hier trouwens in een half uurtje ongeveer, op een PHP codebase. Maargoed, dat draait 's nachts ook wel prima, niet zo'n probleem.

[Rutix]

.oisyn schreef op maandag 16 mei 2011 @ 11:02:
[...]

Maar uit hoeveel miljoen regels C++ bestaat jouw codebase?

Weet niet precies. Maar ik heb het gebruikt op een project met 2500+ files .

Maar zoals ik al zei draait Doxygen via het Continuous Integration process dus wij hebben er nooit last van. Daar komt bij dat we wel SEARCH_INCLUDES uit hebben staan anders gaat die door de hele sdk's heen zoeken die toch niet gedocumenteerd hoeven te worden.

Anyway lunch time.

[Hoogie2004]

[Rutix]

Hoogie2004 schreef op maandag 16 mei 2011 @ 12:34:
*snip*

Jou net overkomen ?

[Hoogie2004]

Rutix schreef op maandag 16 mei 2011 @ 12:50:
[...]

Jou net overkomen ?

Al weken elke dag

[.oisyn]

Rutix schreef op maandag 16 mei 2011 @ 12:20:
[...]

Weet niet precies. Maar ik heb het gebruikt op een project met 2500+ files .

Peanuts dus . In Deus Ex: Human Revolution zitten 6100 files, en dat is alleen de game. De hele content pipeline is nog eens minstens zoveel files.

[ Voor 25% gewijzigd door .oisyn op 16-05-2011 13:02 ]

[Rutix]

.oisyn schreef op maandag 16 mei 2011 @ 12:58:
[...]

Peanuts dus

Zei ook nooit dat niet peanuts was . Zowiezo doxygen normaal gebruiken is best wel dom. Wij hadden toen 2 aparte doyxgen configs. Eentje voor release en eentje voor dev. En via de continuous integration werd dat allemaal netjes gedaan .

[Devilly]

.oisyn schreef op maandag 16 mei 2011 @ 12:58:
[...]

Peanuts dus

Mag ik vragen over hoeveel code jij het dan had?

[.oisyn]

Zie edit.

Rutix schreef op maandag 16 mei 2011 @ 13:01:
Zowiezo doxygen normaal gebruiken is best wel dom. Wij hadden toen 2 aparte doyxgen configs. Eentje voor release en eentje voor dev. En via de continuous integration werd dat allemaal netjes gedaan .

Ik heb ook nooit beweerd dat dat handmatig doen een zinnige klus is . Maar ik reageerde louter op je verbazing over die 2 uur.

[ Voor 96% gewijzigd door .oisyn op 16-05-2011 13:03 ]

[Rutix]

.oisyn schreef op maandag 16 mei 2011 @ 13:02:
Zie edit.


[...]

Ik heb ook nooit beweerd dat dat handmatig doen een zinnige klus is . Maar ik reageerde louter op je verbazing over die 2 uur.

Ok 6500 files kan wel 2 uur duren ofcourse maar files zijn ook relatief natuurlijk want ligt er ook aan hoeveel regels er in een file zit .

[PrisonerOfPain]

.oisyn schreef op maandag 16 mei 2011 @ 13:02:
Zie edit.


[...]

Ik heb ook nooit beweerd dat dat handmatig doen een zinnige klus is . Maar ik reageerde louter op je verbazing over die 2 uur.

Waarschijnlijk is het hier ook onderdeel van het CI process maar ik zit hier nog niet lang genoeg om al die locaties te onthouden / te vinden etc. Kortom, deze keer werd 't even handmatig gedaan :-)

Rutix schreef op maandag 16 mei 2011 @ 13:20:
[...]

Ok 6500 files kan wel 2 uur duren ofcourse maar files zijn ook relatief natuurlijk want ligt er ook aan hoeveel regels er in een file zit .

Snel even gekeken en het waren ongeveer ~60.000 files voor BF3 + Frostbite + content pipeline maar zonder de .Net tools (editor etc). Daar zitten ook project files en data definitie files (eg. editor <> engine interop) dingen tussen. Het ding spendeerde de meeste tijd aan dependencies checken trouwens.

[ Voor 38% gewijzigd door PrisonerOfPain op 16-05-2011 13:32 ]

[.oisyn]

Ik heb net even geteld, een upcoming game waar wij aan bezig zijn heeft ~19.000 .cpp files en ~21.000 header files, en ~6700 daarvan zitten in de game zelf

[Devilly]

Gaat het te ver om te vragen hoeveel regels code dat ongeveer zijn?

[PrisonerOfPain]

.oisyn schreef op maandag 16 mei 2011 @ 14:13:
Ik heb net even geteld, een upcoming game waar wij aan bezig zijn heeft ~19.000 .cpp files en ~21.000 header files, en ~6700 daarvan zitten in de game zelf

Ok iets preciesere stats; 13k cpp files en 20k header files. Geen idee waar die andere 27k in is gaan zitten.

Overigens, beste tool ooit Everything, dat ding is wel zo ontzettend rap. En nog iets, Visual Studio addins maken is een hel, pfff.

[ Voor 6% gewijzigd door PrisonerOfPain op 16-05-2011 14:29 ]

[MTWZZ]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 14:26:
[...]
En nog iets, Visual Studio addins maken is een hel, pfff.

Nogal, als er ergens dingen niet gedocumenteerd zijn is het daar wel

[.oisyn]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 14:26:
Overigens, beste tool ooit Everything

Wow, iemand anders heeft ook de tool gemaakt waar ik ooit mee bezig was maar nooit heb afgemaakt \o/

[PrisonerOfPain]

.oisyn schreef op maandag 16 mei 2011 @ 14:53:
[...]

Wow, iemand anders heeft ook de tool gemaakt waar ik ooit mee bezig was maar nooit heb afgemaakt \o/

Inclusief wildcard search

MTWZZ schreef op maandag 16 mei 2011 @ 14:52:
[...]

Nogal, als er ergens dingen niet gedocumenteerd zijn is het daar wel

En als er iets een complex flow heeft zijn het die dingen wel. Het enige wat ik wilde doen was een lijst van solutions uit de huidige branch toevoegen aan het File menu. Dat bleek al te veel moeite. Ik had ook nog een heel gaaf idee om Lucene.net de find-in-files te laten doen maar laat dat al helemaal maar zitten.

[Devilly]

Devilly schreef op maandag 16 mei 2011 @ 14:15:
Gaat het te ver om te vragen hoeveel regels code dat ongeveer zijn?

Blijkbaar gaat dat inderdaad te ver. Ik ben nu, naar aanleiding van school, bezig om me in Android te verdiepen en ik vind het geweldig. De kans is best groot dat ik hier in mijn vrije tijd nog verder mee ga.

[YopY]

* YopY breekt in.

Wat is de officiële term voor code die je kunt 'lezen' als ware het tekst? Ik had het zelf 'literate programming' genoemd, maar dat is weer iets met tekst en is denk ik niet precies wat het is. Een paar voorbeelden:

Java:

// JMock
context.checking(new Expectations() {{
    one(obj).doSomething(); will(returnValue(somethingElse));
}});

// Mockito:
when(obj.doSomething()).thenReturn(someValue)

// is stiekem Scala
// ScalaTest: Spec
describe("A Stack") {
    it("should pop values in last-in-first-out order") {
      // tl;dr
    }
}

Wat is de officiele term voor dit soort programmeren-zodat-je-het-kunt-voorlezen-aan-je-kinders?

[NetForce1]

YopY schreef op maandag 16 mei 2011 @ 15:08:
* YopY breekt in.

Wat is de officiële term voor code die je kunt 'lezen' als ware het tekst? Ik had het zelf 'literate programming' genoemd, maar dat is weer iets met tekst en is denk ik niet precies wat het is.
[...]
Wat is de officiele term voor dit soort programmeren-zodat-je-het-kunt-voorlezen-aan-je-kinders?

Fluent interface: Wikipedia: Fluent interface

[ Voor 25% gewijzigd door NetForce1 op 16-05-2011 15:16 ]

[PrisonerOfPain]

YopY schreef op maandag 16 mei 2011 @ 15:08:
Wat is de officiele term voor dit soort programmeren-zodat-je-het-kunt-voorlezen-aan-je-kinders?

Kak? (Of OOP zoals het gepionierd werd door Smalltalk ea.)

[ Voor 11% gewijzigd door PrisonerOfPain op 16-05-2011 15:23 ]

[farlane]

YopY schreef op maandag 16 mei 2011 @ 15:08:
Wat is de officiele term voor dit soort programmeren-zodat-je-het-kunt-voorlezen-aan-je-kinders?

Mishandeling?

[Rutix]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 13:30:
[...]

Waarschijnlijk is het hier ook onderdeel van het CI process maar ik zit hier nog niet lang genoeg om al die locaties te onthouden / te vinden etc. Kortom, deze keer werd 't even handmatig gedaan :-)


[...]


Snel even gekeken en het waren ongeveer ~60.000 files voor BF3 + Frostbite + content pipeline maar zonder de .Net tools (editor etc). Daar zitten ook project files en data definitie files (eg. editor <> engine interop) dingen tussen. Het ding spendeerde de meeste tijd aan dependencies checken trouwens.

Had je SEARCH_INCLUDES uit of aan staan ?

Trouwens die " Everything" tool is inderdaad echt heerlijk en super snel.

[.oisyn]

Ik was met een dergelijke tool bezig omdat de standaard dingen (windows indexer, google desktop) de inhoud van files indexeerde, terwijl ik alleen maar geïnteresseerd was in bestandsnamen . Ben blij dat ik 'm nu niet meer af hoef te maken (doe ik misschien alsnog wel, maar nu heb ik iig al een bruikbare tool )

[YopY]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 15:22:
Kak?

farlane schreef op maandag 16 mei 2011 @ 15:35:
Mishandeling?

NetForce1 schreef op maandag 16 mei 2011 @ 15:16:
Fluent interface: Wikipedia: Fluent interface

Zeker? Bij een fluent interface denk ik eerder aan Builder implementaties... Maar het heeft ook fluent eigenschappen, vooral JMock / Mockito.

Denk dat ik maar een eigen term moet gebruiken. In de documentatie van ScalaTest wordt ook de term 'behavior-driven development' gebruikt, maar dat beschrijft de notatie niet echt. Wel wat, natuurlijk.

Behavior-driven fluent interface?

[ Voor 3% gewijzigd door YopY op 16-05-2011 16:07 ]

[PrisonerOfPain]

Rutix schreef op maandag 16 mei 2011 @ 16:01:
[...]

Had je SEARCH_INCLUDES uit of aan staan ?

Staat aan terwijl INCLUDE_PATH leeg is. Al is het wel zo dat we geen third-party libs gebruiken (geen boost/stl) maar alleen in-house dingen. Denk trouwens niet dat ik nog een keer die doxygen docs hoef te genereren. Ik heb ze nog niet aangeraakt en heb ze de afgelopen maanden ook niet nodig gehad.

.oisyn schreef op maandag 16 mei 2011 @ 16:03:
Ik was met een dergelijke tool bezig omdat de standaard dingen (windows indexer, google desktop) de inhoud van files indexeerde, terwijl ik alleen maar geïnteresseerd was in bestandsnamen . Ben blij dat ik 'm nu niet meer af hoef te maken (doe ik misschien alsnog wel, maar nu heb ik iig al een bruikbare tool )

Zo veel werk kan het niet zijn; ik had in een dagje een tool die m'n NTFS journal filenames uitspuugde en ze in een trie gooide. Wat er dan nog ontbreek is een virtual list-view en wildcard search op de trie.

[ Voor 41% gewijzigd door PrisonerOfPain op 16-05-2011 16:14 ]

[Rutix]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 16:12:
[...]


Staat aan terwijl INCLUDE_PATH leeg is. Al is het wel zo dat we geen third-party libs gebruiken (geen boost/stl) maar alleen in-house dingen. Denk trouwens niet dat ik nog een keer die doxygen docs hoef te genereren. Ik heb ze nog niet aangeraakt en heb ze de afgelopen maanden ook niet nodig gehad.


[...]


Zo veel werk kan het niet zijn; ik had in een dagje een tool die m'n NTFS journal filenames uitspuugde en ze in een trie gooide. Wat er dan nog ontbreek is een virtual list-view en wildcard search op de trie.

Ik zie nu pas dat je bij DICE werkt vet man xD

[PrisonerOfPain]

Rutix schreef op maandag 16 mei 2011 @ 16:15:
[...]

Ik zie nu pas dat je bij DICE werkt stage loopt vet man xD

FTFY

[Rutix]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 16:18:
[...]


FTFY

Nog steeds vet niet veel lopen stage bij zo'n bekend bedrijf

[.oisyn]

't is natuurlijk wel een grote stap terug sinds hij bij ons stage heeft gelopen

[YopY]

.oisyn schreef op maandag 16 mei 2011 @ 16:53:
't is natuurlijk wel een grote stap terug sinds hij bij ons stage heeft gelopen

Nietes, want Battlefield heeft een dikke multiplayer, .

En straaljagers. Straaljagers > elleboogmessen.

Overigens: ik verveel me, en moet nog een uur (of vandaag, of morgen) . Ach, morgen thuiswerken, kan ik net zo goed een uurtje langer doorgaan / eerder beginnen (aangezien ik 3 uur reizen bespaar (of 1 uur 20 zonder files )

[ Voor 27% gewijzigd door YopY op 16-05-2011 16:58 ]

[.oisyn]

PrisonerOfPain schreef op maandag 16 mei 2011 @ 16:12:
Zo veel werk kan het niet zijn; ik had in een dagje een tool die m'n NTFS journal filenames uitspuugde en ze in een trie gooide. Wat er dan nog ontbreek is een virtual list-view en wildcard search op de trie.

En oh ja, toen bedacht je dat je ook nog eens een robuuste en snelle database storage moest implementeren. Ik ben juist afgestapt van een trie omdat dat veel te traag was. Niet als alles in memory stond, maar wel als je je gebruikte geheugen wilt limiteren op 50 MB oid.

Ik zie trouwens dat Everything momenteel 220 MB gebruikt.

[ Voor 20% gewijzigd door .oisyn op 16-05-2011 17:05 ]

[RayNbow]

YopY schreef op maandag 16 mei 2011 @ 15:08:
* YopY breekt in.

Wat is de officiële term voor code die je kunt 'lezen' als ware het tekst? Ik had het zelf 'literate programming' genoemd, maar dat is weer iets met tekst en is denk ik niet precies wat het is. Een paar voorbeelden:

Java:

// JMock
context.checking(new Expectations() {{
    one(obj).doSomething(); will(returnValue(somethingElse));
}});

// Mockito:
when(obj.doSomething()).thenReturn(someValue)

// is stiekem Scala
// ScalaTest: Spec
describe("A Stack") {
    it("should pop values in last-in-first-out order") {
      // tl;dr
    }
}

Wat is de officiele term voor dit soort programmeren-zodat-je-het-kunt-voorlezen-aan-je-kinders?

ScalaTest = eDSL?

[ZaZ]

.oisyn schreef op maandag 16 mei 2011 @ 17:01:
[...]

En oh ja, toen bedacht je dat je ook nog eens een robuuste en snelle database storage moest implementeren. Ik ben juist afgestapt van een trie omdat dat veel te traag was.

En realtime filesystem changes en wanneer er niets draait een slimme methode om de wijzigingen te verkrijgen zonder een nieuwe fullscan.
en.. en... en...

De meeste tools lijken op het eerste gezicht altijd heel simpel, tot je zelf aan de slag gaat.
Dan kom je toch altijd nog flink wat dingen tegen.

[PrisonerOfPain]

.oisyn schreef op maandag 16 mei 2011 @ 16:53:
't is natuurlijk wel een grote stap terug sinds hij bij ons stage heeft gelopen

Klopt, ze betalen me hier in fruit

.oisyn schreef op maandag 16 mei 2011 @ 17:01:
[...]

En oh ja, toen bedacht je dat je ook nog eens een robuuste en snelle database storage moest implementeren.

Voor wat? Je start het ding, je parsed het journal (minuutje of twee werk), en luisterd vervolgens naar changes. De test app die ik gemaakt had nam ~100Mb geheugen in beslag en daar kon nog makkelijk 80Mb vanaf als ik een stuk zuiniger was met m'n STL gebruik (de trie node was basically een std::map<wchar_t, Trie*>) dus daar hoefde het ook niet voor.

[.oisyn]

Leuk, mag je lekker alle nodes gaan scannen als je naar een substring zoekt. Je wilt een suffix tree, geen trie. Mijn database was 300MB.

Uit het journal haal je trouwens niet alle bestaande files, alleen de changes.

[ Voor 33% gewijzigd door .oisyn op 16-05-2011 17:19 ]

[PrisonerOfPain]

.oisyn schreef op maandag 16 mei 2011 @ 17:16:
Leuk, mag je lekker alle nodes gaan scannen als je naar een substring zoekt. Je wilt een suffix tree, geen trie. Mijn database was 300MB.

Hangt af van de searches die je (wilt) kunnen doen, ik m'n prototype was initieel bedoeld om het build process sneller te krijgen en dan kun je prima af met filenames matchen vanaf het begin van het woord zodra je wildcards aan het begin van je string wilt hebben voldoet een trie eigenlijk pas niet meer.

Uit het journal haal je trouwens niet alle bestaande files, alleen de changes.

Dat.... viel mij dus ook op Blijkbaar moet je de master file table daarvooer inlezen. Iets voor een andere keer

[NetForce1]

YopY schreef op maandag 16 mei 2011 @ 16:07:
[...]


[...]





[...]


Zeker? Bij een fluent interface denk ik eerder aan Builder implementaties... Maar het heeft ook fluent eigenschappen, vooral JMock / Mockito.

Denk dat ik maar een eigen term moet gebruiken. In de documentatie van ScalaTest wordt ook de term 'behavior-driven development' gebruikt, maar dat beschrijft de notatie niet echt. Wel wat, natuurlijk.

Behavior-driven fluent interface?

Zeker, op de Wikipedia-pagina worden ook specified de mock-voorbeelden genoemd. En als je naar de bliki-pagina van Martin Fowler gaat zie je die voorbeelden ook (Fowler is een van de bedenkers van de term). Fluent API zou je ook nog kunnen gebruiken, of internal DSL.

Edit: internal DSL werd al genoemd: RayNbow in "De Devschuur Coffee Corner"

[ Voor 5% gewijzigd door NetForce1 op 16-05-2011 19:55 ]

[alienfruit]

PrisonerOfPain, moet je dan ook heel de dag spelletjes spelen? Wat een drama lijkt mij dat zeg! Vooral voor jongetjes zoals ik die niet verder komen dan het eerste deel van het eerste level. Moet nog steeds Lara Craft voor de Mac (demo) uitspelen Veelste moeilijk

[ Voor 3% gewijzigd door alienfruit op 17-05-2011 00:20 ]

[Haan]

Ik klikte per ongeluk op een linkje bij een Windows Update: An update that prevents a "0xC0000034" error message when you try to install Windows 7 SP1 or Windows Server 2008 R2 SP1 is available

De NL vertaling van die pagina is echt

[Hoogie2004]

Haan schreef op dinsdag 17 mei 2011 @ 08:34:
Ik klikte per ongeluk op een linkje bij een Windows Update: An update that prevents a "0xC0000034" error message when you try to install Windows 7 SP1 or Windows Server 2008 R2 SP1 is available

De NL vertaling van die pagina is echt

Microsoft:
"Een update wordt voorkomen een foutbericht '0xC0000034' dat bij het installeren van Windows 7 SP1 of Windows Server 2008 R2 SP1 is beschikbaar"

Google translate:
"Een update die een "0xC0000034" foutmelding voorkomt wanneer u probeert te installeren Windows 7 SP1 of Windows Server 2008 R2 SP1 is beschikbaar"

(Google wins, al is die ook net geen 100%, maar wel duidelijk beter)

[ Voor 17% gewijzigd door Hoogie2004 op 17-05-2011 08:40 ]

[Sebazzz]

Bovenaan de pagina staat dan ook "machine translation disclaimer". Dit is niet door een persoon vertaald.

[Haan]

Dat het niet door een mens was vertaald, was wel duidelijk ja Maar die disclaimer had ik over het hoofd gezien, dat is opzich nog wel netjes. Waarschijnlijk kijkt toch geen hond naar zo'n pagina, dus hoef je daar ook geen tijd in te steken om het netjes te vertalen.

[YopY]

RayNbow schreef op maandag 16 mei 2011 @ 17:03:
[...]

ScalaTest = eDSL?

NetForce1 schreef op maandag 16 mei 2011 @ 19:54:
Zeker, op de Wikipedia-pagina worden ook specified de mock-voorbeelden genoemd. En als je naar de bliki-pagina van Martin Fowler gaat zie je die voorbeelden ook (Fowler is een van de bedenkers van de term). Fluent API zou je ook nog kunnen gebruiken, of internal DSL.

Onze dank is groot.

Mbt het machine translation verhaal, ik had eerlijk gezegd gedacht dat er een stijgende lijn zou zijn qua vertaling, maar ik heb de afgelopen paar jaar weinig verbeteringen gezien . Ik las dat Google Translate in eerste instantie gebaseerd was op statistische analyses van nieuwsberichten die ze met Google News verzameld hadden. Logischerwijs zouden vertalingen dus beter worden naarmate de tijd verstrijkt. Ook hebben ze bijvoorbeeld de Translator Toolkit, een soort Google Docs voor vertalingen - je stopt er tekst in, laat het door Google vertalen, en jij (als vertaler zijnde) gaat de vertaling vervolgens verbeteren. Directe reparatie van stukke vertalingen wiens resultaten regelmatig in de vertalingsengine verwerkt worden, zou je denken. Niet dat dat werkt als niemand het gebruikt, natuurlijk, .

[Rutix]

Kofffiieeee

[Hoogie2004]

Rutix schreef op dinsdag 17 mei 2011 @ 09:13:
Kofffiieeee

Yes please

[dev10]

YopY schreef op dinsdag 17 mei 2011 @ 09:11:
Mbt het machine translation verhaal, ik had eerlijk gezegd gedacht dat er een stijgende lijn zou zijn qua vertaling, maar ik heb de afgelopen paar jaar weinig verbeteringen gezien.

Het 100% correct vertalen van complete (Nederlandse) zinnen is op dit gewoon te complex. Ik weet toevallig dat er een Nederlands bedrijf is dat bezig is met het maken van een vertaalprogramma waarmee je complete zinnen kunt vertalen. Ze zeggen alleen al een jaar of vijf dat het bijna klaar is.

Op zich is er de laatste paar jaar wel wat verbetering te zien. Zo zijn er wat vertaalcomputers (kleine apparaatjes die woord voor woord kunnen vertalen) die zinnen van het Nederlands naar het Engels voor 70-80 procent correct kunnen vertalen op de markt gekomen. Een paar jaar geleden had ik niet verwacht dat we die dingen ooit zouden gaan verkopen.

[PrisonerOfPain]

alienfruit schreef op dinsdag 17 mei 2011 @ 00:19:
PrisonerOfPain, moet je dan ook heel de dag spelletjes spelen? Wat een drama lijkt mij dat zeg! Vooral voor jongetjes zoals ik die niet verder komen dan het eerste deel van het eerste level. Moet nog steeds Lara Craft voor de Mac (demo) uitspelen Veelste moeilijk

Ja en nee. Natuurlijk ben je de hele dag in een spel bezig om te testen of het er goed uit ziet of niet, maar het grootste deel van de tijd ontwikkel je gewoon in een saai test-level om te kijken of je feature het doet. Werken met de level-art heeft een veel te hoge iteratietijd omdat de levels gewoon te groot zijn en dat is alleen praktisch als de errors alleen optreden in de daadwerkelijke level-art. Daarnaast game ik eigenlijk vrijwel niet.

[YopY]

Mja, voor zover ik het zie is een goede vertaling op dit moment op zo'n niveau dat je nu per zin (en de context van die zin) moet kijken naar vertalingen. Ik bedoel, een zin als hieboven aangegeven:

" An update that prevents a "0xC0000034" error message when you try to install Windows 7 SP1 or Windows Server 2008 R2 SP1 is available"

wordt vertaald naar:

"Een update die een "0xC0000034" foutmelding voorkomt wanneer u probeert te installeren Windows 7 SP1 of Windows Server 2008 R2 SP1 is beschikbaar"

Je zou in zo'n geval een 'uitzondering' toe moeten voegen op de vertaling van 'when you try to install' zodat er iets minder ongemakkelijks als 'wanneer u probeert te installeren'. iig.

quote: PrisonerofPain

Ja en nee. Natuurlijk ben je de hele dag in een spel bezig om te testen of het er goed uit ziet of niet, maar het grootste deel van de tijd ontwikkel je gewoon in een saai test-level om te kijken of je feature het doet. Werken met de level-art heeft een veel te hoge iteratietijd omdat de levels gewoon te groot zijn en dat is alleen praktisch als de errors alleen optreden in de daadwerkelijke level-art. Daarnaast game ik eigenlijk vrijwel niet.

Puur uit nieuwsgierigheid (en dit is waarschijnlijk ook @ .oysin), wat is de status van testing in de gamedev wereld? Ik, in de Java / Web wereld, weet dat je voor nagenoeg 99% van alles wat je doet een automatisch uitgevoerde test kunt schrijven. Ik kan me voorstellen dat unit tests goed mogelijk zijn, maar de integratie tests (zoals je zelf aangeeft, het testen van een nieuwe feature) lijkt me lastig, aangezien het werken van zoiets gebaseerd is op wat je ziet en dit lastig te reproduceren is met een stukje code. Maar je zou denken dat hier wel werk van gemaakt wordt, niet?

Puur uit niewsgierigheid.

[PrisonerOfPain]

YopY schreef op dinsdag 17 mei 2011 @ 10:38:
Puur uit nieuwsgierigheid (en dit is waarschijnlijk ook @ .oysin), wat is de status van testing in de gamedev wereld?

Een gigantische hoeveelheid blackbox-tests (eg. asserts), onvergeefelijke consoles en een huge-ass Q&A afdeling zorgen er voor dat we genoeg werk te doen hebben unit-tests zie je eigenlijk niet.

[ Voor 4% gewijzigd door PrisonerOfPain op 17-05-2011 10:41 ]

[Caelorum]

YopY schreef op dinsdag 17 mei 2011 @ 10:38:
Ik kan me voorstellen dat unit tests goed mogelijk zijn

Dat vraag ik me af. Ligt denk ik geheel aan de omgeving, maar bijvoorbeeld met de UDK zou dit niet mogelijk zijn en er zijn veel kleine game bedrijven die de UDK gebruiken.

maar de integratie tests (zoals je zelf aangeeft, het testen van een nieuwe feature) lijkt me lastig, aangezien het werken van zoiets gebaseerd is op wat je ziet en dit lastig te reproduceren is met een stukje code. Maar je zou denken dat hier wel werk van gemaakt wordt, niet?

Ik denk dat ze hier de (soms) duur betaalde professionele playtesters voor hebben. Of in sommige gevallen goedkope alpha hobby testers.

[PrisonerOfPain]

Caelorum schreef op dinsdag 17 mei 2011 @ 10:42:
Dat vraag ik me af. Ligt denk ik geheel aan de omgeving, maar bijvoorbeeld met de UDK zou dit niet mogelijk zijn en er zijn veel kleine game bedrijven die de UDK gebruiken.

Ook in de UDK is het prima mogelijk (iig. aan de C++ kant) maar ik denk dat blackbox testen wellicht meer oplevert. Geen idee eigenlijk, ik ben ook maar een stagaire! Ik heb wel zo m'n vermoedens natuurlijk, en dat is dat er met enige regelmaat complete systemen op de schop gaan en dat performance optimalisaties vaak complete 'nette OOP' interfaces helemaal aan gruzellement helpen (en daarmee dus waarschijnlijk ook de tests). Kortom, waarschijnlijk zorgt 't voor meer frictie dan een simpele assert.

[ Voor 26% gewijzigd door PrisonerOfPain op 17-05-2011 10:46 ]

[Caelorum]

PrisonerOfPain schreef op dinsdag 17 mei 2011 @ 10:44:
[...]


Ook in de UDK is het prima mogelijk (iig. aan de C++ kant) maar ik denk dat blackbox testen wellicht meer oplevert

Tja ik doelde dan ook meer op de wat goedkopere varianten waarbij een groot deel in unrealscript wordt gedaan. Tenzij je heel veel dlls gaat zitten aanroepen in je uscript code is testen daar geheel niet handig ^^

[PrisonerOfPain]

Caelorum schreef op dinsdag 17 mei 2011 @ 10:48:
[...]

Tja ik doelde dan ook meer op de wat goedkopere varianten waarbij een groot deel in unrealscript wordt gedaan. Tenzij je heel veel dlls gaat zitten aanroepen in je uscript code is testen daar geheel niet handig ^^

Dat weet jij waarschijnlijk beter dan ik . De laatste keer dat ik iets van gameplay programming deed is enkele jaren terug en de UDK heb ik nog nooit tegen aan hoeven te programmeren.

[alienfruit]

http://bellard.org/jslinux/ Knap hoor!

[PrisonerOfPain]

alienfruit schreef op dinsdag 17 mei 2011 @ 11:20:
http://bellard.org/jslinux/ Knap hoor!

Het steekt waarschijnlijk iets anders in elkaar dan je verwacht http://bellard.org/jslinux/tech.html

[Rutix]

Bij dingen zoals testen enzo verschilt de game industrie gewoon erg met andere software bedrijven.
Volgens mij werd er ook over gezeurd in dit artikel: Game developers are 15 years behind

[PrisonerOfPain]

Rutix schreef op dinsdag 17 mei 2011 @ 11:27:
Bij dingen zoals testen enzo verschilt de game industrie gewoon erg met andere software bedrijven.
Volgens mij werd er ook over gezeurd in dit artikel: Game developers are 15 years behind

En met andere liggen we 15 jaar voor (eg. Chrome die nu pas GPU acceleratie krijgt); kortom, we hebben gewoon andere prioriteiten dan de gemiddelde applicatie

It seems much more common that games developers, as opposed to non-game developers will not have automated unit testing and measure code coverage, adopt agile processes, use proper source code management systems, have proper backups (!), do code reviews, track bugs and do continuous integration.

Overigens hebben we dit dus wel bijna allemaal; de studios waar ik stage gelopen heb (en andere waar ik weet van heb) gebruiken eigenlijk unaniem SCRUM, Perforce (source control) en doen aan backups, bug-tracking & CI. Geen idee of de auteur van het artikel ook daadwerkelijk een gamedev is geweest maar blijkbaar werkt 'ie bij Jira en daar zouden ze toch een aantal grote studios in hun klantenbestand moeten hebben staan. Ik durf er zelfs geld op te zetten dat de kleinere indie studios dit ook vrijwel allemaal doen.

[ Voor 43% gewijzigd door PrisonerOfPain op 17-05-2011 11:49 ]

[Rutix]

PrisonerOfPain schreef op dinsdag 17 mei 2011 @ 11:28:
[...]


En met andere liggen we 15 jaar voor (eg. Chrome die nu pas GPU acceleratie krijgt); kortom, we hebben gewoon andere prioriteiten dan de gemiddelde applicatie


[...]


Overigens hebben we dit dus wel bijna allemaal; de studios waar ik stage gelopen (en andere waar ik weet van heb) gebruiken eigenlijk unaniem SCRUM, Perforce (source control) en doen aan backups, bug-tracking & CI. Geen idee of de auteur van het artikel ook daadwerkelijk een gamedev is geweest maar blijkbaar werkt 'ie bij Jira en daar zouden ze toch een aantal grote studios in hun klantenbestand moeten hebben staan. Ik durf er zelfs geld op te zetten dat de kleinere indie studios dit ook vrijwel allemaal doen.

Juist. Ik linkte het artikel ook niet omdat ik vind dat hij gelijk heeft hoor . Ik ken genoeg game studio's waar ze dit allemaal op orde hebben. Bij indie's zie je inderdaad ook al die dingen maar dan vaak een opensource variant of een gratis variant .

[dcm360]

alienfruit schreef op dinsdag 17 mei 2011 @ 11:20:
http://bellard.org/jslinux/ Knap hoor!

Hee, mn webbrowser is volgens die pagina te oud, en als alternatief moet ik een praktisch even oude webbrowser installeren

[Rutix]

dcm360 schreef op dinsdag 17 mei 2011 @ 12:07:
[...]

Hee, mn webbrowser is volgens die pagina te oud, en als alternatief moet ik een praktisch even oude webbrowser installeren

Welke browser gebruik je dan ?

[Hoogie2004]

Rutix schreef op dinsdag 17 mei 2011 @ 12:52:
[...]

Welke browser gebruik je dan ?

Vast IE6, of Netscape

[OkkE]

dcm360 schreef op dinsdag 17 mei 2011 @ 12:07:
[...]

Hee, mn webbrowser is volgens die pagina te oud, en als alternatief moet ik een praktisch even oude webbrowser installeren

Leeftijd van een browser zegt niet alles. Het gaat, in dit geval, om de javascript engine; die verschilt best nog wel wat per browser, als het om zulke demo's gaat. Deze demo is getest op Firefox 4 en Chrome 11.

[ Voor 11% gewijzigd door OkkE op 17-05-2011 12:58 ]

[dcm360]

Mja, de site zegt dat mn webbrowser te oud is, dat is niet bepaald mijn fout Overigens is Opera wat JS ondersteuning betreft ook niet bepaald slecht of traag.

[Cartman!]

Wat ik qua zulke meldingen superirritant vind is dat een site zegt "vul een geldig e-mailadres in" als ik [e-mail] probeer te submitten. Het is gewoon een geldig e-mailadres maar de validator van die site is gewoon niet in orde

[YopY]

Dat vraag ik me af. Ligt denk ik geheel aan de omgeving, maar bijvoorbeeld met de UDK zou dit niet mogelijk zijn en er zijn veel kleine game bedrijven die de UDK gebruiken.

Niet? Ik denk het namelijk wel - de Unreal engine zelf zou een bakkes aan tests hebben (die je als 'afnemer' natuurlijk niet hoeft uit te voeren, tenzij je de engine zelf kunt aanpassen), en de uScripts zou je ook kunnen testen met een uScript test library. Een test zou bijvoorbeeld zijn: "Als ik aan dit karakter vertel dat hij een stap moet doen, verwacht ik dat zijn positie met 1.0 meter in richting X verandert". Heb de ballen verstand van game design, maar ik geloof wel dat het mogelijk zou moeten zijn. Of het wenselijk is is punt twee, natuurlijk.

PrisonerOfPain schreef op dinsdag 17 mei 2011 @ 10:44:
Ik heb wel zo m'n vermoedens natuurlijk, en dat is dat er met enige regelmaat complete systemen op de schop gaan en dat performance optimalisaties vaak complete 'nette OOP' interfaces helemaal aan gruzellement helpen (en daarmee dus waarschijnlijk ook de tests). Kortom, waarschijnlijk zorgt 't voor meer frictie dan een simpele assert.

Ai, slecht, . In een goed geteste omgeving zou je in zo'n geval natuurlijk eerst de tests bijwerken, danwel de daadwerkelijke interface zelf niet wijzigen (slechts de interface). Zijn boeken over geschreven, . Ga zelf binnenkort Refactoring lezen, waarschijnlijk wordt daar ook in besproken hoe je zowel je gehele interface op de schop kunt nemen zonder je tests finaal stuk te maken. Denk dat het hoofdzakelijk een kwestie van discipline is.

Een spel als Minecraft is een goed voorbeeld van waarom tests goed moeten werken, en een werkend voorbeeld van een agile methodiek (alhoewel ik geloof dat geen van beide echt goed toegepast worden, maar kan het mishebben). Dit omdat er regelmatige releases zijn, en elke versie moet werken. Dat zou ik overigens wel vaker willen zien in de ontwikkeling van een spel - regelmatige updates waarbij nieuwe features en dergelijke toegevoegd worden. Maar ja, je zit dan met het betaalmodel. Zo eentje met in-game aankopen zou het wel in werken denk ik.

[Rutix]

Cartman! schreef op dinsdag 17 mei 2011 @ 13:32:
Wat ik qua zulke meldingen superirritant vind is dat een site zegt "vul een geldig e-mailadres in" als ik [e-mail] probeer te submitten. Het is gewoon een geldig e-mailadres maar de validator van die site is gewoon niet in orde

Ja inderdaad. Die + is echt super handig maar niet alle websites supporten het.

YopY schreef op dinsdag 17 mei 2011 @ 13:38:
[...]


Ai, slecht, . In een goed geteste omgeving zou je in zo'n geval natuurlijk eerst de tests bijwerken, danwel de daadwerkelijke interface zelf niet wijzigen (slechts de interface). Zijn boeken over geschreven, . Ga zelf binnenkort Refactoring lezen, waarschijnlijk wordt daar ook in besproken hoe je zowel je gehele interface op de schop kunt nemen zonder je tests finaal stuk te maken. Denk dat het hoofdzakelijk een kwestie van discipline is.

Een spel als Minecraft is een goed voorbeeld van waarom tests goed moeten werken, en een werkend voorbeeld van een agile methodiek (alhoewel ik geloof dat geen van beide echt goed toegepast worden, maar kan het mishebben). Dit omdat er regelmatige releases zijn, en elke versie moet werken. Dat zou ik overigens wel vaker willen zien in de ontwikkeling van een spel - regelmatige updates waarbij nieuwe features en dergelijke toegevoegd worden. Maar ja, je zit dan met het betaalmodel. Zo eentje met in-game aankopen zou het wel in werken denk ik.

Deadlines zijn vaak de oorzaak waarom ze liever Q&A laten testen dan de tests bij te werken . Die regelmatige updates krijg je vaak met MMO spellen . Verder rest zie je vaak patches ipv nieuwe features