Fredrik får besök av Andreas Ekeroot som diskuterar det whiteboardvänliga språket Haskell. Och monader, förstås, i poddens första försök att förklara monader som amöbor.

Dessutom ett exjobb om att generera program.

Vi reder också ut vem som är äldst av Andreas, Haskell, och Erlang. Samt varför det kan vara ett bra motto att undvika framgång till varje pris.

Lite exempelkod:

sumAllNumbers :: String -> Int

sumAllNumbers str = sum (map read (lines str))

main :: IO ()

main = do

fileContent <- readFile “magiska_tal.txt”

print (sumAllNumbers fileContent)

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Andreas Ekeroot
• Tidigare avsnitt med Andreas
• Haskell
• Regular programming - “den andra podden”
• Quickcheck
• Cakeml - kompilatorn och språket
• Compcert
• Intermediärrepresentation
• LLVM och dess IR
• Erlang
• Elixir
• Property based testing diskuteras också i bland annat avsnitt 386
• Regular programming om när Andreas blev av med jobbet
• The hobbit/Bilbo
• Bilbo illustrerad av Tove Jansson
• Stöd oss på Ko-fi!
• Lat utvärderande programmeringsspråk
• Davidstatyn
• Clean - inspirerade Haskell
• Miranda - inspirerade Haskell
• Ocaml
• Jane street
• F#
• LINQ
• GHC
• Typer i Haskell
• Hindley Milner-typsystem
• Koen Claessen - holländare som introducerade Haskell för Andreas på Chalmers
• Kenneth E. Iverson
• Notation as a tool of thought
• APL
• Game of life i APL
• Simon Marlow
• Set theoretic types - konceptet Elixirs nya typsystem bygger på
• Avoid success at all costs
• Escape from the ivory tower - the Haskell journey, presentation av Simon Peyton Jones
• Freebsd
• Elm
• Evan - skapare av Elm
• Donald Knuth
• Monader
• Saša Jurić - the soul of Erlang - föreläsning där trådar ligger och kraschar utan att störa något annat
• Phil Wadler
• Kategoriteori
• Turingkompletthet
• Dhall - icke-turingkomplett konfigurationsspråk
• YAML
• Magic är turingkomplett
• JSON
• INI-filer
• Chef
• Puppet
• Dal - linsgrytan
• Planescape: torment
• Monader som burritos
• Burritos är monader

Titlar

• Det vi hade tänkt prata om förra gången
• Allt utom Haskell
• Notoriskt svårt att generera program
• Bevis är inte riktigt min grej
• Science was made
• Erlang har det för att de är tjuriga
• Den heta kusinen till Erlang
• Tove Janssonskt
• Det är länge sedan nuförtiden
• Lata funktionella programmeringsspråk
• IO är liksom inte en grej
• Formen i stenen
• Tillbaka till marmorblock
• Den strikta kusinen
• “Ska bara”-språk
• Ordning och reda med typer
• Som AI fast bättre
• Ett sunt system
• Smidigt att skriva på whiteboard
• Haskells märkliga lillebror
• Ta någonting och sluka det
• Plocka ut grejen ur monaden

Fredrik får besök av Daniel Nilsson som berättar om hur han och Hogia jobbar med att ta in nyanställda och LIA-studenter.

Daniels viktigaste tips: ta med de nya som vanliga medlemmar i teamet på de vanliga arbetsuppgifterna.

Fördelar med att vara produktbolag snarare än konsultbolag. Låt LIA ta tid, det ger mest för alla då.

Daniel berättar också hur man intervjuar och tar in nyutexaminerade, med en månads introduktion där man lär sig hela Hogias stack och bygga en applikation i stacken. Skillnaden mot LIA är egentligen att man får en större introduktion till företaget som helhet, medan LIA kanske handlar mer om att komma in i ett team.

Konsultbolag är fegare med att ta in studenter och nya än vad de borde vara?

Stereotypen om utvecklare stämmer inte längre - det handlar mycket mer om kommunikation idag.

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Daniel Nilsson
• Tidigare avsnitt med Daniel
• Hogia
• På meetupen spelades också snacket med Woody Zuill in
• LIA - lärande i arbete
• Mobbande - mobbprogrammering, ett arbetssätt i grupp som används ganska mycket på Hogia
• Parprogrammering
• Stöd oss på Ko-fi!
• VB6 - en klassisk version av Microsofts Visual basic
• Nösnäs teknikcollege

Titlar

• Vi jobbar ju så fort vi hinner
• Hyfsad korvstoppning
• Superdjupa i backend
• En liten tunn grund
• Han är på fyra bolag
• Hela poängen med LIA
• Det är okej att göra fel
• Som vem som helst i teamet
• Kravlöst
• Jag har inga förväntningar
• Det får ta tid

Fredrik snackar fallgropar och tips för att lyckas bli datadriven med Benny Andrén och Hugo Hjertén - experter på data och röster i podden Datastudion.

Problemet är inte att man behöver tjugotvå dashboards till.

Vanliga fallgropar:

• Man beställer datadrivenhet som om det var en teknisk leverans. Datadrivenhet är inte ett tekniskt projekt, man kan vara datadriven med papper och penna.
  • Distanserad ledning
  • Oklar målbild - hitta tydliga saker att göra och fokusera på konkreta problem
  • Output vs outcome - fokusera på värdet man kan och vill få ut
  • Man blir kär i processen
• Gamla högar med data har inget automatiskt värde - det kanske till och med är bättre att utgå från att den inte är det

Bra saker att göra:

• Engagera både ledning och ambassadörer i organistionen
• Se till att folk känner sig delaktiga och har mandat att agera
• Lyssna på varandra
• Det är en resa, det tar tid
• Plocka lågt hängande frukt, löpande
• Intressant räcker inte - vill man bara ha viss data för att det vore intressant, men det faktiskt inte skulle påverka några beslut, så bör det finnas nyttigare saker att fokusera på
• Demokratisera data - och gör det tydligt hur data tagits fram och vad den betyder

Data berättar aldrig varför!

Vill du höra mer om datajobb, kanske mer om de tekniska sidorna? Hör av dig, ge oss mer data för våra beslut!

Ett stort tack till Cloudnet som sponsrar vår VPS!

Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas.

Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik.

Länkar

• Benny
• Hugo
• Datastudion
• Data dao - där Benny och Hugo jobbar
• Avsnitt 594
• Första avsnittet av Datastudion
• ETL-pipeline - extract, transform load
• Qlikview
• Power BI
• A/B-testning
• Refined - förbättrar Atlassians tjänster
• Change, technically - Den andra podden där de pratade om dataanalys i avsnitt ett
• The audience is listening

Titlar

• Hur man lyckas med att bli datadriven
• Tillsammans med instinkt och magkänsla
• Optimera vardagen
• Till stor del mänskligt beteende
• Det här är inte ett tekniskt projekt
• Datadriventhethantverkaren kommer på onsdag
• Vi räknar med att vara datadrivna på torsdag
• Datamokaren kommer
• Där chefer träffas
• Patcha sin organisation
• Din oas av data
• Ett äpple i taget
• Ifrågasätt på ett bra sätt
• Vi har ju aldrig gjort det bättre
• Några dashboards för mycket
• Det här hade varit kul att veta
• En riktning till ett “varför”
• Äga sin egen data
• Gissningsapparat

Kodsnack 600 - Just use +, with Christian Clausen

2024-09-03 05:26

Ladda ner (mp3)Öppna länkar i nya flikar

Fredrik talks to Christian Clausen about the many facets of simplicity.

The cloud and serverless was supposed to be simpler than running your own hardware, but you easily get stuck trying to select the right message bus, needing to know the intricacies of your chosen cloud provider infrastructure, and the like. You end up building your software around the infrastructure you’ve ended up with - rather than picking infrastructure which is right for your software.

The CFO should not be the architect of the software.

Core values and principles - set them up, reflect on them, and notice and decide what to do when they are broken. Should the system change if its core principles are broken, or should the principles be updated to reflect reality? Christian argues simplicity should be a core principle, and very carefully considered and encouraged.

There are enough barriers already, even before you start adding complexity around the problems you’re trying to solve.

And hide the things you do pull in behind true abstractions which don’t leak all over the place.

Don’t ask what you can add, ask what you can postpone.

Generality adds complexity. The more often something changes, the more specific it should be.

Where are the tools which suggest more things to remove instead of things to add?

Thank you Cloudnet for sponsoring our VPS!

Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive.

If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi.

Links

• Christian
• Øredev 2023
• Designing infrastructure-free systems - Christians Øredev 2023 talk
• Merrymake - Christian’s company
• Five lines of code
• Nosql
• Conway - don’t let HR be the architect
• Christian’s blog
• Spring
• Quarkus - “supersonic subatomic Java”
• Reactive programming
• Hibernate
• Gateway drug
• React
• Angular
• Vue
• Google’s serverless is actually Knative
• Support us on Ko-fi!
• Redux
• Sonarqube
• Occam’s razor
• Cyclomatic complexity
• Don’t repeat yourself
• A/B testing
• Christian on Medium

Bonus links - thanks Tomas Kronvall!

• Adding two numbers in Javascript
• Some additional backstory

Titles

• Life happened
• Serverless the right way
• It’s grown a lot
• I love refactoring
• Just as hard as choosing hardware
• Everything into one collection
• I don’t want the CFO to be the architect of the software
• It disappears immediately
• Entropy for the real world
• I came back after six years
• Why though?
• Why do you have this?
• What problem couldn’t you solve without it?
• There are enough barriers already
• Just use +
• Zero of the founding principles
• But it looks like ice cream
• I’ve always hated frameworks
• I feel like I’m writing Javascript
• Was the salary worth it?
• Lending the money to your future self
• What can I postpone?
• Generalization land
• Suggest I remove things!
• Is this the right problem to have?
• I want to say no more
• Humans can build this