• Менеджерам пора проснуться
    +2

    :) image

  • Менеджерам пора проснуться
    0

    В цитатах программистов детский сад какой-то, «я рад, что просто уволился через пять месяцев» — да ты должен был встать и уволиться через 5 минут, дурак!

  • Изучаем этику секс-роботов по голливудским фильмам
    0
    Парень, тебе же написали — «по голливудским фильмам». Чёрное зеркало — британский.
  • Какой спорт выбрать, или как войти в IT и остаться здоровым
    +1
    Бег и велосипед в городе — нереально. Ну кому-то повезло жить рядом с парками или на окраинах, но остальные 99% бегунов надышат себе полный организм выхлопных газов. Глупо. Даже в маске (углекислый газ абсорбирующими фильтрами не задерживается, против него поможет только фотокатализ, но таких масок пока в широком доступе нет).

    Поэтому — летом велик в машину и осваивать пригороды, а зимой — только зал.
  • Учим английский по компьютерным играм
    0

    И не слушайте того, кто говорит, что в шутерах лексикон ограничен. Это у тебя он ограничен, чувак. Открой рот и начни говорить с тиммейтами о жизни, работе, семье, музыке. Ну, в крайнем случае можно о бабах.

  • Учим английский по компьютерным играм
    0

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

  • Курс молодого бойца PostgreSQL
    +2

    Откройте для себя товарища Левенштейна https://postgrespro.ru/docs/postgresql/9.4/fuzzystrmatch.html

  • Вы уволили самого талантливого сотрудника. Надеюсь, теперь вы довольны
    –3

    А почему ты считаешь, что твоя "головная боль" и твоё мнение о расходе собственного рабочего времени должны идти вразрез мнению твоего руководителя? Может быть, ты рок-звезда? По-моему, если босс решил, что для всей команды выгоднее, чтобы джуны смотрели твои пулл-реквесты, а ты бы им разъяснял, то будь добр — показывай и разъясняй. Или ищи другую команду.

  • Еще один пост «почему Agile не работает» (с картинками)
    +7

    Я ничего не понял во втором пункте. Что значит "платят за выгоду"? Почему 75 процентов? Чем недоволен коллектив?


    Это что-то узкоспецифичное из индустрии автора?

  • Необразованная молодёжь. Ответ бизнеса
    0

    Автор, у вас полный трэш начиная с того, что у вас директор — главный разработчик. Если бы он был нормальным директором, он бы вам объяснил, что зарплаты берутся не от "умения и опыта", а от рыночного спроса.


    Не говоря уже о том, что вы пишете на Дельфи в 2017-ом году.

  • Это заблуждение, что технический директор занимается исключительно техническими вопросами
    +3

    Я техдиректор :) Читал с удовольствием до абзаца про бег, процесс и результат. Там написана бредятина, стереотип, который портит всё впечатление. То-ли сформулировано криво, то-ли все вышестоящие рассуждения про работу с людьми не соответствуют действительности.

  • Ожидание длиной в 15 лет. Nginx Application Server
    +4

    Пхп, питон… А ruby, ruby-то где?

  • Грехи и добродетели — в веб-разработке
    +9

    Про тесты ты по-прежнему не прав :) Тесты пишут не для того, чтобы проверить, хорошо ли работает код. Тесты пишут для того, чтобы если через два года десятый по счету менеджер и пятнадцатый программист сломают какую-то фундаментальную штуку в бизнес-логике — это было бы видно СРАЗУ.

  • Хорошо в деревне летом со стамегабитным интернетом
    +1

    Блин, ребята, вы молодцы! Сам парился два года с мачтой и антеннами, пока не получил наконец более-менее стабильные 25мбит (полсотни километров до Санкт-Петербурга). Но это решение конечно с вашим не сравнить, респект!

  • Сети Петри с Symfony а-ля WorkFlow компонент
    0

    Не менее интересно делать системы, в которых путь workflow можно формировать динамически, например из веб-интерфейса. В этом случае кастомер сам конфигурирует состояния, возможные переходы и правила "допустимости" перехода из одного состояния в то или иное новое. Вот один из примеров моих систем: https://github.com/dobryakov/workflow-system


    А вот и другая статья на тему, как можно отдать поток исполнения в руки кастомеру: https://www.dobryakov.com/blog/1838/

  • Немодные модные трекеры: Samsung, Polar, Withings, которых не ждали
    0
    Долго выбирал между оптическим и нагрудным датчиком (жаба душила), в итоге взял Polar H7.
    Работаю со спортивными часами Polar A300. Что получилось в результате:

  • В Норвегии с паразитами рыб борются при помощи подводных роботов с лазерами
    0

    Передайте Матвиенко.

  • Какой пульсометр выбрать в новом сезоне: компромиссные решения в пределах трех-четырех тысяч рублей
    0

    Долго выбирал между оптическим и нагрудным (жаба душила), в итоге взял Polar H7. Работаю с часами Polar A300. Что получилось в результате: https://youtu.be/nVfrZqShUEg

  • Как пасти скотов. Советы руководителю подразделения разработчиков
    –4
    Первое правило — хренотень. Руководитель должен быть лидером, понимать устройство рынка, интересы бизнеса, потребности потребителей. Должен быть коммуникабельным, экстравертом, немного психологом, чтобы объединять вокруг себя умных людей и вести их в нужном направлении. Должен постоянно коммуницировать с «гуманитарными» сотрудниками (отделом продаж, отделом маркетинга и т.д.)

    И вы хотите, чтоб он ещё и код писал? Да щас, блин.

    Второе правило тоже хренотень. Даже лень объяснять почему.
  • Микросервисы: опыт использования в нагруженном проекте
    +2

    Уфф, всю статью читал в напряжении, дойдете вы до шины данных с выбрасыванием эвентов, или нет. С этого надо было начинать :)


    Респектище за статью и архитектуру, молодцы!

  • Программисты не могут написать алгоритмы без помощи: ещё раз про интервью
    –5
    Спрашивать алгоритмы на собеседовании — это такой способ самоидентификации в обществе, демонстрация принадлежности к социальной группе, как не показывать поворотники при перестроении — то есть, говорить «я п*дор». Просто на собеседовании неловко спросить кандидата, п*дор он или нет, вот они и маскируют вопрос под алгоритмы.
  • Договорённости о коммуникациях
    0
    Автор, вас только что вынули из глубокой заморозки?
    Письма, автореплаи, MS Outlook… В 2016-ом году?

    Назовите компанию, в которой работаете, чтобы никто туда случайно не пошёл.
  • Как улучшить работу модема при плохом покрытии сети
    +10
    Вода, вода. Кругом — вода. Про самое главное не сказали не слова, поэтому, извините, скажу за вас. У разных операторов в разных городах (и даже областях) — разные частотные диапазоны, как это можно увидеть на картинке

    image

    Частота не зависит от «типа связи» (2G, 3G, 4G), а выдаётся надзорным органом для конкретной местности. Нормальная антенна ловит плюс-минус 100 от своей частоты, поэтому идея «универсальной антенны» под все — не более чем унылый маркетинговый трюк. Нужно в конкретной местности смотреть статистику, отдаваемую модемом, выяснять какой *конкретно здесь* используется BAND и какая частота, и подбирать антенну под неё.
  • React.js — Руководство для Rails разработчиков
    +1
    Собственно главная беда реакта озвучена в самом начале: это не MVC, а только view-слой.
    Поэтому, как только перед адептами реакта встаёт задача хоть немного манипулировать данными на фронтенде — они начинают ныть и плакать. Элементарные действия вроде сортировки или фильтрации коллекции по набору параметров превращаются в нелепый стыд и боль. Эй, парни! Разработка веб-приложений это на 99% работа с данными, и 1% с визуальным представлением, ау!

    А так-то да, виртуальный дом, всё такое.
  • Зачем программисту знать алгоритмы
    –4
    Приводите сколько хотите.

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

    Вся эта широко обсуждаемая байда о том, что программист должен всегда учиться, эгоцентрично ориентирована программистами на самих себя.

    Программы пишутся не для того, чтобы они отрабатывали за сколько-то там миллисекунд или ради прочей ерунды. Программы пишутся для того, чтобы доходы от них были выше совокупных расходов. С этого надо начинать, а не с меряния пиписьками алгоритмами.
  • Зачем программисту знать алгоритмы
    –5
    Дорогой автор! Любое новое знание, вкладываемое в голову, должно быть экономически оправдано. У вас в статье про это — ни слова.

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

    Я сам трепетно отношусь к алгоритмам и паттернам, продвигаемым IBM и Amazon. Я могу читать лекции о lock-free и темпоральных структурах данных и потоковых вычислениях. Но они не дают мне возможности пинком открывать дверь в отдел кадров любой конторы на рынке, и требовать тройное увеличение оклада. Потому что чем больше инструментов ты знаешь, тем меньше работодателей, где все эти инструменты востребованы одновременно.

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

    Это рынок, чувак.
  • Сказ о том, что в стартапах продавать должен каждый
    +2
    Ну уволим мы всех, а работать-то кто остается? :) Сколько людей Вы лично наняли, за свою карьеру? Сколько команд построили с нуля?

    Можно годами искать этих якобы «ответственных и понимающих», но факт в том что таких людей НЕТ. Или есть, но очень мало. Никто не сможет составить команду из 100% таких, тем более когда это надо сделать быстро в стартапе. Всегда найдутся либо добродушные косячники, либо клинические идиоты.

    Поэтому нужно рассказывать сотрудникам, что такое хорошо и что такое плохо. Обучать их. Нужны грамотные, лаконичные инструкции, покрывающие как можно больше кейсов. Нужны инструменты, ведущие исполнителей по линиям бизнес-процессов (по «скриптам»), помогающие даже самому тупому и безответственному сотруднику правильно обслужить клиента даже в нестандартной ситуации.
  • Сказ о том, что в стартапах продавать должен каждый
    +2
    уволенные сотрудники тендерного отдела всё возмущались — за что с нами так?!!! Мы же всё делали по инструкции…
    А может, всё-таки накажем того идиота, кто эти инструкции писал? :)

    Но нет, конечно проще всё свалить на безалаберность сотрудников, чем думать о бизнес-процессах.
    Некогда ведь думать о бизнес-процессах, продавать надо. Стартап же.
  • Повышаем отказоустойчивость системы на nodejs
    0
    Молодцы!

    Уходите от REST-а, вы его переросли. Переходите на AMQP (а именно RabbitMQ с роутингом). Это даст вам асинхронность и все преимущества event-based loose-coupling системы. В том числе такие приятные вещи, как параллелизация нагруженных узлов, кворумные воутеры, возможность рестарта любого сервиса без потерь, dry-run новых версий сервисов, debug «на ходу» и т.д.

    А во вторых — очень любопытно, как вы решаете вопросы совместимости API при внесении breaking changes? Когда у вас десятки сервисов, предполагаю, вам нужно или передепловать всю кучу на новую версию API или поддерживать две версии одновременно. Как именно вы поступаете?
  • Хроники ремонта: как мы делали новый умный офис Madrobots. Часть вторая, умная
    0
    Я подразумеваю электрический плёночный тёплый пол — который рулонами раскатывается, как линолеум. И поверх него уже финишное покрытие — тот же ламинат, хотя бы. Да, дорого в установке — порядка 2000 рублей за квадратный метр только на сами материалы.

    Он греет не постоянно, а включается релюшкой по датчику. Благодаря этому него расчётное потребление порядка 30 вт/м2, то есть для средней квартиры это сравнимо или даже меньше, чем затраты на освещение. Зато по нему безумно приятно ходить босыми ногами, и даже лежать на нём, как в турецкой бане. Боюсь, при обдуве сверху такого эффекта не будет — у них же первый этаж, под полом неотапливаемый подвал…

    Судя по тому, что автор нас не комментирует, он на эту тему уже забил :)
  • Хроники ремонта: как мы делали новый умный офис Madrobots. Часть вторая, умная
    0
    Нет, это не лучший вариант.
    Во-первых, канальный нагреватель — это чудовищные энергозатраты. Это же, по сути, фен — огромнейшая мощность в сравнении с небольшим полезным эффектом.
    Во-вторых, у них на фотографиях разводка труб идёт по верху, а значит подаваемый тёплый воздух так и будет болтаться наверху, а внизу в районе ног будет вечный холод — причина простуд и эпидемий.

    Более правильно было бы подавать внутрь холодный воздух, направляя потоки так чтобы они не целились людям за воротник, а подогревать помещение — электрическим (плёночным) тёплым полом.
  • Хроники ремонта: как мы делали новый умный офис Madrobots. Часть вторая, умная
    0
    И у вас в щитке я не заметил никаких УЗМ или аналогичных устройств, защищающих от перенапряжений в сети. Их нет или я протупил?

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

  • Хроники ремонта: как мы делали новый умный офис Madrobots. Часть вторая, умная
    +2
    Зря вы не раскрутили тему приточной вентиляции.

    Говорю не голословно, потому что в своё время я подготовил офис для конторы UMI.CMS буквально from scratch — из заброшенного здания, без электричества, воды и отопления.

    По моему опыту, приточка для средней квартиры делается своими руками в рамках бюджета 10-15 тысяч рублей. Большая часть ценника, который вам накрутили, это нафиг никому не нужная сборка комплектующих в единый корпус плюс собственно работа разгильдяев-монтажников.

    Ваша вытяжка на «принципах естественных щелей» — это пережиток советской эпохи, когда в окнах были щели. Вам придётся открывать стеклопакеты зимой, чтобы она работала, и дуть холодом в сотрудников. А летом, по теплофизическим причинам, она работать не будет вообще.

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

  • Проектирование программного обеспечения
    +6
    Ребят, вас десять лет назад заморозили в криогене, что-ли? Откуда водопад в разработке ПО в 2015-ом году? Так и напишите: мы делаем большие, неповоротливые продукты, с циклом развития в несколько лет, а потом их выкидываем и делаем заново, потому что таким способом нашим заказчикам более удобно пилить корпоративные бюджеты.

    По крайней мере, будет честно.
  • 12 типичных ошибок при бэкапе баз данных
    0
    Претензиями обменялись, теперь можно говорить по делу :)

    хочется услышать названия компаний, где финансовые операции делаются вне контекста транзакций

    Я говорю не «где», а «если». Судя по всему, вы работаете в мире, где софт берётся от корпоративных производителей. Я работаю в мире, где софт пишется руками кого попало — кого удалось найти HR-службе. Огромное количество народу вообще не знает, что начисления и списания пишутся отдельными строчками в БД — эти люди просто инкрементируют или декрементируют значение в столбце balance в таблице users.

    для мира реляционных БД с их старомодным ACID

    ACID вам здесь не поможет, так как здесь он говорит лишь о том, что переход значения A в значение B в одной конкретной ячейке реляционной таблицы происходит «мгновенно» с точки зрения внешнего наблюдателя.

    В то же время, рассмотрите пример: многие фреймворки для разработки сайтов предлагают следующий паттерн для денормализации: допустим, есть таблица users и таблица comments (со столбцом user_id в качестве указателя на автора комментария). И разработчику предлагается добавить в таблицу users столбец comments_count, значение в котором инкрементируется приложением (приложением! не триггером в БД!) сразу за фактом добавления каждого нового комментария. Пруфлинк, если что.

    И вот вы сливаете дамп всех таблиц: слили comments, сливаете ещё 100500 таблиц по алфавиту, добрались до users. А у вас такие гиперактивные юзеры — они фигачат комменты по 1000 штук в секунду. И в конечном файле дампа, который вы попытаетесь восстановить после аварии, счётчики comments_count будут не соответствовать реальному количеству строк комментариев в сдампленной таблице comments. Всё — ваша целостность данных развалилась.

    (конечно это решаемо тысячей разных путей, безусловно, но факт налицо)

    Думаю, от таких хостеров надо бежать, а не рассуждать

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

    Что ещё обсудим? :) Any comments welcome!
  • 12 типичных ошибок при бэкапе баз данных
    +1
    Что-то совсем уж чайниковская статья.

    Где рассуждения о том, что нагруженная БД практически никогда длительно не находится в консистентном состоянии?

    О том, что типичная услуга хостеров «бэкап путём снятия SQL-дампа» — это иллюзия, потому что на большом количестве таблиц пока идёт дамп первых таблиц — последние могут противоречиво обновиться?

    О том, что момент бэкапа может попасть между финансовыми операциями (между тем как у юзера A списались деньги, а юзеру B — начислились), а разработчик приложения соответствующими инструментами (транзакциями) просто не владеет?

    О том, что бывает шардинг и партиционирование на физически разных машинах, которые тоже нужно консистентно забэкапить?

    Я считаю, что об этом было бы гораздо полезнее написать, чем о «следите за свободным местом на диске».
  • Что такое красивый код, и как его писать?
    0
    Эй-эй, это что за хренотень? :)

    find_defects();

    if (defects_found()) {

    }


    У вас что, функция хранит результат своей работы в каком-то внешнем состоянии? Может быть, вы ещё Stateful-код пишете и глобальными переменными балуетесь? А с параллелизацией никогда не имели дел?

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

    # псевдокод
    if ( find_defects().getResult().isSuccess() ) {… }

    Или хотя бы так:

    # псевдокод
    try { find_defects(); } catch Exception $e {… }

    А совсем правильно — так:

    # псевдокод:
    successManager.subscribe('find_defects.results.success');
    failManager.subscribe('find_defects.results.fail');

    function find_defects() {
    # do some work…
    dispatch(results)
    }

    Так оно будет правильно работать в распределённых системах.
  • Зачем нужны почты no-reply@?
    –2
    А, Мосигра, привет конкурентам.

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

    В то время как в зарубежной практике тема вполне популярная, примеры [раз], [два], под тем же соусом — чем больше человечной коммуникации — тем успешнее бизнес.

  • Краткая история масштабирования LinkedIn
    +1
    Ах, SOA и REST — мои любимые инструменты :) 975 ресурсов — респект парням!

    Очень любопытно, почему отказавшись от концепции прямых вызовов RPC, они не перешли на очереди. Так как в отличие от REST (я имею в виду традиционно over http — ожидающего ответ в цикле запроса), очереди позволили бы отправлять ответ асинхронно, добавив ещё одну нотку к отказоустойчивости.
  • Проблемы биллинга: Что может пойти не так с самописным софтом
    0
    Пффф… Маркетинг буллшит.

    Когда я работал руководителем в одной русской CMS, мы такое тоннами писали.
    Когда я работал руководителем в веб-студии, мы писали ровно то же самое, но наоборот, про самописный продукт.
    А когда я работал в энтерпрайзе, и мы выбирали между коробкой или наймом команды, на нас лилось такое с обоих строн.

    Хотите правды? Вообще по**й, самописный софт или коробочный, — если его пишут и внедряют дураки, которыми руководят м**аки, то жопа будет абсолютно одинаковая в обоих случаях.