То есть, по вашему, айти - это чисто веб разработка? Причем на JS...
11.12.2022, 15:11
Типов людей всего 10. Те, кто понимает двоичную систему счисления, и те, кто не понимает.
У меня больше вопрос: как целую сферу свели к веб-разработке на JS?
Ведь даже если мы рассматриваем IT, как чисто "internet technologies", то это кроме Веб, еще и mobile разработка (как минимум).
Всегда есть front- и back-end и что первое, что второе может разрабатываться на множестве разных как синхронных, так и асинхронных языков. Mobile вообще имеет свой набор языков и т.д.
Ведь даже если мы рассматриваем IT, как чисто "internet technologies", то это кроме Веб, еще и mobile разработка (как минимум).
Всегда есть front- и back-end и что первое, что второе может разрабатываться на множестве разных как синхронных, так и асинхронных языков. Mobile вообще имеет свой набор языков и т.д.
да
Сам свел, сам спросил
callback hell = одна из лучших реализаций асинхронности вообще, понял+принял
дед, расскажи как там на фортране кодили? коллбеки уже давно не актуальны, как jquery и весь твой опыт написания фронта из 2015го. нормальные разработчики уже давно освоили промисы + async/await. даже на node поддержку промисов для большинства модулей прикрутили, хотя они относительно долго держались в этом отношении
так и промисы не идут ни в какое сравнение с асинхронщиной, например, из C#. За Java не поручусь, но по докам там не хуже.
как минимум, асинхронные задачи там реально выполняются в фоновых потоках, а не нитями в одном потоке. Даже в тормозном Python с его GIL нет такой дичи.
как минимум, асинхронные задачи там реально выполняются в фоновых потоках, а не нитями в одном потоке. Даже в тормозном Python с его GIL нет такой дичи.
Я кстати тоже про это слышал и сталкивался, но мне про кэш до сих пор неясна причина
Если с кэшем проблемы, то, скорее всего, его используют неправильно. Например, кэшируют, когда достаточно починить Н+1 и выкинуть кэш совсем. Или поллинг с диким кэшированием вместо пубсуба.
С датой/временем с современными библиотеками проблем почти нет, если приложение изначально под таймзоны писалось. Хотя есть опыт перевода 5-летнего приложения на мульти таймзоны, вроде вполне успешно.
Нейминг - это проблема, да. Я бы даже еще шире смотрел и добавил "компонентизацию" (хз как это правильно называется, когда нужно понять, в какой модуль новый функционал добавлять, иногда это очень неочевидно, и из-за этого страдает связанность).
С датой/временем с современными библиотеками проблем почти нет, если приложение изначально под таймзоны писалось. Хотя есть опыт перевода 5-летнего приложения на мульти таймзоны, вроде вполне успешно.
Нейминг - это проблема, да. Я бы даже еще шире смотрел и добавил "компонентизацию" (хз как это правильно называется, когда нужно понять, в какой модуль новый функционал добавлять, иногда это очень неочевидно, и из-за этого страдает связанность).
иногда достаточно починить алгоритм, добавить индекс, пять баксов в месяц на железо или сказать бухам "этот отчёт считается долго, быстрее не получится"
Но в реальности не всегда всё так просто, потому без кеша иногда не обойтись.
с датой-временем проблема, зачастую, не в библиотеках, а в ещё не наученых опытом програмистах. А так как нюансов работы с датой/временем много, то всегда есть вероятность внезапно открыть для себя что-то новое.
-- надо дату рождения хранить? не проблема, добавим dateTime поле в бд, а время будем отбрасывать. Мы везде используем dateTime, если не нужен timestamp.
-- как это "дата рождения не правильная? мы всё тестили, всё работало! Человек John Doe из America/New_York наверное ошибается.
-- ну ладно, ладно, кто ж знал, что будут клиенты из других поясов. Заменим dateTime на date. Уж дата есть дата.
-- что значит "дать возможность сохранять дату рождения без указания года"? у нас дата, туда без года нельзя. Ладно, подставим фейковый год, всё будет работать.
-- как это "неправильная дата рождения?" там ставится дата рождения, вот код. если дата не выбрана - ставим 0001 год, а потом заменяем при выводе. удобно. Нет, не проверял, фиксил из дому, а что тут может пойти не так то?! Какие ещё реформы Григория XIII ?
-- та блииин, как это "неправильная дата рождения"? вот, реформы прошли, заменяю год на 9999, да проверял сам, всё работало! нет, високосный год не проверял...
... и так дальше. То время события попадёт на несуществующее время (бо перевод стрелок), то часов в сутках не 24
Но в реальности не всегда всё так просто, потому без кеша иногда не обойтись.
с датой-временем проблема, зачастую, не в библиотеках, а в ещё не наученых опытом програмистах. А так как нюансов работы с датой/временем много, то всегда есть вероятность внезапно открыть для себя что-то новое.
-- надо дату рождения хранить? не проблема, добавим dateTime поле в бд, а время будем отбрасывать. Мы везде используем dateTime, если не нужен timestamp.
-- как это "дата рождения не правильная? мы всё тестили, всё работало! Человек John Doe из America/New_York наверное ошибается.
-- ну ладно, ладно, кто ж знал, что будут клиенты из других поясов. Заменим dateTime на date. Уж дата есть дата.
-- что значит "дать возможность сохранять дату рождения без указания года"? у нас дата, туда без года нельзя. Ладно, подставим фейковый год, всё будет работать.
-- как это "неправильная дата рождения?" там ставится дата рождения, вот код. если дата не выбрана - ставим 0001 год, а потом заменяем при выводе. удобно. Нет, не проверял, фиксил из дому, а что тут может пойти не так то?! Какие ещё реформы Григория XIII ?
-- та блииин, как это "неправильная дата рождения"? вот, реформы прошли, заменяю год на 9999, да проверял сам, всё работало! нет, високосный год не проверял...
... и так дальше. То время события попадёт на несуществующее время (бо перевод стрелок), то часов в сутках не 24
"две проблемы программирования" в таком виде в ру-сегменте сформулированы как минимум десятилетие назад.
В общем основную траблу сформулировал пан KoMaTo3 парой комментов выше.
чисто у меня (никаких хайлоадов и терабайтов данных в бд) дополнительную работу вызывает непрямое изменение данных в бд. Что-то каскадом удалилось? Пересобирай кеш для всего, что хотя бы теоретически могло измениться. Это всё не сложно, если не забывать делать.
тоесть проблема - понять, что данные изменились, и пересобрать нужную часть кеша.
В общем основную траблу сформулировал пан KoMaTo3 парой комментов выше.
чисто у меня (никаких хайлоадов и терабайтов данных в бд) дополнительную работу вызывает непрямое изменение данных в бд. Что-то каскадом удалилось? Пересобирай кеш для всего, что хотя бы теоретически могло измениться. Это всё не сложно, если не забывать делать.
тоесть проблема - понять, что данные изменились, и пересобрать нужную часть кеша.
А, ясно, проблемы orm/связной базы.
Просто когда руками работаешь как с базой, так и с кешем, любое каскадное удаление у тебя управляемо, и ты не просто чистишь нужный кеш по сущности, ты вообще удаляешь из кеша только элементы с участием определенных ид определенных сущностей.
Просто когда руками работаешь как с базой, так и с кешем, любое каскадное удаление у тебя управляемо, и ты не просто чистишь нужный кеш по сущности, ты вообще удаляешь из кеша только элементы с участием определенных ид определенных сущностей.
Кеши бывают разные. если кеш у тебя - абстрактный products.json.gzip, который отдаётся сервером как статика, а значительная часть внутрянки этого файла не просто достаётся из бд, а рассчитывается (например цены на основании складских остатков и курса убитого енота к мёртвому президенту) - тут только пересоздавать.
Чтобы написать коммент, необходимо залогиниться
