De Devschuur Coffee Corner - Iteratie ⓫

[Tjolk]

@DevWouter dat bedoel ik dus met diplomatiek dingen brengen. Ik ben normaal gezien nogal recht voor zijn raap, maar waar dat in het bedrijfsleven al niet altijd tot de beste resultaten leidt, geldt dat bij vrijwilligerswerk nog veel meer natuurlijk. Uiteindelijk doen mensen het werk omdat ze het leuk vinden of zich in ieder geval willen inzetten voor de goede zaak (wat dat dan ook moge zijn). Je moet ze gemotiveerd houden.

Ik heb inmiddels ook voorgesteld om eens met de maker en de oude contentmanager te gaan zitten om wat dingen door te spreken en vooral ook kennis te maken. Dan ga ik natuurlijk geen tirade houden over wat er in mijn ogen mis is, maar gewoon wat lijntjes uitgooien en kijken hoe er gebeten kan worden.

Uiteindelijk denk ik echter wel dat er er een fundamenteel probleem aan kennis is bij de beste man. Als je alleen al dat stukje code ziet wat ik gepost heb, dan zit er op bijna iedere regel (accolades daargelaten) wel een fout. En bij de omliggende HTML die ik niet gepost heb is het niet veel beter. Komt bij; de website is pas 6 jaar geleden opgeleverd; het is niet dat we hier over een systeem uit het begin van de eeuw praten waarbij het gros nog niet beter wist; dit lever je gewoon niet op, zeker niet als professional. Ik wil en kan daar dan geen verantwoordelijkheid voor nemen.

[Creepy]

DevWouter schreef op woensdag 25 juli 2018 @ 10:05:
Moet ik nog popcorn meenemen?

[DevWouter]

@downtime Sorry, misschien kon ik iets duidelijker zijn. Ik ben het in geheel met jou wat betreft continuïteit echter kan ik het "druk zijn" niet plaatsen. Het komt bij mij over alsof je het advies gaf om "te doen alsof je altijd druk ben". Nu ik het herlees denk ik dat je het advies geef om altijd te zorgen dat je ervoor moet zorgen dat je exit-strategie hebt die maximaal 6 maanden mag kosten?

Tjolk schreef op woensdag 25 juli 2018 @ 14:00:
Je moet ze gemotiveerd houden.

Dat! Als je iemand kan motiveren ipv bekritiseren dan is het alleen een kwestie van geduld en kalmte bewaren. Zeker bij vrijwilligers werk waar alles veel langer op zich laat wachten.

Ik wens je in elk geval veel plezier je vrijwilligerswerk! Succes!

Creepy schreef op woensdag 25 juli 2018 @ 15:17:
[...]

[afbeelding]

* DevWouter gaat alvast een nieuwe zak halen

[downtime]

DevWouter schreef op woensdag 25 juli 2018 @ 15:36:
@downtime Sorry, misschien kon ik iets duidelijker zijn. Ik ben het in geheel met jou wat betreft continuïteit echter kan ik het "druk zijn" niet plaatsen.

Ik heb het woord "druk" pas gebruikt nadat jij het gebruikte.

Het komt bij mij over alsof je het advies gaf om "te doen alsof je altijd druk ben". Nu ik het herlees denk ik dat je het advies geef om altijd te zorgen dat je ervoor moet zorgen dat je exit-strategie hebt die maximaal 6 maanden mag kosten?

Het gaat mij inderdaad om die exit-strategie. Daar had ook 12 maanden kunnen staan maar de kern van het verhaal is dat de meeste vrijwilligers maar een beperkte periode actief zijn, om wat voor reden dan ook, en dat ze (anders dan bij een bedrijf) niet altijd opgevolgd worden door iemand met vergelijkbare skills.
Dus onderdruk die behoefte om een prachtige site op maat voor die vereniging te maken als je weet dat jij waarschijnlijk de enige bent die het ding kan onderhouden. Dan maar iets simpels in Wordpress maken. De vereniging zal jou er dankbaar voor zijn.

[DevWouter]

downtime schreef op woensdag 25 juli 2018 @ 16:00:
[...]

Ik heb het woord "druk" pas gebruikt nadat jij het gebruikte.


[...]

Het gaat mij inderdaad om die exit-strategie. Daar had ook 12 maanden kunnen staan maar de kern van het verhaal is dat de meeste vrijwilligers maar een beperkte periode actief zijn, om wat voor reden dan ook, en dat ze (anders dan bij een bedrijf) niet altijd opgevolgd worden door iemand met vergelijkbare skills.
Dus onderdruk die behoefte om een prachtige site op maat voor die vereniging te maken als je weet dat jij waarschijnlijk de enige bent die het ding kan onderhouden. Dan maar iets simpels in Wordpress maken. De vereniging zal jou er dankbaar voor zijn.

Mea culpa! Ik refereerde naar "doe alsof" wat ik vervolgens interpreteerde als "doe alsof je druk bent" om dat vervolgens weer in te korten als "druk te wezen"/"druk zijn".

Of was twee keer fout gelijk aan 1 keer goed?

[whoami]

OData, is dat nog een ding ? Is dat iets waar er nog aandacht aan geschonken wordt ?
/dtv

[Vincentio]

whoami schreef op donderdag 26 juli 2018 @ 15:57:
OData, is dat nog een ding ? Is dat iets waar er nog aandacht aan geschonken wordt ?
/dtv

In de SAP Wereld zeker.

[RagingPenguin]

whoami schreef op donderdag 26 juli 2018 @ 15:57:
OData, is dat nog een ding ? Is dat iets waar er nog aandacht aan geschonken wordt ?
/dtv

ik zie het nog regelmatig voorbij komen, hoewel grahql een stuk hipper/moderner is.

[Ryur]

whoami schreef op donderdag 26 juli 2018 @ 15:57:
OData, is dat nog een ding ? Is dat iets waar er nog aandacht aan geschonken wordt ?
/dtv

Vincentio schreef op donderdag 26 juli 2018 @ 18:12:
[...]


In de SAP Wereld zeker.

In de Microsoft Dynamics NAV/AX/CRM ook nog steeds
Maar ik merk dat Microsoft toch meer en meer aan het inzetten is op Microsoft Graph, je kan er best leuke dingen dan meedoen. Goede Outlook integratie met Microsoft Dynamics CRM bijvoorbeeld

[Motrax]

whoami schreef op donderdag 26 juli 2018 @ 15:57:
OData, is dat nog een ding ? Is dat iets waar er nog aandacht aan geschonken wordt ?
/dtv

Ik vind dat hele REST / OData gebeuren maar een raar dingetje.

• Performed goed! Tot dat je meer dan 10 records tegelijk wil (okay sorry, ik wil een miljoen records, schaalt niet)
• Datatypes zijn voor mietjes! Alles in text!!! Gok zelf maar wat het was!!!
• We hebben een webservice, maar we stoppen er niet de helft in van wat je nodig hebt!!!
• We bieden een nieuwe versie aan die een andere 50% afdekt, maar niet de ontbrekende 50%!!!
• Documentatie is voor mietjes!!! Gok zelf maar wat we aanbieden!!!

[BarôZZa]

Tjolk schreef op woensdag 25 juli 2018 @ 12:05:
Mozeskriebel...

In het lokale dorpsblaadje stond laatst een oproep voor een webmaster (content management). Is allemaal vrijwilligerswerk en omdat het blaadje toch echt wel een functie heeft in het dorp dacht ik: laat ik eens reageren. Inmiddels wat van het broddelwerk gezien, volgens mij hebben ze meer aan iemand die daadwerkelijk de techniek eens onderhanden neemt. Maar ja; de site wordt al jaren gratis onderhouden en gehost door een lokale "webdesigner" zoals hij zichzelf noemt. Ook vrijwilligerswerk, dus dat compleet affakkelen zal een hoop diplomatie van me vragen (niet mijn sterkste punt).

Maar echt; gewoon alles zonder inlog beschikbaar (vandaar dat ik het hier maar even niet noem), file uploads via een flash ding, HTML output die aan alle kanten rammelt, etc. Kom ik eens op de site van die kerel die dus zijn diensten verhuurt, klik ik daar zonder credentials in te vullen op de login button, zie ik hele rare output. View source, na een paar HTML regels komt ik dit tegen:

PHP:

<pho
if($_GET['factuur']){
    $factuur = $_GET['factuur']
}
include("conn.php");
 require "Mollie/API/Autoloader.php";

if isset($GET["new"]){
$SqlAmount="select * from 'factuur' where id="$id" OR fatuur="$factuur"";
    $ophalen = mysql_query($SqlAmount) or die(mysql_error()); 
while($record = mysql_fetch_object($ophalen)){
    $amount=record->amount;
}
}
?>

Het is dat er werkelijk alleen maar openbare informatie op die site staat en nergens met persoonsgegevens o.i.d. omgegaan wordt, dat geeft me nog wat tijd om dit op een nette manier aan te vliegen. Maar ik denk dat ik naast content managen toch ook maar even de techniek naar me toe ga trekken, man man man...

Ik moest gisteren al glimlachen om de fatuur=

Maar nu zie ik pas de <pho

[Motrax]

Oh god... weer met SAP bezig. Client tool downloaden... pure hel. En dit is een softwarebedrijf? Het is al 20 jaar hetzelfde liedje

[Mugwump]

Motrax schreef op vrijdag 27 juli 2018 @ 10:00:
[...]
Ik vind dat hele REST / OData gebeuren maar een raar dingetje.

Wat hebben die bezwaren in vredesnaam met REST / OData van doen? Ik denk dat je vooral een vreemd beeld hebt bij waar REST een alternatief voor zou zijn.

• Performed goed! Tot dat je meer dan 10 records tegelijk wil (okay sorry, ik wil een miljoen records, schaalt niet)

Ik werk nu bijvoorbeeld met CosmosDB. Daar heb je in allerlei talen SDKs voor, maar onder de motorkap is het gewoon REST (met optimalisatie nog rechtstreeks over TCP ipv HTTPS als je dat wilt). Paar duizend documentjes opvragen kost je een paar honderd milliseconden.
Ik denk echter vooral dat je niet helemaal begrijpt wat REST is, waar het voor bedoeld en waar het een alternatief voor zou kunnen zijn.
Als je het hebt over 'ik wil miljoenen records', dan lijk je meer een soort databasequery te willen doen.
Je zou nog steeds prima via een REST API miljoenen records kunnen opvragen, bijvoorbeeld met parallele calls.
Data zsm van A naar B krijgen hangt van een aantal zaken af. Compactheid van de getransporteerde data, overhead van het gehanteerde protocol en ga zo maar door. Wil je optimale performance voor REST, dan pak je bijvoorbeeld Protobuf ipv Json of XML als dataformaat.

• Datatypes zijn voor mietjes! Alles in text!!! Gok zelf maar wat het was!!!

Hoe kom je erbij dat je geen datatypen zou hebben? OData specifieert gewoon primitive types bijvoorbeeld. REST an sich schrijft niets voor, maar het staat je vrij om XML te gebruiken met enorme XSDs die je data beschrijven. Voor JSON over REST heb je met swagger prima documentatie inclusief datatypen. JSON kent ook wel degelijk wat basale primitives anders dan 'string'.

• We hebben een webservice, maar we stoppen er niet de helft in van wat je nodig hebt!!!

Wat zie je hier precies als alternatief? We geven je rechtstreeks leestoegang tot al onze datastores en ga lekker los?

• We bieden een nieuwe versie aan die een andere 50% afdekt, maar niet de ontbrekende 50%!!!

Que? Volgens mij klaag je hier over een specifieke API die slecht geïmplementeerd is ofzo.

• Documentatie is voor mietjes!!! Gok zelf maar wat we aanbieden!!!

Integendeel, het hele idee achter REST en OData is dat er zelfbeschrijvende documentatie is die bovendien automatisch gegenereerd wordt en dus ook live / actueel is. Sterker nog, het is juist ook sterk geënt op het idee van autodiscovery.

[BarôZZa]

Theorie vs praktijk. De meeste web api's(zeker van kleinere partijen) zijn brak, onvolledig en slecht gedocumenteerd. Miljoenen requests doen wordt meestal ook niet gewaardeerd, of is niet te doen vanwege de traagheid of wordt simpelweg gelimiteerd (x aantal requests per minuut, of een harde limit). Protocol kan je vaak niet kiezen.

Veel webservices zijn iets wat later erbij zijn gemaakt voor een hele specifieke toepassing, waar later op voortgebouwd wordt en dat uitgroeit tot een monster (en zaken omgooien wordt lastig als tig applicaties het gebruiken). Uiteraard zijn er uitzonderingen, maar dat zijn uitzonderingen. De meeste Google API's werken weer heerlijk bijvoorbeeld.

[Crazy D]

BarôZZa schreef op vrijdag 27 juli 2018 @ 11:49:
Veel webservices zijn iets wat later erbij zijn gemaakt voor een hele specifieke toepassing, waar later op voortgebouwd wordt en dat uitgroeit tot een monster (en zaken omgooien wordt lastig als tig applicaties het gebruiken).

*knuppel in hoenderhok* mooi he, scrum. Je bouwt precies wat nodig is voor die user story en een jaar later zit je dus met een set aan totaal incomplete services waar je maar weinig aan hebt als je iets anders wilt dan precies wat er blijkbaar in de user story destijds stond.
Ik merk hetzelfde bij Exact (hoewel op zich toch geen kleine partij). Waarbij er in de Rest API complete velden ontbreken of enkel codes staan. Geen probleem als je de omschrijvingen ook kunt ophalen maar daar is geen Api voor. Hebben ze ook nog de Xml wegservices, die bevat gelukkig weer ander velden niet die wel in de rest services staan. En daar krijg je bij een aantal lookup values niet alleen de key maar ook de omschrijving binnen. Maar ook dan is er weer niet een service om alle mogelijke waardes op te halen....

En gelukkig hebben ze sinds eerder dit jaar een limiter ingebouwd om het aantal calls per minuut/dag/maand bij te houden. Ga je er overheen krijg je een nieuwe error code, en moet je stoppen met aanroepen (want alles wat je doorgaat telt alvast bij de volgende periode mee.. dus kun je in 1 uur je complete jaarvoorraad er doorheen jassen....). Zou je wellicht denken: 1. er is een test omgeving waarin je je error handling daadwerkelijk kunt testen, maar die is er niet. En 2., je zou denken dat je ergens kunt nakijken hoeveel zij in het systeem hebben staan qua aantallen calls die je hebt gedaan. Maar nee, dat ook niet ("log het zelf maar" ja maar als ik wordt geblokkeerd terwijl volgens mij log er nog ruimte voor calls is....).

En het grappige? Geloof dat er welgeteld 1 partij was die teveel calls deed (geloof een Excel add-in achtige toepassing), die hebben wat verbeteringen en caching doorgevoerd et voilà niemand haalt de limieten meer. Wat je dus doet afvragen: heel veel heisa, heel veel gedoe, maar ze hadden ook eerst kunnen monitoren en die ene partij erop aanspreken....

[Mugwump]

BarôZZa schreef op vrijdag 27 juli 2018 @ 11:49:
Theorie vs praktijk. De meeste web api's(zeker van kleinere partijen) zijn brak, onvolledig en slecht gedocumenteerd. Miljoenen requests doen wordt meestal ook niet gewaardeerd, of is niet te doen vanwege de traagheid of wordt simpelweg gelimiteerd (x aantal requests per minuut, of een harde limit). Protocol kan je vaak niet kiezen.

Veel webservices zijn iets wat later erbij zijn gemaakt voor een hele specifieke toepassing, waar later op voortgebouwd wordt en dat uitgroeit tot een monster (en zaken omgooien wordt lastig als tig applicaties het gebruiken). Uiteraard zijn er uitzonderingen, maar dat zijn uitzonderingen. De meeste Google API's werken weer heerlijk bijvoorbeeld.

Uiteraard, maar brakke implementaties zijn niet voorbehouden aan REST APIs. Als er APIs beschikbaar worden gesteld, dan zitten daar logischerwijs limieten aan omdat een back end doorgaans plat gaat als er vele gebruikers ongecontroleer op los mogen gaan. Sterker nog, REST kan daar flinke voordelen bieden. Als je je data immutable kunt maken, dan kun je met reverse proxies bovendien enorm hard schalen.

Daarbij blijft mijn vraag staan. Waar zou REST in dat geval een alternatief voor zijn? Als je al je klanten rechtstreeks toegang geeft op je data store gaat ie net zo hard plat natuurlijk.

[dev10]

Crazy D schreef op vrijdag 27 juli 2018 @ 12:33:
[...]

* Verhaal over Exact *

Heel herkenbaar. Die hele API van Exact Online is een farce.

Als je iets probeert weg te schrijven in een niet-bestaande boekhouding, krijg je een lege response met status 200. Geen foutmelding, gewoon helemaal niks. Ik heb dit doorgegeven, maar de persoon die ik toen aan de telefoon had wilde het niet in behandeling nemen, want: 'Je moet er zelf voor zorgen dat de gegevens die je gebruikt correct zijn.'

Sindsdien loop ik met een grote boog om alles van Exact heen.

[BarôZZa]

Mugwump schreef op vrijdag 27 juli 2018 @ 12:55:
[...]


Uiteraard, maar brakke implementaties zijn niet voorbehouden aan REST APIs. Als er APIs beschikbaar worden gesteld, dan zitten daar logischerwijs limieten aan omdat een back end doorgaans plat gaat als er vele gebruikers ongecontroleer op los mogen gaan. Sterker nog, REST kan daar flinke voordelen bieden. Als je je data immutable kunt maken, dan kun je met reverse proxies bovendien enorm hard schalen.

Daarbij blijft mijn vraag staan. Waar zou REST in dat geval een alternatief voor zijn? Als je al je klanten rechtstreeks toegang geeft op je data store gaat ie net zo hard plat natuurlijk.

Maar volgens mij ging z'n post ook niet echt over REST, maar over de REST API's die hij tegenkwam (alles tekst, onvolledig, slechte docu etc). Altijd leuk als je een daterange kan invullen, maar nergens staat in wat voor format bijvoorbeeld.

Niks mis met REST an sich verder, gebruik het liever dan SOAP als het een optie is.

[Mugwump]

BarôZZa schreef op vrijdag 27 juli 2018 @ 13:18:
[...]

Maar volgens mij ging z'n post ook niet echt over REST, maar over de REST API's die hij tegenkwam (alles tekst, onvolledig, slechte docu etc). Altijd leuk als je een daterange kan invullen, maar nergens staat in wat voor format bijvoorbeeld.

Niks mis met REST an sich verder, gebruik het liever dan SOAP als het een optie is.

Hij zegt toch echt: 'Ik vind dat hele REST / OData gebeuren maar een raar dingetje'. Dat is wat anders dan: 'Ik zie heel veel slecht geïmplementeerde REST APIs' in mijn ogen.
Vandaar ook steeds mijn vraag waarvoor het gezien wordt als alternatief. De opgesomde problemen hebben namelijk niets te maken met REST of OData an sich.

[BarôZZa]

Mugwump schreef op vrijdag 27 juli 2018 @ 13:31:
[...]


Hij zegt toch echt: 'Ik vind dat hele REST / OData gebeuren maar een raar dingetje'. Dat is wat anders dan: 'Ik zie heel veel slecht geïmplementeerde REST APIs' in mijn ogen.
Vandaar ook steeds mijn vraag waarvoor het gezien wordt als alternatief. De opgesomde problemen hebben namelijk niets te maken met REST of OData an sich.

Maar dat viel op te maken uit de opgesomde punten.

Als programmeur weet je toch dat je nooit iets letterlijk moet opvatten en altijd tussen de regels door moet lezen om erachter te komen wat iemand echt bedoelt

[Alex)]

En toch blijven we massaal programmeren hè, in plaats van ons om te laten scholen tot buschauffeur ofzo

[Mugwump]

BarôZZa schreef op vrijdag 27 juli 2018 @ 14:04:
[...]

Maar dat viel op te maken uit de opgesomde punten.

Als programmeur weet je toch dat je nooit iets letterlijk moet opvatten en altijd tussen de regels door moet lezen om erachter te komen wat iemand echt bedoelt

Nee, als developer weet je dat "assume = to make an 'ass' out of 'u' and 'me'".
Oftewel altijd wedervragen stellen en uitleg geven en dat deed ik dan ook.

[gekkie]

Alex) schreef op vrijdag 27 juli 2018 @ 14:14:
En toch blijven we massaal programmeren hè, in plaats van ons om te laten scholen tot buschauffeur ofzo

Niet iedereen heeft een Fred Teeven in zich .
(en het interfacen met passagiers is ook niet altijd fijn .. de errors kunnen tegenwoordig nog al fysiek zijn)

Hmmmmm de thuis IT begon zonet te piepen ... m'n ventilator maar moeten afstaan , gelukkig is er nu buiten een beetje windje.

[ Voor 14% gewijzigd door gekkie op 27-07-2018 14:20 ]

[Matis]

Alex) schreef op vrijdag 27 juli 2018 @ 14:14:
En toch blijven we massaal programmeren hè, in plaats van ons om te laten scholen tot buschauffeur ofzo

Nog en paar jaar. Dan word ik, hopelijk, beroepsmatig brandweerman.

[Mugwump]

Alex) schreef op vrijdag 27 juli 2018 @ 14:14:
En toch blijven we massaal programmeren hè, in plaats van ons om te laten scholen tot buschauffeur ofzo

Elke 2.5 uur 30 seconden pauze om naar het toilet te mogen en een salarisplafond van iets van 2700 euro per maand geloof ik. Ik verdien qua totale package op m'n 36e al het dubbele en als je een beetje competente developer bent, dan is de werkdruk doorgaans vrij laag. Als je tenminste niet de gaten hoeft dicht te lopen voor de vele volstrekt incompetenten die er in ons vak rondlopen.

[Alex)]

Mij lijkt het eigenlijk best leuk. Voor 1 dag in de week ofzo.

[Skyaero]

Alex) schreef op vrijdag 27 juli 2018 @ 14:45:
Mij lijkt het eigenlijk best leuk. Voor 1 dag in de week ofzo.

Meld je aan bij de lokale buurtbus. Die draaien op vrijwilligers.

[Vincentio]

Motrax schreef op vrijdag 27 juli 2018 @ 10:42:
Oh god... weer met SAP bezig. Client tool downloaden... pure hel. En dit is een softwarebedrijf? Het is al 20 jaar hetzelfde liedje

Uhm dat ligt toch heel erg wat je wilt doen in SAP en welke versie men heeft draaien daar.
Voor het meeste is tegenwoordig wel een goede web interface en voor ontwikkelen kan je redelijk veel vanuit Eclipse als je echt op SAP zelf wat wilt doen of via Web IDEs of third party IDEs ook in bepaalde gevallen.

[Matis]

Afgelopen week voor het eerst in aanraking gekomen met Elasticsearch. Ik moet bekennen dat ik het erg fijn vind werken in al zijn eenvoud.
Vooral de manier waarop de matcher werkt icm de score vind ik grandioos.

[Mugwump]

Matis schreef op zaterdag 28 juli 2018 @ 11:30:
Afgelopen week voor het eerst in aanraking gekomen met Elasticsearch. Ik moet bekennen dat ik het erg fijn vind werken in al zijn eenvoud.
Vooral de manier waarop de matcher werkt icm de score vind ik grandioos.

Ja, prima search engine, net als SOLR. Lijkt toch een vakgebied dat Microsoft maar moeilijk onder de knie krijgt. Ze hadden vroeger het aangekochte FAST, wat zijn naam niet bepaald eer aan deed en tegenwoordig Azure search wat ook maar een halfbakken implementatie is.

[Matis]

Mugwump schreef op zaterdag 28 juli 2018 @ 13:55:
Ja, prima search engine, net als SOLR. Lijkt toch een vakgebied dat Microsoft maar moeilijk onder de knie krijgt. Ze hadden vroeger het aangekochte FAST, wat zijn naam niet bepaald eer aan deed en tegenwoordig Azure search wat ook maar een halfbakken implementatie is.

We hadden een MySQL database met 5 miljoen rijen en 16 full-text kolommen.
Daarin zoeken met dubbele wildcards op diverse kolommen resulteerde in queries die bijna 2 minuten duren. Dat is voor een API best wel lang
Met ES is dat binnen 10 seconden gepiept

[Mugwump]

Matis schreef op zaterdag 28 juli 2018 @ 17:17:
[...]

We hadden een MySQL database met 5 miljoen rijen en 16 full-text kolommen.
Daarin zoeken met dubbele wildcards op diverse kolommen resulteerde in queries die bijna 2 minuten duren. Dat is voor een API best wel lang
Met ES is dat binnen 10 seconden gepiept

Sommige database engines hebben wel wat fulltext search mogelijkheden, maar het haalt het ook niet bij de features die je hebt in een echte search engine.

[Antrax]

Matis schreef op zaterdag 28 juli 2018 @ 11:30:
Afgelopen week voor het eerst in aanraking gekomen met Elasticsearch. Ik moet bekennen dat ik het erg fijn vind werken in al zijn eenvoud.
Vooral de manier waarop de matcher werkt icm de score vind ik grandioos.

Als je eenmaal weet hoe je ermee moet werken is het een geweldig product!
Ze hebben ook nog redelijke documentatie met voorbeelden.

[Douweegbertje]

Matis schreef op zaterdag 28 juli 2018 @ 17:17:
[...]

We hadden een MySQL database met 5 miljoen rijen en 16 full-text kolommen.
Daarin zoeken met dubbele wildcards op diverse kolommen resulteerde in queries die bijna 2 minuten duren. Dat is voor een API best wel lang
Met ES is dat binnen 10 seconden gepiept

Ik gebruik het dan met https://www.graylog.org/, retentie ongeveer zo gezet dat ik een dataset heb van ~60-90 gig. Met de juiste shards en instellingen kan je dan vrij makkelijk in een bepaalde periode zoeken. Bijvoorbeeld het laatste ~uur kan bijv. 10mil records bevatten: 300ms search results.

m.a.w. helemaal top

[mcDavid]

ES is leuk idd Vooral als je door stemming en wat synoniemen je zoekresultaten zichtbaar ziet verbeteren. Het is even wat uitzoekwerk wat je er allemaal mee kunt, maar implementatie is echt doodeenvoudig.

[Gropah]

Voor de mensen die fan zijn van JetBrains producten, er is nog voor 20 uur een sale van 50% aan de gang voor persoonlijke licenties voor alles in hun toolbox

[Mugwump]

Gropah schreef op dinsdag 31 juli 2018 @ 21:31:
Voor de mensen die fan zijn van JetBrains producten, er is nog voor 20 uur een sale van 50% aan de gang voor persoonlijke licenties voor alles in hun toolbox

Hmm, net een paar dagen te vroeg verlengd dus.

[Ron]

Mugwump schreef op vrijdag 27 juli 2018 @ 14:44:
[...]

Als je tenminste niet de gaten hoeft dicht te lopen voor de vele volstrekt incompetenten die er in ons vak rondlopen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Eärendil]

Gropah schreef op dinsdag 31 juli 2018 @ 21:31:
Voor de mensen die fan zijn van JetBrains producten, er is nog voor 20 uur een sale van 50% aan de gang voor persoonlijke licenties voor alles in hun toolbox

Ik heb mijn IntelliJ-licentie omgezet naar een All Products Pack. De resterende waarde van mijn IntelliJ-licentie (verlengd in mei) werd daarbij omzet in een korting op het Pack.

I already have a subscription and would like upgrade to the All Products Pack. Can I take advantage of the offer?
Yes, of course. Simply scroll higher or go to JetBrains Store, click 'Buy' under the All Products Pack, and follow the instructions. All appropriate discounts will be applied automatically.

[DevWouter]

Eärendil schreef op woensdag 1 augustus 2018 @ 07:57:
[...]


Ik heb mijn IntelliJ-licentie omgezet naar een All Products Pack. De resterende waarde van mijn IntelliJ-licentie (verlengd in mei) werd daarbij omzet in een korting op het Pack.


[...]

Superbedankt! Mijn licentie voor Rider loopt af in september en ik moest die nog verlengen. Ook daar geldt de 50% korting voor.

[Mercatres]

Bedankt! Ik heb nu ook m'n eigen persoonlijke (niet werk) ReSharper gekocht

[dcm360]

Welja, ook maar meteen verlengd, kan ik nu door tot april 2020 Ook nog even overwogen om voor het all-products pack te gaan, maar aangezien dat met name .net-spullen oplevert (ten opzichte van IntelliJ) toch maar niet gedaan.

[kevintjeb]

Eerder geregeld met jetbrains dat ik 20% korting kreeg wegens student zijnde, aankoop alleen uitgesteld door vakantie. Nu met 50% de all products pack aangeschaft, Weer geluk gehad

[Mugwump]

DevWouter schreef op woensdag 1 augustus 2018 @ 10:36:
[...]


Superbedankt! Mijn licentie voor Rider loopt af in september en ik moest die nog verlengen. Ook daar geldt de 50% korting voor.

Is dat inmiddels een beetje volwassen?
Ik heb het een tijdje terug geprobeerd en toen mistte ik nog wel veel support voor frameworks, integratie met Azure en meer van dat soort zaken.
Ik zou het graag gebruiken want alle Jetbrains producten zijn een factor duizend intuïtiever dan elk Microsoft product ooit.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[bauke1994]

kevintjeb schreef op woensdag 1 augustus 2018 @ 11:22:
Eerder geregeld met jetbrains dat ik 20% korting kreeg wegens student zijnde, aankoop alleen uitgesteld door vakantie. Nu met 50% de all products pack aangeschaft, Weer geluk gehad

Tijdens mijn studententijd heb ik gebruik gemaakt van hun studenten aanbieding, het all products pack voor nop.

[DevWouter]

Mugwump schreef op woensdag 1 augustus 2018 @ 11:39:
[...]


Is dat inmiddels een beetje volwassen?
Ik heb het een tijdje terug geprobeerd en toen mistte ik nog wel veel support voor frameworks, integratie met Azure en meer van dat soort zaken.
Ik zou het graag gebruiken want alle Jetbrains producten zijn een factor duizend intuïtiever dan elk Microsoft product ooit.


***members only***

Het is al vrij lang volwassen als ik Visual Studio als meetlat gebruikt. Het enige wat ik echt miste was ondersteuning voor Entity Framework en dat was omdat er geen andere oplossing bestond. Dat is sinds begin dit jaar opgelost.

Ik ben onvoldoende bekend met Azure om je daar te adviseren, maar afhankelijk van hoe vaak je het gebruikt is misschien een idee om Rider als je main IDE voor ontwikkelen te gebruiken en Visual Studio als je secondary voor deploys? Ik heb dit ook een tijdlang gedaan toen de ondersteuning voor EF niet aanwezig was.

Verder ben ik een script-kiddie/console-guru dus ik zit sowieso vaak buiten de IDE te werken (soms gebruik ik zelfs vim om snel een bestand aan te passen).

[Mugwump]

DevWouter schreef op woensdag 1 augustus 2018 @ 13:20:
[...]


Het is al vrij lang volwassen als ik Visual Studio als meetlat gebruikt. Het enige wat ik echt miste was ondersteuning voor Entity Framework en dat was omdat er geen andere oplossing bestond. Dat is sinds begin dit jaar opgelost.

Ik ben onvoldoende bekend met Azure om je daar te adviseren, maar afhankelijk van hoe vaak je het gebruikt is misschien een idee om Rider als je main IDE voor ontwikkelen te gebruiken en Visual Studio als je secondary voor deploys? Ik heb dit ook een tijdlang gedaan toen de ondersteuning voor EF niet aanwezig was.

Verder ben ik een script-kiddie/console-guru dus ik zit sowieso vaak buiten de IDE te werken (soms gebruik ik zelfs vim om snel een bestand aan te passen).

Het is niet zozeer voor deploys, maar meer voor remote debugging en dergelijke.
Heeft Rider trouwens ook niet gewoon een console window net als IntelliJ / PyCharm / whatever?

[DevWouter]

Mugwump schreef op woensdag 1 augustus 2018 @ 13:36:
[...]


Het is niet zozeer voor deploys, maar meer voor remote debugging en dergelijke.
Heeft Rider trouwens ook niet gewoon een console window net als IntelliJ / PyCharm / whatever?

Nee, het heeft geen remote debugger. Het beste wat je hebt is "Attach to local process". En Rider heeft een terminal voor cmd/ps/bash ingebouwd, maar geen nuget-package console of iets dergelijks.

Dat er geen remote debugger in zit is wel jammer, maar ik debug ook bijna nooit

[Mugwump]

DevWouter schreef op woensdag 1 augustus 2018 @ 13:50:
[...]


Nee, het heeft geen remote debugger. Het beste wat je hebt is "Attach to local process". En Rider heeft een terminal voor cmd/ps/bash ingebouwd, maar geen nuget-package console of iets dergelijks.

Dat er geen remote debugger in zit is wel jammer, maar ik debug ook bijna nooit

je debugt bijna nooit? Bouw je wel software?

[Ryur]

Mugwump schreef op woensdag 1 augustus 2018 @ 13:59:
[...]


je debugt bijna nooit? Bouw je wel software?

Ik debug ook bijna nooit
Alles is gecoverd door tests, dus hoef eigenlijk weinig te debuggen.

[DevWouter]

Mugwump schreef op woensdag 1 augustus 2018 @ 13:59:
[...]


je debugt bijna nooit? Bouw je wel software?

Is de correcte uitspraak niet "Bro, do you even software?" of probeer ik nu hipper te doen dan een hipster?


Maar om antwoord te geven op je vraag: Ik test veel, maar zelden met een debugger.
Vaak gebruik ik automatisch tests (unit en e2e tests).

Echter in tegenstelling tot @Ryur heb ik niet altijd een hoge coverage. Vaak schrijf ik mijn code dusdanig modulair dat ik er stukken uit kan rippen om zo vervolgens snel een test project op te zetten. Vaak omdat die onderdelen moeten integreren met partners, en ik weinig zin heb om de API van de partner te gaan mocken.

Nu ik er over nadenk... Ik gebruik LinqPad wel vaak als een soort debugger

[ Voor 3% gewijzigd door DevWouter op 01-08-2018 14:25 ]

[Mugwump]

Ryur schreef op woensdag 1 augustus 2018 @ 14:11:
[...]

Ik debug ook bijna nooit
Alles is gecoverd door tests, dus hoef eigenlijk weinig te debuggen.

Allerhande triviale zaken en verwachte use cases timmer ik zelf ook altijd wel dicht met unit- en integratietests, maar ik ben doorgaans niet de enige die code schrijft en ook niet elk project begint met een prachtig groen veldje.
Als je dan ook nog eens geen controle over / inzicht in het releaseproces hebt, dan is remote debugging wel erg handig. Zaken als niet kunnen verbinden met een extern systeem (database / ander systeem, api, whatever) omdat er ergens een incorrecte waarde voor een variable is geïnjecteerd kun je met remote debugging vaak een stuk makkelijker achterhalen dan door in logs te graven.

[Gropah]

Ik heb erg zitten twijfelen om het complete jetbrains pack te kopen. Ik heb via mijn studie nog wel een jaar het complete pakket wat ik erg kon waarderen toen ik veel java en scala deed, maar dat is niet meer zo. Doe tegenwoordig voornamelijk python, maar daar ben ik redelijk voorzien met sublime text. Het is net iets makkelijker in pycharm dus dat zwengel ik nog af en toe aan. Punt is alleen dat voor mijn bijbaan het pakket niet mag gebruiken want commercieel gebruik op een studentenlicentie. Maar of ik dat 40 euro (of 125 euro voor het hele pakket) waard vind... Vind het vooral jammer dat ik niet ergens makkelijk kan kijken hoe vaak ze een sale hebben, want als er in februari oid weer 1 is dan sluit ik dan misschien aan.

[Antrax]

Gropah schreef op woensdag 1 augustus 2018 @ 16:54:
Ik heb erg zitten twijfelen om het complete jetbrains pack te kopen. Ik heb via mijn studie nog wel een jaar het complete pakket wat ik erg kon waarderen toen ik veel java en scala deed, maar dat is niet meer zo. Doe tegenwoordig voornamelijk python, maar daar ben ik redelijk voorzien met sublime text. Het is net iets makkelijker in pycharm dus dat zwengel ik nog af en toe aan. Punt is alleen dat voor mijn bijbaan het pakket niet mag gebruiken want commercieel gebruik op een studentenlicentie. Maar of ik dat 40 euro (of 125 euro voor het hele pakket) waard vind... Vind het vooral jammer dat ik niet ergens makkelijk kan kijken hoe vaak ze een sale hebben, want als er in februari oid weer 1 is dan sluit ik dan misschien aan.

Ik was ook aan het twijfelen maar heb Datastorm en Webstorm apart gekocht. Het hele pakket is voor mijn werkveld niet echt nodig en daarmee bespaar ik weer geld

[Mugwump]

Antrax schreef op woensdag 1 augustus 2018 @ 16:59:
[...]

Ik was ook aan het twijfelen maar heb Datastorm en Webstorm apart gekocht. Het hele pakket is voor mijn werkveld niet echt nodig en daarmee bespaar ik weer geld

Ik neem aan dat je datagrip bedoelt.

[kevintjeb]

bauke1994 schreef op woensdag 1 augustus 2018 @ 12:34:
[...]


Tijdens mijn studententijd heb ik gebruik gemaakt van hun studenten aanbieding, het all products pack voor nop.

Gebruik ik ook alleen voor zakelijk gebruik is het niet mogelijk helaas!

[Gamebuster]

Ik dacht dat een Soap Client implementeren als onaangenaam was... moet je eens een Soap Server opzetten... manmanman. In ieder geval niet in NodeJS gaan proberen

[ Voor 16% gewijzigd door Gamebuster op 02-08-2018 11:17 ]

[Mugwump]

Gamebuster schreef op donderdag 2 augustus 2018 @ 11:16:
Ik dacht dat een Soap Client implementeren als onaangenaam was... moet je eens een Soap Server opzetten... manmanman. In ieder geval niet in NodeJS gaan proberen

Ik heb dat vroeger nog wel eens in PHP gedaan, wat een ellende was dat.
SOAP werkt nog wel vrij eenvoudig als je gebruik maakt van Java of C# aangezien je het gros laat genereren, maar in veel andere talen is het echt ruk. Veel zaken worden maar half ondersteund, specs zijn niet goed geïmplementeerd en ga zo maar door.

[Gamebuster]

Mugwump schreef op donderdag 2 augustus 2018 @ 11:19:
[...]


Ik heb dat vroeger nog wel eens in PHP gedaan, wat een ellende was dat.
SOAP werkt nog wel vrij eenvoudig als je gebruik maakt van Java of C# aangezien je het gros laat genereren, maar in veel andere talen is het echt ruk. Veel zaken worden maar half ondersteund, specs zijn niet goed geïmplementeerd en ga zo maar door.

Ja ik twijfel of ik gewoon NodeJS/Ruby even drop en gewoon "hardcode" Java/C# opstart. Ik ben niet vies van een beetje public static void.

[ Voor 6% gewijzigd door Gamebuster op 02-08-2018 11:22 ]

[whoami]

Mugwump schreef op woensdag 1 augustus 2018 @ 13:36:
[...]


Het is niet zozeer voor deploys, maar meer voor remote debugging en dergelijke.

VS.NET vind ik echt wel super als je iets op Azure wil debuggen.
Tegen welke problemen loop je daar aan ?

_{en die nieuwe VSTS interface is wel even wennen ja ..}

[Mugwump]

Gamebuster schreef op donderdag 2 augustus 2018 @ 11:21:
[...]

Ja ik twijfel of ik gewoon NodeJS/Ruby even drop en gewoon "hardcode" Java/C# opstart. Ik ben niet vies van een beetje public static void.

Als je even snel wat in elkaar wilt knutselen, dan kun je bijvoorbeeld in relatief weinig tijd een stand-alone spring boot app maken zoals hier beschreven.

Edit:

whoami schreef op donderdag 2 augustus 2018 @ 12:09:
[...]
VS.NET vind ik echt wel super als je iets op Azure wil debuggen.
Tegen welke problemen loop je daar aan ?

Het ging om Rider, de .Net IDE van Jetbrains.

_{en die nieuwe VSTS interface is wel even wennen ja ..}

Niet alleen wennen, hij is nog slechter dan de vorige.
De basis van een goede user interface is uniformiteit en consistentie. Die is echt ver te zoeken. De ene keer kun je een linkje in een nieuwe pagina openen, de andere keer is het een javascript redirect en dan weer een javascript pop-up.
De ene keer geeft rechtermuisknop op een link een standaard browsermenu, dan weer één of ander custom contextmenu. Welke van de twee je krijgt is op geen enkele wijze consistent.
In het ene scherm kun je PBIs wel gewoon slepen naar andere sprints of backlogs, in het andere scherm weer niet.

Als je een work item versleept of een status aanpast trigger je kennelijk een reload van je board die je scrollpositie niet onthoudt waardoor je board weer naar boven schiet als je ergens halverwege bezig was.
Estimation sessies zijn soms opeens niet zichtbaar voor de helft van de teamleden.
Builds hebben wel een folder, releases weer niet (nu net wel geïntroduceerd overigens).

Even fatsoenlijk keyboard shortcuts en features in invoervelden introduceren is er ook niet bij. Je kunt (un)indenten middels de UI, maar met tab ga je naar het volgende UI element. In descriptions en ACs heb je mark-up, maar weer geen tagging van personen, in comments het omgekeerde. En hoewel je weer officieel geen opmaak in comments kunt plaatsen middels de UI, kun je wel weer met ctrl-B / ctrl-I mark-up toevoegen.

Grote ergernis is bijvoorbeeld als je even iemand een linkje wilt sturen van een PBI of Task op een board. Rechtermuisknop > copy link werkt al niet. Het ding openen is ook niet afdoende, want de link van je browser blijft die van je board i.p.v. iets met een anchor (board#pbi of iets dergelijks). Stuur je die dan gaat je collega gewoon naar het board ipv de workitem. Dus dan moet je in die pop-up weer zoeken naar het linkje naar de work item.

Daarnaast zitten gewoon bugs in zoals het feit dat een edit link op een build / release definition je gewoon 80% van de tijd redirect naar de lijst van definitions in plaats van naar het edit scherm.

Het zijn allemaal hele basale zaken op het gebiede van UI / UX, die je van een partij als Microsoft toch wel zou verwachten. [/rant]

[ Voor 70% gewijzigd door Mugwump op 02-08-2018 13:57 ]

[Antrax]

Mugwump schreef op woensdag 1 augustus 2018 @ 19:33:
[...]


Ik neem aan dat je datagrip bedoelt.

Ja, die ja. *Stomme autocorrect*

[Verwijderd]

Gamebuster schreef op donderdag 2 augustus 2018 @ 11:16:
Ik dacht dat een Soap Client implementeren als onaangenaam was... moet je eens een Soap Server opzetten... manmanman. In ieder geval niet in NodeJS gaan proberen

Ik moet nu ook een SOAP client implementeren, voor UPnP A/V, wat trouwens echt een hel is, want bijvoorbeeld dat "Simple Service Discovery Protocol" gebruikt niet-standaard HTTP over multicast (en later weer unicast) UDP.

Heeft iemand overigens een mening over GTK+ vs Qt voor een cross-platform (Linux, Windows en macOS) programma (dat media streamt)?

[ed800]

Hoe denken jullie over devs zonder informatica opleiding?

[Verwijderd]

ed800 schreef op donderdag 2 augustus 2018 @ 16:12:
Hoe denken jullie over devs zonder informatica opleiding?

Allemaal prutsers.

[Mugwump]

ed800 schreef op donderdag 2 augustus 2018 @ 16:12:
Hoe denken jullie over devs zonder informatica opleiding?

Dat is wel een extreem brede groep mensen.
Qua voorkennis zit er al een behoorlijk verschil tussen mensen me bijvoorbeeld een opleiding technische natuurkunde of werktuigbouwkunde en iemand die z'n mavo nooit heeft afgemaakt.

[ed800]

Mugwump schreef op donderdag 2 augustus 2018 @ 16:38:
[...]


Dat is wel een extreem brede groep mensen.
Qua voorkennis zit er al een behoorlijk verschil tussen mensen me bijvoorbeeld een opleiding technische natuurkunde of werktuigbouwkunde en iemand die z'n mavo nooit heeft afgemaakt.

Ik heb Natuurkunde+Wiskunde bachelor en krijg relatief veel IT aanbiedingen. Ik ben echter vrij huiverig om ze aan te nemen, omdat ik nou niet echt pro level code schrijf.....

[Verwijderd]

Ervaring telt over het algemeen veel zwaarder dan opleiding. Als je geen professionele ervaring hebt én geen relevante opleiding, sta je redelijk onderaan de ladder...

[Mugwump]

ed800 schreef op donderdag 2 augustus 2018 @ 16:46:
[...]


Ik heb Natuurkunde+Wiskunde bachelor en krijg relatief veel IT aanbiedingen. Ik ben echter vrij huiverig om ze aan te nemen, omdat ik nou niet echt pro level code schrijf.....

Ach, dat leer je in de praktijk wel. Jouw achtergrond is uitermate geschikt om iets in de IT te gaan doen. Ik heb zelf WO Technische Informatica gestudeerd, maar de code die ik 10 jaar geleden schreef zou ik nu ook prutswerk vinden.
Software development is ook iets dat je in hoge mate in de praktijk moet leren. Zeker als je een WO-achtergrond hebt, waar de nadruk toch veel meer ligt op fundamentele kennis en theoretische concepten.
En als je natuur- en wiskunde gestudeerd hebt, dan ga ik er vanuit dat je het analytisch denkvermogen en de flexibiliteit hebt om je zaken snel eigen te maken.
Het meeste leer je nog van werken in teams met goede ervaren krachten.

[Matis]

Ik zie software ontwikkeling meer als abstract kunnen denken en probleemoplossend vermogen hebben.
Iets dat een WOer met wiskunde prima zou moeten kunnen.

De taal leer je snel genoeg. Wat je op de opleiding krijgt, staat toch in schril contrast met het bedrijfsleven.

Het is veel belangrijker dat je design patterns en ontwikkelmethodes kent dan een daadwerkelijke taal.

[Mercatres]

Onlangs nog een leuk artikel over development vs. ingeneurs gelezen: http://datanews.knack.be/...icle-opinion-1178481.html
Het gaat 'm inderdaad om veel meer dan netjes code kunnen kloppen, het is vooral de vertaalslag van (eender welk) domein naar code, en dat vereist toch wel inzicht en herkennen van patronen.

[Mugwump]

Mercatres schreef op donderdag 2 augustus 2018 @ 17:20:
Onlangs nog een leuk artikel over development vs. ingeneurs gelezen: http://datanews.knack.be/...icle-opinion-1178481.html
Het gaat 'm inderdaad om veel meer dan netjes code kunnen kloppen, het is vooral de vertaalslag van (eender welk) domein naar code, en dat vereist toch wel inzicht en herkennen van patronen.

Ik denk dat er ook wel een zekere analogie zit in de wetenschappen en de ingenieursdisciplines. De fenomenen in de natuurkunde zijn vele malen "wetmatiger" dan die in de economie of sociologie. Daarom roepen mensen nog wel eens dat exacte wetenschappen beter zouden zijn oud. De fenomenen en eisen waar je bij het bouwen van een brug of een huis te maken hebt zijn ook vele malen wetmatiger dan die bij het bouwen van een software systeem. De samenstelling van de grond, de waterstand, de belasting, de weersomstandigheden en ga zo maar door zijn relatief voorspelbaar en stabiel. Als je een huis bouwt, dan roept de klant niet halverwege dat het huis toch drie meter naar links moet of er een verdieping extra op moet, besluit de stroomleverancier niet zomaar over te gaan op een heel ander voltage of over te gaan naar gelijkstroom en ga zo maar door.

[Matis]

Mugwump schreef op donderdag 2 augustus 2018 @ 22:55:
Ik denk dat er ook wel een zekere analogie zit in de wetenschappen en de ingenieursdisciplines. De fenomenen in de natuurkunde zijn vele malen "wetmatiger" dan die in de economie of sociologie. Daarom roepen mensen nog wel eens dat exacte wetenschappen beter zouden zijn oud. De fenomenen en eisen waar je bij het bouwen van een brug of een huis te maken hebt zijn ook vele malen wetmatiger dan die bij het bouwen van een software systeem. De samenstelling van de grond, de waterstand, de belasting, de weersomstandigheden en ga zo maar door zijn relatief voorspelbaar en stabiel. Als je een huis bouwt, dan roept de klant niet halverwege dat het huis toch drie meter naar links moet of er een verdieping extra op moet, besluit de stroomleverancier niet zomaar over te gaan op een heel ander voltage of over te gaan naar gelijkstroom en ga zo maar door.

Dat ligt er maar net aan hoe strikt de contracten zijn en hoeveel de klant voor de wijziging wil betalen.

[Mugwump]

Matis schreef op vrijdag 3 augustus 2018 @ 06:32:
[...]

Dat ligt er maar net aan hoe strikt de contracten zijn en hoeveel de klant voor de wijziging wil betalen.

Dat klinkt natuurlijk leuk, maar zo werkt het in de praktijk vaak niet. Als er bijvoorbeeld door de tweede kamer plots allerlei nieuwe belastingregels worden goedgekeurd, dan kan een heel systeem / project weer op de kop met flinke overschrijdingen tot gevolg waarna er weer artikeltjes verschijnen over waarom er toch zo weinig IT-projecten binnen tijd en budget blijven.
Contracten die 'alles' strak dichtttimmeren lijken me ook een redelijke utopie.

[Matis]

Mugwump schreef op vrijdag 3 augustus 2018 @ 08:01:
Dat klinkt natuurlijk leuk, maar zo werkt het in de praktijk vaak niet. Als er bijvoorbeeld door de tweede kamer plots allerlei nieuwe belastingregels worden goedgekeurd, dan kan een heel systeem / project weer op de kop met flinke overschrijdingen tot gevolg waarna er weer artikeltjes verschijnen over waarom er toch zo weinig IT-projecten binnen tijd en budget blijven.

Dat heeft niets met tijd te maken, alleen met budget. Maar hetzelfde geldt toch ook in de bouw? Toen de BTW van 19 naar 21% ging, werden alle bouwwerken (materiaal in ieder geval) toch ook duurder.

Contracten die 'alles' strak dichtttimmeren lijken me ook een redelijke utopie.

Dat heet bestek

[Mugwump]

Matis schreef op vrijdag 3 augustus 2018 @ 09:12:
[...]
Dat heeft niets met tijd te maken, alleen met budget. Maar hetzelfde geldt toch ook in de bouw? Toen de BTW van 19 naar 21% ging, werden alle bouwwerken (materiaal in ieder geval) toch ook duurder.

Ik doelde op het feit dat wijzigingen in de belastingregels een systeem dat op het vlak van belastingen het één en ander automatiseert volledig op zijn kop kan zetten.

[...]

Dat heet bestek

Hebben we het hier nou over IT projecten of over 'ingenieursprojecten'? Ik snap dat het bij het laatste soort projecten kan, als je denkt dat het bij het eerste soort projecten kan dan moet ik je teleurstellen.

[Matis]

Mugwump schreef op vrijdag 3 augustus 2018 @ 10:00:
[...]


Ik doelde op het feit dat wijzigingen in de belastingregels een systeem dat op het vlak van belastingen het één en ander automatiseert volledig op zijn kop kan zetten.


[...]


Hebben we het hier nou over IT projecten of over 'ingenieursprojecten'? Ik snap dat het bij het laatste soort projecten kan, als je denkt dat het bij het eerste soort projecten kan dan moet ik je teleurstellen.

Oh, we praten een beetje langs elkaar heen

Dan snap ik je punt!

[gekkie]

Mugwump schreef op donderdag 2 augustus 2018 @ 22:55:
[...]
De fenomenen en eisen waar je bij het bouwen van een brug of een huis te maken hebt zijn ook vele malen wetmatiger dan die bij het bouwen van een software systeem. De samenstelling van de grond, de waterstand, de belasting, de weersomstandigheden en ga zo maar door zijn relatief voorspelbaar en stabiel. Als je een huis bouwt, dan roept de klant niet halverwege dat het huis toch drie meter naar links moet of er een verdieping extra op moet, besluit de stroomleverancier niet zomaar over te gaan op een heel ander voltage of over te gaan naar gelijkstroom en ga zo maar door.

Ahum, als bouwkundige moet ik je toch teleurstellen. Al zijn er de laatste jaren enige verbeteringen door de inzet van automatisering waardoor bijvb installatietechniek beter en eerder op elkaar kan worden afgestemd.

Maar tot niet al te lang geleden kwam het voor dat terwijl de fysieke bouw al was gestart, de tekeningen van de verschillende installatie disciplines, ontworpen door verschillende partijen, nog nimmer met elkaar in verhouding waren bekeken, laat staan wat dit nog eventueel voor gevolgen zou hebben voor de constructie.

Windkrachtje 6 en je kraan mag niet meer draaien, gevolg je hele planning naar de knoppen.

De optimalisatie van het eigenlijke bouwproces op de bouwplaats is volstrekt ondergeschikt aan al het andere. Tekeningen voor latere verdiepingen worden pas "definitief" als je al lang en breed met de eerste bezig bent.

Je werkt vaak met een volstrekt samengeraapt zooitje werknemers, waarbij een groot deel via onderaannemers en waarbij die onderaannemers vaak ook nog te weinig werk hebben op 1 bouwplaats.
Met als gevolg dat het meerdere projecten op een dag afloopt, met als gevolg dat ze er de volgende dag ook gewoon niet kunnen zijn, ja sorry, ander project ...

Constructies waar geen standaard oplossing voor is, waar je zelf materieel in elkaar mag gaan klussen om het voor elkaar te krijgen.

Kortom het is op iedere bouwplaats een nieuwe tijdelijke fabriek zien op te richten, in weer en wind, met nieuw personeel voor een product wat nog bergen aan wijzigingen kent, matig gedocumenteerd is. En vervolgens dat proberen te optimaliseren.

Kortom op zich wel ingenieurs werk, alleen niet echt long-lasting qua proces verbeteringen, nieuwe bouwplaats, nieuwe en andere kansen.

[whoami]

Feit is toch dat de requirements bij een 'ingenieursprojec' toch vast liggen. Als er een brug moet gebouwd worden weet je hoe lang/ hoe hoog die brug moet zijn en worden de specs voor maximale belasting enzo toch vastgelegd.
Bij IT Projecten liggen de requirements hopelijk ook vast, maar die veranderen precies altijd wat makkelijker tijdens de uitvoering.

[armageddon_2k1]

Vind de discussie over iemand met opleiding [X] in werkveld [Y] altijd zo grappig. Alsof die 4/5 jaar basiskennis opdoen allesbepalend zijn voor de komende 35 jaar. Factoren als doorzettingsvermogen, bereidheid tot leren en als allerbelangrijkste, de bereidheid tot verandering, zijn veel belangrijker. Dat papiertje is maar een toegangsbewijs tot de arbeidsmarkt (als het goed is), het echte leren komt daarna.

Dit zeg ik als ingenieur die nu een programmeerklus in Kotlin doet ;-)

whoami schreef op vrijdag 3 augustus 2018 @ 11:15:
Feit is toch dat de requirements bij een 'ingenieursprojec' toch vast liggen. Als er een brug moet gebouwd worden weet je hoe lang/ hoe hoog die brug moet zijn en worden de specs voor maximale belasting enzo toch vastgelegd.
Bij IT Projecten liggen de requirements hopelijk ook vast, maar die veranderen precies altijd wat makkelijker tijdens de uitvoering.

Boy, are you wrong Ja, de high-level-requirements zullen vastliggen en voor zoiets als een brug misschien iets strakker. Maar voor die 99% van de mensen die ander ingenieurswerk doen (bijvoorbeeld de ASML'ers, of zoals ik lang bij Philips) veranderen die door het project heen tot een bepaalde milestone. Het echte bouwen is vaak iets waar ik als ingenieur minder bij betrokken was. De collega's van ASML die ik sprak die hadden zoiets van "requirements?".

[Matis]

Bij de bouw van onze nieuwbouwwoning is het schokkend hoeveel in de daadwerkelijke uitvoering NIET volgens de tekeningen is gegaan.
En dan praten we nog maar over een "simpel" hoekwoninkje.

[ Voor 18% gewijzigd door Matis op 03-08-2018 11:29 ]

[armageddon_2k1]

Hoho, laten we even wat dingen uit elkaar halen, voordat we alle branches op een hoop gaan gooien:
- engineers != ingenieurs
- bouwvakkers != (engineers || ingenieurs)
- verificatie van requirements is iets anders als requirements hebben
- de bouwsector (woningen, dus niet boorplatforms ), vol met beunen, is een hele andere wereld dan vele andere ingenieursdomeinen. Ik heb er maar beperkte ervaring mee (dus @gekkie zal me wel corrigeren ), maar procesmatig loopt het enorm achter met andere ingenieursdomeinen. De redenen hiervoor zijn legio en ligt ook niet alleen maar bij de branche. Maar wat ik heb gezien, n=1, is dat er een enorm gat zit in 'wat er gebouwd moet worden = requirements' en of wat er gebouwd is voldoet aan de requirements (verificatie).

[Mugwump]

gekkie schreef op vrijdag 3 augustus 2018 @ 10:58:
[...]

Ahum, als bouwkundige moet ik je toch teleurstellen. Al zijn er de laatste jaren enige verbeteringen door de inzet van automatisering waardoor bijvb installatietechniek beter en eerder op elkaar kan worden afgestemd.

Maar tot niet al te lang geleden kwam het voor dat terwijl de fysieke bouw al was gestart, de tekeningen van de verschillende installatie disciplines, ontworpen door verschillende partijen, nog nimmer met elkaar in verhouding waren bekeken, laat staan wat dit nog eventueel voor gevolgen zou hebben voor de constructie.

Windkrachtje 6 en je kraan mag niet meer draaien, gevolg je hele planning naar de knoppen.

De optimalisatie van het eigenlijke bouwproces op de bouwplaats is volstrekt ondergeschikt aan al het andere. Tekeningen voor latere verdiepingen worden pas "definitief" als je al lang en breed met de eerste bezig bent.

Je werkt vaak met een volstrekt samengeraapt zooitje werknemers, waarbij een groot deel via onderaannemers en waarbij die onderaannemers vaak ook nog te weinig werk hebben op 1 bouwplaats.
Met als gevolg dat het meerdere projecten op een dag afloopt, met als gevolg dat ze er de volgende dag ook gewoon niet kunnen zijn, ja sorry, ander project ...

Constructies waar geen standaard oplossing voor is, waar je zelf materieel in elkaar mag gaan klussen om het voor elkaar te krijgen.

Kortom het is op iedere bouwplaats een nieuwe tijdelijke fabriek zien op te richten, in weer en wind, met nieuw personeel voor een product wat nog bergen aan wijzigingen kent, matig gedocumenteerd is. En vervolgens dat proberen te optimaliseren.

Kortom op zich wel ingenieurs werk, alleen niet echt long-lasting qua proces verbeteringen, nieuwe bouwplaats, nieuwe en andere kansen.

Oh ik stel ook zeker niet dat het ingenieursvak enkel wat standaardhandelingetjes uitvoeren betreft. Kom zelf uit een familie van bouwkundigen.
De zaken die jij hier noemt betreffen vooral de uitvoering en de uitdagingen die je daar tegenkomt. Waar in mijn ogen het grote verschil in zit is dat software-ontwikkeling an sich veel flexibeler is en daarmee ook bij opdrachtgevers het idee geeft dat je ad hoc gewoon de hele richting weer om kunt gooien.
Niemand zal een week voor oplevering van een brug roepen dat hij toch eigenlijk 50 meter verderop moet liggen. Als je tegen de aannemer roept dat je toch je liever even een andere steensoort ziet twee weken voor oplevering en dan heel verbaasd gaat doen dat dat je een vermogen gaat kosten en de oplevering flink vertraagt, dan word je weggehoond. In de IT zijn dat soort zaken helaas aan de orde van de dag.
Daar bovenop krijg je nog alle problemen die jij hier schetst.

[downtime]

Is dit allemaal niet een beetje onwaar? Legio grote bouwprojecten die uitlopen en ver over budget gaan zodra er meer dan een simpele blokkendoos moet komen. Noord-Zuidlijn, vliegveld bij Berlijn, JSF, zodra het geen dertien in een dozijn constructie meer is gaat het duurder worden en langer duren. Het nieuwe vliegveld van Berlijn is zo ver vertraagd dat het nu al te klein is geworden.

[Styxxy]

armageddon_2k1 schreef op vrijdag 3 augustus 2018 @ 11:45:
Hoho, laten we even wat dingen uit elkaar halen, voordat we alle branches op een hoop gaan gooien:
- engineers != ingenieurs

Inderdaad, dat is een veel voorkomend misverstand. Veel mensen vertalen "engineer" letterlijk als "ingenieur". Bv in België is ingenieur een (beschermde) titel (ir.) die je niet zo maar mag gebruiken. Echter als je zegt dat je "software engineer" bent, mag dat wel. Ik heb paar jaar geleden gehad dat een "ir.", die zeer trots op de titel was, het niet accepteerde dat ik "(software) engineer" was.

[armageddon_2k1]

downtime schreef op vrijdag 3 augustus 2018 @ 12:02:
Is dit allemaal niet een beetje onwaar? Legio grote bouwprojecten die uitlopen en ver over budget gaan zodra er meer dan een simpele blokkendoos moet komen. Noord-Zuidlijn, vliegveld bij Berlijn, JSF, zodra het geen dertien in een dozijn constructie meer is gaat het duurder worden en langer duren. Het nieuwe vliegveld van Berlijn is zo ver vertraagd dat het nu al te klein is geworden.

Dit is natuurlijk een beetje bias he? Je ziet en hoort alleen van de projecten die ruk gaan. Dus gebaseerd op die observatie gaan zeggen dat, zodra het geen dertien in een dozijn constructie is het duurder wordt en langer gaat duren (dan wat?), een beetje kort door de bocht.

Uiteraard is iets dat nog nooit gedaan is of niet erg bekend is duurder en moeilijker. Dat is in elk domein.

Styxxy schreef op vrijdag 3 augustus 2018 @ 12:03:
[...]

Inderdaad, dat is een veel voorkomend misverstand. Veel mensen vertalen "engineer" letterlijk als "ingenieur". Bv in België is ingenieur een (beschermde) titel (ir.) die je niet zo maar mag gebruiken. Echter als je zegt dat je "software engineer" bent, mag dat wel. Ik heb paar jaar geleden gehad dat een "ir.", die zeer trots op de titel was, het niet accepteerde dat ik "(software) engineer" was.

Man...sowieso dat mensen trots zijn op een titel vind ik al zo sneu en het gebruiken zich af te zetten tegen anderen. Definieert die titel die je ooit gehaald hebt je identiteit dan zo erg? Vind ik ook altijd zo grappig als er dan iemand op werk in z'n ondertitel heeft staan: "ERP ICN ANDSO DDSNK ICANN SAP" of wat nog meer. Vaak zijn dat de financiele mannetjes die kicken op status.

[DevWouter]

Styxxy schreef op vrijdag 3 augustus 2018 @ 12:03:
[...]

Inderdaad, dat is een veel voorkomend misverstand. Veel mensen vertalen "engineer" letterlijk als "ingenieur". Bv in België is ingenieur een (beschermde) titel (ir.) die je niet zo maar mag gebruiken. Echter als je zegt dat je "software engineer" bent, mag dat wel. Ik heb paar jaar geleden gehad dat een "ir.", die zeer trots op de titel was, het niet accepteerde dat ik "(software) engineer" was.

Je hebt ook twee titels namelijk "ing." en "ir." (althans in Nederland). Beide zijn beschermd. Dat hij er zo trots op zijn titel is, maar het onderscheid niet kent is een beetje treurig.

En mensen die er trots op zijn zou ik continue een brief schrijven waarbij ik "s.s.t.t." gebruiken als titel.

[Mugwump]

Styxxy schreef op vrijdag 3 augustus 2018 @ 12:03:
[...]

Inderdaad, dat is een veel voorkomend misverstand. Veel mensen vertalen "engineer" letterlijk als "ingenieur". Bv in België is ingenieur een (beschermde) titel (ir.) die je niet zo maar mag gebruiken. Echter als je zegt dat je "software engineer" bent, mag dat wel. Ik heb paar jaar geleden gehad dat een "ir.", die zeer trots op de titel was, het niet accepteerde dat ik "(software) engineer" was.

Een opleiding Technische Informatica aan een TU in Nederland leverde je ook gewoon een Ir. titel op. Nu is dat het MSc equivalent.

[gekkie]

armageddon_2k1 schreef op vrijdag 3 augustus 2018 @ 11:45:
De redenen hiervoor zijn legio en ligt ook niet alleen maar bij de branche. Maar wat ik heb gezien, n=1, is dat er een enorm gat zit in 'wat er gebouwd moet worden = requirements' en of wat er gebouwd is voldoet aan de requirements (verificatie).

Valt overigens ook niet altijd mee die verificatie, neem een beetje een woontoren en ga daar eens wapeningscontrole doen. Ja helaas tekening is A0 en windkracht 5 met een beetje miezer regen, succes met verifieren of alles netjes op z'n plek ligt in die spaghetti en een wapperende tekening in een semi-transparante hoes !

Verder is het qua vastleggen qua (definitief) ontwerp bijna een sport om alles tot het laatste moment (en verder) uit te stellen.
Helaas zie je dan ook dat de winst die je kunt boeken met betere methoden, automatisering en processen, opgesouppeerd wordt door het nooooggggggg langer kunnen uitstellen. Daarnaast zijn er zoveel partijen bij financieren, ontwerp en realisatie betrokken dat er ook nog eens een hele berg deelbelangen zijn.
Maarja opdrachtgevers (buiten de overheid en civiele techiek) willen kunnen "kiezen" en een "uniek" ontwerp, dus daar zijn design en build opdrachten maar beperkt.

En als laatste zijn veel bouwmaterialen qua toleranties en interfaces ook wat erhmmmm apart terwijl er aan de andere kant wel een naadloos afwerkingsniveau wordt verlangd
Maar goed, exception krimpscheurtje afvangen en "frunnik_afdeklatje()" aanroepen et voila weer een gefixte interface .

Styxxy schreef op vrijdag 3 augustus 2018 @ 12:03:
[...]
Inderdaad, dat is een veel voorkomend misverstand. Veel mensen vertalen "engineer" letterlijk als "ingenieur". Bv in België is ingenieur een (beschermde) titel (ir.) die je niet zo maar mag gebruiken. Echter als je zegt dat je "software engineer" bent, mag dat wel. Ik heb paar jaar geleden gehad dat een "ir.", die zeer trots op de titel was, het niet accepteerde dat ik "(software) engineer" was.

Mjah iedereen en alles noemt zich in NL dan ook niet voor niets "University" (onbeschermd) ipv "Universiteit" (wel beschermd). Wat dat betreft is die nagestreefte angloficatie leuk en aardig, maar doe het dan wel volledig.

Overigens als ik eens een titel gebruik, dan gebruikis het inderdaad "Ir." en geen "Msc", dan zoekt die buitenlander het maar op of hij vraagt het, maar goed ik ben dan ook een tikkie eigenwijs .

downtime schreef op vrijdag 3 augustus 2018 @ 12:02:
Is dit allemaal niet een beetje onwaar? Legio grote bouwprojecten die uitlopen en ver over budget gaan zodra er meer dan een simpele blokkendoos moet komen. Noord-Zuidlijn, vliegveld bij Berlijn, JSF, zodra het geen dertien in een dozijn constructie meer is gaat het duurder worden en langer duren. Het nieuwe vliegveld van Berlijn is zo ver vertraagd dat het nu al te klein is geworden.

Bij grote overheidsprojecten weten de ingenieurs dat soms al van meet af aan en is het een politiek probleem. Hetzij doordat het een project is wat men persé door wil laten gaan, waarbij het benodigde budget tegen beter weten in wordt verlaagd om het politiek haalbaar te maken. Anderszijds door dat iedereen nog plasjes gaat doen en het budget onvoldoende wordt aangepast (want het project moet dooooorrrr).
Anderzijds door de invloed van vertragingen door de bijna altijd ellelange procedures die na een lange tijd bij de raad van state eindigen (zou je eigenlijk al standaard kunnen opnemen in de kosten, maarja het project moet .....)

Mugwump schreef op vrijdag 3 augustus 2018 @ 11:49:
[...]
De zaken die jij hier noemt betreffen vooral de uitvoering en de uitdagingen die je daar tegenkomt. Waar in mijn ogen het grote verschil in zit is dat software-ontwikkeling an sich veel flexibeler is en daarmee ook bij opdrachtgevers het idee geeft dat je ad hoc gewoon de hele richting weer om kunt gooien.
Niemand zal een week voor oplevering van een brug roepen dat hij toch eigenlijk 50 meter verderop moet liggen. Als je tegen de aannemer roept dat je toch je liever even een andere steensoort ziet twee weken voor oplevering en dan heel verbaasd gaat doen dat dat je een vermogen gaat kosten en de oplevering flink vertraagt, dan word je weggehoond. In de IT zijn dat soort zaken helaas aan de orde van de dag.
Daar bovenop krijg je nog alle problemen die jij hier schetst.

Een week voor oplevering niet, maar in de woning/utiliteitsbouw worden aanpassingen gedurende de bouwfase ook als normaal gezien (al was het maar omdat de noodzakelijk zijn omdat er conflicten zijn met bijvb installaties, tegenwoordig iets minder relevant door BIM en 3D moddeling). Civiele techniek is wat dat betreft een wat andere hoek waarbij je tegenwoordig wel design en build contracten hebt. Dan kun je vanuit het ontwerp ook rekening houden met het bouwproces. Niet dat dat altijd goed gaat getuigen de grote bouwbedrijven die zich toch ook behoorlijk hebben verslikt bij een paar design build finance &maintenance contracten.

In de IT is het waarschijnlijk nog wat erger qua aanpassingen omdat het niet "stoffelijk" is.
Aan de andere kant begrijpt mevrouw ook niet altijd dat ze maanden van te voren de exacte plaats van haar wandcontactdozen moet opgeven bij prefab knutselwerk van haar appartementje, maar goed in de bouw verkopen ze dan wel "Nee" of dat "kost wat heb je ook wat" als de orderportefeuille gevuld is.
In de IT zijn ze kennelijk wat minder de botte boer op dat aspect (tenzij het een overheidsproject is?) ondanks dat de orderportefeuille meestal toch ook wel goed zit.

And on another note:
Fijn dat er maar beperkte documentatie is rond om de Gstreamer python bindings.
Kun je in de C++ docs gaan zitten turen en verzinnen wat het probleem is. Lijkt er op dat buffers niet meer automagisch geunreffed worden als je het python object unreffed. Maar er was ook geen unref() functie in de python bindings . En dan gaat het best hard met je memory .. uncompressed frames bij een leuk full HD filmpje . Maar goed kan nu de buffers op een andere manier mappen en daar zit wel een unmap functie bij .

[ Voor 66% gewijzigd door gekkie op 03-08-2018 13:53 ]

[Mugwump]

gekkie schreef op vrijdag 3 augustus 2018 @ 13:08:

[...]

Een week voor oplevering niet, maar in de woning/utiliteitsbouw worden aanpassingen gedurende de bouwfase ook als normaal gezien (al was het maar omdat de noodzakelijk zijn omdat er conflicten zijn met bijvb installaties, tegenwoordig iets minder relevant door BIM en 3D moddeling). Civiele techniek is wat dat betreft een wat andere hoek waarbij je tegenwoordig wel design en build contracten hebt. Dan kun je vanuit het ontwerp ook rekening houden met het bouwproces. Niet dat dat altijd goed gaat getuigen de grote bouwbedrijven die zich toch ook behoorlijk hebben verslikt bij een paar design build finance &maintenance contracten.

In de IT is het waarschijnlijk nog wat erger qua aanpassingen omdat het niet "stoffelijk" is.
Aan de andere kant begrijpt mevrouw ook niet altijd dat ze maanden van te voren de exacte plaats van haar wandcontactdozen moet opgeven bij prefab knutselwerk van haar appartementje, maar goed in de bouw verkopen ze dan wel "Nee" of dat "kost wat heb je ook wat" als de orderportefeuille gevuld is.
In de IT zijn ze kennelijk wat minder de botte boer op dat aspect (tenzij het een overheidsproject is?) ondanks dat de orderportefeuille meestal toch ook wel goed zit.

Het probleem is in de IT ook vaak simpelweg dat bepaalde changes / nieuwe inzichten gewoon moeten worden uitgevoerd omdat het opgeleverde product anders vrijwel nutteloos is. Een huis waarin de wandcontactdozen op de verkeerde plek zijn zal misschien geen hele blije bewoner opleveren, maar is verder gewoon prima bewoonbaar. Een systeem dat geen rekening houdt met nieuwe juridische kaders, belasting- of auditingregels en ga zo maar door is vaak gewoon niet te gebruiken. Dan kun je of een project volledig afschieten of er extra tijd en geld tegenaan gooien.

[gekkie]

Mugwump schreef op vrijdag 3 augustus 2018 @ 14:07:
[...]
Het probleem is in de IT ook vaak simpelweg dat bepaalde changes / nieuwe inzichten gewoon moeten worden uitgevoerd omdat het opgeleverde product anders vrijwel nutteloos is. Een huis waarin de wandcontactdozen op de verkeerde plek zijn zal misschien geen hele blije bewoner opleveren, maar is verder gewoon prima bewoonbaar. Een systeem dat geen rekening houdt met nieuwe juridische kaders, belasting- of auditingregels en ga zo maar door is vaak gewoon niet te gebruiken. Dan kun je of een project volledig afschieten of er extra tijd en geld tegenaan gooien.

Mjah qua regels zou het fijn zijn als eens wat minder wijzigingen (en dus wat beter overdenken ipv gehaast invoeren en wegens succes dan weer schrappen), en minimale invoeringstermijn hanteren en zaken eens niet op een random plek in een boekjaar klussen. Zou de belastingdienst ook een hoop hoofdbrekens schelen.

Net als die pipo's van de ING die het leuk vinden om de volgorde van je afschriften te wijzigen midden in een jaar (en wat is de besparing in inkt precies voor het printen van een bloody volgnummer op die dingen) .

[DevWouter]

Mugwump schreef op vrijdag 3 augustus 2018 @ 14:07:
[...]


Het probleem is in de IT ook vaak simpelweg dat bepaalde changes / nieuwe inzichten gewoon moeten worden uitgevoerd omdat het opgeleverde product anders vrijwel nutteloos is. Een huis waarin de wandcontactdozen op de verkeerde plek zijn zal misschien geen hele blije bewoner opleveren, maar is verder gewoon prima bewoonbaar. Een systeem dat geen rekening houdt met nieuwe juridische kaders, belasting- of auditingregels en ga zo maar door is vaak gewoon niet te gebruiken. Dan kun je of een project volledig afschieten of er extra tijd en geld tegenaan gooien.

Dat is nogal een scheve vergelijking. Een onhandig geplaatste stopcontact klinkt voor mij eerder alsof de exporter CSV produceert ipv XML/JSON.

Het niet houden aan de juridische kaders, belasting- of auditingregels klinkt meer als een brug dat een tunnel moet zijn.
* DevWouter is ook best goed in het maken van scheve vergelijkingen

[Mugwump]

DevWouter schreef op vrijdag 3 augustus 2018 @ 14:29:
[...]


Dat is nogal een scheve vergelijking. Een onhandig geplaatste stopcontact klinkt voor mij eerder alsof de exporter CSV produceert ipv XML/JSON.

Het is ook geen vergelijking. Dat was het hele punt. Ik probeer al een aantal posts aan te geven dat de natuur van de 'ad hoc' wijzigingen in de IT veel fundamenteler is. wandcontactdozen verplaatsen is te vergelijken met cosmetische interface changes. Niet iets waar je als ontwikkelaar direct blij van wordt als dat nogal ad hoc moet gebeuren, maar qua risico niet zo groot.
Het probleem in de IT is nu juist dat er vaak genoeg wijzigingen uit de lucht komen vallen die het hele fundament van je complete oplossing raken. Daarom gaf ik ook onder andere aan dat vrijwel niemand halverwege besluit dat een huis toch eigenlijk drie meter naar achteren moet.

Het niet houden aan de juridische kaders, belasting- of auditingregels klinkt meer als een brug dat een tunnel moet zijn.
* DevWouter is ook best goed in het maken van scheve vergelijkingen

Ik had het ook niet over 'niet houden aan', maar over het feit dat dat soort kaders en regels gewoon gewijzigd kunnen worden gedurende de looptijd van een (meerjarig) IT project met enorme impact.

[F.West98]

Mugwump schreef op vrijdag 3 augustus 2018 @ 15:24:
[...]


Het is ook geen vergelijking. Dat was het hele punt. Ik probeer al een aantal posts aan te geven dat de natuur van de 'ad hoc' wijzigingen in de IT veel fundamenteler is. wandcontactdozen verplaatsen is te vergelijken met cosmetische interface changes. Niet iets waar je als ontwikkelaar direct blij van wordt als dat nogal ad hoc moet gebeuren, maar qua risico niet zo groot.
Het probleem in de IT is nu juist dat er vaak genoeg wijzigingen uit de lucht komen vallen die het hele fundament van je complete oplossing raken. Daarom gaf ik ook onder andere aan dat vrijwel niemand halverwege besluit dat een huis toch eigenlijk drie meter naar achteren moet.

In China zijn ze daar anders best goed in

[Verwijderd]

gekkie schreef op vrijdag 3 augustus 2018 @ 13:08:
And on another note:
Fijn dat er maar beperkte documentatie is rond om de Gstreamer python bindings.
Kun je in de C++ docs gaan zitten turen en verzinnen wat het probleem is. Lijkt er op dat buffers niet meer automagisch geunreffed worden als je het python object unreffed. Maar er was ook geen unref() functie in de python bindings . En dan gaat het best hard met je memory .. uncompressed frames bij een leuk full HD filmpje . Maar goed kan nu de buffers op een andere manier mappen en daar zit wel een unmap functie bij .

Gebruik jij GStreamer via GObject Introspection?

[gekkie]

Verwijderd schreef op zaterdag 4 augustus 2018 @ 00:18:
[...]
Gebruik jij GStreamer via GObject Introspection?

Python:

import gi
gi.require_version('Gst', '1.0')
from gi.repository import GObject, Gst

I'm afraid so ... op zich werkt gstreamer best mooi, maar de python documentatie is echt en dus zoeken in code examples en gokken op basis van de c++ docs.

[DevWouter]

F.West98 schreef op vrijdag 3 augustus 2018 @ 22:08:
[...]


In China zijn ze daar anders best goed in
[afbeelding]

En in Japan kunnen ze er ook aardig wat van.

[Verwijderd]

gekkie schreef op zaterdag 4 augustus 2018 @ 00:29:
[...]

Python:

import gi
gi.require_version('Gst', '1.0')
from gi.repository import GObject, Gst

I'm afraid so ... op zich werkt gstreamer best mooi, maar de python documentatie is echt en dus zoeken in code examples en gokken op basis van de c++ docs.

Ja, GStreamer is wel OK, maar alle GNOME zooi gebruikt GObject (hun library met een event loop, data types, etc), waardoor ze GObject Introspection kunnen gebruiken om automatisch bindings voor andere talen te maken, maar daardoor documenteren ze die bindings zo goed als niet (behalve een paar voorbeelden voor de meest basale dingen) en moet je dus maar gokken op basis van de C documentatie.

[gekkie]

Verwijderd schreef op zaterdag 4 augustus 2018 @ 10:49:
[...]


Ja, GStreamer is wel OK, maar alle GNOME zooi gebruikt GObject (hun library met een event loop, data types, etc), waardoor ze GObject Introspection kunnen gebruiken om automatisch bindings voor andere talen te maken, maar daardoor documenteren ze die bindings zo goed als niet (behalve een paar voorbeelden voor de meest basale dingen) en moet je dus maar gokken op basis van de C documentatie.

Je zou toch zeggen dat je daar dan ook wel een doc-generator-o-fucker tegen aan zou moeten kunnen gooien.
Bij language bindings van andere projecten (neem bijvb een opencv) lukt dat wel, maar goed het zal wel een prioriteits kwestie zijn.

[PdeBie]

Niet echt een programmeer dingetje, maar wel functioneel iets.

Ik loop op de testomgeving tegen een issue aan waarbij ik vraagtekens heb. Ik bel de klant om te overleggen en hij geeft aan: Dat is geen probleem, dat gaat in de praktijk waarschijnlijk toch niet voorkomen.

Juist... dat woordje waarschijnlijk bevalt mij al niet. Ik zie het eerste support ticket al binnenkomen