Введение

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

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

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

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

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

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

Если вы когда-нибудь самостоятельно собирали компьютер и покупали лицензию на Windows, вам, вероятно, не захочется покупать ещё одну лицензию для следующего компьютера. Но, используя команду slmgr, можно деактивировать старый ПК и активировать новый.

Деактивируйте старый ПК вместо покупки новой лицензии

Лицензии на Windows стоят дорого. Цена официального ключа от Microsoft, от $100 до $200, может сравниться с ценой терабайтного твердотельного накопителя, 16 Гб RAM или материнской платы. А покупать дешёвые ключи с сомнительных веб-сайтов – это не очень хорошая идея. Поэтому платить за очередную лицензию, когда вы избавляетесь от старого компьютера в пользу нового – не очень интересная идея. Но хорошая новость в том, что можно деактивировать ПК, который вы больше не будете использовать, и перенести лицензию на новый.

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

Я работаю в комитете конференции, и по окончании нынешнего PyGotham понял, что не приложил никаких усилий для устранения недопредставленности одной конкретной демографической группы: пожилых кодеров. По сравнению с недопредставленностью женщин и меньшинств в сфере технологий, обычно ускользает от внимания дефицит программистов в возрасте за сорок. В Нью-Йорке для них нет ни встреч, ни списков рассылки, ни известных организаций, представляющих их интересы. В следующем году я обязательно буду искать возрастных программистов для выступления на PyGotham. Но пока я не знаю, где их искать.

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

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

«Какой компонент электропривода в современных электромобилях имеет наивысшую плотность в виде количества ноу-хау на единицу объёма?»

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

И обе стороны окажутся неправы.

В то время, пока ученые спорят, может ли являться наша Вселенная продвинутой компьютерной симуляцией, Джордж Хотц, известный как Geohot (взломщик iPhone, консолей Sony и основатель стартапа Comma.ai), в этом уверен. Настолько, что собрался освобождать человечество из рабства компьютерной системы.

«Нет доказательств того, что это не так», — говорит предприниматель. «Можно легко представить себе сущности, гораздо умнее нас, кто может построить клетку, о существовании которой вы даже не знаете».

От переводчика: эта статья — попытка автора показать преимущества (не недостатки) языков программирования Python и Java, а также продемонстрировать двойственность любых сравнений. Что-то, что кажется преимуществом, может оказаться недостатком, и наоборот. Возможно, какие-то моменты могут показаться спорными, но это и к лучшему — в комментариях можно все обсудить, грамотно обосновав свою точку зрения. Статья подходит как для новичков, так и для программистов с опытом.

Java и Python — одинаково популярные языки программирования. Однако Python более продуктивен: в нем меньше объем кода, нужного для решения задачи. Почему же программисты до сих пор работают с Java там, где можно применить Python? Давайте разбираться.

Очень часто, у начинающих и не только разработчиков возникают вопросы. Как управлять с Arduino с компьютера? А если компьютер — не Raspberry Pi, а обычный домашний компьютер? А если не хочется мучится с ESP8266 и управлять через веб интерфейс? Неужели надо каждый раз открывать Arduino IDE и отправлять команды через Монитор порта? Именно о том, как создать своё собственное приложение с графическим интерфейсом для управления Arduino я сейчас и расскажу.

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

А сейчас всё это (кроме собственно чтения) можно сделать автоматически.

Всем привет. Этой статьей я начинаю серию рассказов о состязательных сетях. Как и в предыдущей статье я подготовил соответствующий докер-образ в котором уже все готово для того чтобы воспроизвести то что написано здесь ниже. Я не буду копировать весь код из примера сюда, только основные его части, поэтому, для удобства советую иметь его рядом для более простого понимания. Докер контейнер доступен здесь, а ноутбук, utils.py и докерфайл здесь.

Несмотря на то, что фреймворк состязательных сетей был предложен Йеном Гудфеллоу в его уже знаменитой работе Generative Adversarial Networks ключевая идея пришла к нему из работ по доменной адаптации(Domain adaptation), поэтому и начнем мы обсуждение состязательных сетей именно с этой темы.

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

30 сентября пользователь aleshqqa1337 опубликовал искренний и, в целом, правильный пост "Необразованная молодёжь". Я понял, что не могу не ответить. Писал комментарий, писал… И в итоге решил написать пост.

Кратко о себе (это важно): работаю программистом-исследователем в сфере ИБ. Сейчас в крупной российской компании, до этого в двух банках, ещё до этого в небольшой инновационной ИБ компании. Преподаю в МГТУ им.Баумана более трёх лет… И тоже много что насмотрелся.

Тем не менее "угол зрения" aleshqqa1337 на мой взгляд немного не правильный. Это статья написана не для критики, а скорее для того чтобы дополнить картину того, что в целом происходит с техническим образованием в России.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

0. Вступление

Цель данной статьи собрать в небольшую кучку основную информацию, минимально достаточную для того, чтобы начать работать с докер на ежедневной основе и удалить с рабочей машины локально установленные apache, mysql, virtualenv, python3, mongodb, memchaced, redis, php5, php7 и весь остальной зоопарк, который мы используем при разработке, и который зачастую еще и конфликтует между собой от версии к версии.

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

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

Infinifactory

Давным-давно, когда я еще учился в университете, я услышал что на математическом факультете в нашем вузе программистам задают интересную задачу: смоделировать так называемый «волчий остров». Суть ее примерно в следующем.

Перевод статьи Валинды Чен.

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

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба