De Devschuur Coffee Corner - Iteratie 6

[Caelorum]

Caelorum schreef op zaterdag 21 juni 2014 @ 10:06:
[....] Nu alleen nog even kijken hoe ik qtcreator zo ver krijg na een build dat help bestand even opnieuw in te laden.
Overigens echt ongelooflijk stom dat dat nog steeds niet in qtcreator zit. Elk andere IDE pakt automatisch comments op, maar dit vage programma dan weer niet

Ik stond echt op het punt een plug-in te gaan bouwen die dit doet, maar bedacht met nog net op tijd dat ik net zo goed even kan wachten op JetBrains.. Ze zouden die publieke beta toch een keer moeten gaan starten...
Overigens is die documentatie over plugins maken voor qtcreator echt ongelooflijk brak. Gelukkig lang niet op het niveau van MonoDevelop, maar jezus zeg... Het is niet meer dan een overzicht van classes en methodes zonder beschrijving wat het allemaal doet. Zie bijv. dit stuk over de HelpManager

*edit*
mja... Misschien morgen eens naar kijken. Is volgens mij niet veel meer dan de buildQueueFinished-slot van de ProjectExplorer::BuildManager hangen aan HelpManager::unregisterDocumentation(...) en HelpManager::registerDocumentation(...)

[ Voor 34% gewijzigd door Caelorum op 21-06-2014 14:19 ]

[Douweegbertje]

Gropah schreef op zaterdag 21 juni 2014 @ 14:10:
[...]


Druk bezig met QA van open source software op basis van gedateerde software reviews. Geen tijd voor devschuur dus helaas

Mooi verhaal als je dit kan posten

[Gropah]

Douweegbertje schreef op zaterdag 21 juni 2014 @ 14:25:
[...]


Mooi verhaal als je dit kan posten

SOA momentje en nu weer, dus tijd voor uitleg

Het gaat om een vak. Eerste deel was het project met de zweden waar ik wel eens wat over heb verteld. Ging prima, ook met een goed cijfer afgerond. Nu moet je echter (omdat de zweden eerder stoppen met het vak dan wij) ook nog een individueel vak doen. Daarvoor moet je dus een stuk opensource software QA'en. Opzich best handig en dan draag je ook nog iets bij aan zo'n project (als het daar tenminste uiteindelijk komt).

Echter zijn er redelijk wat eisen aan de software. Zo moet er al eerder een review van de software zijn gedaan op een website. Een website zonder goede zoekfunctie en zonder goede indicatie's etc waardoor je al meer dan 2 uur kwijt bent om een goed project te vinden. Vervolgens moet je niet van de versie waarvan al een review is de QA doen, maar van de nieuwste versie. Aan de ene kant logisch, want daar heeft het project tenminste wat aan, maar aan de andere kant kunnen de metrics die de site geven en waarop je project gekozen is totaal anders zijn door overhauls etc etc. Dit is deels bij mij het geval waardoor het hele rapport een stuk moeilijk wordt om te maken.

Nu ben ik dus bezig met onderzoek naar bepaalde metrics (voornamelijk met tools zoals CodePro) en hoe die positief te veranderen zijn. Onderdeel van het verslag is echter ook een class diagram voor en na de verandering, wat als gevolg heeft dat als je voorstel tot verbetering redelijk rigoureus is, je veel tijd kwijt bent aan het veranderen van grote class diagrams in visual paradigm, wat nou niet echt snel werkt.

/rant

[jip_86]

Even wat speurwerk gedaan vanmiddag, lijkt weer eens op dat problemen niet door onze module veroorzaakt worden
Maandag niet alleen maar koffiedrinken dus

[Douweegbertje]

Ben nu weer even bezig met m'n keyword checker, eigenlijk bizar dat google zo ontiegelijk moeilijk doet om dit niet standaard aan je te laten zien. Technisch gezien mag je ook geen tools gebruiken om de resultaten door te lopen, maar met wat proxies, verschillende useragents en headers kom je al ver.
Het enige nadeel is dat je af en toe vast kan lopen als de captcha voorbij komt, maar ik hoop op een gegeven moment het zover te hebben dat ik veilig zit.

[F.West98]

*oeps*-momentje....
Ik ben nu druk bezig met overzetten van al mijn domeinen en shit van de ene naar de andere hoster. Eindelijk van die oude prutszooi af

Eén probleempje: ik bedenk me ineens dat er nog wat mailadresjes (puur redirect) staan op die server... En ik heb geen vervangende mailservice, naast een dure Exchange (per account) en een VPS.

* F.West98 gaat eens kijken naar een goedkope manier om dit te fixen

[ValHallASW]

Als je al een bestaand google apps-account hebt voor een ander domein kan je die domeinen daaraan toevoegen. Anders bij een random hoster met 5-euro-per-maand-voor-oneindig-veel-domeinen-pakketjes wat forwards aanmaken?

[ Voor 6% gewijzigd door ValHallASW op 22-06-2014 00:10 ]

[F.West98]

Ja, ik kan dat bij transip doen, maar dat is dan 5-euro-per-jaar-per-domein helaas Mijn domeinen zitten er al.
Ik kijk eens verder... Jammer dat je wel aliassen kunt instellen bij je Outlook.com-account, maar dat die eigenlijk gewoon regelmatig de mailserver controleren en dus niet zelf zo functioneren.
Geen gApps-account helaas.

[Firesphere]

F.West98 schreef op zondag 22 juni 2014 @ 00:36:
Ja, ik kan dat bij transip doen, maar dat is dan 5-euro-per-jaar-per-domein helaas Mijn domeinen zitten er al.
Ik kijk eens verder... Jammer dat je wel aliassen kunt instellen bij je Outlook.com-account, maar dat die eigenlijk gewoon regelmatig de mailserver controleren en dus niet zelf zo functioneren.
Geen gApps-account helaas.

Of je regelt even een RPi-hosting of goedkope VPS waar je een paar e-mail records op host? Dat is toch niet zo ingewikkeld?
Die kun je zelfs in-home hosten. Alleen poort 143 en 25 forwarden naar je pi en je hebt een IMAP server.

Als je dat wilt doen, wel een pro-tip, gebruik alsjeblieft een remote-locatie voor het opslaan van backups, en gebruik je SD-card alleen als boot-systeem, maar laad de mail en config etc. vanaf een USB. SD kaartjes zijn niet heel betrouwbaar wanneer het op veel read/write acties aankomt.

[ Voor 25% gewijzigd door Firesphere op 22-06-2014 01:21 ]

[BtM909]

Wie heeft Yo al geïnstalleerd?

[Firesphere]

BtM909 schreef op zondag 22 juni 2014 @ 01:21:
Wie heeft Yo al geïnstalleerd?

[F.West98]

Firesphere schreef op zondag 22 juni 2014 @ 01:16:
[...]

Of je regelt even een RPi-hosting of goedkope VPS waar je een paar e-mail records op host? Dat is toch niet zo ingewikkeld?
Die kun je zelfs in-home hosten. Alleen poort 143 en 25 forwarden naar je pi en je hebt een IMAP server.

Als je dat wilt doen, wel een pro-tip, gebruik alsjeblieft een remote-locatie voor het opslaan van backups, en gebruik je SD-card alleen als boot-systeem, maar laad de mail en config etc. vanaf een USB. SD kaartjes zijn niet heel betrouwbaar wanneer het op veel read/write acties aankomt.

Allemaal leuk en aardig, maar ik weet 0 van Linux-based dingen :
En Windows Server kan wel leuk een SMTP server maken, maar geen IMAP redirectserver iets, althans, als ik Google vind ik alleen maar Exchange.
@SMTP: Volgens mij is die nu na 1 uur al geblokkeerd (niets gestuurd!), niets komt aan en ik krijg van MS een Outboundresponse dat ik geen spam mag versturen : (ja, ik vereis SSL verbindingen, logins en hij zit op een rare poort)

---

Yo.

[Firesphere]

F.West98 schreef op zondag 22 juni 2014 @ 01:49:
[...]

Allemaal leuk en aardig, maar ik weet 0 van Linux-based dingen :
En Windows Server kan wel leuk een SMTP server maken, maar geen IMAP redirectserver iets, althans, als ik Google vind ik alleen maar Exchange.
@SMTP: Volgens mij is die nu na 1 uur al geblokkeerd (niets gestuurd!), niets komt aan en ik krijg van MS een Outboundresponse dat ik geen spam mag versturen : (ja, ik vereis SSL verbindingen, logins en hij zit op een rare poort)

Ik lees "Ik heb geen zin om een uitdaging aan te gaan".

Je hebt toch toegang tot de DNS records van je domeinen? Dan kun je ook prima je MX-records wijzigen naar een ander IP of domein. Sterker nog, ik heb vaak zat MX records van mail.domain.com doorverwezen naar mail.outlook.com om Office 365 werkend te krijgen voor klanten.

Is echt een stukje cake om aan het werk te krijgen.

[Firesphere]

Dit is een dubbelpost waard vind ik:

De schrijver zegt, dat met refactoren, hij beter bugs kan vinden en fixen.

Hier ben ik het totaal mee oneens. Door te refactoren, herschrijf je alles naar een ander/nieuw/jou bekender systeem.

Dit brengt met zich mee, dat er bugs in de oude code worden gespot, en dus niet meer voorkomen in de nieuwe code.

echter door te refactoren, herschrijf je alles, waardoor je misschien oude code debugged, maar automatisch en onbewust nieuwe bugs introduceert. Refactoring != Bugfixing.

Beweren dat je door te refactoren een programma ontdoet van bugs, getuigd mi van een ongelofelijk tekort aan zelfkennis en een enorme overschatting van eigen kunnen en "gelijkhebbendheid" (ik kan zo snel niet een beter woord bedenken )

[F.West98]

Firesphere schreef op zondag 22 juni 2014 @ 01:53:
[...]

Ik lees "Ik heb geen zin om een uitdaging aan te gaan".

Je hebt toch toegang tot de DNS records van je domeinen? Dan kun je ook prima je MX-records wijzigen naar een ander IP of domein. Sterker nog, ik heb vaak zat MX records van mail.domain.com doorverwezen naar mail.outlook.com om Office 365 werkend te krijgen voor klanten.

Is echt een stukje cake om aan het werk te krijgen.

Ik bedoel er: "Ik heb geen tijd om de uitdaging aan te gaan"
Ik wil best iets leren over Linux e.d., alleen denk ik niet dat ik dat in 2 dagen ga redden. Ik heb nog 2 dagen om alles over te zetten voor mijn contract verloopt, waarvan eentje volgepland is met andere dingen. De rest van de vakantie heb ik het eigenlijk ook enorm druk (ja, echt "vakantie" dus). 3 grote projecten gepland.

Inhoudelijk::
Ja ik heb alles gewoon in Cloudflare staan, dat is geen probleem. Alleen heb ik nergens een IMAP server om dingen te ontvangen en direct door te sturen. Ik heb dus, zoals gezegd, zelf (nog) een Outlook.com-mail en de rest v.d. familie is inmiddels Exchange geworden. Laatste geval kon gewoon dus een nieuwe alias worden, enz. Outlook.com ondersteunt helaas geen custom domains meer......

edit:
Bedankt

[BikkelZ]

BtM909 schreef op zondag 22 juni 2014 @ 01:21:
Wie heeft Yo al geïnstalleerd?

Meteen natuurlijk. Mijn leven is nu compleet!

Firesphere schreef op zondag 22 juni 2014 @ 02:05:
De schrijver zegt, dat met refactoren, hij beter bugs kan vinden en fixen.

Hier ben ik het totaal mee oneens. Door te refactoren, herschrijf je alles naar een ander/nieuw/jou bekender systeem.

Dit brengt met zich mee, dat er bugs in de oude code worden gespot, en dus niet meer voorkomen in de nieuwe code.

echter door te refactoren, herschrijf je alles, waardoor je misschien oude code debugged, maar automatisch en onbewust nieuwe bugs introduceert. Refactoring != Bugfixing.

Beweren dat je door te refactoren een programma ontdoet van bugs, getuigd mi van een ongelofelijk tekort aan zelfkennis en een enorme overschatting van eigen kunnen en "gelijkhebbendheid" (ik kan zo snel niet een beter woord bedenken )

Ik ben eigenlijk altijd wel een beetje aan het tuinieren als ik met code bezig ben ook als ik met mijn eigen code werk. Op dit moment onderhoud ik een applicatie en ik heb 3000 regels toegevoegd en er 4000 weggegooid terwijl er wel functionaliteit is toegevoegd. Dus dan zitter er al sowieso 1000 regels code niet meer in waar dus ook geen bugs in kunnen zitten. Dat nog bovenop de bugfixes.

Maar dat werkt vooral goed bij matig onderhouden code, code waar een goeroe zonder tijdsdruk aan gewerkt heeft daar valt niet veel mee te beginnen.

[ Voor 78% gewijzigd door BikkelZ op 22-06-2014 03:51 ]

[Firesphere]

F.West98 schreef op zondag 22 juni 2014 @ 02:21:
[...]

edit:
Bedankt

yw

[RayNbow]

Firesphere schreef op zondag 22 juni 2014 @ 02:05:
echter door te refactoren, herschrijf je alles, waardoor je misschien oude code debugged, maar automatisch en onbewust nieuwe bugs introduceert. Refactoring != Bugfixing.

Refactoring is inderdaad niet gelijk aan bugfixing, maar dat wordt ook niet beweerd in de aangehaalde tekst.

Echter, met refactoring introduceer je geen nieuwe bugs. Kijk eens goed naar wat het woord betekent. Het betekent niets anders dan dat je iets ontbindt in factoren en/of bepaalde factoren weer met elkaar vermenigvuldigt.

[soulrider]

RayNbow schreef op zondag 22 juni 2014 @ 09:06:
[...]

Refactoring is inderdaad niet gelijk aan bugfixing, maar dat wordt ook niet beweerd in de aangehaalde tekst.

Echter, met refactoring introduceer je geen nieuwe bugs. Kijk eens goed naar wat het woord betekent. Het betekent niets anders dan dat je iets ontbindt in factoren en/of bepaalde factoren weer met elkaar vermenigvuldigt.

Wikipedia: Code refactoring

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility.

de gebruikte google: https://www.google.be/search?hl=nl&q=refactoring

[Caelorum]

BtM909 schreef op zondag 22 juni 2014 @ 01:21:
Wie heeft Yo al geïnstalleerd?

Is er al weer een nieuwe hype? WTF is het? Googlen gaat niet zo makkelijk ^^

Ben zelf nog maar net gaan kijken naar node.js en koa. Eens kijken wat ik daar mee kan Gok dat ik uiteindelijk iets als KOAN ga gebruiken.

[PrisonerOfPain]

RayNbow schreef op zondag 22 juni 2014 @ 09:06:
Echter, met refactoring introduceer je geen nieuwe bugs. Kijk eens goed naar wat het woord betekent. Het betekent niets anders dan dat je iets ontbindt in factoren en/of bepaalde factoren weer met elkaar vermenigvuldigt.

Nee, het is de bedoeling dat je geen nieuwe bugs introduceert. Maar iedere change die je doet kan nieuwe bugs opleveren, zo ook een refactoring.

[RayNbow]

PrisonerOfPain schreef op zondag 22 juni 2014 @ 11:02:
[...]


Nee, het is de bedoeling dat je geen nieuwe bugs introduceert. Maar iedere change die je doet kan nieuwe bugs opleveren, zo ook een refactoring.

Maar is het dan wel een refactoring?

Als ik onzin als 2=1*1 opschrijf, dan heb ik 2 toch ook niet ontbonden in factoren? Je kunt het louter een poging tot een ontbinding noemen.

[Caelorum]

Maar hoe wil je controleren dat jouw herschreven code exact hetzelfde doet als de oude code? Als je refactoring zo gaat beschouwen al jij doet, zal je ook al het gedrag van de bugs mee moeten gaan nemen. Daarnaast als je al niet eens weet wat het oude gedrag is, doordat je de bugs niet ziet (zoals de persoon in het verhaal), hoe kan je dan zeggen dat de herschreven code exact hetzelfde doet? Zelfs met uitgebreide tests is het nagenoeg onmogelijk dat te zeggen.
Overigens ook verspilde moeite, want de tijd die je gebruikt om dat aan te tonen had je dan beter kunnen besteden aan het daadwerkelijk fixen van bugs...

[ Voor 17% gewijzigd door Caelorum op 22-06-2014 11:33 ]

[Gamebuster]

Firesphere schreef op zondag 22 juni 2014 @ 02:05:
Dit is een dubbelpost waard vind ik:
[afbeelding]
De schrijver zegt, dat met refactoren, hij beter bugs kan vinden en fixen.

Hier ben ik het totaal mee oneens. Door te refactoren, herschrijf je alles naar een ander/nieuw/jou bekender systeem.

Dit brengt met zich mee, dat er bugs in de oude code worden gespot, en dus niet meer voorkomen in de nieuwe code.

echter door te refactoren, herschrijf je alles, waardoor je misschien oude code debugged, maar automatisch en onbewust nieuwe bugs introduceert. Refactoring != Bugfixing.

Beweren dat je door te refactoren een programma ontdoet van bugs, getuigd mi van een ongelofelijk tekort aan zelfkennis en een enorme overschatting van eigen kunnen en "gelijkhebbendheid" (ik kan zo snel niet een beter woord bedenken )

Ik ben het er anders mee eens. Afhankelijk van jouw manier van refactoren kan je code wel degelijk beter achter blijven dan dat het was.

Om te beginnen, met TDD heb je uiteraard de grootste functionaliteit gedekt met tests. Met deze tests kan je refactoren tot je een ons weegt zonder je code te breken. Ervan uitgaande dat jij met refactoren als doel hebt je code netter en beter leesbaar te maken, zal je ook de hoeveelheid bugs kunnen verkleinen door de verbeterde leesbaarheid en het automatisch herzien van alle logica, ervan uitgaande dat je weet wat je aan het doen bent.

Als jij bugs introduceert tijdens refactoren moet je echt even beginnen met het schrijven van tests. Als jij je code niet durft aan te raken omdat je bang bent dat je iets breekt, heb je toch echt iets fout gedaan. "Don't touch it!" gebieden moet uitzonderlijk zijn, niet gewoonlijk.

Magoed, als je enkel aan F5 driven development doet, introduceer je uiteraard bugs bij ieder teken dat je aanpast, of je nou iets verwijderd, aanpast of toevoegt.

[ Voor 7% gewijzigd door Gamebuster op 22-06-2014 12:08 ]

[PrisonerOfPain]

RayNbow schreef op zondag 22 juni 2014 @ 11:19:
[...]

Maar is het dan wel een refactoring?

Als ik onzin als 2=1*1 opschrijf, dan heb ik 2 toch ook niet ontbonden in factoren? Je kunt het louter een poging tot een ontbinding noemen.

Wat een onzin voorbeeld. Als je een class opsplitst in twee, of je data flow verandert of wat dan ook is de kans nu eenmaal dat je een fout maakt, meestal probeer je dat op te vangen met automatische tests of wat dan ook. Maar fouten kunnen er altijd in sluipen.

[Gomez12]

Gamebuster schreef op zondag 22 juni 2014 @ 11:58:
[...]
Als jij bugs introduceert tijdens refactoren moet je echt even beginnen met het schrijven van tests.

Dat klinkt leuk, maar als je tests zo goed zijn dan heb je bugvrije software en die bestaat niet.

Oftewel je tests zullen gaten bevatten en er is een kans dat die gaten onopgemerkt blijven totdat je gaat refactoren.

[RayNbow]

Caelorum schreef op zondag 22 juni 2014 @ 11:31:
Maar hoe wil je controleren dat jouw herschreven code exact hetzelfde doet als de oude code? Als je refactoring zo gaat beschouwen al jij doet, zal je ook al het gedrag van de bugs mee moeten gaan nemen.

Het idee van refactoring is dat ze redelijk generiek zijn. Optimalisaties in een compiler houden toch ook geen rekening met bugs in jouw programma? Het hele idee van een optimalisatie is dat het beoogde, waarneembare gedrag hetzelfde blijft.

Daarnaast als je al niet eens weet wat het oude gedrag is, doordat je de bugs niet ziet (zoals de persoon in het verhaal), hoe kan je dan zeggen dat de herschreven code exact hetzelfde doet?

Door het gedisciplineerd (of beter: automatisch) te doen. Je maakt een kleine wijziging en je test. Je maakt een volgende kleine wijziging en je test.

Als je het boek van Fowler leest, dan zie je dat er een methodiek wordt aanbevolen voor elke behandelde refactoring.

Vergelijk het desnoods met het oplossen van een wiskundige vergelijking. Iets als 5x - 30 = 12 schrijf je ook niet meteen om naar x = 10,58,4. Dat doe je stap voor stap en je controleert elke stap.

PrisonerOfPain schreef op zondag 22 juni 2014 @ 12:09:
[...]

Wat een onzin voorbeeld. Als je een class opsplitst in twee, of je data flow verandert of wat dan ook is de kans nu eenmaal dat je een fout maakt, meestal probeer je dat op te vangen met automatische tests of wat dan ook. Maar fouten kunnen er altijd in sluipen.

Het is voornamelijk een taaldingetje. Zo is het ook gebruikelijk om bijv. "er zit een fout in het bewijs" te zeggen, maar dan is het eigenlijk dus geen bewijs.

Verder heb je gelijk dat er fouten bij elke stap kunnen worden gemaakt.

[Firesphere]

Gamebuster schreef op zondag 22 juni 2014 @ 11:58:
[...]

Ik ben het er anders mee eens. Afhankelijk van jouw manier van refactoren kan je code wel degelijk beter achter blijven dan dat het was.

Om te beginnen, met TDD heb je uiteraard de grootste functionaliteit gedekt met tests. Met deze tests kan je refactoren tot je een ons weegt zonder je code te breken. Ervan uitgaande dat jij met refactoren als doel hebt je code netter en beter leesbaar te maken, zal je ook de hoeveelheid bugs kunnen verkleinen door de verbeterde leesbaarheid en het automatisch herzien van alle logica, ervan uitgaande dat je weet wat je aan het doen bent.

Als jij bugs introduceert tijdens refactoren moet je echt even beginnen met het schrijven van tests. Als jij je code niet durft aan te raken omdat je bang bent dat je iets breekt, heb je toch echt iets fout gedaan. "Don't touch it!" gebieden moet uitzonderlijk zijn, niet gewoonlijk.

Magoed, als je enkel aan F5 driven development doet, introduceer je uiteraard bugs bij ieder teken dat je aanpast, of je nou iets verwijderd, aanpast of toevoegt.

Nee, refactoren is herschrijven van code. Het eerste wat mij tegenstaat van de schrijver, is dat hij moet refactoren, om de code te begrijpen. Dan is de code waar hij mee werkt wel heel beroerd lijkt me zo, maar dat terzijde.

Met refactoren herschrijf je. Natuurlijk vallen bestaande bugs op, maar je tests laten niet zien waar die bugs zaten. En je tests zijn ook niet bugfree. Dus door te refactoren, verschuif je het probleem.

100% bugvrije code bestaat gewoonweg niet. En dat wordt het ook niet door te refactoren.

En bang zijn om te refactoren? Waar haal je dat vandaan? Dat heeft niets te maken met de gedeponeerde mening.

[PrisonerOfPain]

RayNbow schreef op zondag 22 juni 2014 @ 12:14:
Als je het boek van Fowler leest, dan zie je dat er een methodiek wordt aanbevolen voor elke behandelde refactoring.

Dat zijn patronen die je zou kunnen gebruiken om te refactoren, maar refactoren is over het algemeen gewoon het hetschrijven van bepaalde delen van een system zodat het beter in het nieuwe design passen. Refactoren doe je dan ook niet voor de lol maar om ruimte te maken voor iets nieuws.

[Firesphere]

PrisonerOfPain schreef op zondag 22 juni 2014 @ 12:53:
[...]


Dat zijn patronen die je zou kunnen gebruiken om te refactoren, maar refactoren is over het algemeen gewoon het hetschrijven van bepaalde delen van een system zodat het beter in het nieuwe design passen. Refactoren doe je dan ook niet voor de lol maar om ruimte te maken voor iets nieuws.

Of omdat de bestaande code gewoonweg slecht is geschreven en een grote hoop spaghetti is. Ook al past het wel in het design.

[PrisonerOfPain]

Firesphere schreef op zondag 22 juni 2014 @ 12:56:
[...]

Of omdat de bestaande code gewoonweg slecht is geschreven en een grote hoop spaghetti is. Ook al past het wel in het design.

Dat ben ik nu aan het doen, een simpel systeem maar het is zo'n zooi. Heb al 30+ files aan moeten passen om die shit overal tussenuit te vissen.

[Jan_V]

Argh.....!!
Footers aan de onderkant van de pagina, ook als de content te 'kort' is om de pagina op te vullen. Wat een drama. Vooral omdat de content container kleiner is dan de echte content, waarschijnlijk door een float blok waar het in zit.

Blij dat ik normaliter met designers werken die dit regelen.

[Gropah]

Gropah schreef op zaterdag 21 juni 2014 @ 14:33:
[...]

Om hier op door te gaan. Visual paradigm

In plaats van theoretische verbetering weer te geven in een nieuw klassediagram, ga je de verbetering maar implementeren en dan het diagram weer reverse engineeren mbv visual paradigm, omdat die grafen editor zo brak is.

edit: en schijnbaar heeft het schijt aan image exports... waarom doet dat ding het niet meer

[ Voor 11% gewijzigd door Gropah op 22-06-2014 14:31 ]

[Gleighton]

Tja het is een baggerprogramma. Helaas heb ik geen echt fatsoenlijke programma's gevonden die het zelfde kunnen.

Aan de andere kant heb ik wel eens een tooltje gevonden dat met een touchscreen werkt. Daarbij teken je dan vierkantjes en blokjes alsof je het met een pen doet, welke dan omgezet worden in leesbare blokjes die je kunt verslepen en aanpassen enzo.

[Douweegbertje]

Yo, wat is Yo nu?

[Struikrover]

Douweegbertje schreef op zondag 22 juni 2014 @ 14:54:
Yo, wat is Yo nu?

Yo!

[Styxxy]

Douweegbertje schreef op zondag 22 juni 2014 @ 14:54:
Yo, wat is Yo nu?

Ik gok op https://github.com/yeoman/yo .

[HMS]

Styxxy schreef op zondag 22 juni 2014 @ 15:21:
[...]

Ik gok op https://github.com/yeoman/yo .

Ik denk eerder http://time.com/2904467/yo-app-hack-security/

[F.West98]

Jan_V schreef op zondag 22 juni 2014 @ 13:35:
Argh.....!!
Footers aan de onderkant van de pagina, ook als de content te 'kort' is om de pagina op te vullen. Wat een drama. Vooral omdat de content container kleiner is dan de echte content, waarschijnlijk door een float blok waar het in zit.

Blij dat ik normaliter met designers werken die dit regelen.

JavaScript:

function positionFooter() {
    if ($(document).height() <= $(window).height()) {
        $('#footer').css("position", "fixed");
        $('#footer').css("bottom", "0");
    } else {
        $('#footer').css("position", "static");
    }
}
$(window).on("resize", positionFooter);
positionFooter();

Maar ik denk dat het niet gaat werken met floats enzo. En je hebt jQuery nodig

[Alex)]

Dat kan ook zonder jQuery

---

Hier moest ik toch wel even om lachen:

Beste Alex,

Mocht je ooit een keer willen van veranderen van werkgever of van functie, denk je dan ook eens aan <bedrijf>?

De koffie staat klaar en is hier echt te drinken...:)

Hartelijke groet,

<naam>
<bedrijf>

[ Voor 84% gewijzigd door Alex) op 22-06-2014 16:14 ]

[Gamebuster]

Net 2 computers, 2 monitoren en een laptop op straat weggegeven. Leuk om mensen blij te maken

"Mevrouw, wilt u een laptop?" "eeuh" "Hij's gratis, en hij werkt nog! Moet alleen een harde schijf in!" "oké... dank je wel... Hij werkt nog?" "Ja, moet alleen een harde schijf in!" "Oke... ik geef 'm wel aan mijn zonen! Dank je wel"

Groepje kinderen:
"Hee jongens, willen jullie een PC?" "EEuh... ja!" "Alsjeblieft! Niet laten vallen, he! Hij werkt echt nog!" "Oke dankjewel!" Jochie van nog geen 12 loopt naar huis met PC die hij amper kan tillen.

Laatste PC weggegeven aan een "gekleurde" oude man die al andere spullen die ik had weggegooid aan het oprapen was (tassen e.d.). Had 'm in het engels uitgelegd dat-ie voor een paar 10tjes een werkende PC ervan kan maken. "God bless you" was reactie. Verder heb ik 'm 3 van die grote plastic tassen gegeven. Hij liep naar huis met een karretje (die ik had weggegooid) vol met oude spullen van mij

Ik zie mensen nu nog steeds de overige troep die ik op straat heb gegooid oppakken en meenemen. Daarnaast weer een lekker leeg huis.

[ Voor 10% gewijzigd door Gamebuster op 22-06-2014 16:17 ]

[Firesphere]

Gamebuster schreef op zondag 22 juni 2014 @ 16:15:
Net 2 computers, 2 monitoren en een laptop op straat weggegeven. Leuk om mensen blij te maken

"Mevrouw, wilt u een laptop?" "eeuh" "Hij's gratis, en hij werkt nog! Moet alleen een harde schijf in!" "oké... dank je wel... Hij werkt nog?" "Ja, moet alleen een harde schijf in!" "Oke... ik geef 'm wel aan mijn zonen! Dank je wel"

Groepje kinderen:
"Hee jongens, willen jullie een PC?" "EEuh... ja!" "Alsjeblieft! Niet laten vallen, he! Hij werkt echt nog!" "Oke dankjewel!" Jochie van nog geen 12 loopt naar huis met PC die hij amper kan tillen.

Laatste PC weggegeven aan een "gekleurde" oude man die al andere spullen die ik had weggegooid aan het oprapen was (tassen e.d.). Had 'm in het engels uitgelegd dat-ie voor een paar 10tjes een werkende PC ervan kan maken. "God bless you" was reactie. Verder heb ik 'm 3 van die grote plastic tassen gegeven. Hij liep naar huis met een karretje (die ik had weggegooid) vol met oude spullen van mij

Ik zie mensen nu nog steeds de overige troep die ik op straat heb gegooid oppakken en meenemen. Daarnaast weer een lekker leeg huis.

De enige ongebruikte pc in mijn huis is een Apple 2, die ga ik toch echt niet even weggeven

Maar topactie!

[BikkelZ]

Over refactoring:

Je haalt een quote uit een boek aan om je punt te maken maar ik ken het onderwerp van het boek noch van het hoofdstuk verder, het zijn gewoon losse quotes zonder context. Als het over het oppikken van een legacy project wat achter gelaten is door de vorige ontwikkelaar kan ik zijn methode zonder meer aanraden. Ga je dit doen als nieuw teamlid in een team wat naar een deadline aan het rushen is flikkeren ze je aan je broekriem en nekvel het raam uit nog voor je eerste week afgelopen is.

Efin. Context dus.

[Firesphere]

BikkelZ schreef op zondag 22 juni 2014 @ 16:29:
Over refactoring:

Je haalt een quote uit een boek aan om je punt te maken maar ik ken het onderwerp van het boek noch van het hoofdstuk verder, het zijn gewoon losse quotes zonder context. Als het over het oppikken van een legacy project wat achter gelaten is door de vorige ontwikkelaar kan ik zijn methode zonder meer aanraden. Ga je dit doen als nieuw teamlid in een team wat naar een deadline aan het rushen is flikkeren ze je aan je broekriem en nekvel het raam uit nog voor je eerste week afgelopen is.

Efin. Context dus.

De context is er volledig, het zijn namelijk allemaal korte stukjes/opmerkingen etc. Dus het hele blokje is de context, het doet er niet toe om wat voor project het gaat, het gaat namelijk niet over een project o.i.d. maar over een algemene insteek.

Dat terzijde, mijn stelling gaat over dat je omwille van bugs vinden niet moet gaan refactoren, dat het statement dat refactoren bugs oplost ongefundeerd is en dat refactoren (dus) absoluut niet hetzelfde is als bugfixen.

De context van het boek doet niet terzake ten opzichte van mijn stelling, omdat die ook alleen maar gaat over de stelling zoals in het getoonde stuk staat.

[Jan_V]

F.West98 schreef op zondag 22 juni 2014 @ 16:02:
[...]

JavaScript:

function positionFooter() {
    if ($(document).height() <= $(window).height()) {
        $('#footer').css("position", "fixed");
        $('#footer').css("bottom", "0");
    } else {
        $('#footer').css("position", "static");
    }
}
$(window).on("resize", positionFooter);
positionFooter();

Maar ik denk dat het niet gaat werken met floats enzo. En je hebt jQuery nodig

Heb het inderdaad met javascript opgelost. Middels CSS werd het me te ingewikkeld. Maar in ieder geval bedankt!

[incaz]

Alleen stond er volgens mij niet dat het bugs fixt, maar dat het het opsporen van bugs makkelijker maakt. En dat kan ik me wel voorstellen - het opsporen van willekeurig wat dan ook in een soep van een functie van 300 regels lang is niet bepaald heel prettig.

[kaesve]

Daarnaast, om effectief te kunnen refactoren moet je een grondig begrip van de code krijgen. Dat helpt ook nogal met het opsporen van bugs. Maar ja, ik zou refactoren ook niet als strategie gebruiken om een reproduceerbare bug op te sporen.

[Douweegbertje]

Op te sporen of om het op te lossen? Ik bedoel, soms kom je iets tegen waarbij je beter maar een zootje opnieuw kan schrijven dan er nog meer in te gaan rommelen.

[BtM909]

Douweegbertje schreef op zondag 22 juni 2014 @ 14:54:
Yo, wat is Yo nu?

Apple: https://itunes.apple.com/us/app/yo./id834335592
Google Play: Yo

Inmiddels al een seed van 1M ontvangen (money down the drain )

[WernerL]

Jan_V schreef op zondag 22 juni 2014 @ 13:35:
Argh.....!!
Footers aan de onderkant van de pagina, ook als de content te 'kort' is om de pagina op te vullen. Wat een drama. Vooral omdat de content container kleiner is dan de echte content, waarschijnlijk door een float blok waar het in zit.

Blij dat ik normaliter met designers werken die dit regelen.

Container div een min-height van 100% geven. Footer een vaste hoogte geven en margin-top een negatieve margin geven die gelijk is aan de hoogte van de div. Heb je geen javascript voor nodig.

Dus ongeveer zo:


HTML:

code:

<div class="container">
Content
<div class="contentbottom"></div>
</div>
<div class="footer">
bla
</div>

CSS:

code:

.container {
height: auto;
min-height: 100%;
}

.contentbottom { height: 300px; }

.footer {
height: 300px;
margin-top: -300px;
}

Works like a charm

Zo heb ik het een hele tijd terug een keer opgelost.

[ Voor 6% gewijzigd door WernerL op 22-06-2014 18:40 ]

[Gamebuster]

"Yo!" geinstalleerd.

Ik had niet verwacht dat het echt zo nutteloos zou zijn als ik me voorstelde.

[Matis]

Om de een of andere reden had Chrome besloten om standaard mijn cookies weg te gooien na iedere browser restart (à la Incognito).
Het duurde even voordat ik daar achter kwam

[Martindo]

Eens zien of ik morgen slaag voor mijn rijexamen.

[Ealanrian]

Martindo schreef op zondag 22 juni 2014 @ 21:08:
Eens zien of ik morgen slaag voor mijn rijexamen.

Vast wel toch? Gewoon zorgen dat je niemand dood rijd

[BikkelZ]

Firesphere schreef op zondag 22 juni 2014 @ 16:37:
[...]

De context is er volledig, het zijn namelijk allemaal korte stukjes/opmerkingen etc. Dus het hele blokje is de context, het doet er niet toe om wat voor project het gaat, het gaat namelijk niet over een project o.i.d. maar over een algemene insteek.

Dat terzijde, mijn stelling gaat over dat je omwille van bugs vinden niet moet gaan refactoren, dat het statement dat refactoren bugs oplost ongefundeerd is en dat refactoren (dus) absoluut niet hetzelfde is als bugfixen.

De context van het boek doet niet terzake ten opzichte van mijn stelling, omdat die ook alleen maar gaat over de stelling zoals in het getoonde stuk staat.

Als ik het binnen de door jou gestelde perken moet houden dan moet ik zeggen dat het refactoren van reeds werkende en net geschreven code puur en alleen met de reden dat je het wil begrijpen omdat er een bug in zit inderdaad een slecht idee is. Software heeft net zoals een database gewoon een soort van normaalvorm en als die het ideaal benadert hoeft je ook niet te refactoren tenzij er nieuwe functionaliteit toegevoegd wordt.

Refactoren tijdens bugfixing doe ik alleen in een project dat qua klasses en functies niet goed genormaliseerd is of last heeft van onduidelijke naamgeving. En dan gaat het verhaal wat je aanhaalde precies op bij mij. Maar dat is eigenlijk gewoon wat je altijd doet, constant refactoren. Dat moet gewoon niet ophopen tot je er aandacht aan moet gaan besteden in een sprint maar direct meegenomen worden bij de changes die technical debt veroorzaken.

[F.West98]

WebDAV i.c.m. IIS Server

Alle tutorials gedaan, alle instellingen goed, en nu een 1920 system error. Bah, bah, bah.
* F.West98 gaat eens een topic aanmaken

[Verwijderd]

o/

Ik lurk al een tijdje mee, maar ik moet nu echt iets van m'n hart. Ik weet niet of mensen het herkennen: Samenwerken met indiërs.

Ze durven nooit toe te geven dat hun het probleem zijn als ik notabene met hun eigen foutmeldingen aan kom zetten. Vaak is het na 1-3 week magisch opgelost en ontkennen ze uberhaupt het probleem. Het altijd maar willen teleconferencen en 'yes yes problem, yes yes not our side. yes yes end user problem.'

Ze zijn nu al 3 week bezig om een time-out op te hogen. Vraag via een curl call (normale API's kunnen ze niet maken.) een aantal gegevens aan. In grotere batches waarop het systeem ontworpen is krijg ik regelmatig een melding van hun webserver (IIS) dat het script gestopt is omdat de time-out periode is verstreken. Blijven ze claimen dat de melding niet bij hun wegkomt en dat onze webservers (Apache, nginx) deze melding geven. Ze gaven ons nog wel als tip om de time-out tijden hoger te zetten. En natuurlijk wordt ondergetekende aangesproken waarom deze fouten nogsteeds niet zijn opgelost.

Ik ben er eigenlijk wel klaar mee bij mijn huidige bedrijf door de werkdruk die alleen maar opgevoerd wordt, ik al ongeveer 1.5-2 jaar werk voor twee man doe (collega zit in ziektewet, geen budget) en mensen op andere locaties moet vervangen.

Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

[F.West98]

@problemen: Indiërs (hoor je vaak genoeg dingen over hier)
@vraag: Hij DM'de mij toen ik hier klaagde over mijn ex-werkgever

[FrameWork.]

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:

Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

Toentertijd via Google zoeken. Daarnaast via Google Maps opzoek naar bedrijven. Waarom deze aanpak kun je je afvragen? Nou ik zocht een bijbaan en vond toen vrijwel alleen maar fulltime posities

Wel een tijdrovend klusje maar ik vond het een leuke bezigheid om eens rond te kijken in de digitale etalage bij de verschillende bedrijven die ik via deze methode tegenkwam.

offtopic:
Deze (student) Software Engineering heeft helaas geen werk meer, dus we mogen weer op zoek

[ Voor 2% gewijzigd door FrameWork. op 22-06-2014 23:19 . Reden: Subtiele toevoeging ]

[Firesphere]

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
o/

Ik lurk al een tijdje mee, maar ik moet nu echt iets van m'n hart. Ik weet niet of mensen het herkennen: Samenwerken met indiërs.

Ze durven nooit toe te geven dat hun het probleem zijn als ik notabene met hun eigen foutmeldingen aan kom zetten. Vaak is het na 1-3 week magisch opgelost en ontkennen ze uberhaupt het probleem. Het altijd maar willen teleconferencen en 'yes yes problem, yes yes not our side. yes yes end user problem.'

Ze zijn nu al 3 week bezig om een time-out op te hogen. Vraag via een curl call (normale API's kunnen ze niet maken.) een aantal gegevens aan. In grotere batches waarop het systeem ontworpen is krijg ik regelmatig een melding van hun webserver (IIS) dat het script gestopt is omdat de time-out periode is verstreken. Blijven ze claimen dat de melding niet bij hun wegkomt en dat onze webservers (Apache, nginx) deze melding geven. Ze gaven ons nog wel als tip om de time-out tijden hoger te zetten. En natuurlijk wordt ondergetekende aangesproken waarom deze fouten nogsteeds niet zijn opgelost.

Ik ben er eigenlijk wel klaar mee bij mijn huidige bedrijf door de werkdruk die alleen maar opgevoerd wordt, ik al ongeveer 1.5-2 jaar werk voor twee man doe (collega zit in ziektewet, geen budget) en mensen op andere locaties moet vervangen.

Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

Samenvattend, zijn er vele redenen om niet te outsourcen. Punt. Not gonna happen bij ons.

En hoe ik bij mijn huidige werkgever ben beland? Tja, "gewild zijn" is denk ik ongeveer waar het op neer komt. M'n vorige werkgever kon mij niet meer betalen, en toen had ik de keuze.

[HMS]

Outsourcen naar India is alleen op papier leuk. Tegenwoordig outsourcen de Indiërs die je inhuurt het weer naar nog goedkopere Indiërs . En de Indiërs met skills verkassen al vrij snel weer ergens anders heen, voor 10 cent per uur (meer) switchen ze probleemloos van werkgever.

[Megamind]

Enige wat nuttig kan zijn is grafisch werk, design, 3d modellen etc. heb ik wel eens geoutsourced, kan weinig mis aan gaan, het ziet er goed uit of niet

[BikkelZ]

Indiërs die ik meemaak zijn altijd best wel goed maar dat zijn de mensen die in de VS terecht zijn gekomen. Mijn baas komt uit India en dat is gewoon een prima vent. Ik ben zelf eigenlijk op dit moment de persoon die geoutsourced zit en ik kan het verhaal ook wel vanuit de andere kant vertellen.

Je kunt prima werk outsourcen maar je gaat niet besparen wat het verschil per uur is. Ik zou zelf nooit een belangrijk deel van ontwikkeling gaan outsourcen zonder zeer directe samenwerking met medewerkers binnen het bedrijf (dus mensen die code zien voordat het gemerged wordt e.d.) en als je het echt goed wil doen moet je een of twee mensen een aardige tijd met die mensen samen laten werken om wat op te bouwen. Company culture, communicatie.

Krijg echt zo vaak features onder ogen vol met jargon en doelen waar ik bij denk "wat wil je nou eigenlijk wat ík doe?". Mensen beseffen zich vaak niet dat na een meeting wat JIRA tickets in elkaar rossen totaal niks zegt voor iemand die niet bij die meeting was.

Overigens ooit ook een *******-engine geoutsourced naar België. Kwam ooit zo ver dat ze een drie dagen rekenden voor wat JS aanpassingen en ik het maar voor ze geschreven heb in een uurtje en gevraagd heb hoe lang het zou duren voordat ze het geïmplementeerd kregen. Drie dagen was het antwoord.

[ Voor 5% gewijzigd door BikkelZ op 23-06-2014 02:27 ]

[Dragor]

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
o/

Ik lurk al een tijdje mee, maar ik moet nu echt iets van m'n hart. Ik weet niet of mensen het herkennen: Samenwerken met indiërs.

Ze durven nooit toe te geven dat hun het probleem zijn als ik notabene met hun eigen foutmeldingen aan kom zetten. Vaak is het na 1-3 week magisch opgelost en ontkennen ze uberhaupt het probleem. Het altijd maar willen teleconferencen en 'yes yes problem, yes yes not our side. yes yes end user problem.'

Ze zijn nu al 3 week bezig om een time-out op te hogen. Vraag via een curl call (normale API's kunnen ze niet maken.) een aantal gegevens aan. In grotere batches waarop het systeem ontworpen is krijg ik regelmatig een melding van hun webserver (IIS) dat het script gestopt is omdat de time-out periode is verstreken. Blijven ze claimen dat de melding niet bij hun wegkomt en dat onze webservers (Apache, nginx) deze melding geven. Ze gaven ons nog wel als tip om de time-out tijden hoger te zetten. En natuurlijk wordt ondergetekende aangesproken waarom deze fouten nogsteeds niet zijn opgelost.

Bij ons is het meestal zo dat ze de problemen die wij vinden nooit kunnen reproduceren tenzij wij er een expliciete testcase bij geven. Dan wordt het gefixed, maar als je de patch binnenkrijgt kun je meestal door 5 minuten naar de code te kijken weer een aantal nieuwe fouten vinden. Dan maar weer terugsturen voor ronde 2, of een nieuw ticket inschieten.

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

Ik werk nu bij het bedrijf waar ik ben afgestudeerd.

[Thesulac]

Outsourcing: Pay peanuts, get monkeys..
Ooit 1 keer gedaan, nooit weer

[Tjolk]

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
Ik lurk al een tijdje mee, maar ik moet nu echt iets van m'n hart. Ik weet niet of mensen het herkennen: Samenwerken met indiërs.

Dat geldt niet specifiek voor Indiërs. Dat geldt eigenlijk voor samenwerken met exerne partijen in zijn algemeenheid. We hebben het hier tot een jaar geleden aan de hand gehad met een Nederlandse partij, exact hetzelfde verhaal. Zij het dan dat we gewoon Nederlands konden praten onderling (met een taalbarrière wordt het exponentieel erger).

De kern van het probleem is volgens mij dat de belangen anders liggen. Binnen je eigen bedrijf heeft iedereen hetzelfde belang voor ogen; externe partners werken over het algemeen puur op uurtje factuurtje en hebben ook nog andere partijen waarvoor ze werken. Altijd gedoe met deadlines, verantwoordelijkheden, verschil in verwacht resultaat, etc.

Vandaar dus dat we e.e.a. maar in huis hebben gehaald.

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

Google.

[alienfruit]

Ik werk als contractor bij een groot bedrijf en nu hebben nu twee mensen aangenomen om mijn werk over te nemen. Volgens mij is het voor de klant goedkoper om mij te blijven inhuren dan die twee mensen (eentje hier in de UK en eentje in Malaysië) aan het werk te hebben. Eentje is nu al 1,5 maand bezig om wat de UI dingen te veranderen. Terwijl ik het nagenoeg voor gezegd heb. Nu is mijn andere collega ook op vakantie Dit gaat een leuke maand worden. Werken voor twee projecten tegerlijkertijd

[ Voor 4% gewijzigd door alienfruit op 23-06-2014 09:00 ]

[Tanuki]

Verwijderd schreef op zondag 22 juni 2014 @ 23:08:
o/

Ik lurk al een tijdje mee, maar ik moet nu echt iets van m'n hart. Ik weet niet of mensen het herkennen: Samenwerken met indiërs.

Ze durven nooit toe te geven dat hun het probleem zijn als ik notabene met hun eigen foutmeldingen aan kom zetten. Vaak is het na 1-3 week magisch opgelost en ontkennen ze uberhaupt het probleem. Het altijd maar willen teleconferencen en 'yes yes problem, yes yes not our side. yes yes end user problem.'

Ze zijn nu al 3 week bezig om een time-out op te hogen. Vraag via een curl call (normale API's kunnen ze niet maken.) een aantal gegevens aan. In grotere batches waarop het systeem ontworpen is krijg ik regelmatig een melding van hun webserver (IIS) dat het script gestopt is omdat de time-out periode is verstreken. Blijven ze claimen dat de melding niet bij hun wegkomt en dat onze webservers (Apache, nginx) deze melding geven. Ze gaven ons nog wel als tip om de time-out tijden hoger te zetten. En natuurlijk wordt ondergetekende aangesproken waarom deze fouten nogsteeds niet zijn opgelost.

Ik ben er eigenlijk wel klaar mee bij mijn huidige bedrijf door de werkdruk die alleen maar opgevoerd wordt, ik al ongeveer 1.5-2 jaar werk voor twee man doe (collega zit in ziektewet, geen budget) en mensen op andere locaties moet vervangen.

Zo. Dat moest er even uit. Brengt mij meteen bij de volgende vraag: Hoe zijn jullie beland bij de hudige werkgever?

Ik heb er inderdaad ook ervaring mee en herken exact wat je hierboven zegt. Ik zat een keer in een call met 2 Indiers en iemand uit Nederland (die de mensen uit India aanstuurt). Gelukkig werkte het bedrijf waar ik werk niet direct samen met de Indiers, maar met die man uit Nederland. Ze zouden gaan onderzoeken waarom de code wel werkt in de test-omgeving, maar niet in de productie-omgeving.

Na 10 minuten, terwijl ik in die 10 minuten in de veronderstelling was dat zij hun code na aan het kijken waren etc, werd er gevraagd of ik het al had gevonden. Ik antwoordde netjes dat ik absoluut geen idee heb van hoe hun code werkt en dus ook echt niet aan het zoeken was en dacht dat zij bezig waren. "Fix our problem" was het antwoord. Nogmaals gezegd dat ik dat niet ga doen. Uiteindelijk heb ik na een uur zelf maar even zitten zoeken en kwam ik erachter dat ze mij 2 bestandjes niet hadden geleverd.

Uiteindelijk moest ik dan zelf die bestanden ergens vandaan halen, terwijl zij die naar mij moesten sturen. Ook dat kreeg ik niet duidelijk. Je voelt je dan zo raar, je wordt gewoon niet begrepen.

Jan_V schreef op zondag 22 juni 2014 @ 16:43:
[...]

Heb het inderdaad met javascript opgelost. Middels CSS werd het me te ingewikkeld. Maar in ieder geval bedankt!

Let op dat je $('#footer'), $(window) en $(document) cachet. Resize events worden heel vaak getriggerd als iemand zijn browser resized.

[Evilbee]

Aan het wachten tot we een tijdslot hebben gekregen om het productie systeem te updaten. Want dat had de klant nog niet geregeld

[TheNephilim]

Wat een rust en vrede hier! Allemaal wilde weekeinden gehad? xd

[Merethil]

Ik heb net een webapp die ik zelf heb gemaakt aangepast. Ik was even vergeten hoe traag en log dat ding is als je hem lokaal draait... 5 minuten wachten tot alles is ingeladen om een aanpassing te testen is saai!
Op de server doet hij exact hetzelfde in 2 seconden

Helaas wil de dag niet echt voorbij gaan.

[Robbiedobbie]

TheNephilim schreef op maandag 23 juni 2014 @ 10:49:
Wat een rust en vrede hier! Allemaal wilde weekeinden gehad? xd

3 dagen met toetsen op de opleiding.

Vanaf woensdag middag ga ik weer los

[alienfruit]

Na 10 minuten, terwijl ik in die 10 minuten in de veronderstelling was dat zij hun code na aan het kijken waren etc, werd er gevraagd of ik het al had gevonden. Ik antwoordde netjes dat ik absoluut geen idee heb van hoe hun code werkt en dus ook echt niet aan het zoeken was en dacht dat zij bezig waren. "Fix our problem" was het antwoord. Nogmaals gezegd dat ik dat niet ga doen. Uiteindelijk heb ik na een uur zelf maar even zitten zoeken en kwam ik erachter dat ze mij 2 bestandjes niet hadden geleverd.

Ze begrijpen je prima hoor maar zijn liever lui dan moe. Dat zeggen mijn Indische collega's altijd

[D-Raven]

Indiers zeggen nooit nee. Dus het enigste wat je hoort is: "yes yes yes" en ze doen "no no no"

[Thesulac]

"Yes you watch soccer match yesterday yes?"

No, I don't watch soccer (ze doelen vaak op Engelse matches).

"Was good match yes?"

[Laurens-R]

Hoewel ik het grotendeels eens ben met het feit dat werken met Indiers een uitdaging kan zijn (ik heb ook positieve voorbeelden meegemaakt), vind ik ook dat hollanders zich regelmatig vergissen in andere culturen als het aankomt op samenwerking.

Wij hollanders kunnen bijzonder lomp zijn in de ogen van andere culturen, ook al zijn wij vanuit onze eigen ogen gewoon 'direct' en 'to-the-point'. Wij hebben geen problemen met het direct praten met management terwijl dat in andere culturen een absolute no-no is. Ik heb nu met meerdere culturen samen gewerkt en het viel me echt op hoe plat en relatief grof sommige nederlanders konden zijn naar bijvoorbeeld mensen uit Azie, maar ook de meer 'westerse' landen als Australie en de VS.

Dus ja, er zijn situaties en landen waar soms echt een grove mismatch is, maar wij hollanders moeten af en toe ook even in de spiegel kijken als het gaat om communicatie en hoe we overkomen. We denken al snel dat we zo internationaal georienteerd zijn, terwijl maar bar weinig nederlanders op een dergelijke manier handelen en communiceren.

[ Voor 8% gewijzigd door Laurens-R op 23-06-2014 11:14 ]

[mbarie]

[HMS]

mbarie schreef op maandag 23 juni 2014 @ 11:14:
[afbeelding]

edit: De muizenval is ook een +1 waard.

[ Voor 7% gewijzigd door HMS op 23-06-2014 11:19 ]

[Alex)]

Ik heb ook de nodige ervaringen met werken met 'India'. Ik heb de nodige 'creatieve' oplossingen uit die hoek zien komen, die weliswaar het issue verhielpen maar absoluut niet voldeden aan de requirements. Denk aan hardcoded meuk als:

code:

if(url.Contains("/checkout/"))
{
    header.Visible = false;
} else if(url.Contains("/checkoutcomplete/"))
{
    header.Visible = true;
    payButton.Visible = false;
} else if(url.Contains("/catalog/"))
{
    header.Visible = true;
    payButton.Visible = true;
    showCartButton.Visible = true;
}

Of aan een oplossing als deze:

Request validation throwing errors in some conditions on the acceptance server. Fixed the issue.

Geen enkele uitleg in het ticket verder, en ook geen eraan gekoppelde check-ins in TFS. Uiteindelijk kwam ik er bij toeval achter dat de 'oplossing' bestond uit het geheel uitschakelen van de request validation-functie in de serverconfiguratie...

Ik heb die lui een paar keer in het echt meegemaakt (de klant vond het nuttig als het hele team samen in een ruimte zat, dus werden de Indiërs naar Nederland gehaald) en dat vond ik best leuk. Het zijn prima lui en ik kon echt wel merken dat ze het goed bedoelen. De output was er alleen niet naar...

[Blubber]

Alex) schreef op maandag 23 juni 2014 @ 11:16:
Geen enkele uitleg in het ticket verder, en ook geen eraan gekoppelde check-ins in TFS. Uiteindelijk kwam ik er bij toeval achter dat de 'oplossing' bestond uit het geheel uitschakelen van de request validation-functie in de serverconfiguratie...

Dat is een mooie oplossing .

[Alex)]

Blubber schreef op maandag 23 juni 2014 @ 11:51:
[...]


Dat is een mooie oplossing .

Een oplossing van het type "operatie geslaagd, patiënt overleden" zul je bedoelen

[Blubber]

Alex) schreef op maandag 23 juni 2014 @ 11:53:
[...]

Een oplossing van het type "operatie geslaagd, patiënt overleden" zul je bedoelen

Ik had wellicht 'oplossing' neer meten zetten .

Je moet gewoon altijd in je main methode een exception handler hebben die alles catched en vervolgens negeert. Op die manier heb je nooit unhandled exceptions!

[Evilbee]

Grr, zitten we midden in een update-procedure van een productie-systeem, is er een collega niet meer te bereiken. Blijkt dat ie is gaan lunchen...

[Barryvdh]

Evilbee schreef op maandag 23 juni 2014 @ 12:27:
Grr, zitten we midden in een update-procedure van een productie-systeem, is er een collega niet meer te bereiken. Blijkt dat ie is gaan lunchen...

Slechte planning om te gaan updaten tijdens de lunch dus

[rubenflush]

Of: slechte planning om te gaan lunchen tijdens updaten

Barryvdh schreef op maandag 23 juni 2014 @ 12:40:
[...]

Slechte planning om te gaan updaten tijdens de lunch dus

[Alex)]

rubenflush schreef op maandag 23 juni 2014 @ 12:41:
Of: slechte planning om te gaan lunchen tijdens updaten

Dat bestaat niet.

Lunch > updates. Altijd.

[Evilbee]

Barryvdh schreef op maandag 23 juni 2014 @ 12:40:
[...]

Slechte planning om te gaan updaten tijdens de lunch dus

Eerder slecht geplande lunch. Hij was al om 11:45 verdwenen...

[BM]

Lijkt me perfect gepland, die zag de problemen wellicht al aankomen

[dcm360]

Chrome Na enkele jaren toch maar weer eens geïnstalleerd, en het heeft nu al rare fratsen. Ik heb het al gepresteerd om 3 keer per ongeluk de browser af te sluiten, door het laatst geopende tabblad te sluiten. Normaalgesproken geven browsers dan toch een nieuw, leeg tabblad?

[Caelorum]

IE11 in ieder geval niet. Volgens mij alleen Opera die dat doet. en wellicht Safari.

[ Voor 13% gewijzigd door Caelorum op 23-06-2014 13:02 ]

[Marientjuh]

Het is maar net wat je verwacht ;-) Ik erger me aan browsers die niet sluiten als het laatste tabblad gesloten word

[dcm360]

Nu ben ik maar even gaan spieken: In Safari en Firefox is het laatst overgebleven tabblad niet te sluiten. Blijkbaar is het inderdaad iets dat alleen Opera doet, en waar ik gewend aan geraakt ben.

[.oisyn]

dcm360 schreef op maandag 23 juni 2014 @ 12:57:
Chrome Na enkele jaren toch maar weer eens geïnstalleerd, en het heeft nu al rare fratsen. Ik heb het al gepresteerd om 3 keer per ongeluk de browser af te sluiten, door het laatst geopende tabblad te sluiten. Normaalgesproken geven browsers dan toch een nieuw, leeg tabblad?

Mijn Chrome laat momenteel geen tooltips zien. En hij kon niet meer checken voor updates. Nou had ik laatst "137 games" adware op m'n PC ineens. 137games.exe proces dat runde, Chrome shortcuts waren vervangen door eentje met een startpagina, shortcut op m'n taakbalk... Alles geremoved, en even handmatig een standalone installer van Chrome gedownload en geïnstalleerd. Hij kan nu iig weer naar updates checken, maar tooltips werken nog altijd niet. Geen idee of het überhaupt gerelateerd is ook.

[Tjolk]

In Fx kun je browser.tabs.closeWindowWithLastTab op False zetten.

[.oisyn]

In Chrome heb je een extension die dit voorkomt:
https://chrome.google.com...glheodcopccdllffcijjeenkj

[matthijsln]

dcm360 schreef op maandag 23 juni 2014 @ 12:57:
Chrome Na enkele jaren toch maar weer eens geïnstalleerd, en het heeft nu al rare fratsen. Ik heb het al gepresteerd om 3 keer per ongeluk de browser af te sluiten, door het laatst geopende tabblad te sluiten. Normaalgesproken geven browsers dan toch een nieuw, leeg tabblad?

Ik heb dat ook altijd, dat ik een ander product direct afschrijf als het ietsie pietsie anders werkt als dat ik gewend ben.

Het is dan wel weer vervelend als een klant dat tegen mij vertelt over mijn programma. Die moeten maar gewoon wennen natuurlijk.

/s

[Gamebuster]

.oisyn schreef op maandag 23 juni 2014 @ 13:13:
[...]


Mijn Chrome laat momenteel geen tooltips zien. En hij kon niet meer checken voor updates. Nou had ik laatst "137 games" adware op m'n PC ineens. 137games.exe proces dat runde, Chrome shortcuts waren vervangen door eentje met een startpagina, shortcut op m'n taakbalk... Alles geremoved, en even handmatig een standalone installer van Chrome gedownload en geïnstalleerd. Hij kan nu iig weer naar updates checken, maar tooltips werken nog altijd niet. Geen idee of het überhaupt gerelateerd is ook.

Ik dacht altijd dat jij alles weet Hoe kan jij iets niet weten?

[F.West98]

6,5 op mijn schoolproject.
- 120 uur besteed voor een project van 80 uur
- Iedereen diep onder de indruk
- In 2 weken helemaal opgezet, naast drukte voor andere vakken, maar nog niet helemaal af (admin nog niet)
- Uitgebreide uitleg over hoe alles werkt (zelfs mijn moeder snapte het) in het verslag

6,5.
- Ja te moeilijke uitleg in het verslag
- Geen flow charts in het verslag
- Goede presentatie! (maar wel een 6,5 op de presentatie)
- Het was niet af (ik had 2 weken!)

[StM]

Te veel hooi op de vork genomen dus

[wackmaniac]

.oisyn schreef op maandag 23 juni 2014 @ 13:13:
[...]


Mijn Chrome laat momenteel geen tooltips zien. En hij kon niet meer checken voor updates. Nou had ik laatst "137 games" adware op m'n PC ineens. 137games.exe proces dat runde, Chrome shortcuts waren vervangen door eentje met een startpagina, shortcut op m'n taakbalk... Alles geremoved, en even handmatig een standalone installer van Chrome gedownload en geïnstalleerd. Hij kan nu iig weer naar updates checken, maar tooltips werken nog altijd niet. Geen idee of het überhaupt gerelateerd is ook.

Ook een keer gehad. Althans niet 137games.exe, maar op mijn Ubuntu-installatie. Enige dat werkte was clean install Chrome.