Pull to refresh
8
0
Андрей Астахов @pa3ot

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

Send message

Хороший слог. Это первое собственное произведение?

Перечитай классиков фантастики, поищи такие «баги» у них. И найдешь.
Лично для меня, это, скорее фича, чем баг. Я могу себе представить мысль, сидящую не в голове — это больше об ощущениях, и о том, как по-разному их можно выразить словами.

Бред чаще бывает в сюжете или диалогах. Когда читаешь и не веришь, что так люди себя могут вести. Пускай даже через сотни лет, пускай даже, если пережили катастрофу, изменившую весь уклад жизни.
Я прошу прощения, в результате правок перевода подменил глагол на противоположный по смыслу. В начале было не «накапливается», а «излучается» или «производится». Подскажите как правильнее будет звучать: верхним слоем испускается вторичное излучение?
Это очень близкий к оригиналу вариант перевода.

Я бы сказал так:
В верхнем слое грунта, толщиной всего несколько микрометров,…
PostgreSql только для хранения сессий и кэшей?
Практически 1-в-1 был и у нас. Иногда добавить несколько полей в каждую таблицу намного проще, чем поддерживать запросы с огромным числом джойнов.
У машинных кодов есть один серьезный фатальный недостаток… ;)
Что насчет мониторинга метрик из своих приложений? Можно ли туда передать свои кастомные метрики и настраивать для них оповещения, проводить анализ?
Можно ли передавать сообщения об ошибках из своих приложений?
Что в этом случае означает «открытая встреча»?
Прямо схватка двух Капитанов Очевидность.
И тут такой выходит третий КО и говорит «Всем молчать! Вы оба неправы!»

Я работал в крупной компании, где мне постоянно говорили: «Используй старые наработки компании. У нас уже есть инструмент для этой задачи». В итоге ситуация доходила до абсурда, когда старую наработку было сложнее приспособить, чем написать аналогичное решение".

«Не изобретайте велосипеды!», «Изобретайте велосипеды!» — просто две догмы.
Вместо того чтобы попадать на крючок принципов нужно проводить постоянный анализ каждого инструмента: написать свой «велосипед» или взять уже готовое решение. А потом проводить повторный анализ спустя какое-то время его использования. Причем все это и так делают, выбирая API, компоненты, библиотеки, но по случаю с удовольствием холиварят. Ваш КО.
но есть очень много Project Managers

И я один из них.
С одной стороны, я получаю проблемные ситуации, к которым привело отсутствие записей.
С другой, когда я начинаю записывать, получаю тонны записей, которые лежат мертвым грузом. Каковы критерии важности информации, которую нужно логировать?

Кроме того, вы не ответили про процессы. Я предполагал, что есть какие-то практики возвращения к логам с целью их анализа и систематизации. Но пока вы описали только логирование само по себе. Я не уверен, что из количества (записей) в данной ситуации неизбежно вырастет качество (менеджмента).
Отличный материал, спасибо. Откликов мало, так как интересен не всем, но зато «не всем» весьма полезен.

Объясните цель и ценность логирования. «Записывать имеет смысл все и всегда.» звучит как мантра.
Вот, предположим, пишем и пишем пару лет, накопилось материалов на тысячи листов и сотни тегов.

В каком процессе участвуют эти логи кроме логирования как такового?
«Интересно, мне одному это совершенным бредом кажется?»

Интересно, этот вопрос, лишенный даже малой доли конкретики, мне одному совершенным бредом кажется?
Рисунок искомой надписи сложно вычленить в общей массе текста. Посмотрите на интерфейс LightWave — чтобы найти некоторые пункты меню, их нужно перечитывать.

Из своего опыта: в интерфейсах без иконок я отыскиваю надписи не по их рисунку, а по их расположению. Проще запоминаются координаты надписи, чем рисунок текста.
Не пропустили. Основное сообщение автора: «Не превращаете agile в культ!».
Вы правы, но вы снова рассказываете о способе решения «через не хочу».
Перед началом выполнения «неприятной» задачи есть такой момент, когда нужно себя заставить. В этот самый момент и запускается прокрастинация.
Кто-то, как вы, осознает этот момент и ищет способ решения. Кто-то не осознает и лезет в фейсбук/хабр/артлебедев/курилку etc.
Но этот момент присутствует всегда и у всех (если нет мощной мотивации). Поэтому и говорят про «приятные» и «неприятные» задачи. И это не трындец, а данность.
Вы описали один из способов решения задач: декомпозицию.
Этот способ прекрасно работает, но не всегда применим.
Например, есть рутинные задачи. Я хорошо знаю как их выполнить. Не нужно понимать, что требуется для решения. Не нужно выделять часть и делегировать. Но делать неинтересно. А это уже зависит от склада ума и вещей, на которые мы не можно явно повлиять.
Если я не прав, то расскажите, что такое интерес и откуда он берется.
Зависит от числа задач, но, так ка число или сложность задач со временем растет, то хранить в голове — не вариант.
У меня есть знакомый, который утверждает, дословно: «Ничего не нужно записывать. Если ты не помнишь, что должен сделать сегодня, завтра, через год, через 5 лет, значит ты занимаешься не своим делом». Наблюдаю за ним много лет, постоянно убеждаюсь в его неправоте: «Что? Я обещал это сделать? Может быть. Давно это было.».
Возможно, вам это очевидно, но мне не было сходу ясно, что речь в статье только о Windows-платформе. Я понял только, когда дочитал до «Нужен виндовый сервер». Имеет смысл поместить эту вводную информацию хотя бы после заголовка.

Information

Rating
Does not participate
Location
Berlin, Berlin, Германия
Date of birth
Registered
Activity