Re: Ny ide vattenbyte
Postat: 28 maj 2017, 05:39:14
Flödesschema är en utmärkt ingång för den ovana programmeraren att komma in i vilken typ av tänk som kan genomföras på programmerings-nivå, oavsett programmerings-språk.
Flödes-schema kan dessutom vara något som TS redan har erfarenhet av då det förekommer inom många yrkes-områden som inte har något alls med dator-programmering att göra, såsom bemanningslistor, beslutsprocesser mm. Inom industrin är det ett vanligt kvalitets-säkringsverktyg.
Vad somliga kanske inte känner till är att man kan köra in ett fungerande flödes-diagram direkt in i Arduinon utan att lära sej någon programkod alls. Här kan man läsa mer om den biten. Tveksamt om man vill göra så, men det går.
För programstruktur på industrinivå krävs ofta att den definieras i någon branch-standardiserad flödesstruktur, t.ex. UML som främst drivs av IBM, NEC och några fler.
Även här finns kompilatorer som översätter UML flödes-scheman direkt till C++ m.fl. språk.
Ett någorlunda genomtänkt uppritat program-flöde, kan relativt enkelt översättas till några satser "if..then..else" och någon loop på ett sätt som även nybörjaren inom programmering snabbt kan få grepp om.
Att börja med att skriva "if" direkt i källkoden utan att ha någon nedskriven planering på fortsättningen är inte bästa starten som nybörjare.
Normalt är nybörjar-gången för Arduino att man modifierar koden för att blinka en lysdiod i olika blinkmönster och sedan bygger på ytterligare erfarenhet i små steg.
I detta fallet är det lite mer direkt från kunskapsnivå noll till pang på rödbetan att styra och reglera sekvenser av händelser som kan ge många olika utfall.
Ska en nybörjare ha en chans till att åstadkomma något vettigt i en sådan situation är en planering som ger en grund-förståelse och fungerande stomme närmast ett krav och definitivt underlättande för TS. Möjligen underlättar det om någon godhjärtat plitar ihop hela koden åt TS så slipper han det helt.
OBS att det inte på något sätt menas nedsättande med "nybörjare" utan är mera att man ännu inte är mottaglig för det lite speciella program-tänket. Lite som att lära sej cykla, när det väl sitter är det enkelt. Har man väl fått förståelsen för det kantiga tänket "if..else" även måste hanterar fallen när man vill ha "lagom" av något så blir det lättare att förstå grunderna i program-flöden oavsett vilket språk det sedan ska skrivas i. Funktionsflöden med symboliska block ger nybörjaren en mjukstart samtidigt som flödes-scheman nästan är viktigare än själva programkoden i större projekt eller kodning med höga funktionalitetskrav, så det är ett bra verktyg för amatörer som vill få till bra kod och ett nödvändigt villkor för somliga yrkes-programmerare.
Att hantera även de lite oväntade händelserna som kan uppstå i ett datorprogram, kan man lära sej behovet av den hårda vägen.
Alternativt, det är ofta simpelt att för varje sensor-input analysera om värdet är rimligt, innan det används för att styra händelser. Sådant slarvas det med mycket på "amatör-sidan" men är inom andra områden en viktig bit av programmeringen.
Steget ovan, två helt skilda obetydliga sensor-avvikelser, kan tillsammans tyda på ett allvarligt problem som lätt missas om man inte i förväg förutsett scenariot i flödes-schemat.
Ingen mjukvara är perfekt eller löser alla problem-scenarion. Att komplettera mjukvarufunktion med funktion i hårdvara såsom bräddavlopp och pump-begränsningar är helt i sin ordning och är precis så man gör med apparater för att skapa säkerhet utöver den säkerhet man kan få "gratis" utfört i datorprogrammet i allt från enkla processorstyrda batteriladdare till stora NC-verktyg genom mekaniska berörings-skydd, eller mekaniskt utföra laddaren så att det inte går ansluta felvända batterier, trots att datorprogrammet kanske också analyserar polaritet innan laddning påbörjas.
Om yttre omständighet tillför funktion, så ska den också dokumenteras i flödes-schemat. Kan verka lite märkligt, men det finns åtskilliga händelser som visar hur fel det kan gå om den inte finns med.
Att nybörjaren lyckas till fullo nyttja ingående data för att höja drift och funktions-säkerhet och göra logiken 100% förutsedd är inte troligt, men medvetenhet om att man kan gå tillbaka till flödesdiagrammet för att se varför saker inte blev 100% vattentät logik från början är till stor hjälp att i efterhand fixa problem, om man fått det inbankat från början, att det är en väsentlig del av programmets dokumentation som bör utföras så väl att det verkligen överensstämmer med den kod man skrev. Det är omöjligt att skapa samma inblick i programmets funktion eller evt. brister genom att bara titta på källkoden, även om den är bra kommenterad direkt i koden.
Att god planering ger totalt den kortaste utvecklingstiden och tydligt dokumenterade och väl förutsedda flöden minskar buggar är knappast nytt och bör tilltala både erfarna programmerare såväl som andra mindre erfarna.
Skulle jag ge råd till TS, så är det att börja med att köpa ett Arduino-kit och köra första program-exemplet, att få en lysdiod att blinka. Det är en aha-upplevelse om man aldrig gjort det förr och behöver ingen planering eller ytterligare hårdvara, förutom en dator med USB-port. Lysdioden sitter troligen redan på kretskortet.
Fortsätt med t.ex. programkod för tidsstyrd multifärg lysdiods-belysning till akvariet som knappast har några större följder om man missar lite i programfunktionen, men ger insikt i behovet av planering för att kunna åstadkomma driftsäker tydlig och välfungerande program-struktur, som dessutom underlättar när man vill bygga ut med fler funktioner efterhand.
Somliga säjer att planering är överflödigt, man löser problemen allt eftersom. Ja det går ta sej fram den vägen om man nöjer sej med enklare självskrivna funktioner, har tid med svår-debuggad tveksam logik och undviker ge sej på att programmera något drifts-kritiskt. Kanske får en och annan svårspårad programkrasch också accepteras, då det är allt för komplicerat att leta efter buggar som visserligen kan vara rätt sett ur ren program-syntax men har tveksam logik, såsom "if kettle level == 0" som troligen oftast kommer fungera men ibland, när det bara finns en minimal mängd vatten i kannan, kan få förödande konsekvenser.
Vill man rita flödesdiagram direkt i datorn, se denna intron till ett gratis-program som hanterar bl.a. UML och som är ytterst enkelt att använda.
Det är mest om jobbet kräver det som jag själv skriver flödesscheman i datorn, men väldigt ofta på vanligt rutat papper, då man alltid hittar saker man annars missat även för relativt enkla program. Huvudflödena är lätta men det är det oväntade som kan vara svårt att förutse fulla effekten av utan analys av flödes-schema.
På grund av olika motbud är kanske TS villrådig, ska han sätta sej med penna och papper och skriva i klartext vilka funktioner och beslut datorprogrammet ska utföra på ett sådant sätt att det sedan kan översättas till tydlig och entydig datorkod, eller ska han hoppa direkt in i skrivandet av Arduino-koden och se om akvariestyrningen blir som han tänkt, utan föregående programmeringserfarenhet?
Skriva flödes-schema för några givare, en manöverpanel, en ventil och en pump, och kolla om logiken håller, det är kanske förlegat och overkill i Arduino-mljö som man hanterar snabbt och enkelt utan bekymmer om struktur?
Flödes-schema kan dessutom vara något som TS redan har erfarenhet av då det förekommer inom många yrkes-områden som inte har något alls med dator-programmering att göra, såsom bemanningslistor, beslutsprocesser mm. Inom industrin är det ett vanligt kvalitets-säkringsverktyg.
Vad somliga kanske inte känner till är att man kan köra in ett fungerande flödes-diagram direkt in i Arduinon utan att lära sej någon programkod alls. Här kan man läsa mer om den biten. Tveksamt om man vill göra så, men det går.
För programstruktur på industrinivå krävs ofta att den definieras i någon branch-standardiserad flödesstruktur, t.ex. UML som främst drivs av IBM, NEC och några fler.
Även här finns kompilatorer som översätter UML flödes-scheman direkt till C++ m.fl. språk.
Ett någorlunda genomtänkt uppritat program-flöde, kan relativt enkelt översättas till några satser "if..then..else" och någon loop på ett sätt som även nybörjaren inom programmering snabbt kan få grepp om.
Att börja med att skriva "if" direkt i källkoden utan att ha någon nedskriven planering på fortsättningen är inte bästa starten som nybörjare.
Normalt är nybörjar-gången för Arduino att man modifierar koden för att blinka en lysdiod i olika blinkmönster och sedan bygger på ytterligare erfarenhet i små steg.
I detta fallet är det lite mer direkt från kunskapsnivå noll till pang på rödbetan att styra och reglera sekvenser av händelser som kan ge många olika utfall.
Ska en nybörjare ha en chans till att åstadkomma något vettigt i en sådan situation är en planering som ger en grund-förståelse och fungerande stomme närmast ett krav och definitivt underlättande för TS. Möjligen underlättar det om någon godhjärtat plitar ihop hela koden åt TS så slipper han det helt.
OBS att det inte på något sätt menas nedsättande med "nybörjare" utan är mera att man ännu inte är mottaglig för det lite speciella program-tänket. Lite som att lära sej cykla, när det väl sitter är det enkelt. Har man väl fått förståelsen för det kantiga tänket "if..else" även måste hanterar fallen när man vill ha "lagom" av något så blir det lättare att förstå grunderna i program-flöden oavsett vilket språk det sedan ska skrivas i. Funktionsflöden med symboliska block ger nybörjaren en mjukstart samtidigt som flödes-scheman nästan är viktigare än själva programkoden i större projekt eller kodning med höga funktionalitetskrav, så det är ett bra verktyg för amatörer som vill få till bra kod och ett nödvändigt villkor för somliga yrkes-programmerare.
Att hantera även de lite oväntade händelserna som kan uppstå i ett datorprogram, kan man lära sej behovet av den hårda vägen.
Alternativt, det är ofta simpelt att för varje sensor-input analysera om värdet är rimligt, innan det används för att styra händelser. Sådant slarvas det med mycket på "amatör-sidan" men är inom andra områden en viktig bit av programmeringen.
Steget ovan, två helt skilda obetydliga sensor-avvikelser, kan tillsammans tyda på ett allvarligt problem som lätt missas om man inte i förväg förutsett scenariot i flödes-schemat.
Ingen mjukvara är perfekt eller löser alla problem-scenarion. Att komplettera mjukvarufunktion med funktion i hårdvara såsom bräddavlopp och pump-begränsningar är helt i sin ordning och är precis så man gör med apparater för att skapa säkerhet utöver den säkerhet man kan få "gratis" utfört i datorprogrammet i allt från enkla processorstyrda batteriladdare till stora NC-verktyg genom mekaniska berörings-skydd, eller mekaniskt utföra laddaren så att det inte går ansluta felvända batterier, trots att datorprogrammet kanske också analyserar polaritet innan laddning påbörjas.
Om yttre omständighet tillför funktion, så ska den också dokumenteras i flödes-schemat. Kan verka lite märkligt, men det finns åtskilliga händelser som visar hur fel det kan gå om den inte finns med.
Att nybörjaren lyckas till fullo nyttja ingående data för att höja drift och funktions-säkerhet och göra logiken 100% förutsedd är inte troligt, men medvetenhet om att man kan gå tillbaka till flödesdiagrammet för att se varför saker inte blev 100% vattentät logik från början är till stor hjälp att i efterhand fixa problem, om man fått det inbankat från början, att det är en väsentlig del av programmets dokumentation som bör utföras så väl att det verkligen överensstämmer med den kod man skrev. Det är omöjligt att skapa samma inblick i programmets funktion eller evt. brister genom att bara titta på källkoden, även om den är bra kommenterad direkt i koden.
Att god planering ger totalt den kortaste utvecklingstiden och tydligt dokumenterade och väl förutsedda flöden minskar buggar är knappast nytt och bör tilltala både erfarna programmerare såväl som andra mindre erfarna.
Skulle jag ge råd till TS, så är det att börja med att köpa ett Arduino-kit och köra första program-exemplet, att få en lysdiod att blinka. Det är en aha-upplevelse om man aldrig gjort det förr och behöver ingen planering eller ytterligare hårdvara, förutom en dator med USB-port. Lysdioden sitter troligen redan på kretskortet.
Fortsätt med t.ex. programkod för tidsstyrd multifärg lysdiods-belysning till akvariet som knappast har några större följder om man missar lite i programfunktionen, men ger insikt i behovet av planering för att kunna åstadkomma driftsäker tydlig och välfungerande program-struktur, som dessutom underlättar när man vill bygga ut med fler funktioner efterhand.
Somliga säjer att planering är överflödigt, man löser problemen allt eftersom. Ja det går ta sej fram den vägen om man nöjer sej med enklare självskrivna funktioner, har tid med svår-debuggad tveksam logik och undviker ge sej på att programmera något drifts-kritiskt. Kanske får en och annan svårspårad programkrasch också accepteras, då det är allt för komplicerat att leta efter buggar som visserligen kan vara rätt sett ur ren program-syntax men har tveksam logik, såsom "if kettle level == 0" som troligen oftast kommer fungera men ibland, när det bara finns en minimal mängd vatten i kannan, kan få förödande konsekvenser.
Vill man rita flödesdiagram direkt i datorn, se denna intron till ett gratis-program som hanterar bl.a. UML och som är ytterst enkelt att använda.
Det är mest om jobbet kräver det som jag själv skriver flödesscheman i datorn, men väldigt ofta på vanligt rutat papper, då man alltid hittar saker man annars missat även för relativt enkla program. Huvudflödena är lätta men det är det oväntade som kan vara svårt att förutse fulla effekten av utan analys av flödes-schema.
På grund av olika motbud är kanske TS villrådig, ska han sätta sej med penna och papper och skriva i klartext vilka funktioner och beslut datorprogrammet ska utföra på ett sådant sätt att det sedan kan översättas till tydlig och entydig datorkod, eller ska han hoppa direkt in i skrivandet av Arduino-koden och se om akvariestyrningen blir som han tänkt, utan föregående programmeringserfarenhet?
Skriva flödes-schema för några givare, en manöverpanel, en ventil och en pump, och kolla om logiken håller, det är kanske förlegat och overkill i Arduino-mljö som man hanterar snabbt och enkelt utan bekymmer om struktur?