Информация
- В рейтинге
- 4 705-й
- Откуда
- Рыбинск, Ярославская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Разработчик приложений, Архитектор программного обеспечения
Ведущий
Rust
Golang
Проектирование архитектуры приложений
Оптимизация кода
Системное программирование
Разработка программного обеспечения
Проектирование баз данных
Алгоритмы и структуры данных
Сетевые технологии
Дмитрий, простите, а у Вас случаем нет блога? Просто очень уж душу греет всё это. Гитарный мастер, техника. Просто кажется, что у Вас есть что рассказать - не только в формате технических статей, а что-то, что можно почитать и послушать после кода, налив 50 вискаря, поигрывая блюзики вечером?
56 т.р.?
Unrugged P1: https://store.onerugged.com/products/p1-rugged-smartphone-6-5-inch-android-14-ip68-waterproof-mil-std-810h-atex $329.00 USD (~24.6 т.р.)
ну или Emdoor EM-H68T. или SINSMART.
вобщем, OEM китайский. учитывая, что выше - цена для конечного пользователя... какая интересно стоимость на заводе?
Михаил, доброго дня! Подозреваю, что ситуация, когда в карму всё-таки добавили, а статью топят в минусах - может вызывать некоторое недоумение. Маленький совет: попробуйте просто скормить статью какому-нибудь ИИ, с вопросом "почему".
Предположу, что Вы - начинающий программист, и делаете первые шаги. Дело в том, что Вы сейчас видите только вершину айсберга IT, поэтому с таким восторгом движимы идеей "напишу новый гугл с телеграмом, ну это же так просто". Этот код, вообще статья - увы, не несет ценности, это пока даже не джуниор-уровень, скорее - что-то уровня студенческого эксперимента или школьного проекта.
Так что в карму - плюс, за огонь в глазах и очевидную тягу к профессии, за статью - минус. И - успехов!
ох.... немного не в тему, но поделюсь болью. несколько лет назад написал первую статью про юникод. у меня не всё хорошо с общением с людьми, но вроде бы справился. но потом - просто потерял понимание, продолжать или нет? мне показалось, что я больше не вписываюсь в хабр, поэтому остановился. а рассказать - в принципе, думаю что есть что - например, как нашел ошибки в официальной юникодовской ICU4X (репорт привел к релизу), либа нормализации, которая быстрее вышеупомянутой, особенности сопоставлений.. но, серьезно - у меня такое впечатление - что это уже какой-то не формат.
критика не в Ваш адрес, а, скорее, просто разочарование в Apple. при совершенно великолепных характеристиках техники, я, как разработчик - просто не могу доверять компании. не понимаю ни внутренних механик, нет доверия в плане приватности, за что они много лет били себя в грудь, метрики... с большим удовольствием слежу за Китаем, где я смогу накатить линукс, и работать, и геймить.
знаете, просто открывая эту статью я был убеждён, что встречу тут упоминание
0x5f3759df:)это вопрос удобства и предпочтений. кто-то кодит в vim (neovim), кто-то в vscode, кто-то использует продукты JetBrains. дело в производительности. когда твоя IDE может обеспечить тебе комфорт и прирост в производительности - это = некий процент в производительности. с учётом ФОТ > среднего для разработчиков - покупка лицензии, если работник предпочитает платную IDE - вполне оправданное решение.
спасибо! вариантов для различных локалей нет? хотя.. в 99% дефолтных весов более чем достаточно :)
p.s. с удовольствием бы почитал, как у вас организована многопоточность, если можно.
а в целом - успехов, вы выбрали довольно трудную дорожку - тут мало хороший продукт сделать, нужно доказать компаниям/разрабочикам, что замена бд с привычной на новую в их архитектуре.. это вот ни разу не легче задачка будет.
нет, я имел ввиду - как устроено сопоставление? вы ответили - "сопоставляются через сопоставление" (шта?) и "в документации есть описание" (нет). мой вопрос, если более детально - насколько поддерживается CLDR, сколько уровней в ключе (отсюда - поддерживается ли регистронезависимость), есть-ли поддержка правил сортировки чисел в строках?
здравствуйте, а что насчёт индексов? как работает сопоставление строк? в документации как-то момент упущен.
всуну свои пять копеек.
очень и очень рекомендую исследовать свой скомпилированный код на Rust (например, с помощью godbolt.org, cargo-asm) - это даст отличный буст в понимании языка.
я прекрасно знаю, что такие неинформативные комментарии не принято оставлять на Хабре. но не могу не сказать - спасибо, пишите больше, пожалуйста.
простите, я статью не читал - так, глянул мельком. (сейчас мой рейтинг полетит вниз... мда..)
претензии такие - сложность статьи - не "сложная". почему нет тарантула? почему нет бенчей? если статья - "сложная" - должно быть обоснование почему - так, а почему - этак?
я имею ввиду - архитектура in-memory базы? сама работа с памятью? структура базы, индексы? банальная многопоточность?
на данный момент, статья выглядит как устаревший гайд для новичков, уж простите.
полностью поддерживаю, сходил и откомментировался там. лучше всё таки что-то делать, чем не делать ничего.
тогда это - максимальное несоответствие заголовка и содержания. clickhouse тут за уши притянут.
Максим, спасибо за статью. мне, как разработчику своего ПО - не столько интересно про космос, а хотелось-бы методологию оценки текущего состояния разработки ) возможность получения общих метрик в процессе разработки, что-ли. ещё раз - спасибо, очень приятно читается
нет, простите, но нет. это какой-то нелепый тест, который показывает непонятно что.
поясню. для 99% пользователей - нужен просто редактор текста, где то что видишь = то что печатаешь. wysiwyg с печатью. эксель - то же самое, только в сторону простой бд.
по факту - лучшее программное обеспечение тут - то, которое обеспечивая совместимость банально удобно и не жрет ресурсы. всё.
а. тут так. я не представляю эту шкалу. т.е. они хоть и близкие по назначению - но очень разные, нельзя тут проводить оценку по количеству фишек. детали - то, что я делаю, можно принять за "что-то вроде атлассиан". и все замещают и замещают.
для меня же - вот я несколько лет назад был не согласен с этой подачей. ну не нравится мне - та же система документации - confluence - где-то избыточна, и неудобна. я работал на крупную компанию, и они сначала выбрали notion, а потом стали делать своё (не знаю, как сейчас у них). нельзя просто "я буду делать то-то и то-то, только круче". важно понять - что, зачем, почему.
моя концепция разработки - сделать удобно. я, кроме того, что программист с опытом в четверть века - специалист по ui/ux.
возвращаясь к вопросу - как оценить кейсы, когда о них никто не задумывался? или - я вот не хочу просто по историческим причинам, в ущерб своему доходу делать подписки. до 5 пользователей бесплатно, или лайфтайм лицензия на пользователя. это вот влияет?
вобщем, чем ближе я к релизу, тем страшнее ))
дельта ценности - незнакомый для меня термин
имеется ввиду оценка, насколько наличие функционала полной версии повлияет на принятие положительного решения о покупке? вопрос - как измерить, тут несколько факторов.
немного другой таргетинг, есть ключевые особенности, которые для одной группы могут быть важны, а для другой - малозначительны. как это измерить?
p.s. хотел проголосовать за комментарий, но промахнулся :( а исправить почему-то нельзя :( простите. (но плюсанул в карму - пожалуйста, пишите ещё, подписался)
о, хорошая концепция :)