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



Материал, перевод которого мы сегодня публикуем, посвящён рассказу о некоторых возможностях консоли Chrome, которые известны не так широко, как они того заслуживают.

Как создать и настроить Angular проект с нуля

Статья была обновлена 29 Февраля 2020 чтобы следовать лучшим практикам.

Короткое вступление

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

Привет, Хабр! Представляю вашему вниманию подборку, которая является переводом моей оригинальной статьи.

Если есть идеи что добавить в подборку — буду рад пообщаться в комментах. Наслаждайтесь!

Перевели новую порцию слайдов. Права доступа в Unix, файловые дескрипторы, потоки, магия proc. И на закуску пара советов о том, как общаться, когда ты не согласен. А вдруг пригодятся =)

Реклама добилась своего: большинство покупателей уверены, что батарейки Duracell и Energizer значительно лучше других. Чтобы проверить, так ли это, я протестировал 20 видов щелочных (alkaline) батареек AAA — от самых дешёвых до самых дорогих.

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

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



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

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



Здесь представлено 13 однострочников. Примеры подготовлены с использованием Node.js v11.x. Если вы будете использовать их в другой среде — это может повлиять на их выполнение.

От переводчиков

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы поговорим о новостях в мире Angular. Мы подготовили для вас наиболее интересные материалы и отобрали список вопросов, который вам должен понравиться. Отметим только, что если вы будете ждать от этой статьи ответа на вопрос "Чем Angular лучше других технологий?", то придется вас огорчить, у нас не будет ответа на него. Почему? Как правило, все мнения вида "Технология X лучше технологии Y" почти всегда не более, чем отражение точки зрения высказывающегося. Однако для тех, кто только начинает изучать этот фреймворк, мы постараемся объяснить, что дает вам эта технология и какую пользу она приносит. Также не проходите мимо и ответьте на опрос, самые популярные ответы будут отправлены Игорю Минару (ведущий разработчик команды Angular). Ну что же, приступим.

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.

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

Сейчас разберемся, что не так с этим Dockerfile.

Итак, прошла неделя.

На написание этой статьи сподвигли поиски JavaScript front-end разработчиков в свою компанию в Ставрополе. Т.к. длительное время не удавалось найти толкового программиста и тогда мы решили запустить программу стажировки с большим количеством обучающего материала по Angular & JS.

Это перевод статьи Vamsi Vempati про его опыт работы над крупномасштабным приложением для компании Trade Me, написанным на Angular.



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

В статье в общих чертах описываются методы, которые мы используем в нашем проекте. Текст по большей части связан с Angular, TypeScript, RxJs и @ngrx/store.

Кроме того, будут рассмотрены некоторые общие рекомендации по написанию кода, которые помогут сделать приложение более «чистым» и читаемым.

Навеяно недавним постом «Как я переехал в Израиль после блокировки Telegram».

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

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

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Преамбула

Для того, чтоб описать и задокументировать правила клиент-серверного
взаимодействия используя Rest-api можно выделить три основных метода:

1. Описывать своим коллегам правила обращения к серверу на пальцах
   Этот метод быстр и не требует долгосрочной поддержки, но высока вероятность, что вас за это будут бить.
   
2. Руками составлять Google-docs/Wiki/Readme в проекте
   Удобно тем, что однажды написанная документация не требует повторного объяснения. Её можно показать коллегам и даже иногда заказчику. Минусом данного метода является долгосрочная поддержка такой документации. Когда Api в проекте вырастает до таких размеров, что сама мысль "А когда же я обновлял документацию?" вызывает холодок по спине, тогда вы понимаете, что дальше так продолжаться не может. Формально вы можете обновлять документацию очень часто и маленькими фиксами, но это до первого отпуска.

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

Приходилось ли вам отслеживать зависимости системных процессов, «кто чей папка», найти императора и убить его, чтобы рабы не респаунились? Можно ps'ать и grep'ать, можно lsof погонять, ведь это так увлекательно ;) Но любые связи, как мне кажется, всегда проще анализировать в визуальной форме, консольные утилиты рисуют хорошие таблички, но из них не всегда можно быстро понять, что с чем связано и в какой последовательности, а для диагностики это очень важно.

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

Тем ценнее встретить качественный научный фильм, популяризирующий научное знание.

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

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

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



Дистрибутивы Linux часто бывают ориентированы на конкретные задачи. Поэтому не получится просто составить список операционных систем и сказать: «они – самые лучшие». Здесь выделены несколько областей использования Linux и выбраны те дистрибутивы, у которых есть все шансы стать первыми в своей нише в 2017-м.

Кто на Земле подвергается наиболее сильному ионизирующему излучению? Дерек Мюллер на своем канале Veritasium рассказывает, как он проехался по земному шару в поисках наиболее радиоактивных мест в рамках съёмки документального фильма для телевидения об уране и о том, как он изменил современный мир.

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