О да, автор статьи ещё не понимает, что реальной проблемой его ребенка станет смартфон, в котором его чадо будет жить, и все его принципы и мечты о воспитании накроются медным тазом...
Всегда представлял себе ток как очень плотное броуновское движение, где частицы движутся со скоростью света, и где суммарный вектор всех электронов даёт направление и "силу" тока. Да, сильно упрощённо, но по крайней мере не даёт сильно заблуждаться в таких вопросах, как "почему ток возникает практически мгновенно при включении рубильника, но скорость "перекачивания" электронов через сечение проводника измеряется в миллиметрах в секунду", или почему потенциал незамкнутого проводника выравнивается "моментально", но при этом вроде как ток в проводнике не возникае, или, например, почему провода в розетке сами по себе (без нагрузки) не греются, ведь в нем постоянно меняется потенциал, и плотность электронов на конце проводника постоянно меняется, а значит ток, увеличивающий и уменьшающий плотность, должен всегда присутствовать.
Через электростанцию частицы на самом деле едва движутся, скорее болтаются туда сюда. Но постоянный ток - это действительно направленное движение частиц, и ни каких волн. Волны - это побочный эффект переменного тока, так что базовое определение электрического тока вполне себе верное.
Под путешествием во времени обыватель понимает перемещение в прошлое или будущее, а не замедление настоящего. Замедление возможно, перемещение - нет. Из-за замедления и нужна поправка в GPS.
Вариант "не рыба, ни мясо" хорош, но имеет свою цену в добавленной сложности на небольших проектах. Например, если у вас проект, умещающийся в одном .net solution с 5ю сервисами и 50ю таблицами в БД, то, EntityFramework гораздо проще использовать, т.к. model = entities, миграции создаются автоматически, проблема с /dev/prod/stg отсутствует, и самое главное, рефакторинг кода происходит совершенно просто и безопасно. Идеально для стартапа.
Вариант с db-first точно не удобнее в таких небольших проектах.
Если же речь про зоопарк технологий с сотнями микросервисов, то, условно говоря, вынесение "ef entities" из entity framework в самостоятельную сущность с возможностью генерации entities обратно в код, да ещё и на разных языках - это логично, хотя и теряется удобство автоматического рефакторинга кода при изменении модели.
Вариант с db-first не удобнее, чем model-first для больших проектов.
Так где же db-first удобнее? Если model-first получит распространение, о db-first можно будет забыть?
Хорошая зарплата перестаёт удовлетворять сама по себе довольно быстро. Через год-другой хорошая ЗП по ощущениям становится просто ЗП. Может вы бы и радовались тому, что все вокруг нищие, но далеко не всем программистам это добавляет счастья.
На одной из прошлых работ мне приходилось ездить в командировки и иногда сидеть прямо за соседним столом с человеком, который использовал мой софт. Это невероятное чувство, даёт столько мотивации и идей, как улучшить программу... К сожалению, больше такого не было, и программы пишутся в пустоту без обратной связи...
У покрытия юнит тестами есть 2 стороны. Первая - это повышение надёжности и сопровождаемости кода, тут бесспорно. Но на этом по сути и всё. Дальше идут недостатки:
Увеличение времени написания кода. Тут, конечно, не всё однозначно. Если участок кода - это алгоритм, который не укладывается легко в голове разработчика, то юнит тесты наоборот ускорят процесс. Но чаще всего код простой, вида, возьми отсюда, положи сюда, дёрни этот сервис, дёрни тот. Юнит тесты такого кода превращаются в сплошные моки, которые потом задолбаешься сопровождать. Например, в стартапе с 1-2 сеньёрами покрытие юнит тестами всего и вся только похоронит стартап. Так что it depends.
Вносить изменения сложнее, если они меняют интерфейсную часть, не говоря уже о серьёзных переделках.
Юнит тесты на UI - это отдельный вид извращенства.
Ещё есть такая проблема, что программист пишет юнит тесты формально, т.е. чтобы только был прогон всех строчек кода, но при этом тесты сами по себе не имеющие самостоятельного смысла. Например, тест, проверяющий, что метод контроллера вызывает метод сервиса. Да, логчино, что такой вызов должен быть, но такой тест даёт всего-лишь ложное покрытие, не проверяющее ни какой логики работы метода (т.е. формально весь код метода выполняется и помечается в coverage report, но по факту можно изменить кучу мест в этом методе, лишь бы не трогать вызов сервиса, и тогда сломанный метод будет вполне себе проходить все тесты).
Не исключаю того, что чем больше проект и программистов на нём, тем больше смысла в том, чтобы делать всё под одну гребёнку (тащить все best practices), потому-что разбираться с каждым по-отдельности сложно, но не нужно считать это применимым всегда и везде, нужно более рационально подходить. Иногда рациональнее отвёркой вкрутить несколько саморезов, чем пытаться впихнуть шуруповёрт.
Поделитесь секретом, как? У меня работает только по мелочи, если что-то сложное, то начинается жесть похожая на то, что описал автор в начале статьи. Самое противное, что ИИ пришет код в лоб: как ты его попросил, так и пишет - прямо бесит, что ты всё за него должен думать.
Хочется думать, что ваш мемный котёнок плачет от того, что у него конфетку отобрали, но мы то знаем, что котёнок просто болен, и у него воспалены глаза.
А так статью не читал, котёнка жалко слишком стало.
Мне показалось, или у вас приложение - что-то типа интернет-магазина? Понимаете сколько контекста уже есть в ИИ по поводу интернет-магазинов? Попробуйте применить такой же подход, условно говоря, в разработке ПО для полёта на Юпитер. В contex window вашего ИИ просто не влезет всё, что нужно понимать в этой области.
Читая статью вспомнил себя, когда только начал работать программистом, года в 22, наверное. До этого программинг был хобби, лет с 10, и считал себя уже шарящим в этом деле. Ох сколько же открытий предстояло мне сделать... Как же наивен я был...
Но мне повезло с тем, что я начинал с более низкоуровневых языков, типа, C++, Delphi, Assembler в конце концов, где ты просто вынужден был понимать как твои данные располагаются в оперативной памяти, и как доступ к ним из разных потоков мог просто в какаху замешать все твои данные - оттуда и пошли все эти синхронизации, блокировки, семафоры, мьютексты и т.п., а также всякие сборщики мусора. И все последующие новые языки и фреймворки я всегда пропускал через фильтр "а как это работает на базовом уровне?"
Автор, вы правильно всё делаете: изучайте, удивляйтесь, делайте открытия, только рановато вы вышли со своим мнением на такую аудиторию.
Проблема вашей статьи в том, что она, простите, бесполезна для кого бы то ни было, кроме лично вас. Новички ничего не поймут и не почерпнут. Бывалые сразу поймут вашу наивность и либо "зароют", либо попытаются "понять, простить, и отпустить".
Кстати, если хотите познать дзен программирования, вам нужно практиковать более "мощные" языки, типа C#, Java, а ещё лучше спуститься на уровень C/C++ и asm. Когда под отладчиком вы увидите по каким адресам в оперативной памяти лежат ваши данные, и увидите как пошагово эти данные меняются, тогда вы сможете сказать, что вы действительно понимаете как именно работает ваша программа на материальном уровне (ну, почти - ещё бы конечно в электронике немного разбираться и вручную спаять схему счетчика с регистрами, хотябы, но это уж чтоб точно сказать "я понимаю этот мир" :) )
Прелесть статьи в том, что она не помогает понять фундаментальные принципы нейросетей и GPT, на нём основанного, зато можно скопипастить код и ничего не понимая начать обучать нейронку.
О да, автор статьи ещё не понимает, что реальной проблемой его ребенка станет смартфон, в котором его чадо будет жить, и все его принципы и мечты о воспитании накроются медным тазом...
Всегда представлял себе ток как очень плотное броуновское движение, где частицы движутся со скоростью света, и где суммарный вектор всех электронов даёт направление и "силу" тока. Да, сильно упрощённо, но по крайней мере не даёт сильно заблуждаться в таких вопросах, как "почему ток возникает практически мгновенно при включении рубильника, но скорость "перекачивания" электронов через сечение проводника измеряется в миллиметрах в секунду", или почему потенциал незамкнутого проводника выравнивается "моментально", но при этом вроде как ток в проводнике не возникае, или, например, почему провода в розетке сами по себе (без нагрузки) не греются, ведь в нем постоянно меняется потенциал, и плотность электронов на конце проводника постоянно меняется, а значит ток, увеличивающий и уменьшающий плотность, должен всегда присутствовать.
Вы не путаете переменный ток с постоянным?
Через электростанцию частицы на самом деле едва движутся, скорее болтаются туда сюда. Но постоянный ток - это действительно направленное движение частиц, и ни каких волн. Волны - это побочный эффект переменного тока, так что базовое определение электрического тока вполне себе верное.
Под путешествием во времени обыватель понимает перемещение в прошлое или будущее, а не замедление настоящего. Замедление возможно, перемещение - нет. Из-за замедления и нужна поправка в GPS.
Какая нафиг дислексия и дисграфия?.. Да, в статье имеются ошибки, но ничего общего с этими "дис".
Вариант "не рыба, ни мясо" хорош, но имеет свою цену в добавленной сложности на небольших проектах. Например, если у вас проект, умещающийся в одном .net solution с 5ю сервисами и 50ю таблицами в БД, то, EntityFramework гораздо проще использовать, т.к. model = entities, миграции создаются автоматически, проблема с /dev/prod/stg отсутствует, и самое главное, рефакторинг кода происходит совершенно просто и безопасно. Идеально для стартапа.
Вариант с db-first точно не удобнее в таких небольших проектах.
Если же речь про зоопарк технологий с сотнями микросервисов, то, условно говоря, вынесение "ef entities" из entity framework в самостоятельную сущность с возможностью генерации entities обратно в код, да ещё и на разных языках - это логично, хотя и теряется удобство автоматического рефакторинга кода при изменении модели.
Вариант с db-first не удобнее, чем model-first для больших проектов.
Так где же db-first удобнее? Если model-first получит распространение, о db-first можно будет забыть?
Хорошая зарплата перестаёт удовлетворять сама по себе довольно быстро. Через год-другой хорошая ЗП по ощущениям становится просто ЗП. Может вы бы и радовались тому, что все вокруг нищие, но далеко не всем программистам это добавляет счастья.
На одной из прошлых работ мне приходилось ездить в командировки и иногда сидеть прямо за соседним столом с человеком, который использовал мой софт. Это невероятное чувство, даёт столько мотивации и идей, как улучшить программу... К сожалению, больше такого не было, и программы пишутся в пустоту без обратной связи...
Вы действительно считаете, что государство блокирует телеграм для защиты граждан?
У покрытия юнит тестами есть 2 стороны. Первая - это повышение надёжности и сопровождаемости кода, тут бесспорно. Но на этом по сути и всё. Дальше идут недостатки:
Увеличение времени написания кода. Тут, конечно, не всё однозначно. Если участок кода - это алгоритм, который не укладывается легко в голове разработчика, то юнит тесты наоборот ускорят процесс. Но чаще всего код простой, вида, возьми отсюда, положи сюда, дёрни этот сервис, дёрни тот. Юнит тесты такого кода превращаются в сплошные моки, которые потом задолбаешься сопровождать. Например, в стартапе с 1-2 сеньёрами покрытие юнит тестами всего и вся только похоронит стартап. Так что it depends.
Вносить изменения сложнее, если они меняют интерфейсную часть, не говоря уже о серьёзных переделках.
Юнит тесты на UI - это отдельный вид извращенства.
Ещё есть такая проблема, что программист пишет юнит тесты формально, т.е. чтобы только был прогон всех строчек кода, но при этом тесты сами по себе не имеющие самостоятельного смысла. Например, тест, проверяющий, что метод контроллера вызывает метод сервиса. Да, логчино, что такой вызов должен быть, но такой тест даёт всего-лишь ложное покрытие, не проверяющее ни какой логики работы метода (т.е. формально весь код метода выполняется и помечается в coverage report, но по факту можно изменить кучу мест в этом методе, лишь бы не трогать вызов сервиса, и тогда сломанный метод будет вполне себе проходить все тесты).
Не исключаю того, что чем больше проект и программистов на нём, тем больше смысла в том, чтобы делать всё под одну гребёнку (тащить все best practices), потому-что разбираться с каждым по-отдельности сложно, но не нужно считать это применимым всегда и везде, нужно более рационально подходить. Иногда рациональнее отвёркой вкрутить несколько саморезов, чем пытаться впихнуть шуруповёрт.
Когда тебе 22 года и ты полон сил, тебе кажется, что всё личное не важно, что нужно достигать целей, а не сопли распускать...
Как странно звучит слово "ошибка" по отношению к дельте в глазах программиста... )
Поделитесь секретом, как? У меня работает только по мелочи, если что-то сложное, то начинается жесть похожая на то, что описал автор в начале статьи. Самое противное, что ИИ пришет код в лоб: как ты его попросил, так и пишет - прямо бесит, что ты всё за него должен думать.
Показалось "мануальный терапевт", ан нет, мануальное тестирование, ю шуд неве юз рашн вордз лайк 'ручное'...
Хочется думать, что ваш мемный котёнок плачет от того, что у него конфетку отобрали, но мы то знаем, что котёнок просто болен, и у него воспалены глаза.
А так статью не читал, котёнка жалко слишком стало.
Т.е. блокировать по подозрению? А если я скачиваю большой файл? Может тогда проще просто блокировать все зарубежные IP и не париться? ))
Наехали на Apple? 😁 Лучше посмотрите как Epic Games наехал на Apple https://ru.wikipedia.org/wiki/Epic_Games_vs._Apple
Их наезд немного приземлил Apple, осмелитесь ли вы так же?
Мне показалось, или у вас приложение - что-то типа интернет-магазина? Понимаете сколько контекста уже есть в ИИ по поводу интернет-магазинов? Попробуйте применить такой же подход, условно говоря, в разработке ПО для полёта на Юпитер. В contex window вашего ИИ просто не влезет всё, что нужно понимать в этой области.
Читая статью вспомнил себя, когда только начал работать программистом, года в 22, наверное. До этого программинг был хобби, лет с 10, и считал себя уже шарящим в этом деле. Ох сколько же открытий предстояло мне сделать... Как же наивен я был...
Но мне повезло с тем, что я начинал с более низкоуровневых языков, типа, C++, Delphi, Assembler в конце концов, где ты просто вынужден был понимать как твои данные располагаются в оперативной памяти, и как доступ к ним из разных потоков мог просто в какаху замешать все твои данные - оттуда и пошли все эти синхронизации, блокировки, семафоры, мьютексты и т.п., а также всякие сборщики мусора. И все последующие новые языки и фреймворки я всегда пропускал через фильтр "а как это работает на базовом уровне?"
Автор, вы правильно всё делаете: изучайте, удивляйтесь, делайте открытия, только рановато вы вышли со своим мнением на такую аудиторию.
Проблема вашей статьи в том, что она, простите, бесполезна для кого бы то ни было, кроме лично вас. Новички ничего не поймут и не почерпнут. Бывалые сразу поймут вашу наивность и либо "зароют", либо попытаются "понять, простить, и отпустить".
Кстати, если хотите познать дзен программирования, вам нужно практиковать более "мощные" языки, типа C#, Java, а ещё лучше спуститься на уровень C/C++ и asm. Когда под отладчиком вы увидите по каким адресам в оперативной памяти лежат ваши данные, и увидите как пошагово эти данные меняются, тогда вы сможете сказать, что вы действительно понимаете как именно работает ваша программа на материальном уровне (ну, почти - ещё бы конечно в электронике немного разбираться и вручную спаять схему счетчика с регистрами, хотябы, но это уж чтоб точно сказать "я понимаю этот мир" :) )
Прелесть статьи в том, что она не помогает понять фундаментальные принципы нейросетей и GPT, на нём основанного, зато можно скопипастить код и ничего не понимая начать обучать нейронку.