Liebe Leute, wie testet man von Bewerbern am besten die Embedded-Fähigkeiten? Ich hatte kürzlich den Fall, dass Leute behaupten sie können was weiß ich alles und scheitern dann am einfachen Datenblatt-Lesen oder verstehen. Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded Programmieren können? Was mir spontan einfällt: -Referenzprojekte -Code Samples Wie macht Ihr das? Viele Grüße, Michael
als Embedded Entwickler sollte man meiner Meinung nach wissen wofür UART I2C CAN DMA FPU usw. stehen und Beherrschung von Bitmanipulationen.
Projekte auf GitHub sind gerne gesehen. Ansonsten, im Gespräch mit einem erfahrenen Entwickler über bisherige Projekte sollte das relativ schnell klar werden.
Michael H. schrieb: > Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded > Programmieren können? Daraus schließe ich, dass Du selber auch keine Ahnung von embedded hast?
Ich war bei einer Firma, die das hands-on festgestellt hat. Da gab es einen PC mit angeschlossenen Evaluation-Board, installierten Compiler, usw. Und da musste der Bewerber was einfaches porgrammieren und flashen, LED die mit bestimmter Frequenz blinkt. Eine Garantie war das aber auch nicht. >I2C CAN DMA FPU jein. Es gibt absolute Experten in 8-Bit und 16-Bit die nie was mit DMA gemacht haben.
J. W. schrieb: > Und da musste der Bewerber was einfaches porgrammieren und flashen, LED > die mit bestimmter Frequenz blinkt. Im Ernst!? Wie lange hat man dafür Zeit? Sprich, sich erstmal in die Doku einlesen etc?
J. W. schrieb: > Ich war bei einer Firma, die das hands-on festgestellt hat. > Da gab es einen PC mit angeschlossenen Evaluation-Board, installierten > Compiler, usw. > Und da musste der Bewerber was einfaches porgrammieren und flashen, LED > die mit bestimmter Frequenz blinkt. > > Eine Garantie war das aber auch nicht. > Genau, man sollte sich nämlich neben dem dabei herausgekommenen Code (auch grausig zusammengefrickelter Code kann eine LED zum Blinken bringen - so nach dem Motto aussen hui und innen pfui) auch ansehen, wie der/die BewerberIn an die Sache rangeht. Dann kann der Test sogar etwas bringen.
* hier ist ein 30 zeilen code snippet, welche Fehler finden sie? * schreiben sie einen algorithmus, welcher die gesetzen bits in einem vektor zählt. * wie bringen sie eine led mit frequenz x oder duty cycle y zu blinken, welche verschiedenen realisierungswege gibt es, welche vor und nachteile hat jeder? * was für projekte haben sie in der vergangenheit realisiert, welche probleme hatten sie, wie sind sie die probleme angegangen und wie haben sie diese gelößt. * etwas näher über die fähigkeiten aus dem lebenslauf/bewerbungsschreiben ein gehen, Stm M. schrieb: > als Embedded Entwickler sollte man meiner Meinung nach wissen wofür UART > I2C CAN DMA FPU usw. stehen und Beherrschung von Bitmanipulationen. Kommt hin, aber nach 2/3 meines elektronik studiums habe ich immer noch nichts mit DMA gemacht. Man muss hier einfach etwas in die tiefe gehen und schaun ob man die Grenzen des Wissens des Bewerbers finden kann.
Wichtig bei solchen Aufgabenstellungen ist es, den Internetzugang zu sperren, damit die Leute tatsächlich gezwungen sind das Datenblatt zu lesen, und nicht nur Lösungen aus einem Forum kopieren! Ein schönes kleines Beispiel wäre auch die Ansteuerung eines Schieberegisters o.ä. per SPI. Wenns am Ende nicht funktioniert ist das ja auch nicht so schlimm - wenn man schon nahe an der Lösung dran ist aber nur irgendwo ein Bit falsch ist kann man das ja auch gelten lassen. Man könnte auch ein fehlerhaftes Programm stellen, und den Bewerber den Fehler suchen lassen, mithilfe eines Debuggers und eines Oszilloskops - man sollte ja beides bedienen können...
Michael H. schrieb: > wie testet man von Bewerbern am besten die Embedded-Fähigkeiten? Ohne Bewerbungsunterlagen, mit Zeugnissen, aus dem das hervorgeht? Gewöhnlich lädt man die ohne doch gar nicht erst ein. Eigentlich sollte man dich testen oder wenigstens zur Verantwortung ziehen. > Ich hatte kürzlich den Fall, dass Leute behaupten sie können was weiß > ich alles und scheitern dann am einfachen Datenblatt-Lesen oder > verstehen. Als Chef, Personaler oder was? Das du als Zugehöriger dieser Interessengruppe ausgerechnet hier die überwiegende Zahl von Arbeitnehmern fragst, stimmt schon etwas nachdenklich. Woher willst du denn wissen, wer dir antwortet, der darin Erfahrung hat? > Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded > Programmieren können? Fehlt nur noch ein Eignungstest. Sollen die AN künftig unternehmerische Risiken übernehmen? Dann müssen die AN aber auch irgend welche Vorteile bekommen. Nix gibts umsonst, höchstens leere Versprechungen. Nach meinen Beobachtungen wissen die AG meist gar nicht was sie wollen und wenn man Ausschreibungen liest, vermisst man signifikante Angaben, wie z.B. welche Controllerfamilie erwartet wird und einiges mehr. Alles wirkt wie anreizlos abgespeckt, aber der AG will entscheiden über Schicksale wie ein König. Und so ein König soll einen nachher folgenhaft bewerten?
Michael H. schrieb: > Ich hatte kürzlich den Fall, dass Leute behaupten sie können was weiß > ich alles und scheitern dann am einfachen Datenblatt-Lesen oder > verstehen. Ich hoffe für Dich, dass die Attitüde, die diese Formulierung rüber bringt, nicht wirklich auf Dich zutrifft. Denn Du zeigst hier, dass es Dich einen Kehricht interessiert, was Deine Arbeitnehmer wirklich können ("was weiß ich") und dass Du nicht bereit bist ihnen Entwicklungsmöglichkeiten zuzugestehen. Gerade beim Lesen von Datenblättern übersieht oder miss-interpretiert man leicht mal ein entscheidendes Detail - selbst wenn es sich um ein gut gemachtes Datenblatt handelt. Sich dann im Nachhinein großkotzert hinzustellen und die grundsätzliche Kompetenz des Arbeitnehmers in Frage zu stellen, ist natürlich bequem. Statt Deine Fachkraft zu fördern schmeißt Du sie dann lieber weg. Als nächstes kommt dann wohlmöglich noch das Herbeireden eines Fachkräftemangels. Hoffentlich liege ich total falsch. Denn ansonsten kann ich Deinen Arbeitnehmern nur wünschen, dass Du als Arbeitgeber möglichst schnell vom Markt verschwindest, statt sie zu verschleißen.
Moin, eine viel wichtigere Frage wäre: Wie checkt man die Fähigkeiten von 'Managern', die im Embedded Bereich Entwicklungen leiten oder beratend tätig sind. Denn die richten deutlich den grösseren Schaden an, als mal ein junger Entwickler, der sich aufgrund seiner guten Bologna-Note etwas selbst überschätzt. Die Frage des TO alleine macht mir diesbezüglich schon etwas Kopfschmerzen... Meine Lieblingstest war: - Irgend ein Assembler-Snippet hinlegen: Was könnte das machen? - Bei den Eltechnikern: Kirchhoffsche-Regel abchecken (kein Witz!) - C-Klassiker kommentieren lassen, wie unten (erst WRITE, dann READ, und wo steckt die Gefahr) Mir war immer wichtig, dass die Leute zeigen, dass sie Fehler aufspüren und sich 'reinhacken' können. Alles andere lernt man dementsprechend schnell.
1 | int func(int mode, int *v) |
2 | {
|
3 | static int c; |
4 | switch (mode) {
|
5 | case WRITE: |
6 | c = *v; break; |
7 | case READ: |
8 | *v = c; break; |
9 | } |
10 | |
11 | return 0; |
12 | } |
Ich bin auch schon überprüft wurden. Vor dem Interview musste ich schon Basis-Aufgaben in C lösen, kniffliges aber einfaches Zeug, z.B. Pointer auf Pointer, was aber jeder mittelmäßiger C-Programmierer wissen müsste. Nach 30min Interview wurde ein Nerd-Programmierer dazugerufen. der befragte mich über Posix-Funktionen, wie sie im Buch Advanced Programming in the Unix Environment (Richard Stevens) beschrieben sind. Ich kannte das Buch, kannte auch die Funktionen, aber mir fielen sie nicht namentlich ein, da ich 10 Jahre nicht damit gearbeitet habe. In (embedded) Linux benutzt das fast keinen mehr, da haben sich andere Sachen etabliert. Ergebnis: Absage wegen mangelnden Kenntnissen in Embedded Linux.
Michael H. schrieb: > wie testet man von Bewerbern am besten die Embedded-Fähigkeiten? Kann man nicht, also das Potential was ein Bewerber mitbringt um nach beliebige Länge und Intesivität von Einarbeitung/Schulung zu leisten im Idealfall vermag ist IMHO nicht in 1h VG belastbar abtestbar. Was man aber testen kann, ist was der Bewerber bisher gelernt/Getan hat und was er davon praktisch umsetzen kann. Einfach mal im Rollenspiel mit Alltagstypischen Szenarien konfrontieren. Der Compiler meckert "variable used before assigned" - wie verfährst du mit dieser Meldung? Die Firma entwickelt Kaffeemaschinen, es kommt ein Anruf: Bei Kundex mit der Firmware geht nix mehr" - was sind deine nächsten Schritte Erklären sie Besonderheiten der Nutzerinterface Button, Poti, drehencoder Was sind soft-Buttons. Was bewacht der Watchdog? was nicht? Vorschlag für einen build-In-selbst-test der Kaffeemaschine? Wann ist die Firmware schnell genüg? Von Frisch-Absolventen würde ich mehr Basics erklären, bspw. Ablauf/Steuerung IRQ und bei der Abschlussarbeit bezüglich embedded Programmierung nach Details fragen lassen. Bspw was so die 3 dicksten bugs waren und wie diese erkannt worden.
Teddy schrieb: > J. W. schrieb: >> Und da musste der Bewerber was einfaches porgrammieren und flashen, LED >> die mit bestimmter Frequenz blinkt. > > Im Ernst!? > Wie lange hat man dafür Zeit? Sprich, sich erstmal in die Doku einlesen > etc? Doku einlesen? check den ordner /examples oder grep die *.h nach dem string gpio - da sollte man 1,2,3 die Funktion zum Pin-wackeln finden.
> Vorschlag für einen build-In-selbst-test der Kaffeemaschine?
Denglish oder Engleutsch?
Michael H. schrieb: > Wie macht Ihr das? Wenn ich als Kandidat um so etwas gebeten werde, biete ich einen "Schnuppertag" im Rahmen einer freiberuflichen Beauftragung an. Das ist aber ganz gewiss nicht kostenlos für das Unternehmen. Irgendwelche "Testereien" am Tisch gibt es nicht. Machen sowieso nur kleine Klitschen, die sich die Probezeit nicht leisten können.
Ordner schrieb: > Kann man nicht, also das Potential was ein Bewerber mitbringt um nach > beliebige Länge und Intesivität von Einarbeitung/Schulung zu leisten im > Idealfall vermag ist IMHO nicht in 1h VG belastbar abtestbar. Ich denke ein paar Basics kriegt man als erfahrener Entwickler auf jeden Fall von einem Uni-Abgänger heraus. Bei Spezialisten ist es teils schon kniffliger, denen muss man auch oft nachsehen, dass sie trotz PhD einfach gewisse Grundlagen vergessen haben. Das Problem ist, dass heutzutage schon in vielen Mittelständlerfirmen die IoBS-Schwafler und HR-Top-Psychologen die Weichen stellen und kaum selber in der Lage sind, richtig gute Fragen zu stellen, da sie selber nie im Dreck gewühlt haben. Ganz toll ist es dann, wenn nach 'nuernberger' die Nerds mit einbezogen werden, die Pi auf 240 Stellen auswendig können und eine Wahnsinns-Menschenkenntnis zur Schau stellen. Und so stehen sich viele Firmen, die 'händeringend suchen' und das Fachkräftemärchen propagieren, eigentlich selber im Weg und müssen dann auf ebenso wasserkochende Personalvermittler zurückgreifen, um ihr Zeug irgendwie halbbatzig auf die Kette zu kriegen und faktisch ihre eigenen Management-Verkrustungen damit umgehen.
Schnitzel12345 schrieb: > Wenn ich als Kandidat um so etwas gebeten werde, biete ich einen > "Schnuppertag" im Rahmen einer freiberuflichen Beauftragung an. > > Das ist aber ganz gewiss nicht kostenlos für das Unternehmen. Und dafür meldest Du Dich extra beim Finanzamt als Selbständiger an und holst Dir vorher bei Deinem bisherigen Arbeitgeber eine Genehmigung dafür ein (brauchst Du normalerweise)? Wenn Du das nicht machst, darfst Du keine Rechnung für diesen einen tollen Schnuppertag stellen. Das Risiko für solche Probleme liegt mittlerweile beim beauftragenden Unternehmen, gerade die Sozialversicherungen machen da regelmäßig Prüfungen. Muss also sauber sein, sonst geht es nicht. > Irgendwelche "Testereien" am Tisch gibt es nicht. Dann wärst Du bei meinem Arbeitgeber raus. Wir haben ein paar kleine Programme mit Fehlern oder Unschönheiten drin, jeweils 1-2 Seiten ausgedruckt. Der Bewerber soll die Fehler finden bzw. erkennen und erklären warum das unsauber ist und verschiedene Alternativen diskutieren. > Machen sowieso nur > kleine Klitschen, die sich die Probezeit nicht leisten können. nicht leisten können? Ich sehe eine Kündigung in der Probezeit als allerletzten Ausweg an: Der neue Arbeitnehmer kündigt seinen bisherigen Job, zieht um etc. und steht dann nach ein paar Tagen vor dem Nichts. Das macht man nicht eben mal, nur weil man zu eitel war im VG vielleicht 30 Min kleine Probeaufgaben zu lösen.
Michael H. schrieb: > Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded > Programmieren können? Klassiker: http://www.rmbconsulting.us/a-c-test-the-0x10-best-questions-for-would-be-embedded-programmers > Was mir spontan einfällt: > -Referenzprojekte > -Code Samples Hauptproblem dabei: professionell ersteller Code ist in der Regel Eigentum des AG, so daß der AN da keine Samples vorweisen kann/darf. Zwar kann man in der Freizeit Opensource-Projekte machen, aber die sind dann meistens nicht professionell, sondern mehr quick&dirty. Weil's für den Eigenbedarf und den Nutzungsfall halt reicht. Und selbst WENN man gute OSS-Projekte hat, hilft das wenig, wenn man nicht den gesamten Code komplett selber geschrieben hat, weil der neue AG das dann ja auch nicht sieht. Bei größeren OSS-Projekten arbeiten aber mehrere dran, und sei es nacheinander. Und selbst WENN man ein gutes OSS-Projekt als Einmannshow hat, hilft das nicht, denn dann ist man raus, weil teamunfähig. Außerdem guckt sich sowieso kein AG ernsthaft OSS-Projekte an, wo viel Code einsehbar wäre, weil das ja zu lange dauert. Die Inkompetenz sitzt hier in der HR, die von der Materie sowenig Plan haben, daß sie nichtmal Fachleute von Blendern unterscheiden können - und sich deswegen auf das Abhaken von Checklisten konzentrieren. Würde man bei Taxifahrern genauso vorgehen, dann bekäme ein Taxifahrer keinen Job, wenn er Erfahrung mit Mercedes-Taxis hat, aber leider ein Fahrer für ein VW-Taxi gesucht wird.
Strubi schrieb: > int func(int mode, int *v) > { > static int c; > switch (mode) { > case WRITE: > c = *v; break; > case READ: > *v = c; break; > } > > return 0; > } Und was soll daran jetzt problematisch sein?
(klar, wenn v in den Wald zeigt, kann das undefiniertes Verhalten geben, aber das ist bei Pointerfehlern ja normal.)
Nop schrieb: > Außerdem guckt sich sowieso kein AG ernsthaft OSS-Projekte an, wo viel > Code einsehbar wäre, weil das ja zu lange dauert. Also mir persönlich reicht eine Datei, um sich den Stil mal anzuschauen. Da kann man schon mal die Pragmatiker von den K&R-Häretikern trennen :-) Ansonsten finde ich es auch interessant, wie jemand bei offenen Projekten die Bug-Reports handhabt, denn die blockierenden Egos in einem Team sind oft die, die nie die Bugs bei sich sehen, aber sich weigern, mal 'gcc -S' bei ihrem C++-Konstrukt zu machen um zu schauen, was wirklich dabei herauskommt. Sowas hat schon eine Firma in die Insolvenz getrieben (und ja, ich war dabei :-/ )
Nop schrieb: > Strubi schrieb: > .. > > Und was soll daran jetzt problematisch sein? In der Form nix :-). Und ich gehe davon aus, dass du auch erklären könntest, warum/wo's knallt, wenn mans anders macht.
Nop schrieb: > Strubi schrieb: > >> int func(int mode, int *v) >> { >> static int c; >> switch (mode) { >> case WRITE: >> c = *v; break; >> case READ: >> *v = c; break; >> } >> >> return 0; >> } > > Und was soll daran jetzt problematisch sein? Kein NULL-Pointer check. Kein default. Da immer 0 returned wird, kann man auch gleich void nehmen. ? mfg
Nop schrieb: > Strubi schrieb: > >> int func(int mode, int *v) >> { >> static int c; >> switch (mode) { >> case WRITE: >> c = *v; break; >> case READ: >> *v = c; break; >> } >> >> return 0; >> } > > Und was soll daran jetzt problematisch sein? Richtig problematisch sehe ich nix. Aber warum einen Returnwert, wenn nur 0 zurückgegeben werden kann? -> weg damit. Auf mode wird nie schreibend zugegriffen -> const. Wenn man ein bißchen pseudo Typsicherheit vorgaukeln wollte, könnte man einen enum aus dem mode machen. Dann kann einem so mancher Compiler darauf hinweisen, wenn man einen case vergisst. Natürlich kann man in v irgendeine wild gecastete Adresse auf nicht alloziierten Speicher rein werfen und damit beliebig Unfug treiben. Der Code ist nicht threadsicher. Wollte man das z.B. auch aus einem Mix Hauptroutine / Interrupt aufrufen, sollte man c als volatile deklarieren. Das sind so Punkte, die ich ansprechen würde, wenn man mir dieses Snippet in einem VG vorsetzte. Vielleicht noch die Anmerkung, dass ich persönlich zwar nichts davon halte break in die gleiche Zeile wie die Operation zuvor zu schreiben. Aber wenn das Firmen-Style ist achselzuck kann ich auch mit leben.
Felix F. schrieb: > Kein NULL-Pointer check. Und schon trennt sich Spreu von Weizen. Diesen Job bekomme ich wohl nicht. :)
Nop schrieb: > Strubi schrieb: > >> int func(int mode, int *v) >> { >> static int c; >> switch (mode) { >> case WRITE: >> c = *v; break; >> case READ: >> *v = c; break; >> } >> >> return 0; >> } > > Und was soll daran jetzt problematisch sein? Och ein Krümelkacker kackt dir da einen großen Haufen vor die Füß: Schlecht lesbar da: -Kommentare fehlen -Leerzeile nach variablen Deklaration fehlt -Deklaeration von WRITE und Mode fehlt -uneinheitliches setzen von '{' - mal eizeln auf einer Zeile, mal am Zeilende -kryptische identifier wenigstens das spacing ist gut. unsicher da: -keine Überprüfung der Eingangsgrößen -nichtsagnder Return-wert -mglw Verwendung von Makros (WRITE/READ) besser wäre mode als enum zu deklarieren. Misc Kritiken: -Header (Autor, filename, Erstelldatum, Copyright) fehlt. Code hinterlässt den Eindruck das der Autor tippfaul oder ungeübt im Umgang mit der Tastatur ist. PS: Wär Ironie-tags braucht soll sie selber setzen.
Strubi schrieb: > Also mir persönlich reicht eine Datei, um sich den Stil mal anzuschauen. > Da kann man schon mal die Pragmatiker von den K&R-Häretikern trennen :-) Und woher weißt Du, wer den Code überhaupt geschrieben hat? Gerade bei OSS sind ja normalerweise mehrere Urheber dabei, selbst bei Einzelprojekten, außer man entwickelt wirklich alles from scratch. > Ansonsten finde ich es auch interessant, wie jemand bei offenen > Projekten die Bug-Reports handhabt Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier: https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/ Andererseits kann man auch keinen Support verlangen, wenn man nichts bezahlt. Jeder gute Wille vom Maintainer ist schon eine Großzügigkeit seinerseits und keine Verpflichtung. Das solltest Du auch bedenken, wenn Du bei offenen Projekten darauf schaust, wie mit bug reports umgegangen wird - das kann sich sehr davon unterscheiden, wie dieselbe Person reagiert, wenn man ihr Geld für das Fixen anbietet.
Gut, den Returnwert könnte man ändern. Const setze ich nur bei Pointern, weil's da für den Aufrufer auch wichtig ist, ob der Buffer sich ändern darf oder nicht. Nullpointercheck mache ich embedded nie, weil ich wegen Speicherfragmentierung und Laufzeitvarianzen ohnehin kein malloc und Konsorten verwende. Pointer sind damit entweder statisch allozierter Speicher oder Adressen von Stack-Objekten - in beiden Fällen nicht NULL. Und aus einem Interrupt heraus würde ich so eine Funktion mit unnötigem Switch eh nicht aufrufen, sondern das direkt in irgendeinen geeigneten Buffer schreiben. Aber der Punkt mit Threadsicherheit ist gut - als Metaller denkt man da nicht sofort dran. Nicht heavy metal, sondern bare metal. ;-) Naja und ein Misra-Checker könnte den fehlenden default anmeckern.
Herbört schrieb: > Der Code ist nicht threadsicher. Wollte man das z.B. auch aus einem Mix > Hauptroutine / Interrupt aufrufen, sollte man c als volatile > deklarieren. Da hätte ich jetz gesagt: denken Sie nochmal drüber nach, ob das "volatile" wirklich hilft. Oder: wo lebt 'c'. Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf das "static" eingeht (Das fehlt nämlich in Slide n-1). Ordner schrieb: > -uneinheitliches setzen von '{' - mal eizeln auf einer Zeile, mal am > Zeilende Auch wenn noch so viel Ironie drinstecken soll: Unterscheide zwischen Funktion und Statement... Aber wo's in die Richtung geht, ist viel Religion (Gnu vs. K&R vs. Linux kernel) dabei. Da wird's auch wieder interessant für beide Seiten (AN/AG), ob sich jemand auf Coding-Style fokussiert und dabei das Ziel vergisst. Nop schrieb: > Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier: > https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/ Kompletter nonsense-Artikel von den ersten Zeilen weg (TL;DR). Sorry. Opensource heisst nicht kostenlos, das wissen Firmen durchaus.
Michael H. schrieb: > Liebe Leute, > > wie testet man von Bewerbern am besten die Embedded-Fähigkeiten? Indem man die richtigen Fragen stellt. Wie kann man die richtigen Fragen stellen? Indem man selbst entsprechende Embedded-Fähigkeiten hat.
Strubi schrieb: > Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf > das "static" eingeht (Das fehlt nämlich in Slide n-1). Ja wenn's fehlt, ist das Ergebnis des Lesens von c natürlich undefiniert. Mit static nicht, auch nicht wenn man das erst mit READ und dann mit WRITE aufruft, weil c eine globale Variable (mit lokalem Scope) ist, die gemäß C-Standard implizit mit 0 initialisiert wird. > Opensource heisst nicht kostenlos, das wissen Firmen durchaus. Klar, wenn mit Opensource hier z.B. gemeint ist, daß Intel-Entwickler an Linux mitarbeiten. Natürlich kann Intel die anweisen, was sie wo implementieren, dokumentieren und fixen sollen. Aber die kleineren Projekte sind eben kostenlose Freizeitprojekte, an die man nicht denselben Anspruch stellen darf (wenngleich man mitunter positiv überrascht wird). Anyway, eine gute Frage wäre, was schon für interessante embedded-spezifische Bugs erlebt hat. Mein Liebling: Absturz beim Hochfahren in einer Routine, die auf dem PC tadellos gelaufen war. Letztlich lag es daran, daß beim Konfigurieren wegen eines Drehers im define einer Mode-Maske aus Versehen ein Teil des RAMs in den powerdown versetzt wurde. Blöderweise lag da der Stack drin.
Strubi schrieb: > Da hätte ich jetz gesagt: denken Sie nochmal drüber nach, ob das > "volatile" wirklich hilft. Hihi, stimmt, nützt eigentlich gar nix. Konkurrierende Schreibzugriffe können sich func immer noch gegenseitig unterbrechen. Da bräuchte es schon einen richtigen Mutex. Hat man den aber, dann ist das volatile bestenfalls nutzlos, sonst ein Zeitfresser. > Aber lustig, das Thema NULL-Pointer kommt öfter auf, als dass jemand auf > das "static" eingeht (Das fehlt nämlich in Slide n-1). Ich hielt gerade das für den Clou: Eine Art Accessor, der es schafft in C so eine Art 'private' Variable zu verkapseln. Würde man c außerhalb der Funktion deklarieren, könnte man zwar getrennte getter / setter implementieren. Aber alle anderen Funktinen dieser Datei hätten auch Zugriff. Mit dieser lokalen statischen Variable nicht. Letztendlich ist das aber ein rein akademisches Beispiel. Ohne dass eine richtige Motivation da ist - warum sollte ich gerade im Embedded Umfeld - den Zugriff auf eine Variable kapseln? Deswegen: Weg mit mode, func, return, switch. Macht eine einfache Sache sinnlos kompliziert.
Strubi schrieb: > Ordner schrieb: >> -uneinheitliches setzen von '{' - mal eizeln auf einer Zeile, mal am >> Zeilende > > Auch wenn noch so viel Ironie drinstecken soll: Unterscheide zwischen > Funktion und Statement... Eigentlich nicht, entweder "braces stand alone" oder eben nicht. aber nie gemischt. http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf > Aber wo's in die Richtung geht, ist viel Religion (Gnu vs. K&R vs. Linux > kernel) dabei. Da wird's auch wieder interessant für beide Seiten > (AN/AG), ob sich jemand auf Coding-Style fokussiert und dabei das Ziel > vergisst. Ganz meine Meinung, die Frage ist immer nach dem Zweck/Sinn. Aber es soll Bereiche geben da sin Formalismen Krümekacker gern gesehen (QS), auch wenn es wirklichen kein Zugewinn am Produktnutzen,-wartbarkeit bringt. Trotzdem könnte man sich der Code Style Knute beugen - wenn's den Chef glücklich macht ...
Nop schrieb: > Nullpointercheck mache ich embedded nie, weil ich wegen > Speicherfragmentierung und Laufzeitvarianzen ohnehin kein malloc und > Konsorten verwende. Pointer sind damit entweder statisch allozierter > Speicher oder Adressen von Stack-Objekten - in beiden Fällen nicht NULL. > > Und aus einem Interrupt heraus würde ich so eine Funktion mit unnötigem > Switch eh nicht aufrufen, sondern das direkt in irgendeinen geeigneten > Buffer schreiben. > > Aber der Punkt mit Threadsicherheit ist gut - als Metaller denkt man da > nicht sofort dran. Nicht heavy metal, sondern bare metal. ;-) Genau, es ist explizit nach einem Test für Embedded gefragt, da zählt Kenntnisse in IRQ, und alles was man für Bare Metal braucht (BootUp Code, Systeminitialisierung). Um das zu prüfen ist das oben gezeigte Code schnipselchen nur partiell geeignet. Vielleicht sollte man von Bewerber auflisten lassen, was zur essentialen Initialisierung eines Controllers gehört, also -Stackpointer setzen -Pin modes konfigurieren -IRQ konfigurieren -powermodes konfigurieren -WDT enablen und was der Bootloader so treibt. Oder ist dergleichen aus dem Kenntnissschatz des heutigen Embedded Programmieres entschwunden?
Moin, Nop schrieb: > Ja wenn's fehlt, ist das Ergebnis des Lesens von c natürlich > undefiniert. Mit static nicht, auch nicht wenn man das erst mit READ und > dann mit WRITE aufruft, weil c eine globale Variable (mit lokalem Scope) > ist, die gemäß C-Standard implizit mit 0 initialisiert wird. Da frage ich jetz nochmal nach: Wo lebt 'c'? Das fiese an dem non-static szenario ist, dass die Routine sogar stabil laufen kann, wenn wir mal die Defaults aussen vor lassen, d.h. ein READ nach einem WRITE bringt immer das richtige Resultat, ausser, wenn... (oder gerade nur dann, wenn...) Und was die Initialisierung angeht, meine Gegenfrage: In welchem Segment würde 'c' landen, und wäre sie wirklich 100% initialisiert? Wie nachprüfen? Herbört schrieb: > Hihi, stimmt, nützt eigentlich gar nix. Konkurrierende Schreibzugriffe > können sich func immer noch gegenseitig unterbrechen. Da bräuchte es > schon einen richtigen Mutex. Hat man den aber, dann ist das volatile > bestenfalls nutzlos, sonst ein Zeitfresser. Da käme dann die Frage, ob die Zugriffe noch atomisch (oder atomar) sind, aber das ist dann recht fortgeschritten und ginge auf die Architektur ein. Herbört schrieb: > Letztendlich ist das aber ein rein akademisches Beispiel. Ohne dass eine > richtige Motivation da ist - warum sollte ich gerade im Embedded Umfeld > - den Zugriff auf eine Variable kapseln? Deswegen: Weg mit mode, func, > return, switch. Macht eine einfache Sache sinnlos kompliziert. Nee, das ist überhaupt kein akademisches Ding, sogar sehr konkret aus einem bare-metal OS, natürlich in der auf 'lazy programming' runtergestrippten Fassung, aber im Prinzip läuft der Zugriff so. Ähnliches ist beim Dauerbrennerthema um Coroutinen oder Proto-Threads der Fall, wo man sich gerne und oft ähnlich ins Knie schiessen kann, und das viel weniger explizit als oben. Ordner schrieb: > Eigentlich nicht, entweder "braces stand alone" oder eben nicht. aber > nie gemischt. Wer konsequent nach K&R programmiert, unterscheidet eben genau so Funktionen von Statements, siehe Linux-Kernelsource. Und Linus' Dogma dürfte bekannt sein... Immer wieder ein nettes Thema. Da gibt's noch so einen (auf die Gefahr hin, Öl ins Feuer zu giessen):
1 | int func(void *p); |
2 | |
3 | // oder |
4 | |
5 | int func(void* p); |
Bei div. Projekten gibt's automatisierte Erziehungsmethoden, dass der Code-Beauty-Checker schlicht die Annahme beim "svn commit" verweigert, wenn solche logischen Böcke drin sind. Nur wenn jemand prinzipiell nur mit Emacs im (IMHO hinderlichen, da schlecht lesbar) Gnu-Coding style entwickeln will, kann man ihn höchstens noch zu einer brauchbaren Library mit sauber dokumentierter API motivieren, obige Erziehungsmethoden kommen dann nicht gut. Denn der Fall dass einer schreit, dass er den Code vom Kollegen aus der andern Liga nicht anfasst, gibt's halt doch öfters. Das ist dann wieder ein anderes Thema: Wie kriegste raus, wie gut der Kollege im Team funktioniert oder nur SCRUM-Bullshit von sich gibt. So am Rande: Vor ein paar Jahren wurde ich mal gefragt, wie ich im 'vi' einen Zeile einrücke. Fand die Frage gut, und die Antwort fand wohl auch der AG gut, d.h. 'PASS'. Ordner schrieb: > Genau, es ist explizit nach einem Test für Embedded gefragt, da zählt > Kenntnisse in IRQ, und alles was man für Bare Metal braucht (BootUp > Code, Systeminitialisierung). Um das zu prüfen ist das oben gezeigte > Code schnipselchen nur partiell geeignet. Ich finde es als 'fuzzy' Vortest schon mal gut, weil erstaunlich ist, wieviele hard-core Embedded-Hacker sich darin verirren. Das Thema mit dem IRQ/Threads lässt sich damit auch abhaken, siehe Herbörts Einwurf. Hingegen lässt sich ein klassischer Embedded-Fragebogen gut auswendig lernen oder einfach Uni-Wissen/Arduino-Praxis wiedergeben. Einen Target konfigurieren ist schliesslich "Datenblatt lesen". Aber Fehler aufspüren - das was im Projekt am meisten Risiko birgt - braucht ne Ecke mehr an tiefgehendem Verständnis.
Bei Berufsanfängern bietet es sich an, über die Masterarbeit zu sprechen (vorher darüber informieren!). Dort kann man dann auch rein fragen, wie was gelöst wurde und man erfährt dann schnell, ob der Bewerber nur oberflächliches Blabla kann oder auch technisch tief drinnen war während der Arbeit.
Der Poster, Michael H. (Gast), hat etwas viel zuwenig Ahnung, was Fachkunde, Personalfuehrung ung Management angeht. Allenfalls mal ein Praktikum ueberdenken? Ah... dies ist das Praktikum. Nee, das Praktikum von der anderen Seite natuerlich.
Beitrag #5028392 wurde von einem Moderator gelöscht.
Herbört schrieb im Beitrag #5028392: > Aber warum? Wenn jemand so einen Aufwand macht, dann hat das einen > Grund. Und der muss gut sein um diese erhöhte Komplexität, Nachteile in > nebenläufiger Verarbeitung und Inkaufnahme von > Performanceverschlechterung zu rechtfertigen. Es geht dabei eigentlich um Handler zu bspw. Betriebsparametern ("Property handler"), eigentlich ein ganz aktuelles IoT-Thema. Sagen wir, du willst ein i2c-Register ins LAN exportieren und brauchst dazu ein Framework oder meinetwegen "OS". Wo sollen da oben die Nachteile sein? Der Zugriff ist genau an einem Ort geregelt und der Overhead eines Funktionsaufrufs ist wohl kaum der Rede wert...
Bei komplexen Projekten tauscht man Ueberblick und Wartbarkeit gegen aufwendigeren Code. Bei Verwendung von Libraries nimmt der Aufwand des Codes wieder ab, sofern man die Libraries ueberblickt. Deswegen sind Echtzeitkernel, oder Echtzeit OS ab einer gewissen komplexitaet des Projektes effektiv vereinfachend und erhoehen die Wartbarkeit gegenueber einem Ansatz mit mehreren Zustandsmaschinen
Strubi schrieb: > Da frage ich jetz nochmal nach: Wo lebt 'c'? c ist eine globale Variable, deren Scope auf die Funktion begrenzt ist. Mit static liegt C nicht auf dem Stack, sondern im BSS-Segment (ZI), und das wird gemäß C-Standard genullt. Daher ist C, da static, sauber initialisiert, auch ohne explizites Nullen bei der Deklaration. Dennoch würde ich explizit hinschreiben "static int c = 0", denn erstens ist c dann immer noch initialisiert, wenn man das static wegnimmt (das Lesen ergibt dann eben immer 0), und zweitens ist es freundlicher für nachfolgende Programmierer, wenn man Dinge explizit statt implizit macht. Wenn der irgendwann unter hohem Zeitdruck einen Bug suchen muß, erleichtert es seine Arbeit, wenn er nicht auch noch die Implizitheiten des C-Standards dabei berücksichtigen muß. > Und was die Initialisierung angeht, meine Gegenfrage: In welchem Segment > würde 'c' landen, und wäre sie wirklich 100% initialisiert? Wie > nachprüfen? c landet im BSS-Segment, genauer gesagt unter ZI. Die Initialisierung prüft man daher einfach per Mapfile. Man sollte natürlich außerdem auch seinen Startupcode prüfen, ob der den ZI-Bereich wirklich nullt und die Kopierschleife für die initialisierten globals beinhaltet. Auf dem PC wird das von der Runtime automagisch gemacht, embedded ist das der Teil zwischen dem Sprung zum Resetvektor und dem Aufruf von main(). > Da gibt's noch so einen (auf die Gefahr hin, Öl ins Feuer zu giessen): > > int func(void *p); So mache ich das immer. Denn dann weiß man daß der Stern zur Variablen gehört, und dann ist auch offensichtlich, daß bei
1 | int *a, b; |
b eben ein Integer und kein Pointer ist. In die Falle laufen übrigens auch gerne Leute rein, die Pointerstrukturen mit define statt typedef definieren. Wobei ich das trotzdem auf zwei Zeilen aufteilen würde, weil ich es lieber habe, wenn Pointer separat deklariert sind. > Das ist dann wieder ein anderes Thema: Wie kriegste raus, wie gut der > Kollege im Team funktioniert oder nur SCRUM-Bullshit von sich gibt. Menschenkenntnis - das, was eine Führungspersönlichkeit am dringendsten braucht. Fachdetails muß sie nicht draufhaben, dafür stellt sie ja die Fachleute ein, aber schon genug Verständnis, um den Übeblick zu behalten. > So am Rande: Vor ein paar Jahren wurde ich mal gefragt, wie ich im 'vi' > einen Zeile einrücke. Fand die Frage gut, und die Antwort fand wohl auch > der AG gut, d.h. 'PASS'. LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß man da eh nicht würde anfangen wollen.
> > LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur > Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß > man da eh nicht würde anfangen wollen. "Ich hasse xxx" hinterlässt natürlich keinen besonders guten Ersteindruck, was Teamfähigkeit etc. angeht. Ich würde es so formulieren: "Ein Editor ist ein Werkzeug, und ich interessiere mich mehr für das Ergebnis als das Werkzeug. Wenn ein Werkzeug eine Einarbeitungszeit von einem Monat benötigt, wo man in notepad++ zum Herausfinden derselben Funktionalität zwei Minuten benötigt, wird das Werkzeug zur Selbstbeschäftigung und damit zum Hindernis zur Produktentwicklung." Hier gibt es zwei Möglichkeiten: Entweder man punktet mit Pragmatismus, oder man ist (wie Du schon selber schreibst) bereits in einem Umfeld angekommen, in dem die Selbstbeschäftigung Teil der Firmenkultur ist, und damit ist schon klar, dass es beidseitig nicht gut funzen wird.
Beitrag #5028470 wurde von einem Moderator gelöscht.
Moin, Nop schrieb: > LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur > Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß > man da eh nicht würde anfangen wollen. Hm. Ein vi applet ist in busybox drinnen, von notepad++ oder eclipse applets hab' ich noch nix gehoert... Gruss WK
gnugnu schrieb: > "Ich hasse xxx" hinterlässt natürlich keinen besonders guten > Ersteindruck, was Teamfähigkeit etc. angeht. Ja gut, im Bewerbungsgespräch sollte man schon etwas auf Hochglanz machen für den ersten Eindruck, das stimmt. Bei KMUs allerdings erheblich weniger als bei Großkonzernen. Dergute W. schrieb: > Hm. Ein vi applet ist in busybox drinnen, von notepad++ oder eclipse > applets hab' ich noch nix gehoert... Das ist auch das Einzige, wozu ich vi überhaupt gelegentlich nutze - wenn ich mich z.B. per SSH irgendwo einwähle und da mal eben ein, zwei Settings in irgendeiner Konfig-Datei anpasse. Für ernsthaftes Editieren finde ich das UI dermaßen daneben, daß ich die Datei lokal bearbeiten und dann hochladen würde. Einen Job, wo ich den ganzen Tag mit vi texten müßte, überlasse ich gerne vi-Liebhabern (die es ja auch gibt). Bonuspunkte könnte man allerdings wohl sammeln, wenn man vi zu einfach findet und lieber gleich mit TECO loslegt. ;-)
Nop schrieb: > Daher ist C, da static, sauber > initialisiert, auch ohne explizites Nullen bei der Deklaration. In der Praxis ist es auf vielen Plattformen nicht initialisiert, mir wäre neu, dass das der olle C-Standard abdeckt. Denn die Initialisierung des .bss is nicht Sache des Compilers sondern der crt0.. Nop schrieb: > In die Falle laufen übrigens > auch gerne Leute rein, die Pointerstrukturen mit define statt typedef > definieren Beim typedef kommt die 'falsche' Notation auch ab und an vor. Was man nach K&R wohl hören will, ist, dass die Philosophie von C die einer Prototypen-orientierten Sprache ist. Demnach gehört der *-Dekorator zur Variable und nicht zur Datentyp-Deklaration. Konrad schrieb im Beitrag #5028470: > Ein i2c Register ins Lan exportieren zu wollen halte ich eigentlich > ohnehin für einen Fail. Das ist zu low-level und müsste eher durch ein > höheres Protokoll gekapselt werden. Tja, genau das macht das Framework, und da macht der asynchrone Co-Routinen-Ansatz Sinn, das Snippet sieht dann allerdings komplexer aus, da gibts dann nich mehr READ/WRITE sondern QUEUE/POLL, usw. Aber das ginge jetzt zu sehr ins Detail. Macht euch bloss nich ins Hemd, es ist nur ein Beispiel. Aber offenbar auch ein ergiebiges, wie die Diskussion zeigt. Und die Frage "warum so kompliziert" somit voll legitim. Nop schrieb: > LOL Nichts gegen Fun-Fragen, aber wenn da ein "ich hasse vi" zur > Ablehnung geführt hätte, wären das dermaßen verkehrte Prioritäten, daß > man da eh nicht würde anfangen wollen. Ich glaube, du verkennst die Prioritäten :-) Das "Hass"-Wort kommt schnell mal von den Wohlfühlprogrammierern mit grossem Ego, die sich früher oder später als wenig teamfähig herausstellen. Aber lieber ehrlich als irgend ein aufgesetztes Google-Blabla, dann weiss man gleich Bescheid. Schlussendlich will halt der "Chef", dass du in dem Firmenoekosystem "funktionierst". Wenn nicht, passt's eben nicht, dafür vielleicht woanders.
Wie kann man überhaupt auf die Idee kommen mit dieser vi-Frage auf die Fähigkeiten des Bewerbers zu schliessen? Welche Liebslingfarbe hat ihr Mauspad wäre genauso dämlich. Das ist ja sowas von strunzedoof. Da sitzt wohl der Fail auf der anderern Seite des Tisches. Bewerbungsgespräche führen sollte man auch können, die andere Seite überschätzt sich hier regelmässig masslos und es werden die dümmsten Fragen mit dubiosen Begründungen gerechtfertigt. Ich halte auch diese Testfragen mit Codesnippets usw. für wenig aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik intus habe, lediglich die fremde Situation verwirrt mich mehr unter der sie stattfinden. Sitze ich an einer IDE und code an einem realen Projekt fallen solche Fehler sofort auf und mache sie erst gar nicht. Ob einer was taugt merkt man innerhalb der Probezeit an einem realen Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren passender Entwicklererfahrung bewirbt, da gilt es doch nur noch zu schauen ob der menschlich ins Team passt, ne Nervensäge ist oder nicht,... und auch das kann man nur zuverlässig herausfinden wenn man mit dem mal drei Wochen unter Realbedingungen arbeitet. Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder gelaufen, der reinste Affenzirkus ist das nur noch.
Michael H. schrieb: > Gibt es irgendwas, um abzuchecken, dass Leute wirklich embedded > Programmieren können? Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt durchziehen lassen. Ein Thermometer mit einer gemultiplexten LED-Anzeige wäre ein nettes Beispiel. Zur Erweiterung lässt man zusätzlich noch eine einfache Uhrenfunktion einbauen. Ruhig reichlich Beispielcode bereitstellen, so dass man sich die Lösung daraus weitestgehend zusammenbasteln kann. Man kann auch ein günstiges Eval-Board zum Einarbeiten zu Hause bereitstellen.
Der TE meldet sich nicht mehr zu Wort. Ich muss sagen, dass der Kollege hier überrannt, überfordert wurde. Sicherlich hat er sich etwas ungeschickt ausgedrückt. Und man kann davon ausgehen, dass er kein Techniker ist. Aber autentische Antworten gibt es nun zu genüge. Jetzt muss der Kollege gucken, was er damit anfangen kann. My 2 Cent: Ich würde mir einen Techniker dazu holen, der den Bewerber etwas auf den Zahn fühlen kann. Wenn der AG vom TE eine große AG ist, dann kann man sich sicherlich auch leisten, nur nach Spitzenkanditaten zu gucken, da wäre der Personaller aber sicherlich etwas professioneller und würde nicht in so einem Forum nach Antworten suchen. Ansonsten muss nehmen was kommt und ggf. einfach mal investieren. Dabei sollte man sich im Umgang mit den qualifizierten Fachkräften nicht allzu doof anstellen, denn imho sind die schneller wieder weg, als einem lieb ist. Die Bezahlung ist hier nur ein Argument von vielen(Arbeitsklima, Kollegen, Aufgabengebiet, Verantwortung, Karriere....)
Strubi schrieb: > In der Praxis ist es auf vielen Plattformen nicht initialisiert Auf welchen genau? Klar, wenn man embedded einen kaputten Startup-Code hat, dann kann man solche Probleme schonmal haben. Dann wird aber auch explizite Initialisierung nicht mehr weiterhelfen, auch nicht explizit mit 0 initialisieren. Denn der Compiler verfrachtet globale Variablen, die explizit mit 0 initialisiert werden, auch ins ZI-Segment. Es wird also nicht im ROM der Init-Wert 0 abgelegt, und diese Variablen werden auch nicht in der Kopierschleife im Startup initialisiert. Spart halt ROM. Die explizite Initialisierung mit 0 richtet sich lediglich an nachfolgende Maintenance-Programmierer, der Übersicht halber. > wäre neu, dass das der olle C-Standard abdeckt. Denn die Initialisierung > des .bss is nicht Sache des Compilers sondern der crt0.. Der C-Standard weiß nichts von Stack und BSS und wer da was umsetzt, der beschreibt nur Verhalten. Section 6.7.8 Initialization of C99 standard (n1256): If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then: — if it has pointer type, it is initialized to a null pointer; — if it has arithmetic type, it is initialized to (positive or unsigned) zero; — if it is an aggregate, every member is initialized (recursively) according to these rules; — if it is a union, the first named member is initialized (recursively) according to these rules. > Schlussendlich will halt der "Chef", dass du in dem Firmenoekosystem > "funktionierst". Wenn nicht, passt's eben nicht, dafür vielleicht > woanders. In einem Ökosystem, in dem man ernsthaft vi als Entwicklungsumgebung benutzen muß, möchte ich auch gar nicht funktionieren. Es ist dann für beide Seiten gut, wenn man sich da so frühzeitig einig wird, daß man nicht zusammenpaßt. Was hingegen durchaus OK ist, das ist der Pin-Debugger, die embedded-Entsprechung des altehrwürdigen printf-Debuggers.
Klaus Maus schrieb: > Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder > gelaufen, der reinste Affenzirkus ist das nur noch. Like....;-)
Schreiber schrieb: > Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt > durchziehen lassen. Es geht aber bei einer Bewerber-Entscheidung auch die Leute zu finden, die das Potential zum Programmierer haben, aber noch nicht haben, weil sie gerade das Studium beendet haben und die Programmierfähigkeiten noch nicht entwickelt haben. Die könnten so ein Fun-Projekt allerdings nicht durchziehen. Das ist ein Problem: die Firmen wollen nur Leute, die das geforderte schon aus dem ff können. Absolventen mit Potential haben oft keine Chance.
Schreiber schrieb: > Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt > durchziehen lassen. Klar doch. Urlaub nehmen zum Probearbeiten.
Klaus Maus schrieb: > Ich halte auch diese Testfragen mit Codesnippets usw. für wenig > aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik > intus habe, lediglich die fremde Situation verwirrt mich mehr unter der > sie stattfinden. Sitze ich an einer IDE und code an einem realen Projekt > fallen solche Fehler sofort auf und mache sie erst gar nicht. Also wer in einem Schnupperinterview nicht in der Lage ist ohne Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter Projektdruck. > schauen ob der menschlich ins Team passt, ne Nervensäge ist oder > nicht,... und auch das kann man nur zuverlässig herausfinden wenn man > mit dem mal drei Wochen unter Realbedingungen arbeitet. Ooch, unter wohldosierten Stress zeigen die Bewerber ihr wahres Gesicht. Und bei manchen genügt die Vorstellung mit dem vi arbeiten zu dürfen zu einer veritablen Stresssituation. Die Frage ist, wie handelt der Bewerber bei bevorstehenden Kontrollverlust - agiert er iritiert, ratlos, verängstigt? Oder bleibt er professionell und handelt rational nach seinen Möglichkeiten (sucht proaktiv Hilfe oder Alternative Lösungen).
Beitrag #5028608 wurde von einem Moderator gelöscht.
Beitrag #5028618 wurde von einem Moderator gelöscht.
Ordner schrieb: > Oder bleibt er professionell und handelt rational > nach seinen Möglichkeiten (sucht proaktiv Hilfe oder Alternative > Lösungen). "Proaktiv". Die rationale Lösung ist, sich eine andere Firma zu suchen, in der man nicht mit Steinzeittools arbeiten muß, und in der man auch nicht schon beim Einstellungstest mit Psychospielchen beharkt wird. Kurzum, Firmen, in denen der Fachkräftemangel nicht schon in der Personalabteilung anfängt. Das sind übrigens dann Firmen, in denen man sich eher für detailierte Kenntnisse des C-Standards als für vi-Fähigkeiten interessiert. ;-)
Angehängte Dateien:
-
C-Init-TI.png
94 KB
@Nop (Gast) >> In der Praxis ist es auf vielen Plattformen nicht initialisiert >Auf welchen genau? Klar, wenn man embedded einen kaputten Startup-Code >hat, dann kann man solche Probleme schonmal haben. Dem TMS320/PICCOLO von TI. Da muss man sich die Nullung ergoogeln 8-0 Da hat TI auch ein wenig gepennt. Warum packen die das nicht in ihre Beispielprogramme rein, von denen es ja reichlich gibt? Denn alle globalen/statischen Variablen im Quelltext explizit mit Null zu initialisieren ist nicht nur nervig, es verbraucht auch Speicher im Flash. >Dann wird aber auch >explizite Initialisierung nicht mehr weiterhelfen, auch nicht explizit >mit 0 initialisieren. Doch, zumindest bei TI, denn die explizit initialisierten Variablen werden initialisiert. Siehe Anhang, aus dem Dokument SPRU514G–December 2013
Es gibt Absolventen, und dort muss man auf das Potential schauen. Wie schnell verstehen sie neue Dinge. Und dann gibt es noch welche, die koennen zwar Code schreiben, haben aber von Projekten keine Ahnung. Und dann gibt es noch welche, die koennen das alles. Die Frage ist was man will. Und dann sollte man auch die Evaluation anpassen. Etwas Code schreiben, oder verstehen .. was soll das ? Ist sowas von Nichtssagend. Der Frage des Posters nach zu urteilen, wollen sie den Billigsten, da sie eh keine Ahnung haben. Das wird auf die Laenge dann der Teuerste. Denn der muss wahrscheinlich alleine durch die ganze Lernkurve.
Falk B. schrieb: > Dem TMS320/PICCOLO von TI. Da das im Startupcode reingehört, liegt es beim Entwickler, für eine C-Standard-konforme Umgebung zu sorgen. Das sind ein paar Zeilen Assembler in der Resetroutine, und die muß man als embedded-Entwickler auch problemlos schreiben können, weil das Programm embedded nicht erst bei main() beginnt. Die Note von TI sagt das auch ganz deutlich. Andere C-Compiler wie beispielsweise GCC tun das ebenfalls nicht, weil es nicht der Job des Compilers ist. Als embedded-Entwickler darf man sich ohnehin nicht auf den vom Hersteller gelieferten Democode verlassen, weil der meistens nur zur Verdeutlichung des manuals dient und nicht als production code. Das ist eben einer der Unterschied zwischen Entwicklung auf dem PC und embedded, jedenfalls für bare-metal embedded. Mit einem OS wie embedded Linux braucht man sich darum natürlich nicht zu kümmern, weil man da eine crt hat, die das tut. > Doch, zumindest bei TI, denn die explizit initialisierten Variablen > werden initialisiert. Nur die, welche man im Quelltext als Anweisungen initialisiert, oder auch die, welche schon bei der Definition initialisiert werden?
Strubi schrieb: > Nop schrieb: >> Bei vielen Opensource-Projekten: durch Ignorieren. Siehe hier: >> > https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/ > > Kompletter nonsense-Artikel von den ersten Zeilen weg (TL;DR). Sorry. > Opensource heisst nicht kostenlos, das wissen Firmen durchaus. Im Gegenteil, sehr schlüssig, gehaltvoll, sorgfältig mit Quellen und funktionierenden links belegt. Wer solche Urteile meint fällen zu dürfen wie Du, sollte sich schon einer genau so gewissenhaften, glaubhaften und sorgfältig recherchierten Argumentationsweise bemühen. Das Wegwischen mit einem scheinbar einzig und Allein auf Grund deiner anderen Meinung beruhenden Pauschalsatz qualifiziert nicht.
@ Nop (Gast) >> Dem TMS320/PICCOLO von TI. >Da das im Startupcode reingehört, liegt es beim Entwickler, für eine >C-Standard-konforme Umgebung zu sorgen. Unsinn!! Das muss der Hersteller der Toolchain liefern! Alle anderen Compiler /IDEs können das doch auch! >Das sind ein paar Zeilen Assembler in der Resetroutine, und die muß man >als embedded-Entwickler auch problemlos schreiben können, Ob ich das KANN ist gar nicht die Frage, sondern ob ich es WILL!!! Warum soll sich JEDER Compilernutzer immer wieder um den gleich Krümelkram kümmen. Außer irgendwlechen Freaks will das keiner! > weil das >Programm embedded nicht erst bei main() beginnt. Bei mir meistens schon, und das hat gereicht. Die wenigsten Anwendungen müssen sich ihren eigenen Startup-Code selber schnitzen. Wozu? >Die Note von TI sagt das auch ganz deutlich. Toll. Denkst du, ich les mir erst SÄMTLICHE Doku durch, ehe ich anfange? > Andere C-Compiler wie >beispielsweise GCC tun das ebenfalls nicht, weil es nicht der Job des >Compilers ist. Siehe oben. Der avr gcc "mutet" das seinen Anwendern nicht zu. Und die Könner dürfen sich jederzeit eigenen Startup-Code schreiben. >Als embedded-Entwickler darf man sich ohnehin nicht auf den vom >Hersteller gelieferten Democode verlassen, weil der meistens nur zur >Verdeutlichung des manuals dient und nicht als production code. Er sollte aber nicht irreführend sein! >> Doch, zumindest bei TI, denn die explizit initialisierten Variablen >> werden initialisiert. >Nur die, welche man im Quelltext als Anweisungen initialisiert, oder >auch die, welche schon bei der Definition initialisiert werden? Auch die, welche bei der Definition initialisiert werden.
Nop schrieb: > "Proaktiv". Die rationale Lösung ist, sich eine andere Firma zu suchen, > in der man nicht mit Steinzeittools arbeiten muß, und in der man auch > nicht schon beim Einstellungstest mit Psychospielchen beharkt wird. > Ehrlich gesagt höre ich lieber noch "hasse vi". Wer einen aktuellen 'gvim' als Steinzeittool bezeichnet, hat ein bisschen was verpasst. Ich erwarte von einem Kandidaten, dass er schon mal effizient coden kann und mir nicht Eclipse-Code-Completion als Geschwindigkeitsvorteil verkauft.. Im beschriebenen Fall auf der anderen Seite der Nahrungskette hatte die Frage eine ganz andere Motivation als die meisten hier so zu denken scheinen, ich lasse das aber mal offen. > Kurzum, Firmen, in denen der Fachkräftemangel nicht schon in der > Personalabteilung anfängt. > > Das sind übrigens dann Firmen, in denen man sich eher für detailierte > Kenntnisse des C-Standards als für vi-Fähigkeiten interessiert. ;-) Im konkreten Fall dieser Firma interessiert man sich auch dazu noch dafür, ob jemand die Feinheiten zwischen ELF-Standard (.bss) und C-Standard kennt und in der Lage ist, beweisbaren, robusten Code zu entwickeln. Das andere ist Handwerkszeug, und ja, wer seine Liebe zu Emacs glaubwürdig demonstriert, darf auch Emacs. Klaus Maus schrieb: > Diese ganze Bewerbungszirkus ist doch heute völlig aus dem Ruder > gelaufen, der reinste Affenzirkus ist das nur noch. Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0 Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich mal gar nicht auf... Nur ist die Gegenmassnahme in den HR-Abteilungen total pervertiert worden (meinetwegen zu "Psychospielchen"). Im Prinzip will man non-intrusiv provozieren, weiss nur manchmal nicht ganz, wie, oder es kommt als so misstrauensdotiert rüber, dass man gleich rückwärts ausm Raum rollen möchte. Aber im Gegenzug ist es damit auch ganz legitim, den Arbeitgeber ebenso zu provozieren und früh abzuklopfen, wie er mit der Waffe Humor als Konfliktlösungsmethode umgehen kann, oder rein mit Hierarchie-Gehorsam und Druck operiert oder sich die religiösen Egos in einem akademischen Kindergarten austoben. Als Fachspezi, den man unbedingt haben muss, hat man allenfalls einen gewissen Guru-Heimvorteil, aber man ist auch als erster weg, wenn die Firma mal einen Neustart machen muss oder verkauft wird, oder es mit den Egos eskaliert. Wir hatten mal einen Frischling angestellt, der zunächst fachlich so mittel schien, aber v.a.: schön rotzfrech (aber nicht arrogant) und eiserne Nerven bei den pythonesquen Fragen. War bereichernd. So abgesehen davon: Der Job soll ja auch Spass machen.
gnugnu schrieb: > Im Gegenteil, sehr schlüssig, gehaltvoll, sorgfältig mit Quellen und > funktionierenden links belegt. Wer solche Urteile meint fällen zu dürfen > wie Du, sollte sich schon einer genau so gewissenhaften, glaubhaften und > sorgfältig recherchierten Argumentationsweise bemühen. Das Wegwischen > mit einem scheinbar einzig und Allein auf Grund deiner anderen Meinung > beruhenden Pauschalsatz qualifiziert nicht. Sagen wir mal so: Es ist mir zu blöd, Edition 20 eines überlangen Beitrags zum Linuxkindergarten, der sich zudem noch einzelne Sachen rauspickt um journalistische Qualität zu suggerieren, im Detail zu kommentieren. Ist sowieso Off topic. Wenn so eine aufmerksamkeits-erheischende Überschrift, dann will ich auch was zu GNU und Konsorten lesen. Sonst wisch ich's - mit Verlaub - weg.
Beitrag #5028859 wurde von einem Moderator gelöscht.
Bürovorsteher schrieb im Beitrag #5028859: > Softwerker sind ja noch viel schlimmere Selbstdarsteller, Großmäuler und > Wichtigtuer, als ich es bisher annahm. > Es hat offenbar seinen Grund, weshalb ich alles in FPGA-Hardware mache. Das liegt nur daran, das sich jeder der einmal "Hello world" in Python geschrieben hat, als Softwareexperte sieht. Bei FPGAs ist das ein bisschen schwieriger ;) mfg
Falk B. schrieb: > Unsinn!! Das muss der Hersteller der Toolchain liefern! Nein, denn für den Startupcode ist man nunmal selber verantwortlich. Genau wie für Interruptroutinen und sowas. Das ist halt embedded, sehr hardwarenah. > Ob ich das KANN ist gar nicht die Frage, sondern ob ich es WILL!!! Warum > soll sich JEDER Compilernutzer immer wieder um den gleich Krümelkram > kümmen. Außer irgendwlechen Freaks will das keiner! Weil der Startupcode auch immer wieder andere Sachen beinhaltet, ist ja nicht nur das Speichernullen. Alles, was man vor main() so braucht. > Bei mir meistens schon, und das hat gereicht. Die wenigsten Anwendungen > müssen sich ihren eigenen Startup-Code selber schnitzen. Wozu? Weil man bei bare metal die volle Kontrolle über das System hat und deswegen aber auch für alles verantwortlich ist. Hat man embedded Linux, dann geht das natürlich allein schon von der Menge her nicht mehr, das ist klar. > Toll. Denkst du, ich les mir erst SÄMTLICHE Doku durch, ehe ich anfange? Nee, aber ich würde erwarten, daß Du den Startupcode, sofern welcher mitgeliefert wird, Dir erstmal durchliest, um das kennenzulernen. Da geht das Programm schließlich los. Wenn da keine Nullungsschleife ist, dann ist das doch offensichtlich. Man darf von einem Entwickler doch erwarten, sein Arbeitswerkzeug zu kennen. Embedded ist eben hardwarenah und nicht wie auf dem PC. Doku nicht lesen, Code nicht lesen und sich dann beschweren, daß was nicht läuft.. merkwürdig. Ich lese ja bei einem Projekt mit unbekannter Hardware auch erstmal das Datenblatt des Controllers, Programming Manual mitsamt Befehlssatz und Erratasheets. Normal. > Auch die, welche bei der Definition initialisiert werden. Dann muß ja jedenfalls die Kopierschleife implementiert sein. Ist das in irgendner crt, die nur als Objektcode da ist, oder ist das Assembler-Startupcode?
Strubi schrieb: > Ich erwarte von einem Kandidaten, dass er schon mal effizient coden kann > und mir nicht Eclipse-Code-Completion als Geschwindigkeitsvorteil > verkauft.. Das ist doch völlig irrelevant, weil beim Coden nicht die Tippgeschwindigkeit entscheidend ist. > Im konkreten Fall dieser Firma interessiert man sich auch dazu noch > dafür, ob jemand die Feinheiten zwischen ELF-Standard (.bss) und > C-Standard kennt Nunja, daß selbiger die Initialisierung nunmal vorschreibt, was sich dann in der Implementierung z.B. im BSS-Segment äußert, ist nunmal so. Übrigens sagen viele Leute, mich eingeschlossen, auch dann BSS, wenn es gar nicht ELF ist. "better save space" ;-) > und in der Lage ist, beweisbaren, robusten Code zu entwickeln. Jepp. Wobei das Coden noch die vergleichsweise einfache Tätigkeit ist. Viel schwieriger ist es, festzulegen, was genau denn implementiert werden soll, und welche Wechselwirkungen es dabei mit anderen Systemen gibt. > Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0 > Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich > mal gar nicht auf... Och menno, gerade wo es unterhaltsam werden könnte. :-) > Im Prinzip will man > non-intrusiv provozieren, weiss nur manchmal nicht ganz, wie, oder es > kommt als so misstrauensdotiert rüber, dass man gleich rückwärts ausm > Raum rollen möchte. Da kann man mit ein wenig Phantasie viel bessere Ergebnisse erzielen. Wenn die Simulation lautet "Chef macht mich saublöd an", ist meine Reaktion "der hat Führungsdefizite". Was aber realistisch sein kann: aufgebrachte Kunden. Aufgebracht, weil das Produkt nicht funktioniert, wie es soll. Die sind aber nicht einfach nur psycho, und das muß man daher auch nicht demütigst erdulden, sondern da gibt's einen realen Kern. In so einem Fall kann man den Kunden erstmal da abholen, wo er steht, ihm das Gefühl geben, daß er ernstgenommen wird, und dann das Gespräch auf die technische Ebene führen. Also laß mal nen Kollegen, der so einen Kunden simuliert, im Besprechungsraum anrufen. Und das dann auch gleich noch auf englisch.
Sapperlot W. schrieb: > Der Frage des Posters nach zu urteilen, wollen sie den Billigsten, da > sie eh keine Ahnung haben. Das wird auf die Laenge dann der Teuerste. > Denn der muss wahrscheinlich alleine durch die ganze Lernkurve. Nur die harten kommen in den Garten. Ungeklärt ist, welche süssen Früchte den Ankömmling im Garten denn erwarten.
Übrigens, mal interessehalber gefragt, falls noch Leute mitlesen, die sowas mitentscheiden - wenn ein Bewerber ein nennenswertes embedded-Projekt in Opensource vorweisen kann: - Würdet Ihr Euch das überhaupt näher anschauen? - Worauf würdet Ihr achten? - Würdet Ihr Euch wirklich die Mühe machen, auch Sourcen anzusehen, um einen Eindruck von den Fähigkeiten zu bekommen? - Falls ja, worauf würdet Ihr dabei schauen? - Welche Rolle würde Doku spielen? - Wäre Github ausreichend, oder wäre eine dedizierte Webseite vorzuziehen? - Falls Letzteres, wäre auch das eigentlich ja recht themenfremde Webdesign ein Kriterium? - Falls ja, inwiefern?
Klaus Maus schrieb: > Ich halte auch diese Testfragen mit Codesnippets usw. für wenig > aussagekräftig. Daran scheitere ich meist auch obwohl ich die Thematik > intus habe, lediglich die fremde Situation verwirrt mich mehr unter der > sie stattfinden. > > Ob einer was taugt merkt man innerhalb der Probezeit an einem realen > Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen > absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren > passender Entwicklererfahrung bewirbt, Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße oder hat über seine Berufserfahrung gelogen. Bei einem Absolventen ist das vielleicht noch verständlich, aber nach 1000 Arbeitstagen mit regelmäßigen Code-ungang nicht. Und es ist einfach diese Fehlleistung abzustellen. Täglich eine Stunde Code ohne Hilsmittel schreiben, dann hat man das nach ein paar Wochen drauf und kommt auch unter Bewerbungs-Stress klar. Ganz nervöse Fälle sollen sich von Arzt was für die Beruhigung verschreiben lassen.
Berufsrevolutionär schrieb: > Klaus Maus schrieb: > >> >> Ob einer was taugt merkt man innerhalb der Probezeit an einem realen >> Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen >> absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren >> passender Entwicklererfahrung bewirbt, > > Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche > keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße > oder hat über seine Berufserfahrung gelogen. > Bei einem Absolventen ist das vielleicht noch verständlich, aber nach > 1000 Arbeitstagen mit regelmäßigen Code-ungang nicht. > Definiere "fehlerfrei." Wenn Deine Aussage wahr wäre, gäbe es in Betrieben, in denen ausschliesslich oder federführend erfahrene Programmierer sitzen, keine bugs mehr. Faszinierend. In DIE Parallelwelt möchte ich mal reinschnuppern.
Ordner schrieb: > Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch > nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter > Projektdruck. Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die Wände.
Klaus Maus schrieb: > Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden > runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu > Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein > Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die > Wände. Ok, da stimme ich voll zu, Prüfungssituationen nerven, ev. bis zum Trauma (nicht ironisch gemeint). Genau da liegt der feine Grat zwischen Psychospiel und nettem Interview. Das meinte ich ansich mit "non-intrusiv": Den Kandidaten "messen", aber nicht negativ beeinflussen, sich aber im Gegenzug auch nicht blenden lassen. Ich denke, sowas geht, auch mit so einem unauffällig plazierten Codesnippet. Wenn sich alle einig sind, dass es kein wahr oder falsch gibt und man sich nur kennenlernen möchte, ist ne Menge Druck raus. Nop schrieb: > Das ist doch völlig irrelevant, weil beim Coden nicht die > Tippgeschwindigkeit entscheidend ist. Naja, wenn einer umständlich mit Maus und Rechtsklick anfängt, Code zu kopieren, und 'YP' zu kryptisch findet... Das meine ich eben mit Handwerkszeug und das merkt man dann in den heissen Phasen ("Hackathon" an der Anlage) schon. Nop schrieb: >> Der Affenzirkus ist nötig geworden, weil einer Menge Leute mit 1.0 >> Abschluss einiges an Kenntnissen fehlt. Das Geschichten-Fass mach ich >> mal gar nicht auf... > > Och menno, gerade wo es unterhaltsam werden könnte. :-) Mach doch n neuen Thread auf. Einen hab ich in kurz, allerdings nur aus erster Hand: Kollege hatte einen PhD vor sich sitzen, der das Ohmsche Gesetz nicht zusammenbekam. (War wohl kein Einzelfall).
Es kam mal ein sehr guter Bewerber, der schon beim Herumführen in der Abteilung sagte (beim Interview war ich nicht dabei), was hier alles suboptimal ist, und was er viel besser machen würde (modernere SW-Tools). Er war wirklich sehr gut, aber er ging (bzw wurde gegangen, wurde nicht gesagt) schon nach einem 1/2 Jahr. Er hat immer alles mögliche kritisiert und ständig auf Unzulänglichkeiten der bestehenden Implementationen hingewiesen. Wenn jemand "zu gut" ist und "zu viel" kann, dann ist es auch nichts. Eigentlich gibt es den perfekten Programmierer/Bewerber gar nicht.
Klaus Maus schrieb: > Ordner schrieb: >> Computeraufbereitung Quelltexte zu verstehen , kann das sicher auch >> nicht mit IDE-Unterstützung im Büro voll mit Störgeräuschen und unter >> Projektdruck. > Ist eher die prüfungsartige Situation, da gehen bei mir die Rolläden > runter. Ob es im Büro laut ist stört mich eher weniger, das hat mich zu > Anfangszeiten mal genervt bin da inzw. relativ schmerzfrei, ausser ein > Handwerker malträtiert irgendwo im Haus mit ner Hilti den ganzen Tag die > Wände. Aber irgendwie musst Du schon Deine prinzipielle Eignung bei der Vorstellung nachweisen! Kein Fahrprüfer gibt dir nach verpatzter Prüfungsfahrt den Führerschein nur auf die bloße Beteuerung hin, das du nur zum Prüfungstermin versagst aber die anderen 364 Tage des Jahres brillierst. Und wer weis was die Prüfungspanik in Dir auslöst und ob diesen Auslöser sicher eliminierten kann. Manchen genügt das Bewusstsein das andere jederzeit die Arbeit begutachten könnten und stürzen deshalb in Versagensängste ab.
J. W. schrieb: > Es kam mal ein sehr guter Bewerber, der schon beim Herumführen in der > Abteilung sagte (beim Interview war ich nicht dabei), was hier alles > suboptimal ist, und was er viel besser machen würde (modernere > SW-Tools). Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen, ist nicht gut. (abgeleiteter Schluß aus dem Grundsatz "A fool with a tool is still a fool").
Ordner schrieb: > Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen, > ist nicht gut. Japp. Deswegen stanzen wir auch immer noch Lochkarten. Weil, das haben wir schon immer so gemacht.
Rumple schrieb: > Ordner schrieb: >> Ein Entwickler der auf modische SW-Tools setzt um es besser zu machen, >> ist nicht gut. > > Japp. Deswegen stanzen wir auch immer noch Lochkarten. Weil, das haben > wir schon immer so gemacht. Nö, deswegen benutzen wir gcc und Shell-script weil die uns die Kontrolle übern den Code und Effizienz wiedegeben, die uns die Comfort-IDE für Voll-dummies genommen haben. Und wissen das es nicht die Tools sind die die Software besser macht sondern der gescheite Umgang mit diesen. Und das diese Lernprozess nicht mit dem bloßen Einkauf/Installation von SW-Gizmos abgeschlossen ist, sondern das dann die eigentliche Arbeit erst beginnt.
Ordner schrieb: > Kontrolle übern den Code und Effizienz wiedegeben, die uns die > Comfort-IDE für Voll-dummies genommen haben. Diese Kontrolle brauchen in der Regel nur die wenigsten, und das ist gut so. Nicht auszudenken wenn jeder kleine Entwickler ständig im Buildsystem rumfrickeln würde. Das wird einmal sauber aufgesetzt vom Integrator/Architekt/Senior-Entwickler und dann ist gut. Und nur dieser Personenkreis soll da drin rumwerkeln. Am Schluß linkt dann die Drittanbieter-Lib nicht mehr weil der Nerd mit seinen ungenehmigten "Optimierungen" das ABI zerschossen hat. Oder noch schlimmer, sie linkt aber tut nicht mehr was sie soll. Nein danke. In großen Projekten abstrahiert man vom Klein-Klein und bündelt solch tiefgehenden Optionen an zentraler Stelle wo nicht jeder herumwerkeln darf. Ich sags mal so: etwas Hintergrundwissen über makefiles/Skripte/Compiler schadet dem kleinen Entwickler nicht. Über den Tellerrand hinauszusehen ist immer gut. Aber die meisten Entwickler sind hinter der gewohnten IDE besser aufgehoben, von wo aus sie die bereits eingerichteten Skripte und Tools bequem erreichen.
Le X. schrieb: > Aber die meisten Entwickler sind hinter der gewohnten IDE besser > aufgehoben, von wo aus sie die bereits eingerichteten Skripte und Tools > bequem erreichen. Ja, und dann kommt ein > ein sehr guter Bewerber, der schon beim Herumführen in der > Abteilung sagte (beim Interview war ich nicht dabei), was hier alles > suboptimal ist, und was er viel besser machen würde (modernere > SW-Tools). Also nicht nur Änderungen an Optionen im Buildscript sondern gleich das gesamte Entwicklungssystem aus dem Fenster kippen!? Wie ich schon eingangs sagte "A fool with a tool is still a fool".
> Denn dann weiß man daß der Stern zur Variablen > gehört, und dann ist auch offensichtlich, daß bei > int *a, b; > b eben ein Integer und kein Pointer ist. Das ist ein Bug der Sprache C. Java war da schlauer.
gnugnu schrieb: > Berufsrevolutionär schrieb: >> Klaus Maus schrieb: >> >>> >>> Ob einer was taugt merkt man innerhalb der Probezeit an einem realen >>> Projekt, diese einstündigen Kaspereien im Bewerbungssgespräch sagen >>> absolut nix aus und auch fehl am Platz wenn sich einer mit 5 Jahren >>> passender Entwicklererfahrung bewirbt, >> >> Ganz ehrlich, wer mit 5 Jahren Berufserfahrung im Vorstellungsgespräche >> keinen fehlerfreien Code schreiben kann, ist als Programmierer Scheiße >> oder hat über seine Berufserfahrung gelogen. >> Bei einem Absolventen ist das vielleicht noch verständlich, aber nach >> 1000 Arbeitstagen mit regelmäßigen Code-ungang nicht. >> > > Definiere "fehlerfrei." Syntaktisch fehlerfrei, der Compiler spuckt keinen Error. Das sollte man schon nach 5 Jahren BE ohne Nutzung von Syntaxhighlight, Code vervollstandigung oder code templates drauf haben. Und die 50 meistgebrauchten functions aus der std-library. Und Funktional fehlerfrei ist auch kein Hexenwerk, da muss man halt Methoden des Software testing kennen und stur requirements umsetzen können. > Wenn Deine Aussage wahr wäre, gäbe es in > Betrieben, in denen ausschliesslich oder federführend erfahrene > Programmierer sitzen, keine bugs mehr. naja Softwarequalität ist Teamleistung, eine faule Traube bspw Tester der Regressiontests vermeidet und der wein istverdorben. Oder die Spec hat Fehler resp. ist unvollständig. Oder die verwendete Software hat Fehler. Oder die Umgebung wurde falsch spezifiziert (Arien5 BuG) Oder, oder. Implementierung ist halt nur eine Phase der Entwicklung deshalb fällt auch aus > Faszinierend. In DIE Parallelwelt > möchte ich mal reinschnuppern. Dann schau mal in die Programmierbuden von sicherheitskritischer Software (Raumfahrt, Medizintechnik) oder liess dich in die DO-178 ein. "Failure is not an Option".
Ich stelle auch den Anspruch fehlerfreien Code zu schreiben. Dazu bedarf es den Code aus einem Guss zu schreiben, und alles aufs Mal zu verstehen. Und nicht eine Library Funktion zu verwenden, die sich etwa so nennt wie ich es mir vorstelle. Nach der N+1-ten Aenderung ist man wieder beim Spaghetti Code. Dann sollte man's eben nochmals neu schreiben. In der Entwicklungsphase verwende ich natuerlich den Watchdog nicht, sonst wuerde ich einen Fehler ja nicht unbedingt finden.
Nop schrieb: >> Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt >> durchziehen lassen. > > Klar doch. Urlaub nehmen zum Probearbeiten. Für jedes Bewerbungsgespräch benötigt man effektiv (inklusive An+Abreise) mindestens 2 Tage Urlaub. Ob man dann jetzt noch einen dritten Tag benötigt oder nicht, macht zeitlich und preislich den Kohl nicht fett. Davon abgesehen, ein einfaches Thermometer mit LED-Anzeige sollte an einem Tag programmiert sein. Wir verwenden einfache Arduino-Boards und 7-Segment-LEDs mit variabler Anschlussbeschaltung (über Steckbrücken). Erforderd etwas mitdenken, ist aber kein Hexenwerk. Etwas Bitbanging, etwas wackeln an den Pins und Timer oder Interrups sollte man auch schon mal "gesehen" haben. Für den Temperatursensor sollte man wissen, was "Spannungsteiler" und "AD-Wandler" sind. Etwas Hauptschulmathemathik dazu und schon ist es fertig... Wer sich nicht ganz doof anstellt, der schafft das mit 100-200 Zeilen Code. J. W. schrieb: > Schreiber schrieb: >> Ja. Einfach mal 1-2 Tage lang kommen und ein kleines Funprojekt >> durchziehen lassen. > > Es geht aber bei einer Bewerber-Entscheidung auch die Leute zu finden, > die das Potential zum Programmierer haben, aber noch nicht haben, weil > sie gerade das Studium beendet haben und die Programmierfähigkeiten noch > nicht entwickelt haben. > Die könnten so ein Fun-Projekt allerdings nicht durchziehen. Etwas Arduino-Code sollte auch ein Anfänger zusammennageln können. Verstehen, und erklären(!!!), was der Code macht, sollte man auch können. Als Alternativen steht richtiges C, Bascom oder Assembler zur Verfügung. Bei Fragen darf Kollege Google konsultiert werden. Wer das nicht kann: Üben, und zwar zu Hause, oder einen anderen Beruf suchen!
Berufsrevolutionär schrieb: > > Und Funktional fehlerfrei ist auch kein Hexenwerk, da muss man halt > Methoden des Software testing kennen und stur requirements umsetzen > können. > naja, der fundamentale Fehler dieser Denkweise ist sicherlich schon eine Million Mal diskutiert worden, also ist das 1 Mio+1. jetzt auch egal: Du MEINST "konform zur Spezifikation," schreibst aber "fehlerfrei," was etwas völlig Anderes ist und etwas impliziert, was es praktisch nicht geben kann, nämlich fehlerfreie Software. Und damit relativiert sich schon eine ganze Menge, denn erstens steht und fehlt damit die faktische Qualität der Software mit der Qualität der Spezifikation sowie der Vollständigkeit der Testmatrix. Zweitens ist selbst die Konformität zu einer bestehenden Spezifikation nur in trivialen Fällen tatsächlich beweisbar. In den meisten praktisch vorkommenden Fällen kann man sich dem nur annähern. Selbst wenn in der Spec steht "bestanden, wenn das System ohne crash x Stunden durchläuft," kann Niemand garantieren, dass dasselbe System nicht nach x Stunden und einer Sekunde abschmiert, also genau nachdem der Test "erfolgreich" abgebrochen wurde. Die Puristen reagieren dann darauf, indem sie nicht deterministische Konditionen einfach verbieten. Das geht natürlich, aber damit reduzierst Du wieder die "beweisbar fehlerfreien Systeme" auf nur einen sehr kleinen Bruchteil der heutzutage praktisch nutzbaren Systeme. Also klar: Du programmierst Satelliten, an die man nicht mehr rankommt, sobald sie im Orbit sind. Dafür verzichtest Du auf Alles, was nicht deterministisch ist, also Nebenläufigkeit, Kommunikation, dynamische Speicherverwaltung, vermutlich sogar Interrupts. So ein System lässt sich tatsächlich deterministisch als "fehlerfrei" im Sinn von "spezifikationskonform" bezeichnen, wenn eine passende Testmatrix definiert wurde. Macht auch Sinn. Allerdings ist die Menge der Systeme, die auf die Art und Weise funktionieren, verschwindend gering. Es gibt z.B. heutzutage so gut wie keine Computersysteme mehr, die nicht in irgendeiner Form mit Anderen Systemen kommunizieren, und damit kommen nicht mehr komplett testbare asynchrone Faktoren ins Spiel. Und letztendlich diktiert leider (ob das gut ist oder nicht) die wirtschaftliche Pragmatik die Entwicklungszyklen, d.h. in den Allerwenigsten Projekten sind die Kapazitäten da, die Anforderungen (die sich dann auch oft genug während der Entwicklungsphase ändern) in eine saubere Spezifikation und eine hinreichende Testmatrix umzusetzen, geschweige denn die Testmatrix auch durchzuziehen. Und das hat absolut nix mit Frickelbuden zu tun. Patch Days und periodische Updates gibt's bei den grossen Herstellern genauso wie bei den Kleinen, und WENN es möglich WÄRE, im grossen Stil saubere und fehlerfreie Software zu produzieren, dann hätten wir nicht Dinge wie Heartbleed.
Schreiber schrieb: > Für jedes Bewerbungsgespräch benötigt man effektiv (inklusive > An+Abreise) mindestens 2 Tage Urlaub. Wenn man vorhat umzuziehen schon. Sonst reicht einer. Es fallen ja auch schon etliche Firmen beim Vorstellungsgespräch durch. Kritische Fragen sind, wie der Entwicklungsprozeß aussieht, wie Change-Management gemacht wird, wie das Config-Management geht, welchen Stellenwert Dokumentation denn so hat. Da kommen Frickelbuden ganz schnell ins Schwimmen, und der Gesichtsausdruck des Chefs verfinstert sich zusehends. > Wir verwenden einfache Arduino-Boards und 7-Segment-LEDs mit variabler > Anschlussbeschaltung (über Steckbrücken). Gibt's Bonuspunkte für die Frage nach ESD-Armbändern? ^^ > Etwas Arduino-Code sollte auch ein Anfänger zusammennageln können. Äh, nee, könnte ich nicht. Weil ich mich mit dem Framework überhaupt nicht beschäftigt habe - ich sehe auch keinen Sinn darin. Aber gut, Du bietest ja auch C an. Abgesehen davon halte ich den ganzen Ansatz aus meiner Sicht aber für ineffizient. Man bewirbt sich ja nicht nur bei einer Firma, und ich werde sicherlich nicht für mehrere Firmen exzessiv Urlaub für Probearbeiten nehmen. Zumal sich bei jeder Firma ja auch nicht nur einer um einen Job bewirbt. Das stiehlt mir zuviel von meiner Zeit, und dann auch noch kostbare Urlaubszeit. Effizienter ist es, mal ein cooles Projekt zu machen, dazu eine Webseite aufzusetzen und gut. Die Firmen, die auf Arbeitsproben stehen, können sich das dann selber angucken. Das skaliert besser für mich, und außerdem kann man dann auch ein Projekt machen, auf das man selber richtig Lust hat, UND das weitaus komplexer als ein LED-Thermometer sein darf.
Nop schrieb: > Kritische Fragen sind, wie der Entwicklungsprozeß aussieht, wie > Change-Management gemacht wird, wie das Config-Management geht, welchen > Stellenwert Dokumentation denn so hat. Du hast keine Ahnung was Change Management überhaupt ist.
Le X. schrieb: > Du hast keine Ahnung was Change Management überhaupt ist. Wovon ich Ahnung habe, davon weißt Du nichts, und wahrscheinlich nicht nur davon nicht. Danke, weitergehen.
Strubi schrieb: > Ganz toll ist es dann, wenn nach 'nuernberger' die Nerds mit einbezogen > werden, die Pi auf 240 Stellen auswendig können und eine > Wahnsinns-Menschenkenntnis zur Schau stellen. Yup, so Vögel zelebrieren es dann richrig einen zu befragen und ihre tatsächliche odet vermeintliche Fachkenntnis zur Schau zu stellen. Ob man sich damit ein Bild über Fähigkeiten des Bewerbers machen kann, ist eine andere Frage. Wer in der besonderen Situation eines Bewerbungsgesprächs spontan keine Fragen aus einem weiten Feld beantworten kann ist deshalb nicht unfähig. Wer überzeugend Scheiße labern kann ist deshalb nicht fähig.
Nop schrieb: > Gibt's Bonuspunkte für die Frage nach ESD-Armbändern? ^^ Das zeigt auf lustige Weise, dass das nicht so pauschal gesagt werden kann, wie man jemanden testen sollte. Wenn einer immer nur AVR gemacht hat, das super kann und du legst im einen St hin, dann guckt der auch blöde. Oder Assembler auf einem PIC, wenn er nicht mal Assembler kann. Man kann dann höchstens fragen wie er sich an einen neuen Controller ran machen würde. Bin froh, dass ich (wahrscheinlich) nicht mehr in die Verlegenheit komme, nochmal nach einem Job Ausschau halten zu müssen. Aber ich möchte auch nicht der sein, der jemanden einstellen und auf Eignung prüfen soll. Gerade in diesem Bereich. Probezeit hin oder her. Es ist für das Unternehmen teuer und für den Bewerber unter Umständen eine Katastrophe, wenn er innerhalb der Probezeit gehen müsste. Wer weiß denn, ob nicht schon in Kürze ganz andere Controller raus kommen, die so gut wie nix kosten, nur noch grafisch programmiert werden und unendlich viel Speicher haben, dazu natürlich mindestens 128 Bit und Quantenverschlüsselung. Dann kannst du nämlich all dein AVR, PIC, MSP, ST -Wissen in die Tonne treten. Ich hätte hier so einige Leute vor Augen, einen besonders, die da vielleicht nicht mehr beweglich genug wären, um sich auf die neuen Sachen einzustellen. Mir wäre wichtig, dass das ein pfiffiges Kerlchen ist, den ich da einstellen würde. Ritsch-ratsch-klick kann jeder nach einiger Zeit, aber sich was ganz neues ausdenken und mit neuen Gegebenheiten sehr gut klar kommen, dazu braucht es Kopf. Gut, den haben alle, aber können sie ihn auch benutzen?
gnugnu schrieb: > https://betanews.com/2015/04/20/why-the-open-source-software-model-is-fundamentally-broken/ >> >> Kompletter nonsense-Artikel von den ersten Zeilen weg (TL;DR). Sorry. >> Opensource heisst nicht kostenlos, das wissen Firmen durchaus. > > Im Gegenteil, sehr schlüssig, gehaltvoll, sorgfältig mit Quellen und > funktionierenden links belegt. derrick wlodarz als ausgewiesenen Trump-Fanboy kann ich nicht ernst nehmen
gnugnu schrieb: > und WENN es > möglich WÄRE, im grossen Stil saubere und fehlerfreie Software zu > produzieren, dann hätten wir nicht Dinge wie Heartbleed. Gerade Heratbleed zeigt aber das fehlerfreie Software möglich ist. Der Bug Auto -ein Doktorand aus Münster- vergass die Überprüfung einer Eingangsvariable (Bufferlänge) und ein Review des Codes fand nicht statt. Der Autor bezeichnet den Fehler als "normal" und nicht als "schwerwiegend". Wären die Basics der Softwareentwicklung: -Überprüfung der Eingangsparamter -definierte/kontrolliert Freigabeprozeduren für Code -Qualitätskontrolle kritischer Änderungen durch review beachtet worden, wäre dieses Schnüffel-Scheunentor nie entstanden. Die selbstgefällige Schlamperei eines Autors und das blinde Vertrauen der Maintainer auf Qualitäten eines ihnen nicht persönlich bekannten Coders machten das möglich. Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch Konsequent umsetzen.
Nop schrieb: > Wovon ich Ahnung habe, davon weißt Du nichts, Aus dem Kontext schließe ich dass du nicht das Veränderungsmanagement (Change Management, https://de.m.wikipedia.org/wiki/Ver%C3%A4nderungsmanagement) gemeint hast sondern das Änderungswesen (https://de.m.wikipedia.org/wiki/%C3%84nderungswesen). Sag Danke, du hast heute was gelernt. Viele Projektleiter verwenden die Begriffe auch falsch.
:
Bearbeitet durch User
Le X. schrieb: > Aus dem Kontext schließe ich dass du nicht das Veränderungsmanagement > (Change Management, > https://de.m.wikipedia.org/wiki/Ver%C3%A4nderungsmanagement) gemeint > hast sondern das Änderungswesen > (https://de.m.wikipedia.org/wiki/%C3%84nderungswesen). > > Sag Danke, du hast heute was gelernt. Na, na, na, nicht so voreilig. Im Englischen heißt beides "change management", steht auch so bei Wikipedia drin. Wenn die Sprache, in der sowas im Unternehmen behandelt wird, Englisch ist, dann gibt es da keinen Unterschied.
Berufsrevolutionär schrieb: > > Wären die Basics der Softwareentwicklung: > -Überprüfung der Eingangsparamter > -definierte/kontrolliert Freigabeprozeduren für Code > -Qualitätskontrolle kritischer Änderungen durch review > > beachtet worden, wäre dieses Schnüffel-Scheunentor nie entstanden. Die > selbstgefällige Schlamperei eines Autors und das blinde Vertrauen der > Maintainer auf Qualitäten eines ihnen nicht persönlich bekannten Coders > machten das möglich. > Hier führst Du aus, dass EINE Fehlerkategorie durch Etablierung und Beachtung von Prozessoren zum Teil eliminiert werden kann. Mag sein, aber daraus zu schliessen, dass "fehlerfreie Software möglich" ist ist falsch (sh. z.B. meine vorherigen Ausführungen über asynchrone Konditionen in heterogenen Umfelden, die niemals weder spezifiziert noch hinreichend getestet werden können). Der Begriff "eingekapselt spezifikationskonform" wäre eine wesentlich bessere Formulierung als "fehlerfrei." > Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch > Konsequent umsetzen. Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum gehören dann nach wie vor Bugs in jeglicher Form und coleur zum täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle, Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt? Offensichtlich scheint es ja nicht trivial möglich zu sein, die Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die Controller sind ja auch nicht immer ganz dumm und würden eine Menge dafür tun, den Folgeaufwand für Fehler vermeiden zu können? So einfach wie Du es Dir denkst ist es nicht, und das kann hier sicherlich Jed/r aus dem Arbeitsalltag bestätigen.
Nop schrieb: > Übrigens, mal interessehalber gefragt, falls noch Leute mitlesen, > die > sowas mitentscheiden - wenn ein Bewerber ein nennenswertes > embedded-Projekt in Opensource vorweisen kann: > > - Würdet Ihr Euch das überhaupt näher anschauen? > - Worauf würdet Ihr achten? Ich hatte schon ein paar Bewerber mit Open Source-Projekten auf github (wenn auch nicht im embedded-bereich). Ich hab mir 10 Minuten genommen da mal reinzuschauen (ist der Aufbau und Code halbwegs sauber, arbeiten noch andere an dem Projekt, wie kommuniziert der Bewerber mit den Mitarbeitern), und dann den Bewerber darauf angesprochen um den Hintergrund (Motivation) für das Projekt zu erfahren. Details zur Programmierstil, -sprache waren da weniger interessant, die kann man lernen. Ein Bewerber hat an einem größeren Open Source Projekt mitgearbeitet, neue Features implementiert, Code Reviews organisiert, usw. - das war für mich und die anderen an der Einstellung beteiligten ein klarer Pluspunkt. Da es auch einige Negativpunkte im Gespräch gab, würde ich sagen dass das letztendlich den Ausschlag gegeben hat den Bewerber doch zu nehmen. > - Würdet Ihr Euch wirklich die Mühe machen, auch Sourcen anzusehen, um > einen Eindruck von den Fähigkeiten zu bekommen? Nur oberflächlich, das frisst zu viel Zeit, und ohne den genauen Kontext zu kennen in dem das Projekt entstanden ist hilft das wenig. > - Wäre Github ausreichend, oder wäre eine dedizierte Webseite > vorzuziehen? Also ich hätte weniger Lust mich durch eine selbst designte Webseite durchzuklicken.
gnugnu schrieb: > Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder > Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie > Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum > gehören dann nach wie vor Bugs in jeglicher Form und coleur zum > täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle, > Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt? Ganz einfacher Kostenfaktor oder einfach Bequemlichkeit, die letzten 10m zum Ziel tun am meisten weh. Sicher kommt dazu, dass gute/aktuelle Testmethoden als weniger "cool" gelten als AO (Agile Onanie). Ich habe von diesen Studiengängen nicht so nen guten Eindruck, und was z.B. an der Embedded World Conference zu Safety-Aspekten verzapft wird, ist teils grobe Marketing-Kamelkacke. Schlussendlich will der Kunde immer mehr 'billig' und Bananagammelware wie zB ein esp8266-SoC gilt dann halt als Messlatte. > Offensichtlich scheint es ja nicht trivial möglich zu sein, die > Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die > Controller sind ja auch nicht immer ganz dumm und würden eine Menge > dafür tun, den Folgeaufwand für Fehler vermeiden zu können? Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird als das halbe Jahr Testbench-Entwicklung. So kann man schon mit geeigneten Software-Techniken und Tools, die über lint/MISRA hinausgehen, richtig robuste SW machen, die beweisbar gut funktioniert, z.B. angefangen mit malloc-Debuggern (oder gleich eigene Pools für seine Objekte anlegen), valgrind, oder die Krönung, gleich das ganze Programm zyklengenau bis auf die Hardware runter simulieren/verifizieren. Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas intensiv vermittelt. P.S. Lass die Helene Fischer doch singen. ("Fehlerlooos, ausgelacht..")
gnugnu schrieb: > Hier führst Du aus, dass EINE Fehlerkategorie durch Etablierung und > Beachtung von Prozessoren zum Teil eliminiert werden kann. Mag sein, > aber daraus zu schliessen, dass "fehlerfreie Software möglich" ist ist > falsch (sh. z.B. meine vorherigen Ausführungen über asynchrone > Konditionen in heterogenen Umfelden, die niemals weder spezifiziert noch > hinreichend getestet werden können). Der Begriff "eingekapselt > spezifikationskonform" wäre eine wesentlich bessere Formulierung als > "fehlerfrei." Blabla -> ich sage, wenn der Doktorand nach den (Grund-)Regeln programmiert hätte, wäre der Fehler erst nicht entstanden. Da brauchst keine gescheit klingende Formulierung wie "eingekapselt spezifikationskonform" sondern eine klare Ansage: -der "Autor" von Bleeding heart hat geschlampt. -und der maintainer hat seine Kontrollpflichten gröblichst missachtet >> Methoden zur Fehlerbeseitigung muss man nicht nur kennen sondern auch >> Konsequent umsetzen. > > Klar. In einer idealen Welt gäbe es auch keine Kriege, Seuchen oder > Helene Fischer. Die interessante Frage ist allerdings die: WENN es wie > Du sagst möglich WÄRE, "fehlerfreie" Software zu produzieren, warum > gehören dann nach wie vor Bugs in jeglicher Form und coleur zum > täglichen Alltag, selbst wenn es für Softwarequalität Lehrstühle, > Studiengänge und FDachkongresse bis zum Notarzteinsatz gibt? Offensichtlich willst Du nicht verstehen, weil das ja genau in dem Satz oben drüber steht. Die Bugs gehören zur Realität weil die menschen die die Bugs programmieren menschliche Schwächen haben und aus unprofessionellen Gründen wie Faulheit, Begriffsstutzigkeit, fehlenden Arsch in der Hose, Selbstherrlichkeit die simplen Regeln zur Fehlervermeidung ignorieren. Das sind nicht selten die, die im VG keinen beispielcode fehlerfrei hinschreiben können und auch auf Nachfrage nach praktischen Fehlervermeidungstaktiken nur akadmisch anmuteten Scheiss absondern. > Offensichtlich scheint es ja nicht trivial möglich zu sein, die > Voraussetzungen für "fehlerfreie Software" zu schaffen, denn die > Controller sind ja auch nicht immer ganz dumm und würden eine Menge > dafür tun, den Folgeaufwand für Fehler vermeiden zu können? sagte ich bereits, Fehlerfreiheit ist Teamleistung, was nützte der beste controller wenn der "programmierer" einen Bug nach dem anderen einschleust und dann so tut als wäre das ganz normal. > So einfach wie Du es Dir denkst ist es nicht, und das kann hier > sicherlich Jed/r aus dem Arbeitsalltag bestätigen. Doch es ist so einfach: Die Fehler werden von den unfähigen Programmierer gemacht und nicht von irgendwelchen bösen Schicksalmächten als strafende Plage auf die Menschheit losgelassen. Und genau das Aussortieren diese Unfachkräfte ist Zweck des in diesem Threads eröterten Eignungstest.
Le X. schrieb: > Aus dem Kontext schließe ich Engineering Change Management, meine Güte, man kann sich auch anstellen. Praktisch sagt man change management auch im engineering. Die deutschen Begriffe kenne ich da nicht einmal, das stimmt, weil die ganzen Dokumente ohnehin allesamt auf englisch sind. Die Frage an sich ist auch eher eine Fangfrage - um rauszubekommen, ob man in jeder Projektphase noch mit Änderungswünschen zugekippt wird, bis man das nur noch als "rabid pprototyping" (nein, kein Tippfehler) bezeichnen kann.
Auf Grund der Antworten hier lässt sich ziemlich genau herauslesen für wen "Entwickeln" Arbeit, und für wen es Leidenschaft ist. Ich werde bei meinem Arbeitgeber (kleine Firma) als reiner Embedded Entwickler hin und wieder zu Personalfragen und Vorstellungsgesprächen zugezogen und das kleine Funkeln in den Augen der Bewerber ist das, worauf ich achte... Überzeugt mich das, ist das was der Bewerber vorher gemacht hat gar nicht mehr so wichtig.
Strubi schrieb: > Schlussendlich will der Kunde immer mehr 'billig' und Bananagammelware > wie zB ein esp8266-SoC gilt dann halt als Messlatte. Nicht jeder Kunde, aber es sind diese Billigheimer-Kunden die die ganze Entwicklerszene versauen. Und da kann ich Linus's Tobsuchtssuchtsanfall und Steve Jobs Ausraster schon verstehen, wenn sie es im Programmieren zu tun haben, die Stringenz und Perfektion für verzichtbar halten. https://www.youtube.com/watch?v=-90iRQbd0fg > Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker > machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird > als das halbe Jahr Testbench-Entwicklung. Ja, kenn ich und andere Beispiele. methoden und tools für die Entwicklung sichere/robuster Software sind bekannt (wurde https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html oder DO-178 schon erwähnt ?!) und nicht wirklich kompliziert. > So kann man schon mit geeigneten Software-Techniken und Tools, die über > lint/MISRA hinausgehen, richtig robuste SW machen, die beweisbar gut > funktioniert, z.B. angefangen mit malloc-Debuggern (oder gleich eigene > Pools für seine Objekte anlegen), valgrind, oder die Krönung, gleich das > ganze Programm zyklengenau bis auf die Hardware runter > simulieren/verifizieren. > Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas > intensiv vermittelt. Mich auch, oder direkt formuliert, ich glaube das wird an keiner Hochschule gelehrt sondern das lernt man nur im Beruf weil da Fehler einbauen und nicht beheben richtig weh tut.
Ich hatte erst gestern mit ein paar Kollegen die selbe Diskussion. Wir waren uns einig dass (Zitat von oben) * hier ist ein 30 zeilen code snippet, welche Fehler finden sie? * schreiben sie einen algorithmus, welcher die gesetzen bits in einem vektor zählt. * wie bringen sie eine led mit frequenz x oder duty cycle y zu blinken, welche verschiedenen realisierungswege gibt es, welche vor und nachteile hat jeder? Schülerkram ist. Sowas hat man im Studium machen müssen, um den Zettel zu bekommen. Einen solchen Affenzirkus würde ich nicht mitmachen, weil ich niemand was beweisen muss, denn dafür hat man die Diplome und Arbeitszeugnisse. Auch ein Assessment würde ich nicht mitmachen, dafür ist mir die Zeit zu schade. Dinge wie * was für projekte haben sie in der vergangenheit realisiert, welche probleme hatten sie, wie sind sie die probleme angegangen und wie haben sie diese gelößt. * etwas näher über die fähigkeiten aus dem lebenslauf/bewerbungsschreiben ein gehen, ist, was zählt. Alles andere finde ich Pipifax :-)
Tobias P. schrieb: > * hier ist ein 30 zeilen code snippet, welche Fehler finden sie? > * schreiben sie einen algorithmus, welcher die gesetzen bits in einem > vektor zählt. * wie bringen sie eine led mit frequenz x oder duty cycle > y zu blinken, welche verschiedenen realisierungswege gibt es, welche vor > und nachteile hat jeder? > > Schülerkram ist. Sowas hat man im Studium machen müssen, um den Zettel > zu bekommen. -- > * was für projekte haben sie in der vergangenheit realisiert, welche > probleme hatten sie, wie sind sie die probleme angegangen und wie haben > sie diese gelößt. > > * etwas näher über die fähigkeiten aus dem > lebenslauf/bewerbungsschreiben ein gehen, Naja, bei einem Absolventen oder Azubi-bewerber führen diese Fragen zwangsläufig auf die zuerst als "Affenzitkus" betitelten Fragen. Und Berufserfahrene und die dafürgehalten werden wollen, legen sich vor dem VG irgendein problem zurecht das sie angeblich heldenhaft bewältigt haben. Und schmücken dann im VG die Fähigkeiten die sie in CV beschönigt haben noch verbal aus.
Berufsrevolutionär schrieb: > Doch es ist so einfach: Die Fehler werden von den unfähigen > Programmierer gemacht und nicht von irgendwelchen bösen Schicksalmächten > als strafende Plage auf die Menschheit losgelassen. Und genau das > Aussortieren diese Unfachkräfte ist Zweck des in diesem Threads > eröterten Eignungstest. Das ist Unsinn! Ich programmiere jetzt seit mehreren Jahrzehnten in vielen Sprachen mit selbständigem beruflichem Hintergrund - ich gehe also davon aus, dass ich irgendetwas richtig mache oder zumindest nicht schlechter als all die anderen Fachkräfte, die für unser aller Software-Angebot mitverantwortlich sind. Und ich versichere Dir, dass fehlerfreier Programmcode ab einem gewissen Komplexitätsgrad absolut normal ist und nur bedingt mit der Expertise des Programmierers zu tun hat. Ein schlechter Programmierer wird zweifellos überwiegend fehlerhafte Programme schreiben, aber von einem fehlerhaften Programm auf einen unfähigen Programmierer zu schließen, zeugt nur von einem fehlenden Bezug zur realen Welt deinerseits. Wer schon mal unter realen Bedingungen Software entwickelt hat, der weiß, dass es da noch etwas mehr gibt, als die reine Lehre vom sauberen und fehlerfreien Programmieren. Ob das nun ein Mangel an Ressourcen ist, an sportlichen Deadlines vom Vertrieb liegt, oder der Art der Entwicklung geschuldet ist, ist dabei völlig unerheblich. Am Ende ist immer entscheidend, wie viel Druck auf dem einzelnen Programmierer lastet bzw. ob er die Zeit hat, seine Arbeit vernünftig zu leisten. Das ist vielleicht kein Schicksal, aber es hat sicherlich in erster Linie etwas mit unserer Gesellschaft zu tun, auf die der Einzelne nur wenig Einfluss nehmen kann. Als Selbständiger habe ich auch schon Aufträge abgelehnt, weil der Auftraggeber der Meinung war, die von mir veranschlagte Zeit für Fehlersuche und Absicherung gegen Angriffe wären reiner Luxus. Und ich bin auch schon oft genug auf meine Kappe vom vereinbarten Pfad abgewichen und habe etwas aufwändiger programmiert als zunächst notwendig, einfach, weil ich aus Erfahrung wusste, dass das, was der Auftraggeber zunächst kategorisch ausgeschlossen hat, sowieso im späteren Projekt-Verlauf als völlig überraschende Änderung nachgereicht wird. Das kann man dann ganz regulär nachberechnen und man muss nicht das ganze Konzept überdenken. Aber als Angestellter kann man sich gegen so etwas nicht so leicht wehren bzw. man hat nicht den selben Handlungsspielraum. Und bei größeren Projekten werden auch oft genug (Teil-)Aufträge an Externe vergeben und spätestens da ist dann alles verloren, sofern man die dadurch vermeintlich eingesparte Zeit nicht durch intensive Reviews wieder auffressen möchte. Und nur mal so: Da ich hobbymäßig mit µCs arbeite, könnte ich mich vortrefflich mit jemandem über CAN, I2C, Interrupts, Timer, PWM, etc. unterhalten. Ob das aus mir einen erfahrenen Embedded-Entwickler macht, lässt sich dadurch aber auch nicht sagen. Es geht ja teilweise auch darum, WIE fest jemand im Sattel sitzt bzw. wie lange man für bestimmte Aufgaben benötigt. Mit diesen Tests filtert man höchstens die Totalversager oder mit etwas Pech diejenigen, die zwar fachlich kompetent sind, aber durchaus unter so einer Art Lampenfieber leiden. Ich halte es für sinnvoller, wenn sich auf AG-Seite jemand mit dem Bewerber unterhält, der von den geforderten Dingen wirklich Ahnung hat. Und zwar nicht wie bei einem Tribunal, sondern nur diese beiden Personen in lockerer Atmosphäre. Der würde recht schnell merken, ob da mehr als nur heiße Luft dahinter ist - ganz ohne diese erniedrigenden Assessment-Tests.
Strubi schrieb: > Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker > machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird > als das halbe Jahr Testbench-Entwicklung. Ja, aber Du vergisst dabei, dass die Siliziumwerker in einem Anderen Universum arbeiten. Für die endet die Welt an ihrem Waferrand. Das ist jetzt keine Kritik oder Geringschätzung, es geht auch nicht Anders. Ein Siliziumwerker kann jedes Staubkorn im durch seinen Platinenrand begrenzten Universum Gradgenau ausrcihten. Das ist seine Aufgabe. Das Universum mit Anderen Universen zu verbinden ist die Aufgabe der Firmwareentwickler, und damit ändern sich die Regeln! > oder die Krönung, gleich das > ganze Programm zyklengenau bis auf die Hardware runter > simulieren/verifizieren. Jetzt haben wir es! Was nützt Dir eine zyklengenaue Simulation, wenn deine Firmware an einem Netzwerk hängt (und von deren Ereignissen mitgesteuert wird), in dem weder das Timing noch die Folge von einkommenden Ereignissen noch völlig von der Problemstellung komplett unabhängige Drittereignisse wie Broadcaststürme vorhergesagt werden können? Oder Kommunikationspartner mal offline gehen oder sich selber durch subtile andere Interpretation von Vorgaben (z.B. andere Implementation von Protokollspezifikationslücken) unvorgesehen verhalten? Wie willst Du das simulieren? Alle möglichen Kombinationen von Nullen und einsen im DMA Pufferspeicher durchnudeln? Wie willst Du guten Gewissens eine kommunizierende Software schreiben, wenn Du weisst, dass da draussen Dutzende von verschiedenen Geräten sind, die Alle etwas Anders funktionieren (das Problem jedes Webserverherstellers in Grün)? Ich sage nicht, dass deswegen alle Firmwareentwicklung in Gottes Hand liegt. Aber die rein elektrotechnische Sichtweise "man muss nur Alles gut genug und genau genug spezifizieren und seine lineare Testmatrix anwenden, und damit sind alle Fehlerquellen abgedeckt" hilft bei der Fírmwareentwickluiung über den Platinenrand hinaus nicht weiter. Da muss man komplett Andere Wergzeugkisten öffnen. > Würde mich interessieren, ob jemand eine Uni/FH kennt, die sowas > intensiv vermittelt. > Mich auch, speziell das intensiv vermittelt, was genau zwischen die Stühle der Hardware- und Softwareentwicklung fällt.
Gonzo schrieb: > Berufsrevolutionär schrieb: > , aber von einem fehlerhaften Programm > auf einen unfähigen Programmierer zu schließen, zeugt nur von einem > fehlenden Bezug zur realen Welt deinerseits. Realitätsverlust? So so, schon mal selbst versucht die Realität hinter dem Heartbleedzu recherchieren? Sicher nicht, sonst wuesstest Du da der Autor nicht nur einen Fehler in dem Stack hinterlassen hat: https://www.heise.de/security/meldung/Noch-mehr-Herzbluten-bei-OpenSSL-2217286.html http://www.netz-trends.de/id/3229/Hacker-Wer-ist-Robin-Seggelmann-der-Heartbleed-Ausloeser/ Und nicht irgendwelche Tippfehler wie if (a=0) oder dreher in der argumentenreihenfolge, sondern willentliches weglassen der Prüfung der Buffergröße. Vielleicht sollte man es umformulieren, vielleicht hat ist er vom Fach-KnowHow her fähig , er ist trotzdem unfähig weil es ihm an der nötige Sorgfalt und Verantwortungsgefühl mangelt. Er verlässt sich einfach drauf das im prtotcolheader immer nur erlaubte Werte stehen. Ist IMHO ein typisches Problem vom Programmieren die nur den akademischen Eifelturm kennen.
Gonzo schrieb: > > Ob das nun ein Mangel an Ressourcen ist, an sportlichen Deadlines vom > Vertrieb liegt, oder der Art der Entwicklung geschuldet ist, ist dabei > völlig unerheblich. Am Ende ist immer entscheidend, wie viel Druck auf > dem einzelnen Programmierer lastet bzw. ob er die Zeit hat, seine Arbeit > vernünftig zu leisten. Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht zum release freizugebeb wenn er nicht seinen Job fertig machen konnte. Das nennt man eigenveratwortliches Arbeiten.
Am Ende des Tages muss mit einem Produkt auch Geld verdient werden und dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber nicht erreichen. Und wer sich ernsthaft hinstellt und behauptet er könne ein mittleres Softwareprojekt komplett bugfrei programmieren (wenn nur <insert reason here>), der entlarvt sich einfach als realitätsferner Dampfplauderer. Warum sich nun an Heartbleed so hochgezogen wird, verstehe ich nicht; ja da wurden ein paar grundlegende Prinzipien der Softwareentwicklung grob verletzt und das hat sich übel ausgewirkt, aber eine Nichtverletzung führt trotzdem nicht automatisch zu richtigem Code. Spätestens wenn sich das erste Requirement ändert, fängt der Spaß an ;)
Abradolf L. schrieb: > Am Ende des Tages muss mit einem Produkt auch Geld verdient werden > und > dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber > nicht erreichen. man KANN Software entwickeln, deren Fehlerfreiheit formal beweisbar ist. Kostet aber Geld, sehr sehr viel Geld. Berufsrevolutionär schrieb: > Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht > zum release freizugebeb wenn er nicht seinen Job fertig machen konnte. > Das nennt man eigenveratwortliches Arbeiten. Nicht sicherheitsrelevante Funktionen kann man als Firmwareupdate nachliefern.
Berufsrevolutionär schrieb: > Und nicht irgendwelche Tippfehler wie if (a=0) oder dreher in der > argumentenreihenfolge, sondern willentliches weglassen der Prüfung der > Buffergröße. Das willentlich unterstellst Du jetzt aber einfach mal so. Hast Du Dir Deine eigenen Links mal durchgelesen? Es war laut seinen eigenen Aussagen ein Flüchtigkeitsfehler. Oder anders ausgedrückt: Eigentlich weiß er es besser, aber man denkt eben nicht immer an alles. Ist jetzt jeder Autofahrer, der nur einmal verschuldet einen Unfall verursacht, ein inkompetenter Idiot? Sicherlich genau so wenig wie der Programmierer des Heartbleed Bugs! Menschen machen Fehler, eben weil wir nicht wie Maschinen funktionieren. Das 4-Augen-Prinzip gibt es nicht, weil alle außer Papa inkompetent sind, sondern weil jeder Mensch mit nur etwas Lebenserfahrung weiß, dass man trotz größter Sorgfalt immer mal etwas übersehen oder vergessen kann. Der im Arbeitsleben real vorhandene Stress gepaart mit Ablenkung verstärken diese Problematik noch zusätzlich. Von daher bestätigst Du nur einmal mehr, dass Du nicht viel von der Softwareentwicklung in der realen Welt verstehst. Berufsrevolutionär schrieb: > Ein Programmiere brauch eben auch den Arsch in der Hose den code nicht > zum release freizugebeb wenn er nicht seinen Job fertig machen konnte. > Das nennt man eigenveratwortliches Arbeiten. In der Theorie gebe ich Dir recht, in der Praxis findet das so leider nur selten statt und hat nichts mit "Arsch in der Hose" zu tun. Der Heartbleed Bug ist aufgrund seiner Auswirkungen ein besonders gefährlicher Fehler und hätte mich persönlich schon aus haftungsrechtlichen Gründen (Vulgo: Vorsatz) auch als mitwissenden Arbeitnehmer dazu veranlasst, diesen Code nicht zum Release freizugeben. Aber wir reden sowohl bei Heartbleed als auch überall sonst in der Praxis ja über Fehler, die noch gar nicht gefunden worden sind und die sich diskussionstechnisch gefühlt hundert mal schwieriger rechtfertigen lassen. Da hängt es dann eher davon ab, ob Dein Vorgesetzter IT-Technisch kompetent ist und nicht ob Du als Programmierer es bist. Sieh doch einfach mal ein, dass auch als absolut kompetent geltende Menschen ab und an Fehler machen - vielleicht nicht so häufig wie imkompetente, aber es muss nur der falsche Fehler zur falschen Zeit auftreten und schon entwickelt sich daraus eine Desaster und erinnert uns daran, dass keiner von uns unfehlbar ist.
Schreiber schrieb: > Abradolf L. schrieb: >> Am Ende des Tages muss mit einem Produkt auch Geld verdient werden >> und >> dafür bleibt nur endliche Zeit. Man kann Perfektion anstreben, aber >> nicht erreichen. > > man KANN Software entwickeln, deren Fehlerfreiheit formal beweisbar ist. > Kostet aber Geld, sehr sehr viel Geld. > Nein. Nicht für jedes Problem. DAS ist formal beweisbar! Wurde auch schon vor gut über 50 Jahren bewiesen! Mal ganz abgesehen davon, dass selbst der Begriff der "Fehlerfreiheit" äusserst debattierbar ist.
gnugnu schrieb: > Strubi schrieb: > >> Es ist doch eigentlich nicht so höllisch kompliziert, die Siliziumwerker >> machen das täglich, weil dort halt ein Fehlschuss aufm Wafer teurer wird >> als das halbe Jahr Testbench-Entwicklung. > > Ja, aber Du vergisst dabei, dass die Siliziumwerker in einem Anderen > Universum arbeiten. Für die endet die Welt an ihrem Waferrand. Das ist > jetzt keine Kritik oder Geringschätzung, es geht auch nicht Anders. Ein > Siliziumwerker kann jedes Staubkorn im durch seinen Platinenrand > begrenzten Universum Gradgenau ausrcihten. Das ist seine Aufgabe. Das > Universum mit Anderen Universen zu verbinden ist die Aufgabe der > Firmwareentwickler, und damit ändern sich die Regeln! > Nein, das ist eben in manchen Fällen nicht mehr so, z.B. wenn ein DSP-ASIC entworfen wird. Dann werden schnell mal die Brücken zw. HW und SW geschlagen und du musst dich als SW-Entwickler an ein paar Dinge "gewöhnen". >> oder die Krönung, gleich das >> ganze Programm zyklengenau bis auf die Hardware runter >> simulieren/verifizieren. > > Jetzt haben wir es! Was nützt Dir eine zyklengenaue Simulation, wenn > deine Firmware an einem Netzwerk hängt (und von deren Ereignissen > mitgesteuert wird), in dem weder das Timing noch die Folge von > einkommenden Ereignissen noch völlig von der Problemstellung komplett > unabhängige Drittereignisse wie Broadcaststürme vorhergesagt werden > können? Oder Kommunikationspartner mal offline gehen oder sich selber > durch subtile andere Interpretation von Vorgaben (z.B. andere > Implementation von Protokollspezifikationslücken) unvorgesehen > verhalten? Wie willst Du das simulieren? Alle möglichen Kombinationen > von Nullen und einsen im DMA Pufferspeicher durchnudeln? Wie willst Du > guten Gewissens eine kommunizierende Software schreiben, wenn Du weisst, > dass da draussen Dutzende von verschiedenen Geräten sind, die Alle etwas > Anders funktionieren (das Problem jedes Webserverherstellers in Grün)? > Das Stichwort ist "Co-Simulation". Und ja, genau der ganze Krempel wird in der Schleife mit teils realen Daten oder pseudozufälligen Timing-Szenarien verifiziert. Natürlich simulierst du nicht beliebige Komplexität bis auf dem untersten Level, das macht keinen Sinn. D.h. für einen MAC muss ich nur zB "beweisen", dass die FIFOs bei einem Packet-Burst nicht vollaufen, events verpasst werden, oder feuernde reentrante IRQs den Stack nicht trashen können (Klassiker..). Damit kann ich dann gewisse Sachen in der Realität schon mal ausschliessen und muss nicht immer wieder ganz unten nach Fehlern suchen. Ab dem Punkt wo alles sowieso extrem nondeterministisch wird, reicht dir die Zeit in der Simulation nicht (manche Tests dauern schon Tage), da portierst du den ganzen Regresstest dann auf die reale HW. > Ich sage nicht, dass deswegen alle Firmwareentwicklung in Gottes Hand > liegt. Aber die rein elektrotechnische Sichtweise "man muss nur Alles > gut genug und genau genug spezifizieren und seine lineare Testmatrix > anwenden, und damit sind alle Fehlerquellen abgedeckt" hilft bei der > Fírmwareentwickluiung über den Platinenrand hinaus nicht weiter. Da muss > man komplett Andere Wergzeugkisten öffnen. > Ich habe die Erfahrung gemacht, dass man deutlich weniger am falschen Ende sucht, wenn man die komplette Mainloop mal in die Simulation haut und die "Coverage" durchspult, wenn Tool XY mal wieder was übersehen hat oder man irgendwo nen Bock in der Register-Initialisierung hat. Welche Werkzeugkiste soll mir das abnehmen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.