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

Доброго времени суток. Всем пользователям ElasticStack рано или поздно нужно визуализировать данные. Большинство использует Kibana. Под катом перевод официальной документации для версии 6.6.

Ссылка на оригинальный материал: Kibana User Guide [6.6] » Visualize

Содержание:

1. Creating a Visualization
2. Line, Area, and Bar charts

В этом году мы, как никогда раньше, основательно подходим к работе над программой AppsConf — конференции для разработчиков мобильных приложений. Во-первых, у нас большой и классный программный комитет. Серьезно, чтобы в итоге отобрать около 60 докладов, 20 крутых профессионалов во всех мыслимых областях мобильной разработки работают с заявками уже с апреля месяца. Через их руки (глаза и уши на созвонах) уже прошло более 70 докладов, на основе которых сформировались некоторые советы о том, что для выступления хорошо, а что — плохо.

Советы эти естественно не связаны именно с тематикой конференции, а относятся к любому выступлению от специалиста для специалистов.

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

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

Меня зовут Андрей Поляков, я руководитель группы документирования API и SDK в Яндексе. Сегодня я хотел бы поделиться с вами докладом, который я и моя коллега, старший разработчик документации Юлия Пивоварова, прочитали несколько недель назад на шестом Гипербатоне.


Светлана Каюшина, руководитель отдела документирования и локализации:
— Объемы программного кода в мире в последние годы сильно выросли, продолжают расти, и это влияет на работу технических писателей, которым приходит все больше задач на разработку программной документации и документирования кода. Мы не могли обойти стороной эту тему, посвятили ей целую секцию. Это три взаимосвязанных доклада, посвященных унификации разработки программной документации. Я приглашаю наших специалистов по документированию программных интерфейсов и библиотек Андрея Полякова и Юлию Пивоварову. Передаю им слово.

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

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

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

Пару месяцев назад на Хабре вышел обзор бесплатных нелинейных видеоредакторов, под которым быстро собрался тред из сотни комментариев. Некоторые из перечисленных инструментов относятся к профессиональным (Lightworks), другие — претендуют на звание бесплатной альтернативы профессиональным видеоредакторам (VSDC).

Штука в том, что определение «профессиональности» довольно расплывчатое, и какой именно при этом подразумевается функционал неясно. Захотелось выяснить, в чём же всё-таки хороши бесплатные аналоги, и можно ли ими заменить программы стоимостью в несколько десятков тысяч рублей. Забегая вперед, скажем, что получилась ситуация почти как по Гоголю:

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

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

В мире существует довольно много компаний, производящих такой класс вещей, как рюкзаки. Ещё больше существует самих рюкзаков: для ноутбуков, для фотоаппаратов, для фотоаппаратов и ноутбуков, для дронов, для активного отдыха, для лежания овощем и т.д — только у нас на сайте отобрано более 50 моделей (и это именно в наличии). Казалось бы, рассказывать о них на Geektimes нет никакого смысла, рюкзаки и рюкзаки. Но сегодня про один всё же расскажем, так как внимания гиков он заслуживает совершенно точно: это новый Bobby от голландской компании XD-Design.

Больше года я занимаю должность технического лидера в своей компании, и хочется поделиться наработками по теме. Имеет смысл уточнить: я веду отдел iOS-разработки из 10 человек в компании-аутсорсере. В моём случае должность подразумевает оптимизацию работы отдела, распределение задач между разработчиками и активности, связанные с программированием. Расскажу немного о своём опыте, наработках и умозаключениях. Статья может быть полезна прежде всего новичкам на аналогичной должности, либо тем, кто на неё метит. Какие-то практики и принципы могут быть переносимы на обычную разработку, на другие платформы или даже другие специальности.

Целью данной публикации не является полный анализ синхронизаторов из пакета java.util.concurrent. Пишу её, прежде всего, как справочник, который облегчит вхождение в тему и покажет возможности практического применения классов для синхронизации потоков (далее поток = thread).

В java.util.concurrent много различных классов, которые по функционалу можно поделить на группы: Concurrent Collections, Executors, Atomics и т.д. Одной из этих групп будет Synchronizers (синхронизаторы).



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

Предлагаю вашему вниманию перевод статьи Ian Lake Intercepting everything with CoordinatorLayout Behaviors.

Вы не продвинетесь далеко в изучении Android Design Support Library, не столкнувшись с CoordinatorLayout. Множество View из Design Library требуют CoordinatorLayout. Но почему? Сам по себе CoordinatorLayout делает не так уж и много, если использовать его с View, входящими в состав Android фреймворка, то он будет работать, как обычный FrameLayout. Так откуда берётся вся его магия? Вот где на сцену выходит CoordinatorLayout.Behavior. Подключив Behavior к дочерней View у CoordinatorLayout, вы сможете перехватывать касания, оконные вставки (window insets), изменения размеров и макета (measurement и layout), а также вложенную прокрутку. Design Library широко использует Behavior чтобы добавить силу большинству функционалу, которую вы видите.

Автор: Вячеслав Михайлов, Solutions Architect.

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

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

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

Многие студенты, впервые сталкиваясь с описанием какой-нибудь хитроумной штуки, вроде алгоритма Кнута – Морриса – Пратта или красно-чёрных деревьев, тут же задаются вопросами: «К чему такие сложности? И это, кроме авторов учебников, кому-нибудь нужно?». Лучший способ доказать пользу алгоритмов – это примеры из жизни. Причём, в идеале – конкретные примеры применения широко известных алгоритмов в современных, повсеместно используемых, программных продуктах.



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.

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

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

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

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема.  Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

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

Во время нарезки графики под приложения часто возникает множество сложностей: от разрешения устройств и проблемы с сетками и рекомендациями Google до непосредственно передачи приложения разработчику. За 2 года я работала над дизайном более 10 приложений, научилась находить решения самых разных проблем и делать так, чтобы в конечном итоге приложение выглядело так же, как и в дизайне.
Об этом и пойдет речь под катом.

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.