This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Bruker dere begrepene “release”, “deploy” og “code review” når dere snakker med nordmenn, eller har dere norske oversettelser dere foretrekker?
Att döma av den här kanalen och artiklar jag hittat visa den är ni “bättre” en svenskar på att hålla er till ert modersmål. Men kodgranskning är ett ord som de flesta använder i alla fall.
Jeg liker "prodsetting" for deploy. Vi snakker også ofte om "bygget". Vi har bare ett bygg som går rett i prod, så det er underforstått at det handler om release/deploy.
Vi praktiserer forøvrig parprogrammering, og slipper å finne på noe for "code review" 😁
1Når det er nødvendig så ber jeg Magnar om "å se over dette", eventuelt "gå gjennom noe kode med meg".
Spennende, jeg hadde inntrykk av at det var noe sånt dere gjorde. Er “prodsette” for deg at koden er i produksjon, uten at den nødvendigvis kjører? --- Teamet jeg jobber i nå holder på å endre seg i retning av hyppigere merge til master. Tidligere: alle jobber med forskjellige ting, all kode skal ha code review i PR før merge og prodsetting, men lite delt innsikt i hverandres kode gjør det vanskelig med code review (kodegranskning). Etter min smak brancher som lever for lenge. Nå: Har startet med mye parprogrammering / ensemble-programmering. “Få ny kode på master uten å brekke ting” har vært vanskelig, fordi det ikke har vært noe opplegg for å prodsette kode uten å kjøre den nye koden (feature-flagg). En utfordring har vært å gi folk på teamet som er vandt til å kode selv lenge, lage PR og så gå i prod trygghet og oversikt. Trygghet: tidligere har de visst at noen andre kommer til å lese koden før den “kommer inn”. Oversikt: tidligere har PR-er blitt brukt til å holde oversikt over hva vi driver med. Hvis en feature skal lages i mange PR-er, må man tenke annerledes for å vite hvilken PR som hører hjemme i hvilken feature.
> Er “prodsette” for deg at koden er i produksjon, uten at den nødvendigvis kjører? Jepp. Vi har ikke noe system for toggling, men det hender at det går ut kode som fungerer, men ikke er fullstendig - og heller ikke er “kobla på“. Men stort sett går det ut ting som kjører.
Hvor stort er teamet @U3X7174KS?
Før jul var det 3 personer. Jeg og en til kom med tidlig i januar. Fredag fikk vi enda en, så nå er vi 6.
Det er et mysterie for meg at selv så små team som 3 pers velger seg såppass byråkratisk samarbeidsform
Ja, enig. Men tidligere har man gitt de tre personene helt forskjellige ting å gjøre, og spurt hver enkelt om estimater på hva de selv kan få til. Så jeg skjønner at det har blitt litt vanskelig å få til godt samarbeid. Siden jul har vi fått fokusert mer på samme ting, og da er det lettere å argumentere for feks parprogrammering. (både lettere å argumentere til andre utviklere, til prosjektleder, og til andre i organisasjonen)
Interessant nok så blir code reviews nesten enda mer håpløst i en sånn setting, for man får veldig liten kjennskap til hverandres hjørne av kodebasen, med mindre man setter av godt med tid til å motvirke det (noe de aller færreste gjør).
Det stemmer ganske bra i vårt tilfelle også 🙂 Et grep som har gjort det litt bedre er at den som har skrevet koden nå tar stilling til hva personen ønsker review på. Er personen trygg på det personen har gjort og vil gå videre? Eller er det noe som var vanskelig og potensielt kan gjøres bedre?
Tror jeg bruker det for litt større greier - første prodsetting av nytt system, stor feature osv
Jag har sällan någon användning för ordet deploy. För mig är det sista steget när en ny version släpps. Så om jag behöver referera till det blir det något typ “installera”.
Ungefär: > Nu ska vi släppa ut ny version (Now we are releasing a new version). För att göra det behöver vi bygga saker och installera dem (To do that we need to build things and deploy them).
Ordet release blir på svenska översatt till olika saker beroende sammanhang. Dels är det det övergripande begreppet för att göra och släppa en ny version. Men det kan också vara att lansera något. En ny funktion, en ny produkt.
I ett större sammanhang kan släppet av en release ses som en installation (deploy), antar jag.
Jeg er så vant til at release og deploy er det samme at jeg tenkte ikke engang på at det kan være separate ting 🙈
Jag tror inte att de är så skilda begrepp för de flesta engelsktalande heller. Men det beror på vad man har för processer. Man kan t ex tänka sig att i stort sett all kod utvecklas och på, och släpps från stammen, kanske bakom flaggor. Sedan är det produkt-/marknadsfolk som bestämmer vad som utgör en release. De gör marknadsföringsmaterial och slår på flaggor för en produkt som rimlar. Då blir det för varje funktion en deploy när den tas in på stammen (commit) och ytterligare en deploy varje gång en flagga gör att den når flera användare. Man kan också se det som händer när marknadsavdelningen släpper ut sin konfiguration av flaggorna och materialet (releasen) som en deploy.
@magnars, er det https://docs.datomic.com/pro/getting-started/dev-setup.html du tidligere nevnte at du kjører i produksjon uten problemer, selv om det ikke er anbefalt av Datomic? Jeg mener å huske du nevnte noe sånt en gang (kan det ha vært i sammenheng med Adventur Delux?), men er usikker på om jeg husker feil.
Stemmer. Det som ikke er anbefalt i prod er å kjøre datomic:dev:// protokollen - den lagrer en h2-database på disk.
Nå som pro er gratis er SQLite et fint alternativ. dev-protokollen er dog det raskeste å komme igang med, og du kan bytte senere.
Jeg kjørte Datomic Free på Adventur frem til nå i jula. Den er gammel som haugene. Kjører nå Datomic Pro med sqlite. Fungerer helt supert.
Er det noen spesielle grunner til at dere velger SQLite fremfor PostgreSQL eller andre alternativer? :thinking_face: Foruten PostgreSQL har jeg mest erfaring med "enterprise" greier fra Oracle og Microsoft. Og analytiske databaser som Snowflake og BigQuery.
Datomic bruker disse bare som et filsystem for å skrive data. SQLite er lett å kjøre, for det er en enkelt prosess mot en fil. I tillegg er den optimalisert for én skriveprosess og mange leseprosesser, akkurat som Datomic, og passer dermed godt.
Om du allerede har Postgres oppe og går er det helt fint, men jeg hadde ikke giddet å kjøre opp postgres i ens ærend hvis jeg slapp unna med SQLite.
At folk betaler for Oracle og MS SQL Server i en verden med SÅ mange gode og gratis alternativer er helt uforståelig for meg.
Det gir mening, ja! PostgreSQL er ganske rask og har en del kule/unike features, men de skal vel sjeldent eller aldri brukes her.
De er irrelevante for Datomic sin del. Den trenger bare et trygt sted å persistere data.
Oracle og MS SQL Server handler mest om 27/4 support, SLA-er og garantier/forsikringer tror jeg, ikke selve databasen så mye. Men hvis de har nedetid utover avtalen så kan man få dekket tapet sitt, etc. Også får man dedikerte kontaktpersoner og utviklere som kan hjelpe med ting. For noen store bedrifter er det en relativt billig forsikring, selv om det koster et par mill i året.
Nærmeste jeg kommer er å ha vært utfor en bug i JVM-en, som atpåtil var fiksa da jeg oppdaget den
Jepp! Jeg vil ikke si jeg synes det er en god idé 😅 Og jeg har prøvd å foreslå å spare en del penger der før. Men forretningsfolk uten teknisk peiling, som ikke stoler på utviklerne de har ansatt, må betale "moron tax" for å føle seg bra, hehe
snakket med en i logistikkbransjen nylig som er oppgitt over at ingenting har blitt bedre i de 20 årene han har jobbet i bransjen, og at alle systemer er noe selgere selger til ledere, uten å innvolvere faktiske brukere og fagfolk
Retail lider av det samme. De fleste retail organisasjoner er drevet av forretningsfolk som ikke er tekniske på noen måte. Problemet er at disse typene ofte har for mye selvtillit og for lite selvinnsikt til å forstå sine egne begrensninger og søke råd fra fagfolk. Istedenfor å stole på tekniske ansatte bruker de masse penger på kjøpte systemer og konsulenter. "Dette koster mye, så det er sikkert bra!"
@magnars / @U9MKYDN4Q Korleis ser ein JDBC sqlite Datomic connection string ut? Eksempel? Trengst det å endrast på transactor classpath? Reknar med at ein køyrer ein standalone transactor?
@UGJE0MM0W Her fra Adventur:
"datomic:" Fra transactor.properties:
sql-url=jdbc:sqlite:/data/datomic-sqlite.db
sql-driver-class=org.sqlite.JDBCMange takk 👍
Aha - så dei må dela disk? Det gjev vel meining det ja
Nice, takk for eksemplene, @magnars! Det jeg sliter mest med er at det er så mange valg man må ta stilling til for å komme i gang. Det gjør jo Datmoic mer fleksibelt når de store brikkene er adskilte, så jeg forstår hvorfor det er sånn.
Mye å sette seg inn i ja. Det aller nest letteste er å sette opp med dev-protokollen på én maskin og jobbe mot disk. Lær deg å jobbe med systemet, og finn ut av de andre tingene når du skal i prod 🙂 (Det aller enkleste kommer under denne)
Ja, eller avhengig av dine behov så kan du jo også bare begynne med en in-mem database.
Right, så typ: 1. In-memory 2. Disk 3. SQLite Lokalt på egen maskin. Og ikke tenke på deployment av kompoenter til andre maskinger før det er nødvendig.
Kanskje jeg skal ta meg tid til å skrive en liten "How to Approach Learning Datomic" guide når jeg graver her.
da det er sagt er det ikke akkurat superkomplisert å bruker docker compose til å fyre opp postgres og la datomic snakke med den lokalt, hvis det ender opp med å være prod-oppsettet. Men, det vil også være nøyaktig 100% likt med sqlite/dev/memory lokalt og postgres i prod, siden database/storage bare lagrer ugjennomsiktige komprimerte blobber med EDN i et key/value-oppsett. Så det gjør ikke noe å ha ulike oppsett dev og prod
Datomic: databasen for de som vil kjøre join-spørringer mellom DynamoDB, Oracle og Excel-regneark
Og valget mellom "Datomic Pro" og "Datomic Peer" download. Det er lite info på siden som forteller hvorfor man vil ha den ene eller den andre.
"Hva om Datomic lignet litt mer på alle andre databaser, og tapte mesteparten av sine fordeler i samme slengen?"
@U01PE7630AC Enig i at det er litt villedende, men jeg vil gjette på at det handler om betalt support vs ingen support
ser på client som en nødvendig onde om du på død og liv skal gjøre spørringer i serverless/lambda og andre kortlevende prosesser
Jeg har brukt Datomic client fra både Java og JavaScript. Da blir Datomic et mye vanskeligere innsalg, for det er rimelig upraktiske greier.
men ja, peer til prosessen din:
[com.datomic/peer "1.0.7021"]Så hvis jeg vil gjøre in-mem lokalt på min egen maskin så trenger jeg kun en dep i min deps.edn? Ikke noe download.
noen må ha working set av dataene i RAM, peer lar deg ha det i appen din, og det er helt 💥 😻
Det er jo egentlig helt sykt fett da! Hvis man kun trenger ephemeral state for brukersesjoner.
eventuelt at paradigmer som er totalt annerledes fra alt annet og løser problemer folk ikke vet de har er noe av det vanskeligste å markedsføre
> det vil også være nøyaktig 100% likt med sqlite/dev/memory lokalt og postgres i prod Mja, når data vert sendt over nettverket (som ikkje skjer med in-memory), så får du (litt) andre typer på dataa om du har databasefunksjoner. Datoms returnert vert også returnert som ein vektor i in-mem, men som ei liste (`java.util.Arrays$ArrayList`) over nettverket.
En av tingene jeg elsket med Erlang/OTP (og Elixir) var tilgangen til https://www.erlang.org/doc/man/ets.html, https://www.erlang.org/doc/man/dets og https://www.erlang.org/doc/man/mnesia.html. Det er persistence innebygget i selve språket/standardbiblioteket uten at man må tenke på noe som helst. Det gjorde det sykt enkelt å spare på ting om det så var i minne, på disk eller i en database. Jeg håper litt på at jeg kan tenke på Datomic som det samme for Clojure.