До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

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

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

Disclaimer: Эту статью я начал писать достаточно давно и закончил только сейчас, так как не было времени. За это время было опубликовано еще 2 аналогичные статьи: вот эта и вот эта. Часть информации в статье повторяет информацию из этих двух статей. Однако, так как всё описанное в статье я рассматриваю через призму собственного опыта, я решил оставить ее без изменений.

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

Много раз, когда шла речь о переводе React-проектов на TypeScript, я часто слышал, что самую сильную боль вызывает создание HoC’ов (Higher-Order Components — компоненты-обертки). Сегодня я покажу приём, как делать это безболезненно и довольно легко. Данный приём будет полезен не только для проектов TS, но также и для проектов ES6+.

Встречайте, противостояние двух фреймворков: Angular и React в формате поединка на примере конкретного простого приложения. За Angular выступает Евгений Гусев (@bunopus), за React — Илья Таратухин (@ilfa). Чтобы сделать честные выводы, они сначала поменялись технологиями и попробовали развернуть базовый проект. Старт на React породил множество проблем, а вот с Angular дело обстояло гораздо проще, потому что это идеальное приложение для человека, который не особенно работал с фронтендом. Но, конечно, это было только начало, дальше пошел настоящий спор, все этапы которого под катом

Сложно уследить за новшествами различных версий ECMAScript, а ещё сложнее — найти полезные примеры их применения, не перекапывая горы информации. Поэтому сегодня мы публикуем перевод материала, автор которого проанализировал 18 новых возможностей ECMAScript, в число которых входят те, что имеются в уже вышедших стандартах ES2016 и ES2017, а также — те, которые должны появиться в стандарте ES2018. Автор этой статьи обещает, что каждый, кто её прочтёт, узнает много интересного и полезного о новых возможностях JavaScript.

Ни для кого не секрет, что многие наши собратья по IT цеху живут в теплых странах. И некоторые из нас думают: “Не хочу серость, холод и давку в метро! Хочу круглый год лежать на пляже с ноутбуком!”. И наверняка многие читали-слышали, что, в одном таком райском уголке, на Кипре, уже прошел кризис, открылась куча IT компаний, и HRы зазывают туда айтишников, обещая райские кущи. Так что же их (айтишников) там ждёт?

Сразу оговорюсь, что я не собираюсь вдаваться в околополитические дискуссии, а просто хочу рассказать некоторые детали по состоянию на 2017-2018 год, чтобы помочь принять решение, если кто-то всерьез задумался о переезде на Кипр. Речь будет идти о Южном Кипре, в основном, о самом русском городе Лимассоле.

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

Дисклаймер:
Для избежания разночтений всё что будет описано ниже — по большей части о городе Лимассол, в котором я живу и работаю. Все сравнения, которые я буду делать с Россией — по большей части с Санкт-Петербургом, в котором я жил последнее время. Далее по тексту под «русскими» я буду иметь ввиду граждан России, Украины, Белоруссии и других русскоговорящих. Местные нас особо не различают, мы для них — все русские.

Всем привет! Хочу поделиться своим переводом статьи React is Slow, React is Fast: Optimizing React Apps in Practice автора François Zaninotto. Надеюсь, это кому-то будет полезным.

Краткое содержание:

1. Измерение производительности React
2. Почему ты обновился?
3. Оптимизация через разбиение на компоненты
4. shouldComponentUpdate
5. Recompose
6. Redux
7. Reselect
8. Остерегайтесь объектных литералов в JSX
9. Заключение

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

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

Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.

«Но Саймон! Почему?!", вы, вероятно, прокричите увидев этот текст на экране. И вот почему:

Перспективы трудоустройства

PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.

Иначе просто невозможно добиться успеха.

Приведем немного научных™ фактов, чтобы доказать эти утверждения:

$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;

— Вам уже 45? Но у нас коллектив очень молодой. Вы уверены, что хотели бы у нас работать?
— Да, конечно! Я много наслышан о вашей компании. Это мечта всей моей жизни!
— Ну ладно. Вот вам простой вопросик. Что означает буква L в аббревиатуре SOLID?
— Liskov Substitution Principle.

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

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

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.

Это перевод статьи, которую Марико Косака написала в качестве альтернативного введения в промисы JavaScript. Наброски иллюстраций она делала в своём блокноте во время чтения разных статей, посвящённых промисам. Если хотите изучить более подробно, в конце вы найдёте список полезных ссылок.

Недавно Марико участвовала в обсуждении того, как можно с помощью JavaScript сделать фичу, которая давала бы доступ к внешним данным (должна была быть асинхронной). Она сказала: «Ну, давайте используем fetch()… так что в коде… эээ...», и пока силилась вспомнить fetch API, собеседник сказал: «Будет возвращаться промис». По словам Марико, её мозг впал в ступор, и она сказала: «Честно говоря, не знаю, что ты имеешь в виду…»

Ей приходилось много раз писать код, основанный на промисах, но для полной картины нужные пазлы в её голове почему-то не соединились. Она поняла, что на самом деле не «въезжает» в суть.

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

Думаю, все согласятся с таким определением: CSS используется для описания представления документа, написанного на языке разметки. Также ни для кого не будет новостью, что за время развития CSS стал довольно мощным средством и что для использования в команде нужны дополнительные инструменты.

Денис Измайлов ( DenisIzmaylov )

Всем привет! Вкратце расскажу о себе. Я — Денис Измайлов. Последние 5 лет сосредоточился на JS-разработке, делал много Single Page Application, highload, React, выступал на MoscowJS несколько раз, каммитил webpack и т.д.

Сегодня хотел бы поговорить вот о чем: почему от Single Page Application в его классическом виде стоит отказаться; как изоморфные приложения отразятся на Вашей зарплате; и что вы будете делать на этих выходных?

Алексей Еремихин ( alexxz )

Я хочу навести порядок в головах, чтобы люди поняли, что такое Hadoop, и что такое продукты вокруг Hadoop, а также для чего не только Hadoop, но и продукты вокруг него можно использовать на примерах. Именно поэтому тема — «С чего начать внедрение Hadoop в компании?»

Структура доклада следующая. Я расскажу:

• какие задачи я предлагаю решать с помощью Hadoop на начальных этапах,
  
• что такое Hadoop,
  
• как он устроен внутри,
  
• что есть вокруг него,
  
• как Hadoop применяется в Badoo в рамках решения задач с первого пункта.
  

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

В этой статье мы рассмотрим, что изменилось в движке Zend седьмой версии по сравнению с пятой, а также разберёмся, как можно эффективно использовать внутренние оптимизации. В качестве исходной точки возьмём PHP 5.6. Зачастую многое зависит от того, как те или иные вещи написаны и представлены движку. При написании критически важного кода необходимо уделять внимание его производительности. Изменив несколько мелочей, вы можете сильно ускорить работу движка, зачастую без ущерба для других аспектов вроде читабельности кода или управления отладкой. Свои рассуждения я докажу с помощью профилировщика Blackfire.

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных. Для ее реализации необходимо определиться со сценариями файловера — это залог успешной работы кластера, протестировать его работу. В двух словах — настраивается репликация, чаще всего асинхронная, и в случае отказа текущего мастера, другая нода(standby) становится текущем «мастером», другие ноды standby начинают следовать за новым мастером.

На сегодняшний день repmgr поддерживает сценарий автоматического Failover — autofailover, что позволяет поддерживать кластер в рабочем состоянии после выхода из строя ноды-мастера без мгновенного вмешательства сотрудника, что немаловажно, так как не происходит большого падения UPTIME. Для уведомлений используем telegram.

Появилась необходимость в связи с развитием внутренних сервисов реализовать систему хранения БД на Postgresql + репликация + балансировка + failover(отказоустойчивость). Как всегда в интернете вроде бы что то и есть, но всё оно устаревшее или на практике не реализуемое в том виде, в котором оно представлено. Было решено представить данное решение, чтобы в будущем у специалистов, решивших реализовать подобную схему было представление как это делается, и чтобы новичкам было легко это реализовать следуя данной инструкции. Постарались описать все как можно подробней, вникнуть во все нюансы и особенности.