Как стать автором
Обновить
100
0
Edward Chernenko @edwardspec

Пользователь

Отправить сообщение
Навязывание галочками по умолчанию, жаль нет законов для вот этого вот.

На практике такой закон приведёт к штрафам за yum, apt-get, npm, composer — ведь все они устанавливают ПО, которого пользователь не просил (пакеты, указанные как зависимости).

Нет, в первоисточнике тоже знать.
Имеется в виду, что должен работать институт репутации. Автор фальшивой работы (например, заменивший слово «мясо» на «шоколад» в уже существующей настоящей работе — такое бывало) легко может налепить ещё 10 фальшивых работ взамен уже разоблачённой.
Если поимка стала большим публичным стыдом (автора фальшивых работ уже знают как такового), то уже бессмысленно мухлевать снова.
Но размещение на сайте, откуда нельзя скачать и ( важно! ) по Сtrl+С нельзя скопипастить текст с экрана
Единственное, чего этим можно добиться — сообщить посетителю сайта, что его считают идиотом.
В том числе тому посетителю, который не имеет злого умысла.
«Эпидемия чумы никак не повлияет на здоровье нежити»
Сертификаты Let's Encrypt разрешено использовать в коммерческих проектах:
Commercial users are welcome to use Let’s Encrypt for commercial and for-profit purposes. This is an intended use; we don’t have any desire to restrict the use of our services to non-profit or non-commercial purposes. (Seth Schoen, EFF)
Отсюда: community.letsencrypt.org/t/are-they-limitations-on-who-can-use-lets-encrypt/687
Не прячьте. Через 1000 лет напишут научную работу «Эволюция мозга человека на примере варварского доисторического программного кода, археологически раскопанного в холодных хранилищах древности»
И внесут «Законопроект о запрете применения формата JPEG к фотографиям представителей власти»
не обязательно что это будет работать для всех или хотя бы для большинства.
Этого и я не утверждал. Я рассказал о своём опыте.
Разработчик, который пилит одну алгоритмическую фичу 7 часов подряд, конечно же может быть выбит из потока вопросом.
Вы когда просматриваете письма точно так же уже отвлекаетесь от работы.
Специфика моей работы — много мелких задач (я не лезу в почту во время реализации фичи, а только между фичами) плюс крупные архитектурные задачи (при обдумывании которых я делаю обязательные паузы специально, т.к. через час-другой может прийти в голову хорошая идея об альтернативной реализации).
Я привык быстро переключаться между задачами и (по ощущениям) не отвлекаюсь от потока, посмотрев на почту.
Ну начнём с того, что форс-мажор — это 1-2 письма в год. Major service disruption. Например, «по IP-адресу сервиса попало блокировкой Роскомнадзора, надо срочно поднять reverse proxy на другом IP».
Все остальные задачи должны быть рассмотрены в течение 24 часов.

И чем это отличается от ситуации когда кто-то подошёл ко мне когда я работаю и просит решить его проблему. А я ему говорю что проблема низкоприоритетная и я её сделаю на следующей неделе. Или вообще его игнорирую и делаю свою работу.
Тем, что он уже отвлёк вас от работы, нет? Даже если не получил ответ. И у вас не было выбора, когда им заниматься.

Выслушать нельзя вполуха. Чтобы понять, о срочной проблеме он говорит или нет, надо полностью отвлечься и дослушать, что он говорит. Пробежать глазами по тексту можно моментально (лично меня это даже не «отвлекает от потока»).

Тут ниже писали про «отвлечение от потока» из-за «посмотреть 5-10 секунд на текст». Вы только посылать этого человека, который подошёл к вам ногами, будете минуту. И он потом ещё будет дуться и жаловаться, что его игнорили (и такое бывает).
Синхронная коммуникация — это когда вы немедленно отвечаете.
Бегло просмотреть письмо можно сразу. Если запрошенная там фича — низкоприоритетная, а разработчик занят, то он не должен всё бросать.
Он может спокойно доделать то, чем занимался ранее.
А это вопрос привычки. Я очень часто проверяю почту.
Беглым просмотром письма. 5-10 секунд достаточно, чтобы узнать, форс-мажор там или нет.
И только тогда, когда открыл почту сам (без всплывающих уведомлений «пришло новое письмо»).
А если ввести асинхронность? Юзер в Телеге должен ждать 24 часа?
Техподдержку надо разбивать на группы/линии. Асинхронность нужна только разработчикам.
1 линия — работник техподдержки, сидящий в чате (синхронное общение с юзером). Если он знает ответ, то отвечает юзеру немедленно. Если не знает, то дёргает 2 линию.
2 линия — опытный работник техподдержки, который знает ответы на почти всё, но не является разработчиком. Синхронное общение с 1 линией. Если он определяет, что это баг, суперсложный вопрос или для расследования надо рыться в коде и т.п., то сообщает юзеру «передал вопрос разрабочикам» и дёргает 3 линию.
3 линия — разработчик, которого дёргают только при сложнейших тикетах. Он может работать асинхронно.
«Просто пылесоса» в сложном софте не бывает. Бывает софт из сотен фич, у которых есть свои названия.
Да, бывают цепочки сообщений типа «мой пылесос не работает, разберитесь», но когда я нахожу причину, то я всегда упоминаю сломавшуюся фичу в своём ответе. Поэтому по её названию цепочка найдётся.
Поиском по ключевым словам + письма сгруппированы в цепочки.
(если вопрос про робот-пылесос, то предыдущая цепочка писем не могла не содержать это слово)
Фрилансер (по допиливанию большого чужого ПО). Механизм общения с клиентом/менеджером:
1) клиент пишет письмо с требованием новой фичи и/или вопросами. Со всеми деталями.
2) работник пишет подробный ответ в течение 24 часов (кроме экстренных задач типа «сайт упал, посмотри, что там»). По новой фиче ответ — или 1. «уже сделано» (со всеми деталями «как это работает» + ссылкой «где посмотреть работающую фичу»), или 2. уточняющие вопросы по требованиям (например, «по добавлению поля Картинка в форму, позволяющую пользователю сайта опубликовать короткую заметку: достаточно ли одной картинки или пользователю нужно загружать много картинок?»), или 3. «сложность оцениваю так-то, ETA (предположительное время выполнения) — 32 мартобря».

С сотрудниками компании, с которой работаю — то же самое. Если мне нужно что-то от дизайнера или маркетолога — пишу письмо №1 и получаю письмо №2. Если им что-то нужно от меня — аналогично.

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

Был случай, в одной компании (где я работал давно) появилась маркетолог (ну вы знаете, какие они soft skills и общительные), которой было непривычно без еженедельных созвонов. У неё была уйма новых идей по фичам, и было очень важно хранить всё это в письменном виде. Настоял на письмах. Через месяц и она признала, что этот подход работает (с удивлением «даже не представляла себе, что координировать коммуникацию получится без звонков голосом»).

Требования из письма (в отличие от обговоренного устно) можно сразу скопировать в баг-трекер. Описание реализованной фичи (из моего ответа) можно скопировать в документацию. Клиент не может забыть, что именно просил (есть текст запроса фичи). Работник не может забыть, что у него просили. Если новый сотрудник Б спросит что-то, о чём уже спрашивал сотрудник А, то можно переслать ему письмо с ответом (а не рассказывать заново, как на совещаниях). Одни плюсы.
И смогут ли они вообще жить на Земле, родившись на планете с меньшей гравитацией?
может быть ключом к открытию новой, единой физической космологии [...] такие же уникальные, как и ваша собственная радужная оболочка [...] меняются на наноуровне времени
Даже по формулировкам видно, что это написано маркетологом, а не учёным.
В нашей практике помогало выставлять nice максимальным (19 — это минимальный приоритет, -20 (минус 20) — максимальный).
Это очень полезный совет, кстати.
Для процесса, который в основном занят вводом/выводом и почти ничего не считает в юзерспейсе, ставить максимальный приоритет (-20) — крайне выгодно. Т.к. этот процесс в основном вызывает syscall-ы ввода-вывода и ждёт результата. Получив квант времени от планировщика, этот процесс вызовет следующий syscall (т.е. немедленно отдаст CPU обратно).

Повышенный приоритет уменьшает время между двумя просыпаниями процесса (т.е. он сможет вызывать syscall-ы чаще), а отнимаемое у других процессов время — не меняется.

Информация

В рейтинге
Не участвует
Откуда
Обнинск, Калужская обл., Россия
Дата рождения
Зарегистрирован
Активность