De Devschuur Coffee Corner - Iteratie ➒

[gekkie]

Candanz schreef op donderdag 15 oktober 2015 @ 09:34:
Dat schiet toch niet op?

Collega refactoren ipv z'n code zal wel geen optie zijn ?

[Ryur]

gekkie schreef op donderdag 15 oktober 2015 @ 09:38:
[...]

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

Hier (Hengelo, OV) is het droog. Wel heeeeeel donker, het lijkt nog net nacht.

[FraxleNL]

Ryur schreef op donderdag 15 oktober 2015 @ 09:43:
[...]

Hier (Hengelo, OV) is het droog. Wel heeeeeel donker, het lijkt nog net nacht.

Zelfde in Rotterdam. Behoorlijk donker terwijl het toch al 09:45 is.

[Candanz]

gekkie schreef op donderdag 15 oktober 2015 @ 09:40:
[...]

Collega refactoren ipv z'n code zal wel geen optie zijn ?

Was het maar een optie.

Hier in Rijssen, OV ziet het er droog uit, begint eindelijk licht te worden.

[ Voor 16% gewijzigd door Candanz op 15-10-2015 09:49 ]

[RayNbow]

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

Twee liften zijn operationeel. Trappen lopen heb ik dinsdag al gedaan.

[Merethil]

Encoding issues... Altijd leuk

[Geerrrt]

Merethil schreef op donderdag 15 oktober 2015 @ 10:11:
Encoding issues... Altijd leuk

[afbeelding]

Met zo'n bandnaam vragen ze er ook om..

[BoAC]

Candanz schreef op donderdag 15 oktober 2015 @ 09:34:
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?

Bouw et dan zelf als het in een uurtje klaar is

[Woy]

Candanz schreef op donderdag 15 oktober 2015 @ 09:34:
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

Het lijkt mij niet handig om aan het eind van het project nog de API interface aan te gaan lopen passen

[Candanz]

Woy schreef op donderdag 15 oktober 2015 @ 10:42:
[...]

Het lijkt mij niet handig om aan het eind van het project nog de API interface aan te gaan lopen passen

Waar zo ver ik er aan werk, bouw ik het ook meteen in. Maar er is geen tijd ingeschat/gescrumt om de al bestaande code aan te passen.

[Merethil]

GeertJam schreef op donderdag 15 oktober 2015 @ 10:23:
[...]


Met zo'n bandnaam vragen ze er ook om..

Tja, gekke Ijslanders he

[Verwijderd]

BikkelZ schreef op woensdag 14 oktober 2015 @ 19:05:
[...]


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
    }
}

Swift.

[Hydra]

Candanz schreef op donderdag 15 oktober 2015 @ 09:34:
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.

Dat is gewoon een onderdeel van je development tijd? Net zoals het schrijven van unit-tests e.d. Je moet niet in gaan zitten schatten op het opleveren van slechts een skelet van de volledige feature: als ik X dagen plan voor een feature is that gewoon 'klaar': geen halfbakken ding waar sowieso nog zaken aan 'gerefactored' moeten worden (bugs daargelaten )

[BikkelZ]

Candanz schreef op donderdag 15 oktober 2015 @ 09:34:
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?

Programmeren is eigenlijk net als schrijven iets wat je gewoon kunt of niet. Sommige mensen kunnen gewoon geen logisch verhaal in elkaar draaien. Dat is zelfs genetisch denk ik. En dan kun je nog trainen.

[.oisyn]

De dingen die hij noemt heeft weinig met al dan niet kunnen programmeren te maken. De ene is gewoon lui en de ander kan niet plannen, of ziet daar iig geen noodzaak toe.

[jbdeiman]

gekkie schreef op woensdag 14 oktober 2015 @ 15:42:
[...]

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

Niet persé, als er iets fout gaat, moet de "hudiige actie" ongedaan gemaakt worden. Feitelijk store je alles wat er gebeurt met de data in de applicatie in een transactie. => Gaat er onverhoopt ergens wat mis, draai je dan e.e.a. terug en zit je in de status VOORDAT het mis begon te gaan.

Je hoeft dus niet alles vooraf te ondervangen, maar je moet rekening houden met iets onverwachts en proberen te zorgen dat dat geen onoverkomelijke consequenties heeft voor je applicaties.

[BikkelZ]

.oisyn schreef op donderdag 15 oktober 2015 @ 13:18:
De dingen die hij noemt heeft weinig met al dan niet kunnen programmeren te maken. De ene is gewoon lui en de ander kan niet plannen, of ziet daar iig geen noodzaak toe.

Ik ben ook lui als ik mezelf met anderen vergelijk. Maar ik ben wel leesbaar lui.

[alienfruit]

Cool, het is gelukt met het niet faden van plaatjes. Nu nog dat gekloot van mijn eigen topic. Ik krijg het gewoon niet voor elkaar. Ik voel mij zo stom, haha.

[azerty]

. word een jezus kruis in internet explorer en chrome, in webdesign subforum dan nog

[ Voor 18% gewijzigd door azerty op 15-10-2015 14:21 ]

[EddoH]

Soms heb ik het gevoel dat ik de enige ben die iets niet begrijpt...
Waarom barst het in veel JavaScript code van de this.myVariable, terwijl m.i een var myVariable veel netter zou zijn. Mis ik nou nog een voordeel/eigenschap van this.myVar??

azerty schreef op donderdag 15 oktober 2015 @ 14:20:
. word een jezus kruis in internet explorer en chrome

En vervolgens een reactie in dat topic:

Toen ik de titel las, wist ik al dat ik ging laggen.

[Alex)]

EddoH schreef op donderdag 15 oktober 2015 @ 14:24:
Soms heb ik het gevoel dat ik de enige ben die iets niet begrijpt...
Waarom barst het in veel JavaScript code van de this.myVariable, terwijl m.i een var myVariable veel netter zou zijn. Mis ik nou nog een voordeel/eigenschap van this.myVar??

Dat heeft alles te maken met scoping.

[EddoH]

Alex) schreef op donderdag 15 oktober 2015 @ 14:26:
[...]

Dat heeft alles te maken met scoping.

Ja dat snap ik

Ik gebruik ook var juist bij 'private' members en lokale variabelen. Het lijkt erop dat sommigen dat onderscheid helemaal niet maken en gewoon overal this.* voor gebruiken Dat is wat ik bedoelde, niet helemaal duidelijk van me. Maargoed, misschien niet het juiste topic voor.

[BikkelZ]

alienfruit schreef op donderdag 15 oktober 2015 @ 14:11:
Cool, het is gelukt met het niet faden van plaatjes. Nu nog dat gekloot van mijn eigen topic. Ik krijg het gewoon niet voor elkaar. Ik voel mij zo stom, haha.

faden of laden?

Ben nu wat minder druk aangezien gisteren de stekker uit dat gekke project getrokken lijkt te zijn, mocht je er echt niet uit komen met je layouts dan kan ik wel ff kijken.

[alienfruit]

Ik heb je een privé bericht gestuurd

[Hydra]

Crisis wat is Java 8 fijn ten opzichte van voorgaande versies. Lambda's, lambda's everywhere!

Wel jammer dat ik per volgende week fulltime op een Java 7 project zit

[incaz]

Wat is precies de aantrekkingskracht van die lambda's?

[F.West98]

incaz schreef op donderdag 15 oktober 2015 @ 17:46:
Wat is precies de aantrekkingskracht van die lambda's?

Veel kortere en overzichtelijkere code? I.p.v. overal new SomeLongNameListenerThingInterface { public void onClickThing(object some, object parameters) { /**/ } } gewoon (some, parameters) -> { /**/ }

[Hydra]

incaz schreef op donderdag 15 oktober 2015 @ 17:46:
Wat is precies de aantrekkingskracht van die lambda's?

Minder boilerplate. Een lambda is ongeveer 100% logica zonder het geneuzel van het maken van een anonymous interface implementation. Je kunt dus kleine losse stukjes herbruikbare code maken. En da's fijn

[WernerL]

Java developers hebben lamda's ontdekt?
Lang leve functionele programmeertalen, Ik gebruik ze al tijden.
Javascript krijgt ze ook in de nieuwe versie.

[BikkelZ]

WernerL schreef op donderdag 15 oktober 2015 @ 18:20:
Javascript krijgt ze ook in de nieuwe versie.

Nou da's fijn om te weten als tegen 2022 meer dan 90% van de browsers het ondersteunt.

[WernerL]

BikkelZ schreef op donderdag 15 oktober 2015 @ 18:21:
[...]


Nou da's fijn om te weten als tegen 2022 meer dan 90% van de browsers het ondersteunt.

Chrome en Firefox ondersteunen het al. Het is wachten op IE, zoals gewoonlijk. Geen idee of Edge er al ondersteuning voor heeft.

Maar dit werkt nu gewoon in Chrome:

code:

[1,2,3].map(x => x * 2)

Ziet er toch wel mooier uit.

[incaz]

Ik ben geloof ik nog niet helemaal overtuigd, nuttige functienamen hebben toch wel enige waarde. Functioneel programmeren is absoluut elegant - maar wat mij betreft ook vaak een drama om later nog te achterhalen wat de gedachte erachter is. Want in al die abstracte elegantie mis je wel gewoon de aardse informatie.

Van de andere kant, Java kent wel veel boilerplate dus in dat opzicht kan ik me de wens voor minder wel voorstellen.

[F.West98]

WernerL schreef op donderdag 15 oktober 2015 @ 18:25:
[...]


Chrome en Firefox ondersteunen het al. Het is wachten op IE, zoals gewoonlijk. Geen idee of Edge er al ondersteuning voor heeft.

Maar dit werkt nu gewoon in Chrome:

code:

[1,2,3].map(x => x * 2)

Ziet er toch wel mooier uit.

Gewoon TypeScript gebruiken, werkt ook in IE

[WernerL]

F.West98 schreef op donderdag 15 oktober 2015 @ 18:36:
[...]

Gewoon TypeScript gebruiken, werkt ook in IE

Niks geen TypeScript.
ScalaJS + ReactJS. Communicatie met server icm Futures en reactive streams.

[Niekfct]

incaz schreef op donderdag 15 oktober 2015 @ 18:33:
Ik ben geloof ik nog niet helemaal overtuigd, nuttige functienamen hebben toch wel enige waarde. Functioneel programmeren is absoluut elegant - maar wat mij betreft ook vaak een drama om later nog te achterhalen wat de gedachte erachter is. Want in al die abstracte elegantie mis je wel gewoon de aardse informatie.

Van de andere kant, Java kent wel veel boilerplate dus in dat opzicht kan ik me de wens voor minder wel voorstellen.

Het is natuurlijk ook een kunst om het goed toe te passen. Voor de toepassing

code:

[1,2,3].map(x => x * 2)

Wil je echt geen aparte functie voor schrijven. Verder verwachten dergelijke functies een bepaalde interface met een bepaalde methodenaam. Hier is niets aan te veranderen.

Dit is het alternatief:

code:

[1,2,3].map(new Func1<Integer, Integer>() {
  @Override 
  public Integer call(Integer i) {
    return i * 2;
  } 
} );

[BikkelZ]

incaz schreef op donderdag 15 oktober 2015 @ 18:33:
Ik ben geloof ik nog niet helemaal overtuigd, nuttige functienamen hebben toch wel enige waarde.

Ja natuurlijk maar je kunt ook functies binnen een lambda gebruiken in de meeste talen.

Zoiets als:

code:

let stuffIWant = stuff.filter { item in isItemIWant(item) }

func isItemIWant(item: Item) -> Bool {
     return item.isSomethingINeed
}

[F.West98]

In .NET met LINQ hebben de echte functienamen niet eens toegevoegde waarde.

C#:

var names = db.Entities.Where(s => s.SomeProperty == "search").Select(s => s.Name).ToList();

Imo is dat toch al duidelijk genoeg.

[RobertMe]

Dat laatste (LINQ voorbeeld) is natuurlijk helemaal geen lambda. Het is expression. In plaats van dat er een stuk code uitrolt wat s.SomeProperty == "search" doet is het een stuk code wat een boom vormt die s.SomeProperty == "search" als expression uitdrukt. Dat laatste kan namelijk door, in dit geval Entity Framework, geparsed worden om zo een WHERE in de query op te bouwen. Als het daadwerkelijk een stuk gecompileerde code was kon EF die informatie niet meer eruit halen.

[BikkelZ]

Sterker nog je mág helemaal geen eigen functies gebruiken in dat voorbeeld.

[RobertMe]

Ik denk dat het wel mag, alleen werkt het dan niet zoals je verwacht.

In dit geval zal .NET dan de IEnumerable<T>.Where(Func<bool, T>) pakken. Waar je verwacht dat ie de IQueryable<T>.Where(Expression<Func<bool, T>>) doet pakken. In dit geval zal EF dus de query zonder WHERE uitvoeren, waarna in .NET over het resultaat wordt gelooped en de lambda per record wordt aangeroepen. Op zijn zachts gezegd dus niet ideaal, maar het zal wel werken.

[F.West98]

Slecht voorbeeld... Beter voorbeeld:

C#:

var names = someList.Where(s => s.SomeProperty == "search").Select(s => s.Name).ToList();

[BikkelZ]

RobertMe schreef op donderdag 15 oktober 2015 @ 19:19:
Ik denk dat het wel mag, alleen werkt het dan niet zoals je verwacht.

In dit geval zal .NET dan de IEnumerable<T>.Where(Func<bool, T>) pakken. Waar je verwacht dat ie de IQueryable<T>.Where(Expression<Func<bool, T>>) doet pakken. In dit geval zal EF dus de query zonder WHERE uitvoeren, waarna in .NET over het resultaat wordt gelooped en de lambda per record wordt aangeroepen. Op zijn zachts gezegd dus niet ideaal, maar het zal wel werken.

Bij mij crashte het run-time met de mededeling dat ik dat niet moest doen.

Nog iets wat me zwaar irriteert aan EF: runtime crashes voor dingen die IMHO gewoon compiler-side afgevangen moesten worden.

[RobertMe]

Hmm. Ik zou verwacht hebben dat het dus wel compileert maar met de verkeerde overload. Maar laatste keer dat ik uberhaupt iets met .NET heb gedaan is dan ook alweer (bijna) 2 jaar geleden.

Maar in die tijd heb ik toen wel zelf een "parser" gemaakt die expressions kon omzetten naar KnockoutJS code. In de .NET class konden dan dingen als zichtbaarheid of verplichtheid worden vastgelegd met een expression, die dus compile time safe was, en at runtime werd die expression dan omgeschreven naar een stuk javascript om automagisch zichtbaarheid/verplichtheid te togglen. Werkte op zich allemaal best geinig. En met de ExpressionVisitor base class die al in .NET zit vrij eenvoudig te realiseren.

[BikkelZ]

Als code niet compile time te vertrouwen is en het ook niet on the fly met een edit terwijl het runt aan te passen is is het precies worst of both worlds. Compile tijd van .Net met de runtime crashes van PHP.

[azerty]

Soms wil je een vertaler toch echt een mep geven hé

[F.West98]

Dat komt omdat het wel valid is om externe functies te gebruiken, alleen kan EF er niets mee. En daarbij is er nog iets geks dat de compiler aanneemt dat je IENumerable functies gebruikt en niet de IQueryable.
Daarom is dit ook niet geldig in de compiler:

C#:

Expression<Func<string, bool>> sorter = s => s.Length == 2;
var shortnames = db.Names.Where(sorter).ToList();

Maar dit wel:

C#:

Expression<Func<string, bool>> sorter = s => s.Length == 2;
var shortnames = db.Names.AsQueryable().Where(sorter).ToList();

En EF werkt enkel met die expressions als je de functie wilt "uitbesteden". Je kan niet een Func<> doorgeven, maar wel een Expression<Func<>>. Dit compilet maar werkt dus runtime weer niet:

C#:

Func<string, bool> sorter = s= => s.Length == 2;
var shortnames = db.Names.Where(sorter).ToList();

Dus in de compiler gebeurt iets vreemds

Maar in Expressions en in Funcs mag je gewoon volgens de spec externe functies gebruiken, en aangezien EF niet is ingebouwd in de taal vraag ik me af hoe je dat compiletime wil gaan controleren.

[ Voor 8% gewijzigd door F.West98 op 15-10-2015 20:37 ]

[Damic]

azerty schreef op donderdag 15 oktober 2015 @ 20:26:
[afbeelding]

Soms wil je een vertaler toch echt een mep geven hé

Staat daar normaal: "Check online for new updates"?

[incaz]

azerty schreef op donderdag 15 oktober 2015 @ 20:26:
[afbeelding]

Soms wil je een vertaler toch echt een mep geven hé

Ik heb er ook een

[gekkie]

azerty schreef op donderdag 15 oktober 2015 @ 20:26:
[afbeelding]

Soms wil je een vertaler toch echt een mep geven hé

Mjah .. dat online kan inderdaad echt niet .... maar wat voor moois zou je daar nou voor kunnen verzinnen.

[azerty]

Damic schreef op donderdag 15 oktober 2015 @ 20:48:
[...]
Staat daar normaal: "Check online for new updates"?

Goed geraden. Ik zou gewoon "updates" gebruikt hebben. De software in kwestie (mkvmerge) staat in het Nederlands (blijkbaar automatisch zo ingesteld na een update, normaal kies ik altijd Engels), en er zitten vrij veel van die letterlijke vertalingen tussen

[BikkelZ]

F.West98 schreef op donderdag 15 oktober 2015 @ 20:36:

Maar in Expressions en in Funcs mag je gewoon volgens de spec externe functies gebruiken, en aangezien EF niet is ingebouwd in de taal vraag ik me af hoe je dat compiletime wil gaan controleren.

In feite is LINQ net wat te generiek om betrouwbaar om te gaan met SQL.

[ajakkes]

azerty schreef op donderdag 15 oktober 2015 @ 21:09:
[...]


Goed geraden. Ik zou gewoon "updates" gebruikt hebben. De software in kwestie (mkvmerge) staat in het Nederlands (blijkbaar automatisch zo ingesteld na een update, normaal kies ik altijd Engels), en er zitten vrij veel van die letterlijke vertalingen tussen

Controleer op kabel voor nieuwe opwaarderingen. Zou ik zeggen.

[bwerg]

Hydra schreef op donderdag 15 oktober 2015 @ 17:10:
Crisis wat is Java 8 fijn ten opzichte van voorgaande versies. Lambda's, lambda's everywhere!

Wel jammer dat ik per volgende week fulltime op een Java 7 project zit

En als je het dan een tijdje gebruikt, en eindelijk je mooie slimme functionele slimmigheidjes kan toepassen, kom je erachter dat het nog steeds een stukje lomper aanvoelt dan een puur functionele taal... Maar voor een taal die uit een compleet andere richting komt is dit toch een hele grote verbetering.

IDE's kunnen er ook nog lang niet echt mee omgaan, trouwens. Autocomplete en andere assistentievormen in eclipse gaan meteen op zijn bek zodra je in een lambda zit. De 'ouderwetse' Java met alle extra boilerplate helpt de IDE ook wel met aanwijzen wat er precies fout is, dat is wat moeilijker als je een stream aanpast met 5 operaties achter elkaar in een one-liner. Maar het is beter dan 5 losse statements, zo nu en dan met wat loopjes eromheen...

[F.West98]

bwerg schreef op donderdag 15 oktober 2015 @ 21:59:
[...]

En als je het dan een tijdje gebruikt, en eindelijk je mooie slimme functionele slimmigheidjes kan toepassen, kom je erachter dat het nog steeds een stukje lomper aanvoelt dan een puur functionele taal... Maar voor een taal die uit een compleet andere richting komt is dit toch een hele grote verbetering.

IDE's kunnen er ook nog lang niet echt mee omgaan, trouwens. Autocomplete en andere assistentievormen in eclipse gaan meteen op zijn bek zodra je in een lambda zit. De 'ouderwetse' Java met alle extra boilerplate helpt de IDE ook wel met aanwijzen wat er precies fout is, dat is wat moeilijker als je een stream aanpast met 5 operaties achter elkaar in een one-liner. Maar het is beter dan 5 losse statements, zo nu en dan met wat loopjes eromheen...

IntelliJ kan dat vrij goed
Ik vind stream ook een beetje een gekunstelde manier om lists "functioneel" te maken. Ze hadden het imo veel beter kunnen integreren in de arraylist class / list interface, dat maakt het iets natuurlijker. Of zit er een reden achter die ik heb gemist?

[Alex)]

BikkelZ schreef op donderdag 15 oktober 2015 @ 21:43:
[...]


In feite is LINQ net wat te generiek om betrouwbaar om te gaan met SQL.

Het is prima te gebruiken voor basisdingen (SELECT * FROM, UPDATE x, DELETE FROM, ...), en ook joins kun je er nog wel enigszins mee doen - het is alleen wel enigszins beperkt ten opzichte van hoe je in (T-)SQL kunt joinen.

Echte complexe queries kun je beter meteen in SQL schrijven.

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

[Bv202]

azerty schreef op donderdag 15 oktober 2015 @ 20:26:
[afbeelding]

Soms wil je een vertaler toch echt een mep geven hé

Je moet eens in Duitsland/Oostenrijk een bankautomaat in het Nederlands zetten. Daar kom je ook wat tegen

[Hydra]

bwerg schreef op donderdag 15 oktober 2015 @ 21:59:
En als je het dan een tijdje gebruikt, en eindelijk je mooie slimme functionele slimmigheidjes kan toepassen, kom je erachter dat het nog steeds een stukje lomper aanvoelt dan een puur functionele taal... Maar voor een taal die uit een compleet andere richting komt is dit toch een hele grote verbetering.

Klopt. Ik ben ook hobbymatig (en hopelijk op professioneel vlak binnenkort) met Scala bezig en dat is toch nog een stuk tja, 'mooier'. Lastig uit te leggen maar het is gewoon 'mooie' code met weinig crap en veel logica.

IDE's kunnen er ook nog lang niet echt mee omgaan, trouwens. Autocomplete en andere assistentievormen in eclipse gaan meteen op zijn bek zodra je in een lambda zit.

Da's Eclipse. IntelliJ is hier erg goed in. Als je met Java 8 bezig bent is IntelliJ IMHO een must.

F.West98 schreef op donderdag 15 oktober 2015 @ 22:26:
IntelliJ kan dat vrij goed
Ik vind stream ook een beetje een gekunstelde manier om lists "functioneel" te maken. Ze hadden het imo veel beter kunnen integreren in de arraylist class / list interface, dat maakt het iets natuurlijker. Of zit er een reden achter die ik heb gemist?

Wat bedoel je precies? Een stream is gewoon wat anders dan een collection. Het is volledig logisch dat dat een andere class is. Een stream kan je ook eenvoudig paralleliseren bijvoorbeeld. Een parallele set of list is, tja, vreemd.

WernerL schreef op donderdag 15 oktober 2015 @ 18:20:
Java developers hebben lamda's ontdekt?

Ik heb ze niet net ontdekt. Alleen zit (of nouja zat, vandaag laatste dag) ik pas de afgelopen 3 maanden in een project waar Java 8 gebruikt wordt. Er is nogal een verschil tussen lambda's kennen en ze daadwerkelijk in je werk gebruiken.

Helaas per volgende week op een project waar de overstap nog niet gemaakt is. Wel in een omgeving waar ook Scala gebruikt wordt dus met wat geluk kan ik die overstap maken.

[ Voor 40% gewijzigd door Hydra op 16-10-2015 10:57 ]

[azerty]

Bv202 schreef op vrijdag 16 oktober 2015 @ 09:02:
[...]


Je moet eens in Duitsland/Oostenrijk een bankautomaat in het Nederlands zetten. Daar kom je ook wat tegen

Ga ik de volgende keer doen als ik geld afhaal

[BikkelZ]

Alex) schreef op vrijdag 16 oktober 2015 @ 01:15:
[...]

Het is prima te gebruiken voor basisdingen (SELECT * FROM, UPDATE x, DELETE FROM, ...), en ook joins kun je er nog wel enigszins mee doen - het is alleen wel enigszins beperkt ten opzichte van hoe je in (T-)SQL kunt joinen.

Echte complexe queries kun je beter meteen in SQL schrijven.

Ik bedoel dat LINQ allerlei dingen toestaat die niet kunnen in SQL en omgekeerd dingen die makkelijk zijn in SQL weer niet zo makkelijk doet omdat het meer een generieke objectenfilter is.

bwerg schreef op donderdag 15 oktober 2015 @ 21:59:
[...]

IDE's kunnen er ook nog lang niet echt mee omgaan, trouwens. Autocomplete en andere assistentievormen in eclipse gaan meteen op zijn bek zodra je in een lambda zit. De 'ouderwetse' Java met alle extra boilerplate helpt de IDE ook wel met aanwijzen wat er precies fout is, dat is wat moeilijker als je een stream aanpast met 5 operaties achter elkaar in een one-liner. Maar het is beter dan 5 losse statements, zo nu en dan met wat loopjes eromheen...

Nou als zelfs Apple het voor elkaar krijgt om het in Xcode te laten werken....

[F.West98]

Hydra schreef op vrijdag 16 oktober 2015 @ 10:51:
[...]


Wat bedoel je precies? Een stream is gewoon wat anders dan een collection. Het is volledig logisch dat dat een andere class is. Een stream kan je ook eenvoudig paralleliseren bijvoorbeeld. Een parallele set of list is, tja, vreemd.

Ja dat wist ik dus niet
Ik vond het alleen omslachtig dat je steeds van een list/enumerable naar een stream moet en weer terug.

En inderdaad is Eclipse denk ik zo'n beetje de enige (grote) IDE die níet goed met lambda's overweg kan. VS, IntelliJ en dus kennelijk ook XCode kunnen het allemaal prima.

[BikkelZ]

F.West98 schreef op vrijdag 16 oktober 2015 @ 15:26:
[...]

En inderdaad is Eclipse denk ik zo'n beetje de enige (grote) IDE die níet goed met lambda's overweg kan.

Eclipse is gewoon crap. Crap crap crap crap crap.

[RayNbow]

* RayNbow gebruikt nog steeds Eclipse voor Python en LaTeX... te lui om een andere IDE te vinden en over te stappen...

Iets met change function en zo.

[acemoo]

RayNbow schreef op vrijdag 16 oktober 2015 @ 15:42:
* RayNbow gebruikt nog steeds Eclipse voor Python en LaTeX... te lui om een andere IDE te vinden en over te stappen...

Iets met change function en zo.

Eclipse voor LaTeX, is dat wel een goed idee?

[RayNbow]

br men schreef op vrijdag 16 oktober 2015 @ 15:45:
[...]


Eclipse voor LaTeX, is dat wel een goed idee?

Ben tevreden met TeXlipse.

[Creepy]

Hier overigens geen problemen met lambda's en code completion in Eclipse? But hey, crap roepen is makkelijk dan het zelf ff uittesten

[BikkelZ]

Creepy schreef op vrijdag 16 oktober 2015 @ 15:49:
Hier overigens geen problemen met lambda's en code completion in Eclipse? But hey, crap roepen is makkelijk dan het zelf ff uittesten

IntelliJ > NetBeans > Eclipse

En dan tussen NetBeans en Eclipse meer ruimte dan tussen IntelliJ en NetBeans.

Daar bovenop ga ik gewoon nooit geen Eclipse meer installeren en al zeker niet opstarten om te kijken of lambda's in Java wel of niet ondersteund worden. Ook al worden ze ondersteund, je werkt nog steeds in Eclipse.

[kenneth]

Zo te horen heeft de universiteit een slechte keuze gemaakt met Eclipse Ik weet nog wel dat ik heel vroeger Netbeans gebruikte en daar redelijk tevreden mee was. Eclipse heeft altijd voor ergernis gezorgd. Mochten er nog wat grotere Javaprojecten aankomen dan maar eens de community edition van IntelliJ gebruiken. Die is neem ik aan even goed als de volledige versie?

[Ryur]

kenneth schreef op vrijdag 16 oktober 2015 @ 21:41:
Zo te horen heeft de universiteit een slechte keuze gemaakt met Eclipse Ik weet nog wel dat ik heel vroeger Netbeans gebruikte en daar redelijk tevreden mee was. Eclipse heeft altijd voor ergernis gezorgd. Mochten er nog wat grotere Javaprojecten aankomen dan maar eens de community edition van IntelliJ gebruiken. Die is neem ik aan even goed als de volledige versie?

Zodra je met Web-wereld aan de slag wilt voor Java is de CE niet voldoende.
Ik moest omdat ik met Spring/Servlets/EJB's (de JavaEE wereld dus) de full-version gebruiken.

[Gleighton]

De Community Edition (CE) is bijna hetzelfde, alleen Java EE gerelateerde dingen heb je daar niet. Voor mijn dagelijkse werk nu is de CE ruim voldoende.

[Hydra]

kenneth schreef op vrijdag 16 oktober 2015 @ 21:41:
Zo te horen heeft de universiteit een slechte keuze gemaakt met Eclipse

Het is slechts zijn mening. IntelliJ is m.i. de beste IDE maar Eclipse is zeker niet slecht en kan prima overweg met Java 8 code. Ik ben het er zeker ook niet mee eens dat Netbeans veel beter is dan Eclipse, eerder omgekeerd.

Maargoed. Het is voor iedereen persoonlijk.

Ryur schreef op vrijdag 16 oktober 2015 @ 22:58:
Zodra je met Web-wereld aan de slag wilt voor Java is de CE niet voldoende.

Da's een beetje overdreven. De volledige versie doet vooral een hoop Java EE spul wat de CE niet doet maar dat mis je niet als je met bijvoorbeeld Spring Boot aan de slag gaat.

[ Voor 28% gewijzigd door Hydra op 17-10-2015 11:23 ]

[Ryur]

Hydra schreef op zaterdag 17 oktober 2015 @ 11:22:
[...]
Da's een beetje overdreven. De volledige versie doet vooral een hoop Java EE spul wat de CE niet doet maar dat mis je niet als je met bijvoorbeeld Spring Boot aan de slag gaat.

Dan hebben ze het veranderd
Laatste keer dat ik met Java bezig was, was al 2 jaar geleden.

En toen moest ik met Spring/Hibernate & EJB's werken. Kon de CE niet gebruiken

[BikkelZ]

Hydra schreef op zaterdag 17 oktober 2015 @ 11:22:
[...]


Het is slechts zijn mening. IntelliJ is m.i. de beste IDE maar Eclipse is zeker niet slecht en kan prima overweg met Java 8 code. Ik ben het er zeker ook niet mee eens dat Netbeans veel beter is dan Eclipse, eerder omgekeerd.

Eclipse kan veel meer dan NetBeans, ondersteunt zo'n beetje iedere programmeertaal die ooit uitgevonden is en heeft enorm veel plug-ins. Je kunt ook bijna alles instellen. Maar goed qua gebruiksgemak vond ik het altijd echt een draak om mee te werken. Ik hou niet van software die een hele studie vereist zonder daar noemenswaardig meer voor terug te krijgen. Ik wil software die problemen oplost voor me terwijl ik programmeer niet software die me er tien terug geeft.

[StM]

Ach, IBM maakt zelfs zijn installers en update tools met het Eclipse platform. Dat is pas een geweldig idee Tientallen MBs voor de software en 1 MB voor de update zelf...

[ElkeBxl]

Zo rustig hier

Op het werk ook rustig, het zijn weeral eens acties bij de NMBS en dus hebben veel collega's dagje recup genomen

[azerty]

Les in uithoek van gebouw -> internet slecht -> noodgedwongen via telefoon nu

[gekkie]

Hmm de bonenmaler "knalt" .. klinkt als iets wat niet helemaal de bedoeling is .. maarja .. als het deurtje dicht zit zie je niks .. en met het deurtje open doet tie uiteraard weer niks .. misschien maar eens kijken waar de detectie daarvan zit.

[TheNephilim]

gekkie schreef op maandag 19 oktober 2015 @ 10:40:
Hmm de bonenmaler "knalt" .. klinkt als iets wat niet helemaal de bedoeling is .. maarja .. als het deurtje dicht zit zie je niks .. en met het deurtje open doet tie uiteraard weer niks .. misschien maar eens kijken waar de detectie daarvan zit.

Ja altijd lastig te debuggen die dingen

[gekkie]

Mjah en geen duidelijk bouwtekening zuigt ook apenootjes ..

Hmm en in NL schijnt het geloof ik hi ha herfstvakantie te zijn.

[ Voor 36% gewijzigd door gekkie op 19-10-2015 12:04 ]

[wouterwouter2]

gekkie schreef op maandag 19 oktober 2015 @ 10:40:
Hmm de bonenmaler "knalt" .. klinkt als iets wat niet helemaal de bedoeling is .. maarja .. als het deurtje dicht zit zie je niks .. en met het deurtje open doet tie uiteraard weer niks .. misschien maar eens kijken waar de detectie daarvan zit.

Pas maar op, straks heb je gemalen plastic in je koffie...

[gekkie]

wouterwouter2 schreef op maandag 19 oktober 2015 @ 12:12:
[...]

Pas maar op, straks heb je gemalen plastic in je koffie...

Tis wel plastic op plastic wat er knalt (kan ook bijna niet anders .. tis nagenoeg alleen maar plastic) ... lijkt iets in het hele up en down gedoe systeem van de zetgroep te zijn ... normaal gesproken knalt alleen de hockeystick die de koffiepuk na afloop in het bakje weet te scoren een beetje. Naja nu maar aan de thee

[mbarie]

Ik las een user story. Ik voelde me aangesproken een baalde ervan dat er aanpassingen gedaan moesten worden in een stuk dat ik heb gerealiseerd. Bleek ik ook de story met de vermeldde aanpassingen geschreven te hebben.

[RobIII]

Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

[ Voor 16% gewijzigd door RobIII op 19-10-2015 14:48 ]

[Candanz]

na 2.5 dag teren op 2 uurtjes slaap, daarna een dag uitslapen, en alle energy er uit te spugen weer druk aan het werk.

Ik ben nu al weer toe aan m'n bed.

[Rutix]

mbarie schreef op maandag 19 oktober 2015 @ 14:09:
Ik las een user story. Ik voelde me aangesproken een baalde ervan dat er aanpassingen gedaan moesten worden in een stuk dat ik heb gerealiseerd. Bleek ik ook de story met de vermeldde aanpassingen geschreven te hebben.

maar scrum enzo houd toch in dat elk ding aangepast kan worden ? Hoeft niet perse te zijn omdat je het crap hebt gemaakt maar omdat het gewoon nog verbeterd kan worden. Ik had onderlaatst ook zoiets hoor wij waren onze interne backlog aan het groomen en ik was een item waarvan ik zei "wat is dat nou weer voor onzin, wie heeft die gemaakt" bleek ik het te zijn geweest

[Matis]

RobIII schreef op maandag 19 oktober 2015 @ 14:46:
Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

Leuk

Misschien ook de moeite waard om de jeugd te enthousiasmeren met programmeren.

[BtM909]

RobIII schreef op maandag 19 oktober 2015 @ 14:46:
Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

Dude, wat doe je mij aan

[BikkelZ]

RobIII schreef op maandag 19 oktober 2015 @ 14:46:
Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

Hmmm niet voor iOS?

[Candanz]

En toen was je collega ziek en heeft ie niks gecommit de laatste week.
Log je in op z'n pc.
Zie je een .js bestandje in SourceTree die compleet veranderd is met een Canvas implementatie, terwijl we dat niet eens gebruiken.

En collega is niet bereikbaar.
Jeuj

[gekkie]

Hmmppffrrfff grmbl .. voeding van de thuisserver kaduuk .. 5 year warranty .. wanneer de fsck is dat ding aangeschaft

[ElkeBxl]

Candanz schreef op maandag 19 oktober 2015 @ 16:08:
En toen was je collega ziek en heeft ie niks gecommit de laatste week.
Log je in op z'n pc.
Zie je een .js bestandje in SourceTree die compleet veranderd is met een Canvas implementatie, terwijl we dat niet eens gebruiken.

En collega is niet bereikbaar.
Jeuj

Jij kan inloggen op zijn pc? Bij ons niet mogelijk hoor Dusja we hebben hier al meegemaakt dat je gewoon weet dat ze iets klaar hadden staan wat nooit ingecheckt is, maar dat we konden wachten tot terugkeer van vakantie... Of ook een mooie: ze checken in met build errors Laten ze jou dus hun debugwerk doen, hatelijk!

[Rem]

ElkeBxl schreef op maandag 19 oktober 2015 @ 16:13:
[...]

Jij kan inloggen op zijn pc? Bij ons niet mogelijk hoor Dusja we hebben hier al meegemaakt dat je gewoon weet dat ze iets klaar hadden staan wat nooit ingecheckt is, maar dat we konden wachten tot terugkeer van vakantie... Of ook een mooie: ze checken in met build errors Laten ze jou dus hun debugwerk doen, hatelijk!

Lekkere collega's heb je dan, als je ze daarop aanspreek is hun reactie ook 'Regel het zelf maar'?

[Rutix]

ElkeBxl schreef op maandag 19 oktober 2015 @ 16:13:
[...]

Jij kan inloggen op zijn pc? Bij ons niet mogelijk hoor Dusja we hebben hier al meegemaakt dat je gewoon weet dat ze iets klaar hadden staan wat nooit ingecheckt is, maar dat we konden wachten tot terugkeer van vakantie... Of ook een mooie: ze checken in met build errors Laten ze jou dus hun debugwerk doen, hatelijk!

Ik zou dus meteen gated checkin instellen zodat dat soort code gewoon gereject worden

[Alex)]

ElkeBxl schreef op maandag 19 oktober 2015 @ 16:13:
[...]
ze checken in met build errors Laten ze jou dus hun debugwerk doen, hatelijk!

Changeset rollbacken en boos mailtje naar de collega sturen :W

[ElkeBxl]

Rem schreef op maandag 19 oktober 2015 @ 16:28:
[...]


Lekkere collega's heb je dan, als je ze daarop aanspreek is hun reactie ook 'Regel het zelf maar'?

Letterlijke quote toen ze hun daarop aanspraken: "Ah echt? Tiens, bij mij builde dat hoor!" Yeah right...

Rutix schreef op maandag 19 oktober 2015 @ 16:32:
[...]

Ik zou dus meteen gated checkin instellen zodat dat soort code gewoon gereject worden

Bij ons is er enkel een gated checkin voor als we naar development deployen, mag inderdaad al wat eerder ingesteld staan.

Alex) schreef op maandag 19 oktober 2015 @ 16:33:
[...]

Changeset rollbacken en boos mailtje naar de collega sturen :W

Dat was het plan, tot we zagen dat het een checkin was van meerdere bugfixes tegelijk. We hebben het dan maar gedebugged gezien we meer tijden zouden verliezen met al die fixes opnieuw te maken. De klant zat te wachten op de fixes dus er zat haast achter.

[azerty]

Daar gaan we weer:

[Matis]

BtM909 schreef op maandag 19 oktober 2015 @ 15:39:
Dude, wat doe je mij aan

[afbeelding]

Been there, done that

[Soultaker]

RobIII schreef op maandag 19 oktober 2015 @ 14:46:
Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

Ziet er leuk uit Little Inferno was ook grappig. Binnenkort maar even aanschaffen.

[Matis]

RobIII schreef op maandag 19 oktober 2015 @ 14:46:
Zojuist Human Resource Machine (van de makers van World of Goo) aangeschaft. Kost maar een tientje en is grafisch, muziekaal en gameplaytechnisch zéker de centjes waard.

Misschien een idee om een kijk-mij-eens-een-lage-score-hebben topic te openen in PRG?

Ikzelf zit een beetje vast in jaar 9.

spoiler:

Ik heb wel 5/5 commando's, maar 28/25 instructies

-- HUMAN RESOURCE MACHINE PROGRAM --

a:
b:
INBOX
JUMPZ c
JUMP b
c:
OUTBOX
JUMP a

[ Voor 9% gewijzigd door Matis op 19-10-2015 19:43 ]

[Caelorum]

ElkeBxl schreef op maandag 19 oktober 2015 @ 16:13:
[...] Jij kan inloggen op zijn pc? Bij ons niet mogelijk hoor [...]

Lekker handig dat. Bij ons gaat het ook niet zo super makkelijk, maar met een beetje moeite en tijd zit je gewoon op de PC van de andere hoor. Met wat meer moeite kan je ook gewoon inloggen onder het profiel. Mocht er ooit iemand plotseling overlijden ^^

[gekkie]

Caelorum schreef op maandag 19 oktober 2015 @ 20:33:
[...]

Lekker handig dat. Bij ons gaat het ook niet zo super makkelijk, maar met een beetje moeite en tijd zit je gewoon op de PC van de andere hoor. Met wat meer moeite kan je ook gewoon inloggen onder het profiel. Mocht er ooit iemand plotseling overlijden ^^

Meh windows zonder diskencryptie ?