Connect with us

Разработка

Сколько стоит сделать приложение?

Разработчик Брайан Конклин делится затратами на разработку своей первой игры.

Анна Уханаева

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

/

     
     

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

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

И я не был новичком. Я был страстным фанатом технологий уже 26 лет и только получил степень магистра в Computer Science. И все же я еще был зелен.

Я быстро понял, что проект не будет дешевым. Каждый раз, когда я отправлял свои требования в потенциальное агентство и спрашивал, во сколько мне обойдется разработка приложения, они называли невиданные цены: 15, 20 и даже $50 000 за разработку и развертывание на iOS и Android.

Путь к просвещению

Цены за разработку приложения, которые мне называли, были для меня неподъемными. Еще я узнал, что пользователи iOS тратят больше на приложения, чем пользователи Android. Так что я решил переработать план и сосредоточиться на приложении для iPhone. Я собирался выучить Objective-C и сделать его самому. На это я заложил пять месяцев и сказал всем, что точно закончу задолго до этого срока. Я проглотил бесконечное количество туториалов по Xcode и Objective-C. Я даже купил новый Macbook Air примерно за $1300.

Попутно нужно было научиться как следует работать в Photoshop. Я даже не представлял себе, сколько графического дизайна заключено в разработке кнопок, фонов и всего прочего. Мне пришлось потратить $500 на разработку некоторых персонажей и фонов для того, чтобы начать.

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

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

Хотите помочь мне сделать приложение?

Уже не такой наивный, я взялся за найм со всей серьезностью.

Очень важно отметить две главные составляющие создания приложения: дизайн и разработка.

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

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

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

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

Дизайн

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

1

Скачок в июне – это плата за первый дизайн, который позволил мне начать. Сюда входит разработка SiK Robot и овечек, а также фоны, пока я пытался закодит приложение сам.

2

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

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

Разработка

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

3

Выброс в июне на графике – это покупка Macbook Air. О, как я был тогда амбициозен! Можно заметить, что работа несколько застопорилась в ноябре из-за того, что переделывался UI. Декабрь прошел за внедрением нового UI, и мы до сих пор вносим финальные штрихи и параллельно отвечаем на пользовательские отзывы, которые прислали нам во время бета-тестирования.

4

Диаграмма показывает, что на декабрь выпала львиная доля всех затрат на разработку. Теперь, после появления новых размеров экранов в iOS, нам нужно писать для iPhone 4,5 и 6. Очень дорого обходится только то, чтобы все было правильно расположено на каждом экране.

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

Разное

Я не буду подробно останавливаться на дополнительных затратах, но игнорировать их тоже нельзя. К ним, например, относятся звуковые эффекты, музыка, сервисные сборы и судебные издержки. Сейчас мы решаем юридические вопросы с Apple, потому что кто-то уже использует название SiK Robot в AppStore. Мы потратили $500 на регистрацию торговой марки и это значительно задержало дату запуска.

Кроме судебных издержек мне пришлось потратить около $1000 на вышеупомянутые вещи.

Продолжающаяся разработка

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

Исправление багов – это как пытаться заткнуть постоянно возникающие в дамбе пробоины. Только заделаешь одну, как появляются две другие.

Полученные уроки

Я многое понял с тех пор, как решил создать приложение. Вот четыре главных вещи:

1. Создавать список требований

Жизненно важно иметь подробное описание всего функционала, который вы хотите иметь в вашем приложении. Это полезное упражнение, потому что оно заставит вас оценить ваше приложение в целом. Просто запишите все, что вы хотите от приложения: одно предложение за раз. Этот процесс называют спецификацией требований к ПО. Это целая отдельная наука, но необязательно описывать все в очень технических терминах. Чтобы начать, нужно иметь хотя бы 10 элементов. Вот три примера из моих требований к SiK Robot.

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

2. Сделайте макет

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

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

Если вы такой же как я, то вы тоже хотите сделать “простое” и “маленькое” приложение. Это не предполагает такой большой работы, правда? Как только вы закончите первые два урока, у вас получится около 20 экранов. Нет? Есть ли в ваших идеях пользовательские аккаунты? Что если пользователь забудет пароль и ему нужно будет его сбросить? Вы сделали эти скрины? Создание экранов пользовательского аккаунта для логина/регистрации/сброса – целый самостоятельный процесс.

Итак, теперь у вас есть полновесный план вашего приложения. Время осознать, что вы не имеете ни малейшего представления, будет ли это работать, а еще очень важно получить одобрение остальных. Я знаю, что вы прекрасный генератор идей, но попробуйте забыть о своем эго ненадолго. Самый быстрый способ валидировать приложение – сделать его как можно меньше. Без какого функционала вы не сможете обойтись совсем? Минимальное число экранов? Это и будет ваш minimum viable product – MVP. Как только вы все это выясните, вернитесь и переделайте требования и макет для отражения MVP. Это то, над чем вы будете работать в ближайшие 3-6 месяцев разработки вашего приложения. Вот пример MVP SiK Robot, который я сделал в октябре. На нем представлен начальный UI, который я в конце концов отбросил и теперь могу спокойно смотреть на него.

5

4. Если вы делаете игру, создайте документ для дизайна игры (Game Design Document – GDD)

Я даже не подозревал о его существовании, когда начинал приложение. Было бы очень полезно, если бы я подготовил его в самом начале. GDD позволяет вам детализировать сюжет, персонажей, уровни/среду, геймплей, арт, музыку/эффекты, пользовательский интерфейс и элементы управления. Он сочетает в себе что-то от требований к программной части и вайрфрейма в контексте игры. Для облегчения жизни можно воспользоваться онлайн-шаблонами.

Заключение

Таким образом, суммарные затраты составили $12,000 и будут еще расти. Теперь мы прошли полный круг. Первоначальные оценки оказались довольно точными. Но вообще, когда я делал прикидки, я надеялся на гораздо более крутое приложение, чем получившийся MVP.

В итоге: если у вас есть идея приложения, создание MVP, скорее всего, обойдется вам как минимум в $10,000.

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

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

10 Comments

  1. mechmeatz

    07.02.2015 at 20:28

    Интересно, в РФ такой же уровень цен? Сейчас прикидываю стоимость разработки и поддержки маленького приложения на Андроиде

    • Василий

      08.02.2015 at 17:05

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

      • egori4

        08.02.2015 at 19:23

        Если у тебя есть друзья, которые готовы жертвовать своим временем, то да, цена будет минимальна, но даже не сложное решение займет всё их свободное время и это, как видишь из статьи не одна неделя, а месяцы, возможно годы. Смотрели фильм indie game the movie? Там разработчики игр очень подробно рассказывают про свой путь от идеи до запуска. И часто это адовый путь, который не пройти без дикой веры в проект.

        • Free Alex

          11.07.2015 at 15:29

          Согласен, создать что то стоющее не так и просто. Решил создать портал музыки и приложение кнему, только портал занял уже почти 2 года, а приложение только начинаю продумывать.

          • egori4

            12.07.2015 at 05:22

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

          • Free Alex

            12.07.2015 at 12:30

            напиши мне в скайп: aleksej773

      • Gregory Malkin

        08.07.2015 at 13:32

        У друзей же нет никакой ответственности перед вами за разработку вашего приложения :) Это раз. Его же еще надо тестировать и тестировать. Разработать одно, а так, чтоб его принял стор – совсем другое) Про стоимость мне вот эта статья понравилась – http://webmartsoft.ru/blog/stoimost-mobilnogo-prilozhenija.html . Но все равно конкретных цифр вам никто не скажет) а если скажут, то еще и поторгуются

        • AppTractor

          12.07.2015 at 11:09

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

    • egori4

      08.02.2015 at 19:26

      Если взять из статьи срок разработки этой, тоже «маленькой» игры, то в разных компаниях примерно так и выйдет. Плюс/минус $ 1 000.

  2. Деня

    27.02.2017 at 11:49

    Ужас, не знаю правда, где Вы такие цены взяли. Я пользуюсь фриланс услугами и это как вижу в 1000000 раз дешевле.Попробуйте! https://5bucks.ru/section/mobile-application/

You must be logged in to post a comment Login

Leave a Reply

Исследования

Какие эмодзи больше всего используют программисты

Эваристо Карабайо  проанализировал около 3,5 гигабайтов логов, чтобы узнать о том, какой эмодзи самый популярный у разработчиков.

AppTractor

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

/

Автор:

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

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

В этой статье я рассматриваю то, как новые разработчики используют эмодзи, в частности, в Gitter Main Chat Room на платформе freeCodeCamp.

Есть как минимум два способа рендеринга эмодзи в Gitter:

  • с использованием псевдонимов (например, таких);
  • с использование UTF-8 путем написания эмодзи непосредственно ключевым словом или копированием/вставкой символа из онлайн-ресурса.

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

Чтобы дать вам краткое представление о том, чем я интересовался, я хотел бы быстро осветить ответы на такие вопросы, как:

  • Есть ли явный шаблон в использовании эмодзи?
  • Каковы самые популярные эмодзи?
  • Сколько людей использует эмодзи?
  • Насколько люди разбираются в словаре эмодзи?

Поэтому давайте начнем и ответим на эти вопросы.

Поговорим об эмодзи

Проведя свой анализ чата freeCode, я узнал, что около 23% вовлеченных в разговоры в чате также были и любителями эмодзи. Я определяю слово «вовлеченный» как человека, который отправил не менее 10 сообщений. Если мы сравним вовлеченных и невовлеченных любителей эмодзи с обычными ценителями чатов, эта цифра возрастет до 45%.

Количество «эмодзионеров» в чате freeCode может показаться маленьким по сравнению с другими чатами и платформами. Однако важно отметить, что:

  • Многие пользователи чата очень скоро выходили из него.
  • Были пользователи, которые предпочли консервативное общение.
  • Некоторые пользователи могли и не знать о существовании эмодзи.

В целом, наши эмодзионеры отослали по крайней мере 753,000 эмодзи (или 600,000, если считать не общее количество эмодзи, а количество сообщений, в которых они появлялись) со средним значением 32 эмодзи для каждых 100 сообщений.

В целом, наши эмодзионеры показали коллективную грамотность, отослав около 800 самых разных эмодзи, то есть около 25% от полного списка. Я отобразил появление новых эмодзи с помощью D3.js, показав, что многие из них были впервые представлены в чате в период с июля 2015 года по июль 2016 года с темпом роста от 10 до 20 новых эмози в неделю.

В среднем один человек использовал около трех разных эмодзи. Такое число получилось потому, что были у нас и настоящие профессионалы эмодзи – так, один использовал около 500 различных эмодзи.

Нетипичные эмодзи в чате?

Чтобы лучше понять, как люди обменивались эмодзи в чате, я сравнил свои выводы с докладом, подготовленным SwiftKey в 2015 году. Эти данные немного устарели, поэтому я добавил данные unicod.org. Объединил их и вот что получилось.

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

Поскольку сравнения, основанные на категоризации высокого уровня, обычно слишком непонятные, я попробовал другое сравнение, сосредоточившись на 25 наиболее используемых эмодзи с 2015 по 2017 год, используя их подкатегории. Вместе эти 25 эмодзи составляли около 15% всех, отправленных в течение этого периода смайликов.

Список эмодзи и их подкатегорий показывает, что наши эмодзионеры все равно хорошо вписываются в типичную модель пользователя эмодзи. Широкое использование иконок категории «Позитивные лица» совпало с подкатегорией «Счастливые лица» SwiftKey.

То же самое было и с подкатегорией «Негативные лица», подобной категории «Печальные лица» SwiftKey. Немного обособленно было использование «: trollface:», которое является доступным значком в GitHub, и обычно оно связано со спам-сообщениями и вредительством, но также используется как шутка в чат-комнате freeCodeCamp. «Какашка» 💩 также была в числе 25 самых используемых эмодзи.

Наиболее часто используемые значки жестов в чате freeCodeCamp являются положительными, связанными с приветствием, поддержкой, доверием и признанием успеха. Еще одно отличие заключается в меньшем использовании значков, таких как «сердца» ♥️ или «поцелуи» 💋, что говорит о том, что поиск партнера не был главной целью этого чата. В чате находится обычно около 70-80% мужчин, что может объясняться тем, что они использовали иконки с оружием 🔫.

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

И награду получает…

В качестве бонуса я написал код с графиком, который показывает Топ-5 наиболее часто используемых эмодзи на freeCodeCamp. Что интересно, некоторые эмодзи набирают постепенно популярность, в то время как другие постепенно сдают позиции. Это очень похоже на «Тур де Франс». Сегодня эмодзи является самым востребованным, а завтра о нем забывают.

Итак, вот самый популярный смайлик:

Честно говоря, я не ожидал, что 😄 («: smile:») станет самым популярным эмодзи. Я думал, что им будет 😂 («: joy:») , учитывая, что Apple недавно назвала его самым популярным за 2017 год.

Следующие 8 эмодзи также появлялись в чате freeCodeCamp. Угадайте, как называется каждый из них.

Я использовал Python и Gitter API, чтобы получать сообщения из основной комнаты чата freeCodeCamp. Библиотеки Python, такие как мультипроцесс и эмодзи, использовались для преобразования данных.

Часть преобразований также требовала данных, доступных в интернете, для которых я сделал настраиваемые скребки, также с библиотеками Python (запросы, urllib, BeautifulSoup4).

Для анализа данных я использовал простой Python и некоторые панды. Визуализация была сделана с использованием matplotlib, а интерактивные графики — в D3.js.

Версии кода доступны в моем репозитории GitHub вместе с несколькими конечными наборами данных. Что касается необработанных наборов данных, используемых для этого проекта, они теперь доступны в Kaggle freeCodeCamp.

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

Обучение

Истории разработчиков, получивших первую работу после 30, 40 и 50 лет

Куинси Ларсон, преподаватель в freeCodeCamp, собрал более 300 историй разработчиков, которые доказывают, что начинать учиться программированию никогда не поздно.

Анна Гуляева

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

/

Почему я это сделал

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

Мне __ лет. Мне уже поздно учиться разработке?

Это один из самых распространенных вопросов в разработке в целом. Чтобы показать вам, сколько разработчиков волнует их возраст, я зашёл на Quora. Конечно, я нашел людей всех возрастов, которые переживают из-за того, что они «слишком старые», чтобы учиться программированию и становиться разработчиком: 60, 59585756555453, 52, 51504948474645444342414039383534333231, 29282726252423222120191817161514.

Что вы скажете кому-то, кто переживает, не слишком ли уже поздно? Многие люди ограничатся старой цитатой Уолта Диснея: «Если вы можете представить это, вы можете сделать это!»

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

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

Но как мне убедить всех этих людей, задающих этот вопрос каждый день? Просто говорить «не переставайте верить» — неэффективно.

Я собрал доказательства, чтобы убедить людей расслабиться по поводу возраста

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

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

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

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

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

Оказалось, что многие разработчики получили первую работу в 30, 40 или 50 лет. Вот несколько историй:

https://twitter.com/mikleane/status/949452946600730626?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F2215e9cee7ade93a7ffbf76c00f6702a%3FpostId%3D64306eb6bb27

https://twitter.com/americanwombat/status/949486088325799937?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Ff3305f7a1f903b59e7c4c9a9c6edd974%3FpostId%3D64306eb6bb27

https://twitter.com/jefflazerus/status/949457462939205632?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2Fc3053bd231b0056db2839f8c57f3828d%3FpostId%3D64306eb6bb27

https://twitter.com/peterdaily/status/949453856127307776?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F054d685fc2fed0e12bfc45634abf6296%3FpostId%3D64306eb6bb27

https://twitter.com/gillessew/status/950138976655912960?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F48799b09a4826507d15624371e46bf60%3FpostId%3D64306eb6bb27

https://twitter.com/amwcodes/status/949581047808716800?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F46ff7a793cd12eb3273696b47e4f17f3%3FpostId%3D64306eb6bb27

https://twitter.com/dbriesz/status/949483215256825856?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F5daccc8369b60bb9807d39e133237d74%3FpostId%3D64306eb6bb27

https://twitter.com/jessdelgrande/status/950163504773902342?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F700f10a61f7d7a18fd00ba8d9bc31ecf%3FpostId%3D64306eb6bb27

Я создал список из 300 разработчиков, которые начали после 30, чтобы показать, сколько людей начали переход к разработке ПО в более старшем возрасте. Я буду и дальше вести этот список. Поэтому, если вы разработчик, получивший первую работу после 30, твитните мне с хэштегом #DevAfter30, и я добавлю вас в список.

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

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

Новости

Интересные материалы: 18.01

Под конец дня – Unity 2018, приложение по доставке и огромное академическое исследование стоимости разработки игр.

Леонид Боголюбов

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

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

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

Мероприятия

Как я участвовал в хакатоне с 13 днями опыта в программировании

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

Анна Гуляева

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

/

Я даже не понял, что подал заявку на хакатон. Я услышал этот термин в подкасте CodeNewbie, когда кто-то делился своей историей. Из подкаста я запомнил рекомендацию стать частью сообщества. Поэтому, когда я увидел пост в группе freeCodeCamp Las Vegas о мероприятии StartUp Weekend, он привлек мое внимание.

Это мероприятие было посвящено созданию новых компаний через объединение предпринимателей, дизайнеров и разработчиков. Но, согласно моему аккаунту freeCodeCamp, я занимался программированием всего 13 дней. Я оставил комментарий под постом и спросил, могу ли я получить пользу от этого мероприятия, несмотря на нехватку знаний и опыта. Мне ответил Майк Зиетлоу и сказал, что я могу получить пользу, только мне нужно будет постараться. Поэтому я оставил заявку на то, что я сначала принял за митап.

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

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

Майк на питче своей идеи

Выбор команды

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

Поэтому я искал команду, в которой будут опытные разработчики. Так получилось, что Майк питчил идею создания сайта для связи предпринимателей и разработчиков из Лас-Вегаса. Пять разработчиков и два бизнес-аналитика вступили в эту команду, и так появилась Developers.Vegas.

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

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

Работа над проектом

Наконец пришло время работы над проектом. До этого мероприятия я писал код в браузерных редакторах в freeCodeCamp и CodePen. После общения с командой я скачал VS Code. Я понял, что не понимаю, как все это работает. Мне нужно было разобраться с git, концепцию которого я понял, но мне ещё многому предстояло научиться. В один момент я работал над master вместо своей ветки. Эта работа была довольно нервной. Я думал, что подведу всю команду. Но, к счастью, я ничего не разрушил.

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

Мне напомнили заходить в Google, как только я застряну. Это звучит несложно, но я думаю, здесь есть особая техника. Я должен был знать, что задаю верные вопросы и получаю нужные ответы. Потом я понял, что никто не хотел браться за работу, которую дали мне. Я пока слишком мало знаю, чтобы понять, почему все ненавидят CSS.

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

Итоги

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

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

В итоге мы заняли второе место! Я рад, что поучаствовал в этом событии. Хотя оно и прервало мою 13-дневную серию на freeCodeCamp, я бы сделал это снова.

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

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

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

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

Вакансии

Популярное

X

Спасибо!

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