0
КОРПБЛОГИ

Катерина Старостина, HRM Anahorеt

31 марта 2018 года - именно в этот день компания Anahorеt и ее друзья-энтузиасты из Anadea и Евгений Зайцев (Senior Developer Monterosa), запустили нужный и долгожданный формат мероприятий для ИТ Минска и его окрестностей в виде codecamp или workshop под ласковым домашним названием «Тупичок программиста».

Никакого бла-бла (ну почти), только практика, только чистый profit. Во время занятий предполагается много кода, экспериментирования, хлопанья себя по лбу, тупления над очевидными вещами, озарений, набитых шишек и прочих эффектов творческо-познавательного процесса.

И начали мы с React Native, не потому что тренд, а для того чтобы разобраться и докопаться до сути!

Хроники “Тупичка”

На первой встрече “Тупичка” разработчики освежили в памяти базовые принципы React Native. Создали и сконфигурировали проект на основе creat-react-native-app. Разобрались в нюансах разработки под мобильные девайсы, а также поработали с Expo. Им удалось настроить окружение для создания в приложении списка ивентов, отобразить список ивентов полученных с сервера по API. А также разобрать нюансы роутинга библиотеки react-navigation и применить первичные стили с помощью библиотеки styled-components.
P.S.А некоторые даже смогли настроить дополнительный роутер :D

Совсем «новички» в React Native не успели закончить  работу непосредственно на ивенте, поэтому им пришлось потрудиться дома, и они - справились :) Потому к следующему занятию все пришли в боевой готовности.

На второй встрече 21 апреля участники смогли навести красоту в приложении, которое было начато ранее, разобрались со стилями, а также на практических примерах обсудили отличие стилей от веба, что принимает styles, что делает StyleSheet.create, убедились в странности флекса. Еще Евгений очень красочно рассказал о том,  почему отдает предпочтение styled-components. В конце занятия удалось обратиться к анимациям.
Несмотря на то, что работа на Тупичке командная, каждый участник смог проявить индивидуальность, и сделать свой проект таким,  каким видит его, а тем у кого совсем мало опыта, ментор предложил реализовать пример его «собственного сочинения»)

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

И это далеко не все планы, впереди нас ждет много продуктивных встреч и по другим технологиям в том числе

P.S.: «Тупичок программиста» - это проект, аналогов которого в Минске еще не было!) Приходите, прокачайте свои скилы до самого высшего Levela.

0
КОРПБЛОГИ

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

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

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

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

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

1. Мечтать не вредно: составляем портрет идеального сотрудника

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

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

2. Материализация мечты: описываем вакансию

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

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

Распространенные ошибки, с которыми  можно столкнуться на этом этапе:

Технические требования написаны «на отцепись». Это бывает, когда HR или рекрутер думает, что он и так все знает, и сам пишет технические требования, еще хуже – копирует из аналогичной вакансии другой компании. Не удивляйтесь – такое бывает. Стоп! Все требования по функционалу должен писать или согласовывать эксперт в предметной области. Чем подробнее описана вакансия, тем выше шанс получить нужного специалиста.

Специалист, составляющий текст вакансии, не до конца понимает, какими личностными качествами должен обладать кандидат. Неопределенность в этом вопросе в дальнейшем грозит сложностями адаптации в коллективе и не только. Простой пример: вы в компании строите корпоративную культуру достижений, которая направлена на технологический прорыв, на интенсивный качественный и количественный рост. Это построение от сотрудников требует высокого уровня мотивации достижений, ориентации на результат и умеренного риска. А при подборе вы отдаете предпочтение кандидатам, чья мотивация – избегание наказания/неудач, ведь они такие «неконфликтные и удобные». Получите ли вы от таких сотрудников отдачу, на которую рассчитываете? Нет! Ведь вся их энергия направлена не на проявление инициативы или поиск наиболее эффективных решений, а на то, чтобы не получить нагоняй от руководителя. В тексте вакансии, например, может быть написано про: любовь к решению нетипичных задач; умение работать в проекте с ограниченными ресурсами и т.п.

Итак, вакансия составлена: вы довольны, слова отражают суть, и значит – можно приступать к поиску.

3. Выхожу тебя искать: разнообразим каналы поиска

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

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

друзья-знакомые-сотрудники, которые могут порекомендовать такого человека, а также специализированные рекрутинговые агентства;

специальные пакетные предложения от job-сайтов;

поиск в социальных сетях по специально настроенным параметрам;

поиск в специализированных группах и сообществах – Telegram, FB, LinkedIn;

анализ списков спикеров и гостей конференций, хакатонов и т.п. (можно и самим провести мероприятие, которое привлечет внимание нужных вам специалистов).

4. Не сдерживаем творческие порывы: устанавливаем контакт с кандидатами

Теперь важно определить наиболее подходящих кандидатов, найти их контакты и наладить общение. Не ограничивайте себя шаблонами «так не принято», «так никто не делает», «так никто не пишет» и т.п. Речь не о том, чтобы высылать кандидату «фото в купальнике», а о том, чтобы не писать стандартные скучные письма, использовать каналы коммуникации, не только LinkedIn и электронную почту (ее мало используют кандидаты 20-25 лет).

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

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

5. А поговорить? Проводим собеседования

У вас сформирован список кандидатов, которые готовы к интервью. Начинается самое интересное: проверка кандидата на соответствие ожиданиям компании. Цель этого этапа – создать такие условия, чтобы кандидат раскрылся, рассказал о себе, и вы смогли провести полный аудит его профессиональных и личностных качеств. Хороший инструмент – открытые «рассуждательные» вопросы. Это вопросы, на которые нельзя ответить однозначно «да» или «нет», те, которые предполагают рассуждение на определенную тему, например: «Вы сказали, что в проекте использовали Х, расскажите, как пришли к такому решению? Между какими способами решениями выбирали? Почему?»

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

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

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

Для эффективного рекрутинга важно построить систему, которая бесперебойно работает на вас. Одна из мощных опор этой системы – репутация компании внутри и на рынке труда. Если с репутацией за пределами компании все хорошо, кандидаты с большой долей вероятности откликнутся на объявление о вакансии и/или примут приглашение пройти техническое интервью, а затем и оффер. Позитивная репутация внутри организации позволяет получать поток хороших кандидатов по рекомендации сотрудников. Ведь компанию, которая тебе не нравится, не порекомендуешь. И не приведешь «в дом» того, за кого впоследствии будешь испытывать неловкость.

0
КОРПБЛОГИ

Stanislav Sinitsky
January 4, 2017

В игровой индустрии существует своеобразная шутка: если хочешь несколько раз заработать на одной игре, делай порт. Посмотрите, например, на компанию Rockstar: в 2013-м году Grand Theft Auto V штурмовала консоли, продажи составляли миллионы проданных копий и миллиарды долларов. Когда ажиотаж поутих, игру запустили на персональных компьютерах, добавив несколько обновлений - вуаля, GTA V снова лидирует на рынке!

Сказать, что есть нечто нечестное или плохое в данном подходе язык не повернётся, так как в итоге выигрывают все: и компания разработчиков, и пользователи сразу на всех платформах, и собственно производители платформ, ведь не все настолько терпеливы, чтобы ждать два года, пока остальной мир режется в любимую игру. А терпеливым придётся апгрейдить ПК, так как порт обзавёлся 4к-текстурами и модными визуальными эффектами. Не побоюсь сказать, что данная бизнес-модель гениальна, так как Rockstar заработали везде, где только могли. И что тут сказать: всем предпринимателям стоит у них учиться вести дела.

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

Расширьте свою аудиторию

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

К примеру, в США, Австралии и Канаде Android менее популярен, нежели iOS. Обратная ситуация наблюдается в Китае, Южной Корее, Японии, Мексике, Индии, Бразилии и так далее. Задумайтесь, сколь огромен этот рынок. Вы сможете не то, что удвоить - утроить свою аудиторию. Согласно данным IDC, Android доминирует на рынке смартфонов - 87,6% продаж смартфонов приходится именно на устройства с операционной системой Google, в то время как Apple довольствуется вполне скромными 11,7%:

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

Раньше основным аргументом избегать Android был факт того, что пользователи iOS охотнее покупают приложения в магазине Apple, в то время как Android-хэды чаще довольствуются бесплатным ассортиментом программ из Google Play. С выходом 6-й версии Android ситуация несколько изменилась - люди стали охотнее покупать софт. Бесплатные приложения стали представлять из себя переполненные рекламой демо-версии, в то время как платный продукт блещет чистотой и опрятностью. Более того, всё больше появляется уникальных и интересных приложений, приобрести которые можно только за деньги. Среди них и порты с iOS. К тому же, помимо платного приложения вы можете сделать и бесплатную версию, на которой сможете заработать на рекламе.

Разработка под Android стала легче

...и дешевле

Если раньше фрагментацию Android так же, как и Волан-де-Морта, не называли вслух, заменяя на "сам-знаешь-что", то теперь эта вещь перестала быть столь ужасной. Разработчиков пугало разнообразие различных разрешений дисплеев и используемых версий операционной системы. Однако Google давно решили эту проблему, выведя основные функции Android и API из операционной системы в Сервисы Google Play, которые распространяются на версии Android от 2.3 и вплоть до самой последней. Больше дизайнерам не нужно страдать, вырисовывая иконки для всех версий операционной системы и дюжины разрешений - можно смело портировать приложение.

Решение этих проблем так же сказалось и на ценовой политике разработки нативного приложения для Android. Теперь это стоит примерно столько же, сколько и разработка для iOS. Более того, в последних версиях устройств количество разрешений значительно сократилось, сделав ставку на большой экран. Поэтому строить ресурсоёмкое приложение будет дешевле хотя бы потому, что старым устройствам просто не хватит мощности запустить его, а потому нет смысла делать версию для Android 2.3 или 4.0.

Добавьте уникальности

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

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

0
КОРПБЛОГИ


Stanislav Sinitsky
December 14, 2016

Придумать хорошее название для продукта - одна из самых трудных частей разработки. Имя значит многое, оно способно предопределить всю дальнейшую судьбу вашего приложения. Вспомнить хотя бы песню Джонни Кэша "A Boy Named Sue", где женское имя превратило жизнь мужчины в сущий ад, несмотря на то, что сам по себе Сью был отличным парнем. Такая история может приключиться и с вашим приложением, пусть даже высочайшего качества - глупое, слишком сложное, невзрачное или несоответствующее имя запросто способно похоронить его на просторах глобальной сети.

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

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

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

Давайте рассмотрим несколько важных моментов в выборе названия.

1. Название должно привлекать внимание. 
Хорошее название само по себе способно заинтриговать и заставить пользователя больше узнать о продукте. К примеру, многих зацепило название "50 оттенков серого". Правда, от него больше веет мыслями о размытых рамках добра и зла и многим хотелось размышлений на эту тему, а не того, что мы получили в итоге. Из удачных примеров стоит вспомнить Viber: название расшифровывается как "вещь, создающая компанейскую атмосферу". Сразу становится интересно, что это, а внутри оказывается ещё и прекрасная замена Skype, мобильным операторам и прочим средствам связи.

2. Название должно быть информативным. 
Prisma. "Давайте взглянем сквозь призму", "изображение словно пропустили через призму" - можно вспомнить десятки подобных фраз. Теперь же к абстрактному смыслу добавился и вполне конкретный - художественная обработка фотографий через Prisma. Пожалуй, лучше названия для этого приложения и не придумаешь.

3. Название должно быть коротким и легко произносимым. 
AppStore ограничил длину названий до 75 символов, но даже если не брать это в расчёт, давайте задумаемся, как люди будут друг другу рассказывать о "чате с исчезающими сообщениями, стикерами, новостями, стилизованными под ТВ, масками, смайлами и возможностью записывать видео, iOS, Android, Windows Mobile бесплатно без регистрации и смс"? Сказать или написать "ты слышал о Snapchat?" куда проще.

4. Название должно быть интуитивно понятным. 
Если у вас каждый раз переспрашивают, о чём ваше приложение, после того, как вы назвали его, то название выбрано не самое удачное. Конечно, оно не должно в точности описывать функционал или кричать о своём стиле, но дать некое представление пользователю было бы неплохо. Facebook: книга лиц, первая ассоциация - фотоальбом. Направление мысли такое название социальной сети даёт верное. А вот SPSeed ни о чём не говорит.

5. Название должно запоминаться. 
Самая сложная часть и высший пилотаж в искусстве давать вещам названия. Ведь одно дело просто привлечь внимание, совсем другое - запомниться на долгие годы. Все прекрасно знают и помнят Instagram благодаря оригинальному слову. Кто знает, что было бы, если создатели оставили оригинальное Instant Telegram?

Конечно, ваше приложение может запомниться блестящим функционалом или дизайном и, скажете вы, пользователи со временем просто выучат название и будут ассоциировать его с контентом. Это не совсем так. Наверняка, хотя бы раз в жизни у вас бывали ситуации в духе: "прекрасная песня, какая группа её поёт?", или "из какой книги эта великолепная сцена?", или "Джек Николсон мастерски изобразил детектива, но как назывался фильм?". И это случается даже с классическими, общеизвестными вещами, многие из которых даже изучались в школе! Хорошее и оригинальное название не позволит вашему детищу быть забытым.

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

0
КОРПБЛОГИ


Stanislav Sinitsky, Alexander Mikhalchenko
December 7, 2016

15 февраля 2016 года компания JetBrains выпустила версию 1.0 языка Kotlin, находившегося в разработке около пяти лет. Работает этот язык поверх JVM. Что такое Java, мы уже рассмотрели в отдельной статье с Александром Михальченко. Сегодня мы снова собрались с ним, на этот раз для разговора о Kotlin - о том, чем хорош этот язык и чем плох, как для разработчиков, так и для предпринимателей.

Привет, Саш.
И тебе привет.

Итак, что, собственно, такое Kotlin?
Язык программирования, разработанный компанией JetBrains, работающий на платформе Java. Он использует JDK, как и сама Java, но имеет другой синтаксис. Решение не ново - уже существуют языки, которые так делают: Scala и Closure, например. Появились они, в основном, из-за проблем с самой Java в плане синтаксиса. То есть, Java - язык надежный, хороший, добротный, на нём можно писать серверные приложения, но синтаксис у него, скажем так, излишне многословный. Дело в том, что разработчики Java довольно инертно её дорабатывают. Они стараются по максимуму поддерживать обратную совместимость и считают, что у пользователей, перешедших на новую версию, должен работать код, написанный ещё в 95-м. У них даже лозунг такой: "написанное однажды работает везде". Это, конечно, больше про кроссплатформенность…

...но они решили копнуть глубже?
Да - написано на одной версии, будет работать на всех следующих.

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

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

От чего же избавился Kotlin?
Kotlin и другие JVM-языки помогли разработчикам писать программы с меньшим количеством кода. Помимо всего того, что есть в Java, они добавляют вещи из мира функционального программирования. Это значительно облегчает написание кода - делает его короче и выразительнее. Чем меньше кода мы пишем, тем меньше кода нужно поддерживать, писать меньше тестов. Собственно, большинство языков появилось по этой самой причине - поменять синтаксис Java, сделать его более удобным, более прагматичным.

Насколько сейчас актуален этот язык?
Сейчас он не то, чтобы слишком популярен - язык молодой, сообщество ещё не набралось. По причине своей молодости Kotlin ещё не в силах конкурировать с той же Scala - более мощным языком с длинной историей. Там уже и над ошибками поработали, и добавили кучу интересных вещей, а Kotlin это только предстоит. В этом более зрелые языки пока что его переигрывают. Но тем не менее, амбиций Kotlin не занимать: язык разрабатывали пять лет, разработчики старались сделать его как можно прагматичнее и не допустить ошибок, которые есть в Java, чтобы "написано однажды" не было высечено в камне и язык можно было развивать. Обещают много интересных фич в будущем, которые в том числе покроют функциональность, имеющуюся на данный момент в Scala.

Как и Java, Kotlin лучше подойдёт большим проектам?
Да. По синтаксису, его можно использовать просто как дополнение к Java. Берём стек Java, к примеру, для серверных приложений, и просто заменяем Java на Kotlin. Всё будет работать, при этом, писать код станет проще. Вопрос заключается лишь в том, что выбрать вместо Java. На сегодняшний день, думаю, многие разработчики всё же остановятся на Scala.

А тебе что больше по душе - Kotlin или Scala?
Мне нравятся оба языка. Думаю, что Kotlin дальше пойдёт в плане Android. Есть, конечно, возможность писать Android-приложения на Scala, но там есть проблема: большой runtime. Она за собой тащит кучу библиотек, из-за чего увеличивается размер apk-файла. У Kotlin же самый маленький runtime среди всех остальных языков (кроме Java). Обычно это Java плюс "что-то", и это "что-то" - это overhead, который за собой язык тащит. У Kotlin он самый маленький - около 700 кб, в то время как у Scala - несколько мегабайт.

Какие недостатки у Kotlin?
Сам я пока что не натыкался ни на какие баги, с компилятором или чем-то другим у меня проблем тоже не было. По поводу синтаксиса - он справлялся с задачами, с которыми я сталкивался. В чём он уступает той же Scala - это в работе с многопоточностью. Java, к слову, тоже в этом проигрывает. У Scala есть future API, которая позволяет выполнять асинхронные задачи в несколько потоков и при этом получается нормальный код вместо мешанины, где разные секции работают в разных потоках и при этом не видна их связь. Scala всё это структурирует средствами своего синтаксиса. В Kotlin что-то такое обещали реализовать в версии 1.1. Но в целом, мне нравится работать на Kotlin из-за его добротного синтаксиса.

Что скажешь насчёт безопасности Kotlin?
Тут вот в чём дело: весь код, написанный на Kotlin, в дальнейшем преобразуется в Java-код. Своего он ничего не добавляет. Соответственно, насколько безопасна Java, настолько безопасен и Kotlin. Если мы говорим о безопасности написания кода, то мне очень нравится null safety в Kotlin. Компилятор может предупредить программиста о том, что ссылка может быть пустой. Если мы попробуем с ней что-то сделать, произойдет ошибка на этапе компиляции. В Java же приложение просто упадет на этапе выполнения.

Что Kotlin может предложить бизнесу? Чем он заинтересует бизнесменов?
Если сравнивать с Java то разработка на Kotlin обойдётся дешевле. Почему? Нужно писать меньше кода и меньше кода поддерживать. Это значит, что код писать проще, а следовательно, приложение будет разрабатываться быстрее. А как известно, время - это деньги.

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

Спасибо большое за интервью, Саш. Было интересно!
Всегда рад.

Итого

По сути, прямое назначение Kotlin - облегчить жизнь программистов, дать им возможность уместить в одну строчку кода то, что в Java заняло бы пять. Как сказал Александр, по ощущениям это сродни смене старого Ford Focus на новенький BMW M3 - когда почувствуешь этот полёт, на старые колёса не захочется возвращаться.

Несомненным преимуществом является полная совместимость с Java, в том числе и обратная. Все библиотеки для Java будут работать на Kotlin и наоборот. Также этот язык открывает прелести тех же Closure и Scala для Android-разработчиков. Порадуются и предприниматели, ведь теперь проекты будут делаться быстрее и дешевле.

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

 

0
КОРПБЛОГИ

Stanislav Sinitsky, Mikhail Bilenko
December 23, 2016

"Час от часу не легче" - так в двух словах можно охарактеризовать гонку трендов в веб-дизайне. Современный дизайн развивается не просто спешно - стихийно, пытаясь угнаться за гонкой технологий. Появились смартфоны и планшеты? Что ж, придётся в первую очередь ориентироваться на них. Прости, десктоп. Гаджеты стали мощнее и вместительнее? Тогда давайте вставлять больше видео, анимаций и интерактивных элементов. VR-устройства? Что ж, давайте рисовать дизайн для них. И нет, десктоп, не смотри такими печальными глазами - тон и моду сейчас задаёт iPhone и Cardboard от Google. Тебе, дружище, придется или подстраиваться, или идти на пенсию. Вон, Microsoft тебе даже новый Windows сделали таким же, как на смартфонах.

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

Гамбургер остаётся в прошлом

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

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

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

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

Телевидение как источник вдохновения

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

Например, раздел новостей Snapchat. 16 крупных медиапорталов, такие как BBC, MTV, IGN, National Geographic, VOX и другие публикуют контент в виде снэпов. То есть, у какой-то новости или статьи есть обложка-анонс, аналогичная рекламному анонсу на ТВ, с живыми кадрами и заголовками, а уже за этой обложкой скрывается или статья, или видео.

Переход от статики к анимации - весьма обширная тенденция. Всё больше появляется сайтов с фоновыми видео, гифки и анимации встречаются чаще обычных картинок. Видеозация интернета происходит всё стремительнее, и вскоре видео само будет включаться на страницах (к примеру, как в ленте Instagram). Люди будут чаще видеть кнопку pause, нежели кнопку play, если, конечно, таковая останется.

Дизайн для VR-устройств

Говоря о тенденциях 2017 года, не получится не упомянуть виртуальную реальность. Она понемногу проникает во все сферы деятельности человека, готовясь стать столь привычным гаджетом, как будильник или мессенджер.

Интернет - не исключение. Появится ещё больше сайтов и ещё больше приложений виртуальной реальности, и все они будут нуждаться в удобном, дружественном к пользователю дизайне. К примеру, не так давно появились 360-градусные видео на YouTube. Вполне вероятно, что вскоре YouTube обзаведётся отдельным VR-сегментом, где пользователь сможет переключаться между видео и совершать прочие привычные действия, не снимая шлема виртуальной реальности. Всевозможные стриминговые сервисы с 360-градусной камерой, риэлтерские агентства с возможностью осмотра потенциального жилья в виртуальной реальности и многие другие сервисы будут нуждаться в дизайне, благодаря которому пользователь сможет получить 100% функционала сайта или приложения без необходимости каждый раз снимать или надевать шлем.

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

Отход от плоского дизайна

Плоский дизайн набирал популярность в 2010-2011 годах, в 2014-м он стал новым дизайнерским стандартом. Это было три года назад (три года, Карл!). Он никак уже не может быть законодателем мод - пользователи слишком привыкли к нему. Поэтому градиенты постепенно возвращаются в моду - и возвращаются в более изящном и утончённом виде. Только взгляните на эти сайты - вы сами всё поймёте: colemansmith.ca, lighthousebrewing.com, stripe.com.

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

Десктоп мёртв

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

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

Тактильная обратная связь

Современный дизайн стремится придать объём контенту не только за счёт виртуальной реальности, но и при помощи тактильных ощущений. Растущая мощность мобильных устройств позволяет по-новому задействовать виброотклик.

Помимо виртуальной клавиатуры, эту технологию можно применять и на веб-сайтах, создавая разнообразные приятные тактильные ощущения при помощи тонких вибросигналов. Таким образом получится создать новый пользовательский опыт, придать веб-странице объём и индивидуальность, увеличить посещаемость сайта и его аудиторию. Также можно и манипулировать действиями пользователя - заманить тактильными ощущениями к кнопкам "buy now", "share" или "subscribe".

Заключение

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

0
КОРПБЛОГИ

 


Валерий Коренков
August 10, 2016

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

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

Так же случилось и с Google Maps: вместо поисков gem'ов, я начал с изучения документации на сайте, о чём сейчас нисколько не жалею. Выяснилось, что ничего особо сложного в интеграции Google Maps API нет.

Геокодирование

Прежде, чем перейти непосредственно к интеграции Google Maps, стоит упомянуть такую вещь, как Геокодирование (Geocoding).

Согласно определению с сайта Google, геокодирование это процесс преобразования адресов (наподобие "1600 Amphitheatre Parkway, Mountain View, CA") в географические координаты в формате latitude: 37.423021; longitude: -122.083739 (широта и долгота соответственно, доли градусов десятичные, без минут и секунд, северная или южная, западная или восточная определяются знаком).

Эти координаты можно использовать для расстановки маркеров или для позиционирования карты.

Для Rails существует отличный gem – Geocoder, который берёт на себя вопросы, связанные с геокодированием. Настраивать его очень просто: достаточно после установки добавить в таблицу, содержащую адреса, поля latitude:float и longitude:float, указать в модели:

и при сохранении записи координаты будут обновляться.

Кроме того, у Geocoder'a есть ещё несколько замечательных "географических" возможностей, вроде поиска каких-либо объектов в окрестностях указанного места.

Статические карты

Google предоставляет работу с картами двух видов – статическими и динамическими.

Казалось бы, область применения статических карт нулевая, ведь динамические намного более привлекательны и функциональны, однако есть два аргумента за использование статических карт:

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

API статических карт очень простой – HTTP запрос с параметрами возвращает цельное изображение. Всё. С полученным изображением можно делать всё, что угодно. Не стоит, разумеется, обрезать копирайт Google или делать что-нибудь подобное.

На этом примере можно увидеть знакомое многим нашим сотрудникам место - офис Анадеи в Днепре:

На этом – оно же, но немного поближе:

И снова оно же, только в виде фото (это тоже один из сервисов Google Maps – Street View):

Очевидно, что вся интеграция статических карт в первом приближении состоит в написании одного метода одного хелпера, что-то вроде:

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

Это, собственно, всё, что касается интеграции статических карт.

Встраиваемые карты

API встраиваемых карт очень похож на API статических.

При помощи всего лишь одного HTTP-запроса можно легко добавить интерактивную карту в приложение. Её можно встроить разместив на странице iframe и указав URL-адрес Google Maps Embed API в качестве атрибута src:

<iframe width="300" height="300" frameborder="0" style="border:0" src="https://www.google.com/maps/embed/v1/place?key=YOUR_API_KEY&q=ADDRESS_OR_COORDINATES" allowfullscreen> </iframe>

Таким образом можно очень легко и очень быстро получить базовую функциональность Google Maps.

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

Дополнительную информацию о встраиваемых картах можно найти здесь.

Динамические карты (JS)

Всё по-прежнему просто!

Первое, что нужно сделать, это подключить Google Maps Scripts при помощи тэга <script>:

Второе: добавить на страницу div c идентификатором, например, map. По этому идентификатору JS-скрипты будут определять, где именно рисовать карту.

Третье, начинать изучать Google Maps Guide и добавлять возможности к интерактивной карте.

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

Ниже приведён код на CoffeeScript для реализации требуемого функционала.

Сначала созданием класс, реализующий необходимые процедуры работы с картой:

Всё уже не так просто, но все ещё понятно, не так ли?

Rails gem'ы и JS плагины

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

Что ж, существует пара gem'ов, пытающихся в этом помочь.

Первый и наиболее популярный – Google-Maps-for-Rails. Откровенно говоря, этот gem очень напоминает знаменитую "Кашу из топора". В роли топора выступает сам gem, в роли крупы, масла, соли – все те кусочки JS-кода, которые всё равно придётся писать руками, чтобы добавить и кастомизировать карту.

Другое дело – gem GoogleMaps, который, кстати, на удивление нелегко найти. Здесь всё рельсовое, добавление всех основных JS-скриптов берёт на себя сам gem. Но и он не без недостатков.

Сложности с подобным подходом начинаются, когда появляется необходимость в интерактивном изменении карт. Без JS-скриптов здесь не обойтись, что сильно понижает ценность попыток оформления подобного функционала в виде gem'ов.

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

Что касается JS-плагинов, подавляющее большинство просмотренных бесплатных вариантов сводятся к одному - JS-код, скопированный с Google Maps Guide, иногда немного реорганизованный.

Список плагинов, которые произвели наиболее приятное впечатление:

gmap3,
Maplace.Js,
gmaps.js.

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

К минусам как gem'ов, так и плагинов можно отнести необходимость построения логики приложения, опираясь на их синтаксис и этот синтаксис предварительно надо изучить. В случае изменения GoogleMap API (а подобное случалось), при отсутствии поддержки gem'а разработчиком (и такое случалось), это может привести к печальным последствиям.

Заключение

Интеграция статических и встраиваемых карт - вопрос написания одного метода. В поисках "готовых решений" просто нет смысла.

Интеграция динамических карт сложнее, но не настолько, чтобы не попробовать сделать это "с нуля", так как:

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

И да, написанный код может быть легко использован в новом проекте или даже вынесен в свой родной плагин. А следовательно, кто знает, возможно, в будущем появится статья о вашем готовом решении!

Страницы:
© 2008–2021 ЗАО «Дев Бай Медиа»
Перепечатка материалов dev.by возможна только с письменного разрешения редакции.
При цитировании обязательна прямая гиперссылка на соответствующие материалы. Пишите на [email protected].