Galen

[Galen]

Wat is het verdict rond mariadistel als lever 'beschermer'?

Velen doen het af als nutteloos en zelf contraproductief (zou igf verlagen, geen idee hoe goed het daar in is, niet opgezocht om eerlijk te zijn).

Bij muizen blijkt het bij middelen zoals dbol en isotretinoïne wel effectief te zijn;

https://www.ncbi.nlm.nih.gov/m/pubmed/15510919/

https://pdfs.semanticscholar.org/91a5/a742cb00b9adfd18b36c364192fa9f3cbd96.pdf

In de context van AAS-geïnduceerde hepatotoxiciteit is er eigenlijk niet echt evidence voor. Ik beschouw het kort in mijn paper (https://www.ncbi.nlm.nih.gov/pubmed/27372877) waar ik ook die studie met ratten aankaart. Ik vermoed dat als het inderdaad heeft gewerkt in dat diermodel, dat dat komt door de antioxidatieve eigenschappen ervan. Maar goed, auteurs hebben er nooit verder onderzoek naar gedaan. Dat is op z'n zachtst gezegd opmerkelijk te noemen. Verder is het gepubliceerd in een redelijk nietszeggende journal en mijn ervaring is dat veel van dat soort onderzoek uit het Oostblok wel met een paar korreltjes zout genomen kan worden.

Misschien dat het een beetje ertegen helpt, het is moeilijk te zeggen op basis van de huidige stand van zaken. Uit klinisch onderzoek blijkt het verder wel veilig.

Voor de rest is er wel wat evidence voor andere zaken. Uit klinisch onderzoek blijkt dat het mogelijk leverfibrose tegengaat onder sommige omstandigheden.

 

[Galen]

Ik kijk net trouwens naar die tweede studie, dat slaat ook weer helemaal nergens op. 40 mg isotretinoïne per kg lichaamsgewicht per dag... Dat is 40 tot 80x de dosering die mensen voorgeschreven krijgen.

Er is ook geen enkele reden om hier dieronderzoek voor uit te voeren. Het is vrij triviaal om dat placebo-gecontroleerd te doen bij mensen: isotretinoïne wordt al decennia voorgeschreven en mariadistelextract komt ook zonder twijfel zo door de ethische commissie. Dit is gewoon puur nutteloos dieronderzoek (en is daarom ook in een nietszeggende journal gepubliceerd.)

As we mentioned in the perivous [sic] section, isotretinoin is widely used for treatment of acne vulgaris. Patients who are treated with isotretinoin are generally young men and women. Therefore, we selected young Balb/c mice for experimental design, and we preferred male mice as well. Because metabolism of the female mice is more variable than males.

Het wordt veelgebruikt door jonge mannen en vrouwen, dus hebben we wat muizen gepakt. En dan eigenlijk alleen mannelijke muizen. Gvd

 

[mucci]

Ik kijk net trouwens naar die tweede studie, dat slaat ook weer helemaal nergens op. 40 mg isotretinoïne per kg lichaamsgewicht per dag... Dat is 40 tot 80x de dosering die mensen voorgeschreven krijgen.

Er is ook geen enkele reden om hier dieronderzoek voor uit te voeren. Het is vrij triviaal om dat placebo-gecontroleerd te doen bij mensen: isotretinoïne wordt al decennia voorgeschreven en mariadistelextract komt ook zonder twijfel zo door de ethische commissie. Dit is gewoon puur nutteloos dieronderzoek (en is daarom ook in een nietszeggende journal gepubliceerd.)


Het wordt veelgebruikt door jonge mannen en vrouwen, dus hebben we wat muizen gepakt. En dan eigenlijk alleen mannelijke muizen. Gvd

Daar heb ik overgelezen hahaha is wel cringeworthy

Geld beter sparen dus, bedankt!

 

[PartyPiet]

Ik ben wel een IT'er. Ik heb informatica en software engineering gestudeerd.

Niet heel erg BB georiënteerd maar wat vind je van domain driven design? En heb je dat weleens toegepast?

 

[Galen]

Niet heel erg BB georiënteerd maar wat vind je van domain driven design? En heb je dat weleens toegepast?

Ik heb er geen goede mening over, want ik weet er te weinig over. Maar van wat ik me herinner kon ik me best vinden in veel van de concepten.

 

[haaii]

Wat gebeurt er als je je paper indient bij meerdere journals tegelijkertijd?

 

[Galen]

Wat gebeurt er als je je paper indient bij meerdere journals tegelijkertijd?

Mochten meerdere journals diezelfde publicatie publiceren, dan komt dat natuurlijk aan het licht (als het niet al eerder aan het licht kwam tijdens peer-review). Die journals zullen dan hoogstwaarschijnlijk je publicatie retracten en je bent daar nooit meer welkom om iets te publiceren. Daarnaast kan het zo zijn, afhankelijk van waar je precies mee akkoord bent gegaan, dat je aangeklaagd kunt worden voor inbreuk op auteursrechten (die draag je namelijk over aan de journal).

 

[haaii]

En beurtlings? Dan mag je zoveel journals proberen als mogelijk, toch?

 

[Galen]

En beurtlings? Dan mag je zoveel journals proberen als mogelijk, toch?

Correct.

 

[PartyPiet]

Ik heb er geen goede mening over, want ik weet er te weinig over. Maar van wat ik me herinner kon ik me best vinden in veel van de concepten.

Ah ok. Omdat je het had over grote programmeerprojecten. Dat is waar DDD het meeste tot zijn recht komt.

 

[Galen]

Ah ok. Omdat je het had over grote programmeerprojecten. Dat is waar DDD het meeste tot zijn recht komt.

Eén van de twee projecten begon relatief klein, maar is met de tijd wat groter geworden (zoals het wel vaker lijkt te gaan). Maar groot is natuurlijk relatief, ik heb het dan over een applicatie met zo'n 200 models om een idee van de schaal te geven. Dus geen project van 6 miljoen regels code oid. natuurlijk.

De andere heb ik initieel geadviseerd tijdens de requirementselicitatiefase en ben niet betrokken geweest bij de oorspronkelijke ontwikkeling en ontwerpfase (de requirements engineering heb ik niet zelf uitgevoerd). Pas later ben ik erbij gekomen om mee te ontwikkelen. Dit project is wat groter, met zo'n 300 models en momenteel bijna 100 microservices. Is nu vooral een project waarbij we nog weinig features implementeren en we de boel voornamelijk lopen te optimaliseren voor performance (nu bijv. bezig met de overstap van redis als message broker naar rabbitmq; al is dat voornamelijk vanuit security standpunt), wat dingen gladstrijken en de ontstane technische schuld inhalen (refactoring en aanvullen met tests).

 

[PartyPiet]

Eén van de twee projecten begon relatief klein, maar is met de tijd wat groter geworden (zoals het wel vaker lijkt te gaan). Maar groot is natuurlijk relatief, ik heb het dan over een applicatie met zo'n 200 models om een idee van de schaal te geven. Dus geen project van 6 miljoen regels code oid. natuurlijk.

De andere heb ik initieel geadviseerd tijdens de requirementselicitatiefase en ben niet betrokken geweest bij de oorspronkelijke ontwikkeling en ontwerpfase (de requirements engineering heb ik niet zelf uitgevoerd). Pas later ben ik erbij gekomen om mee te ontwikkelen. Dit project is wat groter, met zo'n 300 models en momenteel bijna 100 microservices. Is nu vooral een project waarbij we nog weinig features implementeren en we de boel voornamelijk lopen te optimaliseren voor performance (nu bijv. bezig met de overstap van redis als message broker naar rabbitmq; al is dat voornamelijk vanuit security standpunt), wat dingen gladstrijken en de ontstane technische schuld inhalen (refactoring en aanvullen met tests).

100 microservices? Als elke microservice datgene is wat ik denk dat het is (namelijk een volwaardige applicatie met eigen UI, Infrastructure en domein logica) dan hebben we het toch over een enorm groot project en een goede kandidaat voor DDD. Normaalgesproken kun je het wel een paar jaartjes volhouden met een classic MVC model waarbij modellen niet veel meer bevatten dan wat getters en setters (anemic model antipattern) en waarbij het overgrote deel van de business logica in helpers geknald wordt maar uiteindelijk wordt het allemaal 'a big ball of mud'. Met testjes kun je idd gelukkig wel voorkomen dat de ene fix 10 andere dingen om zeep helpt. Goed dat je daar mee bezig bent en dat je daar de ruimte voor krijgt. Ondanks het feit dat achteraf testjes schrijven voor andermans code niet de meest efficiente manier is.
Mocht je een keer wat tijd te besteden hebben dan kan ik je het, op dat gebied, meest bekende boek adviseren: Implementing domain driven design. Eigenlijk is het simpelweg een boek over moderne software architectuur en een verzameling van best practices voor als je applicaties wat grote worden zoals die van jou. Redelijk academisch maar volgens mij houd jij daar wel van

 

[Galen]

100 microservices? Als elke microservice datgene is wat ik denk dat het is (namelijk een volwaardige applicatie met eigen UI, Infrastructure en domein logica) dan hebben we het toch over een enorm groot project en een goede kandidaat voor DDD.

Het varieert wat. Sommige microservices zijn vrij compact, misschien 50 tot 200 regels code. Andere zijn ruim 1000 regels code en weer andere duizenden. Durf zo snel niet te zeggen waar het merendeel ligt; heb er met maar een paar te maken gehad. En dat zijn natuurlijk weer de grootste geweest.

Normaalgesproken kun je het wel een paar jaartjes volhouden met een classic MVC model waarbij modellen niet veel meer bevatten dan wat getters en setters (anemic model antipattern) en waarbij het overgrote deel van de business logica in helpers geknald wordt maar uiteindelijk wordt het allemaal 'a big ball of mud'.

Nu ben ik te weinig bekend met DDD, maar dat is toch nooit een goed idee geweest? Of ik begrijp het verkeerd. Je hangt er op z'n minst alle relaties aan, validatieregels voor de velden enz. Of is dat nog steeds anemic?

Met testjes kun je idd gelukkig wel voorkomen dat de ene fix 10 andere dingen om zeep helpt. Goed dat je daar mee bezig bent en dat je daar de ruimte voor krijgt. Ondanks het feit dat achteraf testjes schrijven voor andermans code niet de meest efficiente manier is.

Mja, zo loopt het altijd in de praktijk. Stakeholders wilden iets het liefst gisteren al geïmplementeerd, je geeft aan dat je het morgen voor 90% werkend kunt hebben dat ze het alvast kunnen demonstreren/gedeeltelijk in gebruik kunnen nemen/whatever, legt de nadelen daarvan uit, en ze kiezen daar dan toch vaak voor. (Even kort door de bocht.)

Maar goed, in dit geval eigenlijk wel een luxe dat we de tijd krijgen om die technische schuld op te lossen.

Mocht je een keer wat tijd te besteden hebben dan kan ik je het, op dat gebied, meest bekende boek adviseren: Implementing domain driven design. Eigenlijk is het simpelweg een boek over moderne software architectuur en een verzameling van best practices voor als je applicaties wat grote worden zoals die van jou. Redelijk academisch maar volgens mij houd jij daar wel van

Ik heb destijds moeten lezen in Making Software: What Really Works, and Why We Believe It (mijn docent was er vrij lyrisch over maar het was weinig academisch; veel opinie en de onderbouwing was vaak aantoonbaar onjuist) en Software Architecture in Practice.
(En we kregen net iets teveel papers over test-driven development; de docenten lieten hun mening daarover niet echt doorschemeren, maar de studies die daarmee gedaan waren waren nogal om te janken gvd.)

Is het ook een idee om het boek van Eric Evans himself te pakken, of kan ik beter gelijk in dat boek beginnen? Ik heb er wel oren naar.

 

[Vieze jij]

pijnlijk,het moment dat je beseft dat de IQ trein aan jou voorbij is gegaan

 

[PartyPiet]

Nu ben ik te weinig bekend met DDD, maar dat is toch nooit een goed idee geweest? Of ik begrijp het verkeerd. Je hangt er op z'n minst alle relaties aan, validatieregels voor de velden enz. Of is dat nog steeds anemic?

Ja, dat is nog steeds anemic. In weze hebben we het hier gewoon over OOP zoals je dat waarschijnlijk ook op school hebt gehad. Zodra je je business logica niet, voor zover mogelijk, in objecten plaatst (in DDD noemen we dat entities/aggregates) spreken we van een anemic model. Uiteraard is dat niet voor alles mogelijk. Denk bijv. aan dingen als calculators die als input diverse data gebruiken. Voor zoiets gebruik je een zogenaamde domain service. Deze bevat de business logica die je echt niet elders kwijt kunt. Het is echter wel iets anders dan een application service. Deze laatste gebruik je voornamelijk voor het coordineren van je use cases. Dus bijvoorbeeld voor het opvragen van data uit je repositories en bijv. na opslaan een domain event dispatchen zodat eventueel geinteresseerde listeners (in bijv. een andere microservice/context) daar weer op kunnen reageren en hun eigen acties kunnen ondernemen.
Van wat ik lees gebruik je al microservices en een messaging systeem. Dat is voor dit soort dingen helemaal top. Door je microservices heb je een strikte scheiding gemaakt op basis van context waardoor je minimale coupling krijgt tussen de afzonderlijke onderdelen en enkel onderling communiceert dmv je messaging systeem als er ergens iets verandert.

Maar goed, in dit geval eigenlijk wel een luxe dat we de tijd krijgen om die technische schuld op te lossen.

Mijn ervaring is dat stakeholders/product owners eigenlijk eerst een keer zelf moeten ervaren hoe het is als dingen te snel opgeleverd worden en vervolgens als een kaartenhuis in elkaar storten omdat er te veel shortcuts zijn genomen.
De beste product owners zijn degene die 1. Exact weten wat ze willen (idealiter dus ook een IT achtergrond hebben) en 2. Daadwerkelijk de authoriteit hebben om functionele keuzes te maken.
Mede daarom werk ik daarom tegenwoordig ook alleen nog maar voor pure SaaS bedrijven waar het software product centraal staat. Hierdoor is er veel meer begrip voor hetgene waar je mee bezig bent en krijg je ook daadwerkelijk de tijd in plaats van: "authenticatie heb je toch zo gemaakt? Dat is toch alleen even een login pagina maken?"

Ik heb destijds moeten lezen in Making Software: What Really Works, and Why We Believe It (mijn docent was er vrij lyrisch over maar het was weinig academisch; veel opinie en de onderbouwing was vaak aantoonbaar onjuist) en Software Architecture in Practice.

Net even gekeken. Die eerste lijkt me niet al te interessant. De meeste vragen waar dat boek antwoord op probeert te geven kun je na een paar jaar zelf wel beantwoorden. Die 2e is misschien al iets beter (ken hem verder niet).

Is het ook een idee om het boek van Eric Evans himself te pakken, of kan ik beter gelijk in dat boek beginnen? Ik heb er wel oren naar.

Ja die kun je altijd pakken maar zou ik persoonlijk niet zo snel doen. Het is inmiddels al wat gedateerd en het 2e boek waar ik het over had gebruikt het boek van Evans als input en probeert het allemaal wat duidelijker uit te leggen met praktische voorbeelden aangevuld met recente technieken als CQRS en Event Sourcing. Ondanks dat alle voorbeelden in Java zijn (ik programmeer zelf momenteel in PHP/Laravel) is het goed te volgen. Al helemaal als je een software opleiding achter de rug hebt.

pijnlijk,het moment dat je beseft dat de IQ trein aan jou voorbij is gegaan

Je snapt zelf hopelijk ook dat dit niks met IQ te maken heeft maar puur met interesses (naast een beetje met gewichten smijten in de gym).

 

[Nomen Nescio]

pijnlijk,het moment dat je beseft dat de IQ trein aan jou voorbij is gegaan

Op volle snelheid ook nog..

 

[Steks]

Op volle snelheid ook nog..

Hoe bedoel je?

 

[Nomen Nescio]

Hoe bedoel je?

 

[Galen]

Ja, dat is nog steeds anemic. In weze hebben we het hier gewoon over OOP zoals je dat waarschijnlijk ook op school hebt gehad. Zodra je je business logica niet, voor zover mogelijk, in objecten plaatst (in DDD noemen we dat entities/aggregates) spreken we van een anemic model. Uiteraard is dat niet voor alles mogelijk. Denk bijv. aan dingen als calculators die als input diverse data gebruiken. Voor zoiets gebruik je een zogenaamde domain service. Deze bevat de business logica die je echt niet elders kwijt kunt. Het is echter wel iets anders dan een application service. Deze laatste gebruik je voornamelijk voor het coordineren van je use cases. Dus bijvoorbeeld voor het opvragen van data uit je repositories en bijv. na opslaan een domain event dispatchen zodat eventueel geinteresseerde listeners (in bijv. een andere microservice/context) daar weer op kunnen reageren en hun eigen acties kunnen ondernemen.
Van wat ik lees gebruik je al microservices en een messaging systeem. Dat is voor dit soort dingen helemaal top. Door je microservices heb je een strikte scheiding gemaakt op basis van context waardoor je minimale coupling krijgt tussen de afzonderlijke onderdelen en enkel onderling communiceert dmv je messaging systeem als er ergens iets verandert.


Mijn ervaring is dat stakeholders/product owners eigenlijk eerst een keer zelf moeten ervaren hoe het is als dingen te snel opgeleverd worden en vervolgens als een kaartenhuis in elkaar storten omdat er te veel shortcuts zijn genomen.
De beste product owners zijn degene die 1. Exact weten wat ze willen (idealiter dus ook een IT achtergrond hebben) en 2. Daadwerkelijk de authoriteit hebben om functionele keuzes te maken.
Mede daarom werk ik daarom tegenwoordig ook alleen nog maar voor pure SaaS bedrijven waar het software product centraal staat. Hierdoor is er veel meer begrip voor hetgene waar je mee bezig bent en krijg je ook daadwerkelijk de tijd in plaats van: "authenticatie heb je toch zo gemaakt? Dat is toch alleen even een login pagina maken?"


Net even gekeken. Die eerste lijkt me niet al te interessant. De meeste vragen waar dat boek antwoord op probeert te geven kun je na een paar jaar zelf wel beantwoorden. Die 2e is misschien al iets beter (ken hem verder niet).


Ja die kun je altijd pakken maar zou ik persoonlijk niet zo snel doen. Het is inmiddels al wat gedateerd en het 2e boek waar ik het over had gebruikt het boek van Evans als input en probeert het allemaal wat duidelijker uit te leggen met praktische voorbeelden aangevuld met recente technieken als CQRS en Event Sourcing. Ondanks dat alle voorbeelden in Java zijn (ik programmeer zelf momenteel in PHP/Laravel) is het goed te volgen. Al helemaal als je een software opleiding achter de rug hebt.


Je snapt zelf hopelijk ook dat dit niks met IQ te maken heeft maar puur met interesses (naast een beetje met gewichten smijten in de gym).

Thanks, hier heb ik wat aan.

 

[mucci]

'Het is voor meer dan 80% afhankelijk van zijn estrogene conversie voor de anabole eigenschappen, dus het gebruik van anti-estrogenen bij dianabol is het stomste wat je ook maar kunt doen. Meer dan één trial heeft ook al aangetoond dat dianabol in combinatie met een anti-estrogeen, of niet-estrogene analogen, nagenoeg geen anabool effect heeft.'


Bovenstaand stukje is geschreven door Peter Van Mol op dit forum in het topic 'relatieve affiniteit van AAS' over methandienone. Hij haalt aan dat er trails zijn die aantonen dat dbol met een AI vrij nutteloos is, ik kan de studie helaas niet vinden en vroeg me af of je een handje kon helpen?