Programmierwettbewerb: Ampelschaltung

[0xFADED]

Solange jetzt nicht jemand mit Brainf*ck um die Ecke kommt hast du den Preis für die ungewöhnlichste Programmiersprache


--- [2015-06-30 21:56 CEST] Automatisch zusammengeführter Beitrag ---


Ich hab meinen Code mal auf GitHub gestellt

BEWARE!!!
UGLY CODE AHEAD!!!
https://github.com/greensn0w/Traffic-Lights.js

LG

 

[0xFADED]

Tja da ist er, der 4. Juli
Nach 7 Commits und einer Statistik von 515 ++ / 97 -- geht mein wohl kürzestes Projekt zu Ende.

Hier mal eine kleine Anleitung, falls sich das irgendjemand antun will:
[src=bash]
#NodeJS und NPM besorgen
sudo apt-get update
sudo apt-get install nodejs
sudo apt-get install npm

#Mein Repo klonen
cd ~/ngb
git clone https://github.com/greensn0w/Traffic-Lights.js.git
cd Traffic-Lights.js

#Abhängigkeiten installieren
npm install

#Und los
node main.js
[/src]

LG

PS: Ich weiß das ist noch was früh, aber gibt es schon einen Termin für den nächsten Wettbewerb ?

 

[Larius]

Ich schätze mal so ca n Monat wird es dauern. Is ja doch einiges zum ausarbeiten und das RL schläft nie

 

[Larius]

Danke euch allen für die zahlreiche Teilnahme - sind ja doch einige recht nette Lösungen dabei herausgekommen. Gehen wir sie mal kurz durch:

-) Dank an Epi für seine Geister-Autos, die an der Kreuzung auftauchen und wieder verschwinden
-) Dank an TheSplit für die deutsche Fahrkunst - wer fährt nicht bei Rot/Gelb schon in die Kreuzung ein, noch bevor es grün ist?
-) Dank an KaPiTN, auch wenn ich nicht ganz durchblicke wg. den Unterstrichen bei den Variablen... Aber ansonsten sehr schön gegliedert!
-) Dank an Flawless für die außergewöhnlichste Lösung
-) Und ein Dank an greensn0w für die wohl beste Commit Message: "Some bugs will be fixed later (TM)" (und tss, nur n Master Branch - Develop ftw!)

Habt ihr Feedback zur Aufgabe, zur Dauer bzw. zur generellen Durchführung?

 

[KaPiTN]

@Larius:

Lediglich eine Konvention für instance fields (private)

 

[theSplit]

Zur generellen Durchführung, wir sollten uns verpflichten Github zu nutzen finde ich.
So sieht man gut wie geplant und ausgeführt wurde und zum anderen macht es das herunterladen und kompilieren mit Makefile oder ähnlichem leichter, gerade bei einer Lösung wie von KaPiTN mit vielen Dateien.

Dazu bietet Github ein schönes Code Highlighting an und man kann Source Code besser organisieren und eine Readme mit Anleitung dazu mit anfertigen. Plus ich und greensnow haben dort schon einen Account

Ich habe gerade mal geschaut, man könnte Github auch ein wenig für die Wettbewerbe "missbrauchen" wenn man eine Organisation gründet und jeder Teilnehmer für eine Aufgabe eine Repository erstellt bzw. freigegeben bekommt (wie genau das funktioniert weiß ich (noch) nicht) - aber das hätte schon etwas.

Auch gibt es GUI Clients für Windows und Linux so das niemand benachteiligt wird wenn es darum geht etwas hochzuladen. Wer fragen hat könnte ja dann auch im Thread posten.

Lohnt sich natürlich nur wenn das niemanden zur Teilnahme abschrecken würde, aber als Fallback könnte man ja auch wieder im Wettbewerbs-Thread posten.

Ansonsten hab ich eigentlich nicht viel mehr zu bemängeln, ich fänd es nur eleganter könnte man den Fortschritt auch beobachten und Veränderungen, daher auch die Idee mit Github, mitverfolgen könnte. Das ist etwas hier im Thread untergegangen finde ich.

Ich bin natürlich gespannt was es für ein weiteres Thema gibt
Mir würde spontan auch Code Golfing einfallen falls man keine Idee für ein Thema hätte.

 

[Timon3]

@theSplit: Ich würde dir zustimmen mit Github. Denjenigen, die sich nicht gut mit Git auskennen, kann man ja ohne Frage helfen, es soll ja definitiv niemand ausgeschlossen werden.

 

[Asseon]

Es ist imho unsinnig, das ganze auf eine Plattform zu beschränken, nicht jeder hat einen github Account und der ein oder andere will vlt auch gar keinen.

 

[theSplit]

@Asseon

Tach, da magst du ja auch recht haben, aber es würde imho vieles vereinfachen. So ein Account ist doch schnell angelegt. Und wer überhaupt nicht mag, der könnte ja hier im Forum auch seine Source posten wie das eben bisher auch gehandhabt wurde.

 

[accC]

Statt eines Github-Accounts könnte Kugelfisch vielleicht ein gitlab aufsetzen.
Im Wesentlichen hätte das den Vorteil, dass man sicher die Datenbanken verknüpfen könnte, so dass jeder NGB-Account auch im gitlab verfügbar ist. Einen zusätzlichen Account braucht sich daher niemand anzulegen. Zusätzlich hätte es den Vorteil der Anonymität, die einem hier bei NGB geboten wird, aber nicht bei github.
Außerdem hätte man mehr Kontrolle über die Projekte. Bei github lassen sich private Projekte nur gegen Bezahlung hosten, wenn ich das richtig in Erinnerung habe.

 

[Asseon]

Warum versucht ihr alle ne Ameise mit nem Orbitallaser zu tätowieren? o.O

 

[theSplit]

Außerdem hätte man mehr Kontrolle über die Projekte. Bei github lassen sich private Projekte nur gegen Bezahlung hosten, wenn ich das richtig in Erinnerung habe.

Private Projekte schon, aber man könnte ja einen OpenSource Organization daraus gründen

Einziger Nachteil wäre, jeder könnte alles einsehen, auch externe.

Mit Gitlab kenne ich mich wiederum nicht aus, klingt aber nach einem riesen Eingriff wenn du mich fragst.

 

[0xFADED]

> Gitlab
> Im Wesentlichen hätte das den Vorteil, dass man sicher die Datenbanken verknüpfen könnte

Das geht leider nicht, es sei denn das NGB verwaltet seine nutzer über LDAP.
Desweiteren bräuchte man dafür die Enterprise Version, die mindestens $408 pro Monat kostet

Zur generellen Durchführung, wir sollten uns verpflichten Github zu nutzen finde ich.

Auf jeden Fall!
Github erleichtert so einiges und ein NGB Team währe schon ne coole Sache

nicht jeder hat einen github Account und der ein oder andere will vlt auch gar keinen.

(abgewandelt)
GitLab hätte den Vorteil der Anonymität, die einem hier bei NGB geboten wird, aber nicht bei github.

Die beiden Argumente sind (meiner Meinung nach) realtiv Sinnfrei.

Zum nicht vorhandenen Account:
Jeder kann sich in 5 Minuten nen Account mit einer Fake-Email-Adresse machen.

Zur Anonymität:
Es muss ja keine offensichtliche Verbindung zwischen GitHub und NGB geben, für diejenigen die "anonym" bleiben wollen.
Wer anonym sein will fragt sich per PN ne Einladung ins Team und schreibt bei der Bewertung nochmal ne PN:

Hallo {{Name}},
Ich bin auf GitHub der {{Benutzername}}

Gruß {{DU}}

EDIT:

[...] man könnte ja eine OpenSource Organization daraus gründen
Einziger Nachteil wäre, jeder könnte alles einsehen, auch externe.

Wer geht denn auf GitHub um uns die Ampelschaltungen zu klauen
Solange wir keine 0-day Hacks schreiben ist das wohl eher unkritisch

LG

 

[drfuture]

Also ansich wäre ein gemeinsames Repository sicher eine nette Sache...
Ich hätte es noch gut gefunden von jedem eine lauffähige Exe zu haben - kann man compilierte Anwendungen auch auf Git hochladen?
Leider hatte hier jetzt auch nicht jeder was fertig lauffähiges zum download angeboten (glaube ich).

zur SPS-Lösung würde mich noch interessieren was das ding denn so macht? ^^ - da fehlen mir jede Menge Kommentare ...

Sonst hat mir das ganze gut gefallen - außer das ich nicht dazu gekommen bin bei "meinem" Wettbewerb meine eigene Lösung abzugeben.
Die alte in vb6 habe ich rausgesucht - aber dann festgestellt das die die ich noch habe komplett unfertig ist und nur sowas kompliziertes macht wie alle Ampeln auf rot blinkend zu schalten

..... findet sich jemand der sich was ausdenken möchte oder soll ich noch mal?

 

[0xFADED]

Also ansich wäre ein gemeinsames Repository sicher eine nette Sache...

Besser währe hier wohl ein Team/ eine Organisation auf GitHub und jeder bekommt sein eigenes Repo.
In einem Repo müsste sonst jeder seine eigene Branch bekommen und das währe einfach nur ein riesen Murks mit haufenweise Merge Konflikten im späteren Verlauf und vieeel Arbeit.

Ich hätte es noch gut gefunden von jedem eine lauffähige Exe zu haben - kann man compilierte Anwendungen auch auf Git hochladen?

Ja, man kann an jedes Release/Tag Anhänge anfügen


EDIT:
Ich würde mich dann übrigens auch als Hilfestellung für die, die GIT/GitHub noch nicht (so gut) können zur Verfügung stellen
Benutze beides schon sehr lange privat und konnte jetzt auch meine Firma dazu überzeugen auf GIT umzusteigen...

 

[theSplit]

Ja, man kann an jedes Release/Tag Anhänge anfügen

Ich glaube das wäre schon die erste Frage die ich hätte, weil ich unter Windows nur den offizellen Githut-Client nutze bzw. unter Linux SmartGit, gibt es aber, sehe ich gerade auch, für Windows, mit Open Source Lizenz und dort noch keine Option verwendet habe mit Releases oder Tags zu arbeiten.

Ich würde mich dann übrigens auch als Hilfestellung für die, die GIT/GitHub noch nicht (so gut) können zur Verfügung stellen
Benutze beides schon sehr lange privat und konnte jetzt auch meine Firma dazu überzeugen auf GIT umzusteigen...

Das wäre super, ich bin schon der erste Kandidat der dich dann mit Fragen löchern würde, ich hoffe du hast harte Nerven wenn es angehen sollte.

..... findet sich jemand der sich was ausdenken möchte oder soll ich noch mal?

Meiner Meinung nach nur zu. Wobei wir aber auch auf Larius warten sollten das er sich äußert

 

[0xFADED]

ich bin schon der erste Kandidat der dich dann mit Fragen löchern würde, ich hoffe du hast harte Nerven wenn es angehen sollte.

Sicher doch

Ich glaube das wäre schon die erste Frage die ich hätte, weil ich unter Windows nur den offizellen Githut-Client nutze bzw. unter Linux SmartGit, gibt es aber, sehe ich gerade auch, für Windows, mit Open Source Lizenz und dort noch keine Option verwendet habe mit Releases oder Tags zu arbeiten.

Spoiler

GUI unter Linux? Schäm dich, mimimi

Kurze Anleitung zu taggen mit Anhang

Du gehst auf dein Repo und klickst auf "releases":

---

Dann legst du einen neuen Release an und lädst die EXE als Anhang hoch:

---

---

---

Tja und das wars schon
Jetzt siehts so aus wenn man auf "releases" klickt:

Den Sourcecode als .ZIP und .TAR.GZ. generiert GitHub übrigens automatisch.
Das ist dann auch der Stand des Sourcecodes der zum Zeitpunkt des Releases der aktuelle war.

Das schöne ist, dass man diesen Tag jetzt in GIT auschecken könnte:
[src=bash]
#Erstmal das Repo klonen
git clone git@github.com:greensn0w/NGB_TEST.git

#> Cloning into 'NGB_TEST'...
#> remote: Counting objects: 6, done.
#> remote: Compressing objects: 100% (3/3), done.
#> remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
#> Receiving objects: 100% (6/6), done.
#> Checking connectivity... done.

#In den Ordner
cd NGB_TEST

#Alle Tags auflisten
git tag -l

#> 1.0-final

#Tag auschecken
git checkout tags/1.0-final

#> Note: checking out 'tags/1.0-final'.
#> HEAD is now at 28b6cef... Create script.sh

#Ab hier kannst du dann aus dem "detached HEAD" eine Branch machen
git checkout -b backport

#> Switched to a new branch 'backport'

#Die neue branch kannst du jetzt beliebig bearbeiten und dann zu GitHub pushen
git push -u origin backport

#> Total 0 (delta 0), reused 0 (delta 0)
#> To git@github.com:greensn0w/NGB_TEST.git
#> * [new branch] backport -> backport
#> Branch backport set up to track remote branch backport from origin.
[/src]

 

[theSplit]

Cool, jetzt muß ich mir das nur noch ausdrucken und an die Wand hängen.

Die Frage kommt bestimmt nochmal ; spätenstens wenn es dann soweit ist ein Release hoch zu laden, bis dahin weiß ich ja bescheid

Ach so, ist der Release ein neuer Commit? Oder sind Releases separate "Commits", also unabhängige Steps von den Commits? Die lediglich eine kompilierte Version auf den Haufen oben drauf legen bzw. Dateien in einer Version eines Programms?

Fragen über Fragen

 

[0xFADED]

@theSplit:
Ein Tag ist (ums in C zu sagen ) ein Pointer auf einen Commit.
Du kannst git dann sagen den Commit auf den der Tag zeigt auszuchecken und daraus auf Wunsch eine Branch machen

(EDIT) Oder besser gesagt:
Ein Tag ist als würdest du ein Namensschild auf dem "stable" steht, an einen Commit hängen

---

Wenn sonst noch Fragen sind kannst du mich auch gerne
per Jabber/XMPP unter greensn0w@jabber.ccc.de anschreiben

 

[theSplit]

@greensn0w:

Danke für das Angebot!

Aber es ging ja nicht eben um die Tags, es ging um die Releases.

Und ich hab gedacht, ein Release gehört indirekt zu einem Stand von Commits, also Punkt X, Y - in der Zeitachse beinhaltet einen "Meilenstein" / Release.
Wenn Git die Sachen noch trennt ist die Feststellung natürlich obsolet aber so würde ich es auffassen

Heute richte ich mir aber aus Selbstschutz kein Jabber ein, muß dazu auch erstmal austesten wie das geht