Не так давно Google купили Firebase и теперь на странице с описанием GCM нас встречает радостная новость о том, что пора бы мигрировать на Firebase.

...GCM users are strongly recommended to upgrade to FCM, in order to benefit from new FCM features today and in the future.

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

Нам понадобится:

• Android Studio
• Код демо-проекта с github
• 20 минут свободного времени

Статья-конспект по книге Роберта Мартина «Идеальный программист». После прочтения книги у меня поменялось отношение к программистической жизни. В книге рассматривается процесс написания кода, сам код, отношение к задачам, TDD и много других полезностей. Читать нужно разработчикам и менеджерам проектов. Частично применимо к дизайнерам.

Это вторая часть статьи по книге Роберта Мартина «Идеальный программист». В первой части статьи мы начали изучать, чем идеальный программист отличается от не идеального. Рассмотрели ответственность, научились говорить «нет» нереальным задачам и говорить «да» так, чтобы заказчик был, уверен, что всё будет готово вовремя. Мы определились, как писать код, принимать помощь и помогать другим. Продолжим.

UPD: в этом посте отражено субъективное мнение автора в 2016-ом году. Сейчас я работаю над своим проектом в сфере обучения облачным технологиям.

Мне не раз приходилось слышать: «Upwork — это же геморрой. Мне приходится тупо кликать мышкой, смотреть фильм на ноуте, чтобы побольше высидеть часов. Поэтому я ушел на XYZ...». Вот этот тезис, личные проблемы с продуктивностью, а также немалое количество self-help книг, побудили меня написать этот пост. Вся моя IT-карьера, связана с Upwork (который был oDesk). Это немного-немало 10,000+ часов работы, 10+ лет проведенных в этой системе, с короткими перерывами.

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

Привет! Последние несколько лет я занимался фрилансом на Upwork (бывший oDesk) и вот наконец решился поделиться своим опытом и наблюдениями с Хабрасообществом в небольшом цикле статей. Начать хотелось бы издалека: кому на мой взгляд стоит рассмотреть фриланс как основной вид своей деятельности + хотелось бы разобрать основные «отпугивающие» факторы, которые мешают многим решиться. Кому небезразлична тема фриланса и Upwork в частности — добро пожаловать под кат.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

Введение

Меня заинтересовал данный фреймворк для сбора информации с сайтов. Здесь были публикации по Scrapy, но поскольку детальной информации на русском языке мало, то я хотел бы рассказать о своем опыте.

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

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

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

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

Почти 4 года назад мы написали одну из самых популярных статей в рунете про проектирование больших проектов с таким же названием, как и эта: часть 1 и часть 2. Только на Хабре её прочитало более 170 тыс. человек, а вообще она публиковалась в самых разных изданиях мира. Более 1000 стартапов использовали наработки из этой статьи для проектирования, и это только те, о которых я слышал и которые нам писали. Но время не стоит на месте, а мы постоянно развиваемся. С тех пор наша технология проектирования значительно эволюционировала и стала еще лучше. В этой статье мы опишем нашу обновленную технологию проектирования и покажем много живых примеров для каждой стадии.

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

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

Динамический прототип

Рис. 9. Демонстрация динамического прототипа для проекта «Маркетплейс».

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