9 лучших опенсорс находок за август 2019

    Доброй осени, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за август 2019.


    За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).


    В сегодняшнем выпуске.
    Технологии внутри: Python, Rust, JavaScript, Go.
    Тематика: веб разработка, администрирование, инструменты разработчика.


    heartrate


    Простая визуализация выполнения вашей Python программы в реальном времени.
    Написано на и для Python.


    Ссылка


    heartrate gif


    npkill


    Утилита для поиска и удаления всех node_modules на вашей системе. Чистит сотни мегабайт места!
    Написано на TypeScript.


    Ссылка


    npkill demo


    ciao


    Утилита для простого мониторинга HTTP адресов и статус кодов. И проверок здоровья. С красивым веб-интерфейсом.
    Написано на Ruby.


    Ссылка


    ciao http


    returns


    Набор примитивов для написания типизированных монад и способов их трансформации и композиции.
    Написано на и для Python.


    Ссылка


    returns demo


    pastel


    Утилита для работы с цветами из командной строки.
    Написано на Rust.


    Ссылка


    pastel demo


    chart.xkcd


    Библиотека для создания графиков в стиле xkcd.
    Написано на JavaScript.


    Ссылка


    chart.xkcd


    portray


    Утилита для генерации документации из исходного Python кода.
    Написана на и для Python.


    Ссылка


    portray demo


    nushell


    Новый shell от Yehuda Katz (Ember.js) и Jonathan Turner (TypeScript, Rust). Главная идея: все внутри = данные.
    Написано на Rust.


    Ссылка
    Ознакомительный пост в блоге создателя


    nushell


    wtf


    Дашборд внутри вашей командной строки.
    Написано на Go.


    Ссылка


    wtf


    Бонус!


    Одна из самых интересных статей за минувший период (хотя фактически она написана в июле) — статья Дена Абрамова про Algebraic Effects. Написано просто, доступно, есть ссылки на более глубокие материалы: https://overreacted.io/algebraic-effects-for-the-rest-of-us/


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

    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 44

      +1
      А есть утилиты меряющие глубину стека и выдающие его статистику для конкретного метода?
        0
        Вы говорите про какой-то конкретный язык?
          –1
          Глубина вызовов я думаю присутствует на любом языке. Но хотелось бы анализатор бинарника. Под MSVC было бы не плохо, соответственно любое сопутствующие языки C#, С++, C…
            0
            Т.е. без запуска кода измерить стек? Это невозможно сделать, ровно как и доказать математически корректность кода.
              –1
              То есть если взять исходный код и проанализировать все вызовы функций по тексту, также как и сделать это с бинарником по методу машинного кода CALL — это не возможно?
                +1
                Псевдокот:

                void recursive(int value)
                {
                if(value==0)
                return;
                else
                recursive(random(0..100));
                }


                Анализ Exe-шника ничего не скажет о возможной глубине стека.
                  –1
                  Анализ EXE может более объективно показать стек, поскольку функции с возможным inline будут отсутствовать. Пример с рекурсией можно отсечь по воссоздаваемому стеку при анализе, проверяя повторные вхождения методов. Смысл анализа не в логике возможных ветвлений, а в глубине вложенности методов.
                    0
                    Не, понимаю зачем это нужно, но по-моему IDA или одно из её расширений это умеет.
                      0
                      Как небольшая бонус фича. Во время дебага и так все видно. Но никто не будет специально дебажить каждую функцию и записывать все варианты стеков, скажем, для соблюдения принятой архитектуры кода. Иногда это помогает оценить нагруженность отдельного метода, вложенностями или вызовами. Ну и помощь при рефакторинге, также как и помощь при разборе незнакомого кода.

                      А когда у тебя получается неявная рекурсия, то это будет сразу видно.

                      Скрытый текст
                      Мне как-то также говорили что нормали для трехмерной модели пересчитать невозможно и не приемлемо, из ряда «российских ученых». Тем не менее функция присутствует в любом движке и даже не требует от редактора сохранять сами нормали модели. На что я получал возглас «ну, это же в движке» — как-будто это магия маленьких зеленых человечков, которые живут внутри этой функции.
                        +1

                        А что там с нормалями было-то, как обосновывалось?


                        Необходимая глубина стека-то неопределяема из-за проблемы останова, тут "а, ну это в движке" не пройдёт.

                          0
                          «А ну это в дебаге», подойдет? Я уже описал область применения и реализуемый алгоритм, не говоря уже об имеющемся полноценном аналоге.
                          А что там с нормалями было-то, как обосновывалось?
                          CrossProduct или векторное умножение не считает объективно только параллельные вектора, но треугольник с параллельными сторонами сам по себе исключаем. Результат есть всегда. Что же касается конкретики расчета нормалей на множестве треугольников, то это задача изначально алгоритмическая и как таковых «пользовательских» нормалей нет. Разве что в виде карты нормалей и прочего уже ручного вмешательства в цепочку от моделирования до рендеринга. Ну и соответственно все утверждения что реализация подобного алгоритма невозможна от лукавого.
                  0
                  Если функции умеют вызывать себя (рекурсия) — в общем случае невозможно
                    –1
                    Есть более сложные примеры с динамическими указателями, в которых действительно хотелось замерить глубину стека, но вот то что это «невозможно» утверждать поспешно. Поскольку тут можно эмулировать вызов метода заданный в ручную.
                      +2
                      Это практически классическая проблема останова

                      ru.wikipedia.org/wiki/Проблема_остановки

                      Которая доказательно не имеет решения для тьюринг-полных языков.

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

                      Примером таких языков являются некоторые (несовременные) языки шейдеров.
                        –1
                        Есть задача с данными: склад с 10 тоннами зерна, настало время раздачи зерна нулевому количеству потребителей. Сколько зерна получит каждый потребитель? Вспоминая утверждение что «на ноль делить нельзя» — задача не решается. Тем не менее каждый потребитель получает 0 зерна или ни сколько.

                        Вот и у вас, точно такая же, трактовка решения задачи «на ноль делить нельзя» — задача не решаема, конец.

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

                          Вот пример решения: Запустить и посмотреть.
                          Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».

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

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

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

                            имеет мало пользы
                            Если брать все возможности интеллисенса, то по отдельности они все тривиальны и имеют мало пользы.
                              +1

                              Если у вас есть абстрактные методы — то бинарник вашей программы каким-то простым алгоритмом уже не проанализировать. Вы просто не сможете узнать те самые "такие же вышестоящие ссылки" без выполнения декомпиляции.

                                –2
                                Зато есть и другие методы. Но в вашем примере результат [0..0] для метода на который должны ссылаться. Но если указать конкретный метод (любого из наследуемых классов) — смоделировать ситуацию, то проблем нет, и декомпилировать ни чего не требуется, тем более при наличии дебаг информации. Для чистого EXE утилита была бы пригодна к дизассемблерам, но смысла в ней мало.

                                Получать такою информацию без использования IDE, которая уже может и дебаг получить и все остальное подвязать, вообще смысла нету. Поэтому это очередной пример сферического коня в вакууме. На ряду с реальными примерами использования которые вы продолжаете игнорировать.
                                  –2
                                  Да я запамятовал, MSVC прекрасно показывает декомпилированный код, проблем также, c выдуманным камнем преткновения, не вижу. Но сам по себе анализ EXE подразумевает его своеобразную декомпиляцию на уровне алгоритмов анализа. Да, это сложный момент, но реализуемый. При этом не требует составления полного аналога дизассемблера. Тут достаточно определять размер команд в машинных кодах. Но все будет зависеть от сложности алгоритма анализа.
                      0

                      Конечно нет, учёные мужи бились над этой проблемой ещё в прошлом столетии. А иначе никто бы просто тесты не писал. Если я правильно понял вопрос, то он сводится к подзадаче https://en.wikipedia.org/wiki/Halting_problem
                      Попробуйте, может удастся решить, впишите себя в историю :)

                        –3
                        Очень сложно спорить с людьми утверждающие что что-то невозможно, основываясь на тривиальных научных терминах, в то время когда этим активно пользуются, в том или ином виде. Меня всегда удивляла такая упоротость.
                          +2

                          Ещё раз — можно построить flame graph во время работы, можно построить граф вызовов по коду, но однозначно предсказать заранее глубину стека во время будущей работы — нет, нельзя.
                          P.S. Я думал у нас конструктивный разговор, а Вы теорему называете "тривиальным научным термином". В этом свете даже не так обидна моя "упоротость". Ловите заслуженный минус в карму.

                            –3
                            Ещё раз — можно построить flame graph во время работы, можно построить граф вызовов по коду, но однозначно предсказать заранее глубину стека во время будущей работы — нет, нельзя.

                            Вот вы сами со своими выводами спорите и хотите назвать это конструктивным разговором? А тем временем я ни где не конкретизировал «предсказание стека» — даже в такой формулировке ВОЗМОЖНЫЙ вариант стека, даже на уровне выше и ниже по вызовам метода, без каких либо данных (как часть дерева и каким либо другим образом), уже реализуемое решение. Но в ходе разговора я слышу только что — это не возможно. Какой тут возможен конструктив если вы, игнорируя реалии, все уже за меня додумали и решили?
                            Я же говорил о какой либо статистике! Опять же разговор о прогнозах или реальной работе все это уже реализовано как статически так и профайлерами.

                            Само по себе слово «предсказание» не требует ни какой точности лишь приближения к варианту работы. Но нет — это невозможно. А иначе как назвать такую зацикленность, на невозможности решения кроме как «упоротость»?

                            Сложности в реализации возможны для любой задачи, но кидать свое «профессиональное» «не реализуемо» в представлении только своего не реализуемого, не обозначенного и не обоснованного варианта — нет тут ни какого конструктива.
                              +1
                              Предсказать и построить постфактум — в этом ключевая разница. Если ее учесть, противоречий в моих словах нет.
                              По поводу «додумали» — основывался на этом:
                              Анализ EXE может более объективно показать стек

                              задал уточняющий вопрос:
                              Т.е. без запуска кода измерить стек?

                              Вы его не опровергаете, а задаете свой уточняющий к слову «невозможно»:
                              То есть если взять исходный код и проанализировать все вызовы функций по тексту, также как и сделать это с бинарником по методу машинного кода CALL — это не возможно?

                              Соответственно я делаю вывод, что именно эту тему обсуждаем, а именно получение глубины стека без запуска, что в моем понимании является предсказанием.
                              Ок, уточню свою мысль — эту задачу корректно решить невозможно. Примерные эвристические алгоритмы могут существовать и неплохо работать на практике.
                                –2
                                Ок, уточню свою мысль — эту задачу корректно решить невозможно.
                                Иначе говоря «предсказание», на основе полученных данных от ветвлений методов, на основе конкретных адресов вызова или названий функций — получить не возможно. И тебе это не кажется противоречивым?

                                У меня есть данные что метод «вызывался..» и «вызывал..», а соответственно построить листы этих последовательностей (уже имеющееся решение), и на основе этого я не могу получить ни какого предсказания. ЗАШИБИСЬ.

                                Соответственно я делаю вывод
                                Ты понимаешь, что ты делаешь вывод о том что невозможно сделать анализ текста или бинарника! Сюда же можешь поставить в ряд, невозможность открытия файла в тотал командере.

                                корректно
                                Корректно это делает дебагер и то не каждый (возможно это вопрос так же и для дебагера), а не представленный мною алгоритм. И как я уже сказал это твое представление о корректности предсказания в твоей необхобимости решения задачи, о которой я не упоминал.
                                  +1
                                  Иначе говоря «предсказание», на основе полученных данных от ветвлений методов, на основе конкретных адресов вызова или названий функций — получить не возможно. И тебе это не кажется противоречивым?

                                  Нет, не кажется.


                                  Сюда же можешь поставить в ряд, невозможность открытия файла в тотал командере.

                                  А какая тут связь?

                                    –2
                                    А какая тут связь?

                                    Передо мной целая статья об утилитах которые анализирует файлы, а мне только что сказали — «этого сделать невозможно». Да еще о том что связи, с тем что «открыть файл в тотал командере — невозможно», ни какой нет.
                                    facepalm.

                                    В рамках своих же восклицаний о «невозможности» могли бы представить случай когда доступ к файлу происходит несколькими программами.

                                    И вы хотите от меня конструктивизма?
              0
              sobolevn Спасибо за подборку.

              heartrate — Простая визуализация выполнения вашей Python программы в реальном времени.

              portray — Утилита для генерации документации из исходного Python кода.
                0
                Поправил, спасибо!
                +4
                Для меня удачной и своевременной находкой был Gitea — веб-интерфейс для работы с репозиториями git (очень похож на GitHub), который можно установить локально. Для тех, кто привык к GitHub, но хочет держать исходники на локальном сервере — отличная находка.
                  0
                  Видимо их сайт словил Хабр-эффект, хорошая реклама
                    +3

                    Скорее РКН-эффект.
                    TL;DR: Они хостятся в Digital Ocean, и часть их IP-адресов заблокировано всякими разными инстанциями.

                    0
                    Который к тому же, в 10-15 раз легче GitLab
                      0

                      GitLab во многом сильно впереди. Тем более, если речь идет про коллаборативную работу.
                      (да, у gitea тоже есть плюс — она сильно легче по необходимым вычислительным ресурсам для работы)

                      0
                      За npkill спасибо :)
                        +2
                        а как же Sampler
                          +17

                          А как же The fuck?
                          На github ~ 46K☆ между прочим!


                            +2

                            rm -rf / он тоже исправит на sudo rm -rf / ?

                              0
                              Для gcc нет такого же? :)
                                +2
                                Ей сто лет в обед, а пост вроде про август.
                                  +1
                                  хмм, идея отличная!
                                  только вот когда оно не так исправит, и что-то с концами грохнет, будет не так прикольно)
                                  0
                                  Я думал заняться визуализатором процесса компиляции, чтоб смотреть за тем, как красиво твой код не компилируется, но всё руки не доходили.
                                    +1
                                    Одна из самых интересных статей за минувший период (хотя фактически она написана в июле) — статья Дена Абрамова про Algebraic Effects. Написано просто, доступно, есть ссылки на более глубокие материалы: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

                                    Посмотрел. Мое мнение нисколько не может считаться авторитетным, но пока мне начинает казаться, что JavaScript'еры извращенцы. Вместо того, чтобы пользоваться тем, что уже есть в других языках, они пытаются сделать JS лучше. То, что при этом придется тащить груз совместимости их не пугает. Касательно алгебраических эффектов — ну, похоже на callback'и (они даже в Си реализовывались с грехом пополам), только не нужно переписывать весь стек вызовов, т.е. интерпретатор добавляет эту фичу скрыто, но ценой еще меньшей эффективности интерпретируемого кода. Вот интересно — когда же мы остановимся в создании этих абстракций над абстракциями? Почему не попытаться взять более лучшие (ага) инструменты (типа Rust, Haskell etc.), а не "усовершенствовать" свой велосипед? Ответ у меня только тот, что перечисленные инструменты требуют квалификации для использовании. А на js — сел и начал писать код.

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

                                    Самое читаемое