De Devschuur Coffee Corner - Iteratie ⓫

[whoami]

Hydra schreef op maandag 21 augustus 2017 @ 19:27:
Ik ben eigenlijk sowieso opgehouden met het gebruiken van ORMs. Kwa expressiveness is er eigenlijk niks wat gewoon SQL naar de kroon kan steken. Je hebt meestal geen ORM nodig maar gewoon een rowmapper die de date uit de resultsets naar objecten omzet. En daar zijn prima libraries voor. Met een ORM moet je nog steeds SQL kunnen lezen (elke niet triviale query moet je echt checken) en je bent vaak langer bezig de relaties tussen je entities te mappen dan dat je bezig bent SQL te schrijven.

Je hebt wel een punt. En ik ben ook wel gecharmeerd van tools zoals Dapper en PetaPoco maar full-blown O/R-M's hebben wel hun nut in bepaalde projecten.

Het project waar ik nu aan werk heb ik ge-erfd, en het gebruik van EF is in dit project eigenlijk wel overkill. Dapper zou eigenlijk een betere keuze geweest zijn. Nadeel zou dan wel zijn dat er verschillende 'drivers' zouden moeten geschreven worden per ondersteund DBMS.
Beetje laat in het project om het nu nog te wijzigen, maar ik denk dat ik het toch eens ga bespreken me de PO.

[ Voor 5% gewijzigd door whoami op 21-08-2017 21:36 ]

[Alex)]

Tsja, ik heb ooit met iemand gewerkt die wat data moest opslaan wat niet in de standaard (SharePoint) omgeving paste. Het ging om één tabel met welgeteld 3 kolommen aan data (naast de PK) en verder geen enkele relaties of constraints.

Diegene moest per sé een ORM moest gebruiken "want dat is modern en elegant", terwijl SQL maar "hopelijk ouderwets is". Ik moest maar eens "met mijn tijd meegaan"...

[RayNbow]

SQL is doorgaans ook ouderwets. Waarom moeten we een query in een string proppen, die vervolgens overpompen naar een databasesysteem, dat vervolgens de string weer mag gaan parsen?

[Alex)]

Wat stel je voor als alternatief?

[whoami]

NoSQL databases, want da's lekker modern.

[Alex)]

whoami schreef op maandag 21 augustus 2017 @ 22:08:
NoSQL databases, want da's lekker modern.

[RayNbow]

Wat dacht je van een databasesysteem dat tabellen exposet als objecten en σ, π, ρ, ⋈, etc., aanbiedt als methodes of functies? Elke functieaanroep bouwt in feite een nieuw deel van de uiteindelijke query AST, die het databasesysteem vervolgens analyseert om met een execution plan te komen.

[Alex)]

Maar wordt een database daar bruikbaarder door? We schrijven toch ook niet alles in assembly?

Als de nood zo hoog is dat SQL niet performant genoeg meer is en er niks meer te tweaken valt, ben je waarschijnlijk software aan het schrijven voor flitshandel op de beurs.

[alienfruit]

Nieuwe notebook inrichten altijd leuk 😄

[RayNbow]

Alex) schreef op maandag 21 augustus 2017 @ 22:26:
Maar wordt een database daar bruikbaarder door?

Combineer het met iets als Type Providers wat F# heeft en je kunt type-safe database queries in je programmeeromgeving tikken i.p.v. te kloten met querystrings.

We schrijven toch ook niet alles in assembly?

Als de nood zo hoog is dat SQL niet performant genoeg meer is en er niks meer te tweaken valt, ben je waarschijnlijk software aan het schrijven voor flitshandel op de beurs.

Het gaat niet om performance. Het gaat om de interface met de database. Waarom moeten we de query als een string aanleveren?

We proberen het volgende toch ook te vermijden in JavaScript?

JavaScript:

var f = eval('(function() { console.log("Hello World"); })');
f();

In plaats daarvan geven we toch de voorkeur aan dit?

JavaScript:

var f = (function() { console.log("Hello World"); });
f();

Dus waarom vervangen we interfaces als

C#:

var res = conn.execute("SELECT * FROM Users WHERE name = 'foo'");

niet door iets als onderstaande (of iets van die strekking)?

C#:

var res = conn.execute(conn.Tables.Users.Where(u => u.name == "foo"));

[Alex)]

Maar dat doet toch bijna hetzelfde? Onder water zal de engine nog altijd de query moeten omsmurfen naar iets wat overweg kan met de interne datastructuren van de database waar het geheel op draait.

En hoe zie je dat "conn.Tables.Users" voor je? Is dat een snapshot van hoe de databasestructuur was op het moment van compileren of is het iets wat dynamisch wordt opgehaald at runtime, en dus mogelijk kan knallen als de datastructuur wijzigt? Hoe ga je om met aggregates op je data? Met joins? Pivots en rollups? Conditional columns?

[ Voor 9% gewijzigd door Alex) op 21-08-2017 23:08 ]

[farlane]

Alex) schreef op maandag 21 augustus 2017 @ 23:07:
En hoe zie je dat "conn.Tables.Users" voor je? Is dat een snapshot van hoe de databasestructuur was op het moment van compileren of is het iets wat dynamisch wordt opgehaald at runtime, en dus mogelijk kan knallen als de datastructuur wijzigt? Hoe ga je om met aggregates op je data? Met joins? Pivots en rollups? Conditional columns?

Zelfde als nu, maar dan zonder de string representatie die er tussenin zit.

[RayNbow]

Alex) schreef op maandag 21 augustus 2017 @ 23:07:
Maar dat doet toch bijna hetzelfde?

Is mijn eval-JS voorbeeld dan ook bijna hetzelfde als m'n eval-loze-JS voorbeeld?

Onder water zal de engine nog altijd de query moeten omsmurfen naar iets wat overweg kan met de interne datastructuren van de database waar het geheel op draait.

Elke functieaanroep kan een stap zijn om de interne datastructuur op te bouwen.

En hoe zie je dat "conn.Tables.Users" voor je? Is dat een snapshot van hoe de databasestructuur was op het moment van compileren of is het iets wat dynamisch wordt opgehaald at runtime, en dus mogelijk kan knallen als de datastructuur wijzigt?

Het probleem van een gewijzigde databaseschema blijf je behouden. Dit verandert t.o.v. SQL-strings niet.

conn.Tables.Users is een representatie van een database-table met een bepaald schema. Het schema informeert het typesysteem. Of dit van te voren ergens statisch is vastgelegd of dat het dynamisch wordt bepaald (bijv. zoals Type Providers in F#) is mij om het even.

Hoe ga je om met aggregates op je data?

Bedoel je iets als conn.Tables.Users.Max(u => u.age)?

Met joins?

conn.Tables.Orders.Join(conn.Tables.Users, o => o.UserId, u => u.Id?

Pivots

Zoiets?

code:

var t = tableOrResultSet;
var q = t.Pivot(
  t.SomeAggFunc(row=>row.field), 
  t.otherField,
  listOfPivotValues
);

en rollups?

Daarvoor moet ik me eerst meer inlezen hoe rollups werken.

Conditional columns?

tbl.Select(row => new {Id = row.Id, BarOrQuux = row.Foo == "Bar" ? row.Bar : row.Quux });

[Alex)]

Je beschrijft nu toch gewoon alsnog SQL, maar dan met een andere syntaxis?

Met een beetje een fatsoenlijke IDE voor je database (zoals SQL Server Management Studio) kun je toch ook krijgen wat je wilt... zoals hints over wat er in je database aanwezig is?

[Megamind]

Die lambda achtige code zal toch ook met een expressie parser moeten worden omgezet in iets wat MySQL, Postgres of MSSQL zal snappen. Dus dan is de vraag maar of de performance van die parser beter is dan de string parser.

[RayNbow]

Alex) schreef op dinsdag 22 augustus 2017 @ 00:11:
Je beschrijft nu toch gewoon alsnog SQL, maar dan met een andere syntaxis?

Ik beschrijf nu een query-taal niet in termen van syntax, maar in termen van primitieve operatoren...

...en veel van die primitieve operatoren zijn geen eens SQL-specifiek, maar generiek.

(Laat dat nou ook eens een van de gedachtes achter LINQ zijn.)

Met een beetje een fatsoenlijke IDE voor je database (zoals SQL Server Management Studio) kun je toch ook krijgen wat je wilt... zoals hints over wat er in je database aanwezig is?

In die IDE die je aanhaalt... worden SQL query's als platte strings behandeld? Dacht het niet.

Megamind schreef op dinsdag 22 augustus 2017 @ 00:39:
Die lambda achtige code zal toch ook met een expressie parser moeten worden omgezet

In het geval van C# wordt die lambda-achtige code al door de C# compiler omgezet. Zo'n lambda-expressie is al een AST.

in iets wat MySQL, Postgres of MSSQL zal snappen.

Het idee is dat database-systemen eigenlijk (in een ideale wereld) AST's/expression trees zouden moeten accepteren. Een soort van OO-achtige API dus. Niet dat er dus tussen de programmalaag en databaselaag een conversie plaatsvindt van query naar string en van string naar query. Dat laatste zou je kunnen vergelijken met Unix-piping vs. PowerShell-piping. In de Unix wereld slaat elk programma zijn resultaten plat tot een platte string en vervolgens mag het volgende programma in de pijplijn de string weer gaan parsen. In PowerShell worden er objecten van de ene Cmdlet naar de andere Cmdlet over de schutting gegooid.

Dus dan is de vraag maar of de performance van die parser beter is dan de string parser.

De performance van het parsen zal me een zorg zijn (als er al geparset moet worden). Dat valt in het niets in vergelijking met het uitvoeren van de daadwerkelijke query.

---

Laten we het eens over een andere boeg gooien. Stel dat we een hypothetische relationele database-engine gaan bouwen in C# voor gebruik in andere C#-programma's. Laat je dan de andere C#-programma's ook communiceren met je engine via platte strings of bied je een wat chiquere API aan?

[Hydra]

Alex) schreef op maandag 21 augustus 2017 @ 21:32:
Diegene moest per sé een ORM moest gebruiken "want dat is modern en elegant", terwijl SQL maar "hopelijk ouderwets is". Ik moest maar eens "met mijn tijd meegaan"...

Klinkt mij als "ik kan geen SQL" in de oren.

RayNbow schreef op maandag 21 augustus 2017 @ 21:56:
SQL is doorgaans ook ouderwets. Waarom moeten we een query in een string proppen, die vervolgens overpompen naar een databasesysteem, dat vervolgens de string weer mag gaan parsen?

SQL is declarative. Je gaat weinig meer expressiviteit vinden dan in een declarative language. Dat beetje SQL vat over het algemeen een veel grotere hoeveelheid whatever-code samen. Wat jij doet, "het is oud en nieuw is beter", is dus precies waarom mensen en-masse op Nodejs en Mongo overgaan.

[ Voor 47% gewijzigd door Hydra op 22-08-2017 07:51 ]

[LEDfan]

RayNbow schreef op maandag 21 augustus 2017 @ 22:18:
Wat dacht je van een databasesysteem dat tabellen exposet als objecten en σ, π, ρ, ⋈, etc., aanbiedt als methodes of functies? Elke functieaanroep bouwt in feite een nieuw deel van de uiteindelijke query AST, die het databasesysteem vervolgens analyseert om met een execution plan te komen.

Ik ben geen expert, maar de symbolen die je aanhaalt zijn afkomstig van de Relationele Algebra, en dat is een procedurele taal. Je omschrijft wat de database engine moet doen om de gewenste relaties op te halen. SQL is een declaratieve taal, je omschrijft niet hoe de database engine zijn taak moet doen, maar je omschrijft welke data je nodig hebt. De database engine zal dan inderdaad een execution plan opstellen, en deze verder optimaliseren. Het verschil is dat bij relationele algebra er weinig plaats is voor optimalisaties omdat de db engine eigenlijk direct uitvoert wat je zegt, terwijl bij SQL de db zelf bepaald wat die juist gaat uitvoeren bv. afhankelijk van welke indexen er zijn.

[Ludwig005]

Droevig nieuws voor de spelers van skrrt.io. het spel is definitief doodverklaard ik ging naar de officele site daar zegt google 404 error website not found nog even kijken op de site van iogames.space en daar blijkt het spel niet meer te vinden zijn. jammer wat is er toch gebeured met hun servers? ik kan het spel ineens niet meer vinden al van gisterenavond.

[RayNbow]

Hydra schreef op dinsdag 22 augustus 2017 @ 07:48:
[...]


SQL is declarative. Je gaat weinig meer expressiviteit vinden dan in een declarative language.

M'n opmerking ging hier voornamelijk over het gebruik van SQL in de vorm van platte tekst in andere programmeertalen.

Maar als we het over de taal SQL zelf gaan hebben, dan is het declaratief, maar qua expressiviteit schort het nog een klein beetje. Waarom zijn resultsets in SQL geen first-class citizens? Dat is net zoiets als in een programmeertaal wel array<int> toestaan, maar geen ondersteuning bieden voor array<array<int>>.

Wat jij doet, "het is oud en nieuw is beter", is dus precies waarom mensen en-masse op Nodejs en Mongo overgaan.

Wat ik voorstel is echter ook niet echt een nieuw concept.

LEDfan schreef op dinsdag 22 augustus 2017 @ 07:55:
[...]


Ik ben geen expert, maar de symbolen die je aanhaalt zijn afkomstig van de Relationele Algebra, en dat is een procedurele taal. Je omschrijft wat de database engine moet doen om de gewenste relaties op te halen. SQL is een declaratieve taal, je omschrijft niet hoe de database engine zijn taak moet doen, maar je omschrijft welke data je nodig hebt.

Zulke operatoren leggen niet per se een volgorde vast. Eerst projecteren en dan filteren kan bijv. worden herschreven naar eerst filteren, dan projecteren.

De database engine zal dan inderdaad een execution plan opstellen, en deze verder optimaliseren. Het verschil is dat bij relationele algebra er weinig plaats is voor optimalisaties omdat de db engine eigenlijk direct uitvoert wat je zegt,

Een database engine hoeft niet per direct iets uit te voeren. Er staat niets in de weg om uitvoering uit te stellen, i.e., someTable.Foo(f).Bar(g).Quux(h).Run(). In dit opzicht is dit ook declaratief. Je geeft aan wat je nodig hebt (maar omdat we nu eenmaal tekens moeten intikken is dit inherent lineair en moeten we toch een of andere volgorde kiezen) en de engine kan algebraïsche wetten toepassen om een slim execution plan te verzinnen.

[whoami]

RayNbow schreef op dinsdag 22 augustus 2017 @ 08:51:
[...]


Maar als we het over de taal SQL zelf gaan hebben, dan is het declaratief, maar qua expressiviteit schort het nog een klein beetje.

Hoezo ? Hoe kan dit bv

code:

SELECT SUM(Amount) FROM Table

nog expressiever ?

Waarom zijn resultsets in SQL geen first-class citizens? Dat is net zoiets als in een programmeertaal wel array<int> toestaan, maar geen ondersteuning bieden voor array<array<int>>.

Hoe zou je een resultset in C# bv als een first-class citizen gaan voorstellen ? Lijkt me niet zo simpel,

Wat ik voorstel is echter ook niet echt een nieuw concept.

Je stelt gewoon LINQ to SQL voor

schutting

hmm, good old times

[Hydra]

RayNbow schreef op dinsdag 22 augustus 2017 @ 08:51:
Maar als we het over de taal SQL zelf gaan hebben, dan is het declaratief, maar qua expressiviteit schort het nog een klein beetje.

Kun je voorbeelden geven?

Waarom zijn resultsets in SQL geen first-class citizens? Dat is net zoiets als in een programmeertaal wel array<int> toestaan, maar geen ondersteuning bieden voor array<array<int>>.

Idem hier; hoe zie je dat voor je?

[CodeCaster]

NuGet please. Ik wil OurLib3 installeren in een project dat dat nog niet bevat, krijg de fout:

Unable to find a version of 'Microsoft.Owin' that is compatible with

'Autofac.Owin 4.0.0 constraint: Microsoft.Owin (>= 3.0.0 && < 4.0.0)',
'Microsoft.AspNet.WebApi.Owin 5.2.3 constraint: Microsoft.Owin (>= 2.0.2)',
'Microsoft.Owin.Cors 3.0.1 constraint: Microsoft.Owin (>= 3.0.1)',
'Microsoft.Owin.Host.SystemWeb 3.1.0-rc1 constraint: Microsoft.Owin (>= 3.1.0-rc1)',
'Microsoft.Owin.Security 3.0.1 constraint: Microsoft.Owin (>= 3.0.1)',
'Microsoft.Owin.Security.Cookies 3.0.1 constraint: Microsoft.Owin (>= 3.0.1)',
'Microsoft.Owin.Security.OAuth 3.0.1 constraint: Microsoft.Owin (>= 3.0.1)',
'OurLib1 2.2.0 constraint: Microsoft.Owin (>= 3.0.0 && < 4.0.0)',
'OurLib2 3.0.6 constraint: Microsoft.Owin (>= 3.0.0 && < 4.0.0)',
'OurLib3 2.2.0-beta04 constraint: Microsoft.Owin (>= 3.1.0)',
'OurLib4 1.11.7-beta1 constraint: Microsoft.Owin (>= 3.0.1)'.

Volgens mij voldoet Microsoft.Owin 3.1.0 aan alle voorwaarden?

Maar 3.0.1 van die package was geïnstalleerd, nadat ik handmatig had geüpdatet naar 3.1.0 werkte de installatie van dit package wel. Dacht dat 'ie dat zelf wel zou kunnen met "Dependency behavior" op "Highest".

---

@ORM-discussie: ik heb onlangs voor een ETL-proces een mix van handgeschreven queries en PetaPoco vervangen door Entity Framework, omdat die laatste wél normaal kan omgaan met meer dan één join zonder een bak aan boilerplatecode en magische strings.

Toen de queries ineens als joins werden geschreven (en ja, poeplelijk, Project1 tot en met Extent5, maar leesbaar), kon ik met behulp van het execution plan ineens een paar nuttige indexes verzinnen en ging de performance 700% omhoog.

[Alex)]

Hydra schreef op dinsdag 22 augustus 2017 @ 07:48:
[...]


Klinkt mij als "ik kan geen SQL" in de oren.

En diegene noemde zichzelf nog 'highly experienced software engineer' ook...

[DevWouter]

Het grappig is dat SQL en EF elkaar eigenlijk tegengestelde doelstelling heeft.

SQL is ooit bedacht zodat er zonder tussenkomst van een ontwikkelaar er data opgehaald kon worden uit de database. Handig voor managers
EF is vervolgens bedacht zodat er zonder tussenkomst van een manager er data opgehaald kan worden uit de database. Handig voor ontwikkelaars

[CodeCaster]

Alex) schreef op dinsdag 22 augustus 2017 @ 10:40:
[...]

En diegene noemde zichzelf nog 'highly experienced software engineer' ook...

Je moet toch een POCO met een paar properties maken om je resultaten in op te slaan, en de connectionstring moet toch in je configuratie.

Dan vind ik dit:

C#:

List<Poco> result = new List<Poco>();

var connectionString = ConfigurationManager.ConnectionStrings["YourDatabase"].ConnectionString;
using (SqlConnection connection = new SqlConnection(connectionString))
{
    SqlCommand command = new SqlCommand("SELECT * FROM YourTable", connection);
    connection.Open();
    using (var reader = command.ExecuteReader())
    {
        while (reader.Read())
        {
            result.Add(new Poco
            {
                Foo = reader["FooCol"].ToString(),
                Bar = reader["BarCol"].ToString(),
            });
        }
    }
}

Toch behoorlijk minder elegant dan dit:

C#:

public class YourContext : DbContext
{
    public YourContext(string nameOrConnectionString)
        :  base(nameOrConnectionString)
    { }
    
    public DbSet<Poco> Pocos { get; set; }
}

using (var context = new YourContext("YourDatabase"))
{
    var result = context.Pocos.ToList();
}

En dan heb ik het nog niet eens over paging, async, meer kolommen uitlezen in je query, enzovoorts.

Neemt niet weg dat een developer SQL moet kunnen, maar SQL is echt niet altijd de oplossing.

---

DevWouter schreef op dinsdag 22 augustus 2017 @ 10:53:
Het grappig is dat SQL en EF elkaar eigenlijk tegengestelde doelstelling heeft.

SQL is ooit bedacht zodat er zonder tussenkomst van een ontwikkelaar er data opgehaald kon worden uit de database. Handig voor managers
EF is vervolgens bedacht zodat er zonder tussenkomst van een manager er data opgehaald kan worden uit de database. Handig voor ontwikkelaars

Het gevaar is dat je door de abstractie van een ORM de database gaan behandelen als black box. Dat is killing, maar daar ben je als ontwikkelaar en als team bij. Ja, er kan iemand een cross join ToList()en en zo niet alleen de database- maar ook de applicatieserver op z'n knieën brengen, maar dat kan met een SQL-query die als string is ingetikt ook.

[ Voor 23% gewijzigd door CodeCaster op 22-08-2017 10:55 ]

[Sebazzz]

Hoeveel ORM ook gehaat worden, als je veel CRUD werk heb is het gewoon prima. Formuliertjes bouwen, opslaan en ophalen.

Je moet weten hoe je het gebruikt. Grote hoeveelheden geconsolideerde data ophalen kan vaak beter met een MicroORM.

[Hipska]

Ludwig005 schreef op vrijdag 18 augustus 2017 @ 13:07:
http://skrrt.io/ gaaf spelletje. bediening gaat via de pijltjestoetsen. doel van het spel is om zoveel mogelijk jerrycans te verzamelen om in leven te blijven maar ook om je score(xp) te verhogen . je begint (0 tot 200 xp) van een gewone gezinswagen en eindigt bij 12800 xp met een supersportwagen. lees de spelregels nog eens goed door.

Doe ik iets mis? Al een aantal dagen probeer ik die site te bezoeken en krijg telkens een 404.

[Tarkin]

Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

[Hydra]

DevWouter schreef op dinsdag 22 augustus 2017 @ 10:53:
SQL is ooit bedacht zodat er zonder tussenkomst van een ontwikkelaar er data opgehaald kon worden uit de database. Handig voor managers

Waar heb je dat vandaan? Het is gebaseerd op het paper van Codd en een vrij letterlijke vertaling van zijn relationele model. Voorlopende query methoden waren niet erg leesbaar en an sich was dat wel een doel van SEQUEL net zoals dat een doel is van de meeste hedendaagse talen. Maar ik vind dat "zonder tussenkomst van een ontwikkelaar" nogal vergezocht. Relationele algebra is geen onderdeel van de gemiddelde MBA vermoed ik

Sebazzz schreef op dinsdag 22 augustus 2017 @ 11:02:
Hoeveel ORM ook gehaat worden, als je veel CRUD werk heb is het gewoon prima. Formuliertjes bouwen, opslaan en ophalen.

Je moet weten hoe je het gebruikt. Grote hoeveelheden geconsolideerde data ophalen kan vaak beter met een MicroORM.

Dat gaat richting "no true Scottsman": ik weet prima wanneer ik het gebruik. Ik heb namelijk ondervonden dat ik met plain SQL + rowmappers een stuk sneller en flexibeler werk dan met een ORM die die twee afzonderlijke zaken probeert te integreren.

En ik zie dat als de fundamentele fout van ORMs: het denken dat je het mappen van rows naar objecten en het queryen van objecten samen kan voegen klopt volgens mij niet. Je werpt dan meer obstakels op dan dat je er snelheid mee wint.

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:07:
Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

Motievatieproblemen zijn management problemen en is dus iets dat met dat team en het management aangepakt moet worden. Dus eerst; waarom zijn ze niet gemotiveerd?

[ Voor 49% gewijzigd door Hydra op 22-08-2017 13:13 ]

[simon]

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:07:
Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

Open gesprek over waar het motivatieprobleem in zit, goed opletten dat je ze niet het motivatieprobleem in de schoenen schuift.

[CodeCaster]

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:07:
Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

Ik zie doorgaans dat de motivatie keldert als er onduidelijkheid is. Niet alleen slecht voorbereide projecten zijn hier debet aan, maar ook karig beschreven tickets en een gebrek aan langetermijnvisie.

Er moet minstens een paar weken werk liggen voor een team; je moet niet verwachten dat je ontwikkelaars dagelijks naar je toekomen om te vragen wat ze nu weer mogen doen.

[Mercatres]

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:07:
Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

Een goede retro houden helpt ook af en toe

[Jan_V]

alienfruit schreef op maandag 21 augustus 2017 @ 22:47:
Nieuwe notebook inrichten altijd leuk 😄

#Feed: https://chocolatey.org/packages

#Install Chocolatey

Set-ExecutionPolicy -Scope CurrentUser Unrestricted

Set-ExecutionPolicy Unrestricted

iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex


Get-PackageProvider -Name chocolatey

Get-PackageProvider -Name nuget

#Update Chocolatey

choco upgrade chocolatey


#Normal software

choco install keepass -y

choco install 7zip.install -y

choco install firefox -y

refreshenv

choco install googlechrome -y

refreshenv

choco install itunes -y

refreshenv

#choco install icloud -y #Should done later when Outlook is properly configured

refreshenv

choco install crashplan -y

refreshenv

choco install slack -y

choco install inputdirector -y

#choco install paint.net -y #Does not have checksums, discarded.

choco install sublimetext3 -y

choco install vlc -y

refreshenv

choco install adobereader -y

refreshenv

choco install rdcman -y

refreshenv

#choco install spotify

refreshenv


#Development software IDE

choco install visualstudiocode -y

choco install visualstudio2015enterprise -y


#Development software tooling

choco install beyondcompare -y

choco install fiddler4 -y

refreshenv

#choco install resharper-platform -y #Gaat beter via de reguliere installer

refreshenv

choco install git.install -y

refreshenv

#choco install github -y #Has wrong checksum

refreshenv

choco install sourcetree -y

refreshenv

choco install gitextensions -y

refreshenv

#choco install vmwareworkstation

choco install nodejs.install -y

refreshenv

choco install zoomit -y

#choco install python2 -y

refreshenv

choco install python -y

refreshenv

choco install gitkraken -y

refreshenv

choco install filezilla -y

choco install openlivewriter -y

choco install teamviewer -y

Parasol uitklappen, koffie halen en 2 uurtjes wachten.
Winning!

[Tarkin]

Mercatres schreef op dinsdag 22 augustus 2017 @ 13:29:
[...]

Een goede retro houden helpt ook af en toe

Jup, daar is de afwachtende houding naar boven gekomen 1.5u aan het sleuren geweest om maar een antwoordje te krijgen. Goed of slecht; Zitten ze allemaal als een bende schapen naar je te kijken

CodeCaster schreef op dinsdag 22 augustus 2017 @ 13:17:
[...]

Ik zie doorgaans dat de motivatie keldert als er onduidelijkheid is. Niet alleen slecht voorbereide projecten zijn hier debet aan, maar ook karig beschreven tickets en een gebrek aan langetermijnvisie.

Er moet minstens een paar weken werk liggen voor een team; je moet niet verwachten dat je ontwikkelaars dagelijks naar je toekomen om te vragen wat ze nu weer mogen doen.

Het is eerder een iets in de trant van geen zin hebben in agile denk ik. Onder het motto we ondergaan de meetings en doen dan onze eigen zin en je zal wel iets krijgen dat werkt...

Het maffe is dat er mensen bijzijn die hier al een paar jaar zitten in een agile context en dat het sinds kort slechter lijkt te gaan. Ben nog aan het uitzoeken waarom

[ Voor 53% gewijzigd door Tarkin op 22-08-2017 13:57 ]

[Hydra]

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:56:
Het is eerder een iets in de trant van geen zin hebben in agile denk ik. Onder het motto we ondergaan de meetings en doen dan onze eigen zin en je zal wel iets krijgen dat werkt...

Het is wel belangrijk dat de voordelen van agile duidelijk gemaakt worden; het is in principe de bedoeling dat het meer zelfsturend wordt dus minder opgelegde zaken en als het goed is ook minder en kortere meetings.

Daarnaast is een voordeel van Scrum dat je proces meer inzichtelijk wordt. Maar dat is voor sommige developers meteen een groot nadeel; het wordt transparanter dus doen alsof je het druk hebt is er niet meer bij; "je ziet wel wanneer is af is" heeft geen plaats in software engineering.

[Dark Blue]

Zo, ik zeg weer eens hallo. 'Hallo!'

Na een aantal jaar in /13 (en /31, puberen), en daarna een aantal jaar totaal geen GoT, ben ik hedentendage junior developer, en ik merk dat ik veel ontwikkelingen mis. Dat vindt m'n werkgever voor een junior niet zo erg, maar ik wel. Leren zal ik!

Dus kom ik hier meelurken opdat ik wat meer Python, Django, en omliggende platformen in mijn hoofd krijg.
/14 staat gebookmarked! Hopelijk kan ik gauw wat bijdragen leveren.

[Alex)]

Tarkin schreef op dinsdag 22 augustus 2017 @ 13:07:
Een agile team dat er precies niet veel zin in heeft en een afwachtende houding aanhoudt, hoe kan je dat het beste counteren?

Geen agile opdringen?

Agile werken is een mindset, als het hele team er collectief geen zin in heeft moet daar eens over gepraat worden.

[Tarkin]

Hydra schreef op dinsdag 22 augustus 2017 @ 14:26:
[...]


Het is wel belangrijk dat de voordelen van agile duidelijk gemaakt worden; het is in principe de bedoeling dat het meer zelfsturend wordt dus minder opgelegde zaken en als het goed is ook minder en kortere meetings.

Daarnaast is een voordeel van Scrum dat je proces meer inzichtelijk wordt. Maar dat is voor sommige developers meteen een groot nadeel; het wordt transparanter dus doen alsof je het druk hebt is er niet meer bij; "je ziet wel wanneer is af is" heeft geen plaats in software engineering.

Ik probeer het om zo zelfsturend mogelijk te maken. Maar keer op keer moet je eraan sleuren om er iets uit te krijgen. Wel klagen over het feit dat de stories niet technisch geanalyseerd zijn, maar als je dan voorstelt om het tijdens de sprint te doen zodat we volgende sprint met deftig geanalyseerde stories kunnen beginnen, tja daar hebben ze dan ook geen zin in;

Alex) schreef op dinsdag 22 augustus 2017 @ 14:44:
[...]

Geen agile opdringen?

Agile werken is een mindset, als het hele team er collectief geen zin in heeft moet daar eens over gepraat worden.

Mja, dat was ook al op m'n gedachten gekomen. Maar het feit dat ze hier al jaren zo werken + iedereen die hier binnenkomt krijgt de vraag of ze het zien zitten om agile te werken..

Je zou denken dat er wat meer positivisme is hiervoor.

Het is ook een subset van mensen die er geen zin in lijkt te hebben. Het wordt tijd om eens een iets andere dan gewoonlijke retro te doen vrees ik

[whoami]

Tarkin schreef op dinsdag 22 augustus 2017 @ 15:03:
[...]

Ik probeer het om zo zelfsturend mogelijk te maken. Maar keer op keer moet je eraan sleuren om er iets uit te krijgen. Wel klagen over het feit dat de stories niet technisch geanalyseerd zijn, maar als je dan voorstelt om het tijdens de sprint te doen zodat we volgende sprint met deftig geanalyseerde stories kunnen beginnen, tja daar hebben ze dan ook geen zin in;

In een bedrijf waar ik gewerkt heb, was het zo dat je tijdens een sprint eerst bugs moest oppikken, indien geen bugs, analyse taken oppikken, en dan pas ontwikkeltaken.
Dan moet diegene die de sprints inplant er natuurlijk wel voor zorgen dat je een gezonde mix hebt van deze 3 types workitems.

[Tarkin]

whoami schreef op dinsdag 22 augustus 2017 @ 15:13:
[...]
In een bedrijf waar ik gewerkt heb, was het zo dat je tijdens een sprint eerst bugs moest oppikken, indien geen bugs, analyse taken oppikken, en dan pas ontwikkeltaken.
Dan moet diegene die de sprints inplant er natuurlijk wel voor zorgen dat je een gezonde mix hebt van deze 3 types workitems.

Dan komen we niet aan de nieuwe ontwikkeltaken

Groot project waarvan de software fixed price is opgeleverd door een ander bedrijf (daarvan komt dus ook al een groot deel van de frustratie). We proberen het nu zo te doen dat een deel van de tijd bugfixing is, een ander deel van de tijd nieuw development.

Het is niet zozeer dat ze niet goed developen ofzo, het werk is goed gedaan. Het is alleen de communicatie en het hele agile gebeuren waar ze geen zin in hebben.

[whoami]

Tarkin schreef op dinsdag 22 augustus 2017 @ 15:54:
[...]


Dan komen we niet aan de nieuwe ontwikkeltaken

Vandaar dat ik zeg dat diegene die de sprint inplant hier een verantwoordelijkheid heeft zodanig dat de analyse-taken en bugs niet alle beschikbare tijd innemen.

[Verwijderd]

Wat vinden jullie eigenlijk van die "serverless computing" hype?

[TheNephilim]

Verwijderd schreef op dinsdag 22 augustus 2017 @ 17:17:
Wat vinden jullie eigenlijk van die "serverless computing" hype?

Ik moest even Googelen (https://en.wikipedia.org/wiki/Serverless_computing), maar volgens mij is dat niet verkeerd.

Normaal gesproken koop je x capaciteit in, waarbij je rekening moet houden met (bijv.) één piekuur per dag waarbij je alle capaciteit nodig hebt. De rest van de dag staat de capaciteit die je over hebt 'niks te doen'.

Dus dat je met 'serverless computing', waarbij je alleen betaald voor waar je gebruik van maakt, misschien geld bespaart is dat mooi natuurlijk.

[alienfruit]

Gaaf hoor, een nieuwe notebook gekregen van Apple en nu werkt mijn bluetooth Muis weer zonder om de haverklap de Bluetooth verbinding te verliezen. Happy days!

[RayNbow]

whoami schreef op dinsdag 22 augustus 2017 @ 09:06:
[...]

Hoezo ? Hoe kan dit bv

code:

SELECT SUM(Amount) FROM Table

nog expressiever ?

Ik doelde met expressiever vooral op het stuk dat volgde:

[...]
Hoe zou je een resultset in C# bv als een first-class citizen gaan voorstellen ? Lijkt me niet zo simpel,

In SQL zelf is een resultset geen first-class citizen. Het resultaat van een query is een resultset waarvan de rijen bestaan uit primitieve tuples. De waarde in een kolom van een rij kan zelf geen resultset zijn.

[...]

Je stelt gewoon LINQ to SQL voor

Ssshhh...

(Al genereert LINQ to SQL vziw platte SQL strings die naar de database engine gestuurd worden. Het zou mooi zijn als database engines in feite de LINQ operatoren 'natively' zouden ondersteunen.)

Hydra schreef op dinsdag 22 augustus 2017 @ 09:24:
[...]

Kun je voorbeelden geven?

[...]

Idem hier; hoe zie je dat voor je?

Een willekeurig voorbeeld:

Python:

import sqlite3
conn = sqlite3.connect(':memory:')

conn.executescript('''
CREATE TABLE Users(id INTEGER PRIMARY KEY ASC, name TEXT);
CREATE TABLE Orders(
   id INTEGER PRIMARY KEY ASC, 
   product TEXT, 
   value INT, 
   user INTEGER, 
   FOREIGN KEY(user) REFERENCES Users(id)
);
''')


conn.executescript('''
INSERT INTO Users VALUES (1, 'Jan');
INSERT INTO Users VALUES (2, 'Klaas');
INSERT INTO Users VALUES (3, 'Piet');
''')


conn.executescript('''
INSERT INTO Orders VALUES (1, 'TV', 600, 1);
INSERT INTO Orders VALUES (2, 'meubel', 200, 1);
INSERT INTO Orders VALUES (3, 'koelkast', 400, 1);

INSERT INTO Orders VALUES (4, 'pc', 2000, 3);
INSERT INTO Orders VALUES (5, 'auto', 15000, 3);
''')

for row in conn.execute('''
SELECT Users.name, Orders.product
FROM Users LEFT JOIN Orders ON Users.id = Orders.user
'''):
    print row

Uitvoer:

(u'Jan', u'TV')
(u'Jan', u'koelkast')
(u'Jan', u'meubel')
(u'Klaas', None)
(u'Piet', u'auto')
(u'Piet', u'pc')

Wat in SQL echter niet mogelijk is, is een query verzinnen die het volgende resultaat produceert:

(u'Jan', [(u'TV',), (u'koelkast',), (u'meubel',)])
(u'Klaas', [])
(u'Piet', [(u'auto',), (u'pc',)])

[Ludwig005]

Hipska schreef op dinsdag 22 augustus 2017 @ 12:31:
[...]

Doe ik iets mis? Al een aantal dagen probeer ik die site te bezoeken en krijg telkens een 404.

ik krijg dat ook sinds gisterenavond. ik snap niet wat ze met hun gameservers gedaan hebben.

[Hydra]

Tarkin schreef op dinsdag 22 augustus 2017 @ 15:03:
Ik probeer het om zo zelfsturend mogelijk te maken. Maar keer op keer moet je eraan sleuren om er iets uit te krijgen. Wel klagen over het feit dat de stories niet technisch geanalyseerd zijn, maar als je dan voorstelt om het tijdens de sprint te doen zodat we volgende sprint met deftig geanalyseerde stories kunnen beginnen, tja daar hebben ze dan ook geen zin in;

Sorry hoor. Maar wat de fuck? "Geen zin in"? Je shit op orde hebben voordat je eraan begint is gewoon je werk doen. Misschien tijd om een paar van de grootste geenzinhebbers er subiet uit te flikkeren om een voorbeeld te stellen.

Dit is nieteens Scrum eigen. Hier heb je een term voor; refinement, maar dat is gewoon een stukje tijd dat je pakt om met je team te bedenken wat je gaat bouwen en hoe de volgende sprint. Als mensen daar "geen zin in" hebben, hebben ze geen zin in hun werk doen. En dan zou ik als werkgever ook geen zin hebben salaris uit te betalen.

Verwijderd schreef op dinsdag 22 augustus 2017 @ 17:17:
Wat vinden jullie eigenlijk van die "serverless computing" hype?

Hoezo hype? Het is een verdere evolutie van microservices waar het concept 'applicatie' met daaronder een 'server' verder weggeabstraheerd wordt. Niet echt een hype; AWS lambda's bijvoorbeeld werken erg leuk.

[ Voor 57% gewijzigd door Hydra op 22-08-2017 20:30 ]

[Alex)]

Hydra schreef op dinsdag 22 augustus 2017 @ 20:27:
[...]


Sorry hoor. Maar wat de fuck? "Geen zin in"? Je shit op orde hebben voordat je eraan begint is gewoon je werk doen. Misschien tijd om een paar van de grootste geenzinhebbers er subiet uit te flikkeren om een voorbeeld te stellen.

Dit is nieteens Scrum eigen. Hier heb je een term voor; refinement, maar dat is gewoon een stukje tijd dat je pakt om met je team te bedenken wat je gaat bouwen en hoe de volgende sprint. Als mensen daar "geen zin in" hebben, hebben ze geen zin in hun werk doen. En dan zou ik als werkgever ook geen zin hebben salaris uit te betalen.

Het is makkelijk om te zeggen dat ze meer Agile moeten zijn, maar als niemand het voortouw neemt om te laten zien waarom Agile een prettige werkwijze is voor dat bedrijf, dan zal er weinig gebeuren.

Ik ben benieuwd naar de samenstelling van dat team en de evolutie die de leden de afgelopen jaren hebben doorgemaakt. Zijn het bijvoorbeeld juniors die al jaren op dat niveau zitten en nooit zijn gegroeid (en verwachten dat ze hapklare brokken krijgen), of zijn het senioren die tegen het spreekwoordelijke plafond zitten en bijna aan hun pensioen toe zijn?

Ik ben zelf niet louter positief over Agile of Scrum maar ik zie wel de meerwaarde die het kan bieden - als de omgeving tenminste ook op zo'n manier werkt. Scrum in een klassieke mastodont-enterprise zal niet echt lekker werken omdat je dan al snel te maken krijgt met processen, procedures en andere teams/groepen die absoluut niet Agile werken.

[Hydra]

Alex) schreef op dinsdag 22 augustus 2017 @ 20:40:
Ik ben zelf niet louter positief over Agile of Scrum maar ik zie wel de meerwaarde die het kan bieden - als de omgeving tenminste ook op zo'n manier werkt. Scrum in een klassieke mastodont-enterprise zal niet echt lekker werken omdat je dan al snel te maken krijgt met processen, procedures en andere teams/groepen die absoluut niet Agile werken.

Hier bij de ING werkt het prima hoor, al het "geen zin" volk is eruit geknikkerd.

[alienfruit]

Het is juist belangrijk om tijd te nemen om de refinement te doen. Niemand vind het leuk om dubbel of driedubbel werk te doen. Omdat bij aanvang de requirements niet duidelijk was of omdat Technisch Analist niet alles goed begrepen heeft of de UX-designer niet de beperkingen qua data inzichtelijk had.

Ik neem er liever tijd voor dan later meuk opnieuw te moeten doen zonder dat de deadline opschuift en dus stress

[Alex)]

Onze refinements zijn meestal vrij snel klaar. Maar het developmentteam en de PO voelen elkaar dan ook erg goed aan, een half woord is vaak al genoeg. Dat is wel fijn.

[RagingPenguin]

Van een team dat agile/Scrum niet zo ziet zitten zou ik verwachten dat ze schijt hebben aan het scrumboard bijhouden en hele userstories per sprint uitwerken. Niet dat ze compleet in elkaar zakken en nergens zin meer in hebben.

Waarschijnlijk is er wel meer aan de hand en is Scrum meer iets waar makkelijk op af valt te geven zonder dat je echt inhoudelijk hoeft te reflecteren op je eigen functioneren. (ik zelf zou denken dat er meerdere mensen totaal niet op hun plek zitten in dat team)

[Alex)]

RagingPenguin schreef op dinsdag 22 augustus 2017 @ 21:06:
Van een team dat agile/Scrum niet zo ziet zitten zou ik verwachten dat ze schijt hebben aan het scrumboard bijhouden en hele userstories per sprint uitwerken. Niet dat ze compleet in elkaar zakken en nergens zin meer in hebben.

Als je als team collectief in elkaar zakt en nergens meer zin in hebt, is dat uiteindelijk vooral funest voor jezelf. Je eindejaarsbeoordeling zal dan niet veel hoger uitkomen dan "doet wat er van 'm wordt verwacht" wat weer negatieve gevolgen heeft voor je salarisontwikkeling, promotiekansen, enzovoorts.

Als het team het agile-spelletje meespeelt, maar wel hoge eisen stelt aan de stories, levert dat de leden uiteindelijk meer op. Dat het bedrijf daarvan profiteert is niet vanzelfsprekend.

Waarschijnlijk is er wel meer aan de hand en is Scrum meer iets waar makkelijk op af valt te geven zonder dat je echt inhoudelijk hoeft te reflecteren op je eigen functioneren. (ik zelf zou denken dat er meerdere mensen totaal niet op hun plek zitten in dat team)

Er kunnen allerlei redenen zijn waarom mensen "niet zo'n zin hebben" in Agile. Dat kan zijn omdat ze liever op de watervalmanier werken, omdat de omgeving agile niet stimuleert of zelfs frustreert ("scrumbuts") of omdat ze vinden dat er te veel wordt gepraat en te weinig wordt gedaan.

Een goede retrospective kan helpen om dit boven water te krijgen, maar dan moet het team wel het vertrouwen hebben dat ze vrijuit kunnen spreken tegenover de scrum master / project manager / agile-akela. Als het team bang is dat ze later kunnen worden afgerekend op dingen die ze tijdens een retrospective zeggen, zul je nooit de waarheid boven tafel krijgen.

Notities die tijdens een retrospective worden gemaakt zouden bijvoorbeeld niet buiten het team gedeeld moeten worden zonder dat het team daarmee instemt.

[ Voor 13% gewijzigd door Alex) op 22-08-2017 23:32 ]

[Canaria]

Dark Blue schreef op dinsdag 22 augustus 2017 @ 14:43:
Zo, ik zeg weer eens hallo. 'Hallo!'

Na een aantal jaar in /13 (en /31, puberen), en daarna een aantal jaar totaal geen GoT, ben ik hedentendage junior developer, en ik merk dat ik veel ontwikkelingen mis. Dat vindt m'n werkgever voor een junior niet zo erg, maar ik wel. Leren zal ik!

Dus kom ik hier meelurken opdat ik wat meer Python, Django, en omliggende platformen in mijn hoofd krijg.
/14 staat gebookmarked! Hopelijk kan ik gauw wat bijdragen leveren.

vrouwelijke developers take over!

Ik ben na tien jaar SharePoint ook iets anders gaan doen: Umbraco- en Sitecore-development. Als SharePoint-freelancer heb ik de afgelopen periode heel veel tijd geïnvesteerd in Treehouse en Pluralsight. Nu nog geen jaar later ben ik in zowel Umbraco als Sitecore gecertificeerd.

In SharePoint was ik ook vooral bezig met WCM maar dat voelde toch een beetje als met te kleine schoenen een marathon hordelopen. En dan is het met perfect passende schoenen en zonder horden op de weg heel wat comfortabeler en makkelijker. De medaille na afloop is weliswaar iets minder groot, maar whatever. De tijd van per se de grootste medaille willen showen ligt inmiddels achter me, voor zover ik daar ooit aan mee heb gedaan. For what it's worth, ik ben mijn toenmalige manager nog steeds dankbaar dat hij ooit tegen me zei: "je moet SharePoint gaan leren, daar zit een gouden toekomst in!"

Grootste compliment dat ik de afgelopen tijd heb ontvangen: "je programmeert als een man!"

[gekkie]

RayNbow schreef op dinsdag 22 augustus 2017 @ 18:02:
[...]
Wat in SQL echter niet mogelijk is, is een query verzinnen die het volgende resultaat produceert:

(u'Jan', [(u'TV',), (u'koelkast',), (u'meubel',)])
(u'Klaas', [])
(u'Piet', [(u'auto',), (u'pc',)])

In "standaard" SQL vast niet, maar er zijn wel sql databases die een ARRAY_AGG() hebben.

[whoami]

Hoe bevalt dat Sitecore eigenlijk ?
Ik kon vorig jaar ergens beginnen waar men ook gebruik maakte van Sitecore voor alle web-applicaties die ze ontwikkelden. Uiteindelijk toch niet toegehapt juist vanwege Sitecore. Dat was volgens mij een zodanige niche dat ik bang was om daarin vast te komen zitten.

[RayNbow]

gekkie schreef op woensdag 23 augustus 2017 @ 00:07:
[...]

In "standaard" SQL vast niet, maar er zijn wel sql databases die een ARRAY_AGG() hebben.

Ik zie dat je met ARRAY_AGG in ieder geval arrays van een enkel veld kunt hebben. Kun je ook een arrays van tuples hebben? Bijv.:

(u'Jan', [(u'TV', 600), (u'koelkast', 200), (u'meubel', 400)])
(u'Klaas', [])
(u'Piet', [(u'auto', 15000), (u'pc', 2000)])

[Hydra]

Alex) schreef op dinsdag 22 augustus 2017 @ 23:24:
agile-akela.

Stealing that...

Canaria schreef op dinsdag 22 augustus 2017 @ 23:49:
Grootste compliment dat ik de afgelopen tijd heb ontvangen: "je programmeert als een man!"

Dat een man dat tegen je zegt, daar gaan me de haren van overeind staan. Hij heeft nog nooit van Margaret Hamilton gehoord waarschijnlijk.

[ Voor 54% gewijzigd door Hydra op 23-08-2017 08:53 ]

[whoami]

of Barbara Liskov

[RayNbow]

...of Ada?

[farlane]

Hydra schreef op woensdag 23 augustus 2017 @ 08:49:
Hij heeft nog nooit van Margaret Hamilton gehoord waarschijnlijk.

Ik nu wel ....

[whoami]

farlane schreef op woensdag 23 augustus 2017 @ 09:08:
[...]


Ik nu wel ....

Dus, jij hebt Canaria dat compliment gegeven ?

[farlane]

whoami schreef op woensdag 23 augustus 2017 @ 09:16:
Dus, jij het Canaria dat compliment gegeven ?

Toegegeven, ik ben een pummel maar de opmerking zelf vind ik behoorlijk arrogant (aangenomen dat de spreker een man was, anders was het waarschijnlijk een sneer )

[Firesphere]

Hydra schreef op woensdag 23 augustus 2017 @ 08:49:

[...]


Dat een man dat tegen je zegt, daar gaan me de haren van overeind staan. Hij heeft nog nooit van Margaret Hamilton gehoord waarschijnlijk.

Dit.

[Neko Koneko]

Canaria schreef op dinsdag 22 augustus 2017 @ 23:49:
[...]
Grootste compliment dat ik de afgelopen tijd heb ontvangen: "je programmeert als een man!"

Dus ze hebben eindelijk de comment regels met ASCII boobs in je code gevonden?

[whoami]

farlane schreef op woensdag 23 augustus 2017 @ 09:20:
[...]

Toegegeven, ik ben een pummel maar de opmerking zelf vind ik behoorlijk arrogant (aangenomen dat de spreker een man was, anders was het waarschijnlijk een sneer )

Ik eigenlijk ook. Ik zou dat iig niet echt als een compliment opnemen.

[Cloud]

Wat een opmerking is dat zeg Het zal denk ik wel als een compliment bedoeld zijn maar het klinkt inderdaad wel verschrikkelijk arrogant.

[CodeCaster]

Over de agile-discussie: het hele probleem wat Agile niet oplost is slecht omschreven en slecht gepland werk.

Op veel plekken waar ik heb gewerkt, bestaat een task of user story enkel uit een titel, en komen soms ook zo in de refinement terecht. Daar heb je een Definition of Ready voor, maar die wordt vaak keihard genegeerd.

Daarnaast vind ik het lastig om te bepalen wanneer er een technisch ontwerp gemaakt en bijbehorende discussies gevoerd moeten worden. In ieder geval níet tijdens de refinement, want dan duurt 'ie te lang.

Stel, je hebt een user story waar nieuw te bouwen functionaliteit voor gemaakt moet worden, dan wil ik, voordat ik ook maar begin met een schatting af te geven, weten wat de impact van de wijziging is (welke andere systemen raakt het, zijn er mogelijk issues met backwards compatibility), welke oplossingsrichtingen zijn overwogen en hoe we het geheel gaan testen en opleveren (acceptatiecriteria).

Wat ik de afgelopen paar jaren eigenlijk telkens weer heb zien gebeuren, is dat die discussie tóch tijdens de refinement wordt gevoerd, dat er iemand de eerste beste oplossing in de groep gooit die diegene kan bedenken, en dat er verder (wellicht door gebrek aan overzicht over het hele systeem) niet tegenin wordt gegaan, en dan tijdens reviewen, testen, uitrollen of zelfs gebruik pas blijkt dat die oplossing helemaal niet de beste was, laat staan gedocumenteerd is.

Ik ben heel goed in van tevoren bedenken wat er allemaal mis kan gaan, maar heb dan niet altijd direct de oplossing paraat. Dus dan wint degene die wél een oplossing voor handen heeft, hoe brak en ondoordacht die dan ook is. Terwijl ik juist even de tijd wil nemen om alternatieven te bedenken en tegen elkaar af te wegen.

Daarnaast wordt die oplossing noch de afweging dan in het betreffende ticket geüpdatet, noch de wiki bijgewerkt, dus de gekozen oplossing moet je dan maar uit de codewijzigingen en commitmessages halen. Dat zorgt voor vervelende reviews met veel geheenenweer ("Waarom heb je voor aanpak X gekozen en niet Y?").

Maar misschien wordt het ook gewoon tijd voor mij om een andere categorie opdrachtgevers te gaan aanboren.

Bij iedere nieuwe opdracht moet ik weer vechten voor dat het team zich gaat houden aan de Definition of Ready en Definition of Done, het opstellen van acceptatiecriteria, het houden van design meetings, het toepassen of uitbreiden van de coverage van unittests, het schrijven van uitrolinstructies en het maken van rollback-plannen en/of -scripts.

[.oisyn]

RayNbow schreef op woensdag 23 augustus 2017 @ 09:05:
...of Ada?

Ik wilde het net zeggen

[SPee]

Jan_V schreef op dinsdag 22 augustus 2017 @ 13:43:
[...]
Parasol uitklappen, koffie halen en 2 uurtjes wachten.
Winning!

Ik wou mijn nieuwe laptop ook inrichten mbv Chocolately. Maar toen ik zag dat enkele van mijn programma's meerdere versies achterliepen, heb ik daar maar toch vanaf gezien.
De package heeft versie 3.4, in de comments van 4mnd geleden staat "versie 3.5 is uit, please update" met antwoord "probably tomorrow" en er is een pull request voor 4.1.
Toen ontdekte ik ook dat ze een eigen bin directory bijhouden, waardoor los updaten moeilijk is en ik was er klaar mee.

Dus ik heb de installatie op de "oude" manier gedaan. Kan je ook beter de licenties in de gaten houden (werk pc) en zonder de consumenten programma's.
Het meeste werk zit nog altijd in de data en instellingen overzetten. En ik moet de Virtualbox images nog overzetten naar Hyper-V. Geweldig dat docker-for-windows


En werken vanuit een enkele regel: hoe herkenbaar. Ik denk ook niet dat het beter gaat worden. Mijn huidig project is "wij moeten het systeem testen". Dus dan is het "making up as you go", "fake it" en zelf iets bedenken.

[EddoH]

Pfff....ik begin zo erg aan mezelf te twijfelen vandaag...

Waarom zou iemand een UART (oftewel, simpel bytes versturen) API zo maken, dat de send functie een pointer naar een buffer van 32 bits elementen(u_int32 *) verwacht, met een size argument in bytes?

Ben ik nou zo dom, of is dit totaal krankzinnig?

[Tarkin]

@Hele agile discussie, Ik moet het nog even allemaal op een rijtje zetten maar wss zal ik er hier wel een topic voor openen.

Het is vooral een combinatie van voorheen gezegde zaken.
-gekochte applicatie die niet goed begrijpbaar is
-motivatieproblemen
-Agile niet optimaal uitgevoerd (of hoe zeg je dat )
-...

Ik moet vooral eens nadenken hoe ik het hier terug in de positieve richting kan draaien. Er zijn alleszinds teamleden die me hierbij willen helpen en hun schouders eronder zetten. TBC

[Defector]

Tarkin schreef op woensdag 23 augustus 2017 @ 13:15:
@Hele agile discussie, Ik moet het nog even allemaal op een rijtje zetten maar wss zal ik er hier wel een topic voor openen.

Het is vooral een combinatie van voorheen gezegde zaken.
-gekochte applicatie die niet goed begrijpbaar is
-motivatieproblemen
-Agile niet optimaal uitgevoerd (of hoe zeg je dat )
-...

Ik moet vooral eens nadenken hoe ik het hier terug in de positieve richting kan draaien. Er zijn alleszinds teamleden die me hierbij willen helpen en hun schouders eronder zetten. TBC

Heb ook wel eens motivatie problemen gehad als dev. En dat kwam vooral door de overkill aan vergaderingen/meetings/stand-ups/refinements/retrospectives. Dat er van het daadwerkelijke werken aan de sprint niet veel terecht kwam. Dit had weer resultaat op de output tijdens de sprint. Dit werd dus weer een groot punt in de retrospective, waardoor die weer uitliep. Dus je was weer een dag aan het vergaderen hoe dat nou beter kon.

Een van de punten was de hele tijd wel duidelijk, maar werd niet echt goed opgepakt. Was dat de story's niet van goede kwaliteit waren. Niet echt goed te begrijpen behalve door de mensen die er direct bij betrokken waren. Niet echt duidelijk wat nou de definition of done was. Een van de oplossingen was om meer in te zetten op de refinements. Maar ik kan je wel vertellen dat een refinement van 4/6 uur killing is. En daarna produceer je ook weinig meer.

Dus uiteindelijk waren we meer bezig met het process dan het programmeer werk wat moest gebeuren.

Het is een hele rant geworden, en ik weet niet of je er wat aan hebt. Maar wel een praktijk ervaring.

[ Voor 3% gewijzigd door Defector op 23-08-2017 13:30 ]

[farlane]

EddoH schreef op woensdag 23 augustus 2017 @ 12:21:
Pfff....ik begin zo erg aan mezelf te twijfelen vandaag...

Waarom zou iemand een UART (oftewel, simpel bytes versturen) API zo maken, dat de send functie een pointer naar een buffer van 32 bits elementen(u_int32 *) verwacht, met een size argument in bytes?

Ben ik nou zo dom, of is dit totaal krankzinnig?

Als de data(byte) ook "control/status bits" kan bevatten? Not saying dat het een goed ontwerp is, maar zoiets ben ik wel eens tegen gekomen in een receive buffer die dan aangaf bij welk byte een parity error was opgetreden geloof ik.

[gekkie]

RayNbow schreef op woensdag 23 augustus 2017 @ 07:28:
[...]

Ik zie dat je met ARRAY_AGG in ieder geval arrays van een enkel veld kunt hebben. Kun je ook een arrays van tuples hebben? Bijv.:

(u'Jan', [(u'TV', 600), (u'koelkast', 200), (u'meubel', 400)])
(u'Klaas', [])
(u'Piet', [(u'auto', 15000), (u'pc', 2000)])

PostgreSQL allows columns of a table to be defined as variable-length multidimensional arrays. Arrays of any built-in or user-defined base type, enum type, or composite type can be created. Arrays of domains are not yet supported.

[DevWouter]

Hydra schreef op dinsdag 22 augustus 2017 @ 13:09:
[...]


Waar heb je dat vandaan? Het is gebaseerd op het paper van Codd en een vrij letterlijke vertaling van zijn relationele model. Voorlopende query methoden waren niet erg leesbaar en an sich was dat wel een doel van SEQUEL net zoals dat een doel is van de meeste hedendaagse talen. Maar ik vind dat "zonder tussenkomst van een ontwikkelaar" nogal vergezocht. Relationele algebra is geen onderdeel van de gemiddelde MBA vermoed ik

Oh, daar heb ik een hele goeie bron voor: Het is een opmerking die een oud werkgever ooit maakte.

Na wat onderzoek kwam ik het volgende tegen in een paper van IBM (3~4 jaar na die van Codd) en daarin staat het volgende:

These rules are intended to simplify programming for the professional and to make data base interaction available to a new class of users.

A brief discussion of this new class of users is in order here. There are some users whose interaction with a computer is so infrequent or unstructured that the user is unwilling to learn a query language. For these users, natural language or menu selection (3,4) seem to be the most viable alternatives. However, there is also a large class of users who, while they are not computer specialists, would be willing to learn to interact with a computer in a reasonably high-level, non-procedural query language. Examples of such users are accountants, engineers, architects, and urban planners. It is for this class of users that SEQUEL is intended.

Bron: http://www.almaden.ibm.co...hamberlin/sequel-1974.pdf

[Hydra]

DevWouter schreef op woensdag 23 augustus 2017 @ 13:51:
Na wat onderzoek kwam ik het volgende tegen in een paper van IBM (3~4 jaar na die van Codd) en daarin staat het volgende:

Lol:

A brief discussion of this new class of users is in order here. There are some users whose interaction with a computer is so infrequent or unstructured that the user is unwilling to learn a query language. For these users, natural language or menu selection (3,4) seem to be the most viable alternatives. However, there is also a large class of users who, while they are not computer specialists, would be willing to learn to interact with a computer in a reasonably high-level, non-procedural query language. Examples of such users are accountants, engineers, architects, and urban planners. It is for this class of users that SEQUEL is intended.

Dus introduceren we een nieuwe query language

Ik denk dat je het in de context van die tijd moet zien en de voorlopers van SQL, die waren niet te lezen. Maar SQL heeft natuurlijk niks met de engelse taal te maken en is niet iets dat gebruikers die geen taal willen leren op gaan pakken. Maar het is een heel stuk meer laagdrempelig dan z'n voorgangers; dat was gewoon wiskunde

Defector schreef op woensdag 23 augustus 2017 @ 13:28:
Heb ook wel eens motivatie problemen gehad als dev. En dat kwam vooral door de overkill aan vergaderingen/meetings/stand-ups/refinements/retrospectives. Dat er van het daadwerkelijke werken aan de sprint niet veel terecht kwam. Dit had weer resultaat op de output tijdens de sprint. Dit werd dus weer een groot punt in de retrospective, waardoor die weer uitliep. Dus je was weer een dag aan het vergaderen hoe dat nou beter kon.

Tja. Scrum-but dus. Een bestaand proces wat al niet werkt en daar dan een extra proces bovenop plakken zonder de bron van het probleem aan te pakken werkt natuurlijk niet. Als je een goeie Scrum coach inhuurt is dat het eerste wat 'ie je vertelt. Als je een slechte inhuurt dan zit die gewoon lekker zoveel mogelijk uren te maken.

Scrum komt in plaats van je al dan niet bestaande processen en zou minder meetings moeten opleveren, niet meer. Een stand-up duurt bij ons tien minuten. De planning, retro, en demo duren elk een uur per 2 weken. De refinement sessies, wat gewoon software ontwerp is en dus een onderdeel is van je software engineering practice staan gepland op 3 uur per sprint maar duren meestal korter en heel af en toe, bij complexe zaken, iets langer. En dat is het wel.

[ Voor 33% gewijzigd door Hydra op 23-08-2017 14:00 ]

[DevWouter]

Hydra schreef op woensdag 23 augustus 2017 @ 13:55:
[...]


Lol:


[...]


Dus introduceren we een nieuwe query language

Ik denk dat je het in de context van die tijd moet zien en de voorlopers van SQL, die waren niet te lezen. Maar SQL heeft natuurlijk niks met de engelse taal te maken en is niet iets dat gebruikers die geen taal willen leren op gaan pakken. Maar het is een heel stuk meer laagdrempelig dan z'n voorgangers; dat was gewoon wiskunde

Helemaal mee eens. Je kan het ook heel makkelijk zien als een verkoop argument.

[Defector]

Hydra schreef op woensdag 23 augustus 2017 @ 13:55:
[...]

[...]


Tja. Scrum-but dus. Een bestaand proces wat al niet werkt en daar dan een extra proces bovenop plakken zonder de bron van het probleem aan te pakken werkt natuurlijk niet. Als je een goeie Scrum coach inhuurt is dat het eerste wat 'ie je vertelt. Als je een slechte inhuurt dan zit die gewoon lekker zoveel mogelijk uren te maken.

Scrum komt in plaats van je al dan niet bestaande processen en zou minder meetings moeten opleveren, niet meer. Een stand-up duurt bij ons tien minuten. De planning, retro, en demo duren elk een uur per 2 weken. De refinement sessies, wat gewoon software ontwerp is en dus een onderdeel is van je software engineering practice staan gepland op 3 uur per sprint maar duren meestal korter en heel af en toe, bij complexe zaken, iets langer. En dat is het wel.

Klopt dat was het ook en dat werd ook vaak genoeg aangegeven. Maarja daar werd niks meegedaan want. Scrum is hot en dus dat gaan we doen.

[EddoH]

farlane schreef op woensdag 23 augustus 2017 @ 13:31:
[...]

Als de data(byte) ook "control/status bits" kan bevatten? Not saying dat het een goed ontwerp is, maar zoiets ben ik wel eens tegen gekomen in een receive buffer die dan aangaf bij welk byte een parity error was opgetreden geloof ik.

Nee... het gaat echt puur en alleen om de data... De API zit ook nog eens in ROM, dus kan het niet fixen ook

Mompelt iets over Indiërs

[Hydra]

EddoH schreef op woensdag 23 augustus 2017 @ 12:21:
Pfff....ik begin zo erg aan mezelf te twijfelen vandaag...

Waarom zou iemand een UART (oftewel, simpel bytes versturen) API zo maken, dat de send functie een pointer naar een buffer van 32 bits elementen(u_int32 *) verwacht, met een size argument in bytes?

Die data staat al ergens in het geheugen. Het is een beetje onzinnig om daar dan een kopie in een nieuwe array van te maken. Of bedoel je dat niet?

[.oisyn]

Hydra schreef op woensdag 23 augustus 2017 @ 14:12:
[...]


Die data staat al ergens in het geheugen. Het is een beetje onzinnig om daar dan een kopie in een nieuwe array van te maken. Of bedoel je dat niet?

Je hoeft de boel niet te kopiëren om het als een ander type te interpreteren . Het maakt voor het versturende systeem ook niet zoveel uit wat de data is, het zijn gewoon bytes. De invoer had dus net zo goed een void* kunnen zijn, dan had je het alles kunnen voeren.

[Hydra]

.oisyn schreef op woensdag 23 augustus 2017 @ 14:28:
Je hoeft de boel niet te kopiëren om het als een ander type te interpreteren . Het maakt voor het versturende systeem ook niet zoveel uit wat de data is, het zijn gewoon bytes. De invoer had dus net zo goed een void* kunnen zijn, dan had je het alles kunnen voeren.

Ja, maar dan is het in essentie toch praktisch hetzelfde?

[EddoH]

Hydra schreef op woensdag 23 augustus 2017 @ 14:12:
[...]


Die data staat al ergens in het geheugen. Het is een beetje onzinnig om daar dan een kopie in een nieuwe array van te maken. Of bedoel je dat niet?

Wat .oisyn zegt.

En daarnaast gaat het fout als ik bijvoorbeeld 1 karakter uit een u_int8 buffer wil sturen, aangezien dit gecast moet wordt naar een u_int32*, en dat gaat niet goed als ik vervolgens 1 byte ga sturen.

[.oisyn]

Hydra schreef op woensdag 23 augustus 2017 @ 14:40:
[...]


Ja, maar dan is het in essentie toch praktisch hetzelfde?

Nee, want als het een void* is kun je er een pointer naar een HydrasOntzettendCooleData struct geven zonder dat de compiler klaagt. Nu loop je de hele tijd expliciet te casten naar u_int32

[Hydra]

.oisyn schreef op woensdag 23 augustus 2017 @ 14:42:
Nee, want als het een void* is kun je er een pointer naar een HydrasOntzettendCooleData struct geven zonder dat de compiler klaagt. Nu loop je de hele tijd expliciet te casten naar u_int32

Ah, zo. Thanks

[TheNephilim]

Github: "We're investigating reports of problems fetching raw and release content."

Meh, ik vroeg me al af waarom composer en npm zo moeilijk aan het doen waren . Net als je begint aan een nieuw project uiteraard...

[farlane]

EddoH schreef op woensdag 23 augustus 2017 @ 14:41:
Wat .oisyn zegt.

En daarnaast gaat het fout als ik bijvoorbeeld 1 karakter uit een u_int8 buffer wil sturen, aangezien dit gecast moet wordt naar een u_int32*, en dat gaat niet goed als ik vervolgens 1 byte ga sturen.

Daarnaast kan alignment een probleem opleveren.

Zit net te denken, misschien dat ze met deze brakke constructie een alignment proberen af te dwingen?

[EddoH]

farlane schreef op woensdag 23 augustus 2017 @ 15:54:
[...]

Daarnaast kan alignment een probleem opleveren.

Zit net te denken, misschien dat ze met deze brakke constructie een alignment proberen af te dwingen?

Hmmm goeie..tis wel een ARM. Alsnog een brakke constructie inderdaad, en ik ben er altijd wel bedacht op. Zet het dan gewoon in de documentatie/commentaar.

[Canaria]

whoami schreef op woensdag 23 augustus 2017 @ 00:08:
Hoe bevalt dat Sitecore eigenlijk ?
Ik kon vorig jaar ergens beginnen waar men ook gebruik maakte van Sitecore voor alle web-applicaties die ze ontwikkelden. Uiteindelijk toch niet toegehapt juist vanwege Sitecore. Dat was volgens mij een zodanige niche dat ik bang was om daarin vast te komen zitten.

Ik vind het wel wat. Niet zo clean en elegant als Umbraco maar wel fijn opgezet. Je wordt gedwongen om heel gestructureerd te werken en er moet voordat je begint al nagedacht zijn over de datastructuren. Ik vind het wel omslachtig om custom fieldtypes toe te voegen. En Umbraco compositions zijn intuïtiever maar ook beperkter dan Sitecore template inheritance om een entiteitenmodel op te zetten. Then again: de functionaliteit is er wel! Ik was met SharePoint gewend om dat allemaal zelf te moeten maken. Entiteiten in custom SharePoint Lists.

[.oisyn]

farlane schreef op woensdag 23 augustus 2017 @ 15:54:
Zit net te denken, misschien dat ze met deze brakke constructie een alignment proberen af te dwingen?

Except that it doesn't. Als je toch al moet casten, zal het de compiler geen zier boeien als je vanaf een pointer naar struct met andere alignment requirements cast.

[EddoH]

.oisyn schreef op woensdag 23 augustus 2017 @ 19:03:
[...]


Except that it doesn't. Als je toch al moet casten, zal het de compiler geen zier boeien als je vanaf een pointer naar struct met andere alignment requirements cast.

Dat is waar, maar misschien dacht iemand dat het een vorm van 'documentatie' duidelijkheid geeft.
Maar...neh...

Overigens vind ik net een stuk documentatie waar men wel bij de receivebuffers aangeeft dat die 32 bits aligned moeten zijn.
De reden daarachter snap ik op dit moment (vanuit hardware gezien) eigenlijk ook niet, behalve een brakke API implementatie..

[.oisyn]

EddoH schreef op woensdag 23 augustus 2017 @ 20:32:
[...]


De reden daarachter snap ik op dit moment (vanuit hardware gezien) eigenlijk ook niet

Waarschijnlijk een beperkt aantal adresbits in het betreffende hardwareregister

[EddoH]

.oisyn schreef op woensdag 23 augustus 2017 @ 20:42:
[...]

Waarschijnlijk een beperkt aantal adresbits in het betreffende hardwareregister

Nu gaan we de devschuur scope te buiten, maar kun je aangeven hoe het gebruik van 32bits aligned buffer de benodigde adresbits beperkt? Ik snap hem nog niet helemaal..

[.oisyn]

Je moet de UART hardware configureren, meestal door wat waardes te schrijven naar memory mapped hardware registers. Het adres van de receive buffer is een van de properties, maar ook dingen als data rate, stop bits, etc. Meestal zijn al de waardes efficient gepacked in slechts een paar ints. Als het adres altijd 32 bits aligned is, dan scheelt dat dus 2 adresbits - bit 0 en 1 van een 32 bit aligned adres is immers altijd 0.

[EddoH]

.oisyn schreef op woensdag 23 augustus 2017 @ 21:12:
... bit 0 en 1 van een 32 bit aligned adres is immers altijd 0.

Ah natuurlijk! Thanks.

De meeste uarts die ik in het verleden gebruikt heb las ik zelf uit de receive registers, en hoefde ik geen adressen te configureren. Dit, met een geleverde HAL, werkt even anders.

[Swedish Clown]

TheNephilim schreef op woensdag 23 augustus 2017 @ 15:36:
Github: "We're investigating reports of problems fetching raw and release content."

Meh, ik vroeg me al af waarom composer en npm zo moeilijk aan het doen waren . Net als je begint aan een nieuw project uiteraard...

Dát is dus precies de reden waarom wij in beginsel alles intern mirroren. Als je gebruik maakt van een library, mirror deze (incl. deps) intern.

Je zou maar net 's nachts uit je nest gebeld worden en geen release kunnen doen omdat Github op ze nek ligt.

Des te hoger de SLA, des te strikter het wordt

[farlane]

.oisyn schreef op woensdag 23 augustus 2017 @ 19:03:
[...]
Except that it doesn't.

I know, maar mss vond de ontwerper het de moeite waard om dat op deze manier te benadrukken.

EddoH schreef op woensdag 23 augustus 2017 @ 20:32:
[...]
Dat is waar, maar misschien dacht iemand dat het een vorm van 'documentatie' duidelijkheid geeft.
Maar...neh...
Overigens vind ik net een stuk documentatie waar men wel bij de receivebuffers aangeeft dat die 32 bits aligned moeten zijn.

Dat dus.

.oisyn schreef op woensdag 23 augustus 2017 @ 21:12:
Meestal zijn al de waardes efficient gepacked in slechts een paar ints.

"Vroeger" was dit tot in het uiterste doorgevoerd, maar met de moderne processoren (waar ik mee in aanraking kom dan he) geeft men tegenwoordig meer de voorkeur aan een logische indeling en wat minder aan het besparen van dat laatste bitje. Maargoed, het zou idd een reden kunnen zijn.

Neemt niet weg dat het nog immer bollox is om de alignment vereisten op die manier te communiceren.

[.oisyn]

Bij de moderne CPU's waarmee ik in aanmerking kom (GPU's) wordt er nog immer gigantisch gepacked, nog steeds om geheugen uit te sparen. En dan krijg je dus ook rare alignment requirements zoals 32kB voor een texture