019 – Der kleine Mikrofreak
Wir sprechen in dieser Episode über In Ear Monitors, Brummen und unsere Audiosetups. Danach berichtet hukl von HTTP/3, Letty von mathematischen Kacheln und zum Abschluss sprechen wir über Job Interviews in Zeiten von ChatGPT und schließen mit ein bisschen Matrix ab
Shownotes
- Arturia MicroFreak – https://thmn.to/thoprod/457192?offid=1&affid=3301
- INKAA – Timestamp für den Mix 1:23:37 – https://soundcloud.com/wuza-berlin/wuza-waves-90-inkaa-geschmeidig-gegen-den-strom
- 3.5mm auf 6.3mm Adapter – https://thmn.to/thoprod/300470?offid=1&affid=3301
- Shure SE215 CL – https://thmn.to/thoprod/262382?offid=1&affid=3301
- Shure SE425 CL – https://thmn.to/thoprod/253091?offid=1&affid=3301
- Custom Sleeves für IEMs – https://www.scheinhardt.de/shop/custom-sleeves/custom-sleeves
- TritonAudio FetHead – https://thmn.to/thoprod/439143?offid=1&affid=3301
- SSL 2 Audio Interface – https://thmn.to/thoprod/481700?offid=1&affid=3301
- Shure SM 7b – https://thmn.to/thoprod/129929?offid=1&affid=3301
- QUIC – https://en.wikipedia.org/wiki/QUIC
- HTTP/3 – https://en.wikipedia.org/wiki/HTTP/3
- GoAccess – https://goaccess.io/
- The Logfile Navigator – https://lnav.org
- WordPress Command Line – https://wp-cli.org
- Tessellation – https://en.wikipedia.org/wiki/Tessellation
- Penrose Tiling – https://en.wikipedia.org/wiki/Penrose_tiling
- d3js – https://d3js.org/
- P5js – https://p5js.org/
- 7 Days to Die – https://store.steampowered.com/app/251570/7_Days_to_Die/
- Jaccard Index – https://en.wikipedia.org/wiki/Jaccard_index
- Matrix – https://matrix.org/
- Glitterbrains Matrix Channel muss noch ein bisschen warten – da muss hukl noch was administrieren
CLI-Logfile-Analyse für nginx gibt’s auch in Rust!
https://github.com/Canop/rhit
In meiner Erfahrung unanständig schnell, auch auf komprimiertes Logfiles.
Ob es alles hat, das ihr braucht, weiß ich nicht; ich nutze es nur gelegentlich für sehr einfache Sachen.
Moin,
der Tilinggenerator ist ein sehr schoenes Problem. Was ich wahrscheinlich versuchen wuerde waere zuerst einen Graph zu generieren in dem jede vertex ein tile representiert und jede edge die Kante zwischen zwei tiles, also den Dual graph von dem was gezeichnet werden soll. Dann kann man die Eigenschaften der tiles (zb Anzahl der Kanten) und die constraints der Komposition (welche Seiten von tiles zusammen passen, wieviele tiles sich in einem Punkt treffen duerfen, etc) im Graph beruecksichtigen. Aus dem Graph ein tiling zu zeichnen ist dann recht einfach. Je nach dem wie gross die zu kachelnde Flaeche ist koennte man auch zunaechst einen kleinen Graph generieren und ihn dynamisch erweitern wenn man beim Zeichen an die Grenzen der Flaeche stoesst.
Bitte entschuldige mein denglisch, ich habe an diesem Thema immer nur auf englisch gearbeitet …
cheers, Nico
Nico! Vielen Dank für die Idee mit dem Graph! Darüber habe ich überhaupt nicht nachgedacht es so zu lösen. Genial, dass muss ich mir mal genauer anschauen. Und denglish ist fine, da wird hier nicht complaint.
Zum Thema Over-ear Kopfhörer und Brille: mit vielen Kopfhörern ist mit das auch sehr unangehmen für länger zum Tragen. Welcher Kopfhörer allerdings extrem angenehm ist, auch mit Brille, ist mein Beyerdynamic DT 1770 Pro (der DT 1990 Pro hat die gleiche Bauform, der ist genauso) mit den Velourpolstern. Super angenehm über der Brille auch wenn es mal länger dauert.
Der Grund warum ich das schreibe: inspiriert von eurer Sendung habe ich mal wieder meine In-ear Kopfhörer getestet. Die geben in der Tat mehr Freiheitsgefühl beim Kopfhörer tragen, aber der Klang war so viel schlechter als mit dem Beyerdynamic dass ich nach ein paar Stunden direkt wieder zu denen gewechselt bin. Kann natürlich sein, dass ich die falschen In-ears gekauft habe (Etymotic ER4XR) aber laut reviews sollten es jetzt auch nicht die schlechtesten sein.
Fuer die Kommunikaton mit Recruitern und Unternehmen habe ich mir eine kostenlose Prepaid eSIM geholt, die ich nach der Jobsuche wieder abgeschaltet habe. Wuerde ich allen empfehlen, die sich mit diesen Leuten auseinandersetzen muessen. 🙂
IQ 3000 Move *notier
Da ihr euch ja freut, wenn eure Tipps/ Empfehlungen anderen Menschen helfen, hier ein kleiner Dank an Letty.
Nachdem meine einfache Brother Nähmaschine meine Liebste öfter mal nervte, erfreuen wir / sie uns seit Jahren an der Bernina die bis vor einigen Jahren wohl die teuerste Investition in unserem Haushalt war.
Vielen Dank für diese Empfehlung 🙂
Das freut mich! Liebe meine auch echt sehr.
@Hukl warum magst du kein camel case? Snake case unterbricht für mich den Schreibfuss, trägt nicht zur Lesbarkeit bei und führt zu längeren Variablennamen.
Dann ist das für dich natürlich ok aber generell würde ich behaupten, dass camelCase eher weniger gut lesbar ist.
Hier mal 3 spontane Beispiele die mir einfallen
Bei snake_case muss ich viel weniger über diese Dinge nachdenken und es ist einfacher für mich consistent zu bleiben.
Es gibt aber auch diverse Studien zu dem Thema die zwar sagen, dass man mit Beiden gut klar kommt wenn man konsistent ist und sich dran gewöhnt hat aber ich meine, dass die meisten Studien auch sagen, dass Leute die frisch auf eine Codebase mit ungewohntem Style schauen, snake_case besser lesbar/verstehbar und verwirrungsärmer ist.
ChatGPT listet da Folgende:
Zu der von ChatGPT generierten Liste an Studien: ich konnte lediglich die Erste davon tatsächlich mit Google Scholar finden, die anderen scheinen mir nicht zu existieren.
Und das Fazit der ersten Studie klingt bei den Autoren auch anders, als in der von ChatGPT erzeugten Zusammenfassung: “Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.”
Ah ja sehr gut! Ich habe danach auch noch n bisschen nachgegoogelt und wollte das Kommentar erst editieren aber dachte dann, mal schauen wie investiert du bist 🙂 Ich finde meine persönlichen 4 Beispiele auch viel treffender und mich wird man nicht mehr überzeugen, dass CamelCase lesbarer ist als snake_case. Zu meinen Beispielen hast du ja leider nix gesagt.
Hier mal noch echte Studien:
difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style. The interaction of Experience with Style indicates that novices benefit twice as much with respect to time, with the underscore style. https://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
In den Quellen von Beiden finden sich noch viele weitere Papers. Am Ende sagen fast alle, wenn man sich an das eine oder andere gewöhnt hat, dann performt man schlechter mit dem anderen Style. Es gibt unterschiedliche Disziplinen in denen CamelCase oder snake_case besser performt. Correctness vs. Comprehension z.B.
Zum Abschluss vielleicht noch dieser knackige Blogpost: https://whatheco.de/2013/02/16/camelcase-vs-underscores-revisited/
Also ich habe gar nicht das Bedürfnis, dich oder jemand anderen von einem bestimmten Format für Identifier zu überzeugen 🙂 Ich bin übrigens auch gar nicht derjenige, der das Thema hier in den Kommentaren aufgebracht hat. Ich bin ursprünglich eigentlich nur hier aufgeschlagen, weil ich meinen Kommentar zu nichtperiodischen Parkettierungen loswerden wollte.
Persönlich bin ich im Alltag dauernd sowohl camelCase als auch snake_case ausgesetzt, aber habe da bisher noch keine starke Meinung in die eine oder andere Richtung entwickelt. Entsprechend hatte ich bisher auch wenig Interesse an einer solchen Diskssion.
Eine mit ChatGPT generierte Liste an wissenschaftlichen Quellenangaben hat dann allerdings doch meine Neugier getriggert, und so habe mich auf diese Suche begeben. Entschuldige also bitte, dass ich lediglich auf diesen einen Aspekt in deiner sehr ausführlichen Antwort auf die Frage einer anderen Person eingegangen bin.
Aber hey, tatsächlich ist mein neu erwecktes Interesse noch nicht ganz befriedigt, daher werde ich mir möglicherweise demnächst auch noch mal ein paar der Studien aus beiden Lagern anschauen um etwas über deren Versuchsaufbauten, Methodiken und die gefundenen Effektstärken zu lernen. (So wie ich mich kenne, kann es aber auch sein, dass es dazu doch nicht mehr kommt, weil ich bis dahin schon wieder das Interesse verloren habe oder in ein anderes Rabbit Hole gefallen bin.)
All good 🙂 Also ich finde es auch nicht so ein heißes Thema. Programmiersprachen kann man nach eigenem Geschmack aussuchen und trotzdem muss man machmal APIs benutzen, die nicht nach dem eigenen Geschmack sind. Also muss man sich eh mit Beidem Abfinden 🙂
Zum Thema nicht nichtperiodische Parkettierungen:
Letty hat ja gesagt, dass sie etwas haben wollte, was mit möglichst wenigen Figuren auskommt. Da musste ich sofort an letztes Jahr denken, als bei den Parkettierungs-Nerds weltweit Aufregung und Freude groß waren, weil nach 60 Jahren endlich der erste echte “Einstein” entdeckt wurde — der “Hut” — und dieser auch noch eine verblüffend einfache Form besitzt:
* https://aperiodical.com/2023/03/an-aperiodic-monotile-exists/
* https://en.wikipedia.org/wiki/Einstein_problem#The_hat
Es genügt also also eine einzige Figur!
Den Hut habe ich auch gesehen! Und weiß überhaupt nicht, warum ich ihn wieder verworfen hatte.. hm, vlt weil Kite und Dart “einfacher” aussehen. Ich werd den auf jeden Fall mit in die Liste aufnehmen 😀
(Schon wieder zwei Wochen rum… ? Wenn man nicht sofort, gleich kommentiert…)
Zum Thema Mikrofon (für Letty) empfehle ich euch bei dem Youtube-Kanal „DIY Perks“ reinzuschauen. Dort gibt es viele interessante Bastelprojekte um Technikequipment und diverses Zeugs. Also das Video für den Augenblick ist: „Building a quality USB-C microphone“ – https://www.youtube.com/watch?v=LoQu3XXIayc – für unter 100 Euro. Am Ende Vergleicht Matt, der viel zu gut aussehend für so’n Bastelolm ist, sein Mikrofon mit einem »Neumann U87 AI«-Mikrofon für round about 3.000 USD — kein Unterschied!
So, jetzt ziehe ich mir nochmal Alexander Marcus auf dem Parookaville 2024 rein. Prost! „Reißverschluss klemmt, Innenfutter eingeklemmt… Woo-Wooo! Woohoohoo! Elektriker!“
Zum Thema TailwindCSS und WordPress.
Letty, du kannst WordPress-Elemente und ihre Klassen mit TailwindCSS über das `@apply`-Attribut in deinem CSS stylen. Technisch gesehen erlaubt dir `@apply`, TailwindCSS Utility-Klassen in benutzerdefinierte CSS-Regeln einzubinden.
Beispiel: Wenn du ein WordPress-Element mit einer bestimmten Klasse hast, kannst du diese Klasse im CSS so erweitern:
“`css
.custom-button {
@apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
}
“`
In diesem Beispiel wendest du die Tailwind-Utilities `bg-blue-500`, `text-white`, `font-bold`, `py-2`, `px-4` und `rounded` auf die Klasse `.custom-button` an.
Beim Build-Prozess (z.B. durch Webpack, Vite, oder den Tailwind-JIT-Compiler) ersetzt Tailwind die @apply-Anweisungen durch die tatsächlichen CSS-Regeln der angegebenen Utility-Klassen.