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

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

Не рассматриваются подходы с использованием Markdown, Pandoc, Asciidoc и Confluence как более сложные и узкоспециализированные, а статью хотелось сделать доступной и понятной не только молодым людям, но и людям старших возрастов.

Во многих мошеннических схемах используется очень простая и действенная идея: когда человек вкладывается во что-то, это что-то обретает для него ценность, даже если по факту это пустышка. Например, всякие фейковые опросы, где человек тратит 2 часа времени, чтобы ответить на 500 вопросов, потом в личный кабинет падает 300кк рублей, но нужно заплатить 500р "комиссии" за вывод средств. Никто никогда бы не поверил в эту чушь, но когда потрачено 2 часа и кажется, что от награды отделяет самая малость... Или же человек играет в покер и проиграл уже все деньги, дом и кота, но нужно продолжать, потому что "столько проиграно, нужно отыграть".

Вчера я чуть не попался на это. Не на мошенничество, нет - я чуть не попал в упомянутую психологическую ловушку "слишком много вложил, чтобы бросить", которую сам себе и построил. Но моя история совсем не уникальна, поэтому помимо неё я собрал тут коллекцию историй и применил ORDER BY scale ASC, чтобы вы оценили: эта ловушка живёт на всех масштабах - от маленьких сиюминутных решений до целых жизней.

Построим алгоритм распознавания эмоций (Face Expression Recognition), который работает с изображениями.

Продолжаем тему D-Bus на Хабре. D-Bus — система межпроцессного взаимодействия (IPC), которая позволяет приложениям в операционной системе сообщаться друг с другом. При этом приложения могут находиться на разных компьютерах.

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

В тоннелях Boring Company, построенных, чтобы не было пробок, теперь пробки. Cybertruck не поедет до 2023 года Но все это мелкие проблемы по сравнению с тем, чем обещает стать Starlink. Это главный проект Илона Маска, который должен спонсировать SpaceX, и собрать достаточно денег, чтобы обеспечить полет на Марс. Но он может стать и самой большой ошибкой.

1500 спутников уже запущены и работают, 145 000 пользователей в США и Канаде уже довольны своим интернетом. Тем не менее верить в успех этого проекта, скорее всего, преждевременно. И даже более того: возможно, нам будет лучше, чтобы это будущее никогда не наступило.

Осторожно, в тексте много цифр. И, если вы продолжаете верить в Starlink, он может вас сильно разочаровать.

Логировать лучше, чем не логировать. Чем больше разбираешься в чужом и своём коде, тем больше убеждаешься в справедливости этих слов. В Python есть прекрасный модуль logging: настолько удобный и гибкий, насколько вряд ли когда-нибудь понадобится. Мы не будем обсуждать, как его настроить, благо инструкций для этого хватает. Считаем, что всё уже настроено и надо просто добавить логгер в наши классы, чтобы использовать его внутри объектов.

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

Пост в помощь тем кто интересуется практической пользой от применения нейросетей на фондовом рынке.

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

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

Я был таким человеком в 2008 году, когда приехал в частную школу английского языка в Лондоне. В школе были группы семи уровней: Beginner, Elementary, Intermediate (и Pre- и Upper-), Advanced, Advanced+. После тестирования меня определили в группу Advanced+. Наверно, у меня было что-то в районе Proficiency, C2?

Ребята-казахи из группы Pre-Intermediate как-то посмеялись надо мной в пабе, потому что меня официант не понял, а их – без проблем. А ещё я не знал некоторых простых разговорных выражений, которые знали люди из групп Intermediate и даже ниже, поскольку в предыдущие пять лет делал упор на чтение классической литературы. И ещё очень, ОЧЕНЬ плохо понимал живую речь на слух. Похоже на С2?

А какой уровень у человека, которого чуть не застрелила полиция в США потому, что он не смог разобрать на слух простые слова “the police”? Это произошло со мной в 2012 году в городе Чарльстон, Южная Каролина. На тот момент, кстати, я как профессионал вырос на голову по сравнению с 2008 годом и уже успел поработать переводчиком. А ведь реально написали бы потом, что был он иностранец, плохо знал язык. Справедливости ради, “the police” проорал афроамериканец с характерным выговором, в гражданской одежде, из автомобиля без полицейской маркировки (“undercover police” это называется).

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

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

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

Подробное описание всего процесса включения ПО в реестр программного обеспечения минкомсвязи от частного лица на личном опыте.

Первыми это обнаружили шумеры. Шумеры — это те самые ребята, которые 6 тысяч лет назад изобрели кучу полезного: колесо, плуг, письменность, классовое общество, цветные ткани, бубенчики. В том числе они изобрели календарь. Это сегодня календарь нужен чтобы не пропустить день рождения коллеги или деловую встречу, а праздники — это очередной повод выпить. А тогда нужно было знать, когда сеять пшеницу, когда собирать урожай, когда готовиться к розливу рек, когда высохнут дороги после наводнения, чтобы пойти резать соседей, ну или пойти торговать с ними. Праздники также были сугубо практического назначения, по ним отмерялось начало или окончание очередного этапа сельхоз работ. И выпить на праздники как же без этого (пивоварение тоже они изобрели). Кстати у шумеров была шестидесятеричная система счета и именно они разделили час на 60 минут, а минуты на 60 секунд. Так что теперь вы знаете кого проклинать, когда мучаетесь, переводя километры в час в метры/секунды. 

В своей книге «Сид Мейер: Жизнь в мире компьютерных игр» знаменитый разработчик рассказывает о ключевых моментах карьеры, много шутит и через всю книгу дает советы и лайфхаки по разработке игр. А в этой статье основные из них — перевод под катом.

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

Привет, меня зовут Игорь и я работаю в команде Tarantool. При разработке мне часто требуется быстрое прототипирование приложений с базой данных, например, для тестирования кода или для создания MVP. Конечно же хочется, чтобы такой прототип требовал минимальных усилий по доработке, если вдруг будет решено пустить его в работу.

Мне не нравится тратить время на настройку SQL базы данных, думать, как управлять шардированием данных, тратить много времени на изучение интерфейсов коннекторов. Хочется просто написать несколько строчек кода и запустить его, чтобы все работало из коробки. В быстрой разработке распределенных приложений мне помогает Cartridge — фреймворк для управления кластерными приложениями на основе NoSQL базы данных Tarantool.

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

Свой путь к гибким методологиям разработки организации часто начинают с того, что нанимают сертифицированного Agile-консультанта (Certified Agile Consultant™), изучают Agile-манифест разработки программного обеспечения и Scrum. Затем тратят время на то, чтобы наверстать упущенное за 20 с лишним лет, и, надеюсь, приходят к выводу, что главное — это поставка, а не процесс. Но почему все должны начинать сначала? Манифест был написан более 20 лет назад. И несмотря на то, что некоторые принципы уже устарели, большинство тренингов по Scrum только закрепляют то, что требует обновления. Например, "поставка каждые 2-4 недели" продолжает ограничивать большинство команд.

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