• GitHub теперь официально принадлежит Microsoft
    0
    Интеграция между Github и JIRA прекрасная, вообще без проблем. Видим все коммиты, все PR и их статусы, можем триггерить изменение статусов на вебхуки от github.

    Вот интеграция JIRA и Confluence оставляет желать лучшего, как ни странно.
  • GitHub теперь официально принадлежит Microsoft
    +4
    Вообще, умение гуглить — это главный навык программиста. Я не очень понимаю, почему это человек себя зовёт программистом.
  • GitHub теперь официально принадлежит Microsoft
    +4
    Для программиста умение разработать и закодить архитектуру — это где-то 20-40% скилла (в зависимости от конкретного проекта). Остальное — это знание IDE, экосистемы, умение дебажить, знание инструментов и хитрых опций, которые помогут запустить незапускаемое, подключить неподключаемое и узнать неузнаваемое с помощью этих инструментов и т.п.

    Вообще, уже вроде как вполне официально объявлена эпоха DevOps, а у нас некоторые «программисты» всё ещё запуск консольных команд считают чисто админской обязанностью. В ответ, конечно, написание скриптов некоторые «админы» считают строго обязанностью программистов. Ну а релизить код на сервер, вестимо, должен техлид.
  • GitHub теперь официально принадлежит Microsoft
    +1
    Проект куплен в 2005-м, а первый релиз в 2008-м. Я бы сказал, купили не проект на ранней стадии, в специалистов и их наработки.
  • GitHub теперь официально принадлежит Microsoft
    +12
    Мужчина, вернитесь в свой 2002-й год, пожалуйста.
  • GitHub теперь официально принадлежит Microsoft
    +4
    Там одна система восстановления пароля что стоит. Я восстанавливал пароль в скайпе уже раз 15 (потому что пользуюсь редко и постоянно забываю последний выставленный). Во-первых, там абсолютно идиотские правила для задания пароля (не должен повторять прошлых? я пытаюсь _вспомнить_ пароль, я так и сказал «я забыл пароль»!). Во-вторых, через раз после попытки ввода восстановленного пароля он слетает и на почту приходит сообщение «кто-то пытался зайти в ваш аккаунт». При этом я не могу просто нажать «это был я», мне надо снова вводить _новый_ пароль.

    Короче, уж до чего гуглы кривые в плане UX, но MS вообще впереди планеты всей. Я теперь всем просто говорю свой номер телефона и предлагаю увидеться в Телеграме, Ватсапе или Вайбере, даже по работе. Ну а корпоративный мессенджер уже несколько лет назад был заменён Slack'ом.

    В принципе, если на смену github'а (уровень Skype до прихода MS) придёт кто-то с идеями уровня Slack'а — я не буду против.
  • Избавляем игрока от раздражения: правильное использование случайных чисел
    +2
    Вот так казуальщина убивает хардкор :D
  • GDPR как оружие массового поражения
    0
    Кейс из Британии: Несколько месяцев вели консультации с юристами. В итоге всё, что сделали: возможность для админов по запросу пользователя найти все данные, которые мы о нём храним, и экспортнуть их в PDF для последующей отправки пользователю (так называемый Right to Access). Хотели ещё сделать возможность анонимизации всех персональных данных пользователя по запросу (так называемый Right to Be Forgotten), но в итоге при дальнейшем исследовании выяснили, что бизнес-критические данные можно хранить столько, сколько заявляем в T&C (у нас это 7 лет), поэтому задвинули на самое днище бэклога.

    Кроме того, делаем pentest сертифицированной компаний в качестве доказательства, что у нас всё окей с аудитом безопасности.
  • Как не сойти с ума от Scrum? Опыт растущего проекта
    0
    +2
  • Как не сойти с ума от Scrum? Опыт растущего проекта
    0
    Если бы у автора реально был Agile, то как раз плотные коммуникации — это, фактически, обязательное требование. Т.к. там команда должна работать на определённый результат, а не просто на выполнение задач. Но у автора не Agile совсем.
  • Как не сойти с ума от Scrum? Опыт растущего проекта
    0
    1. Agile не подходит для релизов раз в квартал. Это само по себе противоречит почти всем принципам Agile.
    2. PO не должен следить за написанием требований, он сам их должен писать, технические специалисты должны описывать технические подходы. PO фактически занимается тем, что формирует стратегию достижения поставленных бизнесом целей. Поэтому в разрезе употребления термина «product owner» фраза «следит за соответствие требований пожеланиям заказчика» неуместна. У вас, скорее, менеджер проекта.
    3. PO не должен оценивать задачи, PO должен брать оценку от технических специалистов и на базе оценки принимать тактические решения, которые позволят остаться в рамках road map (например, выкинуть второстепенные требования или принять решение о реализации грязного MVP вместо полноценно рабочей функциональности).
    4. Выделение фиксированного времени на фикс багов не имеет смысла — фикс конкретного бага должен приоритизироваться так же, как и разработка фич. Достаточно странно тратить 50% времени разработчиков на фиксы чего-то некритического при наличии критических бизнес-требований, например.

    Если коротко — у вас не Agile процесс и не Agile команда.
  • Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]
    +3
    Да я бы ещё 3/4 своих комментариев поудалял. Скромнее надо быть, да эффект Даннинга-Крюгера не всегда позволяет :D
  • Срочный переезд с Amazon Web Services — истории двух клиентов
    +7
    «Облако в РФ даёт больше гарантий клиентам, что сервис не будет заблокирован РКН»
    Довольно смешное высказывание. Облако в РФ может быть заблокировано не только для россиян, но и, так сказать. полностью уничтожено.
  • Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]
    +4
    Просто пообщайтесь с человеком, поймите, комфортно ли вам будет с ним работать, говорит ли он какие-то адекватные вещи, говорит ли он о том, что он делал в прошлом или о том, чем может помочь именно вам.

    Имхо, самая большая проблема, что проекты ищут людей на должности, не людей для решения определённых задач/проблем.

    Пример 1 (отрицательный): «Мы ищем программиста высокого уровня. Вы знаете, что такое SOLID?»
    Пример 2 (положительный): «Мы заметили, что у нас есть определённые проблемы с быстрой реализацией MVP фич, кроме того, мы хотели бы реализовать полнотекстовый поиск.»

    Если человек способен решить ваши текущие проблемы/задачи, то, в абсолютном большинстве случаев, он будет способен решать и проблемы/задачи в будущем.

    Собеседование — это беседа двух людей и их попытка выяснить, будет ли им интересно работать вместе и получать ли они пользу от этой работы. Мне кажется, какой-то план собеседования работает только в случае, если у вас конвейер и команда из 30 программистов. Если у вас, скажем, 5 программистов на команду, то каждый член команды может прикрывать определённую область. Кто-то быстрый и энергичный, кто-то медленный и дотошный, кто-то хорошо умеет разбираться с запутанными багами и т.п. Поэтому ищете вы чаще всего не столько компетенцию, сколько компетенцию, психологические особенности и т.п.
  • Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]
    –2
    2-2.5 года для программиста — это очень много. Если у вас 90% программистов работает по 2-2.5 года, это говорит не о успешности собеседований, а о определённом ментальности программистов, которых вы принимаете на работу. Для молодых программистов, скажем, 2-2.5 года на одном месте — для меня даже странно.
  • Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]
    +3
    Я писал пост о собеседованиях сюда лет 6 назад. Сейчас пост удалил, т.к. мне он кажется откровенно глупым. А собеседования у меня теперь проходят в свободном стиле — рассказываю о компании, рассказываю, какие у нас есть проблемы, которые пытаемся новой позицией решить и т.п. Далее человек рассказывает о себе и уже в контексте наших проблем рассказывает о своём опыте и о своих «набросках» к решению этих проблем (это получается само собой, я даже не задаю этих вопросов).

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

    А вот эти все каверзные вопросы — это для викторин, а не для _СО_беседований.
  • Джеф Атвуд: «Ваш пароль слишком короткий!»
    0
    Средний бытовой процессор генерирует около 300-400 тысяч md5 хешей в секунду, sha1 чуть меньше. Поэтому соль в этом случае спасёт только от радужных таблиц, но никак не от брутфорса (соль обычно идёт в одном «пакете» с хешом, поэтому проблемы никакой нет). Нужно использовать долгоиграющие алгоритмы, соль генерировать отдельную для каждого генерируемого пароля и хранить рядом с паролем. А ещё лучше — пользоваться встроенной функциональностью языка программирования, перед этим изучив её реализацию.
  • Джеф Атвуд: «Ваш пароль слишком короткий!»
    +5
    1. Если кому-то вдруг так понадобился ваш пароль, что они готовы потратить на его подбор более 2 часов работы кластера — поздравляю, вы добились определённого успеха в жизни.
    2. Достаточно использовать «цикличные» алгоритмы со временем генерации хеша примерно 0.1 секунды на среднем процессоре (sha512 со 10 тысячами циклов, например) и с использованием случайных солей, чтобы полностью забыть про угрозу подбора пароля при утечке базы.
    3. Всегда стоит задумываться, а нужно ли в вышам бложике требовать пароли повышенной сложности.
    4. Если без сложного пароля нельзя обойтись, то без него можно обойтись с использованием двухфакторной авторизации.
    5. Если всё, что выше, не подошло, читайте RFC, ISO и т.п., подобные посты вам не помогут. При этом внимательно изучайте историю взломов выбранного метода защиты.
  • Джеф Атвуд: «Ваш пароль слишком короткий!»
    0
    Соль нужна для защиты от радужных таблиц. Хранить соль отдельно от пароля — это крайняя степень паранойи и говорит лишь о том, что человек не понимает, насколько хороший алгоритм хеширования он применяет.
  • О Symfony 3.0
    –1
    «Но обновляться было просто из-за того, что сохранялась обратная совместимость.»
    Хорошая шутка.
  • Оптимизация модулей RequireJS в Symfony2
    0
    RequireJS — это не компилятор и не минификатор. Это удобная штука для разруливания зависимостей в JS (что-то типа use и DI). Оптимизатор r.js всего лишь позволяет собирать всё в один файл с учётом зависимостей и минифицировать этот файл.

    Имхо, вместо всяких ассетиков проще на девелопменте использовать неминифицированный код, а на продакшн (стейджинг и т.п.) деплоить чем-то вроде Grunt. Я, например, использую Grunt с тремя модулями — grunt-contrib-less, grunt-contrib-watch и grunt-contrib-requirejs. Задача local (она же является default-задачей) состоит из grunt-contrib-watch, подключается неминифицированная версию JS-фреймворка. Задача deploy состоит из grunt-contrib-less и grunt-contrib-requirejs, подключается минифицированный склеенный файл с JS-фреймворком. В идеале хорошо иметь отдельные склеенные файлы для каждой страницы сайта (контроллеры с их зависимостями).

    В итоге у меня для деплоя используется Capistrano (с модулем Capifony — набором задач для деплоя проекта на Symfony 2), который на завершающих шагах (перед перенаправлением симлинка на новый релиз) вызывает Grunt для компиляции JS и LESS.
  • Медведь на лестнице
    +6
    … влез на нее…
  • Обнаружена крупнейшая из известных звёзд
    0
    В целом фраза «в 1500 раз больше Солнца» заставила задуматься, что имеется виду под размером.
  • Единое зарядное устройство для всех мобильных девайсов: в ЕС приняли новый закон
    0
    Кстати, не на всех телефонах вставлять зарядку надо именно стрелкой вверх.
  • Контрактное программирование в PHP
    0
    Так аннотации — это и есть уровень абстракции. По сути, мы просто указываем, какой сервис вызвать и с какими параметрами. Т.е. делаем то же самое, что делали бы в коде метода. Конечно, есть отличия в том, как это делается в коде и в аннотациях, но по мне — это намного ближе к обычному подходу по сравнению с конфигами.
  • Контрактное программирование в PHP
    0
    Я насчёт роутинга как раз склоняюсь к указанию ресурсов (контроллеров) в конфиге и описании роутов в самом классе. Слабые связи и разделение ответственности. Плюс более удобное и быстрое переопределение роутов.
  • Контрактное программирование в PHP
    0
    made my day :)
  • Контрактное программирование в PHP
    0
    Ну вот мне, например, выносить логику приложения в конфиги не нравится. Чтобы понять всю логику, приходится смотреть и в код какого-нибудь класса, и в конфиг, который в yaml или xml не всегда доходчиво реализован.
  • Контрактное программирование в PHP
    0
    Вам не совсем правильно сказали. Оно не кешируется в дев-режиме, но оно компилируется в идентичный PHP-код. Т.е. не важно, yaml, xml или аннотации — сначала всё равно идёт компиляция этих параметров в php-код.
  • Пространства имен в PHP, разъяснение
    0
    Пойти написать пост про то, как правильно кодировать и проверять пароли с помощью библиотеки crypt, что ли.
  • Пространства имен в PHP, разъяснение
    0
    Я ни одной серии этого сериала не посмотрел, но уже после пары неймспейсов понял, «об чём речь». Хотя сначала я было обрадовался, что кто-то использует имена мифических исландских (например) персонажей. Ан нет, всё то же, что и вчера, и позавчера.
  • Пространства имен в PHP, разъяснение
    0
    А для чего такое может пригодиться?
  • Пространства имен в PHP, разъяснение
    0
    Я заметил, что те, кто пишут комментарии/документацию на русском, кодят и документируют примерно так:
        /**
         * Функция получает информацию о валютном аккаунте этого кошелька.
         * Данные затем сохраняются в поле $accountData.
         * Операция также считается успешной, если данные найдены в поле
         * Пустой $currencyName означает запрос на все аккаунты кошелька
         * $accountData, хоть запроса при этом и не выполняется.
         * @param string $currencyName
         * @return boolean $success
         */
        public function getAccountData($currencyName = "")
    
        /**
         * Функция готовит данные для отображения кошелька. Возвращается айди и вся
         * информация по аккаунтам. Можно передать массив с нужными типами
         * аккаунтов. Если этого не сделано, запрашиваются данные по всем.
         */
        public function getDisplayData(...)
    


    Если у таких людей отобрать русский язык, они автоматически постепенно учатся кодить так, чтобы их код говорил за себя. Хоть и не всегда.
  • Пространства имен в PHP, разъяснение
    0
    В целом, плохо, если человек-программист ещё и человек-корявый-английский. Большинство адекватной и свежей документации пишется на английском, большинство решений проблем описано на английском. Я вообще мало доверяю программистам, не знающим английский (при этом разговорный не обязателен).

    При программировании на PHP мне, по сути, достаточно двух ресурсов:
    1. php.net, на котором все обсуждения специфики работы функций/пакетов/классов на английском
    2. stackoverflow.com вообще всё на английском

    И мне не совсем (совсем не) понятно, с каким ресурсами работают программисты, не знающие языка.
  • Пространства имен в PHP, разъяснение
    0
    Как ни странно, я заметил закономерность — если человек пишет в PHP коде комментарии по-русски, то эти комментарии такие же нечитаемые, как и его код.
  • Вебсокеты на PHP. Часть 3. От чата до игры: Battle City
    0
    Не надо над этим шутить здесь, я бы сказал. Да и вообще затрагивать подобную тематику.
  • Пространства имен в PHP, разъяснение
    0
    Это жаргонизм. Меня, например, он слегка раздражает. Как минимум, потому что его обычно используют менеджеры, которые жутко любят аббревиатуры и сокращения. Раздражает примерно так же, как «прога», «комп», «прогер» и т.п. Сам всегда говорю «функциональность», но других не исправляю.
  • За что конкретно я ненавижу некоторых отдельно взятых маркетологов — или как айтишник по магазинам ходил
    +1
    Вам нравится, что для большинства аппаратов, способных тянуть новые версии софта, обновления этого софта не поставляются? Или нравится, что надёжность девайсов стала такой, что девайсы ушатываются за 1-2 года?

    Я тут в руки взял Нокию свою старую — лёгкий маленький кирпич с тачскрином, аж слезу пустил. А ведь он испытал сильный бросок в стену и два мощных удара пяткой :)
  • За что конкретно я ненавижу некоторых отдельно взятых маркетологов — или как айтишник по магазинам ходил
    +6
    Моя знакомая — «Я взяла кредит 50 тысяч на год, мне всё посчитали, платить я буду всего 3 тысячи в месяц.»
  • За что конкретно я ненавижу некоторых отдельно взятых маркетологов — или как айтишник по магазинам ходил
    +1
    С карманниками, как и с маркетологами, надо просто быть внимательнее. В этом смысле выбор один и тот же — быть или не быть обманутым жуликами.