Självlärd programmerare, är jag redo för att söka jobb? Detaljerad GitHub bifogad

Permalänk
Medlem
Skrivet av first:

Rust verkar väldigt intressant.
Om man som jag, som dras till back end hållet och är långt mer engagerad i att interagera med hårdvara än en front end (även om det är omöjligt att slippa front enden helt), och även om man inte kan slå fast att jag är särskilt smart från det jag levererat nu så kanske det går att slå fast att jag åtminstone inte är trög...

Vore det då inte smart av mig att försöka tillskansa mig de grunder inom back end som redan tagits upp, men sedan försöka lära mig att koda i Rust, som verkar vara på frammarsch och dessutom lite jobbigt att byta till, och förutsatt att jag fixar grunderna i Rust, försöka rida på den vågen och halka in på ett bananskal på en okej junior position inom det?

Istället för att:
* Ha web apps som mitt end game, som jag ändå faktiskt inte är särskilt intresserad av.
* Längta efter att plugga Embedded, vilket ändå aldrig blir av. Med Rust skulle jag vara närmare framtidens embedded än med Java iallafall, vad jag läst mig till.

Jag är liksom den som hellre uppdaterat gamla Karolinskas patientregister från vi säger COBOL, där dokumentationen försvunnit och ingen har koll på något, till senaste snabbaste programvaran, sittandes i deras sunkiga källare anno tidigt 1900-tal och kvarlevor från djurförsök, än att bli anställd på Meta Platforms och bli involverad i deras senaste algo för att sälja annonsplatser för skräp.

Inte för att jag är kapabel till ngt av det i dagsläget, men om jag var.

C/c++ är inte på väg bort och tror inte du klarar dig på bara rust, men man måste ju börja någonstans… testa gärna rust men jag tror lägre är vägen framåt, i alla fall att kunna läsa och förstå c/c++ med pekare och minneshantering

Permalänk
Medlem
Skrivet av first:

Rust verkar väldigt intressant.
Om man som jag, som dras till back end hållet och är långt mer engagerad i att interagera med hårdvara än en front end (även om det är omöjligt att slippa front enden helt), och även om man inte kan slå fast att jag är särskilt smart från det jag levererat nu så kanske det går att slå fast att jag åtminstone inte är trög...

Vore det då inte smart av mig att försöka tillskansa mig de grunder inom back end som redan tagits upp, men sedan försöka lära mig att koda i Rust, som verkar vara på frammarsch och dessutom lite jobbigt att byta till, och förutsatt att jag fixar grunderna i Rust, försöka rida på den vågen och halka in på ett bananskal på en okej junior position inom det?

Istället för att:
* Ha web apps som mitt end game, som jag ändå faktiskt inte är särskilt intresserad av.
* Längta efter att plugga Embedded, vilket ändå aldrig blir av. Med Rust skulle jag vara närmare framtidens embedded än med Java iallafall, vad jag läst mig till.

Jag är liksom den som hellre uppdaterat gamla Karolinskas patientregister från vi säger COBOL, där dokumentationen försvunnit och ingen har koll på något, till senaste snabbaste programvaran, sittandes i deras sunkiga källare anno tidigt 1900-tal och kvarlevor från djurförsök, än att bli anställd på Meta Platforms och bli involverad i deras senaste algo för att sälja annonsplatser för skräp.

Inte för att jag är kapabel till ngt av det i dagsläget, men om jag var.

På tal om Cobol så har SEB egna utbildningar i det språket som vem som helst kan söka till. Cobol är gammalt men inget språk som kommer försvinna.

Permalänk
Medlem

Jag skulle rekommendera att gå via .NET (C#) men fokusera på Azure services, GitHub/GitHub actions, CI/CD, docker/containers.
Om du kan visa på att du kan några av dem någorlunda bra så spelar din kunskap i t.ex .NET inte så stor roll (om du har bara har är ok/nybörjare) och du har möjlighet att utveckla det mer på arbetsplatsen.
Det är brist på kompetens på allt som inte är ren utveckling men ändå ingår i dagens ansvar av en utvecklare.
Problemet är att tekniken går snabbare än utvecklingsspråken, och få utbildningar kan vara 'up-to-date'.
Kort så kan man säga att praktisk kunskap (som man kan visa) är alltid bättre än något på papper i form av utbildning.

Några länkar i (nästan) ordning ang .NET + Azure / GitHub / docker: (skippa om du redan kan)

Installera Visual Studio 2022
https://visualstudio.microsoft.com/vs/getting-started/

Bara för att komma igång med C# (online)
https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-cshar...

Skapa en websida med Blazor
https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutori...
Några olika exempel med Blazor (4.5h trainings)
https://learn.microsoft.com/en-us/training/paths/build-web-ap...
All info om Blazor:
https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=as...

Skapa ett konto hos Azure för gratis hosting av din Blazor app med mera.
https://azure.microsoft.com/en-us/free/

Skapa en gratis (12 månader) MSSQL databas
https://learn.microsoft.com/en-us/azure/azure-sql/database/fr...

Lägg till Entity Framework som ORM för en databas.
https://learn.microsoft.com/en-us/aspnet/core/blazor/blazor-s...

Skaffa en gratis variant av Azure DevOps för CI/CD. (enkelt sagt bygg och deployment)
https://azure.microsoft.com/en-us/pricing/details/devops/azur...

Skaffa en gratis GitHub konto (alternativ till ha allt på Azure DevOps)
https://github.com/join

Om du valde GitHub, titta på GitHub Actions för att deploya till Azure.
https://docs.github.com/en/actions/learn-github-actions
eller
https://learn.microsoft.com/en-us/azure/app-service/deploy-gi...
eller
https://chrissainty.com/building-blazor-apps-using-azure-pipe...

Hosta websidan via Azure Web Apps via DevOps.
https://learn.microsoft.com/en-us/azure/static-web-apps/deplo...

Lägg till Azure AD (login => authentication/authorization) via Azure AD.
https://learn.microsoft.com/en-us/aspnet/core/blazor/security...

Info om att installera docker lokalt
https://docs.docker.com/desktop/install/windows-install/

Kör din web app inom en container
https://learn.microsoft.com/en-us/dotnet/core/docker/build-co...

Lite om att använda docker/containers i Azure
https://learn.microsoft.com/en-us/dotnet/core/docker/introduc...

Permalänk
Medlem
Skrivet av zoomster2:

Jag skulle rekommendera att gå via .NET (C#) men fokusera på Azure services, GitHub/GitHub actions, CI/CD, docker/containers.
Om du kan visa på att du kan några av dem någorlunda bra så spelar din kunskap i t.ex .NET inte så stor roll (om du har bara har är ok/nybörjare) och du har möjlighet att utveckla det mer på arbetsplatsen.
Det är brist på kompetens på allt som inte är ren utveckling men ändå ingår i dagens ansvar av en utvecklare.
Problemet är att tekniken går snabbare än utvecklingsspråken, och få utbildningar kan vara 'up-to-date'.
Kort så kan man säga att praktisk kunskap (som man kan visa) är alltid bättre än något på papper i form av utbildning.

Några länkar i (nästan) ordning ang .NET + Azure / GitHub / docker: (skippa om du redan kan)

Installera Visual Studio 2022
https://visualstudio.microsoft.com/vs/getting-started/

Bara för att komma igång med C# (online)
https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-cshar...

Skapa en websida med Blazor
https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutori...
Några olika exempel med Blazor (4.5h trainings)
https://learn.microsoft.com/en-us/training/paths/build-web-ap...
All info om Blazor:
https://learn.microsoft.com/en-us/aspnet/core/blazor/?view=as...

Skapa ett konto hos Azure för gratis hosting av din Blazor app med mera.
https://azure.microsoft.com/en-us/free/

Skapa en gratis (12 månader) MSSQL databas
https://learn.microsoft.com/en-us/azure/azure-sql/database/fr...

Lägg till Entity Framework som ORM för en databas.
https://learn.microsoft.com/en-us/aspnet/core/blazor/blazor-s...

Skaffa en gratis variant av Azure DevOps för CI/CD. (enkelt sagt bygg och deployment)
https://azure.microsoft.com/en-us/pricing/details/devops/azur...

Skaffa en gratis GitHub konto (alternativ till ha allt på Azure DevOps)
https://github.com/join

Om du valde GitHub, titta på GitHub Actions för att deploya till Azure.
https://docs.github.com/en/actions/learn-github-actions
eller
https://learn.microsoft.com/en-us/azure/app-service/deploy-gi...
eller
https://chrissainty.com/building-blazor-apps-using-azure-pipe...

Hosta websidan via Azure Web Apps via DevOps.
https://learn.microsoft.com/en-us/azure/static-web-apps/deplo...

Lägg till Azure AD (login => authentication/authorization) via Azure AD.
https://learn.microsoft.com/en-us/aspnet/core/blazor/security...

Info om att installera docker lokalt
https://docs.docker.com/desktop/install/windows-install/

Kör din web app inom en container
https://learn.microsoft.com/en-us/dotnet/core/docker/build-co...

Lite om att använda docker/containers i Azure
https://learn.microsoft.com/en-us/dotnet/core/docker/introduc...

Inte helt dumt, men finns fler alternativ så som java + spring boot (speciellt eftersom det är språk han redan kan till viss del)

Permalänk
Medlem

Har suttit idag och fått in testing i Online Surgeon, inte på allt men en del. Det var några timmars bökande med att få spring och hibernate att sparka igång databasen så som görs i normala fall. Till slut så.

Nu har jag läst lite om den typ av test jag lagt in och det verkar snarare vara integration test och inte unit test, eftersom jag gick direkt på att testa en färdig end point och inte den underliggande metoden. Men i mitt fall är dem så snarlika varandra att det kanske inte spelar någon roll. Jag har ju bara metoder som anropar databasen i princip, menlöst att inte testa end pointsen direkt då. Eller så är det ett unit test trots allt, jag kanske förstått fel.

När jag fått in tests på alla metoder så ska jag sätta mig och fatta vad det är jag gjort också, just nu är det mest Google och skriva in och se om det fungerar.

Permalänk
Medlem
Skrivet av first:

Har suttit idag och fått in testing i Online Surgeon, inte på allt men en del. Det var några timmars bökande med att få spring och hibernate att sparka igång databasen så som görs i normala fall. Till slut så.

Nu har jag läst lite om den typ av test jag lagt in och det verkar snarare vara integration test och inte unit test, eftersom jag gick direkt på att testa en färdig end point och inte den underliggande metoden. Men i mitt fall är dem så snarlika varandra att det kanske inte spelar någon roll. Jag har ju bara metoder som anropar databasen i princip, menlöst att inte testa end pointsen direkt då. Eller så är det ett unit test trots allt, jag kanske förstått fel.

När jag fått in tests på alla metoder så ska jag sätta mig och fatta vad det är jag gjort också, just nu är det mest Google och skriva in och se om det fungerar.

Integrationstester är i min mening viktigare, de är stabilare mot underliggande refaktorering och andra kodändringar, ska allt unittestas kan man ofta få mycket dubbelarbete. Känns som ett bra och rimligt val i det här sammanhanget

Permalänk
Medlem
Skrivet av medbor:

Integrationstester är i min mening viktigare, de är stabilare mot underliggande refaktorering och andra kodändringar, ska allt unittestas kan man ofta få mycket dubbelarbete. Känns som ett bra och rimligt val i det här sammanhanget

Ok! Men låt säga att projektet var större och det fanns en drös med vanliga unit tests att göra. Ligger det fortfarande på enskild programmerare att göra integration tests? Jag läste att det ofta var särskilda test grupper som gjorde det.

Å andra sidan lär det knappast skada att göra det nu ändå för att visa att jag vet vad det är.

Permalänk
Medlem
Skrivet av first:

Ok! Men låt säga att projektet var större och det fanns en drös med vanliga unit tests att göra. Ligger det fortfarande på enskild programmerare att göra integration tests? Jag läste att det ofta var särskilda test grupper som gjorde det.

Å andra sidan lär det knappast skada att göra det nu ändå för att visa att jag vet vad det är.

Det beror helt på projektet

Oftast gör programmerare tester som greppar större features, sen brukar testare/qa automatisera och göra större svep som ui-tester som går igenom hela appar och försöker få så många funktioner som möjligt att köras och testas så ofta som möjligt

Permalänk
Medlem
Skrivet av first:

Ok! Men låt säga att projektet var större och det fanns en drös med vanliga unit tests att göra. Ligger det fortfarande på enskild programmerare att göra integration tests? Jag läste att det ofta var särskilda test grupper som gjorde det.

Å andra sidan lär det knappast skada att göra det nu ändå för att visa att jag vet vad det är.

Det varierar. Mitt jobb har en tendens att ändra sig när det gäller vem som är ansvarig för att skriva och köra tester på olika nivåer typ var tredje månad eller så. Vi har tester på fem nivåer, från enhetstester på nivå 1, via komponenttester, API- eller integrationstester, funktionella tester på systemnivå (manuella eller automatiserade) till i slutändan E2E-tester av hela systemet. Efter det tillkommer mer testning som sker i en annan del av organisationen, typ tester av kundsystem och konfiguration och så. Och våra säljbolag runtom i världen testar också våra saker i samband med att de använder något nytt för första gången, en release exempelvis men det kan också handla om viss funktionalitet som de inte nyttjat innan eller så.

För att göra detta använder vi vanliga ramverk för enhetstester beroende på miljö, nunit, jasmine etc. Andra ramverk för integrations- eller systemtester, exempelvis specflow. Över det har vi två testramverk som, mer eller mindre, är utvecklade internt eller av personer som är anställda hos oss.

I dagsläget är det utvecklingsteamen som är ansvariga upp ungefär till nivå fyra. Jag har exempelvis precis skrivit testfall på ganska hög nivå för en feature en annan i mitt team byggt som jag också "kör" igenom. Detta är typ på nivån, logga in, gå till sidan "inställningar", klicka på detta menyalternativet, lägg till X, ta bort Y, redigera Z i listan B genom att göra "Å", då ska detta hända. Kolla i databasen/loggarna att det ser ut som förväntat. I denna körning innefattas också normalt utforskande tester, alltså klicka runt i komponenten som testas och försök sabba den. Går allt bra så lämnar jag över dessa testfall till testteamet så får de automatisera, om möjligt, annars tar de in mina testfall i de manuella tester de kör vid varje release.

För en nybörjare tror jag det är viktigt att komma igång och få in testtänket. Greppa dependency injection och använd det i dina projekt för enhetstester är en bra början. Det gör förstås saker mer komplicerade med interfaces överallt, och du lär behöva något mockingramverk eller så, och så, men det är ju så det ser ut i verkligheten så det är bara att lära sig. Att skriva testfall på högre nivå är ju tekniskt enklare, men kräver ju en del kunskap kring systemet och den kringliggande miljön för att det ska träffa rätt, så det är kanske inte någon större mening att tänka på det för dina egna projekt. Däremot om du ger dig på ett större open source-projekt kanske.

Specflow är ganska bra tycker jag, om man vill göra lite mer omfattande tester, men det är ingen industristandard riktigt eller så, så det kanske inte är direkt applicerbart på en anställning. Har man väl gjort jobbet med att integrera specflow i ett projekt så är det väldigt lätt att lägga till fler tester. Hela tanken med specflow är ju att låta personer som inte är utvecklare skriva tester som kan köras direkt, vilket är något av en utopi, men har man sakerna på plats så underlättar det i alla fall.

Permalänk
Medlem

Såklart man kan söka jobb.

Ett problem är att ofta är den som läser jobbansökan en rekryterare utan någon programmeringskunskap. Dens uppgift är att kontakta personer och gallra bort sökande.

Personen som då inte har en tydlig meritlista får det svårt att få dessa "rekryterare utan någon programmeringskunskap" att låta en gå vidare.

En tankeställare jag får är: Vi i sverige har gratis utbildning inom både YH och högskola, det är bara att läsa. En person som valde att läsa själv så kommer genast frågan varför? Och hur fick personen denna tid att läsa ifrån. Gick personen arbetslös, hade den ett vanligt jobb vid sidan av?

Ta en 22åring som har gått arbetslös sedan gymnasiet och lägger fram att den har pluggat programmering på egen hand. Så känns det för mig större chans att anställa en person som gick en 3årig högskoleutbildning inom detsamma.
Vilken som är bäst kan man aldrig veta, men det handlar om att chansa rätt. Där fel val kostar en massa pengar.

Permalänk
Medlem
Skrivet av snajk:

Det varierar. Mitt jobb har en tendens att ändra sig när det gäller vem som är ansvarig för att skriva och köra tester på olika nivåer typ var tredje månad eller så. Vi har tester på fem nivåer, från enhetstester på nivå 1, via komponenttester, API- eller integrationstester, funktionella tester på systemnivå (manuella eller automatiserade) till i slutändan E2E-tester av hela systemet. Efter det tillkommer mer testning som sker i en annan del av organisationen, typ tester av kundsystem och konfiguration och så. Och våra säljbolag runtom i världen testar också våra saker i samband med att de använder något nytt för första gången, en release exempelvis men det kan också handla om viss funktionalitet som de inte nyttjat innan eller så.

För att göra detta använder vi vanliga ramverk för enhetstester beroende på miljö, nunit, jasmine etc. Andra ramverk för integrations- eller systemtester, exempelvis specflow. Över det har vi två testramverk som, mer eller mindre, är utvecklade internt eller av personer som är anställda hos oss.

I dagsläget är det utvecklingsteamen som är ansvariga upp ungefär till nivå fyra. Jag har exempelvis precis skrivit testfall på ganska hög nivå för en feature en annan i mitt team byggt som jag också "kör" igenom. Detta är typ på nivån, logga in, gå till sidan "inställningar", klicka på detta menyalternativet, lägg till X, ta bort Y, redigera Z i listan B genom att göra "Å", då ska detta hända. Kolla i databasen/loggarna att det ser ut som förväntat. I denna körning innefattas också normalt utforskande tester, alltså klicka runt i komponenten som testas och försök sabba den. Går allt bra så lämnar jag över dessa testfall till testteamet så får de automatisera, om möjligt, annars tar de in mina testfall i de manuella tester de kör vid varje release.

För en nybörjare tror jag det är viktigt att komma igång och få in testtänket. Greppa dependency injection och använd det i dina projekt för enhetstester är en bra början. Det gör förstås saker mer komplicerade med interfaces överallt, och du lär behöva något mockingramverk eller så, och så, men det är ju så det ser ut i verkligheten så det är bara att lära sig. Att skriva testfall på högre nivå är ju tekniskt enklare, men kräver ju en del kunskap kring systemet och den kringliggande miljön för att det ska träffa rätt, så det är kanske inte någon större mening att tänka på det för dina egna projekt. Däremot om du ger dig på ett större open source-projekt kanske.

Specflow är ganska bra tycker jag, om man vill göra lite mer omfattande tester, men det är ingen industristandard riktigt eller så, så det kanske inte är direkt applicerbart på en anställning. Har man väl gjort jobbet med att integrera specflow i ett projekt så är det väldigt lätt att lägga till fler tester. Hela tanken med specflow är ju att låta personer som inte är utvecklare skriva tester som kan köras direkt, vilket är något av en utopi, men har man sakerna på plats så underlättar det i alla fall.

Intressant läsning, tack.

Nu är det i Java och Spring som jag sitter och mycket här sker genom annoteringar, som är bra då det inte blir överväldigande mycket på en gång utan lagom. Samtidigt är man ju nyfiken på vad som sker bakom annoteringen.

Jag har just nu alla mina tester i samma class, en separat fil under /test istället för /main. För att strukturera upp det lite har jag lagt security tests först, t.ex. CSRF, authentification och authorization på metodnivå. Jag vet inte om det är ett bra sätt men är väl bättre med någon struktur än ingen alls iallafall.

Det var någon som pratade om att jag borde separera en del logik/kod ifrån min 'OnlineSurgeonController' till ett enskilt service-lager. Jag förstog inte helt vad den menade, är det att separera logik beroende på vad för CRUD-operation som görs? Det är ju i princip det enda som händer i det programmet. Eller är det just CRUD operationer som hör hemma i servicelager och mina enda två metoder som gör något annat, 'sendToSurgery' och getNamesFromIds som anses höra hemma mer i kontrollern?

Permalänk
Medlem

Har inte läst allt men skulle nog säga att det är bättre att lära sig grunderna riktigt bra och bygga något projekt som man själv har nytta av och tycker är roligt än att lära sig en massa nya saker, blir lätt för spretigt och urvattnat. Det kommer när hobby projektet växer.
Jag har ännu inte träffat någon nyanställd som kan Azure men det går bra ändå, de lär sig snabbt på plats när de är anställda. Viktigare att de kan tänka och skriva kod.

/Viktor

Permalänk
Medlem
Skrivet av first:

Intressant läsning, tack.

Nu är det i Java och Spring som jag sitter och mycket här sker genom annoteringar, som är bra då det inte blir överväldigande mycket på en gång utan lagom. Samtidigt är man ju nyfiken på vad som sker bakom annoteringen.

Jag har just nu alla mina tester i samma class, en separat fil under /test istället för /main. För att strukturera upp det lite har jag lagt security tests först, t.ex. CSRF, authentification och authorization på metodnivå. Jag vet inte om det är ett bra sätt men är väl bättre med någon struktur än ingen alls iallafall.

Det var någon som pratade om att jag borde separera en del logik/kod ifrån min 'OnlineSurgeonController' till ett enskilt service-lager. Jag förstog inte helt vad den menade, är det att separera logik beroende på vad för CRUD-operation som görs? Det är ju i princip det enda som händer i det programmet. Eller är det just CRUD operationer som hör hemma i servicelager och mina enda två metoder som gör något annat, 'sendToSurgery' och getNamesFromIds som anses höra hemma mer i kontrollern?

Man brukar väl vilja hålla controllers ganska cleana, brukar köra mer logik och mappning av DTO etc i en service och även ha repository, istället för att prata med databasen direkt i controllern som en del gör. Föredrar visserligen att mappa i extensions, sen finns ju automappers också.

Permalänk
Medlem
Skrivet av ChrisDev:

Man brukar väl vilja hålla controllers ganska cleana, brukar köra mer logik och mappning av DTO etc i en service och även ha repository, istället för att prata med databasen direkt i controllern som en del gör. Föredrar visserligen att mappa i extensions, sen finns ju automappers också.

Okej, om jag vänder på det då, vad är det som anses ska ligga i en kontroller?

Permalänk
Medlem
Skrivet av first:

Okej, om jag vänder på det då, vad är det som anses ska ligga i en kontroller?

Finns säkert en del tyckande om det som med allt annat.
Men så som jag lärt mig och brukar försöka hålla det är att bara ta request/response och skicka till/från en service som är injectad med ett interface.
Ibland behöver man ju göra lite enklare logik i controllern med dock.

Permalänk
Medlem
Skrivet av ChrisDev:

Man brukar väl vilja hålla controllers ganska cleana, brukar köra mer logik och mappning av DTO etc i en service och även ha repository, istället för att prata med databasen direkt i controllern som en del gör. Föredrar visserligen att mappa i extensions, sen finns ju automappers också.

Man kan göra sub controller tasks för varje endpoint eller varje typ av payload och sånt

Finns många sätt att dela upp saker på

Helst vill man att en klass ska hålla koll på och göra en sak, och ha ett tydligt ansvarsområde

Permalänk
Medlem
Skrivet av medbor:

Man kan göra sub controller tasks för varje endpoint eller varje typ av payload och sånt

Finns många sätt att dela upp saker på

Helst vill man att en klass ska hålla koll på och göra en sak, och ha ett tydligt ansvarsområde

Ja det finns väl som sagt många sätt att göra på och mycket tyckande antar jag.
Har hört folk prata om controllers på tusentals rader vilket låter ganska jobbigt.
Att en controller/service/respository/what not hör till en specifik resurs/ansvarsområde antar jag är ganska standard dock, men jag är för ny i det verkliga livet för att uttala mig 😁

Permalänk
Medlem

Okej tack för förklaringarna. Jag försöker applicera det på mitt eget projekt men får inte riktigt ihop det.

Som för OnlineSurgeon då; där finns 3 tables och därmed 3 repos, samt två logikfunktion som arbetar ihop (sendToSurgery).
Menar ni att jag ska, eller kan, ha :

* 1 controller som för vidare till 3 service layers (ett per repo/table). Var hamnar då logikfunktionen?
* 3 kontrollers och 1 service layer där sendToSurgery hamnar

Jag fattar inte skillnaden mellan service layer och repository.

Från Baeldung:
RESTful applications are designed to be service-oriented and return raw data (JSON/XML typically). Since these applications do not do any view rendering, there are no View Resolvers – the Controller is generally expected to send data directly via the HTTP response.

Är det så enkelt som att ni tycker att jag ska dela upp det i separata kontrollers, en per repo?

Permalänk
Medlem
Skrivet av first:

Okej tack för förklaringarna. Jag försöker applicera det på mitt eget projekt men får inte riktigt ihop det.

Som för OnlineSurgeon då; där finns 3 tables och därmed 3 repos, samt två logikfunktion som arbetar ihop (sendToSurgery).
Menar ni att jag ska, eller kan, ha :

* 1 controller som för vidare till 3 service layers (ett per repo/table). Var hamnar då logikfunktionen?
* 3 kontrollers och 1 service layer där sendToSurgery hamnar

Jag fattar inte skillnaden mellan service layer och repository.

Från Baeldung:
RESTful applications are designed to be service-oriented and return raw data (JSON/XML typically). Since these applications do not do any view rendering, there are no View Resolvers – the Controller is generally expected to send data directly via the HTTP response.

Är det så enkelt som att ni tycker att jag ska dela upp det i separata kontrollers, en per repo?

Service = business logic, mellan controller och repository.
Repository = närmast databas och ska ta/skicka data i domän-form.

Så är rätt vanligt med ett repository för varje tabell/entity men ibland gör man ett mer generiskt base repository.

Folk med mer erfarenhet får gärna rätta mig om jag svamlar men det är så här jag lärt mig och förstått det iaf.

Permalänk
Medlem
Skrivet av swesen:

Jag har tagit mig från självlärd inom programmering till jobb inom embedded via YH, lärde mig minimalt på YH förutom att det var bra att få upp mitt självförtroende, de 4-5 projekten vi hade i grupp och även att ha CSN under LIA (praktik på företag). Jag lyckades imponera på företaget och fick anställning direkt.

Kollade lite i ditt HoMM och ser lite saker du kan tänka på. Det handlar delvis om koddubblering, men även objekthantering och datastruktur för att göra framtida ändringar enklare och koden mer läsbar.

Kodduplicering:

Här är två näst intill identiska funktioner, men även under så gör du dessa rutor i "def view_info(self)", dessa rutor kan göras mer dynamiskt så de anpassar sig efter hur många rader text som ska vara i. Du kan göra en klass med funktioner för att hantera det här

def dialogue_display(self, input1="", input2="", input3="", input4=""): print("-" + '{:-^140s}'.format("-") + "-") print("|" + '{:^140s}'.format(input1 + input2) + "|") print("|" + '{:^140}'.format(input3 + input4) + "|") print("-" + '{:-^140s}'.format("-") + "-") input("\n") def dialogue_return(self, input1="", input2="", input3="", input4=""): print("-" + '{:-^140s}'.format("-") + "-") print("|" + '{:^140s}'.format(input1 + input2) + "|") print("|" + '{:^140s}'.format(input3 + input4) + "|") print("-" + '{:-^140s}'.format("-") + "-") choice = input("\n") return choice // Exempel class dialogues: def line(): return "-" + '{:-^140s}'.format("-") + "-\n" def dialogue(text: str)->str: result = line() for row in text.split("\n"): result += "|" + '{:^140s}'.format(row) + "|\n" result += line() class Player: def dialogue_display(self, input1="", input2="", input3="", input4=""): print(dialogues.dialogue(input1+input2+"\n"+input3+input4) input("\n") def dialogue_return(self, input1="", input2="", input3="", input4=""): print(dialogues.dialogue(input1+input2+"\n"+input3+input4) choice = input("\n") return choice

Du använder inte heller din referens till "self" någonstans här.

Dold text

Datastruktur/objekthantering:

Det här såg jag mycket hos andra på YH de gör något hårdkodat så det inte går att enkelt ändra i framtiden. Tänk dig när du går till ett enormt projekt med följande kod på 30 ställen.

def new_turn(self): self.gold += self.dailyg self.wood += self.dailyw self.stone += self.dailys self.crystal += self.dailyc self.sulfur += self.dailysu self.mercury += self.dailym self.gems += self.dailyge // Exempel from dataclasses import dataclass, fields @dataclass class Inventory: gold:int = 0 wood:int = 0 stone:int = 0 crystal:int = 0 sulfur:int = 0 mercury:int = 0 gems:int = 0 def __add__(self, other): return Inventory(*(getattr(self, dim.name)+getattr(other, dim.name) for dim in fields(self))) class Player: inventory = Inventory(4000, 10, 10, 4, 4, 4, 4) daily = Inventory(500) def new_turn(self): self.inventory += self.daily

Du kan sen lägga till andra värden eller ta bort genom att bara ändra inventory klassen.

Dold text

Det här svaret uppskattade jag också extra mycket. För att du la ner tiden! Bra grejer, jag implementerade allt. Det blev:

class Dialogues: def line(width): return ("-" + '{:-^' + str(width) + 's}').format("-") + "-\n" def box(text: str, width)->str: result = Dialogues.line(width) for row in text.split("\n"): result += ("|" + '{:^' + str(width) + 's}').format(row) + "|\n" result += Dialogues.line(width) return result def inside_box(text: str, width)->str: result = "" for row in text.split("\n"): result += ("|" + '{:^' + str(width) + 's}').format(row) + "|" return result def headline(text: str, width)->str: result = "" for row in text.split("\n"): result += ("|" + '{:-^' + str(width) + 's}').format(row) + "|" return result

för dialoger, ett extra argument för valfri width och några fler varianter.
edit: Jag kan iof lägga till ett tredje argument, line=False, och vid True så kallar jag på Line, annars inte, och så kan jag fimpa mina två extra metoder. Kan även lägga in val av utfyllnadstecken som fjärde argument. Imorgon.

Implementerade dataclass för Resources, snodde den rakt av, samt daily-uppdateringsmetoden.

Jag har även lagt "dwXamount" i en lista istället för varsin rad. Sparade totalt ca 35 rader totalt.
Jag har också ordnat en extern DB för alla units och snart alla spells och heroes. Hittills sparat 150 rader kod.
Även brutit ut class Player från Entities. Player är nu 1214 rader, entities 886 rader. Övriga 300 rader totalt.

Integrity testing i OnlineSurgeon och unit testing i Super Deliveries API. Nu får det vara helg. Ska läsa på om olika arbetsmetoder, agile med mera i helgen och så blir det nog ett par ansökningar nästa vecka.

Permalänk
Medlem

Vad tycker ni om min korta sammanfattning av Agile, SCRUM, KANBAN, LEAN, DevOps? Jag vet att det är kort och inte inbegriper allt men samtidigt så är de inte särskilt banbrytande arbetssätt imo, de flesta framgångsrika arbetsplatser har implementerat någon form av arbetsmetodiken. Det handlar om att minimera friktion för kommunikation på arbetsplatsen och att fokusera på det som är viktigt. LEAN har jag redan arbetat med t.ex.

Därmed kan jag råka ha förstått något galet och då får ni gärna haffa det

Agile är ett arbetssätt. Det går ut på att dela upp ett projekt i många mindre delmål av flera anledningar:
* För att fördröja viktiga beslut in i det sista/längre fram i kedjan och därmed undvika att behöva göra om, om ett beslut ändras
* Att anpassa de första stegen i kedjan så att de blir mindre beroende av hur de framtida stegen utvecklar sig
* Genom att dela upp projektet i delpunkter kan fokus koncentreras bättre och extra insatser lättare fördelas

SCRUM är en agil metodik. Det innefattar bland annat:
* Dagliga, mycket korta möten där projektmedlemmar uppdaterar varandra om status
* Sprints, en period där funktioner som blivit valda för sprinting börjar kodas. Fokus ligger på just dessa funktioner. Ut kommer en ny komponent/funktion för projektet. Sedan startar nästa Sprint.

KANBAN är att visuellt upptäcka hur arbetsflödet ser ut och på så sätt upptäcka flaskhalsar, samt hur mycket kapacitet en viss avdelning har, t.ex. KANBAN härstammar från LEAN.

LEAN är ett annat arbetssätt än Agile, men det innebär inte att de inte är kompatibla. Inom LEAN är en viktig komponent att identifiera waste inom produktionen. Allt som inte för produkten eller tjänstens kärn-uppdrag framåt är waste, och bör som sådant elimineras. Exempel på waste: onödiga, ej tillfrågade funktioner, större antal chefer än nödvändigt, väntande (JIT är bättre), att byta position (du tappar fokus), överlämningar.

DevOps: https://aws.amazon.com/devops/what-is-devops/
DevOps, Development Operations, är ett arbetssätt som använder många delar från Agile. Projektmedlemmar integreras under samma avdelning, utvecklare och managers, tex, är inte särskilda. Projektmedlemmar, framförallt utvecklare, stannar också kvar under hela projektets gång, vilket eliminerar waste i form av överlämning och ny-inlärning.
Om det övergripande målet med ett projekt är att implementera eller förbättra säkerheten hos ett program, eller där säkerheten överlag är högsta prioritet, kan arbetssättet kallas DevSecOps.
DevOps är att som projektmedlem har du ett större övergripande ansvarsområde än att du bara är utvecklare eller i en management position - ofta är det bägge två samtidigt. Det handlar om att ha helhjärtat engagemang för slutprodukten, leveransen och kvalitetssäkring. DevOps är att utveckla med en helhetsbild.

Permalänk
Medlem
Skrivet av first:

Okej tack för förklaringarna. Jag försöker applicera det på mitt eget projekt men får inte riktigt ihop det.

Som för OnlineSurgeon då; där finns 3 tables och därmed 3 repos, samt två logikfunktion som arbetar ihop (sendToSurgery).
Menar ni att jag ska, eller kan, ha :

* 1 controller som för vidare till 3 service layers (ett per repo/table). Var hamnar då logikfunktionen?
* 3 kontrollers och 1 service layer där sendToSurgery hamnar

Jag fattar inte skillnaden mellan service layer och repository.

Från Baeldung:
RESTful applications are designed to be service-oriented and return raw data (JSON/XML typically). Since these applications do not do any view rendering, there are no View Resolvers – the Controller is generally expected to send data directly via the HTTP response.

Är det så enkelt som att ni tycker att jag ska dela upp det i separata kontrollers, en per repo?

Arkitektur kan man gräva ner sig i i all evighet om man vill. Ta en google på t.ex. Clean Architecture för en start som är hyfsat modern och försök att förstå vad det är för poänger de försöker göra och vilka problem de försöker lösa.

Mycket av det handlar om att man i en modern, komplex programvara inte vill att olika lager "läcker ut" i varandra. Du ska kunna byta ut hela din frontend, eller koppla på något annat presentationslager, utan att behöva göra några som helst förändringar i underliggande lager. Samma sak i andra änden, kan du byta till en helt annan databas utan att ditt applikationslager märker av det?

Visa signatur

"Kom inte hit och trassla till saker med fakta"

Permalänk
Medlem
Skrivet av first:

Vad tycker ni om min korta sammanfattning av Agile, SCRUM, KANBAN, LEAN, DevOps? Jag vet att det är kort och inte inbegriper allt men samtidigt så är de inte särskilt banbrytande arbetssätt imo, de flesta framgångsrika arbetsplatser har implementerat någon form av arbetsmetodiken. Det handlar om att minimera friktion för kommunikation på arbetsplatsen och att fokusera på det som är viktigt. LEAN har jag redan arbetat med t.ex.

Därmed kan jag råka ha förstått något galet och då får ni gärna haffa det

Agile är ett arbetssätt. Det går ut på att dela upp ett projekt i många mindre delmål av flera anledningar:
* För att fördröja viktiga beslut in i det sista/längre fram i kedjan och därmed undvika att behöva göra om, om ett beslut ändras
* Att anpassa de första stegen i kedjan så att de blir mindre beroende av hur de framtida stegen utvecklar sig
* Genom att dela upp projektet i delpunkter kan fokus koncentreras bättre och extra insatser lättare fördelas

SCRUM är en agil metodik. Det innefattar bland annat:
* Dagliga, mycket korta möten där projektmedlemmar uppdaterar varandra om status
* Sprints, en period där funktioner som blivit valda för sprinting börjar kodas. Fokus ligger på just dessa funktioner. Ut kommer en ny komponent/funktion för projektet. Sedan startar nästa Sprint.

KANBAN är att visuellt upptäcka hur arbetsflödet ser ut och på så sätt upptäcka flaskhalsar, samt hur mycket kapacitet en viss avdelning har, t.ex. KANBAN härstammar från LEAN.

LEAN är ett annat arbetssätt än Agile, men det innebär inte att de inte är kompatibla. Inom LEAN är en viktig komponent att identifiera waste inom produktionen. Allt som inte för produkten eller tjänstens kärn-uppdrag framåt är waste, och bör som sådant elimineras. Exempel på waste: onödiga, ej tillfrågade funktioner, större antal chefer än nödvändigt, väntande (JIT är bättre), att byta position (du tappar fokus), överlämningar.

DevOps: https://aws.amazon.com/devops/what-is-devops/
DevOps, Development Operations, är ett arbetssätt som använder många delar från Agile. Projektmedlemmar integreras under samma avdelning, utvecklare och managers, tex, är inte särskilda. Projektmedlemmar, framförallt utvecklare, stannar också kvar under hela projektets gång, vilket eliminerar waste i form av överlämning och ny-inlärning.
Om det övergripande målet med ett projekt är att implementera eller förbättra säkerheten hos ett program, eller där säkerheten överlag är högsta prioritet, kan arbetssättet kallas DevSecOps.
DevOps är att som projektmedlem har du ett större övergripande ansvarsområde än att du bara är utvecklare eller i en management position - ofta är det bägge två samtidigt. Det handlar om att ha helhjärtat engagemang för slutprodukten, leveransen och kvalitetssäkring. DevOps är att utveckla med en helhetsbild.

Agilt handlar framförallt om att vara öppen för förändringar, jobba nära med andra i projektet utanför teamet och vara beredd att styra om. Väldigt nära besläktat med UX, förbättringar för alla olika användare av kod/infrastruktur/appar/webbsidor/support i projektet. Snabba små ändringar är mycket lättare att underhålla och få feedback på

Permalänk
Medlem
Skrivet av first:

Vad tycker ni om min korta sammanfattning av Agile, SCRUM, KANBAN, LEAN, DevOps? Jag vet att det är kort och inte inbegriper allt men samtidigt så är de inte särskilt banbrytande arbetssätt imo, de flesta framgångsrika arbetsplatser har implementerat någon form av arbetsmetodiken. Det handlar om att minimera friktion för kommunikation på arbetsplatsen och att fokusera på det som är viktigt. LEAN har jag redan arbetat med t.ex.

Därmed kan jag råka ha förstått något galet och då får ni gärna haffa det

Agile är ett arbetssätt. Det går ut på att dela upp ett projekt i många mindre delmål av flera anledningar:
* För att fördröja viktiga beslut in i det sista/längre fram i kedjan och därmed undvika att behöva göra om, om ett beslut ändras
* Att anpassa de första stegen i kedjan så att de blir mindre beroende av hur de framtida stegen utvecklar sig
* Genom att dela upp projektet i delpunkter kan fokus koncentreras bättre och extra insatser lättare fördelas

SCRUM är en agil metodik. Det innefattar bland annat:
* Dagliga, mycket korta möten där projektmedlemmar uppdaterar varandra om status
* Sprints, en period där funktioner som blivit valda för sprinting börjar kodas. Fokus ligger på just dessa funktioner. Ut kommer en ny komponent/funktion för projektet. Sedan startar nästa Sprint.

KANBAN är att visuellt upptäcka hur arbetsflödet ser ut och på så sätt upptäcka flaskhalsar, samt hur mycket kapacitet en viss avdelning har, t.ex. KANBAN härstammar från LEAN.

LEAN är ett annat arbetssätt än Agile, men det innebär inte att de inte är kompatibla. Inom LEAN är en viktig komponent att identifiera waste inom produktionen. Allt som inte för produkten eller tjänstens kärn-uppdrag framåt är waste, och bör som sådant elimineras. Exempel på waste: onödiga, ej tillfrågade funktioner, större antal chefer än nödvändigt, väntande (JIT är bättre), att byta position (du tappar fokus), överlämningar.

DevOps: https://aws.amazon.com/devops/what-is-devops/
DevOps, Development Operations, är ett arbetssätt som använder många delar från Agile. Projektmedlemmar integreras under samma avdelning, utvecklare och managers, tex, är inte särskilda. Projektmedlemmar, framförallt utvecklare, stannar också kvar under hela projektets gång, vilket eliminerar waste i form av överlämning och ny-inlärning.
Om det övergripande målet med ett projekt är att implementera eller förbättra säkerheten hos ett program, eller där säkerheten överlag är högsta prioritet, kan arbetssättet kallas DevSecOps.
DevOps är att som projektmedlem har du ett större övergripande ansvarsområde än att du bara är utvecklare eller i en management position - ofta är det bägge två samtidigt. Det handlar om att ha helhjärtat engagemang för slutprodukten, leveransen och kvalitetssäkring. DevOps är att utveckla med en helhetsbild.

Jag tycker i grunden att du hittat ganska bra definitioner. När du väl kommer att jobba i en organisation kommer du sen märka att inte alla som säger att de är agila verkligen är det i verkligheten. Det är inte nödvändigtvis fel - ibland kan man inte vara så flexibel som man vill eftersom man lovat en leverans - men det är viktigt att förstå.

Framförallt vill jag väcka lite mer tankar kring DevOps. I grunden är det ju sammanslaget av två ord "Development" och "Operations". En jämförelse kanske kan vara en vanlig fysisk fabrik som tillverkar en vara. Ett gäng konstruerar och bygger maskinen som står i fabriken (Dev) och ett annat arbetsgäng kör och servar maskinen när den väl producerar varan (Ops). DevOps kombinerar två saker: Mjukvarans natur och vem gör vilket jobb?

Den första aspekten är att mjukvara är mer flexibel än en fysisk maskin, den går att ändra även när den börjat köra. Alltså så finns det anledning att det är nästan samma sak att utveckla som att köra - samma kompetenser behövs, och förståelsen från båda fälten behövs, alltså smälter de samman. Du nämner utveckling och management, men operations, drift, är också viktigt här. Detta märks extra tydligt i moderna molnmiljöer - om programmeraren inte tänker på driften kan det komma en oväntad faktura på en miljon från AWS.

Den andra aspekten av DevOps är att väldigt många i mjukvaruvärlden vill programmera och mycket färre vill bara vara datavaktmästare och klappa om kod som annan skriven. Med DevOps och andra modetermer som "Infrastructure as code" så hamnar mycket mer av jobbet som behöver göras nära en programmerares vardag. Istället för att manuellt skriva in en konfigurationsfil i ett system så skriver du programkod som sätter upp systemet automatiskt etc etc.

Permalänk
Medlem
Skrivet av blackcoffee:

Jag tycker i grunden att du hittat ganska bra definitioner. När du väl kommer att jobba i en organisation kommer du sen märka att inte alla som säger att de är agila verkligen är det i verkligheten. Det är inte nödvändigtvis fel - ibland kan man inte vara så flexibel som man vill eftersom man lovat en leverans - men det är viktigt att förstå.

Framförallt vill jag väcka lite mer tankar kring DevOps. I grunden är det ju sammanslaget av två ord "Development" och "Operations". En jämförelse kanske kan vara en vanlig fysisk fabrik som tillverkar en vara. Ett gäng konstruerar och bygger maskinen som står i fabriken (Dev) och ett annat arbetsgäng kör och servar maskinen när den väl producerar varan (Ops). DevOps kombinerar två saker: Mjukvarans natur och vem gör vilket jobb?

Den första aspekten är att mjukvara är mer flexibel än en fysisk maskin, den går att ändra även när den börjat köra. Alltså så finns det anledning att det är nästan samma sak att utveckla som att köra - samma kompetenser behövs, och förståelsen från båda fälten behövs, alltså smälter de samman. Du nämner utveckling och management, men operations, drift, är också viktigt här. Detta märks extra tydligt i moderna molnmiljöer - om programmeraren inte tänker på driften kan det komma en oväntad faktura på en miljon från AWS.

Den andra aspekten av DevOps är att väldigt många i mjukvaruvärlden vill programmera och mycket färre vill bara vara datavaktmästare och klappa om kod som annan skriven. Med DevOps och andra modetermer som "Infrastructure as code" så hamnar mycket mer av jobbet som behöver göras nära en programmerares vardag. Istället för att manuellt skriva in en konfigurationsfil i ett system så skriver du programkod som sätter upp systemet automatiskt etc etc.

En sak att tänka på med ops är också att det kan skilja väldigt mycket. På mitt jobb har vi ca 50% on-prem, dvs kunder som kör och underhåller servrarna själva, i de fallen är ops mer att vara med på debug-sessioner eller svara på mail. Fallen när man själv har en tjänst eller app är det mer att kolla på analytics/hälsa/loggar, sköta uppdateringar, öka prestanda och kapacitet, underhålla säkerhetsuppdateringar och så vidare

Varierar väldigt mycket vad det kan handla om. Men det hjälper utvecklare att vara mer insatta i hur produkterna används och vara medveten vilka problem andra administratörer och operatörer ställs inför

Permalänk
Medlem
Skrivet av blackcoffee:

Jag tycker i grunden att du hittat ganska bra definitioner. När du väl kommer att jobba i en organisation kommer du sen märka att inte alla som säger att de är agila verkligen är det i verkligheten. Det är inte nödvändigtvis fel - ibland kan man inte vara så flexibel som man vill eftersom man lovat en leverans - men det är viktigt att förstå.

Framförallt vill jag väcka lite mer tankar kring DevOps. I grunden är det ju sammanslaget av två ord "Development" och "Operations". En jämförelse kanske kan vara en vanlig fysisk fabrik som tillverkar en vara. Ett gäng konstruerar och bygger maskinen som står i fabriken (Dev) och ett annat arbetsgäng kör och servar maskinen när den väl producerar varan (Ops). DevOps kombinerar två saker: Mjukvarans natur och vem gör vilket jobb?

Den första aspekten är att mjukvara är mer flexibel än en fysisk maskin, den går att ändra även när den börjat köra. Alltså så finns det anledning att det är nästan samma sak att utveckla som att köra - samma kompetenser behövs, och förståelsen från båda fälten behövs, alltså smälter de samman. Du nämner utveckling och management, men operations, drift, är också viktigt här. Detta märks extra tydligt i moderna molnmiljöer - om programmeraren inte tänker på driften kan det komma en oväntad faktura på en miljon från AWS.

Den andra aspekten av DevOps är att väldigt många i mjukvaruvärlden vill programmera och mycket färre vill bara vara datavaktmästare och klappa om kod som annan skriven. Med DevOps och andra modetermer som "Infrastructure as code" så hamnar mycket mer av jobbet som behöver göras nära en programmerares vardag. Istället för att manuellt skriva in en konfigurationsfil i ett system så skriver du programkod som sätter upp systemet automatiskt etc etc.

Bra utveckling av betydelsen, tack!

Permalänk
Medlem

Jag har börjat söka ett par jobb och kommer fortsätta med det. Under tiden ska jag såklart fortsätta utvecklas. Vad tror ni ger mest bang for buck av följande alternativ? Kom gärna med eget förslag om du har en bra ide.

1) Utveckla en enkel Front End i React till varje projekt, starta med Super Deliveries, sen Online Akuten. Det låser upp möjligheten att kunna hosta dem, på Azure rentav eller annan billigare tjänst. Förutom att kunna visa på att jag kan Full Stack så är det också lättare att visa vid ansökan, kan bara skicka länk.
Sist hade jag tagit mig an en Front End till HoMM vilket hade varit mäktigt då det låser upp riktig grafik om jag lämnar kommandotolken som interface

2) satsa på back end till ytterligare en app, men ännu mer avancerat. T.ex, ange adress, matcha den mot Google API för att komplettera adressen med postnr t.ex, hämta sedan genomsnittligt kvmpris från Boolis API för angivna Google adress. Bygg upp lite statistik för ett område och spara i databas samt välj att spara till fil eller nåt, jag vet inte vad.

Om nån har förslag på nåt vettigare så kör,jag försöker bara komma på något
Det jag inte väljer nu, tar jag sen. Så det är bara frågan om vad jag gör först.

Permalänk
Medlem
Skrivet av first:

Jag har börjat söka ett par jobb och kommer fortsätta med det. Under tiden ska jag såklart fortsätta utvecklas. Vad tror ni ger mest bang for buck av följande alternativ? Kom gärna med eget förslag om du har en bra ide.

1) Utveckla en enkel Front End i React till varje projekt, starta med Super Deliveries, sen Online Akuten. Det låser upp möjligheten att kunna hosta dem, på Azure rentav eller annan billigare tjänst. Förutom att kunna visa på att jag kan Full Stack så är det också lättare att visa vid ansökan, kan bara skicka länk.
Sist hade jag tagit mig an en Front End till HoMM vilket hade varit mäktigt då det låser upp riktig grafik om jag lämnar kommandotolken som interface

2) satsa på back end till ytterligare en app, men ännu mer avancerat. T.ex, ange adress, matcha den mot Google API för att komplettera adressen med postnr t.ex, hämta sedan genomsnittligt kvmpris från Boolis API för angivna Google adress. Bygg upp lite statistik för ett område och spara i databas samt välj att spara till fil eller nåt, jag vet inte vad.

Om nån har förslag på nåt vettigare så kör,jag försöker bara komma på något
Det jag inte väljer nu, tar jag sen. Så det är bara frågan om vad jag gör först.

Låter vettigt. Frontend kan dock handla om väldigt mycket, bli inte för fokuserad på design och animationer, se till att hålla det responsivt och tydligt (spinners när man väntar på svar eller gör något till exempel), felmeddelanden när man gör fel…)

Annars är det som du varit inne på förut att forka eller göra en pullrequest på något stort repo/projekt

Permalänk
Medlem
Skrivet av swesen:

Jag har tagit mig från självlärd inom programmering till jobb inom embedded via YH, lärde mig minimalt på YH förutom att det var bra att få upp mitt självförtroende, de 4-5 projekten vi hade i grupp och även att ha CSN under LIA (praktik på företag). Jag lyckades imponera på företaget och fick anställning direkt.

Kollade lite i ditt HoMM och ser lite saker du kan tänka på. Det handlar delvis om koddubblering, men även objekthantering och datastruktur för att göra framtida ändringar enklare och koden mer läsbar.

Kodduplicering:

Här är två näst intill identiska funktioner, men även under så gör du dessa rutor i "def view_info(self)", dessa rutor kan göras mer dynamiskt så de anpassar sig efter hur många rader text som ska vara i. Du kan göra en klass med funktioner för att hantera det här

def dialogue_display(self, input1="", input2="", input3="", input4=""): print("-" + '{:-^140s}'.format("-") + "-") print("|" + '{:^140s}'.format(input1 + input2) + "|") print("|" + '{:^140}'.format(input3 + input4) + "|") print("-" + '{:-^140s}'.format("-") + "-") input("\n") def dialogue_return(self, input1="", input2="", input3="", input4=""): print("-" + '{:-^140s}'.format("-") + "-") print("|" + '{:^140s}'.format(input1 + input2) + "|") print("|" + '{:^140s}'.format(input3 + input4) + "|") print("-" + '{:-^140s}'.format("-") + "-") choice = input("\n") return choice // Exempel class dialogues: def line(): return "-" + '{:-^140s}'.format("-") + "-\n" def dialogue(text: str)->str: result = line() for row in text.split("\n"): result += "|" + '{:^140s}'.format(row) + "|\n" result += line() class Player: def dialogue_display(self, input1="", input2="", input3="", input4=""): print(dialogues.dialogue(input1+input2+"\n"+input3+input4) input("\n") def dialogue_return(self, input1="", input2="", input3="", input4=""): print(dialogues.dialogue(input1+input2+"\n"+input3+input4) choice = input("\n") return choice

Du använder inte heller din referens till "self" någonstans här.

Dold text

Datastruktur/objekthantering:

Det här såg jag mycket hos andra på YH de gör något hårdkodat så det inte går att enkelt ändra i framtiden. Tänk dig när du går till ett enormt projekt med följande kod på 30 ställen.

def new_turn(self): self.gold += self.dailyg self.wood += self.dailyw self.stone += self.dailys self.crystal += self.dailyc self.sulfur += self.dailysu self.mercury += self.dailym self.gems += self.dailyge // Exempel from dataclasses import dataclass, fields @dataclass class Inventory: gold:int = 0 wood:int = 0 stone:int = 0 crystal:int = 0 sulfur:int = 0 mercury:int = 0 gems:int = 0 def __add__(self, other): return Inventory(*(getattr(self, dim.name)+getattr(other, dim.name) for dim in fields(self))) class Player: inventory = Inventory(4000, 10, 10, 4, 4, 4, 4) daily = Inventory(500) def new_turn(self): self.inventory += self.daily

Du kan sen lägga till andra värden eller ta bort genom att bara ändra inventory klassen.

Dold text

Jag kollade just upp vad def dialogue(text: str)->str: faktiskt innebär. Det var mer användbart än jag trodde. Snitsig funktion!