Информация
- В рейтинге
- 3 018-й
- Откуда
- Рыбинск, Ярославская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Разработчик приложений, Архитектор программного обеспечения
Ведущий
Rust
Golang
Проектирование архитектуры приложений
Оптимизация кода
Системное программирование
Разработка программного обеспечения
Проектирование баз данных
Алгоритмы и структуры данных
Сетевые технологии
Справедливо :) я в целом хотел выразить мысль, но помешало моё косноязычие - что рабочее окружение, которое составляет основу рабочего процесса - стоит подтюнить, а с остальным - не стоит впадать в крайности.
и соглашусь, и нет. окружение - это не только хоткеи. это то, во что пялишься по 20 часов в день, и это должно быть комфортно. но вот с другой стороны… приказал долго жить старый комп. купил дешевый ноут - и уж больно бесил тачпад. казалось бы - отключи и работай дальше - так нет, надо было написать расширение для gnome - переключалку, опубликовать, и зачем-то это поддерживать - хотя давно не на ubuntu/gnome…
Вот с этими метриками какая штука… Большинство людей смотрит развлекательный мейнстрим, который есть и у нас. А тех, кому нужно другое - например, свежие обзоры новых статей с arxiv, разработку языков программирования (скажем, выступления Эндрю Келли), компиляторы, не-мейнстримовые тысячу раз разжеванные алгоритмы; - эти проценты просто не учитывают.
Или например - какие-то мануалы по починке своего многострадального ноутбука, видео мастеров. Например, подписан на несколько гитарных мастеров из разных стран.
Цифры всё это не показывают - они показывают “насколько большинство считает контент этих платформ достаточным”, среднюю температуру по больнице. Так что - фиговая метрика, но сморится в глазах чиновников солидно.
Тут опечатка, наверное. При композиционной нормализации (форма C) - когда встречается ненормализиованные кодпоинты - сначала делается декомпозиция, а затем уже комбинирование.
а потом приходит Эндрю Келли, выдает спич про асинхронность через I/O интерфейсы, и выносит окрашивание асинка на свалку истории.
Дмитрий, простите, а у Вас случаем нет блога? Просто очень уж душу греет всё это. Гитарный мастер, техника. Просто кажется, что у Вас есть что рассказать - не только в формате технических статей, а что-то, что можно почитать и послушать после кода, налив 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 тут за уши притянут.