![](http://webcf.waybackmachine.org/web/20210507022201im_/https://habrastorage.org/getpro/habr/avatars/e36/812/d3d/e36812d3de38eb3d479d7a13228717ef.png)
Собственный микроскоп из кубиков LEGO
- Перевод
![](https://webcf.waybackmachine.org/web/20210507022201im_/https://habrastorage.org/getpro/habr/post_images/ecf/a46/3ff/ecfa463ff898ea7399cc3445d0618a3f.jpg)
В предыдущей части статьи мы написали реализацию простейшей нейросети в виде JS класса. Теперь давайте попробуем дать ей настоящее задание. Сценарий будет следующим: пользователь будет рисовать в определенном блоке веб-страницы смайл, а наша нейросеть попробует определить грустный он или веселый. Давайте приступим.
Итак, моя первая публикация успешно прошла модерацию, поэтому рад вам представить вторую часть статьи, в которой мы применим полученные знания на практике и напишем простейшую нейросеть с нуля.
Как я говорил во вступлении к первой части, я frontend-разработчик, и мой родной язык - JavaScript, реализовывать нашу нейросеть в рамках данной статьи мы будем именно на нем. Для начала несколько слов о структуре.
Статья об одном неудачном решении, которое распространено при переходе на микросервисы. Несмотря на то, что Microsoft и другие компании в своих руководствах рассматривают возможность создавать Entity Serivces, есть все основания считать его антипаттерном. Далее мы поговорим о том, что такое Entity Service и какими свойствами он обладает для конечной системы в целом.
Здравствуйте. Меня зовут Андрей, я frontend-разработчик и я хочу поговорить с вами на такую тему как нейросети. Дело в том, что ML технологии все глубже проникают в нашу жизнь, и о нейросетях сказано и написано уже очень много, но когда я захотел разобраться в этом вопросе, я понял что в интернете есть множество гайдов о том как создать нейросеть и выглядят они примерно следующим образом:
Найти несколько DOM-элементов и получить к ним доступ из JavaScript можно разными способами: querySelectorAll
, getElementsByTagName
, children
и так далее. В итоге в каждом случае будет возвращена коллекция — сущность, которая похожа на массив объектов, но при этом им не является, на самом деле это набор DOM-элементов.
Но во время работы с коллекциями можно столкнуться с поведением, которое покажется странным, если не знать один нюанс — они бывают живыми (динамическими) и неживыми (статическими). То есть либо реагируют на любое изменение DOM, либо нет. Вид коллекции зависит от способа, с помощью которого она получена. Рассмотрим на примере.
По мнению абсолютного большинства жителей этой планеты, разработчики это - какие-то зажравшиеся люди, которые сидят в своих уютных креслах, занимаются какой-то фигнёй и получают за это непомерные деньги. Эталонные тепличные условия и голубая мечта, которая выродилась в пренебрежительное “Войти в айти”. Но если предположить, что всё действительно так, как принято считать - и стул удобный, и денег платят много, и работа интересная - то почему же программисты, как и все остальные люди, иногда меняют место работы? Может быть, недостаточно платили? Или кресло было не такое удобное? Что-то же должно побудить человека, у которого всё хорошо (по мнению окружающих), выйти из зоны комфорта и пойти искать новое место работы. И что именно он ищет на этом новом месте? Давайте поговорим об этом. И да, многое здесь может показаться банальным, но почему-то достаточное количество людей предпочитают не брать в расчёт и половину из этих банальностей. Или делают вид, что им всё равно.
Эта статья является конспектом книги «Принципы юнит-тестирования». Материал статьи посвящен интеграционным тестам.
Юнит-тесты прекрасно справляются с проверкой бизнес-логики, но проверять эту логику «в вакууме» недостаточно. Необходимо проверять, как разные ее части интегрируются друг с другом и внешними системами: базой данных, шиной сообщений и т. д.
В этой статье рассматривается роль интеграционных тестов, когда их следует использовать и когда лучше положиться на классические юнит-тесты. Также затронем эффективное написание интеграционных тестов.
Заключительный пост №5 для начинающих посвящен сопоставительной визуализации электоральных данных.
Пост №3 для начинающих посвящен генерированию распределений, их свойствам, а также графикам для их сопоставительного анализа.
Пост №2 для начинающих посвящен описательным статистикам, группированию данных и нормальному распределению. Все эти сведения заложат основу для дальнейшего анализа электоральных данных.
Серия из 5 постов для начинающих представляет собой «ремикс» первой главы книги 2015 года под названием «Clojure для науки о данных» (Clojure for Data Science). Автор книги, Генри Гарнер, любезно дал согласие на использование материалов книги для данного ремикса с использованием языка Python.
Книга была написана как приглашение в так называемую «науку о данных», которая в последние годы получила сильный импульс к развитию в связи с потребностью в быстрой и своевременной обработке больших наборов данных локально и в распределенной среде.
Три главы книги были адаптированы под язык Python в течение следующего года после издания книги, т.е. в 2016 году. Публикация ремикса книги в РФ не получилась по разным причинам, но одна из главных станет понятной в конце этой серии постов. В конце заключительного поста можно будет проголосовать за или против размещения следующей серии постов. А пока же…
Моржовый (walrus) оператор, появившийся в Python 3.8, дает возможность решить сразу две задачи: присвоить значение переменной и вернуть это значение, поэтому порой можно написать код короче и сделать его более читаемым, и он может быть даже более эффективным с точки зрения вычислений.
Давайте посмотрим на моржовый оператор и приведем примеры того, где он может быть полезен.
От переводчика: профессия девелопер адвоката появилась не так давно и почти у каждого крупного продукта или технологии есть свой адвокат, технологические компании понимают важность этого канала общения с миром. Есть такая должность и в Haulmont. Когда мы формулировали требования к вакансии, нам самим пришлось отвечать на вопрос "А что же должен делать девелопер адвокат?" И эта статья простым языком и очень исчерпывающе на этот вопрос отвечает.
Несколько лет назад я написал статью “Кто такой вообще этот девелопер адвокат?”, в которой постарался помочь людям в технической индустрии понять, что входит в эту роль. И до сих пор я получаю тонны вопросов про это в Твиттере.
В этой статье я собираюсь пролить свет на роль Developer Advocate и в этот раз приведу конкретные примеры задач и обязанностей, которые я выполняю в своей ежедневной работе в качестве Senior Developer Advocate в Microsoft, а также в качестве человека, который занимается этим с 2015 года.
Цель этой статьи — показать как мы можем сконфигурировать два и более контейнеров, чтобы они могли взаимодействовать друг с другом. В этой статье мы сделаем следующее:
Создадим образ Docker используя простой веб-сервис с использованием Python и Flask.
Запустим два отдельных контейнера
Создадим сеть в Docker
Объединим контейнеры используя созданную сеть
Роберт Мартин представил принципы SOLID в 2000 году, когда объектно-ориентированное программирование стало настоящим искусством для программистов. Каждый хочет создать что-то долговечное, которое можно использовать повторно, насколько это возможно, с минимальными изменениями, которые потребуются в будущем. SOLID - идеальное название для этого.
Фактически, объектно-ориентированное программирование работает лучше всего, когда мы можем отделить то, что останется, от того, что изменится. Принципы SOLID помогают разделять это.
Мне лично нравится идея, лежащая в основе принципов SOLID и я многому из нее научился.