• Как я искал пацанский движок для блога
    +1

    Есть похожий на Jekyll движок для стат. сайтов — Hugo.
    Для него есть фронтенды, которые позволяют постить https://gohugo.io/tools/frontends/
    Мы используем netlify cms — это выглядит как кусок js в браузере, который ходит в наш гитлаб (приложение через OAuth) и позволяет контент-менеджеру редактировать статьи сайта. Мы его деплоим на тестовый и доступный только изнутри сайт, там контент-менеджер всё делает и потом это выкатывается на основную версию.

  • Спор о первом языке программирования: окончательное решение
    0

    В плюсах совершенно другой и особенный ООП. Я бы сказал, что он гораздо ближе к "земле" в виде сишечки, и прочего низкоуровневого — подход к управлению памятью совершенно другой, нежели в той же жабе или смоллтолке. И это очень сильно влияет на мышление и на код.

  • Спор о первом языке программирования: окончательное решение
    +1
    а о первом языке для изучения программирования

    И Go здесь однозначно проигрывает, потому что он не даёт простой и прозрачной интерактивности для детей. На нём только байты в консоли перемешивать и по сети гонять хорошо. Да и то, второго не сделать, если не понимать модель горутин. Детям это не нужно.


    Тратить год университетского обучения чтобы научить сортировать массивы в консоли — это моветон.

    Это не моветон, но данность. Со школы люди приходят с очень разной подготовкой. К тому же, уметь писать базовые алгоритмы и понимать их имплементацию — это важный навык. Это здорово помогает траблшутить всякую дичь в сложных библиотеках с плохой документацией. Возможно год — это лишнего, но потратить на это семестр — вполне нормально.


    Так вот, в обучение программированию никак не входят, например, кишки тредпула, или асинхронного рантайма

    Окей, а что входит? Базовые алгоритмы и структуры данных? Перевод задачи с языка хз в тз, а потом подбор алгоритмов под тз? В идеале списком.
    Мне просто кажется, что обучение программированию в вышке — это обучение понятиям. Итерация, рекурсия, оптимизация хвостового вызова, коллбеки, асинхронность, промисы, ивент луп, потоки, тредпул, модели памяти, модели вычислений, типы, структуры данных, объекты, итд — это всё примеры таких понятий. В идеале учебный язык должен хорошо иллюстрировать максимум таких концепций с минимумом шелухи вокруг. При этом желательно иметь встроенные средства визуализации, и, например, REPL, чтоб можно было чуть ли не на лекциях/практиках интерактивно иллюстрировать материал или график например вывести по-быстрому. Очень удобно те же сортировки иллюстрировать прямо на ходу, или то, как задачки в ивент лупе обрабатываются по очереди.
    Чтоб не надо было как в java писать кучу лишних строчек, тащить развесистые библиотеки и IDE, просто чтоб студенты по выходу из вуза писали на знакомом индустриальном языке. Ничего против java не имею, но язык проектировали явно не для обучения, а чтоб можно было человека после недельных курсов посадить промышленный код фигачить.


    есть тренд на уход от исключений в пользу сумм-типов.

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

  • Спор о первом языке программирования: окончательное решение
    +1
    Да и не сложные они.

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


    Обучать можно прекрасно и без исключений

    Студентов — нельзя. Им потом с ними жить в других языках.


    Если для совсем мелких — то есть языки типа Черепашки или Скрэтча со встроенными средствами визуализации.

    Да, пожалуй надо разделять языки для совсем детей — скрэтч итд и для первокурсников, которые пришли учиться на CS-факультеты.
    Но даже в этом случае простая визуализация средствами стандартной библиотеки (важно!) — это очень полезная штука, значительно увеличивающая вовлеченность в процесс.


    Инструменты для написания визуального интерфейса для Go есть. Они не лучше и не хуже, чем для Python, Java, C/C++ и пр.

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


    Только вот большинство задач начальном этапе — это вообще голая консоль.

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

  • Спор о первом языке программирования: окончательное решение
    0

    Go далеко не такой очевидный, когда дело доходит до горутин и каналов. Возможно их просто не нужно давать, но подозреваю без этого будет сложно, т.к. там весь Go ими пропитан. Плюс специфика result, err. В большинстве промышленных языков вместо этого используют исключения, а panic в Go сделан прямо скажем, по остаточному принципу.
    В статье ещё указывается важный момент для начинающих — интерактивность, возможность увидеть результат, т.е. наличие тех же графических примитивов (да хоть те же окошки в дельфи или egavga.bgi) или работы с html (сейчас уже не катит, потому что всю интерактивность делают на js) в стандартной библиотеке, а в Go этого нет. Go — это всё же чисто индустриальный язык, который создан в гугле для нужд написания http-сервисов, который json или другие байтики туда-сюда гоняют.

  • К вопросу о Linux (Л)
    +1

    Статья, кмк, откровенно плоха для хабра. Такое прокатило бы в lor/talks, но здесь было бы правильным показать кусочки исходников, приложить пару картинок с диаграммой взаимодействия, добавить ссылки на используемую спеку USB или развёрнутые цитаты из неё.
    И ещё крайне желательно собрать всё это в кучу и послать баг-репорт автору подсистемы, просто потому что так устроено OSS-сообщество.

  • Еще раз про обещания
    0

    я написал для этого обработчик, который роняет процесс nodejs, т.к. имхо необработанный reject == исключение.

  • Позиция инженерной команды Okko по событиям, связанным с Nginx
    +3

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

  • Open source – наше всё
    +3

    в голову приходят Elliptics и Cocaine
    они куда менее известны.
    А такой копирайт на CatBoost и ClickHouse скорее всего связан с тем, что права на написанный код сейчас явно переданы Яндексу.

  • Позиция Mail.ru Group по развитию opensource в России
    0

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

  • Open source – наше всё
    +7

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

  • Как мы в ЦИАН укрощали терабайты логов
    0

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

  • Как мы в ЦИАН укрощали терабайты логов
    0

    У меня идея такая, что если запрос успешно завершился, то это можно понять, вычитав логи по данному запросу из кафки максимум за минуту после запроса, ведь так? Соответственно можно написать относительно простой фильтр-консьюмер, который будет фильтровать логи трассировок из входящей очереди (фильтры можно легко пошардить по reqid, чтоб можно было масштабировать по числу ядер) и перекладывать уже в очередь из которой вычитывает логстеш. Если попало под паттерн семплирования (500я ошибка/время выполнения большое/req_id кратен 1000, итд) — оставляем весь трейс, не попало — выкидываем в мусорку. ЕМНИП Cloudflare про что-то подобное рассказывали.
    С другой стороны — это лишнее копирование трейсов из очереди в очередь, и я не знаю, есть ли готовые кирпичики, чтоб это быстро сделать.

  • Как мы в ЦИАН укрощали терабайты логов
    +1

    А были какие-то мысли, как уменьшить количество записываемых и сохраняемых логов?
    Первая мысль, которая приходит ко мне в голову — сэмплирование трассировок для проверки производительности. Раз логи проходят через кафку, то можно большую часть успешно выполненных запросов просто выкидывать (выкинуть всё межсервисное взаимодействие, логи БД итд, оставляя только запись на входящий nginx), не записывая никуда, они не очень нужны.

  • Flipper Zero — пацанский мультитул-тамагочи для пентестера
    +1

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

  • Flipper Zero — пацанский мультитул-тамагочи для пентестера
    +8

    ИК-порт ещё, кмк, мастхэв, чтоб безобразничать с кондиционерами и телевизорами в барах =)

  • Axios или Fetch: чем пользоваться в 2019 году?
    +2

    Пожалуй соглашусь с тем, что как правило проще написать под себя маленькую обёртку в Promise над уже существующим http клиентом, чем брать библиотеку.
    Но вот про то, что пятисотка от сервера и исключения из-за обращения к неопределенной переменной — это принципиально разное, не соглашусь. И то, и другое — ошибки выполнения, и те и другие нуждаются в обработке.
    Сама идея промисов подразумевает, что у нас есть две цепочки выполнения кода, нормальная и обработки ошибок.
    Это целый подход к потоку выполнения, и он заразен из-за асинхронной природы, т.к. расползается по всему коду — почти все места должны быть готовы к тому, что тебе из функции сразу придёт промис и нужно будет выстраивать цепочку выполнения для обработки результатов.


    Здорово прочищает мозги статья Railway oriented programming, где примеры даны на F#, но во многом перекликаются с нынешней реализацией промисов.

  • Как мы разработали устройство для контроля внимания водителей. Опыт Яндекс.Такси
    0

    интересно, получится ли ловить также водителей под веществами.

  • Как мы боремся с копированием контента, или первая adversarial attack в проде
    0

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

  • «Яндекс.Телефон» не пользуется спросом
    0

    там полгода подписки дают не на я.музыку, а весь я.плюс.
    т.е. полгода 10% скидки на я.такси в комфорте.
    ещё я.музыку можно юзать в оффлайне и это тоже хорошо.
    в общей сложности подписочных плюшек там тысячи на две наберётся. Если грамотно абузить, то возможно побольше.

  • «Яндекс.Телефон» не пользуется спросом
    +1

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

  • «Яндекс.Телефон» не пользуется спросом
    +1

    до меня гуглокарты точно также докапываются всё время.
    отключал. через полгода снова началось — галка слетела.
    недавно я.карты тоже стали с этими вопросами докапываться, тоже отключил это.

  • [лонгрид] 20 лет программистской карьеры в большом маленьком городе
    +1

    Работу иногда хочется сменить и сложности с продажей/покупкой в другом районе — останавливающий фактор. в масштабах москвы жить на съёмной квартире удобнее кмк. // хотя тут вылазят другие тонкости, если ты семейный человек с детьми.

  • [лонгрид] 20 лет программистской карьеры в большом маленьком городе
    0

    в Ижевске, в отличие от Москвы не такая плотность транспорта, даже в час пик вряд ли придётся сидеть в машине больше часа — устать от вождения просто не успеваешь.
    Вне часа пик поездка через весь город занимает около получаса и довольно приятна.

  • [лонгрид] 20 лет программистской карьеры в большом маленьком городе
    +1

    в ижевске радует только то, что такси из одного конца города в другой стоит 200р, т.е. отсутствие транспорта в позднее время неприятно, но не фатально.

  • DevConf: переход Uber с PostgreSQL на MySQL
    0

    если верить этому, то изменения видны ещё до коммита
    https://stackoverflow.com/a/3364466/1049821


    but SQL Server does not version metadata, and so changes would be visible to others before the transaction commits.

    или это поведение уже изменено в более свежих версиях?

  • DevConf: переход Uber с PostgreSQL на MySQL
    +1

    Хорошо, где у MS SQL транзакционный DDL?
    Мне сильно нравится возможность Postgres в отдельной транзакции, никому не мешая (почти), накатить непростой апдейт на схему БД и откатиться, если что-то пойдёт не так.

  • Python, Delphi и C++ глазами учёного
    0

    есть. я под blackfin немного трогал 8 лет назад.

  • Python, Delphi и C++ глазами учёного
    0

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


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

  • Python, Delphi и C++ глазами учёного
    +1

    Строго говоря, мне неоднократно приходилось править вылетающий чужой расчетный код на Delphi именно из-за неаккуратной работы с памятью. В поведении с динамическими массивами Delphi почти ничем не отличается от C++, кстати проверка границ работает только для статических массивов и выполняется ЕМНИП только на этапе компиляции, в рантайме можно легко напороться и на use after free и на вылет за границы.


    Python не очень хорош, т.к. быстро работающие расчётные библиотеки тоже могут иметь свои протекающие абстракции и взрывы из-за недостатка точности etc. Но с другой стороны, ученые уже к нему привыкли как к инструменту, могут быстро его освоить и худо-бедно читать/писать.

  • Объясняем современный JavaScript динозавру
    0

    ну вот примерно об этом и речь.

  • Объясняем современный JavaScript динозавру
    0

    Сейчас веб-версию слака сильно переписали в лучшую сторону. Десктопная версия пока что ужас-ужас. =(

  • Объясняем современный JavaScript динозавру
    +1

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

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0

    я и не утверждаю, что схема ломается постоянно.
    На одной итерации добавилось поле, на другой стало not null, на третьей потребовалось поменять логику взаимодействия этого поля с другими, на четвертой — материализовать значение/агрегат в другую таблицу.
    Просто такие изменения потихоньку наслаиваются друг на друга и потом становится очевидно, что мы из существующего решения уже выросли и время немножко поменять нормализацию в отдельных кусочках итд.
    Неприятность заключается в том, что при рефакторинге надо очень хорошо тестировать, а SQL штука сильно завязанная на данные и требует большое количество тестов, если хочется надёжности.

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0

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


    Увы, не всё можно загнать под общую готовую схему.
    Иначе заказчик уже купил и внедрял бы готовое решение.
    Иначе бы всё ПО уже давно бы написали.

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0
    Оракл и постгрес прекрасно справляется с сотнями джойнов, он для этого и предназначен.

    Кем и как это проверено? Это сильно зависит от структуры таблиц, данных, статистики, индексов, объёма данных.


    Вы не справляетесь.

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


    мы не умеем в скл

    Мой пойнт в том, что не существует единого SQL, который всегда одинаково хорошо работает на любой СУБД. В каждом движке есть грабли и тонкости, из-за которых часто приходится делать иначе, чем в другой СУБД. Запрос, который идеально работает в pgsql, может быть неэффективным в oracle или в принципе не реализуемым (привет, пагинация в oracle 11, боже, как я ржал, когда увидел правильное решение). И это нормально.


    выбрасываем деньги на оракл

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


    но пользуем иерархическую бд 30-летней давности

    ??? не понял, откуда такой вывод.


    P.S. а можно без ad hominem и апломба? раздражает же и убивает адекватную дискуссию.

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0
    — оно стоит того

    А теперь новая вводная — требуется импортозамещение на Postgresql. =)


    Глупости, можно конечно.

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


    Если слова «десяток джойнов» смущают ораклиста то его надо заменить, этот негодный

    Десяток джойнов куда больше смущают оракловый оптимизатор, у которого случается горе от ума. И помимо ораклиста есть ещё другие члены команды, которые пишут и читают SQL, так что не поможет. Уж лучше аккуратненько писать ХП и потом их бить на кусочки, да оптимизировать помаленьку.

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0

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

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0

    По первому абзацу целиком и полностью согласен.


    Кстати, это не очень связано с невозможностью работать с большими данными. Размер данных зависит от возможностей файловой системы.

    Что есть большие данные? Я раньше слышал определение — они не влазят в ни в один из доступных на массовом рынке серверов. И там далеко не только в файловой системе возникают проблемы.

  • Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем
    0

    Не было бы нормальных людей, шарящих в СУБД, мы бы за хранимые процедуры даже не стали бы браться. Писали бы всё на аппсервере. Другое дело, что с большинство ораклом раньше не работали.
    Есть у нас хороший ораклист. Целый один. Но скорость развития проекта просто не та, при которой он бы успевал что-то сделать.
    И ещё живых ораклистов за вменяемые деньги найти — это огромная проблема.
    И нет, нельзя написать запрос так, чтобы он был одновременно читабельным, поддерживаемым и при этом всегда делал что надо, в условиях, когда нужно регулярно менять что-то в схеме, добавлять/убирать возврат каких-то полей, когда поля скачут из not null в nullable итд.
    Обычные запросы в таких условиях очень быстро превращается в убористую кашу с десятком джойнов и вложенных запросов, которая завешивает и оптимизатор, и ораклиста.
    Тупые хранимые процедуры с последовательной логикой работают просто чудесно на этом фоне. И никаких вопросов с транзакционностью.