Я вам более скажу. Есть Вайбер прости господи. В вайбере все чаты зашифрованы end-to-end по умолчанию много лет. Причём это не мешает получать сообщение на всех своих устройствах. И не мешает заводить чаты с более чем одним собеседником.
У меня рука-лицо от читателей. Будто комменты в космополитан, а не на техническом сайте.
Абсолютно нормальное утверждение про то, что специальное покрытие может снижать температуру. Вот у вас когда вендор на чип пассивный радиатор клеит и говорит, что температура падает, вы же не называете его лжецом?
Абсолютно нормально и ничему не противоречит утверждение о том, что специальное покрытие дома снижает температуру крыши на 9 градусов когда на улице +6. Просто надо включить голову и представить, что крыша изначально имела температуру скажем +18 градусов, её обшили радиаторами, она стала +9 при воздухе +6. Даже ночью.
Спасибо, добрый человек!
Я как раз страдал что в ряде приложений зависания бывали при определённых ситуациях. Понятно что это проводник где-то втупливает. Но я, к счастью, могу отмонтировать сетевые диски.
Зависит от того как вы попали в ассемблер железок. Если вы получили перед этим что-то вроде Computer Science вышку, то это профильное. Иначе это как каменщик 5-го разряда (можеть быть с золотыми руками и ясной головой), пожелавший резко стать проектировщиком зданий.
:) Настаивать не буду. Я не технический переводчик ни разу.
По прогнозированию у меня отдельный пост есть тут в комментах.
Да, я знаю что в английском это устоялось именно так пышно называть ту однострочную упрощенную проверку пакета на то посылать ли его по быстрому пути. И возможно действительно правильно переводчику дословно и переводить.
У меня вопрос к знатокам. Что вообще имеется в виду в оригинале под "header prediction"?
У меня ощущение после гугления, что это про упрощённый анализ заголовков пакета для принятия решения по какому пути его пустить: slow vs fast.
И prediction здесь состоит в том, чтобы минимальными проверками угадать и значение прочих заголовков пакета.
Верно?
Если я верно понял суть, то возможно и переводить надо без слова предсказание/прогнозирование вообще. Если это не устоявшийся термин конечно.
Получится:
"header prediction code" -> "упрощённая классификация пакетов" (на быстрый путь/медленный путь)
"failed fast path’s header prediction" -> "ошибочно послали пакет по быстрому пути" (в контексте) или "ошибочная маршрутизация пакета по быстрому пути"...
Во-первых я ни разу не переводчик. Возможно я придираюсь местами.
Давайте первый переведённый абзац разберём.
we provide each developer with a writable database snapshot
мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных
Если без контекста, то перевод слова writable (перезаписываемый) верный.
Но в английском была однозначность: database snapshot with write access.
А в русском создается второе значение, где сам снимок БД перезаписывают для каждого разработчика в процессе обеспечения его этими снимками.
И мне при первом прочтении увиделось вот это искаженное значение.
These snapshots are updated daily through a pipeline that involves… step1… step2… step3
Обновление при этом происходит ежедневно в виде конвейера, который включает… step1… step2… step3
Как-то не по-русски этот "конвейер" тут. Хотя дословно слово верно переведено.
Возможно потому что часто в русском оставляют кальку "пайплайн". А может было бы ещё лучше превратить во что-нибудь вроде "последовательность шагов". Или вообще переформулировать без перевода этого слова. "Обновление состоит из этапов/шагов".
copy-on-write при переводе исчезло. Не уверен как правильно и понятно перевести.
немного непоследовательно описание данных пайплайна: "данные среды", потом "датасет" передающийся "на серверы базы данных".
.....
===================================
Давайтея попробую сам эту лямку потянуть.
Оригинал:
As part of our standard toolkit, we provide each developer at Skroutz with a writable database snapshot against which she can develop. These snapshots are updated daily through a pipeline that involves taking an LVM snapshot of production data, anonymizing the dataset by stripping all personal data, and transferring it via rsync to the development database servers. The development servers in turn use ZFS snapshots to expose a copy-on-write snapshot to each developer, with self-service tools allowing rollback or upgrades to newer snapshots.
Ваш перевод:
Здесь в Skroutz в составе нашего стандартного набора инструментов мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных, которые он использует в разработке. Обновление при этом происходит ежедневно в виде конвейера, который включает формирование LVM-снимков данных производственной среды, анонимизацию этого датасета путем удаления всей личной информации и его последующую передачу через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют ZFS-снимок каждому разработчику вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
Мои правки по вашему переводу:
Здесь в Skroutz частью нашего стандартного набора инструментов является обеспечение каждого разработчика снимками базы данных с возможностью записи, которые он использует в разработке. Обновление при этом происходит ежедневно в виде пайплайна, который включает формирование LVM-снимков производственной базы данных, анонимизацию этих данных путем удаления всей личной информации и их последующую передачу через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют ZFS-снимок с копированием при записи каждому разработчику вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
И всё ещё хочется это переписать, сделав предложения более простыми, без сложноподчинённых (а-ля художественный, но для технического текста):
У нас в Skroutz есть стандартный набор инструментов для разработчиков. Частью набора является личный снимок производственной базы данных с возможностью локальной записи. Обновления происходят ежедневно путём создания LVM-снимка производственной базы данных, анонимизации этих данных путем удаления личной информации, а также и их последующей передачи через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют каждому разработчику ZFS-снимок с копированием при записи вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
Перевод крайне корявый. Из-за этого крайне сложно понять текст даже тем, кто по должен бы его понимать в соответствии с опытом работы.
У меня стойкое ощущение, что следующие фразы означали совсем иное у автора до перевода:
— «сбой прогнозирования заголовка быстрого пути»
— «попытка упростить код, удалив из него прогнозирование заголовков и связанные с ним пути файлов»
Это микроконтроллеры. Скорее всего даже исключения поддержать не смогут. Не факт, что STL доступен. Вы ещё вызовы в джаву вставить предложите. И хром туда встроить чтобы запросы в интернет делал.
Возможно я не знаю какого-то красивого решения. Подскажите, пожалуйста, как сделать идемпотентным пример из статьи с сообщением о переименовании пользователя? Чтобы несколько таких сообщений перемешанных и повторённых давали правильный результат.
Про личные проблемы я специально написал. В приличных которах принято знать чем живёт персонал, что его мотивирует, а что наоборот. Включая и то, что менеджер обязан знать что у его подчинённого умерла собака и поэтому он вторую неделю сам не свой на работе. И делают встречи не раз в год. И даже не раз в квартал. А раз в неделю-две. И обратную связь в обе стороны дают на таких встречах.
1. Конторы, которые описывает автор находятся в каменном веке, потому что они не доросли до разделения труда. Как это инженер не хочет картошку копать, да еще хочет зарплату больше чем у подсобника?! А лопатой кто работать будет?
2. Конторы, которые описывает автор находятся в каменном веке, потому что они не доросли до современного управления персоналом. В нормальных конторах будут регулярные совещания один-на-один с непосредственным начальником. Причём не для галочки. Как раз чтобы не было вот этого: "никто в здравом уме не станет думать о проблемах коллег по работе, особенно если проблемы – где-то в личной жизни".
3. Находиться в каменном веке еще пол беды. Часто в мелких конторах это может быть оправданно чем-то. Но у меня ощущение «рука-лицо» от того что автор искренне не подозревает в какой дыре находится и пытается составить целую теорию, оправдывающую пребывание в этой дыре.
Телеграм — распиаренный крипто шлак.
Тоже хотел это сказать. Статья похоже безумно интересная. Но превращается в трэш явно из-за перевода. Она и в верном переводе то непростая будет....
Отопления в такие дома не ставят. Оно ни к чему.
Просто надо думать для какого климата придумана та или иная технология. В тёплом климате строят тонкие дома и парятся охлаждением.
Не надо на север тянуть что ни попадя (неподходящие технологии)!
Вы ещё вспомните, что снежная шапка не даст краске развернуться в полной мере :)
У меня рука-лицо от читателей. Будто комменты в космополитан, а не на техническом сайте.
Абсолютно нормальное утверждение про то, что специальное покрытие может снижать температуру. Вот у вас когда вендор на чип пассивный радиатор клеит и говорит, что температура падает, вы же не называете его лжецом?
Абсолютно нормально и ничему не противоречит утверждение о том, что специальное покрытие дома снижает температуру крыши на 9 градусов когда на улице +6. Просто надо включить голову и представить, что крыша изначально имела температуру скажем +18 градусов, её обшили радиаторами, она стала +9 при воздухе +6. Даже ночью.
Трындёжь какой-то. Я на 2 года младше и застал очереди.
Впрочем может вы в какой прибалтике/гдр жили… Или может в семье приблатнённой (партия или при складах, распределении)?
Спасибо, добрый человек!
Я как раз страдал что в ряде приложений зависания бывали при определённых ситуациях. Понятно что это проводник где-то втупливает. Но я, к счастью, могу отмонтировать сетевые диски.
Иногда лучше проигнорировать уместное чужое сообщение. Чем вот так съезжать с темы коряво.
:) Настаивать не буду. Я не технический переводчик ни разу.
По прогнозированию у меня отдельный пост есть тут в комментах.
Да, я знаю что в английском это устоялось именно так пышно называть ту однострочную упрощенную проверку пакета на то посылать ли его по быстрому пути. И возможно действительно правильно переводчику дословно и переводить.
У меня вопрос к знатокам. Что вообще имеется в виду в оригинале под "header prediction"?
У меня ощущение после гугления, что это про упрощённый анализ заголовков пакета для принятия решения по какому пути его пустить: slow vs fast.
И prediction здесь состоит в том, чтобы минимальными проверками угадать и значение прочих заголовков пакета.
Верно?
Если я верно понял суть, то возможно и переводить надо без слова предсказание/прогнозирование вообще. Если это не устоявшийся термин конечно.
Получится:
"header prediction code" -> "упрощённая классификация пакетов" (на быстрый путь/медленный путь)
"failed fast path’s header prediction" -> "ошибочно послали пакет по быстрому пути" (в контексте) или "ошибочная маршрутизация пакета по быстрому пути"...
Извините за тон.
Во-первых я ни разу не переводчик. Возможно я придираюсь местами.
Давайте первый переведённый абзац разберём.
we provide each developer with a writable database snapshot
мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных
Если без контекста, то перевод слова writable (перезаписываемый) верный.
Но в английском была однозначность: database snapshot with write access.
А в русском создается второе значение, где сам снимок БД перезаписывают для каждого разработчика в процессе обеспечения его этими снимками.
И мне при первом прочтении увиделось вот это искаженное значение.
These snapshots are updated daily through a pipeline that involves… step1… step2… step3
Обновление при этом происходит ежедневно в виде конвейера, который включает… step1… step2… step3
Как-то не по-русски этот "конвейер" тут. Хотя дословно слово верно переведено.
Возможно потому что часто в русском оставляют кальку "пайплайн". А может было бы ещё лучше превратить во что-нибудь вроде "последовательность шагов". Или вообще переформулировать без перевода этого слова. "Обновление состоит из этапов/шагов".
copy-on-write при переводе исчезло. Не уверен как правильно и понятно перевести.
немного непоследовательно описание данных пайплайна: "данные среды", потом "датасет" передающийся "на серверы базы данных".
.....
===================================
Давайтея попробую сам эту лямку потянуть.
Оригинал:
Ваш перевод:
Мои правки по вашему переводу:
И всё ещё хочется это переписать, сделав предложения более простыми, без сложноподчинённых (а-ля художественный, но для технического текста):
У меня стойкое ощущение, что следующие фразы означали совсем иное у автора до перевода:
— «сбой прогнозирования заголовка быстрого пути»
— «попытка упростить код, удалив из него прогнозирование заголовков и связанные с ним пути файлов»
А вот про ТЗ я не присал ничего. Вам почудилось.
Давайте расставлю точки над и.
1. Конторы, которые описывает автор находятся в каменном веке, потому что они не доросли до разделения труда. Как это инженер не хочет картошку копать, да еще хочет зарплату больше чем у подсобника?! А лопатой кто работать будет?
2. Конторы, которые описывает автор находятся в каменном веке, потому что они не доросли до современного управления персоналом. В нормальных конторах будут регулярные совещания один-на-один с непосредственным начальником. Причём не для галочки. Как раз чтобы не было вот этого: "никто в здравом уме не станет думать о проблемах коллег по работе, особенно если проблемы – где-то в личной жизни".
3. Находиться в каменном веке еще пол беды. Часто в мелких конторах это может быть оправданно чем-то. Но у меня ощущение «рука-лицо» от того что автор искренне не подозревает в какой дыре находится и пытается составить целую теорию, оправдывающую пребывание в этой дыре.
Это если они так и делают как в статье: «Расскажите про хэшмэп!» и дальше молчат и ждут ответа на все свои пункты и бонусы.
Надеюсь я просто неправильно понял как автор предлагает вести такое собеседование.