1. Введение

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



Я тоже довольно долго изучал эти вопросы. Российское законодательство по этим вопросам сильно зарегулировано, и все эти законы и правила причиняют массу проблем фрилансерам, работающим на зарубежный рынок. В итоге я принял решение перевести свой «бизнес» в другую юрисдикцию. Изучив все возможные варианты, я выбрал такой путь — зарегистрировать фирму ООО в Латвии, и принимать платежи от заказчиков на эту фирму. То есть просто переместить свой бизнес из России в Латвию.

Я уже год работаю в таком формате, я сталкивался с разными проблемами и оценил плюсы и минусы. В итоге я решил, что в сумме я выиграл от такого решения. В комментариях к статьям о фрилансе я периодически читаю вопросы типа «как работать на заказчиков из США», «Как платить налоги на платежи с Upwork-а», и поэтому я решил поделится своим опытом, тем более что подобных статей я еще нигде не видел.

Введение

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

В ходе работы приходилось нанимать программистов и обучать основам бухгалтерского учета. Когда обучал программистов бухучету, мне нравилось за час рассказать им всю базовую теорию. Приятно срывать покровы сложности и таинственности. Оказывается, курсы бухгалтеров никому не нужны. Нет такой науки. Разве что набор терминов, в которых путаются сами бухгалтера…

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

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

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

В этот раз мы решили разнообразить поток технических интервью реальным хардором и подготовили материал на основе доклада Руслана cheremin Черемина (Deutsche Bank) про анализ работы пары Escape Analysis и Scalar Replacement, сделанный им на JPoint 2016 в апреле минувшего года.

Видеозапись доклада перед вами:



А под катом мы выложили полную текстовую расшифровку с отдельными слайдами.

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

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

Облако из слов в заголовках тикетов во внутреннем Яндекс.Трекере

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

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

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

Предполагается. что вы знакомы с многими функциями из Java SE, поэтому в основном информация дается кратко. Конечно, можно использовать эту статью и просто для обучения основам Java SE платформы (но в этом случае, после чтения статьи вам скорее всего придется обратиться к другим источникам).



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

Внимание: я не буду касаться вопросов по самому языку Java (вроде для чего нужно слово final или чем overriding отличается от overloading), это потребует отдельной статьи, это вопросы именно по Java SE (6-9) платформе.

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

Какой из них верный и чем грозит ошибка при выборе договора?

Всем привет!

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

Пример такой задачи – это соревнование Kaggle Inclass по идентификации пользователя в Интернете по его последовательности переходов по сайтам.

UPD 01.2022: С февраля 2022 г. ML-курс ODS на русском возрождается под руководством Петра Ермакова couatl. Для русскоязычной аудитории это предпочтительный вариант (c этими статьями на Хабре – в подкрепление), англоговорящим рекомендуется mlcourse.ai в режиме самостоятельного прохождения.

Все материалы доступны на GitHub.
А вот видеозапись лекции по мотивам этой статьи в рамках второго запуска открытого курса (сентябрь-ноябрь 2017). В ней, в частности, рассмотрены два бенчмарка соревнования, полученные с помощью логистической регрессии.

Привет всем, я — сорокалетний программист-самоучка, а это моя история.

Пару недель назад я наткнулся на график распределения людей, интересующихся технологиями, ИТ и программированием. И он заставил меня задуматься о моей карьере.



Через каких-то 20 лет мне стукнет 60. И вероятность того, что я еще смогу заниматься тем, для чего был создан, составляет очень крошечную величину. Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 1990 году, через год после того, как мне на 14-тилетие родители подарили ПЭВМ «Микроша».

В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

В начале сентября мы, JetBrains, объявили о переходе на подписочную схему лицензирования.

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

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

Вкратце с учетом сегодняшних изменений новая лицензионная модель, которая вступит в силу 2 ноября, выглядит так:

Когда Вы запускаете свой продукт — Вы совершенно не знаете, что произойдет после запуска. Вы можете так и остаться абсолютно никому не нужным проектом, можете получить небольшой ручеек клиентов или сразу целое цунами пользователей, если про Вас напишут ведущие СМИ. Не знали и мы.

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

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

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

Сразу после запуска вся наша архитектура выглядела так:



Это была 1 виртуалка от Digital Ocean за 80$ в мес (4 CPU, 8 GB RAM, 80 GB SSD). Взяли с запасом. Так как “а вдруг лоад пойдет?”. Тогда мы действительно думали, что, вот, запустимся и тысячи пользователей ринут на нас. Как оказалось — привлечь и заманить пользователей та еще задача и нагрузка на сервер — последнее о чем стоит думать. Из технологий на тот момент была лишь Java 8 и Netty с нашим собственным бинарным протоколом на ssl/tcp сокетах (да да, без БД, spring, hibernate, tomcat, websphere и прочих прелестей кровавого энтерпрайза).

Все пользовательские данные хранились просто в памяти и периодически сбрасывались в файлы:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

На протяжении долгого времени я не до конца понимал htop. Я думал, что средняя загрузка [load average] в 1.0 означает, что процессор загружен на 50%, но это не совсем так. Да и потом, почему именно 1.0?

Затем я решил во всём разобраться и написать об этом. Говорят, что лучший способ научиться новому — попытаться это объяснить.

Вышел долгожданный релиз второй версии форумного движка vanilla. В блоге разработчиков появилось новость о релизе.

Что такое Vanilla?

Vanilla forums — это минималистичный форумный движок. Цель проекта — создать простой инструмент для онлайн-конференций с простой возможностью наращивания функционала. Нет, это не второй phpbb, это действительно очень упрощённый форум.

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

Несмотря на свою кажущуюся простоту этот движок «из коробки» даёт почти всё, что нужно большинству пользователей, как-то: разграничение прав, подфорумы и категории, html/bbcode/markdown.

Что нового?

Те, кто использовали первую версию этого движка, помнят, что он был совсем неприглядным, и для того, чтобы сделать из него «конфетку», пришлось бы очень сильно потрудиться. Со второй версией это уже в прошлом. Из коробки Vanilla имеет простой, но аккуратный дизнайн, которым вполне можно пользоваться. Более того, на официальном сайте в разделе дополнений есть ряд тем, подготовленных профессиональными дизайнерами. Так что, первое, что заметят те, кто пробовал первую версию — это безусловно то, что система стала привлекательнее, и ей даже можно пользоваться «из коробки».

Настолько ли «энергичен» Java 8 Stream API? Возможно ли «превращение» обработки сложных операций над коллекциями в простой и понятный код? Где та выгода от параллельных операций, и когда стоит остановиться? Это одни из многочисленных вопросов, встречающихся читателям. Попробуем разобрать подводные камни Stream API с Тагиром Валеевым aka @lany. Многие читатели уже знакомы с нашим собеседником по статьям, исследованиям в области Java, выразительным докладам на конференциях. Итак, без проволочек, начинаем обсуждение.

— Тагир, у вас отличные показатели на ресурсе StackOverflow (gold status в ветке «java-stream»). Как вы думаете, динамика применения Java 8 Stream API и сложность конструкций выросла (на основе вопросов и ответов на данном ресурсе)?

Всем привет. Эта статья продолжение 10к на ядро с конкретными примерами оптимизаций, которые были проделаны для повышения производительности сервера. С написания первой части прошло уже 5 мес и за это время нагрузка на наш продакшн сервер выросла с 500 рек-сек до 2000 с пиками до 5000 рек-сек. Благодаря netty, мы даже не заметили это повышение (разве что место на диске уходит быстрее).


(Не обращайте внимание на пики, это баги при деплое)

Эта статья будет полезна всем тем кто работает с netty или только начинает. Итак, поехали.

Нативный Epoll транспорт для Linux

Одна из ключевых оптимизаций, которую стоит использовать всем — это подключение нативного Epoll транспорта вместо реализации на java. Тем более, что с netty это означает добавить лишь 1 зависимость:

<dependency>
   <groupId>io.netty</groupId>
   <artifactId>netty-transport-native-epoll</artifactId>
   <version>${netty.version}</version>
   <classifier>linux-x86_64</classifier>
</dependency>

и автозаменой по коду осуществить замену следующих классов:

• NioEventLoopGroup → EpollEventLoopGroup
• NioEventLoop → EpollEventLoop
• NioServerSocketChannel → EpollServerSocketChannel
• NioSocketChannel → EpollSocketChannel

Дело в том, что java реализация для работы с не блокирующими сокетами реализуется через класс Selector, который позволяет вам эффективно работать с множеством соединений, но его реализация на java не самая оптимальная. Сразу по трем причинам:

• Метод selectedKeys() на каждый вызов создает новый HashSet
• Итерация по этому множеству создает iterator
• И ко всему прочему внутри метода selectedKeys() огромное количество блоков синхронизации

В моем конкретном случае я получил прирост производительности около 30%. Конечно же, эта оптимизация возможна только для Linux серверов.

На этой неделе случилось важное для нас событие — вышла первая версия языка программирования Kotlin! Так как почти вся разработка Kotlin велась в Питерском офисе компании JetBrains, многие хабровчане уже знают, что такое Kotlin и пробовали его на практике, поэтому этот пост больше для комментариев: задавайте любые вопросы и команда Kotlin ответит. Мы онлайн!

Сообществу Angular требуются свежие туториалы и учебники с простыми примерами на последних версиях библиотек. Правила, которые работали в Angular v0.X, уже не все действуют, в чём легко убедиться, а хочется разобрать что-то более сложное, чем фильтр из учебника на сайте и TODO-лист из примеров реализации (как, например, найденный для v1.0.3: jsfiddle.net/dakra/U3pVM ). Когда такие примеры покажутся слишком простыми, хочется посмотреть на развитие постановки задачи и приближенное к реальности приложение с некоторым оформлением стилей.

Предлагается вниманию пример приложения — работы с телефонной книгой в 2 списках: основного и «spam». Каждый из списков подвержен фильтрации (ну это — самое простое и встроенное в фреймворк), редактированию элементов, добавлению новых и удалению имеющихся. Одним кликом переносятся элементы из одного списка в другой, а подсветки элементов сделаны в стиле Bootstrap v.3.

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

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

Нам выпала возможность пообщаться с Тасо Дю Валем – CEO и сооснователем Toptal, самой большой в мире компании без единого физического рабочего «места».

Toptal объединяет под своим флагом 3% наиболее подходящих компаниям специалистов, отвечающим наивысшим требованиям профессионализма. 5 лет назад Toptal, обычная сеть фрилансеров, трудоустраивала лишь 25 разработчиков и такое же количество клиентов. Сегодня сеть Toptal – это тысячи программистов и дизайнеров (компания не говорит точную цифру) и более 2000 клиентов. Так как расходы на управление разработкой удвоились за последние пару лет, модель Toptal находит всё больше сторонников.

Тасо ведёт направление развития компании с 2010 года, когда после поглощения Google стартапа, в котором он работал (Slide), пути их развития разошлись. Как это ни странно, но в пределах Кремниевой Долины Toptal один из тех стартапов, о которых «мало говорят». Во-перых, потому, что команда основателей не привлекает гигантские инвестиционные раунды. Во-вторых, потому что ей это не очень нужно — при таком спросе на разработчиков, Toptal с некоторой неохотой принимал $1,4 миллиона от Андриссена Хоровитца, Адама Ди'Анжело и Адама Роквеллера из Quora. Сейчас оборот компании превышает $80 млн в год, а ведь идёт только шестой год.

На Леонардо Ди Каприо высокий спрос, а предложение низкое

— Тасо, наш первый вопрос классический. Когда к тебе пришла идея и понимание того, что это может быть новая и успешная компания?

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

В определённый момент я сказал себе: “Решение должно существовать. Люди должны иметь возможность узнать, что есть крутые специалисты и их можно нанять. И способ узнать об этом должен быть абсолютно масштабируем, а главное – ему должны доверять все участники”.

В принципе это и был момент старта Toptal как компании.

Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:

1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.

Подразумевается, что при желании заказчик может общаться со всеми членами команды. Оплата работы — почасовая.