В приложении 2ГИС теперь есть навигатор. Мы научились «ехать» по треку, озвучивать манёвры, автоматически перестраивать маршрут, рассчитывать время в пути, доводить пользователя до входа в здание или организацию, учитывая заборы и шлагбаумы, — и всё это в честном офлайне. Пробки (вот разве что для них нужен интернет), разведённые мосты и перекрытые улицы учитываем давно. Пока в нашем навигаторе — необходимый минимум. Чуть позже научим его предупреждать о слишком высокой скорости, лежачих полицейских и камерах ГИБДД, настроим ночной режим, сделаем маршруты по платным и грунтовым дорогам опциональными. Чтобы воспользоваться им, нужно обновить 2ГИС в своем смартфоне или скачать в AppStore или Windows Store. Для Android обновление выходит постепенно, начиная с 22 августа (будет доступно на всю аудиторию к сентябрю).

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

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

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

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

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.

Несколько дней назад David Demaree, главный по Typekit в Adobe, издал крутую книжку "git для людей". Чтобы привлечь к ней внимание, он опубликовал выжимку самой, на мой взгляд, интересной главы — как оформлять коммиты чтобы и волки были целы, и овцы сыты, и песец не пришел. А я за эти выходные подготовил выжимку из выжимки — сокращенный и адаптированный перевод, чтобы можно было быстро прочитать и добавить в копилку своего опыта самое ценное.

Итак, Вы готовы сделать свой великолепный коммит, который, безусловно, делает код чуточку лучше, либо фиксить какой-то баг, а может, Вы и вовсе решили поменять переходы строк на Windows/Unix-Style? Естественно, Ваш код безупречен и достоин всевозможных похвал! Браво! Достойно ли Ваше сообщение Ваших трудов? Смогут ли потомки разобрать, что Вы сделали через месяц? Через год? Десять лет?

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

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

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

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

О том, как можно использовать девайс было сказано мало, и об этом — в продолжении. Сразу скажу, что на kickstarter этот спектрометр уже собрал 1,3 миллиона долларов вместо 200 тысяч, и до конца сбора средств еще 33 дня.

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

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

Давайте начнем. Сначала о процессах.

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

В этом выпуске серии «5 вещей …», я представлю некоторые из тонких аспектов многопоточного программирования, в том числе synchronized-методы, volatile переменные и атомарные классы. Речь пойдет в особенности о том, как некоторые из этих конструкций взаимодействуют с JVM и Java-компилятором, и как различные взаимодействия могут повлиять на производительность приложений.

В последнее время тема удалённой работы стала особенно актуальной — достаточно вспомнить этот недавний пост на хабре, выход книги Remote от Джейсона Фрайда и приуроченный к запуску книги старт биржи поиска удалённых сотрудников от 37 Signals.
Сторонников у неё более чем достаточно, особенно среди работников, уставших изо дня в день добираться до офиса по сумасшедшим городским пробкам. Противников также немало и в первую очередь среди работодателей. Здесь я постараюсь объяснить, почему, несмотря на все минусы (многие из которых, к слову, либо временные, либо вымышленные), удалённая работа — это наше будущее, и будущее весьма близкое. Как человек из IT-индустрии, я конечно имею в виду в первую очередь её, но значительная часть этих наблюдений носит универсальный характер.
Сразу оговорюсь, я не хочу сказать, что работа в офисе уйдёт в небытие, она лишь превратится из единственного возможного способа в инструмент, решающий определённый спектр задач. Под катом список основных плюсов удалёнки для работника и работодателя, а в следующей части я постараюсь опровергнуть основные мифы, к которым часто апеллируют её противники.

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

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

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

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

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

Ужасно не люблю выражение «заставить себя». По моему убеждению, нельзя заставить себя — с собой можно только договориться. Ну, или обмануть — но это не лучший выход.
Итак, как договориться с собой сделать что-то, что совершенно явно не хочется делать? И настолько же явно необходимо.
Некоторое время назад я прочёл в блоге психолога Хайди Халворсон о трёх простых причинах, которые мешают нам что-то делать, и таких же (ну, почти) простых решениях этих проблем. И поскольку время показало, что решения (по крайней мере, мне) подходят — спешу поделиться ими.

Итак, почему же дедлайн близится, а решения всё нет?

Друзья, спасибо за такой большой интерес к нашему видео про троллинг, картины мира и прочие неконструктивные приемы коммуникаций (на текущий момент его посмотрели более 6,000 человек). Если вдуматься, то 24 мин. видео * 6,000 = 2,400 часов времени — надеемся, что это было для вас полезно.

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

P.S. Поскольку хабраопрос в предыдущей статье показал, что текст лучше чем видео, в этот раз есть и видео, и текст.

За те 6 лет, что я занимаюсь образовательными проектами по управлению людьми, довелось сделать интервью с десятками менеджеров и директоров. У нас были ТОР-менеджеры Лаборатории Касперского, Oracle, EPAM, Global Logic и других компаний — самые разные люди. И я понял, что до сих пор не сделал интервью с тем, с кем давно нужно было сделать — с моим коллегой SlavaPankratov.

А тут как раз и повод подоспел — три года с выхода “Черной книги менеджера” (18+, требуется регистрация), вероятно самой популярной и скандальной книги по менеджменту. Ровно три года назад Слава ее как раз и написал.

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

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

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

Спасибо за статью habrahabr.ru/post/191210! Хорошую тему подняли.

Поделюсь и своим опытом. Ниже — идентичное содержание и первой, и заключительной лекции в программе подготовки стажеров.

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

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

О программисте, как о решающем факторе, и о его мозге, как об основном инструменте, мы сейчас поговорим.

Эта статья — вольный перевод статьи «The hardest and easiest way to be a better coder» портала medium.com.
В ней выражена идея, которую обычно не принято озвучивать в индустрии разработки программ.
Эта идея о том, что программисты тоже люди. Но люди, живущие в культуре, отрицающей эмоции в общении.
Автор отличненько описывает нам важный путь развития. И это совсем не вкачивание технических навыков или GTD.

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом: