POPULARITY
Medien berichten dieser Tage von steigender Kinder- und Jugendkriminalität in Österreich, es gibt Forderungen nach einer Senkung der Strafmündigkeit, nach "gefängnisähnlichen" Unterbringungen.Wir schauen genauer hin: o zu „Systemsprengern“ und der Frage, welche Erfahrungen Kinder machen sollten, um ein System zu beleben, statt es sprengen zu müsseno ob es denn stimmt, dass die Jugend von heute faul, fordernd und verwöhnt isto was die Abkehr von autoritären Erziehungsstilen bewirkto warum wir bedürfnisorientierte Erziehung allzu oft missverstehen und womöglich auch gar nicht verstehenmöchteno ob Strafe sein - und wer nicht hören will, fühlen - musso ob Strenge und Härte stark macheno was sich hinter dem Begriff der emotionalen Granularität verbirgto welche Türen sich auftun, wenn erwachsenen Bezugspersonen klar wird: Da habe ich zu hart reagiert [Der Blickpunkt Erziehung Podcast bietet Impulse zum Alltag mit Kindern und ersetzt keine etwaig notwendigen therapeutischen Maßnahmen.].Iris van den Hoeven ist Gründerin von Blickpunkt Erziehung und seit vielen Jahren im Kinderschutz und in der Elternbildung tätig. Sie ist Erziehungs- und Bildungswissenschafterin, psychosoziale Beraterin, im Expert:innenpool der WKO gelistete Supervisorin und arbeitet im Bereich elementarpädagogischer Fortbildungen als Lehrbeauftragte an verschiedenen Pädagogischen Hochschulen. Zudem bietet sie in Verbindung mit zahlreichen Kooperationen Vorträge, Keynotes, Fortbildungen, Webinare, Inhouse-Seminare und Ausbildungslehrgänge zum Thema der gewaltfreien und liebevollen Begleitung kindlicher Entwicklung an, sowie Beratung für Eltern und Elementarpädagog:innen, Fach- und Fallsupervision für elementarpädagogische Teams, Lehrsupervision nach LSB-Gewerbeordnung 2006, §4 Abs.(4) 1a und 1b und den Podcast „Blickpunkt Erziehung - Kindheit liebevoll begleiten“. Auf Social Media steht sie im täglichen Austausch mit über 55.000 Abonnent:innen.VeranstaltungenFortbildung SalzburgDownloads: Wut im kleinen BauchYouTube: TROTZ der PHASEAnmeldung zum Blickpunkt Erziehung NewsletterKontakt / AnfragenÜber michwww.blickpunkt-erziehung.atPodcast „Blickpunkt Erziehung - Kindheit liebevoll begleiten“Frage zur Rubrik „Hingehört & Nachgefragt“ einreichenBeratung & SupervisionBPE FacebookBPE InstagramBPE ThreadsBPE LinkedIn
Die Granularität, oder auch Kleinteiligkeit, von Product Backlog Items ist eine ständige Herausforderung für Product Owner. Manchmal sind die Product Backlog Items zu groß oder man leider unter viel zusätzlicher Verwaltungsarbeit, weil immer wieder ganze Pakete an kleinteiligen Items repriorisiert werden müssen. Das zentrale Thema der Folge ist also die Größe eines Backlog Items. Während der Scrum Guide lediglich fordert, dass Einträge innerhalb eines Sprints abgeschlossen sein sollten, empfehlen Dominique und Oliver eine zusätzliche Regel: Ein Item sollte nicht mehr als die Hälfte des Sprints in Anspruch nehmen. Diese Daumenregel hilft dabei, das Risiko zu minimieren, dass sich ein einzelnes Item über den gesamten Sprint zieht und zu wenig Spielraum für Anpassungen bleibt. Doch Granularität ist nicht nur eine Frage der Planung, sondern auch der langfristigen Produktstrategie. Items, die erst in ferner Zukunft relevant sind, können zunächst grob formuliert sein. Je näher der Umsetzungstermin rückt, desto feiner werden sie definiert. Oliver betont, dass eine zu frühe Detailierung oft überflüssig ist, weil sich Prioritäten im Laufe der Zeit ändern. Das Zusammenfassen und Neuformulieren von Items kann deshalb ebenso sinnvoll sein wie das Zerteilen größerer Einträge. Ein weiteres Thema ist die Handhabung von Granularität im Sprint. Unterschiedlich große Items innerhalb eines Sprints sind kein Problem, solange sie alle einen Mehrwert liefern und das Team die Zusammenhänge versteht. Eine gesunde Mischung aus kleinen, mittleren und größeren Items kann sogar dabei helfen, besser zu lernen und das Forecasting zu verbessern. Ein rein auf gleich große Einträge ausgerichtetes Backlog – wie es beim No Estimates-Ansatz oft gefordert wird – kann zwar die Vorhersagbarkeit erhöhen, schränkt aber unter Umständen die Flexibilität ein. Die Diskussion zeigt, dass Product Owner die Granularität ihrer Backlog Items bewusst steuern sollten. Refinement-Aktivitäten sind notwendig, um sicherzustellen, dass ein gemeinsames Verständnis im Team herrscht. Dabei ist jedoch auch Mut zur Lücke gefragt: Nicht jedes Item muss bis ins kleinste Detail ausformuliert werden. Gerade bei sehr kleinen Verbesserungen kann es sinnvoller sein, sie direkt umzusetzen, anstatt sie ins Backlog aufzunehmen. Letztlich ist die optimale Granularität immer vom jeweiligen Produkt und Team abhängig. Product Owner sollten sich bewusst machen, dass sie nicht nur für den Inhalt des Backlogs verantwortlich sind, sondern auch für seine Struktur und Handhabbarkeit.
In dieser Podcast-Episode diskutiere ich mit Marcus Schmid, Business Analyst/ Product Owner bei Schmilis Consulting, die Herausforderungen und Lösungen bei der Anbindung der IT-Systeme eines mittelständischen Versicherers an seine Vertriebspartner. Wir analysieren zwei konkrete Projekte aus dem Jahr 2024. Kernpunkte: Ausgangssituation: Der Versicherer möchte den Maklermarkt stärker bedienen und benötigt dafür moderne, standardisierte Schnittstellen. Die bestehende Infrastruktur basiert auf proprietären Lösungen und älteren Standards (z.B. GTV), was ineffizient ist. BiPRPO als Schlüssel: BiPRO (Brancheninitiative Prozessoptimierung) wird als zentraler Standard für die Prozessoptimierung zwischen Versicherern und Vermittlern identifiziert. Die Umsetzung von BiPRO ist jedoch komplex und erfordert ein strategisches Vorgehen. Vorstudie als essentieller Schritt: Eine umfassende Vorstudie (ca. 6 Monate) mit internen Experten und Vertretern von Maklerpools ist entscheidend, um Prioritäten zu setzen und die richtige Reihenfolge der Implementierung zu definieren. Das perfekte Team: Das Projektteam sollte Business Analysten (mit Erfahrung in alten und neuen Versicherungsprodukten), Entwickler (mit Expertise im Zielsystem und der Architektur), einen Architekten und Vertreter aus dem Vertrieb beinhalten. Techniker allein reichen nicht aus. Dienstleister-Einbindung: Der Einsatz eines externen Dienstleisters zur Implementierung von BiPRO reduziert Komplexität und Aufwand. Attribut-Mapping als größte Herausforderung: Das Zuordnen der Attribute zwischen dem eigenen System und dem BiPRO-Standard ist sehr arbeitsintensiv. Unterschiedliche Namensgebungen, Datenformate und Längenbeschränkungen erschweren den Prozess. Hier ist Expertenwissen unerlässlich. Geschäftsvorfälle und Granularität: Die korrekte Abbildung von Geschäftsvorfällen (z.B. Vertragsabschluss, Schadenmeldung, Mahnung) ist essenziell für die effiziente Verarbeitung durch die Makler und Pools. Eine zu grobe oder zu feine Granularität kann zu Problemen führen. Testkonzept und Qualitätssicherung: Ein umfassendes Testkonzept mit Fokus auf die Schnittstellenkommunikation (XML, JSON) und die Einbeziehung von Fachbereichen ist unerlässlich. Die Qualitätssicherung sollte konkrete Daten und reale Szenarien verwenden. Rechtliche Aspekte: Die Übertragung sensibler Daten erfordert die Einhaltung von Datenschutzbestimmungen und rechtlichen Rahmenbedingungen. Eine frühzeitige Einbindung der Rechtsabteilung ist daher wichtig. Agile Entwicklung: Ein agiler Entwicklungsprozess ermöglicht eine schrittweise Implementierung und eine schnellere Bereitstellung von Ergebnissen. Wichtigste Erkenntnis: Eine frühzeitige und umfassende Einbindung aller relevanten Stakeholder (intern und extern) ist der Schlüssel zum Erfolg. Vergesst niemanden! Der Erfolg eines solchen Projekts hängt maßgeblich von einer gründlichen Vorplanung, der Zusammensetzung des Projektteams, der Berücksichtigung rechtlicher Aspekte und der frühzeitigen Einbindung aller relevanten Stakeholder ab. BiPRO bietet zwar einen Standard, aber das Mapping der eigenen Daten und die Gestaltung der Geschäftsvorfälle bleiben eine große Herausforderung. Links in dieser Ausgabe Zur Homepage von Jonas Piela Zum LinkedIn-Profil von Jonas Piela Zum LinkedIn-Profil von Marcus Schmid
Cosa significa "rispecchiare le emozioni" di bambini e bambine? In che modo possiamo accompagnarli nella costruzione della competenza emotiva? Ne parliamo con Silvia Iaccarino in questo episodio, focalizzando il tema della granularità emotiva e della consapevolezza interocettiva. Ulteriori contributi: https://percorsiformativi06.it/dimmi-come-mi-sento-limportanza-della-mentalizzazione-per-la-sana-crescita-dei-bambini/Ebook gratuito "Le emozioni dei bambini"https://percorsiformativi06.it/prodotto/lottavo-senso-linterocezione-con-silvia-iaccarino/https://percorsiformativi06.it/prodotto/corso-educazione-emotiva-silvia-iaccarino/https://pubmed.ncbi.nlm.nih.gov/17576282/https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2021.703658/fullhttps://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2022.715966/fullesempio di granularità emotivaConsapevolezza interocettivahttps://neurosciencenews.com/interoception-self-awareness-23472/https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2018.00798/full
Modul 2, Ziele: In Teil 2 von 5 beschäftigen wir uns mit dem Identifizieren und Setzen von Zielen.Dabei ist es wichtig nicht nur das Endresultat zu sehen: wie man das Foto am Gipfelkreuz macht.Jedes kleine Detail zu sehen und sich darin zu verlieren ist überwältigend.Durch die Zielsetzungsmethode (von dem Bestseller Buch The ONE Thing) identifizieren wir deine langfristigen Ziele. Dann machen wir uns die Granularität zu nutze und Teilen unsere großen Ziele machbare "Häppchen". Viel Spaß bei diesem sehr praktischen Modul!Workbook: Hier findest du den Workbook Teil 2: Ziele.Exzellenz durch Eigenleistung: Allrounder AudioprogrammreiheDieses umfassende Audioprogrammreihe ist darauf ausgerichtet Dir zu helfen Dein volles Potenzial in Beruf/Arbeit, Gesundheit und Beziehungen zu entfalten.Es besteht aus fünf Modulen, bestehend aus fundamental wichtige Prinzipien der Produktivität und der Etablierung von anhaltende Routinen. Wir beschäftigen uns mit Zielen und geben dir eine Schritt für Schritt Anleitung um in Aktion zu treten.Ein "must-hear" Persönlichkeitsentwicklungsprogramm für jede/n Selbstoptimierer/-in.Du willst jede Woche praktische Tipps die du in dein Leben integrieren kannst um messbare Resultate im Bereich Persönlichkeitsentwicklung zu bekommen?
Regierungspressekonferenz in der BPK vom 21. Dezember 2022 Bitte unterstützt unsere Arbeit finanziell: Konto: Jung & Naiv IBAN: DE854 3060 967 104 779 2900 GLS Gemeinschaftsbank PayPal ► http://www.paypal.me/JungNaiv Auf dem Cover-Bild der Episode seht ihr heute: Arne Collatz, Sprecher Verteidigungsministerium Kapitel: 00:00:00 Beginn 00:00:20 Bericht aus dem Kabinett 00:05:20 CCS-Technik 00:10:30 Arbeitsmarktteilhabe 00:12:56 Iran 00:13:51 Tilo zu Lufthansa-Boni 00:17:45 Twitter 00:20:55 Tilo zu Twitter 00:21:49 Arbeitszeiterfassung 00:23:07 Afghanistan 00:24:30 Lieferkettengesetz 00:27:47 Tilo zu Kontrolle des Lieferkettengesetzes 00:29:11 Selenski in Washington 00:34:16 Patriotsystem 00:35:08 Puma-Panzer-Ausfall 00:40:47 Tilo zum Puma 00:44:30 Tilo zum Puma II 00:45:11 Waffen für Ukraine 00:47:59 Tilo zu Kampfpanzer für Ukraine 00:48:51 Pflegemangel 00:49:59 Biontech-Lieferung nach China 00:54:21 Tilo zur Biontech-Lieferung 00:55:02 Medikamentenengpass 00:57:21 Tilo zu Raubkunst/Benin-Bronzen 01:00:04 Marokko 01:01:24 Situation in Ostkongo 01:02:47 Nachreichung Benin Bronzen
Das zentrale "Kraftwerk" der Agilität sind Feedbackloops und kontinuierliche Verbesserung. Sie lassen Dich mit minimalem Aufwand Ziele erreichen, die zunächst unvorstellbar erschienen. Feedbackloops entstehen immer dort Wo etwas nutz- bzw. überprüfbares geschieht. Möglichkeit zur Rückmeldung gegeben oder sogar gepullt wird. Die Rückmeldung wahrgenommen und passend in Änderungen umgesetzt wird. Feedbackloops können zufällig entstehen oder geplant werden. Feedbackloops kosten Zeit und werden deswegen oft nicht oder nur halbherzig wahrgenommen. Hier hilft eine Kultur der kontinuierlichen Verbesserung. Warum ist es so wichtig Kontinuierliche Verbesserung beinhalten die Kraft des Zinseszinseffekt. Es gibt mehrere Ebene des Feedbacks und der Verbesserung Das Arbeitssystem. Entscheidungen im System. Die zwischenmenschliche Zusammenarbeit und Kommunikationskultur. Die eigentliche Arbeit. Metaebene: Verbesserung der Verbesserungsprozesse. Umsetzung in der Persönlichen Agilität:Regelmäßige Retros gestaffelt in unterschiedlichen Granularitäten und Zielsetzungen. Arbeit so gestalten das früh nutz/bewertbare Ergebnisse entstehen Ideen und Zwischenergebnisse früh mit einem schnell größer werdenden Kreis an Menschen Teilen. Eine persönliche Methode zum gesunden Umgang mit Feedback schaffen Hat es Euch gefallen? Habt Ihr Verbesserungsvorschläge, Fragen oder Themenwünsche? Kommt auf mich zu:Ihr könnt die Folge auf https://www.personal-agility-podcast.de/ kommentieren und diskutieren.Twitter @p_a_pc Instagramm @p_a_pc FacebookLinkedInsimon@klaiber.com / https://www.linkedin.com/in/simonklaiber/ twitter/clubhouse: @simonklaiber
In questo episodio parliamo della nostra capacità di descrivere le emozioni nel dettaglio, una abilità detta granularità emotiva. Sviluppare questa abilità ci permette di regolarle meglio, non essendone travolt* ma dandoci la possibilità di esperirle in pieno.Per esercitare la tua granularità emotiva puoi scaricare gratuitamente questa scheda e utilizzarla per descrivere i tuoi stati emotivi!Music credits: Federico Ricci
durée : 01:00:10 - Grain (4) : l'IDM et la Granularité - par : Clément Lebrun - invité : Anthony Papavassiliou, musicologue (étude de l'Intelligent Dance Music (IDM)) - réalisé par : Périne Menguy
Il est venu le temps de nos doudous jeux vidéo d'automne, mais aussi de se projeter dans l'avenir des consoles et de bien d'autres choses fun... Retrouvez vos chroniqueurs favoris dans un nouvel épisode Party chat! 01:05 Nos jeux du mois 20:47 Les Nouvelles du front 28:54 Nos jeux flops 39:05 Twitch surfin' 47:12 Allez, on joue! 56:05 Le tour d'horizon des annonces 01:07:51 Nos jeux du mois prochain 01:17:40 Y'a pas que le jeux vidéo dans la vie @YAC1N3@UnkleLauh@ADILTAOUFIK@_9uizm0_@Manultraman@antopyra@Rgiansily Pour nous suivre: sur twitter: https://twitter.com/jaimejouercast sur facebook: https://www.facebook.com/jaimejouerseriedocumentaire/ sur Instagram:https://www.instagram.com/jaime_jouer/ Et tous nos épisodes sont disponibles en écoute sur Spotify, Ausha, Deezer, Itunes, Podmust et Stitcher! J'aime Jouer podcast:1 podcast THEMA et 1 podcast PARTY CHAT par mois!#teamjaimejouer #jeuxvidéo #podcast
Thomas Lobinger ist Software Development Manager bei Amazon Web Services in Berlin. In unserem Interview mit ihm sprechen wir ein wenig über seinen Werdegang, über Design Systeme, wie bei Amazon Web Services Teams funktionieren und was er für Erfahrungen in den letzten Jahren in einem ständig wachsenden Unternehmen gemacht hat. Unser Team kümmert sich um das Design System, Tools und Automating … um das Leben von Frontend-Entwicklern und Designern besser zu machen und deren Produktivität zu erhöhen. —Thomas Lobinger Das Design System ist über eine längere Phase entstanden. Die Genesis des AWS Design Systems liegt darin begründet, dass das zentrale Frontend-Entwicklungsteam der großen Menge an Projekten nicht nachkommen konnte. Alleine 2016 sind 1017 Features und Services gelauncht worden, um dies mal in einen Kontext zu setzen. Deshalb ist das durch ein Team auch nicht machbar gewesen. —Thomas Lobinger Wir sprechen über Granularität und Feinteilgkeit in Designsystemen und was die Basis für Komponenten ist: Was ist der richtige Grad an Vorschriften vs. Einschränkung der Kreativität? Für uns sind HTML-Tags/Webstandards diese Basis. Wir haben uns dann auf web components fokussiert, haben deren API aktuell noch über Klassen abstrahiert, können diese dann aber (wenn web components native verfügbar sind) ablösen. —Thomas Lobinger Standardisierung ist für das Team um Thomas bei AWS auf allen Ebenen und in allen Gewerken Thema: Wir haben einen Prozess angestoßen, der nicht nur im Frontend standardisiert ist sondern auch im Design. Wir stecken z.B. Research in solche Standards, denn wenn wir standardisieren dann auch richtig. —Thomas Lobinger Open Source für Design Systeme ist Thema für uns und Thomas sagt dazu: Wir glauben, dass es ein Benefit ist für die Community (unser Design System open source zu stellen), … um zu sehen wie es gelöst worden ist. —Thomas Lobinger Uns am Ende noch ein Aufruf: Sucht Euch eine Firma wo ihr das (Design Systeme/UIengineering) umsetzen könnt. Seid nicht der frustrierte Einzelkämpfer. Lasst Euch nicht aufhalten! —Thomas Lobinger Das Interview wurde am 15.09.2017 per Skype aufgenommen. Shownotes & Links Working backwards (Blogpost) Working Backwards (Video) Olga Madejska: Breaking Bad - Web Components in production, what worked for us | JSConf EU 2015 (Web?) Components in production Draft of the Unity (Single File Web Component) Specification
Ajoutez un peu de chaos à votre début de semaine en écoutant nos tentatives ratées d'émissions de radio fictives entrecoupées de bouttes de nous autres qui jasent! On parle de Friends, de papier, des portes du matin, de oiseaux, de Sonic the Hedgehog, du sommeil, de salon funéraire et de commanditaires potentiels. C't'écoeurant!Aux Portes du MatinPersonne check les liensTélécharger l'épisode
Guillaume, Cédric et Arnaud se retrouvent autour du micro pour parler pendant une session marathon de 3h30 du build, de Maven et de Gradle. Dans cette deuxième partie, on y discute tests puis on aborde des questions spécifiques à chaque outil. On aborde enfin le dilemme: migrer ou ne pas migrer, telle est la question. Le tout basé sur les questions posées sur la mailing list des cast codeurs : merci à vous ! Enregistré le 19 juillet 2017 Téléchargement de l’épisode LesCastCodeurs-Episode–175.mp3 Interview Ta vie ton œuvre Cédric Champeau Gradle Inc. Arnaud Héritier Cloudbees Gradle Maven Les tests Gradle / Maven: Quelle est la philosophie officielle des deux outils pour la gestion des tests au delà des tests unitaires (une fois les différents modules assemblés et déployés) ? Dans des projets maven par exemple, je vois des fois des modules dédiés, en scope test ou scope runtime et lancés à la main, d’autres fois des projets indépendants. Chaque équipe a plus ou moins sa propre façon de gérer la chose mais rien n’a l’air vraiment normalisé (ou du moins partagé par la communauté). Gradle / Maven: Quels sont les ‘best practices’ pour faire du ‘test and watch’ (genre infinitest) avec maven et gradle ? Les intégrations Gradle: Pourquoi je ne peux pas faire de Run Tests sur un projet en Gradle dans IntelliJ alors qu’avec Maven je peux ? Gradle / Maven: Pour les deux, qu’en est il de l’intégration dans les différents IDE ? J’ai été agréablement surpris par l’intégration de Gradle dans Netbeans, mais je n’ai pas beaucoup joué avec. Gradle / Maven: “Quid de l’intégration dans mon IDE préféré ?” Gradle / Maven: “Quid de l’intégration dans mon continuous build préfére ?” Gradle en profondeur Gradle: Y’a moyen de voir en Gradle à quel test je suis rendu ? Gradlew/mvnw Gradle: Pourquoi mvnw et gradlew ne downloadent par leurs jars au lieu de nous forcer à les mettre dans .mvn et gradle ? Gradle: Pour Gradle, vous ne trouvez pas affreux ces fichiers “gradlew” et “gradlew.bat” à la racine de chaque projet dans github ? Scripting vs XML Gradle: Est-il prevu de pouvoir avoir un fichier build.gradle a chaque niveau de la hierarchie de tes modules au lieu d’avoir besoin de decrire manuellement tous les paths dans un fichier settings.gradle ? C’est un point que j’ai trouvé penible (par ex https://github.com/xwiki/xwiki-commons/blob/master/settings.gradle et là je ne liste que qq modules - en pratique il y en a des centaines ds le build xwiki). Gradle: Est-ce que Gradle travaille a essayer d’homogénéiser encore plus les builds Gradle ? Qd j’ai essayé de convertir le build Maven de XWiki en Gradle, j’ai lu la doc puis j’ai regarde 4–5 builds differents en gradle pour voir les bonnes practices. Et la j’ai ete embete car chacun avait des pratiques un peu differentes. Au debut j’etais meme paumé et puis apres qq heures de recherches j’ai commencé à identifier des patterns communs mais qd meme avec pas mal de variations. Du coup je n’ai pas su trouver facilement les best practices et j’ai du me les faire et en consequence le build Gradle XWiki est lui aussi encore un peu different des autres probablement. Qu’est-il prevu sur le sujet ? En gros comme simplifier encore plus l’onboarding Gradle ? BOM Gradle: Le BOM de maven est-il une invention du malin ? Et quel est son équivalent pour Gradle ? Android Gradle: Pourquoi l’intégration de ces outils dans Android Studio est-elle aussi pathétiquement mauvaise ? (je suis obligé d’utiliser ce sous-outil, et j’ai mal à mon gradle : je ne peux pas voir mes dépendances facilement, et l’intégration se résume à une lecture de la liste des tâches et à leur lancement). Maven en profondeur Maven: Quand est-ce que le bogue Maven du shade plugin qui ne remplace pas le jar d’origine pas le jar shadé sera corrigé? (et que donc l’équipe Maven reviendra à la raison) ? Maven: Pour revenir au cycle de vie de Maven, serait-il possible de configurer des cycles de vies (notion de descripteurs de cycles de vie). En gros, pouvoir dire que mon projet suit un cycle de vie à 3 phases qui sont “resource, compile, install” et qu’un autre avec X phases comme compile, “prepare, …, install, deploy-maven-repository, deploy-env”) Maven: Pour Maven encore, il y avait il me semble un projet polyglot pour les descripteurs, qu’en est-il ? Pourrait on imaginer des descripteurs en yaml et/ou json ? Maven: y’a t’il beaucoup de boites qui dev leurs petits plugins Maven perso pour adapter à leurs problématiques ? Granularité / découpage de modules avec Maven Maven: comment gérer les builds où l’appli finale est la résultante de nombreux multi-module Maven project, chacun dans un repo git perso avec leur version. Nous avons des problèmes pour gérer les évolutions de versions de chacun de ces multi-modules et faire en sorte que les modules qui en dépendent se MAJ vers la nouvelle version. Les BOM Maven sont une piste mais c’est pas clair… Maven: est-ce une bonne pratique de considérer comme absolue la règle selon laquelle tous les modules d’un multi-module Maven project doivent avoir le même numéro de version ? Maven: est-ce bien une mauvaise pratique que de mettre dans le même repo Git 2 multi-module Maven projects qui ne partagent pas le même parent ? Maven: les devs familiers avec Maven n’ont ils pas trop tendance à découper leurs appli en modules Maven alors qu’ils pourraient se contenter des package Java ? Je me rend compte que c’est mon cas perso… Maven: Pour des grosses applis, faites-vous plusieurs petits builds et un meta-build d’assemblage final agrégeant les petits morceaux ? Ou alors faites-vous un bon gros build qui dure longtemps mais recompile/repackage tout ? Ou alors vous laissez-vous le choix en faisant en sorte de pouvoir faire les 2 (sur Jenkins) Maven: “classpath too long”: c’est la résultante du point précédant. Nous commençons à nous heurter à des problèmes de “classpath too long” sous Windows pour des Proof of Concepts mixant de nombreux projets. Le point de non-retour est-il proche ? (Pour info, nous contournons temporairement le problème en ayant utilisé la commande mklink pour simlinker le repo Maven sur c:repo et gagner quelques caractères sur chaque dépendance… oui, c’est tres moche) Maven: quid du paramétrage du build ? Par exemple actuellement nous avons une phase de packaging assez générique qui prend en entrée un numéro de version de l’application à packager. Merci Jenkins. Migration Migrer vers Gradle, mais pourquoi (pas) ? Et la valeur du build dans tout ça … Gradle: Pourquoi est-ce que depuis 3 ans, je vais voir une prez de Cédric sur Gradle, et j’en ressors en me disant “Gradle, ça a l’air quand même vachement bien”, et que l’année qui suit, je retourne voir une prez de Cédric l’année suivante sans avoir rien changé sur mes projets Java ? Gradle: Suis-je tellement fainéant dans mon petit confort de build Maven pour reposer sur mes acquis et ne pas switcher ? Je veux dire … à chaque fois j’ai de bons arguments apportés par Cédric pour migrer, et pourtant, le switch ne se fait finalement pas. Gradle / Maven: Considère-t-on aujourd’hui le build comme accessoire sur un projet Java pour ne pas vouloir engager un investissement de migration ? (je parle beaucoup de mon cas perso ici, mais j’ai l’impression qu’il n’est pas si isolé que ça) Ou au contraire, est-ce tellement critique et relativement assez peu agile qu’on a trop peur d’en changer? Si on reprend le cas de Ant vs Maven, pas mal de gens ont traine a migrer, c’etait trop risque, les bonnes pratiques etaient encore peu connues, tout le monde avait peur de crasher son projet a cause de ca… Personne ne veut essuyer les platres d’une “nouvelle” techno de build avec son projet. Gradle: Peut-etre Gradle en est-il encore la et a du mal a passer le cap des Early-Adopters (ceci dit, avec Android et son armee de developpeurs d’apps ca devrait changer vite si c’est le cas; tant qu’Android l’infidele decide de rester sur Gradle :P Gradle: Et enfin, LE point-cle: est-ce que la migration de Maven a Gradle amene une valeur ajoutee suffisante pour justifier l’effort et le risque? J’ai pas l’impression de lire beaucoup de retour d’experience de projets qui disent avoir gagne drastiquement en productivite en en qualite grace a une migration Maven->Gradle. Gradle / Maven: “je démarre un projet, Gradle ou Maven ?” Conclusion Gradle / Maven: les devs et le build: généralement, la grande majorité des devs ne s’y intéressent pas. A titre perso, je trouve ça fondamental, si le build est mal fait, ça handicap tout le projet sans que les gens ne s’en aperçoivent malgré les effets négatifs, ils ne voient pas comment faire autrement => est-ce un ressenti que vous avez ? Nous contacter Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com
Ein Talk im Café hat gut geklappt, deshalb habe ich mich mit Marinko Spahic, seines Zeichens VFX Designer, im Kaffee Ernst in der Kölner Südstadt getroffen. Wir sprechen über seinen Einstieg in die Film- und Video-Branche, Parallelen zwischen Film- und Produktdesign, die Granularität von Designprozessen unter anderem am Beispiel von Melancholia, Leidenschaft, Lernen und Jurassic Park. Toller Gast, entspannter Talk. Daran wird angeknüpft! Wer Formfreude einmal live erleben möchte kann das im Rahmen der Kölner Internetwoche gleich fünf Mal machen: Unter widjet.de/iw7 findet Ihr nach etwas scrollen die Termine (alle von 10-11:30 Uhr) und Gäste. Kostenlos anmelden könnt & müsst Ihr Euch direkt unter das-formfreude-podcast-fruehstueck.eventbrite.de Marinko wird auch mit von der Partie sein! Nicht verpassen :)
Die Digitalisierung verändert unsere Wahrnehmung der Welt: Unsere Körper, die Natur, unsere sozialen Beziehungen – alles erscheint in höherer Auflösung, durch immer mehr Daten analysierbar. Feinste Unterschiede werden erkennbar, das Individuelle überlagert das Allgemeine. Lässt sich unser gesellschaftliches Ideal der Gleichheit vor diesem Hintergrund aufrechterhalten? Im Umgang mit komplexen Daten sind uns Computer zusehends überlegen. Wer sind wir noch, wenn Intelligenz und Rationalität nicht mehr als allein menschliche Merkmale gelten können? Müssen wir uns vom Homo rationalis zum Homo irritabilis entwickeln, um uns von intelligenten Maschinen abzugrenzen? (Klappentext) Mit wem ich auch rede, alle haben das Gefühl, dass die Welt, wie wir sie kannten, zusammenbricht. Das Buch von Christoph Kucklick hat es mir mit eiskalter Nüchternheit bestätigt, mir aber auch Lust gemacht, mich mit den Fragen und Herausforderungen der Zukunft auseinanderzusetzen und der Katastrophe mit Engagement und Neugier zu begegnen statt mit Untergangsangst. Dringende Leseempfehlung!
Gemeinsam mit Erik Gostischa-Franta, der uns auch kräftig bei der Qualitätssicherunges-Vorlesung und Übung hilft geben wir einen kurzen Einblick in Test-getriebene Entwicklung. Die Kernaussage auf den Punkt gebracht ist folgende: Für jedes Feature, das man plant und in die eigene Anwendung einbauen möchte, muss gleichzeitig nachgedacht werden, wie dieses zu testen ist. Dasselbe gilt dann für die eigentliche Implementation: hier ist immer zu überlegen, ob die konkrete Implementation auch (automatisch) zu testen ist. Über Automatisierung sprechen wir in diesem Podcast allerdings nicht, das ist schon in der Einheit mit Reinhard Pötz diskutiert worden.Konkrete Inhalte sind:Bedingungen für erfolgreiche Test-StrategienTest-Driven DevelopmentGranularität von TestsUnit-Test FrameworksBeispiel: Testen einer DAO MethodeVorlesung als m4a
© 2020-2025 Ivy Podcast Discovery LLC
