|
|
|
|
|
|
|
| | Zitat von con_chulio
Wieso?
Es gilt ja X <= N
Wenn ich 5 murmeln in der Urne habe kann ich maximal 5 mal ziehen
| |
Meine Lesekompetenz ist nicht sehr gut  (ohne Zurücklegen)
|
|
|
|
|
|
|
|
|
|
|
|
// Habe nur was durcheinander gebracht.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von homer is alive am 30.07.2018 15:54]
|
|
|
|
|
|
|
|
M.Sc.++
|
|
|
|
|
|
|
|
|
|
|
Grats! 
Now that I feel better, I can't justify eating this entire bag of cookies.
|
|
|
|
|
|
|
|
|
|
|
|
Tippi Toppi
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Glückwunsch!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Glückwunsch. Vielleicht schaffe ich das mit 45 auch mal
|
|
|
|
|
|
|
|
|
|
|
Fields-Medaille an meine Alma Mater. Irgendwie freut einen sowas ja doch.
Reality is frequently inaccurate.
|
|
|
|
|
|
|
|
|
|
|
|
ETH auch dabei. Fühle nix
|
|
|
|
|
|
|
|
|
|
|
|
Die Rings- und die Groups-Medaille werden erst nächstes Jahr vergeben, oder?
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Fields-Medaille an meine Alma Mater. Irgendwie freut einen sowas ja doch.
Reality is frequently inaccurate.
| |
Beim ersten hinschauen dachte ich, du wärst es...
|
|
|
|
|
|
|
|
|
|
|
|
Geht dieses Jahr eigentlich irgendjemand auf Konferenzen zu Python, Statistik, Machine Learning, Optimierung oder Data Science im weiten Sinne? Und welche fandet ihr in der Vergangenheit empfehlenswert?
|
|
|
|
|
|
|
|
|
|
|
CSS Shice
Ich möchte bei diesen Verschachtelten Elementen das erste und letzte Element mit der class "range" ansprechen.
Problem ist, dass CSS bei Siblings mit gleichen Childs unter :first-child/:last-child nur aus den eigenen childs das first und last findet, aber nicht über siblings hinweg.
Gibt es eine CSS Möglichkeit, an die Elemente ranzukommen?
Da es ein Angular Modul ist, kann ich die Struktur nicht umschreiben.
Mit JS kann man afaik eher dran kommen, aber ich möchte wissen, ob CSS eine Möglichkeit anbietet.
Zwei Personen sagten mir bereits, dass CSS das wohl nicht kann.
|
|
|
|
|
|
|
|
|
|
|
|
Ich fürchte ich kann kein CSS, aber ich kann diesen Vortrag von Martin Odersky empfehlen, der über die programmatische Abstraktion von Kontext im allgemeinen spricht. Fand ich sehr spannend.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Lightspeed
CSS Shice
Ich möchte bei diesen Verschachtelten Elementen das erste und letzte Element mit der class "range" ansprechen.
Problem ist, dass CSS bei Siblings mit gleichen Childs unter :first-child/:last-child nur aus den eigenen childs das first und last findet, aber nicht über siblings hinweg.
Gibt es eine CSS Möglichkeit, an die Elemente ranzukommen?
Da es ein Angular Modul ist, kann ich die Struktur nicht umschreiben.
Mit JS kann man afaik eher dran kommen, aber ich möchte wissen, ob CSS eine Möglichkeit anbietet.
Zwei Personen sagten mir bereits, dass CSS das wohl nicht kann.
| |
Da hast du mehrere Probleme: Die first/last-child pseudoklassen gelten nur in Bezug zum direkten Parent im Tree, und auch wirklich nur für das erste und letzte Element. Also für child(0), child(n-1).
Auch die first/last-of-type selektoren beziehen sich auf einen direkten parent, und funktionieren eigentlich gleich: Beispiel
Auch selector list arguments werden so funktionieren, weil die first/last-child und verwandte Selektoren so definiert sind, dass nur effektiv erste und letzte, respektive n-te Kinder selektiert werden.
Sibblingselektoren funktionieren nur für Nodes unterhalb eines Parents, wobei aber keine Ancestor, sondern wirklich nur Parentnodes berücksichtigt werden. Ich vermute hier ist die Performance schuld, aber um es genau zu wissen, müsste man wahrscheinlich in der Implementation rumgurken.
Mit einem konstruierten Beispiel sieht man auch ganz schön, dass die first/last Selektoren sich auf den Parent, und nicht den Selektoren beziehen. Macht auch Sinn, weil HTML Singlepass gerendert wird, und die CSSOM representation preloaded ist. Du hast also zum Zeitpunkt des Renderns kein Bezug auf folgende / vorhergehende Elemente, womit es praktisch unmöglich ist, zu wissen wann du jetzt insgesammt das erste und letzte Klassenselektiere Element deiner subkinder erreicht hast.
Nimm JS, da ist es bedeutend weniger Aufwand
¤: Ach und mehr so für die Allgemeinheit, warum es mit JS geht: Mit Javascript greifst du in das fertige DOM-Model ein (nicht direkt, sondern über ein Pseudomodell, welches in der Regel erst einen repaint triggert wenn ein JS-pass durchgelaufen ist. So ähnlich wie der Tick einer Gameengine). Du hast also alle Informationen des fertigen Baums und nicht nur Nodeweise Information der descendants. Damit hat man also viel mehr Stateful Information, mit der man Manipulationen durchführen kann. CSS kann zwar immer mehr, und wird auch in Zukunft mehr können, aber CSS möglichst Stateless zu halten ist der einzige Weg, wie man vielleicht irgendwann echtes Async und partial rendering des Domtrees hinkriegen kann.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von SwissBushIndian am 03.08.2018 12:14]
|
|
|
|
|
|
|
|
|
SBIs Antworten sind wie immer schön ausführlich und Informationsreich.
Ja, dann werde ich über JS da ran gehen müssen.
Danke sehr.
|
|
|
|
|
|
|
|
|
|
|
Wieso nicht
| |
| Code: |
.cal > .month > .day:first-child {
background-color: cyan;
}
.cal > .month > .day:last-child {
background-color: purple;
} |
|
?
Scheiß auf die .range Klasse.
https://jsfiddle.net/dn841rb5/60/
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 03.08.2018 13:52]
|
|
|
|
|
|
|
|
|
|
Das ist nicht was er will. Er will quasi ein flatmap aller range klassen über cal. Also insgesammt die erste und letzte Rangenode, unabhängig von month und day.
|
|
|
|
|
|
|
|
|
|
|
Dann understande ich nicht :/ .
Was anderes:
In meiner Firma geht's größtenteils um Web-related Dinge, Daten hin-und-herschupfen, Interfaces, Verknüpfung mehrerer Systeme, Frontend und Backend (eher ich). Soweit eh alles interessant und abwechslungsreich.
Es geht allerdings aktuell die Frage um, was in Zukunft gemacht wird. Weiterhin die "klassische" Web-App/Website aus HTML5, JavaScript und Serversprache-X (mit anderen Technologien wie Solr, Node.js etc. je nach Anwendungsfall), oder zusätzlich Hybrid-Apps auf Basis von den in den letzten Jahren aufgekommenen JavaScript/Apache Cordova Frameworks wie Electron, Ionic oder React Native entwickeln?
Wenn es nach mir ginge, würde ich Mobile Apps nativ in Java und mühsamerweise auch in Objective C bauen. Allerdings wünscht sich die Firma mehr die hippen Framworks, wo man halt in JavaScript "hinpfuschen" kann. Naja.
Ein paar generelle Fragen:
- Was ist denn hier zu empfehlen von diesen Frameworks? Laut meiner Recherche sind eigentlich nur Electron (eher nur Desktop?), React Native (eher nur Mobile?) und Ionic ("alles"?) interessant. Oder halt direkt Apache Cordova.
- Macht es Sinn ein Framework zu wählen, dass wirklich jedes Device/OS abdeckt (wie z.B. Ionic), oder sollte man lieber klar trennen zwischen Mobile/Desktop? Nach meinen Tests mit Ionic habe ich das Gefühl, dass man sich da mehr Arbeit einhandelt, als man spart.
- Wie sieht's performancemäßig mit z.B. Electron aus? Das JavaScript dort wird ja zum Teil irgendwie in native Code übersetzt, aber so "schnell" wie z.B. C# kann das ja nicht sein. Liegt halt natürlich auch am Anwendungsfall.
Vielleicht kann mir ja jemand dazu ein paar Worte zur Entscheidungsunterstützung mitgeben.
|
|
|
|
|
|
|
|
|
|
|
Zumindest bei uns wird versucht, der nativen App langsam alles abzugraben an Features, damit sie dann weg kann. Zumindest gibt es die Annahme, dass die Kunden langsam die Schnauze voll von den ganzen App-Popups und den unnötigen Installationen haben. Dementsprechend wurde/wird die Webseite (u. a. mit React) so umgebaut, dass sie entsprechend gut auf mobilen Geräten funktioniert und schnell genug ist.
Hängt natürlich auch davon ab, was dein Entwicklungsteam überhaupt leisten kann. Wenn du sehr spezielle Anforderungen oder Kunden hast, die mit einer "normalen" Webseite auch nicht gut funktionieren, würde ich eher zur App tendieren. Wenn nicht, würde ich den Aufwand eher vermeiden, bei dem ganzen Hersteller/Browser/Spezialitäten-Chaos, und "nur" eine gute Webseite hinstellen.
Gefühlt gibt es bei Apps halt auch nur die Stufen
nutzlos -> nutzlos und groß -> nutzlos und groß und langsam -> nervtötend -> ................lange nichts............ -> lohnt sich, bietet Mehrwert,
aber die letzten Stufen erreichen nur wenige.
|
|
|
|
|
|
|
|
|
|
|
Ihr macht also gar keine builds für Android und Apple, sondern schickt die User einfach auf die Website? Das geht halt nur solange, bis man auf features des devices wie z. B. Gyrometer zurückgreifen muss.
Und so ne Website kann ich ja auch "klassisch" mit HTML5 und jQuery bauen. Angular und React sind bieten vermutlich einfach ein größeres Framework für App-Komponenten an.
Und brauche ich dann überhaupt sowas wie Electron? Eigentlich ja nicht, oder?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 06.08.2018 8:59]
|
|
|
|
|
|
|
|
|
| | Zitat von derSenner
Das geht halt nur solange, bis man auf features des devices wie z. B. Gyrometer zurückgreifen muss.
| |
Das stimmt nur bedingt. Für viele gerätespezifische Sachen gibt es BrowserAPIs. Orientation, GPS und sowas funktioniert in der Regel tadellos. Ich bin ja nicht so der Frontendmensch, aber ich habe vor 2 Monaten einen Prototyp für eine Art Educational-Pokemon Go zusammengezimmert mit 2 anderen. Alles nur React + Browser (mit Javabackend, aber das spielt hier ja keine Rolle), aber hat ziemlich gut funktioniert. Maps, Navigation, GPS, Kamerazugriff für QR-Code Scan etc.
Ich denke der Weg "So lange nicht nativ wie möglich -> Java/Swift" ist ziemlich gangbar inzwischen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.08.2018 9:02]
|
|
|
|
|
|
|
|
|
Interessant, wusste ich nicht, dass man das mittlerweile größtenteils auch über die BrowserAPIs abgreifen kann.
Wobei: Wie sieht's hier mit Kompatibilität mit IE11 aus? Edge arbeitet mittlerweile eh recht brav.
So vom Feeling her bedeutet das aber, dass z.B. React einfach die modernere Variante ist, um JavaScript ins Web zu bringen. Weil, wie gesagt, prinzipiell kann ich so Web-Apps auch mit jQuery machen.
Nun kann es aber dennoch vorkommen, dass man mal ne offline App bauen muss, die auch tatsächlich als App installierbar sein soll. Dann scheint mir die Kombination aus grundsätzlich React im Web + React Native sinnvoll. Oder?
Aber damit habe ich wiederum wirkliche Desktop Apps nicht abgedeckt.
Von den eierlegenden Wollmilchsäuen wie Ionic ist Abstand zu halten?
Wichtige Frage: Wo muss man Grenzen in der Entwicklung ziehen, wo kann man Technologien vereinen. Es gibt grundsätzlich drei Thematiken: Web, Mobile, Desktop.
// Ich bin gerade etwas kurz angebunden, aber würde folgende Aufteilung Sinn machen?
Desktop: Electron (oder React Native mit gewissen Plugins)
Mobile: React Native
Web: React
Für mich scheint es, dass man sowieso zwei- oder dreigleisig fahren muss.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von derSenner am 06.08.2018 13:15]
|
|
|
|
|
|
|
|
|
Die Frage ist halt, wie viele Libraries und Komponenten man untereinander wiederverwenden kann. Und ich denke da ist die Überschneidung grösser, wenn man sein Frontend überall mit JS macht, als wenn man jeweils eine native Lösung sucht. Aber einheitliche UIs über mehrere Plattformen ist ja nicht nur Mobile ein Problem, sondern auch auf dem Desktop. Eine wirkliche Lösung gibt es nicht, sondern ein "passt zu diesem Projekt". Ich habe zum Beispiel auch schon Projekte gesehen, die Unity verwendet haben für eine Businessapplikation, weil es sinnvoll war und auf allen Mobilsystemen lief.
¤: Und React ist halt einfach ein Beispiel für ein Framework mit angenehmer Abstraktion. Angular und Vue sind vergleichbar. Mit react und redux lassen sich halt viele funktionale Patterns schön anwenden, mit dem Bonus vielleicht einige Komponenten in React Native wiederzuverwenden. React auf Electron oder im Browser macht praktisch keinen Unterschied.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.08.2018 15:38]
|
|
|
|
|
|
|
|
|
|
Ich danke. Dann versuch ich mein Glück mal vorrangig mit React Native, und versuche zu das auch soweit es geht auf Web umzumünzen.
|
|
|
|
|
|
|
|
|
|
|
Nur noch als Ergänzung: Bei uns ist es auch eine rein geschäftliche Entscheidung, weil wir uns die ganzen Besonderheiten bei der App-Entwicklung nicht leisten können und wollen. Eine gute und schnelle Webseite beschäftigt uns halt gut genug.
Dafür haben wir z. B. einen entsprechenden Anbieter, der unsere Webseite automatisch auf x Geräten in y Versionen der Betriebssysteme mit z Browsern end-to-end-testet. Wie gesagt, das reicht für uns und am Ende (auch) eine Geldfrage. Und eine gute App ist halt nicht mal eben hingezaubert.
Ich bin auch kein Frontend-Profi, bei uns ist React der heiße Scheiß und Angular + jQuery sind lange tot. Electron und Ionic wird nicht benutzt... gefühlt ist meine Erfahrung, dass die so ähnlich wie der Pizzadienst um die Ecke: entweder können sie nur eine Sachen richtig gut, oder sehr viele Sachen eher schlecht.
Die Unterscheidung Web/Mobile/Desktop finde ich ohne spezielle Anforderungen heute nicht mehr sinnvoll, solange man eben alles in einen Browser pressen kann. Ich meine drei verschiedene Projekte will doch auch keiner pflegen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [smith]
Ich meine drei verschiedene Projekte will doch auch keiner pflegen.
| |
Das ist es halt vor allem. Ausser natürlich, man kann einfach beliebig Geld drauf werfen.
|
|
|
|
|
|
|
|
|
|
|
Leider gibt es aber Kunden, die eine App nicht über eine Website öffnen wollen. Die wollen ein Icon am Smartphone oder Tablet, und das Ding muss offline funktionieren. Sowas kann man dann auch ganz anders bzw. zusätzlich zum Hauptgeschäft der großen Website/Intranet/whatever verkaufen.
Deshalb suche ich halt schon auch eine Strategie, um eine App auch als apk oder ähnliches ausrollen zu können.
Aber dafür scheint eh React Native geeignet zu sein. Zusätzlich kann man auch noch über den Browser "Apps" anbieten, aber das ist vom Verkauf her eine ganz andere Sache, finde ich.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 06.08.2018 19:03]
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXII ( Jetzt nehmen uns Computer schon die Memes weg! ) |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)