Не понял претензий к немецкому? Красивый, довольно логичный и простой язык.
Не лингвист, простой обыватель, только начинаю учить немецкий. Что-то даже после английского немецкий не кажется ни красивым, ни логичным, ни простым... хз, как люди запоминают какой пол у каких предметов в разных языках. Правила чтения - такое себе, да еще и с исключениями, по звучанию слова не всегда поймешь как оно пишется (а по написанию - не всегда поймешь как оно читается %) ) Еще и наплодили кучу диалектов, и очень крепко держатся за них.
Эсперанто — хорошая попытка общего языка, пусть с опорой в основном на европейский фундамент. ...... Хотелось бы пожелать для его творения ещё одного взлёта популярности, но ещё бы хотелось чтоб такой взлёт случился не за счёт мировых катаклизмов
В википедии (уж простите) высказывается мнение что как раз катаклизмы XXвека и убили Эсперанто на взлете
В начале 1920-х годов были предложения принять эсперанто в качестве рабочего языка Лиги Наций. Десять делегатов поддержали это предложение, но французский делегат Габриэль Аното проголосовал против. Ему не нравилось, что французский язык теряет свои позиции в качестве международного и он видел в эсперанто угрозу. Однако, спустя два года Лига Наций рекомендовала государствам-членам включить эсперанто в свои учебные планы. 1920-е годы многими историками оцениваются как период расцвета эсперанто-движения.
В СССР эсперанто активно распространялся в 1920-е годы, по предложению Льва Троцкого[10], он широко изучался как «язык мировой революции». Эсперанто активно использовался в сети «рабкоров» (рабочих корреспондентов), на этом языке велось радиовещание (в том числе внутреннее). В это время даже надписи на почтовых конвертах дублировались на двух языках, русском и эсперанто[11] (по некоторым свидетельствам такие открытки выходили и позже — например, в 1946 году[12]). Но с середины 1930-х годов активисты движения эсперанто подверглись репрессиям в СССР как «троцкисты», «шпионы» и «террористы»[13]. Многие советские эсперантисты, например, Николай Хохлов и Николай Кабанов, отошли от активной деятельности. Последний адрес на доме репрессированного эсперантиста
В нацистской Германии с середины 1930-х годов национальные эсперанто-организации были распущены, а многие участники эсперанто-движения физически уничтожены. Адольф Гитлер писал в «Майн кампф»[14], что эсперанто был создан как универсальный язык для объединения еврейских диаспор. Создание свободной от евреев Национальной Германской эсперанто-лиги было недостаточно для умиротворения нацистов. Обучение эсперанто было запрещено в немецких лагерях для военнопленных во время Второй мировой войны.
Как результат, движение эсперантистов в СССР и Германии фактически прекратило существование.
А вы погуглите как выглядит испанская или немецкая клавиатура. Когда появляется потребность - начинают делать клавиатуры с какими надо символами. Да и сейчас есть и наклейки и гравировка.
Латиница - ужасный выбор, из популярных языков она подходит разве что итальянскому. Всем остальным банально не хватает букв для тех звуков, которые используются в языке. Потому у испанцев, немцев, чехов, поляков и прочих есть буквы выходящие за стандартные 26 букв латиницы. Кто-то, как французы, англичане и немцы вынужден использовать сочетания, а-ля deutsch. Брать латиницу = тащить страшное легаси, которое поломает всю архитектуру.
Если уж изобретать новый язык, то букв его алфавита должно хватать для всех используемых в нем звуков (и вот определить набор этих звуков, удобный для всех - не такая уж и простая задача, если конечно не ограничиться созданием языка только для привыкших к индоевропейской семье)
Есть еще такой проект: https://archivebox.io/ "ставишь плагин в свой Firefox и он автоматически сохраняет тебе на сервер всё, что ты смотрел в интернете." сам пока еще не пробовал)
Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения (о чем и пишет автор обсуждаемой статьи, и с чем я согласен, исходя из своего личного многолетнего опыта)
Выплаты разрабам за быстроту работы не связаны с их оценками.
А что такое "быстрота работы"? Разве не выполнение в соответствии с оценкой или быстрее? И если нет оценки - то нет и "быстроты". Или вы предлагаете количество набираемых символов в секунду считать?
Требуем разработчиков оценивать время выполнения работ, собираем статистику
статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика
это просто смешно. Вы недооцениваете разрабов. Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее". Возможно даже будет оставаться время на сериалы и леваки. Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна %))
После сбора статистики строим вероятностную модель распределения оценок
И она вам показывает что:
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной.
"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений?
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
если Вася и Петя пойдут разными путями, то они получат и разные результаты.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом. "Законы Мёрфи", наверное, тоже все читали.
Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Их (массивы) точно лучше передавать по ссылке, как PHP передаёт объекты
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Используйте for
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt. Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Мы поможем вам определить, как мы разделяем и распределяем нагрузку между различными типами работников в центре обработки данных
Каких работниках? зачем нам определять как вы разделяете?
Каждый раз, когда мы разрабатываем новое ИТ-решение, нам необходимо учитывать и учитывать определенные архитектурные аспекты, которые являются неотъемлемой частью любого чертежа систем
Учитывать и учитывать и учитывать? А что за чертежи?
архитектура доступна для наблюдения, если она предоставляет подсказки и подсказки о своих внутренних условиях
Нужно больше подсказок. Особенно об условиях.
Код базируется на контролируемых версиях системы контроля версий
we need to go deeper...
Состояние должно быть бесхранилищным
Бесхранилищный... это шедевр
Сервисы должны быть легковесными и обработчиками.
На улице шли двое - дождь и я.
Приложение должно быть развернуто на нескольких экземплярах.
На нескольких экземплярах чего?
Административные задачи должны выполняться через один-time-процессы
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Как SRE, наша первая задача дня — обеспечить разделение и балансировку рабочей нагрузки между общими ресурсами и вспомогательными службами.
Первая задача дня - это вместо дейлика, каждое утро?
Germany's Blue Card Долгосрочная виза для высококвалифицированных работников, право на получение определяется по системе баллов. Получатель: работник Диплом: да Семья: да Продолжительность: 4 года Возобновляемый: да Стоимость: не указана Требования: высокий уровень владения немецким языком и ваша работа должна позволять вам зарабатывать не менее 50 800 € в год Время рассмотрения: не указано
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
Про совместимость API: > Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8 Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие: По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
Вроде уже была изобретена альтернатива в виде pickle ?
Кто-нибудь пользовался? Действительно ли нужна ещё одна новая версия?
Не лингвист, простой обыватель, только начинаю учить немецкий. Что-то даже после английского немецкий не кажется ни красивым, ни логичным, ни простым... хз, как люди запоминают какой пол у каких предметов в разных языках. Правила чтения - такое себе, да еще и с исключениями, по звучанию слова не всегда поймешь как оно пишется (а по написанию - не всегда поймешь как оно читается %) ) Еще и наплодили кучу диалектов, и очень крепко держатся за них.
В википедии (уж простите) высказывается мнение что как раз катаклизмы XXвека и убили Эсперанто на взлете
В начале 1920-х годов были предложения принять эсперанто в качестве рабочего языка Лиги Наций. Десять делегатов поддержали это предложение, но французский делегат Габриэль Аното проголосовал против. Ему не нравилось, что французский язык теряет свои позиции в качестве международного и он видел в эсперанто угрозу. Однако, спустя два года Лига Наций рекомендовала государствам-членам включить эсперанто в свои учебные планы. 1920-е годы многими историками оцениваются как период расцвета эсперанто-движения.
В СССР эсперанто активно распространялся в 1920-е годы, по предложению Льва Троцкого[10], он широко изучался как «язык мировой революции». Эсперанто активно использовался в сети «рабкоров» (рабочих корреспондентов), на этом языке велось радиовещание (в том числе внутреннее). В это время даже надписи на почтовых конвертах дублировались на двух языках, русском и эсперанто[11] (по некоторым свидетельствам такие открытки выходили и позже — например, в 1946 году[12]). Но с середины 1930-х годов активисты движения эсперанто подверглись репрессиям в СССР как «троцкисты», «шпионы» и «террористы»[13]. Многие советские эсперантисты, например, Николай Хохлов и Николай Кабанов, отошли от активной деятельности.
Последний адрес на доме репрессированного эсперантиста
В нацистской Германии с середины 1930-х годов национальные эсперанто-организации были распущены, а многие участники эсперанто-движения физически уничтожены. Адольф Гитлер писал в «Майн кампф»[14], что эсперанто был создан как универсальный язык для объединения еврейских диаспор. Создание свободной от евреев Национальной Германской эсперанто-лиги было недостаточно для умиротворения нацистов. Обучение эсперанто было запрещено в немецких лагерях для военнопленных во время Второй мировой войны.
Как результат, движение эсперантистов в СССР и Германии фактически прекратило существование.
А вы погуглите как выглядит испанская или немецкая клавиатура. Когда появляется потребность - начинают делать клавиатуры с какими надо символами. Да и сейчас есть и наклейки и гравировка.
Латиница - ужасный выбор, из популярных языков она подходит разве что итальянскому. Всем остальным банально не хватает букв для тех звуков, которые используются в языке. Потому у испанцев, немцев, чехов, поляков и прочих есть буквы выходящие за стандартные 26 букв латиницы. Кто-то, как французы, англичане и немцы вынужден использовать сочетания, а-ля deutsch. Брать латиницу = тащить страшное легаси, которое поломает всю архитектуру.
Если уж изобретать новый язык, то букв его алфавита должно хватать для всех используемых в нем звуков (и вот определить набор этих звуков, удобный для всех - не такая уж и простая задача, если конечно не ограничиться созданием языка только для привыкших к индоевропейской семье)
В таких случаях надо нажимать
Ctrl+Shift+V, откроется список всех последних скопированных строк, где можно будет выбрать предыдущий вариант.Есть еще такой проект: https://archivebox.io/
"ставишь плагин в свой Firefox и он автоматически сохраняет тебе на сервер всё, что ты смотрел в интернете."
сам пока еще не пробовал)
А с чего вы взяли что Роб Пайк умер в 2011 ?
Судя по википедии он до сих пор жив. И только в 2021 году уволился из Гугла. Его гитхаб до сих пор активен.
SD карты штука ненадежная, они и сами мрут, без зубов. А значит у вас будет бэкап ключа (образ карточки)
И всем будет понятно, что бэкап ключа где-то должен быть - поэтому есть смысл попытать(ся)
Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения (о чем и пишет автор обсуждаемой статьи, и с чем я согласен, исходя из своего личного многолетнего опыта)
А что такое "быстрота работы"? Разве не выполнение в соответствии с оценкой или быстрее? И если нет оценки - то нет и "быстроты".
Или вы предлагаете количество набираемых символов в секунду считать?
статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
это просто смешно. Вы недооцениваете разрабов. Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее". Возможно даже будет оставаться время на сериалы и леваки. Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна %))
И она вам показывает что:
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной.
"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
которая имеет мало общего с реальностью.
Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом.
"Законы Мёрфи", наверное, тоже все читали.
Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Точно лучше? Вообще, явно передавать что-то по ссылке надо, только если вам это действительно нужно. Например, если вам надо изменять в вызываемом методе/функции содержимое огромного массива, так чтобы это изменение сохранилось в вызывающем контексте. Но это весьма частный кейс, и возможно вы что-то делаете не так.
Вот так, без каких либо условий, всегда? Так себе совет. Используйте for в тех случаях, когда вы знаете для какой конкретно цели он вам нужен. Например, если вам надо итерируясь по огромному массиву менять его содержимое, так чтобы они сохранилось по завершению цикла... Что также достаточно редкий кейс.
Я то думал, что основной минус Тайваня - возможность военного конфликта с Китаем и вмешательством третьих сил.
А оказывается - существование налогов и омс... не уверен что многие захотят жить в тех странах, где сейчас нет таких "основных недостатков".
Это кто-то читал? Тем кто еще не читал, советую и не читать.
То ли кривой перевод, то ли сразу ChatGpt.
Если все-таки перевод, то поделитесь ссылкой на оригинал, может там будет понятнее.
Каких работниках? зачем нам определять как вы разделяете?
Учитывать и учитывать и учитывать? А что за чертежи?
Нужно больше подсказок. Особенно об условиях.
we need to go deeper...
Бесхранилищный... это шедевр
На улице шли двое - дождь и я.
На нескольких экземплярах чего?
один-time-процессы - интересный термин. В копилку к "бесхранилищный".
Первая задача дня - это вместо дейлика, каждое утро?
даже боюсь читать дальше...
Вы многое путаете. Бальной системы для BlueCard нет. Это для нового третьего способа "Chancenkarte" который только обсуждают и еще не приняли.
Диплом был обязателен не на 100%, раньше можно было показать опыт работы около 3х лет на должности, которая требует сопоставимого уровня знаний. Но сейчас это не работает для граждан РФ.
Продолжительность 4 года - это максимум на который дают блюкард, но бывает и меньше. Потом можно продлевать. Некоторые после 4-5 лет так и остаются на блюкард, и не получают ПМЖ по собственному желанию. Первые 2 года вид на жительство (по блюкард, не ПМЖ) привязан к работодателю, и поменять работу можно только согласовав новый контракт в администрации по делам иностранцев.
Высокий уровень владения немецким языком - нет такого требования на получения визы и временного вида на жительство по блю кард. Показать знание языка потребуется потом, когда будете подаваться на ПМЖ и гражданство. От уровня зависит то, как рано сможете подать документы. Сейчас в процессе рассмотрения закон о новых сроках, типа паспорт за три года, если сдадите немецкий на C2. Закон пока не принят.
Виза это хорошо, но нужна еще информация:
сколько времени надо провести в стране до получения ПМЖ (если это в принципе возможно) + условия сохранения ПМЖ (в некоторых странах достаточно выехать на полгода, чтобы потерять постоянный вид на жительство)
сколько времени до паспорта (если это в принципе возможно, некоторые страны не дают паспорт, кроме как по браку с гражданином(гражданкой))
есть ли разрешение на работу у супругов приехавших по воссоединению семьи
требования по знанию языков (далеко не в каждой стране будет комфортно только с английским, не все готовы учить язык на котором говорит меньше 1 млн человек в мире)
в тексте договора медицинского страхования.
Про совместимость API:
> Из возможностей, доступных в первом выпуске DragonFly отмечается поддержка протокола RESP2 и 130 команд Redis, что примерно соответствует функциональности выпуска Redis 2.8
Это было полгода назад. Разработчики постепенно добавляют поддержку команд из более новых версий Redis, но о полной совместимости говорить рано.
Про быстродействие:
По бенчмаркам команды Redis (ниже приводил ссылку на офсайт), они быстрее чем DragonFly. При этом они конечно запускали не один инстанс Redis на многопоточном процессоре, а несколько.
А вот еще одно небольшое сравнение redis vs keyDB, и тут тоже не вышло превосходства keyDB в 5-25х маркетинговых раз.