Search
Write a publication
Pull to refresh
4
0
Send message
Полностью согласен. Маркетологов, забивающих всё баннерами и как бы контекстной рекламой — нужно отдавать в школы для слабоумных на перевоспитание. Как и тех, кто платит им деньги (или даже в первую очередь тех, кто платит).
Сами по себе публицистические материалы могут быть отличной рекламой. Но для этого маркетологам нужно интенсивно думать, размещать разные статьи и заметки на разных ресурсах. Маркетологи думать не хотят. Они хотят вставить баннер в 10000 страниц и считать «клики». Потому что маркетологи — это просто наёмные работники, которым нужно отчитываться перед начальством и которым в действительности глубоко плевать на результативность бизнеса. Потому что суть проблемы — в том, что баннеры и прочий подобный шлак типа контекстной рекламы — попросту не работают от слова никак (привет, Яндекс, ты меня уже задрал показывать 2 одинаковые картинки рядом, не имеющие никакого отношения к тому, что мне реально интересно).
Послушайте, вы давно добровольно тыкали в баннеры и контекстные блоки, переходили на сайт рекламодателя и делали покупку? Нет? Ни разу? А считаете ли вы себя абсолютно исключительными людьми, отличающимися от «серой массы» кардинально? Если да, то вы заблуждаетесь. Никаких кардинальных отличий нет, а клики по баннерам, которые сами по себе случайны или злонамеренны (накрутка) в большинстве случаев — не приводят ни к каким покупкам.
Так за что, для чего маркетологи издеваются над нами, размазывая свой шлак по страницам? Почему мы должны это терпеть? Почему бы им не напрячься и не начать уже отрабатывать свои деньги, размещая статьи и заметки, завуалированно побуждающие приобрести тот или иной продукт на профильных ресурсах, посвящённых подобного рода продуктам, занятиям и близкой по смысле тематике?
ОК, мы видим пример хабра, где можно сколько угодно использовать адблок, но это не приведёт к тому, что хабру будет нечем платить за аренду серверов и админстрирование. Почему? Потому что хабр в основном использует механизм скрытой или по крайней мере «таргетированной» умной рекламы в самих статьях. Хорошо ли это? Если мне не нравится -я просто не читаю. Если понравится — прочитаю, и, вполне вероятно, даже куплю какую-нибудь железку или софт.
Компании же, размещающие баннерную рекламу, воспринимаются потенциальными «потребителями» априори негативно, как нечто второсортное. Исключение — раскрученные бренды типа какого-нибудь Бургер-кинга, для которых это не то, чтобы простительно, но по сути дела норма их поведения, которую никто на оспаривает. Но это — исключения, а правило — это всё-таки чувство отвращения и раздражения у посетителя страницы к рекламному контенту. Так что может купить такой пользователь? Маркетологи, ау, вы вообще в своём уме, если реально считаете, что старая реклама всё ещё способна создавать дополнительную прибыль?
Есть группа для обмена опытом эксплуатации Splunk в России, t.me/splunk_ru или поищите в контактах Телеги: «splunk» — тут-то мы и отыщемся.
Как интересно у вас обсуждение развивается! Я бы сказал, что новые «Газели» на порядок интереснее самого опроса.
Аудитория — самая большая проблема этого опроса, которая делает из него мусорную статистику на тему «что думают о зарплатах пользователи Ответов». На мой взгляд, вполне подтверждающийся реальной практикой, на социальных ресурсах mail.ru сидят в основном скучающие полумаргиналы. Не знаю среди своих знакомых ни одного специалиста, даже не очень высокооплачиваемого, который бы хоть раз упоминал что-либо, кроме почты mail.ru (и ту чаще в негативном контексте).
Trie представлено нерационально: зачем хранить пустые связи типа e -> i -> r, по ссылке от h, если вместо этого можно хранить просто суффикс «eir» и разбить его на компоненты только тогда, когда нужно будет вставить какой-нибудь «they»?
Всё хорошо было до самой последней фразы, на которую уже обратили внимание: «Я тоже хочу». Она какая-то нелепая, ни к чему толком логически не привязанная. Что она хочет — можно только догадываться.
Но, повторюсь, написано очень живо, искренне и читается легко. Просто на мой взгляд замятый конец лучше всё-таки поправить, чтобы стало ещё лучше. Могут предложить исправление :)
Не далее как вчера переживал из-за того, что событийная модель в Mojolicious как-то резко уступила место тотальному async/await'у и промисам, и все мои коллеги уже переписали свой Mojo-код на промисы, а я ещё нет. Как вдруг выясняется, что сегодня Perl уже умер (на 5.28'й версии скоропостижно скончался от несбывшихся надежд, R.I.P?). Пойду что ли на PHP всё перепишу, раз такое дело: хабр же не может ошибаться.
Не далее как позавчера читал статью о заводе «Рубин», датированную 1995-м годом.
Я не должен был её читать, потому что они слишком старая? Возможно, мне не стоило бы читать свежие воспоминания участников событий 1993-го, 1996-го, 1998-го, 1999-го годов, потому что в них — правда, а не то, что придумывают об этих событиях в 2018-м году. Да, наверное, с точки зрения разного рода полицаев всех мастей, необходимо ограничить доступ ко всему старому, потому что интернет — это своеобразная коллективная память, и я прекрасно понимаю, что многим, наверняка и вам в том числе, выгодно, чтобы эта память была как можно короче.

>А то с такой логикой, давайте вернемся в пещеры. Будем бить себя дубинками по голове
Да, кстати, если уж говорить про «себя дубинкой по голове», то да, у меня есть неотъемлемое право бить себя дубинкой по голове — и никто у меня это право просто так не отнимет. И уже моё личное дело, буду я им пользоваться или нет, вас это абсолютно не касается.
Несколько расстроило то, что в 8-ке хотят реализовать асинхронщину в рантайме лишь частично. Я не понимаю — это вообще как? Часть ввода-вывода на низком уровне сделают неблокирующим, часть блокирующим? Или добавят ворох функций «на _nb», которые будут точно неблокирующими? ИМХО лучше сразу сделать нормальные зелёные потоки, в которых все операции будут выглядеть блокирующими, а в действительности при IO будет передаваться управление циклу событий / планировщику зелёных потоков — тогда не нужно будет придумывать новые функции, а просто старые будут на низком уровне делать только неблокирующий ввод-вывод (ну или блокирующий, но только в режиме единственного зелёного потока, что сложнее).
В QBasic "$" стоял после переменной строкового типа, это был суффикс, а не префикс.
Уважаемый переводчик, скажите пожалуйста, а у нас завтра какая среда будет — та, что из вещества или та, что из композита?
Читал и плакал. Честно.
Можно я буду цитировать ЭТО, не всегда приводя ссылки на Первоисточник?
>В любой момент времени выполняется только одна задача.
Но многоядерных процессорах тоже??
Отличная статья, за последний абзац — так прямо отдельное спасибо. У меня о постсоветском пространстве и целях сложилось совершенно аналогичное мнение. Причём это касается не только мелких и средних компаний, но даже гигантов рынка. Аполитичность, которой у нас принято гордиться — это просто другая сторона медали, на которой с той стороны, которой она обратная, выгравировано буквально «Бесцельность». И пример компании, выпускающей 3D-сканеры очень удачный: они прекрасно понимают «осознанность»/«осмысленность» существования своей компании, поэтому легко и непринуждённо описывают цели своего существования. По поводу того же MailCloud'а — я далеко не уверен, что им удалось бы сделать это столь же легко (поэтому и не делают).
Да, простите мне мою дремучесть, пожалуйста, но после первого же SQL-оператора в этой статье (на мой взгляд, интересной, всяко интереснее всякой мути про реакты&ангуляры) — у меня возник вопрос: что это за БД и почему она отдаёт результаты запросов в таком странном формате??
Проблема, возможно, в том, что никто не обращает внимание на слово «чуть» перед «замешкавшимся»: Ваше «чуть» может сильно отличаться от моего, да и от случая к случаю «чуть» может меняться в широких пределах. Если Вы имели в виду что-то вроде «отвлёкся на полчаса, чтобы масло поменять, вернулся — и уже не помню, что там было на предыдущей странице „Так говорил Заратустра“ », то в общем всё вполне логично.
Вообще мне, как скриптеру с огромным стажем, здесь есть просто непаханное поле для комментариев, потому что слишком многое выдаёт дилетантизм авторов, а скорее просто небрежение изучением документации языка. Чего стоит только сравнение вида [[ "${var}" == «string» ]] при том, что куда корректнее и короче [[ $var == 'string' ]]: в двойных квадратных скобках не нужно воспринимать переменные как куски интерполируемого текста, строки в двойных кавычках, не использующие интерполяцию — это не только лишняя нагрузка на клавиши shft, но и просто моветон в BASH (точно так же и в perl, например). В арифметических выражениях вообще не нужен сигил у переменных: $(( X+ Y )), а не выглядящее просто ужасно $(( ${X} + ${Y} )) — и не лень же им было это набирать… Утверждение о массивах в BASH, которые если используешь, то надо сразу писать на Python — какой-то ничем не подкреплённый плевок в сторону BASH, хотя для своих задач (как инструмент системного администрирования) это отличный язык, и Python его здесь способен заменить, только если вы изначально отлично знаете Python (и, очевидно, знаете BASH ещё хуже, чем те, кто написал эту Google-памятку).
Не могу сказать, что для меня данная статья не была полезной, но некоторый снобизм при посредственном знании предмета — её авторов совершенно не красит.
У меня сложилось впечатление, что они имели в виду «в соответствии с внутренними правилами компании BASH — единственный разрешённый скриптовый язык». В противовес другим Shell-языкам: sh, csh,ksh, zsh, tcsh и т.д., и т.п. В контексте упоминания Solaris как исключения для этого правила -получается вполне логично.
Во-первых удалённые команды выполняются всё-таки неким shell'ом, а никак не сервером мониторинга, нет ничего особо выдающегося в том, что агент может забрать STDOUT команды.
Во-вторых — во всех нормальных компаниях (из известных мне — просто во всех), конфигурацией управляют итак централизованно, через штуки типа Puppet и Ansible
Ну и в-третьих — а вы точно проверяли, что все ваши агенты НЕ принимают удалённые команды без шифрования? Проверьте — будете удивлены. Мы на всех агентах эту «возможность» отключили.

Information

Rating
Does not participate
Registered
Activity