oscarnylander - 2017-11-27 08:29 01s
Lisp implementerat på färre än 200 rader C: https://carld.github.io/2017/06/20/lisp-in-less-than-200-lines-of-c.html
johanhazelius - 2017-11-27 08:31 23s
Snyggt😁
daniel.winther - 2017-11-27 08:32 47s
Oj herregud
oscarnylander - 2017-11-27 08:33 21s
Lisp är ett förvånansvärt simpelt språk att implementera 🙂
daniel.winther - 2017-11-27 08:33 41s
Ja uppenbarligen 😄
erik.malm - 2017-11-27 17:18 49s
Har de löst problemet med att lisp är nittio procent parenteser?
daniel.winther - 2017-11-27 18:00 17s
😂
jenspeterolsson - 2017-11-28 08:01 30s
Någon mer än jag som höll på med amos? Faktum är att jag på fullt allvar tycker att http://vb.net|vb.net är/var minst lika bra som c# men eftersom ingen förstår det så… https://sourceforge.net/projects/xamos/
XAMOS
daniel.winther - 2017-11-28 08:07 58s
Aldrig hört talas om. Men kul att du nämner vb 😊 själv tyckte jag inte .net varianten var jättekul utan i den vevan gick jag över till c#. Däremot var det visual basic som på allvar fick mig att programmera. Från vb3 till vb6, underbar tid! Nånstans där innan har jag nåt minne av qbasic i dos. Sen börjar minnena tona ut, man börjar ju bli till åren nu… @jenspeterolsson du måste ju ha suttit med vb också innan .net?
jenspeterolsson - 2017-11-28 08:26 00s
@daniel.winther Nope. Amos var på Amiga, och sedan jobbade jag med c++, powerbuilder (!) och bash script mest innan c#. Men på IKEA satt jag under flera års tid med http://vb.net|vb.net och gillar tydligheten i syntaxen. Lite som Python…
erik.malm - 2017-11-28 20:37 18s
AMOS var nåt vi Atari ST ägare bara suktade efter. Köpte och läste Amiga/Commodore tidningar med AMOS tutorials och C64 program som man skrev in själv. Massor av Poke <Slumpmässig siffra här> statements i rad. Jag hade ingen C64 heller.
jenspeterolsson - 2017-11-28 20:48 35s
Fail hela vägen alltså @erik.malm Och se hur långt du har kommit ändå 😬
erik.malm - 2017-11-28 20:55 17s
Klar fail hela vägen, men det är kanske ett tecken om man tycker “Poke” listor i tryck är sjukt bra läsning.
jenspeterolsson - 2017-11-28 21:20 36s
Ha ha min lillebrors kompis sa senast jag träffade honom hur sjukt imponerade de var på den tiden av alla som programmerade ”på riktigt” och inte bara skrev av kodlistningar från datormagazine Men Amiga, c64 och st var helt klart bra skolor Och inte minst datormagazine
daniel.winther - 2017-11-28 21:22 34s
Datormagazine var grym!
erik.malm - 2017-11-29 05:37 15s
Någon med en Mac och High Sierra som har lust att testa? Tydligen ska man kunna logga in som root utan lösen, bara man trycker på unlock knappen flera gånger. https://twitter.com/lemiorhan/status/935578694541770752
daniel.winther - 2017-11-29 06:04 47s
Har bara sierra än så länge Men ganska kul diskussion att läsa 😂
daniel.winther - 2017-11-29 08:42 29s
Apropå kortfattad diskussion vi hade om graphql på senaste Etimo challenge, vad sägs om att prova detta i photo garden för apiet mot klienten. På så vis kanske vi kan lägga en bättre grund för flera typer av klienter på sikt. Tror det kan va intressant att lära sig mer om det.
GraphQL: A query language for APIs.
https://github.com/graphql/graphiql
graphql/graphiql
jenspeterolsson - 2017-11-29 09:19 08s
Kanske inte introducera både graphql och elastic search samtidigt? Jag är personligen inte så inne på graphql men om flera andra tycker det vore kul har jag inget emot att lära mig det.
daniel.winther - 2017-11-29 09:35 24s
Kanske blir överflödigt men jag tänkte nog inte att vi jobbar direkt mot elastic search från frontend utan att vi går via ett api, därav möjligheten.
jenspeterolsson - 2017-11-29 09:54 35s
Graphql har inte lagring utan är bara ett queryspråk som jag fattat det? D.v.s. det behövs api emellan både för graphql och elastic?
daniel.winther - 2017-11-29 09:55 08s
Graphql är ju en tolk av input till Query mot källa
jenspeterolsson - 2017-11-29 09:55 28s
Men kortsiktigt behöver vi ju främst läsa json och möjligtvis skriva enkel json så alternativet till graphql är väl snarare mongo/postgres etc. Elastic kommer nog in senare i utvecklingen när vi har mer data och fler sökfunktioner Sedan är det ingen nackdel att man är lite advokat för ett eget teknikval och tar lite större ansvar för att få det på plats @daniel.winther Så om du tar på dig ledarhatten för graphql är det ju ett plus 😉 Lite som oscar med docker t.ex.
oscarnylander - 2017-11-29 09:59 36s
GraphQL är klart intressant, vet inte om jag tolkat projektet helt men är det som jag tror det är kan man nog spara en hel del utevecklingstid på att använda det
daniel.winther - 2017-11-29 09:59 48s
@jenspeterolsson Absolut men vill helst inte propsa på nåt om ingen annan är intresserad 😄 Bra då är vi 2 @oscarnylander!
daniel.winther - 2017-11-29 10:15 04s
Men som du säger @oscarnylander så har vi kanske inte alla detaljer på plats exakt hur allt ska funka, och antagligen inte samma bild allihopa. Jag tror också, i min vision, att det kan spara tid på sikt men samtidigt kommer det nog ta längre tid att implementera initialt.
oscarnylander - 2017-11-29 10:19 59s
Det ända jag varit skeptisk till är licensen, men den kanske ändrades i samband med React-ändringen?
daniel.winther - 2017-11-29 11:26 14s
Har inte kollat, ska undersöka
johanhazelius - 2017-11-29 11:43 14s
Appropå att alla kanske inte har samma bild av vad photo.garden ska bli - jag kommer ansvara för att ta fram produktvisionen. Som vanligt utformar Vi den gemensamt men jag kommer hålla i pennan och ansvara för att vi faktiskt dokumenterar visionen så vi säkrar att vi alla har samma bild av slutmålet. Draft kommer innan nästa challange
oscarnylander - 2017-11-29 11:43 33s
Låter bra!
jenspeterolsson - 2017-11-29 13:02 23s
Jag tänker att kopplat till produktvisionen så arbetar vi med milestones i Github i form av features (inte releaser, vilket jag vid närmare eftertanke tror är fel väg att gå). T.ex. för feature “Display photos from Google Drive” så ingår det ett antal issues i Github som att koppla mot Googles API, kanske transformera Googles format till ett standardformat vi vill arbeta med, visa i front-end m.m. Våra fyra första features skulle då kunna vara:
- Display photos from Google Drive
- Continuous Delivery (docker, appar, server, deploy etc.)
- Feature flags (så att vi kan deploya kontinuerligt trots att en feature inte är klar)
- Search on metadata (date and place) from photos Verkar det vettigt?
johanhazelius - 2017-11-29 13:24 46s
Tycker det låter vettigt @jenspeterolsson
daniel.winther - 2017-11-29 15:20 44s
Låter som en bra start!
jenspeterolsson - 2017-11-29 17:43 01s
Har flyttat markdown om produkt som vi uppdaterade senaste Etimo challenge till github istället (kan då öppnas direkt i browser), ligger här: https://github.com/Etimo/photo-garden/blob/master/Product%20draft.md
Etimo/photo-garden
daniel.winther - 2017-12-01 13:04 41s
Exempel på annorlunda dataanalys: https://techworld.idg.se/2.2524/1.693637/kent-deppigaste-laten
Vilken Kent-låt är deppigast? Nu finns det dataanalys på det.
erik.malm - 2017-12-01 13:37 19s
Den lär vara från “La Belle Epoque” albumet annars är det fel på analysen. Har spenderat mycket tid med R under min doktorandtid men måste erkänna att jag aldrig såg den här möjligheten.
jenspeterolsson - 2017-12-01 13:44 41s
Jag som gillar Kent åtminstone fram till ca 2002 läste artikeln och deppigaste låten var från Hagnesta Hill Sedan sätter jag frågetecken för hur man kan göra en objektiv analys i frågan 😉