С окружением все нормально, поднимается без проблем — этот пункт не стоит брать во внимание в вопросе о нужности/ненужности typescript.
В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.
Давайте разберем, я не против. На 20-ом ходу после взятия черной ладьи получаем данную позицию.
В случае хода черных на f1 с проведением пешки в ферзи, белые тут же съедают оного на 21-ом ходу с шахом, вынуждая черного короля пойти на a2, после чего продолжается та же самая свистопляска с шахами и постановкой белого ферзя на c4 при черном короле на b1, вынуждая черных точно так же продолжать отдавать фигуры (ходить пешками) вплоть до последнего цугцванга, когда фигур для «отсрочки мата» уже не останется.
Полагаю, что нарушение последовательности, наоборот, может лишь приблизить мат.
Суть — используя характерный прием с последовательностью шахов и ключевое поле с4, вынуждать черных отдавать одну за другой фигуры в цикле до возникновения цугцванга, после которого и следует неизбежный мат. Если черные проведут ферзя, то белые его съедят и мясорубка продолжит работать дальше по тому же принципу.
Что туда в src только не пробовал пихать народ в свое время.
Начиная с "about:blank" и "#", заканчивая всякими "//:0" и "file://", варианты в сочетании с opacity:0, чтобы не было видно «битой картинки» и т.д.
Веселое было времечко.
Представилась некая кнопка/режим — при нажатии появляется возможность помечать участки текста и оставлять к ним описание. Так же становятся видны уже помеченные участки, что позволит избежать множественных однотипных сообщений автору, а также станет сигналом для желающего указать на ошибку, мол, на нее уже обратили внимание.
К сожалению, практика показывает, что либо музыка, либо «стартап» )
Независимому музыканту нормально зарабатывать на музыке (под этим я подразумеваю что-то хотя бы как-то заслуживающее внимания, а не заезженные мейнстримовые шаблоны) практически нереально — в лучшем случае копейки и необходимость тратить время на кучу не особо приятных вещей, которые необходимо делать в «стартапах». Короче, на работе работать все равно придется )
Да и вообще, если музыкант изначально ставит себе цель, отличную от непосредственно творчества и смещает акцент в сторону «заработать на музыке» — это изрядно попахивает.
Однако, прорекламировать себя на хабре и не словить минусов — это бесценно ;)
Asynchronous operations. The editor should never, ever block and prevent the user from getting their work done. For example, autosave will spawn a thread with a snapshot of the current editor buffer (the peristent rope data structure is copy-on-write so this operation is nearly free), which can then proceed to write out to disk at its leisure, while the buffer is still fully editable.
Наткнулся не так давно на упоминание, что сейчас гугловцы во главе с тем самым Raph Levien пилят некий «Xi editor» на rust. Обещают, мол, круто и производительно все будет, но до нормального релиза ждать еще долго. Тем не менее, 4K звезд им уже понатыкали на github. В общем, если кому интересно будет: https://github.com/google/xi-editor
— «Главный симптом торможения – это торможение.» Это можно цитировать.
Вот это тоже неплохо:
«Но стоит упомянуть про новый элемент picture, который, будучи предназначен для адаптивных решений, тем не менее, снижает нагрузку и на производительность сайта.»
Я тут заканчиваю небольшой бойлерплейт для создания chrome-расширений на базе webpack с hot module replacement и автоматическим chrome.runtime.reload() при компиляции, есть мысли по завершении статейку написать.
Про контексты в расширениях — это довольно значимый пунктик, в частности, доступ к chrome API из injected-скриптов, доступ к js-окружению на странице, контекст применения HMR-обновлений (т.к. это не обычная страница, пришлось немного подпилить механизм hot-апдейтов) и т.д. нюансы.
Если будут желающие поучаствовать словом и делом — буду рад.
Много чего сейчас есть. Например, определенной (и вполне заслуженной) популярностью пользуется сборка на webpack с использованием npm-скриптов (для действий не покрываемых сборщиком).
«Накладные расходы» на поддержку нормальной модульности минимальны, призывы «только конкатенация» непонятны.
Содержательно.
Хоть бы написали, что из себя представлял проект.
Цитата с github:
«Post Hawk — это сервис, предоставляющий простое и понятное API, для организации связи между мобильными и web приложениями в режиме реального времени.»
В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.
Пропаганда, если не самоубийств, то, как минимум, наркотиков.
В случае хода черных на f1 с проведением пешки в ферзи, белые тут же съедают оного на 21-ом ходу с шахом, вынуждая черного короля пойти на a2, после чего продолжается та же самая свистопляска с шахами и постановкой белого ферзя на c4 при черном короле на b1, вынуждая черных точно так же продолжать отдавать фигуры (ходить пешками) вплоть до последнего цугцванга, когда фигур для «отсрочки мата» уже не останется.
Суть — используя характерный прием с последовательностью шахов и ключевое поле с4, вынуждать черных отдавать одну за другой фигуры в цикле до возникновения цугцванга, после которого и следует неизбежный мат. Если черные проведут ферзя, то белые его съедят и мясорубка продолжит работать дальше по тому же принципу.
Начиная с "
about:blank" и "#", заканчивая всякими "//:0" и "file://", варианты в сочетании сopacity:0, чтобы не было видно «битой картинки» и т.д.Веселое было времечко.
Независимому музыканту нормально зарабатывать на музыке (под этим я подразумеваю что-то хотя бы как-то заслуживающее внимания, а не заезженные мейнстримовые шаблоны) практически нереально — в лучшем случае копейки и необходимость тратить время на кучу не особо приятных вещей, которые необходимо делать в «стартапах». Короче, на работе работать все равно придется )
Да и вообще, если музыкант изначально ставит себе цель, отличную от непосредственно творчества и смещает акцент в сторону «заработать на музыке» — это изрядно попахивает.
Однако, прорекламировать себя на хабре и не словить минусов — это бесценно ;)
https://github.com/google/xi-editor
Про контексты в расширениях — это довольно значимый пунктик, в частности, доступ к chrome API из injected-скриптов, доступ к js-окружению на странице, контекст применения HMR-обновлений (т.к. это не обычная страница, пришлось немного подпилить механизм hot-апдейтов) и т.д. нюансы.
Если будут желающие поучаствовать словом и делом — буду рад.
«Накладные расходы» на поддержку нормальной модульности минимальны, призывы «только конкатенация» непонятны.
Хоть бы написали, что из себя представлял проект.
Цитата с github: