Podcasts about Not invented here

Dr Christopher Snowdon joins us to discuss the "Not Invented Here" syndrome in activist groups and policy campaigns. From weight loss drugs to e-cigarettes, nuclear power to GM foods, Snowdon explores how campaign groups often resist practical solutions that weren't developed by their own organisations - even when these solutions clearly work. Using real-world examples, Snowdon breaks down how activist groups frequently prefer radical societal changes over pragmatic fixes. He examines cases like public health groups opposing effective weight loss medications while pushing for dramatic changes to food environments, and environmental groups rejecting nuclear power despite its clear benefits for reducing emissions. The conversation reveals how institutional preferences and ideological commitments can sometimes override stated goals. The discussion dives into why this resistance happens, from the sunk cost fallacy to anti-corporate sentiment, and explores what it means for solving major societal challenges. Snowdon explains how campaign groups' rejection of market-based solutions often stems from deeper ideological preferences for reshaping society, rather than simply addressing the problems they claim to want to solve. This episode offers insights into why some of our most pressing problems remain stuck in ideological gridlock despite available solutions. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit insider.iea.org.uk/subscribe

I get a tech newsletter most days, which has news that I enjoy, but interspersed among the news and ads are projects, frameworks, or repos, most of which I've never heard of before. I used to read these, but it seems that there is an endless list of these, which all have marketing descriptions that somehow claim this set of code solves problems that others don't or that this code is easy to use and integrate with, or well, I don't know what other promises. I'm usually turned off by the end of the first sentence. The thing I've noticed is that there are so many projects out there. Even in the database space, if I happen to read a discussion on some aspect of databases, such as database deployment frameworks, I'll see links to technologies I've never heard of in my life. Some are small projects, and some are small companies, but there is an amazing variety of solutions for any tech problem. I'm not sure most of them are much different from the others, but the Not Invented Here syndrome seems to be everywhere. These observations also remind me of just how vast the world is and how little I see of it on a daily basis. Read the rest of Keep. It. Simple.

Etes-vous sujet au syndrome NIH – Not Invented Here en anglais – ou en français au syndrome du "Pas inventé ici" ?Le NIH, c'est la tendance au sein d'une organisation à rejeter des innovations ou des solutions externes, simplement parce qu'elles n'ont pas été créées en interne...➽ Pour vous inscrire à ma lettre d'inspiration mensuelle :https://bit.ly/LettreGM-POD➽ Pour découvrir notre coaching professionnel :https://bit.ly/CCPro-YT► Qui suis-je ?Guillemette Moreau, coach de dirigeants, coach de carrière, formatrice en entreprise, je souhaite partager mes découvertes et outils pour aider à un monde professionnel plus heureux, motivé et efficient !► Pour me contacter :Courriel : contact@guillemettemoreau.comhttps://www.linkedin.com/in/guillemette-moreau-coaching/https://www.facebook.com/GuillemetteMoreau

El síndrome del no inventado aquí (NIH, Not Invented Here, por sus siglas en inglés) se puede definir como una tendencia de las personas y las organizaciones a evitar cosas que no crearon ellos mismos. NIH es a menudo el resultado del orgullo que hace que una organización crea que puede resolver un problema de una mejor manera que las soluciones preexistentes que ya lo hacen. Este síndrome puede ser similar al síndrome de “reinventemos la rueda”. El síndrome de Not Invented Here a veces también se conoce como la "teoría del cepillo de dientes". Después de todo, una solución se parece mucho a un cepillo de dientes; todos quieren uno, todos necesitan uno, pero nadie quiere usar el de otra persona Me encantaría tu feedback. Hazlo via email (rafael.lucero@adum.es) o directamente a mi móvil: +34686463724 No te olvides de comprar mi libro "Kaizen Lean 4P29" en Amazon https://www.amazon.es/dp/B0BB3H21J3 Saludos Rafa https://linktr.ee/rafalu0 Escucha el episodio completo en la app de iVoox, o descubre todo el catálogo de iVoox Originals

Этот выпуск в YouTube: https://youtu.be/o0y4iPGYe6s Дима и Вячеслав проводят ретроспективу первого сезона Biweekly и делятся планами на свое подкастерское будущее. * Первый эпизод Biweekly вышел 24 февраля 2016 года (https://sonar.one/biweekly/1) * Другиe Димины подкасты * Доброе утро, Индия! (https://sonar.one/good-morning-india) * Not Invented Here (https://sonar.one/podcasts/not-invented-here) * Подкаст Biweekly начался с идеи "Английский – в широкие айтишные массы!" * Славу привел к подкастам Дима, а Дима как-то сам до этого дошел * Почему только у недавних эпизодов понятные названия? * Слава с особой теплотой вспоминает эпизоды посвященные темам * 126: Good Year (https://sonar.one/biweekly/126) * 127: Год равномерного распределения эфира (https://sonar.one/biweekly/127) * 143: Retro themes (https://sonar.one/biweekly/143b) * 152: Отчетно-выборное заседание (https://sonar.one/biweekly/152) * 171: Темы на 2020 (https://sonar.one/biweekly/171) * 206: Темы 2021 (https://sonar.one/biweekly/206) * 232: Прогресс по темам 2021 (https://sonar.one/biweekly/232) * 241: Снова темы (https://sonar.one/biweekly/241) * The Theme System (https://www.themesystem.com) from CGP Grey and Myke Hurley * Книжный клуб Biweekly * 39: Литературный piece (https://sonar.one/biweekly/39) * 141: Пш., скрщ. (https://sonar.one/biweekly/141) * 197: Современная практика стоицизма (https://sonar.one/biweekly/197) * 235: Humankind: A Hopeful History (https://sonar.one/biweekly/235) * 266: Tribal Leadership (https://sonar.one/biweekly/266) Выпуски с гостями * 46: Соединенные треугольники успеха (https://sonar.one/biweekly/46) c Димой Миндрой * 55: Пожизненная Холакратия (https://sonar.one/biweekly/55) с Артемом Сердюком * 64: Выявить метапрограмму (https://sonar.one/biweekly/64) c Аней Стеценко * 86: Спина верблюда (https://sonar.one/biweekly/86) c Мариной Зайцевой * 122: Саппортная труба (https://sonar.one/biweekly/122) с Надей Новицкой * 137: Кто сидел в кубикле? (https://sonar.one/biweekly/137) с Андреем Кривцуном * 145: Душевные противотанковые ежи (https://sonar.one/biweekly/145) с Володей Недогодой * 217: Ком'юніті та їх децентралізація (https://sonar.one/biweekly/217) з Анною Головченко * This Week Planner (https://www.etsy.com/shop/thisweek) * Неизвестная история заставки для видео к 217-му выпуску * Другие памятные эпизоды * 37 Это не называется дебатами (https://sonar.one/biweekly/37) про ...дебаты * 70: Маленькие саботажики (https://sonar.one/biweekly/70) про методичку ЦРУ * 79: “Out of the box” thinking (https://sonar.one/biweekly/79) – первый англоязычный * 125: Live (https://www.youtube.com/watch?v=BNHfeO1kjFY) – первый живой и единственный записанный с ведущими в одной комнате * 157: 5 столпов бизнеса (https://sonar.one/biweekly/157) – c Диминой идеей устройства бизнеса * 265: Коллекция инструментов (https://sonar.one/biweekly/265) – венец эволюции первого сезона * Какие уроки Дима и Слава вынесли из первого сезона * Будущий новый формат Спасибо всем слушателям, которые прошли этот путь с нами!

Этот выпуск в YouTube: https://youtu.be/o0y4iPGYe6sДима и Вячеслав проводят ретроспективу первого сезона Biweekly и делятся планами на свое подкастерское будущее.* Первый эпизод Biweekly вышел 24 февраля 2016 года (https://sonar.one/biweekly/1)* Другиe Димины подкасты * Доброе утро, Индия! (https://sonar.one/good-morning-india) * Not Invented Here (https://sonar.one/podcasts/not-invented-here)* Подкаст Biweekly начался с идеи "Английский – в широкие айтишные массы!"* Славу привел к подкастам Дима, а Дима как-то сам до этого дошел* Почему только у недавних эпизодов понятные названия?* Слава с особой теплотой вспоминает эпизоды посвященные темам * 126: Good Year (https://sonar.one/biweekly/126) * 127: Год равномерного распределения эфира (https://sonar.one/biweekly/127) * 143: Retro themes (https://sonar.one/biweekly/143b) * 152: Отчетно-выборное заседание (https://sonar.one/biweekly/152) * 171: Темы на 2020 (https://sonar.one/biweekly/171) * 206: Темы 2021 (https://sonar.one/biweekly/206) * 232: Прогресс по темам 2021 (https://sonar.one/biweekly/232) * 241: Снова темы (https://sonar.one/biweekly/241)* The Theme System (https://www.themesystem.com) from CGP Grey and Myke Hurley* Книжный клуб Biweekly * 39: Литературный piece (https://sonar.one/biweekly/39) * 141: Пш., скрщ. (https://sonar.one/biweekly/141) * 197: Современная практика стоицизма (https://sonar.one/biweekly/197) * 235: Humankind: A Hopeful History (https://sonar.one/biweekly/235) * 266: Tribal Leadership (https://sonar.one/biweekly/266)Выпуски с гостями * 46: Соединенные треугольники успеха (https://sonar.one/biweekly/46) c Димой Миндрой * 55: Пожизненная Холакратия (https://sonar.one/biweekly/55) с Артемом Сердюком * 64: Выявить метапрограмму (https://sonar.one/biweekly/64) c Аней Стеценко * 86: Спина верблюда (https://sonar.one/biweekly/86) c Мариной Зайцевой * 122: Саппортная труба (https://sonar.one/biweekly/122) с Надей Новицкой * 137: Кто сидел в кубикле? (https://sonar.one/biweekly/137) с Андреем Кривцуном * 145: Душевные противотанковые ежи (https://sonar.one/biweekly/145) с Володей Недогодой * 217: Ком'юніті та їх децентралізація (https://sonar.one/biweekly/217) з Анною Головченко* This Week Planner (https://www.etsy.com/shop/thisweek)* Неизвестная история заставки для видео к 217-му выпуску* Другие памятные эпизоды * 37 Это не называется дебатами (https://sonar.one/biweekly/37) про ...дебаты * 70: Маленькие саботажики (https://sonar.one/biweekly/70) про методичку ЦРУ * 79: “Out of the box” thinking (https://sonar.one/biweekly/79) – первый англоязычный * 125: Live (https://www.youtube.com/watch?v=BNHfeO1kjFY) – первый живой и единственный записанный с ведущими в одной комнате * 157: 5 столпов бизнеса (https://sonar.one/biweekly/157) – c Диминой идеей устройства бизнеса * 265: Коллекция инструментов (https://sonar.one/biweekly/265) – венец эволюции первого сезона* Какие уроки Дима и Слава вынесли из первого сезона* Будущий новый форматСпасибо всем слушателям, которые прошли этот путь с нами!

Developers, in general, are very optimistic about the code they write. This is likely one cause of their estimates of the time required being low, as well as the various bugs that slip through because of corner cases that appear for the problem being solved. Often developers think they've considered the various ways this code ought to work and covered all the possibilities. Usually we find they've not thought about the problem from other perspectives and need to adjust their code. They often also feel that their code is superior to others, and that they can examine a problem in a new way. One of the reasons that I think many developers want to rewrite systems in some new technology or new way, embracing the Not-Invented-Here way of looking at other people's code. They want to write their own solution. Read the rest of Developer Optimism

One of the biggest risks for an engineering org is the “Not Invented Here” syndrome where the tech team wants to rethink every decision and rebuild every piece of tech from scratch. But sometimes it makes sense to take a different path if the constraints you're optimizing for are uncommon.In this episode I chat with Adam Sypniewski, CTO at Deepgram about some of the non-obvious choices that their team has made - from programming languages and hosting to team composition and how to approach build vs buy decisions.

Gurus, why should you have your engineers and researches out in the field? How can they get a good product market fit? What is the NOT INVENTED HERE factor and why should you avoid it? Dr. Carlson discusses this and more. Listen in as he provides further evidence that perfect should not be the enemy of good. You will enjoy this episode as Dr. Carlson gets into all of this and more. www.immunexpress.com       www.septicyte.com

In this episode, I meet Ramon Vullings, The IdeaDJ, talking all things creativity and innovations and his new book Great Leaders Mix and Match.  He is also the author of a number of books in the creative space including Not Invented Here, Creativity Today and Creativity in Business.   Ramon is an engaging keynote speaker, author, cross-industry expert & ideaDJ, he speaks about bringing the outside world in and why remixing of ideas cross-sector is a smart strategy in this digital era. Described as "an electrifying and passionate speaker, his talk on the topic of cross-industry innovation & creativity was one of the most well received talks at the NASA summit." - Omar Hatamleh, Chief Innovation Officer – NASA Ramon helps business leaders with strategies, tools & skills to look beyond the borders of their domain to transform their business in a smarter way Web: https://www.ramonvullings.com/ Book: https://amzn.to/3dTbHGv I mentioned a couple of other things  My fundraising page for the London Marathon is here - https://uk.virginmoneygiving.com/NigelCreasersvirtualLondon2021 Link to other show guests books and my books - https://www.nigelcreaser.com/p/sunday-lunch-shop.html --- Send in a voice message: https://podcasters.spotify.com/pod/show/sundaylunchpm/message

Wherein things were Not Invented Here, and Frank is Dwayne 'The Rock' Johnson.

Erdem Kaya Patent şirketinin kurucusu Erdem Kaya ile "Patent Ticarileştirme Süreçlerinde Doğrular ve Yanlışlar" üzerine keyifli bir sohbet gerçekleştirdik. Podcast yayınında konuştuğumuz konulara dair linkleri aşağıda bulabilirsiniz: ABD teknoloji transfer ekosisteminin performans göstergeleri: http://bit.ly/AUTM-licensing-survey-2018 TÜBİTAK Patent Lisans Çağrısı: https://bit.ly/TUBITAK-Patent-Lisans-Cagrisi Patent Değerleme: https://www.patenteffect.com/patvindex Ayrıca Erdem Kaya Patent hakkında daha geniş bilgi edinmek isterseniz: https://www.erdemkayapatent.com Düzeltme: Bölüm içerisinde "Not Invented Here" olgusunu bir felsefe olarak ifade etmiştik ancak literatürde bir sendrome olarak geçmektedir. Şirketlerin bu sendromun üstesinden gelerek açık inovasyona adaptasyonlarını geliştirmeleri gerekiyor. Dinleyicilerimizden Oya Zincir'in uyarısı için çok teşekkür ederiz.

פודקאסט מספר 394 של רברס עם פלטפורמה - אורי ורן שוב מארחים את ליאור קיסוס, התאריך (למי שעדיין עוקב בשנה הזאת) הוא ה-21 ביולי 2020. ליאור כבר ביקר כאן מספר פעמים (וכאן על הקנטינה ושוב בפרק 132 (Sasson/פרדס-חנה…) ואז על mean.io בפרק 188 וכן - עברו כבר 10 שנים מאז 2010…); ליאור גם הרצה (וגם גייס) בכנס שלנו - והיום נדבר על Rancher ועל נושאים באיזור, וגם על המסע של ליאור מחברת Open source ל . . . ובכן, תיכף נשמע מה הוא עושה היום, אל תדאגו - זה לא מאוד רחוק (כאן מלטה) - אבל בהחלט מעברים טכנולוגיים חדים ומעניינים.אז ליאור - קצת עליך ועל החברה שלך:אני ליאור קיסוס, אני ה-CTO של חברה בשם Linnovate, שקיימת כבר מאז 2006 - אנחנו כבר 14 שנים, ומתגלגלים ומשתניםבאמת, כשהתראיינו זה היה בכל מיני Milestones לאורך הדרך ותפיסות לאורך הדרך כך שמעניין להתסכל על זה.יש לי חמישה (5!) בנים שזה 5^2 (2 בחזקת חמש…) אפשרויות לגרום אחד לשני לדמם או ליפול על האף או כל מיני דברים כאלה . . כמעט שלא הגעתי כי עוד בן נפל וכמעט פתח את הראש ודברים כאלה . . .(רן) אמרתי לאישתי שבסוף הדביקו לך את הבן, אבל זה לא קורונה . . . רק דבק פצעים(ליאור) אבל אני חייב להתחיל עם התנצלות - היה, אני חושב, את הרברסים של 2015 בחיפה (הרבה עבר על ה-web interface מאז), על בניית קהילות Open Source וה-Grooming של איך לפתח את זה בעקבות ה-mean.io וכל הנושא הזה שדיברנוואני לא קודדתי את הסרטון . . . אני נושא על עצמי את המשקל הזה, אני פשוט לא קודדתי את הסרטון, וזה גם הסרטון היחיד שלא יצא ברברסים של 2015 (בגלל זה הלינק כזה). אשמתי, בגדתי . . .(רן) אז אחרי שגרמנו לך לאשמה, בושה ורגשות ממש שליליים - בוא מעכשיו נעשה רק טוב ההתנצלות מתקבלת.(ליאור) סבבה - אז אנחנו ב-Linnovate עברנו איזושהי אבולוציה . . . תקציר הפרקים הקודמים - חברה שהתחילה סביב Drupal, מערכת ניהול התוכןהתחילה בכלל עוד קודם ב-Linux ו-Innovation - זה השםותמיד - Open Source היה הקונספט, ותמיד היה לנו משהו שאני דלוק עליו, שהחברה איכשהו רצה בעקבותיו.רצנו כמה שנים עם Drupal ואז שברנו את תקרת הזכוכית של כל מיני עמותות וארגונים, לעבוד עם כל מיני John-Bryce-ים ו-Commtouch-ים וערוץ הילדים וחבר’ה כאלה.בעקבות ההתקדמות הזו, כשפגשנו את ה-mean.io והיה את הפרק על mean.io, לא יודע מתי (2013…), פתאום נפתח לנו העולם הזה, לפני 8-9 שנים, של Full-Stack JavaScript, של Angular, של Node.js, של MongoDB בסביבות 2011-2012 כזה . . . ואז פתאום התחלנו כחברה להשתנות - אנחנו עושים גם את זה וגם את זה(רן)רק תזכיר לנו - MEAN זה ראשי תיבות של . . . (ליאור) Mongo-Express-Angular-Node - זה היה “הדבר” כש-Angular 1.0 היה “הדבר”, אבל זה היה גם דבר מאוד יפה של Keyword-proximity, וזה היה באמת פרויקט משותף שלנו ושלי ב-Linnovate יחד עם עמוס חביב, שהיה פרילנסר שעבד איתנו באותה תקופה, וביחד חשבנו לגייס על זה כסףהיו כמעט 12,000 Starts ב-GitHub, נדל”ן מאוד מענייןהבעיה של mean.io, בפרספקטיבה - בעולם שהוא decoupled ועם microServices ודברים כאלה, זה היה “מונוליט כפול” - גם “מגיש לך את הדף” (עם ה-Node.js)ואז מעלה את ה-Angularמה שקורה זה בעצם שאתה “הכי איטי” - גם מגיש את הדף, אין Server-side rendering . . . אתה יודע, המון דברים שגרמו לזה להיות אחלה מערכת ללמוד עליה Node.js ו-Mongo ו - Angular, אבל ממש לא בחירה-להיט למערכות Production.(רן) מבחינת חוויות משתמש . . .(ליאור) חוויית משתמש, קצת ריצודים - אבל גם מבחינת “לבנות משהו רציני”, כלומר - הרבה אנשים אמרו “אה - MEAN Stack זה כמו ה-LAMP Stack החדש”נגיד שאתה רוצה לבנות משהו ב-Ionic, איזושהי אפליקציה שתדבר עם API - אז זה לא מתאים, כי זה מפיל לך איזו חתיכת Angular מיותרת שאתה לא רוצה, ואתה רוצה רק לעשות איזשהו Client-side . . .זה היה אחד מהפרויקטים שפתח את הדלת לפרויקטי Open-source מגניבים כאלה - Boilerplate-ים כאלה שאתה מתחיל איתם בעיקר בצד של ה-Full-stack JavaScript - אבל אז באו מתוחכמים יותרהאמת היא שאחד הדברים שלמדתי זה שלנהל פרוייקט Open-source זו משרה מלאה, זה F@$&ing קשה, זה משהו טוטאלי, זה שואב אותך רגשית, אתה נכנס לענייניםזה מאוד קשה, זה כמו סטארטאפ - אתה לא יכול לעשות את זה ביחד עם להיות CTO ובעלים של חברת שירותים.(רן) וכסף עדיין אין שם, לפחות לא היה . . .(ליאור) לא היה בשלבים האלה, וזה לא . . . אפילו השחקנים שהרבה יותר ממומנים, אם נסתכל למשל על Meteor, שלכאורה היה באותה Space אבל הרבה יותר ממומן - גם הם עשו את ה-Pivot שלהם לעולם ה-GraphQLזה לא שאתה נורא ברור . . . כלי פיתוח - יש שם עסק, אבל זה לא בוננזה כלכליתרק אם אתה לוקח פרויקט Open-source ומארח אותו (Hosting) והענן, עדיין - זה מה שעובד.(רן) אז סיימת את האפיזודה הזו עם mean.io - ולאן המשכת?(ליאור) אנחנו ב-Linnovate יודעים גם לפתח דברים גם ב-Angular וגם ב-Node.js, וכל הזמן שומרים על המתח הזה…בערך בשנים האלה פיתחנו את האתר של “ישראל היום” - ו”ישראל היום” זה Drupal כמערכת לניהול תוכן, אבל עם API ב-Node.js וב-Mongo, עם אינדוקס (Indexing) החוצה ל-Elastic, אולי אחרי זה Solr קודם ואחרי זה Elastic, לא זוכר. ואלמנטים קטנים כאלה ב-Angular שמדברים עם ה-API שלך.ואז אנחנו עושים Drupal - אבל Drupal יותר יותר מתוחכםזה ממש הסימן היכר שלנו, של CMS-ים, שיש להם קומפוננטות (Components) בתוך ה-CMS שמדברות עם API קצת יותר רציניים ממה שה-CMS יודע לספקמה שקרה לנו בעקבות mean.io זה שהיה לנו את כל ה-Skill-set הזה, התחלנו לבנות דברים שונים, הרבה יותר אפליקטיביים, פחות האתר של Commtouch עם ה-MarCom הנוירוטית והדינמיקה הספציפית הזאת - ויותר עם מערכות יותר ויותר אפליקטיביות.מה שקרה זה שכשניסינו לגייס כסף ל-mean.io וקיבלנו איזה שישה “לא” בוואלי ואיזה חמישה “לא” בארץ, כשניסינו להקים את הדבר הזה, אני זוכר פגישה עם אדן שוחט מ”אלף” שאמר “איזה אחלה - יש לכם אחלה Traction ואתם נורא חמודים והכל אחלה” - ואז הוא התחיל לשאול אותי שאלות . . .כמה אנשים משתמשים בזה? וב-Command line הזה? וכמה הורדות יש לך? ומי הם האנשים? . . .הדבר הזה זרק אותי לעולם ש פתאום נכנסתי ל-Elasticsearch ברצינות כי רציתי לענות על השאלותאחרי שלושה חודשים היה לי Pie Chart של התפלגות הפקודות CLI של ה-MEAN . . .(רן) אז הנה, אדן - כתשובה לשאלה שלך: 350 . . .(ליאור) לגמרי . . . אבל הדבר הזה פתאום מקדם אותךבשלב הזה, אחרי שלא גייסנו כסף, אמרנו “Fuck it - אנחנו נבנה את זה בכל זאת” . . . - נקדם את התנועה הזאת, את mean.ioאמרנו שנבנה את ה - MEAN Network - המקום שבו אתה לוחץ על כפתור וזה עושה Hosting של האפליקציה שלך בלחיצת כפתור, זה בגדול היה הרעיון.כשזה התפתח, בשלב מסויים אמרנו רגע - איכשהו עם הדבר הזה והטכנולוגיה שבנינו, פתאום אתה בונה דברים עם Queues, אתה רוצה להתעסק עם המון מידעאז התחלנו לאסוף לוגים ולהראות את הלוגים של הבנאדם, שתראה את כל הלוגים שנכנסים, עם כל מיני משימות, לראות את הדברים שאתה מריץ - ואז אתה פתאום מגיע לבעיות של Performance ו-Scaleאז פתאום צריך להתחיל לעבוד עם Queues . . אז גם היה את הפרק כאן בכרכור, בשדות של כרכור, כשהיינו עוד חברה חמודה כזאת שבנתה דברים ב-Drupal והייתה מאוד ממוקדת ב-Drupal(אורי) אי שם ברחוב גן-עז . . .(ליאור) ופתאום אנחנו מוצאים את עצמנו בתור חברה שיש לה איזושהי סכיזופרניה כזאת - כחברת שירותים, שנותנת שירותים סביב CMS ומערכות כאלה, שיש לה שרירים, שהיא מתחילה לבנות דברים ב-microServices, נכנסת ל-DevOps, מתחילה לעבוד עם - Docker ובהמשך Kubernetes - אתה כאילו לוקח מנטליות של חברת מוצר, ומכיל אותה על חברת שירותלבנאדם שמזמין את השירות והאתר - לא מעניין אותו טסטים אוטומטיים, לא מעניין אותו CI/CD, לא מעניין אותו כלוםאבל אתה שומע את הפודקאסט ואומר - “אבל ככה בונים את זה” . . . יש כל הזמן את המתח הזה בין המוצר לחברת השירותים.אם נחזור לרגע ברקורסיה בחזרה - התחלנו לבנות דברים יותר ויותר מורכבים, ופתאום שינינו את מודל הזה של ה-MEAN Network ואמרנו שנפתח את זה - את אותו הדבר שעשינו ל-MEAN, בואו נעשה ל-WordPress ול-Drupalהקמנו סטארטאפ שקוראים לו Stacksight, לקחנו את כל התשתיות האלה שאספנו אותן . . .(רן) רגע, בוא נראה אם אני מבין: ל-WordPress יש כבר חברה שנותנת את WordPress-as-a-Service, נקראים Automattic . . .(אורי) אצלם זה ב-Hosted(ליאור) אנחנו לא התכוונו לתת את ה-Hosted . . . היה לנו Event-stream, שכל דבר שאתה לוחץ . . יותר כמו Segment או Event-based Analytics - אז כל מיני Events וכל מיני Logsלקוח שלנו, למשל חברת נת”ע - אם הבנאדם לחץ “Publish” למכרז ב-23:00 או ב-00:05, או מתי שהעורך שלך, שעובד על ה-CMS, אם הוא מעביר שעות ב-08:00 אבל מתחיל לעבוד ב-10:30 - אלו תובנות מעניינות לאנשים שעובדים על המערכות האלה . . . (אורי) אבל באמת - ברור לכולנו שכמעט מכל אפליקציה . . . במקרה שלכם מה שנותן את השירות הבסיסי זה ה-CMS, ומה שאתה אומר זה “יש לי את היכולות לתת לך מה-CMS הזה הרבה יותר” - השאלה האם זה לא קצת overwhelming בשביל הלקוחות הטיפוסיים שלכם, שאומרים “אבל רציתי רק CMS - אין לי בכלל אנשים או כוח אדם או יכולת להתמודד עם התובנות שאתה תיתן לי על מתי העורך שיושב על ה-CMS התחיל לעבוד”(ליאור) אתה נוגע בדיוק במתח שלי - זה בדיוק המתח שמתעסק עם זה שאתה מצמצם את עולם הלקוחות שלך ללקוחות מאוד מסויימים שכן אכפת להם מהדברים האלה.בכלל, כחברה, זה לקח אותנו לעוד תהליך שקרה, שדרך ה-mean.io . . . הייתה איזושהי כתבה בגוגל, אני קיבלתי טלפון או מייל כזה מגוגל שאומר “תראו, אנחנו רוצים להשתמש, בקטע של Copyrights, בלוגו של Mean“מגניב, Google, אחלה . . .תקחו, תעשו”ואז התברר שזו ממש הייתה הפלטרפורמה האולי-רביעית בענן שלל Google, שהיה לה Click-to-Deploy שאתה לוחץ ומתקין, עוד לפני למשל Ruby on Rails, יחד עם עוד אפליקציות - אז הם העלו את mean.io כי הם ראו שזה צומח ומתקדם.(רן) ב - Google Cloud?(ליאור) כן, אבל ממש ב-GCP המוקדם, לפני חמש או שש שנים.מה שקרה אז היה שהייתה כתבה ב-Geektime - “הנה הטכנולוגיה של החברה הישראלית שבחרו לשלב ב-Google” . . .ואז פנו אלינו מחיל מודיעין, מאמ”ן . . . פה התחיל (כששאלת מה אני עושה היום) “הרומן” שלי ובכלל של Linnovate עם המגזר הבטחוני.אנחנו בחמש-שש שנים האחרונות עובדים המון על החיבור שבין Open-source למגזר הבטחוני, ומסתבר שזה חיבור חזק, שמתקדם וקורה, וזה חלק מאוד משמעותי בעיסוק שלי היום.(רן) אתה אומר שזה התחיל במקרה, ככל הנראה בעקבות כתבה ב-Geektime, שבמקרה קרתה בעקבות פנייה של Google אליכם כי הם ראו הרבה Starts (ב-GitHub) או משהו כזה? . . .(אורי) החיים קורים במקרה . . .(ליאור) זה לחלוטין . . . זה עבר איזושהי רבולוציה (Revolution), היום יותר מחצי מהפעילות שלנו היא במגזר הבטחוני.אנחנו ממש מובילים בחיבור הזה שבין Open-source ו-Cloud Native ו-Kubernetes, בעבר openstack, ובחיבורים האלה, ובכלל בכלים ובתרבות הפתוחה.(רן) אם תרשה לי רגע של נוסטלגיה - אני זוכר שלפני משהו כמו 8 או 9 שנים קראו לי לגלילות (לכאורה), להרצות שם באחת היחידות (לכאורה!), ודיברתי איתם, אני לא זוכר בדיוק מה היו הנושאים, אבל אחד מהם היה Open Sourceבאו אלי בסוף ההרצאה כמה חיילים ואמרו לי “אנחנו מה-זה רוצים להטמיע כל מיני פרויקטים ב-Open Source, אבל לא יתנו לנו בחיים” . . .אז אני שואל את עצמי האם אולי מאז קרה משהו, אני לא יודע . . .(אורי) אני חושב שהייתה תפיסה בגופים הבטחוניים ש”זה לא בטוח”, ועד שנראה לי שבשלב מסויים - קודם כל מה לעשות, ה-Open source מתקדם הרבה יותר מהר היום מכל דבר אחר, והם התחילו למצוא את עצמם מאחורה, וזה הגיע כלחץ מבחוץ.נראה לי שהם פשוט גילו שהם יכולים לקחת Branches אליהם, להעביר אותם . . .(ליאור) “הלבנה” - התהליך זה הלבנה, שמעבירים אותם פנימה(אורי) כן - בדרך לוקחים את ה-Open Source הזה ו”עושים לו קולונוסקופיה” כדי לראות שהוא לא Malicious - ומאותו רגע זה שלך, תעשה עם זה . . .(ליאור) זה בדיוק מה שקרה, אבל זה הרבה יותר עמוק והרבה יותר אסטרטגי, זאת אומרת - אחרי שנים, יש מונח שנקרה System of Systems, מעיין מגדל קוביות כזה, שפעם הצורה הייתה לשים קובייה של IBM, שעליה אתה שם קובייה של Microsoft - אבל הקובייה לא יושבת בדיוק אותו הדבר, היא טיפה שמאלה . . .והיא מונחת על קובייה של Oracle, אבל הקובייה הזאת מונחת קצת שמאלה… ואתה מחבר את כל הפתרונות האלה, כשכל אחד הוא גם פתרון ורטיקלי שעושה נורא Up-sell - הוא בנוי להיות Ecosystem משלו, אבל מכל מיני סיבות הם (גופים עמומים ליד גלילות) אף פעם לא הולכים עם הכל אצל ספק אחד - והמערכות האלה לא מתכנסות והן לא עובדותלמה? כי הארכיטקטורה היא לא פתוחה - והיא לא שלהם.מה שקרה בחבר’ה שאימצו, ואני מכבד את הפרטיות שלהם (כדאי), החבר’ה שאימצו אותנו לתוך העולם הזה - הם מבינים מעולה Open-source, והם הובילו מהפכות (גם?) שם, שהובילו לכך שהיום במכרזים, ב-CDR-ים בתוך סקרים שאני משתתף בהם, ממש מופיע ש”הארכיטקטורה היא פתוחה”, היא חייבת להיות פתוחה או שאתה לא עומד בתנאי המכרז.(רן) לא במובן של “זה לא סודי” אלא במובן של משתמשים בסטנדרטים של …(ליאור) משתמשים בסטנדרטים של openstack ושל Kubernetes, בעולם שהוא air-gaped והוא מנותקזה כבר לא עניין של . . . לפני 5-6 שנים היו מלחמות של Oracle עם מול Mongo, ואח”כ של Elasticsearchהיינו ברכש של openstack, מצאנו את עצמנו מייצגים את Canonical …אה, דרך אגב, אנחנו המייצגים של Canonical בארץ . . . ושל Rancher . . . אנחנו לא כל כך מיומנים בלמכור את השירותים, אבל בגדול - היינו חלק מהרכש הזה, רשתות openstack באמ”ן ובאלתא ובעולמות כאלה.היום יש שינוי . . . זה מאוד שונה - בנאדם שהולך להתגייס, הדבר הכי טוב שהוא יכול לעשות זה להיכנס ולהיות מעורב ב-Open Sourceהיום הנתמ”ם, הקורס של ה-DevOps שלהם - הם ממש שינו את השם: פעם זה היה “נתמ”מניק”, איש QA כזה, והיום זה קורס DevOps ואנשים ברמת Linux איכותית, יוצאים משם אנשים איכותיים.מה שקרה זה שיש כאן איזושהי תת-קהילה, שהמאזינים (כנראה) לא מכירים, של Open-source בתעשיות הבטחוניותיש כנס סודי כזה - לא באמת סודי אבל לא פתוח לקהל הרחב - שרץ לדעתי משהו כמו 7-8 שנים, שהוא חלק מה-Ecosystem הפתוח הזה, שכולם באים פעם בשנה, בדרך כלל באוקטובר, יש בחור בשם עמי שלזינגר שמארגן אותו, הוא כבר בפנסיהכנס? קהילת מפתחים בארץ? Open source? באוקטובר?! . . .זה כנס שכל אחת מהיחידות מראה מה היא עושה - אלביט ואלתא והצבא - ועושים שם דברים ממש מדהימים, מראים את היכולות האלה, ואני חושב שזה מדליק את הדמיון, ואיכשהו הוא עשה משהוכל התעשיות האלו עובדות מאוד Open-source, מאוד פתוח - וזה אולי 90% ממה שאני עושה ביום-יום - במפגש הזה שבין Open-source והמגזר הבטחוני.(רן) קודם כל - יכול להיות שחלק מהמאזינים שלנו נמצאים בקהילה הזו שהזכרת . . .(אורי) אז זה יכול להיות בטוח . . . (רן) יש סיכוי כזה, כן . . . אבל אני סקרן לדעת - אתה יודע האם גופים בטחוניים נוספים בעולם אימצו Open-source באותו אופן?(ליאור) כולם - ובאגרסיביות.יש, למשל, אנחנו תיכף נדבר על Rancher, ואחד מה-Case Studies של Rancher זה שבתוך חצי שנה בערך, בצורה מאוד אגרסיבית, הם עשו כל מיני מערכות תומכותלמשל - בתוך F16 יש Kubernetes Cluster שמנהל כל מיני מטריקות . . . כשאתה חושב על זה ועובד על זה אז זה מאוד הגיוני, שבתוך בתוך F16 יש Kubernetes Cluster, אבל זה היה תהליך כדי להגיע לזה.טבעי לחלוטין למאזינים הקבועים, חדשות ישנות מ 1 באפריל 2019 - חיל האויר הישראלי עולה לענןכל התעשיות, כל העולם היום של אוטונומיה, שאני גם מתחיל להתעסק איתולמשל ב-Cloud Native Days, לא בדיוק הרברסים (הערה במקום), אבל הייתה הרצאה על ניהול, של, לדעתי jFrog אני חושב, על איך שהם עושים CI/CD ל-k3s, מעיין “Kubernetes קטן”’ לפעמים של Single board, שמותקן בתוך רכב.כל הפרויקטים האלה של KubeFlow, של AI - שאני מתעסק באיך אני רותם את היכולות של Cloud Native ושל Kubernetes לתוך העולם הזה של AI - אתה רואה אותו בעצם מתחיל להיות מופץ - ומופץ ל-Edge, ל-Devices בקצה - והתעשיות הבטחוניות לגמרי שם.נורא מעניין אותם אוטונומיה ונורא מעניין אותם אינטיליגנציה בקצה . . .(רן) והדברים האלה נותנים להם שני דברים - Robustness ו-Standardization: לא צריך עכשיו הרבה ארכיטקטורה, כי היא כבר נתונה, ולא צריך לחשוב על מה יקרה אם זה יכשל, כי זה רובסטי, באופן יחסי.(ליאור) אני חושב שיש גם אלמנט כלשהו של ענווה - פעם “אנחנו אלופי העולם, אנחנו מגלילות, אנחנו בונים דברים” (לכאורה!!), ואלביט ורפא”ל מצד אחד, כש”Everything is built here” - וברגע שאתה . . .(אורי) אין NIH . . .(ליאור) כן, ה - Not Invented Here מאוד חזקומה שקורה זה שהנחשול הזה של Open source, שאנחנו, שלושתינו, מסתכלים על זה בפרספקטיבה של 20 שנים . . .(אורי) אבל תקשיב - הבסטיליה נפלה . . .(ליאור) מזמן!(אורי) מיקרוסופט נפלה - מזמן(ליאור) היא נבנתה מחדש והמציאה את עצמה מחדש בתור “אביר ה-Open-source”.זו החברה שתורמת הכי הרבה Open-source בעולם, זו הזייה . . . אנחנו מסתכלים על זה כעל “מיקרוסופט הקדומה”, אבל זו אנקדוטה.מתי אמרתי להורים שלי שצריכים לקנות מניות של MSFT? כשפנו אלי מהמטה של Microsoft, לפני איזה חמש שנים, ואמרו “בוא נעלה לממשל זמין…” - בירושלים, לדעתי זה היה במשרד החוץ - “… נשכנע אותם לרדת מ-SharePoint ולשים Moodle”.רגע - אבל אתם Microsoft - למה שתלכו ותורידו SharePoint? . . .ביום שהם הלכו All-in על Azure, מבחינת התמריצים והעמלות של אנשי המכירות . . . תחשבו מה קורה: איש המכירות בא ואומר “יש דבר כזה שקוראים לו Azure, בואו ניקח את ה-SQL Server שלך ל-Azure!” ואתה אומר לו “לא רוצה…מה יש לי לחפש ב-Azure, עד שהכל עובד לי כאן?” . . .“אבל יש לך קרדיטים! ויש לך דברים! כדאי לך!” - “לא רוצה!” - “אז מה אתה רוצה לשים בענן?” - “אני רוצה לשים Open-Source בענן . . .”וברגע שאחד או חמישה או חמש מאות או חמשת אלפים אנשי מכירות של מיקרוסופט, המשוואה הזאת התחברה להם - אם תסתכל מה רץ היום ב-Azure, אז זה טון של Canonical ו-Ubuntu, זה הכל Open Source.ואז החברה, ברגע שהיה ההיזון החוזר הזה, שבעצם Open Source זה יותר כסף לאיש המכירות בכיס - אז אני מוכר Open Source ברבאק . . יש הרבה היגוי מלמעלה וכל הדברים האלה, אבל זה גם אלמנט מאוד משמעותי.העולם השתנה ללא היכר, הצבא והמגזר הבטחוני השתנה ללא היכר, בגלל שאתה יודע - דווקא בצבא זה קצת יותר מהיר ויש איטרציות, כי חיילים משתחררים ונכנסים פנימה חדשים עם דם חדש וקצת יותר גמישים מחשבתית.בתעשיות הבטחוניות הם קצת יותר איטיים כי יש להם הרבה יותר Legacy - יש לי אפליקציות שנמצאות 15 שנה, אבל ה-Digital Transformation של האפליקציות האלה, זה מה שאני עושה היום ב-Linnovateבוא ניקח את “המונוליט הפסיכי הזה שלך, שפרוש ואי אפשר להוציא אותו עם מנוף”, אבל בוא נראה איך אנחנו לוקחים אותו וכותבים אותו מחדש, מחלקים אותו ל-MicroServices, שמים על Docker, מחברים ל-Kubernetes . . . (רן) אז בוא נדבר באמת קצת על טכנולוגיה, הזכרנו כל כך הרבה Buzzwords . . . את Kubernetes אנחנו מכירים, “שלום-שלום”, לא ניכנס לשם, אבל הזכרת עוד כמה פרויקטים שקשורים - k3s, הזכרת את Rancher - למה אנחנו צריכים את כל זה? מה הם נותנים לנו? מה אתם עושים איתם?(ליאור) כמו שאמרנו - לגבי Kubernetes זה “שלום-שלום”, ברור לחלוטין, נדלג על השלב של להגיד למה Kubernetes זה Inevitable וזה הכל . . .(אורי) כן, אנחנו מנסים לייצר פרק אחד שבו לא מדברים על Kubernetesלא הלך . . .(ליאור) זה “ה-Linux החדש” של לפני 20 שנה . . . ב-20 שנה הבאות כנראה שזה יהיה כאן.אבל זה לא מספיק - כי כמו שיש לי RBAC, שאנחנו אוהבים לכנות אותו “הראבק” - ואז “הראבקים” האלה, אתה רוצה UI כדי לנהל אותם ולחבר אותם לתוך ה-Active Directory הארגוני . . .(רן) רק נרגיע עם הראבק - RBAC זה Role-based access control, שזו שכבת ה-Access-Control של Kubernetes.(ליאור) כן, אבל יש הרבה מעטפת כדי לחבר את ה-Kubernetes לארגון (פרק 368) - שחקן מאוד ידוע זה לדוגמא OpenShift של Red Hatזאת אומרת שאתה בעצם רוצה לקחת את ה-Kubernetes ולהנגיש אותו לארגון, אתה רוצה שיהיה פחות מפחיד.(רן) אם נלך באמת על האלגוריה הזו ל-Linux, אפשר באמת להסתכל על Kubernetes כעל ה-Kernel:סבבה, נותן לך את היכולות הבסיסיות - אבל אתה עדיין צריך UI מסביב, אתה עדיין צריך User-space(ליאור) נכון, דרך המערכת הזאת אתה בעצם מנגיש את ה-System Calls וכל הדברים האלה ש-Kubernetes יודע לעשותהמון פעמים, במנטליות של פרויקטי Open Source כאלה, Kubernetes “רוצה” להיות קטן וממוקד, הוא לא מחפש לגדול - “אני רק אייצר את ה-Ecosystem” את ה-CNCF, ואנשים ישלימו לי את החלקים של הפאזל(ליאור) אנחנו, לפני שנתיים-שלוש, כשהתחלנו להסתכל על Kubernetes, נתקלנו ב-Rancherאם נדבר על שלושה פרוייקטים מעניינים - זה Rancher, שזה בעצם אותו UI לניהול Kubernetesהאמת שלדעתי, הייתי בכנס של openstack ואמרו לי שגם לכם יש איזושהי פלטפורמה ב-Outbrain לניהול Kubernetes, נכון?(אורי) היא לניהול ה-Deployments מעל Kubernetes (פרק 386! - Kubernetes and Dyploma at Outbrain)(ליאור) אז זה בדיוק בחפיפה מאוד עם Rancher - מה ש-Rancher עושה הוא בעצם, בניגוד ל-OpenShift, מתעסק ב-Helm, עוד פרויקט CNCF, שזה כמו rpmאם דיברנו על האלגוריה שלנו - אז Helm זה rpm - יופי, יש לי Desktop, עכשיו מה אני מתקין על ה-Desktop?(רן) מנהל חבילותבדיוק - אז הם מנהלים “קטלוג אפליקציות”, שמרגע שיש לי את ה-Rancher רץ, אז אם אני רוצה אני יכול להתקין WordPress או שאני רוצה Elastic או Kibana ואני רוצה פה ואני רוצה שם . . . קליק, ואני מתקין את המערכות האלה על ה-Kubernetes.(רן) אז Rancher בעצם נותן לך UI פלוס ניהול חבילות . . .(ליאור) UI, ניהול משתמשים, בקליק אתה מעלה Prometheus שסורק לך את ה-Cluster, ובקליק אתה מחבר את זה ל-LogStash . . . כל מיני דברים כאלה, שזה מה שכל ארגון צריך לעשות - הם פישטו את זה ל”קליק”.השוני המהותי הוא שבתפיסה שלהם הם נמצאים בעולם של הרבה Clusters, כלומר עוד פעם סוג של “Monolith vs. microServices” נגיד - OpenShift זה עולם שהוא מאוד פופולארי בבנקאות וגם במגזר הבטחוני - עולם שבו יש Cluster אחד גדול ואתה עובד מול ה-Cluster הגדול.אבל כאן אומרים “תראו, אני צריך הרבה Clusters - ואני צריך להפריד בין ה-Dev וה-Stage ואני רוצה Cluster פר נושא ויש לי עשרות Clusters” . . . בתפיסה שלהם, אני רוצה ללמוד איך לנהל מאות ואלפי Clusters.הדבר הזה הוביל אותם, אם יש לי יכולת לנהל Multiple Clusters מכאן, ולעשות מה שנקרא Multi-Cluster Apps - אני עכשיו מייצר בתוך הקטלוגים שלי את ה-Helm-ים שלי, ואז אני יכול להכין אותם על גבי Cluster שונה.אם אתה עובד עם Nice, אנחנו עובדים עם Nice או אם Amdocs, שעובדים גם עם Rancher - תחשבו שאני רוצה עכשיו לעשות Cloud Certification, לבדוק את האפליקציה שלי, כי כנראה אני אפגוש OpenShift אצל לקוחות, ואני אפגוש EKS וכל ה-Kubernetes המנוהל הזה - ואני רוצה לבדוק את זה בכל הסביבות האלה.אז אני מחזיק Clusters בכל הסביבות ואני בעצם עושה Deployments של אותה אפליקציה לכל אחד מה-Clusters.(רן) לחברת מוצר אני מניח שזה יכול להיות שימושי אם באמת מחזיקים מספר Clusters, למשל Cluster פר Data-center, או אפילו מספר Clusters בכל Data-center, ואתה רוצה עכשיו לפרוש את השירות שלך, אז אתה יכול לפרוש אותו במקביל לכל ה-Clusters.(ליאור) כן, או תרחישי DR-ים כאלה . . . יש המון תרחישים מאוד הגיוניים בקטע הזה, עם המחשבה הזו של Multiple-Clusters, וזה שוני מאוד משמעותי בין Rancher והמתחרים שלה.לפני איזה שבוע Rancher נקנתה ע”י SUSE - העסקה עוד צריכה להסתיים, אבל זה עוד איזה משהו מעניין שקורה בתוך העולם הזה.מה שקורה זה שזה הוביל אותם . . . אם דיברנו על זה ש-Rancher זה בעצם ה-UI, מה שקורה היום בעולם של Kubernetes זה שיש הפצות Kubernetes - יש לי Distribution של Kubernetes, שקוראים לו RKE, שמתאים בעצם ל-On-Premise.כשאני עובד באלתא, או עם הצבא בכל מיני מקומות, ואני רוצה עכשיו להרים ממש בקלות Kubernetes Cluster, אז אני פשוט עושה Deployment דרך ה-Rancher, מריץ כמה פקודות של Docker על ה-Nodes עצמם ומקים לי Cluster נורא בקלות, בחצאי-שעות כאלה, להקים Cluster ואז להתחיל לנהל אותו, לקבל מטריקות מ-Prometheus, לשלוח את המידע החוצה . . . זה כלי מאוד חמוד.(רן) זאת אומרת - זה מיועד לסביבה שבא אתה מנותק מהאינטרנט . . .(ליאור) או בכל On-Premise . . . היום בקטע של Hybrid Cloud, אתה לא בהכרח תמיד מנותק . . . גם אצלכם ב-Outbrain יש אלמנטים שיושבים ב-Data-Center ויש אלמנטים שיושבים ב-Cloud, ובין אם זה קשור לאספקט הכלכלי או לכל מיני אספקטיםיש לדבר הזה מקום, לא צריך ללכת ל-100%, משחק סכום אפס של “אני רק בענן” או רק on-premise, וזה כלי מאוד חשוב במקום הזה.זה הוביל את Rancher לעוד שני פרויקטים נורא מעניינים - אני חושב שהשוס, ה-פרויקט הכי מעניין של Rancher, שכל הקורונה התעסקתי איתו אינטנסיבית, זה k3sרפרנס - New Tool of the Year 2019 ב-stackshareתחשבו, עוד פעם אנחנו חוזרים לאלגוריה של Linux - מה היה עם Linux, ב”אלפיים וקצת”? בהתחלה הוא היה קצת על Proxy Servers ועל Apache, בשולי ה-Data centerואז הוא נכנס ממש ל-Databases, ל-”Unbreakable Linux” כל התקופה הזו של 2005-2006אבל מה שקרה זה שהגיע MontaVista Linux - אם Linux היה רלוונטי לדברים נורא גדולים, אז פתאום זה רלוונטי לדברים קטנים.ואז הגיע Android . . .אתם רואים שבעצם Linux עלה למעלה - ואז ירד למטה, וזה בדיוק מה שקורה היוםה-MontaVista Linux של Kubernetes זה k3s, שזה בעצם (חוץ מחתיכת אלגוריה) “לקחו את Kubernetes, העיפו לה כמה מיליוני שורות קוד” או משהו כזה, לא יודע - ואת המינימום האפשרי, בהתחלה זה רץ על SQLite, בערך ב-500Mb של Footprint, זה משהו שרץ היום על Raspberry Pi . . .(רן) זה Node בודד או שזה Cluster שלם?אתה יכול לעשות Multiple-Clusters . . . אני יכול לשים ב-Show-notes צילום של ה-Cluster שלי: כשיש לך ארבעה Raspberry Pi . . . יש כאלה Boards של NVIDIA, ו-Boards חזקים, GPUs חזקים של Jetson, שאתה בונה לעצמך כל מיני Clustersתחשוב שאתה עושה Taint ו-Label ל - Jetson שלך - יכול לשבת GPU ולעשות AI על Jetson.ואת כל שאר הדברים הקטנים אתה עושה על Raspberry Piפתאום כל הדבר והמחשבה הגדולה הזאת - הכל מתנקז “לעולם הקטן”.(אורי) יכול להיות שהחזון הזה, כשאנחנו מדברים על Internet of Things - פתאום לא יהיה מצב שבו כל Thing הוא . . . כל מנורה בתאורת רחוב, אז לא רק שזו “מנורה מנוהלת”, פתאום היא בכלל Node ב-Cluster . . .(ליאור) יכול להיות . . מה שקורה זה שלקחת את הנכסים של העולם “הגדול” ושל ה-Data Centers והעננים הפסיכיים האלה שרצים נורא מהר - איך אני לוקח את זה לתוך העולם הקטן וה-Embedded.אז תחשבו על עולם של CI/CD - הרי בעבודה ב-CI/CD לא עובדים ב-Embedded . . . מה זה Embedded? אני לוקח Board ועושה Flash לתוך ה-ROM או PROM או כל מיני דברים פתאום, מרגע שעלתה קצת השכבת אבסטרקציה (Abstraction) . . . יש לי חבר שכתב פוסט על GitLab ו-Terraform ו-K3s - איך הוא עושה CI/CD של ה-Deployment של ה-Cluster . . .זה ממש מייצר מהפכה בצורה שאתה כותב Embedded(אורי) כמו שדיברנו . . . לא זוכר אם דיברנו על זה עם אורית או עם מישהו אחר שהיה פה, על ניהול Devices של Network - ב-Hardware כל ה-Network הוא Linux . . . אתה עושה Deployment ו-CI/CD על ה-Network Device(רן) אבל זה ב-Data center . . . ליאור מדבר איתך על הראוטר הביתי שלך, על הטלויזיה, המקרר . . .(ליאור) כן, זה לא משחק-סכום-אפס . . . אם אני רוצה ש”לנורה תיהיה אינטליגנציה”, ואני רוצה להריץ Kubeflow במנורה, אולי כדי שהיא תבוא ותידלק בצבע לפני הזיהוי פנים, או שהבקר של הנורה יעשה דברים יותר מתוחכמים, ואני ארצה לא לכתוב את זה Hard-coded לתוך ה-Board של המנורה, אלא להשתמש באותן אבסטרקציות ובאותם כלים שגדלו “למעלה” - היום זה אפשרי, היום זה דברים שאנחנו עושים, שוב - בעיקר במגזר הבטחוני, אבל לא רק.(אורי) נראה לי שגם . . . הרבה פעמים אנחנו שוכחים שאפשר לעשות Deployment גם בלי Container: בגלל שאנחנו רגילים לעשות Deployment של Containers אז פתאום כל דבר צריך להיות Node, צריך להריץ איזושהי Container-environment כמו Kubernetesאבל בעצם - למה זה תפס ב-Data centers? כי ה-Hardware הוא General-Purpose . . . אתה יכול לעשות על ה-Hardware, היום אתה עושה עליו אפליקציה אחת ומחר אתה עושה עליו אפליקציה שניהבמקרר - אתה צריך שהוא יקרר . . . או ברחפן - אתה צריך שהוא יעשה “אפליקציית רחפנות” . . .(ליאור) אבל בכל אחד מהדברים האלה עדיין יש לי “עוד מוח”, שמביא את הערך המוסף, התחרותי, למקרר או לרחפן.(אורי) אני מבין - אבל אתה בסוף יש עליו אפליקציה שהיא ייעודית למקרר . . .(ליאור) אבל זה גם General Purpose, כי הרחפן הזה - פעם אחת הוא עם ARM ופעם אחרת עם Board של Intel, ופעם אחרת עם כזה או כזהה-Kubernetes יצר שכבה של אבסטרקציה (Abstraction), שכל מיני דברים יכולים לרוץ עליו(אורי) זה משהו ש-JVM לא יכול ליצור?(ליאור) בגדול כן - זה נורא דומה לאבסטרקציה הזאת, אבל היתרון הוא שזה בסוף הכל אותו חארטה . . . אתה עובד בצורה שאני עובד, ואותו מפתח, שעכשיו עבד שלוש שנים ב Data Center, ה-Skill-set שלו עכשיו רלוונטי כדי לפתח גם Board כזה, כי הוא עובד בצורה מאוד דומה, מול מערכת הפעלה שהיא מאוד דומה.אז אני לא חושב שזה Bug - זה Feature . . . כשאני מסתכל על זה, תחשוב רק מבחינת היבטים של פיתוח, אתה עושה קונסולידציה (Consolidation) לצורת פיתוח מאוד דומה אבל כמובן שזה לא מתאים, ויכול להיות שזה מה שאתה מדבר עליו - החישוביות של ה-Board, מה שרץ ב-Real-time ואני לא רוצה לחטוף איזה ארבע שכבות אבסטרקציה בדרך אליו - עדיין יש לה מקוםאבל גם זה, כמו שדיברנו על העולם ההיברידי - זה Hybrid: יש לי את הבקר הספציפי שכתוב עליו קוד בצורה מסויימת, אבל כדי לאסוף את המטריקות ואת הלוגים ולשנע אותם לתוך איזשהו Elasticsearch או לתוך איזשהו Data Center שבו אני אוסף את המידע - אני אשים שם Filebeat שירוץ ב-Docker לאיזשהו LogStash שיקח את זה ל-Elasticsearch - זה כאילו כותב את עצמו, זה נורא ברור . . .(אורי) כן, אני רק אומר שאתה יודע - Deployments ו-Deployment scripting וכו’ - עשינו גם לפני שהיו Docker-ים, וכתבנו לוגים ועשינו מלא דברים וזה “כתב את עצמו” . . . Chef יכול לעשות את זה.אני רק אומר שלפעמים אנחנו שוכחים שיש פה שכבת אבסטרקציה, שזה נכון שהיא הרבה יותר “רזה” מ-Virtual Machine, אבל היא עדיין עולה משהו(רן) אני חושב שמה שליאור אומר זה שבשביל האחידות, יש מחיר - אבל גם יש יתרוןאני יכול לפשט לך את הדברים - ותחליט אם אתה רוצה את זה ומוכן לשלם את המחיר(אורי) בסדר . . .(רן) ספציפית ב-k3s המחיר הוא הרבה יותר נמוך, כי אתה יכול להריץ את זה כבר (למשל) על רחפן ועל Raspberry Pi, אז המחיר לא כזה גבוה אבל הוא קיים, הוא תמיד קיים.עכשיו תחליט איפה אתה רוצה לשלם - ויכול להיות שבאלביט או בתעשייה בטחונית אחרת הם אמרו “סבבה, אני מוכן לשם את המס הזה” של 5% או 10% או Whatever, בשביל אחידות - ולהרוויח עבור זה זמן פיתוח.(ליאור) חוק Moore עדיין לטובתינו, אתה יודע . . .(אורי) אני חושב שפשוט ה-Devices הם היום קטנים יותר ועם כוח חישוב גדול יותר(ליאור) בדיוק - ואז זה מתחיל להפוך את כל העסק הזה שם . . . מקרר עם זיהוי פנים שלפי המנח של הכתפיים ידלק באור כחול או משהו כזה ויציע לי שוקו . . .לא יודע מה הם ימציאו, אבל בטוח שבאמל”ח שמזהה אותך ובודק איזה ארבעה (רק?!) דברים לפני שהוא מתפוצץ עליך, סביר להניח שהדברים האלה ימצאו את עצמם (לכאורה, כן?)(אורי) במלחמת המפרץ הראשונה קראו לזה “פצצה חכמה” . . .(ליאור) ממש ממש חכמה(אורי) חכמה, אבל ביישנית . . .(ליאור) אז עכשיו הפצצות יתחילו לפתח תודעה, ויתחילו פצצות פציפיסטיות ו . . .(אורי) כן, ביישנית - הלכה והתפוצצה בצד . . .(רן) פצצה-netes? שמעתם את זה פה . . . (לפחות עד שהצנזורה תמחוק . . .)(ליאור) אני חושב ש . . . דיברנו על Rancher ועל RKE, על ההפצה שלו שהוא משתמש בה כדי לנהל את ה-Hybrid Cloud, ודיברנו על ה-k3s, שזה פרויקט מרתק לדעתי המון מהאוטונומיה - רכבים אוטונומיים, אתם תמצאו את זה הרבה מאוד בתוך העולם הזה, הוא צמח והוא מאוד פופלרי ומאוד מגניבעוד פרויקט אולי אחרון מתוך הבית הזה של Rancher שאולי כדאי להסתכל עליו - קוראים לו Longhornלא זהכלומר - כל ה-Theme של Rancher זה חוואים, מתוך ה-Pets vs. Cattle - זה התפתח שם בקטע זה של “אנחנו בשוורים, אני מתייחס לכל השרתים כמו אל בקר” - אז כל השמות של Rancher זה סביב העולם הזה.ו-Longhorn זה בעצם (כזה אבל גם) Distributed Storage, סטייל OpenEBSאני עכשיו משתמש, אני חושב שזה StatefulSets של Kubernetes, כדי לנהל את מה שפעם היינו עושים ב-GlusterFS, אז אני עכשיו בעצם מפזר את כל אחד מה-Nodes ב-Cluster שלי, מקצה את הדיסק שלו - וכולם “בשותף” בעצם מספקים את זהזה נורא נוח לטפל ב-Persistent Volumes issue . . .(רן) קצת Hadoop כזה, אבל מחדש . . .(ליאור ) כן - הכל אותו חארטה . . . אנחנו בלופ . . .(רן) אני בטוח שגם בשנות השישים הייתה גרסא של זה איפשהו . . .(ליאור) אז Longhorn הוא נורא נוח בזה שאני, בכמה קליקים דרך Rancher, עושה שני קליקים ופתאום יש לי פתרון ל-Persistent Storage, שנותן לי בעצם את ה-PV ב-Cluster ומנהל את ה . . (רן) אבל מה זה? Block Device? איך זה נראה?(ליאור) זה Block Device . . . אתה יודע, יש פרוייקטים נוספים כמו Min.io ועוד דברים לטפל ב-Object Storage, או Ceph, אבל הדבר הזה מתעסק עם Block Device, הוא נותן מענה ל-Block Devices בתוך המרחב הזה - הוא נורא נוח.עכשיו, תחשוב על זה שאני עכשיו לקחתי “להק רחפנים” שרוצים עכשיו איכשהו לסנכרן איזשהו File System, ויש לי איזה 50 רחפנים בלהק כזה - והם אשכרה מחזיקים File System ביניהם, דרך ה-Connectivity שלהם - זה בעצם הטכנולוגיות שיקחו אותנו לשם.מעל מה מרחף להק הרחפנים הזה? . . . לא חשוב.(רן) אנחנו כבר ממש לקראת סוף הזמן (זה רק קורונה, זה יעבור…), הייתה שיחה ממש מעניינת - יש עוד נושא שרצית להזכיר לפני שאנחנו נסיים?(אורי) איפה אתם משתלבים בסקריפט של הסדרה טהרן?(ליאור) אהה . . . אנחנו בעיקר צופים . . . זה הלקוחות שלנו שעושים את הדברים האלה (לכאורה).(אורי) נשאיר למאזינים את הדמיון שלהם(ליאור) אנחנו . . . כל דבר בתוך המפגש הזה, בין Kubernetes . . . אני אעשה עכשיו תרגיל מסויים בהיפנוזה - תחזרו אחרי: “קיסוס Kubernetes, קיסוס Kubernetes” . . . זה ה Key word.רק להיזהר על ראש ממשלת מלזיה.כל דבר שקשור ל-Cloud Native, לKubernetes, לOpen Source, כמובן במפגש עם הנושאים האלה של המגזר הבטחוניוגם במערכות האלה, כש-CMS צריך הרבה יותר אינטליגנציה ואיזשהו קומפוננט (Component) בפנים כדי לעשות דברים הרבה יותר מורכבים - דברו איתי, אנחנו נשמח לעזור.בפרק אחר אני כבר אספר על כל ה-Open source שיצרו מאז . . .(רן) מעולה, יופי, שוב תודה שבאת ליאור - ותבוא שוב!ועוד קצת תוספות לגרסת הבמאי - Rancher Israel community at Whatsapp - https://chat.whatsapp.com/FBHr4Bvvl4x3a39Q7W3jpILinnovate kubernetes support service - https://k8support.comNice intro for Rancher in CNCF Meetup - about managing fear (and k8s clusters ) with Rancherhttps://youtu.be/7HNdNpkUw7cהקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

Sean Pillot de Chenecey interviews Ramon Vullings, author of ‘Not Invented Here'. A cross-industry expert and ‘Idea DJ', Ramon shares how he helps leaders with strategies, tools and skills to look beyond the borders of their domain, to transform their business in a smarter way. Included: Ramon's current book Innovating events Innovation to stay ahead Ramon's book: http://www.crossindustryinnovation.com/ Book Ramon to speak: http://bit.ly/Ramon-Vullings Book Sean to speak: http://bit.ly/SeanPdeC

Sponsors Sentry– use the code “devchat” for $100 credit Netlify TripleByte Panel Justin Bennett Thomas Aylott Dave Ceddia Notes Today’s show has the panel discussing image lazy loading in React. Image lazy loading is the notion that images that are below the fold (rendered outside of your browser view when you initially load a page) are deferred and loaded later, so that your page loads faster. As you scroll down the page and things get close, then they are loaded in. This is a commonly suggested performance optimization, but often it doesn’t work well in React. The panelists talk about their experiences with lazy loading and different methods they’ve seen on other sites. They discuss the tradeoff between having a lot of images and slower loading and the importance of communicating with the design team. Since lazy loading is a unique challenge in React, they give recommendations for implementing lazy loading and tools for tracking site usage. They talk about dealing with JavaScript payloads, bundle and load splitting, and automating performance tracking. They discuss different performance tracking tools. The panelists address the NIH bias (Not Invented Here) and the trend that designers tend to be willing to pay money for good tooling, while engineers are cheap. There have been great improvements in the marketplace for good tools, so much so that oftentimes buying the tools is cheaper than making them yourself. They finish by discussing the pros and cons of building vs. buying and the future of the frontend. Links Lighthouse Gatsby Above the fold optimizations Below the fold optimizations Crump Survive JS on Webpack React lazy load image component Calibre SpeedCurve Bundle Analyzer Inspect Pack by Formidable Labs Cypress Github Actions Follow DevChat on Facebook and Twitter Picks Justin Bennett: Netlify Dev Products Easy Peasy Thomas Aylott: Displaced: Stories from the Syrian Diaspora React Rewind Dave Ceddia: Notion Understanding By Design

Sponsors Sentry– use the code “devchat” for $100 credit Netlify TripleByte Panel Justin Bennett Thomas Aylott Dave Ceddia Notes Today’s show has the panel discussing image lazy loading in React. Image lazy loading is the notion that images that are below the fold (rendered outside of your browser view when you initially load a page) are deferred and loaded later, so that your page loads faster. As you scroll down the page and things get close, then they are loaded in. This is a commonly suggested performance optimization, but often it doesn’t work well in React. The panelists talk about their experiences with lazy loading and different methods they’ve seen on other sites. They discuss the tradeoff between having a lot of images and slower loading and the importance of communicating with the design team. Since lazy loading is a unique challenge in React, they give recommendations for implementing lazy loading and tools for tracking site usage. They talk about dealing with JavaScript payloads, bundle and load splitting, and automating performance tracking. They discuss different performance tracking tools. The panelists address the NIH bias (Not Invented Here) and the trend that designers tend to be willing to pay money for good tooling, while engineers are cheap. There have been great improvements in the marketplace for good tools, so much so that oftentimes buying the tools is cheaper than making them yourself. They finish by discussing the pros and cons of building vs. buying and the future of the frontend. Links Lighthouse Gatsby Above the fold optimizations Below the fold optimizations Crump Survive JS on Webpack React lazy load image component Calibre SpeedCurve Bundle Analyzer Inspect Pack by Formidable Labs Cypress Github Actions Follow DevChat on Facebook and Twitter Picks Justin Bennett: Netlify Dev Products Easy Peasy Thomas Aylott: Displaced: Stories from the Syrian Diaspora React Rewind Dave Ceddia: Notion Understanding By Design

Where we discuss Not Invented Here, or the tendency in technology companies to needlessly reinvent the wheel. Comments for the episode are welcome - at the bottom of the show notes for the episode there is a Disqus setup, or you can email us at feedback@operations.fm Links for Episode 67: NetDisco C10K Problem

Этот выпуск в YouTubeПосле некоторого перерыва Дима и Вячеслава обсуждают недавние события, правила работы со "срочными" запросами и сложности использования продвинутого английского.* Giveaway "Deep Work" успешно завершен* Диме очень не нравится слово "собственник" и разговоры, в которых оно возникает* Недавно прошел 3PM Uncon* Что делать в ситуации, когда поступает входящий звонок, а человек уже находится в процессе взаимодействия с клиентом или другим человеком* Сложности в профессиональной коммуникации из-за слишком advanced English: "This is not a drop-in replacement"* Вячеслав попрекает Диму тем, что он забросил свой подкаст Not Invented Here* Мотивация: pull против push

How To Kill Off Organisational Silos   Every organisation suffers from the Not Invented Here syndrome.  This is where collaboration is dismisseD in favour of independence, even when it is a cost to the business.  Sections or divisions within the body of the organisation do not cooperate and form a united front to win in the market, because of rivalry, stupidity, egos, history, politics etc.  The cost of all of this hairy chested independence is high.    Gaining collaboration from other parts of the organisation is the mark of the superior leader.  The good news is that we don't have to work this out for ourselves.  There is a nine step method we can follow to make sure 1 + 1 = 5 rather than 2.   Goal Defintion What is the issue exactly? What is the central goal we wish to achieve through this collaboration?  How will this increase the competitiveness of our team against the rival companies' team?  We need to define what success lookS like at the start.   Building A Case Opinions are cheap and everybody has one.  We need to come armed to the teeth with facts and data to be persuasive.  We need to gather all the relevant facts about the current situation, so that we can clearly articulate the starting point and also elaborate what the finish line will look like.   Define The Issue Clearly We know where we are now, having gathered the data.  We know where we need to be, to win in the market.  Why aren't we there already?  What is lacking or missing or insufficient?  How will this work?  Who needs to do what for all the moving pieces to line up for success?   Request Help Strong individuals are often driven to do things independently because they want to claim all the glory at the end.  Too many “I Did It My way” sessions at the karaoke for these types.  The greater good, the bigger picture, has to be the focus. Winning as a total team rather than as individuals, requires humility enough to ask others for help.  When asking, the request needs to be very detailed and specific, so that the assisting party knows what resources will be required and how much time burden will be involved.   The Art Of The Possible The initiating group has to be able to accept other thoughts and means of achieving the end, rather than being locked into what they think should happen.  The “how” part needs to draw on ideas from all parties and be reformulated so that the sense of ownership is as widespread as possible.   Collaboration In Action Brainstorming together as a reality is now taken to the entire group, so that everyone has input. If the correct method is being used, then fast thinkers, slower thinkers, deeper thinkers will all be tapped for their ideas.  The ideas initially generated won't be judged at the generation stage, as that will be left to later in the brainstorming.   Implementation Ideas are cheap. Action is what creates value and now the ideas created have to be acted upon.  As we don't know what will work and won't work, we are constantly testing progress to make sure we are on the right track.  We don't want to commit too many resources, too early to discover our plan cannot work.  We keep pushing forward through the milestones to make sure this is the right thing to continue doing.   Follow-Up We need to keep everyone on board, so we need regular check-ins on progress to make sure the time and resource commitment is being honoured.  We don't allow people to drift and drop out, because we are carefully monitoring the milestones we have set.  Accountability Is a big part of success and this is where the leader needs to apply maximum scrutiny and pressure.   Evaluation How were the results? Did we achieve what we intended to achieve.  What things emerged that we had not counted on?  Did we make the targets we had set for ourselves?  Did our activities throw up new opportunities we hadn't thought about or did it close off possibilities which were once considered valuable?  Did we adopt an attitude of there is no failure only learning?   Getting different groups to cooperate is always a struggle.  The bigger struggle is to try and do it without a solid mechanism to make sure it works.  We usually try and build the plane in the air, rather than having a solid blueprint before we touch any materials or tools.  This nine step process is the blueprint. When followed it will absolutely guarantee we will do a better job, than if we were left to our own devices, to work it by ourselves.

Show Notes: https://justinfimlaid.com/not-invented-here-syndrome-for-security Sponsor: https://www.nuharborsecurity.com Contact Me: https://justinfimlaid.com/contact-me/ Twitter: @justinfimlaid LinkedIn: https://www.linkedin.com/in/jfimlaid/ Have you ever had an idea to advance your company or another companies security posture?  And it's a really good idea.  Like really good.  You do you your homework and dot the "I's" and cross the "T's" and your propose a superior solution that sets your organization up for, what you think, is long term success?  When you propose your idea, someone passionately proposes an alternative weaker solution.  Or worse, people take shots at your idea trying to make it look like swiss cheese for the apparent purpose of making an alternate idea better? If yes, you might have seen and experienced the "Not Invented Here Syndrome". One of the more concise definitions of Not Invented Here Syndrome (NIHS) I've heard come from Techopedia: "Not invented here syndrome is a mindset or corporate culture that favors internally-developed products over externally-developed products, even when the external solution is superior. NIHS is frequently used in the context of software development, where a programmer will overlook all the attributes of an existing solution simply because it wasn't produced in-house." Another variant to NIHS is the micro variation comes when the security department or CISO is accountable for security but doesn't have responsibility for security.  So if you are security professional recommending products/solutions that are always "shot down" by those with budget authority there could be a few reasons and Not Invented Here might be the cause.  NIHS can take a couple forms (this list adapted from Techopedia): The other teams don't value the work of others.  They have pride in a negative way.They don't understand or unwilling to try to understand the benefits and lack confidence.Fear that their previous ideas aren't valued.Territorial battles, e.g. internal "turf wars".Fear of having to learn something new.Wanting to control the process.  Would rather "reinvent the wheel" to maintain control.Jealousy that they didn't think of the idea first.Belief that they can do a better job.The other teams don't value the work of others and believe they can do better.  They have pride in a positive way. There's always the counter argument that the Security team always makes sub-tier recommendations and IT rather keeps the proverbial security train on the tracks. Anyway, NIHS is a real thing and can really be barrier to completing an annual plan.  For organizations that don't foster innovation NIHS can really be present in the way the company operates day to day.  There's some great articles on Not Invented Here and how some of the worlds longest standing companies foster innovation and work with external ideas to make their business grow. Some interesting links you might check out... https://hbswk.hbs.edu/item/the-benefits-of-not-invented-here https://www.forbes.com/sites/haroldsirkin/2017/03/09/not-invented-here-not-at-the-most-innovative-companies/#1d85172c1e35

Show Notes: https://justinfimlaid.com/1-thing-i've-learned-about-successful-security-leaders/ Sponsor: https://www.nuharborsecurity.com Contact Me: https://justinfimlaid.com/contact-me/ Twitter: @justinfimlaid LinkedIn: https://www.linkedin.com/in/jfimlaid/ I traveled to 7 cities this week.  It was a little intense to say the least.  Luckily I had some awesome company with me which made the trip a little easier. While in Austin I was listening to the cover band the Spazmatics and I was talking to a friend about the Pwned Podcast.  We were kicking around ideas for content, so out of Austin Texas, this weeks question - what is single commonality I see amongst successful security leaders. One commonality I see among successful security leaders. It's their ability to build relationships within a security organization.  They are able to get their peers and other folks in the organization to pick up the security gauntlet to enable the security program.  They are also able to get their organizational cohorts to self select the correct security decisions when no one else is looking.  I was pretty fortunate early in my career that someone much smarter than me taught me about the "Not invented here" stance by many people.  The idea of Not Invented Here is someone's general resistance to an idea because it wasn't their own, and they no matter what believe their ideas are better.  From Wikipedia "The reasons for not wanting to use the work of others are varied, but some can include a desire to support a local economy instead of paying royalties to a foreign license-holder, fear of patent infringement, lack of understanding of the foreign work, an unwillingness to acknowledge or value the work of others,jealousy, or forming part of a wider turf war. As a social phenomenon, this philosophy can manifest as an unwillingness to adopt an idea or product because it originates from [somewhere else]." From What I learned from this is sometimes arguing with someone who has this not invented here stance matters less because it's while you may win the argument now, that same person will try to prove in the long term while you were wrong and look to sabotage, perhaps indirectly, your success. I digress a little bit, but my point is that successful relationship builders can see the bigger picture don't get meyered down in petty arguments of singular facts.  Rather concensus, and doing things together as a team, is the most important thing. As I look back over my career, I can clearly connect some realtionship dots.  One thing I always did was take care of the vendors who took the time to visit me.  See when I was a CISO, I lived in northern VT, and get anyone to leave Boston to make a 3 hour drive was amazing.  Now, I wasn't always a buyer, but One thing I would always do is make it worth their drive by taking them out to dinner, spending time with people, learning about their personal life.  Nothing lasts forever - and when I left my job, it was those vendor realtionships that helped me start NuHarbor Security. Now I'm on the Vendor side, I realized the Vendor community is a WAY WAY bigger network than security professionals who perform security within a company.  The vendor network is big and they talk to everyone.  They're an amazing network to draw on if you ever needed help.  I often see security professionals treat the vendor community fairly harsh, and vise versa.  But really, we're all fighting the same battle and we have a lot of commonalities.  If we accept that we're better together. So my answer this week to what is a single commonality I see amongst successful security leaders.  It's their ability to build long-term relationships with internal cohorts as well as develop external partnerships with outside organizations.  These are the individuals I see excel in the their carrer.

Jack Naneek tackles failure and criticism, pointing out that it’s usually the source of the our greatest learning.  More important, however, is the stepping back to decide whether any criticism from the outside is even worth considering.  A Research and Development Department for the Church is suggested.  In the end, we realize Joseph Smith just […] The post Mormon Awakenings: Episode 019: Not Invented Here! appeared first on Mormon Awakenings.

#15: Not Invented Here #34: Promises … in Objective-C Soroush's OAuth Signature Generator BAKMultipartRequestBuilder Michael Jurewitz: “You never go full Brichter” Letterpress: Word Game Will Shipley: My “Doom” 20th Anniversary Stories

This week, Chris and Soroush discuss Soroush's latest project, which among other things involves porting his Swift Promises library to Objective-C. Soroush's Swift promise library Gist of Soroush's Objective-C promise library Fucking Block Syntax Episode 4: Promises Episode 15: Not Invented Here BAPromise CocoaPods, Carthage Bitcode Android Support Library Tiny Swift Idioms in Objective-C We didn't discuss this in the episode, but it's relevant: One Weird Trick to Lose Size

Everyone is guilty of this at one time or another, even me sometimes... Getting too carried away and biting off more than you can chew... Filling up the "to-do list" (yuck) with way too much "stuff" Then, it's a huge distraction and that big long list becomes a thing you're scared to look at, or maybe even you feel bad when you do... I can also relate to my mindset ten years ago when even five minutes of money-making activities per day seemed like "too much work" for me... Send a quick email in the morning? I can't do that every day... People tell me to blog or post a daily video? How will I have time for anything else? "Forget about a daily podcast..." I expected myself to post once a day for maybe 4-5 days and then quit! Sound familiar? Of course it does... don't pretend it doesn't! So what changed? This... Insight #1: Exterminate "Not-Invented-Here" Syndrome and Used the Right Tools Don't invent from scratch if you can help it. In this day and age, you don't need to know HTML, CSS, how to edit graphics and upload files. Just use WordPress, grab whatever beautiful theme you want to use for your design (most look like you paid thousands of dollars), and you can grab whatever plugins you want to add pop-ups, social share links, and so on. Just grab what gets it done now instead of delaying yourself months or even years for no reason... Insight #2: Stop Switching Gears and "Chunk" Instead Speaking of WordPress, use its scheduling feature. Scheduling is one of the few hidden "Easter eggs" hidden in WordPress and I'm constantly amazed at how few people know that this is a thing... Here's how it works: let's say you create a WordPress blog and you decide that once per day, you want to post a new video reviewing the latest iPhone or Android app... That's a huge time commitment. Literally every day, you're going to have to login and research that latest app. There's no guarantee that you'll find something good. Maybe you won't be motivated that day. Maybe you'll have something better to do or a huge emergency will come up and stop you... And then... you might miss a day, two days, a week, and then think to yourself... it's been three months since I posted a video about the latest app. It wasn't a priority then, so why should it be a priority now? Posting one or two videos didn't seem to get me much traction, and maybe if I'd posted 50 to 100 videos I'd see real results, but who has that sort of patience? Solution: Schedule several posts every time. With WordPress, you can add a new "post" (journal entry) and Publish it, or set it to go live instantly. Or, you can change the date to go live tomorrow, in a week, or two weeks. WordPress has built-in drip content (just set the date and time of your posts into the future) without any special plugins. Just imagine, on a Monday, grabbing five YouTube videos from various sources reviewing the latest apps (with your link at the bottom) and you'll set those posts to go live on Tuesday morning, Wednesday, Thursday, Friday. Or, how about this: on April 1st, schedule two weekly posts in advance. That means that on April 1st, you just scheduled posts on your blog for April 1st and April 8th... Then, on April 8th, you already had that day scheduled. You schedule your two videos to go live on April 15th and April 22nd... Keep this up for 10 weeks (three to five minutes per day) and by June 3rd, you're already scheduled ahead to mid-August. And by August, you're scheduled ahead until the following year. Just by posting more than what you need, the website (WordPress) will work on autopilot for you, even after you've put it out of your mind. Constantly switching gears and putting out fires is a MASSIVE time waster. Avoid it by chunking up your tasks and scheduling things out on autopilot for many weeks to come. Insight #3: Imagine a Clear CONCRETE Vision of What the Future LOOKS Like It sounds super hokey, but most self-help (Napoleon Hill type of stuff) revolves around you usin...

Simple Made Easy by Rich Hickey “Rich Hickey emphasizes simplicity's virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path.” Talk Transcript, with slides Fatal Error episode 7: The Single Responsibility Principle Fatal Error episode 15: Not Invented Here Some examples we mention: Object-Relational Mapping vs Key-value Database CocoaPods vs. Carthage Slides mentioned in this post: Development Speed Simplicity Made Easy

Get a new Fatal Error episode every week by becoming a Patreon supporter!Caleb and Sam from Runtime join Chris and Soroush to talk about "Not Invented Here" and how we approach project dependencies.Wikipedia: Not Invented Heresoffes/mixpanel: Sam's Unofficial Swift Mixpanel clientNPM's Left PadCocoaPods: Quality IndexesSwift Package ManagerFloat LabelGithubGif of the animationantitypical/Resultjonkykong/SideMenuSVProgressHUDYour hosts:Sam on TwitterCaleb on TwitterChris on TwitterSoroush on Twitter

This week we are joined by Soroush Khanlou and Chris Dzombak of "Fatal Error" to talk about "Not Invented Here" and how we approach project dependencies. Get in touch with us in the Spec Slack or on Twitter at @runtimefm. Links Soroush on Twitter Chris on Twitter Fatal Error Not Invented Here

Har du nu opfundet den dybe tallerken igen? Så er du måske ramt af Ikke-Opfundet-Her syndromet… eller “Not Invented Here”, som det hedder på engelsk. Rigtig mange tror at de opfinder noget nyt, men i rigtig mange tilfælde er det allerede opfundet. Så hvorfor forsøge at opfinde noget nyt? Hvorfor ikke bare kopiere andre? Picasso […]

　前回に引き続き、イノベーションを追求する組織のコミュニケーションに関連するキーワードを取り上げます。今回は、NIHシンドローム（症候群）です。 　NIHといっても、アメリカの国立衛生研究所ではありません。これは、Not Invented Here、「ここで発明されたものではない」という英語の頭文字をとった語です。研究開発プロジェクトのメンバーが、長期に亘って固定されると、プロジェクトの外部から得られるアイデアが採用されなくなる傾向を意味しています。 　このような現象は、ラルフ・カッツとトーマス・アレンという2人の研究者が1982年に発表した論文で指摘しました。彼らは、ある企業の研究開発組織に所属する研究者から得られたデータを分析した結果、このような現象を示すとともに、それに伴ってプロジェクトの業績が低下するという傾向も指摘しています。彼らによれば、メンバーの在職年数が２〜4年のときにプロジェクトの業績は最も高くなり、5年を過ぎると低下するというのです。 　実は、この論文で行われている分析の手続きには、いくつか腑に落ちない点があるのですが、プロジェクトのメンバーが固定されることに伴う弊害の指摘には、直観的な分かり易さがある所為か、NIHシンドロームという語は、その後、自前主義を意味するものとして広まっていきました。 　実際、プロジェクトのメンバーが長い間変わらないと、自前主義に陥ると言われてみれば、誰でも思い当たるところがあるのではないでしょうか。プロジェクトの初期段階では、まだメンバーがどのような知識を持っているのかが互いに分かっていないため、外部情報源から得られる情報やアイデアが活用されるでしょう。しかし、時間が経つにつれてチームワークが強化されてくると、メンバーは組織内部で互いに知識を補い合い、協力的に仕事を進めるようになります。この傾向が行き過ぎると、必要な知識は組織内部に全て保有されているかのような思い込みが生じ、外部情報源への接触を怠るようになるわけです。 　ただ、問題は自前主義そのものにあるのではなく、それがプロジェクトの業績を低下させるという点にあります。組織の業績が４〜５年をピークとして、それ以後低下するという傾向は、既に1960年代にドナルド・ペルツとフランク・アンドリュースが行った研究の中でも指摘されていました。 　こういう傾向が、避けられないものであるならば、プロジェクトのメンバーを定期的に組み換えることが、イノベーション・マネジメントにとっての課題となります。 今回のまとめ：NIHシンドロームとは、研究開発プロジェクトのメンバーが長期的に固定されると、外部情報源からの情報やアイデアが採用されなくなり、プロジェクトの業績が低下する傾向を意味しています。

One of the best places to find fresh ideas could very well be completely outside of your current industry and commonly used resources. Cross-industry innovation is a way to create what is next and separate yourself from what is.  Ramon Vullings is an inspirational speaker, a cross-industry innovation expert, author and ideaDJ. He believes that there are positive alternatives to the way we interact and how we shape our businesses for the better.  Ramon is the author of Creativity in Business and Not Invented Here, a way to jump-start your innovation efforts by going beyond the borders of your industry. 

This episode includes discussions on peer feedback, the “Skill and the Will”, Alan’s favorite author, Steven Johnson, Not-Invented-Here, and learning organizations. --- Support this podcast: https://anchor.fm/abtesting/support

This episode includes discussions on peer feedback, the “Skill and the Will”, Alan’s favorite author, Steven Johnson, Not-Invented-Here, and learning organizations.