Книга содержит 37 правил и опыта их применения. Отмечу правила, на которые обратил внимание лично я, и применил бы, а частично уже и применил.

Такие как:

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

Остальные или простые или вода.

Сегодня, в восьмой части перевода руководства по JavaScript, мы сделаем обзор возможностей языка, которые появились в нём после выхода стандарта ES6. Мы, так или иначе, сталкивались со многими из этих возможностей ранее, где-то останавливаясь на них подробнее, где-то принимая как нечто само собой разумеющееся. Этот раздел руководства призван, наряду с раскрытием некоторых тем, которых мы ранее не касались, упорядочить знания начинающего разработчика в области современного JavaScript.

→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9

Одной из самых заметных новшеств современного JavaScript стало появление стрелочных функций (arrow function), которые иногда называют «толстыми» стрелочными функциями (fat arrow function). При объявлении таких функций используют особую комбинацию символов — =>.

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

Иногда эти и другие преимущества ведут к тому, что стрелочному синтаксису отдают безусловное предпочтение перед другими способами объявления функций. Например, популярная конфигурации eslint от Airbnb принуждает к тому, чтобы всегда, когда создают анонимную функцию, такая функция была бы стрелочной.

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

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

Автор статьи, перевод которой мы публикуем, считает, что, к несчастью, в большинстве из существующих руководств по React не уделяется должного внимания ценным практическим приёмам разработки. Такие руководства не всегда дают тому, кто по ним занимается, понимание того, что такое «правильный подход» к работе с React.



В этом руководстве, которое рассчитано на начинающих разработчиков, имеющих знания в области HTML, JavaScript и CSS, будут рассмотрены основы React и самые распространённые ошибки, с которыми может столкнуться программист, пользующийся данной библиотекой.

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

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

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

Список разбивала на четыре категории:

1. Книги про бизнес;
2. Книги по проектированию — не вносила в список классику, а дополняла чем-то новым (на мой взгляд);
3. Книги о психологии поведения;
4. Книги про тексты.

Для некоторых книг нашла саммари, ссылки прилагаются.

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

Очень хочется этой статьей нанести максимальную пользу не только себе, но и коллегам.

Это второй пост о всевозможных трюках во фронтенд-разработке. В нем затронут вопрос оптимизации сайта, скорости его загрузки на устройствах с недостаточным объемом оперативной памяти и медленным CPU.

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



В основе материала — расшифровка доклада Виталия с конференции HolyJS 2018 Piter.

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

Почему я решил написать эту статью

Очень часто в рабочей среде, на просторах интернета и на собеседованиях можно услышать, например, вот такое:

«С этим Скрамом столько встреч! Когда работать то?!»;
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».

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

Далее я хотел бы рассказать о типичных случаях, откуда берут своё начало эти проблемы.

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

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

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

Я читал и читаю довольно много книг. Хорошие книги, которые мне понравилось, записываю, чтобы потом порекомендовать. Я решил сделать небольшую подборку must have книг, которые должен прочитать каждый начинающий руководитель. Одно из требований, чтобы эти книги были не только полезными, но и интересными. Книги должны заинтересовать человека развиваться в управлении, ни в коем случае не демотивировать.

Привет, Хабр! Адресую эту статью себе более молодому и неопытному, а также всем, кто чувствует неуверенность в подходе к технической документации. Хотя если кому-то из зубров проектного дела она поможет, буду рад вдвойне.

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

«Проще, чем кажется» — бизнес-роман о том, на что еще способны программисты.

1

— Слушай, Сергей, ты меня достал уже. Просто назови срок, когда сделаешь отчет.

— Я не хочу делать отчет в таком виде, это неправильно. Не отчет, а глупость какая-то. Галя, ты сама разве не видишь?

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

— Даже если задача — полный бред? Даже если отчет никому не нужен, и никто не будет на него смотреть?

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

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

Автор статьи, перевод которой мы публикуем сегодня, полагает, что в мире существует ещё много программистов, которые, когда им нужно разработать простое веб-приложение, обращаются к jQuery. Обычно это случается тогда, когда некую страницу нужно оснастить простыми интерактивными возможностями, но использование для этого какого-нибудь JavaScript-фреймворка кажется явным перебором. Ведь это — килобайты ненужного кода, шаблоны, инструменты для сборки проектов, средства для упаковки модулей… При этом подключить к странице jQuery, воспользовавшись CDN-ресурсом, проще простого.



В этом материале речь пойдёт о том, как перевести проект, созданный с использованием jQuery, на Vue.js. Этот проект будет создан на jQuery, а потом переработан с применением Vue. Автор материала хочет продемонстрировать всем желающим то, что использование Vue, даже в сравнительно небольших проектах, не обязательно означает чрезмерное увеличение размера кода таких проектов и большую дополнительную нагрузку на программиста. Это, наоборот, при практически тех же размерах вспомогательного кода, что и при использовании jQuery, позволяет повысить производительность труда и улучшить качество приложений.

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

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

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

Я буду объяснять SOLID самым простым способом, так что новичкам легче будет разобраться. Будем рассматривать принципы один за другим.

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

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

Плюс традиционно – небольшой подарок хабражителям.

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

Это бизнес, который внезапно стал больше Англии, повлиял на технический прогресс, развязал пару войн и перебил сотни тысяч людей. На половине планеты следы этой компании — от «Садов Компании» близ мыса Доброй Надежды до упоминаний в современных фильмах вроде «Пиратов Карибского моря». Бизнес впечатлял.

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

Первый способ решения проблемы был прост как полено — перекредитоваться и зализать раны, а потом медленно отдавать занятое. Но вот только Амстердам давал под 14% в месяц, и поэтому слегка окосевшие от голландской наглости англичане брать отказались.

Оставалось думать. Это было непривычно, поэтому результат тоже получился неожиданный.

Какие инструменты нужны тестировщику? Об этом мы сегодня порассуждаем в этой статье, в основе которой — доклад Юлии Атлыгиной с прошлого Heisenbug. Видеозапись доклада доступна по ссылке.