JavaRush /Java-Blog /Random-DE /Java und Fahrräder: Treffen in St. Petersburg

Java und Fahrräder: Treffen in St. Petersburg

Veröffentlicht in der Gruppe Random-DE
In 14 Tagen, am 30. Oktober, findet im Wrike- Büro ein ungewöhnliches kostenloses Treffen zum Thema „Java und Fahrräder: Wann lohnt es sich, in das Schreiben eigener Tools im Backend zu investieren?“ statt.
Java und Fahrräder: Treffen in St. Petersburg - 1
Sie können sich auf der Website des Veranstalters für die Veranstaltung anmelden . Das Treffen findet von 19:00 bis 22:30 Uhr an der Adresse statt: St. Petersburg, Swerdlowskaja-Damm 44D (BC Leto), Wrike-Büro. Wenn Sie nicht physisch anwesend sein können, können Sie die Veranstaltungen per Übertragung auf Youtube verfolgen . Das Hauptthema der Veranstaltung wird die Frage der Schaffung eigener Produkte und ihrer Besonderheiten aus maßgeschneiderten Projekten sein. Erfahrene Referenten beschreiben detailliert Situationen, in denen es sinnvoll ist, in die Entwicklung interner Tools zu investieren, und in denen Sie sich mit vorgefertigten Lösungen zufrieden geben können. Die Referenten werden die Frage aufwerfen, wann ein Projektarchitekt das Recht hat, mit neuen Technologien zu experimentieren, wann Tools auf Unternehmensebene eingesetzt werden können und wie viel Flexibilität bei der Auswahl von Technologien von der Größe, dem Alter des Projekts, internen oder externen Kunden abhängt . Das Treffen ist nützlich für erfahrene Java-Entwickler, Architekten, technische Leiter und alle Backend-Entwickler mit einem hohen Kenntnisstand.
Java und Fahrräder: Treffen in St. Petersburg - 2
Programm und Referenten:
  1. Dmitry Mamonov , Wrike „Vom Fahrrad zum Motorrad: Warum die Entwicklung eigener Lösungen besser sein kann als die Verwendung vorgefertigter Frameworks.“

  2. Wie unterscheidet sich der Prozess der Entwicklung eines eigenen Produkts aus technischer Sicht von Outsourcing-Projekten? Wann ist es sinnvoll, von Grund auf in die Entwicklung zu investieren, und wann ist es besser, auf eine fertige Lösung zu setzen?

  3. Vladimir Krasilshchik , Yandex „Willkommen, sonst sind Radfahrer nicht erlaubt“

  4. In der Softwareentwicklung gilt das Schreiben eigener Fahrräder als die Romantik der Arbeit. Programmierer teilen stolz ihre Fahrräder und veröffentlichen sie auf Github. Laut Sprecher handelt es sich um „Hello World“-Projekte mit dem Ziel, etwas zu lernen, oder um Unsinn auf der Ebene von „Wir können uns nicht erinnern, warum wir eine Billardkugel erfunden haben, aus der Haare wachsen, aber es war höllisch schwierig.“

    In seiner Rede geht der Redner auf die Fragen ein, die sich ein „Radfahrer“ oder ein „Radfahrer“-Teamleiter stellen sollte, bevor er zur Tour de France geht. Er wird Beispiele für Bibliotheken und Frameworks nennen, deren Entstehung durch einen pragmatischen Ansatz gerechtfertigt und diktiert wurde, sowie Beispiele für Kreationen, deren Entstehung auf der Grundlage pragmatischer Überlegungen unmöglich ist.

    Java und Fahrräder: Treffen in St. Petersburg - 3
  5. Vyacheslav Lapin , EPAM – Hacken der „Einstiegskurve“

  6. „Fahrräder“ zu erfinden ist eine großartige Lehrmethode! Aufstrebende Künstler kopieren meist die Gemälde von Meistern. Warum wird das NIH-Syndrom in der IT als böse angesehen? Um zu verstehen, wie eine Bibliothek oder ein Framework funktioniert, ist es schließlich am besten, zu versuchen, das Problem, das sie lösen, selbst zu lösen, normalerweise indem man etwas Ähnliches schreibt.

    Da wir zu einem Modell des ständigen, permanenten Lernens übergegangen sind (tatsächlich sind Lernen und Arbeit zu einem einheitlichen Prozess geworden), unterstützt uns der „Fahrradbau“ dabei perfekt, da er im Wesentlichen eine Lernpraxis ist: Wir lesen Tutorials, Artikel, schauen zu Reden auf Konferenzen halten und versuchen, einiges davon in unseren Kampfprojekten auszuprobieren und so den kürzesten Weg entlang der „Einstiegskurve“ in eine neue Technologie zu finden.

    Allerdings ist dies oft nicht der kürzeste, günstigste und sicherste Weg, die geschäftlichen Probleme des Kunden zu lösen, sodass der Kunde selten damit einverstanden ist. Wohin soll sich ein „armer Entwickler“ in einer solchen Situation wenden? Dies wird in Wjatscheslaws Bericht erörtert.

Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION