Hallo, ich bin seit einigen Jahren raus aus der Embedded-Entwicklung und möchte nun wieder einsteigen. Welche Tools sollte man da in einem professionellen Umfeld heute beherrschen? Was ist da alles gefordert? Gruß, Hans-Hermann
:
Slack, Jira, Confluence, E-Mail, Docker, Git, ...dafür geht dann schon 30% der Arbeitszeit drauf.
Der "Embedded Sektor" ist groß, so groß daß er schon wieder 2 Dutzend Untersektoren hat. Dementsprechend gibt es unterschiedliche Tools für unterschiedliche Zwecke wie Sand am Meer. Präzisiere also Dein Anliegen.
Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und vim, das ist das absolute Minimum das in allen Bereichen zwingend ist, quasi die Beherrschung der Grund-Infrastruktur. Dazu kommen dann noch diverse speziellere Tools und auch IDEs für bestimmte Zwecke.
Desweiteren Opsgenie, MS Office, MS Azure, Bedienung von Telefonen (Telefonkonferenzen sind ganz wichtig), Wikipedia (zusätzlich zu Confluence, am besten schreibt man alles redundant auch ein drittes Mal in ein Word Dokument).
Gute bis sehr gute Englischkenntnisse in Wort und Schrift.
Chinesisch ist noch optional aber zunehmend nützlich.
Bernd K. schrieb: > Gute bis sehr gute Englischkenntnisse in Wort und Schrift. Gute Deutschkenntnisse sind natürlich auch nicht vrkehrt!
HAL (SETM32, vor allem im professionellen Umfeld), AVR Studio 4, WINAVR, Assembler, RS232 (Debugging), I=U/R kennen und anwenden
Bei solchen Threads postet doch jeder nur was er selbst halbwegs kann, und das wird dann zum absoluten Standard und Minimum erklärt.
Wenn man Embedded Android macht: find und grep.
Ich würde alles lernen was dieses Kommando ausgibt: ls /bin /sbin /usr/bin (Duck und weck)
Evtl. auch noch eine Fortbildung im Fliesenlegen!
Dass hier noch keiner Arduino genannt hat....
Andreas B. schrieb: > Dass hier noch keiner Arduino genannt hat.... Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung) gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da eine Projektanfrage.
Beitrag #6141108 wurde von einem Moderator gelöscht.
Haha schrieb: > Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung) > gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da > eine Projektanfrage. Wenn es darum geht, z.B. ein Shield und zugehörige Libraries, oder einen ganz eigenen Arduino zu entwickeln als Evaluations-Plattform für eigene Produkte, ist das doch nicht verkehrt, wie z.B. der Linduino.
Haha schrieb: > Evtl. auch noch eine Fortbildung im Fliesenlegen! Irrtum! Was heutzutage gebräuchlich ist, ist mit LEGO umgehen zu können. Also nix Fliesen, sondern Plastich dreidimensional! W.S. ps.: seit wann ist der Freitag auf den Mittwoch verlegt worden?
W.S. schrieb: > Was heutzutage gebräuchlich ist, ist mit LEGO umgehen zu können. > > Also nix Fliesen, sondern Plastich dreidimensional! Ich drucke meine Fliesen auch im 3D Drucker.
Haha schrieb: > Slack, Jira, Confluence, E-Mail, Docker, Git, ...dafür geht dann > schon 30% der Arbeitszeit drauf. Git und generell Linux reicht. Rest ist unnützer Mist
ISO9001 sollte man auch im Schlaf beherrschen.
Hans-Hermann schrieb: > Welche Tools sollte man da in einem professionellen Umfeld heute > beherrschen? Was ist da alles gefordert? Multimeter, Oszilloscope, Crimpzange, Schraubendreher, funktionsgenerator, daran scheitern 50% der Hochschulabsoventen, in bestimmten Fachrichtungen 100%. (die, die unter Tools was ganz anderes verstehen).
IM Drahtwickel schrieb: > Multimeter, Oszilloscope, Crimpzange, Schraubendreher, > funktionsgenerator, Ich hab mir an der Hochschule mal einen Funktionsgenerator geliehen. Ein Jahr später brauchte ich ihn noch einmal, und er stand noch auf exakt den gleichen Einstellungen...
Programmierer schrieb: > Ich hab mir an der Hochschule mal einen Funktionsgenerator geliehen. Ein > Jahr später brauchte ich ihn noch einmal, und er stand noch auf exakt > den gleichen Einstellungen... Sowas macht man heute auch mit einem Arduino!
Haha schrieb: > Sowas macht man heute auch mit einem Arduino! Geht auch, mit Funktionsgenerator war's etwas einfacher. Arduino wäre aber handlicher gewesen...
Programmierer schrieb: > Haha schrieb: >> Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung) >> gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da >> eine Projektanfrage. > > Wenn es darum geht, z.B. ein Shield und zugehörige Libraries, oder einen > ganz eigenen Arduino zu entwickeln als Evaluations-Plattform für eigene > Produkte, ist das doch nicht verkehrt, wie z.B. der Linduino. Wenn der Hardwareentwickler irgendwas braucht, wo er einfach seinen Sensor dran flanschen kann um schnell mal die Analogwerte per UART auszugeben, auch nicht.
Nur die Werkzeuge die notwendig sind;-) Je nach Target am Besten die Hersteller Tools zum FLASHEN bzw. Debugging Compiler und Editoren sind Geschmackssache. Wer sich es leisten kann professionelle Tools zu verwenden fährt nicht unbedingt schlecht. Wer nicht die Geduld und das Wissen hat Spezial Tools zu konfigurieren ist mit konfektionierten IDEs/Tools besser dran. Bei Makefile Projekten tut man sich mit Linux meist besser. Mit IDEs ist Windows gut genug. Als Nicht-Spezialist fährt man (manchmal) mit kommerziellen Tools vielleicht besser. In der Firma verwenden wir für die aktuellen Projekte allerdings nur kommerzielle Werkzeuge. Auch wenn man mich mich jetzt teert und federt, bin ich der Meinung, daß man mit vernünftig programmierten C oder C++ immer noch am besten fährt. Wenn auch für viele Newcomer Sprachen oft mächtig getrommelt wird, kommt man mit C/C++ doch immer noch zuverlässig zum Ziel. Aber das muss jeder selbst entscheiden. Wer da abenteuerlich veranlagt ist, wird sich mit der Vielfalt der neuen Werkzeuge sicherlich austoben können sofern man mit der Lernkurve und Evolution der Werkzeuge zurecht kommt. Für einfachere Sachen im Hobbybereich kann man übrigens auch mit dem verschrieenen Arduino IDE + GCC gut zurecht kommen. Auch wenn der Editor einfach gehalten ist, ist so ziemlich alles wirklich Notwendige vorhanden. Auch dort kann man "Bare Metal" programmieren. Man ist nicht unbedingt auf externe Bibliotheken angewiesen und man kann ziemlich frei gestalten. Wer Debuggen wichtig findet, wird mit JTAG GDB gut zurecht kommen. Debugger ist je nach Projekt wichtig oder man braucht ihn kaum. In meiner Praxis komme ich fast ohne Debugger aus. Nur wenn man selber einen blöden (Schlampigkeits) Fehler macht, dann hilft der Debugger es schneller zu finden. 90% der Zeit befindet sich der Fehler meist vor dem PC. Manche 8-bit Debugger Infrastrukturen funktionieren nicht so gut. Was Debuggen betrifft, machte ich mit ARM7/Cortex uC JTAG und GDB gute Erfahrungen. Mit AVR und PIC war es immer ein frustrierendes Erlebnis.
Wer seine Software debuggen muss, ist ein Anfänger und kein Profi. Die Diskussion hatt wir hier im Forum jetzt schon häufig genug.
Haha schrieb: > Wer seine Software debuggen muss, ist ein Anfänger und kein Profi. So ein Quatsch. Diese Arroganz, zu denken, man könne keine Fehler machen, hat schon Raketen und Flugzeuge abstürzen lassen. Leute, die behaupten, nicht debuggen zu müssen, sind meistens die, die zu faul sind, den Umgang mit dem Debugger zulernen.
Beitrag #6142005 wurde von einem Moderator gelöscht.
Haha schrieb: > HAL (SETM32, vor allem im professionellen Umfeld) Naja, die SPL bzw. LL-Driver sind auch ok >AVR Studio 4 Veratlet, Atmel Studio 7 ist um längen komfortabler >WINAVR Veraltet, einen aktuellen GCC sollte man schon mal verwenden >Assembler, RS232 (Debugging), I=U/R kennen und anwenden Check!
Haha schrieb: > Wer seine Software debuggen muss Wirst Du diesen Schwachsinn jetzt in jedem Thread posten der auch nur entfernt was mit Mikrocontrollern oder Programmierung zu tun hat?
Beitrag #6142122 wurde von einem Moderator gelöscht.
Batman schrieb im Beitrag #6142122: > Hatte letztens einen Bewerber (Snowflake) der sich mit seinem Rasperry > Kenntnissen gebrüstet hat. Wenn der sich mit den Details der CPU und z.B. des Grafikprozessors, des Kernels und der zugehörigen Treiber für den R-PI auskennt - Respekt! Das ist dann ein hochqualifizierter Experte mit seltenen Kenntnissen, den man für anspruchsvolle Embedded-Linux-Entwicklung einsetzen kann. Könnte man durchaus als goldene Schneeflocke bezeichnen...
Beitrag #6142152 wurde von einem Moderator gelöscht.
Beitrag #6142182 wurde von einem Moderator gelöscht.
Beitrag #6142192 wurde von einem Moderator gelöscht.
Batman schrieb im Beitrag #6142192: > Nein, der kann höchstens ein Image aus dem Internet herunterladen und > auf einem Raspi installieren. Nagut. In jedem Fachgebiet gibt es Deppen.
Embedded ist ein riesiger Bereich - da kann man kaum sagen, was man benötigt und was nicht. Wichtig ist eigentlich nur eine Sache: sich schnell in neue Anforderungen/Software einarbeiten zu können (eben weil es so eine große Vielfalt gibt). Oft gehört auch dazu, dass man sich in die Thematik des Umfelds der späteren Elektronik einarbeitet, weil der Kunde selbst noch nicht genau weiss, was er überhaupt benötigt. Walter T. schrieb: > Simulink, TargetLink, LabView ... Noch nie benutzt :-) konfusius schrieb: > Bei solchen Threads postet doch jeder nur was er selbst halbwegs kann, > und das wird dann zum absoluten Standard und Minimum erklärt. Natürlich! Daher gehören fundierte Kenntnisse über Fluidphysik, Metallurgie, Zerspanung, CNC-Kenntnisse und Bearbeitung optischer Flächen zwingend dazu - vorher braucht man nicht einmal an irgendwelche Elektronik zu denken ;-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Noch nie benutzt :-) Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-)
Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder eine andere PCB Design Software genannt hat.
Walter T. schrieb: > Chris D. schrieb: >> Noch nie benutzt :-) > > Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-) Na Gott sei Dank! :-) Ernsthaft: ich bin sehr froh, für diesen Bereich nicht entwickeln zu müssen.
konfusius schrieb: > Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder > eine andere PCB Design Software genannt hat. Ok: Eagle oder KiCad, aber bitte nur jeweils den Layouteditor. Wer braucht schon Schaltpläne?
Walter T. schrieb: > Chris D. schrieb: > Noch nie benutzt :-) > > Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-) Unsinn
konfusius schrieb: > Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder > eine andere PCB Design Software genannt hat. Wir haben alle in Anbetracht der Leser- und Schreiberschaft hier aufs peinlichste genau darauf geachtet keine kontroversen und stark polarisierenden Themen anzuschneiden oder überhaupt auch nur beim Namen zu nennen, bzw. überhaupt auch nur daran zu denken!
konfusius schrieb: > Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle > oder > eine andere PCB Design Software genannt hat. Die Hardware kaufen wir billig in China, wir brauchen nur einen Doofen der die mitgelieferte Software repariert.
Programmierer schrieb: > Haha schrieb: >> Wer seine Software debuggen muss, ist ein Anfänger und kein Profi. > > So ein Quatsch. Diese Arroganz, zu denken, man könne keine Fehler > machen, hat schon Raketen und Flugzeuge abstürzen lassen. Leute, die > behaupten, nicht debuggen zu müssen, sind meistens die, die zu faul > sind, den Umgang mit dem Debugger zulernen. Debuggen != Testen Da werden 2 unterschiedliche Sachen vermischwechselt. Wenn (auch embedded-)SW wirklich gut gemacht ist, dann kann sie bei einem Test gerne auch mal abkacheln. Jedoch bei der Informationsspur welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne Debugging. Ich duerfte von so arbeitenden Senior-Kollegen lernen und weiss somit dass es auch ohne (klassisches/stereotypes) Debugging geht, sehr weit geht. (Branchen: Flugsicherheit, Sprachkommunikation, Telekom i.A., SCADA) Sobald jedoch bei der Konzeptionsphase von Produkte "schnell-schnell" was gemacht wird (sprich: zu frueh und unbedacht Quellcode gerotzt wird); tja dann... ja genau dann wird Debugging noetig und auch haarig. Dann ist aber der Zug schon abgefahren.
Industriegereifter alter Sack schrieb: > Wenn (auch embedded-)SW wirklich gut gemacht ist, dann kann sie bei > einem Test gerne auch mal abkacheln. Wieso Testen? Wer keine Fehler macht, braucht doch nicht testen! Industriegereifter alter Sack schrieb: > Jedoch bei der Informationsspur > welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und > auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne > Debugging. Das Verfolgen der "Informationsspur" ist debuggen. Fehler Suchen eben.
Programmierer schrieb: > Wieso Testen? > Wer keine Fehler macht, braucht doch nicht testen! DAS ist Deine Behauptung! Lebe DU lange und gut damit... > Industriegereifter alter Sack schrieb: >> Jedoch bei der Informationsspur >> welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und >> auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne >> Debugging. > > Das Verfolgen der "Informationsspur" ist debuggen. Oh Mist.. er hat es gemerkt (ausser dass es ohne Debugger geschieht :-> ) So gewinnst Du eine Reise nach Amerika. Wenn Du nun auch aufhoerst zu trollen (s.o.), gewinnst Du auch die Heimreise dazu. > Fehler Suchen eben. Du meinst, Etwas nicht gemachtes (s.o.) zu suchen? Bin raus, tschuess.
Um auf das Ursprungsthema zurückzukommen: Ich selbst bevorzuge für meine Projekte verständlicherweise MDK-ARM mit ULINK pro oder plus, sowie die zugehörige Middleware (bin ja vorbelastet :-) ). Andere (Bekannte) verwenden im professionellen Umfeld z.B. IAR oder andere kommerzielle IDEs. Vorteil an diesen ist, sie unterstützen den Entwickler mit integrierten Werkzeugen, wie (im ARM Cortex Fall) z.B. einem ITM Terminal, grafischen Analysetools für Variablen und RTOS, oder gar Instruction Trace. Somit braucht man keinen UART (= ITM printf), oder einen PortPin mit dem Oszi ausmessen (= Data Watch, Zeitmessung im Fenster). Ich für meinen Geschmack greife eher selten bis gar nicht auf HALs zurück (z.B. STM). Man sollte sich aber für ARM Cortex die CMSIS Standardisierungen ansehen (CMSIS Headerfiles, Treiber, ...). Je nach Projekt und Portierbarkeit macht es doch Sinn, sich auch mit den HALs auszukennen. Im privaten Bereich greift man lieber auf kostenlose Lösungen aus den gnu Paketen zurück. Verständlich, eine Vollversion der kostenpflichtigen ist meisst nicht ganz billig. Zum Glück schmeissen ST und Konsorten seit einiger Zeit mit Boards um sich, wo gleich ein kleiner Debugger mit drauf ist :-) Ansonsten bietet z.B. Segger (als Konsequenz der China Clone?) eine recht günstige EDU Version des JLink an. Zurück zu dem, was man können sollte: - mind. eine IDE / Toolchain bedienen können - C/C++ bevorzugt, da man näher am Core ist (ASM Jünger, steinigt mich :-) ) - Software-Architektur, den Code zumindest halbwegs sinnvoll auf Module aufteilen - die Zielarchitektur verstehen oder verstehen lernen! - das Manual der MCU lesen & verstehen - Peripherals auch durch Lesen des Manuals programmieren können - sich Standards anschauen (z.B. CMSIS) - Code Debuggen, Fehler auf verschiedenste Weise eingrenzen können - Grundverständnis in Elektronik, Schaltpläne lesen können - Assembly und Register (Debugger) lesen können, um Code zu optimieren - Architektur Besonderheiten (Intrinsics) - und vielleicht muss man ab und an auch mal wissen, wo das heisse Ende vom Lötkolben ist :-) - ggf. PC Programmierung (z.B. Visual Studio) für Test Tools oder Datenauswertung Beim Debuggen kreativ werden, vor allem bei selten auftretenden Problemen: Falls jemand die NetLase LC kennt: Ich habe z.B. die Ethernet Kommunikation und meine internen Buffer und Timeouts sowie das Zusammenspiel mit den Interrupts analysiert, durch geschicktes Setzen von Werten verschiedener Variablen, die dann grafisch angezeigt wurden. In gleicher Weise konnte ich die Ausführung der Interrupts sehen. So wurde dann irgendwann klar, dass ein Interrupt in einem sehr seltenen Fall etwas zu lange dauerte. Grafisch findet man das nach ner Weile, mit printf geht das gar nicht, da man das Timing stört. So gibt es verschiedene Arten, Code zu Debuggen. angefangen mit printf für langsame Ausgaben bis hin zu Pin Toggling oder Data Trace für zeitkritische Stellen. Beruflich zerlege ich u.a. die oben genannten Datenströme unter Windows und sorge für die Darstellung incl. grafischem Rendering. Ich liebe große Datenmengen, je mehr und zeitkritischer, desto besser :-) Und: Sicherlich gibt es in meinem Post das ein oder andere, für das ich gleich zerissen werde :-)
:
Bearbeitet durch User
Beitrag #6142843 wurde von einem Moderator gelöscht.
Beitrag #6143225 wurde von einem Moderator gelöscht.
Beitrag #6143360 wurde von einem Moderator gelöscht.
Beitrag #6143413 wurde von einem Moderator gelöscht.
Beitrag #6143462 wurde von einem Moderator gelöscht.
Beitrag #6143465 wurde von einem Moderator gelöscht.
Beitrag #6143474 wurde von einem Moderator gelöscht.
Beitrag #6143477 wurde von einem Moderator gelöscht.
Bernd K. schrieb: > Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und > vim, das ist das absolute Minimum das in allen Bereichen zwingend ist Die Aussage ist so pauschal natürlich Quatsch. Es gibt etliche Firmen, die weder Docker noch git benutzen. Manche benutzen auch kein make, sondern ein anderes Build-System. Manche benutzen andere Compiler als den gcc. Welchen Editor man verwendet, ist in der Regel komplett wumpe... und so weiter und so fort.
:
Bearbeitet durch User
Hans-Hermann schrieb: > Welche Tools sollte man da in einem professionellen Umfeld heute > beherrschen? Was ist da alles gefordert? Wenn die Frage auf spezifische Tools eines bestimmten Herstellers abzielt, dann ist sie falsch gestellt. Tools kommen und gehen. Genau so wie viele Programmiersprachen auch. Was man braucht, ist Methodenwissen. Und in aller Regel Tools aus den folgenden Kategorien: Lesen von Datenblättern. Erstellen von Anforderungen. Erstellen von Architektur/Design Dokumenten. Editieren von Sourcecode. Compiler. Linker. Debugger. Test Framework. Erstellen von Testberichten. Welche das dann im konkreten Fall sind, unterscheidet sich von Firma zu Firma sehr stark. Daher kann man hier keine pauschal gültige Antwort geben.
Bernd K. schrieb: > Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und > vim, das ist das absolute Minimum das in allen Bereichen zwingend ist, > quasi die Beherrschung der Grund-Infrastruktur. Dazu kommen dann noch > diverse speziellere Tools und auch IDEs für bestimmte Zwecke. Eben. Ich bin Profi und nutze weder Bash, python, Docker, git, make und vim. Ich konzentriere mich lieber auf mein Produkt, als auf eine tolle Toolchain. Das ist denke ich ein großer Fehler, den heutzutage vor allem Startups begehen. Die vergessen dann das Wesentliche, worum es eigentlich geht und schütten sich mi irgendwelchen Programmen zu... und versauen ihre Arbeitsweise. Wenn z.B. ein Kunde auf einen STM8 programmiert haben möchte, dann nehme ich STVD, für STM32 STM32CudeIDE, für Atmel das Atmel Studio 7. Ich baue mir keine Toolchain auf und gehe sofort ans Werk. Wenn es eine fertige SOftware gibt, dann nutze ich die auch. Gibts die später nicht mehr, nutze ich halt etwas anderes. Python ist meiner Auffassung nach etwas für kleine Programm interne Scripte. Ach aufm Linux programmiere ich (hardwarenah) in C/C++ und nicht in Python. Docker kannste gleich inne Tonne kloppen, das brauchen höchsten Fanboys aus dem Bereich Frontend/Backend. make nutze ich auch nicht, ich lebe nicht mehr im Jahr 1995.
Mark B. schrieb: > Lesen von Datenblättern. > Erstellen von Anforderungen. > Erstellen von Architektur/Design Dokumenten. > Editieren von Sourcecode. > Compiler. > Linker. > Debugger. > Test Framework. > Erstellen von Testberichten. Da fehlt noch: Repository für den Sourcecode. Change Management Tool / Application Lifecycle Management Tool.
:
Bearbeitet durch User
Den richtig guten reicht Power Point völlig. Damit überzeugt man die Chefs das man es drauf hat und man wird auf eine Position befördert die wiederum nur PowerPoint benötigt. Alles darunter sind "Implementierungsdetails" um die sich untergebene kümmern sollen. So läuft das.
Cyblord -. schrieb: > Den richtig guten reicht Power Point völlig. Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-)
Mark B. schrieb: > Cyblord -. schrieb: >> Den richtig guten reicht Power Point völlig. > > Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-) Abschließendes Kritierum ist die Zahl auf dem Gehaltszettel. Und wenn da jemand, angeblich völlig Ahnungslos, 150% von mir verdient, dann muss ich vielleicht meine Einschätzung korrigieren.
Cyblord -. schrieb: > Mark B. schrieb: >> Cyblord -. schrieb: >>> Den richtig guten reicht Power Point völlig. >> >> Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-) > > Abschließendes Kritierum ist die Zahl auf dem Gehaltszettel. Und wenn da > jemand, angeblich völlig Ahnungslos, 150% von mir verdient, dann muss > ich vielleicht meine Einschätzung korrigieren. Es gibt tatsächlich Leute, die schlechte Arbeit leisten und trotzdem viel verdienen. Möglich wird das durch ein System, in dem Manager schon lange keine echte Verantwortung mehr tragen. Zur Not gibt es halt den "goldenen Handschlag" und sie werden für ihre schlechte Leistung mit ein paar Millionen Euro Abfindung bestraft. :-/
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.