Pull to refresh
58
0.1
Alexander @speshuric

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

Send message
Да ладно бы с анимацией. Вот только что пошёл ленту читать. И вот опять. 2,7 МБ КДПВ! И еще ~4 впридачу другими картинками.
Ага, бывает когда даже КДПВ на несколько МБ.
Смотрите, вот пример из вашего текста
Казалось бы, можно предложить эти сферы Асе — ситуация win-win. Но есть одно большое возражение: заметьте, что Ася предпочла уйти в другую команду прежде, чем выяснить возможности роста в своей. Такое поведение, скорее всего, прямо говорит об отсутствии качеств, необходимых для более ответственной позиции: доверия к руководителю, активности, лояльности, умения сформулировать потребности и смелости о них рассказать.

Я его читаю и мне, может быть и неправильно, кажется, что имелось в виду «Ася должна была выяснить», «Ася должна была быть активнее и лояльнее». На месте Аси я бы от этих «кредиторов», которым «должна» бежал бы и без офферов, пока проценты на долги не придумали.
Теперь, после разъяснения, мне уже кажется, что идея в том, что «Асе и мне было бы лучше, если бы она спросила», но всё равно фразы про «активнее и лояльнее» срабатывают как триггеры.

Надеюсь понятно объяснил, что меня напрягло.
Ну тогда, мне кажется, вы с читателями статьи на разных языках просто говорите. Мне показалась статья чересчур категоричной и из серии «сотрудник должен» и «сотрудник обязан». Ничего он не обязан в этой части.

А я всё равно буду спрашивать про возможность контр-оффера, потому что смена сотрудника на нового внешнего — это затраты 3-6 месячных ЗП (есть случаи, когда меньше, но чаще примерно такие). Если прямо сейчас вопрос можно решить за 10% этой суммы в месяц, то так точно надо сделать. Если 20% — то это разумно обсуждаемо. Что делать после контр-оффера — вопрос отдельный, но какие-то выводы и изменения делать надо.
Вот вы про взаимную честность пишете, а на самом деле уровень откровенности между вами и сотрудником в лучшем случае где-то 3-4 из 10 (на 8 он откровенен перед собой обычно, на 9 при глубоком самоанализе, на 6-7 если повезет, то с близкими людьми).
Если вы явно или неявно требуете большего («узнал о возможностях роста» и «озвучил проблемы»), то в лучшем случае получите явный отказ, а скорее всего «фигу в кармане». В большинстве случаев для достаточно сообразительных сотрудников ближние перспективы на текущем месте достаточно понятны и без явного обсуждения, что безусловно не повод для руководителя не общаться на эту тему с сотрудником. Если не подняли ЗП по результатам пересмотра в марте, то зачем ему ждать мифического октября, когда есть понимание, что можно получать больше?

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

Я надеюсь, что это был сарказм. Это самый отвратительный и "саботирующий" KPI из того что можно придумать.
Первое. Это не показатель продуктивности, а "штрафной" показатель. Также, как количество опозданий или количество ушедших клиентов. Это не показатель производительности совсем.
Второе. Даже как штрафной показатель это может разрушить производство ПО и ухудшить качество.


  1. Не бывает полных, непротиворечивых и адекватных спецификаций на программу сложнее блокнота. Для блокнота, впрочем тоже не существует. Менеджмент разработки будет всеми силами всё валить на спецификацию/задание. Причем, если для исправления надо 10 минут, а для того, чтобы "отпинаться" 3 часа — будет потрачено 3 часа.
  2. Без подробной спецификации вообще ничего не будет. Затраты на спецификацию вырастут кратно. Разработка и тестирование будут придираться к спецификации, пока она не станет неподъёмной. Затраты на составление и согласование спецификации можно смело прибавлять к стоимости и срокам.
  3. Разработка будет оценивать задачи, превышающие некоторый достаточно примитивный порог в недостижимую стоимость. Особенно, если это новые возможности. Даже если они выполнимы. Соответственно с этого момента система развивается только заплатками, которые в лучшем случае не улучшат архитектуру (в худшем — быстро похоронят). Приоритеты и возможности развития бизнеса идут лесом.
  4. Тестирование будет постоянно завышать приоритет найденных ошибок и выявлять много мелочи, которая на самом деле не влияет на свойства ПО, но для них это хороший и удобный способ показать, что "мы нашли 100 дефектов, а что 1 пропустили — это посмотрите какой шлак на входе".
  5. Разработчики пишут код с ошибками. И будут писать код с ошибками. И до прода ошибки докатываются. С таким показателем оптимальная стратегия разработчика — написать как можно меньше. Через некоторое время в команде не останется тех, кто заинтересован в развитии. А если еще и наказывать новых разработчиков за ошибки старых, то вообще никого не останется.
  6. Менеджмент разработки сделает всё, чтобы дефект было сложно зарегистрировать как дефект. "Это кривые спеки", "это код вендора", "это ошибка в библиотеке", "это нарушен пункт 182 ч. 2 тома 15 инструкции оператора". Поверьте, это проще, чем писать без ошибок. Ну и конечно, заводить дефекты может только тестировщик, у которого тоже такой же KPI :)
  7. У сопровождения и пользователей быстро накопится много задач типа "это не дефект", которые делают их жизнь невыносимой. Но это не дефекты, нет. И скорость обработки 20 сообщений в минуту внесена в спецификацию. Пользователь не смог купить товар на сайте? Ну конечно, вот это поле обязательное, а он его заполнить не может потому что в мобильном сайте оно не отображется, но всё по спецификации!
  8. Разработчик мягко говоря не будет заинтересован в разработке/прикручивании прозрачного мониторинга системы. В системе будут проблемы, просто о них никто не будет знать.

В следующей итерации придётся завернуть гайки, требовать обоснование оценок, которое будет дороже разработки, еженедельный разбор багтрекера на совете директоров, сравнение трекинга времени и количества закоммиченных строки кода. Добро пожаловать в ад.

Ага, было 5 шагов:

1. Найти узкие звенья системы.
2. Решить, как использовать узкое звено.
3. Согласовать все остальные действия с этим решением.
4. Повысить пропускную способность узкого звена.
5. Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1.

Всё выкинули кроме п 4 (как искать, как устранять простои и непрофильную узкого этапа, как использовать ритм и целенаправленно допускать простой неузких мест).

Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".


  • Начнем с того, что шли они не в шеренгу, а в колонну.
  • Кусок с походом полностью вырван из контекста. В оригинальной книге это был один из ключевых моментов изобретения техники "буфер-барабан-веревка". Почему шли, почему это важно, как реагировали дети на предложения — всё это и есть контекст.
  • Применять "Цель" впрямую к разработке — достаточно спорно и сложно, это сто раз обсуждено и много лет назад написаны "Цель-3", "Критическая цепь" и "Синдром стога сена". Более того идеи КЦ уже проникли и в PMBoK.

И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)

Ну так девопс это не только, и не столько автоматизация сборки и развертывания. (Чтобы не было двоякого толкования: я под Devops понимаю примерно то, что изложено в «The DevOps Handbook» от Gene Kim. В этих терминах даже чисто технически автоматизация сборки и развертывания это меньше половины автоматизации)
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на devops будут ненужными.
А сразу ссылки на фиды дать или еще лучше OPML сделать было сложно?

Для aphyr.com фид я не нашёл.
У Devops есть один необходимый показатель: time-to-market. Сколько прошло времени от идеи до продукта. Если это часы-дни, то девопс есть. Если это недели-месяц, то девопс может и есть, но не работает эффективно. Если это месяцы-год, то никакого девопса нет. Это не «достаточное» условие, но «необходимое». Если вы, предположим, вложили в девопс миллион и time-to-market улучшился с года до 11 месяцев, то вы выкинули миллион.

Остальные показатели и метрики интересны только в контексте «где болит» и «как исправить», причем, если «болит» не на критическом пути, то и приоритет исправления не высокий.
Крупные проекты ну никак не релевантны "советам как оформлять open source проект". Они скорее антипример: во-первых, они вынуждены использовать более сложную инфраструктуру просто из-за объёма фидбэка от пользователей. Во-вторых, они неповоротливы и отягощены тоннами легаси, из-за чего могут до сих пор использовать и CVS, и свои кривые системы сборки, и устаревший стандарт C++, и что угодно. В-третьих, у них свои заморочки с инвесторами. И да, от этого страдают и разработчики, и контрибуторы, и пользователи, и аудиторию они теряют — контрибутить в таких монстров хочет и может далеко не всякий. И тем не менее, зеркало на GH среди них — скорее правило, чем исключение. И почти все (их тех у кого апстрим в git) таки принимают PR.

Не совсем.
Да, есть кейсы, как с ядром линуха, но много труъ опенсорса не хостится на гитхабе вовсе не из-за объёма фидбэка от пользователей, тонн легаси и прочего. Ну в самом деле, какая очередь фидбэка в v8 или Ardour?
Из того, что я вижу основные причины в issue. Issue в github это удобно, пока busfactor==1 и не надо передавать мейнтейнерство. Вторая причина — если проект является частью большой инициативы (chromium, kde, gnu, apache и проч), тогда зеркало обычно есть, но контрибутинг через свою площадку.
И обратите внимание, что каждый отдельный реп обычно не гигантский, примеры: mousepad или gparted — небольшие, а коммитов немного (да и что там докоммичивать?). А в гигантский corefx контрибутят изо всех сил (при том, что там надо соглашение с MS подписать и требования по качеству нормальные). К слову в структуре corefx очень легко разобраться и найти нужное.


Я это всё к тому, что мир FOSS не заканчивается на github trends. Рекомендация для начала своего проекта попробовать github — отличная рекомендация (хотя, как я писал ниже gitlab мне и больше по душе). А безаппеляционное "только github, остальные маргиналы и проприерасты" — уже не отличная, потому что "остальные" себя вполне обосновано могут и мейнстримом считать.
В плане "разобраться с интерфейсом" github, gitlab и bitbucket различаются подчас меньше, чем соседние похожие проекты в jira или youtrack в одной организации.

Что биржа будет делать, если злоумышленник получил root-доступ на большинство серверов?

«Биржа» даже в России — это далеко не однородная структура: несколько юрлиц, сотни серверов, множество разных сервисов (на очень разном ПО, на разных ОС, разные MQ, разные СУБД и всё это не только X86). Поэтому «получить root-доступ на большинство серверов» весьма сложно. Если у злоумышленника настолько большие возможности, то биржа ему зачем?
Как будет обрабатываться ситуация, когда о взломе узнали спустя два-три месяца манипуляции котировками на «низком» уровне (когда разным участникам торгов отдаются разные цифры)?

Эм… Ну начнем с того, что биржа должна в итоге «смэтчить» заявки. То есть у каждого покупателя должен быть продавец с той же ценой (да, тут много оговорок, например центральный контрагент в РФ или несколько уровней брокеров, но сам мэтчинг где-то есть). И у покупателя, и у продавца, и у клиринга есть достаточно информации о сделке, чтобы проверить, что деньги не взялись «ниоткуда». Эта информация очень важна и проверяется многократно и разнообразно. Ведь именно на оборот обычно завязаны комиссии. Это топорно и выявится не «через 2-3 месяца» а примерно в ближайший клиринг.
Схемы, как например, с фронт-раннигом (когда нехороший участник транслирует дальше завышенные котировки, а сам совершает сделку по рынку, делая одновременно встречную с тем, кому транслировал некорректную котировку) обычно делаются не на бирже (там клиринг это сразу покажет), а в совершенно диких и нечестных брокерах. Этими самыми брокерами а не «хацкерами».
И пусть статья весьма «детского» уровня, но вывод в ней в правильный: какой-то компонент биржи взломать можно, но превратить это в свою выгоду (и в потери других) в целом проблематично [гораздо проще ломать других участников].

Этот абзац у автора получился самым спорным и заведомо холиварным.


  • Холивар svn/git/hg. При всей популярности git, на hg сидят крупные и важные проекты (JDK, Firefox), да и некоторые с svn не торопятся уйти. У hg и svn с выбором хостинга посложнее, но бросаться фразами "андеграунд, либо суровая проприетарщина" точно не стоило.
  • Безальтернативно "только github" тоже опрометчиво. Во-первых, есть bitbucket и gitlab, причем последний семимильными шагами наращивает функциональность. У gitlab есть в общем-то всё что и у github, но есть еще закрытые репозитории, есть встроенный CI (не wow, но для микропроектов вполне), есть возможность экспортировать проект с обвязкой типа issue и т.п. в файл и потом развернуть локально — не так страшно всё потерять.
  • Более того огромное количество OS-проектов НЕ хостится на гитхабе. Среди достаточно крупных и серьёзных проектов основной репозиторий на гитхабе скорее исключение, чем норма (linux kernel, kde, gnome, xfce и прочие). Скорее норма какой-нибудь gitorious локальный и списки рассылки. И, да, благодаря архитектуре git у большинства таких проектов есть R/O зеркало на github — просто потому что это легко и незатратно. Но завязывать workflow разработки на github весьма спорная идея даже для pet project.

Хотя если у разработчика есть сомнения, где же выложить свою нетленку, то github самое оно.

Если честно, то я сильно сомневаюсь, что у вас получается настроить независимо две гитары с точностью до 1/4 герца. Да, проверить это можно по частоте биений, которая будет для близких частот примерно равна их разнице. Для независимо настроенных на слух инструментов период биения в 4 секунды это прям "вау". Я когда в пределах одной гитары настраиваю пятую струну по первой или первую по пятой по резонансу третьей гармоники или по натуральному флажолету на 7 ладу, то делаю специально биения в 3 секунды (потому что квинта не ровно 1/3 грифа). У тюнеров, кстати, точность ниже. Но это на инструменте, где я точно знаю, что лады и флажолеты прям отъюстированы. И то на самом деле чуть сильнее прижать струну и будет куча других гармоник/биений.


Резонансные частоты у всех гитар разные и у всех далеко не одна. И учитывая простоту подстройки под любую базовую частоту я сильно сомневаюсь, что мнение гитар в спорах "про ля" учитывается.


Ну и разумеется, равномерно темперированный строй — хорош лишь в теории. когда вы равномерно играете в 24 тональностях. А когда у вас один ля-минор -лучше сделать строй под него.

Хм. Я вот этот абзац не понял. "Равномерно темперированный строй" это, наверное, 99% того, что можно услышать в принципе, более того почти вся современная (последние несколько веков, как подсказывает вики) музыка базируется на равномерно темперированном строе из 12 ступеней. И сам термин "ля-минор" имеет смысл в равномерной темперации, но как-то бессмысленен вне её. Может вы что-то другое имели в виду?

Разница между 440 и 432 навскидку примерно треть полутона. Если взять, например, гитару то без камертона или образца я её настраивал с точностью 1/4-1/5 полутона, но это я делал почти каждый день, это очень знакомый инструмент и это я пытался настроить правильно. Большинство моих знакомых без камертона настраивали менее точно, так что почти уверен, что значительная часть (настраиваемых) инструментов звучит дома и на репетициях черт знает где. Да что там на репетициях! Если на концерте в группе нет чего-то константного (синтезатор, например), то зачастую там плюс-минус четверть тона ошибка запросто бывает.
Из слушателей разницу между 432 и 440 заметит примерно 1 из 100.
Поддерживаю, хотя и переживаю за глаза единорога :) не поэтому ли уже пришлось очки одеть? Судя по тому как работают Ardour, JACK и все эти Catia/Claudia/LADISH, Cadence и открытые драйвера внешних многоканальных звуковых карт (а именно — изредка и вопреки здравому смыслу), единорог может заплакать.

Вот на примере этой публикации и видно почему ICO не доверяют и считают это разводом:


  1. Из 5 примеров ни в одном нет ссылки на домашнюю страницу.
  2. Из 5 проектов, кажется, ни один до продукта и стабильной выручки не дошёл. Ну то есть так чтобы это не было чем-то "пирамидообразным", чтобы были стабильные кастомеры и т.п.
  3. Я не вижу и не смог найти откуда взяты оценки ICO в $. Ну в самом деле — если это долларовые оценки в какой-то криптовалюте, то в какой валюте, на какой момент курс?
  4. Если "Filecoin" и "Status" содержат хоть какую-то конкретику, то остальные почти чисто производные от "криптовалютной" темы. А значит вне этой темы не видно монетизации, а риски впрямую связаны с рисками регулирования криптовалют.

Это только беглое прочтение, дальше просто и копать было лень.

Как выше отметили — ЗП неадекватно низкая, вот и вся аналитика из пальца. На позиции за 60 в Мск берут примерно за факт прихода на собеседование. На 80 — знает хоть что-нибудь (или не знает, но попросил 80 и вел себя адекватно). С портфолио (пусть и Потемкинская деревня), с подогнанным резюме и "был осведомлен о последних тенденциях веб-разработки, знал основные инструменты верстки и мог уверенно вести беседу о своем опыте работы на профессиональном языке" — смело надо было ориентироваться на 90-110. Тогда бы был хоть какой-то шанс увидеть технические интервью.

Information

Rating
2,817-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity