mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Literatur-Tipps zum Thema Software-Entwicklung gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Quereinsteiger (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin Projektleiter im Bereich Maschinenbau und kümmere mich 
zusätzlich um das Thema Prozessoptimierung. Ich habe immer mehr 
Berührungspunkte mit IT-Themen, weil ich die funktionalen Anforderungen 
des Fachbereichs vertrete.

Begriffe, die für jeden ITler selbstverständlich sind (z.B. GUI, 
Klassendiagramme, relationale Datenbank..) muss ich mir bisher aneignen, 
um bei den Diskussionen "mitzuhalten". Ich suche dementsprechend nach 
geeigneter Literatur, um entsprechende IT-Grundlagen zu lernen. Mein 
Ziel ist es, größere IT-Projekte leiten zu können.

Was ich bisher für den groben Überblick recht gut fand:
- Handbuch für Softwareentwickler vom Rheinwerk-Verlag
- Modernes Projektmanagement von Timinger, Holger

Folgende Bücher klingen für mich ansprechend:
- IT-Projektmanagement: Was wirklich funktioniert – und was nicht. von 
Matthias Geirhos
- Handbuch IT-Projektmanagement von Ernst Tiemeyer
- Systematisches Requirements Engineering von Christof Ebert

Habt ihr weitere Tipps? Gerne auch Blogs oder Youtube-Kanäle zu dem 
Thema.

Schon mal vielen Dank!

Beitrag #5935856 wurde von einem Moderator gelöscht.
Beitrag #5935860 wurde von einem Moderator gelöscht.
Beitrag #5935863 wurde von einem Moderator gelöscht.
Autor: Peter123 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Die Recherche nach passender Literatur sollten studierte Leute bzw. 
Studenten an Universitäten eigentlich selbst leisten können. (Das wurde 
uns im Studium sinngemäß von den Profs so gesagt.)

Beitrag #5935877 wurde von einem Moderator gelöscht.
Autor: Quereinsteiger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter123 schrieb:
> Die Recherche nach passender Literatur sollten studierte Leute
> bzw. Studenten an Universitäten eigentlich selbst leisten können. (Das wurde
> uns im Studium sinngemäß von den Profs so gesagt.)

Sehe ich auch so. Deswegen habe ich ja schon Recherche betrieben. Habe 
nun mit einem Fernstudium in Informatik begonnen, den Scrum-Master 
gemacht (weil ja überall nur noch von Sprints die Rede ist..) und eigne 
mir Sachen bisher über verschiedene Medien bei Bedarf an. Ich hatte mir 
erhofft, dass sich hier auch andere weiterbilden und gute Tipps haben.

Autor: Peter123 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Einen Tipp kann ich dir aber doch geben:

Ist quasi ein Standardwerk mit vielen Auflagen:

- Ian Sommerville, Software Engineering

Einfach mal den Titel in der Amazon Suche eingeben

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"The mythical man month" ist auch ein lesenswerter Klassiker.

Autor: Quereinsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter123 & Walter T.
Danke! Werde ich mir mal genauer anschauen.

Autor: Test (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
In einem Informatikstudium ist Softwareentwicklung eigentlich nur (wenn 
überhaupt) ein Randthema. Das meiste ist einfach nur knallharte 
Mathematik. GUIs und Sprints interessieren da auch niemanden. Es geht um 
Algorithmen, Beweise und Mathematik. Das wird dir also für die Praxis 
nicht viel bringen.

Autor: Quereinsteiger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Test (Gast)
Ja, dem bin ich mir bewusst. Ich bin derzeit als Akademie-Student an der 
Fernuni-Hagen eingeschrieben. Gerade lerne ich Software Engineering 
(sehr UML lastig), was ich interessant finde. Mit dem Thema Datenbanken 
hatte ich beruflich Berührungspunkte und werde ich das kommende Semester 
auch belegen.

Programmierkenntnisse habe ich in Maßen, weil ich beruflich ab und zu 
kleinere Anwendungen schreibe (Daten abgleichen, Texte verarbeiten). Ob 
ich mir wirklich ein komplettes Studium antue, weiß ich noch nicht. 
Mathe hatte ich schon im Maschinenbau-Studium genug und braucht man als 
Projektleiter realistisch gesehen nicht. Mir geht es eher darum, mir das 
Vokabular anzueignen.

Als Projektleiter im Maschinenbau sind die Tätigkeiten (meine Vermutung) 
ähnlich wie in der Software-Entwicklung:
- Anforderungen richtig erfassen (nicht das machen, was der Kunde einem 
vorgibt, sondern das machen, was den Kunden am Ende wirklich zufrieden 
stellt)
- Arbeitspakete planen und Abhängigkeiten der Pakete auf dem Schirm 
haben
- Arbeitspakete gut vorbereiten, dass man für die Abarbeitung nicht 
zwingend das beste Pferd im Stell einsetzen muss
- Die Änderungswünsche der Kunden aus den Besprechungen bewerten und 
koordiniert ins Team streuen
- Schauen, wer aus dem Team dafür geeignet (und verfügbar ist). Sprich: 
Macht's der Senior oder kann ich darauf auch mal einen Einsteiger 
loslassen, weil da nichts anbrennt.
- Wenn ein Arbeitspaket nicht nach Plan läuft, darauf verstärkt den 
Fokus legen
- Zeitabschätzungen & Kompetenzen der Mitarbeiter hinterfragen (ich hab 
manchmal Berufseinsteiger, die bessere Leistung liefern als manch ein 
geduldeter "Erfahrener")
- Schauen, dass kein unkontrolliertes Produkt an den Kunden geht
- und das Finanzielle wie Stunden haken, Projekt ausplanen, 
Lenkungsausschüsse, Rechnungen stellen, Chef beruhigen, dass man alles 
im Griff hat etc.

Mir fehlt ein bisschen der Abgleich, ob der Arbeitsalltag so viel anders 
ist als jetzt im Maschinenbau. Am schwierigsten stelle ich es mir 
derzeit vor, die Kompetenz von anderen Mitarbeitern richtig 
einzuschätzen, da mir die Kompetenz dafür fehlt.

Beitrag #5936171 wurde von einem Moderator gelöscht.
Autor: klausi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja in Zukunft noch mehr, wenn nicht schon heute, wird die IT das Zentrum 
sein.. Hypewort"Digitalisierung"...
Klar klassisches Engineering bzw Leute die es verstehen, wird man immer 
noch benötigen. Aber auch da, wird vieles automatisiert werden... Von 
IT..

Beitrag #5936181 wurde von einem Moderator gelöscht.
Autor: Quereinsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Einfach unverbesserlich (Gast)
Ja, leider.. ich war bisher stets bemüht, nicht das typische Ende von 
Peterchen zu erleiden.. Wie Klaus schreibt, schreitet die 
Digitalisierung immer mehr voran, auch im Maschinenbau. Ich hab ab und 
zu Studenten, die für mich Sachen programmieren und Chefs, die nicht 
einsehen, dass diese auch von kompetenten Fachleuten betreut werden 
müssen. Am Ende muss ich als Laie selbst drüber schauen, warum irgendwas 
nicht funktioniert oder das Programm anpassen, wenn der Student wieder 
weg ist. Oder ich soll in Vorstellungsgesprächen beurteilen, ob der 
Werkstudent kompetent genug für den Job ist.

Bisher agiere ich nur anhand von "gesundem Menschenverstand" wie 
Variablen sinnvoll benennen, Versionierungen einführen, modularer Aufbau 
der Programme  Wiederverwendung von Modulen  Testen von Extremfällen 
etc.
Ich merke bei meinem AG, dass man aus Mangel an guten IT-Projektleitern 
irgendwelche Entwickler nimmt, die die Anforderungen an die Software 
nicht verstehen, keine sinnvollen Prioritäten setzen und teilweise 
unnütze Software ausrollen (die dann den üblichen Tod stirbt, weils 
keiner benutzt).

Beitrag #5936214 wurde von einem Moderator gelöscht.
Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal diesen edX Kurs an:

https://www.edx.org/course/software-engineering-essentials

Der ist als Uebersicht wirklich super und aufbauend auf diesem Wissen 
wuerde ich dann entsprechend nach Literatur suchen. Es werden auch 
Literaturempfehlungen gegeben an die man sich halten kann.

Ein Buch das alles abdeckt wird schwierig zu finden sein, dazu gibt es 
einfach zuviele verschiedene Teilbereiche.

Wenn es mehr um die Prozesse gehen soll, als um die Entwicklung, dann 
kann ich noch das Buch

https://www.oreilly.com/library/view/the-devops-handbook/9781457191381/

empfehlen. Wenn man so wirklich bei 0 anfangen muss, dann unbedingt 
vorher noch diesen Roman lesen

https://www.amazon.de/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

Sehr kurzweilig und macht richtig Spass. Gibt es mittlerweile auch auf 
deutsch.

Autor: Dipl. Inf (FH) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil 
die Musik einfach in den USA spielt und deutsche Autoren den 
Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken 
abschreiben. Zudem liest sich das häufig so spannend wie 
Steuerparagraphen.

Mythical Man Month wurde ja schon genannt.

Der Termin ist ein sehr gutes Buch über Projektmanagement, als 
kurzweiliger Roman verpackt.

Peopleware ist der Klassiker zum Umgang mit den Entwicklern.

Wenn's praktischer sein soll auch Clean Architecture. Einfach, damit man 
weiss, dass es sowas wie Software Architektur überhaupt gibt und die 
Entwickler nicht alles nur schnell zusammen hacken sollen.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dipl. Inf (FH) schrieb:
> Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil
> die Musik einfach in den USA spielt und deutsche Autoren den
> Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken
> abschreiben.

Die obige Empfehlung war fuer den deutschen Roman. Es liesst sich auch 
auf Englisch sehr gut, jedoch finde ich es gut, dass eine deutsche 
Alternative gibt. Es geht auch darum wie die verschiedenen Charaktere 
untereinander in Beziehung stehen, da ist das schon in Ordnung.

Allerdings ist die englische Originalfassung wirklich in verstaendlichem 
Englisch geschrieben, das koennte laessig als Schullektuere durchgehen.

Autor: MeineMeinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobias B.
Der edx-Kurs klingt sehr gut! Danke!
Vom Phoenix- Buch hatte ich bisher nur eine kindle Leseprobe. Dort gings 
um die Beförderung vom Protagonisten, weniger um technische Details. 
Ändert sich das im Laufe des Buchs?

@Dipl. Inf
Danke für die Buchtipps! Bisher lese ich sehr "pragmatische" Bücher und 
schau mir ab und zu Youtube-Videos dazu an, aber Romane sind zur 
Auflockerung auch gut.

Mir ist bewusst, dass in der IT Englisch noch wichtiger ist als im 
Maschinenbau. Für den Scrum Master habe ich mit dem Original Scrum-Guide 
gelernt, weil mir der Umweg über die deutsche Übersetzung auch zu 
umständlich vorkam. Bin aber auch nicht abgeneigt, wenn es gute deutsche 
Literatur gibt. Liest sich schneller und ich bin nicht so mit der 
Interpretation von manchen Begriffen beschäftigt.

Autor: NurMut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dipl. Inf (FH) schrieb:
> Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil
> die Musik einfach in den USA spielt und deutsche Autoren den
> Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken
> abschreiben.

Dann könnte man auch chinesische Literatur empfehlen.

Dipl. Inf (FH) schrieb:
> Zudem liest sich das häufig so spannend wie Steuerparagraphen.

Das ist mein Hauptargument für amerikanische Literatur und Vorlesungen. 
Es wird so einleuchtend erläutert, dass es im Prinzip jeder direkt 
versteht. Zitat eines Professors: Ich habe Elektrotechnik nicht während 
des Studiums verstanden, nicht während meiner Promotion, nicht in meiner 
10 jährigen Industrietätigkeit, sondern richtig tiefgreifend erst seit 
dem ich Professor bin. Ein Teilgrund dafür ist meiner Meinung nach, dass 
die deutschen Lehrbücher ähnlich formuliert sind wie das deutsche 
Steuerrecht.

Samenstau im Maschinenbau schrieb im Beitrag #5935860:
> Das Softwareteam streitet sich immer mit dem Elektronikteam.
> Aber beide können sich darauf einigen, dass die Maschinenbauer gegenüber
> die wahren Deppen sind.

Kindergarten!

Tobias B. schrieb:
> Allerdings ist die englische Originalfassung wirklich in verstaendlichem
> Englisch geschrieben, das koennte laessig als Schullektuere durchgehen.

Das ist meistens so.

Autor: Kollege (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also ehrlich! Ihr seid wieder einmal so über alle Maßen überheblich und 
teilweise beleidigend! Muß das wirklich so sein? Mit Euch würde ich, 
wenn Ihr Euch im Betrieb auch so benehmt, nicht arbeiten wollen. Auch 
Maschinenbauer sind Menschen:-)

Der TO hat aus seiner Sicht bestimmt guten Grund zu seiner Frage und es 
ist sein Privileg und Angelegenheit. Wenn ihr was dagegen habt, dann 
bleibt doch einfach still. Man ist auch in einem Forum nicht zu einer 
Entgegnung gezwungen.

Beitrag #5936429 wurde von einem Moderator gelöscht.
Autor: Quereinsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ron Jeremy
Vermutlich Mangel an Alternativen. Die ITler & Consultants bei meinem AG 
verstehen die komplexen Anwendungsfälle nicht. Befriedigen ihre Tickets 
und ignorieren User-Rückmeldungen, so lang der Chef oder Kunde die Tools 
"cool" findet. Die merken erst Jahre später, dass es ein Millionengrab 
ist, weils keiner nutzt. Dann kommen sie wieder zu mir, weil ich ihnen 
das von Anfang an so prognostiziert habe & andere Ideen hatte. Bin 
vielleicht IT-technisch ein Noob, aber zumindest das Buttons nicht nur 
schön aussehen müssen, weiß ich.

Autor: Peter123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit 
ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute 
zusammenzubringen.

Beitrag #5936561 wurde von einem Moderator gelöscht.
Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MeineMeinung schrieb:
> @Tobias B.
> Der edx-Kurs klingt sehr gut! Danke!
> Vom Phoenix- Buch hatte ich bisher nur eine kindle Leseprobe. Dort gings
> um die Beförderung vom Protagonisten, weniger um technische Details.
> Ändert sich das im Laufe des Buchs?

Ohja, da gehts drunter und drueber. Ich will jetzt nicht zu viel 
Spoilern, aber erst wird der Laden an die Wand gefahren und beim Aufbau 
von vernuenftigen Prozessen wirds dann auch technischer. In der Regel 
werden auf die Koryphaeen der jeweiligen Prozessbereiche eingegangen und 
auf deren Standardwerke. Im Anhang wird das dann noch technischer und 
detailierter ausgefuehrt.

Ich wuerde das Buch jetzt nicht unbedingt als technischen Leitfaden 
nehmen, dafuer ist dann das Buch von Gene Kim, et al ("The DevOps 
Handbook") viel besser geeignet (hab gerade geehen dass es das 
mittlerweile auch auf deutsch gibt, ob das aber taugt weiss ich nicht). 
Der Roman eignet sich eher als Motivation und da man super mit den 
Charakteren mitfuehlen kann (und das DevOps Handbook auch immer wieder 
auf die Geschichte referenziert) hat man einen wirklich tollen 
Praxisbezug, auch wenn die Geschichte fiktiv ist.

: Bearbeitet durch User
Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter123 schrieb:
> Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit
> ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute
> zusammenzubringen.

Full ACK. Leider braucht man selbst entsprechende Expertise und die 
Expertise anderer einzuschaetzen. Interessant dazu auch foglender Wiki 
Artikel:

https://de.wikipedia.org/wiki/Anti-Pattern#Organisations-,_Management-_bzw._Prozess-Anti-Pattern

Ich wuerde daher sogar noch eine Stufe runtergehen und behaupten, ein 
guter Projektleiter vertraut auf die Expertise seiner Experten.

Autor: Peter123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Peter123 schrieb:
>> Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit
>> ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute
>> zusammenzubringen.
>
> Full ACK. Leider braucht man selbst entsprechende Expertise und die
> Expertise anderer einzuschaetzen. Interessant dazu auch foglender Wiki
> Artikel:
>
> 
https://de.wikipedia.org/wiki/Anti-Pattern#Organisations-,_Management-_bzw._Prozess-Anti-Pattern
>
> Ich wuerde daher sogar noch eine Stufe runtergehen und behaupten, ein
> guter Projektleiter vertraut auf die Expertise seiner Experten.

Sehr interessanter Artikel. Vielen Dank für den Link!

Autor: Quereinsteiger (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@Tobias B.
Das klingt gut! Kommt auf meine Liste, wenn ich mal ein wenig was 
Entspanntes zwischendrin lesen will. Von der Story her war die Leseprobe 
unterhaltsam. Wobei ich auch genug Storys von meinem AG schreiben 
könnte.. Hatte in letzter Zeit viel mit der Management-Ebene zu tun. Da 
wundere ich mich oft, wie manche Leute an so eine hohe Stelle kommen 
konnten.

Der Link ist echt genial. Gilt nicht nur für den IT-Bereich.
Mir wurde zu dem Thema ein gutes Video von Fefe empfohlen:
Youtube-Video "34C3 -  Antipatterns und Missverständnisse in der Softwareentwicklung"

@Peter
Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler 
und unter Stress versemmeln die besten Leute was. Wenn man das als Team 
abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem 
geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen 
Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf. 
viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu 
finden, wo derjenige nicht so viel Schaden anrichtet.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quereinsteiger schrieb:
> @Tobias B.
> Das klingt gut! Kommt auf meine Liste, wenn ich mal ein wenig was
> Entspanntes zwischendrin lesen will. Von der Story her war die Leseprobe
> unterhaltsam.

Ok, dann findest du sicher zu jedem Charakter eine Person, die du im 
realen Leben mal kennen gelernt hast. Das macht das Buch auch 
autenthisch und ich wette das der Autor aehnlichs erlebt hat, es 
beschreibt einfach den allgemeinen Wahnsinn im Alltag, jedoch mit Happy 
End. :-)

Quereinsteiger schrieb:
> Der Link ist echt genial. Gilt nicht nur für den IT-Bereich.
> Mir wurde zu dem Thema ein gutes Video von Fefe empfohlen:
> Youtube-Video "34C3 -  Antipatterns und Missverständnisse in der
> Softwareentwicklung"

Danke fuer den Link, werde ich mir mit Vergnuegen ansehen.

: Bearbeitet durch User
Autor: Peter123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quereinsteiger schrieb:
> @Peter
> Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler
> und unter Stress versemmeln die besten Leute was. Wenn man das als Team
> abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem
> geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen
> Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf.
> viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu
> finden, wo derjenige nicht so viel Schaden anrichtet.

Mag ja alles wahr sein. Aber das hängt auch von der Größe und Struktur 
Eurer Organisation (Firma) ab, ob der Projektleiter (der Chef) im 
operativen Geschäft (bei der Softwareentwicklung) noch direkt mitmischen 
sollte oder nicht. Weil ich die ja nicht kenne, kann ich auch dazu keine 
Aussagen machen.

Es ist nämlich ein großer Unterschied, ob du als Projektleiter z.B. 10 
Mitarbeiter/Softwareentwickler oder 100 Mitarbeiter/Softwareentwickler 
leitest. Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der 
Erstellung einer Softwarelösung mitzuarbeiten. Aber ich denke bei 100 
Mitarbeitern, aufgeteilt in verschiedene Projektgruppen, wird es schon 
schwierig.

Autor: Quereinsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,
sind je nach Projektphase 5-15 Leute.

Autor: NurMut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter123 schrieb:
> Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der
> Erstellung einer Softwarelösung mitzuarbeiten.

Selbst bei 10 Leuten ist der SW Projektleiter normalerweise wegen 
Meetings, Freigaben, Releaseplanung und Koordination so zu, dass er 
bestenfalls mal über die SW schauen kann, aber nicht mehr selbst 
programmieren.

Ausnahme: Sein Team besteht aus Frischlingen, die es nicht gebacken 
bekommen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.