Занятный факт на тему нишевости BWT — он также лежит в основе bowtie2 (hence the name), одного из стандартных биоинформатических инструментов для выравнивания фрагмента ДНК на геном.
Странная теория заговора, про большой бизнес-то. Вроде как текущее экодвижение наоборот борется против больших бизнесов и их неконтролируемых выбросов.
Рассчитывать на извержение супервулкана — это как рассчитывать на ядерную зиму. Конечно, это решит проблему глобального потепления, но есть нюанс.
Разумеется, никому не нужно CO2. До тех пор, пока внезапно всем оно будет нужно, но будет уже поздно.
Про растения это вы хорошо пошутили, конечно. Чтобы остановить глобальное потепление, придётся высаживать каждый год растений столько, чтобы количество зафиксированного в них углерода превзошло количество углерода, добытого в качестве полезных ископаемых (и впоследствии выброшенного в атмосферу). Где предлагаете это делать? Нам пахотные земли по-прежнему необходимы.
Ну, при большом желании, наверное, можно, но зачем. Так может с точки зрения кода даже хуже получиться, будут гипергранулированные компоненты, из которых что-то собрать это целый квест. Ну и каждая новая зависимость рискует потребовать каскада дальнейших разбиений произвольной глубины.
Если бы у меня изначально был PG, я бы, может, и не женился бы вовсе...
В питоне с dependency injection и type hints нельзя. Если объект А зависит от Б, Б — от В, а В — от А, и они в разных модулях, то всё, не получится объявить ни один из классов, не импортнув два других.
Ну и даже если бы можно было, я считаю, что лучше уж обзёрверы, чем порядок импортов, за которым нужно следить... Там в жирных компонентах у меня и по сорок импортов бывало.
Celery не требует maintenance скилла, но RabbitMQ/Redis требуют, а ещё они требуют CPU и памяти в кубернетисе. Кроме того, ещё одна внешняя зависимость — это ещё одна проблема в тестах: надо либо везде мокать и тогда нет уверенности, как оно будет работать с настоящим Celery, или разворачивать Celery и RabbitMQ/Redis на CI.
Ещё в Celery, насколько я помню, не очень хорошая поддержка отложенных тасок (оно все отложенные таски вычитывает из очереди и держит в памяти, пока момент не настанет). Поэтому я подумал, что мне проще сделать свой Aliceq.
Так это фактически и есть HTTP-запросы. Но сырой JSON в тестах печатать неудобно, да и рефакторить тоже неудобно.
Косты были минимальные, мы двумя-тремя нодами обходились и маленьким регистри, то есть всё в пределах $100 в месяц. Нагрузки мало, данных мало) MongoDB была поднятая руками на стейтфулсете дёшево и сердито.
Julia идеально подходит для решения такого рода задач.
Но почему? Каким образом малоизвестный язык, под который нет ни одной полноценной IDE и который ни в одной операционке не предустановлен, идеально подходит для решения таких задач?
Если тренер захочет заниматься, он зайдёт в приложение для атлетов и ему создастся сущность «атлет». Я не понимаю, о какой проблеме вы говорите.
Автоматический вывод средств мы не делали, отправляли расчёты руками (стартап же), но даже если бы сделали, списание раз в месяц и ин-апп кошелёк с выводом средств это две фундаментально разные, практически не пересекающиеся функциональности.
В реляционной БД будет всё то же самое. TrainerProfile, AthleteProfile, оба связаны 1-1 с AuthUser.
Как вы интересно всё разложили. Мне зарплата не шла, я ради опыта делал) И у нас было (и всё ещё остаётся) какое-то (небольшое) количество платящих пользователей, которые всем довольны, так что «никому не нужно» это смелое обобщение. В США вроде даже успешный конкурент с такой же моделью нашёлся.
Насчёт кубернетиса вы, возможно, правы, но я не соглашусь, что он как-то усложнил мне жизнь. Мне с kubectl легко и удобно. А по деньгам на наших нагрузках там нет принципиальной разницы, было бы $10 вместо $100 — это всё ещё копейки по сравнению с тем же маркетингом.
Насчёт сущностей — я всё ещё считаю, что разделить их было верным решением. У них много непересекающихся данных (у атлетов — анкета, биллинг и всё такое, у тренеров — публичный профиль и условия контракта) и не хотелось бы, чтобы они и там, и там были optional. К тому же, получится, что в коде постоянно фигурирует два разных «юзера» и их очень легко перепутать.
Насчёт приложений. В моём представлении поддерживать два специализированных приложения проще, чем одно универсальное. Кроме того, в текущем варианте мы делали тренерские фичи на более простом React Native, который мог редактировать даже я, а клиентские — на красивых нативных компонентах. Если бы я начинал заново, я бы оставил так же.
Для этого дисклеймер, что это техническая статья. А не полетело оно по бизнесовым причинам.
Но если вкратце, оказалось, что этот проект не очень хорошо ложится в концепцию венчурных инвестиций. Даже при занятии 100% рынка миллионов пользователей и миллиардных капитализаций бы не было, а значит, это не венчур. Поэтому в какой-то момент мы потеряли возможность привлекать новые инвестиции, а карманных денег на захват рынка нам не хватило.
«Когда я был junior’ом, делал тестовые направо и налево. Через полгода мне написал сотрудник компании, для которой я «проходил отбор». Спросил: «Как у тебя в задании реализован модуль Х? Мы внедрили твоё решение, но теперь всё падает». Оказалось, они просто скопировали мой код... но даже не потрудились сообщить, что я «не подошёл»».
Невыдуманные истории, о которых невозможно молчать.
Когда элементов будет обработано 2001, окно с 1002 по 2001 будет расположено в индексах с 1 по 1000. Давайте покажу. Текущее окно подчёркиваю снизу стрелкой ^.
К тому времени, как массив заполнится до конца, у нас, помимо актуального окна, смещающегося к концу, появится почти полная копия этого же окна в начале:
Почти полная, потому что элементы с 1001 по 1999 — это 999 элементов, то есть как раз на один меньше, чем нужно. Но следующим шагом мы допишем этот элемент в конец и снова получим полноценное окно длины 1000, начинающееся с первого элемента массива:
Ну. Массив длины 1999. Сначала заполняю первые 1000 индексов. Потом при поступлении очередного значения записываю его в i-ю и (i+1000)-ю позиции. При такой организации процесса у меня всегда есть непрерывный подмассив, содержащий последние 1000 элементов (см. пример для N=3 в моём комментарии выше). С этим непрерывным подмассивом делаю что хочу.
Медиана — не очень практичный пример (для медианы проще держать две кучи), а вот, например, FFT — вполне.
Насчёт быстрее — это надо проверять. Но сдвиги подразумевают, что время обработки не размазано равномерно, а раз в сколько-то итераций "тормозит" — подозреваю, для потоковой обработки это нежелательно.
Занятный факт на тему нишевости BWT — он также лежит в основе bowtie2 (hence the name), одного из стандартных биоинформатических инструментов для выравнивания фрагмента ДНК на геном.
Странная теория заговора, про большой бизнес-то. Вроде как текущее экодвижение наоборот борется против больших бизнесов и их неконтролируемых выбросов.
Рассчитывать на извержение супервулкана — это как рассчитывать на ядерную зиму. Конечно, это решит проблему глобального потепления, но есть нюанс.
Разумеется, никому не нужно CO2. До тех пор, пока внезапно всем оно будет нужно, но будет уже поздно.
Про растения это вы хорошо пошутили, конечно. Чтобы остановить глобальное потепление, придётся высаживать каждый год растений столько, чтобы количество зафиксированного в них углерода превзошло количество углерода, добытого в качестве полезных ископаемых (и впоследствии выброшенного в атмосферу). Где предлагаете это делать? Нам пахотные земли по-прежнему необходимы.
Ну, при большом желании, наверное, можно, но зачем. Так может с точки зрения кода даже хуже получиться, будут гипергранулированные компоненты, из которых что-то собрать это целый квест. Ну и каждая новая зависимость рискует потребовать каскада дальнейших разбиений произвольной глубины.
Если бы у меня изначально был PG, я бы, может, и не женился бы вовсе...
Your feedback is always a gift 💝
В питоне с dependency injection и type hints нельзя. Если объект А зависит от Б, Б — от В, а В — от А, и они в разных модулях, то всё, не получится объявить ни один из классов, не импортнув два других.
Ну и даже если бы можно было, я считаю, что лучше уж обзёрверы, чем порядок импортов, за которым нужно следить... Там в жирных компонентах у меня и по сорок импортов бывало.
Celery не требует maintenance скилла, но RabbitMQ/Redis требуют, а ещё они требуют CPU и памяти в кубернетисе. Кроме того, ещё одна внешняя зависимость — это ещё одна проблема в тестах: надо либо везде мокать и тогда нет уверенности, как оно будет работать с настоящим Celery, или разворачивать Celery и RabbitMQ/Redis на CI.
Ещё в Celery, насколько я помню, не очень хорошая поддержка отложенных тасок (оно все отложенные таски вычитывает из очереди и держит в памяти, пока момент не настанет). Поэтому я подумал, что мне проще сделать свой Aliceq.
Так это фактически и есть HTTP-запросы. Но сырой JSON в тестах печатать неудобно, да и рефакторить тоже неудобно.
Косты были минимальные, мы двумя-тремя нодами обходились и маленьким регистри, то есть всё в пределах $100 в месяц. Нагрузки мало, данных мало) MongoDB была поднятая руками на стейтфулсете дёшево и сердито.
Рассмотрел бы такой вариант, если бы под рукой был Dart-разработчик, но, к сожалению, никогда не видел таких вживую.
Но почему? Каким образом малоизвестный язык, под который нет ни одной полноценной IDE и который ни в одной операционке не предустановлен, идеально подходит для решения таких задач?
Если тренер захочет заниматься, он зайдёт в приложение для атлетов и ему создастся сущность «атлет». Я не понимаю, о какой проблеме вы говорите.
Автоматический вывод средств мы не делали, отправляли расчёты руками (стартап же), но даже если бы сделали, списание раз в месяц и ин-апп кошелёк с выводом средств это две фундаментально разные, практически не пересекающиеся функциональности.
В реляционной БД будет всё то же самое. TrainerProfile, AthleteProfile, оба связаны 1-1 с AuthUser.
Инвестор не платит за горящие глаза, у него своя голова на плечах и гораздо больший опыт оценки перспективности бизнесов, чем у нас.
Как вы интересно всё разложили. Мне зарплата не шла, я ради опыта делал) И у нас было (и всё ещё остаётся) какое-то (небольшое) количество платящих пользователей, которые всем довольны, так что «никому не нужно» это смелое обобщение. В США вроде даже успешный конкурент с такой же моделью нашёлся.
Насчёт кубернетиса вы, возможно, правы, но я не соглашусь, что он как-то усложнил мне жизнь. Мне с kubectl легко и удобно. А по деньгам на наших нагрузках там нет принципиальной разницы, было бы $10 вместо $100 — это всё ещё копейки по сравнению с тем же маркетингом.
Насчёт сущностей — я всё ещё считаю, что разделить их было верным решением. У них много непересекающихся данных (у атлетов — анкета, биллинг и всё такое, у тренеров — публичный профиль и условия контракта) и не хотелось бы, чтобы они и там, и там были optional. К тому же, получится, что в коде постоянно фигурирует два разных «юзера» и их очень легко перепутать.
Насчёт приложений. В моём представлении поддерживать два специализированных приложения проще, чем одно универсальное. Кроме того, в текущем варианте мы делали тренерские фичи на более простом React Native, который мог редактировать даже я, а клиентские — на красивых нативных компонентах. Если бы я начинал заново, я бы оставил так же.
Для этого дисклеймер, что это техническая статья. А не полетело оно по бизнесовым причинам.
Но если вкратце, оказалось, что этот проект не очень хорошо ложится в концепцию венчурных инвестиций. Даже при занятии 100% рынка миллионов пользователей и миллиардных капитализаций бы не было, а значит, это не венчур. Поэтому в какой-то момент мы потеряли возможность привлекать новые инвестиции, а карманных денег на захват рынка нам не хватило.
Две недели на статью на 50 печатных страниц... Насколько я представляю, текст примерно на 90% сгенерирован ИИ?
Эта статья написана нейронкой?
Невыдуманные истории, о которых невозможно молчать.
Есть новости?)
Когда элементов будет обработано 2001, окно с 1002 по 2001 будет расположено в индексах с 1 по 1000. Давайте покажу. Текущее окно подчёркиваю снизу стрелкой ^.
Сначала заполняем пустой массив:
Дальше, поскольку нам нужны только последние 1000 элементов, единичку можно затирать:
К тому времени, как массив заполнится до конца, у нас, помимо актуального окна, смещающегося к концу, появится почти полная копия этого же окна в начале:
Почти полная, потому что элементы с 1001 по 1999 — это 999 элементов, то есть как раз на один меньше, чем нужно. Но следующим шагом мы допишем этот элемент в конец и снова получим полноценное окно длины 1000, начинающееся с первого элемента массива:
Ну. Массив длины 1999. Сначала заполняю первые 1000 индексов. Потом при поступлении очередного значения записываю его в i-ю и (i+1000)-ю позиции. При такой организации процесса у меня всегда есть непрерывный подмассив, содержащий последние 1000 элементов (см. пример для N=3 в моём комментарии выше). С этим непрерывным подмассивом делаю что хочу.
Медиана — не очень практичный пример (для медианы проще держать две кучи), а вот, например, FFT — вполне.
Почему?.. По-моему, расходы памяти просто в два раза больше и всё.
Насчёт быстрее — это надо проверять. Но сдвиги подразумевают, что время обработки не размазано равномерно, а раз в сколько-то итераций "тормозит" — подозреваю, для потоковой обработки это нежелательно.