Pull to refresh
80
0
Дмитрий @AlexWriter

software developer

Send message
думаю, что да.

git clone https://github.com/esrlabs/chipmunk.git
cd chipmunk
rake full_pipeline


Релиз увидите в

chipmunk/application/electron/dist/release

На борту надо иметь:
  • node 10 и младше
  • ruby 2.6 и младше
  • rust
Полностью с вами согласен, юзкейсов очень много. И далеко не всегда логи хранятся удалённо. У нас, например, довольно большая группа пользователей, работающих с embedded software. И там можно получать десятки гигобайт логов лишь за ночь или за одну сессию тестирования. При этом логи часто бывают от нескольких источников, что вовсе не облегчает жизнь. Ну и конечно, такие логи живут более ли менее локально.
Спасибо за ваш вопрос. Там были изменения в порядке подписания приложения. Мы «покрыли» тот порядок, который установлен на 10.15 и младше, и, честно, не стали заморачиваться над поддержкой процедуры подписания для более поздних версий. Дело только в подписи. Решили, что если появится issue на этот счёт, то обязательно добавим поддержку более ранних версий ОС, но пока запросов не поступало.
нет, релизы пока публикуются только на github
Спасибо за ваш совет. Как ответить — не знаю. Задумался. Ведь так то вилка умеет три четверти того, что делает ложка, но меж тем она существует :/
Спасибо за ваш комментарий.
Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
Спасибо за ваш комментарий. Я отвечу сравнением, если позволите.

В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.

Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.

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

ЗЫ. Кстати ripgrep шустрее )
Не бывает «некуда уходить». Бывает только «страшно». Просто начинайте смело работать над своим желанием лучшего. Заставьте себя хотеть перемен. Убедите себя в том, что иного выхода, кроме как двигаться вперед у вас тупо нет. Прямо так – или я тут в конце концов сопьюсь (утрированно), или я стану крутым парнем из столицы. Никто, вообще никто не держит вас на месте, кроме вас самих. Поймите это, и все потихонечку начнет двигаться.

Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.

Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
Спасибо, сработали суеверия. Вы совершенно правы. Подправил, обновил.
Если у вас есть событие «Aa» и событие «a», то это два разных события.
Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.

С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).

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

Но я никак не могу понять, что вы хотите сказать/доказать?

  • Что react знает больше людей? Очевидно.
  • Что я покусился на святое? Я уже ответил Вам ниже, что никто react «уделывать» не собирается.
  • Что react и подобное нужно использовать везде (даже в до безобразия маленьких проектах)? Весьма и весьма спорный тезис.
  • Что не нужно / нельзя / запрещено искать собственные решения для тех или иных задач? А как же тогда тот же react на свет появился? До него, что не было альтернатив? А как быть с нашим Яндексом? Уж сколько он «пилит» своих решений. Он тоже плохой?
  • Или может вы считаете, что если некий проект сделан на react, то его с ходу «прочитает» любой сторонний разработчик? Да, нет. Все также придется какое-то время сидеть и разбираться, что к чему.


Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.

Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.

То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.

Спасибо.
У меня, конечно, то еще самомнение, но в одиночку противопоставлять себя замечательным, талантливым и умным ребятам, создавшим react?

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

Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.

Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.

Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.

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

Спасибо за ваш вопрос и ваше время на эксперимент )

Ну на самом деле – это верный подход. Должны быть некие свойства/характеристики, которые отличают продукт от его конкурентов/аналогов.

Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.

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

  • Избегание дополнительного окружения (библиотек, тулзов и прочего). Полная самодостаточность и возможность расширения функционала внутри решения со стороны разработчика. Это уже во многом реализовано. Flex.Patterns легко позволяет добавлять свой функционал к тому, что уже есть. Скажем вы «прицепились» к узлу, Flex.Patterns даст вам основной набор инструментов (ну там события прицепить, размеры снять, стили переопределить, анимацию применить и прочее). Но на ряду с этим у вас есть простой интерфейс для добавления своих инструментов к данному функционалу и, что очень важно, интегрировать эти вот свои инструменты внутрь Flex.Patterns – то есть делать свою собственную сборку конечного продукта.
  • Только стандартный синтаксис. Ну об этом я уже очень много говорил.
  • Хранение шаблонов и их ресурсов на клиенте.


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

Спасибо за ваш вопрос.

Information

Rating
Does not participate
Location
Словения
Date of birth
Registered
Activity