Homepage von Basti1012 = ,Hauptmenü
Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung

GitHub Mobile ist nicht mehr in der Beta. (Screenshot: t3n)

GitHubs Smartphone-App verlässt den Beta-Status und ist ab sofort für alle Nutzer unter iOS, iPadOS und Android verfügbar. So soll Entwicklern das Arbeiten mit ihren Repositories unterwegs leichter fallen.

GitHub Mobile steht ab sofort für alle Nutzerinnen und Nutzer unter den großen Mobil-Betriebssystemen zur Verfügung. Entwickler können damit auf ihren mobilen Geräten ? egal, ob Smartphone oder Tablet ? Code kommentieren, prüfen und einpflegen sowie auf Feedback und Problemmeldungen reagieren. Dabei synchronisiert sich die App mit der Website, sodass Entwickler ihre auf dem Mobilgerät begonnene Arbeit auf der Website nahtlos fortsetzen können. GitHub will sie als Verlängerung der Website verstanden wissen.

So sieht GitHub Mobile im Einsatz aus. (Screenshot: GitHub)

Neues Notifications-System bereits integriert

Um Entwickler unterwegs in alle Kommunikationsprozesse einzubinden, arbeitet GitHub Mobile bereits mit dem vollständig neuen Notifications-System, das ab April 2020 auch in der Web-Oberfläche verfügbar sein soll.

In der nun aktuellen Version 1.0 unterstützt GitHub Mobile die selbstgehostete Version von GitHub, den Enterprise Server, noch nicht. Die erforderlichen API sollen im Laufe des Jahres hinzukommen.

GitHub Mobile basiert auf gemeinsamer Codebasis

Schon bislang war die Smartphone-App im Rahmen eines Betaprogramms für iOS und Android erhältlich. Zur Entwicklerkonferenz GitHub-Universe 2019 hatte der Hersteller die Betaversion der App für iOS vorgestellt. Android-Nutzer mussten einen langen Atem beweisen und konnten sich erst Anfang 2020 über eine Betaversion der App freuen.

Am Betaprogramm haben nach Aussage GitHubs rund 10.000 iOS-Nutzer und 50.000 Android-Nutzer teilgenommen. Letztlich sollen beide Apps auf der gleichen Codebasis aufsetzen, dabei aber native Anwendungen auf ihren jeweiligen Plattformen sein.

Die ersten Kommentare in den App-Stores lassen auf kleinere Startschwierigkeiten schließen. Dabei scheint die App vor allem sowohl unter iOS wie auch unter Android das Einloggen in den eigenen GitHub-Account zu verweigern.

Passend dazu: Github kauft ein: Node.js-Paketmanager NPM wechselt ins Microsoft-Lager



MySQL Storage Engine Vergleich – Warum MyISAM?

Neuerdings ist InnoDB die Standard-Engine von MySQL, was ich echt vernünftig finde. Ich finde es erstaunlich, wie sich MyISAM so lange halten konnte und würde gern verstehen, warum. Meiner Meinung nach zeichnet die Verbreitung von MyISAM ein trauriges Bild für Webanwendungen im Allgemeinen. Foreign Keys sind ein Segen! Deshalb die gewagte Aussage: Webanwendungen werden oft als wilder Hack hingeschustert, weswegen auch auf Datenbankseite keine vernünftige Integrität gebraucht wird.

Anders kann ich mir jedenfalls nicht erklären, wie es MyISAM zu solch einer hohen Verbreitung geschafft hat. Nachfolgend führe ich nochmal eine kleine (von mir kommentierte) Gegenüberstellung auf, die die wichtigsten Unterscheidungsmerkmale umfasst:

MyISAM

  • Die Daten-Speicherung in little endian soll für eine Maschinenunabhängigkeit / Betriebssystemunabhängigkeit sorgen – Ich weiß nicht, in wiefern das im Webumfeld praxisrelevant ist (LAMP als Standard-Stack). Kommentare hierzu erwünscht!
  • NULL-Werte sind in indizierten Spalten zulässig
  • MyISAM unterstützt FULLTEXT-Indizes, Blobs und Text-Columns sind indizierbar – Praktisch!
  • Die Höchstlänge für Schlüssel beträgt 1000 Bytes (kann aber durch ein rekompilieren beliebig angepasst werden)
  • eine MyISAM-Tabelle kann maximal 64 Indizes haben – sollte reichen, wer mehr braucht hat oft beim Design was falsch gemacht.
  • Pro Index dürfen es bis zu 16 Spalten sein
  • Jede Tabelle wird getrennt gespeichert: Das Manual sagt dazu:

    Jede MyISAM-Tabelle wird in drei Dateien auf der Festplatte gespeichert. Die Namen der Dateien beginnen mit dem Tabellennamen und haben eine Erweiterung, die den Dateityp angibt. Eine .frm-Datei speichert das Tabellenformat. Die Datendatei besitzt die Erweiterung .MYD (MYData). Die Indexdatei hat die Erweiterung .MYI (MYIndex).

  • Wohl das wichtigste Unterscheidungsmerkmal: MyISAM arbeitet mit Table-Locking. Das ist beim Lesen schneller als das Row-Locking von InnoDB, wird aber bei parallelen Reads/Writes die Schreibvorgänge verzögern. Siehe dazu: Erzeuger-Verbraucher-Problem.

InnoDB

  • Man liest – verglichen mit MyISAM – oft von einer sichereren Recovery im Fall eines Crashes
  • Referentielle Integrität durch Foreign-Key-Unterstützung. Für mich DAS Feature.
  • Transaktionen. In ernstgemeinten, kritischen Anwendungen geht es nicht ohne.
  • Das Manual sagt zur Serverauslastung:

    InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine.

Vielleicht habe ich ein Killer-Argument für MyISAM übersehen? Und was spricht eigentlich gegen eine gemischte Verwendung von MyISAM / InnoDB in der selben Datenbank je nach jeweiliger Anforderung an eine Tabelle?

Umwetter Warnumgen und Wetter vorschau