Не специалист, но вроде можно сильно ускорить вашу реализацию метода отжига, если в каждой итерации не пересчитывать расстояние маршрута полностью. Если правильно представляю, то достаточно сравнить длину двух старых и двух новых отрезков чтобы понять уменьшится общая протяженность или нет. В случае большого количества городов можно потратить это время на новые попытки улучшить результат.
Муравьиный алгоритм еще не смотрел. Спасибо за статью, очень интересно.
На счет безопасности, в некоторых CI есть интересная встроенная защита от таких случаев.
Пошло от Travis CI, по-моему, Например, как это реализовано в drone.
Переменные зашифровывают и заливают в корневую папку вместе с сигнатурой на файл конфигурации.
Поэтому если файл изменится CI откажется подставлять зашифрованные переменные в эту сборку.
Возможно и в Gitlab CI есть нечто подобное.
Насчет навалимся, можно подготовить конкурс (наподобие фильтрации почты на js и других).
Каждый процент результата может сильно упростит жизнь в итоге.
Не помню, были ли задачи в области распознавания речи, в поиске вижу, что что-то было.
Как уже говорили, задача сложная и интересная, можно применить множество знаний.
Начать с фильтрации шумов и закончить попытками предсказать будущее)
Причем, можно не сильно ограничивать участников в выборе инструментов, количестве попыток и т.д.
Предполагаю, потребуется приличная выборка слов речи, не знаю в каком формате, наверно wav какой-нибудь)
Знаю, что случаи разные. Возможно, вопрос больше даже адресован пользователям, среди которых есть специалисты.
Может ли в данном случаи работать электроэнцефалография. Я так понимаю, ЭЭГ следит за электрической активностью мозга и сам не вырабатывает никаких полей. Просто в свое время наталкивался на кучу девайсов подобного рода для разработчиков игр, некоторые даже с инструментами под разные платформы. Возможно, не стоит рассматривать их так серьезно. Но может найдутся те кто пробовал и смогут сказать пару слов о том насколько они отзывчивые и сложно ли приучиваться.
Любителям перфоманса советую посмотреть доклад одного из разработчиков V8, Вячеслава Егорова, «Производительность JavaScript через подзорную трубу». Понравились примеры, в которых компилятор считает ваш код недостаточно сложным!)) и не оптимизирует его, поэтому нужно добавлять всякий мусор)). Также узнал про «раскрутку цикла». Отличные впечатления от самой конференции, спасибо докладчикам и организаторам!
Полностью согласен, в примере с ES6 тоже не все обратимо. Мне больше нравится более узкий термин для таких инструментов.
Compiling is the general term for taking source code written in one language and transforming into another. Transpiling is a specific term for taking source code written in one language and transforming into another language that has a similar level of abstraction.
В любом случаи, есть все шансы получить обратно очень даже качественный код (конечно, не исходный), особенно, если большая часть этого кода была скомпилирована автоматически.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
var User = (function () { function User() { ... }; User.prototype.name = ...; return User; }());
Стрелочные функции, которые выглядят как то так
(function () { return ({...}); });
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Да, возможно, кому-то как и мне будет радостно узнать, что актуальные версии редактора есть под linux.
Пробовал запускать демки на Linux Mint, очень круто, просто дальше их сайта никогда не заглядывал.
Есть инструменты ES5 -> ES6, например lebab. Возможно есть подобия и для TS.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Верно, типизация в TypeScript опциональна и не причиняет больших не удобств, даже наоборот! )
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Расширяется все и атомы тоже, но расширение в области атомов чуть медленнее, чем в области протранства между атомами (зависимость от энергии) и поэтому кажется, что атомы отдаляются. Мне почему-то легче представлять все наоборот, что вселенная отсается прежней, а объекты в ней уменьшаются пропорционально имеющейся энергии и поэтому кажется, что все будто бы разлетается. Не знаю, эквивалентны эти взгляды или нет.
10 мин процессорного времени для экономии 1 гигабайта.
Потом каждый раз по 5 мин с кэшированием и надеждой переложить на пользователей и их браузеры.
Если не ошибаюсь, тут пропорционально увеличиваются риски, так как возрастает ценность битов…
Не тоже самое, конечно, что реплику отключить на несколько петабайт, но все равно))
Я бы назвал эти искусственные ограничители (цена, зрелищность, компактность) преимуществами, которых нужно добиться и философский как бы не станет. А результат у вас, действительно, получился зрелищным и увлекательным, очень круто.
Здесь уже отмечали проблему серверных решений и самого стандарта, поэтому не стал расписывать.
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
Я бы посоветовал попробовать на транслирующем сервере nginx-rtmp модуль, вся работа будет напоминать работу со статикой (ретрансляции, балансировки, cdn… )
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Муравьиный алгоритм еще не смотрел. Спасибо за статью, очень интересно.
Пошло от Travis CI, по-моему, Например, как это реализовано в drone.
Переменные зашифровывают и заливают в корневую папку вместе с сигнатурой на файл конфигурации.
Поэтому если файл изменится CI откажется подставлять зашифрованные переменные в эту сборку.
Возможно и в Gitlab CI есть нечто подобное.
Каждый процент результата может сильно упростит жизнь в итоге.
Не помню, были ли задачи в области распознавания речи, в поиске вижу, что что-то было.
Как уже говорили, задача сложная и интересная, можно применить множество знаний.
Начать с фильтрации шумов и закончить попытками предсказать будущее)
Причем, можно не сильно ограничивать участников в выборе инструментов, количестве попыток и т.д.
Предполагаю, потребуется приличная выборка слов речи, не знаю в каком формате, наверно wav какой-нибудь)
Может ли в данном случаи работать электроэнцефалография. Я так понимаю, ЭЭГ следит за электрической активностью мозга и сам не вырабатывает никаких полей. Просто в свое время наталкивался на кучу девайсов подобного рода для разработчиков игр, некоторые даже с инструментами под разные платформы. Возможно, не стоит рассматривать их так серьезно. Но может найдутся те кто пробовал и смогут сказать пару слов о том насколько они отзывчивые и сложно ли приучиваться.
В любом случаи, есть все шансы получить обратно очень даже качественный код (конечно, не исходный), особенно, если большая часть этого кода была скомпилирована автоматически.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
Стрелочные функции, которые выглядят как то так
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Пробовал запускать демки на Linux Mint, очень круто, просто дальше их сайта никогда не заглядывал.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Интересно, насколько вредно вдыхать такой пластик
Потом каждый раз по 5 мин с кэшированием и надеждой переложить на пользователей и их браузеры.
Если не ошибаюсь, тут пропорционально увеличиваются риски, так как возрастает ценность битов…
Не тоже самое, конечно, что реплику отключить на несколько петабайт, но все равно))
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Ну технологии и цели, конечно, тут разные
интересен вклад стабилизаторов и сколько топлива требуется чтобы он стоял как вкопанный, на примере такого опытного человека не понять