Pull to refresh
7
0
Станислав Иванов @ohmytribe

User

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

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

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

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

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

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

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

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

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

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

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

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

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

Information

Rating
Does not participate
Location
Грузия
Registered
Activity