В айти есть только 3 проклятые вещи: 1. Таймзоны 2. Протухшие сертификаты 4. И ошибка на единицу / it-юмор :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

it-юмор geek 

В айти есть только 3 проклятые вещи:
1.	Таймзоны
2.	Протухшие сертификаты 4. И ошибка на единицу
3.	Асинхронность,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и  айтишный юмор


Подробнее
В айти есть только 3 проклятые вещи: 1. Таймзоны 2. Протухшие сертификаты 4. И ошибка на единицу 3. Асинхронность
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
Развернуть
То есть, по вашему, айти - это чисто веб разработка? Причем на JS...
Paascal Paascal 11.12.202218:11 ответить ссылка 2.2
асинхронность в JS сейчас как раз не проклятая вещь, а, как говорят случайные знающие люди, одна из лучших реализаций асинхронности вообще.
fokk fokk 11.12.202218:18 ответить ссылка -1.0
Вообще не в тему
че не в тему? Шутка про асинхронность зачем-то переводится в срач про js. Да кому какая разница какая там асинхронность в жаваскриптах?
tolkotak tolkotak 11.12.202219:44 ответить ссылка -6.7
Типов людей всего 10. Те, кто понимает двоичную систему счисления, и те, кто не понимает.
а еще есть те, кто знают оди яп и пишут о нем на каждом углу
tolkotak tolkotak 12.12.202200:44 ответить ссылка -0.7
Я про то, что список с 0 должен был быть.
У меня больше вопрос: как целую сферу свели к веб-разработке на JS?
Ведь даже если мы рассматриваем IT, как чисто "internet technologies", то это кроме Веб, еще и mobile разработка (как минимум).
Всегда есть front- и back-end и что первое, что второе может разрабатываться на множестве разных как синхронных, так и асинхронных языков. Mobile вообще имеет свой набор языков и т.д.
Paascal Paascal 11.12.202218:25 ответить ссылка -0.8
Internet или все таки information technology?
ffs_ffs ffs_ffs 11.12.202218:36 ответить ссылка 12.2
да
Я же указал "даже если"
да ну, бред какой-то
Ahiru Ahiru 11.12.202219:09 ответить ссылка 0.3
Асинхронность далеко не только в веб-разработке JS есть. В общем случае многпоточность - та же самая проблема.
wataru wataru 11.12.202218:58 ответить ссылка 1.8
Внезапно появилось куча js фреймворков и вот мы здесь...
doctype doctype 11.12.202220:02 ответить ссылка -0.6
Сам свел, сам спросил
веб-сфера далеко не только на js.
Звучит как замануха в секту.
callback hell = одна из лучших реализаций асинхронности вообще, понял+принял
дед, расскажи как там на фортране кодили? коллбеки уже давно не актуальны, как jquery и весь твой опыт написания фронта из 2015го. нормальные разработчики уже давно освоили промисы + async/await. даже на node поддержку промисов для большинства модулей прикрутили, хотя они относительно долго держались в этом отношении
fokk fokk 12.12.202201:39 ответить ссылка -0.2
так и промисы не идут ни в какое сравнение с асинхронщиной, например, из C#. За Java не поручусь, но по докам там не хуже.

как минимум, асинхронные задачи там реально выполняются в фоновых потоках, а не нитями в одном потоке. Даже в тормозном Python с его GIL нет такой дичи.
Нет вроде, а почему тебе так показалось?
kronya kronya 11.12.202218:53 ответить ссылка -0.3
При чем тут веб-разработка и таймзоны? Это типичная ошибка девопса-новичка, когда ваши инстансы работают в какой-либо зоне, кроме utc+0.
Могут быть твои все в гринвиче, а вот те, с которыми твоё ПО общается - нет.
И вот эти, вторые - они левых контор.
Что из перечисленного относится только к веб-разработке? Или конкретно к JS?
Ssipak Ssipak 12.12.202203:25 ответить ссылка 0.3
только две
1. нейминг
2. инвалидация кеша

всё остальное - кривые руки.
всё остальное, кроме работы с датой/временем
ЖЖБа ЖЖБа 11.12.202218:54 ответить ссылка 1.7
Я кстати тоже про это слышал и сталкивался, но мне про кэш до сих пор неясна причина
С кешем проблема, как правильно понять, когда его нужно переформировать. Слишком редко - устаревшие данные, слишком часто - сервер охуеет, при каждых UPDATE/INSERT/DELETE (если мы про БД) - вообще забей, всё-равно что без кеша.
Если с кэшем проблемы, то, скорее всего, его используют неправильно. Например, кэшируют, когда достаточно починить Н+1 и выкинуть кэш совсем. Или поллинг с диким кэшированием вместо пубсуба.

С датой/временем с современными библиотеками проблем почти нет, если приложение изначально под таймзоны писалось. Хотя есть опыт перевода 5-летнего приложения на мульти таймзоны, вроде вполне успешно.

Нейминг - это проблема, да. Я бы даже еще шире смотрел и добавил "компонентизацию" (хз как это правильно называется, когда нужно понять, в какой модуль новый функционал добавлять, иногда это очень неочевидно, и из-за этого страдает связанность).
empiro empiro 11.12.202220:21 ответить ссылка 1.2
иногда достаточно починить алгоритм, добавить индекс, пять баксов в месяц на железо или сказать бухам "этот отчёт считается долго, быстрее не получится"
Но в реальности не всегда всё так просто, потому без кеша иногда не обойтись.

с датой-временем проблема, зачастую, не в библиотеках, а в ещё не наученых опытом програмистах. А так как нюансов работы с датой/временем много, то всегда есть вероятность внезапно открыть для себя что-то новое.
-- надо дату рождения хранить? не проблема, добавим dateTime поле в бд, а время будем отбрасывать. Мы везде используем dateTime, если не нужен timestamp.
-- как это "дата рождения не правильная? мы всё тестили, всё работало! Человек John Doe из America/New_York наверное ошибается.
-- ну ладно, ладно, кто ж знал, что будут клиенты из других поясов. Заменим dateTime на date. Уж дата есть дата.
-- что значит "дать возможность сохранять дату рождения без указания года"? у нас дата, туда без года нельзя. Ладно, подставим фейковый год, всё будет работать.
-- как это "неправильная дата рождения?" там ставится дата рождения, вот код. если дата не выбрана - ставим 0001 год, а потом заменяем при выводе. удобно. Нет, не проверял, фиксил из дому, а что тут может пойти не так то?! Какие ещё реформы Григория XIII ?
-- та блииин, как это "неправильная дата рождения"? вот, реформы прошли, заменяю год на 9999, да проверял сам, всё работало! нет, високосный год не проверял...

... и так дальше. То время события попадёт на несуществующее время (бо перевод стрелок), то часов в сутках не 24
С датами ещё и интервалы. Очень, очень блчдский заеб в некоторых случаях.

Но я что хочу спросить. Я давненько не в мейнстриме. Что за проблема с кешами, что у вас не удаётся кешировать?
"две проблемы программирования" в таком виде в ру-сегменте сформулированы как минимум десятилетие назад.
В общем основную траблу сформулировал пан KoMaTo3 парой комментов выше.
чисто у меня (никаких хайлоадов и терабайтов данных в бд) дополнительную работу вызывает непрямое изменение данных в бд. Что-то каскадом удалилось? Пересобирай кеш для всего, что хотя бы теоретически могло измениться. Это всё не сложно, если не забывать делать.
тоесть проблема - понять, что данные изменились, и пересобрать нужную часть кеша.
А, ясно, проблемы orm/связной базы.
Просто когда руками работаешь как с базой, так и с кешем, любое каскадное удаление у тебя управляемо, и ты не просто чистишь нужный кеш по сущности, ты вообще удаляешь из кеша только элементы с участием определенных ид определенных сущностей.
Кеши бывают разные. если кеш у тебя - абстрактный products.json.gzip, который отдаётся сервером как статика, а значительная часть внутрянки этого файла не просто достаётся из бд, а рассчитывается (например цены на основании складских остатков и курса убитого енота к мёртвому президенту) - тут только пересоздавать.
Я бы выбросил нахуй статику, и сделал бы сервис, который:
1. Поднимается - создаёт с нуля как жсон, так и гзип. Оба держит в памяти, гзип прямо из памяти по запросу отдаёт.
2. Подписан на события изменения сущностей. Как только сущность меняется, та часть, что ответственна за изменения, кидает евент. Наш сервис его ловит, вносит правку в жсон, пересоздает гзип.
Если упираемся в память, то что-то можно сбрасывать на диск или в бд, но обычно нахуй не всралось.
Тупые кеши не нужны.
Как только сущность меняется, мы встречаемся с проблемой инвалидации кеша. Ибо проблема наполовину и состоит из того, чтобы отловить и не профукать, когда меняется сущность.
Так то мне ничего не мешает просто тыркнуть задачу обновления файла, ибо по сравнению с количеством чтений кешированной информации количеством пересозданий можно пренебречь. А держать отдельно сервис, который надо синхронизировать с данными - просто перенести проблему в другое место.
я повторюсь - "инвалидация кеша" это не какая-то конкретная проблема с конкретной реализацией. это задача общего плана, связанная с тем, что разные части приложения не имеют информации о других частях приложения by default. клиент не знает, что сервер обновился, нжинкс не заметил, что файл обновился, парсер ошибочно детектирует изменение данных и дропает кеши и т.д и т.п.
А я тебе о том, что кеши в таком виде не нужны.
Если тебе надо скорость - то дубляж данных неизбежен, твоя несчастная база загнётся нахуй если все будут с нуля оттуда всё перестраивать.
Кеш должен знать, ЧТО он кеширует, и уметь изменять это по событиям изменения, а не вытирать, и заново пересоздавать. Это принципиальное отличие.
Если у клиента вдруг поменялось имя(вышел замуж, хуле), то сервис изменит имя в своих данных по событию, а не сотрёт всё нахуй и запустит перегенерацию из базы.
Соответственно, если вся система реагирует на события, а не мучает БД на каждый чих, вся эта хуета работает на пару порядков быстрее. В базу просто сохраняется изменение на случай переподнятия.
повторюсь
если вся система реагирует на события
если твоя система умеет адекватно реагировать на события - у тебя нет проблемы. Ибо научить систему адекватно реагировать на события - бо́льшая часть проблемы.
А каким образом реализовано кеширование информации - статика ли, кеширующий сервис, прокси - это мелочи, не относящиеся к проблеме в общем.
Ну, тащемта, да.
Если сразу писать на событийной модели, то оно будет реагировать нормально. Если, конечно, писали не рукожопы, но с ними нихуя не работает.
Переделать другую модель под события - согласен, будет много геморроя.
Я уже не говорю про приложения, в которых персистентные события и являются, собственно, базой данных.
и уволившийся автор кода
akko akko 11.12.202219:22 ответить ссылка 0.9
Прикинь сколько еще такой хуйни он мог наговнокодить? А теперь это можешь делать ты!
На этот код надо приходить, когда он уже немного подбродит, а контора поймет, что без увеличения бюджета тут совсем никак.
Ошибка на единицу из-за отсчета с нуля. В данном примере ее не может быть по определению.
Deviant Deviant 11.12.202221:40 ответить ссылка 0.0
В датасаенсе есть проклятиых стула:
1. Шумные и неполные данные
2. Непонятные требованая заказчика
Сядешь на оба.
Scallop Scallop 12.12.202219:18 ответить ссылка -0.3
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы

Похожие посты
ДАВАЙТЕ ВСЕ В IT ТУТ НЕ СЛОЖНО - айти. Какой же ты пидорас! #techicom startup
@tychycorn
Все хотят работать в IT, но никто не хочет пахать по 20 часов внеделю за $100К в год
3:26 РМ • 12 и юл. 2022 г. • Twitter for iPhone
41 етвит 8 твитов с цитатами 214 лметок «Нравится»
подробнее»

твиттер интернет айти it-юмор geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор

#techicom startup @tychycorn Все хотят работать в IT, но никто не хочет пахать по 20 часов внеделю за $100К в год 3:26 РМ • 12 и юл. 2022 г. • Twitter for iPhone 41 етвит 8 твитов с цитатами 214 лметок «Нравится»
Console prices, adjusted for inflation
$796
1977- Atari 2600 Original price: $200
$935
1979- Intellivision Original price: $300
$410
1982- ColecoVision Original price: $175
$412
1986- Master System Original price: $200
$412	$346	$365	$1,125
1986- NES	1989- Genesis	1989- TurboGrafx 16 19
подробнее»

geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор ps консоли ps1 PS2 ps3 ps4 xbox xbox one песочница

Console prices, adjusted for inflation $796 1977- Atari 2600 Original price: $200 $935 1979- Intellivision Original price: $300 $410 1982- ColecoVision Original price: $175 $412 1986- Master System Original price: $200 $412 $346 $365 $1,125 1986- NES 1989- Genesis 1989- TurboGrafx 16 19
Which statements concerning the following code are true?
class A
{
public A() {> // A1
public A(String s) { thisO; System.out.println("A :"+s);	>	// A2
>
class 3 extends A
{
public int B(String s) { System.out.println("B :”+s); return 0; > // B1
>
class C extends B
{
private C(){ supe
подробнее»

geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор it-юмор it java экзамен сертификат

Which statements concerning the following code are true? class A { public A() {> // A1 public A(String s) { thisO; System.out.println("A :"+s); > // A2 > class 3 extends A { public int B(String s) { System.out.println("B :”+s); return 0; > // B1 > class C extends B { private C(){ supe