В предыдущей подборке самых полезных материалов про визу O-1 много спрашивали про релокейт в Европу. Я целый день копал рунет и накопал полезное про релокейт не только в Европу, но почти куда угодно: Азию, Латинскую Америку, Австралию, Ближний Восток, Африку, Китай и даже… в Россию. Всего про 49 стран.

Недавний (пару недель назад) опрос 2423 ИТишников (50% Senior, 30% Middle, 10% Junior):

• 23% в ближайшие 5 лет точно уеду (563)
• 18% уже уехал (443)
• 37% колеблюсь (900)
• 21% не собираюсь уезжать в принципе (517)

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

В конце поста — опрос.

(Если у вас есть полезные ссылки на «личный опыт» по релокейту, который вам понравился, делитесь, буду признателен.)

Если вы отслеживаете множество событий и то и дело добавляете новые, вам приходится выполнять серию одних и тех же операций:

1. Повесить событие на сайте.
2. Создать в GTM триггер.
3. Создать в GTM тэг отправки события в Google Analytics.
4. Создать в GTM тэг отправки события в Яндекс Метрику.
5. Если у вас собираются данные для ретаргетинга в Facebook и VK, то для каждого из них нужно создать в GTM еще по тэгу.

При этом количество сущностей в GTM растет и ориентироваться в них становится всё утомительней. (А еще GTM не резиновый и допустимое количество сущностей ограничено.)

Я придумал и внедрил решение, которое позволяет:

• сократить рутину, избавляя от шагов 2-5;
• не плодить тэги;
• упростить управление событиями.

Нужно только один раз настроить несколько сущностей в GTM и больше вообще его не трогать при добавлении новых событий! Подробности по порядку.

Привет, читатель!

Меня зовут Артём Сайгин, я веду телеграм-канал Growth Lab, в котором делюсь опытом роста IT-продуктов.

В сети много статей по веб-аналитике, но найти действительно стоящие и последовательно сгруппированные материалы нелегко.

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



Отмечу, что список материалов будет пополняться.

Если я не добавил стоящий материал, свяжитесь со мной — добавлю.

Приступим!

Введение в веб-аналитику

Что такое веб-аналитика и зачем она вам нужна?
Подробное руководство по аналитике веб-трафика
Какие бывают источники трафика
Какие ошибки возникают при работе с Google Analytics и как с ними бороться
Как настраивать представления в Google Analytics — подробное руководство
18 метрик и KPI интернет-маркетинга, которые вы должны знать
Основные термины в веб-аналитике
Что такое UTM-метки и как их применять
Глоссарий: базовые понятия веб-аналитики
Что такое ROI и какие нюансы следует учитывать при его расчете
Модели атрибуции — подробный обзор и сравнение
Модели атрибуции от Google
Что такое A/A тестирование, и как его провести
6 советов начинающему веб-аналитику

На первом в истории полностью виртуальном мероприятии РИТ++, прошедшем в конце мая, инженер Qrator Labs — Георгий Тарасов, рассказал публике про веб-скрейпинг, он же парсинг, популярным языком. Мы решили предоставить вашему вниманию транскрипцию выступления. Видео в конце публикации.

Всем привет! Хочу очередной раз поднять тему про найм. Только я собираюсь поговорить об этом с точки зрения кандидата, а не работодателя. Ведь собеседование, вопреки многим стереотипам, процесс двусторонний — вопросы может задавать не только интервьюер, но и сам соискатель. За прошлый год я провёл порядочное количество собеседований, и абсолютное большинство кандидатов огорчило меня отсутствием вопросов о компании, всего 5 человек стали меня расспрашивать о работе.

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

Техника кеширования позволяет создавать более масштабируемые приложения, запоминания результаты некоторых запросов в быстрое in-memory хранилище. Однако, некорректно реализованное кеширование может сильно ухудшить впечатление пользователя о вашем приложении. Эта статья содержит некоторые базовые понятия о кешировании, различные правила и табу, которые я извлек из нескольких прошлых своих проектов.

Не используйте кеширование.

Ваш проект работает быстро и не имеет никаких проблем с производительностью?
Забудьте о кешировании. Серьезно :)

Оно сильно усложнит операции чтения из базы без каких-либо бенефитов.

Правда, Мохамед Саид в начале этой статьи делает некоторые вычисления и доказывает, что в некоторых случаях оптимизация приложения на миллисекунды способна сэкономить кучу денег на вашем AWS счету. Так что, если прогнозируемая экономия на вашем проекте больше, чем 1.86 долларов, возможно, реализация кеширования — неплохая идея.

Данный мануал/гайд/etc написан для тех, кому лень собирать по кускам ту или иную информацию об установке «мака» на PC, все понятно и по полочкам.

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

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

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

Примечание. «Зомбирование» в данном контексте — многократное повторение ложной и/или неточной информации.

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

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

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

Это телевидение.

Приветствую тебя, Хабра-сообщество и новички в мире Laravel!

Данная статья написана для новичков в сфере Лары и призвана помочь им в начальной стадии освоения фреймворка.

В статье будут рассмотрены, так сказать, «базовые» пакеты, без которых лично мне трудно работать над каким-либо проектом.

Итак, если Вам интересна тема, прошу под кат.

Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «React Patterns» Майкла Чана, с некоторыми моими примечаниями и дополнениями.

Прежде всего хотел бы поблагодарить автора оригинального текста. В переводе я использовал понятие «Простой компонент» как обозначение Stateless Component aka Dump Component aka Component vs Container
Конструктивная критика, а так же альтернативные паттерны и фичи React приветствуются в комментах.

Оглавление

• Простые компоненты — Stateless function
• JSX распределение атрибутов — JSX Spread Attributes
• Деструктуризация аргументов — Destructuring Arguments
• Условный рендеринг — Conditional Rendering
• Типы потомков — Children Types
• Массив как потомок — Array as children
• Функция как потомок — Function as children
• Функция в render — Render callback
• Проход по потомкам — Children pass-through
• Перенаправление компонента — Proxy component
• Стилизация компонентов — Style component
• Переключатель событий — Event switch
• Компонент-макет — Layout component
• Компонент-контейнер — Container component
• Компоненты высшего порядка — Higher-order component

Поехали!

Изображения и текст принадлежат их авторам.

Анимация элементов в мобильных приложениях — это просто. Правильная анимация тоже может быть простой… если вы последуете представленным в статье советам.

Сегодня кто только не использует CSS 3 анимацию в своих проектах, тем не менее не только лишь все, но мало кто может делать это правильно. Даже описаны так называемые «лучшие практики», но люди продолжают делать всё по-своему. Скорее всего потому, что просто не понимают, почему всё устроено именно так, а не иначе.

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

Проектирование

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

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

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

Предлагаю читателям «Хабрахабра» перевод замечательной статьи «Nine Nasty UX Truths» за авторством Antoine Valot. В интернетах есть множество материалов по теории UX, но советы ниже являются результатом тяжелой работы автора, что-то вроде шишек, набитых в процессе. Antoine признается, что облажался бессчётное количество раз за последние 20 лет, и описанные истины — это лишь некоторые из способов избежать провалов. Не повторяйте ошибок, наслаждайтесь.

От переводчика:
Предлагаю вашему вниманию перевод краткого (действительно краткого) руководства по ES6. В нём можно ознакомиться с основными понятиями стандарта.
Оригинальный текст в некоторых случаях был дополнен или заменён на более подходящий источник. Например, часть определения ключевого слова const является переводом документации с MDN.
Чтобы лучше разобраться в некоторых концепциях (для выполнения качественного перевода) использовалось описание стандарта на сайте MDN, руководство "You Don't Know JS: ES6 & Beyond" и учебник Ильи Кантора.

Перевод выложил на Гитхаб: https://github.com/etnolover/ES6-for-humans-translation. В случае нахождения ошибок пишите, исправлю.
Ссылка на оригинальный текст: https://github.com/metagrover/ES6-for-humans

Update 22.07.2016: добавил опрос про const

Содержание

• let, const и блочная область видимости
• Стрелочные функции
• Параметры по умолчанию
• Spread/Rest оператор
• Расширение возможностей литералов объекта
• Восьмеричный и двоичный литералы
• Деструктуризация массивов и объектов
• Ключевое слово super для объектов
• Строковые шаблоны и разделители
• for...of против for...in
• Map и WeakMap
• Set и WeakSet
• Классы в ES6
• Тип данных Symbol
• Итераторы
• Генераторы

• Промисы

  
  
• Опрос: в каком регистре писать const?

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

Это цикл статей больше специалистов, значительно более углубленно, чем все мои прошлые статье в этой области. В статье я расскажу про крупнейшие интернет-магазины США, Китая, России и Украины, расскажу как маркетинг влияет на проектирование, покажу подробный Mind Map гипермаркета, опишу 57 основных модулей интернет-магазинов для внешней (покупательской) части и более 50 модулей для внутренней части (административной), покажу интерфейсы магазинов и еще много полезного.

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

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

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

Итак, прошу любить и жаловать, Виктор Русакович. Родом из Минска, работает в компании GP Software.travel.
Виктор последние пять лет занимается (в основном) фронт-енд разработкой. Ну а начинал, как и большинство из нас, с jQuery.

Потом был backbone, angular v1. Последние полгода он работает в проекте на Redux/React.js (часто их путают с RxJS, но это немного другое).

Мы создадим простой, но реалистичный модуль комментариев для блога, упрощенный аналог модуля комментариев реального времени, предлагаемый такими ресурсами как Disqus, LiveFyre и Facebook.

Мы обеспечим:

• Представление для отображения всех комментариев
• Форму для ввода и отправки комментариев
• Задел на будущее, для подключения настоящего бэк-енда

Также будут реализованы:

• Optimistic commenting: комментарии появляются на странице раньше чем они сохраняются на сервере, что визуально ускорит наш модуль
• Live updates: комментарии других пользователей появляются на странице в реальном времени
• Markdown formatting: пользователи могут использовать Markdown-разметку для форматирования текста

Финальная версия

Ссылка на GitHub

В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий из опыта других компаний.

В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.

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