• Власти Москвы объявят конкурс на создание системы распознавания лиц
    0
    Потому что не считаю обсуждаемую систему инструментом для репрессий.

    Я не отрицаю, что этой системой могут и будут злоупотреблять. Однако основное её назначение — борьба с преступностью. И я думаю, что плюсы от использования в полезных целях перевесят минусы от злоупотреблений.
  • Власти Москвы объявят конкурс на создание системы распознавания лиц
    0
    Не достаточно вдавался в подробности кто это такие, чтобы сформировать отношение.
    Поиск дал ссылки на новости о том, что их решения используют для блокировки телеграма.
    К блокировке телеграма, как и к любым другим попыткам ввести интернет цензуру отношусь отрицательно.
  • Власти Москвы объявят конкурс на создание системы распознавания лиц
    0
    Ага, зачем делать свои высокотехнологичные разработки. Надо только на западные опираться.

    А в этой стране надо только выкачивать нефть и выращивать бананы. Впрочем, для бананов климат не совсем подходящий, так что…
  • Kotlin Playground
    0
    Попробую придумать пример для наглядности.
    Допустим у меня есть веб-сайт, где пользователь должен задать свой пароль.
    Обычно пароли должны соответствовать каким-то требованиям: минимальная длина, наличие каких-то символов и т.д. Если пользователь придумал неправильный пароль, то сайт должен отказать с сообщением что не так.

    Разумеется, код проверки пароля несложно запрограммировать внутри системы, но предположим, что хочется дать возможность администратору сайта самому задавать требования к пользовательским паролям. Один из вариантов решений: сделать в адмике сайта формочку, где администратор на котлине может написать такую функцию:
    fun checkPassword(password: String, locale: Locale): CheckPasswordResult

    Эта функция проверяет пароль, а в случае неудачи формирует сообщение об ошибке на языке пользователя.

    Можно конечно сказать: зачем так делать, ведь можно же описать требования для пароля регуляркой, шаблонами, etc. Но в конце концов это же всего лишь простой пример для иллюстрации, в жизни бывают и более сложные случаи конфигурации, которые просто так регуляркой не опишешь, нужен скрипт.

    Что я имею в виду под взаимодействием с кодом?
    А то, что код, который вводит админ, это не просто замкнутый сам на себя пример, который отработал, напечатал рядом результат и на этом все, нет. В пользовательский скрипт надо передать из системы контекст (в нашем примере это сигнатура требуемой функции и выбранная на сайте локаль пользователя), некое api, через которое скрипт может получать информацию о системе или управлять ею.
  • Kotlin Playground
    0

    А можно ли как-то взаимодействовать с кодом, введённым пользователем, чтобы, например, использовать это в качестве пользовательских скриптовых сценариев?


    Ну например, есть веб-админка, и хочется чтобы через неё налету что-то сконфигурировать через описание на котлине.

  • Нужно ли менеджеру уметь программировать
    +1

    Охх…
    Статью следовало бы назвать "Типичные ошибки бывшего программиста, ставшего начинающим руководителем".


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


    Но в целом основные задачи у руководителя всё-таки другие. А задачи по большому счету две: продукт и команда.


    Менеджер должен уметь редактировать файлы при помощи Vim??? :/ Да вы наверное шутите.

  • Вредный Кейворд «Interface»
    +5
    Статья смешная, но производит впечатление, что ее писал джуниор, начитавшийся книжек по ООП.

    Просто автор видимо не дебажил часами падающие на C++ программы, в которых такой же студент сваял ажурные конструкции из множественного/виртуального наследования, потом запутался в выборе нужного cast при проведении типов и получил UB по лбу.

    К слову, в большинстве проектах на C++, на которых я работал, множественное наследование было тупо запрещено. Это к вопросу о том, насколько «успешно» решили эту задачу в C++
  • Вредный Кейворд «Interface»
    0
    deleted
  • Рояль должен быть исчезнут: уровни профессионального развития и их оценка, у программистов
    0
    У меня от стиля изложения сложилось впечатление, что автор просто хочет выпендриться.
    Накрутить слова так, чтобы с одной стороны было плохо понятно, а с другой выглядело по «философски», и читатели пытались выловить смысл из глубины её глубин. Ну и как водится, винегрет из терминов, жаргонизмов и отсылок ко всему попало.

    > «Будет больно. Потому что будет правда.»
    Вот она, попытка сорвать покровы.
  • Как мы расписание общественного транспорта в 2ГИС добавляли
    0
    А откуда берут данные яндекс-транспорт и citymapper?
    Из тех же источников что и вы или каких-то других?

    Я понимаю, что вопрос не совсем к вам, но наверняка вы в своих поисках пытались провентилировать этот вопрос.
  • Как работает hashCode() по умолчанию?
    0
    Если я правильно понял, то все эти танцы с бубнами преследует одну цель: вычислять hashCode лениво, при первом вызове.

    Неужели это оправдано? Не проще ли было при создании объекта сразу проинициализировать его адресом или каким-то псевдослучайным числом?

    Это выглядит как очень дешевое действие, которое отработает за пару тактов и ни на что особо не повлияет.
  • ExcelArt – изометрия «на халяву». Рисуем псевдообъемный телефон без 3D и Фотошопа
    +18
    А можете нарисовать в экселе таблицу в форме котёнка?
  • HOCON — конфигурируем гибко
    0
    Принято.
    Да, встроенный JavaScript убирает все инфраструктурные издержки.

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

    Впрочем, никто не мешает попробовать так сделать и потом рассказать о своем опыте. Я имею в виду не просто попробовать сделать в качестве эксперимента — понятно что так можно. Скорее интересен опыт долгосрочного использования, когда эти js конфиги отдаются на откуп админам, которые занимаются поддержкой системы, и они там на них что-то программируют.
  • HOCON — конфигурируем гибко
    0
    Ну сначала о чисто бытовых неудобствах, которые мне видятся на пути подключения полноценных скриптов:
    1. Они предустановленны, но не везде. Например мы в процессе разработки запускаем свои сервера на чем попало, в том числе и windows. Придется бегать и ставить скрипты там.
    2. Предустановленная версия скриптов может не совпасть с требуемой. Или нестыковки в каких-то требуемых библиотеках, в путях, в переменных окружения.
    3. Надо еще как то передать данные из скрипта в свою программу, а как? Первое что приходит в голову, скрипт печатает их в stdout, а программа парсит. Но тогда нужны какие-то соглашения о формате этих данных, чем-то печатать, чем-то парсить. То есть скрипт ещё не является готовым решением, надо еще строить мост между скриптом и родительской программой.

    Если же сравнить эти телодвидения с HOCON, то нам надо всего лишь
    1. Поключить библиотеку (с помощью maven или gradle это делается одной строчкой)
    2. Вызвать функцию parseFile.
    3. Profit. После этого мы получаем готовый объект из которого можно читать значения.

    Теперь насчет сложности как языка. HOCON — это все-таки небольшая надстройка над JSON, с весьма ограниченными возможностями, которые решают вполне конкретную задачу. По сути это всё те же текстовые данные, но с возможностью прототипирования.

    Когда делаешь конфиги на обычном JSON или XML, то основная проблема с которой сталкиваешься: дублирование данных. И хочется эти дубликаты как-то выносить в общее место и потом на них ссылаться. Собственно, HOCON с помощью прототипирования как раз и помогает это сделать.

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

    HOCON же имеет те именно возможности, которые нужны для конфигов, не больше и не меньше. Он очень простой. Его изучение сводится к получасовому изучению мануала, после чего все более менее понятно и сразу можно работать.

    Конечно, возможно в будущем опять окажется что чего-то не хватает, но пока что хватает. Одно из сильных достоинств HOCON — это его легковесность.
  • HOCON — конфигурируем гибко
    0
    Парсер HOCON — это маленькая библиотечка на Java, которая к тому же не тянет никаких зависимостей.
    А если JavaScript — то в нашем случае это надо внутрь JVM, на которой наш сервер работает, целый JavaScript интерпретатор затаскивать.

    Кроме того, описывать конфиги на JavaScript языке на мой взгляд все-таки не совсем удобно. Слишком широкие возможности, которые предоставляет полноценный скриптовый язык, могут привести к злоупотреблениям и чрезмерному усложнению конфигов.

    Ну то есть при желании так сделать конечно можно, но я бы так делать не стал :)
  • HOCON — конфигурируем гибко
    0
    Можно и так. Просто примеры купированные, в них опущено что в s1 помимо ip есть и другие параметры. В исходном варианте было как-то так
    s1: 
    {
        ip = “192.168.10.1”
        port = 123
        database = "goodwin"
        username = "root666"
        password = "nobodyknows"
        threadpool_size = 10
        // и так далее
    }
    


    Кстати да, вместо двоеточия можно писать =, это как кому нравится.

    Насчет того что include игнорирует пропуски, да я согласен что было бы неплохо иметь директиву с обязательным включением.

    Семантика игнорирования missing files была задумана видимо как раз под описанный мной пример: когда в основном конфиге задаются все нужные параметры по умолчанию, а в опциональном дополнительном можно что-то если надо перекрыть.
  • HOCON — конфигурируем гибко
    +1
    Спасибо за указанную неточность в терминах, принято.
  • HOCON — конфигурируем гибко
    +1
    Да, так и есть, у нас тоже есть подобные использования.
  • Книги для системного администратора. Моя книжная полка
    0
    Подскажите, в какой-нибудь из этих книг описаны принципы организации каталогов в linux?

    Ну типа что такое \etc, \var, \opt и так далее.

    Просто что что меня всегда бесило в linux — это то, что каждая уважающая себя программа считает своим долгом разбросать свои кровавые ошметки по всей файловой системе. И хочется наконец понять логику по которой это делается.
  • Совсем немного о travel-интерфейсах
    +3
    Как пользователю мне, за исключением некоторых мелочей, вполне удобны существующие авиапоисковики.

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

    То есть вот надо мне 15 января попасть из Москвы в Стамбул, я говорю сервису: когда, откуда и куда. Сервис показывает варианты. Все быстро и просто.

    А концепция «первый экран приложения содержит готовые предложения, а не фильтры.» — это как раз рекламный bullshit, который не нужен пользователю. Ему не надо «на море» и «в горы». Пользователь, пришедший на авиапоисковик, уже знает куда и когда ему надо.

    Поэтому первая страница должна содержать именно параметры запроса.
  • Главное преимущество Go
    +3
    Время покажет.
    Мне этот подход скорее напоминает checked exceptions в java.

    То бишь есть обычные exceptions, а есть checked exceptions.
    Есть обычные коды возвращаемых ошибок, а тут checked коды.

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

    Но сейчас, годы спустя, checked exceptions считается неудавшимся дизайном. Например, в том же C# от них осознанно отказались.

    Здесь очень похожая ситуация, форсирование обработки, только механизм передачи сделан не через исключение, а через возвращаемое значение.
  • Главное преимущество Go
    0
    Ну почти тоже самое. Серебряная пуля — метод который решает существующие проблемы гораздо эффективнее, чем предыдущие методы. Представляем java — новый язык, на котором мы будем писать программы в несколько раз эффективней, чем на допотопном C++. Представляем обработку ошибок в Go — мы будем обрабатывать их гораздо эффективнее чем в предыдущих языках. Метафора в общем то про это.

    С долгосрочностью/краткосрочностью совсем не понятно. Что является осью времени, на которой мы измеряем эту долгосрочность? Работа программы? Жизнь программиста? Развитие IT индустрии?
  • Главное преимущество Go
    +2
    Ну она так воспринимается. Что есть старый путь, через исключения, «неправильный». А есть новый, «правильный». Который вроде как благодаря легкости и простоте должен подтолкнуть программистов к правильной обработке ошибок.

    А комментарии же уже после идут, отдельно. Извиняюсь, если оскорбил.
  • Главное преимущество Go
    0
    Если лишь 1 вызов из многих содержит ошибку, то конечно проблемы нет.

    Однако бывают код, и это отнюдь не редкость, а вполне распространен на практике, в котором интенсивность содержания ошибок высокая. И с этим тоже надо что-то делать. Собственно я именно про такой код и задал вопрос.

    В случае исключений до самой main падать не нужно. Обычно используется паттерн с большим try catch, наложенным на какую-то высокоуровневую операцию, который ловит все подряд. Ну тот же пример с web server, который генерит страницу. В процессе генерации страницы может случится всякое, ведь он же в том числе ходит за данными и во внешние источники. Но что бы ни случилось, обработка будет одна и та же: пользователю отдаем страницу 500, а техническому специалисту печатаем текст ошибки в лог.

    Паттерн отлично работает, причем web сервер лишь пример, его можно применять еще много где.

    Вот это действительно удобный подход, который позволяет программисту писать простой линейный код и снимает с него головную боль обработки бесчисленных fail path, которые случиться во время генерации. Соотношение код обработки ошибок/основной код сведено к минимуму.
  • Главное преимущество Go
    0
    Ну я так понял, что panic — это не основная схема, а вспомогательная. Что по задумке авторов языка panic нельзя злоупотреблять, что основным способом обработки ошибок должен быть error.

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

    Например, на все нужные ему стандартные пакеты напишет врапперы, которые превратят error в panic, забьет на инновацию языка авторов и будет работать по старому, с исключениями. Можно даже сделать библиотеку error2panic, выложить в opensource и она будет пользоваться популярностью.

    Да, это хорошо, что язык предоставляет возможность обойти авторскую задумку и работать по старому, но мне все-таки интересно, можно ли удобно пользоваться новым способом.
  • Главное преимущество Go
    +1
    Дело в том, что этот вариант является, как мне кажется, основным разумным поведением по умолчанию. И именно так работает обработка ошибок на исключениях, люди к этому уже привыкли.

    После каждого вызова писать if r.err — это не выход, это принять страдания и смириться. Но ведь тут речь идет об удобстве, о том что простой и удобный синтаксис будет подталкивать программистов к правильному написанию программ.

    Я всецело согласен с тезисом, что простота и удобство синтаксиса является мощным мотиватором для программистов, но я вижу, что обработка ошибок в Go создает огромную проблему, которая перекрывает все преимущества такого подхода. И решения этой проблемы я пока не вижу. Поэтому исключения для меня пока что выглядят куда проще и удобней, чем этот механизм.
  • Главное преимущество Go
    +2
    Спасибо за ссылку.
    Но вообще этот вопрос настолько важен, что мне кажется в статье про «серебряную пулю для обработки ошибок» нельзя это не упомянуть. Это я, разумеется, не Вам, а автору статьи.

    Что касается решения, которое изложено в ссылке, то оно не является полным решением проблемы

    1. Что делать, если мне все-таки нужно поведение, когда, при возникновении ошибки в очередной строчке, мне нужно сразу же завершить выполнение фрагмента? А отложить ошибку в сторону и проверить в конце нельзя, так как остаток фрагмента кода будет работать с битыми данными, а это плохо.

    2. Предлагаемый в ссылке паттерн на самом деле сводит основное рекламируемое свойство Go на нет: программист в этом паттерне волен легко проигнорировать ошибку. То есть это уже не будет иметь никаких принципиальных преимуществ над обычными кодами возврата.
  • Главное преимущество Go
    +3
    Код, в котором вызывается 10 раз подряд одна и та же функция, ошибки от которой нужно обрабатывать абсолютно одинаково — то да, исключения дают более читабельный код. Нюанс в том, что такой код редко встречается, и если и встречается — то это повод для рефакторинга.


    Как раз таки очень часто встречается. Представьте себе например, что вы работаете с базой. Или с сетью. И вот у вас кусок кода который в каждой строчке в эту базу или сеть лазит. И из каждой строчки потенциально может вылететь IOException.

    Не имея возможности завернуть этот кусок кода в единый try catch, проверяя ошибочный результат на каждую операцию, вы просто задолбаетесь.

    А код распухнет вдвое, его логику будет сложнее читать из-за этих if err != nil на каждой второй строчке.
  • Архитектура сервера онлайн-игры на примере Skyforge
    +1
    Доступность сообщений на клиенте отдана на откуп интерфейсу. Если его сломать можно слать какие угодно сообщения кому угодно. Но везде, где это хоть сколько-нибудь опасно или должно быть ограниченно игрой есть серверные проверки. Тогда в логах сервера будут ошибки, мы их увидим и плохого игрока… кхм… накажем :)


    Просто по этому абзацу может создаться ошибочное впечатление, что если взломать сетевой протокол, то можно выполнять некорректные команды на сервере. А мы потом будем по логам это отслеживать и наказывать опосля. И судя по комменту про чит из Archeage это могут действительно так понять.

    Я поэтому и решил откомментить дополнительно, что все подперто, выполнить некорректную команду не получится.
  • Архитектура сервера онлайн-игры на примере Skyforge
    –1
    На самом деле это подперто и клиент никаких левых сообщений прислать не сможет.
    В аннотации @ReplicateCmd указывается уровень доступа клиентской команды. Когда команда приходит на frontend, её уровень сразу же сверяется с уровнем доступа аккаунта, и при несоответствии она не будет выполнена и еще в лог напишут, что была попытка взлома.

    Поэтому даже если игрок сумеет с клиента отправить какой-то чит, он не пройдет, так как у его аккаунта недостаточно прав на сервере.
  • Хитрые задачи по Java
    +1
    да, статья получилась удачной
    спасибо
  • Как Денис Крючков выкупил Хабр у Mail.ru
    +1
    Ну например, просто на эмоциях.
    Есть люди, которые умеют отделить эмоции от бизнеса, а есть которые нет.
    Че-то накипело, че-то недодали, какие-то обиды — вот и выплеснулось.

    Если рассуждать рационально, то ссориться ему с мейлу смысла нет абсолютно никакого.
  • Альтернативные крестики-нолики
    +2
    это чудесно!
  • «Правильный» подбор программистов
    0
    После тяжелого рабочего дня я еду к ним на собеседование, попадаю под ливень, вымокаю насквозь, ругаясь про себя нахожу офис…

    А еще перед входом позвонила жена и сообщила, что наш любимый хомячок Кеша умер…