Метка «ответственность»

Привет Гиктаймс! Сразу хочу отметить что я очень старался избегать политических вопросов, но так как работа в качестве ИП это в том числе про налоги, а налоги это про государство, то немного политики в посте есть, простите. Таки приступим.

Последние 7 лет я как и многие здесь читал Хабр (а сейчас Гиктаймс), и обычно мне удалось справляться с порывами запилить пост другой, и светлые идеи благополучно направлялись на склад, откуда никогда не возвращались. Но несколько недель назад все изменилось. Я прочел замечательный пост под названием «Если вместо оформления на работу предлагают открыть ИП», и теперь не могу молчать. И так, давайте разберемся что же меня так зацепило…
Читать полностью »

Всем добрый день. Извиняюсь за то, что долго не писал. Были болезнь, сдача проектов, ITIL сертификация. Теперь я готов вернуться и постараться поделиться тем, что я получил за годы работы в ИТ.

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

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

Читать полностью »

Время изменилось. Теперь в одиночку можно написать приложение для миллионов человек. Не нужно думать ни о хостинге, ни о дистрибуции, ни о масштабируемости — облака сделают всё за вас.

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

Стоит сейчас какому-нибудь «Энгри бёрдз» написать «2-е птицы», и все молодое поколение будет неправильно наращивать окончания у числительных (на самом деле, наращиваются только порядковые числительные: «2-й дом», «1-му победителю», но «2 птицы»).

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

Поговорим сегодня о внимании к деталям на одном практическом примере (будет много картинок).

Разбираем основные интерфейсные ошибки на примере одного банковского клиента
Читать полностью »

Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS Active Directory.

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

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

В этот момент мы начали работать над внедрением общего решения по управлению учетными записями и правами доступа, IdM. Для начала пришлось избавиться от раздробленности и свести все кадровые базы в одну промежуточную кадровую систему. Её связали с Active Directory через новый центр-репозиторий. Потом подключили к репозиторию остальные бизнес-системы вот так:

Ад с учётными записями — почему в одной компании пользователей было в 3 раза больше, чем сотрудников

Дальше мы удалили все лишние учётки, оставили только действительных сотрудников (заодно увидели пару уволенных, но активно логинящихся). Потом нашли пару очень странных людей...Читать полностью »

В опубликованном 17 сентября на сайте Комитета Государственной Думы ФС РФ по гражданскому, уголовному, арбитражному и процессуальному законодательству проекте измений в Гражданский Кодекс есть и новые положения, которые в целом интересны. Текст большой, вот что я выделил как наиболее интересное и попытался прокомментировать.
Читать полностью »

Продолжаем разговор.

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

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

Пожалуй, пойду прямо по тем же пунктам.
Читать полностью »

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

Обнаруживаю себя вечером в 9 часов на работе, с гневным клиентом в ICQ, которому «срочно надо», и в попытке привести в рабочее состояние код, который сегодня писал другой программист. Похоже, сегодня запустить это не получится. Клиент не стесняется в выражениях, давит на чувство вины. Жутко стыдно. От долгого сидения за компом болят глаза. От необходимости отлаживать и разгребать чужой говнокод — спина. Если у вас болит спина — скорее всего, вы прямо сейчас должны делать работу, которую ненавидите. В голове — отчаянье, злость. И долбит мысль:

Я
Не хочу
Отвечать за чужие косяки

Читать полностью »

Обнаруживаю себя вечером в 9 часов на работе, с гневным клиентом в ICQ, которому «срочно надо», и в попытке привести в рабочее состояние код, который сегодня писал другой программист. Похоже, сегодня запустить это не получится. Клиент не стесняется в выражениях, давит на чувство вины. Жутко стыдно. От долгого сидения за компом болят глаза. От необходимости отлаживать и разгребать чужой говнокод — спина. Если у вас болит спина — скорее всего, вы прямо сейчас должны делать работу, которую ненавидите. В голове — отчаянье, злость. И долбит мысль:

Я
Не хочу
Отвечать за чужие косяки

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js