De Devschuur Coffee Corner - Iteratie ➒

[BikkelZ]

alienfruit schreef op dinsdag 13 oktober 2015 @ 15:10:
Ja, maar nu heb je bijvoorbeeld UIStackView in iOS 9 and dat is toch wel handig. Maar ja, als je dus twee iOs versies moet ondersteunen kan je het niet gebruiken... Best wel jammer.

Heeft natuurlijk niks te maken dat ik mijn view werkend heb gekregen met UIStackView en nog steeds zit te klooien met de single versie. Ik ga nu voor f--cked up weergave in Interface Builder en dan de constraint constante zetten in runtime...

Toch maar eens iOs ontwikkelaar vinden die mij code zou willen peer reviewen

60% zit al op iOS 9 dus als je nog even doorprutst hoeft iOS 8 al niet meer

Ik kan wel kijken maar deze week is weer meer crunch net zoals de vorige. Niet betaald werk doe ik niet tenzij het een half uurtje is.

[alienfruit]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 15:14:
60% zit al op iOS 9 dus als je nog even doorprutst hoeft iOS 8 al niet meer

Streefdatum is rond kerst en nieuwjaar... Wat denk je?

Ik kan wel kijken maar deze week is weer meer crunch net zoals de vorige. Niet betaald werk doe ik niet tenzij het een half uurtje is.

Ah, ik zal er over nadenken. Ik doe hetzelf momenteel als niet betaald werk

[BikkelZ]

alienfruit schreef op dinsdag 13 oktober 2015 @ 15:25:
[...]


Streefdatum is rond kerst en nieuwjaar... Wat denk je?

https://mixpanel.com/tren...port_unit:day,to_date:-42

iOS 8 ging wat langzamer dan iOS 9 nu gaat omdat het meer bugs had en lastiger te upgraden was. Ik denk dat iOS 9 rond kerst wel richting de 70-80% zit qua marktaandeel.

[.oisyn]

Gaat wel hard met die iOS versies. Volgens mij zit 'm iPad Air (1) nog op iOS 6, kan dat?

[Ryur]

.oisyn schreef op dinsdag 13 oktober 2015 @ 15:37:
Gaat wel hard met die iOS versies. Volgens mij zit 'm iPad Air (1) nog op iOS 6, kan dat?

Nee. Air(1) wordt standaard geleverd met iOS 7.
Air(2) wordt standaard geleverd met iOS8.

iOS 7 was een grote release (complete UI verandering).
iOS 8 & iOS 9 zijn relatief 'kleine' wijzigingen.

[ Voor 30% gewijzigd door Ryur op 13-10-2015 15:40 ]

[BikkelZ]

.oisyn schreef op dinsdag 13 oktober 2015 @ 15:37:
Gaat wel hard met die iOS versies. Volgens mij zit 'm iPad Air (1) nog op iOS 6, kan dat?

Alles vanaf de iPad 2 en de iPhone 4S kan op iOS 9 draaien.

[Ryur]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 15:39:
[...]


Alles vanaf de iPad 2 en de iPhone 4S kan op iOS 9 draaien.

Klopt, maar als je niet update zit op de Air(1) iOS7

[.oisyn]

Ryur schreef op dinsdag 13 oktober 2015 @ 15:38:
[...]

Nee. Air(1) wordt standaard geleverd met iOS 7.
Air(2) wordt standaard geleverd met iOS8.

iOS 7 was een grote release (complete UI verandering).
iOS 8 & iOS 9 zijn relatief 'kleine' wijzigingen.

Ik weet dat ik 'm een keer naar een hoger iOS versie heb geüpdatet toen ik 'm net had, maar toen was ie wel al een hele tijd uit (paar maanden erna lag de Air 2 in de winkels geloof ik). Nu je het zo zegt heb ik 'm volgens mij naar iOS7 geüpdatet. iOS8 en zeker 9 zeggen me helemaal niets.

[RayNbow]

Waterleiding gesprongen @ EWI TU Delft...

* RayNbow zit nu thuis terwijl z'n computer e.d. nog in z'n kantoor liggen...

[ Voor 25% gewijzigd door RayNbow op 13-10-2015 15:57 ]

[CodeCaster]

Of ik even een soft-delete van gebruikers wilde ondersteunen. Prima, daar had ik al rekening mee gehouden, dus met letterlijk drie regels code was de check ingebouwd in de service.

Ik gebruik ASP.NET Identity, maar ga geen workarounds toepassen zoals de op het web wordt veelvuldig voorgestelde lockout-datum (die bedoeld is voor te veel foute inlogpogingen) op een datum ver in de toekomst zetten. Ik had al een nullable DateTime-kolom genaamd Deleted.

Maar toen stuitte ik op een issue met foutafhandeling. Zes uur later ... foutafhandeling in ASP.NET MVC / WebAPI is een zootje.

Nu ben ik er met drie verschillende aanpakken bíjna uit, maar in sommige gevallen besluit WebAPI alsnog zijn eigen error-response te gooien, en niet mijn standaard API-bericht-wrapper, waardoor de client de response niet kan parsen.

[ Voor 56% gewijzigd door CodeCaster op 13-10-2015 16:29 ]

[.oisyn]

RayNbow schreef op dinsdag 13 oktober 2015 @ 15:55:
Waterleiding gesprongen @ EWI TU Delft...

Dat krijg je er nou van als je die dingen managed met functionele talen

[ Voor 12% gewijzigd door .oisyn op 13-10-2015 16:26 ]

[Candanz]

En toen was het laaste kwartiertje productiviteit aangebroken op werk, zover dat er nog is.

[Laurens-R]

Candanz schreef op dinsdag 13 oktober 2015 @ 16:44:
En toen was het laaste kwartiertje productiviteit aangebroken op werk, zover dat er nog is.

ook gewoon gepost om 16 minuten voor 17.00

dan zit je 't ook echt uit

[RayNbow]

.oisyn schreef op dinsdag 13 oktober 2015 @ 16:26:
[...]


Dat krijg je er nou van als je die dingen managed met functionele talen

De schuld ligt eerder bij het renovatiebedrijf dat destructive updates toepast.

[Caelorum]

.Gertjan. schreef op dinsdag 13 oktober 2015 @ 14:39:
[...] Een parameter kan inderdaad een null zijn (iemand kan een null erin mikken) en moet gecheckt worden (of met attributes worden afgevangen), maar [...]

Misschien dat ik gewoon in een 'luxe' positie zit, maar ik check nooit op null waardes in functies die ik schrijf. De persoon die de functie aanroept moet het maar checken en zorgen dat alles OK is. Als ik namelijk moet gaan checken op null waardes, moet ik eigenlijk ook gaan checken op alle andere condities. Dat kost ontzettend veel tijd.
Overigens worden alle foutmeldingen gelogd en gemaild, dus daar ontgaat ons op het werk vrijwel niets.
Thuis maakt het me eerlijk gezegd ook niet uit. Daar mag code falen, omdat ik de enige gebruiker ben

[Niekfct]

Defensive programming vs programming by contract

Het liefst werk ik met de tweede, mits ik er redelijkerwijs vanuit kan gaan dat de functie daadwerkelijk correct aangeroepen kan worden. Voor nullable problemen zijn er bijvoorbeeld annotaties (@NotNull, @Nullable) waarmee een IDE als IntelliJ mee overweg kan, dus deze pas ik eigenlijk overal toe.

Defensive programming heeft dan weer als (redelijk groot) voordeel dat je code vroeg faalt, en je precies weet waar de oorzaak ligt.

In praktijk gebruik je dus meestal van beide

[.oisyn]

Ik heb liever dat iets gewoon crasht dan dat de boel toevallig in een een of ander codepath belandt dat stilletjes faalt. Kwam pas nog allemaal code tegen van een lutser die dan gewoon maar returnt uit een functie als een pointer onverwacht null is (met als comment erbij: "defensive" true story). Ga dan maar eens debuggen waarom iets niet werkt zoals het zou moeten .

Maar ja, null checks zijn ook maar arbitrair. Ga je dan ook checken of die ene int wel binnen het verwachte bereik valt? Of dat een enum waarde er wel eentje is uit de lijst met valide enums?

[Niekfct]

.oisyn schreef op dinsdag 13 oktober 2015 @ 19:42:
Ik heb liever dat iets gewoon crasht dan dat de boel toevallig in een een of ander codepath belandt dat stilletjes faalt.

Ik heb nog liever dat mijn programma niet eens compileert Null safety zoals in Kotlin bijvoorbeeld, maar ook bijvoorbeeld tools als OpenJML waarmee dat soort dingen (integer bounds, list contents, etc) statisch gecheckt kunnen worden. Helaas is dit niet heel breed toegankelijk, en werkt het ook overal nog lang niet altijd.

[ Voor 3% gewijzigd door Niekfct op 13-10-2015 19:57 ]

[.oisyn]

En bovendien zijn lang niet alle condities statisch te controleren.

[BikkelZ]

.oisyn schreef op dinsdag 13 oktober 2015 @ 19:42:
Ik heb liever dat iets gewoon crasht dan dat de boel toevallig in een een of ander codepath belandt dat stilletjes faalt. Kwam pas nog allemaal code tegen van een lutser die dan gewoon maar returnt uit een functie als een pointer onverwacht null is (met als comment erbij: "defensive" true story). Ga dan maar eens debuggen waarom iets niet werkt zoals het zou moeten .

Maar ja, null checks zijn ook maar arbitrair. Ga je dan ook checken of die ene int wel binnen het verwachte bereik valt? Of dat een enum waarde er wel eentje is uit de lijst met valide enums?

Waarom heb je dan liever een crash in plaats van een kritieke fout in je log of een gebruiker die je belt dat schermpje x het niet meer helemaal doet? Stel je voor dat je een applicatie als Word hebt, wil je dan dat die applicatie crasht of dat hij gewoon even niks doet als je op Bold klikt en je omgekeerd Arabische tekens LTR met een Chinese Windows alleen cursief blijven?

[RayNbow]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 21:16:
[...]


Waarom heb je dan liever een crash in plaats van een kritieke fout in je log of een gebruiker die je belt dat schermpje x het niet meer helemaal doet? Stel je voor dat je een applicatie als Word hebt, wil je dan dat die applicatie crasht of dat hij gewoon even niks doet als je op Bold klikt en je omgekeerd Arabische tekens LTR met een Chinese Windows alleen cursief blijven?

Stel je voor dat je onder een MRI apparaat ligt en er een kritieke fout optreedt in de software van het apparaat. Wil je dat het apparaat crasht en stopt of de fout logt en vrolijk doorgaat?

[BikkelZ]

RayNbow schreef op dinsdag 13 oktober 2015 @ 21:24:
[...]

Stel je voor dat je onder een MRI apparaat ligt en er een kritieke fout optreedt in de software van het apparaat. Wil je dat het apparaat crasht en stopt of de fout logt en vrolijk doorgaat?

Ik denk dat als je gedwongen wordt te checken op een bepaalde waarde en je vervolgens checkt en dan niks doet je hoofdelijk aansprakelijk gesteld moet worden. Dat denk ik. En ik denk dat een null-pointer makkelijker recht te lullen als er een BBQ lucht uit de MRI kamer dan een:

code:

guard let radiationIntensityManager = radiationIntensityManager else {
     return // shrug
}

[RayNbow]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 21:31:
[...]


Ik denk dat als je gedwongen wordt te checken op een bepaalde waarde en je vervolgens checkt en dan niks doet je hoofdelijk aansprakelijk gesteld moet worden. Dat denk ik. En ik denk dat een null-pointer makkelijker recht te lullen als er een BBQ lucht uit de MRI kamer dan een:

code:

guard let radiationIntensityManager = radiationIntensityManager else {
     return // shrug
}

In een puur functionele taal is bovenstaande code gelukkig onzinnig.

[BikkelZ]

Niekfct schreef op dinsdag 13 oktober 2015 @ 19:56:
[...]


Ik heb nog liever dat mijn programma niet eens compileert Null safety zoals in Kotlin bijvoorbeeld, maar ook bijvoorbeeld tools als OpenJML waarmee dat soort dingen (integer bounds, list contents, etc) statisch gecheckt kunnen worden. Helaas is dit niet heel breed toegankelijk, en werkt het ook overal nog lang niet altijd.

We hadden het over Swift wat zo'n beetje een Kotlin kloon is. Maar dan moet je wel unwrappen op een gegeven moment en dan is het de vraag wat je doet als een unwrapping faalt.

[Niekfct]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 21:56:
[...]


We hadden het over Swift wat zo'n beetje een Kotlin kloon is. Maar dan moet je wel unwrappen op een gegeven moment en dan is het de vraag wat je doet als een unwrapping faalt.

In Kotlin is er niet zoiets als unwrappen. Of je krijgt de (niet null-)waarde, of de compiler begint te bitchen.

_{Ok, je kunt '!!' gebruiken, maar dan doe je iets verkeerd.}

[BikkelZ]

Niekfct schreef op dinsdag 13 oktober 2015 @ 22:50:
[...]

_{Ok, je kunt '!!' gebruiken, maar dan doe je iets verkeerd.}

Daar begon de hele discussie ooit mee. Dat je met Swift dus altijd ! moet voorkomen en in plaats daarvan altijd eerst moet checken met guard / let / else

[farlane]

Het zal dus liggen aan het type software dat je schrijft welke optie de voorkeur heeft : in het geval van het MRI apparaat wil je dat 'ie stopt, in het geval van de tekstverwerker moet 'het ding gewoon niet zeiken.

[gekkie]

farlane schreef op dinsdag 13 oktober 2015 @ 23:14:
Het zal dus liggen aan het type software dat je schrijft welke optie de voorkeur heeft : in het geval van het MRI apparaat wil je dat 'ie stopt, in het geval van de tekstverwerker moet 'het ding gewoon niet zeiken.

In het geval van de MRI heb ik als nog liever een gecontroleerde shutdown dan een crash .. (tenzij je er van uit wilt gaan dat de rest van het apparaat netjes wel met alle failsaves blijft werken)

[Gamebuster]

RayNbow schreef op dinsdag 13 oktober 2015 @ 21:24:
[...]

Stel je voor dat je onder een MRI apparaat ligt en er een kritieke fout optreedt in de software van het apparaat. Wil je dat het apparaat crasht en stopt of de fout logt en vrolijk doorgaat?

Stel je ligt aan een be-ademingmachine (of ander iets dat continue moet blijven draaien om je in leven te houden) en er treedt een kritieke fout op... Dan maar een log statement ipv crash-shutdown

[.oisyn]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 21:16:
[...]


Waarom heb je dan liever een crash in plaats van een kritieke fout in je log

Dat zeg ik niet, ik zeg liever een crash dan helemaal niet op de hoogte worden gebracht. Nergens zeg ik dat je beter een crash hebt dan informatie in een logfile. De rest van mijn reactie zal over die eerste situatie gaan.

of een gebruiker die je belt dat schermpje x het niet meer helemaal doet?

Ik maak geen applicaties waarbij gebruikers bellen dat schermpje X het niet meer doet

En natuurlijk moeten applicaties niet crashen in het wild, dat geldt voor games net zo goed. Maar het is wel zo dat het bij een crash meteen duidelijk is dat er iets mis is, en tevens waar het mis gaat. Als het gewoon niet werkt zoals verwacht moet je maar hopen dat het iemand opvalt.

Dat gezegd hebbende, terug naar je opmerking over de eindgebruiker. De situatie voor games is wel een tikkeltje anders. Feitelijk heb ik 2 klanten: mededevelopers die van mijn software gebruik maken, en de eindgebruiker (de gamer). Het lijntje naar mededevelopers alsmede de bijbehorende iteratie-tijd is extreem kort. In het ergste geval, waarbij een crash iemand van z'n werk afhoudt en de veroorzaker is niet direct te bereiken of er is niet direct een oplossing voor handen, kan de boosdoenende submit gewoon worden teruggerold. Iedereen heeft direct toegang tot sourcecontrol dus dergelijke problemen zijn zo verholpen.

Dan de eindgebruiker. Op dat punt hebben we op zich weinig meer aan logging, maar crashes moeten op dat punt gewoon niet gebeuren. Maar bedenk wel dat er enorm veen usertesting aan vooraf gaat, dus die crashes worden echt wel gevonden voor de game in de winkel ligt. En het is vooral daar dat een crash een veel duidelijkere fout is dan iets wat niet helemaal werkt zoals het zou moeten werken. Die komen dan ook redelijk snel terug met een minidump en dan is de fout zo achterhaald.

gekkie schreef op dinsdag 13 oktober 2015 @ 23:16:
[...]

In het geval van de MRI heb ik als nog liever een gecontroleerde shutdown dan een crash .. (tenzij je er van uit wilt gaan dat de rest van het apparaat netjes wel met alle failsaves blijft werken)

Dat je een global exception handler hebt die de boel gracefully afsluit betekent niet dat je het dan geen crash meer kunt noemen

[ Voor 10% gewijzigd door .oisyn op 13-10-2015 23:49 ]

[BikkelZ]

.oisyn schreef op dinsdag 13 oktober 2015 @ 23:48:
[...]

Dat zeg ik niet, ik zeg liever een crash dan helemaal niet op de hoogte worden gebracht. Nergens zeg ik dat je beter een crash hebt dan informatie in een logfile. De rest van mijn reactie zal over die eerste situatie gaan.

[...]

Ik maak geen applicaties waarbij gebruikers bellen dat schermpje X het niet meer doet

En natuurlijk moeten applicaties niet crashen in het wild, dat geldt voor games net zo goed. Maar het is wel zo dat het bij een crash meteen duidelijk is dat er iets mis is, en tevens waar het mis gaat. Als het gewoon niet werkt zoals verwacht moet je maar hopen dat het iemand opvalt.

Dat gezegd hebbende, terug naar je opmerking over de eindgebruiker. De situatie voor games is wel een tikkeltje anders. Feitelijk heb ik 2 klanten: mededevelopers die van mijn software gebruik maken, en de eindgebruiker (de gamer). Het lijntje naar mededevelopers alsmede de bijbehorende iteratie-tijd is extreem kort. In het ergste geval, waarbij een crash iemand van z'n werk afhoudt en de veroorzaker is niet direct te bereiken of er is niet direct een oplossing voor handen, kan de boosdoenende submit gewoon worden teruggerold. Iedereen heeft direct toegang tot sourcecontrol dus dergelijke problemen zijn zo verholpen.

Dan de eindgebruiker. Op dat punt hebben we op zich weinig meer aan logging, maar crashes moeten op dat punt gewoon niet gebeuren. Maar bedenk wel dat er enorm veen usertesting aan vooraf gaat, dus die crashes worden echt wel gevonden voor de game in de winkel ligt. En het is vooral daar dat een crash een veel duidelijkere fout is dan iets wat niet helemaal werkt zoals het zou moeten werken. Die komen dan ook redelijk snel terug met een minidump en dan is de fout zo achterhaald.


[...]

Dat je een global exception handler hebt die de boel gracefully afsluit betekent niet dat je het dan geen crash meer kunt noemen

code:

guard let thing = thing else {
    somethingFunnyHandler(stuff)
    return
}

func somethingFunnyHandler(stuff: Stuff) {
    if debugOrTest {
          dumpAndCrash(stuff)
    } else {
          sendErrorToServer(stuff)
    }
}

[.oisyn]

Ga heen met je lelijke Swift code

[Caelorum]

Jouw verhaal gaat duidelijk niet alleen voor games op. Dit is overigens ook mijn insteek. Laat maar crashen. Na een x periode aan dat soort bugs oplossen werkt het uiteindelijk gewoon en blijft het ook gewoon werken (totdat iemand de server update oid ^^)

[F.West98]

In mijn applicatie heb ik ook een leuke middenweg: als er ergens iets fout gaat deadlockt hij
Er gaat iig iets vaags fout met exception handling en de TPL, maar na veel testen gaat het niet meer fout

Maar daar moet ik nog eens beter naar gaan kijken.

[BikkelZ]

Caelorum schreef op woensdag 14 oktober 2015 @ 00:18:
Jouw verhaal gaat duidelijk niet alleen voor games op. Dit is overigens ook mijn insteek. Laat maar crashen. Na een x periode aan dat soort bugs oplossen werkt het uiteindelijk gewoon en blijft het ook gewoon werken (totdat iemand de server update oid ^^)

Waarom denk je dat bugs niet opgelost worden als iets niet crasht? Je hebt of "zachte" errors zoals API's die ineens veranderen of er uit liggen, of je hebt echte bugs die meteen opvallen en in de meeste gevallen ook direct gelogd worden.

[ Voor 16% gewijzigd door BikkelZ op 14-10-2015 00:30 ]

[Caelorum]

BikkelZ schreef op woensdag 14 oktober 2015 @ 00:30:
[...]
Waarom denk je dat bugs niet opgelost worden als iets niet crasht?

Ik zeg niet dat het niet wordt opgelost, maar zoals .oisyn al zei, iemand moet het opvallen. Als de logs niet in eigen beheer zijn, maar aan de kant van de klant.. tja... Met een crash valt het heel snel op
Overigens zelfs al zijn de logs in eigen beheer. Op het werk loggen we ook best veel en een hoop komt ook echt alleen daarin en crasht de applicatie niet van. Die logs worden alleen niet elke dag bekeken en alleen de redelijk kritieke zaken worden automagisch gemaild. Als iets echt crash mailt of belt de klant meestal vrij snel op. Als het proces gewoon doorloopt, maar niet doet wat ze verwachten, valt het ze vaak niet eens op en merken wij het soms ook pas dagen later. Dan kan het echt al redelijk serieuze vormen hebben aangenomen. Heel vervelend.
Dan kan je dus twee dingen doen. Of je logt alles, gaat heel defensief programmeren en loopt de logs dagelijks na, of je laat het snel crashen bij onverwachte zaken en lost het ter plekke op voordat het nog ergere zaken veroorzaakt. Mijn voorkeur gaat dan naar het laatste, maar beide manieren zijn in principe goed.

[ Voor 3% gewijzigd door Caelorum op 14-10-2015 00:36 ]

[Alex)]

Hallo Android Marshmellow

En hallo Google Now on Tap:

[ Voor 36% gewijzigd door Alex) op 14-10-2015 00:56 ]

[.oisyn]

WTF mijn catch-all bij Google Apps werkt ineens niet meer
.edit: en aliases ook niet . Hoe kan ik nou een nieuw certificaat aanvragen
.edit2: extra user aangemaakt, dat werkt blijkbaar wel. Waardeloos dit.

[ Voor 61% gewijzigd door .oisyn op 14-10-2015 01:06 ]

[RayNbow]

Gamebuster schreef op dinsdag 13 oktober 2015 @ 23:43:
[...]

Stel je ligt aan een be-ademingmachine (of ander iets dat continue moet blijven draaien om je in leven te houden) en er treedt een kritieke fout op... Dan maar een log statement ipv crash-shutdown

Zelfs dan moet het ding gewoon crashen (en vervolgens een recovery plaatsvinden). Na een kritieke fout weet je niet of het apparaat nog het gewenste gedrag vertoont. Weet je wel zeker dat het apparaat iemand nog in leven weet te houden als het vrolijk door blijft gaan na een kritieke fout? Ex falso quodlibet.

[HuHu]

RayNbow schreef op dinsdag 13 oktober 2015 @ 21:24:
[...]

Stel je voor dat je onder een MRI apparaat ligt en er een kritieke fout optreedt in de software van het apparaat. Wil je dat het apparaat crasht en stopt of de fout logt en vrolijk doorgaat?

Een MRI scanner is een heel slecht voorbeeld en de termen "software" en "apparaat" zijn niet specifiek genoeg.

Als in de software van het "bedieningspaneel" een fout optreedt, mag dat prima crashen en herstarten. Echter het apparaat moet altijd blijven draaien, omdat een quench (het "crashen" van de scanner) fysieke gevaren met zich meebrengt.

In alle bijna omstandigheden moet een MRI scanner blijven draaien, kritieke software fout of niet. Er moet een melding komen, patiënt veilig uit de ruimte en onder gecontroleerde omstandigheden beslissen wat er moet gebeuren.

[ Voor 7% gewijzigd door HuHu op 14-10-2015 09:02 ]

[farlane]

RayNbow schreef op woensdag 14 oktober 2015 @ 07:19:
Ex falso quodlibet.

F... me, kan ik op Wikipedia het artikel gaan opzoeken wat dat inhoudt. En de artikelen die uitleggen wat het artikel inhoudt.

[Vincentio]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 15:30:
[...]


https://mixpanel.com/tren...port_unit:day,to_date:-42

iOS 8 ging wat langzamer dan iOS 9 nu gaat omdat het meer bugs had en lastiger te upgraden was. Ik denk dat iOS 9 rond kerst wel richting de 70-80% zit qua marktaandeel.

Gelukkig zijn de meeste apps die ik ontwikkel voor enterprise omgevingen. Iets makkelijker om bepaalde versies te forcereren.

Al hebben wij wel een aantal apps draaien in de App Store. De App die nu zeer actief gebruikt wordt, daar zit 78% van de gebruikers van op iOS 9.

[HuHu]

farlane schreef op woensdag 14 oktober 2015 @ 09:04:
[...]

F... me, kan ik op Wikipedia het artikel gaan opzoeken wat dat inhoudt. En de artikelen die uitleggen wat het artikel inhoudt.

Het betekend ook wel: de onzinregel. Omdat niemand weet wat of hoe de fout is en hoe het apparaat zich daarna gedraagt, kun je dus niet zeggen dat het apparaat door moet gaan (omdat je niet weet wat het gevolg van de fout is).

[Caelorum]

HuHu schreef op woensdag 14 oktober 2015 @ 09:01:
[...] In alle bijna omstandigheden moet een MRI scanner blijven draaien, kritieke software fout of niet. Er moet een melding komen, patiënt veilig uit de ruimte en onder gecontroleerde omstandigheden beslissen wat er moet gebeuren.

Zou het niet gewoon handiger zijn als de MRI scanner gewoon echt uit gaat met een melding ergens waarom het mis is gegaan? Door blijven draaien lijkt me niet zo handig, want je hebt toch al niets meer aan het resultaat, omdat het beïnvloed kan zijn door de bug. Zviw wordt een patient ook niet opgesloten in het apparaat, dus deze kan er altijd uit.
Overigens denk ik dat als een MRI scanner crasht, je deze meteen uit de roulatie mag halen om het rustig uit te zoeken. Zelfde als de eerder genoemde beademingsmachine. Die zou ik niet meer vertrouwen totdat het 100% zeker is dat het niet aan de hardware ligt, maar aan de software (waarna alle apparaten van dat type eigenlijk niet meer te gebruiken zijn totdat de fix er is).
Overigens in jouw voorbeeld heb ik liever dat de MRI scanner crasht, de foutmelding op het laatste moment nog doorstuurt naar het bedieningspaneel en dat deze dit eventueel ergens toont of whatever. Maar dat ding kan zover ik kan bepalen gewoon gekilled worden.

[ Voor 10% gewijzigd door Caelorum op 14-10-2015 09:25 ]

[HuHu]

Caelorum schreef op woensdag 14 oktober 2015 @ 09:24:
[...]

Zou het niet gewoon handiger zijn als de MRI scanner gewoon echt uit gaat met een melding ergens waarom het mis is gegaan? Door blijven draaien lijkt me niet zo handig, want je hebt toch al niets meer aan het resultaat, omdat het beïnvloed kan zijn door de bug. Zviw wordt een patient ook niet opgesloten in het apparaat, dus deze kan er altijd uit.
Overigens denk ik dat als een MRI scanner crasht, je deze meteen uit de roulatie mag halen om het rustig uit te zoeken. Zelfde als de eerder genoemde beademingsmachine. Die zou ik niet meer vertrouwen totdat het 100% zeker is dat het niet aan de hardware ligt, maar aan de software (waarna alle apparaten van dat type eigenlijk niet meer te gebruiken zijn totdat de fix er is).
Overigens in jouw voorbeeld heb ik liever dat de MRI scanner crasht, de foutmelding op het laatste moment nog doorstuurt naar het bedieningspaneel en dat deze dit eventueel ergens toont of whatever. Maar dat ding kan zover ik kan bepalen gewoon gekilled worden.

Nee. Een MRI scanner mag niet uit. Nooit, alleen onder zéér speciale omstandigheden.

De magneet van de scanner wordt gekoeld met vloeibaar helium. Zodra een MRI scanner quenched, ontsnapt dit helium onder zeer grote druk en wordt de temperatuur van het apparaat van -270 C naar kamertemperatuur gebracht. Dit brengt gevaren en zeer hoge kosten met zich mee. De scanner is daarna enkele weken uit de roulatie en waarschijnlijk (grotendeels) afgeschreven. Zo'n crash kan honderdduizenden euro's kosten tot enkele miljoenen als het apparaat afgeschreven is.

Daarom is MRI een slecht voorbeeld. Zo'n apparaat mag niet crashen, de kosten en gevaren (van het ontsnappende helium) zijn te hoog.

[Caelorum]

Ah, dat verklaart een hoop

[HuHu]

Medische software is een hele andere tak van sport. Ik schrijf medische software, maar zet er heel groot boven "NOT FOR MEDICAL USE", want ik wil mijn vingers er niet aan branden.

[ZaZ]

MRI scanners zijn eigenlijk gewoon bedoeld om bureaustoelen in te gooien natuurlijk.
Vet lachen.

[HuHu]

De nieuwe medewerker had als opdracht gekregen de nieuwe computer aan te sluiten op de MRI scanner, zodat er wat experimentele software getest kon worden.

Een half uurtje later ging de telefoon van de manager: "hallo, dit is de manager", nam hij mee op.

"Ja hoi, je nieuwe medewerker hier. Euhhh... de computer hangt aan de MRI scanner."

- "Ow dat heb je vlot gedaan, mooi!", zei de manager blij.

"Nee, nou... de computer hangt aan de MRI scanner..."

Enige gelijkenis met waar gebeurde scenario's berusten louter op toeval.

[gekkie]

.oisyn schreef op dinsdag 13 oktober 2015 @ 23:48:
[...]
Dat je een global exception handler hebt die de boel gracefully afsluit betekent niet dat je het dan geen crash meer kunt noemen

Denk toch dat de gemiddelde piloot liever een nood/voorzorgslanding communiceert als hij er eentje gaat maken dan dat hij in paniek roept CRASH ! (en vervolgens een tijd lang hexadecimaal reciteert) ... en hem alsnog netjes parkeert op de landingsbaan

Dus koffiekan theekan alleskan .. maar ik zou het toch net iets anders benoemen

[ Voor 7% gewijzigd door gekkie op 14-10-2015 10:20 ]

[Otherside1982]

Oracle doet een beetje stom vandaag, query duurt 14 seconden:

SQL:

select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select id_c from c where nummer = 1234) 

Als ik de subselect apart uitvoer krijg ik onmiddelijk het resultaat, als ik de subselect vervang door een waarde krijg ik ook onmiddelijk resultaat. Blijkbaar optimaliseert hij de subselect niet of zo

[.oisyn]

gekkie schreef op woensdag 14 oktober 2015 @ 10:19:
[...]

Denk toch dat de gemiddelde piloot liever een nood/voorzorgslanding communiceert als hij er eentje gaat maken dan dat hij in paniek roept CRASH ! (en vervolgens een tijd lang hexadecimaal reciteert) ... en hem alsnog netjes parkeert op de landingsbaan

Dus koffiekan theekan alleskan .. maar ik zou het toch net iets anders benoemen

Die vergelijking gaat natuurlijk compleet mank, software is geen vliegtuig. De code crasht gewoon. De handler zorgt ervoor dat die crash echter niet aan de gebruiker wordt getoond, en dat de boel nog enigszins geborgen kan worden voor zover mogelijk.

[incaz]

.oisyn schreef op woensdag 14 oktober 2015 @ 10:43:
Die vergelijking gaat natuurlijk compleet mank, software is geen vliegtuig.

Maar een vliegtuig is wel software!

De code crasht gewoon. De handler zorgt ervoor dat die crash echter niet aan de gebruiker wordt getoond, en dat de boel nog enigszins geborgen kan worden voor zover mogelijk.

Dat hangt er ook een beetje vanaf hoe of wat. Crashes bij bv onverwachte memorycorruption: ja, prima. Als er andere pointers je memory overschrijven weet je idd echt niet wat er gebeurt. Dan is 'mayday, mayday' wel het beste.

Maar bij heel veel andere dingen kun je gewoon uitgaan van de mogelijkheid tot fouten, en dat is dan geen crash: netwerkverbindingen falen, bestanden raken corrupted, verkeerde (sensor)input, en bij views (waar het allemaal mee begon) is een falende view omdat ie ergens is afgesloten helemaal niet per se een probleem waarop gecrasht moet worden, omdat het als je dat afhandelt helemaal niet hoeft te leiden tot een programma dat onvoorspelbaar is. Dat kun je gewoon graceful oplossen: opnieuw proberen bv, of handelen zoals je doet als het er in de eerste plaats nooit geweest was... Dat hoeft echt niet altijd een crash op te leveren.

[Woy]

Otherside1982 schreef op woensdag 14 oktober 2015 @ 10:34:
Oracle doet een beetje stom vandaag, query duurt 14 seconden:

Waarom niet gewoon

SQL:

select A.*, C.*
from A
   join B on b.id_a = A.id_a
   join C on C.id_c = A.id_c AND C.nummer = 1234 

[Cloud]

incaz schreef op woensdag 14 oktober 2015 @ 11:04:
[...]
Maar bij heel veel andere dingen kun je gewoon uitgaan van de mogelijkheid tot fouten, en dat is dan geen crash: netwerkverbindingen falen, bestanden raken corrupted, verkeerde (sensor)input, en bij views (waar het allemaal mee begon) is een falende view omdat ie ergens is afgesloten helemaal niet per se een probleem waarop gecrasht moet worden, omdat het als je dat afhandelt helemaal niet hoeft te leiden tot een programma dat onvoorspelbaar is. Dat kun je gewoon graceful oplossen: opnieuw proberen bv, of handelen zoals je doet als het er in de eerste plaats nooit geweest was... Dat hoeft echt niet altijd een crash op te leveren.

Volgens mij was dat dan ook niet wat .oisyn voorstelde Hij heeft het over echte excepties (die dus exceptioneel behoren te zijn), niet over zaken die je vooraf kunt voorspellen zoals een timeout op een netwerkverbinding. Die kun je, omdat je ze kunt verwachten, inderdaad netjes afhandelen.

[KabouterSuper]

Otherside1982 schreef op woensdag 14 oktober 2015 @ 10:34:
Oracle doet een beetje stom vandaag, query duurt 14 seconden:

SQL:

select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select id_c from c where nummer = 1234) 

Als ik de subselect apart uitvoer krijg ik onmiddelijk het resultaat, als ik de subselect vervang door een waarde krijg ik ook onmiddelijk resultaat. Blijkbaar optimaliseert hij de subselect niet of zo

En als je de WITH syntax gebruikt?

code:

WITH TMP AS (select id_c from c where nummer = 1234)
select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select tmp.id_c from tmp)

[ Voor 0% gewijzigd door KabouterSuper op 14-10-2015 11:12 . Reden: Oeps, haakjes vergeten ]

[Otherside1982]

Woy schreef op woensdag 14 oktober 2015 @ 11:06:
[...]

Waarom niet gewoon

SQL:

select A.*, C.*
from A
   join B on b.id_a = A.id_a
   join C on C.id_c = A.id_c AND C.nummer = 1234 

Waarom wel? Het resultaat zou toch hetzelde moeten zijn.
De query zit zonder subselect in de toepassing waarbij id_c wordt ingevuld via een parameter. Om te testen was het nu makkelijker om via een subselect op nummer het id op te zoeken. Met een join kan uiteraard ook en dat doe ik ook, maar niet voor zo'n ad-hoc queries. Een subselect kan je makkelijker toevoegen en weer weghalen zonder de originele query te veranderen.

---

KabouterSuper schreef op woensdag 14 oktober 2015 @ 11:11:
[...]


En als je de WITH syntax gebruikt?

code:

WITH TMP AS (select id_c from c where nummer = 1234)
select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select tmp.id_c from tmp)

Maakt niks uit, duurt ook 14 seconden.

Met andere DBMSen zoiets nog niet gezien, dat een subselect zoveel trager is.

[ Voor 24% gewijzigd door Otherside1982 op 14-10-2015 11:19 ]

[.oisyn]

incaz schreef op woensdag 14 oktober 2015 @ 11:04:
[...]


Maar een vliegtuig is wel software!

Nee, een vliegtuig bevat software. Composition, geen inheritance

Cloud schreef op woensdag 14 oktober 2015 @ 11:08:
[...]

Volgens mij was dat dan ook niet wat .oisyn voorstelde Hij heeft het over echte excepties (die dus exceptioneel behoren te zijn), niet over zaken die je vooraf kunt voorspellen zoals een timeout op een netwerkverbinding. Die kun je, omdat je ze kunt verwachten, inderdaad netjes afhandelen.

^^^ Wat hij zegt . Ik had het ook expliciet over een globale exception handler. De zaken die jij (incaz) beschrijft vang je lokaal af. Tenzij je ze vergeet af te vangen, dan worden ze alsnog opgepikt maar dat is dan weer gewoon effectief een crash. De globale handler zorgt er alleen maar voor dat je in plaats van de Windows crash dialog gewoon een custom dialog krijgt.

[ Voor 12% gewijzigd door .oisyn op 14-10-2015 11:19 ]

[gekkie]

incaz schreef op woensdag 14 oktober 2015 @ 11:04:
Dat hangt er ook een beetje vanaf hoe of wat. Crashes bij bv onverwachte memorycorruption: ja, prima. Als er andere pointers je memory overschrijven weet je idd echt niet wat er gebeurt. Dan is 'mayday, mayday' wel het beste.

Maar bij heel veel andere dingen kun je gewoon uitgaan van de mogelijkheid tot fouten, en dat is dan geen crash: netwerkverbindingen falen, bestanden raken corrupted, verkeerde (sensor)input, en bij views (waar het allemaal mee begon) is een falende view omdat ie ergens is afgesloten helemaal niet per se een probleem waarop gecrasht moet worden, omdat het als je dat afhandelt helemaal niet hoeft te leiden tot een programma dat onvoorspelbaar is. Dat kun je gewoon graceful oplossen: opnieuw proberen bv, of handelen zoals je doet als het er in de eerste plaats nooit geweest was... Dat hoeft echt niet altijd een crash op te leveren.

Mjah zoals ik al eerder aangaf een probleem in o.a. de Linux kernel .. dev'ers die zetten in drivers overal "BUG_ON's" ... leuk voor het ontwikkelen ... echter blijven ze ook zitten.

Iets minder als je kernel crasht op iets onverwachts in een totaal futiele oninteressante driver.
De meeste zouden best met een big fat warning afkunnen .. desnoods disable je die hele driver .. maar je hoeft meestal niet het hele systeem plat te gooien. (al is het soms wellicht lastig om vooraf te bedenken wat er allemaal aan opvolgende fouten zouden kunnen gaan optreden).

[gekkie]

Otherside1982 schreef op woensdag 14 oktober 2015 @ 10:34:
Oracle doet een beetje stom vandaag, query duurt 14 seconden:

SQL:

select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select id_c from c where nummer = 1234) 

Als ik de subselect apart uitvoer krijg ik onmiddelijk het resultaat, als ik de subselect vervang door een waarde krijg ik ook onmiddelijk resultaat. Blijkbaar optimaliseert hij de subselect niet of zo

En wat heeft het orakel zelf te melden als je vraagt om uitleg ?

[.oisyn]

Oracle only tells you what you need to hear.

[KabouterSuper]

gekkie schreef op woensdag 14 oktober 2015 @ 11:25:
[...]

En wat heeft het orakel zelf te melden als je vraagt om uitleg ?

Dik kans dat Oracle de subquery voor elke regel in A uitvoert. Zelfs als C in je cache zit, geeft dit trage queries.

[Woy]

KabouterSuper schreef op woensdag 14 oktober 2015 @ 11:35:
[...]


Dik kans dat Oracle de subquery voor elke regel in A uitvoert. Zelfs als C in je cache zit, geeft dit trage queries.

Mja, maar dat is nogal stom als het geen correlated subquery is. Kijk van MySQL o.i.d. kan je dat natuurlijk wel verwachten, maar van Oracle zou je toch wel beter verwachten.

[gekkie]

KabouterSuper schreef op woensdag 14 oktober 2015 @ 11:35:
[...]
Dik kans dat Oracle de subquery voor elke regel in A uitvoert. Zelfs als C in je cache zit, geeft dit trage queries.

Zou je er dan geen "where any()" van kunnen maken ipv een "Where =" ?

[ZaZ]

waarom niet gewoon een explain doen die waarschijnlijk de vraag meteen beantwoordt.

[n2theb]

Gekke vraag, maar is het niet handiger om te groeperen en een limit 1 op de where statement te zetten?
Zoals;

code:

select * 
from A
   join B on b.id_a = A.id_a 
where A.id_c = (select id_c from c where nummer = 1234 LIMIT 1)
group by A.id_a

[Otherside1982]

gekkie schreef op woensdag 14 oktober 2015 @ 11:38:
[...]

Zou je er dan geen "where any()" van kunnen maken ipv een "Where =" ?

where in (subselect) is inderdaad snel

ZaZ schreef op woensdag 14 oktober 2015 @ 11:41:
waarom niet gewoon een explain doen die waarschijnlijk de vraag meteen beantwoordt.

Te veel moeite voor een ad-hoc query die niet in de toepassing zit

Het was gewoon iets wat me opviel, die query voerde ik even uit om wat te controleren, die moet niet optimaal zijn. Ik had alleen niet verwacht dat het zo traag zou zijn.

[ Voor 14% gewijzigd door Otherside1982 op 14-10-2015 11:45 ]

[KabouterSuper]

gekkie schreef op woensdag 14 oktober 2015 @ 11:38:
[...]

Zou je er dan geen "where any()" van kunnen maken ipv een "Where =" ?

where EXISTS is in het algemeen de snelste variant. ANY and SOME worden door de optimizer normaliter naar EXISTS getransformeerd.

In dit geval krijg je overigens maar 0 of 1 resulta(a)t(en) uit je subquery (anders zou where .. = () een fout opleveren),dus ik vermoed dat je de boel niet heel erg versnelt.

[gekkie]

KabouterSuper schreef op woensdag 14 oktober 2015 @ 11:35:
[...]
Dik kans dat Oracle de subquery voor elke regel in A uitvoert. Zelfs als C in je cache zit, geeft dit trage queries.

Ik bedoelde de EXPLAIN van Oracle .. maar goed .. als je eigen "georakel" waar zou zijn .. dan zou ik verwachten dat de "WITH" variant wel verschil zou maken.

[KabouterSuper]

gekkie schreef op woensdag 14 oktober 2015 @ 11:57:
[...]

Ik bedoelde de EXPLAIN van Oracle .. maar goed .. als je eigen "georakel" waar zou zijn .. dan zou ik verwachten dat de "WITH" variant wel verschil zou maken.

Ja, dat snapte ik. Maar het is altijd leuk om te voorspellen wat Oracle doet zonder gelijk naar de explain plan te grijpen. Maar wellicht kan otherside de twee plans even dumpen, dan kunnen we daarna weer verder met ons leveln.

[gekkie]

KabouterSuper schreef op woensdag 14 oktober 2015 @ 12:04:
[...]
Ja, dat snapte ik. Maar het is altijd leuk om te voorspellen wat Oracle doet zonder gelijk naar de explain plan te grijpen. Maar wellicht kan otherside de twee plans even dumpen, dan kunnen we daarna weer verder met ons leveln.

Vast z'n delphi IDE nog aan het opstarten

[Otherside1982]

gekkie schreef op woensdag 14 oktober 2015 @ 12:05:
[...]

Vast z'n delphi IDE nog aan het opstarten

Nee, ik werk bijna nooit met Oracle, dus even moeten opzoeken hoe ik een explain plan deed en de output deftig kreeg.
Voor de liefhebbers, zoals verwacht dus een full table scan. Niet de meest recente versie van Oracle 11.2.0.1 (2011 ergens?), maar dit zou toch beter moeten kunnen.

code:

select * from a join b on b.id_a = a.id_a where b.id_c = (select id_c from c where nummer = 1234)
---------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                 |   529K|    29M|   773   (3)|
|   1 |  NESTED LOOPS                  |                 |       |       |            |
|   2 |   NESTED LOOPS                 |                 |   529K|    29M|   772   (3)|
|   3 |    TABLE ACCESS FULL           | B               |   529K|    16M|   764   (2)|
|   4 |    INDEX RANGE SCAN            | C_FK            |     1 |       |     0   (0)|
|   5 |     TABLE ACCESS BY INDEX ROWID| C               |     1 |     8 |     1   (0)|
|   6 |      INDEX UNIQUE SCAN         | AK_C            |     1 |       |     0   (0)|
|   7 |   TABLE ACCESS BY INDEX ROWID  | A               |     1 |    26 |     0   (0)|
---------------------------------------------------------------------------------------

code:

select * from a join b on b.id_a = a.id_a where b.id_c = any (select id_c from c where nummer = 1234)
-----------------------------------------------------------------------------------------
| Id  | Operation                      | Name              | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                   |   126 |  8442 |   197   (0)|
|   1 |  NESTED LOOPS                  |                   |       |       |            |
|   2 |   NESTED LOOPS                 |                   |   126 |  8442 |   197   (0)|
|   3 |    NESTED LOOPS                |                   |    69 |  2346 |     1   (0)|
|   4 |     TABLE ACCESS BY INDEX ROWID| C                 |     1 |     8 |     1   (0)|
|   5 |      INDEX UNIQUE SCAN         | AK_BAK            |     1 |       |     0   (0)|
|   6 |     TABLE ACCESS BY INDEX ROWID| B                 |    69 |  1794 |     0   (0)|
|   7 |      INDEX RANGE SCAN          | C_FK              |     1 |       |     0   (0)|
|   8 |    INDEX RANGE SCAN            | A_FK              |     2 |       |     2   (0)|
|   9 |   TABLE ACCESS BY INDEX ROWID  | A                 |     2 |    66 |     3   (0)|
-----------------------------------------------------------------------------------------

[gekkie]

Otherside1982 schreef op woensdag 14 oktober 2015 @ 12:30:
[...]

Nee, ik werk bijna nooit met Oracle, dus even moeten opzoeken hoe ik een explain plan deed en de output deftig kreeg.
Voor de liefhebbers, zoals verwacht dus een full table scan. Niet de meest recente versie van Oracle 11.2.0.1 (2011 ergens?), maar dit zou toch beter moeten kunnen.

code:

Het orakel heeft gesproken ..

Zou het wellicht nog uit kunnen maken om het type join te specificeren ?
(of wijzigen in een select * from b join a where b= ipv select * from a join b where b=)

Hij lijkt nu inderdaad eigenlijk nog niks met de where clause te willen doen tot na de join.

Bij de weg .. ik zie nergens in de explain dat tie b.id_a ziet als PK of FK .. en derhalve dat b.id dus ook wellicht niet UNIQUE en NOT NULL is ?
(en dus een full table scan gaat gebruiken om die meuk als best effort te joinen)


http://news.slashdot.org/...2Fslashdot+%28Slashdot%29
Joy oh joy

[ Voor 84% gewijzigd door gekkie op 14-10-2015 14:04 ]

[Alex)]

Ik heb gisteren Android Marshmallow geïnstalleerd op mijn Nexus 5. Het viel me op dat het icoontje voor Google News iets anders was (er staat een hondenpoot bij), toen ik die app startte kreeg ik dit:



Ik ben geen developer of Googler. Foutje bedankt, dev-build in de OTA gestopt?

[BikkelZ]

Een crash is alleen beter dan datacorruptie en verder is het de meest onelegante oplossing die je maar kunt bedenken.

[alienfruit]

Ik zit nu al een tijdje te klooien met mijn UICollectionViewCell's. Ik moet de profielfoto inladen en als het eenmaal geladen wil ik de UIImageView in daden. Alleen nu als je dus een beetje rond schoolt blijven de foto's ingeladen. Dat staat wel een beetje stom.

[Rutix]

BikkelZ schreef op woensdag 14 oktober 2015 @ 14:58:
Een crash is alleen beter dan datacorruptie en verder is het de meest onelegante oplossing die je maar kunt bedenken.

Sowieso is een crash nooit gewenst maar het maar loggen en doorgaan is in veel situaties ook niet gewenst omdat je de state niet meer kunt garanderen. Dan is crashen en daarna recoveren veel veiliger.

[Vincentio]

alienfruit schreef op woensdag 14 oktober 2015 @ 15:01:
Ik zit nu al een tijdje te klooien met mijn UICollectionViewCell's. Ik moet de profielfoto inladen en als het eenmaal geladen wil ik de UIImageView in daden. Alleen nu als je dus een beetje rond schoolt blijven de foto's ingeladen. Dat staat wel een beetje stom.

Zie je nu de verkeerde foto's in de cellen of gewoon niet zo mooi? In het eerste geval, altijd wat zetten in de imageview al is het maar "leeg".

[Laurens-R]

Vandaag op beurs github keycord gekregen... Ben ik nu hip?

[gekkie]

keycords .. maken ze die nog

[Mercatres]

Laurens-R schreef op woensdag 14 oktober 2015 @ 15:36:
Vandaag op beurs github keycord gekregen... Ben ik nu hip?

Ik heb een flessenopener van HipChat, dat is pas hip

[Cloud]

BikkelZ schreef op woensdag 14 oktober 2015 @ 14:58:
Een crash is alleen beter dan datacorruptie en verder is het de meest onelegante oplossing die je maar kunt bedenken.

En toch is het op de lange termijn beter voor je software. Je wilt fouten zo snel als mogelijk vinden, liefst voordat code bij de klant terechtkomt. Fail fast dus. Loggen + doorgaan kan ook maar dan moet je 200% bovenop die log zitten, ook consequent tijdens development.

En data corruption heb je al snel natuurlijk. Als je een échte exceptie alleen maar logt en gewoon doorgaat, hoe weet jij dan in welke state jouw programma verkeert? Is dat niet per definitie 'data corruptie' (state corruptie)?

Als er echt iets exceptioneels gebeurt moet je gewoon hard falen, want je weet toch niet wat je nog veilig kunt doen. En met hard falen bedoel ik niet dat je zelfs global exception handling weglaat, maar wél dat je na die exception handling je applicatie of proces afkapt. Zo kun je geheel opnieuw beginnen en garanderen dat je in een voorspelbare state terechtkomt.

[gekkie]

Cloud schreef op woensdag 14 oktober 2015 @ 15:38:
[...]
En toch is het op de lange termijn beter voor je software. Je wilt fouten zo snel als mogelijk vinden, liefst voordat code bij de klant terechtkomt. Fail fast dus. Loggen + doorgaan kan ook maar dan moet je 200% bovenop die log zitten, ook consequent tijdens development.

Maar dan zouden je (unit)tests dus alles moeten vangen ... maar dan is het ook niet onvoorspelbaar en had je het ook gewoon kunnen oplossen

[BikkelZ]

alienfruit schreef op woensdag 14 oktober 2015 @ 15:01:
Ik zit nu al een tijdje te klooien met mijn UICollectionViewCell's. Ik moet de profielfoto inladen en als het eenmaal geladen wil ik de UIImageView in daden. Alleen nu als je dus een beetje rond schoolt blijven de foto's ingeladen. Dat staat wel een beetje stom.

Je moet een Table of een Collection in iOS zo zien dat eigenlijk alleen maar de cellen bestaan die je in beeld hebt staan. Scrollt er eentje uit beeld en daarna eentje in beeld dan wordt de ZELFDE cel herbruikt. Je moet dus altijd bij het configureren van je cel hem helemaal resetten, bijvoorbeeld als je lazy loading gebruikt voor een foto dan moet je eerst de bestaande foto weggooien en dan pas gaan laden.

Wat het beste is bij lazy loading is dat je de image in je data klasse opslaat als buffer en dan eerst kijkt of je hem al hebt als je weer terug scrollt voordat je hem weer opnieuw in gaat laden. Ook is het belangrijk dat je checkt dat de callback van je lazy loading wel plaats vindt voor de juiste cel, hij kan inmiddels al herbruikt zijn.

Rutix schreef op woensdag 14 oktober 2015 @ 15:02:
[...]

Sowieso is een crash nooit gewenst maar het maar loggen en doorgaan is in veel situaties ook niet gewenst omdat je de state niet meer kunt garanderen. Dan is crashen en daarna recoveren veel veiliger.

State is natuurlijk een vorm van data. En je komt inderdaad op een bepaald punt bij bijvoorbeeld een game dat je niet verder kunt als je speler positie ineens DOUBLE_MAX, DOUBLE_MAX is geworden noch wil je dat er dan nog even gesaved kan worden, dat is waar. Maar dan nog is crashen de meest lompe manier om het te voorkomen.

[ Voor 22% gewijzigd door BikkelZ op 14-10-2015 16:22 ]

[alienfruit]

Zie je nu de verkeerde foto's in de cellen of gewoon niet zo mooi? In het eerste geval, altijd wat zetten in de imageview al is het maar "leeg".

Oh, elke keer fade hij de foto in terwijl het al in mijn NSCache is opgeslagen. Misschien alleen inladen als jet een remote download is en niet wanneer het al in de image cache staat. Een flag erbij om te vertellen of de foto uit de cache komt of geladen is van interwebs.

Wat het beste is bij lazy loading is dat je de image in je data klasse opslaat als buffer en dan eerst kijkt of je hem al hebt als je weer terug scrollt voordat je hem weer opnieuw in gaat laden. Ook is het belangrijk dat je checkt dat de callback van je lazy loading wel plaats vindt voor de juiste cel, hij kan inmiddels al herbruikt zijn.

Hmm, hoe doe je die check voor de juiste cell dan? Moet je dan de NSIndexPath ergens opslaan?

[BikkelZ]

alienfruit schreef op woensdag 14 oktober 2015 @ 16:24:
[...]


Oh, elke keer fade hij de foto in terwijl het al in mijn NSCache is opgeslagen. Misschien alleen inladen als jet een remote download is en niet wanneer het al in de image cache staat. Een flag erbij om te vertellen of de foto uit de cache komt of geladen is van interwebs.


[...]


Hmm, hoe doe je die check voor de juiste cell dan? Moet je dan de NSIndexPath ergens opslaan?

Bijvoorbeeld. Meestal komt data uit een webservice dus heb je een personId die je als een int mee kunt geven in de return block. Gebruik geen self reference in verband met crashes, altijd een weak self reference gebruiken en op null checken en terug casten of een simpele waarde zoals een int (maar je moet je image weer zetten op de cell, dus heb je self nodig).

Rommelige pseudocode:

code:

func configureCell(person: Person) {
    self.person = person // Store in cell
    let personId = person.id // Store ID
    
    avatar.image = nil // Reset of set de hele cel, bijvoorbeeld eerst bestaande plaatje weghalen
    // Check hier of deze person al een image heeft, zo ja direct zetten en afkappen

    ImageFetcher.fetchImage(person.imageId, completion: { [weak self] image
        // Eerst image cachen hier
        guard let strongSelf = self where strongSelf.person.id == personId else {
              return // Cell bestaat niet meer of is herbruikt
        }

        strongSelf.avatar.image = image
    }
}

[Alex)]

Ik heb een tijdje terug Visual Studio 2015 geïnstalleerd, en een trial van Resharper 9.2. Nou is die trial verlopen, en ik wil best gaan betalen voor R#..

Maar als ik nu een upgrade aanschaf loopt die vanaf 16 februari (einddatum van mijn vorige licentie) tot 15 februari 2016. Dat vind ik een beetje kort, vooral omdat vanaf 2 november Jetbrains' nieuwe licentiestructuur ingaat en ik dan voor hetzelfde geld een tweejarige subscription krijg.

[azerty]

Alex) schreef op woensdag 14 oktober 2015 @ 22:06:
Ik heb een tijdje terug Visual Studio 2015 geïnstalleerd, en een trial van Resharper 9.2. Nou is die trial verlopen, en ik wil best gaan betalen voor R#..

Maar als ik nu een upgrade aanschaf loopt die vanaf 16 februari (einddatum van mijn vorige licentie) tot 15 februari 2016. Dat vind ik een beetje kort, vooral omdat vanaf 2 november Jetbrains' nieuwe licentiestructuur ingaat en ik dan voor hetzelfde geld een tweejarige subscription krijg.

Dan moet je nog maar een week of 2 wachten, of de suggestie die hier niet genoemd mag worden voor een week of 2 toepassen

[F.West98]

azerty schreef op woensdag 14 oktober 2015 @ 22:15:
[...]


Dan moet je nog maar een week of 2 wachten, of de suggestie die hier niet genoemd mag worden voor een week of 2 toepassen

Windows opnieuw installeren en nog een keer een trial doen?

[azerty]

F.West98 schreef op woensdag 14 oktober 2015 @ 22:24:
[...]

Windows opnieuw installeren en nog een keer een trial doen?

Is een optie natuurlijk

[BikkelZ]

Alex) schreef op woensdag 14 oktober 2015 @ 22:06:
Ik heb een tijdje terug Visual Studio 2015 geïnstalleerd, en een trial van Resharper 9.2. Nou is die trial verlopen, en ik wil best gaan betalen voor R#..

Maar als ik nu een upgrade aanschaf loopt die vanaf 16 februari (einddatum van mijn vorige licentie) tot 15 februari 2016. Dat vind ik een beetje kort, vooral omdat vanaf 2 november Jetbrains' nieuwe licentiestructuur ingaat en ik dan voor hetzelfde geld een tweejarige subscription krijg.

Ik heb ze gemaild voor het zelfde probleem en als je het vraagt dan verlengen ze je trial voor je.

[gekkie]

zowel netjes al slim van ze

[RayNbow]

Yay voor onverwarmde kantoorkamers...

[Vincentio]

RayNbow schreef op donderdag 15 oktober 2015 @ 07:06:
Yay voor onverwarmde kantoorkamers...

Ach wees blij dat je niet hoeft te zwemmen op je kantoorkamer

[gekkie]

Niet opgewarmd van alle trappen op hobbelen dus ?

[Ryur]

gekkie schreef op donderdag 15 oktober 2015 @ 09:01:
Niet opgewarmd van alle trappen op hobbelen dus ?

Ikzelf werk op de begane grond, dus nee
Maar ik heb de airco hier weer aanstaan; heb het bijna altijd te warm!

[Creepy]

*verwarming hoger zet*

[Candanz]

het liefst refactor ik alles wat mijn collega heeft gemaakt zodat het een stuk leesbaarder is en makkelijker te hergebruiken voor toekomstige collegas. Maar ja, daar is geen tijd voor.

Hopelijk toch aan het eind van het project tijd voor regelen om tenminste goede fout afhandeling er in te bouwen in plaats van dingen lopen surpressen. Het is verdomme een API waar straks meerdere mensen mee moeten werken, dan wil je tenminste toch goede foutmeldingen en gestructueerde data terug krijgen, met functies die sense maken en geen functies zoals getShop waarmee je onder andere Alle, een aantal, 1 of geen shops kan krijgen als result......

En dan is het ook nog zo'n iemand waar je achter aan moet zitten.
Belooft ie om iets te maken gister, vraag ik hem hoe het er mee gaat. "Nog niet bezig mee geweest, maar doe ik zo wel, met een uurtje is het klaar". 5 uur later, nog niet eens begonnen.

Dat schiet toch niet op?

[gekkie]

Ryur schreef op donderdag 15 oktober 2015 @ 09:25:
[...]
Ikzelf werk op de begane grond, dus nee
Maar ik heb de airco hier weer aanstaan; heb het bijna altijd te warm!

Ah wel potentieel beneden strooms dus .. maar wel droog gehouden ?

[wackmaniac]

Blegh! Net nu ik een nieuwe iPhone heb ligt iTunes weer plat. Pfffff, sim is al over