xREL.v3

xREL Terminal Client - Thema

Sprache wählen
Board RSS API Status Hilfe Kontakt
xREL-Forum > xREL.to > Developer Forum
xREL Terminal Client
HashWorks
HashWorks Quoten-Ossi
17. Jan. 2016, 21:11 Uhr
https://github.com/hashworks/xRELTerminalClient

Da DerGrinch ja in letzter Zeit mal was an der API macht (und vor allem mal die Suche hinzugekommen ist) hab ich mich mal daran gemacht n' Terminal Client zu schreiben.

Sollte wenn ich nichts übersehen habe von der kompletten API nutzen machen.

Ist mein erstes Projekt in Go, wer sich da also besser auskennt darf sich auch gern mal den Code anschauen, bin mir sicher es gibt ein paar Sachen die ich da "falsch" mache :)

#


 
DerGrinch
18. Jan. 2016, 00:00 Uhr
Habe selbst vor nicht allzu langer Zeit mit Go angefangen und war sofort von begeistert, vor allem von der Produktivität und der Einfachheit der Sprache. Ich habe deinen Code mal überflogen und habe vor allem "organisatorische" Dinge gefunden die ich nicht so toll finde:
  • Du hast vielleicht zu viele Packages. Der configHandler passt eigentlich auch in das main package (du kannst da mehr als eine Datei haben, hat lange gedauert bis ich das herausgefunden habe...), das oauth-package in das api-package. Das haut aktuell nicht ganz hin, da auch api den configHandler braucht, deswegen:
  • Mit einem (für das api-package) globalem config-struct dort die Einstellungen verwalten, die man anfangs einmal mit einer Methode von außen setzen muss. Der Vorteil: Wenn ich nun ein eigenes Programm mache dass die xREL-API braucht, mache ich einfach ein "import github.com/hashworks/xRELTerminalClient/api" und kann dein Grundgerüst dafür nutzen und muss es nicht neu machen. Aktuell muss ich mich jedoch dann an deine Vorgaben des configHandlers halten, der (ich habe das nur überflogen) ein Format/Pfad für die Config-Datei vorgibt. Unschön.
  • Ebenfalls aus dem Grund der Wiederverwertung: Schönere Package Names. Die api wird xrelapi (oder auch nur "xrel"?). Man kann zwar den Package-Namen "überschreiben" (also das github.com/b/api als xrelapi verfügbar gemacht wird), sprechende Namen sind da trotzdem netter. Die Twitter-API läuft zum Beispiel einfach als "twitter", da es dann schöne Befehle ala twitter.Tweet() ergibt :) (Da das client-package wohl kaum von anderen Projekten importiert werden würde muss man sowas dort nicht unbedingt machen bzw. beachten).
  • Das client-Package könnte man auch komplett auflösen (und ins main hauen). Wie eben geschrieben wird das kaum einzeln in fremde Projekte importiert werden. Die Projekt-Interne (nicht für andere Projekte zur Wiederverwendung gedachte) Struktur bleibt jedoch komplett dir überlassen, und nach einem überfliegen des Codes macht es rein wegen der Übersichtlichkeit auch Sinn das auszulagern. Deswegen passt das schon so.
  • godoc ;)
  • Das build-script.. brr... ich glaube "distribute.sh" wäre da ein schönerer Name für, war zuerst verwirrt wegen dem Namen. Wenn man den "go-Weg" geht (go install ....) braucht man das ja nicht ;)
  • Diverse Hinweise aus Effective Go beachten, z.B. keinen Unterstrich in Funktionsnamen packen (Release_GetInfo -> ReleaseGetinfo, GetReleaseInfo o.ä. (xrel.GetRelease(Info) liest sich doch super? ;) Siehe Hinweis mit dem Package Namen)). Effective Go ist allgemein eine sehr sehr gute Quelle um den "go-typischen" Weg kennenzulernen und zu verstehen.


Ansonsten schöne Arbeit :) Go ist eine klasse Sprache, was man da in sehr kurzer Zeit imposantes auf die Beine stellen kann ist schon unglaublich (auch wenn ich meinen Code vor allem Anfangs mehrmals refactoren musste, meistens aus ähnlichen organisatorischen Gründen wie eben gelistet, bis man dann die für Go typischen Muster drauf hat).
7 mal bearbeitet, zuletzt 18. Jan. 2016, 00:15 Uhr

#


HashWorks
HashWorks Quoten-Ossi
18. Jan. 2016, 09:07 Uhr
DerGrinch schrieb:
[...]


Wunderbar, so hab ich mir das vorgestellt, dankeschön :) Werd die Tage mal bisschen umbauen.

DerGrinch schrieb:
Das build-script.. brr... ich glaube "distribute.sh" wäre da ein schönerer Name für, war zuerst verwirrt wegen dem Namen. Wenn man den "go-Weg" geht (go install ....) braucht man das ja nicht ;)


Habs umbenannt. Den go-Weg kann ich ja leider nicht gehen da ich nicht oAuth Key & Secret ins Github legen will ;)
1 mal bearbeitet, zuletzt 18. Jan. 2016, 09:32 Uhr

#


jm3
jm3 Ex-Blogger
18. Jan. 2016, 20:34 Uhr
HashWorks schrieb:

Habs umbenannt. Den go-Weg kann ich ja leider nicht gehen da ich nicht oAuth Key & Secret ins Github legen will ;)


Auch wenn ich jetzt nicht in Go schreibe, aber eigentlich solltest du ja auch Platzhalter machen können die dann entweder der User eingeben muss oder die man halt von Hand anpassen muss. Machen ja viele PHP Webapps auch so.

#


HashWorks
HashWorks Quoten-Ossi
18. Jan. 2016, 20:41 Uhr
jm3 schrieb:
Auch wenn ich jetzt nicht in Go schreibe, aber eigentlich solltest du ja auch Platzhalter machen können die dann entweder der User eingeben muss oder die man halt von Hand anpassen muss. Machen ja viele PHP Webapps auch so.


Naja, das kannst du ja machen wenn du von Source compiliert. Aber das ist ja nicht der Sinn von OAuth. Siehe die Android App, selbes Prinzip, muss man ja auch nichts eingeben.

#


HashWorks
HashWorks Quoten-Ossi
28. Apr. 2016, 18:30 Uhr
xREL API v2 implementiert, neue Funktionen hinzugefügt.

https://github.com/hashworks/xRELTerminalClient/releases/tag/v2.0.0

#


Chester
Chester 🌊
20. Jan. 2021, 12:30 Uhr 
{
    "error_type": "oauth2",
    "error": "invalid_client",
    "error_description": "Client authentication failed"
}

Bekomme diesen Fehler beim Authentifizieren.

❯ xrel -version
xREL Terminal Client
https://github.com/hashworks/xRELTerminalClient
Version: 2.1.2

Published under the GNU General Public License v3.0.


#


doc_gonzo
doc_gonzo User
12. März 2021, 11:45 Uhr
das funktioniert nimmer...

https://github.com/hashworks/xREL-Terminal-Client/issues/1

#



Thema
Thema abonniert:
Nein