Программирование

Сегодня мы хотим познакомить вас с проектом Lego Microscope. Цель этого проекта заключается в том, чтобы предоставить всем желающим инструкции и ресурсы по сборке собственного микроскопа из кубиков LEGO.

Микроскоп

Миссия Replit — сделать программирование более доступным. Мы предоставляем людям бесплатные вычисления в облаке, чтобы они могли создавать приложения на любом устройстве. Одним из самых популярных способов создания приложений в Интернете на сегодняшний день является React. Однако исторически инструменты React были медленными на Replit. В то время как экосистема JavaScript создала отличные инструменты для профессиональных разработчиков, многие из самых популярных из них, такие как Create React App и Webpack, становятся все более сложными и неэффективными.

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

Этот новый опыт основан на Vite, инструменте сборки JavaScript, который обеспечивает быструю и экономичную разработку. Vite поставляется с рядом функций, включая HMR или Hot Module Replacement, команду сборки, которая объединяет ваши инструменты с Rollup, и встроенную поддержку TypeScript и JSX.

Точка зрения невежественного студента информатики



Вероятно, вы прочитали заголовок этого поста и подумали: «Что этот парень курит? Java повсюду!» Вы правы, Java по-прежнему доминирует в отрасли и c ее помощью запускаются одни из крупнейших в мире критически важных приложений. Но распространение Java — это не то, о чем я говорю, я говорю о шумихе вокруг нее. Я провожу много времени с неопытными программистами. А что любят делать неопытные программисты? Быть взволнованным и самоуверенным в отношении таких инструментов, как языки программирования. Ни один из студентов CS, с которыми я встречаюсь, не восхищается Java, и я думаю, что так не должно быть.

Молодые/наивные разработчики (включая меня) часто попадают в ловушку фетишизации новых языков и инструментов в ущерб производительности и здравомыслию. До работы в Halp (теперь принадлежащей $TEAM) у меня были почти романтические отношения с серверным TypeScript. Я думал, что экосистема node.js была самой крутой вещью: мне понравилась идея транспилированного кода, отладки в реальном времени, огромной библиотеки пакетов и даже странных и фрагментированных систем сборки. Когда я действительно использовал его в разработке и поговорил с более опытными инженерами, магия быстро исчезла.

В предыдущей части статьи мы написали реализацию простейшей нейросети в виде JS класса. Теперь давайте попробуем дать ей настоящее задание. Сценарий будет следующим: пользователь будет рисовать в определенном блоке веб-страницы смайл, а наша нейросеть попробует определить грустный он или веселый. Давайте приступим.

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

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

Пройдя через несколько альфа- и бета-версий, наконец-то появился Bootstrap 5, на что у разработчиков ушло несколько месяцев. Новая версия претерпела серьезные изменения, включая отказ от поддержки Internet Explorer (IE) и зависимости jQuery. От IE было решено отказаться, потому что браузер занимает всего 3% рынка и его доля продолжает снижаться.

Что такое Bootstrap? Это самый популярный в мире CSS-фреймворк с открытым исходным кодом, который разработан командой Twitter. В v5 внесено сразу несколько критически важных изменений, давайте посмотрим, что там и как.

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

Здравствуйте. Меня зовут Андрей, я frontend-разработчик и я хочу поговорить с вами на такую тему как нейросети. Дело в том, что ML технологии все глубже проникают в нашу жизнь, и о нейросетях сказано и написано уже очень много, но когда я захотел разобраться в этом вопросе, я понял что в интернете есть множество гайдов о том как создать нейросеть и выглядят они примерно следующим образом:

Найти несколько DOM-элементов и получить к ним доступ из JavaScript можно разными способами: querySelectorAll, getElementsByTagName, children и так далее. В итоге в каждом случае будет возвращена коллекция — сущность, которая похожа на массив объектов, но при этом им не является, на самом деле это набор DOM-элементов.

Но во время работы с коллекциями можно столкнуться с поведением, которое покажется странным, если не знать один нюанс — они бывают живыми (динамическими) и неживыми (статическими). То есть либо реагируют на любое изменение DOM, либо нет. Вид коллекции зависит от способа, с помощью которого она получена. Рассмотрим на примере.

По мнению абсолютного большинства жителей этой планеты, разработчики это - какие-то зажравшиеся люди, которые сидят в своих уютных креслах, занимаются какой-то фигнёй и получают за это непомерные деньги. Эталонные тепличные условия и голубая мечта, которая выродилась в пренебрежительное “Войти в айти”. Но если предположить, что всё действительно так, как принято считать - и стул удобный, и денег платят много, и работа интересная - то почему же программисты, как и все остальные люди, иногда меняют место работы? Может быть, недостаточно платили? Или кресло было не такое удобное? Что-то же должно побудить человека, у которого всё хорошо (по мнению окружающих), выйти из зоны комфорта и пойти искать новое место работы. И что именно он ищет на этом новом месте? Давайте поговорим об этом. И да, многое здесь может показаться банальным, но почему-то достаточное количество людей предпочитают не брать в расчёт и половину из этих банальностей. Или делают вид, что им всё равно.

Эта статья является конспектом книги «Принципы юнит-тестирования». Материал статьи посвящен интеграционным тестам.

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

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

Заключительный пост №5 для начинающих посвящен сопоставительной визуализации электоральных данных.

Пост №4 для начинающих посвящен техническим приемам визуализации данных.

Пост №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 и я многому из нее научился.