Sprichwörter tragen eine Bedeutung in sich, aber immer mehr Leute interpretieren sie nur noch wortwörtlich.
Wenn sich solche Behauptungen wieder als Trend durchsetzen, verwandelt sich der Besprechungsraum ganz selbstverständlich erneut ins Chaos.
Die Paperwork-Leute drehen dann völlig auf und dieselben Fehlversuche werden jedes Jahr aufs Neue wiederholt.
Das hängt stark mit dem Arbeitsrecht des jeweiligen Landes zusammen … In vielen US-Unternehmen wird einfach reihum Bereitschaft übernommen, und wenn es in einem bestimmten Zeitraum nicht geht, tauscht man die Reihenfolge. Weil es eben belastend ist … Manche Unternehmen haben auch ein eigenes On-Call-Team.
In Europa gibt es fast immer eine gesonderte Vergütung, sei es, weil sich die Tätigkeit geändert hat, oder weil es sich um Überstunden handelt.
Bei uns wird das wegen des pauschalen Überstundengehalts eher irgendwie nebenbei geregelt. On-Call ist eindeutig Arbeit, wird aber so verpackt, als wäre die Vergütung für diese Zeit eine Art Zusatzleistung.
Tatsächlich dürfte es schon schwer sein, all diese Dienste überhaupt zu nutzen, daher ist die Unterstützung für MCP ein großer Vorteil.
Wenn die API in Zukunft nur gut gepflegt wird, dürfte das sehr nützlich sein.
Apples Hardware ist zwar hervorragend, aber die Software ist voller Absichten, die Nutzer an die Leine zu legen.
Selbst wenn man eine selbst erstellte und gebaute App nur auf dem eigenen Gerät ausführen will, braucht man ein 100-Dollar-Abo.
Wenn man als Entwickler kleinere bis mittelgroße Open-Source-Apps nutzt, sie selbst baut und verwendet,
ist es bequemer, einfach Android zu nutzen, als auf Apple-Geräten Schwachstellen auszunutzen, sie zu jailbreaken und per Sideloading Apps zu installieren.
Bei uns gab es für Bereitschaft die Hälfte des Stundenlohns, einen Zuschuss zu den Kommunikationskosten, und die Einsatzzeit wurde als Überstunden mit dem 1,5-fachen Satz vergütet.
[Link entfernt] Den Screenshot der Android-Version habe ich hier eingefügt. Je länger man es benutzt, desto mehr wirkt es wie ein eigenartiges Werkzeug. Auch die Community ist skurril und hat viele überraschende Seiten.
Mit Emacs allein kann man dies und das alles erledigen. In letzter Zeit lässt es sich sogar auf Android installieren, sodass ich dieselben Funktionen wie auf dem Desktop nutzen kann, was großartig ist. Ich beschäftige mich gerade intensiv mit dem Thema Emacs als Wissensmanagement-Tool. Wenn mein Kind, das jetzt in den Kindergarten geht, in die Grundschule kommt, wird es bis dahin wohl schon Life-Logging mit Emacs machen, haha. Wenn man nur ein einziges Werkzeug beherrschen muss, verringert das langfristig die Zahl der Dinge, über die man sich Gedanken machen muss.
Aber wenn man den Nutzern einfach das Prinzip der Obfuskation offengelegt und sich per Haftungsausschluss bestätigen lassen hätte, dass es von bestimmten Modellen geknackt werden kann, hätte man den Dienst wohl auch ohne Rückerstattung weiter anbieten können — da sind Sie den Nutzern gegenüber wirklich sehr rücksichtsvoll, haha
Das war ein Text, der mir eine Antwort auf die Gedanken gegeben hat, die mich in letzter Zeit beschäftigen. Vielen Dank, dass Sie diesen großartigen Text geteilt haben.
In letzter Zeit habe ich manchmal den Eindruck, dass Personal abgebaut wird und die schwieriger gewordene Wartung als Open Source ausgelagert und der Community aufgebürdet wird.
Beim Refactoring kam es ziemlich oft vor, dass das Parsing des Codes auf tsserver-Seite so langsam wurde, dass der Editor komplett eingefroren ist. Hoffentlich erscheint das schnell, damit wir von diesem Leid befreit werden.
Ich hatte den Eindruck, dass alle structural typing in den Raum werfen, ohne groß darüber nachzudenken.
Wenn man es in eine Sprache mit nominal typing wie C# oder Rust neu schreiben wollte, müsste man die grundlegende Struktur des Projekts viel zu stark verändern, also wäre das wohl nicht leicht gewesen.
Unter den Sprachen mit structural typing, die gegenüber der bestehenden JS-Basis eine höhere Performance liefern könnten, kämen wohl nur C++ oder Golang infrage, und wenn man auch die Produktivität berücksichtigt, gibt es keine echte Alternative.
Das liegt wohl daran, dass man noch kein wirklich gutes Electron-Haus erlebt hat ~
... so klingt es jedenfalls, hahaha
Sprichwörter tragen eine Bedeutung in sich, aber immer mehr Leute interpretieren sie nur noch wortwörtlich.
Wenn sich solche Behauptungen wieder als Trend durchsetzen, verwandelt sich der Besprechungsraum ganz selbstverständlich erneut ins Chaos.
Die Paperwork-Leute drehen dann völlig auf und dieselben Fehlversuche werden jedes Jahr aufs Neue wiederholt.
Das hängt stark mit dem Arbeitsrecht des jeweiligen Landes zusammen … In vielen US-Unternehmen wird einfach reihum Bereitschaft übernommen, und wenn es in einem bestimmten Zeitraum nicht geht, tauscht man die Reihenfolge. Weil es eben belastend ist … Manche Unternehmen haben auch ein eigenes On-Call-Team.
In Europa gibt es fast immer eine gesonderte Vergütung, sei es, weil sich die Tätigkeit geändert hat, oder weil es sich um Überstunden handelt.
Bei uns wird das wegen des pauschalen Überstundengehalts eher irgendwie nebenbei geregelt. On-Call ist eindeutig Arbeit, wird aber so verpackt, als wäre die Vergütung für diese Zeit eine Art Zusatzleistung.
Tatsächlich dürfte es schon schwer sein, all diese Dienste überhaupt zu nutzen, daher ist die Unterstützung für MCP ein großer Vorteil.
Wenn die API in Zukunft nur gut gepflegt wird, dürfte das sehr nützlich sein.
Apples Hardware ist zwar hervorragend, aber die Software ist voller Absichten, die Nutzer an die Leine zu legen.
Selbst wenn man eine selbst erstellte und gebaute App nur auf dem eigenen Gerät ausführen will, braucht man ein 100-Dollar-Abo.
Wenn man als Entwickler kleinere bis mittelgroße Open-Source-Apps nutzt, sie selbst baut und verwendet,
ist es bequemer, einfach Android zu nutzen, als auf Apple-Geräten Schwachstellen auszunutzen, sie zu jailbreaken und per Sideloading Apps zu installieren.
Bei uns gab es für Bereitschaft die Hälfte des Stundenlohns, einen Zuschuss zu den Kommunikationskosten, und die Einsatzzeit wurde als Überstunden mit dem 1,5-fachen Satz vergütet.
Da versteckt sich zwischendurch wohl die C#-Fraktion.
> Mal ehrlich, auch wenn man heute Java entwickelt, muss man nicht unbedingt Produkte von JetBrains verwenden.
Diesem Punkt kann ich ... nur schwer zustimmen, seufz ...
[Link entfernt] Den Screenshot der Android-Version habe ich hier eingefügt. Je länger man es benutzt, desto mehr wirkt es wie ein eigenartiges Werkzeug. Auch die Community ist skurril und hat viele überraschende Seiten.
Mit Emacs allein kann man dies und das alles erledigen. In letzter Zeit lässt es sich sogar auf Android installieren, sodass ich dieselben Funktionen wie auf dem Desktop nutzen kann, was großartig ist. Ich beschäftige mich gerade intensiv mit dem Thema Emacs als Wissensmanagement-Tool. Wenn mein Kind, das jetzt in den Kindergarten geht, in die Grundschule kommt, wird es bis dahin wohl schon Life-Logging mit Emacs machen, haha. Wenn man nur ein einziges Werkzeug beherrschen muss, verringert das langfristig die Zahl der Dinge, über die man sich Gedanken machen muss.
[Link entfernt]
Aber wenn man den Nutzern einfach das Prinzip der Obfuskation offengelegt und sich per Haftungsausschluss bestätigen lassen hätte, dass es von bestimmten Modellen geknackt werden kann, hätte man den Dienst wohl auch ohne Rückerstattung weiter anbieten können — da sind Sie den Nutzern gegenüber wirklich sehr rücksichtsvoll, haha
Das war ein Text, der mir eine Antwort auf die Gedanken gegeben hat, die mich in letzter Zeit beschäftigen. Vielen Dank, dass Sie diesen großartigen Text geteilt haben.
Ich nutze die LSP, die ich direkt selbst gebaut habe. Nach dem Wechsel zu Go merkt man sofort deutlich, dass der Ressourcenverbrauch gesunken ist.
In letzter Zeit habe ich manchmal den Eindruck, dass Personal abgebaut wird und die schwieriger gewordene Wartung als Open Source ausgelagert und der Community aufgebürdet wird.
Oh, großartig, endlich ...!!!
MS ist wirklich großartig.
Heutzutage ist es in Mode, JavaScript einfach nach Rust / Go zu verlagern, nur um die Performance zu verbessern.
Oh, der Hammer
Beim Refactoring kam es ziemlich oft vor, dass das Parsing des Codes auf tsserver-Seite so langsam wurde, dass der Editor komplett eingefroren ist. Hoffentlich erscheint das schnell, damit wir von diesem Leid befreit werden.
Ich hatte den Eindruck, dass alle structural typing in den Raum werfen, ohne groß darüber nachzudenken.
Wenn man es in eine Sprache mit nominal typing wie C# oder Rust neu schreiben wollte, müsste man die grundlegende Struktur des Projekts viel zu stark verändern, also wäre das wohl nicht leicht gewesen.
Unter den Sprachen mit structural typing, die gegenüber der bestehenden JS-Basis eine höhere Performance liefern könnten, kämen wohl nur C++ oder Golang infrage, und wenn man auch die Produktivität berücksichtigt, gibt es keine echte Alternative.