DerLenny

@Muddlehead

Ich wünschte, da gäbe es eine klare und immer funktionierende Lösung.

 

Du hast hier die gleichen Probleme die bei Knowledge management immer auftauchen.

Die einzelnen Quellen können ja aus mehreren Gründen interessant sein (auch wenn man sie aktuell nur für ein Projekt braucht).

 

Aus Sicht des jeweiligen Projekts möchtest du eine hierarchische Struktur, die zu deinem Projekt passt. Aus eine r mehr generellen Sicht, willst du ein Netz an Informationen. Diese beiden Strukturen können sich anteilig stark unterscheiden.Auch sind bei Hierarchien nicht immer die Ordnung der Gliederungsebenen gleich, da man ggf. verschiedene Ansichten auf das gleiche Datenmaterial braucht, etc.

 

Ich bau mir halt einen Order für das Projekt, und hau da alles rein, was ich finde. Teilweise erstelle ich hier auch direkt Unterordner.

Dann geh ich nochmal drüber, wen ich eine bessere Idee des Gebiets und vom Aufbau meiner Arbeit habe und vergebe TAGS, damit ich, wenn ich in meiner eigenen Literatur DB suche auch finde.

 

Mein Workflow ist also: Schritt 1: in meinen bestehenden Referenzen suchen, das schließt Zotero und meine lokal gespeicherten Bücher und Papers ein.

Dann gehe ich auf eine allgemeine Suche (scholar, diverse Datenbanken) und haue das entweder in meinen Hauptordner, oder in Unterordner, wenn ich schon eine grobe Idee hab.

Am Ende ordne ich die Infos nochmal nach den Anforderungen meiner Arbeit.

 

Ich hab bei der Recherche dann immer noch nen Notizbuch offen, damit ich mir Ideen und interessante Punkte (nach denen ich ggf. später weiter suchen möchte) notieren kann.

Ah, ich mach mir immer einen großen ordner in Zotero, und geh dann durch und verteile dann die Artikel auf Unterornder. Word tut aber sicher auch, und man kann glaub auch viel flexibler Zeu dazu schreiben... hm.. evt. teste ich das mal aus :)

Danke für den Tipp!

Zitat

Die Quellen habe ich mir in ein Word-Dokument gepackt und die Quellen (sogar mit DOI!) farblich markiert.

 

Nutzt du kein Literaturverwaltungsprogramm?

Yeah! Freu mich schon! 😄

Wow, cooles Thema. Das gibt eine Menge her, und ist super interessant.    

Schreist du dan Updates hier, wie das Schreiben läuft?

ok, ich denke zwar, das bekommst du hin, wenn du es wirklich als Puzzleaufgabe siehst, und hier ggf. Fragen stellst, aber ich vertrau mal Deiner Meinung :)

 

Es ist eigentlich gar nicht so schwer, und der Baum ist halt ein Nebenprodukt. Wenn du meinst, es wäre zu schwer es wirklich zu programmieren - schreib mal auf, wie du es machen würdest.

Wirklich so Pen&Paper mäßig.

Und spiel dann mal den Ablauf im Kopp durch, und mal dir auf nem anderen Zettel auf, wie sich die Daten ändern.

 

Wenn du dir vorstellen kannst, wie das funktioniert, ist das Programmieren nur noch der letzte Schritt. Wenn du dir an manchen Stellen nicht sicher bist, schreib grob auf, was an der Stelle passiert.

Du kannst es dann immer noch genauer formulieren, wenn du die groben Schritte hast.

Und wenn du merkst, dass du ne schleife brauchst, kannst einfach nen Pfeil an die Stelle machen, etc.

Das Ergebnis ist dann evtl. kein 'gültiges" Flussdiagram, aber es geht auch erstmal um die Strukturierung der Problemlösung. Und das geht mit Stift und Papier wirklich besser, als wenn man sich auch noch mit ner Sprache rumschlagen muss.

 

Und wenn der Ablauf passt, ist der Übergang zu Code auch wirklich nur noch ein googeln von "wie mache ich X in [Programmiersprache].'

 

 

 

Mist, wollte bearbeiten, nicht zitieren... und eigentlich noch kurz darauf hinweisen, dass die erste C++ Implementierung von Stroustrup C code erzeugt hat, der dann kompiliert wurde.

Coding-Trivia FTW.

Die Basis ist das Strukturieren, das funktioniert dann sowohl auf Code als auch auf Daten Ebene.

 

Wenn Du ein Problem in Einzelschritte, Oberbegriffe, bedingte Ausführungen und Schleifen zerlegen kannst, und sei es nur im Kopp oder aufm Stück Papier hast den größten Teil geschafft.

Programmbeispiele sollten an der Stelle wirklich nur Beispiele sein. Programmiersprachen sind austauschbar, die Basics bleiben.

 

Es macht absolut Sinn zuerst die Grundlagen des Programmflusses zu lernen, und dann einen Blick auf Datenstrukturen und dann auf Algorithmen zu werfen, die mit diesen Datenstrukturen arbeiten.

 

Es macht Sinn, einen kleinen Ausflug in die Geschichte der Programmiersprachen zu werfen, damit einem klar wird, warum Dinge so sind. Die meisten profs haben das halt gemacht, weil sie mit dem Zeug groß geworden sind. 

 

Wer aber noch nie in einer Sprache gearbeitet (oder sie zumindest gesehen hat), die nicht strukturiert ist (sagen wir mal C64 Basic oder Z80 ASM), dem wird nicht klar werden, warum strukturierte Programmierung so funzt, wie sie funzt.

Objektorientieres Design ist eigentlich nur strukturierte Programmierung, nur dass jede Funktion einen (versteckten) Parameter auf das Datenobjekt bekommt, zu dem es gehört. Dieser versteckte Parameter ist auch der Grund, warum man zwischen Funktionen und Methoden unterscheidet. Funktionen bekommen diesen Param nicht, Methoden bekommen ihn.

Mir fehlt oft auch die Unterscheidung zwischen Objekt-orientierten Design und Obj. Orientierter Programmierung. 

 

Das sind Tools, die einen eine Aufgabe erleichtern sollen. Wenn ich OOP/OOD alsSelbstzweck einsetze, sind die Ergebnisse meist fürchterlich. Auch der Versuch sich an "realen" Objekten zu orientieren, anstatt am Problem kann teilweise zu diesem Problem führen.

 

Wenn du gerade an Datenstrukturen knabberst:

Ich hätte eine Idee für ein kurzes Spiel, bei dem du am Ende ein besseres Verständnis für Bäume (und damit auch Listen) hast:

 

Tiere raten.

Die Ausgabe sieht in etwa wie folgt aus:

Zitat

Denke Dir ein Tier.

Schwimmt es? (j/n)

> n
Ist es eine Taube? (j/n)
> n
Was ist es dann?
> Katze
Mit welcher Frage kann man "Taube" und "Katze" unterscheiden?
> Ist es ein Säugetier
Und für "Katze" ist die Antwort?
> j
Danke.
Noch ein Spiel?

Du fängst mit 3 Knoten am Anfang an.
Schwimmt es

  j: Hai
  n: Taube

 

Wenn das Tier nicht erraten wird, legst du einen neuen Knoten für die Frage und die Antworten an:

Schwimmt es

 j: Hai

 n: Ist es ein Säugetier

      j: Katze

      n: Taube

Hat ein Knoten keine Kinder, dann ist es ein Endknoten, dann kommt die "Ist es ein X" Frage.

 

Am Anfang musst halt die Daten bei jedem start neu eingeben. Und dann schreibst eine Serialisierung dafür, damit du es speichern kannst. Und dann natürlich auch wieder laden.

 

Das war das erste Problem bei dem ich mich mit Bäumen und Serialisierung auseinander gesetzt habe.

 

Man knobelt am Anfang ein bisschen, aber wenn es mal läuft, ist es echt eine nette Sache :)

 

Das Buch, von dem ich immer noch profitiere ist: "The Pragmatic Programmer."

 

Gerade am Anfang tendiert man dazu, Dinge etwas komplizierter zu bauen, als sie sein müssen - Pragmatic Programmer holt einen wieder etwas auf den Boden der Tatsachen zurück.

 

vor 11 Minuten hat Nadja_studiert_Informatik geschrieben:

ein kleines Rollenspiel

Wenn du es schaffst, es klein zu halten...

 

Rollenspiele gehen schnell in gewaltige Dimensionen. 

Mach am Anfang evtl. eher sowas wie die Card Battler - da sind viele Element ähnlich (deine Karten/ Chars haben Werte, Specials, etc), aber du brauchst deutlich weniger "Drum-herum" Code.

 

Da ist auch das Handling näher an typischen Applikationen, da du die normalen GUI Events nutzen kannst. Du kannst aber trotzdem viele RPG-Dinge ausleben. Wäre evtl. ein guter Mittelweg.

 

Hast dir überlegt dein Java Projekt für Android zu machen?

Android ist IMO einer der besten Gründe aktuell ein Java Projekt zu starten.

 

Anonsten: Such dir was aus, was Dir Spaß macht/ dich interessiert, und setz ds in java um.

 

ich habe zu Browser Applet Zeiten ne Menge Games in Java geschrieben. Wenn es Dir Spaß macht, dann ist a) die Motivation höher, und wenn du dir b) noch ein kleines Spiel schnappst, dann ist das auch nicht so das Ding.

Snake in Java, dann musst mit Schleifen und Listen hantieren, es ist Echtzeit, etc. 

Nice!

Ichhab mir auch schon überlegt von Anki auf einen physikalischen Karteikasten umzusteigen, einfach weil man bei der Erstellung der Karten mehr Aufwand braucht und damit auch eher was hängen blebt.

 

Ich bin aktuell am hadern ob ich es eher "Lexikon-Style" mäßig mache, also Begriff auf der einen und Erklärung auf der anderen Seite, oder ob ich die "Fragen-Seite" wirklich als Frage definiere, damit ich a) näher an der Klausur bin und b) dies wohl auch den Abrufprozess verbessern soll.

 

hast du das mal probiert und hast da evtl. schon Erfahrungen?

Herzlichen Glückwunsch! :)