Når man har kommet forbi det absolutt enkleste, begynner å bruke litt avhengigheter osv., så kommer man fort borti byggesystem. Byggesystem i denne konteksten tenker jeg på som Maven, Gradle, NPM, Cargo osv.

Tanken min er noe ala:

• Hvorfor bruker vi byggesystem? (enkelte har kanskje kun kompilert/kjørt direkte med python, javac, kotlinc, node, nettleser osv., og kan kanskje lure på hvorfor de trenger dette)
• Oppgaver et slikt program ofte løser (f.eks nevne dependencies, testkjøringer, bygging, lage "utgivbar" applikasjoner som andre kan kjøre uten for mye hazzle osv. "Transitive avhengigheter" kan nok nevnes her for å få opp litt øyne. Bare passe på å gjøre det på en måte som ikke virker for kompleks)
• Eksempler på byggesystem du finner der ute

Litt usikker på hvordan jeg ville strukturert dette for øyeblikket, eller hva det kalles på norsk 🙁 Tenker jeg lufter dette i tilfelle noen har tanker eller føler skrivekløe.

Heisann, fett prosjekt. Om det skal være open source, så må det lisensieres som det, dvs du må legge på en LICENSE.md med en open source lisens. Ellers så er det forsatt kode som ingen andre kan bruke, selvom vi teknisk sett kan laste den ned og åpne PRer. En populær en er MIT, men finnes mange lisenser med forskjellige trase-offs. Denne nettsiden kan hjelpe deg med å velge 😊 https://choosealicense.com

Prøver å få opp noe rundt backend opplæring nå, og kom på at sikkerhet etter en stund kan bli et sentralt emne. F.eks autentisering, autorisering osv. Absolutt ikke noe man har på intro-siden, men kan være noe vi bør ha litt ressurser linket til eller lignende. Muligens også en artikkel som introduserer disse emnene.

Usikker på hvor det passer, så lager en issue som en slags huskelapp for oss 🙂

Dette begrepet florerer det av i ulike artikler, videoer osv. på nettet. Kan sikkert være lurt om vi forklarer konseptet kort og konsist? Pluss det obligatoriske venn-diagrammet med Development+Operations 😛 Usikker på den beste måten å forklare det på for en nybegynner, så putter det her i tilfelle noen andre får litt skrivekløe 🙂

Intro

Vi ønsker å restrukturere Koding.no, for å gjøre det enklere både for studenter å navigere seg igjennom siden, men også enklere for utviklere å bidra til siden.

For å kunne diskutere dette ordentlig, så tenker jeg for referanse å legge inn et lite skriv under som er sånn oppsettet er tenkt ut per idag. Dagens løsning er ikke noen optimal løsning, selv om grunnprinsippene er på plass. Jeg legger så ved et forslag under på måter vi eventuelt kan restrukturere.

Nåværende struktur

Lær Koding

Lær koding er hoved-featuren som Koding.no tilbyr. Målet med featuren er å gi en konkret vei for studenter å følge, slik at de kan føle seg selvsikre på sin egen fremgang. Dette gjør vi idag igjennom noen få korte intro-artikler, videre inn i en enkel mål-liste.

Man kan også si at wiki/ressurser er en slags del av denne featuren, siden den er ment som en lookup for å fullføre mål-listen. Definitivt et tegn på svakhet i strukturen, og kanskje et hint om at ressursene bør ligge en annen plass, eller i en annen form.

Wiki

Per idag er "Wiki" en slags samleboks for alt av uorganisert fagmateriale som refereres til ellers rundt om kring på nettstedet. Både navnet på seksjonen/featuren, og organiseringen - er suboptimale.

Dine forslag

Åpner dette for kollektiv diskusjon, alt innspill er satt pris på!

Akkurat nå er forhåndsvisningen av siden veldig anonym om man f.eks viser den i pinned repositories:

(og andre steder der den vises)

Tenker at selv første setning fra readme'en i en eller annen form kan øke førsteinntrykket litt. Noe ala: "Open-source norsk nettside som har som hovedmål å veilede nye utviklere mot selvstyrt læring innen koding" 🙂

Til ref ser min personlige nettside sin forhåndsvisning slik ut:

Å legge til litt flere relevante tags kan også gjøre det lettere å finne prosjektet. Forslag til tags: norsk, norge, teaching-materials, learn-to-code, learning, self-taught
(sikkert flere også)

Vær gjerne uenig. Dette er jo veldig subjektivt hva jeg føler kunne hjulpet folk å finne repoet 🙂

Er dette funksjonalitet som er ønskelig, hvilken løsning bør vi gå for, og hvordan bør vi håndtere det?

Pros

• Mer innsikt i hva som resonerer med brukere
• Potensielt mer innsikt i trender og popularitet

Cons

• Kompleksitet ihht. personvern

Mine tanker

Optimalt sett så ser jeg for meg en løsning som både er anonymt, men også åpen for alle å se - slik at det ikke bare blir jeg som har netlify login som sitter på kunnskapen. Er det noen som har god erfaring rundt dette og tips om hvordan vi eventuelt bør implementere det?

Det enkleste alternativet hadde vært Netlify Analytics iom. at vi bruker Netlify for hosting, server functions, auth og deployment fra før. Men jeg er ikke helt sikker på implikasjonene med å gjøre den dataen offentlig for brukerbasen.

En ting jeg er sikker på er at dette er noe jeg vil diskutere med brukerene før jeg implementerer, det er derfor jeg har startet denne diskusjonstråden. Hyggelig om dere har noen tanker og vil bidra til tråden.

Tenker det kan være greit å dekke dette også. Er flere som sikkert kunne ønske å gå denne veien. Er veldig fort kun backend og frontend type oppgaver (API og bruk av APIer) som dekkes i ulike fora og artikler, og embedded kan fort virke litt skummelt om man ikke helt vet hvor man vil begynne. Putter det her for å starte diskusjon om hva som bør dekkes under noe slikt, og kanskje inspirere flere 😄 (pluss hva fagområdet sin tittel bør være)

Konsepter det kan være verdt å nevne:

• IoT: Internet of things
• Terminologi: firmware, maskinkode, datamaskin-arkitektur osv.
• programmeringsspråk-linker til tutorials om C, Rust, assembly (x86, ARM, og evt. annet?) osv.

Jeg har i andre sammenhenger lest lærebøker hvor bøkene kommer seg selv i forkjøpet ved å bruke ord og uttrykk før de er introdusert. Dette kan være ganske frustrerende for den som er ny til stoffet. Dette er en lett felle å gå i som vi burde være oppmerksomme på når vi utarbeider innhold på koding.no.

Et eksempel på dette finnes på koding.no/opplaering i avsnittet om frontend-utvikling:

Frontend utviklere jobber på å implementere design og brukergrensesnitt, som regel nettsider og apper. Hvis du har et øye for design og liker å jobbe med brukergrensesnitt, så er frontend utvikling noe for deg.

Deler av jobben innebærer å jobbe med designere og UX-ere for å lage gode brukeropplevelser, og å jobbe med backend utviklere for å få systemene til å henge sammen.

Det er også viktig å ha god forståelse for hvordan brukere bruker systemene, og å teste at systemene er tilgjengelige og lette å bruke for alle mennesker, uavhengig av funksjonsevne.

Som helt ny ville jeg spurt meg selv "hva er en designer?", og jeg ville ihvertfall lurt på hva en "UX-er" er for noe. Det er ikke ment at denne saken kun skal handle om dette ene tilfellet, men heller ta opp et viktig poeng: La oss ikke bruke ord og uttrykk før vi har forklart hva de betyr. Kanskje denne saken kan være en samlesak for dette poenget.

Det blir etterhvert mange ord og uttrykk som skal forklares, og selv om vi forklarer det eller annet sted tenker jeg det kan være lurt å legge opp til at man enkelt kan navigere til betydningen av ting og tang. Kanskje vi kunne utviklet støtte for å trykke på enkelte ord som så leder brukeren frem til forklaringen slik som man gjør på Wikipedia f.eks?

Tanker?

Vi bør oppgradere til Docusaurus, og i samme slengen sjekke at spacing-tokens kommer inn i fra Infima.

• ℹ️ Upgrade to Docusaurus V3
• ℹ️ Infima Spacing Tokens

APIer er et ord som blir kastet fram og tilbake i den moderne utviklings-verdenen. Begrepet er allerede brukt i "Finn din fagområde" under "Opplæring" (der Backend står beskrevet). Mange kjenner REST APIer, og det er jo det det hintes til her. Burde vi kanskje forklart litt hva API betyr i ulike tilfeller? Selv selgere og aksjemeglere (les Finansavisen når tech selskaper er nevnt om du tviler) nevner APIer nå om dagen, og det kan til tider være vanskelig å vite hva denne siste gruppen mener når de bruker begrepet 😛

F.eks:

• Web API (REST, RPC osv.)
• API exposet i biblioteker? libCURL tilbyr jo C API for å gjøre http requests.
• Andre betydninger jeg overser fordi jeg er trøtt? 😛

Tenker meg kanskje i web tilfellet at vi kunne hatt en fin graf med noe ala: "Fronend applikasjon" -> "Server" -> "Database" eller lignende. Man kan nok trygt droppe å ha hvor dataen hentes fra. Kan kanskje være lurt å se den vanligste "API typen" for å øke foreståelsen til nybegynnere. Selv store selskaper lager fort denne type enkle CRUD-applikasjoner.