"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/13896/crop5dbbed904a73d_cropped.jpeg?f=community)
/u/89193/crop5913059561374.png?f=community)
:strip_exif()/u/316566/crop570109b769a18_cropped.gif?f=community)
En bedankt, ik moest even opzoeken wie dat ook alweer was en nu kan ik de komende maand Google Ads voor paardrijbroeken verwachten.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Sexy, ach heb je een goed excuus om op je werk gezellig je stokpaardjes te blijven berijden:
[...]
En bedankt, ik moest even opzoeken wie dat ook alweer was en nu kan ik de komende maand Google Ads voor paardrijbroeken verwachten.
, dressed for the occasion.
:strip_icc():strip_exif()/u/67180/crop5e000c49677af_cropped.jpeg?f=community)
Vorige week heb ik - zonder de achterliggende code of platform te kennen - een systeem uitgebreid van 1 communicatie bus naar meerdere communicatie bussen. De code was al voorbereid op meerdere bussen, maar dit was in het verleden nooit nodig geweest en met 1 bus heeft de code altijd gewerkt.
Tijdens het testen een tweede bus toegevoegd. Bleek dat de tweede bus wel werkte, maar de eerste ineens niet meer. Het heeft me drie dagen gekost om er achter te komen dat in de loop langs alle bussen voor het opmaken van de variabele lijsten ook de variabele lijsten werden toegekend aan de bus, alleen dan zonder check op "met welke bus ben ik bezig?". De eerste bus kreeg dus 2 maal dezelfde variabele lijst toegekend waardoor die over de zeik ging.
Drie dagen naar de klote. Een voordeel is wel dat ik de achterliggende code nu ook ken en geleerd heb hoe ik het platform kan debuggen.
Tijdens het testen een tweede bus toegevoegd. Bleek dat de tweede bus wel werkte, maar de eerste ineens niet meer. Het heeft me drie dagen gekost om er achter te komen dat in de loop langs alle bussen voor het opmaken van de variabele lijsten ook de variabele lijsten werden toegekend aan de bus, alleen dan zonder check op "met welke bus ben ik bezig?". De eerste bus kreeg dus 2 maal dezelfde variabele lijst toegekend waardoor die over de zeik ging.
Drie dagen naar de klote. Een voordeel is wel dat ik de achterliggende code nu ook ken en geleerd heb hoe ik het platform kan debuggen.
You don't have to be crazy to do this job, but it helps ....
:strip_exif()/u/39092/wolkje-avatar3.gif?f=community){kind=avatar}
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
Definieer "serverless" ?
Als alles met "wolk" er in geldt als zijnde geen server, want je ziet ze niet ...
Ik gok dat zowel cloudflare als azure niet geheel gebakken lucht zijn (bij azure kun je daar sinds gisteren over twijfelen sinds ze aangegeven hebben dat het datacenter een oven was), maar gewoon een berg servers bevatten.
Kortom gewoon "time well spend" ?:
Drie dagen naar de klote. Een voordeel is wel dat ik de achterliggende code nu ook ken en geleerd heb hoe ik het platform kan debuggen.
Je hebt je dankzij een probleem een stuk diepgaander in de applicatie kunnen verdiepen (je inlezen in code zonder een werkelijk probleem is doorgaans toch oppervlakkiger dan dat je iets voor langere tijd moet debuggen waarbij je van lieverlee toch assumpties maar eens moet laten varen en dingen moet uitzoeken en testen) waar je bij iedere interactie en bij ieder toekomstig probleem de vruchten van plukt.
[ Voor 41% gewijzigd door gekkie op 05-09-2018 10:03 ]
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
Ik denk dat je prima kan begrijpen dat 'ie doelt op cloud functions zoals van Azure, AWS of Cloudflare waar je zelf geen kennis hebt van de onderliggende hardware, OS en whatsoever
Het is een term die nu toch al even meegaat en iedereen weet dat er uiteindelijk gewoon ijzer onder hangt. Maar dat heb je ook met bijvoorbeeld containers of VPS'jes, en toch noemen we dat "virtual"...
[ Voor 12% gewijzigd door Merethil op 05-09-2018 10:04 ]
Ok dan klopte m'n analyse dus aardig ... "serverless" is in aardige mate een synoniem voor "in de wolken".:
[...]
Ik denk dat je prima kan begrijpen dat 'ie doelt op cloud functions zoals van Azure, AWS of Cloudflare waar je zelf geen kennis hebt van de onderliggende hardware, OS en whatsoever
Is "de cloud" als marketing term dan nu alweer uitgewerkt ?
Het is wel de meest optimale manier om serverless te gebruiken. Zoals hij zelf al uitlegt helpt het heel erg als de content die je serveert vrijwel statisch is en dus efficiënt gecached kan worden. Mooi voorbeeld van een situatie waarin je dus een goede use case hebt.
In de praktijk zie ik serverless ook vaak genoeg worden toegepast in gevallen waar het absoluut niet het juiste middel voor het beoogde doel is. Als je serverless gaat doen met een wirwar aan functions / lambdas, shared states tussen executies in databases gaat opslaan, zoveel doet dat je executietijden in de buurt komen van de time-outs en ga zo maar door, dan had je misschien gewoon een applicatie moeten bouwen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Nou, nee. Cloud computing is een stuk ruimer, maar serverless draait helemaal om het kunnen draaien van functions die je zelf definieert en je laat de provider (AWS, Azure etc) zelf bepalen wáár ze het draaien. Kans is dat je functions gewoon elke keer dat ze draaien op dezelfde server draaien, maar kans is ook dat er gewoon randomly gekozen wordt waar nog ruimte is.
Je doet zelf niets meer met servers maar laat ze dat volledig managen en vanuit een developmentomgeving bouw je dan je functions voor gebruik als API voor andere doeleinden. Wij gebruiken het zelf vooral voor functies die we niet heel vaak nodig hebben op AWS, want zodra je de functie een tijdje niet gebruikt gaat 'ie in een vorm van hibernation waar hij niets kost totdat we hem weer aanroepen.
En zelfs dan is zo'n functie vaak centenwerk in een maand, tenzij je hem óf miljarden keren per maand aanroept, óf grote hoeveelheden data gaat verstouwen.
Nou dat dus ja
[ Voor 9% gewijzigd door Merethil op 05-09-2018 10:10 ]
Serverless bekt gewoon net wat lekkerder dan execution-not-tied-to-a-specific-server-whether-thats-virtualized-or-not.:
[...]
Ik denk dat je prima kan begrijpen dat 'ie doelt op cloud functions zoals van Azure, AWS of Cloudflare waar je zelf geen kennis hebt van de onderliggende hardware, OS en whatsoever
Het is een term die nu toch al even meegaat en iedereen weet dat er uiteindelijk gewoon ijzer onder hangt. Maar dat heb je ook met bijvoorbeeld containers of VPS'jes, en toch noemen we dat "virtual"...
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Goh ik had niet verwacht dat de discussie die zou ontstaan nu over de definitie van "serverless" zou gaan. Natuurlijk heeft Azure en Cloudflare servers in hun serverparken staan, dat is nogal logisch
Zoals @Merethil ook aangeeft dus.Waar het mij om gaat is dat Troy geen (gevirtualiseerde) servers afneemt bij die partijen maar slechts executies voor die functions. Die functions schalen ideaal mee met drukte, beter nog dan je met gehele VMs zou kunnen doen. Want als er echt niets te doen is, betaal je in dit scenario echt 0. Maar de lichtste VM kost altijd wat. In dit geval een veelvoud van wat Troy nu betaalt, terwijl de lichtste VM hoogstwaarschijnlijk de pieken van HIPB absoluut niet aan kan.
Dat was wat ik bedoelde met de kracht van serverless
Ja als je zo'n lange naam verzint natuurlijk zeker
[ Voor 10% gewijzigd door Cloud op 05-09-2018 10:47 ]
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
/u/12668/hydra.png?f=community)
Of de term dekt de lading vrij beroerd, maar goed als daar consensus over is, mij best
.Is FAAS (Function As A Service) wellicht nog wel duidelijker om aan te geven wat size en scope is van de building blocks die je extern laat managen.
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
Een aanzienlijk deel van de kostenbesparing behaalt Troy door Cloudflare, dat is wel belangrijk om te vermelden. Door zoveel mogelijk te cachen komen heel veel requests nooit bij de Azure Functions terecht.
En voor wat betreft Microsoft en de winstgevendheid: goede vraag.
Mijn gedachten (ik ben absoluut niet zeker of dit waar is):
In principe hebben zij de servers al staan en draaien natuurlijk. Anders kunnen ze nooit on-demand extra VMs de lucht in schoppen binnen 10 minuten. Wellicht gebruikt Microsoft ook ongebruikte servercapaciteit om die functions op te draaien. En dan is het bijna pure winst, als we er even vanuit gaan dat een function-uitvoer niet noemenswaardig veel meer stroom gebruikt dan idle. Tegenwoordig zullen ze ook wel (gevirtualiseerde) servers hebben die gereserveerd zijn voor function uitvoer, gok ik. En daar is het een kwestie van slim voorspellen hoeveel capaciteit je nodig hebt. Maar dat geldt voor de servers die VMs moeten draaien uiteraard ook
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/189240/av70.png?f=community)
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
/u/262310/ava.png?f=community)
Dat kan je instellen. Je budgetten kan je namelijk vrij specifiek beheren.
Om antwoord te geven wat dan het verdien model is:
- x-miljoen queries !oN!on! ja ok; maar hoeveel kwamen daadwerkelijk terecht bij de functie ipv cache?
- 9 van de 10x draait er naast serverless ook: database(s), storage(S3), ES, ???, meerdere buckets voor je serverless, API endpoints, etc.
- Ah je gaat dan ook wel even de simple email service gebruiken
- domains in route 53
- nog wat logging in cloudwatch
ah shit, vendor locked.
Laten we dan onze static instances ook bij AWS zetten. Nog wat storage erbij.. poef lekker 120$ p/m voor een 2 cpu servertje.
-------
Je kan als je "slim" bent vrijwel gratis of voor enkele centjes per maand een enorme stack aan tech neerzetten. Zie het meer als entry level; net zoals je ook gratis (of goedkopere) licenties van Office krijgt als student. Ga je bij een bedrijf werken: dan wilt iedereen Office want ze weten niet anders. A 120 euro p/jaar (?).
Ik gebruik dus als basis openstack bij een provider in NL. Voor specifieke cases maak ik gebruik van AWS. Denk hierbij aan SES (1000 mails voor ~10 cent). EC2 instances voor een paar cent; free tier en die spot instances ($0.0069 per Hour).
------
Ik heb eens berekend wat het zou kosten om alles naar AWS te zetten. Resultaat was een factor 10 - 15 duurder.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Uiteraard, intern verkeer is 0.02$ / GB (0.00$ voor cloudfront en 0.01$ voor je eigen region) en extern is 0.09$ / GB
Exclusief de daadwerkelijke opslag ~$0.022 per GB en dan eventueel van je setup nog een 0.00x$ per 1k requests.
^ Dit is dan iig voor S3
De hele oplossing waar ik hier over praat slaat ongeveer 200TB aan data op. Er komen dagelijks forse hoeveelheden aan data vanuit andere systemen binnen en externe request liggen ook boven de 10M per dag.:
[...]
Uiteraard, intern verkeer is 0.02$ / GB (0.00$ voor cloudfront en 0.01$ voor je eigen region) en extern is 0.09$ / GB
Exclusief de daadwerkelijke opslag ~$0.022 per GB en dan eventueel van je setup nog een 0.00x$ per 1k requests.
^ Dit is dan iig voor S3
Dus dat loopt fors in de kosten.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
Gaaf, wat is dat voor iets?:
[...]
De hele oplossing waar ik hier over praat slaat ongeveer 200TB aan data op. Er komen dagelijks forse hoeveelheden aan data vanuit andere systemen binnen en externe request liggen ook boven de 10M per dag.
Dus dat loopt fors in de kosten.
Engineering is like Tetris. Succes disappears and errors accumulate.
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
:strip_icc():strip_exif()/u/734655/crop6390c3acd41c6_cropped.jpg?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Een combinatie van een operationeel systeem met datavoorziening richting consumenten en daarnaast ook een datawarehouse. Iets met logistiek.:
[...]
Gaaf, wat is dat voor iets?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/48320/kenshin60.png?f=community)
:strip_icc():strip_exif()/u/393369/crop55d593566408c.jpeg?f=community)
Dit is al het tweede mailtje wat ik hem krijg, uit het niks:
Lijkt me dat deze mail op zichzelf al tegen de AVG in gaat
Lijkt me dat deze mail op zichzelf al tegen de AVG in gaat
[ Voor 16% gewijzigd door Pizzalucht op 06-09-2018 10:37 ]
Hij is leuk, sowieso is Foone wel een aardig account om te volgen:
https://twitter.com/Foone/status/1037031222164082688
[...]
Voor de rest of it, lees het Twitter draadje
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
Dus zet jij dat maar even publiek met NAW, email, telefoon, etc.:
Dit is al het tweede mailtje wat ik hem krijg, uit het niks:
[afbeelding]
Lijkt me dat deze mail op zichzelf al tegen de AVG in gaat
Tjolk is lekker. overal en altijd.
Dat zijn allemaal publieke gegevens hoor...:
[...]
Dus zet jij dat maar even publiek met NAW, email, telefoon, etc.
Ze noemen ORM's niet voor niks "the vietnam of computer science"
Ask yourself if you are happy and then you cease to be.
Ben er ook wel redelijk van teruggekomen. Het is vooral handig als je heel snel een CRUD-achtig applicatietje wilt opzetten met een API / UI. Bij complexere database-interactie moet je je toch al snel in allerlei onhandige bochten gaan wringen.:
[...]
Ze noemen ORM's niet voor niks "the vietnam of computer science"
En juist als je wat basale CRUD doet is vaak een document store net zo handig. Weg is de impedence mismatch.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/373849/cowava2.png?f=community)
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Tsja, ik ben hoofdzakelijk .NET developer, maar toevallig pas ook nog Python gedaan. Onderstaand stukje code is een CRON job wrapper:
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
| #!/usr/bin/env python """Jobwrapper script for crontab Example: MAILTO=info@****.com MAILFROM=info@****.com JOBNAME="USB Backup" 0 23 * * * /scripts/jobwrapper.py /scripts/usbbackup.py This script uses SSMTP for mail delivery. """ import os import sys import subprocess import socket from email.mime.multipart import MIMEMultipart from email.mime.text import MIMEText class ConfigurationError(Exception): def __init__(self, message): self.message = message def send_mail(mailto, contents): """Send mail with SSMTP""" process = subprocess.Popen(["/usr/sbin/ssmtp", mailto], stdin=subprocess.PIPE, stdout=subprocess.PIPE) process.stdin.write(contents) process.communicate() process.stdin.close() def create_mail(hostname, jobname, mailfrom, mailto, exitcode, output): """Create mail message""" title = '{0}: {1} {2}'.format(hostname, jobname, 'succeeded' if exitcode == 0 else 'failed') msg = MIMEMultipart('alternative') msg['Subject'] = title msg['From'] = mailfrom msg['To'] = mailto if exitcode != 0: msg['X-Priority'] = '2' html = [] html.append("<html>") html.append("<body>") html.append("<h1>{0}</h1>".format(title)) html.append("<pre><code>") html.append(output) html.append("</code></pre>") html.append("</body>") html.append("</html>") html_string = ''.join(html) part1 = MIMEText("Please use a HTML capable mail client -_-", 'plain') part2 = MIMEText(html_string, 'html') msg.attach(part1) msg.attach(part2) return msg.as_string() def main(): """Main function""" try: # Check configuration mailto = os.environ.get('MAILTO') if mailto is None: raise ConfigurationError('Please set the MAILTO environment variable') mailfrom = os.environ.get('MAILFROM') if mailfrom is None: raise ConfigurationError('Please set the MAILFROM environment variable') jobname = os.environ.get('JOBNAME') if jobname is None: raise ConfigurationError('Please set the JOBNAME environment variable') if len(sys.argv) == 1: raise ConfigurationError('No commandline parameters were passed!') # Run the command we get from the commandline arguments exitcode = 0 output = '' try: output = subprocess.check_output(sys.argv[1:], stderr=subprocess.STDOUT) except subprocess.CalledProcessError as e: output = e.output exitcode = e.returncode # Build mime message hostname = socket.getfqdn() mimetext = create_mail(hostname, jobname, mailfrom, mailto, exitcode, output) # Send it with SSMTP send_mail(mailto, mimetext) except ConfigurationError as e: print("Configuration error: ", e.message) except: print("Unexpected error: ", sys.exc_info()[0]) # Run main function main() |
Kom maar met die fakkels
Misschien leer ik er nog wat van.Ik heb zelf ook nog wel wat kanttekeningen bij mijn scriptje, maar voor nu werkt het prima. 1 ding dat bijvoorbeeld mist is een afhandeling voor timeouts, dus als het sub process niet terugkomt. Een ander dingetje is als het subprocess erg veel regels produceert, dan gaat dit script geheugen vreten (of misschien wel vastlopen), omdat de output niet direct door wordt gegeven.
Maar dit zijn dus dingen die in mijn eigen situatie niet echt spelen momenteel en meer "nice to have" zijn.
Ask yourself if you are happy and then you cease to be.
Het enige dat ik zo snel zie, is dat het qua leesbaarheid, een extraction kan gebruiken for `send_mail` en `create_mail`. Anders dan dat... is't redelijk vergelijkbaar met mijn skills:
[...]
Tsja, ik ben hoofdzakelijk .NET developer, maar toevallig pas ook nog Python gedaan. Onderstaand stukje code is een CRON job wrapper:
** weg gehaald, want de post was te lang, somehow **
Kom maar met die fakkels
Ik heb zelf ook nog wel wat kanttekeningen bij mijn scriptje, maar voor nu werkt het prima. 1 ding dat bijvoorbeeld mist is een afhandeling voor timeouts, dus als het sub process niet terugkomt. Een ander dingetje is als het subprocess erg veel regels produceert, dan gaat dit script geheugen vreten (of misschien wel vastlopen), omdat de output niet direct door wordt gegeven.
Maar dit zijn dus dingen die in mijn eigen situatie niet echt spelen momenteel en meer "nice to have" zijn.
Ik zal dan ook maar even code-dumpen:
*Code even in een quote gegooit, zodat het wordt afgekort. Scheelt spam spul enzo*
Dit geval verwacht een bepaalde SQL structuur en een Solr instance voor search, structuur is gebaseerd op de standaard die SilverStripe (yah, duh, dat is waar ik voor werk) hanteerd. Nieuwe berichten worden elke 5 minuten naar Solr gestuurd voor de index en het domein in de code is hard-coded. En ja, domein bestaat en is een SilverStripe site die basically hetzelfde doet als deze code.
Verschil is, dat de Python code werkt met Slack, waar de website alleen maar gebruikt wat de Python code in de database heeft gepropt.
Indien mensen geinteresseerd zijn, de code slaat elk bericht in een Slack Workspace op in een database. Een ander stuk zorgt er voor dat alle nieuwe berichten elke X minuten naar Solr wordt gepushed zodat ze geindexed zijn voor search.
In de Slack Workspace kun je daarmee dus zoeken buiten de limiet van Slack voor gratis workspaces.
Ondersteund zijn bijvoorbeeld "@MyBotName zoek", en je krijgt 1 response, plus een link om verder te zoeken via de website.
Of je kan de bot direct aanspreken in de Slack DM, en je krijgt 10 resultaten terug.
Smerig dingetje, als het een mention is van de bot, pas ik het event van Slack aan, zodat er een limiet van 1 resultaat is, smerig, maar het werkt om te voorkomen dat ik een Slack channel vol spam
Fun fact: Je kan zien hoe erg ik bezig ben met functionaliteit vs. herbruikbaarheid aan m'n comments. Main.py was origineel een container die _alles_ deed... de refactor heeft duidelijk effect op mijn code comments gehad
[ Voor 77% gewijzigd door Firesphere op 06-09-2018 14:21 ]
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik zag in het smerige stukje code (sendmessage.py:59 en 63) None checks met een equality operator.
Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
Voor de rest word ik er een beetje duizelig van
Ask yourself if you are happy and then you cease to be.
Weer wat geleerd! Mijn linter en Python interpreter (en VSCode) vonden het allemaal prima, dus ik had het niet gezien. Thanks!:
[...]
Ik zag in het smerige stukje code (sendmessage.py:59 en 63) None checks met een equality operator.
Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
Voor de rest word ik er een beetje duizelig van
Wat maakt je duizelig? Het meeste is eigenlijk alleen maar het opzoeken van de juiste referenties etc. voor Slack. Zoveel bijzonders gebeurd er eigenlijk niet
*edit*
Ah, `allow_equals:false` maakt m'n VSCode compleet over de rooie gaan inderdaad. Cool!
[ Voor 19% gewijzigd door Firesphere op 06-09-2018 14:39 . Reden: Ik snap BB Code nog steeds niet ]
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
De grote hoeveelheid nested if statements:
[...]
Wat maakt je duizelig? Het meeste is eigenlijk alleen maar het opzoeken van de juiste referenties etc. voor Slack. Zoveel bijzonders gebeurd er eigenlijk niet
Vooral in sendmessage.py. Ik zou de code met de eerste for loop waarschijnlijk afsplitsen in een aparte parse functie. Ook zou ik geen try catch gebruiken voor het controleren of iets een geldig getal is, maar een functie zoals isnumeric().
Python heeft geen switch() statement - ik heb het even opgezocht
- anders zou ik dat ook willen gebruiken in jouw code
[ Voor 14% gewijzigd door Lethalis op 06-09-2018 15:32 ]
Ask yourself if you are happy and then you cease to be.
/u/243953/crop56f55a7bcf291.png?f=community)
in plaats van een switch hoor je gebruik te maken van een dictionary, maar dat is niet altijd even toepasselijk of handig. Zou zo ook niet 1,2,3 weten hoe dat goed te implementeren.:
[...]
De grote hoeveelheid nested if statements
Vooral in sendmessage.py. Ik zou de code met de eerste for loop waarschijnlijk afsplitsen in een aparte parse functie. Ook zou ik geen try catch gebruiken voor het controleren of iets een geldig getal is, maar een functie zoals isnumeric().
Python heeft geen switch() statement - ik heb het even opgezocht
[ Voor 8% gewijzigd door Gropah op 06-09-2018 15:43 ]
De cognitieve complexiteit schiet door het dak inderdaad.:
[...]
De grote hoeveelheid nested if statements
Vooral in sendmessage.py. Ik zou de code met de eerste for loop waarschijnlijk afsplitsen in een aparte parse functie. Ook zou ik geen try catch gebruiken voor het controleren of iets een geldig getal is, maar een functie zoals isnumeric().
Python heeft geen switch() statement - ik heb het even opgezocht
Heb in m'n huidige project ook nog een stuk waarin we complete refactoring moeten doen van code die bol staat van de functies / methods met 100+ cognitive complexity.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
@Lethalis Wil je ook PEP 8 feedback? Dan horen er namelijk twee witregels tussen de imports en de rest van de code te zetten, en ook twee witregels tussen de functies. Er hoort ook nog een witregel te zitten na main() (dus nog een lege regel 109)
Zelf zou ik die main() op het einde binnen een if __name__ == "__main__" zetten. Of misschien de hele main() functie weghalen.
Maar da's natuurlijk allemaal muggenzifterij
Meer inhoudelijk: Ik vraag me af of een aantal ConfigurationErrors te combineren zijn (MAILTO, MAILFROM en JOBNAME), maar daar weet ik zo 1-2-3 ook geen elegantere oplossing voor. Daarnaast zou ik de output van de subprocess naar een tijdelijk bestand schrijven (Python heeft hier tempfile voor) om geheugenproblemen te voorkomen.
Zelf zou ik die main() op het einde binnen een if __name__ == "__main__" zetten. Of misschien de hele main() functie weghalen.
Maar da's natuurlijk allemaal muggenzifterij
Meer inhoudelijk: Ik vraag me af of een aantal ConfigurationErrors te combineren zijn (MAILTO, MAILFROM en JOBNAME), maar daar weet ik zo 1-2-3 ook geen elegantere oplossing voor. Daarnaast zou ik de output van de subprocess naar een tijdelijk bestand schrijven (Python heeft hier tempfile voor) om geheugenproblemen te voorkomen.
🠕 This side up
I prefereer dan weer ES. Niet zo zeer qua engine maar wel de stabiliteit en scale mogelijkheden. SOLR is me toch een partij vaak gecrashed hier en daar..
Overigens thx voor het sharen van je code, altijd leuk om door te lezen
Omdat dat eigenlijk de 'native' insteek van ES is. "Designed for the cloud" zeg maar. Solr heeft dan Solr Cloud met een zookeeper combo.
Eigenlijk een lang verhaal kort; ES kan gewoon out of the box redundant met meerdere nodes werken. Solr niet
* whoami nog altijd fan van NHibernate voor complexe domain-models.:
[...]
Ben er ook wel redelijk van teruggekomen. Het is vooral handig als je heel snel een CRUD-achtig applicatietje wilt opzetten met een API / UI. Bij complexere database-interactie moet je je toch al snel in allerlei onhandige bochten gaan wringen.
En juist als je wat basale CRUD doet is vaak een document store net zo handig. Weg is de impedence mismatch.
Al ben ik tegenwoordig wel niet zo veel meer met db's en ORM bezig; laatst nog eens Dapper gebruikt voor wat simpele data-access. Dat is dan wel geen full-blown ORM, maar ik was er wel best door gecharmeerd.
https://fgheysels.github.io/
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/286895/icon1.png?f=community)
Hoe grappig ik python soms ook vindt, er heeft echt iemand een punt van zitten maken dat python dingen anders moet doen dan andere talen. Geen do-while ("not pythonic!"), maar wel een while-else. Bedankt joh, daar hebben we wat aan.
Heeft geen speciale krachten en is daar erg boos over.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dank voor de feedback team! 
Thanks Ik ben ondertussen toe aan wat refactoring en sendmessage is mijn primary om bij te schaven, want inderdaad wat'n draak
Ik ben niet anti-ES ofzo (eerder, ik vind het een top product), maar te weinig ervaring om het snel en effectief te laten werken. Solr daarentegen kostte me een half uur aan configuratie (en anderhalve dag aan indexeren van alle berichten in Slack, maar dat is ongerelateerd aan Solr )
In mijn geval, is het gewoon de beste oplossing om een Slack bot te schrijven. Flexibeler dan een web-interface in PHP/.NET/Whatever, omdat het draait als een background daemon in plaats van een echte web service.
Maar uiteindelijk, is elke taal hetzelfde. Het is alleen andere woordjes voor bepaalde dingen.
Eerlijk gezegd... verwar ik ze zelf momenteel ook regelmatig:
[...]
De grote hoeveelheid nested if statements
Ik ben dan ook niet echt "trots" op de sendmessage. Die heb ik expres gekozen omdat het dus de smerigste van allemaal is
Thanks Zoaals uitgelegd hier boven... feedback zeer welkom!:
[...]
De cognitieve complexiteit schiet door het dak inderdaad.
Heb in m'n huidige project ook nog een stuk waarin we complete refactoring moeten doen van code die bol staat van de functies / methods met 100+ cognitive complexity.
Ik ben ondertussen toe aan wat refactoring en sendmessage is mijn primary om bij te schaven, want inderdaad wat'n draak Ik ben zo gewend aan Solr tegenwoordig... ES is niet campatible genoeg met SilverStripe momenteel (naar mijn mening), en mijn ervaring met Solr, voor mij was de keuze vrij simpel.:
[...]
I prefereer dan weer ES. Niet zo zeer qua engine maar wel de stabiliteit en scale mogelijkheden. SOLR is me toch een partij vaak gecrashed hier en daar..
Overigens thx voor het sharen van je code, altijd leuk om door te lezen
Ik ben niet anti-ES ofzo (eerder, ik vind het een top product), maar te weinig ervaring om het snel en effectief te laten werken. Solr daarentegen kostte me een half uur aan configuratie (en anderhalve dag aan indexeren van alle berichten in Slack, maar dat is ongerelateerd aan Solr
)Ik vind Python een erg elegante taal eigenlijk. Hoofdzakelijk omdat de indentatie zo belangrijk is. Het dwingt de schrijver om na te denken over indentatie (en veel auto-formatters doen het ook fout, wat voor rare situaties zorgt). Deze geforceerde indentatie is vooral bij junior engineers belangrijk vind ik, omdat het er voor zorgt dat ze de gewoonte van goede indentatie leren.
In mijn geval, is het gewoon de beste oplossing om een Slack bot te schrijven. Flexibeler dan een web-interface in PHP/.NET/Whatever, omdat het draait als een background daemon in plaats van een echte web service.
Maar uiteindelijk, is elke taal hetzelfde. Het is alleen andere woordjes voor bepaalde dingen.
[ Voor 158% gewijzigd door Firesphere op 07-09-2018 04:54 ]
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/10274/crop67712295188a6_cropped.jpg?f=community)
/u/81985/crop566b00b43645a.png?f=community)
Extraction extraction extraction, nog lang niet perfect, maar al wel een stuk beter wat betreft leesbaarheid
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Dan stap je wel erg snel over het verschil in expressiviteit tussen verschillende talen. Is het in VB net zo makkelijk om te werken met immutable datastructuren als in F#? Als je een relationele database wil uitvragen, kies je Pascal of SQL? Biedt Go higher kinded types?
De obligate link naar Paul Graham laat ik aan een ander
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Jep, ik generaliseer nogal daar, maar ik sta toch achter mijn reactie. Natuurlijk zijn er een hoop verschillen, maar de logische denkwijze om van A naar B te komen, is hetzelfde:
[...]
Dan stap je wel erg snel over het verschil in expressiviteit tussen verschillende talen. Is het in VB net zo makkelijk om te werken met immutable datastructuren als in F#? Als je een relationele database wil uitvragen, kies je Pascal of SQL? Biedt Go higher kinded types?
De obligate link naar Paul Graham laat ik aan een ander
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/302903/logo.jpg?f=community){kind=logo}
Ik vind elegantie 'in the eye of the beholder', maar dit soort zaken worden juist door Pythonfans inderdaad vaak genoemd als reden dat Python zo geweldig is. Ik vind persoonlijk indentation als language construct namelijk zo ongeveer het meest onzalige idee allertijden.
Daarnaast heb je idee en uitwerking. het idee is wellicht dat je juist zou afdwingen dat mensen geen eindeloze nesting zouden toepassen met totaal onoverzienbare functies tot gevolg, maar de praktijk is vaak anders zoals jouw voorbeeld al aangeeft.
Het idee bij Pythondevelopers is vaak dat talen als Java en C# enorm verbose zijn en gigantisch ingewikkeld om hele simpele dingen te doen. Nou is dat beeld op veel vlakken sowieso al wel vaak gedateerd, maar er zijn ook heel wat nieuwe talen bijgekomen in dezelfde ecosystemen. Zo heb je Kotlin en F# bijvoorbeeld.
Python is ook wel prima voor scripting / automatisering, data science en dingen die je even snel in elkaar moet klussen, maar voor applicaties van serieuze omvang levert het in mijn ogen toch vooral een onoverzichtelijke brei op, maar ik heb persoonlijk ook echt een schurfthekel aan dynamic typing.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dit is ook exact mijn mening.
Zodra mn python script > 50 lines heeft ga ik namelijk huilen van ellende.
Hoewel ik het zelf erg tof vind is er nog een ander negatief punt;
python2.7 vs 3 en dan nog die dependency hell. De 1 required v1.2 en de ander 1.4 en dan sloop je de rest en dan zet je pip erop en dan valt heel python uit elkaar.
Zeker op een system waar je toch al snel diverse python-based dingen gebruikt kan je best tegen dit soort grappen aanlopen.
Je kunt er ook echt heel mooi 'verkennend' in programmeren middels Jupyter notebooks wat het erg geschikt maakt voor allerhande data science dingen.:
[...]
Dit is ook exact mijn mening.
Zodra mn python script > 50 lines heeft ga ik namelijk huilen van ellende.
Hoewel ik het zelf erg tof vind is er nog een ander negatief punt;
python2.7 vs 3 en dan nog die dependency hell. De 1 required v1.2 en de ander 1.4 en dan sloop je de rest en dan zet je pip erop en dan valt heel python uit elkaar.
Zeker op een system waar je toch al snel diverse python-based dingen gebruikt kan je best tegen dit soort grappen aanlopen.
Collega van me was laatst een dag bezig om uit te vinden hoe hij een methode in een SDK nou precies moest aanroepen in Python.
Nou lag dat vooral aan hem, want ik was er binnen een kwartier wel uit, maar dynamic typing helpt dan ook echt niet. Bij een statically typed language miept je compiler tenminste gelijk.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Types zijn fijn 
Hindley-Milner, algebraic data types. Ik ben het eindelijk gaan waarderen. In dit tempo ga ik over tien jaar zelfs Haskell waarderen (en begrijpen)
Hindley-Milner, algebraic data types. Ik ben het eindelijk gaan waarderen. In dit tempo ga ik over tien jaar zelfs Haskell waarderen (en begrijpen)
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Even een ordinaire crosspost naar het grote enquete-topic.
Wij hebben hier een stagiair die een onderzoek doet specifiek gericht op devven dus dit lijkt me de uitgelezen plek om buiten het enquete-topic de juiste doelgroep aan te spreken
Wij hebben hier een stagiair die een onderzoek doet specifiek gericht op devven dus dit lijkt me de uitgelezen plek om buiten het enquete-topic de juiste doelgroep aan te spreken
Hoeder van het Noord-Meierijse dialect
Uhm... Auw...? Ik begin hier te toch een beetje te merken dat ik een ouwe rot ben.
"www" is een subdomein en werd voornamelijk populair omdat het vaak de naam was voor de machine bedoelt voor de buiten wereld (world-wide). Zo waren er vroeger ook site's die "w3" of "web" gebruikte als naam voor hun na buiten gerichte server. De reden waarom de prefix van "www" zo populair werd is omdat het zeer duidelijk aangaf dat het om een website ging en niet om een fysieke locatie. Dit was nog in de tijd dat men dacht dat voor online shoppen je een fysieke winkel moest simuleren waarbij je virtueel door gangpaden liep en waarbij je producten uit een virtueel rek pakte. Als je een beeld wilt vormen dan kan je het vergelijken door in VR door een supermarkt te lopen... alleen ipv van VR moet je denken aan een CRT monitor met een resolutie van 800x600 (als je geluk had!).
Zie men "Kom kijken bij ons op www..." dan wist men dan ze een computer moesten pakken ipv het stratenboek.
Tegenwoordig is "www" niet meer nodig om te communiceren dat het om een website gaat. Echter waar Google de plank mis slaat is dat er technische een heleboel redenen zijn. Het is namelijk een subdomein. En cookies van een hoofddomein gaan mee naar het subdomein. Twitter heeft geen "www" domein en toen ze ook afbeeldingen toe gingen staan, moesten ze een nieuw domein nemen. Anders kreeg je bij elke afbeelding namelijk ook de cookies.
Zelf heb ik het ook al een keer meegemaakt waarbij site.com/a en site.com/b een mapping hadden naar twee verschillende sites. Echter omdat ze dezelfde cookie gebruiken om je sessie bij te houden moest je twee verschillende browsers gebruiken.
Dan is er nog een derde reden: Het kan verwijzen naar verschillende systemen.
Als jij je mailserver en webserver zonder subdomein draait op twee verschillende machines dan moet er een systeem tussen gezet worden om het verkeer te splitsen. Nu is een mailserver een slecht voorbeeld omdat clients moeten kijken naar de MX-record, maar je moest soms best creatief zijn met port forwarding. Echter dat werkte alleen maar als de andere partij geen firewall had die alles blokkeerde behalve de gebruikelijke porten.
Persoonlijk ben ik overtuigd dat www staat voor WoutersWonderlijkeWereld
"www" is een subdomein en werd voornamelijk populair omdat het vaak de naam was voor de machine bedoelt voor de buiten wereld (world-wide). Zo waren er vroeger ook site's die "w3" of "web" gebruikte als naam voor hun na buiten gerichte server. De reden waarom de prefix van "www" zo populair werd is omdat het zeer duidelijk aangaf dat het om een website ging en niet om een fysieke locatie. Dit was nog in de tijd dat men dacht dat voor online shoppen je een fysieke winkel moest simuleren waarbij je virtueel door gangpaden liep en waarbij je producten uit een virtueel rek pakte. Als je een beeld wilt vormen dan kan je het vergelijken door in VR door een supermarkt te lopen... alleen ipv van VR moet je denken aan een CRT monitor met een resolutie van 800x600 (als je geluk had!).
Zie men "Kom kijken bij ons op www..." dan wist men dan ze een computer moesten pakken ipv het stratenboek.
Tegenwoordig is "www" niet meer nodig om te communiceren dat het om een website gaat. Echter waar Google de plank mis slaat is dat er technische een heleboel redenen zijn. Het is namelijk een subdomein. En cookies van een hoofddomein gaan mee naar het subdomein. Twitter heeft geen "www" domein en toen ze ook afbeeldingen toe gingen staan, moesten ze een nieuw domein nemen. Anders kreeg je bij elke afbeelding namelijk ook de cookies.
Zelf heb ik het ook al een keer meegemaakt waarbij site.com/a en site.com/b een mapping hadden naar twee verschillende sites. Echter omdat ze dezelfde cookie gebruiken om je sessie bij te houden moest je twee verschillende browsers gebruiken.
Dan is er nog een derde reden: Het kan verwijzen naar verschillende systemen.
Als jij je mailserver en webserver zonder subdomein draait op twee verschillende machines dan moet er een systeem tussen gezet worden om het verkeer te splitsen. Nu is een mailserver een slecht voorbeeld omdat clients moeten kijken naar de MX-record, maar je moest soms best creatief zijn met port forwarding. Echter dat werkte alleen maar als de andere partij geen firewall had die alles blokkeerde behalve de gebruikelijke porten.
Persoonlijk ben ik overtuigd dat www staat voor WoutersWonderlijkeWereld
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
/u/1906/crop5dfd46928e003.png?f=community)
www kán een subdomein zijn maar is meestal gewoon een hostnaam. Als het wel een subdomein is dan moet er ook een wildcard record in DNS zijn. Als dat wildcard record naar hetzelfde IP verwijst als het www-record dan zal www.domein.tld naar dezelfde site wijzen als domein.tld.:
Uhm... Auw...? Ik begin hier te toch een beetje te merken dat ik een ouwe rot ben.
"www" is een subdomein en werd voornamelijk populair omdat het vaak de naam was voor de machine bedoelt voor de buiten wereld (world-wide). Zo waren er vroeger ook site's die "w3" of "web" gebruikte als naam voor hun na buiten gerichte server. De reden waarom de prefix van "www" zo populair werd is omdat het zeer duidelijk aangaf dat het om een website ging en niet om een fysieke locatie. Dit was nog in de tijd dat men dacht dat voor online shoppen je een fysieke winkel moest simuleren waarbij je virtueel door gangpaden liep en waarbij je producten uit een virtueel rek pakte. Als je een beeld wilt vormen dan kan je het vergelijken door in VR door een supermarkt te lopen... alleen ipv van VR moet je denken aan een CRT monitor met een resolutie van 800x600 (als je geluk had!).
Zie men "Kom kijken bij ons op www..." dan wist men dan ze een computer moesten pakken ipv het stratenboek.
Tegenwoordig is "www" niet meer nodig om te communiceren dat het om een website gaat. Echter waar Google de plank mis slaat is dat er technische een heleboel redenen zijn. Het is namelijk een subdomein. En cookies van een hoofddomein gaan mee naar het subdomein. Twitter heeft geen "www" domein en toen ze ook afbeeldingen toe gingen staan, moesten ze een nieuw domein nemen. Anders kreeg je bij elke afbeelding namelijk ook de cookies.
Zelf heb ik het ook al een keer meegemaakt waarbij site.com/a en site.com/b een mapping hadden naar twee verschillende sites. Echter omdat ze dezelfde cookie gebruiken om je sessie bij te houden moest je twee verschillende browsers gebruiken.
Dan is er nog een derde reden: Het kan verwijzen naar verschillende systemen.
Als jij je mailserver en webserver zonder subdomein draait op twee verschillende machines dan moet er een systeem tussen gezet worden om het verkeer te splitsen. Nu is een mailserver een slecht voorbeeld omdat clients moeten kijken naar de MX-record, maar je moest soms best creatief zijn met port forwarding. Echter dat werkte alleen maar als de andere partij geen firewall had die alles blokkeerde behalve de gebruikelijke porten.
Persoonlijk ben ik overtuigd dat www staat voor WoutersWonderlijkeWereld
Je hebt gewoon veel meer controle dan met pakweg Entity Framework + de mapping-mogelijkheden zijn wel heel goed. Een legacy database mappen naar een min-of-meer OK object-model is in NHibernate mogelijk, daar waar het in EF bv veel moeilijker is. De leercurve is dan ook wel wat steiler.
En misschien was ik wat ongenuanceerd: ik ben niet veel meer bezig met relationele data, momenteel
/dit topic gaat veel te snel.
https://fgheysels.github.io/
https://github.com/chromi...tter/url_formatter.cc#L71
Iemand op hackernews verwees hier naar; zit gewoon geen logica achter dus
In de reacties bij de Chromium bug kwam ook al langs dat iets als foo.www.example.com ook wordt omgezet naar foo.example.com, dat is natuurlijk ook al helemaal raar.:
[...]
https://github.com/chromi...tter/url_formatter.cc#L71
Iemand op hackernews verwees hier naar; zit gewoon geen logica achter dus
:strip_icc():strip_exif()/u/172182/crop5ea83ce62d327.jpeg?f=community)
Dit topic is gesloten.