https://www.linkedin.com/pulse/containers-future-ian-eyberg/
That's when I realized that there has been an entire generation of software engineers that have grown up on this madness. Imagine if you were 22 or 23 back in 2013 (that's only 7 years ago) but in a world of software that's practically a lifetime. Hell that's long enough to graduate from college and earn your "senior engineer" spurs. You could've spent all of your 20s only deploying containers and not knowing any other methods even existed. Case in point - the term "ingress" is used in the k8s community as if it's some sort of product category and lo-and-behold nginx is used as a main component. Go figure. You'll see people asking questions like "What would you use for ingress?". What they are basically asking is how would you configure nginx as a reverse proxy.
That's when I realized that there has been an entire generation of software engineers that have grown up on this madness. Imagine if you were 22 or 23 back in 2013 (that's only 7 years ago) but in a world of software that's practically a lifetime. Hell that's long enough to graduate from college and earn your "senior engineer" spurs. You could've spent all of your 20s only deploying containers and not knowing any other methods even existed. Case in point - the term "ingress" is used in the k8s community as if it's some sort of product category and lo-and-behold nginx is used as a main component. Go figure. You'll see people asking questions like "What would you use for ingress?". What they are basically asking is how would you configure nginx as a reverse proxy.
Linkedin
Containers are Not the Future
I saw this tweet the other day and it prompted me to start arranging some more thoughts on the subject - putting pen to paper so to speak. As I'll touch below you don't see engineers making statements like this that often in public as the container crowd…
И ещё оттуда же:
A very interesting paradox going on is that a lot of kubernetes users are learning/deploying kubernetes clusters via "resume-driven development" and VPs of engineering and other leaders are letting them so that they can retain them and do what is already a very hard job to do - hire engineers.
Directors and VPs and other leaders are effectively throwing them a bone to keep them employed at their companies - not necessarily for technical/cost benefits. Many people in positions of management have privately admitted this.
A very interesting paradox going on is that a lot of kubernetes users are learning/deploying kubernetes clusters via "resume-driven development" and VPs of engineering and other leaders are letting them so that they can retain them and do what is already a very hard job to do - hire engineers.
Directors and VPs and other leaders are effectively throwing them a bone to keep them employed at their companies - not necessarily for technical/cost benefits. Many people in positions of management have privately admitted this.
Главный элемент в работе разработчика — это прогресс. Нужно обязательно выдавать хоть какой-то результат работы, который бы ощутимо приближал к поставленной цели. Если человек не может раз, скажем, в месяц или два выдавать результат, то его работу очень сложно оценить и поэтому доверие к нему со стороны менеджмента будет падать. Нельзя жить в коконе, а телепатия не работает — менеджер не может, не хочет и не имеет возможности вникать в самую суть программерской работы. Разработчик обязательно должен уметь рассказывать, чем именно он занимается, как далеко продвинулся и продемонстрировать это. Менеджеры — не телепаты.
Не понимаю, почему люди так псят на КриптоПро CSP — это качественный отечественный продукт с отличной поддержкой и документацией. Это не распильно-откатный проект, он действительно работает.
http://maximilyahov.ru/blog/all/je-suis-krasavchik/
Когда человек откликается на вакансию, он ошибочно думает так: «Я должен показать, какой я крутой. Чем более крутым я себя покажу, тем больше вероятность, что меня наймут».
Это заблуждение по двум причинам.
Дальше по ссылке, очень толковый текст.
Когда человек откликается на вакансию, он ошибочно думает так: «Я должен показать, какой я крутой. Чем более крутым я себя покажу, тем больше вероятность, что меня наймут».
Это заблуждение по двум причинам.
Дальше по ссылке, очень толковый текст.
maximilyahov.ru
Я красавчик
Когда человек откликается на вакансию, он ошибочно думает так: «Я должен показать, какой я крутой. Чем более крутым я себя покажу, тем больше вероятность
Не могу до сих пор отделаться от стойкого убеждения, что философия — это в целом bullshit. Там есть отдельные прикладные направления, но в остальном — это замкнутое на самое себя словоблудие, разбитое на враждующие между собой кластеры.
У прокрастинации есть один плюс: завершённое дело вызывает небывалый кайф, нормальным людям не понять.
У книг с большим количеством иллюстраций есть одна огромная проблема: картинки и текст, который их использует, находятся на разных страницах. Это вроде бы мелочь, но когда иллюстраций несколько сотен и они все важные, необходимость скроллить туда-сюда начинает в итоге выбешивать.
И вроде совсем базовое правило оформления книг, а всё равно на эти грабли авторы продолжают наступать.
И вроде совсем базовое правило оформления книг, а всё равно на эти грабли авторы продолжают наступать.
Среди айтишников существует популярная идея, что «заказная» и «продуктовая» разработка фундаментально различаются, что люди, привыкшие к одной из систем, не могут работать в другой. И это очень печально, поскольку фундаментально разницы там особо нет. А неспособность людей работать в другой области проистекает от бардака, царящего в продуктовой разработке.
Да-да, дети, в заказной разработке порядка в целом больше. Человек, привыкший к чётким форумлировкам, ТЗ и системе контроля качества, не хочет работать в продуктовом хаосе. И наоборот, привыкший работать в мутных водах продуктовой разработки, не может приспособиться к «адской бюрократии» в заказной.
А вот если в продуктовой среде всё чётко: ТЗ, архитектура, контроль качества, стейкхолдеры и отчёты, то миграция происходит легко и безболезненно.
Да-да, дети, в заказной разработке порядка в целом больше. Человек, привыкший к чётким форумлировкам, ТЗ и системе контроля качества, не хочет работать в продуктовом хаосе. И наоборот, привыкший работать в мутных водах продуктовой разработки, не может приспособиться к «адской бюрократии» в заказной.
А вот если в продуктовой среде всё чётко: ТЗ, архитектура, контроль качества, стейкхолдеры и отчёты, то миграция происходит легко и безболезненно.
Любят программисты аналогии. А ещё они любят считать себя инженерами, а программы — результатом работы. И вот тут возникает нежданчик: Что является результатом работы «настоящего» инженера? Некий физический продукт, скажем, автомобиль или дом, или мост. Не абстрактный, а совершенно конкретный с конкретным серийным номером, адресом и географическими координатами. И с этим вроде бы все согласны и это вроде бы очевидно: сначала идёт проектирование, затем конструирование (то есть сборка, производство), контроль качества и приём в эксплуатацию.
У ненастоящих же инженеров названия некоторых из этих этапов притащены в их предметную область и они даже любят рассказывать о проектировании софта, разработке и приёме в эксплуатацию. Вот только процентный баланс в этих этапах кардинально иной.
К примеру, производство физического объекта занимает существенное время и требует существенных ресурсов; аналог же производства в программировании — это вовсе не написание кода, как многие считают! Производство программы — это компиляция и сборка! При этом результат компиляции — это ещё не финальный результат работы, а лишь артефакт для этапов тестирования и внедрения. И вот уже результат внедрения в виде конкретной работающей программы/системы на конкретном компьютере — вот это настоящий результат.
А что же такое проектирование и написание кода? А оба этих этапа мапятся на один — проектирование физического объекта. При этом исходный код — это по сути детальная документация по созданию программы, по этой документации другие системы (компилятор и система сборки) изготавливают бинарные файлы.
В итоге получаем такое. Для физических объектов на стадии проектирование—производство—тестирование—внедрение тратится примерно одинаковое время (скажем, по 25% для простоты), при этом на производство ещё и физические ресурсы уходят. А для программных объектов на этап проектирования уходит 70%, 1% на производство (=компиляция и сборка) и 20% на тестирование и 9% на внедрение.
Именно дешевизна производства (по сути просто копирование байтов) и является действующим фактором т.н. «софтварного пиратства». Производство софтварного продукта не стоит ничего, а проектирование стоит ВСЁ.
Когда кто-то сравнивает строительство дома и написание кода, плюйте ему в лицо. Строительство дома (укладывание кирпичей итп) нужно сравнивать с компиляцией. А вот написание кода надо сравнивать с работой архитектора зданий. Но поскольку строительство — это долго и затратно, архитектор зданий не беспокоится о частой тотальной переделке всего, в отличие от программиста, для которого вполне норма «снести здание программы» и построить его заново.
В этом и есть ключевое отличие производства физических объектов от производства софта.
У ненастоящих же инженеров названия некоторых из этих этапов притащены в их предметную область и они даже любят рассказывать о проектировании софта, разработке и приёме в эксплуатацию. Вот только процентный баланс в этих этапах кардинально иной.
К примеру, производство физического объекта занимает существенное время и требует существенных ресурсов; аналог же производства в программировании — это вовсе не написание кода, как многие считают! Производство программы — это компиляция и сборка! При этом результат компиляции — это ещё не финальный результат работы, а лишь артефакт для этапов тестирования и внедрения. И вот уже результат внедрения в виде конкретной работающей программы/системы на конкретном компьютере — вот это настоящий результат.
А что же такое проектирование и написание кода? А оба этих этапа мапятся на один — проектирование физического объекта. При этом исходный код — это по сути детальная документация по созданию программы, по этой документации другие системы (компилятор и система сборки) изготавливают бинарные файлы.
В итоге получаем такое. Для физических объектов на стадии проектирование—производство—тестирование—внедрение тратится примерно одинаковое время (скажем, по 25% для простоты), при этом на производство ещё и физические ресурсы уходят. А для программных объектов на этап проектирования уходит 70%, 1% на производство (=компиляция и сборка) и 20% на тестирование и 9% на внедрение.
Именно дешевизна производства (по сути просто копирование байтов) и является действующим фактором т.н. «софтварного пиратства». Производство софтварного продукта не стоит ничего, а проектирование стоит ВСЁ.
Когда кто-то сравнивает строительство дома и написание кода, плюйте ему в лицо. Строительство дома (укладывание кирпичей итп) нужно сравнивать с компиляцией. А вот написание кода надо сравнивать с работой архитектора зданий. Но поскольку строительство — это долго и затратно, архитектор зданий не беспокоится о частой тотальной переделке всего, в отличие от программиста, для которого вполне норма «снести здание программы» и построить его заново.
В этом и есть ключевое отличие производства физических объектов от производства софта.
Никогда больше не куплю домой роутер микротик. Инфернальное мерзейшее поделие для цискозадротов и линуксовых админов, у которых борода из витой пары уже растёт. Мучительный процесс конфигурации этого адского изделия приводит в бешенство.
Текущий роутер я даже не буду никому дарить, а просто выброшу, люди не должны с этим пересекаться.
Текущий роутер я даже не буду никому дарить, а просто выброшу, люди не должны с этим пересекаться.
Эксперимент с Adobe Reader на макоси закончился — глючная тормозная параша, некоторые баги совсем невыносимы (например, на больших файлов при скроллинге в нижнем правом углу постоянно возникает непонятный прогрессбар, который сильно раздражает и отвлекает), поэтому переключился на Foxit Reader.
Отличный цикл статей про мифы reusablity:
* https://www.ufried.com/blog/reusability_fallacy_1/
* https://www.ufried.com/blog/reusability_fallacy_2/
* https://www.ufried.com/blog/reusability_fallacy_3/
Один момент прям отдельно нужно выделить:
First of all, reusability is a deeply industrial belief. In the physical world, reusability is mostly interchangeable with standardization. Standardized parts support building the product at a lower price and can easily be reused in multiple products. On the other hand, any part that is designed with reusability in mind is a candidate for becoming a standardized part.
* https://www.ufried.com/blog/reusability_fallacy_1/
* https://www.ufried.com/blog/reusability_fallacy_2/
* https://www.ufried.com/blog/reusability_fallacy_3/
Один момент прям отдельно нужно выделить:
First of all, reusability is a deeply industrial belief. In the physical world, reusability is mostly interchangeable with standardization. Standardized parts support building the product at a lower price and can easily be reused in multiple products. On the other hand, any part that is designed with reusability in mind is a candidate for becoming a standardized part.
Ufried
The reusability fallacy - Part 1
Why the reusability promise does not work
Ну и вдогонку к https://t.me/fieryfiles/245 продолжаю утверждать, что аналогии между физическим миром и программированием не работают, как бы красиво они ни выглядели.
Мы сейчас наблюдаем в очень интересный случай — взрывной рост популярности продукта и вытекающие из этого проблемы. Речь, конечно, про софт для видеоконференций zoom.
Вплоть до последних недель это был нишевый корпоративный продукт, достаточно популярный, но не слишком. Но всё изменилось с коронакризисом, популярность взлетела буквально взрывным образом, и на сервис пристальное внимание обратили хкаеры и медиа-падальщики (журналисты). Из-за возросшей популярности вселенная резко потребовала возврата технического долга: принятые когда-то решения внезапно очень больно взорвались, когда хакеры начали находить уязвимости и разоблачать маркетинговый булшит, который раньше никем особо не замечался, а теперь вдруг на волне интереса все стали детально всё исследовать. Медиа-падальщики, естественно, мимо такого пройти не могли, а так как новости про чужие проблемы «продаются» лучше, все стервятники бросились писать про уязвимости и баги.
А если бы не коронакризис, то zoom бы развивался потихоньку, хакеры тихо эксплуатировали уязвимости, а сми писали умеренные статьи про сервис раз в год. Компания явно оказалась не подготовлена к популярности.
Вплоть до последних недель это был нишевый корпоративный продукт, достаточно популярный, но не слишком. Но всё изменилось с коронакризисом, популярность взлетела буквально взрывным образом, и на сервис пристальное внимание обратили хкаеры и медиа-падальщики (журналисты). Из-за возросшей популярности вселенная резко потребовала возврата технического долга: принятые когда-то решения внезапно очень больно взорвались, когда хакеры начали находить уязвимости и разоблачать маркетинговый булшит, который раньше никем особо не замечался, а теперь вдруг на волне интереса все стали детально всё исследовать. Медиа-падальщики, естественно, мимо такого пройти не могли, а так как новости про чужие проблемы «продаются» лучше, все стервятники бросились писать про уязвимости и баги.
А если бы не коронакризис, то zoom бы развивался потихоньку, хакеры тихо эксплуатировали уязвимости, а сми писали умеренные статьи про сервис раз в год. Компания явно оказалась не подготовлена к популярности.