Это конечно круто, но почему люди просто не переоткроют для себя ReGIS (векторную графику в терминале) и sixel (пиксельную графику в терминале).

xterm -xrm "XTerm*decTerminalID: vt340" -xrm "XTerm*numColorRegisters: 256"

clear && convert <(curl -s https://upload.wikimedia.org/wikipedia/en/7/7d/Lenna_%28test_image%29.png) sixel:-

Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.

Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.

Главный Технический Императив Разработки ПО — управление сложностью

— Совершенный код

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

• состояние всего приложения хранится в одном месте
• единственный способ изменить состояние — отправка Action'ов
• все изменения происходят с помощью чистых функций

Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

Привет! Хочу поделиться своими мыслями по, казалось бы, простой теме — типизации. В частности, поговорить о тайпчекинге в JavaScript.

Часто люди воспринимают типизацию как эдакую серебряную пулю, которая защищает от всех проблем. Но это не так, часто ожидания от типизации неоправданны, а простота таких инструментов, как TypeScript, обманчива и слишком переоценена.

Это не типичная статья из серии «Изучаем TypeScript», а, как мне кажется, фундаментальная история. Мы начнем с основ, поговорим о данных, о способе их хранения, а затем перейдем к типизации и посмотрим, как она влияет на работу программы.

Привет, друзья!

Хочу поделиться с вами заметками о Docker.

Заметки состоят из 4 частей: 2 теоретических и 2 практических.

Если быть более конкретным:

• эта часть посвящена самому Docker, Docker CLI и Dockerfile;
• в второй части рассказывается о Docker Compose;
• в третьей части мы разработаем приложение, состоящее из 3 сервисов (клиента, админки и API) и базы данных (PostgreSQL);
• в четвертой части мы это приложение "контейнеризуем".

Если вам это интересно, прошу под кат.

Предисловие

const o = {
    foo: 1
}
o.hasOwnProperty('foo') // true
o.hasOwnProperty('bar') // false

0. Об авторе

Каждое приложение использует компоненты с выпадающими блоками. Такие панели используются в выпадающем списке, Autocomplete, Tooltip и т.д. В Material CDK есть инструмент Overlay для создания такого функционала.

В этой статье мы рассмотрим какую проблему решает Overlay CDK, кто использует его и напишем свой компонент на базе этого инструмента.

Qucs-S является программой с открытым исходным кодом для моделирования электронных схем. Qucs-S кроссплатформенный (поддерживаются Linux, Windows и FreeBSD), написан на С++ с использованием набора библиотек Qt и разрабатывается полностью в частном порядке (в отличие, например от KiCAD, который имеет спонсора в лице CERN). В феврале этого года проект восстал из мёртвых и вышел релиз 0.0.23. Главным новшеством версии 0.0.23 было то, что программа теперь портирована на Qt5, чем обеспечена собираемость на современных дистрибутивах Linux. Актуальным релизом на текущий момент является 0.0.24 https://github.com/ra3xdh/qucs_s/releases/tag/0.0.24, в котором добавлено несколько новых видов моделирования. Далее будут рассмотрены основные возможности программы и показано как в Qucs-S смоделировать схему.

• Готовимся к собеседованию по PHP: ключевое слово «static»
• Готовимся к собеседованию по PHP: псевдотип «callable»
• Готовимся к собеседованию по PHP: Всё об итерации и немного про псевдотип «iterable»

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

function User(first, last){
   this.name = first + " " + last;
}

var user = new User("John", "Resig");

var name = "Resig";
var user = User("John", name);
// здесь переменная «user» не определена
// БОЛЕЕ ТОГО: значение «name» теперь ужé не «Resig»!
if ( name == "John Resig" ) {
   // фигассе!…
}

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

Рассказ будет в трех частях:

- Трудности, с которыми нам пришлось столкнуться, и как мы их преодолевали.

- Конкретные решения по некоторым распространенным кейсам при написании интеграционных тестов.

- Подход к написанию E2E-тестов (тестов, покрывающих взаимодействие всех систем приложения, включая back-end и пользовательский интерфейс) с использованием паттерна PageObject, пришедшего к нам из мира веб-разработки.

Мы привыкли слышать, что Angular это фреймворк, который решает массу задач из коробки: свой cli, встроенная сборка приложений, автоматическая миграция на новые версии с помощью schematic, работа с http, DI, реактивные формы, работа с состоянием - все это удобные инструменты для разработчика. Обычно я сравниваю его с коробкой автомат, сел и сосредоточенно поехал по дороге, без отвлечений на коробку передач.

Но в мире веба мы всегда должны думать о пользователях. И один из разделов, который заботиться о них называется веб доступность (Accessibility, A11y в англоязычной среде). И тут Angular позаботился о нас и дал мощнейших инструмент из коробки под названием CDK a11y. Предлагаю ознакомится с концепцией доступности и изучить применение этого инструмента в Angular.

Начнем с начала

Всем привет! Меня зовут Игорь, я — фронтэндер в Tinkoff.ru. И, как ни странно, я давно и безнадежно прикипел к Angular и ко всему, что с ним связано.

Очень хорошо помню свои первые проблемы со сборкой приложения на Angular: как передать в приложение переменные окружения или изменить алгоритмы сборки стилей? Я так к этому привык при работе с React. И сначала это решали с помощью ng eject: конфигурация webpack просто извлекалась из недр Angular CLI и изменялась как душе разработчика угодно. Выглядело это как костыль — webpack.config.js был раздутым и сложным. Но, когда Angular CLI v8.0.0 принес нам стабильный CLI Builders API, который позволяет кастомизировать, заменять или даже создавать новые CLI команды, все стало проще.

Сейчас самый популярный билдер для кастомизации конфигурации webpack — @angular-builders/custom-webpack. Если заглянуть в исходники всех билдеров, поставляемых пакетом, можно увидеть очень компактные решения, не превышающие и 30 строк кода.

Го тогда запилим свой? Challenge Accepted!

Сейчас многие фреймворки имеют в своем арсенале CLI (Command Line Interface) и ангуляр – не исключение. Впервые с CLI-утилитами я столкнулся, когда пробовал EmberJS и тогда мне это показалось очень удобным инструментом, который довольно сильно экономил мое время. Но, к сожалению, из коробки CLI-утилиты подходят только для несложных, домашних проектов.

Использование их же в крупных production-проектах без допилки напильником почти невозможно. Поэтому на старте нашего проекта мы вынуждены были отказаться от его использования из-за особенностей нашей архитектуры. Почти год я периодически смотрел в сторону Angular CLI в плане его развития и огорчался, что мы не можем его использовать, так как это сделало бы вход в проект гораздо проще. Но в один прекрасный момент команда Angular выпустила @angular-devkit, который содержит в себе набор пакетов, используемых cli утилитой, и это дало нам возможность допилить Angular CLI под наши нужды. Репозиторий содержит на сегодняшний день с десяток пакетов, но в этой статье мы рассмотрим только те, которые относятся к schematics.

let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));

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