Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться
Зачастую, текущее поколение крудошлепов и рестоделов, поражденное успешным прохождением литкода, о модели и теории банально не задумывается, а пока эффективные менеджеры дойдут до старика брукса, которые выросли из этих же растоделов и крудошлепов сократят не одну сотню сеньеров.
И со своей стороны хочется доучить Си и С++ и уйти писать что-то системно продуманное, нежели, чем ломать голову об очередной модели в обычном продукте, где зачастую о дизайне никто не заморачивается. Когда проект загнивает, то тушат джунами и/или деньгами, перематывая изолентой хибернейт, спринг веб, JPA и прочие аббревиатуры.
Безусловно есть оч. крутые спецы с богатым опытом, обширными знаниями и умением создавать продукты как с бизнесовой стороны, так и с технической, но на фоне общей массы они незаметны.
P.S. я не против фреймворков и тулов - это прекрасные инструменты в своих нишах, но если кругозор ограничен исключительно фреймворками, то точного технического решения не получить, т.к. где-то да и придется сделать свой велосипед. Также я считаю полезным решать литкод, но это всего лишь небольшая часть из разработки.
Россия обладает значительными запасами РЗМ, которые оцениваются в 28,7 млн тонн. Крупнейшие месторождения находятся в Мурманской области и Якутии.
Добыча:
Основным источником РЗМ в России является Ловозерское месторождение, где добывают лопаритовую руду. Однако, в целом, уровень добычи РЗМ в России остается низким по сравнению с мировыми лидерами.
Переработка:
Переработка РЗМ в России также развита недостаточно. Основной объем концентрата РЗМ, получаемого на Ловозерском ГОКе, отправляется на гидрометаллургическую переработку на Соликамский магниевый завод. В настоящее время Россия пытается восстановить полный цикл производства РЗМ, от руды до готовой продукции.
Значение РЗМ:
РЗМ являются стратегическим сырьем для многих отраслей промышленности, включая электронику, производство аккумуляторов для электромобилей, оборонную промышленность и другие.
Перспективы:
В России предпринимаются усилия по увеличению добычи и переработки РЗМ, а также развитию производства продукции на их основе. В частности, планируется строительство нового разделительного завода в Соликамске.
Основные компании:
Ключевыми компаниями, участвующими в добыче и переработке РЗМ в России, являются «Росатом», «Соликамский магниевый завод», «Уралредмет» и другие.
CTO - Chief Technology Officer, т.е. человек с глубокой технической экспертизой, который решает о применимости того или иного инструмента, создает свои инструменты.
CTO вещает про какие-то встречи, уровни, трайбы, а технологии то где? где масштаб решений где вы обошли конкурентов? Какие бизнес задачи вы решили и тем самым обошли конкурентов и стали прибыльнее, какие know-how решения за этим были? Какие уникальные технические решения были изобретены при помощи вас? Для CTO как-то очень слабо.
В С++ точно такой же результат. Чтение операндов идет слева направо. Получили первый операнд, его значение равно 5, потом увеличили на 1 и значение стало равно 6, получили второй операнд, его значение равно 6 и потом еще увеличили на 1. пототм посчитали и присвоили значение i, при этом в i уже должно быть 7. Но справдливости ради, надо посмотреть ассемблер без оптимизации.
На мой взгляд верхний и нижний уровень определения недостаточно раскрыты. Т.к. зависимость верхнего модуля от нижнего вполне нормально и любая слоеная модель (например OSI) это продемонтрирует.
Но вопрос в другом, когда строится сложная система, то для того, чтобы не тащить конкретную специфику инфраструктуры, выделают интерфейс (только это не конструкция языка, а абстракция модуля) и таким образом заявляют/утверждают требуемые функции от инфраструктуры реализации. И пример у Роберта Мартина как раз об этом и говорит, что не надо тащить KeyboardReader в приложение, т.к. приложению все равно откуда читать и куда писать. Но DIP надо применять тоже разумно, TTM играет важную роль и если вынос в DIP стоит относительно недорого, то для начальной реализации можно сначала реализовать прямую связь, а потом уже внести абстракцию - это очень тонкий и индивиудальный момент и не всегда такое получается сделать.
Ответ: 1. DIP реализован корректно.
НЕТ!! Есть например модуль шифрования/обращения по сети/любая другая либа, с какого перепугу этот модуль должен реализовывать какие-то левые интерфейсы из приложений, если его использует 100500 приложений?
Автор обвинил, что 90% неправильно понимают и сам же в диаграммах ресует чушь. Пост просто реклама ТГ канала.
Так вроде организация должна быть по бизнес логике, а не квадратное с квадратным, а круглое с круглым. Такое применимо для небольших проектов, а когда организация проекта происходит по типу/назначению класса, контроллеры в контроллеры, енамы в енамы, сервисы в сервисы, а потом все референсят всех.
Вы плохо представляете как работают большие компании и "технарь"/"не технарь" вообще не причем, там требуются совсем другие навыки. Комании по типу боинга это - мини государство.
Трагедии можно было избежать, если бы руководство Boeing следовало базовому принципу эффективного управления — умению выстраивать диалог внутри компании
Там вообще все не так, вот от слова совсем и вы рассуждаете с позиции рядового работника, примерно как в булгакове: "Да взять все и поделить" - нет, не получится.
У большой компании нет владельца, есть акционеры, которые в теории должны управлять, но это только в теории. И есть ряд системных проблем, от которых эти компании страдают.
В больших компаниях слишком много людей, которым плевать на будушее компании, в их фокусе ближайшая перспектива. И это не потому, что они плохие, а потому, что система такая. В итоге разумная стратегия может сводиться к получению годовой или двух годовой премии, после которой некоторые пишут фаревелл письма: "I decided to leave to pursue new opportunities", ну может 3-4 года чтобы стать руководителем показать видимость получить повышение и тоже фаревел.
Акциями владеет очень большое количество людей, которые естественно ничего нерешают. Покупают акции, чтобы избежать инфляции, а если компания еще и рост покажет, то совсем хорошо, особенно в бычьем рынке - ничего не делаешь, а денюшка капает.
Серьезные владельцы
Есть крупные акционеры, фонды, которые берут деньги в управление, где портфельные менеджеры и кванты выискивают моменты покупки и продажи акций - им плевать что будет с боингом, главное успеть продать до падения или во время падения. Плюс в фондах мониторят другие факторы + "инфа с сарафана". Но им в принципе наплевать на будущее боинга, лишь бы успеть купить до подъема и продать до падения. Стратегическое управление не входит в фокус этих людей, by design. Этим людям важна строчка с PnL.
Несерьезные игроки
Брокерные клерки и хомяки, которые торгуют на новостях и кустарной аналитике, и которые хотят сберечь свои кровные в чужом кошельке, которые может быть бы и хотели управлять по простоте душевной, да только возможности нет в принципе.
Управление
Вот тут много мутного. Есть CEO, который является главным управленцем компании, но есть еще совет директоров, который выбирает этого CEO. Но фишка в том, то если граждане захотят "кинуть" компанию, при такой структуре у них это легко получится. Это ведь не оголтелые 90е, когда могут такого "борцуху" вывезти в лес, а тут некому вывозить. Для того, чтобы это избежать реализации откровенных схем кидка, есть еще какие-то люди: совет/комитет, который прописан в политике или учредительных документах компании. При этом CEO или кто-то еще не могут просто так отстранить этот комитет или ослабить его полномочия (пишу на догадках, надо "копать", читал только про совет директоров).
А далее замкнутый круг. Чтобы акции покупались, цена должна расти, а чтобы росла цена акции должны покупаться, "иначе все, всему бизнесу хана" (с) х/ф Бабло. И вот тут всем управляют мьеньеджеры, для которых боинг это строчка в спредшите с главной колонкой PnL или годовой премией. В боинге никто не будет перед отчетами рассказывать, что у них что-то пошло не так, а когда что-то идет не так, главное дотянуть до ближайшего срока, а дальше хоть трава не расти и так во всех отделах, с разной степенью.
Про MAX 737
The series was announced in August 2011, first flown in January 2016,
Under McNerney, Boeing’s stock price did very well. Cash flow was generally strong, and investors like short-term metrics like these. But he also leaves behind a toxic legacy that future leadership will need to deal with.
ога, ога, который сами же и породили :) Ну а почему и нет, инвертированный распил тоже работает. Объявляем экономию на технарях, для чего кормить инженеров с ЗП под 200k$, если в индии можно программиста нанять за 10 баксов в час, цена работника макдака в США.
Ну и проворачивают. Годовые премии и бонусы, акционеров были положены себе в карман. Как в бигтехах вам платят опционы, потому, что вы влияете на будущее компании! (рядовой то сотрудник конечно влияет, хах). В инвестменте не платят опционов, там платят кешом, потому что все "в теме как это работает".
Я не поверю, что об этом не знал CEO или приближенные, "звонки" были по всем линиями, но управлцены это делали целенаправленно и сознательно. Для них краткосрочный "кидок" оказался выгоднее долгосрока, с точки зрения стратегии, а не с точки зрения того, что они злодеи. т.к. персональные цели разумного менеджера по приоритету всегда выше, чем цели компании, иначе он идиот.
Кому не жалко, можете карму докрутить или окончательно заминусить, чтобы я сюда вообще не пришел, никогда, ахахаха.
Нужно написать функцию (f) округления положительных чисел к ближайшему целому, используя только Math.floor.
Боже какая дичь! Автор, что вы хотите этой задачей проверить? Какие навыки? Эта задача не проверяет кодинг скилы, она не проверяет навыки программирования, знания или применения библиотек и фреймворков. Это вообще не алгозадача от слова никак.
Про представление чисел с плавающей точкой уже сказали, там все не так просто.
Мне кажется таких интервьюверов, а заодно и непоредственного руководителя, надо просто уволить одним днем.
В команию могут попасть абсолютные неадекваты, а адекваты просто развернутся и уйдут. Что еще хуже, для индустрии задаете в корне неверные стандарты.
сли честно, в реальной жизни умение решать "алгоритмические задачи" не то чтобы не понадобится, но за 30-летнюю "карьеру", у меня было только одно место работы, где чаще, чем раз в месяц приходилось решать задачи близкие к алгоритмическим.
Конечно не было, если вы задаете такие вопросы на собесе, то какой вменяемый руководитель допустит вас до серьезных вещей.
У меня неоднозначные впечатления от алгозадач литкода, но как правило, разработчики с опытом справляются с ними хорошо и это просто входной фильтр и не более того. Но таким инструментом тоже надо уметь пользоваться.
плюсанул бы да кармы нет. Микросервисный и cloud-based подход лепят везде и всюду усложняя инфраструктуру и добавляя себе гемора. Вместо обычного подхода, накидали сервисы с разумной детализацией, закинули на сервак(виртуалку), подняли несколько инстансов в разных ДЦ и погнали. Но нет же для простых сервисов, возьмут куберы, контейнеры, прокси, балансеры, облачные базы, и вроде все должно работать но все равно летят ошибки из-за инфраструктуры, в 70% проектов вообще нафиг не нужен этот cloud-based подход. Да и потом для масштабирования в реальном времени из-за нагрузки, такого куска можно применить cloud-based подход. Более того есть бизнес процессы, которые в принципе масштабируются сложнее из-за длинных цепочек и мест синхронизаций
Тут еще следует упомнуть про бонусы и опционы (это даже не акции) и что эта ЗП до налогов.
У меня все равно есть разрыв шаблона, спрашивают литкод, который в жизни применяют разве что датабазники какие-нить, писатели поисковых движков и прочего, может еще системщиков где-то цепляет. Но условно не решил литкод хард - тебя не берут, но почему никто не оценивает реальный опыт и умение решать реальные проблемы просто - ведь именно за это компания получает деньги - за умение решать проблемы, а не задачи, как технические, так и организационные.
Но есть ощущение, что фанги переоценены и это рынок работодателя.
Вера это вообще не научно. Есть практики воспоминания прошлого опыта и такое проверяется очень легко, например если зарыл клад и можешь вспомнить это место, то надо прийти и проверить. Или например есть какие-то особенности, которые известны только тебе и которые можно проверить только сейчас. Если проверка не срабатывает вполне может быть фантазия.
Со своей стороны у меня есть такие доказательства того, что я работал в определенной области и мои навыки в это области есть, при этом в текущей жизни я этим не занимался от слова вообще. Есть другие косвенные подтверждения у других людей. Но полностью прошлая память так или иначе "зашита" в текущем воплощении, видимо для того, чтобы нарабатывать новый опыт, ну и воспоминания о смерти, болезни и прочих мучениях могут быть совсем неражужными и будут только мешать нарабатывать опыт.
Мне регулярно сыпят минусы в карму и на харб я хожу только из-за того, что доступны ленты сообщений. Но раз сыпят, то люди не хотят воспринимать мою инфу - на то их полное право.
Человек и так бессмертен, правда относительно. Физическое тело - инструмент накопления опыта. С каждой новой жизнью человек нарабатывает новый опыт и то, что дается человеку легко, просто говорит о том, что у него в этой области отлично наработанный опыт. И если человек 5 жизней был связан с музыкой, много ли ему надо чтобы начать играть? Нет. Тот кто никогда не занимался музыкой либо очень давно, то ему этот опыт будет даваться очень тяжело.
Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые: создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 2 года он работал, за ЗП ключевого в роли создателя. Такой же подход можно использовать и для рядового.
Итоговая стратегия строится так, что обещания+текущая позиция дешевле, чем инфляция на рынке. Чтобы нанять кого-то со стороны, необходимо докинуть денег для того, чтобы человек поменял место.
При этом, работая на одном месте бОльшая часть времени у большинства уходит на рутину, которая удешевляет вашу цену рынке и то, что востребовано у вас в компании, может быть совсем не востребовано где-то еще.
Регулируя разные параметры модели можно получить разные результаты. Есть примеры когда люди сидят по 15 лет на одном месте, со средней ЗП и лайтовыми условиями труда, есть те кто скачут пробуют, но при этом из-за нервов и времен страдает личная жизнь. Кому какую стратегию выбирать: выбор каждого и там и там есть плюсы и минусы. Но чтобы получить максимальную цену, надо досканально знать рынок.
Ретро, спринты, скрамы. Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому. Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт. Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей? Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя. Я не хочу читать, что это работает, я хочу запустить и проверить что это работает. Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует. Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать. Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
может вопрос дилетантский, но почему нельзя написать какой-нить фронтент для LVVM или написать какой-нить диалект для С++ или Java, как например это сделал JetBrains с котлином. Котлин ООП язык с примесью функциональности, по сути фронтенд для Java, Native и т.д. При этом если писать для JRE, то можно использовать все либы для java, на что-то там есть мапинги, на что-то нет. Почему не взять какую-то стандартную платформу и заиспользовать всю ее мощность и комьюнити, при этом перкомпилить все конфигурации, ну или компилить конфигурации во время сборки? добавить какие-то тулы для фомроклепа, но поверх стандартных либ. С учетом кроссс платформенности перевести на англ язык и захватить например какие-то азиатские рынки, хотя там свое написано уже, но тем не менее это бы значительно расширило долю рынка.
Спецы по 1С можете прокоментировать? я код 1С выидел пару раз, и очень примерно представляю как этоработает.
А я в какой-то степени понимаю боль собеседущего. Если у тебя в резюме указано что ты знаешь A и B, но не можешь сказать каких-то ключевых характеристик, то этоточно говорит о том, что человек их не знает. одно дело спрашивать какой хедер надо указать чтобы передать xml. но если указан SOAP и REST, то он как минимум должен это знать, если гражданин знает матан (я его например не знаю, ну т.е. пределы, интегралы и прочее это понятно), то базовые вещи, пределы и теоремы он знать должен иначе это вранье, либо рассказать в каком объеме знает. Автор абсолютно правильно спрашивает про рассуждение, потому что все IT это постоянное принятие решений и для чего тебе м***ак решение которого надо контролировать постоянно? Который мог просто банально понатаскаться на типичные вопросы, а думать не умеет. То же самое и с программированием, типовые задачи, типовые вопрсоы, а на выходе г-но. Потому что проблемы это всегда задачи с каким-то тонкостями и надо правильно выработать или выбрать решение.
С точки зрения юзера 2000 и WinXp были отличными системами. Добавив туда мультирабочий стол из коробки, каких-то плюшек из 7ки была бы отличная ОС. при установке 1.5-2 Гб на диске, как уже написали никуда не лезет в инет и в целом все доступно и кастомизируемо (привет реестр). Все системы после XP это какой-то разброд и шатание в поисках чего-то нового, при этом похоронив все старое. Если в XP я спокойно работал в проводнике на клавитуре и вообще мог сделать все на клавиатуре, элементов фокуса было меньше, то сейчас такая работа вообще не реальна. Перепиливание UI каждый раз приводит к тому, что мне вообоще все равно какой он, я его перестал настраивать от слова совсем. Если бы мне винда не требовалась для работы, у меня бы остался только линукс.
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи Заголовок: сделать восстановление пароля Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>. Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину. Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
P.S. и еще бросилось в глаза: "Устные договоренности ничего не значат!" - брехня. Может звучит грубо, но:"за базар надо отвечать", потому что люди за него помнят и могут спросить. И прежде всего этой аксиоме должен следовать руководитель - его слово куда весомее его подчиненных
Зачастую, текущее поколение крудошлепов и рестоделов, поражденное успешным прохождением литкода, о модели и теории банально не задумывается, а пока эффективные менеджеры дойдут до старика брукса, которые выросли из этих же растоделов и крудошлепов сократят не одну сотню сеньеров.
И со своей стороны хочется доучить Си и С++ и уйти писать что-то системно продуманное, нежели, чем ломать голову об очередной модели в обычном продукте, где зачастую о дизайне никто не заморачивается.
Когда проект загнивает, то тушат джунами и/или деньгами, перематывая изолентой хибернейт, спринг веб, JPA и прочие аббревиатуры.
Безусловно есть оч. крутые спецы с богатым опытом, обширными знаниями и умением создавать продукты как с бизнесовой стороны, так и с технической, но на фоне общей массы они незаметны.
P.S. я не против фреймворков и тулов - это прекрасные инструменты в своих нишах, но если кругозор ограничен исключительно фреймворками, то точного технического решения не получить, т.к. где-то да и придется сделать свой велосипед.
Также я считаю полезным решать литкод, но это всего лишь небольшая часть из разработки.
Хороший пример про бизнес в РФ и как китай переигрывает экономически, хотя судя по гуглу редкоземельных металлов у нас навало.
Удачи автору!
Гугл про редкоземельные металлы
https://www.google.com/search?q=редкоземельные+металлы+в+россии&oq=редкощземеотные&gs_lcrp=EgZjaHJvbWUqCQgCEAAYDRiABDIGCAAQRRg5Mg8IARAAGA0YgwEYsQMYgAQyCQgCEAAYDRiABDIJCAMQABgNGIAEMgkIBBAAGA0YgAQyCQgFEAAYDRiABDIJCAYQABgNGIAEMgkIBxAAGA0YgAQyCQgIEAAYDRiABDIJCAkQABgNGIAE0gEIOTM2OGowajeoAgCwAgA&sourceid=chrome&ie=UTF-8
Более подробно:
Запасы:
Россия обладает значительными запасами РЗМ, которые оцениваются в 28,7 млн тонн. Крупнейшие месторождения находятся в Мурманской области и Якутии.
Добыча:
Основным источником РЗМ в России является Ловозерское месторождение, где добывают лопаритовую руду. Однако, в целом, уровень добычи РЗМ в России остается низким по сравнению с мировыми лидерами.
Переработка:
Переработка РЗМ в России также развита недостаточно. Основной объем концентрата РЗМ, получаемого на Ловозерском ГОКе, отправляется на гидрометаллургическую переработку на Соликамский магниевый завод. В настоящее время Россия пытается восстановить полный цикл производства РЗМ, от руды до готовой продукции.
Значение РЗМ:
РЗМ являются стратегическим сырьем для многих отраслей промышленности, включая электронику, производство аккумуляторов для электромобилей, оборонную промышленность и другие.
Перспективы:
В России предпринимаются усилия по увеличению добычи и переработки РЗМ, а также развитию производства продукции на их основе. В частности, планируется строительство нового разделительного завода в Соликамске.
Основные компании:
Ключевыми компаниями, участвующими в добыче и переработке РЗМ в России, являются «Росатом», «Соликамский магниевый завод», «Уралредмет» и другие.
CTO - Chief Technology Officer, т.е. человек с глубокой технической экспертизой, который решает о применимости того или иного инструмента, создает свои инструменты.
CTO вещает про какие-то встречи, уровни, трайбы, а технологии то где? где масштаб решений где вы обошли конкурентов? Какие бизнес задачи вы решили и тем самым обошли конкурентов и стали прибыльнее, какие know-how решения за этим были? Какие уникальные технические решения были изобретены при помощи вас?
Для CTO как-то очень слабо.
потому что это самолет, там вибрациии, перегрузки, удары при посадке и такое устройство должно быть надежным и точным.
В С++ точно такой же результат.
Чтение операндов идет слева направо.
Получили первый операнд, его значение равно 5, потом увеличили на 1 и значение стало равно 6, получили второй операнд, его значение равно 6 и потом еще увеличили на 1.
пототм посчитали и присвоили значение i, при этом в i уже должно быть 7.
Но справдливости ради, надо посмотреть ассемблер без оптимизации.
С вики страницы нашел вот такие оригиналы
https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf
https://linux.ime.usp.br/~joaomm/mac499/arquivos/referencias/oodmetrics.pdf
На мой взгляд верхний и нижний уровень определения недостаточно раскрыты. Т.к. зависимость верхнего модуля от нижнего вполне нормально и любая слоеная модель (например OSI) это продемонтрирует.
Но вопрос в другом, когда строится сложная система, то для того, чтобы не тащить конкретную специфику инфраструктуры, выделают интерфейс (только это не конструкция языка, а абстракция модуля) и таким образом заявляют/утверждают требуемые функции от инфраструктуры реализации.
И пример у Роберта Мартина как раз об этом и говорит, что не надо тащить KeyboardReader в приложение, т.к. приложению все равно откуда читать и куда писать.
Но DIP надо применять тоже разумно, TTM играет важную роль и если вынос в DIP стоит относительно недорого, то для начальной реализации можно сначала реализовать прямую связь, а потом уже внести абстракцию - это очень тонкий и индивиудальный момент и не всегда такое получается сделать.
НЕТ!! Есть например модуль шифрования/обращения по сети/любая другая либа, с какого перепугу этот модуль должен реализовывать какие-то левые интерфейсы из приложений, если его использует 100500 приложений?
Автор обвинил, что 90% неправильно понимают и сам же в диаграммах ресует чушь. Пост просто реклама ТГ канала.
Так вроде организация должна быть по бизнес логике, а не квадратное с квадратным, а круглое с круглым.
Такое применимо для небольших проектов, а когда организация проекта происходит по типу/назначению класса, контроллеры в контроллеры, енамы в енамы, сервисы в сервисы, а потом все референсят всех.
Ну штош, соболезную, сеньеров у вас нет :)
Вы плохо представляете как работают большие компании и "технарь"/"не технарь" вообще не причем, там требуются совсем другие навыки. Комании по типу боинга это - мини государство.
Там вообще все не так, вот от слова совсем и вы рассуждаете с позиции рядового работника, примерно как в булгакове: "Да взять все и поделить" - нет, не получится.
У большой компании нет владельца, есть акционеры, которые в теории должны управлять, но это только в теории. И есть ряд системных проблем, от которых эти компании страдают.
В больших компаниях слишком много людей, которым плевать на будушее компании, в их фокусе ближайшая перспектива. И это не потому, что они плохие, а потому, что система такая. В итоге разумная стратегия может сводиться к получению годовой или двух годовой премии, после которой некоторые пишут фаревелл письма: "I decided to leave to pursue new opportunities", ну может 3-4 года чтобы стать руководителем показать видимость получить повышение и тоже фаревел.
Структура компании
https://companiesmarketcap.com/boeing/shares-outstanding/
https://www.investopedia.com/ask/answers/062315/what-difference-between-shares-outstanding-and-floating-stock.asp#:~:text=Shares outstanding is the total,of a company's active shares.
Выпущенные акции (или находящиеся в обращении акции) — это любые акции, находящиеся во владении акционеров и инсайдеров компании.
Итого 618 млн акций.
Попытался найти мажоритариев https://www.investopedia.com/articles/insights/052116/top-3-boeing-shareholders-ba.asp, по инфе не густо, но такое просто так никто не публикует. Но даже если кто-то владеет 3-6% для такой компании уже считается мажоритарием.
Акциями владеет очень большое количество людей, которые естественно ничего нерешают. Покупают акции, чтобы избежать инфляции, а если компания еще и рост покажет, то совсем хорошо, особенно в бычьем рынке - ничего не делаешь, а денюшка капает.
Серьезные владельцы
Есть крупные акционеры, фонды, которые берут деньги в управление, где портфельные менеджеры и кванты выискивают моменты покупки и продажи акций - им плевать что будет с боингом, главное успеть продать до падения или во время падения. Плюс в фондах мониторят другие факторы + "инфа с сарафана". Но им в принципе наплевать на будущее боинга, лишь бы успеть купить до подъема и продать до падения. Стратегическое управление не входит в фокус этих людей, by design. Этим людям важна строчка с PnL.
Несерьезные игроки
Брокерные клерки и хомяки, которые торгуют на новостях и кустарной аналитике, и которые хотят сберечь свои кровные в чужом кошельке, которые может быть бы и хотели управлять по простоте душевной, да только возможности нет в принципе.
Управление
Вот тут много мутного. Есть CEO, который является главным управленцем компании, но есть еще совет директоров, который выбирает этого CEO. Но фишка в том, то если граждане захотят "кинуть" компанию, при такой структуре у них это легко получится. Это ведь не оголтелые 90е, когда могут такого "борцуху" вывезти в лес, а тут некому вывозить. Для того, чтобы это избежать реализации откровенных схем кидка, есть еще какие-то люди: совет/комитет, который прописан в политике или учредительных документах компании. При этом CEO или кто-то еще не могут просто так отстранить этот комитет или ослабить его полномочия (пишу на догадках, надо "копать", читал только про совет директоров).
По фатку CEO наемный гражданин, которому надо просто отсидеть свой срок, а дальше хоть трава не расти https://www.thestreet.com/investing/stocks/boeing-company-history-ceo-list
А далее замкнутый круг. Чтобы акции покупались, цена должна расти, а чтобы росла цена акции должны покупаться, "иначе все, всему бизнесу хана" (с) х/ф Бабло. И вот тут всем управляют мьеньеджеры, для которых боинг это строчка в спредшите с главной колонкой PnL или годовой премией. В боинге никто не будет перед отчетами рассказывать, что у них что-то пошло не так, а когда что-то идет не так, главное дотянуть до ближайшего срока, а дальше хоть трава не расти и так во всех отделах, с разной степенью.
Про MAX 737
А CEO ушел W. James McNerney Jr.: July 2005 to July 2015, казалось бы новое скоро полетит, а он уходит https://www.forbes.com/sites/richardaboulafia/2015/06/24/boeing-mcnerney-and-the-high-price-of-treating-aircraft-like-it-was-any-other-industry/ ну и прекрасная статья, которая говорит, что
И еще немного инсайда. А что если таки CEO или кто-то из совета директоров захочет "погреть руки" https://theprint.in/world/boeing-engineers-blame-cheap-indian-software-for-737-max-problems/256999/
ога, ога, который сами же и породили :) Ну а почему и нет, инвертированный распил тоже работает. Объявляем экономию на технарях, для чего кормить инженеров с ЗП под 200k$, если в индии можно программиста нанять за 10 баксов в час, цена работника макдака в США.
Ну и проворачивают. Годовые премии и бонусы, акционеров были положены себе в карман. Как в бигтехах вам платят опционы, потому, что вы влияете на будущее компании! (рядовой то сотрудник конечно влияет, хах). В инвестменте не платят опционов, там платят кешом, потому что все "в теме как это работает".
Я не поверю, что об этом не знал CEO или приближенные, "звонки" были по всем линиями, но управлцены это делали целенаправленно и сознательно. Для них краткосрочный "кидок" оказался выгоднее долгосрока, с точки зрения стратегии, а не с точки зрения того, что они злодеи. т.к. персональные цели разумного менеджера по приоритету всегда выше, чем цели компании, иначе он идиот.
Кому не жалко, можете карму докрутить или окончательно заминусить, чтобы я сюда вообще не пришел, никогда, ахахаха.
Боже какая дичь! Автор, что вы хотите этой задачей проверить? Какие навыки?
Эта задача не проверяет кодинг скилы, она не проверяет навыки программирования, знания или применения библиотек и фреймворков.
Это вообще не алгозадача от слова никак.
Про представление чисел с плавающей точкой уже сказали, там все не так просто.
Мне кажется таких интервьюверов, а заодно и непоредственного руководителя, надо просто уволить одним днем.
В команию могут попасть абсолютные неадекваты, а адекваты просто развернутся и уйдут. Что еще хуже, для индустрии задаете в корне неверные стандарты.
Конечно не было, если вы задаете такие вопросы на собесе, то какой вменяемый руководитель допустит вас до серьезных вещей.
У меня неоднозначные впечатления от алгозадач литкода, но как правило, разработчики с опытом справляются с ними хорошо и это просто входной фильтр и не более того. Но таким инструментом тоже надо уметь пользоваться.
плюсанул бы да кармы нет. Микросервисный и cloud-based подход лепят везде и всюду усложняя инфраструктуру и добавляя себе гемора.
Вместо обычного подхода, накидали сервисы с разумной детализацией, закинули на сервак(виртуалку), подняли несколько инстансов в разных ДЦ и погнали.
Но нет же для простых сервисов, возьмут куберы, контейнеры, прокси, балансеры, облачные базы, и вроде все должно работать но все равно летят ошибки из-за инфраструктуры, в 70% проектов вообще нафиг не нужен этот cloud-based подход.
Да и потом для масштабирования в реальном времени из-за нагрузки, такого куска можно применить cloud-based подход.
Более того есть бизнес процессы, которые в принципе масштабируются сложнее из-за длинных цепочек и мест синхронизаций
А можете озвучить таких конкурентов, для расчширения кругозора.
Тут еще следует упомнуть про бонусы и опционы (это даже не акции) и что эта ЗП до налогов.
У меня все равно есть разрыв шаблона, спрашивают литкод, который в жизни применяют разве что датабазники какие-нить, писатели поисковых движков и прочего, может еще системщиков где-то цепляет.
Но условно не решил литкод хард - тебя не берут, но почему никто не оценивает реальный опыт и умение решать реальные проблемы просто - ведь именно за это компания получает деньги - за умение решать проблемы, а не задачи, как технические, так и организационные.
Но есть ощущение, что фанги переоценены и это рынок работодателя.
Вера это вообще не научно.
Есть практики воспоминания прошлого опыта и такое проверяется очень легко, например если зарыл клад и можешь вспомнить это место, то надо прийти и проверить. Или например есть какие-то особенности, которые известны только тебе и которые можно проверить только сейчас.
Если проверка не срабатывает вполне может быть фантазия.
Со своей стороны у меня есть такие доказательства того, что я работал в определенной области и мои навыки в это области есть, при этом в текущей жизни я этим не занимался от слова вообще.
Есть другие косвенные подтверждения у других людей. Но полностью прошлая память так или иначе "зашита" в текущем воплощении, видимо для того, чтобы нарабатывать новый опыт, ну и воспоминания о смерти, болезни и прочих мучениях могут быть совсем неражужными и будут только мешать нарабатывать опыт.
Мне регулярно сыпят минусы в карму и на харб я хожу только из-за того, что доступны ленты сообщений. Но раз сыпят, то люди не хотят воспринимать мою инфу - на то их полное право.
Человек и так бессмертен, правда относительно. Физическое тело - инструмент накопления опыта. С каждой новой жизнью человек нарабатывает новый опыт и то, что дается человеку легко, просто говорит о том, что у него в этой области отлично наработанный опыт.
И если человек 5 жизней был связан с музыкой, много ли ему надо чтобы начать играть? Нет. Тот кто никогда не занимался музыкой либо очень давно, то ему этот опыт будет даваться очень тяжело.
Работодателю в принципе невыгодно, чтобы сотрудники оставались в рынке и были на острие технологий. Им необходимо чтобы их бизнес работал и чтобы их системы обслуживали и развивали.
Условно разделю сотрудников на следующих: создатели, ключевые, рядовые:
создатели - создают продукт с нуля, могут значительно изменить жизнь продукта в лучшую сторону.
ключевые - создают меньше, но хорошо знают как должна работать текущая система и умеют ее поддерэивать в таком состоянии.
рядовые - обычные сотрудники делающие рутину.
Допустим, бизнес хочет создать новый продукт и выйти на рынок. Соотвественно необходимо нанять/найти "создателя" с релевантным опытом. Либо "ключевого" который возможно сможет что-то создать. И в довесок рядовых, которые смогут делать то, что говорят ключевой/создатель.
В компании, у каждого проекта своя стадия. Допустим, проект уже запущен, приносит деньги, его надо просто развивать. Как удешивить?
Один из вариантов стратегии: находим способных людей из ключевых, которым можно предложить повышение, если они проявят себя "как создатель". При этом за те же деньги + обещания сейчас, он будет работать как создатель, а заплатим мы ему только потом и это тоже предмет торга. Если справится, то получит прибавку, но при этом 2 года он работал, за ЗП ключевого в роли создателя. Такой же подход можно использовать и для рядового.
Итоговая стратегия строится так, что обещания+текущая позиция дешевле, чем инфляция на рынке. Чтобы нанять кого-то со стороны, необходимо докинуть денег для того, чтобы человек поменял место.
При этом, работая на одном месте бОльшая часть времени у большинства уходит на рутину, которая удешевляет вашу цену рынке и то, что востребовано у вас в компании, может быть совсем не востребовано где-то еще.
Регулируя разные параметры модели можно получить разные результаты. Есть примеры когда люди сидят по 15 лет на одном месте, со средней ЗП и лайтовыми условиями труда, есть те кто скачут пробуют, но при этом из-за нервов и времен страдает личная жизнь.
Кому какую стратегию выбирать: выбор каждого и там и там есть плюсы и минусы.
Но чтобы получить максимальную цену, надо досканально знать рынок.
Ретро, спринты, скрамы.
Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому.
Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт.
Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей?
Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя.
Я не хочу читать, что это работает, я хочу запустить и проверить что это работает.
Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует.
Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать.
Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
может вопрос дилетантский, но почему нельзя написать какой-нить фронтент для LVVM или написать какой-нить диалект для С++ или Java, как например это сделал JetBrains с котлином.
Котлин ООП язык с примесью функциональности, по сути фронтенд для Java, Native и т.д.
При этом если писать для JRE, то можно использовать все либы для java, на что-то там есть мапинги, на что-то нет.
Почему не взять какую-то стандартную платформу и заиспользовать всю ее мощность и комьюнити, при этом перкомпилить все конфигурации, ну или компилить конфигурации во время сборки? добавить какие-то тулы для фомроклепа, но поверх стандартных либ.
С учетом кроссс платформенности перевести на англ язык и захватить например какие-то азиатские рынки, хотя там свое написано уже, но тем не менее это бы значительно расширило долю рынка.
Спецы по 1С можете прокоментировать? я код 1С выидел пару раз, и очень примерно представляю как этоработает.
А я в какой-то степени понимаю боль собеседущего.
Если у тебя в резюме указано что ты знаешь A и B, но не можешь сказать каких-то ключевых характеристик, то этоточно говорит о том, что человек их не знает.
одно дело спрашивать какой хедер надо указать чтобы передать xml.
но если указан SOAP и REST, то он как минимум должен это знать, если гражданин знает матан (я его например не знаю, ну т.е. пределы, интегралы и прочее это понятно), то базовые вещи, пределы и теоремы он знать должен иначе это вранье, либо рассказать в каком объеме знает.
Автор абсолютно правильно спрашивает про рассуждение, потому что все IT это постоянное принятие решений и для чего тебе м***ак решение которого надо контролировать постоянно?
Который мог просто банально понатаскаться на типичные вопросы, а думать не умеет.
То же самое и с программированием, типовые задачи, типовые вопрсоы, а на выходе г-но. Потому что проблемы это всегда задачи с каким-то тонкостями и надо правильно выработать или выбрать решение.
С точки зрения юзера 2000 и WinXp были отличными системами. Добавив туда мультирабочий стол из коробки, каких-то плюшек из 7ки была бы отличная ОС.
при установке 1.5-2 Гб на диске, как уже написали никуда не лезет в инет и в целом все доступно и кастомизируемо (привет реестр). Все системы после XP это какой-то разброд и шатание в поисках чего-то нового, при этом похоронив все старое. Если в XP я спокойно работал в проводнике на клавитуре и вообще мог сделать все на клавиатуре, элементов фокуса было меньше, то сейчас такая работа вообще не реальна.
Перепиливание UI каждый раз приводит к тому, что мне вообоще все равно какой он, я его перестал настраивать от слова совсем. Если бы мне винда не требовалась для работы, у меня бы остался только линукс.
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи
Заголовок: сделать восстановление пароля
Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>.
Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
P.S. и еще бросилось в глаза: "Устные договоренности ничего не значат!" - брехня. Может звучит грубо, но:"за базар надо отвечать", потому что люди за него помнят и могут спросить.
И прежде всего этой аксиоме должен следовать руководитель - его слово куда весомее его подчиненных