Portfolio Performance - Mein neues Programm

[Justphil]

Muss man bei PP eigentlich jeden Aktiensplit selbst eintragen, oder kommt das auf den Lieferanten der Kurse an?

Ich beziehe die Kurse von Google via Portfolio Report, in diesen Daten ist allerdings kein Split enthalten.

Das die Info irgendwie da sein muss ist klar, aber ich dachte das wären dann quasi "die eigenen" Daten, also wenn man schon das Wertpapier hat muss man sich selbst darum kümmern, dass beim Split eben die Anzahl erhöht wird.

 

Ich dachte wenn ich nun alle historischen Google Kurse lösche und neu lade, könnte ich auch einfach den Split umgehen.

(Mehr so eine unwichtige Frage, kann den Split natürlich auch recherchieren und dann eintragen )

[chirlu]

vor 15 Minuten von Justphil:

Muss man bei PP eigentlich jeden Aktiensplit selbst eintragen, oder kommt das auf den Lieferanten der Kurse an?

 

Die Kurse sind eine Sache, aber an der vorhandenen Stückzahl ändert sich ohne dein Zutun nichts.

[Marfir]

Kann man sich auch die Dividendenrendite an Hand des historischen Einstandskurses anzeigen lassen? Die Spalte "Div% 1 Jahr" berechnet das leider auf den aktuellen Kurs, was nur dann überein stimmt wenn zufällig der historische Einstandskurs dem aktuellen Kurs entspricht.

 

[chirlu]

vor 11 Minuten von Marfir:

Kann man sich auch die Dividendenrendite an Hand des historischen Einstandskurses anzeigen lassen?

 

Yield on cost nennt sich das. Nein.

[Marfir]

vor 2 Minuten von chirlu:

 

Yield on cost nennt sich das. Nein.

Oh 6 Jahre alter feature request. Wäre cool wenn das mal umsetzt werden würde. Die Kennzahl zu berechnen ist trivial und PP hat alle Infos die es dafür braucht. Sollte also keine große Sache sein. Woran hängt es?

 

[Merol Rolod]

vor 2 Stunden von Marfir:

Woran hängt es?

Dann frisch ans Werk. Es hindert dich niemand den Request umzusetzen.

[Marfir]

Am 26.3.2023 um 18:08 von Merol Rolod:

Dann frisch ans Werk. Es hindert dich niemand den Request umzusetzen.

Hm ich sehe gerade da sind noch 37 pull requests offen. Einige noch aus 2017. Scheinbar fehlts dem Projekt eher an Reviewern als an Umsetzern. Bin mir daher gerade unsicher ob es sich lohnt in das Projekt einzuarbeiten wenn mein PR dann vielleicht paar Jahre herumliegen würde.

[Bennerich]

vor 11 Stunden von Marfir:

Hm ich sehe gerade da sind noch 37 pull requests offen.

Aber auch 1.538 closed pull requests - die meisten davon auch gemergt.

Das Merging liegt an der Zeit (je kleiner, desto schneller) und den Auswirkungen der Änderungen (ja tiefer der Change eingreift, desto schwieriger).

Yield on Cost erscheint mir eher kleiner zu sein.

[chirlu]

Einige PRs sind auch steckengeblieben; d.h. es ist klar, dass es so nicht geht und überarbeitet werden muss, aber die Überarbeitung ist nie passiert.

[Marfir]

Ok danke für eurer feedback. Dann könnte man die alten PRs auch einfach schließen, dass es nicht so aussieht als wäre hier ein Review Stau.

[Marfir]

@Bennerich

Warum hat das Projekt so einen seltsamen package Namen "name.abuchen.portfolio"? Für mich wäre "de.portfolio" logischer?

[chirlu]

vor 42 Minuten von Marfir:

Für mich wäre "de.portfolio" logischer?

 

Die Domain portfolio.de gehört aber jemand anderem.

[Marfir]

vor einer Stunde von chirlu:

 

Die Domain portfolio.de gehört aber jemand anderem.

Das ist rechtlich betrachtet nicht relevant. Da die domain portfolio-performance.info lautet könnte man das root package auch info.pp nennen.

[chirlu]

vor 10 Minuten von Marfir:

Das ist rechtlich betrachtet nicht relevant.

 

Das hat auch niemand behauptet. Trotzdem sollte man sich an Konventionen halten.

 

vor 11 Minuten von Marfir:

könnte man das root package auch info.pp nennen.

 

Die Domain pp.info gehört auch jemand anderem, bzw. ist reserviert.

[Marfir]

vor 3 Minuten von chirlu:

 

Das hat auch niemand behauptet. Trotzdem sollte man sich an Konventionen halten.

die konvention wäre info.portfolio_performance welche hier nicht eingehalten wurde

[chirlu]

vor 3 Minuten von Marfir:

die konvention wäre info.portfolio_performance

 

Richtig.

 

vor 3 Minuten von Marfir:

welche hier nicht eingehalten wurde

 

Es gibt keine Vorgabe, welche deiner Domains du verwenden musst.  Ich vermute auch stark, dass es portfolio-performance.info zu Anfang noch gar nicht gab.

[Marfir]

vor 3 Minuten von chirlu:

 

Richtig.

 

 

Es gibt keine Vorgabe, welche deiner Domains du verwenden musst.  Ich vermute auch stark, dass es portfolio-performance.info zu Anfang noch gar nicht gab.

Deshalb hatte ich auch @Bennerich gefragt. Er muss es ja wissen.

Ich habe ein Ticket angelegt wo die Diskussion weiter gehen kann.

 

[chirlu]

vor 26 Minuten von Marfir:

Ich habe ein Ticket angelegt wo die Diskussion weiter gehen kann.

 

Erstens, Github-Tickets liest keiner. Zweitens, ich weiß nicht, was die Diskussion soll – das Paket heißt seit Ewigkeiten so, wie es heißt (entsprechend der Konvention, einen Domainnamen zu verwenden), und das wird auch kaum geändert werden.

[Marfir]

vor 21 Stunden von chirlu:

 

Erstens, Github-Tickets liest keiner. Zweitens, ich weiß nicht, was die Diskussion soll – das Paket heißt seit Ewigkeiten so, wie es heißt (entsprechend der Konvention, einen Domainnamen zu verwenden), und das wird auch kaum geändert werden.

Dein Statement ist merkwürdig. Du hast mir doch selbst auf 2 meiner Tickets geantwortet und etwa jedes zweite Ticket von anderen Autoren hat einen Kommentar (nicht alle geprüft). Scheinbar reden wir an einander vorbei. Mit Ticket meinte ich ein issue auf github.

Die Aussage "das war schon immer so und wird immer so sein" ist enttäuschend. Es ist nicht unüblich dass package namen auch mal refactored werden wenn sich die Hauptdomain ändert. Es gibt durchaus valide Gründe es so zu belassen ("haben wir schon immer so gemacht" sehe ich nicht als validen Grund).

Ich kann verstehen dass es Unbehagen bereitet wenn andere Entwickler auf den eigenen Code schauen und Fragen stellen. Aber Verbesserungsvorschläge mit "lesen wir nicht" und "war schon immer so (schlecht)" pauschal abzulehnen hatte ich nicht von einem der Hauptprogrammierer erwartet. 

[chirlu]

vor 52 Minuten von Marfir:

Mit Ticket meinte ich ein issue auf github.

 

Ich auch.

 

vor 53 Minuten von Marfir:

Es gibt durchaus valide Gründe es so zu belassen ("haben wir schon immer so gemacht" sehe ich nicht als validen Grund).

 

Gibt es denn einen validen Grund, den Namen zu ändern? Irgendeinen Nutzen?

 

vor 54 Minuten von Marfir:

von einem der Hauptprogrammierer

 

Offenbar meinst du mich damit. Ich sehe mich aber nicht als „einen der Hauptprogrammierer“; und ich kann auch nichts ablehnen.

[Bennerich]

Am 28.3.2023 um 20:49 von Marfir:

Warum hat das Projekt so einen seltsamen package Namen "name.abuchen.portfolio"?

Ich habe einfach eine Domain verwendet, die mir gehört - noch bevor ich überhaupt wusste, dass ich PP als Projekt veröffentliche. Die Domain portfolio-performance.info habe ich erst 4 Jahre später registriert.

 

Du hast auf jeden Fall recht - man könnte die Domain ändern. Leider ist der Name mir an einer Stelle in das XML gerutscht. Außerdem ist das package in den Preferences, d.h. zum Beispiel das Fensterlayout, die Spalten, die View-Einstellungen hängen davon ab. Und auch einige Parameter haben den Package-Namen drin, die zum Beispiel von den Linux Packages genutzt werden. Darum ist die Änderung des Package-Namen eine nicht triviale Änderungen - sicherlich machbar (es ist alles nur Software), aber das bedeutet einigen Aufwand. Und weil danach idealerweise alles wieder so funktioniert wie vorher, habe ich meine Zeit auf andere Features verwendet.

 

Github Issues werden in der Tat etwas stiefmütterlich behandelt. Das ist eine Frage der Zeit. Ich habe mir schon länger mal vorgenommen, die Github Issues zu bereinigen - einfach alles alte wegräumen um dann auf neue Tickets besser reagieren zu können. Oder besser zu kategorisieren. Und schneller mal zu zumachen (auch wenn es weh tut). Vielleicht schaffe ich das im April mal wirklich anzugehen - aber versprechen kann ich nichts.

[Marfir]

vor 9 Stunden von Bennerich:

Ich habe einfach eine Domain verwendet, die mir gehört - noch bevor ich überhaupt wusste, dass ich PP als Projekt veröffentliche. Die Domain portfolio-performance.info habe ich erst 4 Jahre später registriert.

 

Du hast auf jeden Fall recht - man könnte die Domain ändern. Leider ist der Name mir an einer Stelle in das XML gerutscht. Außerdem ist das package in den Preferences, d.h. zum Beispiel das Fensterlayout, die Spalten, die View-Einstellungen hängen davon ab. Und auch einige Parameter haben den Package-Namen drin, die zum Beispiel von den Linux Packages genutzt werden. Darum ist die Änderung des Package-Namen eine nicht triviale Änderungen - sicherlich machbar (es ist alles nur Software), aber das bedeutet einigen Aufwand. Und weil danach idealerweise alles wieder so funktioniert wie vorher, habe ich meine Zeit auf andere Features verwendet.

 

Github Issues werden in der Tat etwas stiefmütterlich behandelt. Das ist eine Frage der Zeit. Ich habe mir schon länger mal vorgenommen, die Github Issues zu bereinigen - einfach alles alte wegräumen um dann auf neue Tickets besser reagieren zu können. Oder besser zu kategorisieren. Und schneller mal zu zumachen (auch wenn es weh tut). Vielleicht schaffe ich das im April mal wirklich anzugehen - aber versprechen kann ich nichts.

Super danke für die Erklärung. Das es so weitreichende Auswirkungen hat war mir nicht bewusst. Da stimme ich zu, dann macht es Sinn das so zu belassen.

 

Bzgl. github issues: Ich konnte die refactoring tickets nur als bug anlegen, da es außer feature und bug nichts anderes zur Auswahl gab. Kann man da noch einen weiteren issue Typ definieren? Ansonsten kann man das dann blos mit labels als workaround kennzeichnen. 716 issues aufräumen ist in der Tat nicht einfach. Sind sicher auch viele duplicated darunter.

[exiting]

Hallo allerseits,

 

war jemand in den letzten Tagen damit erfolgreich historische Kurse von onvista zu laden? Meine Letzten sind vom 28.3., danach nichts Neues. Die debug Antwort sieht allerdings auf den ersten Blick unverdächtig  aus, also keine offensichtliche Änderung auf Server-Seite oder ein Fehlercode. Im PP Forum Thread dazu gibt es nichts neues, deshalb bin ich gar nicht sicher ob das Problem nicht bei mir liegt.

[Marfir]

vor 19 Stunden von chirlu:

Gibt es denn einen validen Grund, den Namen zu ändern? Irgendeinen Nutzen?

 

Natürlich. Gutes naming bei packages, klassen, variablen etc. ist wichtig. Bei name.abuchen habe ich erst gedacht das ist irgend ein Wortwitz "ab buchen". Das das eine domain sein soll, die dann auf xing weiter leitet aber nicht auf portfolio-performance war halt seltsam.

[Marfir]

@Bennerich

Sorry noch eine Frage. Wieso ist die Projektstruktur so untypisch? Normaler weise liegt der source code unter src/main/java und tests unter src/test/java. Gleiches für resourcen. Hier sind Tests aber in einem anderen Submodul organisiert als der eigentlich zu testende Code. Und die Resourcen liegen in den Code packages mit drin anstatt extra.

Für ein Maven Multimodulprojekt ist die Struktur auch gewöhnungsbedürftig. Normaler weise liegt im root die parent pom und darunter sind die module. Hier scheint portfolio-app das parent zu sein, obwohl es auf der gleichen Ebene ist wie der Rest.