Что-то не сходится. Ну положим они распарсили из вашей переписки и привязали российский номер его телефона к вашему кабинету. Но ведь сообщение в WhatsApp идёт опять же по номеру телефона. То есть должно было быть доставлено получателю. Не хватает шага почему СДЭК вместо использования явно указанного российского номера получателя, использует ваш левый сингапурский.
Я понимаю ещё если его адрес в вашем кабинете указан и они по адресу неправильно заматчили получателя. И потом взяли ваш сингапурский номер из вашего кабинета. Но тогда парсинг номеров телефонов из сообщений совсем не при чем
как работает дата в коболе и почему при неправильной обработке она дефолтится в 150 лет
150 лет - это не дата, а промежуток времени. Вы имели в виду, что пустая дата в Коболе - это 20 мая 1975 года? Ну тогда бы была туча записей людей которым скоро будет 150 лет.
Скорее стагнатцией на ИТ-рынке пытаются поддержать хайп вокруг генеративных нейросетей. Типа смотрите, даже программисты уже не нужны, такие умные нейросети. Вкладывайтесь в нейросети еще больше. Что характерно, чем больше будут вкладываться в нейросети, тем хуже будет ИТ-орасли. Не потому, что они способны заменить программистов, просто они отвлекают на себя инвестиции.
Хмм, вообще-то число позиций SE в США выросло в 2024 году. Число безработных SE, вероятно, также выросло по той простой причине, что рынок ещё не адаптировался к тому, что рост не такой быстрый как в 10-е годы, а вернулся к росту как в нулевых. Вот, например: https://newsletter.pragmaticengineer.com/p/state-of-eng-market-2024
Ну а то, что AI замечает программисты. Ну это старая история, Fortran как язык программирования высокого уровня был создан для замены программистов. И собственно последние 60 лет только говорят, что заменят программистов, то low code решением, то каким-нибудь супер-пупер языком высокого уровня на котором может программировать каждый, то генераторами кода. Сейчас похоже настал новый виток генераторов кода.
Мне кажется, вы очень быстро делаете выводы, не зная ситуации.
Проблема с Британским музеем в том, что у него очень много посетителей. Даже в дни когда все системы работают перед ним бывает выстраиваются огромные очереди.
Физические кассы для платных выставок внезапно у него есть и внезапно они принимают наличность. Я не знаю работают ли они сейчас, на сайте музея сказано, что приоритет отдается владельцам "pre-booked ticketsholders", что как бы намекает, что купить билеты можно и на месте.
Проблема в том, как управлять массой людей внутри музея, который имеет как бесплатные, общедоступные экспозиции, так и временные, билеты на которые надо покупать.
Я подозреваю, что турникеты перестали работать и пропуск осуществляется вручную, а это сильно уменьшает поток людей.
Думаю, есть и другие системы неработоспособность которых ухудшает пропускную систему музея.
В ваших примерах не всегда очевидна польза той или иной оптимизации.
К примеру, вы пишите, что
Оператор EXISTS будет эффективнее, чем JOIN, потому что сервер не считывает лишние строки из таблицы, если необходимо убедиться, что запись существует, в какой-либо таблице.
Если вы взгляните на планы для обоих запросов с JOIN и EXISTS в статье, то увидите, что в обоих случаях делается полный скан таблиц, и считывается 830 записей из salesorder и 2155 из orderdetail. Разница в стоимости запросов в данном случае из-за ошибки оптимизатора PostgreSQL, который решил, что в первом случае после join останется 2155 записей, а во втором 830, что явная ошибка так как их должно остаться одинаково. В реальности я бы сказал,что второй запрос будет дороже из-за дополнительного HashAggregate stage.
Вообще, если взглянуть на проблему JOIN и EXISTS шире, то хороший оптимизатор старается переписать запрос, который использует подзапросы, как в случае с JOIN, в запрос с JOIN, что, кстати, и произошло в данном случае, если вы взляните на планы.
В друих случаях, я бы доработал примеры, например, в случае с BETWEEN не продемонстрировано использовование индекса в одном случае и полного скана в другом. И я бы переименовал этот совет - речь ведь больше не про BETWEEN, а про то, что в ряде случаев из-за использование функций, индексы становится невозможно использовать и по\тому лучше избегать использования функций на проиндексированных колонках.
Ни в одном из примеров не продемонстрировано, что перезаписывание действительно делает запрос быстрее, только показана оценка стоимости запроса. Но доверять ей не стоит так как оптимизаторы баз данных частенько ошибаются в них. Хорошо было бы увидеть выигрыш во времени исполнения на реалистичных данных (а не на таблицах с парой тысяч записей) и с использованием индексов.
Сказали, что это полностью формальная встреча, и я к ней так и относился.
Это у вас ключевая ошибка - просто так никто не будет встречаться, тем более человек уровня бизнес-партнера. Сколько раз я уже слышал подобные истории от "просто" обеда с командой до "формальной" встречи с биг боссом, которые заканчивались отказом из-за того, что кандидат не был готов и не показал себя лучшим образом.
В первой части статьи проводится подмена понятий - вместо саморазвития критикуется показуха и делается вывод, что это плохо. Ну мы и так знаем, что показуха это плохо.
Во второй части - просто набор банальностей. Типа ставьте "истинные цели". Что такое истинная цель и как ее определить? Это из раздела - если вы бездомный просто купите дом.
Никаких истинных целей не существует, в жизни все намного сложнее и при выборе целей нужно уметь балансировать приверженность к достижению цели и ее актуальность, которая постоянно меняется. Нет смысла достигать цели, которая уже не актуальна, но если постоянно менять цели, то ничего не достигнешь. Найти правильный баланс здесь не просто.
Ну и дальше, цените качество. Ещё бы кто сказал, какая именно книга или курс качественны. Иногда приходится перебрать немало вариантов прежде чем найдешь что-то стоящее.
Ну и далее по тексту набор наивных, непродуманных утверждений. Из раздела родитесь здоровым и богатым, ведите правильную жизнь, слушайте правильных мысли и игнорируйте неправильные.
Я даже знаю, что сделает это агентство - создаст реестр LL моделей. И пролоббирует закон согласно которому, модно будет использовать модели только из этого реестра.
В таких случаях я обычно использую услуги местной таксокомпании. Да это может быть дороже, чем на 20-50%, но хотя бы есть гарантия, что уедешь.
Что касается других городов, то в европейских странах практически везде есть Welcome Pickups, который встречает в аэропорту и отвозит туда. Опять же дороже Убера, но не в 4 раза, а качество услуг несопоставимо выше.
Сравнение рейтинга Welcome Pickups и Uber на TrustPilot
UPD: Добавлю еще ретинг местной компании, услушами которой я пользуюсь вместо Убера
PS Здесь я рассматриваю Убер и Яндекс Такси как компании одного класса. Поэтвожу Убер в качестве примера, так как Яндекс Такси у меня недоступно.
Я тоже раньше не мог понять почему люди так любят Excel, но в итоге смирился и сумел даже понять в какой-то мере. По моему представлению продвинутые пользователи ценят в Excel независимость и простоту.
Независимость заключается в том, что чтобы опробовать новую идею, быстро глянуть на данные в каком-то разрезе - не надо спрашивать программистов добавить новую функциональность, а потом ждать 2 месяца - можно сделать здесь и сейчас.
Простота - вот есть старый добрый Excel, который они знают вдоль и поперек, он не требует переобучения какой требует каждая новая CRM система, если что непонятно - можно глянуть в Интернете. Опять же Excel не падает как многие наколенные поделки, выдаваемые за профессиональные решения.
Поэтому я вполне понимаю почему стандартный вопрос пользователей - как выгрузить данные в Excel. И получив данные в Excel они начинают творить какие-то странные, дикие вещи там. Мне непонятные. Но если у них все работает, они довольны и хотят продолжать в том же духе, пусть продолжают. Не программистам же указывать как кому работать.
Обычный поиск по документам внутри организации был и до Copilot, такие сервисы предлагает и Microsoft Office, и Google Docs. В данном случае Copilot тоже выступил как поисковик по документам, давая ответы на их основе и предлагая ссылки на документы.
Что-то не сходится. Ну положим они распарсили из вашей переписки и привязали российский номер его телефона к вашему кабинету. Но ведь сообщение в WhatsApp идёт опять же по номеру телефона. То есть должно было быть доставлено получателю. Не хватает шага почему СДЭК вместо использования явно указанного российского номера получателя, использует ваш левый сингапурский.
Я понимаю ещё если его адрес в вашем кабинете указан и они по адресу неправильно заматчили получателя. И потом взяли ваш сингапурский номер из вашего кабинета. Но тогда парсинг номеров телефонов из сообщений совсем не при чем
150 лет - это не дата, а промежуток времени.
Вы имели в виду, что пустая дата в Коболе - это 20 мая 1975 года? Ну тогда бы была туча записей людей которым скоро будет 150 лет.
Вывод - покупать хостинг у них, назря что-ли они столько треша переводят 😂
Скорее стагнатцией на ИТ-рынке пытаются поддержать хайп вокруг генеративных нейросетей. Типа смотрите, даже программисты уже не нужны, такие умные нейросети. Вкладывайтесь в нейросети еще больше. Что характерно, чем больше будут вкладываться в нейросети, тем хуже будет ИТ-орасли. Не потому, что они способны заменить программистов, просто они отвлекают на себя инвестиции.
Хмм, вообще-то число позиций SE в США выросло в 2024 году. Число безработных SE, вероятно, также выросло по той простой причине, что рынок ещё не адаптировался к тому, что рост не такой быстрый как в 10-е годы, а вернулся к росту как в нулевых. Вот, например: https://newsletter.pragmaticengineer.com/p/state-of-eng-market-2024
Ну а то, что AI замечает программисты. Ну это старая история, Fortran как язык программирования высокого уровня был создан для замены программистов. И собственно последние 60 лет только говорят, что заменят программистов, то low code решением, то каким-нибудь супер-пупер языком высокого уровня на котором может программировать каждый, то генераторами кода. Сейчас похоже настал новый виток генераторов кода.
Какое коварство со стороны Microsoft релизить DocumentDB на 4 года раньше чем Амазон форкнул MongodDB под именем DocumentDB
https://habr.com/ru/articles/234233/
Мне кажется, вы очень быстро делаете выводы, не зная ситуации.
Проблема с Британским музеем в том, что у него очень много посетителей. Даже в дни когда все системы работают перед ним бывает выстраиваются огромные очереди.
Физические кассы для платных выставок внезапно у него есть и внезапно они принимают наличность. Я не знаю работают ли они сейчас, на сайте музея сказано, что приоритет отдается владельцам "pre-booked ticketsholders", что как бы намекает, что купить билеты можно и на месте.
Проблема в том, как управлять массой людей внутри музея, который имеет как бесплатные, общедоступные экспозиции, так и временные, билеты на которые надо покупать.
Я подозреваю, что турникеты перестали работать и пропуск осуществляется вручную, а это сильно уменьшает поток людей.
Думаю, есть и другие системы неработоспособность которых ухудшает пропускную систему музея.
Реклама телеграмм канала есть? Есть.
Вам что ещё и осмысленный текст к рекламе подавать?
В ваших примерах не всегда очевидна польза той или иной оптимизации.
К примеру, вы пишите, что
Если вы взгляните на планы для обоих запросов с JOIN и EXISTS в статье, то увидите, что в обоих случаях делается полный скан таблиц, и считывается 830 записей из salesorder и 2155 из orderdetail. Разница в стоимости запросов в данном случае из-за ошибки оптимизатора PostgreSQL, который решил, что в первом случае после join останется 2155 записей, а во втором 830, что явная ошибка так как их должно остаться одинаково. В реальности я бы сказал,что второй запрос будет дороже из-за дополнительного HashAggregate stage.
Вообще, если взглянуть на проблему JOIN и EXISTS шире, то хороший оптимизатор старается переписать запрос, который использует подзапросы, как в случае с JOIN, в запрос с JOIN, что, кстати, и произошло в данном случае, если вы взляните на планы.
В друих случаях, я бы доработал примеры, например, в случае с BETWEEN не продемонстрировано использовование индекса в одном случае и полного скана в другом. И я бы переименовал этот совет - речь ведь больше не про BETWEEN, а про то, что в ряде случаев из-за использование функций, индексы становится невозможно использовать и по\тому лучше избегать использования функций на проиндексированных колонках.
Ни в одном из примеров не продемонстрировано, что перезаписывание действительно делает запрос быстрее, только показана оценка стоимости запроса. Но доверять ей не стоит так как оптимизаторы баз данных частенько ошибаются в них. Хорошо было бы увидеть выигрыш во времени исполнения на реалистичных данных (а не на таблицах с парой тысяч записей) и с использованием индексов.
Это у вас ключевая ошибка - просто так никто не будет встречаться, тем более человек уровня бизнес-партнера. Сколько раз я уже слышал подобные истории от "просто" обеда с командой до "формальной" встречи с биг боссом, которые заканчивались отказом из-за того, что кандидат не был готов и не показал себя лучшим образом.
Какие именно полезные мысли?
В первой части статьи проводится подмена понятий - вместо саморазвития критикуется показуха и делается вывод, что это плохо. Ну мы и так знаем, что показуха это плохо.
Во второй части - просто набор банальностей. Типа ставьте "истинные цели". Что такое истинная цель и как ее определить? Это из раздела - если вы бездомный просто купите дом.
Никаких истинных целей не существует, в жизни все намного сложнее и при выборе целей нужно уметь балансировать приверженность к достижению цели и ее актуальность, которая постоянно меняется. Нет смысла достигать цели, которая уже не актуальна, но если постоянно менять цели, то ничего не достигнешь. Найти правильный баланс здесь не просто.
Ну и дальше, цените качество. Ещё бы кто сказал, какая именно книга или курс качественны. Иногда приходится перебрать немало вариантов прежде чем найдешь что-то стоящее.
Ну и далее по тексту набор наивных, непродуманных утверждений. Из раздела родитесь здоровым и богатым, ведите правильную жизнь, слушайте правильных мысли и игнорируйте неправильные.
Вместо "Саморазвитие не работает" заголовок должен быть "Общие мысли об эффективном саморазвитии, набросанные для рекламы моего телеграм канала".
Я даже знаю, что сделает это агентство - создаст реестр LL моделей. И пролоббирует закон согласно которому, модно будет использовать модели только из этого реестра.
Почему только 250 вопросов? Уверен, ChatGPT может нагенерить их еще больше.
Я уверен, что есть более эффективная стратегия подготовки к интервью ПМ, чем просто придумывать ответы на сотни рандомных вопросов.
В таких случаях я обычно использую услуги местной таксокомпании. Да это может быть дороже, чем на 20-50%, но хотя бы есть гарантия, что уедешь.
Что касается других городов, то в европейских странах практически везде есть Welcome Pickups, который встречает в аэропорту и отвозит туда. Опять же дороже Убера, но не в 4 раза, а качество услуг несопоставимо выше.
Сравнение рейтинга Welcome Pickups и Uber на TrustPilot
UPD: Добавлю еще ретинг местной компании, услушами которой я пользуюсь вместо Убера
PS
Здесь я рассматриваю Убер и Яндекс Такси как компании одного класса. Поэтвожу Убер в качестве примера, так как Яндекс Такси у меня недоступно.
.
Я тоже раньше не мог понять почему люди так любят Excel, но в итоге смирился и сумел даже понять в какой-то мере. По моему представлению продвинутые пользователи ценят в Excel независимость и простоту.
Независимость заключается в том, что чтобы опробовать новую идею, быстро глянуть на данные в каком-то разрезе - не надо спрашивать программистов добавить новую функциональность, а потом ждать 2 месяца - можно сделать здесь и сейчас.
Простота - вот есть старый добрый Excel, который они знают вдоль и поперек, он не требует переобучения какой требует каждая новая CRM система, если что непонятно - можно глянуть в Интернете. Опять же Excel не падает как многие наколенные поделки, выдаваемые за профессиональные решения.
Поэтому я вполне понимаю почему стандартный вопрос пользователей - как выгрузить данные в Excel. И получив данные в Excel они начинают творить какие-то странные, дикие вещи там. Мне непонятные. Но если у них все работает, они довольны и хотят продолжать в том же духе, пусть продолжают. Не программистам же указывать как кому работать.
Странная метрика, я бы тоже вышел по ней инженером-призраком. Так как в последнее время мои задачи почти не включают написание кода.
Видимо по мнению этих горе-исследователей, программисты занимаются только написание кода.
Обычный поиск по документам внутри организации был и до Copilot, такие сервисы предлагает и Microsoft Office, и Google Docs. В данном случае Copilot тоже выступил как поисковик по документам, давая ответы на их основе и предлагая ссылки на документы.
Помнится мне ещё в 2009 году МГТС по ошибке сделала доступным поиск внутренних документов через свой сайт https://safe.cnews.ru/news/top/v_mgts_masshtabnaya_utechka_personalnyh
Copilot не принес тут ничего нового - дверь была открыта всегда.
Ну так ведь не получится написать кликбейтный заголовок. Кого волнует качество материала когда на кону число прочтений и рейтинг.