Как всем известно, JavaScript — это язык, который очень быстро развивается. В стандарте ES2020 имеется немало новых возможностей, с которыми вам, вероятно, захочется познакомиться поближе. Честно говоря, писать JS-код можно по-разному. Различные варианты кода, направленные на решение одной и той же задачи, способны дать один и тот же результат, но некоторые из этих вариантов кода могут оказаться значительно короче и чище других. Для того чтобы сделать код качественнее и понятнее, можно пользоваться всяческими полезными приёмами. О некоторых из таких приёмов речь пойдёт в материале, перевод которого мы сегодня публикуем. Надеемся, то, о чём вы сегодня узнаете, когда-нибудь вам пригодится.

На модальных окнах, на рекламных объявлениях, на других подобных всплывающих элементах веб-страниц часто можно найти кнопку «Закрыть» с соответствующим символом. Эти кнопки позволяют пользователям (по крайней мере — некоторым из них) закрывать окна. Возможность щёлкнуть по кнопке «Закрыть» часто доступна только тем посетителям веб-страниц, у которых есть мышь. Дело в том, что большинство реализаций подобных кнопок далеко не идеально. В материале, перевод которого мы сегодня публикуем, будет рассмотрено 11 проблемных паттернов, которые используются при создании кнопок «Закрыть», а также — способы решения проблем этих паттернов. Здесь же речь пойдёт и об удачных способах создания кнопок «Закрыть».

Для начала немного теории. Что такое The Twelve-Factor App?

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

Документ сформирован разработчиками платформы Heroku.

Методология двенадцати факторов(The Twelve-Factor App) может быть применена для приложений, написанных на любом языке программирования и использующих любые комбинации сторонних служб (backing services) (базы данных, очереди сообщений, кэш-памяти, и т.д.).

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

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

Расшифровка доклада 2015 года Алексея Лесовского "Deep dive into PostgreSQL internal statistics"

Disclaimer от автора доклада: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов в которых появилась масса новшеств, улучшений и изменений относительно статистики и часть материала устарела и не актуальна. По мере ревью я постарался отметить эти места чтобы не вводить тебя читатель в заблуждения. Переписывать же эти места я не стал, их очень много и получится в итоге совсем другой доклад.

СУБД PostgreSQL — это огромный механизм, при этом состоит этот механизм из множества подсистем, от слаженной работы которых напрямую зависит производительность СУБД. В процессе эксплуатации обеспечивается сбор статистики и информации о работе компонентов, что позволяет оценить эффективность PostgreSQL и принять меры для повышения производительности. Однако, этой информации очень много и представлена она в достаточно упрощенном виде. Обработка этой информации и ее интерпретация порой совсем нетривиальная задача, а "зоопарк" инструментов и утилит запросто поставит в тупик даже продвинутого DBA.

Анализ больших данных в Python переживает эпоху возрождения. Она началась с библиотеки NumPy. Эта библиотека, кстати, является одной из составных частей тех инструментов, о которых пойдёт речь в этом материале. В 2006 году тема обработки больших данных постепенно набирала обороты, этот процесс ускорился с появлением Hadoop. Потом появилась библиотека pandas со своими структурами данных DataFrame, которые обычно называют просто «датафреймами». В 2014 году большие данные стали мейнстримом, в этом же году появилась платформа Apache Spark. В 2018 году вышла библиотека Dask и другие средства для анализа данных в Python.



Каждый месяц мне попадаются новые инструменты для анализа данных в Python, которые мне очень хочется освоить. Потратив час-другой на их изучение, можно, в долгосрочной перспективе, сэкономить немало времени. Кроме того, важно следить за тем новым, что происходит в интересующей тебя сфере технологий. Возможно, вы полагаете, что эта статья будет посвящена библиотеке Dask. Но это не так. Сегодня я расскажу вам об одной недавно обнаруженной мной Python-библиотеке, о которой стоит знать тем, кто занимается анализом данных.

Привет, Хабр!

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

Полгода назад мы представили explain.tensor.ru — публичный сервис для разбора и визуализации планов запросов к PostgreSQL.



За прошедшие месяцы мы сделали про него доклад на PGConf.Russia 2020, подготовили обобщающую статью по ускорению SQL-запросов на основе рекомендаций, которые он выдает… но самое главное — собирали ваши отзывы и смотрели за реальными use case.

И теперь готовы рассказать о новых возможностях, которыми вы можете пользоваться.

Мартин Фаулер в книге «Patterns of Enterprise Application Architecture» описывает «Модель предметной области (Domain Model)» как сложный подход к организации бизнес-логики. Метод заключается в создании классов, соответствующих объектам предметной области из реального мира как с точки зрения структуры данных, так и поведения. При этом технические аспекты, такие как хранение данных, аутентификация и авторизация, управление транзакциями, выносится за пределы слоя бизнес-логики. Паттерн реализуется одним из двух способов:

1. Богатая (насыщенная) модель — данные и поведение инкапсулируются внутри объектов предметной области.
2. Анемичная модель — в объектах предметной области инкапсулируются только данные, поведение (методы) выносится в отдельный слой сервисов.

Фаулер и Эванс считают анемичную модель анти-паттерном. Однако многие кодовые базы, с которыми мне доводилось работать, реализованы именно в стиле «анемичной» модели. Под катом расшифровка и видео моего доклада с DotNext 2019 Moscow, посвященного сравнению сильных и слабых сторон обоих подходов и не очевидным деталям реализации модели предметной области в парадигме ООП и в функциональном стиле.

Расшифровка доклада 2014 года Ильи Космодемьянского "Как PostgreSQL работает с диском".

Часть поста, конечно, устарела, но здесь рассмотрены фундаментальные моменты PostgreSQL при работе с диском, которые актуальны и сейчас.

Диски, память, цена, процессор — в таком порядке смотрят на характеристики сервера админы, покупающие машину под базу данных. Как эти характеристики взаимосвязаны? Почему именно они?

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

"Железо", настройки операционной системы, файловой системы и PostgreSQL: как и для чего выбирать хороший setup, что делать, если конфигурация "железа" не оптимальна, и какие ошибки могут сделать бесполезным самый дорогой RAID-контроллер. Увлекательное путешествие в мир батареек, "грязных" и "чистых" страниц, хороших и плохих SSD-дисков, покрасневших графиков мониторинга и ночных кошмаров системных администраторов.

Это перевод статьи с ресурса dev.to. Ее автор Fayaz Ahmed делится списком своих любимых инструментов для разработчиков.



Я разрабатываю такие проекты, как Tvflix, GSON, Appy Dev, а также множество различных микропроектов, поэтому увлекаюсь поиском бесплатных инструментов для моей работы.

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

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



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

Чудаковатые и ломающие мозг правила Usenet, Burning Man и Stack Overflow

Джоел Спольски, апрель 2018

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

Это одна из хитростей, которая может помочь самостоятельно разрешить проблему в процессе программирования. Еще один способ — освоить отладку программы (дебаггинг) по принципу “разделяй и властвуй”. Невозможно перерыть тысячу строк кода ради одной ошибки. Зато можно разделить код на две части и посмотреть, что происходит в первой половине, а что происходит во второй. Сделай это пять-шесть раз и дойдешь до той самой строки с ошибкой.

С учетом вышесказанного любопытно почитать чек-лист Джона Скита для написания идеального вопроса. Джон спрашивает: “Прочитали ли вы внимательно вопрос, чтобы оценить его внятность и понятность для человека, который в глаза не видел ту информацию, которой вы обладаете?”. По большому счету, это и есть тест с резиновой уточкой. Другой вариант: “Если в вопрос включен код, вписали ли вы его в полную, но короткую программу?”. Акцент на короткой программе — это, по сути, проверка того, пытались Вы “разделить и властвовать” или нет.

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

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

Всем привет!

Я сделал перевод и набил субтитры на отличный доклад Рича Хикки — Hammock Driven Development (Разработка через гамак). Впервые на русском языке.

Доклад впервые был представлен в 2010 году на первой конференции Clojure Conj.

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

В этой серии материалов речь пойдёт о подходах к разработке, используемые командой Trade Me, которые выражены в виде более чем двух десятков рекомендаций, касающихся таких технологий, как Angular, TypeScript, RxJS и @ngrx/store. Кроме того, определённое внимание здесь будет уделено универсальным техникам программирования, которые направлены на то, чтобы сделать код приложений чище и аккуратнее.

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

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

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

А что если поезд попадёт в туннель? Тут высока вероятность того, что связь с интернетом прервётся и веб-приложение не сможет «достучаться» до сервера. В этом случае пользователю придётся перезагрузить страницу приложения после того, как поезд выедет из туннеля и соединение с интернетом восстановится.

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

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



Материал, перевод которого мы сегодня публикуем, посвящён разбору нескольких способов повторения неудачных запросов в Angular-приложениях.

Производительность — это ключ к успеху веб-приложения. Поэтому разработчикам нужно знать о том, как возникают утечки памяти, и о том, как с ними бороться.

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



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

11 апреля 2006

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

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

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

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

И он садится писать код.

В конце есть краткое содержание.

Задачи надо выполнять качественно и в срок. Это основа порядка в управлении. Только когда всё делается качественно и в срок, то результаты достигаются, удовольствие получается, страна развивается. Выброс дофамина от решенной качественно и в срок задачи несравнимо выше, чем от листания ленты фейсбука. Не слушайте лодырей, которые говорят, что половину задач можно было бы не решать, а сроки – бессмысленная выдумка менеджеров. Задача. Качество. Срок.

Улыбнулись, пока читали? Ну, внутренне хотя бы. Если да, то читайте дальше. Если нет, то выбирайте другую публикацию.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Different Ways to Pass Inputs to a Component in Angular» автора Netanel Basal.



В этой статье, мы разберём три разных способа передачи данных в компонент. В следующем примере мы будем использовать select как главный компонент, но методы, используемые в нём релевантны и в других компонентах.

Создадим компонент select, который получает следующие входные данные — size и placement.

Использование Inputs

Первый метод, с которым мы все знакомы — использование декорантора Input.

@Component({
  selector: 'app-select',
  template: `
    <p><b>Size</b> {{ size }}</p>
    <p><b>Placement:</b> {{ placement }}</p>    
    `
})
export class SelectComponent {
  @Input() size: 'sm' | 'md' | 'lg' = 'md';
  @Input() placement: 'top' | 'bottom' | 'right' | 'left'  = 'bottom'
}

И этот код отлично работает, за исключением того, что он не такой гибкий. Например нам нужно задать переменной size значение large для любого select в нашем приложении. Таким образом мы должны разрешить клиетну переписать любой input на глобальном уровне.

Использование зависимости Injection

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

import { InjectionToken, Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class SelectConfig {
  size: 'sm' | 'md' | 'lg' = 'md'
  placement: 'top' | 'bottom' | 'right' | 'left' = 'bottom';
}

export function setSelectConfig(config: Partial<SelectConfig>) {
  return {
    ...new SelectConfig(),
    ...config
  }
}

Для начала нам нужно создать конфигурацию провайдера. Этот провайдер может быть использован как token, type, а также задавать значения по умолчанию для каждого input. Используем это в нашем компоненте select: