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

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

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

После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?

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

В отличие от распространенной "клиент-серверной" архитектуры, для децентрализованных приложений характерно:

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

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

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

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

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

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

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

Про Flutter написано уже много статей. С каждым месяцем он становится всё популярнее. Поэтому я решил интерпретировать официальную документацию Flutter в лаконичный формат «вопрос — ответ». Думаю, многие, как и я, не имеют достаточно свободного времени для подробного изучения документации фреймворка, с которым они ещё не работают.

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

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

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

Привет, %username%.

Я, как обычно, не успокоюсь.

А всему причина пентафторид иода и прошлая статья!

В общем, все мы (надеюсь) помним начало творчества Ридли Скотта и просто потрясающий фильм «Чужой», который я рекомендую, несмотря на то, что он 1979 года. К концу этой статьи я докажу, что фильм не просто крут — он НАУЧЕН!

А для этого мы напряжём память и вспомним концовку: Рипли садится на челнок и внезапно обнаруживает там Чужого.

А теперь будет немного картинок, тёплых воспоминаний и химии.

По мере того как ваше приложение развивается и растёт, увеличивается и время его сборки — от нескольких минут при пересборке в development-режиме до десятков минут при «холодной» production-сборке. Это совершенно неприемлемо. Мы, разработчики, не любим переключать контекст в ожидании готовности бандла и хотим получать фидбек от приложения как можно раньше — в идеале за то время, пока переключаемся с IDE на браузер.

Как этого достичь? Что мы можем сделать, чтобы оптимизировать время сборки?

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

Оптимизации размера бандла и производительности самого приложения в этой статье не рассматриваются.

Нет повести печальнее на свете,
чем повесть о ViewPager’e и SET’e

Хочется предупредить, что автор ‒ новичок андроид, поэтому статья содержит столько технических неточностей, что вас, скорее, нужно предупредить о том, что в статье могут встретиться технически достоверные утверждения.

Куда приводит бекенд

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

Хотелось навсегда забыть этот страшный бекенд. К счастью, судьба подкинула мне идею – это было мобильное приложение. Основной его фишкой должно было стать нестандартное использование камеры. Работа закипела. Прошло немного времени, и вот прототип готов. Релиз проекта близился и все было хорошо и стройно, пока я не решил сделать пользователю “удобно”.

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

Однажды вечером, сразу после того, как я закончил разбираться с наследованием в JS, мне пришла в голову идея, что пора бы заняться чем-нибудь посложнее — например паттернами. На столе внезапно оказалась книжка Gof, а на экране ноутбука появился труд с названием «JavaScript patterns».

В общем, спустя пару вечеров, у меня появились описания и реализации на JavaScriptе самых основных паттернов — Decorator, Observer, Factory, Mediator, Memoization (не совсем паттерн, а скорее техника, но мне кажется что она прекрасно в этот ряд вписывается) и Singleton.

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

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

Листинг многих файлов занимает время

Всё началось с вопроса в техподдержку от пользователя. Он сообщил о проблеме, что выполнение ls занимает несколько минут в каталоге c более 15 000 записей в $SCRATCH [каталог для временных файлов — прим. пер.].

Наверное, все близкие к веб-разработке люди уже наслышаны о Progressive Web App. Ещё бы! Эта технология практически уравняла веб и мобильную разработку с точки зрения распространения продуктов и вовлечённости пользователей.

Да, современный фронтенд, написанный, например, на React, работает как приложение. Но вот только скачивается это приложение в браузер и запускается из него. В этом и заключается огромный гандикап, который всегда имела мобильная разработка. Давайте подумаем, чем с точки зрения обычного пользователя, «приложение» отличается от «сайта». Сразу в голову приходит, что приложение в телефоне, а сайт на компьютере. Но ведь есть мобильный браузер, так что сайт и в телефоне тоже. Тогда остаётся 3 существенных отличия:

Недавно я участвовал соревнованиях демосцены Revision 2019 в категории «PC 4k intro», и моё интро выиграло первое место. Я занимался кодингом и графикой, а dixan сочинял музыку. Основное правило соревнования — необходимо создать исполняемый файл или веб-сайт, имеющий размер всего 4096 байта. Это означает, что всё приходится генерировать с помощью математики и алгоритмов; никаким другим способом не получится ужать изображения, видео и аудио в такой крошечный объём памяти. В этой статье я расскажу о конвейере рендеринга своего интро Newton Protocol. Ниже можно посмотреть готовый результат, или нажать сюда, чтобы посмотреть как оно выглядело вживую на Revision, или зайти на pouet, чтобы прокомментировать и скачать участвовавшее в конкурсе интро. О работах конкурентов и об исправлениях можно прочитать здесь.

Приветствую, хабровчане!

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

Примерное время прочтения: 12 минут.

“Проще обмануть человека, чем убедить его, что он был обманут”
Неизвестный автор

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

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

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

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

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

Раньше у россиян было одно испытание в году — пережить новогодние праздники, желательно целыми и невредимыми. Новый вызов — 5 + 4 дней в тёплой весенней обстановке на даче или на природе: с лопатами, блюдами на огне, в приятной компании близких и неприятном соседстве клещей. И если с правилами обращения с огнём и клещами знакомы почти все, то с едой какая-то беда: то пересушено, то не дожарено, то невкусно, то расстройство ЖКТ. А ведь каждый из нас с вами просто носитель тайны приготовления еды на огне, гуру администрирования горячих углей и DevOps-шашлыка. Ну что, похоливарим на вторнично-пятничном расслабоне?