Все потоки

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

Разработка или выбор управляющего контроллера для встраиваемой системы на ПЛИС –актуальная и не всегда тривиальная задача. Часто выбор падает в пользу широкораспространенных IP-ядер, обладающих развитой программно-аппаратной структурой – поддержка высокопроизводительных шин, периферийный устройств, прикладное программное обеспечение и, в ряде случаев, операционных систем (в основном Linux, Free-RTOS).  Одними из причин данного выбора являются желание обеспечить достаточную производительность и иметь под рукой готовый инструментарий для разработки программного обеспечения.

В том случае, если применяемая в проекте ПЛИС не содержит аппаратных процессорных ядер, реализация полноценного процессорного ядра может быть избыточной, или вести к усложнению программного его обеспечения, а следовательно приведет к увеличению затрат на его разработку. Кроме того, универсальное софт-ядро будет, так или иначе, занимать дефицитные ресурсы программируемой логики. Специализированный софт-процессор будет более оптимальным решением в свете экономии ресурсов логики – за счет адаптированной системы команд, небольшого количества регистров, разрядности данных (вплоть до некратной 8битам). Согласование с периферийными устройствами – проблема в основном согласования шин и протоколов. Заменой сложной системы обработки прерываний может служить многопоточная архитектура процессора.

Стековые софт-процессоры и контекст потока

Обычно многопоточные процессоры имеют одно АЛУ и несколько наборов регистров (иногда называемых «теневыми» регистрами) для хранения контекста потока, следовательно, чем больше требуется потоков, тем будут больше накладные расходы логики и памяти. Среди разнообразия архитектур софт-процессорных ядер следует выделить стековую архитектуру. Такие процессоры часто называют еще Форт-процессорами, так как чаще всего их ассемблер естественным образом поддерживает подмножество команд языка Форт.

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

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

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

Но нет, не так хорошо ты выполняешь свою работу. Спринты не закрываются, таски льются рекой, два seniora объявили друг другу войну из PR, а менеджеры решили пойти войной на тебя, объявив тебя виновником всего этого беспорядка. И вот очередное утро, дейли, и после чашки кофе ты задаешь себе вопрос: "А эффективен ли я и моя команда?"

В последнее время я всё чаще и чаще ловлю себя на мысли, что идиоты правят этим миром. Это проявляется не только в том, что "Мнение большинства - всегда ошибочно, потому, что большинство людей - идиоты" (© Эдгар Алан По), но и в конкретных ситуациях с казалось бы крупными IT-компаниями и организациями, которыми руководит явно не большинство. Тем не менее идиотами становимся мы сами. Это крайне хорошо было продемонстрировано нами в 2018 году, когда мы, хостинг-провайдер ua-hosting.company, предоставляющий услуги в Нидерландах и США и "заразившись" интеллектом в этих странах, удалили свой сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим (подробнее описано в статье "Как мы убили себя в один клик, размещая сайт и биллинг на геокластере или ещё раз поговорим об избыточности").

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

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

Это работа является логическим продолжением моего первого подробного текста для сообщества об актуальных подходах к верстке Как верстать веб-интерфейсы быстро, качественно и интересно. Но, если в первом трактате, внимание уделялось, прежде всего, стилю кода, его качеству и эффектным современным возможностям различных препроцессоров и фреймворков, что демонстрировалось на некоторых конкретных специфических задачах, теперь хочется сфокусироваться на архитектурных или даже организационных аспектах веб-производства. Если вы не читали мой первый текст, но собираетесь при этом прочесть этот — не поленитесь перейти по ссылке и пробежать глазами самые последние разделы каждой из двух частей первого пособия: «Готовые решения» и «Песочницы». Этот текст начинает прямо с этих мест и развивает именно эти идеи: и о пагубности применения раскрученных-популярных «на все готовых» UI-«дизайн-систем»-фреймворков для создания кастомизированных веб-морд любой сложности и, о, по сути, полезности использования хотя бы минимального документирования и явных соглашений при разработке веб-GUI на фронтенде. Но я не стану тратить время, доказывая, что «ни в коем случае нельзя использовать Vuetify или AntDesign» для создания крупных UI-систем с полностью кастомным оформлением. Вам не нужно прикручивать себе огромный геморрой непроницаемый слой плохо кастомизируемого готового GUI для того чтобы написать кнопку или поле ввода! Если вам нужен датапикер — найдите и допилите что-нибудь под себя. Это понимание может только прийти или так и не придти с годами тяжелого опыта, когда вы будете постоянно тратить непростительно много своего времени на то, чтобы написать очевидно отвратительный CSS — «кряки с !important`ами поверх стилей библиотеки», выдумывать чудные костыли на javascript чтобы изменить дефолтное поведение виджетов на кастомное и хитрое-нестандартное затребованное вашими дизайнерами... И при этом ваши шаблоны, стили и js-обвязки будут превращаться во все менее читаемые запутанные нагромождения разнообразно оформленного кода, с различным подходом к наименованию и прочими бедами… Этот текст и написанный для него проект призваны наглядно показать «а как надо?».

В некоторых современных объектно-ориентированных языках есть понятие идексаторов – свойств, позволяющих работать с экземпляром класса как с массивом, используя [] нотацию. В этой статье я хочу продемонстрировать как это сделать на современном JavaScript.

NLI (natural language inference) – это задача автоматического определения логической связи между текстами. Обычно она формулируется так: для двух утверждений A и B надо выяснить, следует ли B из A. Эта задача сложная, потому что она требует хорошо понимать смысл текстов. Эта задача полезная, потому что "понимательную" способность модели можно эксплуатировать для прикладных задач типа классификации текстов. Иногда такая классификация неплохо работает даже без обучающей выборки!

До сих пор в открытом доступе не было нейросетей, специализированных на задаче NLI для русского языка, но теперь я обучил целых три: tiny, twoway и threeway. Зачем эти модели нужны, как они обучались, и в чём между ними разница – под катом.

Одно из самых интересных событий, которые произошли в мире аудио за последние годы — небывалый рост популярности форматов высокого разрешения (Hi-Res). Среди причин появления в своё время новых форматов — неудовлетворённость качеством звучания CD, ведь на заре эпохи компакт-дисков все звукозаписывающие лейблы спешили переиздать свой аналоговый каталог на цифровом носителе, мало заботясь о качестве: хотя бы плюс-минус привлекательное и лишённое всевозможных щелчков и прочих шероховатостей звучание уже казалось победой.

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

Кадры из фильма-долгостроя, большие змеи и красивые девушки в комплекте. Крутая кондовая графика, пояснения, советы и хитрости рендера. Жуткая красота и красивая жуть. Ковёр! Кормим змей от фотографии до смонтированного результата.

Буквально месяц тому назад вышла книга: "PHP 8 Programming Tips, Tricks and Best Practices" от Дуг Бирера (Doug Bierer). В этой книге автор делает обзор php 8.0, объясняет его нововведения и описывает потенциальные ошибки перехода со старых версий на php 8.0. 

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

Совсем недавно передо мной встала очень на вид простая задача - выбрать для небольшой компании (28 человек) систему управления тест кейсами. Поручили мне эту задачу в силу того, что в компании я пока один единственный тестировщик, а если правильнее и точнее сказать, то QA-engineer.

Итак, приступим, первое с чего стоит начать - это скорее всего Ютуб, посмотрим как работают большие компании, кто и что говорит о той или иной системе, почитаем статьи на Хабре, что и вам советую сделать, несмотря на подобные статьи, как эта.

Helm использует go templates для рендеринга манифестов. Есть функции которые были разработаны специально для helm. Но в большинстве своем используется библиотека Sprig.

Но что если нам мало функций и мы хотим воспользоваться своим кастомным шаблонизатором?

Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.

Акт первый, технический

В назначенный час я встретился со своим интервьюером. Собеседование выглядело “добротным” и стандартным в заданной проф. области, оттого местами скучным. Было много задач на ревью кода и обсуждения специфики языка, в частности...

Недавно я добавил новую фигурку в мое приложение...