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

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

Итак, поехали.

предыдущие главы

30. Интерпретация кривой обучения: Большое смещение

Предположим, ваша кривая ошибок на валидационной выборке выглядит следующим образом:

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

Но трудно предположить, как будет выглядеть экстраполяция кривой зависимости качества алгоритма на валидационной выборке (Dev error) при добавлении данных. А если валидационная выборка маленькая, то ответить на этот вопрос еще сложнее из-за того, что кривая может быть зашумлена (иметь большой разброс точек).

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

Компьютер — это просто. Или нет?

Статья состоит из двух частей:

1. Краткое описание некоторых архитектур сетей по обнаружению объектов на изображении и сегментации изображений с самыми понятными для меня ссылками на ресурсы. Старался выбирать видео пояснения и желательно на русском языке.
2. Вторая часть состоит в попытке осознать направление развития архитектур нейронных сетей. И технологий на их основе.

Рисунок 1 – Понимать архитектуры нейросетей непросто

Все началось с того, что сделал два демонстрационных приложения по классификации и обнаружению объектов на телефоне Android:

• Back-end demo, когда данные обрабатываются на сервере и передаются на телефон. Классификация изображений (image classification) трех типов медведей: бурого, черного и плюшевого.
• Front-end demo, когда данные обрабатываются на самом телефоне. Обнаружение объектов (object detection) трех типов: фундук, инжир и финик.

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

Немного истории, истоков и революции

Привет, Хабр!

Уже довольно давно я пишу свой игровой фреймворк — такой pet project для души. А так как для души нужно выбирать что-то, что нравится (а в данном случае — на чём нравится писать), то выбор мой пал на nim. В этой статье я хочу поговорить именно про nim, про его особенности, плюсы и минусы, а тема геймдева лишь задаёт контекст моего опыта — какие задачи я решал, какие трудности возникли.

Давным-давно, когда трава была зеленее, а небо чище, я встретил nim. Хотя нет, не так. Давным-давно я хотел заниматься разработкой игр, чтобы написать свою Самую Классную Игру — думаю, многие проходили через это. В те времена Unity и Unreal Engine только-только стали появляться на слуху и, вроде как, ещё не были бесплатными. Я не стал их использовать, не столько из-за жадности, сколько из-за желания написать всё самому, создать игровой мир полность с нуля, с самого первого нулевого байта. Да, долго, да, сложно, зато сам процесс приносит удовольствие — а что ещё для счастья надо?

Современный мир разработки, по-своему, прекрасен. Хорошей практикой считается свободное распространение своих знаний и разработок. Стремление к знаниям создает спрос, а habr, toster (ныне qna), github, митапы, конференции и прочее являются отличным предложением. О митапах и конференциях я сегодня и хотел бы рассказать. Под катом история как я, будучи разработчиком и собственником IT-компании, начал выступать на IT конференциях.

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

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

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

Введение

Многие компьютерные системы, использующие реляционные БД, хранят в них какую-то финансовую информацию о балансах и транзакциях. При этом при проектировании и разработке такой БД часто встает вопрос, а как именно хранить эту информацию. Обычно выбор стоит между дешевой "простой записью" и более сложной "двойной записью".

Лука Пачоли, автор самой старой (15 век) дошедшей до нас книги с описанием принципов двойной записи

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

Основные правила таковы:

1. Sentiment Analysis (Анализ настроений через текст)