спасибо! вариантов для различных локалей нет? хотя.. в 99% дефолтных весов более чем достаточно :)
p.s. с удовольствием бы почитал, как у вас организована многопоточность, если можно.
а в целом - успехов, вы выбрали довольно трудную дорожку - тут мало хороший продукт сделать, нужно доказать компаниям/разрабочикам, что замена бд с привычной на новую в их архитектуре.. это вот ни разу не легче задачка будет.
нет, я имел ввиду - как устроено сопоставление? вы ответили - "сопоставляются через сопоставление" (шта?) и "в документации есть описание" (нет). мой вопрос, если более детально - насколько поддерживается CLDR, сколько уровней в ключе (отсюда - поддерживается ли регистронезависимость), есть-ли поддержка правил сортировки чисел в строках?
очень и очень рекомендую исследовать свой скомпилированный код на Rust (например, с помощью godbolt.org, cargo-asm) - это даст отличный буст в понимании языка.
простите, я статью не читал - так, глянул мельком. (сейчас мой рейтинг полетит вниз... мда..)
претензии такие - сложность статьи - не "сложная". почему нет тарантула? почему нет бенчей? если статья - "сложная" - должно быть обоснование почему - так, а почему - этак?
я имею ввиду - архитектура in-memory базы? сама работа с памятью? структура базы, индексы? банальная многопоточность?
на данный момент, статья выглядит как устаревший гайд для новичков, уж простите.
Максим, спасибо за статью. мне, как разработчику своего ПО - не столько интересно про космос, а хотелось-бы методологию оценки текущего состояния разработки ) возможность получения общих метрик в процессе разработки, что-ли. ещё раз - спасибо, очень приятно читается
нет, простите, но нет. это какой-то нелепый тест, который показывает непонятно что. поясню. для 99% пользователей - нужен просто редактор текста, где то что видишь = то что печатаешь. wysiwyg с печатью. эксель - то же самое, только в сторону простой бд. по факту - лучшее программное обеспечение тут - то, которое обеспечивая совместимость банально удобно и не жрет ресурсы. всё.
а. тут так. я не представляю эту шкалу. т.е. они хоть и близкие по назначению - но очень разные, нельзя тут проводить оценку по количеству фишек. детали - то, что я делаю, можно принять за "что-то вроде атлассиан". и все замещают и замещают. для меня же - вот я несколько лет назад был не согласен с этой подачей. ну не нравится мне - та же система документации - confluence - где-то избыточна, и неудобна. я работал на крупную компанию, и они сначала выбрали notion, а потом стали делать своё (не знаю, как сейчас у них). нельзя просто "я буду делать то-то и то-то, только круче". важно понять - что, зачем, почему. моя концепция разработки - сделать удобно. я, кроме того, что программист с опытом в четверть века - специалист по ui/ux.
возвращаясь к вопросу - как оценить кейсы, когда о них никто не задумывался? или - я вот не хочу просто по историческим причинам, в ущерб своему доходу делать подписки. до 5 пользователей бесплатно, или лайфтайм лицензия на пользователя. это вот влияет?
имеется ввиду оценка, насколько наличие функционала полной версии повлияет на принятие положительного решения о покупке? вопрос - как измерить, тут несколько факторов.
немного другой таргетинг, есть ключевые особенности, которые для одной группы могут быть важны, а для другой - малозначительны. как это измерить?
p.s. хотел проголосовать за комментарий, но промахнулся :( а исправить почему-то нельзя :( простите. (но плюсанул в карму - пожалуйста, пишите ещё, подписался)
спасибо за статью! в контексте того, что происходит в нашем импортозамещении - актуально.
довольно длительное время (полтора года) работаю над крупным проектом, и на определенный момент встал перед выбором - выпустить MVP, обрезав функционал и положиться на использование сторонних библиотек, или упереться лбом и вести разработку до релиза в том виде, в котором изначально задумывался продукт.
покрутил-повертел MVP.. и продолжил писать - в этом виде система превращалась в ещё одну из десятков аналогичных, с разницей в виде монетизации и с перекрашенными кнопками, с напрочь убитой изначальной идеей. и эта самая изначальная идея просто-напросто не получила бы развития в дальнейшем - костыли/сторонние либы вросли-бы в код, и вместо внедрения ключевых фишек пришлось-бы сосредоточиться на обрастании (не всем нужным) функционалом.
что осознал (или подтвердил на личном примере), двигаясь по дорожке разработки без MVP:
вы не сможете оценить востребованность продукта на более-менее ранней стадии, что позволило бы более-менее безболезненно отказаться от концепции / сменить вектор разработки при её провале.
готовьтесь к тому, что бюджет закончится. совсем. время разработки увеличилось, притока денег нет.
проблемы найма - см. предыдущий пункт, плюс - на ранней стадии требуются действительно скилловые (читай - высокооплачиваемые) сотрудники. также возрастают затраты на контроль разработки, повышенные требования к ведению документации, большая нагрузка на позицию архитектора приложения. т.е. либо готовиться к соло-разработке, либо нужно иметь действительно внушительный бюджет.
старт будет труднее - если в случае с MVP ещё есть какой-то бюджет на рекламу - то тут придётся покрутиться.
надо быть морально готовым к провалу. я не к тому, что нацелен на него, конечно, но сколько раз видел коллег с горящими глазами - "моя убер-система нагнет рынок!" - и... околонулевые продажи, разочарование. в этом случае особенно тяжело воспринимается затраченное время. просто стоит расценивать как опыт, плюс наработки никуда не денутся.
если востребованность продукта на выбранном направлении высокая - конечно же, появятся решения конкурентов, которые пошли по пути MVP. и разработку начать могли позже, и нишу займут. ещё раз вспомнить ключевые фичи, ради чего всё начато и к чему стремишься придти.
не знаю, ребят. отметился - посмотрим, во что это выльется. а про свой стартап я напишу тоже на хабре - только сначала про тексты расскажу - как обещал )
да, тут я лажанулся - исправлю. занимаюсь серверными приложениями, десктоп - линукс и макось, а виндой пользовался последний раз лет 15 назад.. спасибо!
спасибо! вариантов для различных локалей нет? хотя.. в 99% дефолтных весов более чем достаточно :)
p.s. с удовольствием бы почитал, как у вас организована многопоточность, если можно.
а в целом - успехов, вы выбрали довольно трудную дорожку - тут мало хороший продукт сделать, нужно доказать компаниям/разрабочикам, что замена бд с привычной на новую в их архитектуре.. это вот ни разу не легче задачка будет.
нет, я имел ввиду - как устроено сопоставление? вы ответили - "сопоставляются через сопоставление" (шта?) и "в документации есть описание" (нет). мой вопрос, если более детально - насколько поддерживается CLDR, сколько уровней в ключе (отсюда - поддерживается ли регистронезависимость), есть-ли поддержка правил сортировки чисел в строках?
здравствуйте, а что насчёт индексов? как работает сопоставление строк? в документации как-то момент упущен.
всуну свои пять копеек.
очень и очень рекомендую исследовать свой скомпилированный код на Rust (например, с помощью godbolt.org, cargo-asm) - это даст отличный буст в понимании языка.
я прекрасно знаю, что такие неинформативные комментарии не принято оставлять на Хабре. но не могу не сказать - спасибо, пишите больше, пожалуйста.
простите, я статью не читал - так, глянул мельком. (сейчас мой рейтинг полетит вниз... мда..)
претензии такие - сложность статьи - не "сложная". почему нет тарантула? почему нет бенчей? если статья - "сложная" - должно быть обоснование почему - так, а почему - этак?
я имею ввиду - архитектура in-memory базы? сама работа с памятью? структура базы, индексы? банальная многопоточность?
на данный момент, статья выглядит как устаревший гайд для новичков, уж простите.
полностью поддерживаю, сходил и откомментировался там. лучше всё таки что-то делать, чем не делать ничего.
тогда это - максимальное несоответствие заголовка и содержания. clickhouse тут за уши притянут.
Максим, спасибо за статью. мне, как разработчику своего ПО - не столько интересно про космос, а хотелось-бы методологию оценки текущего состояния разработки ) возможность получения общих метрик в процессе разработки, что-ли. ещё раз - спасибо, очень приятно читается
нет, простите, но нет. это какой-то нелепый тест, который показывает непонятно что.
поясню. для 99% пользователей - нужен просто редактор текста, где то что видишь = то что печатаешь. wysiwyg с печатью. эксель - то же самое, только в сторону простой бд.
по факту - лучшее программное обеспечение тут - то, которое обеспечивая совместимость банально удобно и не жрет ресурсы. всё.
а. тут так. я не представляю эту шкалу. т.е. они хоть и близкие по назначению - но очень разные, нельзя тут проводить оценку по количеству фишек. детали - то, что я делаю, можно принять за "что-то вроде атлассиан". и все замещают и замещают.
для меня же - вот я несколько лет назад был не согласен с этой подачей. ну не нравится мне - та же система документации - confluence - где-то избыточна, и неудобна. я работал на крупную компанию, и они сначала выбрали notion, а потом стали делать своё (не знаю, как сейчас у них). нельзя просто "я буду делать то-то и то-то, только круче". важно понять - что, зачем, почему.
моя концепция разработки - сделать удобно. я, кроме того, что программист с опытом в четверть века - специалист по ui/ux.
возвращаясь к вопросу - как оценить кейсы, когда о них никто не задумывался? или - я вот не хочу просто по историческим причинам, в ущерб своему доходу делать подписки. до 5 пользователей бесплатно, или лайфтайм лицензия на пользователя. это вот влияет?
вобщем, чем ближе я к релизу, тем страшнее ))
дельта ценности - незнакомый для меня термин
имеется ввиду оценка, насколько наличие функционала полной версии повлияет на принятие положительного решения о покупке? вопрос - как измерить, тут несколько факторов.
немного другой таргетинг, есть ключевые особенности, которые для одной группы могут быть важны, а для другой - малозначительны. как это измерить?
p.s. хотел проголосовать за комментарий, но промахнулся :( а исправить почему-то нельзя :( простите. (но плюсанул в карму - пожалуйста, пишите ещё, подписался)
о, хорошая концепция :)
спасибо за статью! в контексте того, что происходит в нашем импортозамещении - актуально.
довольно длительное время (полтора года) работаю над крупным проектом, и на определенный момент встал перед выбором - выпустить MVP, обрезав функционал и положиться на использование сторонних библиотек, или упереться лбом и вести разработку до релиза в том виде, в котором изначально задумывался продукт.
покрутил-повертел MVP.. и продолжил писать - в этом виде система превращалась в ещё одну из десятков аналогичных, с разницей в виде монетизации и с перекрашенными кнопками, с напрочь убитой изначальной идеей. и эта самая изначальная идея просто-напросто не получила бы развития в дальнейшем - костыли/сторонние либы вросли-бы в код, и вместо внедрения ключевых фишек пришлось-бы сосредоточиться на обрастании (не всем нужным) функционалом.
что осознал (или подтвердил на личном примере), двигаясь по дорожке разработки без MVP:
вы не сможете оценить востребованность продукта на более-менее ранней стадии, что позволило бы более-менее безболезненно отказаться от концепции / сменить вектор разработки при её провале.
готовьтесь к тому, что бюджет закончится. совсем. время разработки увеличилось, притока денег нет.
проблемы найма - см. предыдущий пункт, плюс - на ранней стадии требуются действительно скилловые (читай - высокооплачиваемые) сотрудники. также возрастают затраты на контроль разработки, повышенные требования к ведению документации, большая нагрузка на позицию архитектора приложения. т.е. либо готовиться к соло-разработке, либо нужно иметь действительно внушительный бюджет.
старт будет труднее - если в случае с MVP ещё есть какой-то бюджет на рекламу - то тут придётся покрутиться.
надо быть морально готовым к провалу. я не к тому, что нацелен на него, конечно, но сколько раз видел коллег с горящими глазами - "моя убер-система нагнет рынок!" - и... околонулевые продажи, разочарование. в этом случае особенно тяжело воспринимается затраченное время. просто стоит расценивать как опыт, плюс наработки никуда не денутся.
если востребованность продукта на выбранном направлении высокая - конечно же, появятся решения конкурентов, которые пошли по пути MVP. и разработку начать могли позже, и нишу займут. ещё раз вспомнить ключевые фичи, ради чего всё начато и к чему стремишься придти.
блин, не комментарий получился, а крик души :)
спасибо за кусочек детства )
мискузи, ни плюс, ни минус. у всех разный опыт. всё.
очень классно, когда сможете сказанное ощутить не непонятностью, а звуком. мне это хорошо помогло в азии - звуки
не знаю, ребят. отметился - посмотрим, во что это выльется. а про свой стартап я напишу тоже на хабре - только сначала про тексты расскажу - как обещал )
насчёт дотнета - ну, логично, раз у него ноги растут из майкрософта. а вот насчёт Java - не знал, спасибо за комментарий!
да, тут я лажанулся - исправлю. занимаюсь серверными приложениями, десктоп - линукс и макось, а виндой пользовался последний раз лет 15 назад.. спасибо!
исправил, спасибо!