• 10 топовых плагинов для IntelliJ IDEA, которые ты не должен пропустить
    0

    Вот - спасибо! Подозреваю, что этот кусок вырезали, так как стыдно было вставлять ссылку на нормальный перевод в статью переведённую Гуглом.

  • Какой объем займет информация, необходимая для оцифровки вашего мозга?
    0
  • Управление зависимостями в Node.js
    0

    вот развёрнутый список (окей, это не только вебпак):

    • import синтаксис вместо require(), export синтаксис вместо module.exports

    • типы модулей: amd, umd, commonjs, nextjs и т.д.

    • loaders, импорт-чего-угодно, а не только js (картинки, статические файлы, и т.п.)

    • type script вместо js, заголовочные файлы, source maps

    • lock файлы разных видов, повторябельные сборки

    • менеджмент транзитивных зависимостей

    • lerna для управления мульти-пакетными репозиториями

    • yarn вместо npm, yarn workspaces

  • Управление зависимостями в Node.js
    –1

    В 21 веке пользуются webpack + type script, к чему это легаси?

  • TREX: 27-ричная симметричная система счисления
    0

    Это, кстати, очень хорошая мысль. К примеру, двоичный поиск - как его организовать в троичном компьютере, если он не умеет легко делить на 2?

    Только не предлагайте троичный поиск, я даже боюсь представить, как бы выглядел его алгоритм :)

  • TREX: 27-ричная симметричная система счисления
    0

    Начинающие программисты нынче вообще не разбираются в системах счисления, сегодня начинающие программисты должны уметь разбираться в концепциях питона, вебпака и прочего. А байты, биты и все такое - это предмет низкоуровневых оптимизаций.

  • TREX: 27-ричная симметричная система счисления
    0

    А можете всё-таки словами объяснить, пожалуйста? В статье какие-то странные вычисления, основанные на том, что «складывать в столбик в троичной системе быстрее чем в двоичной» (меньше переносов). С одной стороны это правда, с другой стороны - а какова практическая польза с учётом того, что компьютеры оперируют в основном с числами фиксированной длины и на таких числах базовая арифметика и логика всегда выполняется за один такт? Получается, что надо ориентироваться не на скорость работы, а на число транзисторов необходимых для реализации логики (меньше транзисторов = дешевле и проще делать многоядерные процессоры). И вот про число транзисторов в статье ни слова.

  • C# vs Kotlin
    0

    Это исторически сложилось так, возможно со временем его научат учитывать атрибуты типа [Inject] - это в целом делабельно (не требует каких-то кардинальных изменений языка). Нечто подобное уже есть: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/nullable-analysis

  • Дженерики в языке Go
    0

    Надо определится - или тут или здесь - если дженерики можно в библиотеках, как их запретить в сервисном коде? А если не запретить, то их будут использовать… и как выше сказали они сложные.

  • Дженерики в языке Go
    +1

    Ничего не имею против Rust. Если вас после миграции все устраивает - это именно то, о чем я говорю (C# был взят для примера). И да, открытость языка - это очень важно. Я как бывший .NET разработчик до сих пор радуюсь, что MS решилась сделать компилятор (Roslyn) и рантайм (.NET Core/5.0) открытым - это дало дало огромный буст к развитию языка.

  • Дженерики в языке Go
    0

    Так вот я о том же - может таки мигрировать на что-то другое, что из коробки поддерживает дженерики и плагины? Тот же с# - дженерики работают из коробки, плагины - можете написать, компилятор открытый - в последних версиях есть возможность кодо-генерации (можете изобрести свой DSL и генерировать С# код во время компиляции встроенными средствами, только хорошо подумайте есть ли от этого профит), как частный случай - можете придумать собственные операторы типа await (вам это точно надо?)

  • Дженерики в языке Go
    –3

    Я не эксперт в Go, могу предположить, что оно без этого не взлетает, возможно изначальная идея «простоты» неработоспособна. Дженерики можно туда же отнести; в целом - надо определиться - или очередной .NET/Java, или простота с ограничением возможностей, которая подходит не всем. Простота вроде как декларировалась Гуглом изначально, если простой синтаксис не удовлетворяет реальные требования бизнесов де-факто, то (наверное) стоит отказаться от идеи совсем, и вместо попытки сделать очередную джаву, огласить язык мёртвым (для этого требуется мужество и чёткое понимание бизнес целей). На двух стульях (разрешив сложные штуки в библиотеках и только простые штуки в сервисах) усидеть сложно.

    // на правах личного мнения

  • Дженерики в языке Go
    0

    Тогда нужно менять язык. Идея Go в простоте, а дженкрики никогда не были простыми - после введения базовых дженериков, начнётся форсинг ко/контр-вариантности, затем форсинг дженериков-полных-по-тьюрингу как в С++ (тут есть надежда, что фиче реквест отобьют, ибо уже слишком сложно)

    TL/DR - добавив дженерики и т.п. - получится очередной .NET/C#, а простота присущая Go пропадёт - зачем это надо? Может проще сразу писать на условном .NET?

  • Откровения трезвого инженера
    +3

    За оторванность от суровой реальности, очевидно :)

  • C# vs Kotlin
    0

    К тому же, сложение функций в стиле последовательного вызова - это не так чтоб очевидная операция. Я бы лично предпочёл синтаксическую ошибку в таком случае (вызывайте компоуз явно если действительно хотите их “сложить”). Т.е. «сложение» ивент хендлеров мне (лично) выглядит очевидным, а вот сложение «обычных» функций - нет. С#, к сожалению, не разделяет эти два юз кейса.

  • C# vs Kotlin
    0

    В условном С++ тот же оператор сложения строк определён явно - если вы отлаживаете дебаг версию к нему можно перейти поднявшись по стеку

  • C# vs Kotlin
    0

    Нуу… вроде и да, но мне в отладчике не было понятно сходу, каким чудом вызвался Delegate.Compose - вроде бы и логично, но в коде такого нету, без анализа компилятора неочевидно почему ИМЕННО ЭТОТ вызов был сделан

  • C# vs Kotlin
    0

    Если честно, я не очень понял как это работает в Котлин.

    Вот пример: допустим у нас есть класс Service1, который создаётся IoC контейнером, он зависит от логгера, который инжектится тем же IOC контейнером, в с# я могу написать как-то так:

    class Service1 {

    [Inject]

    public ILogger Logger { get; set; } = null!;

    public void DoSomething() {

    // …

    Logger.Info(“test”); // Logger is not-null

    }

    }

    Здесь конструкция «= null!» говорит компилятору, что я хорошо подумал, и Logger будет гарантированно инициализирован при создании объекта. Как тоже самое сделать в Котлин?

  • C# vs Kotlin
    0

    Да, вы правы - я как-то привык ходить в декомилированную реализацию для последних новшеств типа асинк и уже подзабыл что многие другие вещи объявляются неявно.

    Иными словами, мне хотелось бы видеть определение Func не как делегат сам по себе, а как обертку над делегатом, которая показывает, что именное происходит внутри. Так, к примеру, делают в с++ - вы можете посмотреть что внутри std::function или std::string - мне почему-то казалось, что с# пошёл похожим путём, но это (очевидно) когнитивная иллюзия.

  • C# vs Kotlin
    0

    Костыль в том, что это преобразование объявлено неявно. Если бы тип Func<T> имел статический метод Func<T> operator +(Func<T> a, Func<T> b) - то было бы более менее логично - мы просто вызываем оператор. Но такого метода нету (его не выдаёт рефлексия, его не показывает ILDasm).

    Очень похоже что этот кхм «метод» встроен в сам компилятор - компилятор «знает из коробки» что если пытаются сложить две функции одинакового типа, то надо вызвать Delegate.Combine и скастить результат обратно в функцию - именно это знание я и называю костылём - оно неочевидное и его не видно в исходниках рантайма. Зато, я, кажется, нашёл это место в компиляторе: https://github.com/dotnet/roslyn/search?q=System_Delegate__Combine (файл LocalRewriter_BinaryOperator.cs, строки 175 и 230)

  • C# vs Kotlin
    0

    Вообще это очень интересная магия, если посмотреть IL код, видно что компилятор делает следующее:

    Func<int> z = (Func<int>) (Delegate) Delegate.Combine(x, y);

    Это очень похоже на неудачно выстреливающий костыль в компиляторе: очень похожие вещи происходят в event-ах, но там все выглядит логично из-за наличия в определении ключевого слова ивент которое явно говорит что «сложение» означает последовательный вызов обработчиков:

    public event Func<int> Z;

    // …

    Z = x; // подписать на ивент X

    Z += y; // а ещё подписать Y

    Похоже что компилятор де-факто не проверяет наличия «event» в определении z - поэтому синтаксис из примера и работает. Интересно было бы копнуть глубже и посмотреть как Roslyn делает парсинг, но лень :)

  • У каждого приложения должна быть палитра команд
    0

    Панельки нужны для редактирования и анализа структуры мокапа. Дело не в том, что их можно или нельзя убрать; дело не в отсутствие предпросмотра. Дело в том, что когда мокап в темных тонах, а его структура на панельках в белых тонах, то глаза у некоторых людей (типа меня) начинают ощутимо болеть/уставать от высокого контраста на экране.

  • Микросервисы — не способ масштабироваться
    0

    Вам повезло - вы, похоже, успешно выделили и поддерживаете отдельные сущности/модули внутри вашего монолита. Если вы перечитаете мой первый комментарий, то увидите, что я писал о том, что это (в целом) возможно, но удаётся далеко не всем.

  • Микросервисы — не способ масштабироваться
    +1

    Начиная с микросервисов сразу мы отсрачиваем запуск проекта в целом.

    Именно поэтому я добавил в конце оговорку про «умеют готовить devops» - если у команды есть опыт в этой сфере, то накладные расходы будут приемлемыми. Если опыта нет, то вы правы и надо пилить как получается в надежде получить опыт и прибыль от MVP; однако, надо помнить что в будущем таки придётся переделывать, если стартап взлетит; дальнейшие соображения зависят от специфики продукта, количества инвестиций и т.п.

    Проектам редко нужно 50 человек. Скорее всего эти 50 пилят 5 разных проектов. Смежных, но разных.

    Склонен с вами не согласится - «типичным магазинам» не нужен, а вот успешный энтерпрайз-грейд SaaS стартап - это как раз и есть человек 50, при этом все работают над одним продуктом (но над разными фичами). В таких ситуациях микросервисы являются той самой штукой, которая делает отдельные команды независимыми при условии правильного разделения зон ответственности.

  • Микросервисы — не способ масштабироваться
    0

    del

  • Микросервисы — не способ масштабироваться
    0

    Вы с одной стороны правы (микросервисы, действительно не решают проблему горизонтального масштабирования нагрузки), но приходите к «опасным» выводам. Основная выгода от микросервисов проявляется, когда ваша команда становится достаточно большой, чтобы проявлялись проблемы единой кодовой базы (монолита). 10 человек могут работать с монолитом эффективно, 50 - уже не могут: появляются мерж-конфликты, регрессивное тестирование становится дорогим, а релизы - праздником, а не повседневностью как должно быть. Монолит (в смысле деплоя) - это такая штука, которую вроде бы и можно сделать «правильно» - выделив и изолировав модули, - но она не обеспечивает надлежащего контроля над границами этих самых модулей; в условиях «релиз надо на вчера» (как обычно бывает), монолит склонен к скатыватнию в спагетти-код, где всё зависит от всего. Именно поэтому стоит начинать с микросервисов сразу - не дожидаясь пока у вас накопится тонна неподдерживаемого кода. Для этого, конечно, нужна команда, которая умеет правильно готовить devops часть, ну а технологий, сегодня, (благо) хватает, велосипед изобретать не нужно.

  • У каждого приложения должна быть палитра команд
    –1

    Даже не знаю, фигма это отдельное зло. Как можно всерьёз говорить про дизайнер мокапов у которого, банально, нету темной цветовой темы? Редактировать/смотреть на мокап в темных цветах на фоне белых панелек, которые нельзя убрать - то ещё удовольствие для глаз.

    Интерфейс фигмы можно назвать простым и понятным, но никак не удобным.

    Там даже нету нормальной палитры цветов. Хочешь градиент от красного к зелёному в «правильном» цветовом пространстве, которое сохраняет визуальную яркость цвета воспринимаемую человеком (типа lab)? Ищи в интернете генератор и копируй цвета обратно в фигму вручную :(

  • Если у вас нет плюсов
    +1

    Не помню точно условие (да и размер победителя), к сожалению, помню только что «тривиального» решения там не было

  • Если у вас нет плюсов
    +1

    Есть такие задачки, до сих пор помню code challenge 15-летней давности, который меня выбил на неделю

    язык: asm

    набор инструкций: I 386**

    цель: написать DOS программу (.com), которая принимает на стандартный вход 1 байт (число 0-255) и выводит в стандартный вывод N знаков $, где N - число на входе, после чего завершается с кодом 0

    критерий оценивания: побеждает программа минимального размера

    ** ну, и маленький нюанс: нельзя использовать команды условного перехода (jz, je, jne и т.п.), нельзя использовать арифметику (add, sub, inc, dec, mul, div), в том числе адресную арифметику (lea, dword ptr [eax + 4] и т.п.)

    Победила программа размером (кажется) 19 байт

  • Модульный, полностью ремонтопригодный ноутбук Framework доступен для предзаказа
    0

    Маки живут 5 лет легко как новые, наверное и 10 живут, но дольше 5 лет все равно нет смысла держать ноут (разве что, в режиме печатаной машинки). Моему старому эйру 9 лет и до он сих пор работает и, даже, обновляется.

  • Заметки о Unix: надёжная работа с API C-библиотеки Unix возможна только из программ, написанных на C
    +2

    Ах да, .h файлы - это вполне себе documentation-as-a-code в таких случаях. Даже с комментариями иногда.

  • Заметки о Unix: надёжная работа с API C-библиотеки Unix возможна только из программ, написанных на C
    +5

    Желтоватенько, конечно. Если errno определена препроцессором, значит ее реализация «встраивается» в бинарники во время компиляции, так ведь? То есть все уже собранные бинарники перестанут работать корректно если реализацию поменять.

    Вопрос: какого масштаба апокалипсис должны найти в текущей реализации чтобы такое изменение протащить через все код ревью в прод? Сломавшийся при этом GO будет явно меньшей проблемой, да и ту можно починить «скопировав» реализацию ещё раз и все пересобрав.

  • Автор атаки KRACK раскрыл подробности о 12 критических уязвимостях популярных беспроводных устройств
    +2

    Платный VPN, HTTPS, Secure DNS, многофакторная аутентификация, смотреть на сертификат при посещении важных сайтов

  • Чернобыль ч.5. Вне АЭС
    +1

    Все-таки есть принципиальная разница между жить на заражённой территории и летать на самолете - на заражённой территории радиоактивные элементы попадают внутрь через рот и это намного хуже, чем облучение снаружи. Те же альфа-частицы успешно блокируются кожей, но если источник такой радиации съесть - все резко становится плохо.

    Это я не к тому что пилоты не получают дополнительную радиацию (с этим глупо спорить), это я к тому, что сравнивать цифры на дозиметре просто так некорректно (их можно сравнивать только если обеспечена защита от попадания радионуклидов внутрь организма).

  • 6 причин, по которым вам следовало бы отказаться от гистограмм
    +4

    Ох беда… уважаемые переводчики - не переводите, пожалуйста, то, что вы не понимаете. CDF (которую хвалят в статье) и PDF - это суть одно и то же, только CDF кумулятивная (в случае идеальных распределений - интеграл от PDF). Все те «интервалы» (bins), которые есть в PDF также есть и в CDF, только в кумулятивной функции они выглядят как ступеньки а не как провалы. Наконец, ни CDF, ни PDF нельзя сравнивать глазами - можно сравнивать только мат. методами (типа t-теста, который, к слову, имеет существенные ограничения - распределения должны быть нормальными, сравнение должно производится только один раз по достижении необходимого объема статистики, и т.п.). Если сравнивать «глазами» без понимания мат. статистики получится чушь что в одном, что в другом случае. И это мы не ещё не начали говорить про нюансы типа эффекта Бонферрони.

  • Инженер Google раскритиковал Apple за торможение развития веб-технологий
    +1

    +1: iOS, долго сидел на хроме, пока там не появилась бага, которая «отгрызает в никуда» 15-20% процентов горизонтального пространства экрана, если телефон перевернуть из вертикального положения в горизонтальное и обратно (после такого поворота хром рендерит картинку так, как будто экран стал ощутимо уже, справа остаётся белая полоса).


    Гугл не может или не хочет это чинить уже год! Год!!!


    С тех пор — сижу в сафари — он хотя бы работает как надо...

  • Как без усталости кодить по восемь с лишним часов
    +12

    Это ещё не все, дальше там про технику 69-минутных интервалов. В каждом интервале 17 минут перерыва (зарядка итп). Итого (606 — 606/69*17)/60 = 4.5 часа действительно работы.


    Вот это поворот! :)

  • «Котовий брызгатрон» — или боевая турель против кота ^_^
    +1

    Ох, нам бы такую штуку домой, уже готовую к применению....

  • Что делать, если украли смартфон
    0

    Аааа да, простите. Читал по дороге домой на ходу, вторую часть сообщения не увидел...

  • Что делать, если украли смартфон
    0

    Паролем шифруется случайно сгенеренный ключ шифрования для данных, а не сами данные