Дело в том что в Go slice внутри это обычный массив с capacity. Соответственно если capacity превышено то создается новый массив с увеличенным capacity, в него переписываются старые значения и добавляются новые. Если это делается в одном потоке то все норм, но в многопоточном варианте будут проблемы. Все таки в go идеоматическим вариантом было бы передача значений по каналам и аккумулирование детей в родительском потоке отвечающем за текущий набор детей.
Здесь самый на мой взгляд интересный вопрос в плане производительности. Скажем если сгенерить большое дерево (ну скажем пусть будет 1 млн узлов) и выбрать из него процентов 5 данных что получится по скорости и потреблению памяти? Причем если в плане haskel в целом замеров в сети много то вот сравнение go vs C# было бы интересным ИМХО
Тут такое дело, что для налогового резидента — да достаточно на 7 месяцев выехать, а вот для валютного (появившегося в законах кажется в 12 году) даже на 1 день приезд меняет статус. По поводу получения доходов на счет фирмы согласен. Но здесь возникает вопрос как их потом легально получить. По идее если мы остаемся в рамках 100% белых схем надо о доходах с компаний тоже в налоговую сообщать и уплачивать налоги с распределенной прибыли. Кроме того эти доходы должны сразу приходить на счет физлица в РФ. Наверное если решить эти проблемы и разобраться с валютным контролем, схема вроде более менее легальна
Я немного дополню еще несколько пунктов:
5) Кажется с 2012 года введен термин валютный резидент, в соответствии с которым если Вы получаете доходы на счет за границей идет штраф в размере 75-100% от транзакции (конечно чистое совпадение)
6) Погуглите чисто ради интереса про законопроект об отбирании последнего жилья (вроде еще не приняли, хотя я не уверен)
7) Налоговая как Вы правильно отметили белая и пушистая ровно до того момента пока не придет увеличенный план по сбору налогов
Как резюме: заводить трактор — правильная стратегия, но если ее выполнять, нужно избавиться от всех активов и организации в РФ юрисдикции, вывезти себя за пределы РФ и ни на день сюда не возвращаться чтобы не нарушать наши законы.
Все перечисленное чисто мое оценочное суждение.
Можно я вброшу несколько мыслей по данному поводу:
1) На сегодняшний день (ИМХО) не существует полностью легальных способов получать деньги от людей по всему миру на счет компании в РФ юрисдикции (вариант с прямым перечислением на счет ИП не рассматриваем как нереальный для интернет бизнеса, где много мелких транзакций)
2) При непробитии чека штраф составляет 75-100% от выручки (+ штраф не освобождает от налогов)
3) ИП отвечает всем своим имуществом
4) 11 марта 2018 года будут выборы президента РФ, после которых нужно будет срочно закрывать стремительно разрастающуюся дыру в бюджете
На самом деле если совсем извращаться на PHP можно было бы взять Thread safe версию и сделать php extension на C++ и в нем уже хранить все данные прямо в памяти. Правда я так понимаю придется использовать apache а он вроде как работает через блокирующие сокеты и соответственно решение получится все равно медленным. Кстати если посмотреть на Java решения, вроде бы там тоже в основном через JNI использовали код на C++
Тут конечно организаторы наверное еще просветят какие технологии использованы в топе, но я предполагаю что победил такой стек: C++, сервер на голом epoll, lockfree структура для хранения данных в памяти. По сути изначально видимо был тонкий намек на использование tarantool, но серверов на tarantool в топе не заявлено. В целом выбор вполне логичный с учетом отсутствия требования на персистентность данных(хотя бы WAL) и необязательность соответствие ACID
По вашему комментарию (https://habrahabr.ru/post/329478/?reply_to=10241628#comment_10241608) понял о чем Вы говорите. Да с C++ есть проблемы в области кроссплатформенности. Есть какие то подвижки в правильном направлении (например при использовании CMake) к унификации, но в плане организации сборки, нормального кроссплатформенного решения я не нашел. Хотя мне кажется здесь проблема глубже. В С++ не хватает общего пакетного менеджера и нормального управления зависимостями. Может быть если бы приняли модули в 20 стандарте стало бы проще организовать сборку
А если это был упрёк, что веб-стэк трудно завести где-то ещё
Нет как раз наоборот. Веб стэк легко завести на чем угодно OS X/Win/Ubuntu/CentOS итд
Увы, я против веб. Не везде он применим и бэкэнд во многих случаях даже у веба далеко не js.
Я лично без проблем заводил под Win node.js, php/nginx, php/apache, golang, rust(правда на ранних версиях была проблема с openssl), java бэкенд. Мне кажется это покрывает процентов 80 всех вариантов
Плюс куда? Винде? Простите, кроссплатформенные JetBrains и Sublime мне гораздо ближе.
JetBrains тяжеловат, плюс к тому будучи написанным на java работает на любой оси. Sublime — да, неплох
Осталось добавить их в стандартную поставку, были проблемы с установкой дополнительного софта в одной организации.
мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
На самом деле есть еще вариант кросс платформенного приложения под Win/OS X + веб сервисы. Разрабатывать под винду из под Wine то еще "удовольствие". Для комфортной разработки под OS X так или иначе желателен мак. Зато весь веб стек заводится с полпинка на Windows. Вопрос c консолью тоже закрывается очень легко. У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие. Сейчас вот появилась еще Windows Subsystem for Linux. Вопрос \n vs \r\n тоже закрывается прямо при установке git (checkout \r\n push \n). Раньше еще был плюс в виде Notepad++ — на глаз один из самых быстрых редакторов в плане открытия файла. С выходом VSCode это уже не так актуально.
Правда есть один нюанс. win10 ужасно не стабильная и тормозящая ось. А вот win7 была вполне себе ничего
А можно какие то пруфы данного утверждения? Просто если с подзапросами я согласен, то join при правильном проектировании БД обычно проблем не вызывает. Обычно на мускуле самая большая проблема group by. Уже на 20млн записей посчитать статистику становится проблемой
В изначальном варианте в Go подозрительно выглядит строка
Дело в том что в Go slice внутри это обычный массив с capacity. Соответственно если capacity превышено то создается новый массив с увеличенным capacity, в него переписываются старые значения и добавляются новые. Если это делается в одном потоке то все норм, но в многопоточном варианте будут проблемы. Все таки в go идеоматическим вариантом было бы передача значений по каналам и аккумулирование детей в родительском потоке отвечающем за текущий набор детей.
Здесь самый на мой взгляд интересный вопрос в плане производительности. Скажем если сгенерить большое дерево (ну скажем пусть будет 1 млн узлов) и выбрать из него процентов 5 данных что получится по скорости и потреблению памяти? Причем если в плане haskel в целом замеров в сети много то вот сравнение go vs C# было бы интересным ИМХО
https://github.com/YousefED/typescript-json-schema вот например генерация схем из исходников typescript. И например вот валидатор https://github.com/epoberezkin/ajv
Есть еще jsonschema https://json-schema.org/implementations.html
**gydfdtr@67890
Спасибо за интересную наводку!
Это уже интересно. А можно вкратце 2 вопроса:
1) Почему 12млн?
2) Что такое КИК?)))
Тут такое дело, что для налогового резидента — да достаточно на 7 месяцев выехать, а вот для валютного (появившегося в законах кажется в 12 году) даже на 1 день приезд меняет статус. По поводу получения доходов на счет фирмы согласен. Но здесь возникает вопрос как их потом легально получить. По идее если мы остаемся в рамках 100% белых схем надо о доходах с компаний тоже в налоговую сообщать и уплачивать налоги с распределенной прибыли. Кроме того эти доходы должны сразу приходить на счет физлица в РФ. Наверное если решить эти проблемы и разобраться с валютным контролем, схема вроде более менее легальна
Я немного дополню еще несколько пунктов:
5) Кажется с 2012 года введен термин валютный резидент, в соответствии с которым если Вы получаете доходы на счет за границей идет штраф в размере 75-100% от транзакции (конечно чистое совпадение)
6) Погуглите чисто ради интереса про законопроект об отбирании последнего жилья (вроде еще не приняли, хотя я не уверен)
7) Налоговая как Вы правильно отметили белая и пушистая ровно до того момента пока не придет увеличенный план по сбору налогов
Как резюме: заводить трактор — правильная стратегия, но если ее выполнять, нужно избавиться от всех активов и организации в РФ юрисдикции, вывезти себя за пределы РФ и ни на день сюда не возвращаться чтобы не нарушать наши законы.
Все перечисленное чисто мое оценочное суждение.
Можно я вброшу несколько мыслей по данному поводу:
1) На сегодняшний день (ИМХО) не существует полностью легальных способов получать деньги от людей по всему миру на счет компании в РФ юрисдикции (вариант с прямым перечислением на счет ИП не рассматриваем как нереальный для интернет бизнеса, где много мелких транзакций)
2) При непробитии чека штраф составляет 75-100% от выручки (+ штраф не освобождает от налогов)
3) ИП отвечает всем своим имуществом
4) 11 марта 2018 года будут выборы президента РФ, после которых нужно будет срочно закрывать стремительно разрастающуюся дыру в бюджете
А можно вопрос, раз уж Вы в теме? А разве netty проигрывает epoll?
На самом деле если совсем извращаться на PHP можно было бы взять Thread safe версию и сделать php extension на C++ и в нем уже хранить все данные прямо в памяти. Правда я так понимаю придется использовать apache а он вроде как работает через блокирующие сокеты и соответственно решение получится все равно медленным. Кстати если посмотреть на Java решения, вроде бы там тоже в основном через JNI использовали код на C++
Тут конечно организаторы наверное еще просветят какие технологии использованы в топе, но я предполагаю что победил такой стек: C++, сервер на голом epoll, lockfree структура для хранения данных в памяти. По сути изначально видимо был тонкий намек на использование tarantool, но серверов на tarantool в топе не заявлено. В целом выбор вполне логичный с учетом отсутствия требования на персистентность данных(хотя бы WAL) и необязательность соответствие ACID
Мне всегда казалось, что большой switch надо разруливать паттерном Commander
Если Вас интересует именно вопрос копирования можно использовать http://gnuwin32.sourceforge.net/
Обе команды делают одно и то же
Есть еще cygwin, MinGW32 и WSL
По вашему комментарию (https://habrahabr.ru/post/329478/?reply_to=10241628#comment_10241608) понял о чем Вы говорите. Да с C++ есть проблемы в области кроссплатформенности. Есть какие то подвижки в правильном направлении (например при использовании CMake) к унификации, но в плане организации сборки, нормального кроссплатформенного решения я не нашел. Хотя мне кажется здесь проблема глубже. В С++ не хватает общего пакетного менеджера и нормального управления зависимостями. Может быть если бы приняли модули в 20 стандарте стало бы проще организовать сборку
Нет как раз наоборот. Веб стэк легко завести на чем угодно OS X/Win/Ubuntu/CentOS итд
Я лично без проблем заводил под Win node.js, php/nginx, php/apache, golang, rust(правда на ранних версиях была проблема с openssl), java бэкенд. Мне кажется это покрывает процентов 80 всех вариантов
JetBrains тяжеловат, плюс к тому будучи написанным на java работает на любой оси. Sublime — да, неплох
мне кажется не сложнее установки нужных пакетов из aptitude, brew итд.
На самом деле есть еще вариант кросс платформенного приложения под Win/OS X + веб сервисы. Разрабатывать под винду из под Wine то еще "удовольствие". Для комфортной разработки под OS X так или иначе желателен мак. Зато весь веб стек заводится с полпинка на Windows. Вопрос c консолью тоже закрывается очень легко. У меня скажем есть в консоли bash, все утилиты типа grep, awk и прочие. Сейчас вот появилась еще Windows Subsystem for Linux. Вопрос \n vs \r\n тоже закрывается прямо при установке git (checkout \r\n push \n). Раньше еще был плюс в виде Notepad++ — на глаз один из самых быстрых редакторов в плане открытия файла. С выходом VSCode это уже не так актуально.
Правда есть один нюанс. win10 ужасно не стабильная и тормозящая ось. А вот win7 была вполне себе ничего
Давайте
Хочется хотя бы на пальцах понять на каких объемах и каких индексах у join c 10 таблицами начинаются проблемы
А можно какие то пруфы данного утверждения? Просто если с подзапросами я согласен, то join при правильном проектировании БД обычно проблем не вызывает. Обычно на мускуле самая большая проблема group by. Уже на 20млн записей посчитать статистику становится проблемой