De Devschuur Coffee Corner - Iteratie ➒

[gekkie]

Rhapsody schreef op donderdag 08 oktober 2015 @ 15:06:
[...]
Dus dan stinkt het niet alleen naar koffie, overal hoor je pruttelende machines

Achja vind het op zich wel mooi hoe mensen zich dan weer ontworstelen aan van bovenaf opgelegd wensdenken
Vervolgens een pruttelaar verbod ... transparante werkkamers zodat het ook nog te handhaven is .. die dan weer volhangen met posters en stapels pampier omdat er geen bergruimte is .. maar vooral voor de privacy .. (en de pruttelaar).

[Gamebuster]

alienfruit schreef op donderdag 08 oktober 2015 @ 15:03:
[...]


Ik ben zelf nog een beginnende Swift-er. Maar inderdaad je moet vaak as! of ! gebruiken. Hoe haal je die weg dan? Verder wat bedoel je met de [weak self] blok? Wanneer heb je dat nodig? Guards moet ik nog eens naar kijken. Nog niks over gehoord.

Verder moet ik nog verdiepen in hoe ik Core Data kan gebruiken als lokale cache voor een REST service.

https://developer.apple.c.../uid/TP40014097-CH9-ID120
CMD+F "guard"

[alienfruit]

gekkie schreef op donderdag 08 oktober 2015 @ 15:07:
Ik gok om te zorgen dat iets niet per ongeluk niet ge-garbage-collect wordt omdat er nog ergens een stray reference is. Op zich een potentiele ellende die je bij alle garbage collected languages wel tegen komt. Kan in python ook vrij gauw je applicatie laten afknallen door de OOM-killer

Aah ja, ik moet mij nog verdiepen in Instruments om op zoek te gaan naar geheugenlekken in mijn Swift-based app. Te lang niet meer meegewerkt na jaren JavaScript/ABAP. Langzaam komt het weer terug, haha.

[gekkie]

ElkeBxl schreef op donderdag 08 oktober 2015 @ 15:09:
[...]

Klopt, dat is betalen uit eigen zak. Hoeveel het hun kost weet ik niet, voor andere zaken lijken ze geld teveel te hebben. Zo zijn onze badges vervangen en hebben we er allemaal een lederen zakje bijgekregen om die badge in te steken. Nogal onnodig gezien er geen problemen waren met de badges...

Het benodidge uitvoerings/handhavingssysteem is niet zelden duurder dan hetgene waarom het ging

Achja als je baas overgaat op oploskoffie weet je ook waarom:
http://www.gewoonovergeld...-wat-kost-dat-nu-eigenli/

Maar goed op de zaak moet je daar natuurlijk nog een dik vet koffielease-ontzorgingscontract bij op tellen.

[ Voor 7% gewijzigd door gekkie op 08-10-2015 15:18 ]

[Caelorum]

BikkelZ schreef op donderdag 08 oktober 2015 @ 14:50:
[...] ik word helemaal ziek van al die overbodige ;, new, (), if (sjakie == null) { return; } op allerlei objecten die nooit maar dan ook nooit null hadden hoeven zijn, [...]

Dat ligt niet echt aan C#, maar aan de manier waarop je programmeert. Je kan er gewoon voor zorgen dat iets nooit null kan zijn.

[gekkie]

alienfruit schreef op donderdag 08 oktober 2015 @ 15:17:
[...]
Aah ja, ik moet mij nog verdiepen in Instruments om op zoek te gaan naar geheugenlekken in mijn Swift-based app. Te lang niet meer meegewerkt na jaren JavaScript/ABAP. Langzaam komt het weer terug, haha.

Wet van behoud van ellende zal hier ook wel weer van toepassing zijn .. je hoeft nu niet meer constant een beetje zelf na te denken over al je allocaties en free()'s .. maar goed daar komt voor in de plaats komt dat je nu soms heel hard moet nadenken over waar de fsck er kennelijk nog ergens een referentie hangt te bungelen.

[ZaZ]

Deze maakt het wel makkelijker tegenwoordig

code:

foo?.Bar();

[BikkelZ]

alienfruit schreef op donderdag 08 oktober 2015 @ 15:03:
[...]


Ik ben zelf nog een beginnende Swift-er. Maar inderdaad je moet vaak as! of ! gebruiken. Hoe haal je die weg dan? Verder wat bedoel je met de [weak self] blok? Wanneer heb je dat nodig? Guards moet ik nog eens naar kijken. Nog niks over gehoord.

Verder moet ik nog verdiepen in hoe ik Core Data kan gebruiken als lokale cache voor een REST service.

Bijvoorbeeld:

Swift:

class SomeViewController: UIViewController {
    @IBOutlet var exampleLabel: UILabel? // Ik vermijd altijd de weak var variant die Interface Builder gebruikt

    func example1(value: String) {
        exampleLabel?.text = value // Is exampleLabel niet gelinkt dan crasht het in ieder geval niet
    }
    
    func save() {
        guard let value = exampleLabel?.text else { // Value is geen String? maar String op deze manier
             return // Zou normaal niet moeten gebeuren maar ik laat mijn app er niet op crashen
        }

        someobject.save(value) // Save accepteert alleen maar non-nil Strings, dus geen nil-check in de body
    }
}

Voor Core Data gebruiken veel mensen Relic geloof ik Realm. Ik heb Core Data al heel lang niet meer aangeraakt.

gekkie schreef op donderdag 08 oktober 2015 @ 15:07:
[...]

Ik gok om te zorgen dat iets niet per ongeluk niet ge-garbage-collect wordt omdat er nog ergens een stray reference is. Op zich een potentiele ellende die je bij alle garbage collected languages wel tegen komt. Kan in python ook vrij gauw je applicatie laten afknallen door de OOM-killer

Nope, het heeft te maken met threads. Zo gauw je dingen in een andere thread doet kan het zijn dat bijvoorbeeld je viewcontroller inmiddels niet meer geladen is op het moment dat je callback terug komt, bijvoorbeeld omdat je user naar een ander scherm gegaan is. Op dat moment moet je checken of self nog wel bestaat.

Garbage collection is juist dit jaar afgeschaft, Swift en Objective-C doen alleen nog maar aan ARC.

Swift:

NetworkThing.request(someRequest, success: { [weak self] result in
    guard let strongSelf = self else { // self?.doSomething() kan ook als je niet unwrapt
        return // Probably gone
    }
   
    strongSelf.refresh(result)
}

Caelorum schreef op donderdag 08 oktober 2015 @ 15:21:
[...]

Dat ligt niet echt aan C#, maar aan de manier waarop je programmeert. Je kan er gewoon voor zorgen dat iets nooit null kan zijn.

In C# kan iédere referentie naar een klasse op elk moment zo'n beetje null zijn, in Swift e.a. is een klasse alleen optioneel als je hem optioneel maakt. In C# kun je wél Int? doen maar niet SomeClass? of SomeClass!. Een class reference is altijd nullable in Java en C#.

[gekkie]

Hmm ok bij ARC zit je garbage collection niet periodiek in je runtime omgeving maar wordt het semi intelligent in je applicatie zelf gecompileerd. Maar opzich loop je als ik het zo vluchtig zie nog steeds tegen ongeveer dezelfde problemen aan. Bovendien is alles default Strong ipv weak, dus heeft dan neem ik aan specifiek met je voorbeeld te maken dat je delen op een andere thread doet en de sync daar tussen (wat kennelijk geen ref oplevert in jouw geval waardoor je instance foetsie kan zijn voordat je returned ?)

[Woy]

BikkelZ schreef op donderdag 08 oktober 2015 @ 15:36:
[...]
In C# kan iédere referentie naar een klasse op elk moment zo'n beetje null zijn, in Swift e.a. is een klasse alleen optioneel als je hem optioneel maakt. In C# kun je wél Int? doen maar niet SomeClass? of SomeClass!. Een class reference is altijd nullable in Java en C#.

Maar dat kun je wel als pre-conditie stellen. Tevens kun je voor parameters met het NotNull attribute aangeven dat iets niet null mag zijn. Het is natuurlijk niet keihard afgedwongen, maar het is beter dan allemaal null checks overal in je code.

[BikkelZ]

[NonNull] is al standaard C# of gewoon een waarschuwing van ReSharper? Het zou gewoon een compile-time error moeten zijn voor mij, gooi een ! achter een class name en het is gewoon altijd gegarandeerd geen null. Vooral handig bij functies maar ook op het moment dat je via een constructor kunt garanderen dat properties altijd bestaan.

gekkie schreef op donderdag 08 oktober 2015 @ 15:49:
Hmm ok bij ARC zit je garbage collection niet periodiek in je runtime omgeving maar wordt het semi intelligent in je applicatie zelf gecompileerd. Maar opzich loop je als ik het zo vluchtig zie nog steeds tegen ongeveer dezelfde problemen aan. Bovendien is alles default Strong ipv weak, dus heeft dan neem ik aan specifiek met je voorbeeld te maken dat je delen op een andere thread doet en de sync daar tussen (wat kennelijk geen ref oplevert in jouw geval waardoor je instance foetsie kan zijn voordat je returned ?)

Het gaat er simpelweg om dat blocks niet weten dat een bepaalde referentie gedereferenced is op het moment dat ze uitgevoerd worden. Ook voorkom je er mee dat er variabelen gevangen worden in een block.

[ Voor 12% gewijzigd door BikkelZ op 08-10-2015 16:01 ]

[gekkie]

Vind het apart dat tie niet kan detecteren dat zo lang die callback nog niet fulfilled is, je instance en class variables niet gesloopt moet worden (tenzij je je callback weak hebt gemaakt .. maar standaard zou toch alles strong zijn ?) ?

[ Voor 4% gewijzigd door gekkie op 08-10-2015 16:18 ]

[farlane]

BikkelZ schreef op donderdag 08 oktober 2015 @ 16:00:
[NonNull] is al standaard C# of gewoon een waarschuwing van ReSharper? Het zou gewoon een compile-time error moeten zijn voor mij, gooi een ! achter een class name en het is gewoon altijd gegarandeerd geen null.

Dan moet je al die snoezige programmeurtjes gaan uitleggen wat het verschil is tussen een reference en een non-null reference, veel te ingewikkeld.

[BikkelZ]

gekkie schreef op donderdag 08 oktober 2015 @ 16:17:
Vind het apart dat tie niet kan detecteren dat zo lang die callback nog niet fulfilled is, je instance en class variables niet gesloopt moet worden (tenzij je je callback weak hebt gemaakt .. maar standaard zou toch alles strong zijn ?) ?

Ik weet de echte reden ook niet, maar waarschijnlijk is het nog erger dat er allerlei ViewControllers inclusief Views inclusief plaatjes en eventueel geluiden blijven rondhangen tot die callback geweest is die nooit meer komt.

Het blijft gewoon een gotcha in iOS programmeren. Verder doe ik helemaal geen reet met weak var eigenlijk, ik zag een of andere Indiase programmeur het wel eens gebruiken bij IBOutlets maar die worden onder de motorkap al standaard weak var gemaakt.

[Caelorum]

BikkelZ schreef op donderdag 08 oktober 2015 @ 15:36:
[...] In C# kan iédere referentie naar een klasse op elk moment zo'n beetje null zijn, in Swift e.a. is een klasse alleen optioneel als je hem optioneel maakt. In C# kun je wél Int? doen maar niet SomeClass? of SomeClass!. Een class reference is altijd nullable in Java en C#.

Een class reference inderdaad, maar als je iets perse niet null wilt hebben kan je het altijd nog een value type gebruiken (a la struct). Daarnaast kan je als preconditie inderdaad gewoon stellen dat een class reference niet null mag zijn. Dan kan het inderdaad nog wel, maar als iedereen die aan de code werkt met deze insteek werkt dan heb je niet null checks all over the place.

Daarmee wil ik overigens niet zeggen dat een string! operator niet handig zou zijn hoor. Altijd beter om zoiets te enforcen met de compiler, maar het niet hebben van non-nullable reference types wil niet zeggen dat je alleen maar bezig bent met niet null checken.

[ Voor 14% gewijzigd door Caelorum op 08-10-2015 17:31 ]

[farlane]

Caelorum schreef op donderdag 08 oktober 2015 @ 17:25:
Een class reference inderdaad, maar als je iets perse niet null wilt hebben kan je het altijd nog een value type gebruiken (a la struct).

Met pass by value semantics, wat je waarschijnlijk niet wilt bij een non-null reference.

[BikkelZ]

Caelorum schreef op donderdag 08 oktober 2015 @ 17:25:
[...]

Een class reference inderdaad, maar als je iets perse niet null wilt hebben kan je het altijd nog een value type gebruiken (a la struct). Daarnaast kan je als preconditie inderdaad gewoon stellen dat een class reference niet null mag zijn. Dan kan het inderdaad nog wel, maar als iedereen die aan de code werkt met deze insteek werkt dan heb je niet null checks all over the place.

Daarmee wil ik overigens niet zeggen dat een string! operator niet handig zou zijn hoor. Altijd beter om zoiets te enforcen met de compiler, maar het niet hebben van non-nullable reference types wil niet zeggen dat je alleen maar bezig bent met niet null checken.

Het gaat ook niet om de null checks all over the place, maar de momenten dat iemand denkt even geen null check nodig te hebben. Ik heb serieus alle forced unwraps uit de applicatie gegooid en niet alleen werkte alles met 1KLoC aan changes nog precies zoals voorheen, maar de applicatie liep ook significant minder vaak vast.

Er zal vast wel ergens een schermpje of een knopje zijn wat "niks doet"....maar dat is beter dan crashen.

[alienfruit]

Ja, ik gebruik weak var eigenlijk alleen voor @IBOutlet's of referenties naar delegates of view models voor UIViewControllers.

Bijv. weak var selectedProfile: Profile!

Maar misschien is deinit() en dan selectedProfile op nil zetten duidelijk... of is het helemaal niet nodig

[BikkelZ]

alienfruit schreef op donderdag 08 oktober 2015 @ 21:51:
Ja, ik gebruik weak var eigenlijk alleen voor @IBOutlet's of referenties naar delegates of view models voor UIViewControllers.

Bijv. weak var selectedProfile: Profile!

Maar misschien is deinit() en dan selectedProfile op nil zetten duidelijk... of is het helemaal niet nodig

Als je weak var selectedProfile: Profile! per ongeluk niet zet dan crasht je applicatie toch?
Ik begrijp ook niet waarom gewoon var selectedProfile: Profile? niet fatsoenlijk zou deallocaten als je ViewModel niet meer gereferred wordt door je ViewController. Maar beter nog zet je alles in je init() dan heeft je object gegarandeerd altijd alle properties.

[Scott]

BikkelZ schreef op donderdag 08 oktober 2015 @ 18:38:
[...]
Er zal vast wel ergens een schermpje of een knopje zijn wat "niks doet"....maar dat is beter dan crashen.

Dat ben ik niet (in alle gevallen) met je eens, crashen is juist handig omdat je meteen weet dat er iets fout is gegaan. Je krijgt een crashlog (als je inderdaad Fabric gebruikt), en kunt de bug meteen oplossen. Als het niet crasht kun je maanden gaan zonder dat je überhaupt door hebt dat er een probleem is waar je gebruikers tegenaan lopen.

Onze regel wat betreft outlets: als er een code path is dat een view kan verwijderen, dan maak je het een weak var met ?. Anders een strong var met !. In het eerste geval houd je niet nodeloos een view vast als die gedealloced wordt omdat je hem verwijdert. In het tweede geval heb je meteen een crash als je je outlet niet connect en hoef je niet een halfuur te zoeken naar waarom je view niet updatet.

[alienfruit]

Interessant. Ik gebruik mijn selectedProfile voor prepareForSegue-call. Dus ik ben er redelijk zeker van dat zijn beschikbaar is zolang ik prepareForSegue wel een nil-check heeft.

[OkkE]

Bye bye IE10 en lager.

End of support is coming for older versions of Internet Explorer.
Beginning January 12, 2016, only the current version of Internet Explorer available for a supported operating system will receive technical support and security updates. Microsoft recommends that customers running older versions of Internet Explorer upgrade to the most recent version, which is Internet Explorer 11 on Windows 7, Windows 8.1, and Windows 10.
Bron: https://technet.microsoft...255&MSPPError=-2147217396

[acemoo]

OkkE schreef op vrijdag 09 oktober 2015 @ 10:46:
Bye bye IE10 en lager.


[...]

Ofwel, mensen blijven zitten met een browser die niet meer geupdate word? Opzich niet zo erg denk ik, aangezien de mensen die op een oude versie zitten toch blijkbaar niet updaten.

[azerty]

br men schreef op vrijdag 09 oktober 2015 @ 10:59:
[...]

Ofwel, mensen blijven zitten met een browser die niet meer geupdate word? Opzich niet zo erg denk ik, aangezien de mensen die op een oude versie zitten toch blijkbaar niet updaten.

Maar misschien zet dat de IT afdelingen van grote bedrijven met oude versies toch eens aan het denken... Zolang er nog security updates voor uitkwamen, konden ze gerust op die versie blijven...

[Laurens-R]

azerty schreef op vrijdag 09 oktober 2015 @ 11:13:
[...]


Maar misschien zet dat de IT afdelingen van grote bedrijven met oude versies toch eens aan het denken... Zolang er nog security updates voor uitkwamen, konden ze gerust op die versie blijven...

Bij ons zijn ze inmiddels over op de laatste IE (grote enterprise)... dat is echt heerlijk bij het ontwikkelen van web apps, omdat je lekker aan de slag kan gaan met recente client side technologieën + support wat een stuk eenvoudiger word.

[Avalaxy]

Alleen weer jammer dat HTTP2 support voor IE11 alleen werkt op Windows 10.

[BikkelZ]

Scott schreef op vrijdag 09 oktober 2015 @ 06:24:
[...]

Dat ben ik niet (in alle gevallen) met je eens, crashen is juist handig omdat je meteen weet dat er iets fout is gegaan. Je krijgt een crashlog (als je inderdaad Fabric gebruikt), en kunt de bug meteen oplossen. Als het niet crasht kun je maanden gaan zonder dat je überhaupt door hebt dat er een probleem is waar je gebruikers tegenaan lopen.

Ik dacht er eerst inderdaad ook zo over, maar daar ben ik toch van af gestapt. Crashlytics laat je non-fatal issues loggen op het moment dat je in een guard let else blok terecht komt die een fatsoenlijk team wat er gewoon boven op zit net zo veel vertelt als een harde crash.

Scott schreef op vrijdag 09 oktober 2015 @ 06:24:
[...]

Onze regel wat betreft outlets: als er een code path is dat een view kan verwijderen, dan maak je het een weak var met ?. Anders een strong var met !. In het eerste geval houd je niet nodeloos een view vast als die gedealloced wordt omdat je hem verwijdert. In het tweede geval heb je meteen een crash als je je outlet niet connect en hoef je niet een halfuur te zoeken naar waarom je view niet updatet.

Over welke "ons" heb je het, je vaste werk of bij Ray Wenderlich?

In de ideale wereld wordt alles goed doorgetest ook bij kleine wijzigingen. In de echte wereld gaat de junior die nauwelijks snapt wat jouw scherm doet nog even een kleine UI bug fixen en vervangt daarbij net die ene NSLayoutConstraint die jij in uitzondering X een klein beetje aanpast in je code, maar op dat punt komt hij nooit in de code noch de tester noch valt het op in een code review dus gaat het ineens live.

Ik heb besloten forced wraps met de volgende mentaliteit te benaderen: "mocht deze variabele onverhoopt toch nil zijn, is dat dan zo erg dat de applicatie moet crashen?". Ik ben er nog geen use case voor tegen gekomen.

alienfruit schreef op vrijdag 09 oktober 2015 @ 09:24:
Interessant. Ik gebruik mijn selectedProfile voor prepareForSegue-call. Dus ik ben er redelijk zeker van dat zijn beschikbaar is zolang ik prepareForSegue wel een nil-check heeft.

Die nil-check moet je dus overal herhalen en vooral niet vergeten, terwijl hem optional maken geen zwaar wegende nadelen heeft. Je wordt er altijd compile time al braaf aan herinnerd dat je hem eerst moet checken.


Maar goed waarom Apple precies weak var ! gebruikt vind ik lastig om te achterhalen, of het nou gemak is of ook nog iets onder de motorkap.

[ Voor 14% gewijzigd door BikkelZ op 09-10-2015 13:17 ]

[gekkie]

Scott schreef op vrijdag 09 oktober 2015 @ 06:24:
[...]

Dat ben ik niet (in alle gevallen) met je eens, crashen is juist handig omdat je meteen weet dat er iets fout is gegaan. Je krijgt een crashlog (als je inderdaad Fabric gebruikt), en kunt de bug meteen oplossen. Als het niet crasht kun je maanden gaan zonder dat je überhaupt door hebt dat er een probleem is waar je gebruikers tegenaan lopen.

Ja en nee ... Linux kernel zit er ook vol mee .. BUG_ON()' s .. weet niet of de patches al gecommit zijn dat het WARN_ON()'s worden .. maar owww wat is het irritant als je machine down gaat omdat een sound drivertjes ergens iets niet kon. Eigenlijk zouden ze een BUG_ON() variant moeten hebben voor drivers die standaard tot de driver / het subsytem beperkt blijft.

[Alex)]

Laurens-R schreef op vrijdag 09 oktober 2015 @ 11:27:
[...]


Bij ons zijn ze inmiddels over op de laatste IE (grote enterprise)... dat is echt heerlijk bij het ontwikkelen van web apps, omdat je lekker aan de slag kan gaan met recente client side technologieën + support wat een stuk eenvoudiger word.

Met uitzondering van de Citrixservers, die zitten nog vrolijk op IE 9

[kwaakvaak_v2]

Zonder twijfel beledig ik weer een forse groep mensen, maar.... als je nu echt helemaal niks kunt behalve uit je nek uit zwammen. Kun je zonder problemen SEO specialist worden en daar dikke boterhammen mee verdienen. Waarom die toko's nooit in Tros Opgelicht te zien zijn, is mij ook een raadsel.

[.oisyn]

Schaamteloze copypaste uit het GGPT

[gekkie]

kwaakvaak_v2 schreef op vrijdag 09 oktober 2015 @ 15:08:
Zonder twijfel beledig ik weer een forse groep mensen, maar.... als je nu echt helemaal niks kunt behalve uit je nek uit zwammen. Kun je zonder problemen SEO specialist worden en daar dikke boterhammen mee verdienen. Waarom die toko's nooit in Tros Opgelicht te zien zijn, is mij ook een raadsel.

En totaal geen eer-gevoel hebben .. ook wel een vereiste .. maar goed dat is een kwaliteit die tegenwoordig niet bepaald schaars meer te noemen is .. dus snap opzich dat je hem weggelaten had .

Achja .. moet toch een mooi wereldbeeld zijn .. dat iedereen op nummer 1 kan staan en blijven (vaak willen ze wel zelf "meten" .. )

[acemoo]

.oisyn schreef op vrijdag 09 oktober 2015 @ 15:27:
Schaamteloze copypaste uit het GGPT

[afbeelding]

Code van de student met het comentaar van de large company lijkt in mijn ogen een goede keuze.

[alienfruit]

2015-10-09 14:48:01.661 Project[27747:466655] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x7fc842821a70 h=--& v=--& H:[Project.SwippableCardView:0x7fc842d78a70(0)]>",
"<NSLayoutConstraint:0x7fc8429784a0 H:|-(10)-[UIImageView:0x7fc842d3db60] (Names: '|':UIView:0x7fc842d3fb50 )>",
"<NSLayoutConstraint:0x7fc84296d220 H:[UIImageView:0x7fc842d3db60]-(5)-[UILabel:0x7fc842d3c6f0'Kuala Lumpur, Malaysia']>",
"<NSLayoutConstraint:0x7fc84296d270 UILabel:0x7fc842d3c6f0'Kuala Lumpur, Malaysia'.trailing == Project.ProfilePictureImageView:0x7fc842d55810.trailing + 10>",
"<NSLayoutConstraint:0x7fc84296e370 H:[Project.ProfilePictureImageView:0x7fc842d55810]-(10)-| (Names: '|':UIView:0x7fc842d3fb50 )>",
"<NSLayoutConstraint:0x7fc84296d6b0 UIView:0x7fc842d3fb50.width == Project.ActivityCardView:0x7fc842d42040.width>",
"<NSLayoutConstraint:0x7fc842d793b0 Project.ActivityCardView:0x7fc842d42040.width == Project.SwippableCardView:0x7fc842d78a70.width>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fc84296d220 H:[UIImageView:0x7fc842d3db60]-(5)-[UILabel:0x7fc842d3c6f0'Kuala Lumpur, Malaysia']>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

Stomme Autolayout constraint bullshit. Snap er nog steeds de ballen van. Hier ooit maar eens naar kijken....

[Firesphere]

br men schreef op vrijdag 09 oktober 2015 @ 15:50:
[...]

Code van de student met het comentaar van de large company lijkt in mijn ogen een goede keuze.

Huh? Gewoon de kat-versie. Zoals het hoort.

[gekkie]

Firesphere schreef op vrijdag 09 oktober 2015 @ 15:55:
[...]
Huh? Gewoon de kat-versie. Zoals het hoort.

Techno-kitties die hier op de toetsen hebben gezeten deden alles in binary of crypto .. een voorliefde voor het liggen op een CRT monitor .. en de gedachte dat je bij elk raam wel een vorm van een ruitenwisser zou kunnen gebruiken.

[Woy]

br men schreef op vrijdag 09 oktober 2015 @ 15:50:
[...]

Code van de student met het comentaar van de large company lijkt in mijn ogen een goede keuze.

Gewoon een eenvoudige iteratieve implementatie natuurlijk.

[acemoo]

Woy schreef op vrijdag 09 oktober 2015 @ 16:00:
[...]

Gewoon een eenvoudige iteratieve implementatie natuurlijk.

Sorry, ik bedoelde niet dat het een echte goede code was, maar dat het van deze voorbeelden de beste lijkt.
recursief fibonacci is natuurlijk gewoon stom langzaam.

[hellum]

http://www.nu.nl/wetensch...-dementietest-honden.html

[Firesphere]

gekkie schreef op vrijdag 09 oktober 2015 @ 15:59:
[...]

Techno-kitties die hier op de toetsen hebben gezeten deden alles in binary of crypto .. een voorliefde voor het liggen op een CRT monitor .. en de gedachte dat je bij elk raam wel een vorm van een ruitenwisser zou kunnen gebruiken.

[BikkelZ]

alienfruit schreef op vrijdag 09 oktober 2015 @ 15:52:
[...]


Stomme Autolayout constraint bullshit. Snap er nog steeds de ballen van. Hier ooit maar eens naar kijken....

Autolayouts is vrij lastig om in te komen. Probeer het bij Interface Builder te houden in het begin, geen coded constraints. Scrollviews en tableviewcells zijn vaker lastig. Varieer eens tussen verschillende sizes in Interface Builder om te kijken of er niks rood wordt (ik zet hem altijd standaard op 3,5" iPhone)

[alienfruit]

Ja, inderdaad lastig. Ik heb ook alleen constraints in de Interface Builder alleen dan zegt van alles en nog wat. Als ik dan de missing constraints toevoeg is alles over hoop

Jammer dat je niet iOS 9 targetten en lekker UIStackView kan gebruiken.

[Scott]

BikkelZ schreef op vrijdag 09 oktober 2015 @ 12:58:
[...]


Ik dacht er eerst inderdaad ook zo over, maar daar ben ik toch van af gestapt. Crashlytics laat je non-fatal issues loggen op het moment dat je in een guard let else blok terecht komt die een fatsoenlijk team wat er gewoon boven op zit net zo veel vertelt als een harde crash.


[...]


Over welke "ons" heb je het, je vaste werk of bij Ray Wenderlich?

Mijn vaste werk.

In de ideale wereld wordt alles goed doorgetest ook bij kleine wijzigingen. In de echte wereld gaat de junior die nauwelijks snapt wat jouw scherm doet nog even een kleine UI bug fixen en vervangt daarbij net die ene NSLayoutConstraint die jij in uitzondering X een klein beetje aanpast in je code, maar op dat punt komt hij nooit in de code noch de tester noch valt het op in een code review dus gaat het ineens live.

Ik heb besloten forced wraps met de volgende mentaliteit te benaderen: "mocht deze variabele onverhoopt toch nil zijn, is dat dan zo erg dat de applicatie moet crashen?". Ik ben er nog geen use case voor tegen gekomen.

Wij testen dit soort dingen redelijk intensief:

• Eerst als een nieuwe feature voor het eerst geschreven is
• Dan als die feature in master gemerged wordt
• Een "smoke"- en integratietest elke week als we een release doen
• Tegelijkertijd met release testing sturen we een beta uit naar zo'n 1000 (binnenkort 2000+) power users

We zien zelden crashes in productie, en als dat gebeurt is het meestal iets binnen Apple's frameworks. Maar, ik snap je punt. We hebben ook geen juniors en veel code reviews worden door bijna iedereen in het team wel bekeken, dus de kans dat iemand iets aanpast dat ongezien dingen breekt is klein.

[...]


Die nil-check moet je dus overal herhalen en vooral niet vergeten, terwijl hem optional maken geen zwaar wegende nadelen heeft. Je wordt er altijd compile time al braaf aan herinnerd dat je hem eerst moet checken.

Ik vind het feit dat al je views nu optional zijn zwaarwegend. Als je nu waardes uit wil lezen moet je alles eerst gaan unwrappen, alleen maar omdat een view dat je weet dat er altijd is, toch optional is (nogmaals, views waarvan je dat niet weet verdienen wel optional te zijn).

Maar goed waarom Apple precies weak var ! gebruikt vind ik lastig om te achterhalen, of het nou gemak is of ook nog iets onder de motorkap.

BikkelZ schreef op vrijdag 09 oktober 2015 @ 17:41:
[...]


Autolayouts is vrij lastig om in te komen. Probeer het bij Interface Builder te houden in het begin, geen coded constraints. Scrollviews en tableviewcells zijn vaker lastig. Varieer eens tussen verschillende sizes in Interface Builder om te kijken of er niks rood wordt (ik zet hem altijd standaard op 3,5" iPhone)

Over het algemeen is het maken van constraints met NSLayoutConstraint waardeloos, maar ik vond het in het begin wel echt helpen het te begrijpen. Je leest namelijk precies wat je doet ("constraint with item X's top, equal to item Y's bottom"). Als je de basis eenmaal doorhebt overstappen op IB en de NSLayoutConstraint methods vergeten.

[ Voor 13% gewijzigd door Scott op 09-10-2015 20:18 ]

[BikkelZ]

Scott schreef op vrijdag 09 oktober 2015 @ 20:15:
[...]

Wij testen dit soort dingen redelijk intensief:

• Eerst als een nieuwe feature voor het eerst geschreven is
• Dan als die feature in master gemerged wordt
• Een "smoke"- en integratietest elke week als we een release doen
• Tegelijkertijd met release testing sturen we een beta uit naar zo'n 1000 (binnenkort 2000+) power users

We zien zelden crashes in productie, en als dat gebeurt is het meestal iets binnen Apple's frameworks. Maar, ik snap je punt. We hebben ook geen juniors en veel code reviews worden door bijna iedereen in het team wel bekeken, dus de kans dat iemand iets aanpast dat ongezien dingen breekt is klein.

Er gaat uiteindelijk niks boven werken met goede programmeurs en een goed nageleefde standaard.

Scott schreef op vrijdag 09 oktober 2015 @ 20:15:
[...]

Ik vind het feit dat al je views nu optional zijn zwaarwegend. Als je nu waardes uit wil lezen moet je alles eerst gaan unwrappen, alleen maar omdat een view dat je weet dat er altijd is, toch optional is (nogmaals, views waarvan je dat niet weet verdienen wel optional te zijn).

Ik kan het me voorlopig nog niet veroorloven niet defensief te coden. Ik mag vandaag nog acht uur doorcrunchen en dan gaat het de App Store in, of het nou goed of bijna goed is. No way dat ik zit te wachten op een applicatie die er uit klapt alleen omdat de 23:43 merge toevallig net een IBOutlet verneukte.

Scott schreef op vrijdag 09 oktober 2015 @ 20:15:
[...]

Over het algemeen is het maken van constraints met NSLayoutConstraint waardeloos, maar ik vond het in het begin wel echt helpen het te begrijpen. Je leest namelijk precies wat je doet ("constraint with item X's top, equal to item Y's bottom"). Als je de basis eenmaal doorhebt overstappen op IB en de NSLayoutConstraint methods vergeten.

Beter werk je met zoiets als Cartography dan is het voor het oog in ieder geval wat makkelijker te verwerken.

[ Voor 5% gewijzigd door BikkelZ op 09-10-2015 21:32 ]

[dcm360]

En toen had ik ineens een ander ORM onder mijn applicatie zitten...

Volgens mij had ik al een keer een beetje frustratie geuit over de nieuwe versie van Slick, en na een paar dagen aan moeite in de upgrade gestoken te hebben had ik er vandaag geen zin meer in. In ongeveer een uur of 2 heb ik Slick vervangen door Squeryl, en het werkt gewoon. Nu zit ik met best een berg frustratie over alle tijd die ik in Slick gestoken heb, want diezelfde applicatie heb ik twee jaar terug met ruim meer benodigde tijd dan een paar uur overgezet van Squeryl naar Slick.

[Firesphere]

Hey, ik was onbekend met Squeryl, ziet er best tof uit, hoewel de belofte's van wat het kan enigsinds hol zijn, omdat niet alles automatisch gaat...
Maar dat heeft elk JORM wel geloof ik.

[ Voor 11% gewijzigd door Firesphere op 11-10-2015 02:03 ]

[F.West98]

Altijd leuk... One-to-many aanpassen naar many-to-many. Nu al het hele weekend bezig alle verwijzingen en usages aan te passen

[Alex)]

Ha, zo'n situatie had ik ook ooit eens bijna. Gelukkig was ik de opdrachtgever te slim af.

Klant: "Alex, kun je item X toevoegen aan het formulier? Hoeft er maar eentje te zijn"
Ik: "Zeker weten dat het er maar één hoeft te zijn?"
Klant: "100% zeker"
* Alex) bouwt een N:N-relatie en een UI die maar één element toont
Klant, 2 minuten nadat het klaar is om te testen: "Err, zouden het toch meerdere X'en kunnen zijn?"
* Alex) gooit een boolean om in web.config
Klant:

[ Voor 5% gewijzigd door Alex) op 11-10-2015 16:03 ]

[Firesphere]

F.West98 schreef op zondag 11 oktober 2015 @ 02:04:
Altijd leuk... One-to-many aanpassen naar many-to-many. Nu al het hele weekend bezig alle verwijzingen en usages aan te passen

Zo complex is dat toch niet?, kwestie van een migration bouwen en je ORM aanpassen.

Alex) schreef op zondag 11 oktober 2015 @ 16:02:
Ha, zo'n situatie had ik ook ooit eens bijna. Gelukkig was ik de opdrachtgever te slim af.

Klant: "Alex, kun je item X toevoegen aan het formulier? Hoeft er maar eentje te zijn"
Ik: "Zeker weten dat het er maar één hoeft te zijn?"
Klant: "100% zeker"
* Alex) bouwt een N:N-relatie en een UI die maar één element toont
Klant, 2 minuten nadat het klaar is om te testen: "Err, zouden het toch meerdere X'en kunnen zijn?"
* Alex) gooit een boolean om in web.config
Klant:

Hoe makkelijk het ook kan zijn, ik had hier echt geld voor gevraagd en gezegd dat het me een halve dag zou kosten. Als je specs verandert, verandert ook de prijs.

[F.West98]

Firesphere schreef op zondag 11 oktober 2015 @ 16:04:
[...]

Zo complex is dat toch niet?, kwestie van een migration bouwen en je ORM aanpassen.

En alle usages aanpassen. DBModel wordt omgezet in een APIModel, daar ook omzetten, de input moet meerdere ondersteunen, ik moet op alle plekken waar er iets mee gedaan wordt (er op geselecteerd wordt bijvoorbeeld) aanpassen naar of de list het bevat en niet of het equals is enzo.. En ondertussen nog andere bugs en dingetjes tegenkomen. En hele weekend = hele dag gisteravond dus het viel enigszins mee

[Firesphere]

F.West98 schreef op zondag 11 oktober 2015 @ 16:15:
[...]

En alle usages aanpassen. DBModel wordt omgezet in een APIModel, daar ook omzetten, de input moet meerdere ondersteunen, ik moet op alle plekken waar er iets mee gedaan wordt (er op geselecteerd wordt bijvoorbeeld) aanpassen naar of de list het bevat en niet of het equals is enzo.. En ondertussen nog andere bugs en dingetjes tegenkomen. En hele weekend = hele dag gisteravond dus het viel enigszins mee

In welk kutframework is dat, dat relations overal geupdated moeten worden, in plaats van dezelfde methods kunnen blijven gebruiken voor een updated record?

[F.West98]

Firesphere schreef op zondag 11 oktober 2015 @ 16:18:
[...]

In welk kutframework is dat, dat relations overal geupdated moeten worden, in plaats van dezelfde methods kunnen blijven gebruiken voor een updated record?

Entity Framework?
In het model hoef ik maar één ding bij te werken.
Maar daarna moest ik op alle plekken dat die property geaccessed werd dus zorgen dat het daar goed ging. Dingen als

C#:

db.Foo.Where(s => s.bar.name == someName);

Moeten nu dit zijn

C#:

db.Foo.Where(s => s.bar.Any(a => a.name == someName));

En setters moeten nu een list.add worden, API-input en output moet worden aangepast (API zelf moet niet gewijzigd worden dus ik moet bij output een string.Join doen en bij input een split, en ipv een enkele select om juiste bar te krijgen nu een foreach/.select om alle bars te krijgen en die in een list te stoppen, enz enz enz.

[BikkelZ]

Lijkt mij niet te voorkomen dat je dan aan de slag kan overal waar de applicatie 1 in plaats van n objecten verwacht.

[incaz]

Ik voel een antipattern aankomen waar je gewoon alles een n-n-relation maakt. (Een soort variant op db in een db, nu tabellen met slechts 2 kolommen: of een koppeltabel, of een eigenschap. Futureproof forever!)

Maar op sommige plekken voel je het gewoon al aankomen inderdaad, en dan is het wel zo handig om het maar gewoon wel te doen. n-to-n limiteren op 1 is stukken makkelijker dan alles ombouwen als het al diep in je applicatie zit.

[F.West98]

Ik ging er in dit geval van uit dat het echt 1-n was maarja, assumptions

[Firesphere]

TMOAF

[Alex)]

Firesphere schreef op zondag 11 oktober 2015 @ 16:04:
[...]

Hoe makkelijk het ook kan zijn, ik had hier echt geld voor gevraagd en gezegd dat het me een halve dag zou kosten. Als je specs verandert, verandert ook de prijs.

Ik bouw niet alles "futureproof", maar ik had al zo'n voorgevoel dat het verzoek ging komen en ik had (vooraf) écht geen zin om na een dag al wijzigingen te mogen gaan maken in iets wat ik nog geen dag eerder had opgeleverd.

Ik ben gewoon aartslui en zit liever een uurtje uit het raam te kijken*.

edit: En de reactie van de klant was het waard - het heeft me ook een goede projectbeoordeling opgeleverd ("Alex denkt met me mee en is me herhaaldelijk zelfs te slim af geweest").


* De klant had een kantoor op de Zuidas, met uitzicht op het spoor en de snelweg. Dat was echt een geweldige lokatie.

[ Voor 24% gewijzigd door Alex) op 11-10-2015 22:09 ]

[Ryur]

Alex) schreef op zondag 11 oktober 2015 @ 21:23:
[...]
* De klant had een kantoor op de Zuidas, met uitzicht op het spoor en de snelweg. Dat was echt een geweldige lokatie.

Ik kijk in mijn kantoor uit op een MBO school (het ROC in Hengelo) & daarvan de bushalte.
Loopt ook wel wat leuks rond

Het leuke is ook: je kan niet van buiten naar binnen kijken, dus wij kunnen gewoon kijken zonder schuld

[GateKeaper]

Ryur schreef op zondag 11 oktober 2015 @ 21:41:
[...]
Het leuke is ook: je kan niet van buiten naar binnen kijken, dus wij kunnen gewoon kijken zonder schuld

Volgens mij maakt dat het juist meer gluren dan kijken. Vies mannetje .

[Geerrrt]

GeertJam schreef op donderdag 01 oktober 2015 @ 15:34:
[...]


Daar gaan we weer...
[...]

De manier waarop het wachtwoord wordt verstuurd is inderdaad niet geheel veilig. De reden dat wij gebruikers vragen een account aan te maken is niet omdat het gaat om vertrouwelijke gegevens, maar zodat wij iedereen kunnen benaderen als er een wijziging in de XML is. Ook met een wachtwoord van iemand anders kunnen gebruikers niet bij persoonlijke of andere kwetsbare gegevens komen.

[ Voor 11% gewijzigd door Geerrrt op 12-10-2015 12:15 ]

[azerty]

GeertJam schreef op maandag 12 oktober 2015 @ 12:14:
[...]


[...]

Veiligheid (zelfs maar de basis / best practices) is blijkbaar absoluut niet van belang... Hoe veilig is hun "xml"?

[incaz]

Doe dan uberhaupt geen password. Er is genoeg mailinglist-software beschikbaar die dat keurig regelt.

[Skyaero]

Ach ja, het kan altijd erger

https://twitter.com/iMHLv2/status/652224896471318528

[ElkeBxl]

Skyaero schreef op maandag 12 oktober 2015 @ 13:28:
Ach ja, het kan altijd erger

https://twitter.com/iMHLv2/status/652224896471318528

Hey, het is tenminste niet plain-text

[gekkie]

ElkeBxl schreef op maandag 12 oktober 2015 @ 14:09:
[...]

Hey, het is tenminste niet plain-text

Hij heeft Hasj gebruikt

[Candanz]

gekkie schreef op maandag 12 oktober 2015 @ 14:56:
[...]

Hij heeft Hasj gebruikt

Niet eens zout op gedaan.
Wat slecht toch.

[Alex)]

Deze twee knopjes zitten veel te dicht bij elkaar:



De linker geeft je een paar gruwelijk irritante dialoogvensters waar je doorheen moet lopen om een bestand aan TFS toe te voegen. De rechter zet zonder blikken of blozen een delete klaar.

[incaz]

Alex) schreef op maandag 12 oktober 2015 @ 17:18:
De linker geeft je een paar gruwelijk irritante dialoogvensters waar je doorheen moet lopen om een bestand aan TFS toe te voegen. De rechter zet zonder blikken of blozen een delete klaar.

De simpele oplossing is om ze helemaal niet meer te gebruiken?

(Maar ja, ik zie het probleem. Op mijn laptop zijn de F-toetsen standaard gemapt naar functies zoals geluid harder / zachter etc. Leuk. Maar ze hadden de F4 naar 'venster sluiten' gedaan terwijl F5 refresh is. )

[Alex)]

incaz schreef op maandag 12 oktober 2015 @ 17:26:
[...]


De simpele oplossing is om ze helemaal niet meer te gebruiken?

Tsja, als je een bestand toevoegt buiten VS om zul je 'm toch wijs moeten maken dat het bestand wél in source control hoort.

(Maar ja, ik zie het probleem. Op mijn laptop zijn de F-toetsen standaard gemapt naar functies zoals geluid harder / zachter etc. Leuk. Maar ze hadden de F4 naar 'venster sluiten' gedaan terwijl F5 refresh is. )

Oeh, die is nasty

Ik had vroeger een toetsenbord met een powerbutton helemaal rechtsbovenin. Hartstikke leuk, maar dat ding zat dus gemapt naar één of ander commando dat Windows echt per direct afsluit...

[ Voor 14% gewijzigd door Alex) op 12-10-2015 17:29 ]

[.oisyn]

[gekkie]

Mjah je bent ook meestal zelf de Cock .. (meestal werken je CSI spulletjes ook maar matig).

[F.West98]

.oisyn schreef op vrijdag 09 oktober 2015 @ 15:27:
Schaamteloze copypaste uit het GGPT

[afbeelding]

"Code from a programming book"

C:

int fibmem[47]; // 46 is the biggest Fibonacci number to fit in a 32-bit integer

int fibonacci(int n) {
    if((n == 0) || (n == 1)) {
        return n;
    }
    if(fibmem[n] == 0) {
        fibmem[n] = fibonacci(n-2) + fibonacci(n-1);
    }
    return fibmem[n];
}

Onder de noemer "dynamic programming"

[Soultaker]

Als we die logica doortrekken:

C:

int fibonacci(int n) {
  static int fib[47] = {
              0,         1,         1,         2,          3,          5,
              8,        13,        21,        34,         55,         89,
            144,       233,       377,       610,        987,       1597,
           2584,      4181,     6765,      10946,      17711,      28657,
          46368,     75025,    121393,    196418,     317811,     514229,
         832040,   1346269,   2178309,   3524578,    5702887,    9227465,
       14930352,  24157817,  39088169,  63245986,   102334155, 165580141,
      267914296, 433494437, 701408733, 1134903170, 1836311903};
  return fib[n];
}

[dcm360]

Maar dat werkt wel, in tegenstelling tot de code van F.West98.

[.Gertjan.]

BikkelZ schreef op donderdag 08 oktober 2015 @ 15:36:
In C# kan iédere referentie naar een klasse op elk moment zo'n beetje null zijn, in Swift e.a. is een klasse alleen optioneel als je hem optioneel maakt. In C# kun je wél Int? doen maar niet SomeClass? of SomeClass!. Een class reference is altijd nullable in Java en C#.

Het heeft zijn voor en nadelen om het op die manier op te lossen.

Ik ben bij die "default/fail safe" oplossingen altijd bang voor een situatie waarin iets naar een default/non-crash terugvalt, want niet iedereen is op de hoogte van wat de default waarde is (bv in .NET is de default van int -> 0, int? -> null). Op zich heeft het hebben van null ook voordelen, ik weet nog wel dat in de oude .net versies geen nullable was voor valuetypes en daar miste ik hem toch echt wel (zeker als je DB wel een null toestond), je viel dan vaak terug op een vlag PropertySpecified/PropertySet. Null is een goede waarde voor: "not specified".

In de nieuwe compiler heeft men voor de "overbodige" null checks gelukkig een trucje toegevoegd waarmee je hem kan shorthanden (gelukkig ook toe te passen in .Net < 4.6, zolang je maar de nieuwe compiler gebruikt, het is namelijk een compiler trucje en resulteert in prima code in oudere CLI-assembly versies):

C#:

var xVal = MyObject?.MyProperty?.MySecondProperty;

Als hier een van de items in de tree null is, wordt xVal ook null. Dat scheelt je een hoop if's en maffe checks. Dat is toch wel een van de mooiere toevoegingen in de nieuwe compiler

[Candanz]

PDO loopt raar te doen.

code:

PDOStatement Object ( [queryString] => SELECT S.*, (SELECT COUNT(id) FROM shop WHERE parent = S.id) AS num_children FROM shop S WHERE status = :status AND parent IS NULL ORDER BY id ASC LIMIT :limit, :size ) 
Array ( [status] => Y [limit] => 5 [size] => 5 )

Deze word gewoon uitgevoerd.

code:

PDOStatement Object ( [queryString] => SELECT S.*, (SELECT COUNT(id) FROM shop WHERE parent = S.id) AS num_children FROM shop S WHERE status = :status AND parent IS NULL ORDER BY id ASC LIMIT :limit, :size ) 
Array ( [status] => Y [limit] => 0 [size] => 5 )

Deze niet.

Komt niet eens door naar de database.

En toen kreeg ik een ingeving om ze maar eens te intvallen, wat gewerkt heeft. Terwijl ze gewoon al naar int gecast zijn van te voren. PHP en types, gaan niet goed samen.

[ Voor 11% gewijzigd door Candanz op 13-10-2015 10:42 ]

[EddoH]

Candanz schreef op dinsdag 13 oktober 2015 @ 10:30:
PDO loopt raar te doen.

code:

PDOStatement Object ( [queryString] => SELECT S.*, (SELECT COUNT(id) FROM shop WHERE parent = S.id) AS num_children FROM shop S WHERE status = :status AND parent IS NULL ORDER BY id ASC LIMIT :limit, :size ) 
Array ( [status] => Y [limit] => 5 [size] => 5 )

Deze word gewoon uitgevoerd.

code:

PDOStatement Object ( [queryString] => SELECT S.*, (SELECT COUNT(id) FROM shop WHERE parent = S.id) AS num_children FROM shop S WHERE status = :status AND parent IS NULL ORDER BY id ASC LIMIT :limit, :size ) 
Array ( [status] => Y [limit] => 0 [size] => 5 )

Deze niet.

Komt niet eens door naar de database.

Expliciet binden als PARAM_INT?

[Alex)]

Ik heb net dit mailtje ontvangen in mijn secundaire inbox (een gmail-account dat de boel doorstuurt naar m'n primaire mailbox), en ik weet even niet wat ik ermee moet...

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Als ik dit door Google Translate haal zou het gaan om een vooruitbetaling voor een huwelijksakte? Ik ga helemaal niet trouwen, en al helemaal niet in Duitsland

Het lijkt allemaal wel te kloppen: Hemmoor is een bestaand Duits plaatsje (nabij Cuxhaven), de afzender werkt daadwerkelijk voor de gemeente bij de betroffen afdeling, er zit geen afwijkende Reply-To-header op het mailtje en de headers lijken ook allemaal te kloppen. Ik zie er tenminste geen Russische of Chinese IP-adressen in voorkomen.

Spam/oplichting (en kan ik het negeren?), of is er meer aan de hand...?

[Candanz]

EddoH schreef op dinsdag 13 oktober 2015 @ 10:43:
[...]


Expliciet binden als PARAM_INT?

Dat deed ik ook al.

code:

if (count($array) > 0) {
            foreach ($array as $key => $value) {
                if (is_numeric($value)) {
                    $stmt->bindValue("$key", $value, PDO::PARAM_INT);
                } else {
                    $stmt->bindValue("$key", $value);
                }
            }
        }

0 word gewoon gezien als numeric, al getest. Maar anyway, intval helpt.

[incaz]

dcm360 schreef op dinsdag 13 oktober 2015 @ 00:24:
Maar dat werkt wel, in tegenstelling tot de code van F.West98.

afgezien van de n+1 die een n-1 moet zijn uiteraard, wat zou er misgaan bij die van FWest? (Als je braaf een n kiest [0, 46] tenminste? Maar dat wordt in de meeste versies niet afgevangen.)

[HuHu]

F.West98 schreef op maandag 12 oktober 2015 @ 18:39:
[...]

"Code from a programming book"

C:

int fibmem[47]; // 46 is the biggest Fibonacci number to fit in a 32-bit integer

int fibonacci(int n) {
    if((n == 0) || (n == 1)) {
        return n;
    }
    if(fibmem[n] == 0) {
        fibmem[n] = fibonacci(n-2) + fibonacci(n+1);
    }
    return fibmem[n];
}

Onder de noemer "dynamic programming"

Ik mag hopen dat dit: fibonacci(n-2) + fibonacci(n+1); , niet uit een boek komt.

[Verwijderd]

Candanz schreef op dinsdag 13 oktober 2015 @ 10:44:
[...]

Dat deed ik ook al.

code:

if (count($array) > 0) {
            foreach ($array as $key => $value) {
                if (is_numeric($value)) {
                    $stmt->bindValue("$key", $value, PDO::PARAM_INT);
                } else {
                    $stmt->bindValue("$key", $value);
                }
            }
        }

0 word gewoon gezien als numeric, al getest. Maar anyway, intval helpt.

Volgens documentatie moet je zo binden:

PHP:

$sth->bindValue(':calories', $calories, PDO::PARAM_INT);

Dus mét ":". Geen idee of dat uitmaakt. Wel raar dat intval het oplost...

[Candanz]

Het hele rare is dat ik dus een generieke database class gebruik die mijn queries PDO opbouwt en door stuurt, en het op 1 pagina wel gewoon goed gaat, en op een andere weer niet, met precies de zelfde values qua limit, ik het stukje letterlijk overgekopieerd, en werkte het niet. Maar werkte nog steeds wel op de originele pagina. Beetje raar, maar het werkt. Yay.

En ik bind nergens met ':' en het werkt gewoon?

[ Voor 6% gewijzigd door Candanz op 13-10-2015 11:10 ]

[Jegorex]

Alex) schreef op dinsdag 13 oktober 2015 @ 10:43:
Ik heb net dit mailtje ontvangen in mijn secundaire inbox (een gmail-account dat de boel doorstuurt naar m'n primaire mailbox), en ik weet even niet wat ik ermee moet...

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Als ik dit door Google Translate haal zou het gaan om een vooruitbetaling voor een huwelijksakte? Ik ga helemaal niet trouwen, en al helemaal niet in Duitsland

Het lijkt allemaal wel te kloppen: Hemmoor is een bestaand Duits plaatsje (nabij Cuxhaven), de afzender werkt daadwerkelijk voor de gemeente bij de betroffen afdeling, er zit geen afwijkende Reply-To-header op het mailtje en de headers lijken ook allemaal te kloppen. Ik zie er tenminste geen Russische of Chinese IP-adressen in voorkomen.

Spam/oplichting (en kan ik het negeren?), of is er meer aan de hand...?

Kan natuurlijk ook gewoon zijn dat hij het naar een verkeerd email adres gestuurd heeft.
Je kunt een email sturen dat hij waarschijnlijk een verkeerd adres gebruikt heeft, of gewoon negeren en hopen dat de mensen waar de mail voor bedoelt is nog kunnen trouwen.

[Alex)]

Jegorex schreef op dinsdag 13 oktober 2015 @ 11:24:
[...]

Kan natuurlijk ook gewoon zijn dat hij het naar een verkeerd email adres gestuurd heeft.
Je kunt een email sturen dat hij waarschijnlijk een verkeerd adres gebruikt heeft, of gewoon negeren en hopen dat de mensen waar de mail voor bedoelt is nog kunnen trouwen.

Mijn (volgens mij typisch Nederlandse) achternaam stond wel genoemd in het mailtje, dat is het vreemde.

Ik heb een mailtje teruggestuurd (in het Engels) dat ik - volgens Google Translate - begrijp dat het gaat om een voorschot voor een huwelijksakte, en dat me dat niet lijkt te kloppen omdat ik niet ga trouwen.

[EddoH]

Pfff, ik wordt gek van die Shuffle functie van Spotify!
Elke keer als ik hem uitzet staat hij een volgende keer op magische wijze weer aan. Is er nou geen manier om hem parmanent uit te zetten??

Sowieso is de Spotify app verschrikkelijk, maar die shuffle functie is werkelijk absurd. En daar betaal je dan nog 10,- per maand voor..

[RayNbow]

Goed, gisteren/vandaag erachter gekomen dat het niet slim is om een div met een YouTube iframe erin te detachen en te reinserten...

[Otherside1982]

Alex) schreef op dinsdag 13 oktober 2015 @ 11:30:
[...]


Mijn (volgens mij typisch Nederlandse) achternaam stond wel genoemd in het mailtje, dat is het vreemde.

Ik heb een mailtje teruggestuurd (in het Engels) dat ik - volgens Google Translate - begrijp dat het gaat om een voorschot voor een huwelijksakte, en dat me dat niet lijkt te kloppen omdat ik niet ga trouwen.

Ik kreeg laatst een email ivm een aanvraag tot verzekering voor iemand met dezelde voornaam. Ik heb ze maar terug gemaild dat ik die persoon niet ben, maar dat zijn emailadres wellicht lijkt op het mijne. Komt jouw achternaam ook voor in het emailadres?

[Alex)]

Otherside1982 schreef op dinsdag 13 oktober 2015 @ 11:44:
[...]

Komt jouw achternaam ook voor in het emailadres?

Ja, het mailtje kwam binnen op "alex<achternaam>@gmail.com".

Ik weet dat er in Nederland nog iemand rondloopt met mijn naam, verder kan ik (op Facebook en Google tenminste) geen naamsgenoten vinden. Die andere Alex komt ergens uit de randstad, het lijkt me niet dat die juist in de buurt van Hamburg zou gaan trouwen.

Ik vind het maar vreemd

[F.West98]

dcm360 schreef op dinsdag 13 oktober 2015 @ 00:24:
Maar dat werkt wel, in tegenstelling tot de code van F.West98.

[TheNephilim]

Klopt volgens mij, zie ook 'This picture...': http://thetomorrowlab.com...s-hate-being-interrupted/

[BikkelZ]

.Gertjan. schreef op dinsdag 13 oktober 2015 @ 08:31:
[...]


Het heeft zijn voor en nadelen om het op die manier op te lossen.

Ik ben bij die "default/fail safe" oplossingen altijd bang voor een situatie waarin iets naar een default/non-crash terugvalt, want niet iedereen is op de hoogte van wat de default waarde is (bv in .NET is de default van int -> 0, int? -> null). Op zich heeft het hebben van null ook voordelen, ik weet nog wel dat in de oude .net versies geen nullable was voor valuetypes en daar miste ik hem toch echt wel (zeker als je DB wel een null toestond), je viel dan vaak terug op een vlag PropertySpecified/PropertySet. Null is een goede waarde voor: "not specified".

Het gaat er om dat áls iets null kán zijn, je er ook van uit moet gaan dat het zo is en op het moment dat je geen nullable waarde verwacht het ook geen null kan zijn. Als ik een waarde heb die meteen gezet wordt dan hoeft hij niet nullable te zijn:

C#:

var thing = new Thing() // toch is "var" een nullable instance van Thing!

.Gertjan. schreef op dinsdag 13 oktober 2015 @ 08:31:
[...]

In de nieuwe compiler heeft men voor de "overbodige" null checks gelukkig een trucje toegevoegd waarmee je hem kan shorthanden (gelukkig ook toe te passen in .Net < 4.6, zolang je maar de nieuwe compiler gebruikt, het is namelijk een compiler trucje en resulteert in prima code in oudere CLI-assembly versies):

C#:

var xVal = MyObject?.MyProperty?.MySecondProperty;

Als hier een van de items in de tree null is, wordt xVal ook null. Dat scheelt je een hoop if's en maffe checks. Dat is toch wel een van de mooiere toevoegingen in de nieuwe compiler

Ja dat is alvast een goed begin, maar ik wil méér

[BikkelZ]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[EddoH]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 14:24:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[.Gertjan.]

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


Het gaat er om dat áls iets null kán zijn, je er ook van uit moet gaan dat het zo is en op het moment dat je geen nullable waarde verwacht het ook geen null kan zijn. Als ik een waarde heb die meteen gezet wordt dan hoeft hij niet nullable te zijn:

C#:

var thing = new Thing() // toch is "var" een nullable instance van Thing!

Op dit moment is Thing inderdaad niet logischerwijs als null te verwachten op korte termijn, echter kan je in hetzelfde code-block alsnog besluiten om thing naar null te drukken, wat op zich niet eens geheel onverwachts is (om hem bijvoorbeeld aan de garbage collector over te laten, I know dat dat niet de meest sympathieke oplossing is, maar het kan).

Een parameter kan inderdaad een null zijn (iemand kan een null erin mikken) en moet gecheckt worden (of met attributes worden afgevangen), maar zodra je zelf een variabele maakt en data toewijst is de kans klein dat buiten je eigen bereik een null terecht komt waar je hem niet verwacht. Uiteraard wordt het lastiger naarmate je objecten genest raken (dan kan een andere functie je inner-objecten naar null setten) of naarmate de scope ruimer wordt (class objects), maar in principe kan bij een zelf gemaakte (lokale) variabele nooit zomaar naar null worden gewezen zonder dat je zelf een toewijzing doet middels een thing = [....] .

Ja dat is alvast een goed begin, maar ik wil méér

Misschien toch je eigen compiler knutselen

[BikkelZ]

EddoH schreef op dinsdag 13 oktober 2015 @ 14:35:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[alienfruit]

Het leuke van Android vind ik wel de compatibility libraries zodat je toch nog nieuwe UI API kan gebruiken in oudere versies van Android. Zie ik nooit bij iOS gebeuren...

[EddoH]

BikkelZ schreef op dinsdag 13 oktober 2015 @ 14:44:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[BikkelZ]

alienfruit schreef op dinsdag 13 oktober 2015 @ 14:59:
Het leuke van Android vind ik wel de compatibility libraries zodat je toch nog nieuwe UI API kan gebruiken in oudere versies van Android. Zie ik nooit bij iOS gebeuren...

Je hoeft op iOS eigenlijk nooit meer dan twee OS versies te ondersteunen. iOS 5 is wel ooit een dingetje geweest ivm met eerste generatie iPads maar daarna eigenlijk niet meer.

EddoH schreef op dinsdag 13 oktober 2015 @ 15:01:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 33% gewijzigd door BikkelZ op 13-10-2015 15:05 ]

[alienfruit]

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