Connect with us

Разработка

Разработчик или инженер?

Джэни Клентон, iOS/Mac разработчик изливает душу о наболевшем: о утративших смысл сообществах программистов, о Swift, и о том, что её первым учителем программирования стал Иисус.

Ксения

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

/

     
     

Джэни Клентон, iOS/Mac разработчик, изливает душу о наболевшем: об утративших смысл сообществах программистов, о Swift, и о том, что её первым учителем программирования стал Иисус.

1c995f8

В прошлом месяце мой начальник, Дэниел Паско, разместил вот такой твит:

Разработчики сосредоточены на создании отличного кода.
Инженеры сосредоточены на создании отличных продуктов.

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

Хипстер-программирование

Никто туда больше не ходит. Там слишком много народу, – Йоги Берра

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

Потом я стала участником сообщества Ruby. Была знакома со многими людьми, которые вели там активную деятельность, и казалось, что язык перспективный.

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

Я мучилась с этим какое-то время, только чтобы потом узнать, что все, кто работал с Ruby, перешли на Clojure. А затем на Haskell. Возможно, что они заинтересовались еще и Swift, но потом я уже не могла уследить, какой язык был модным. Может быть Go…

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

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

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

У меня была отвертка, а все вокруг – шурупы

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

Он был сильно увлечен программированием и рассказал мне, что знание языка программирования – очень ценный навык. Он усадил меня в уголок с книгой и ноутбуком. Показал где Terminal и как писать код в TextEdit и компилировать его из командной строки.

Всё это выполнялось в Perl.

Книга, которую он дал мне, была та самая книга с ламой от O’Reilly года примерно 1998-го. Иисус сказал мне, что этот язык стабилен и не изменится, так что ничего страшного, если книга старая. Я начала рассказывать людям, что учу Perl, и встречала испуганные взгляды тех, кто говорил, что его больше никто не использует. Мне советовали учить PHP, потому что за ним будущее.

perl6book-parody

Я поговорила об этом с Иисусом и он ответил, что не стоит заморачиваться и учить PHP, потому что всё можно сделать и в Perl. Perl подходит для всего.

Замените «Perl» на «JavaScript» и получится в точности то, что происходит сейчас в сообществе программистов.

Я не собираюсь спорить о том, самостоятельный ли язык программирования JavaScript или нет. Это не то, о чем я веду речь. JavaScript это инструмент. У него есть свои области применения. Если я хочу написать веб-сайт, я не стану делать это в Swift с Cocoa фреймворками.

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

Недавно я читала о том, что состояние веб-разработки в данный момент статично. Большие компании, вроде Yahoo, в основном переписывают свои веб-сайты снова и снова, когда появляется новый JavaScript фреймворк.

Еще я прочитала, что кто-то создал фреймворк поверх JQuery, который уже является фреймворком поверх JavaScript. Наверное, пытался создать JavaScript фреймворк для выполнения работы серверного бэкенда. Это веб-язык! Он был предназначен для одной функции и только одной! Его так изуродовали просто потому, что кому-то лень учить новый.

Минутная слава

На ObjC пишут те, кто уже годами создает продукты с его использованием. На Swift пишут те, кто надеются на минутную славу.

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

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

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

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

Большая часть смысла сообщества испарилась. А тогда, когда у нас был Objective-C, люди вступали в сообщество, и опытные специалисты помогали им. Сейчас каждый выставляет себя экспертом и никто не хочет задавать вопросы, которые помогут им стать более опытными программистами в Swift. Их мнение тонет среди множества подобных, а новичкам становится еще труднее действительно начать учить Swift.

Что делать

Я год работала на Брэда Ларсона. Мы потратили это время на перенос унаследованного ПО из Objective-C в Swift. Вот две важные причины этого:

  1. Кодовая база была хрупкой и нельзя было ничего добавить и изменить в ней, не сломав.
  2. Проблемы, с которыми мы сталкивались годами, не случились бы, если бы мы написали кодовую базу в Swift.

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

После этого я вывела правильный вопрос: Какую проблему решает этот код?

Тогда он начал мне объяснять, как небезопасен был наш предыдущий код из-за ограниченности Objective-C. Он потратил годы на решение этой проблемы и понял, что именно нужно сделать.

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

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

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

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

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

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

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

Ксения
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

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

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

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

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

Лучшие материалы о разработке и маркетинге технологических продуктов.

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

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

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

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

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

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

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

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

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

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

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

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

Итого

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

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

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

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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