Connect with us

Программирование

Программирование это новый пузырь?

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

Анна Гуляева

Опубликовано

/

     
     

Моя подруга недавно задала вопрос, который я слышал много раз в разных вариациях:

Не кажется ли вам, что некоторые низкоуровневые профессии программистов вымрут как птицы додо? Сейчас это похоже на большой пузырь, который рано или поздно лопнет. Мне кажется, что одна из причин “престижности” технологических и связанных с наукой (на низком уровне) профессий заключается в нелепом жаргоне индустрии и всеобщей компьютерной неграмотности, и оба этих фактора исчезнут в следующие десять лет […]

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

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

Движение к коммодификации

Страх того, что алгоритмы заменят людей на работе, — не нов и не беспричинен. В любой области, а особенно в технологии, силы рынка подталкивают корпорации к автоматизации и коммодификации. Один из способов изображения этого явления — циклы хайпа Gartner.

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

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

В этой метафоре «машиной» является язык программирования. Этот профессор спрашивал: вы хотите делать сайты на JavaScript или вы хотите создавать движок V8 для JavaScript?

Создание веб-сайтов уже автоматизировано при помощи WordPress и других сервисов. С другой стороны, у V8 появляются конкуренты, некоторые из которых решают открытые вопросы. Языки приходят и уходят (сколько сейчас открыто вакансий для Fortran?), но всегда будут люди, создающие следующий язык. К счастью для нас, все реализации пишутся на языках программирования. Путь «оператора машины» в программировании делает вас «создателем машины» в том смысле, который оказался неверным для работников сталелитейных заводом в прошлом.

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

Коммодификация распространяется на всё, не только на программирование. Человеческий труд постоянно заменялся автоматизированным или дополнялся таким образом, что требовал меньше людей. Беспилотные автомобили и грузовики являются последним примером этой великой традиции. Если цикл создания и автоматизации является частью жизни, то естественно будет спросить: какие работы и индустрии находятся в зоне риска, а какие нет?

Кто автоматизирует кого?

AWS, Heroku и другие аналогичные хостинговые платформы навсегда изменили роль системного администратора и DevOps-инженера. Раньше интернет-бизнесу был необходим свой “мастер серверов”. Кто-то, кто был подкован в Linux, мог настроить сервер Apache или NGINX, подключить все физические компоненты и сделать все необходимое для того, чтобы сервер стал доступным в публичном вебе. Хотя некоторые люди по-прежнему применяют этот навык в работе, AWS делают некоторые из этих навыков устаревшими, особенно на уровне небольшого опыта и размещения оборудования. В Amazon, Netflix и Google существуют хорошо оплачиваемые вакансии для людей с глубокими знаниями в инфраструктуре сетей, но спрос в малом и среднем бизнесе на таких людей значительно упал.

Инструменты бизнес-аналитики, такие как SalesForce, Tableau и SpotFire также начали занимать пространство, которое исторически занимали инженеры. Эти системы сократили потребность в штатных администраторах баз данных, но они увеличили спрос на понимание SQL. Они сократили потребность во внутренней технологии отчетности, но увеличили спрос на «инженеров интеграции», которые автоматизируют поток данных к сторонним платформам. Ранее этим полем правили Excel и таблицы, а теперь оно перешло к языкам вроде Python и R, а также SQL для управления данными. Некоторые профессии исчезли, но в целом спрос на разработчиков программ вырос.

Data Science — это ещё один интересный пример коммодификации, более близкой к программированию. Scikit.learn, Tensorflow и PyTorch — это библиотеки, которые упрощают людям задачу создания приложений с машинным обучением, устраняя необходимость создания алгоритмов с нуля. На самом деле, теперь возможно провести набор данных через многие алгоритмы машинного обучения с разными параметрами, практически не понимая работу этих алгоритмом (это неправильно, но возможно). Компании бизнес-аналитики, вероятно, будут пытаться интегрировать эти алгоритмы в свои инструменты в следующие несколько лет.

Во многом Data Science сейчас похожа на веб-разработку 5–8 лет назад. Это популярная область, в которую вы можете попасть с небольшим количеством знаний из-за «разрыва в навыках». Программы по веб-разработке закрываются, а программы по data science появляются на их месте. Kaplan, которая купила первый лагерь по веб-рзработке Dev Bootcamp и основала лагерь по data science Metis, решила закрыть Dev BootCamp и поддерживать Metis.

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

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

В этом контексте нельзя проигнорировать и физический аспект. Как сказал Майк Актон: «Программное обеспечение — это не платформа, аппаратное — платформа». Разработчикам стоит немного изучить компьютерную архитектуру и электротехнику. Большой переворот случится при появлении потребительского квантового компьютера, он изменит многое в профессиональном программировании.

Квантовые компьютеры пока далеки от нас, но растущий интерес к графическим процессорам и движение к параллелизации — это неминуемый сдвиг. Скорости работы процессоров остаются неизменными уже несколько лет, а за это время возникла потребность в машинном обучении. Желание работать с OpenMP, OpenCL, Go, CUDA и другими языками и фреймворками параллельной обработки данных никуда не денется и будет только нарастать. В ближайшем будущем параллелизация станет всеобщим требованием и выйдет за пределы ниш операционных систем, инфраструктуры и видеоигр.

Все учатся кодить

Веб-сайты повсеместны. Опрос Stack Overflow 2017 года показывает, что около 15% профессиональных разработчиков работают в компаниях, связанных с интернетом или веб-сервисами. Бюро статистики труда ожидает ускорение роста в веб-разработке (24% между 2014 и 2024). Благодаря видимости отрасли, многие сосредоточены на «сокращении разрыва в навыках». Лагери программирования обучают практически только веб-разработке, а онлайн-курсы по этой теме заполнили Udemy, Udacity, Coursera и другие платформы.

Комбинация роста автоматизации в веб-разработке и приток новых программистов привели к тому, что некоторые предсказывают появление рынка «синих воротничков» для разработчиков. Другие даже предполагают, что это движение к рынку “рабочих” специальностей является стратегией больших технологических компаний. Остальные, конечно, считают, что мы движемся к очередному пузырю.

Изменение спроса на определенные технологии — это не новость. Языки и фреймворки всегда то набирают силу, то теряют популярность. Веб-разработка в своей текущей инкарнации (JS — король) рано или поздно пройдет путь веб-разработки в начале 2000-х (помните Flash?). Новым является то, что многие люди изучают исключительно современные фреймворки веб-разработки. Прежде чем вы назовете себя React-разработчиком, вспомните, что были люди, которые идентифицировали себя как Flash-разработчиков. Полагаться на определенный язык, фреймворк или технологию в своей карьере рискованно. Конечно, сложно предсказать, какие технологии останутся релевантными, но если вы собираетесь пойти ва-банк, я рекомендую положиться на эффект Линди и выбрать что-то вроде C, который уже перенес испытание временем.

У следующего поколения будет такой уровень врожденной технологической грамотности, которого нет у поколения X и миллениалов. Одним результатом этого станет то, что CMS будут использоваться по умолчанию. Сами инструменты станут лучше, и молодые сотрудники будут лучше ими пользоваться. Эта комбинация определенно снизит ценность низкоуровневых навыков IT и веб-разработки, когда молодые специалисты войдут на рынок труда. Школы следуют за этим трендом, предлагая курсы программирования и информатики, и образованные ученики смогут сразу после окончания стать стажерами-программистами.

Другая большая группа потенциальных программистов включает выпускников MBA и аналитиков данных. В предложениях о работе, в которых прежде доминировал Excel, начинает использоваться SQL. Веб-метрики заменят таблицы в роли главного инструмента создания отчетов. Если это продолжится, все больше аналитиков данных будут сразу учить SQL, потому что он позволит проще экспортирования данные в таблицы.

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

Число людей с образованием в информатике и программировании продолжает расти. Университет Пердью сообщает, что количество заявлений на направление информатики удвоилось за пять лет. Корнелл сообщает об аналогичном росте числа выпускников по этому направлению. Этот тренд неудивителен в свете распространения ПО. Молодые люди не представляют будущего без компьютеров, поэтому хотят изучать то, что даст им уверенность в трудоустройстве.

Редкость и ожидание

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

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

Школ программирования становится больше – и это не просто так. Вы можете многое узнать о программировании без знаний о большом «О», неясных структурах данных и деталей об алгоритмах. Иногда выпускники Стэнфорда соперничают с выпускниками Hack Reactor, но это верно только для одной или двух областей. Выпускники курсов программирования пока не работают в области встроенных систем, криптографии, безопасности, робототехники, инфраструктуры сетей или в разработке и исследовании искусственного интеллекта. Хотя эти области быстро растут.

Некоторые навыки уже превращаются из редких навыков в базовое ожидание. Понимание механизмов, вроде AWS, становится довольно распространенным. Но большие компании, развивающие технологии, обычно не ищут людей с «базовым пониманием JavaScript». AWS обслуживают миллиарды пользователей каждый день. Чтобы поддерживать такую инфраструктуру инженер должен понимать протоколы сетей, компьютерную архитектуру и иметь несколько лет аналогичного опыта работы. Как и в любой области, здесь есть любители и мастера.

Эти престижные фирмы исследуют проблемы и создают системы, которые действительно двигают границы возможного. Но они по-прежнему испытывают дефицит кадров, несмотря на то, что базовые навыки программирования достаточно распространены. Люди, которые могут писать алгоритмы для прогнозирования изменений в генах, которые дадут желаемый результат, будут очень ценными в будущем. Люди, которые могут программировать спутники и космические аппараты и автоматизировать машины, будут по-прежнему высоко цениться. Это не те области, для работы в которых достаточно «трехмесячной интенсивной программы», как в веб-разработке.

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

Бимодальные распределения заработной платы

Во многих областях действует бимодальное распределение заработной платы: небольшое количество сотрудников зарабатывают большие деньги, а остальные получают неплохую зарплату, но не входят в верхний процент. NALP визуализирует этот феномен абсолютно понятно. Многие юристы зарабатывают между 45 и 65 тысячами долларов. Это хорошая зарплата, но мы не можем ассоциировать её с «топовыми профессионалами».

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

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

Зарплаты мобильных разработчиков 2017: деньги, платформы, стаж и регионы

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Программирование

Все инженеры умеют программировать, но не все программисты могут быть инженерами: в чем отличие?

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

Анна Гуляева

Опубликовано

/

Многим людям не нравится термин “инженер по разработке программного обеспечения” из-за относительного сравнения с инженерным делом. Но эта статья посвящена не термину. Если вам не нравится название, вы можете заменить его на “автор ПО”, “мастер ПО” или даже “художник по ПО”.

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

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

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

Хотите еще бльше аналогий? Конечно:

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

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

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

Инженеры понимают все о проблемах, которые они решают, о своих решениях, об ограничениях этих решений, последствиях этих решений для приватности и безопасности.

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

Склонность к поиску решений

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

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

Перед созданием программы инженер задает вопросы:

  • Какие проблемы я пытаюсь решить?
  • Можно ли сделать для их решения что-то, кроме написания кода?
  • Что я могу сделать, чтобы эти проблемы было проще решить при помощи кода?

Качество кода

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

Один из самых важных аспектов разработки ПО — создавать с самого начала системы, которые можно будет расширять. Изменение программ неизбежно. Пользователи начнут требовать новых функций и новых способов применения программ.

Каждый программист (не)счастлив по своему

Сама по себе программа не так полезна. Ценность их функций проявляется, когда разные программы коммуницируют друг с другом, обмениваются данными и совместно работают над представлением данных и интерфейсов пользователям. Об этом нужно помнить при создании программ. Какие сообщения они будут принимать? Какие события будут отслеживаться? Какие сообщения они будут отправлять? Как мы будем проводить аутентификацию и авторизацию коммуникаций?

Другой важный аспект отличных программ — это ясность кода, а не количество тестов или число в отчете по тестовому покрытию. Этот код может прочитать кто-то ещё? Смогу ли я понять этот код через несколько недель?

В программировании существует только две по-настоящему сложных вещи: инвалидация кэша и наименование вещей, — Фил Карлтон

Удобство чтения кода важнее, чем вы думаете. К сожалению, для ясности кода нет хороших метрик. Знание хороших методов может помочь, но часто этого недостаточно. Хорошие инженеры просто учатся этому с опытом. Здесь подходит метафора с писательством: знание большого количества слов не поможет вам писать понятные тексты.

“У меня не было времени на короткое письмо, поэтому я написал длинное”, — Марк Твен

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

Правильный разработчик

Среда и тестирование

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

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

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

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

Стоимость и эффективность

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

Как найти лучших разработчиков для работы над проектом

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

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

Удобство использования

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

Вот несколько примеров:

  • При создании форм для ввода данных хорошая программа будет игнорировать прописные или строчные буквы? которые используются для ввода email-адреса. Она также уберет ненужные пробелы. Не нужно мучать пользователя из-за включенного Caps Lock, адрес почты уникален. Если программа принимает новые адреса, она должна сообщать пользователю о проблемах с вводом, например, об отсутствии знака @ или опечатке в gmail.ocm.
  • При перенаправлении пользователя хорошая программа запомнит первоначальное местоположение и перенаправит пользователя туда после завершения задачи. Хорошая программа также запомнит уже введенные данные и взаимодействия, которые нужны будут в следующих шагах. Например, вы ищете авиабилеты на Expedia в качестве гостя. Затем вы решили создать аккаунт. Вся ваша история поиска будет сохранена в новый аккаунт, и вы сможете получить к ней доступ с разных устройств.
  • Хорошая программа создается с учетом пользовательских сценариев. Поставьте себя на место пользователя. Однажды я забронировал билет United и забыл ввести свой номер постоянного пассажира. После получения подтверждения я отправился на сайт United, чтобы добавить номер, и эта задача заняла у меня десять минут. К этой функции не было очевидных путей, поэтому мне пришлось проверить все ссылки, которые могли бы вести к ней. Я уже был на странице с этой функцией, но я не увидел её в первый раз, потому что она была спрятана в большой форме. Мне пришлось найти информацию о пассажире, пролистать около 20 строк в этой форме, ввести номер пассажира и номер телефона, чтобы отправить эту форму. Это пример программы, которая создавалась без учета точки зрения пользователя.

Читабельность и безопасность

Это наиболее важные моменты, которые отличают профессионалов от любителей. Они знают, что ответственны за создание надежных и безопасных решений.

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

Пользователи будут вводить неверные данные в программу. Некоторые будут делать это специально, чтобы взломать её. Ответственного за недавний скандал с Equifax обвинили в том, что этот человек не сделал свою работу, то есть не создал устойчивую к зловредным входным данным программу.

Безопасность касается не только зловредных данных, но и обычных. Если пользователь забывает пароль, то сколько раз он или она сможет его ввести? Заблокируете ли вы после этого аккаунт? Что если кто-то этого и добивается? Позволите ли вы вводить пароль через незащищенное соединение? Что если попытка логина состоялась из необычного места? Что если логин кажется сгенерированным автоматически?

Что вы сделаете, чтобы защитить пользователей от межсайтового скриптинга и подделки запросов, атаки посредника и простого социального фишинга? Есть ли у вас стратегия на случай DDoS-атаки? Эти вопросы — это только несколько из проблем, к которым вы должны готовиться.

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

Дефекты программ невидимы. Наша способность предсказывать и предотвращать известные дефекты ограничена. Поэтому инженеры понимать ценность хороших инструментов, которые могут помочь им писать корректные и безопасные программы.

Инструменты

Несомненно, нам нужны хорошие инструменты. Они многое меняют и часто недооцениваются. Представьте, если бы нам все ещё нужны были FTP для ффайлов! Представьте проблемы с производительностью и устранением багов без Chrome DevTools! Представьте, как неэффективно бы было писать на JavaScript без ESLint и Prettier!

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

Когда я нахожу отличный инструмент, я жалею лишь о том, что не нашел его раньше. Хорошие инструменты помогут вам стать хорошим программистом. Ищите их, используйте их, цените их и улучшайте их.

Выбор языка имеет значение. Типобезопасность имеет значение. Лучшее, что случилось с JavaScript — это TypeScript и Flow. Статический анализ кода важнее, чем вы думаете. Если вы этого не делаете, то ставите себя под удар неизвестных будущих проблем. Не программируйте без системы статической проверки типов. Если в вашем языке этого нет, поменяйте язык или используйте компилятор. Сегодняшние компиляторы могут работать, просто читая комментарии в коде, и это будущее проверки типов для языков, которые не поддерживают её.

Эволюция разработки

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

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

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

 

Комментарии
Продолжить чтение

Новости

Россияне победили в чемпионате мира по программированию ACM ICPC

AppTractor

Опубликовано

/

Автор:

Сегодня в Пекине завершился финал чемпионата мира по программированию ACM ICPC. Российские вузы традиционно показали высокие результаты: команда Физтеха в составе Александра Останина, Александра Голованова и Никиты Уварова взяла золото и заняла второе место, команда МГУ — первое. Команда Университета ИТМО и Уральского федерального университета получили бронзовые медали. Все российские команды завоевали 4 медали из 13 — это больше, чем у других стран. У США и Китая — по 3. По одной у Японии, Кореи и Литвы.

Алексей Малеев, руководитель команды Cryptozoology, директор Центра ИТ-образования МФТИ:

В этом году очень много сильных команд, помимо традиционных вузов Санкт-Петербурга, очень сильные ребята из Польши и Кореи. Контест проходит на высоком уровне в Университете Пекина, принимающая сторона вложила много труда в организацию. Высокие результаты на старте показали два ведущих московских вуза — МГУ и МФТИ. Отмечу, что Москва имеет самое большое представительство среди всех городов мира – сразу 4 университета отстаивают честь нашего региона. Более того, 10 из 13-ти медалистов прошли школу Moscow Workshops ICPC на базе МФТИ. Команда Физтеха показала высокий результат, они уверенно шли к победе весь год, в полуфинале NEERC взяли абсолютное чемпионство, и сейчас на мировом уровне взяли золото. Они показали лучший результат за всю историю участия МФТИ в соревнованиях, с чем можно поздравить команду Cryptozoology! Мы гордимся нашими студентами.

«Сегодня команда МФТИ взяла золото в самом главном международном соревновании по программированию. Это доказывает, что программистское образование у нас в стране — одно из лучших в мире. Поздравляем команду МФТИ “Cryptozoology” и всех российских программистов!», — ректор МФТИ Николай Кудрявцев.

Команда Физтеха успешно решила восемь задач, при этом первыми справилась с пятой. На протяжении 5-часового контеста сборная лидировала, занимая первое место в таблице результатов. Но за несколько минут до окончания турнира, команда Moscow SU Red Panda в составе Михаила Ипатова, Владислава Макеева и Григория Резникова решила ещё одну задачу, что обеспечило им победу.

С 31 марта по 1 апреля прошёл студенческий чемпионат MosCode Festival, организованный Центром развития ИТ-образования МФТИ. Сборы стали репетицией ACM ICPC. В них прошли подготовку 10 из 13 медалистов финала.

ACM ICPC — это один из главных Всемирных студенческих чемпионатов по программированию. В этом учебном году в нём принимали участие более 300 000 студентов с 6 континентов. Чемпионат уходит своими корнями в соревнование, проводившееся в Техасском университете в 1970-х годах. Ныне чемпионат проводится ежегодно под эгидой ассоциации вычислительной техники (ACM). В разное время спонсорами соревнований становились такие компании, как Apple, AT&T и Microsoft, IBM и JetBrains.

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

Тур олимпиады происходит следующим образом: каждой команде на пять часов выдаётся компьютер и от восьми до двенадцати задач, условия которых написаны на английском языке. Интересно, что команды пишут решения не просто текстом, а на языках программирования C, C++ или Java и посылают их на тестирующий сервер.

Комментарии
Продолжить чтение

A/B тестирование

A/B-тестирование в Firebase: часть 2

Продолжаем изучать Remote Config и A/B-тестирование в Firebase и учимся делать ваших пользователей самыми счастливыми!

AppTractor

Опубликовано

/

Автор:

Расширенный пользовательский таргетинг

Давайте изменим механизмы, чтобы понять, что еще мы можем сделать с Firebase Remote Config вне A/B-теста.

В предыдущем уроке вы избежали международного кризиса, установив shouldWeIncludePluto в true для ваших пользователей в Скандинавии. Оказывается, однако, что такой настройки на основе страны недостаточны. Выбор того, планета ли Плутон, является глубоко личным, и многие люди со всего мира хорошо относятся к планетному статусу Плутона. Как мы можем настроить Planet Tour для всех?

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

Свойства пользователя в Google Analytics

Свойство пользователя в Google Analytics для Firebase – это просто свойство, связанное с конкретным пользователем.

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

В вашем случае вы будете использовать свойство likeSmallRocks, чтобы понять то, как пользователь относится к небольшим, холодным скалам на окраинах нашей солнечной системы. Затем вы будете использовать это свойство в сочетании с Remote Config, чтобы предоставить пользователям новый опыт на основе этого значения.

Хотя существуют разные способы определить, является ли пользователь поклонником маленьких отдаленных скальных пород, проще всего просто спросить их.

В верхней части PlanetsCollectionViewController.swift добавьте эту строку:

import Firebase

Затем добавьте следующее определение reuseIdentifier:

private let takenSurveyKey = "takenSurvey"

Наконец, добавьте следующее внутри расширения с помощью MARK: – Internal, прямо над функцией addFancyBackground ().

@objc func runUserSurvey() {
  let alertController = UIAlertController(title: "User survey",
    message: "How do you feel about small, remote, cold rocks in space?",
    preferredStyle: .actionSheet)

  let fanOfPluto = UIAlertAction(title: "They're planets, too!", style: .default) { _ in
      Analytics.setUserProperty("true", forName: "likesSmallRocks")
  }

  let notAFan = UIAlertAction(title: "Not worth my time", style: .default) { _ in
      Analytics.setUserProperty("false", forName: "likesSmallRocks")
  }

  alertController.addAction(fanOfPluto)
  alertController.addAction(notAFan)
  navigationController?.present(alertController, animated: true)

  UserDefaults.standard.set(true, forKey: takenSurveyKey)
}

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

Теперь, когда вы определили свое свойство пользователя в коде, вам необходимо выполнить второй шаг, который позволяет консоли Firebase знать, что это свойство существует, чтобы оно могло начать создавать отчеты на его основе. Лучше всего добавлять user property в консоль Firebase одновременно с добавлением ее в код. Откройте консоль Firebase и выберите «Google Analytics», затем «User Properties» .

Теперь будьте осторожны в следующем шаге – консоль Firebase не позволяет редактировать или удалять свойства пользователя после их создания! Выберите NEW USER PROPERTY и создайте новую запись, которая называется likeSmallRocks. Я рекомендую копировать и вставлять имя, чтобы убедиться, что оно точно соответствует. Дайте ему любое описание, которое вы хотели бы. Затем нажмите CREATE.

Вернитесь в PlanetsCollectionViewController.swift и в конце viewDidAppear(_:) и добавьте эти строки, чтобы убедиться, что вы запрашиваете это только один раз при установке приложения:

if !UserDefaults.standard.bool(forKey: takenSurveyKey) {
  runUserSurvey()
}

Если вы хотите немного упростить тестирование, добавьте этот код viewWillAppear(_:) выше customizeNavigationBar(), который добавит кнопку на панель навигации, чтобы запустить опрос в любое время, минуя проверку того, что вы уже видели это:

let retakeSurveyButton = UIBarButtonItem(barButtonSystemItem: .compose,
                                         target: self,
                                         action: #selector(runUserSurvey))
parent?.navigationItem.rightBarButtonItem = retakeSurveyButton

Создайте и запустите приложение. Теперь вас спросят, как вы относитесь к маленьким скалам в космосе. Не стесняйтесь и честно ответьте.

Настройка вашего приложения

Теперь вы можете начать настройку Remote Config на основе этого значения. Откройте консоль Firebase и выберите Remote Config. Если вы закончили предыдущий туториал, вы увидите свою запись для shouldWeIncludePluto. И если вы этого не сделали, создайте ее заново.

Если вам нужно создать, сначала нажмите «ADD YOUR FIRST PARAMETER». Затем введите значение параметра shouldWeIncludePluto для Parameter key и сохраните значение по умолчанию пустым (Default value). Затем нажмите ADD PARAMETER.

Нажмите значок карандаша рядом с надписью shouldWeIncludePluto, чтобы изменить его, затем выберите Add value for condition > Define new condition. Назовите новое условие «Small rock fans» и укажите это условие, если User property > likesSmallRocks | exactly matches | true.

Примечание. Не выбирайте оператор сравнения == в этом диалоговом окне – это используется только для чисел.

Нажмите CREATE CONDITION, затем установите для этого значения значение true и значение по умолчанию – false .

Примечание. Если вы не выполнили предыдущий туториал, то здесь не будет состояния «Pluto fans». Ничего страшного!

Нажмите UPDATE, затем PUBLISH CHANGES.

Теперь создайте и запустите приложение снова.

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

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

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

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

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

Вернитесь в Remote Config в консоли Firebase и создайте новую запись для planetImageScaleFactor. Дайте ему значение 0,2 для пользователей в состоянии «Small rock fans» и значение по умолчанию 0,45. Нажмите UPDATE, затем PUBLISH CHANGES.

Снова запустите Planet Tour. В зависимости от того, как вы относитесь к маленьким скалам, планеты, такие как Марс или Плутон, должны выглядеть пропорционально больше или меньше.

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

И вы можете выполнить некоторые A/B-тесты с этими параметрами, чтобы узнать, что делает пользователей вашего приложения самыми счастливыми!

Комментарии
Продолжить чтение

Обучение

План изучения Android-разработки для начинающих

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

Анна Гуляева

Опубликовано

/

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

0. Изучите Java

Да, я отметил этот шаг как нулевой, потому что перед изучением Android-разработки у вас должно быть знание Java. Вы можете сказать: “Но ведь Kotlin гораздо лучше подходит для Android-разработки, чем Java? И Google сделал его официальным языком для создания Android-приложений. Тогда зачем мне сначала изучать Java?”

Я не говорю, что вы не должны учить Kotlin. Я советую сначала изучить Java, потому что вы только начинаете заниматься Android-разработкой, а Java по-прежнему является важной частью Android. Ресурсов для обучения Android API на Kotlin пока недостаточно. Многие из уроков для начинающих написаны на Java. Поэтому для вас будет полезно понимать код на Java, не прогоняя его через конвертер.

Я посоветую для обучения Java книгу Head First Java. Она так интересно написана, что вам покажется, будто вы изучаете Java по комиксу. Другой хороший вариант — Thinking in Java.

1. Купите книгу по Android-разработке или пройдите онлайн-курс

После изучения Java приходит время начать обучаться Android-разработке. Я советую книгу Android Programming: The Big Nerd Ranch Guide для начала. Она основана на популярных буткэмпах Big Nerd Ranch. Вы можете использовать эту книгу в качестве практического руководства по Android-разработке, так как в ней много примеров кода с отличными пояснениями по ключевым концепциям.

Также я рекомендую Head First Android Development. Хотя эта книга немного устарела, она объясняет ключевые концепции очень интересным способом. Если вам понравился стиль Head First, вам будет приятно читать эту книгу.

Если вы предпочитаете видеоуроки, то советую вам пройти эти курсы:

Если вы хотите стать сертифицированным Android-разработчиком и у вас есть средства, я советую вам записаться на программу Android Developer Nanodegree от Udacity совместно с Google.

Google предлагает бесплатный курс Android Basics Nanodegree для незнакомых с программированием

Не забудьте добавить в закладки официальный обучающий гид для Android-разработчиков от Google. Этот гид затрагивает все базовые вещи и образцы кода, которые будут полезны для любого Android-разработчика.

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

Другие курсы:

2. Убедитесь, что понимаете эти концепции очень хорошо

Activity LifeCycle

Service, IntentService и их жизненный цикл

Broadcast Receivers

Content Providers

Tasks и Back Stack

Устранение багов в приложении

Context в Android

Android Views и Layouts

Темы и стили в Android

Fragments

ViewPager

RecyclerView

Shared Preferences

SQLite

Threading

ThreadPoolExecutor

Looper, Handler, HandlerThread

HTTP и REST

Организация сетей в приложениях Android

Уведомления

Локация и карты

Сенсоры Android

Локализация

Разрешения

App Standby и Doze Mode

Библиотеки поддержки в Android

Материальный дизайн

Система сборки в Android

3. Другое рекомендуемое чтение

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.