Спасибо, интересно было почитать. Позволю высказать свое мнение по данной теме.
Я бы начал с более детального рассмотрения предоставленного юзкейса. И в первую очередь следовало бы ограничить зону ответственности сервиса. Когда границы определены, можно найти уже и стейкхолдеров (в данном случае другие сервисы).
В статье немного размыты границы между функциональными и не функциональными требованиями к системе. Однако на базе юзкейса будет намного легче определить функциональные требования к сервису (кто и что от него хотят, и какие функции он, сервис, должен предоставить, что бы удовлетворить требования).
Нефункциональные же требования, скорее всего на интервью мало чем помогут (разве что для рассуждений на тему выбора технологий и реализации), но уточнять всегда полезно.
Опять же, когда проработали системные функции сервиса, встает вопрос о данных, не о конкретной реализации API, а именно о данных, чем и как обмениваются между собой сервис со стейкхолдерами (другими сервисами, пользователем и тд.).
Ну и далее по списку, на базе функциональной архитекруты, можно подумать о логической архитекруте, что можно в некоторых случаях один к одному перенести на физический уровень (уровень реализации непосредственно софта) и тд.
Читаю статю я задался вопросом, а отчего такой уровень детализации, вроде жизненного цикла данных и расчета количество требуемых процессоров, если речь идет о системной архитектуре. Очень часто смешивание архитектурных уровней ведет к дальнейшему хаосу, и к тому что никто систумную архитектуру больше не учитывает, и тот же Вася берет и просто что то там реализовавает. :)
70к/1760*2 это около 80€ в час. Вполне себе реалистичный штундезатц ( по гулпу даже меньше среднего, но то гулп просто выбирает из тех кто указал свою желаемую почасовую ставку для поиска проекта).
80 * 1760 получаем почти 141к .. что и так по формуле ясно, в два раза выше готовой зарплаты на найме.
Но что мы имеем на найме.. пенсия.. так она по пунктам считается. Арбайтслосгельд при потере работы вроде только 9 месяцев платят.. а то может уже и 6... Ну мед страховку половину платит работодатель.. так 140к в год куда выгоднее.. после вычета налога .. это где то дополнительные +40к которые фрилансер потратит на свою пенсию, страховку, поиск клиентов и тд.
Вопрос скорее в некотором психологическом комфорте. В долгосрочной перспективе найм может быть и более выгодным, ибо по статистике фрилансеров в среднем работают больше 40 часов в неделю, но сможешь ли ты скажем 20-30 лет работать в таком темпе, вот уж вопрос. Ну и найм в Германии плох тем что тут везде тарифы.. если на найме и вне тарифа тогда ситуация обычно более приятная.
Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Например фреймворк Scrum прямо запрещает отказываться от дейли встреч.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
Я бы интерпретировал ваш результат таким образом: раз модель выдает рандомный результат, а 50% можно смело считать рандомом (хотя всегда имеет смысл сравнить с настоящим рандом), то у вас просто нет зависимостей между x-ми и y-ми. Т.е. модель выступает в качестве простого инструмента выявления статистических зависимостей. И раз модель не находит этих зависимостей, то в вашем алгоритме торговли нет никакого эджа :), либо вы упускаете какие либо данные которые ваш мозг воспринимает как впомогательные для принятия решений, если уж руками ваш торговый алгоритм зарабатывает.
Отсюда следует, что модель следует улучшать лишь тогда, когда у вас есть некоторое приимущество, и ваш алгоритм его использует.
Numba будет медленее чем реализация на чистом c++. Если говорить про питон, то я бы посоветовал посмотреть в сторону RAPIDS (у них там есть реализация датафреймов как пандас но на gpu), но только если имеется cuda. :)
зы. пару месяцев назад ради интереса я тут потестил как ускорить расчет максимальной возможной просадки используя монтекарло и лучший результат конечно был c++ cuda, но из питона мы можем отлично получить почти такую же скорость... Постить тут не буду, но кому интересно может глянуть на моем ютбчике.
да я просто поторопился с комментарием, видимо malloc меня очень задел. Почти во всех проектах которых я работал, динамическое выделение памяти запрещено стандартами. Ну и еще пару мелочей, а так да.. еще раз повторюсь, выглядит все интересно :)
И то верно, cpython, gtk... для pc проектов вполне возможно. Хотя наверное я очень критичен с некоторыми изменениями, возможно наверное и в эмбедед это все отлично вписать.
Начало статьи было довольно увлекательным :). Простите, не хочу Вас критиковать, но некоторые утверждения в вашей статье не верны, попросту по тому, что люди все же еще не знают точно как работает мозг.
Что бы создать действительно работающий AGI, нам надо понять как работает неокортекс в нашей голове, и я полснотью придерживаюсь и соглашаюсь в этом с мистером Джефом Хокинсом. Кстати, не так давно вышла его новая книга «A Thousand Brains», он там описывает теоретический фреймворк работы неокортекса. В целом думаю, вам может быть интересны работы его команды, гляньте в гугле по слову numenta и загляните на их гитхаб.
Еще мне кажется может быть интреесным обратить внимание на капсульные нейронные сети, там присутствует механизм отслеживания относительности признаков друг к другу.
Жаль конечно, что мы еще очень очень далеки от мало мальско разумного искуственного интелекта :), но кто знает, может уже в следующие 10-20 лет что то и получится.
Чаще всего в организациях уже имеется стандарт ведения документации, а что то изменить в уже устоявшейся системе часто бывает почти невозможно, особенно если это немецкие компании. :)
Asciidoc отличный продукт, по большей части в своей работе я его правда использую для составления некоторой сопуствующей документации, или быстрого описания аритектуры.
Люксембург отличная страна для жизни! Но мне всегда казалось, что там не такой широкий выбор IT проектов, чем у тех же немцев.
… Трёхэтажный дом в Германии с участком, гаражом и сауной — стоит 400,000€, ...
Про Германию малость не так, 400к конечно дом можно купить, но вопрос большой где именно. На юге за такую сумму даже шалаш не продадут :), а вот на северовостоке, таки да, можно замок приобрести.
Спасибо, интересно было почитать.
Позволю высказать свое мнение по данной теме.
Я бы начал с более детального рассмотрения предоставленного юзкейса. И в первую очередь следовало бы ограничить зону ответственности сервиса. Когда границы определены, можно найти уже и стейкхолдеров (в данном случае другие сервисы).
В статье немного размыты границы между функциональными и не функциональными требованиями к системе. Однако на базе юзкейса будет намного легче определить функциональные требования к сервису (кто и что от него хотят, и какие функции он, сервис, должен предоставить, что бы удовлетворить требования).
Нефункциональные же требования, скорее всего на интервью мало чем помогут (разве что для рассуждений на тему выбора технологий и реализации), но уточнять всегда полезно.
Опять же, когда проработали системные функции сервиса, встает вопрос о данных, не о конкретной реализации API, а именно о данных, чем и как обмениваются между собой сервис со стейкхолдерами (другими сервисами, пользователем и тд.).
Ну и далее по списку, на базе функциональной архитекруты, можно подумать о логической архитекруте, что можно в некоторых случаях один к одному перенести на физический уровень (уровень реализации непосредственно софта) и тд.
Читаю статю я задался вопросом, а отчего такой уровень детализации, вроде жизненного цикла данных и расчета количество требуемых процессоров, если речь идет о системной архитектуре. Очень часто смешивание архитектурных уровней ведет к дальнейшему хаосу, и к тому что никто систумную архитектуру больше не учитывает, и тот же Вася берет и просто что то там реализовавает. :)
А поделитесь цифрой "предложения от которого невозможно отказаться"? Просто ж у немцев везде тарифные сетки в больших компаниях.
Что то с формулой не так..
70к/1760*2 это около 80€ в час. Вполне себе реалистичный штундезатц ( по гулпу даже меньше среднего, но то гулп просто выбирает из тех кто указал свою желаемую почасовую ставку для поиска проекта).
80 * 1760 получаем почти 141к .. что и так по формуле ясно, в два раза выше готовой зарплаты на найме.
Но что мы имеем на найме.. пенсия.. так она по пунктам считается. Арбайтслосгельд при потере работы вроде только 9 месяцев платят.. а то может уже и 6... Ну мед страховку половину платит работодатель.. так 140к в год куда выгоднее.. после вычета налога .. это где то дополнительные +40к которые фрилансер потратит на свою пенсию, страховку, поиск клиентов и тд.
Вопрос скорее в некотором психологическом комфорте. В долгосрочной перспективе найм может быть и более выгодным, ибо по статистике фрилансеров в среднем работают больше 40 часов в неделю, но сможешь ли ты скажем 20-30 лет работать в таком темпе, вот уж вопрос. Ну и найм в Германии плох тем что тут везде тарифы.. если на найме и вне тарифа тогда ситуация обычно более приятная.
а получить больше 100к в соседней Германии, так это еще ооооочень постараться надо %)
Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
Да походу пункт номер 4 самый главный. Спать нужно достаточно :) и тогда все будет ок.
Я бы интерпретировал ваш результат таким образом: раз модель выдает рандомный результат, а 50% можно смело считать рандомом (хотя всегда имеет смысл сравнить с настоящим рандом), то у вас просто нет зависимостей между x-ми и y-ми. Т.е. модель выступает в качестве простого инструмента выявления статистических зависимостей. И раз модель не находит этих зависимостей, то в вашем алгоритме торговли нет никакого эджа :), либо вы упускаете какие либо данные которые ваш мозг воспринимает как впомогательные для принятия решений, если уж руками ваш торговый алгоритм зарабатывает.
Отсюда следует, что модель следует улучшать лишь тогда, когда у вас есть некоторое приимущество, и ваш алгоритм его использует.
Numba будет медленее чем реализация на чистом c++. Если говорить про питон, то я бы посоветовал посмотреть в сторону RAPIDS (у них там есть реализация датафреймов как пандас но на gpu), но только если имеется cuda. :)
зы. пару месяцев назад ради интереса я тут потестил как ускорить расчет максимальной возможной просадки используя монтекарло и лучший результат конечно был c++ cuda, но из питона мы можем отлично получить почти такую же скорость... Постить тут не буду, но кому интересно может глянуть на моем ютбчике.
да я просто поторопился с комментарием, видимо malloc меня очень задел. Почти во всех проектах которых я работал, динамическое выделение памяти запрещено стандартами. Ну и еще пару мелочей, а так да.. еще раз повторюсь, выглядит все интересно :)
И то верно, cpython, gtk... для pc проектов вполне возможно. Хотя наверное я очень критичен с некоторыми изменениями, возможно наверное и в эмбедед это все отлично вписать.
Хохо, эко Вы заморочились, но в целом очень прикольно.
Интересно, а в каких проектах промышленной разработки в принципе такой код может быть разрешен? Есть у меня подозрения, что почти нигде.
Что бы создать действительно работающий AGI, нам надо понять как работает неокортекс в нашей голове, и я полснотью придерживаюсь и соглашаюсь в этом с мистером Джефом Хокинсом. Кстати, не так давно вышла его новая книга «A Thousand Brains», он там описывает теоретический фреймворк работы неокортекса. В целом думаю, вам может быть интересны работы его команды, гляньте в гугле по слову numenta и загляните на их гитхаб.
Еще мне кажется может быть интреесным обратить внимание на капсульные нейронные сети, там присутствует механизм отслеживания относительности признаков друг к другу.
Жаль конечно, что мы еще очень очень далеки от мало мальско разумного искуственного интелекта :), но кто знает, может уже в следующие 10-20 лет что то и получится.
Про Германию малость не так, 400к конечно дом можно купить, но вопрос большой где именно. На юге за такую сумму даже шалаш не продадут :), а вот на северовостоке, таки да, можно замок приобрести.