За последние 10 лет работы в качестве QA, бизнес-аналитика, продакт-оунера, продакт менеджера, а также БА-ментора, я получил полезный опыт, которым хочу поделиться.

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

После несерьёзной статьи на серьёзную тему Job Safety Driven Development возникла идея написать о том, как появляются ошибки разработчиков. Вместо этого появилась статья «Почему всё ломается даже у хороших программистов?» (Часть 1 и Часть 2). Мысль нужно закончить. Уже рассмотрено два краевых случая, давайте посмотрим и на «обычные» причины ошибок программистов. В первой части этой статьи мы рассмотрели, что такое ошибка вообще, цену и ценность ошибок, немного коснулись темы интерактивного программирования и разработки через багфикс. На примере "ошибки выжившего" поняли, как формируются негативные паттерны поведения. Здесь же мы рассмотрим проблему оптимизации, которая по своей разрушительной силе не очень уступает разработке через багфикс. Посмотрим, а нужны ли программисту фундаментальные знания, а если да, то зачем. И попытаемся затронуть проблему слепого копирования ритуалов (карго-культ) в программировании. Продолжаю пробовать писать простым языком, чтобы было понятно широкой аудитории.

Меня всегда очень интересовала довольно грустная ситуация с языком РНР. Из неказистого шаблонного движка для веб-страничек, к середине 2010-х он вырос в мощный, современный и аккуратный язык программирования… в то время как практически все обучающие материалы в сети выставляют его всё тем же неуклюжим уродцем, который с огромным трудом, не соблюдая никаких стандартов, позволяет разве что сделать примитивную веб-страничку с кучей уязвимостей. Что, разумеется, уже давно совершенно не так. Поэтому когда на форуме РНР клуба появился пост о наборе "наставников" на курс по РНР в HTML Academy, я не раздумывая подал заявку. Чтобы посмотреть как с обстоит с этим дело на платных курсах, а так же по возможности поделиться своим опытом в этой области.

Что вам сказать? "Если хотите, чтобы вам и дальше нравилась колбаса, не берите экскурсию на мясокомбинат"

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

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

Итак, каковы основные причины неудачных миграций в облака, и как снизить риски?

Когда вы окончили курсы или вуз, теоретические знания есть, а опыта и практики обычно маловато. Компании неохотно нанимают новичков, поэтому начать карьеру проще через стажировку. Её лучше рассматривать не как работу, а как продолжение образования с приятным бонусом в виде оплаты. Рассказываем, как искать стажировку и чего от неё ждать.

^{Источник картинки}

Работающий код может иметь изъяны — например, быть недостаточно простым, лаконичным и понятным. Это может быть признаком более глубоких проблем в коде, а избавиться от них можно с помощью рефакторинга. В этой статье разберем наиболее популярные недостатки кода. Материал адаптирован на русский язык вместе с Глебом Михеевым, директором по технологиям Skillbox и спикером профессии «Frontend-разработчик PRO» и преподавателем курса Frontend-разработки в Skillbox Борзуновым Игорем.

Это глава из «Книги нормального фрилансера», в которой я делюсь накопившимся опытом проектировщика интерфейсов, работающего на себя.

Разговор ведя с клиентом, стань ему ближайшим другом,
Поделись чужим секретом, обсуди своих коллег.
Объясни, что срочно надо, чтоб проект пошёл в работу,
Скоро взнос за ипотеку и голодный дома кот.

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

«У меня тяжёлая жизненная ситуация»

Не стоит рассказывать будущим клиентам о том, как всё плохо, и как фрилансеру нужна работа. Какими бы ни были финансовые обстоятельства и как бы на самом деле ни хотелось заполучить заказ, клиент этого не должен узнать.

Любой системный администратор сталкивался или столкнется с ситуацией, когда стандартных возможностей распределения прав в Linux недостаточно для выполнения задачи. Но не всегда лучшим решением станет подключение ACL. 

Эта статья поможет определиться действительно ли проекту требуется гибкость на уровне пакета ACL и какие проблемы могут возникнуть при его использовании. 

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

Перед тем, как запускать свой сайт или приложение, в котором вы собираетесь использовать cookies или иные идентификаторы (local storage, AAID, UDID и т.д.) устройств/сессии пользователя, необходимо выполнить требования законодательства о персональных данных.

Зачем? Во-первых, вы выстраиваете открытые и честные отношения со своими пользователями. Во-вторых, вы будете готовы к проверкам регуляторов. В-третьих, вы сможете избежать штрафов, которые могут достигать 4% годового оборота своей компании.

Давайте разберемся, как онлайн-идентификаторы связаны с защитой персональных данных.

Согласно ФЗ «О персональных данных» и GDPR куки-файлы и иные идентификаторы пользователя относятся к персональным данным, поскольку позволяют теоретически определить конкретного субъекта или выделить его среди других лиц.

Наиболее известным делом по рассматриваемой нами теме стал судебный спор Vidal-Hall v. Google (2015). Используя сookieы-файлы, компания Google осуществляла сбор информации об интернет-трафике пользователей. Заявители, не будучи осведомлены о незаконных действиях ответчика, настаивали на привлечении последнего к ответственности за нарушение порядка использования сookies – персональных данных, которые позволяют вычислить пользователей.

Суд занял позицию истцов и положительно ответил на вопрос об отнесении Cookie-файлов к персональным данным, так как они, «не называя прямо субъекта … позволяют выделить его из всей массы пользователей, следовательно, отвечают критерию идентификации» [1].

Следовательно, в отношении cookies и прочих идентификаторов необходимо соблюдать требования законодательства.

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

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

Согласитесь, неприятно осознать, что компания тебе не подходит, когда ты уже приступил к задачам в полном объеме. Особенно, если поиск работы перед этим занял продолжительное время. На что обратить внимание, чтобы скипнуть плохую компанию как можно раньше и продолжить поиски “той самой”.

Хей, Хабр! Я – Юнна, работаю HR в 2people IT. Улучшаю условия для работы, провожу грейды и ищу крутых специалистов. Сегодня я расскажу, какие действия со стороны работодателя кричат о том, что трудиться в этой компании не стоит, а какие тихонько на это намекают.

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

Что такое IT для обычного обывателя? Как правило, это дивный чудесный мир, где все работают удаленно 2-3 часа в день и получают миллионы. Думал ли восемнадцатилетний я, поступающий на 1 курс специальности "Информационная безопасность" о том, что здесь все действительно легко и просто? Конечно нет. Я понимал, что первое время будет тяжело, но верил в то, что год-два опыта работы и мое старание помогут мне выйти на уровень квалифицированного специалиста и, как следствие, достойной работе и заработку.

И вот, время шло. Я суетился, пытался искать пути трудоустройства, параллельно учился и изучал материал самостоятельно, и вот, на третьем курсе, я уже работаю в технической поддержке. Проработав там 10 месяцев, я узнал о том, что обучение в ВУЗе покрывает от силы 10 процентов того, что потребовалось в работе, и что самостоятельное изучение является чуть ли не основополагающим в становлении меня как специалиста. Для меня, как человека, который верил в то, что учебное заведение призвано ОБУЧАТЬ, это было, мягко говоря, шоком. Однако, благодаря моему опыту работы в технической поддержке, я смог разобраться в теоретической базе системного и сетевого администрирования, а также приобрел небольшой практический опыт работы с оборудованием.

Поводом для написания этой статьи послужил случай, когда сотрудники нашего HR-отдела предложили мне взять в нашу проектную группу Департамента разработки программного обеспечения ЛАНИТ на производственную практику выпускника одного из московских техникумов.  Кандидат обучался четвертый год по специальности «Прикладная информатика» и, судя по резюме, претендовал на должность «стажера-разработчика SQL, С#, HTML, CSS». Он уже прошел предварительные собеседования и, по словам наших кадровиков, показал себя наиболее адекватным из 15 других претендентов. Поскольку у меня это был не первый случай руководства практикой у студентов и предыдущие прецеденты имели положительный результат, я согласился.

Термин «выгорание» вошёл в мою жизнь как-то неожиданно. Работал я. Работал много лет: сначала кодил, потом свои проекты делал, команды собирал, бизнес налаживал… И тут — Бац! Куча мемов на эту тему во всех связанных с IT-ресурсах. Не знаю, то ли я в какой-то тундре жил, то ли тундра жила во мне. Но да ладно: мемы почитал, поржал и забыл. А тут неожиданно этот термин вошёл в обиход моих ребят. Где-то как бы в шутку, где-то в серьёз. А мы все знаем: в каждой шутке есть доля шутки, а остальное — чистая правда. 

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

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

«Вот я в своё время по 10 часов работал без выходных и отпусков. Скучные проекты пилил, ночью на проде хотфиксил и т.д. и т.п. У ребят же условия другие: график нормированный (авралы, конечно, бывают, но всё в рамках), переработки оплачиваются х1,5-х2 (всё по ТК), проекты интересные. Премии! Отпуска! Работа, блин, командная! Не как дурак сидишь и всё в одного пилишь, а в коллективе ответственных товарищей. Какое, мол, выгорание? Я вам сейчас расскажу про выгорание!» Ну и прочая блаж в том же духе.

Продолжаю рассказывать о том, что осталось за бортом российских технологических площадок. Сегодня все в контексте ИБ и работы с персональными данными.