• Ваш мобильный навигатор затрудняет управление дорожным движением
    0
    Да ладно с ними с нейронами, кажется, не строить маршрут через мост, который разведен согласно расписанию — уже более работающее решение, чем то, что есть сейчас.
  • Ваш мобильный навигатор затрудняет управление дорожным движением
    0
    Больновато читать размышления в комментариях о том, что условный Яндекс.Навигатор может всё это просчитывать в реальном времени, в то время как Яндекс.Навигатор так и не научился не строить маршруты через разведенные мосты в Питере.
  • Разработка интернет-магазина для сохранения природы Камчатки
    +1
    После просмотра сайта появилось желание съездить на Камчатку.
    Купить вещи желания не появилось.
    Ну, и как справедливо заметили — если господа хотят пиарить свои вещи «помощью Камчатке» — неплохо бы об этом рассказать подробнее. Что, как, кому помогаете, по какому принципу, сколько денег, etc. А пока выглядит как глупый пиар.

    Такая себе success story, честно говоря.
  • Взрывающие телефон
    +2
    От прочтения статьи впечатления примерно такие же, как у главного героя при получении первой записки.
    Вроде все символы выглядят знакомо, но какая-то тарабарщина.
  • Нейронки за 5 минут
    –1
    Нет, не вижу. А она есть?
    Пока что всё, что я вижу, это как вы проецируете собственные предрассудки на те или иные категории граждан.
  • Последствия блокировки для Telegram
    0
    Если я не путаю, то это ситуация «ФСБ утверждает, что человек пользовался телеграм», а не доказательства.
    Во всей этой схеме слишком много допущений для того, что бы считать утверждение «телеграмм используется террористами» верным.

  • Последствия блокировки для Telegram
    +3
    Имею в виду популярность продукта у запрещённых группировок и противодействие этому со стороны государств.

    Использование Телеграма террористами становится гарантом конфиденциальности сервиса.


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

    Если нет, то давайте прибережем формулировки «популярен у террористов», «используется террористами»и пр. для Первого Канала? Зачем у людей хлеб отбирать.
  • Неожиданные преимущества ролевых настольных игр
    0
    Пятое издание такое себе. Лучше уж 3.5 хотя бы, если не 2. ;)
  • Почему я не люблю DevOps (и современное ПО)
    0
    Всё сильно зависит от специфики.
    Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.

    3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
    Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
    Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.

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

    Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
    Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
  • Почему я не люблю DevOps (и современное ПО)
    +4
    Ещё раз. Как таковой DevOps ничего не убивает.
    Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
    Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
    А регрессия на нем шла в ручную в среднем три дня.
    Потом там находились баги, они правились, и регрессировали ещё три дня.
    Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
    На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.

    В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
    Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
    И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
    Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.

    Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.

    Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
    Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
    Но это не изъян практик, это изъян людей.
  • Почему я не люблю DevOps (и современное ПО)
    +12
    Во первых, обеспечение качества это не (только) тестирование. И тем более это не только ручное тестирование.
    ДевОпс практики никак не ограничивают обеспечения качества, более того, правильно построенный процесс должен не только помогать бесконечно, быстро и прозрачно деливерить, но так же просто, быстро и безболезненно оценивать результаты релиза и, при малейшей необходимости, безболезненно откатываться.
    Это то, что называется мониторингом и управлением качеством. QA инженеры неистово радуются такому.

    Теперь по поводу ручного тестирования, его смерти и смещения в автоматизацию.
    Первое: Автоматизация заменяет регрессионное ручное тестирование.
    Это как раз те самые тесты, которые точно так же идут по заранее расписанным сценариям и точно так же, как и автотесты, пропускают всё, что ими не покрыто.
    Это регулярно повторяемая, однообразная и не слишком интересная работа — то, что стоит автоматизировать всегда и при любой возможности.
    Это освобождает ресурсы вашего отдела тестирования для исследовательского тестирования и тестирования методом свободного поиска. Как раз тех видов тестирования, где нужны интуиция, чувство прекрасного, здравый смысл и аналитические способности. Словом, всё то, что может человек, но не может скрипт написанный человеком.

    Убивает ручное тестирование вовсе не ДевОпс, а потребности бизнеса и реалии рынка.
    Ручное тестирование убивает скорость.
    Сейчас даже у SPA для продажи носков такое количество ручек, состояний и внешних интеграций, что тестировать его руками — долго и неэффективно.
    А делать кодфриз на неделю, что бы хорошенько всё оттестить не нужно примерно никому.
    В то же время инженеры по тестированию — ограниченный, дорого и плохо масштабируемый ресурс.
    Автотесты, в свою очередь, масштабируются очень просто и стоят относительно недорого.

    Ну и скопом отвечу на ваши комментарии выше:
    1) «Традиционный QA» отлично себя чувствует в полном CI\CD окружении. Потому что тестирование — один из этапов CI\CD.
    Размазывание ответственности за качество на всю команду это то, за что будет неистово топить любой адекватный QA инженер. И этот тезис появился задолго до того, как девопс практики вошли в моду.
    Может ли команда, следующая devops практикам существовать без QA Engineer как выделенной роли? Да, может.
    Значит ли это, что там не будет QA, QC и тестирования как набора активностей? Нет, не значит.

    Кажется у человека, на которого вы ссылаетесь, просто каша в голове из понятий.

    2) Интеграционное и регрессионное тестирование — отлично поддается автоматизации. Это тривиальнейшая инженерная задача, которой за месяц обучается человек, раньше не писавший код вообще.
    Это полтора прикладных инструмента, три паттерна и совершенно типовые архитектурные решения.

    3) Код автотестов может содержать ошибки. Это так. Точно так же, как ошибками может обладать документация для тестирования.
    Но тут есть одна ключевая разница: автотесты ведут себя одинаково всегда. Вы можете бесконечно расширять их набор, увеличивая покрытие, и их поведение не будет меняться от того, что вам понадобилось прогнать регрессионный набор тестов 12 раз подряд в ночь с пятницы на субботу.
    Ручное тестирование всегда обладает человеческим фактором. В случае регрессионного и функционального тестирования — это огромный минус. Потому что глаз замыливается, внимательность может падать, а прогонять нон-стопом регрессионные тесты — это своего рода пытка.

    Меняется ли тестирование и QA? Да, меняется.
    Происходит ли это за счет популяризации девопс практик и инструментов? Да, в том числе.
    Приводит ли это к смерти тестирования? Нет, не приводит. Это приводит к тому, что в тестировании начинают использовать код там, где код эффективнее, оставляя человеку те области, где он (пока что) выигрывает.

    P.S. И да, я работаю QA инженером и прекрасно вижу, что происходит на QA-рынке.
    Никакой смертью QA там и не пахнет. Зато действительно появляется всё больше компаний, которые понимают, что просто посадить 10 тестировщиков что бы они нон-стопом гоняли одни и те же тесты из релиза в релиз — недостаточно для обеспечения качества продукта.
  • Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm
    0
    Всё так, всё так. В целом, про велосипеды была отсылка именно к первой мантре разработчика.
    Касательно Zen of Python, я бы сказал что в моей голове это тезис хорошо соотносится с Simplicity is better than Complicity, т.к. «не делать лишнюю работу и использовать готовые решения» — тоже часть упрощения твоего кода. Но в целом да, моё высказывание было не до конца корректным.
  • Рассказ о том, как я майню эфир через meltdown на ваших телефонах при помощи npm
    +6
    Я, конечно, понимаю, что говорю с переводом, но всё же.
    Я не увидел в оригинальной статье посыл, что «NPM — зло, давайте забьем разработчиков камнями». Она (на мой скромный взгляд, опять же) про то, что инфраструктура разработки — это тоже вектор атаки на продукт.
    И тут хочется отметить несколько моментов:
    Первый — автор «ответа» явно передергивает, когда сводит всё к «Автор уговорил разработчиков внедрить свой вредоносный код». Это немного искажает суть: Злоумышленнику достаточно убедить внедрить этот код кому-либо из разработчиков внутри вашего dependency-tree, что бы после обновления зависимостей вы получили у себя в продукте вредоносный код.

    Второй — Да, опенсорс строится на доверии. Да, каждый из нас может делать его лучше. Да, подтягивая зависимости мы берем ответственность за последствия.
    Это всё очевидно и правильно. Это не отменяет того факта, что в моем домашнем проекте, который я быстро накидал за пару выходных как proof of concept, объем кода в dependency tree в несколько раз больше, чем, собственно, в самом проекте.
    Ну, просто потому, что Zen of Python и первая мантра разработчика: не пиши велосипед, используй готовое решение.
    И да, я понятия не имею, что происходит под капотом у зависимостей дальше первого уровня дерева (т.е. кроме тех, которые я подтянул сам).
    И далеко не у всех команд разработки есть ресурсы (будь-то сила, время или компетенция) изучить полностью древо зависимостей на предмет уязвимостей.
    Потому что помимо интерпрайза есть инди-разработчики. Потому что помимо умудренных опытом дримтимов есть ребята, которые делают свой проект на коленке, а потом данные пользователей их мобильного приложения утекают черти куда.
    Заслуживают ли такие разработчики пинков коллег, общественного порицания и ночных багфиксов потом? Возможно.
    Но их пользователи определенно не заслуживают того, что бы их данные куда-то сливали из-за неосмотрительности разработчика.

    Итог:
    Сгустил ли автор оригинальной статьи краски про то, как просто всё это осуществить, что бы более драматично обрисовать масштабы уязвимости? Да, определенно.
    Действительно ли этой проблеме нужно столько внимания, что бы на её тему поднимать панику и драматизировать? На мой взгляд тоже да.
  • Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов
    +8
    Затем, что контролем кода занимаются одни люди, а оформлением на себя дополнительной карты — совсем другие.
    И когда с вашего сайта радостно начнет утекать sensitive data пользователей, ответ «Да завели бы себе отдельную карту и всё» их вряд ли устроит.
    Не говоря уж о том, что платежные данные — не единственная ценная информация, которую оставляют пользователи на сайтах.
    Это точно так же могут быть реквизиты аккаунтов, сканы документов, приватный контент, whatever.
    И в итоге попытка отказаться от использования всего этого в интернете сводит всё к п.1 из статьи выше.

    upd: Я буду обновлять ветку комментов каждый раз, перед там как что-то постить.
  • Мой опыт войти в айти в сравнении с тамбовким таксистом
    +1
    Вы знаете, если оторваться на секунду от заоблачных зарплат в заказных постах, и посмотреть на общую картину, о которой говорится в посте: в IT все ещё относительно высокие зарплаты и безумный кадровый голод.
    Последнее время приходится искать к себе в команду людей (как раз таки тестирование\QA).
    На Питерском рынке все очень плохо. Катастрофически.

    Джуниоры, которые приходят, ожидают, что идут в школу. Их надо плотно менторить, следить за каждым их шагом, указывать что и где почитать и чуть ли не домашнее задание выписывать.
    Им не достаточно того, что бы им дали практическую задачу, неограниченное время её решение и проверили результат.
    Да, многие из них говорят «Я готов работать хоть за еду». Но поймите, мне не нужно, что бы вы работали бесплатно. Мне нужно, что бы вы хотя бы старались учиться и работать самостоятельно. Не получается? Окей, вопросы приветствуются, помощь будет оказана.
    Но сидеть и плевать в потолок потому, что ментор не накидал тебе задач и не проследил, что ты их делаешь, серьезно?
    С миддлами и синьорами ситуация примерно аналогичная. Да, они уже научились решать типовые задачи по четко заданным инструкциям, но приносить пользу без постоянного менторинга — не могут.
    Да, эти люди сидели, и писали автотесты. Да, эти люди тестировали сложные системы ПО и писали к ним горы документации.
    При этом на простые вопросы «Почему сделал вот так, а не вот так» они не могут ответить.
    Это даже не «Не знаю других решений», это «Зачем мне рассматривать варианты, если я уже нагуглил один ответ?».
    И эти парни приходят на собеседования с зарплатными ожиданиями в 100+к, что является вполне хорошей зарплатой для СПБ, на мой взгляд. Для человека с 2-3 годами опыта в отрасли.

    К чему я это все?
    Да, в отрасль за последние 5-7 лет пришло довольно много людей (в том числе я, например).
    Но, даже если закрыть глаза на то, что и сам рынок IT сильно вырос за это время, количество людей, которые хотят работать от этого увеличилось не сильно.
    В IT довольно легко «войти», но надо понимать, что на этом вхождении всё не заканчивается.
    Впереди ещё огромный путь, полный самообучения, сомнений в собственной компетенции (почти всегда обоснованных) и проблем, которые придется решать самому. Если человек к этому готов — он без проблем найдет работу и довольно стремительно начнет зарабатывать приличные деньги.

    P.S. Рынок зарплат и медианные цифры — не сильно показательная картина, на самом деле.
    Взять тех же QA инженеров. Я собеседовал довольно много людей, опыт которых при измерении в годах сильно превышает мой собственный. Первые несколько раз меня это безумно сильно беспокоило, типа: «Как так? У этого парня в два раза больше опыта, чем у меня, а я буду его собеседовать?!»
    После десятка таких собеседований мне хотелось сойти с этой планеты, потому что люди с 9+ годами опыта даже не проверяли, компилируется ли код, который они высылают в тестовом задании (спойлер: нет, не компилируется). Те, которые проверяли — присылали код хуже, чем взятый мной на работу junior.
    Как результат: многие из ребят, с которыми мне доводилось работать, сейчас получают суммы, находящиеся или на верхней границе, или выше Питерского QA рынка зарплат.
    Многие из тех, с кем приходилось пересекаться работают Senior QA Engineer на зарплате миддла, и даже её, на мой взгляд, не особенно то заслуживают по уровню своей компетенции.
  • Все профессии важны: почему тестировщика нужно ценить не меньше, чем программиста
    +7
    Давайте начнем издалека:
    QA — это не только тестирование. А автоматизация тестирования — это всего лишь инструмент, а не отдельный «вид» или специальность.
    Чем больше опыта я набираюсь в качестве QA-инженера — тем больше простора для развития вижу. Хотя, вынужден признать, после определенной планки количество «интересных» вакансий начинает стремительно падать.
    Но всё таки. Список компетенций, которыми приходится обладать QA инженеру (в широком, т.е. правильном, смысле этого термина) — предельно широкий.
    Ты должен обладать достаточной компетенцией в разработке — тебе необходимо понимать, как будет работать код, который пишут твои коллеги. Видеть все возможные bottleneck`и и потенциальные проблемы, а в определенный момент — не только увидеть их, но и суметь донести это видение проблемы до коллег и, возможно, предложить альтернативные варианты.

    Ты должен обладать хорошими навыками аналитика и менеджера, что бы работать с требованиями, избегать создания defective by design продуктов, иметь возможность увидеть и оценить максимум из возможных сценариев использования.

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

    Ты должен разбираться в инфраструктурных моментах, ведь недостаточно обеспечить корректное выполнение кода в вакууме. Приложение должно работать корректно (а формирование критериев корректности — это отдельная история) в продакшен окружении.
    И тебе нужно понимать, как создать адекватное тестовое окружение и каким оно должно быть, что бы это было production-like. Тебе нужно понимание того, как это сделать (что бы если уж не настроить самому, то иметь возможность сформировать требования коллегам).

    Ко всему этому необходимо понимание бизнес-специфики приложения, с которым вы работаете. Просто потому, что критерии качества, которые вы должны формировать и которым должен соответствовать продукт, неразрывно связаны с бизнесом. Нет золотого стандарта «high quality product», подходящего для всех приложений. Где-то важна высокая отказоустойчивость и минимум багов. Где-то важна возможность безболезненно откатиться, но опробовать фичу. Где-то вы можете допустить 300 UI багов, главное что бы логика работала, а где-то цена одной уехавшей кнопки слишком высока.
    Для каждого продукта процесс «калибровки» качества разработки будет разным. И ожидаемый результат — тоже.

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

    В целом, да, я думаю что любой опытный QA инженер должен иметь навыки автоматизации.
    Это не значит, что он должен ей сконцентрироваться на написании автотестов. Это значит, что он должен понимать когда и в каком виде стоит применять это решение. Какой профит от этого будет и каких трудозатрат это потребует.
    С другой стороны я, например, категорически не понимаю Test Automation Engineer, т.е. ребят, которым спускают список кейсов на автоматизацию, а они выдают код. На мой взгляд, это категорически неэффективная схема.
    Но это всё тема для холиваров.
  • Вы работаете не в том месте (если у вас офис открытого типа)
    0
    Ну, эта часть пассажа касалась, преимущественно, не разработки. Согласен с вами, не сильно комфортно так сидеть.
    Хотя знаю ребят из смежных областей, который при возможности распланировать свое рабочее пространство так, как им хочется — выбрали именно этот.

    В любом случае, мне кажется, любая (пере-)планировка должна отвечать интересам команды и людей в ней.
  • Вы работаете не в том месте (если у вас офис открытого типа)
    +1
    Ну, перекрытия\перегородки тоже бывают разные. Я, например, считаю что возводить сплошняковые стены стоит только в крайней степени (они жрут много «воздуха», особенно с высокими потолками) при этом принося довольно мало пользы.
    Зонировать и разделять пространство можно очень по разному и стены — не всегда оптимальный вариант.
    (Естественно, не классический кубический вариант, да)

    Ну и в любом случае то, как ты планируешь использовать пространство влияет и на выбор здания. Покупать ангар, что бы строить тонну стенок внутри — выглядит не самым идеальным планом, проще найти уже поделенное на кабинеты пространство.
  • Вы работаете не в том месте (если у вас офис открытого типа)
    +1
    Плюс «открытой» планировки в том, что её можно почти безболезненно адаптировать и перепланировать под себя.
    Если у вас есть здание, построенное тремя сочлененными буквами Щ, то любая перепланировка и перераспределение пространства будет сталкиваться с этими ограничениями.
    В то время как огромный ангар (на примере фейсбукового) можно зонировать и перепланировать как душе угодно.

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

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

    При чересчур плотной рассадке опенспейс превращается в дикий курятник и некомфортно ни кому, но и кабинетная структура при наличии двух квадратных метров пространства на человека даст себе так себе результат (мне бы, например, не хотелось сидеть в «кабинете» размером с собачью будку).
  • «Энтерпрайзная срамота» или как свести с ума разработчика на собеседовании
    –2
    В целом всё верно. Если все вышеперечисленное вызывает у вас неистовый баттхёрт попаболь — лучше сразу идти к двери, избавите компанию от неадекватного сотрудника.
  • Оживляя динозавров: TDD vs Test-Last
    +2
    Юниты не заменяют интеграционных тестов. Как и наоборот.
    Как вы думаете, сколько времени для разработчиков и тестировщиков вы сэкономите, если перед каждым часом прогона интеграционных тестов (которые потом упадут и укажут на проблему взаимодействия модулей), будут гнаться секунды юнитов (которые потом упадут и укажут на конкретную точку отказа)?
    Юниты, по сравнению с интеграционными тестами, имеют ряд ключевых преимуществ.
    Они быстрые, атомарные и независимые.
    Если у вас упал интеграционный тест — вы садитесь и дебажите, почему он упал (даже при правильном разграничении тестов и читаемом output всегда существует более одного варианта причины падения).
    Если у вас упал юнит тест — в большинстве случаев он слишком атомарен, что бы вы дебажили его падение сколько-нибудь долгое время.
    Более того, юнит тесты стабильнее, в том смысле, что лучше переносят изменения системы.

    В статье есть отличная пирамидка из уровней тестирования.
    Один уровень не заменяет другой, но они отлично дополняют друг друга. Писать и гнать тесты выгоднее всего, в долгосрочной перспективе, снизу вверх.
  • Гороскоп для разработчиков
    0

    Ничего общего с действительностью, как обычно и бывает в гороскопах :)

  • Дмитрий Сорин, Senior Software Engineer в Atlassian, поделился впечатлениями о пяти годах работы в «Яндексе»
    0
    Окей, убедили. Я предпочитаю работать в компаниях, где это сопряженные метрики. :)
  • Дмитрий Сорин, Senior Software Engineer в Atlassian, поделился впечатлениями о пяти годах работы в «Яндексе»
    0
    Я не мешаю, я делаю выводы из написанного. Если бы там было написано «не холиварить за зря по технологиям» — вопросов было бы значительно меньше. Вы же написали «не спорь с руководителем, он умнее».
    Но, даже в вопросах применяемых технологий аргументация на уровне «я начальник — мне виднее» это провал.
    Тем более, что вы стремитесь, вроде как, набирать классных специалистов.
    Если преимущества выбранного мудрым руководителем технического решения очевидны — компании выгоднее, что бы эти преимущества один раз были озвучены, разработчик осознал и получил +100 exp.
    Если они не так очевидны, как хотелось бы руководителю всегда можно сказать «это тема для разговора, давай обсудим потом, сейчас дедлайн».
    Подход же «начальнику виднее как делать» убивает в людях инициативу. И не особо важно, заключается ли инициатива в том, использовать промиси или нет, или же в какой цвет покрасить кнопку и где её расположить.
    Важно, что «кому-то там виднее, как делать — буду делать так», вместо подумать головой, поговорить и понять, почему именно так.

    Опять же, у меня не достаточно информации, что бы судить как оно там на самом деле. Я лишь отталкиваюсь от того, что написано в статье. Фидбэк и вот это всё.
  • Дмитрий Сорин, Senior Software Engineer в Atlassian, поделился впечатлениями о пяти годах работы в «Яндексе»
    0
    На фоне нытья про овертаймы и низкие зарплаты меня больше всего смутило
    Не спорь с начальником
    как аргумент влияющий на продвижение по карьерной лестнице.
    В то время, как во всем мире ищут разработчиков, готовых думать про продукт, а не просто решать спущенные сверху задачи, Яндекс говорит «не твоего ума дела, я начальник — ты дурак».
    Классненько.
  • Блеск и нищета автоматизации тестирования
    0
    У вас очень странные выводы.
    Если у вас стартап, который требует динамичного развития, вы уверены, что у вас есть ресурсы гонять 5 часовую регрессию руками?
    Если у вас стартап, который активно набирает обороты, уверены ли вы, что стоит жертвовать качеством ради ускорения релизов на 10-15% времени? (И, что важнее, так ли в этом уверены ваши пользователи?)

    Во всём нужен баланс.
  • Блеск и нищета автоматизации тестирования
    0
    Уверенность в качестве это когда вы знаете, что API не ответит ошибкой при нормальном user flow.
    То, о чём вы говорите — это уверенность в возможности быстро локализовать проблему.

    Проблема «мониторинговых» тестов в том, что они алертят постфактум. Т.е. вы узнаете о проблеме только тогда, когда N пользователей вместо ожидаемого результата получат хрен.
    Более того, в случае новой функциональности и всяких изощренных юсабилити экспериментов всё ещё сложнее — вы не всегда можете понять, то ли UX эксперимент не удался и конверсия просела, то ли пользователь не видит кнопку сабмита формы (условно) и уходит нахрен.
    Пока вы это выясняете — пользователи испытывают баттхёрт. И вы их теряете (при условии, конечно, что у них есть альтернатива, но если её нет — можно и вообще не париться, и так схавают).

  • ФСБ арестовала лидера «Шалтай-Болтая»
    0

    Не очень понимаю, как связаны эти два тезиса.
    Если сми очевидно врут — поводов верить им нет, даже когда это единственный источник информации.
    Эта вся ситуация настолько шита белыми нитками, что прям ух.

  • Лучшие головоломки, про которые не знает никто*
    –1
    Я вас расстрою, но ни одна из приведенных вами игр не является специфично «гиковой».
  • ФСБ арестовала лидера «Шалтай-Болтая»
    0
    Слабо в это верится, честно говоря.
  • Бывший разработчик Firefox: удалите сторонние антивирусы
    0
    И в итоге пользовать открывает другой браузер и качает нужный ему антивирус.
    Будет мне ещё браузер указывать, куда ходить.
  • Как работают ИТ-специалисты. Андрей Цай, ADV-ONLINE
    0
    Давайте по порядку. Комп компании.
    Первое, я не верю, что в IT компании CTO не может купить себе комп, которым ему будет приятно пользоваться.
    Т.е. это не джуниор разработчик, которому «что выдали — на том и работаю». Немного не тот уровень.

    По поводу имиджа. Есть вполне себе премиумные виндовые девайсы (как всякие там surface и топовые dell).
    Которые так же органично вписываются в имидж крутого и статусного CTO, как и макбук про.
    В общем, это тоже не самый однозначный ответ.

    Может, всё таки, люди имеющие вес в IT отрасли должны двигать мысль, что нужно использовать удобные инструменты для решения своих задач, а не яблоко ради яблока?

    Я, как бы, не осуждаю и всё такое, просто «вынужден» кажется весьма натянутым. Хотел бы — не использовал бы.
  • Как работают ИТ-специалисты. Андрей Цай, ADV-ONLINE
    0
    Вот интересно, зачем человеку, 99% времени работающему в Chrome — Макбук Про?
    Тем более, что «вынуждено»?

    Я конечно понимаю: CTO, статусно-бохато, но всё же.
  • Что изменилось в 2016 году в сфере программирования? Итоги прошедшего года и планы на 2017
    +11
    И это блог образовательной, прости господи, площадки.
  • Система военных Великобритании видит работающую технику даже за бетонной стеной
    +1
    Идея неплохая, но боюсь скоро демонтируют.
  • Интересные Sсi-Fi фильмы, которые вы (не должны были, но) могли пропустить в 2016 году
    0
    Отлично. Ещё в этих цивилизациях было много других норм и «гражданских долгов».
    Не говоря уж о том, что в то время такой гражданский долг мог быть оправдан из-за низкой продолжительности жизни и высокой смертности.
    Да и банально тем, что эти сыновья должны были поддерживать хозяйство и обеспечивать твою старость. Других вариантов особо не было.
    Сейчас этих проблем не стоит, нормы морали видоизменились и в общем-то двадцать первый век наступил, добро пожаловать.
    И любому разумному человеку насрать, кто с кем спит, у кого есть жена, а у кого нет, и прочее.
    Это личное дело каждого и не иметь детей вообще — точно такая же норма, как иметь 1-2-3-4-5-17 детей.
  • Интересные Sсi-Fi фильмы, которые вы (не должны были, но) могли пропустить в 2016 году
    0
    Это очень плохой Sci-Fi.
    Т.е. как бы изначально он хотел таковым быть, но когда они заткнули дыру в космическом корабле планшетом — Sci самоаннигилировался, остался только fi.
  • Интересные Sсi-Fi фильмы, которые вы (не должны были, но) могли пропустить в 2016 году
    0
    Гомосексуальность не нарушает функций размножения. Т.е. в случае совокупления с особью противоположного пола шансов на размножения столько же, сколько и у гетеросексуальных особей.
    Другое дело, что люди ставят своё личное счастье выше функции размножения, и подобный контакт им не интересен. Thats all.
  • Интересные Sсi-Fi фильмы, которые вы (не должны были, но) могли пропустить в 2016 году
    +6
    А где взаимосвязь между моралью и сексуальной ориентацией?
    Я вот вижу, только, что вы бугуртите и гомофобите из-за неугодных вам сцен в зарубежных произведениях.
  • У разработчика программного обеспечения должен быть опыт сисадминства
    0
    Это нормальная практика, но вы же понимаете, что говорите об очень узкоспециализированном специалисте?
    Т.е. он не может поменять стэк технологий, потому что привязан к 1С. Он не может переметнуться в другую сферу, когда бухгалтерия ему надоест.
    Да банально страну дислокации сменить не может, потому что условный 1C нафиг не нужен в условных штатах.
    Разбирается и в бухгалтерии, и в бизнес процессах — скорее следствие того, что N времени он работает в этой сфере. А не следствие того, что он до этого бухгалтером работал.
    При этом 2к/час — вполне средняя цифра для фриланс разработчика с хорошим стажем. Ничего космического.

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