De Devschuur Coffee Corner - Iteratie ⓬

[Hydra]

gekkie schreef op dinsdag 14 april 2020 @ 11:14:
Klopt, al kan ik ook niet vinden dat "zelf doen", nou tot extreem veel meer problemen hoeft te leiden.
Beiden kan prima werken en het uitbesteden van een hoop setup werk is inderdaad makkelijk.

Tja. In theorie wel. In de praktijk zie ik toch echt dat "zelf down" er vrijwel altijd toe leidt dat er shortcuts genomen worden omdat het toch allemaal wel erg veel tijd kost. En daarbij heb ik gewoon niet zulke goeie ervaringen met de 'gemiddelde' Opser. Echt goeie zijn zo extreem zeldzaam.

[Koenvh]

gekkie schreef op dinsdag 14 april 2020 @ 08:35:
[...]

Bijvb zoals ik al aangaf bij de GROUP BY's wat strenger in de leer is en dus een query weigert uit te voeren, wat dan weer niet netjes wordt afgevangen in een transcactie en rollback van het geheel en hee presto we hebben een verneukte database. (al geloof ik dat mysql/maria nu ook iets van een "strict" mode hadden ofzo, heb me er verder niet echt in verdiept).


[...]

Vanaf MySQL 8 is dat geloof ik standaard strict. Kun je overigens wel uitzetten.

Hydra schreef op dinsdag 14 april 2020 @ 10:46:
[...]

Nee, dan parkeer ik 't liever bij Google. Daarbij; Google en AWS lopen lichtjaren voor op 'gewone' hosting providers met alle producten die ze bieden. Heb weinig behoefte m'n eigen Kubernetes of Kafka cluster op te moeten tuigen bijvoorbeeld.

Klopt, al ga ik ook graag voor de tussenweg (DigitalOcean, Hetzner, OVH), afhankelijk van het project. Scheelt een hoop geld, en je krijgt ook contact voor technische problemen zonder een zak geld neer te hoeven leggen (zoals bij Google wel het geval is). Maar dat maakt me niet uit als anderen het betalen

[ Voor 36% gewijzigd door Koenvh op 14-04-2020 12:47 ]

[gekkie]

Hydra schreef op dinsdag 14 april 2020 @ 12:01:
[...]
Tja. In theorie wel. In de praktijk zie ik toch echt dat "zelf down" er vrijwel altijd toe leidt dat er shortcuts genomen worden omdat het toch allemaal wel erg veel tijd kost. En daarbij heb ik gewoon niet zulke goeie ervaringen met de 'gemiddelde' Opser. Echt goeie zijn zo extreem zeldzaam.

Bij jouw Opser's gaat het een beetje zoals: https://www.ed.nl/buitenl...nceert-zichzelf~aa146152/ ?

Koenvh schreef op dinsdag 14 april 2020 @ 12:42:
[...]
Vanaf MySQL 8 is dat geloof ik standaard strict. Kun je overigens wel uitzetten.

Hmm gauw uitzetten dan, anders werkt tante sjaan d'r wordpress plugin niet meer.
Achja mysql / maria hebben nu ook CTE's, json en de hele riedel. Wat dat betreft hebben ze op zich wel hard door gebouwd.

[ Voor 25% gewijzigd door gekkie op 14-04-2020 16:24 ]

[Motrax]

gekkie schreef op dinsdag 14 april 2020 @ 10:03:
[...]

En als je je wel graag zorgen wilt maken om licenties, dan kun je beter Oracle nemen .

We hebben specifieke projecten gedraaid met maar 1 doelstelling: alle Oracle spullen er uit. Alles. Niet alleen de database. Maar ze nemen steeds weer dingen over, kunnen we er weer software uitwerken

[Sandor_Clegane]

Sebazzz schreef op dinsdag 14 april 2020 @ 09:01:
[...]

Feitelijk als de je Express editie gebruikt hoef je je voor licenties niet zorgen te maken - en als het puur voor ontwikkeldoeleinden is dan kan je met de developer editie ook vooruit.

Als je boven de limieten van Express komt dan heb je ook waarschijnlijk wel genoeg marge om een licentie te kunnen aanschaffen

True, alleen als je dan leuke features wilt gebruiken, laten we zeggen documenten op een fileshare zetten via een UNC pad, dan moet je daarna de enterprise versie installeren.

External blobs.

[Sebazzz]

Sandor_Clegane schreef op dinsdag 14 april 2020 @ 20:51:
[...]


True, alleen als je dan leuke features wilt gebruiken, laten we zeggen documenten op een fileshare zetten via een UNC pad, dan moet je daarna de enterprise versie installeren.

External blobs.

Het is niet helemaal hetzelfde als RBS [ik neem aan dat je het daarover hebt], maar FILESTREAM voldoet in veel gevallen ook en daarmee blijf je wel netjes onder het 2GB limiet van SQL Server.

Het is wel jammer dat veel nuttige features zoals bijvoorbeeld TDS (SQL < 2019) enkel op SQL Server Enterprise beschikbaar zijn. Always Encrypted heb je bijvoorbeeld niet zoveel aan als je in de DB wilt sorteren of op gedeeltes van de cijfertekst moet kunnen zoeken.

[gekkie]

Motrax schreef op dinsdag 14 april 2020 @ 19:57:
[...]
We hebben specifieke projecten gedraaid met maar 1 doelstelling: alle Oracle spullen er uit. Alles. Niet alleen de database. Maar ze nemen steeds weer dingen over, kunnen we er weer software uitwerken

"Motrax the OracleSlayer" The ever continuing trilogy

[Mugwump]

Hydra schreef op dinsdag 14 april 2020 @ 12:01:
[...]


Tja. In theorie wel. In de praktijk zie ik toch echt dat "zelf down" er vrijwel altijd toe leidt dat er shortcuts genomen worden omdat het toch allemaal wel erg veel tijd kost. En daarbij heb ik gewoon niet zulke goeie ervaringen met de 'gemiddelde' Opser. Echt goeie zijn zo extreem zeldzaam.

Ik heb met heel wat Opsers gewerkt die heel goed waren in "zelf down".

[Sandor_Clegane]

Sebazzz schreef op dinsdag 14 april 2020 @ 21:12:
[...]

Het is niet helemaal hetzelfde als RBS [ik neem aan dat je het daarover hebt], maar FILESTREAM voldoet in veel gevallen ook en daarmee blijf je wel netjes onder het 2GB limiet van SQL Server.

Het is wel jammer dat veel nuttige features zoals bijvoorbeeld TDS (SQL < 2019) enkel op SQL Server Enterprise beschikbaar zijn. Always Encrypted heb je bijvoorbeeld niet zoveel aan als je in de DB wilt sorteren of op gedeeltes van de cijfertekst moet kunnen zoeken.

RBS was maar een voorbeeld, maar dat is wel wat ik bedoel. In Postgres heb je gewoon alle functies tot je beschikking en zit je geen technische afwegingen te maken voor niet technische limieten.

Dat was een beetje de gist van mijn verhaaltje.

[Motrax]

Sebazzz schreef op dinsdag 14 april 2020 @ 21:12:
Always Encrypted heb je bijvoorbeeld niet zoveel aan als je in de DB wilt sorteren of op gedeeltes van de cijfertekst moet kunnen zoeken.

Always Encrypt is sowieso een feature welke niet goed geïmplementeerd is. Een database staat niet alleen op zich zelf. Leuk dus dat er encryptie op een veld is, maar als je alleen focussed op de gehele BI stack van MS, dan ondersteund bijna geen andere tool de Always Encrypt. Laat staan als je non-MS tools gebruikt.

Dus je laad data richting Power BI, Power BI kan dan dacht ik nog net Always Encrypted data decrypten, maar in Power BI is het weer niet versleuteld. Ja de algemene versleuteling/security, maar niet zoals Always Encrypt bedacht is.

[jbdeiman]

Motrax schreef op woensdag 15 april 2020 @ 06:26:
[...]
Always Encrypt is sowieso een feature welke niet goed geïmplementeerd is. Een database staat niet alleen op zich zelf. Leuk dus dat er encryptie op een veld is, maar als je alleen focussed op de gehele BI stack van MS, dan ondersteund bijna geen andere tool de Always Encrypt. Laat staan als je non-MS tools gebruikt.

Dus je laad data richting Power BI, Power BI kan dan dacht ik nog net Always Encrypted data decrypten, maar in Power BI is het weer niet versleuteld. Ja de algemene versleuteling/security, maar niet zoals Always Encrypt bedacht is.

Wij hebben er (vanwege doorzoekbaarheid) voor gekozen om met hardwarematige encryptie te werken, en er zijn meerdere 'hoepels' nodig om bij de database omgeving te geraken (waarna je ook nog in moet loggen om de database in te kunnen zien).
Onze software draait in de cloud, en de database is (mits de juiste gegevens bekend zijn) alleen via 2 lagen te benaderen, of via onze software.
1. inloggen in de 'cloud omgeving'
2. inloggen in de web-omgeving
3. inloggen in de database omgeving

Alle credentials zijn willekeurig en anders dan iedere vervolgstap, daarmee is de database zelf benaderen practisch niet te doen. De software wordt gepen-test (whitebox en blackbox), waarmee ook dat potentiële lek zo dicht mogelijk is.
En de schijven zijn hardwarematig versleuteld, dwz dat als iemand (die dan toegang heeft tot het datacenter) en een schijf meeneemt, die daar nog niets mee kan (een hele server meenemen valt wel op dacht ik zo).

Qua security zijn wij ingesteld op dat het altijd een kat en muis-spelletje zal blijven, dwz dat wij (binnen het redelijke) er alles aan doen om het zo veilig mogelijk te doen, en als er iets bekend wordt wat een potentieel lek is wordt dat ook bekeken en indien nodig opgelost.

[Antrax]

Net securitytxt.org gespot. Er is zelfs een rfc draft voor. It makes sense, kinda.

[Feanathiel]

.oisyn schreef op donderdag 16 april 2020 @ 16:06:
[...]

In een dynamische taal weet je hooguit alleen dat Foo en/of Bar een operator+ heeft. Maar je weet niet of Foo ook instances van Bar afhandelt in zijn operator+. Je kunt dan zeggen: de linkerkant bepaalt. Maar dan kom je weer in de knoei met built-in types, want die kun je niet overriden, dus dan bepaalt ineens de rechterkant. In het geval van een static op Foo met twee operands moet je dan ook nog eens gaan opzoeken welke van de twee de Foo is in dit verhaal. Een aparte functie voor als Foo rechts staat is dan wel prettig. Maar wel weer meer implementatiewerk.

Het is ook even uitkijken dat je geen onverwachte situaties krijgt. Dus dat bijvoorbeeld operatorEquals([this] number, string) een ander antwoord geeft dan operatorEquals([this] string, number), mocht die bestaan.

Waar gebruik je de tool voor, puur uit interesse? Of is het meer een hobby project? Bestaat ook alweer (bijna/ruim) 20 jaar namelijk.

[.oisyn]

Feanathiel schreef op zaterdag 18 april 2020 @ 13:26:
[...]


Het is ook even uitkijken dat je geen onverwachte situaties krijgt. Dus dat bijvoorbeeld operatorEquals([this] number, string) een ander antwoord geeft dan operatorEquals([this] string, number), mocht die bestaan.

Tja, als je equality niet commutatief wil maken moet je dat natuurlijk zelf weten

Waar gebruik je de tool voor, puur uit interesse? Of is het meer een hobby project? Bestaat ook alweer (bijna/ruim) 20 jaar namelijk.

Wow, good find
Niet *helemaal* waar though. Dit kun je zien als de derde complete rewrite .

Kol Q l8or 1 was niet meer dan een simpele rekenmachine waarbij je een expressie in kon typen, met C-like operatoren en outputs in verschillende bases. Vooral het kunnen intypen en editen van een expressie vond ik heel belangrijk want Windows Calculator modelleert een echt fysieke rekenmachine, waarbij je getallen in kunt voeren en dan op een knop kan rammen, maar naderhand nooit meer de daadwerkelijke berekening iets kan aanpassen. Jammer dat die screenshot niet meer bestaat in die oude post. Kan er ook niets meer over terugvinden op mijn PC of Nas. Volgens mij heb ik de code nog wel ergens op een oude backup CD staan.

Maar goed, Kol Q l8or 1 had al snel zijn tekortkomingen. Ik wilde ook gewoon zelf variabelen en functies kunnen definieren. En ik wilde meer een console achtige interface waarin je alle vorige resultaten kunt terugzien. En zo ontstond dus Kol Q l8or 2 in 2010.



Deze werd uiteindelijk Turing Complete toen ik vectoren en recursie toevoegde . Maar ik miste wel de echte programmeermogelijkheden, en andere types zoals strings en objecten. Ik gebruikte de Coco/R parser generator, maar ik vond het altijd een hoop werk om een nieuwe feature toe te voegen. Helaas is de code ervan verloren gegaan in de Grote HDD Crash van 2013, dus ik ben weer opnieuw begonnen in 2017.

Mijn interesse hiervoor werd gewekt bij een poging tot het salvagen van bepaalde files van de gecrashte RAID 0 array (1 disk was aan gruzelementen, de andere werkte nog). Ik vond de sourcefile van een bignum library van me terug. De bijbehorende header was corrupt dus die heb ik opnieuw moeten intypen. Nadat ik die enigszins productierijp had gemaakt ging ik er een parser omheen bouwen. Dat mondde uiteindelijk uit in KolQ. De parser hier is een handgeschreven recursive descent parser. Na mijn jarenlange gexperimenteer met verschillende parser generators was ik verbaasd over hoveel makkelijker het is om die dingen gewoon zelf met de hand te schrijven, en hoeveel makkelijker het vervolgens ook is om een feature toe te voegen.

Maar om je vraag te beantwoorden waarom ik dit doe, het voornaamste doel is eigenlijk gewoon interesse . Compilerbouw heb ik altijd een interessant vakgebied gevonden en zoals je ziet ben ik daar ook veel mee bezig geweest. Maar dit project is meer dan dat, ik gebruik het ook dagelijks bij mijn werk. KolQ is nog niet helemaal productierijp, maar Kol Q l8or 2 is gewoon een tray app die ik elke dag wel even aanklik om gewoon even iets uit te rekenen. Maar laatst zat ik wat code te debuggen (een Delaunay tetrahedralizer) en daarbij moest ik wat matrix bewerkingen verifieren. Er zijn wel wat online tools voor (zoals deze), maar ik miste iets om een loopje te kunnen doen. En tus ging ik support voor matrices toevoegen aan KolQ.

Het mooie was vooral dat ik dat gewoon kon doen in KolQ zelf, kwestie van even een Matrix klasse definieren en de bijbehorende operaties. Maar ik had nog geen support voor operator overloading, en het zou wel handig zijn om dat hiervoor te hebben, dus toen heb ik dat er ook maar even ingehangen.

Goed, natuurlijk was mijn implementatie natuurlijk niet meteen goed, maar het probleem is dat mijn error reporting nog zeer ondermaats is. Ik moest het doen met "Wrong number of arguments in function call" op het moment dat ik een matrix inverteer. Geen idee welke functie of op welke regel ik dat moest zoeken. Nou heb ik de bug inmiddels al wel gefixed, maar dit stoorde me zo erg dat ik inmiddels allerlei debuginfo aan het toevoegen ben. Zo genereer ik inmiddels callstacks, en hou ik source code locaties bij

[RayNbow]

.oisyn schreef op zondag 19 april 2020 @ 01:43:
[...]Vooral het kunnen intypen en editen van een expressie vond ik heel belangrijk[...]

Heet dat niet gewoon Excel?

[Hydra]

RayNbow schreef op zondag 19 april 2020 @ 07:24:
Heet dat niet gewoon Excel?

Da's een rare manier om Python te spellen...

Neemt overigens niet wel dat ik dat soort spul waar @.oisyn mee bezig is ook erg cool vindt. Heb zelfs iets dergelijks met Java en Antlr gemaakt een tijd terug. Ook een keer een workshop over gegeven. Dit terwijl ik Vertalerbouw 1 en 2 echt de grootste shitvakken van m'n opleiding vond.

Maarja. Op de middelbare voorgenomen om, toen ik Duits eindelijk kon droppen, nooit meer Duits te gaan spreken. En toen dus een half jaar in Wenen gewoond... Denk dat m'n leraar Duits in een scheur gelegen had.

[ Voor 57% gewijzigd door Hydra op 19-04-2020 11:49 ]

[Feanathiel]

.oisyn schreef op zondag 19 april 2020 @ 01:43:
Helaas is de code ervan verloren gegaan in de Grote HDD Crash van 2013, dus ik ben weer opnieuw begonnen in 2017.

Dank voor je uitleg.

Ah, balen van die data man. Eerder bij mij ook gebeurd. Geeft je ergens toch ook weer vrijheid om dingen op een andere manier te doen.

.oisyn schreef op zondag 19 april 2020 @ 01:43:
Vooral het kunnen intypen en editen van een expressie vond ik heel belangrijk want Windows Calculator modelleert een echt fysieke rekenmachine, waarbij je getallen in kunt voeren en dan op een knop kan rammen, maar naderhand nooit meer de daadwerkelijke berekening iets kan aanpassen.

Die snap ik goed. Ff snel wat uitrekenen, eventueel wat aanpassen en weer verder. Excel is soms handig als je niet veel hoeft aan te passen, maar daar zit je al snel in de knoop als je zoiets als (eigen) functies of objecten wilt gebruiken (ja, via VBA ).

Hydra schreef op zondag 19 april 2020 @ 11:47:
Da's een rare manier om Python te spellen...

Neemt overigens niet wel dat ik dat soort spul waar @.oisyn mee bezig is ook erg cool vindt.

Dat is het 'm ook. Meestal begin ik aan zoiets, maar kom er dan al snel achter dat anderen daar veel beter in zijn en het meeste al bestaat. Uiteindelijk vind ik het allemaal wel interessant om zoiets te maken, daar niet van.

.oisyn schreef op zondag 19 april 2020 @ 01:43:
een Delaunay tetrahedralizer

Voor breakable meshes?

[.oisyn]

Feanathiel schreef op zondag 19 april 2020 @ 13:20:
Voor breakable meshes?

Nee light probe interpolation.

---

Hah mijn moeder had nog een versie van Kol Q l80r 1 op haar laptop staan (die was altijd een groot fan van het programma)

[ Voor 49% gewijzigd door .oisyn op 19-04-2020 20:25 ]

[gekkie]

.oisyn schreef op zondag 19 april 2020 @ 20:12:
[...]

Nee light probe interpolation.

---

Hah mijn moeder had nog een versie van Kol Q l80r 1 op haar laptop staan (die was altijd een groot fan van het programma)

[Afbeelding]

Ze heeft je ooit octaal met de paplepel in gegoten ?

[Hydra]

Feanathiel schreef op zondag 19 april 2020 @ 13:20:
Dat is het 'm ook. Meestal begin ik aan zoiets, maar kom er dan al snel achter dat anderen daar veel beter in zijn en het meeste al bestaat. Uiteindelijk vind ik het allemaal wel interessant om zoiets te maken, daar niet van.

Mocht je het nog nooit gedaan hebben kan ik je zeker aanraden om met iets als een parser generator een grammar te maken en dan deze dan naar code te generen om bijvoorbeeld een calculator te maken. Is echt leuk om te doen, niet heel veel werk, en geeft heel veel inzicht in hoe een compiler werkt.

[Sebazzz]

Deze serie heb ik gevolgd: https://ruslanspivak.com/lsbasi-part1/

Dat gaf mij eindelijk een excuus om weer te prutsen met C++: https://github.com/sebazzz/lsbasi

[alienfruit]

Tweede keer nu al deze bullshit; ik wordt er een beetje moe van. Ze hebben bij dit bedrijf (ander dan de vorige) over 6-12 maanden.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Mugwump]

alienfruit schreef op maandag 20 april 2020 @ 17:47:
Tweede keer nu al deze bullshit; ik wordt er een beetje moe van. Ze hebben bij dit bedrijf (ander dan de vorige) over 6-12 maanden.


***members only***

Kan ik me goed voorstellen. Lijkt me ook enorm frustrerend om nu te moeten solliciteren. Er is zoveel onzekerheid in de markt dat zelfs solide bedrijven in de IT erg voorzichtig zijn.

Wat ik dan wel weer humor vond is dat ik iemand in een IT-traineeship sprak die ze aan het werk wilden zetten als komkommerplukker.

[gekkie]

Mugwump schreef op maandag 20 april 2020 @ 18:08:
[...]
Kan ik me goed voorstellen. Lijkt me ook enorm frustrerend om nu te moeten solliciteren. Er is zoveel onzekerheid in de markt dat zelfs solide bedrijven in de IT erg voorzichtig zijn.

Wat ik dan wel weer humor vond is dat ik iemand in een IT-traineeship sprak die ze aan het werk wilden zetten als komkommerplukker.

Hmm hadden ze beter een covid-19 app kunnen laten bakken, wie weet wordt het nog eens wat en anders leren ze er hopelijk wat van

Maar soliciteren en acquisitie is momenteel vrij lastig bij gebrek aan perspectief. Iedereen wacht af en houdt zo veel mogelijk liquiditeit vrij.

[ Voor 11% gewijzigd door gekkie op 20-04-2020 18:13 ]

[Vincentio]

alienfruit schreef op maandag 20 april 2020 @ 17:47:
Tweede keer nu al deze bullshit; ik wordt er een beetje moe van. Ze hebben bij dit bedrijf (ander dan de vorige) over 6-12 maanden.


***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Sebazzz]

alienfruit schreef op maandag 20 april 2020 @ 17:47:
Tweede keer nu al deze bullshit; ik wordt er een beetje moe van. Ze hebben bij dit bedrijf (ander dan de vorige) over 6-12 maanden.


***members only***

Wij zijn ook op zoek naar een IT-er maar ook door hogerop teruggefloten - bedrijfsbreed (grote accountantkantoor) is er een stop.

[Grijze Vos]

Wij hebben onze vacatures niet stopgezet. Maar hebben wel besloten de kandidaten voorlopig kritischer te beoordelen. Moet wel zeggen dat wij niet zo ontzettend marktgevoelig zijn. (Totdat de klanten van onze klanten failliet gaan, dan zullen we er wel iets van gaan voelen misschien.)

[alienfruit]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Nou ja, zo'n grote fan was ik nou ook weer niet van dat framework

Wij hebben onze vacatures niet stopgezet. Maar hebben wel besloten de kandidaten voorlopig kritischer te beoordelen.

Ja, dat snap ik, maar je moet mij niet een baan geven, contract en al, en dan het 1,5 week terug draaien. Dat vind ik gewoon een naaistreek.

[Grijze Vos]

Ja, dat ben ik met je eens, dat is behoorlijk fucked.

Ik heb in het verleden ook wel eens een medior afgeraden voor de functie omdat ik een lichte twijfel had, en ik het niet vond kunnen dat iemand zijn vaste baan opzegt terwijl ik in het halfjaar daarna misschien negatief moet gaan adviseren voor verlenging. Dat is wel een van de voordelen van juniors, die hebben toch nog geen baan om op te zeggen.

[alienfruit]

Ja, snap ik , @Grijze Vos maar ik neem toch niet aan dat je deze medior al een contract had aangeboden en de medior deze ondertekend had?

[Mugwump]

alienfruit schreef op dinsdag 21 april 2020 @ 22:54:
Ja, snap ik , @Grijze Vos maar ik neem toch niet aan dat je deze medior al een contract had aangeboden en de medior deze ondertekend had?

Bij ons is het helaas wel gebeurd dat contracten in de proeftijd en van mensen die nog moesten starten zijn beëindigd. Maar dat waren wel allemaal contracten die voor alle coronamaatregelen waren ondertekend. Als je nu net anderhalve week geleden een contract hebt ondertekend dan slaat het niet echt ergens op nee.

[Grijze Vos]

alienfruit schreef op dinsdag 21 april 2020 @ 22:54:
Ja, snap ik , @Grijze Vos maar ik neem toch niet aan dat je deze medior al een contract had aangeboden en de medior deze ondertekend had?

Nee absoluut niet. Dat is precies wat ik wil voorkomen.

[Hydra]

alienfruit schreef op dinsdag 21 april 2020 @ 13:14:
Ja, dat snap ik, maar je moet mij niet een baan geven, contract en al, en dan het 1,5 week terug draaien. Dat vind ik gewoon een naaistreek.

Sommige bedrijven laten nu hun ware kleuren zien. Backbase die geld zat heeft maar externen dwingt een tariefverlaging van 40% te accepteren. Booking.com die geld zat hebben, maar toch aan het overheidsinfuus willen. De action die geld zat heeft, maar leveranciers veel later betaalt. Dat bedrijf waar jij het over hebt valt hier min of meer ook onder.

Enige wat we kunnen doen is zorgen dat een hoop mensen dit weten zodat het ook daadwerkelijk tot reputatieschade leidt. Over deze strategie van o.a. backbase heb ik een LinkIn post geschreven die zo'n 6000 keer gezien is. Niet omdat het mij persoonlijk raakt (mijn klant gedraagt zich heel netjes), maar omdat ik vind dat dit soort acties die bedrijven moeten schaden op de lange termijn.

[wackmaniac]

Ik denk dat nog wel mee kan vallen over hoeveel reserves bedrijven in kas hebben. Booking.com heeft momenteel waarschijnlijk 0 inkomsten en aangezien ze wel uitgaves hebben teer je snel in op je reserves. Ik praat overigens niets goed, want ik meen te hebben gelezen dat ze zeer recentelijk nog redelijk wat eigen vermogen afgeroomd hebben naar aandeelhouders.

[Feanathiel]

Hydra schreef op maandag 20 april 2020 @ 10:44:
[...]


Mocht je het nog nooit gedaan hebben kan ik je zeker aanraden om met iets als een parser generator een grammar te maken en dan deze dan naar code te generen om bijvoorbeeld een calculator te maken. Is echt leuk om te doen, niet heel veel werk, en geeft heel veel inzicht in hoe een compiler werkt.

Zeker. Destijds ook mee bezig gehouden om zoiets te implementeren. Daarbij veel inspiratie opgedaan van een tool met de naam Calca (niet van mij; een oude versie staat nog steeds online zie ik, maar wellicht niet meer representatief wat de tool nu doet). Eigenlijk is het zoals eerder ook verteld, dan begin je aan zoiets, gebruik je het zelf niet zo veel en dan zakt de interesse ook om de tool verder uit te breiden. Je moet echt een doel hebben zodat je het zelf gaat gebruiken, of anderen dat wellicht gaan doen. Dat was bij mij niet het geval

[alienfruit]

Sommige bedrijven laten nu hun ware kleuren zien. Backbase die geld zat heeft maar externen dwingt een tariefverlaging van 40% te accepteren. Booking.com die geld zat hebben, maar toch aan het overheidsinfuus willen. De action die geld zat heeft, maar leveranciers veel later betaalt. Dat bedrijf waar jij het over hebt valt hier min of meer ook onder.

Ja, ik hoorde van een ex-collega die bij Revolut (internetbank hier in VK) werkt dat er ook werd gevraagd voor een salarisverlaging voor een jaar. Maar als je dit deed dan krijg je wel opties in de bank ervoor terug met een dubbel waarde van wat de verlaging is. Ik denk dat dit nog wel redelijk netjes als het op vrijwillige basis is.

Maar ja, mijn eigen spaarpotje begint inmiddels wel wat leeg te worden. Ik ga binnenkort ook naar wat kleiners verhuizen. Ik zit er over na te denken om misschien ook zoiets aan te bieden tijdelijke verlaging tot het Coronavirus gebeuren weer voor bij is.

[Grijze Vos]

wackmaniac schreef op woensdag 22 april 2020 @ 11:21:
Ik denk dat nog wel mee kan vallen over hoeveel reserves bedrijven in kas hebben. Booking.com heeft momenteel waarschijnlijk 0 inkomsten en aangezien ze wel uitgaves hebben teer je snel in op je reserves. Ik praat overigens niets goed, want ik meen te hebben gelezen dat ze zeer recentelijk nog redelijk wat eigen vermogen afgeroomd hebben naar aandeelhouders.

Met een brutowinsmarge van 39.1% over 2019 mogen ze van mij echt opzouten als ze nu niet genoeg reserve hebben om rond te komen. Dat is echt een heel stevige winstmarge. Als ze dat allemaal hebben uitbetaald mogen de aandeelhouders nu ook bloeden.

[Hydra]

alienfruit schreef op woensdag 22 april 2020 @ 13:33:
Ja, ik hoorde van een ex-collega die bij Revolut (internetbank hier in VK) werkt dat er ook werd gevraagd voor een salarisverlaging voor een jaar. Maar als je dit deed dan krijg je wel opties in de bank ervoor terug met een dubbel waarde van wat de verlaging is. Ik denk dat dit nog wel redelijk netjes als het op vrijwillige basis is.

Ja, daar heb ik geen problemen mee hoor. Het ging me vooral om bedrijven die echt misbruik maken.

wackmaniac schreef op woensdag 22 april 2020 @ 11:21:
Ik denk dat nog wel mee kan vallen over hoeveel reserves bedrijven in kas hebben. Booking.com heeft momenteel waarschijnlijk 0 inkomsten en aangezien ze wel uitgaves hebben teer je snel in op je reserves. Ik praat overigens niets goed, want ik meen te hebben gelezen dat ze zeer recentelijk nog redelijk wat eigen vermogen afgeroomd hebben naar aandeelhouders.

Als ze winst uit kunnen keren zouden ze een buffer moeten hebben. Hebben ze dat niet, dan verdienen ze het m.i. gewoon om falliet te gaan. Heb als ZZPer ook gewoon een buffer, zit nu op een half jaar.

[ Voor 38% gewijzigd door Hydra op 22-04-2020 14:08 ]

[alienfruit]

Shell zit in de internet business blijkbaar: https://www.shellenergy.co.uk/broadband/products

[Kalentum]

alienfruit schreef op donderdag 23 april 2020 @ 13:02:
Shell ziet in de internet business blijkbaar: https://www.shellenergy.co.uk/broadband/products

Ik zit bij Oxxio en die leveren ook internetabonnementen. Dan krijg je maar liefst 2,50 korting als je energieklant bent.

[kenneth]

@alienfruit, wat dacht je van werken met de mooiste taal van de wereld? https://twitter.com/isaac.../1253255037666689029?s=19

[PrisonerOfPain]

kenneth schreef op donderdag 23 april 2020 @ 13:27:
@alienfruit, wat dacht je van werken met de mooiste taal van de wereld? https://twitter.com/isaac.../1253255037666689029?s=19

Rust?

[gekkie]

Wel oppassen met de cola.

[Sandor_Clegane]

PrisonerOfPain schreef op donderdag 23 april 2020 @ 16:21:
[...]


Rust?

Bijna goed.

[R4gnax]

wackmaniac schreef op woensdag 22 april 2020 @ 11:21:
Ik denk dat nog wel mee kan vallen over hoeveel reserves bedrijven in kas hebben. Booking.com heeft momenteel waarschijnlijk 0 inkomsten en aangezien ze wel uitgaves hebben teer je snel in op je reserves. Ik praat overigens niets goed, want ik meen te hebben gelezen dat ze zeer recentelijk nog redelijk wat eigen vermogen afgeroomd hebben naar aandeelhouders.

Booking.com heeft wss. weinig te lijden anders dan operationele kosten. Praktisch alle annuleringen proberen ze de consument door te sturen richting het hotel om het daar zelf te regelen en zo de kosten bij de hotelier te dumpen.

Hele smerige toko die in deze tijd z'n ware kleuren goed laat zien.


Zeker als je even meeneemt dat:

Grijze Vos schreef op woensdag 22 april 2020 @ 13:39:
[...]


Met een brutowinsmarge van 39.1% over 2019 mogen ze van mij echt opzouten als ze nu niet genoeg reserve hebben om rond te komen. Dat is echt een heel stevige winstmarge. Als ze dat allemaal hebben uitbetaald mogen de aandeelhouders nu ook bloeden.

--- dan mogen ze van mij echt lekker stikken.


Destemeer aangezien ze kennelijk al tussen de regeltjes door gedreigt hebben mensen in NL de zak te gaan geven als de staatssteun geweigerd zou worden.


Echt: ik kots op dat bedrijf. Volgens traditioneel Amerikaans model alles en iedereen uitknijpen en de zaak bij elkaar bluffen en strong-arm-en ter meerdere ere en glorie van de winst-maximalisatie.

[ Voor 34% gewijzigd door R4gnax op 23-04-2020 19:37 ]

[Sandor_Clegane]

R4gnax schreef op donderdag 23 april 2020 @ 19:31:
[...]


Booking.com heeft wss. weinig te lijden anders dan operationele kosten. Praktisch alle annuleringen proberen ze de consument door te sturen richting het hotel om het daar zelf te regelen en zo de kosten bij de hotelier te dumpen.

Hele smerige toko die in deze tijd z'n ware kleuren goed laat zien.


Zeker als je even meeneemt dat:


[...]


--- dan mogen ze van mij echt lekker stikken.


Destemeer aangezien ze kennelijk al tussen de regeltjes door gedreigt hebben mensen in NL de zak te gaan geven als de staatssteun geweigerd zou worden.


Echt: ik kots op dat bedrijf. Volgens traditioneel Amerikaans model alles en iedereen uitknijpen en de zaak bij elkaar bluffen en strong-arm-en ter meerdere ere en glorie van de winst-maximalisatie.

Wat zeur je nou man, het is een Nederlands succesverhaal!

[ Voor 6% gewijzigd door Sandor_Clegane op 24-04-2020 11:43 ]

[Mugwump]

Sandor_Clegane schreef op vrijdag 24 april 2020 @ 11:43:
[...]


Wat zeur je nou man, het is een Nederlands succesverhaal!

Alleen al wel weer een jaar of 15 volkomen Angelsaksisch, maar dat mag de pret niet drukken.

[Sandor_Clegane]

Let's Encrypt is echt geweldig. Wildcard voor de nop, yay!

[Boudewijn]

Sandor_Clegane schreef op vrijdag 24 april 2020 @ 11:43:
[...]


Wat zeur je nou man, het is een Nederlands succesverhaal!

Het is niet (meer) nederlands, en als het dat wel was... wat dan nog?
Slim dat ze in het gat zijn gesprongen destijds, maar ik laat er echt geen traan om als ze morgen niet meer bestaan.

[Koenvh]

Sandor_Clegane schreef op vrijdag 24 april 2020 @ 14:31:
Let's Encrypt is echt geweldig. Wildcard voor de nop, yay!

Klopt, al is de DNS aanpassen soms nog wel een geklooi als dat niet automatisch kan. Ik hoop dat BuyPass Go dat ook nog gaat ondersteunen (en sowieso groter wordt), want ik heb toch liever een goede Europese oplossing

[Janoz]

Sandor_Clegane schreef op vrijdag 24 april 2020 @ 14:31:
Let's Encrypt is echt geweldig. Wildcard voor de nop, yay!

Dat is trouwens al een tijdje zo. Ik kan me herinneren dat ik vorige maand problemen had met de verlenging dus het moet toch zeker al 4 maand beschikbaar zijn.

Gelukkig werkt de automatische vernieuwing nu wel weer. TransIP had iets in hun API waardoor het door mij gebruikte docker image een foutmelding gaf. Gelukkig een fix kunnen pushen en nu werkt alles weer. Open source is soms best fijn

[WernerL]

Was deze eigenlijk al langs gekomen?

[Matis]

Koenvh schreef op vrijdag 24 april 2020 @ 15:45:
Klopt, al is de DNS aanpassen soms nog wel een geklooi als dat niet automatisch kan. Ik hoop dat BuyPass Go dat ook nog gaat ondersteunen (en sowieso groter wordt), want ik heb toch liever een goede Europese oplossing

Ik gebruik traefik voor het automatisch genereren van wildcard DNS certificaten en doet meteen de reverse proxy naar al m'n websites.

Fijne tool!

[Sandor_Clegane]

Boudewijn schreef op vrijdag 24 april 2020 @ 14:58:
[...]

Het is niet (meer) nederlands, en als het dat wel was... wat dan nog?
Slim dat ze in het gat zijn gesprongen destijds, maar ik laat er echt geen traan om als ze morgen niet meer bestaan.

Ik dacht dat de knipoog voldoende was, maar ik zal er volgende keer even sarcasm tags omheen zetten.

Hoe minder rentseekers hoe beter.

Koenvh schreef op vrijdag 24 april 2020 @ 15:45:
[...]

Klopt, al is de DNS aanpassen soms nog wel een geklooi als dat niet automatisch kan. Ik hoop dat BuyPass Go dat ook nog gaat ondersteunen (en sowieso groter wordt), want ik heb toch liever een goede Europese oplossing

Yep, dit is nog wel een dingetje, heb mijn domein ergens draaien waar dat niet automatisch kan en dus moet ik met de hand af en toe een acme challenge invoeren. Voor de rest is hun staat van dienst prima, dus ja, dat doe ik dan maar even.

[ Voor 41% gewijzigd door Sandor_Clegane op 24-04-2020 20:35 ]

[armageddon_2k1]

De nieuwe NPM fuckup is hier nog niet langsgekomen?

https://github.com/then/i...?q=is%3Aissue+is%3Aclosed

Een oneliner die alle major frameworks breekt. Angular, React, Firebase tools, etc.

De mensen buitelen weer over elkaar heen op Reddit en Hackernews, maar wat me altijd verbaasd is dat mensen gillen dat hun productie build kapot is en dan vraag ik me altijd af.... hoe dan? Je hebt toch een package.lock? Je gaat toch niet een npm install doen zonder .lock in je productie omgeving?

[P-Storm]

Matis schreef op vrijdag 24 april 2020 @ 18:21:
[...]

Ik gebruik traefik voor het automatisch genereren van wildcard DNS certificaten en doet meteen de reverse proxy naar al m'n websites.

Fijne tool!

Heb je hiervan een tutorial? Ik wil dit nog steeds een keer opzetten voor mijn Synology Docker solution, maar nog niet heel erg naar gezocht.

[gekkie]

armageddon_2k1 schreef op zaterdag 25 april 2020 @ 22:27:
De nieuwe NPM fuckup is hier nog niet langsgekomen?

Mjah sorry .. ik gebruik het niet en was het ook niet van plan.
Het dichtste bij wat ik ben geweest was een geojson converterfukker draaien en dat werkte, gelijk daarna weer een apt-get purge nodejs.

https://github.com/then/i...?q=is%3Aissue+is%3Aclosed
Een oneliner die alle major frameworks breekt. Angular, React, Firebase tools, etc.

Mjah misschien de "Trump" onder de talen dan, veel one-liners met bitter weinig substansie, wat regelmatig tot lijden wil leiden.

De mensen buitelen weer over elkaar heen op Reddit en Hackernews, maar wat me altijd verbaasd is dat mensen gillen dat hun productie build kapot is en dan vraag ik me altijd af.... hoe dan? Je hebt toch een package.lock? Je gaat toch niet een npm install doen zonder .lock in je productie omgeving?

Mjah ik verwonder me er toch over, hebben ze bij javascript een soort pep-8, waarin staat dat het max aantal zinvolle regels in een file 1 moet zijn ofzo ?

Ok source files van > 5000 regels zijn ook niet echt altijd prettig, maar een iets grover opgezette standard library dan 1 regel per library zou toch wel een aardige optimalisatie zijn.

[R4gnax]

armageddon_2k1 schreef op zaterdag 25 april 2020 @ 22:27:
dan vraag ik me altijd af.... hoe dan? Je hebt toch een package.lock? Je gaat toch niet een npm install doen zonder .lock in je productie omgeving?

Dus wel. Mensen draaien gewoon een npm install ipv een npm ci. En ze checken het lock file niet in, "want dat geeft de hele tijd merge-conflicten." De onwetendheid is echt veel en veel te groot.

[ Voor 6% gewijzigd door R4gnax op 25-04-2020 23:15 ]

[Matis]

P-Storm schreef op zaterdag 25 april 2020 @ 22:43:
Heb je hiervan een tutorial? Ik wil dit nog steeds een keer opzetten voor mijn Synology Docker solution, maar nog niet heel erg naar gezocht.

Ja, dat heb ik: Matis in "[Traefik - Proxy/Loadbalancer] Ervaringen & Discussie"
En als aanvulling daarop: lolgast in "[Traefik - Proxy/Loadbalancer] Ervaringen & Discussie"

Edit; kleine toevoeging, ik heb mijn DNS records bij TransIP staan.
Dat resulteert in een acme.json bestand waarin de private keys voor het certificaat staan.

[ Voor 5% gewijzigd door Matis op 26-04-2020 05:59 ]

[P-Storm]

Top, mijn domein heb ik ook bij TransIP staan. Vandaag eens mee gaan stoeien, dank!

Als C# developer die momenteel in C programmeert: wat is het wennen met casten, (dangling) pointers en de documentatie... Al is de afwisseling wel weer leuk, daar niet van. Ik mis iemand in de buurt die mij de 'niet 2 seconden googlebare vragen' kan beantwoorden.

Aan de andere kant, ik heb een andere developer wel geleerd over git en over meerdere .c files te gebruiken. Iets van scheiding is toch wel practisch

[Matis]

P-Storm schreef op zondag 26 april 2020 @ 07:26:
Top, mijn domein heb ik ook bij TransIP staan. Vandaag eens mee gaan stoeien, dank!

Ja, het was even uitzoeken hoe je het moest configureren. Als het eenmaal draait, is het een peulenschil.

Als C# developer die momenteel in C programmeert: wat is het wennen met casten, (dangling) pointers en de documentatie... Al is de afwisseling wel weer leuk, daar niet van. Ik mis iemand in de buurt die mij de 'niet 2 seconden googlebare vragen' kan beantwoorden.

Aan de andere kant, ik heb een andere developer wel geleerd over git en over meerdere .c files te gebruiken. Iets van scheiding is toch wel practisch

Bij mijn vorige werkgever heb ik heel veel in C geprogrammeerd. Op embedded Linux om precies te zijn, met uClibc op een real-time kernel. Dat was, over het algemeen, erg leuk om te doen. Debuggen daarentegen was wel weer een crime om te doen. Vanwege het weinige geheugen en opslag dat die platformen hadden, was het haast niet mogelijk om alle applicaties en libs met debug extensies op het target te krijgen. Dat moest middels tftp ingeladen worden.

[Voutloos]

R4gnax schreef op zaterdag 25 april 2020 @ 23:14:
[...]


Dus wel. Mensen draaien gewoon een npm install ipv een npm ci. En ze checken het lock file niet in, "want dat geeft de hele tijd merge-conflicten." De onwetendheid is echt veel en veel te groot.

Check. Je zou bijna willen dat install in production mode enkel werkt als je een lock file hebt met daarin een iets oudere timestamp. Of iets dergelijks om de flow af te dwingen.

Maar waarschijnlijk komt er dan heel snel nóg een package bij met maar 1 regeltje, namelijk om die check onklaar te maken.

[Piitaa]

Fatsoenlijk dependency management is een vervelende klus, dus gelukkig maakt npm het je erg makkelijk om je kop in het zand te steken.

/s

[Sandor_Clegane]

Paket is echt zo'n verademing...

OAuth2 is ook wel een ding zeg. Dacht: "Ah dat doen we even...." Famous last words.

Een Nginx container, Dex container, OAuth2 proxy container, Samba container plus LDAPS connector en 20 config files later werkt het......

Plus wat SSL certificaten en een test webserver.......

[Hydra]

R4gnax schreef op zaterdag 25 april 2020 @ 23:14:
Dus wel. Mensen draaien gewoon een npm install ipv een npm ci. En ze checken het lock file niet in, "want dat geeft de hele tijd merge-conflicten." De onwetendheid is echt veel en veel te groot.

Dat npm install de lock file soort van negeert help ook niet echt. npm ci is nogal een rare naam.

M.i. is het hele NPM ecosysteem gewoon rot. Vooral omdat er een paar vrij debiele 'thought leaders' zijn waar hordes developers achteraan lopen, en het overgrote deel van de devs daar gewoon geen idee heeft wat software engineering inhoudt.

[Ed Vertijsment]

Er zijn zeker issues met npm, maar als zijnde een package manager vind ik het persoonlijk beter dan vele andere. Werk ook vaak met (Python) pip, maar das ook vrij ral.

[gekkie]

Ed Vertijsment schreef op zondag 26 april 2020 @ 14:28:
Er zijn zeker issues met npm, maar als zijnde een package manager vind ik het persoonlijk beter dan vele andere. Werk ook vaak met (Python) pip, maar das ook vrij ral.

ral 9001 of 9010 ?
En wat is er mis met pip, behalve dat misschien eerst een proposal van "dit wil ik gaan doen, vindt je het dan nog steeds leuk ?" wel aardig zou zijn (zoals apt/aptitude bij debian).

Maar goed het is een lastig probleem met genoeg trade-offs zodat er altijd wel iets te mauwen is.
Maar ik denk dat NPM/javascript wel een heel erg extreem iets is met zeer weinig bundeling en van basale dingen meer varianten dan noodzakelijk. Denk dat de communities bij pip/pypi, perl/cpan php/pear dat toch wel iets minder idioot doen, op een gegeven moment komt er toch wel een bundeling en iets min of meer standaards uit rollen.
Bij rust heb ik de indruk dat het ook aardig gefragmenteerd nog is en tevens aardig wat cryptische benamingen (nodig weer eens mee verder om er weer eens wat meer mee te doen).

[R4gnax]

Hydra schreef op zondag 26 april 2020 @ 13:49:
[...]


Dat npm install de lock file soort van negeert help ook niet echt. npm ci is nogal een rare naam.

M.i. is het hele NPM ecosysteem gewoon rot. Vooral omdat er een paar vrij debiele 'thought leaders' zijn waar hordes developers achteraan lopen, en het overgrote deel van de devs daar gewoon geen idee heeft wat software engineering inhoudt.

Helaas een constatering waaar ik het grotendeels mee eens moet zijn. Het strekt verder dan enkel het ecoysysteem, want ook NPM zelf heeft de nodige op haar kerfstok.

[gekkie]

Overigens van de wikipedia:

History

npm is written entirely in JavaScript and was developed by Isaac Z. Schlueter as a result of having "seen module packaging done terribly" and with inspiration from other similar projects such as PEAR (PHP) and CPAN (Perl).[5]

Je zou het wel op in iedergeval twee heel verschillende manieren kunnen lezen

[R4gnax]

gekkie schreef op zondag 26 april 2020 @ 20:10:
Overigens van de wikipedia:

[...]

Je zou het wel op in iedergeval twee heel verschillende manieren kunnen lezen

Het heeft inderdaad wel een heel erg hoog "hold my beer" gehalte, ja.

[Vincentio]

armageddon_2k1 schreef op zaterdag 25 april 2020 @ 22:27:
De nieuwe NPM fuckup is hier nog niet langsgekomen?

https://github.com/then/i...?q=is%3Aissue+is%3Aclosed

Een oneliner die alle major frameworks breekt. Angular, React, Firebase tools, etc.

De mensen buitelen weer over elkaar heen op Reddit en Hackernews, maar wat me altijd verbaasd is dat mensen gillen dat hun productie build kapot is en dan vraag ik me altijd af.... hoe dan? Je hebt toch een package.lock? Je gaat toch niet een npm install doen zonder .lock in je productie omgeving?

Mwah, je kan ook gewoon je dependencies vastpinnen.En een dependency bot laten draaien voor updates. Zorgen dat je volledige unit test dekking hebt en op elk pull request je unit tests laten draaien.
En dan alleen door mogen als die slagen.

Slagen die, accept je de pull request en trap je je pipeline verder af.

Vertrouw niet met semver gewoon dat minor updates niet iets kunnen laten stuk gaan.

...

Even verder gekeken, sowieso, waarom, een package die al 5 jaar geen onderhoud heeft gehad en 1 freaking line of code is. WAAROM gebruik je dat? Dat is ook gewoon een groot probleem. Men gebruikt veeeeeel te makkelijk een package.

[ Voor 10% gewijzigd door Vincentio op 27-04-2020 22:30 ]

[Janoz]

P-Storm schreef op zondag 26 april 2020 @ 07:26:
Top, mijn domein heb ik ook bij TransIP staan. Vandaag eens mee gaan stoeien, dank!

Ik heb mijn domein ook bij TransIP staan, maar ik gebruik https://github.com/Grexxboxx/docker-certbot-transip/

Deze laat ik dan de certificaten wegschrijven in een map die ik vervolgens deel met andere docker images die het certificaat nodig hebben (traefik, maar ook de nginx die ik voor extern verkeer gebruik).

[Matis]

Janoz schreef op dinsdag 28 april 2020 @ 01:48:
Ik heb mijn domein ook bij TransIP staan, maar ik gebruik https://github.com/Grexxboxx/docker-certbot-transip/

Deze laat ik dan de certificaten wegschrijven in een map die ik vervolgens deel met andere docker images die het certificaat nodig hebben (traefik, maar ook de nginx die ik voor extern verkeer gebruik).

Werkt dat ook met wildcard DNS certificaten en DNS challenges?

[dev10]

gekkie schreef op zondag 26 april 2020 @ 20:10:
Overigens van de wikipedia:

[...]

Je zou het wel op in iedergeval twee heel verschillende manieren kunnen lezen

Ik heb op de PHP-subreddit wel eens iemand zien zeggen dat hij PEAR en PECL gebruikt voor z'n dependencies en dat Composer een last-resort zou moeten zijn. De persoon in kwestie gaf de volgende redenen:

- Composer heeft geen package signing
- Composer packages zijn vaak van slechte kwaliteit
- Je kan geen private repositories gebruiken
- Libraries worden niet gereviewd
- JSON is lastig
- Composer packages hebben verschillende API stijlen

[bauke1994]

Via packagist worden maar meer dan 3 keer zoveel installs per maand gedaan als er via pear in totaal zijn gedaan. Maar nee composer doet inderdaad geen package signing daar heeft hij wel een punt

[Mugwump]

dev10 schreef op dinsdag 28 april 2020 @ 10:16:
- JSON is lastig

Als je een dergelijk argument gebruikt dan moet je je toch ernstig gaan afvragen of je wel het juiste vak hebt gekozen.

[Hydra]

Mugwump schreef op dinsdag 28 april 2020 @ 10:49:
Als je een dergelijk argument gebruikt dan moet je je toch ernstig gaan afvragen of je wel het juiste vak hebt gekozen.

Heeft 'ie het niet specifiek over JSON config files? Want dan ben ik het wel met 'em eens; dan nog liever XML, of beter: YAML.

[gekkie]

Nee wat mensen weten te doen met xml is een zegen .. vanochtend net met een xml-file met html-entities.
Met python werden die bij zowel ElementTree als lxml de handel geskipt, maar goed eerst de hele file als string door een html.unescape() heen rossen lijkt wel te werken.

dev10 schreef op dinsdag 28 april 2020 @ 10:16:
[...]
Ik heb op de PHP-subreddit wel eens iemand zien zeggen dat hij PEAR en PECL gebruikt voor z'n dependencies en dat Composer een last-resort zou moeten zijn. De persoon in kwestie gaf de volgende redenen ...

Zal die NPM'er daar wel z'n inspiratie op hebben gedaan, nouja op het "JSON is lastig" aspect na dan .

[ Voor 43% gewijzigd door gekkie op 28-04-2020 11:05 ]

[Janoz]

Matis schreef op dinsdag 28 april 2020 @ 08:06:
[...]

Werkt dat ook met wildcard DNS certificaten en DNS challenges?

Dat image gebruik ik juist omdat ik een wildcard certificaat gebruik. En dat werkt alleen met DNS challenges.

[Mugwump]

Hydra schreef op dinsdag 28 april 2020 @ 10:56:
[...]


Heeft 'ie het niet specifiek over JSON config files? Want dan ben ik het wel met 'em eens; dan nog liever XML, of beter: YAML.

Ongetwijfeld, maar hoe zijn die 'lastiger' dan XML of YAML?
Als er overigens iets is dat van mij liever vandaag dan morgen mag worden afgeschaft, dan is het wel iets als YAML of in bredere zin alles dat indentation als 'language construct' gebruikt.

[dev10]

Hydra schreef op dinsdag 28 april 2020 @ 10:56:
[...]


Heeft 'ie het niet specifiek over JSON config files? Want dan ben ik het wel met 'em eens; dan nog liever XML, of beter: YAML.

De letterlijke quote was: The JSON syntax is cumbersome to use. Hij zal het gehad hebben over composer.json en composer.lock. Er valt wel iets voor te zeggen, maar als ik heel eerlijk ben komt het nauwelijks voor dat je handmatig in dat bestand aanpassingen aan het doen bent.

En als dat je reden is om de de facto standaard dependency manager van PHP niet te gebruiken ben je te eigenwijs voor woorden.

[gekkie]

Mugwump schreef op dinsdag 28 april 2020 @ 11:12:
[...]
Als er overigens iets is dat van mij liever vandaag dan morgen mag worden afgeschaft, dan is het wel iets als YAML of in bredere zin alles dat indentation als 'language construct' gebruikt.

Hmmm ik mis op eens een grumpy wurgslang uit het terrarium, ik zou vanavond even onder het bed kijken voor je gaat slapen

[Hydra]

Mugwump schreef op dinsdag 28 april 2020 @ 11:12:
Ongetwijfeld, maar hoe zijn die 'lastiger' dan XML of YAML?

Met de hand JSON schrijven is gewoon een pain in the ass omdat alle keys ook quotes nodig hebben. Voor lezen maakt het an sich weinig uit, maar YAML en XML zijn met de hand wel makkelijker te schrijven in mijn ervaring.

Hoe dan ook; lijkt me niet dat een developer vindt dat JSON zelf 'moeilijk' is ofzo.

Wat betreft indentation: heb er zelf geen enkel probleem mee YAML te schrijven. Iedere fatsoenlijke IDE kan 't netjes formatten en dan zie je zo of je fouten maakt.

[ Voor 14% gewijzigd door Hydra op 28-04-2020 11:52 ]

[dcm360]

Even 'snel' YAML schrijven gaat me net zo goed af als even 'snel' iets schrijven in Python: ik heb altijd wel een indent fout. Voor configuratiebestanden zie ik het liefst HOCON, maar dat kom je nauwelijks tegen in het wild helaas.

[RayNbow]

Gewoon .ini gebruiken.

[Mugwump]

Hydra schreef op dinsdag 28 april 2020 @ 11:50:
[...]


Met de hand JSON schrijven is gewoon een pain in the ass omdat alle keys ook quotes nodig hebben. Voor lezen maakt het an sich weinig uit, maar YAML en XML zijn met de hand wel makkelijker te schrijven in mijn ervaring.

Hoe dan ook; lijkt me niet dat een developer vindt dat JSON zelf 'moeilijk' is ofzo.

Wat betreft indentation: heb er zelf geen enkel probleem mee YAML te schrijven. Iedere fatsoenlijke IDE kan 't netjes formatten en dan zie je zo of je fouten maakt.

Tsja, als je het dan toch over IDEs hebt, dan hoef je vaak dat soort files al niet eens zelf te schrijven aangezien die het grootste gedeelte al voor je afhandelen.

Mijn bezwaar tegen YAML is met name als ik het moet gebruiken voor iets als CloudFormation. Idealiter kopieer je natuurlijk nooit wat en is er altijd netjes sprake van hergebruik. In de praktijk ben je heel vaak stukken CF template aan het copy-pasten en aanpassen. Dat verneukt echt altijd je indentation.

En dan is dat nog minder erg dan Python omdat indentation daar de werking van je code radicaal kan veranderen. Haakjes of end statements oid maken de intentie van de ontwikkelaar expliciet.

[Hydra]

Mugwump schreef op dinsdag 28 april 2020 @ 12:02:
En dan is dat nog minder erg dan Python omdat indentation daar de werking van je code radicaal kan veranderen. Haakjes of end statements oid maken de intentie van de ontwikkelaar expliciet.

Ben het an sich wel met je eens dat het m'n voorkeur ook niet heeft, maar als ik Python schrijf (meestal voor deployments, toch wat leesbaarder dan Bash), loop ik er weinig tegen aan. IntelliJ heeft 't meestal wel door als ik iets fout doe.

[Mugwump]

Hydra schreef op dinsdag 28 april 2020 @ 12:04:
[...]


Ben het an sich wel met je eens dat het m'n voorkeur ook niet heeft, maar als ik Python schrijf (meestal voor deployments, toch wat leesbaarder dan Bash), loop ik er weinig tegen aan. IntelliJ heeft 't meestal wel door als ik iets fout doe.

Nee als je het zelf schrijft en zeker wanneer het voor deploymentzaken is dan valt het prima te doen.
Ik werk echter ook met veel mensen uit de BI en Data Science hoek die vooral geïnteresseerd zijn in de boel zo snel mogelijk aan elkaar breien en dan weer door naar het volgende projectje. Totdat het echt complex wordt en ze totaal verzuipen in die 23 geneste if statements.

[Hydra]

Mugwump schreef op dinsdag 28 april 2020 @ 12:25:
Nee als je het zelf schrijft en zeker wanneer het voor deploymentzaken is dan valt het prima te doen.
Ik werk echter ook met veel mensen uit de BI en Data Science hoek die vooral geïnteresseerd zijn in de boel zo snel mogelijk aan elkaar breien en dan weer door naar het volgende projectje. Totdat het echt complex wordt en ze totaal verzuipen in die 23 geneste if statements.

Heb PTSD van een project waarbij een berg data scientists dat soort spul zaten te ontwikkelen. Een enkele service met 16 instances op Kubernetes omdat het niet vooruit te branden was. Dus kwam het bij ons terecht van "doe 'es in Java?". Die code was echt zum kotsen

[Mugwump]

Hydra schreef op dinsdag 28 april 2020 @ 12:40:
[...]


Heb PTSD van een project waarbij een berg data scientists dat soort spul zaten te ontwikkelen. Een enkele service met 16 instances op Kubernetes omdat het niet vooruit te branden was. Dus kwam het bij ons terecht van "doe 'es in Java?". Die code was echt zum kotsen

Zo zat ik ooit eens naast een ETL'er die een data scientist aan het uitleggen was waarom z'n algoritme niet echt snel werkte.
Dat ging ongeveer zo:
"Hier zit het probleem. Je doet een inner join in een inner join in een inner join.."
-- 2 minuten later --
"... in een inner join in een inner join in een inner join ..."
-- weer 2 minuten later --
"... in een inner join in een inner join in een inner join. Dat gaat niet werken."

[Piitaa]

Mugwump schreef op dinsdag 28 april 2020 @ 11:12:
[...]


Ongetwijfeld, maar hoe zijn die 'lastiger' dan XML of YAML?
Als er overigens iets is dat van mij liever vandaag dan morgen mag worden afgeschaft, dan is het wel iets als YAML of in bredere zin alles dat indentation als 'language construct' gebruikt.

Geen fan van Wikipedia: Whitespace (programming language) dus, neem ik aan?

[Mugwump]

Piitaa schreef op dinsdag 28 april 2020 @ 14:53:
[...]


Geen fan van Wikipedia: Whitespace (programming language) dus, neem ik aan?

Daar zie ik de voordelen dan nog wel weer van in. Aangezien ze daar enkel spaces, tabs en linefeeds gebruiken kun je die visualiseren met drie kleurtjes in een IDE en kunnen zelfs de leden van de Jostiband leren programmeren.

[ElkeBxl]

RayNbow schreef op dinsdag 28 april 2020 @ 12:02:
Gewoon .ini gebruiken.

Lol, dat is geleden van toen ik met PHP aan het prutsen was dat ik nog eens .ini gebruikt heb. Wat een throwback...

[RayNbow]

ElkeBxl schreef op woensdag 29 april 2020 @ 08:11:
[...]

Lol, dat is geleden van toen ik met PHP aan het prutsen was dat ik nog eens .ini gebruikt heb. Wat een throwback...

Ik onderhoud software dat nog dingen wegschrijft en uitleest in .ini-formaat... 😅

[Tk55]

Mugwump schreef op dinsdag 28 april 2020 @ 12:25:
[...]


Nee als je het zelf schrijft en zeker wanneer het voor deploymentzaken is dan valt het prima te doen.
Ik werk echter ook met veel mensen uit de BI en Data Science hoek die vooral geïnteresseerd zijn in de boel zo snel mogelijk aan elkaar breien en dan weer door naar het volgende projectje. Totdat het echt complex wordt en ze totaal verzuipen in die 23 geneste if statements.

Hydra schreef op dinsdag 28 april 2020 @ 12:40:
[...]


Heb PTSD van een project waarbij een berg data scientists dat soort spul zaten te ontwikkelen. Een enkele service met 16 instances op Kubernetes omdat het niet vooruit te branden was. Dus kwam het bij ons terecht van "doe 'es in Java?". Die code was echt zum kotsen

Ik denk dat dit probleem voort komt uit het volgende: Data Scientists zijn meestal te verdelen in twee groepen, namelijk de "statistici" (studies statistiek, econometrie) en de "programmeurs" (studie Informatica).

• De "statistici". Ze werken op hun studie vaak met talen als R, waarbij het schrijven van functies geen gemeengoed is. Hun programmeerervaring komt vaak voort uit het oplossen van opdrachten binnen hun studie. Dat doe je eenmalig en vervolgens hoeft het nooit meer opnieuw te draaien.
• De "programmeurs". Ze werken op hun studie vaak met verschillende talen (Python, Java, C, etc). Uiteraard ervaart deze groep hetzelfde met studieopdrachten, maar... In de programmeur wereld wordt er vaak gesproken over snelheid, Clean Code, refactoring, Test Driven Development, etc. Er ligt veel meer nadruk op het schrijven van goede en productiewaardige code. De ervaring met verschillende talen en de vele bovengenoemde concepten helpt daarbij.

In het werk vertaalt dit zich naar:

• De statistici maken snelle analyses en "proof of concepts". Dit zit logischerwijs vaak niet erg netjes in elkaar. Slechte naamgeving, langzame code, slechte structuur.
• De programmeurs mogen vervolgens de "proof of concepts" in productie zetten. Echter is de code vaak zo slecht (of in een niet productiewaardige taal zoals R), dat het volledig herschreven mag worden.

Het resultaat is dat de programmeurs de statistici vervloeken (zoals hier ). Echter worden de statistici nauwelijks, of slechts zeer langzaam, beter in het schrijven van code. Dat komt omdat het schrijven van goede code vanuit hun perspectief geen meerwaarde oplevert. Het wordt toch herschreven (door de programmeurs).

Wat ik ook zie is dat de "proof of concepts" niet alleen worden gebruikt om een afgebakende test te draaien. Vaak worden ze in een soort semi productie proces gezet, waarbij stakeholders er afhankelijk worden. Vervolgens mogen anderen de oplossing alsnog nog herbouwen, terwijl het proof of concept verder wordt ontwikkeld. Zo bewandel je ineens twee paden, waarbij je herschreven oplossing de brakke oplossing pas mag vervangen bij feature parity. Vervolgens duurt het allemaal nog langer.

Tijd voor een andere baan

[CodeCaster]

Ik heb echt de meest fantastische client-lib-manager voor Visual Studio gevonden: https://github.com/jamiebuilds/LibManUal

[RagingPenguin]

Tk55 schreef op woensdag 29 april 2020 @ 11:03:
[...]


[...]

Ik denk dat dit probleem voort komt uit het volgende: Data Scientists zijn meestal te verdelen in twee groepen, namelijk de "statistici" (studies statistiek, econometrie) en de "programmeurs" (studie Informatica).

• De "statistici". Ze werken op hun studie vaak met talen als R, waarbij het schrijven van functies geen gemeengoed is. Hun programmeerervaring komt vaak voort uit het oplossen van opdrachten binnen hun studie. Dat doe je eenmalig en vervolgens hoeft het nooit meer opnieuw te draaien.
• De "programmeurs". Ze werken op hun studie vaak met verschillende talen (Python, Java, C, etc). Uiteraard ervaart deze groep hetzelfde met studieopdrachten, maar... In de programmeur wereld wordt er vaak gesproken over snelheid, Clean Code, refactoring, Test Driven Development, etc. Er ligt veel meer nadruk op het schrijven van goede en productiewaardige code. De ervaring met verschillende talen en de vele bovengenoemde concepten helpt daarbij.

In het werk vertaalt dit zich naar:

• De statistici maken snelle analyses en "proof of concepts". Dit zit logischerwijs vaak niet erg netjes in elkaar. Slechte naamgeving, langzame code, slechte structuur.
• De programmeurs mogen vervolgens de "proof of concepts" in productie zetten. Echter is de code vaak zo slecht (of in een niet productiewaardige taal zoals R), dat het volledig herschreven mag worden.

Het resultaat is dat de programmeurs de statistici vervloeken (zoals hier ). Echter worden de statistici nauwelijks, of slechts zeer langzaam, beter in het schrijven van code. Dat komt omdat het schrijven van goede code vanuit hun perspectief geen meerwaarde oplevert. Het wordt toch herschreven (door de programmeurs).

Wat ik ook zie is dat de "proof of concepts" niet alleen worden gebruikt om een afgebakende test te draaien. Vaak worden ze in een soort semi productie proces gezet, waarbij stakeholders er afhankelijk worden. Vervolgens mogen anderen de oplossing alsnog nog herbouwen, terwijl het proof of concept verder wordt ontwikkeld. Zo bewandel je ineens twee paden, waarbij je herschreven oplossing de brakke oplossing pas mag vervangen bij feature parity. Vervolgens duurt het allemaal nog langer.

Tijd voor een andere baan

Ik denk dat het probleem hem vooral zit in dat veel bedrijven nog niet doorhebben wat een data scientist eigenlijk doet en ze maar beschouwd als de 'zoveelste programmeer subdicipline'. Data scientists zouden 'productie code opleveren' niet als taak moeten hebben. Een data scientist levert inzichten en de formules om die inzichten opnieuw te maken op een geupdate data set.

Een ander probleem is dat er vaak een kloof is tussen data science en traditioneel development waarbij beide partijen zich als superieur zien. Om een feature in een applicatie te bouwen die werk van een data scientist intergreerd moet er worden samengewerkt i.p.v. het over de schutting gooien dat je nu vaak ziet. Dit is hetzelfde verschijnsel met management vs development of design vs development. Veel bedrijven zijn nog steeds eilandjes van diciplines waar samenwerking ver te zoeken is. Als ik iets geleerd heb over 'de echte wereld' is dat de cultuur van een bedrijf een van de grootste factors is in succes.

[Mugwump]

RagingPenguin schreef op woensdag 29 april 2020 @ 11:45:
[...]


Ik denk dat het probleem hem vooral zit in dat veel bedrijven nog niet doorhebben wat een data scientist eigenlijk doet en ze maar beschouwd als de 'zoveelste programmeer subdicipline'. Data scientists zouden 'productie code opleveren' niet als taak moeten hebben. Een data scientist levert inzichten en de formules om die inzichten opnieuw te maken op een geupdate data set.

Een ander probleem is dat er vaak een kloof is tussen data science en traditioneel development waarbij beide partijen zich als superieur zien. Om een feature in een applicatie te bouwen die werk van een data scientist intergreerd moet er worden samengewerkt i.p.v. het over de schutting gooien dat je nu vaak ziet. Dit is hetzelfde verschijnsel met management vs development of design vs development. Veel bedrijven zijn nog steeds eilandjes van diciplines waar samenwerking ver te zoeken is. Als ik iets geleerd heb over 'de echte wereld' is dat de cultuur van een bedrijf een van de grootste factors is in succes.

Ik begreep van mijn collega data scientists ook wel dat de term behoorlijk aan het devalueren was. Er kwamen vaak enorm veel sollicitaties op vacatures en dan niet bepaald enkel van mensen met een achtergrond in de econometrie, maar oneerbiedig gezegd ook van heel wat mensen zonder zware achtergrond die een online cursus klooien met Python hadden gedaan.
Als je concreet kijkt naar wat het dagelijks werk van een data scientist ook echt inhoudt, dan is het bezig zijn met complexe statistische analyse en modellering maar een heel marginaal onderdeel van de werkzaamheden. Er is heel veel overlap met traditioneel BI werk zoals ETL en datavisualisatie. In theorie heb je het verschil tussen 'data engineers' en 'data scientists', maar in de praktijk zie je dat toch minder vaak.

[Hydra]

Tk55 schreef op woensdag 29 april 2020 @ 11:03:
Ik denk dat dit probleem voort komt uit het volgende: Data Scientists zijn meestal te verdelen in twee groepen, namelijk de "statistici" (studies statistiek, econometrie) en de "programmeurs" (studie Informatica).

• De "statistici". Ze werken op hun studie vaak met talen als R, waarbij het schrijven van functies geen gemeengoed is. Hun programmeerervaring komt vaak voort uit het oplossen van opdrachten binnen hun studie. Dat doe je eenmalig en vervolgens hoeft het nooit meer opnieuw te draaien.
• De "programmeurs". Ze werken op hun studie vaak met verschillende talen (Python, Java, C, etc). Uiteraard ervaart deze groep hetzelfde met studieopdrachten, maar... In de programmeur wereld wordt er vaak gesproken over snelheid, Clean Code, refactoring, Test Driven Development, etc. Er ligt veel meer nadruk op het schrijven van goede en productiewaardige code. De ervaring met verschillende talen en de vele bovengenoemde concepten helpt daarbij.

Ik zie dat anders. Data scientists zijn eigenlijk altijd statistici. Model bouwers. De code die ze produceren is een ruw model; dit zou de input moeten zijn voor gespecialiseerde software engineers (data engineers) om daaruit production-ready software te halen, en deze dan naar productie te brengen.

Het probleem is vooral dat bedrijven echt geen hol snappen van data science en zo iets hebben van "ja maar het is toch software die het doet?" en data scientists rechtstreeks die zooi door laten zetten. Ik geloof niet zo dat er 2 groepen zijn; elke data scientists werkt m.i. zo. Tuurlijk zijn er sommigen bij die betere developers zijn, maar die zijn vaak weer minder goed in het statistische deel. En dan zijn er nog een boel bedrijven die data analysten data scientists zijn gaan noemen, omdat dat beter bekt. Die mensen kunnen vaak geen van beiden.

Wat ik ook nog eens lastig vind, is dat Data Science een relatief 'jong' veld is. Er is gewoon enorm weinig collectieve ervaring. Daarbij zijn veel data scientists zelf ook gewoon onervaren. En als onervaren persoon heb je vaak de neiging om je favoriete tool als gouden hamer te zien. Die zie je heel vaak bij toepassingen als machine learning. De business die gewoon resultaten wil, en niet 10% false positives kan accepteren, en data scientists die dan niet kunnen zeggen dat hun oplossing daarvoor niet gaat werken.

[gekkie]

Tk55 schreef op woensdag 29 april 2020 @ 11:03:
[...]
Het resultaat is dat de programmeurs de statistici vervloeken (zoals hier ). Echter worden de statistici nauwelijks, of slechts zeer langzaam, beter in het schrijven van code. Dat komt omdat het schrijven van goede code vanuit hun perspectief geen meerwaarde oplevert. Het wordt toch herschreven (door de programmeurs).

Wat ik ook zie is dat de "proof of concepts" niet alleen worden gebruikt om een afgebakende test te draaien. Vaak worden ze in een soort semi productie proces gezet, waarbij stakeholders er afhankelijk worden. Vervolgens mogen anderen de oplossing alsnog nog herbouwen, terwijl het proof of concept verder wordt ontwikkeld. Zo bewandel je ineens twee paden, waarbij je herschreven oplossing de brakke oplossing pas mag vervangen bij feature parity. Vervolgens duurt het allemaal nog langer.
Tijd voor een andere baan

Mjah, als je het ziet als exploratief en iteratief de specs neerzetten in pseudo code, dan klinkt het toch lang zo slecht nog niet ?
Of heb je liever 1000 pagina's niets zeggende management-speak als specs

Voornaamste probleem kan weer komen als managers vervolgens komen mauwen met:
"maar er lag toch al code, dus het was al voor 99.9% af, dus waarom duurt het toch zo lang en kost het als nog zoveel geld ?"