Хотя и полезно, спасибо, но хотелось бы ещё и рекомендации по самим библиотекам - что и как юзать. Почему pytest а не unittest, почему классы а не функциональные тесты, что лучше factory-boy или mommy/bakery. А чего б не взять tavern или postman это наше все. Если тест интеграции с Aws брать moto/boto или писать своё. И в конце - а где авто сборщик документации тестов а'ля swagger?
Существует ли Австрия или нет, но кожанные мешки, ее усиленно путают с Австралией.
У меня австрийский паспорт, летел из Калифорнии США в Швейцарию. Показываю паспорт на таможне.
Таможенник - как вы планируете попасть из Швейцарии в Австрию?
Я - Вот билет на поезд из аэропорта Швейцарии в мой город в Австрии.
Таможенник - Но не существует поездов из Швейцарии в Австрию!
Подтянулся второй таможенник, они открыли бинг и стали бинглить существует ли такая страна Австрия и где она находится. Слава богу, тогда еще бинг не подозревал, что Австралии не существует, и предположил, что Австралия - это не Австрия.
А я еще ржал над футболками "no kangaroos in Austria".
Я не понял, а где timeout в requests в завершающем примере. Нигде? Тогда: If no timeout is specified explicitly, requests do not time out. И уже не важно какой там токен. Сидим ждём. Ну и пока сидим и ждём, переписываем с реализацией настоящего прекращения по timeout.
После того, как перепишем, проверяем реализацию. Поскольку параметр timeout в requests не учитывает время после начала передачи данных, и есть риск опять сидеть и ждать.
Я давно уже гражданин, супруга с Aufenthaltstitel.
<sarcazm mode=on>
Что бы воспользоваться подобными сервисами - нужно потрудиться и показать подтверждение многомесячного дохода ниже прожиточного минимума, достичь невозможности оплаты коммуналки и намного задолжать арендную плату.
Но после того как ты всего этого достигнешь - жизнь заиграет новыми красками. Каждое предложение по работе будет выглядеть восхитительным. Любое собеседование из 12 этапов - будет казаться недолгим и позитивным.
Короче - хочешь новых ощущений - резко стань нищим с 2мя детьми. Дальше все пойдет как по маслу! Не благодари.
Абсолютно подтверждаю. Hr + Hacker Rank (текстовый редактор выбесил, у меня время тикает, а он мне скобки ставит, куда не надо) + Домашка + Tech две штуки + CTO.
Мне понравилось т.к. было все позитивно но время пожирает неимоверно.
Я сейчас такую тупую вещь спрошу. А зачем может понадобиться так сложно работать с классами?
Например, есть у вас много UL в них много LI. Поставил на <UL class="card"> и выбирай все первые LI: ul.card > li
Ну собственно, как и пример с синим элементом. Вам нужен синий третьим или последним? Потому как, если дать третьему элементу модификатор синей подложки, и потом добавить четвертый, то подложка будет у третьего. Потому как привязка свойства идет к конкретному блоку, а не к макету.
Кстати, по примерам видно, что речь скорее идет про ABEM, потому как в настоящем BEM модификаторы идут через "--". Пруф.
Спасибо, за статью, за четыре года знакомства и попыток пользоваться этой методологией, я все еще не прочувствовал, какое удобство добавляет БЭМ? Сeйчас у меня в проекте около 230 компонентов, в них применены bootstrap и, позже, tailwind и я так и не осознал, что бы мне дал переезд на BEM или ABEM.
@yudeek - а что мешало создать компонент "элемент списка". Хранит свой стейт внутри, при необходимости перерендер только одного компонента, DRY опять же, код проще:
Я вижу эту статью, как не совсем корректное применение идеи Абрахама Маслоу к коммерческому программированию. Почему не совсем корректное - потому, что в изначальной идее фундаментом являются безусловные предпосылки личности каждого. В идее статьи смешались бизнес задачи владельца бизнеса и его безусловные стремления и задачи программиста, и не важно, если это одна и та же персона. Но не суть. Если допустить таки идею, что идея пирамиды потребностей применима, то становится понятно, что закладывал автор: В Пирамиде Маслоу есть несколько уровней и, казалось бы, обеспечил себя жратвой и потомством, и остановись, но нет - сытому и размножившемуся индивиду надо уже развитие и признание. Так и в идее статьи автор, предположительно, хочет добавить другие потребности, какие должны быть удовлетворены, после удовлетворения потребностей бизнеса. И именно тут и кроется нестыковка. Задачи бизнеса достигнуты - остановись. Это бизнес проект а не личность. Но нет, давайте добавим тестирование и простой саппорт, как надстройку к потребностям. Хотя на самом деле - эти задачи тоже должны быть задачами бизнеса, поскольку, как и было разумно отмечено в комментариях, не каждому бизнесу это надо. Например, я пишу MVP для проверки бизнес идеи. Прошло плохо - убил проект. Не рефакторнул, а просто отказался! О тестах и улучшении речи даже не идёт. Только так и работает в бизнесе, а в применении к личностям подобный подход, минимум, аморален. Хотя бы поэтому идея с потребностями не сработает в коммерческом программировании.
Ээ. Какое смелое название ги-пердев.
А по делу: Андроид 10, Huawei, жесты отключены. Съехал влево, вижу экран с текстом "Артефакты с хакатонов". А обратно то как? Влево вправо не работает. Экран обновлять?
Согласен, что журнал изменений - отличный инструмент. Он беспристрастно фиксирует какое изменение было сделано, кем и когда. Но журнал никогда не скажет - работает ли код с изменениями или нет.
А вот тут не соглашусь. Фиксацией текущего состояния я помогаю себе найти, что сломалось при рефакторинге кода. Иначе - рефакторнул микро тех должок, на автомате, при пролистывании, и через несколько часов рефакторинга уже непонятно, почему не заводится. Мини юниты здорово спасают нервы на огромном проекте и уменьшают время рефакторинга, как бы странно это не казалось коллегам только начинающим работать в том же проекте.
Ребят, вам бы программиста. А то сил нет это видеть. Ну что в форме 8-кратная копипаста, неужели не ёкнуло ни у кого? Ну или что в stacks несколько запросов в базу на один объект. Или один и тот же файл 100 раз открываете - у вас кеширование результатов не изобрели что ли? А RAW sql в коде админстратора? Ну прям совсем нетестируемо не читаемо и неподерживаемо. Я не сомневаюсь, что работает. Но в данных примерах это работает не потому что, а вопреки.
Не совсем. Исторически могло сложиться так, что не было предпосылок для образования новой стабильной формы. Исследовали ожидали, что 8+20 — это стабильно. Если бы сработало — стало б понятно, что может привести к появлению этого изотопа и, вероятно, нашли бы и в природе. Тут скорее речь о том, что ядро не держит 20 ожидаемых нейтронов. Я не знаю откуда пошло число 20 для кислорода. В этом случае сотношение нейтронов/протонов слишком высокое, ядро перегружено нейтральными элементами. Будь я ядром — я бы точно начал сбрасывать балласт. Что кислороды 28/27 и сделали. Физики плиз — объясните, откуда 20 взялось. У меня предок занимался изотопами я его слушал краем уха, но сейчас спросить уже некого 😔
Хотя и полезно, спасибо, но хотелось бы ещё и рекомендации по самим библиотекам - что и как юзать. Почему pytest а не unittest, почему классы а не функциональные тесты, что лучше factory-boy или mommy/bakery. А чего б не взять tavern или postman это наше все. Если тест интеграции с Aws брать moto/boto или писать своё. И в конце - а где авто сборщик документации тестов а'ля swagger?
с Австрией вообще все сложно:
Причина Первой Мировой: Застрелили одного австрийца.
Причина Второй Мировой: Не застрелили одного австрийца.
У вас SECRET_KEY сполз. Но это не страшно. А вот то, что тестов нет никаких - это беда. Общая. У многих.
Существует ли Австрия или нет, но кожанные мешки, ее усиленно путают с Австралией.
У меня австрийский паспорт, летел из Калифорнии США в Швейцарию. Показываю паспорт на таможне.
Таможенник - как вы планируете попасть из Швейцарии в Австрию?
Я - Вот билет на поезд из аэропорта Швейцарии в мой город в Австрии.
Таможенник - Но не существует поездов из Швейцарии в Австрию!
Подтянулся второй таможенник, они открыли бинг и стали бинглить существует ли такая страна Австрия и где она находится. Слава богу, тогда еще бинг не подозревал, что Австралии не существует, и предположил, что Австралия - это не Австрия.
А я еще ржал над футболками "no kangaroos in Austria".
Я не понял, а где timeout в requests в завершающем примере. Нигде? Тогда: If no timeout is specified explicitly, requests do not time out. И уже не важно какой там токен. Сидим ждём. Ну и пока сидим и ждём, переписываем с реализацией настоящего прекращения по timeout.
После того, как перепишем, проверяем реализацию. Поскольку параметр timeout в requests не учитывает время после начала передачи данных, и есть риск опять сидеть и ждать.
Какой же это ящер? Это же Альф!!! Ээх молодёжь, классику забывать стали 😭
Я давно уже гражданин, супруга с Aufenthaltstitel.
<sarcazm mode=on>Что бы воспользоваться подобными сервисами - нужно потрудиться и показать подтверждение многомесячного дохода ниже прожиточного минимума, достичь невозможности оплаты коммуналки и намного задолжать арендную плату.
Но после того как ты всего этого достигнешь - жизнь заиграет новыми красками. Каждое предложение по работе будет выглядеть восхитительным. Любое собеседование из 12 этапов - будет казаться недолгим и позитивным.
Короче - хочешь новых ощущений - резко стань нищим с 2мя детьми. Дальше все пойдет как по маслу! Не благодари.
</ sarcazm>Можно не извиняться, Я стараюсь находить позитив даже в той непростой ситуации, в которой сейчас нахожусь.
AMS Arbeitslosengeld (пособие по безработице).
BH Mindestsicherung (пособие по нищете).
DELO-Förderung (пособие для защиты от выселения).
Caritas Familiensсhirm (пособие для семей с доходом ниже уровня самообеспечения).
Жить на вышеперечисленные доходы не получится, но выжить можно.
Абсолютно подтверждаю. Hr + Hacker Rank (текстовый редактор выбесил, у меня время тикает, а он мне скобки ставит, куда не надо) + Домашка + Tech две штуки + CTO.
Мне понравилось т.к. было все позитивно но время пожирает неимоверно.
p.s. Результат жду.
Вчера была статья новость про chatgpt и dalee, неявно подтверждающая, что текст капсом имеет приоритет.
может просто изначально речь шла только о лицензированных копиях, вот потому так мало?
Я сейчас такую тупую вещь спрошу. А зачем может понадобиться так сложно работать с классами?
Например, есть у вас много UL в них много LI. Поставил на <UL class="card"> и выбирай все первые LI:
ul.card > liНу собственно, как и пример с синим элементом. Вам нужен синий третьим или последним? Потому как, если дать третьему элементу модификатор синей подложки, и потом добавить четвертый, то подложка будет у третьего. Потому как привязка свойства идет к конкретному блоку, а не к макету.
Кстати, по примерам видно, что речь скорее идет про ABEM, потому как в настоящем BEM модификаторы идут через "--". Пруф.
Спасибо, за статью, за четыре года знакомства и попыток пользоваться этой методологией, я все еще не прочувствовал, какое удобство добавляет БЭМ? Сeйчас у меня в проекте около 230 компонентов, в них применены bootstrap и, позже, tailwind и я так и не осознал, что бы мне дал переезд на BEM или ABEM.
@Tyusha- Вот спасибо, буду цитировать:
@yudeek - а что мешало создать компонент "элемент списка". Хранит свой стейт внутри, при необходимости перерендер только одного компонента, DRY опять же, код проще:
нотация работает как в Vue.js 2, так и в Vue.js 3.
Я вижу эту статью, как не совсем корректное применение идеи Абрахама Маслоу к коммерческому программированию. Почему не совсем корректное - потому, что в изначальной идее фундаментом являются безусловные предпосылки личности каждого. В идее статьи смешались бизнес задачи владельца бизнеса и его безусловные стремления и задачи программиста, и не важно, если это одна и та же персона.
Но не суть. Если допустить таки идею, что идея пирамиды потребностей применима, то становится понятно, что закладывал автор:
В Пирамиде Маслоу есть несколько уровней и, казалось бы, обеспечил себя жратвой и потомством, и остановись, но нет - сытому и размножившемуся индивиду надо уже развитие и признание.
Так и в идее статьи автор, предположительно, хочет добавить другие потребности, какие должны быть удовлетворены, после удовлетворения потребностей бизнеса.
И именно тут и кроется нестыковка. Задачи бизнеса достигнуты - остановись. Это бизнес проект а не личность. Но нет, давайте добавим тестирование и простой саппорт, как надстройку к потребностям. Хотя на самом деле - эти задачи тоже должны быть задачами бизнеса, поскольку, как и было разумно отмечено в комментариях, не каждому бизнесу это надо. Например, я пишу MVP для проверки бизнес идеи. Прошло плохо - убил проект. Не рефакторнул, а просто отказался! О тестах и улучшении речи даже не идёт. Только так и работает в бизнесе, а в применении к личностям подобный подход, минимум, аморален. Хотя бы поэтому идея с потребностями не сработает в коммерческом программировании.
Ээ. Какое смелое название ги-пердев.
А по делу: Андроид 10, Huawei, жесты отключены. Съехал влево, вижу экран с текстом "Артефакты с хакатонов". А обратно то как? Влево вправо не работает. Экран обновлять?
Мне показалось, что ход разработки очень похож на ТДД, разница только в том что с разработкой по ТДД ещё и тесты готовы.
За шаги спасибо, предпоследний часто пропускаю, но зря. Мне понравилось, что Сначала проверяем шаблон действия и только потом имплементацию.
Согласен, что журнал изменений - отличный инструмент. Он беспристрастно фиксирует какое изменение было сделано, кем и когда. Но журнал никогда не скажет - работает ли код с изменениями или нет.
А вот тут не соглашусь. Фиксацией текущего состояния я помогаю себе найти, что сломалось при рефакторинге кода. Иначе - рефакторнул микро тех должок, на автомате, при пролистывании, и через несколько часов рефакторинга уже непонятно, почему не заводится. Мини юниты здорово спасают нервы на огромном проекте и уменьшают время рефакторинга, как бы странно это не казалось коллегам только начинающим работать в том же проекте.
Ребят, вам бы программиста. А то сил нет это видеть. Ну что в форме 8-кратная копипаста, неужели не ёкнуло ни у кого? Ну или что в stacks несколько запросов в базу на один объект. Или один и тот же файл 100 раз открываете - у вас кеширование результатов не изобрели что ли? А RAW sql в коде админстратора? Ну прям совсем нетестируемо не читаемо и неподерживаемо. Я не сомневаюсь, что работает. Но в данных примерах это работает не потому что, а вопреки.
Не совсем. Исторически могло сложиться так, что не было предпосылок для образования новой стабильной формы. Исследовали ожидали, что 8+20 — это стабильно. Если бы сработало — стало б понятно, что может привести к появлению этого изотопа и, вероятно, нашли бы и в природе. Тут скорее речь о том, что ядро не держит 20 ожидаемых нейтронов. Я не знаю откуда пошло число 20 для кислорода. В этом случае сотношение нейтронов/протонов слишком высокое, ядро перегружено нейтральными элементами. Будь я ядром — я бы точно начал сбрасывать балласт. Что кислороды 28/27 и сделали. Физики плиз — объясните, откуда 20 взялось. У меня предок занимался изотопами я его слушал краем уха, но сейчас спросить уже некого 😔