Рубрика «разработчик»

Юридические эксперименты в ИТ. Как кастомизировать закон под себя - 1

Похоже, власти прислушались к жалобам бизнеса на неудобные законы и приняли закон об экспериментальных правовых режимах в сфере цифровых инноваций (Федеральный закон от 31.07.2020 № 258-ФЗ). По сути государство говорит нам: «Вам не нравится действующее регулирование? Окей, придумайте свои законы, которые вас устроят. Мы на время сделаем их обязательными для вас и других желающих и посмотрим, как они работают. Если эксперимент пройдет хорошо, то сделаем из вашей идеи полноценный закон, обязательный для всех».

Давайте рассмотрим, кому от нового закона станет удобнее и в чем его особенности.

Поехали!
Читать полностью »

Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx) - 1

Ситуация с правами на код в Российской Федерации довольно интересная: по закону разработчик (физлицо) защищён очень и очень сильно. Нужно как-то весьма прилично косякнуть, чтобы оказаться неправым. А вот работодателю нужно довольно много и кропотливо бегать с бубном и бумагами, чтобы получить права на тот самый код, который пишется на его же зарплату.

Давайте рассмотрим, что говорят законы о правах на код с обеих сторон:

  • Когда и какие права возникают у вас (как физлица) на код.
  • Как правильно устроена передача имущественных прав на код работодателю.
  • Тимлид, который делал ревью, — он соавтор или кто?
  • Можно ли коммитить в свой pet-project с рабочего компьютера в рабочее время?
  • Какой геморрой предстоит пройти, чтобы правильно использовать код, если вы его заказали?

И так далее.

Поехали!Читать полностью »

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

Первый совет — хватит доставать своих людей!

Какие ошибки делают руководители на удалёнке - 1

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

Какие ошибки делают руководители на удалёнке - 2
Дятел-менеджмент в чистом виде

Если стоит задача повысить эффективность команды сейчас и в перспективе — оставьте людей в покое. И установите 15-минутные дейли по утрам. Я уже успела увидеть и общепроектные синхры раз в четыре часа, и дейли по два часа, и впадающих во фрустрацию менеджеров, привыкших договариваться сидя лицом к лицу с кем-то. Читать полностью »

Портал тестовых сред, или Спасём наш девопс - 1

Пару лет назад мы чувствовали себя в каком-то сюрреалистическом сне. Все вокруг шли в облако для тестирования (удобно же разворачивать-сворачивать тестовые среды), а мы пытались выяснить, какие инструменты «из коробки» нужно поставлять. Для этого мы вместе с заказчиками разбирались, как устроены процессы девопса. И оказалось, что только единичные компании в России как-то грамотно применяют автоматизацию.

Сразу поясню, что мы по большей части общались или с теми, кто занимается разработкой в компании до 150–200 человек, или с производствами, где с ИТ традиционно тяжело. У компаний крупнее обычно есть и процесс, и собственное облако, и к нам они приходят за резервным размещением.

Производство обычно хорошо отлажено. Есть цикл, план релизов, есть цель, код идёт к цели вместе с разработчиками.

Тестирование и QA тоже хорошо отлажены чаще всего.

А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA. Читать полностью »

Обезл***вание д***ных — это не просто рандомизация - 1

В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.

Так вот, не будет.

Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.

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

То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных. Читать полностью »

Как ни странно, но многие разработчики, начиная с джуниоров и заканчивая синьорами, видят только один путь своего развития: менеджмент. Они планируют переходить в руководители проектов или становиться техническими руководителями. Но IT-сфера намного шире, вариантов и путей развития большое количество. Развиваться можно, не только получая новые навыки, но и совершенствуя существующие. Об этом и о нескольких возможных дорогах для дальнейшего развития карьеры разработчика я расскажу в своем посте. Интересно будет не только начинающим свою карьеру, но и опытным разработчикам, которые еще не определились со своей судьбой или просто устали писать код.

Есть ли жизнь после Синьора? - 1
Источник
Читать полностью »

Байки про суровое российское ИТ и жертв цифровизации - 1

Россия иррациональна. Есть правильные практики, есть сто раз ощупанные грабли, но всё равно с завидным постоянством случается что-то эпическое. Иногда по причине: «Ну уж меня-то точно пронесёт», иногда: «Всегда так делали, и работало», иногда просто из-за ошибок. Возможно, в генах.

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

Когда позвали нас разбираться, там было примерно 10 разных версий ПО (релизы от 0.9 до 2.4). Есть исходники 1.5, эта версия собиралась когда-то из них. Документации нет. А систему надо дорабатывать и развивать. Посчитали «переписать всё заново» и «доработать 1.5» и остановились на втором — TtM три-четыре месяца против года. Научили собирать спецов поддержки, поправили исходники, свели кодовые базы, сделали инфраструктуру, организовали одну «разливочную», куда принимается исходник, там собирается и дистрибутируется. Это стоило нам и заказчику большого количества геморроя.

Заходите, покажу ещё примерно то, как можно поошибаться с процессом разработки, и к каким интересным последствиям это приводит. Читать полностью »

Даже в очень крупных компаниях часто отношение к разработчикам, как к грибам: держат в темноте и кормят навозом. Пишите код, родные, и не высовывайтесь. Этот подход может быть удобен для многих (в том числе иногда — для самих разработчиков в случае не очень адекватного менеджмента), но с точки зрения бизнеса неоптимален. Моя позиция: разработчики должны иметь возможность узнавать всё то, что происходит в компании и на рынке, но без давления. Захотел — копнул и разобрался, не захотел — не надо.

Редко когда разработчик не хочет понимать, зачем и что он делает. Редко кто не хочет видеть влияния реализованных фич на мир вокруг. Да ладно, давайте будем честными: мы тут все или из-за денег, или из-за возможности делать что-то значимое. Деньги есть везде. А вот интересные проекты встречаются реже.

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

Как начинающему разработчику выжить на собеседовании и не сойти с ума на работе - 1

От переводчика: Валерий Алексиев, опытный программист, рассказал о том, что лучше делать разработчику ПО в самом начале карьерного пути. В частности, какие инструменты стоит использовать и на что обращать внимание на собеседованиях.

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

История фреймворка React: как Фейсбук приобрел Инстаграм и почему это привело к открытию исходного кода React.js

Как Фейсбук приобрел Инстаграм и почему это привело к открытию исходного кода React.js - 1

Сегодня React — одна из самых популярных в мире библиотек JavaScript для пользовательского интерфейса: более 70 тыс. «звезд» на Гитхабе, не менее 1100 авторов и миллионы скачиваний каждый месяц — кроме того, этот фреймворк используется более чем в 4 тыс. компаний. Но когда Фейсбук впервые показал React миру, это мало кого обрадовало.

Мы решили погрузиться в историю рождения одной из самых популярных технологий в мире разработки ПО — React, и пригласили Пита Ханта (Pete Hunt), стоявшего у истоков этой библиотеки (сейчас он генеральный директор компании Smyte), чтобы он наконец-то рассказал о том, для чего создавали React, почему эта технология стала популярной в Фейсбуке после приобретения Инстаграма, и как она в итоге вышла в люди.

Основные моменты

От приложения Facebook Camera к приобретению Инстаграма


Марк (Цукерберг) собрал всех и говорит: «Мобильные устройства «выстрелят», поэтому срочно бросаем всё и переводим ресурсы на мобильные разработки». Мне казалось, это какая-то сумасшедшая идея: мы не могли поддерживать работу самого большого фотосайта в сети, имея горстку людей в команде. Совершенно бессмысленно переводить людей на разработку приложений для iOS и Android, которые составляют совсем небольшую долю нашего трафика. Но оказалось, что Марк был на 100% прав — поэтому я и не генеральный директор Фейсбука…

Мы разработали приложение Facebook Camera, и даже гордились тем, что получилось… Но пришел Инстаграм — и наш проект канул в Лету…

Ребятам из Инстаграма дали гараж на территории Фейсбука, где можно было сидеть и спокойно пилить свою идею. Они пользовались надежными системами безопасности Фейсбука, но кроме того продолжали использовать AWS, а еще — разрабатывали собственную стратегию продукта, насколько я могу судить… И я был первым сотрудником из Фейсбука, которого перевели в Инстаграм…

Переведено в AlconostЧитать полностью »


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