Ich glaube, es wäre dieselbe Situation, wenn der Eigentümer es nicht selbst baut, sondern jemand anderen damit beauftragt.
Egal, wie gut man es erklärt, es kommt zu Missverständnissen, und egal, wie sorgfältig man alles begleitet, es gibt immer Bereiche, an die vorher niemand gedacht hat.
Wenn man beim Bauen jeden einzelnen Punkt nachfragen muss, den der Eigentümer nicht erwähnt hat, kostet das viel Zeit und ist frustrierend. Deshalb gibt es ziemlich viele Dinge, die Fachleute eigenständig erledigen, und genau diese Punkte scheinen alle zum Streitfall zu werden.
Übrigens beneide ich Sie darum, dass Sie offenbar noch nicht so oft von SI-Dienstleistern über den Tisch gezogen wurden.

Sieht gut aus.

Mein Gott!

Haha, meine Güte
Ich habe das über Slack gesehen und bin hergekommen, weil ich dachte, es sei vielleicht ein Tippfehler, aber tatsächlich war es keiner, haha. Ich habe den Beitrag mit viel Spaß gelesen. Danke für die detaillierte Erklärung.
Nur nebenbei, aber in der UI der Tesla-, X- und Starlink-Apps scheint sich irgendwie ein ziemlich konsistenter Geschmack zu zeigen…

Ich würde Cline auch gern einmal ausprobieren!

Hacker News war offenbar auch eine Community mit ziemlich hohem Durchschnittsalter
Die verschiedenen Meinungen sind interessant

Hahahaha, genau das ist es.

Titel und Inhalt passen nicht zusammen. Ich wurde reingelegt.

Ich hatte bisher nur daran gedacht, Starlink einmal auszuprobieren. Es ist schon erstaunlich, so einen Bericht zu sehen, in dem es auf einer Auslandsreise mitgenommen und genutzt wurde.
Wie erwartet ist schon der Kauf in einem Land, in dem es noch nicht eingeführt ist, und die Aktivierung eines Tarifs? selbst eine Hürde.
Hat sich gut lesen lassen.

Wenn all diese Wellen vorübergezogen sind, wie wird die Nachwelt sich an diese Generation erinnern?

Ich glaube, es ging weniger darum, dass ich das Internet unbedingt brauchte, sondern eher um den Wunsch, die Satelliten-Internetdienste, die auch normale Verbraucher nutzen können, wenigstens einmal auszuprobieren, wenn ich schon in eine abgelegene Gegend reiste, in der es kein Mobilfunksignal gibt. Haha

So wie man die Autorität von Lehrbüchern nicht ignoriert, nur weil sie altbacken wirken, und wie sich ihre Alternativen kaum vollständig an ihre Stelle setzen können, bilden bekannte Wirtschaftsbücher selbst die Grundlage oder den Kern der Betriebswirtschaftslehre und der Startup-Forschung.
Das große Werk von Professor Steve Blank, die Methodik der Kundenentwicklung, wurde zu dieser Grundlage und zur Theorie des Lean Startup; die daran beteiligten Wissenschaftler und Pioniere haben wirksame Werkzeuge wie das Business Model Canvas und das Lean Canvas entwickelt und populär gemacht.
Diese abzuwerten oder ihren eigentlichen Zweck zu vergessen und sie als Allheilmittel zu betrachten, zeugt meines Erachtens davon, dass ihr ursprünglicher Zweck nicht richtig verstanden wurde.

Ich gehöre auch zu der Gruppe altgedienter Führungskräfte in multinationalen Unternehmen, und ich stimme voll und ganz zu, dass nur The Goal eine Ausnahme ist. Bücher aus dieser Ecke sind wirklich eine Verschwendung von Zeit und Papier. Bücher über Geschichte, Wirtschaft und Geisteswissenschaften helfen deutlich mehr.

Wenn man Trivy laufen lässt, gibt es im Vergleich zu js NPM oder Java Maven deutlich weniger High- oder Critical-Funde und es ist sicherer. Was genau will der Artikel also mit Rust behaupten?

Gibt es nicht einen Dienst, dem man einfach einen Webseiten-Link schicken und ihn um eine Zusammenfassung bitten kann?

Es gibt einen Slack für Tech-Führungskräfte, der von Michael Lopp betrieben wird.
RLS - Rands Leadership Slack
Wer Interesse hat, sollte einmal vorbeischauen. Der Slack ist inzwischen riesig und hat mehr als 36.000 Mitglieder.
Um beizutreten, sollte man den Inhalt unter dem obigen Link sorgfältig lesen und Lopp dann eine E-Mail schicken.
Name/Beruf/warum man beitreten möchte/wo man von RLS gehört hat/eigener LinkedIn- oder Twitter-Account

Das ist nicht nur ein Problem von Rust.
Es ist ein gemeinsamer Vorteil und zugleich ein potenzielles Problem aller Sprachen, die öffentliche Paket-Repositories und Paketmanager mit transitiven Abhängigkeiten unterstützen.
Letztlich müssen die Leute, die es verwenden, eben gut damit umgehen …
Trotz des leftpad-Vorfalls bei Node&npm hat sich nichts geändert.

In einem ähnlichen Kontext scheint es auch wichtig zu sein, bei der Erstellung von Unterlagen für Kunden, Investoren oder Vorgesetzte aus der Perspektive heranzugehen, etwas zu schaffen, das sich verkaufen lässt. Man Pages sind hervorragend, aber wenn man ihr Format als Benchmark nimmt, um eine Investorenpräsentation zu verfassen, scheitert man wohl.

Ich stimme zu, dass es im Zeitalter der KI-Entwicklung unverzichtbar ist, in kleinen Einheiten mit klar abgegrenzter Verantwortung zu implementieren.

Ich denke, dass Microservices auch in Startups viele Vorteile haben. Vor allem die Vorteile eines Monorepos kann ich wirklich empfehlen.

• Wenn die Produktausrichtung geändert wird, sind bei Microservices die anzupassenden Teile klarer abgegrenzt und weniger zahlreich als bei einem Monolithen. Ich halte das für einen wirklich großen Vorteil.
• Im Zeitalter der KI-gestützten Entwicklung lassen sich die kleinen Einheiten von Microservices mithilfe von KI leichter entwickeln. (Das heißt nicht, dass es bei einem Monolithen nicht geht.)
• Die Belastung durch CI/CD erkenne ich an, aber es gibt auch Services, die schon in der Phase eingestellt werden, in der man noch die Richtung festlegt. Selbst wenn man sie erst aufbaut, nachdem die endgültige Richtung feststeht, ist das fast ein reines Copy-and-paste-Niveau und innerhalb einer Woche umsetzbar.
• Es gibt klar erkennbare Open-Source-Stärken je nach Sprache. Security und Business-Logik in Java, KI in Python – in einer Microservice-Architektur kann man so möglichst viel Open Source nutzen.