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

в 7:02, , рубрики: алгоритм, база данных, банк, безопасность, Блог компании ТЕХНОСЕРВ, данные, информационная безопасность, маскировка, обезличивание, разработчик, СУБД, тестировщик, тесты, финансы, хранение, хранение данных

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

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

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

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

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

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

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

в 7:34, , рубрики: карьера, Карьера в IT-индустрии, нетянегамлет, обучение, Программирование, работа, разработчик, управление персоналом

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

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

в 7:06, , рубрики: байки, Блог компании КРОК, заказчик, консалтинг, разработчик, управление проектами

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

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

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

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

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

в 7:02, , рубрики: Блог компании Туту.ру, команда, отчёт, пользователь, продукт, проект, разработчик, управление проектами, управление разработкой

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

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

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

в 10:47, , рубрики: skillbox, Блог компании Skillbox, Карьера в IT-индустрии, карьера программиста, начинающий разработчик, обучение, Программирование, разработчик, Учебный процесс в IT

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

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

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

в 13:23, , рубрики: Alconost, github, javascript, javascript framework, javascript library, ReactJS, Блог компании Alconost, инженер, качество кода, пользовательский интерфейс, Программирование, разработка по, разработка программного обеспечения, разработчик, создание программ

История фреймворка 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Читать полностью »

в 9:07, , рубрики: Блог компании NIX Solutions, Программирование, программист, программный инженер, Проектирование и рефакторинг, разработчик, Читальный зал

Программная инженерия отличается от программирования - 1

Перевод Software engineering is different from programming.

Некоторым людям не нравится термин «программный инженер» из-за метафоры с инженерным делом. Но эта статья не про термин. Если он вам не нравится, замените на Автора программ, Умельца по программному обеспечению или Программного художника!

Под «программным инженером» я подразумеваю человека, который считает своей профессией написание качественного ПО. Этот человек использует науку и статистику в своей профессии, и не относится к ней как к способу зарабатывания денег.

Умение программировать не делает вас программным инженером.
Читать полностью »

в 9:25, , рубрики: Alconost, Блог компании Alconost, инженер, Карьера в IT-индустрии, качество кода, ненормальное программирование, Программирование, разработка по, разработка программного обеспечения, разработчик, Совершенный код, создание программ

Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО

Не путайте разработку ПО и программирование - 1
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.

Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!

Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.

Чтобы стать разработчиком, уметь программировать недостаточно.

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

Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.

Хотите еще аналогий? Пожалуйста:

  • В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
  • Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
  • Никто не зовет соседа — мастера на все руки построить дом с нуля.

Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.

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

в 7:26, , рубрики: Alconost, Блог компании Alconost, быстрое программирование, Занимательные задачки, качество кода, код, мысли, ненормальное программирование, проблемы разработки по, Программирование, программист, продуктивность, простой код, разработка, разработчик, сложный код, Совершенный код, советы

Секрет быстрого программирования: не задумывайтесь - 1


Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том, можно ли как научиться программировать с космической скоростью.

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

Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код. Впрочем, дедлайны не должны приводить к сложности. Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто». То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.

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

Нет, это вообще не магия и не врожденный дар. На самом деле существует всего одно простое правило, считаясь с которым, со временем вы полностью решите проблему:
Читать полностью »

в 10:19, , рубрики: говнокод, Карьера в IT-индустрии, подушка безопасности, разработчик, управление персоналом, управление разработкой, метки:

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

Или по-другому: разработчик, нанятый с целью поднятия ЧСВ группы разработчиков, стоящих у истоков говнокода.
Читать полностью »

1...234...5
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js