Спасибо за программу, давно пользуюсь, очень облегчает жизнь. Есть два пожелания:
1. Скриншотить то состояние экрана, которое имеется в момент нажатия хоткея, а не в момент завершения выделения квадратика. Поясню. Имеется на странице что-то, что изменяется со временем, пусть будет какая анимация. В нунжный мне момент жму cmd+alt+5, и ожидаю, что затем всё замрёт(сделается скришот и отобразится на экране поверх всего остального), и я уже в сделанном скриншоте выделю нужную мне область. А на деле получается, что реальный скриншот будет сделан только в момент завершения выделения прямоугольника мышкой.
2. В окошке редактора monosnap сделать возможность переключаться между предуще сделанными скриншотами.
Соглашусь с вышесказанным.
Начинал в студенчестве с C++, затем работал на пхп, после чего писал на C#, а теперь использую на руби и кофескрипт.
Побывал фактически с обеих сторон баррикад (хотя есть ещё мечта с эрлангом поработать). Так вот, слова о том, что компилятор и статическая типизации сильно помогают кому-то от ошибок, вызывают лишь недоумение. Если у вас компилируется программа, это означает лишь то, что вы научились грамотно писать на синтаксисе данного языка. И всё, больше это ничего не гарантирует. А умение грамотно писать автоматом приходит где-то через месяц-два работы на новом для вас языке, после чего этап компиляции приносит лишь весьма длинную и совершенно ненужную паузу перед запуском проекта или тестов. Да, тестов, т.к. — это единственное мне известное, что может хотя бы кое-как гарантировать, что ваш промышленный код работает как задумано. Если вы конечно не работаете на НАСА и не пишете на чёрт-знает-чем-с-математическим-доказательством-корректности-кода, производя в месяц несколько сотен строк кода.
А если вы на том же javascript пишете что-то сложнее нескольких обработчиков на jQuery, то тут могут и должны писаться тесты, для которых уже существуют на данный момент технологии(ещё пару лет назад с этим было гораздо хуже), позволяющие запускать js тесты как из консоли, так и на билд-сервере.
> Открытие «электронных кошельков» на Интернет-сайтах для расчетов с поставщиками товаров и услуг.
Вот это имхо очень правильно.
Любят некоторые «магазины» после отмены платежа за товар деньги возвращать не туда, откуда средства были получены, а на «личный счёт пользователя» на своём сайте.
Почему-то все сразу вспоминают говносайты с зачастую ворованным контентом (зачем на них вообще заходить-то?). А о том, что при этом в не меньшей степени страдают и нормальные сайты без назойливой рекламы, предпочитают не думать.
Все, кто ратуют за истребление рекламы, наверное хотят читать исключительно википедию, гос сайты, да небольшие ресурсы с посещаемостью 100 человек в день? Практически любой крупный сайт, который вы посещаете существует исключительно за счёт рекламы, в том числе и хабрахабр. Платная подписка — вещь достаточно утопичная, осуществимая в данный момент, наверное, лишь для крупнейших информационных ресурсов.
Или «хороший сайт» в размещении рекламы не нуждается? Ну да. На первых порах. Потом с каждой дополнительной тысячей посетителей в день и пропорциональным ростом счетов за хостинг энтузиазм владельцев начнёт стремительно уменьшаться.
И в итоге по достижению определённого процента посетителей с адблоком сайты начнут ставить залушку — «режете рекламу? тогда до свидания. в интернете много других сайтов, идите куда-нибудь ещё»
Мне кажется только это не очень действенная мера. Ну посадят его за решётку, ну и что, кому до принимающих решения в гугле будет до этого дело? Посидит, пройдут выборы, и отпустят.
Выписать многомиллионный штраф или временно закрыть доступ к сервисам, лишив аудитории и прибыли от неё, было бы гораздо более эффективно. Для забывших — компании имеет своё представительство в стране, зарабатывает там деньги, и обязана подчиняться местным законам, не важно какие они есть.
Сам ни в коей мере к «писательству» отношения не имею, но уже который год с удовольствием слушаю подкаст www.writingexcuses.com, где несколько писателей (Брендон Сандерсон, Мэри Робинетт Коваль, Говард Тайлер, Dan Wells) обсуждают разные связанные с их работой и увлеченим вещи: как они пишут, о чём пишут, как подходят к разным проблемам, какие жанры предпочитают и почему, и т.д. Иногда у них бывают гости из англоязычных писателей, порой весьма известные личности.
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
Вы определитесь, о чём хотите рассказать.
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
Если кратко, то ваш контроллер делает:
1) вводит свой менеджер событий, причём не следуя конвенциям и бекбона, и джейквери, и многих других современных библиотек, — addListeners и fireEvent вместо лаконичных on и trigger.
2) завуалированно и в особо извращённой форме хранит глобальные объекты, доступные в единственном экземпляре
От подобного делегирования меньшей связанности не будет, наоборот оно лишь поощряет использования глобальных объектов.
3) создаёт объекты через строковые литералы для геттеров из пункта 2. и ещё, как я понимаю, чтобы передать параметры в конструктор, придётся создавалку переопределять.
С пунктом 1 отлично справляется view, который будет сверху всех остальных, который будет содержать в себе прочие view. А пункты 2 и 3 вовсе вредны.
Про контроллеры бекбона выше верно написали, их в прошлом выпилили потому, что всё, кроме взаимодействия с урлами, дублирует логику Backbone.View
Во вторых, мы можем определить базовые части, не дожидаясь, пока они будут доступны. Это позволит загружать файлы в произвольном порядке. Парсинг имён в ссылки произойдёт только после того, как все скрипты будут загружены.
Да, если подключить сначала view, а потом модели или коллекции перед моделями, то работать ничего не будет. Но зачем загружать файлы в произвольном порядке, если есть над этим контроль? Имхо этот вовсе не проблема.
Вот чего в действительности не хватает бекбону, это:
1) более мощного роутера, чтобы можно было задавать опциональные параметры урлам и накладывать ограничения на содержимое параметров.
2) из коробки механизма отношений сежду моделями и коллекциями, подобно тому как в backbone.relational плагине сделано(только там реализация не самая лучшая).
3) из коробки механизма рендеринга партиалов
Примерно тоже самое, хотя как там работает ребейз не знаю.
Вот про мерж непонятно. Если он у вас по часу у вас каждый день занимает, то итоговый мерж потребует времени за все предыдущие дни разом, плюс большой оверхед из-за того, что массу изменений за долгий период скопом мержить труднее, чем по чуть-чуть.
Или меркуриал не запоминает как конфликты при ребейзе разрешаются и каждый раз заново? С гитом при последующих ребейзах конфликты, возникшие при предыдущих, больше не появляются.
«Подливание» произвольных коммитов в бранч тоже есть — cherry pick.
При этом при возникновении конфликта вы будете разруливать не финальное состояние ваших файлов, когда хз что и как было изменено, а состояние файлов лишь на момент того вашего коммита, при котором и произошёл конфликт.
Тут немного поясню. Когда двумя коммитами A и B в одном и том же файле вы сделали конфликтующие с «транком» изменения, то сначала при ребейзе у вас будет возможность поправить конфликт из коммита A(процесс ребейза остановится), а затем продолжить ребейз, после чего он остановится уже на конфликте из коммита B.
1. Скриншотить то состояние экрана, которое имеется в момент нажатия хоткея, а не в момент завершения выделения квадратика. Поясню. Имеется на странице что-то, что изменяется со временем, пусть будет какая анимация. В нунжный мне момент жму cmd+alt+5, и ожидаю, что затем всё замрёт(сделается скришот и отобразится на экране поверх всего остального), и я уже в сделанном скриншоте выделю нужную мне область. А на деле получается, что реальный скриншот будет сделан только в момент завершения выделения прямоугольника мышкой.
2. В окошке редактора monosnap сделать возможность переключаться между предуще сделанными скриншотами.
Начинал в студенчестве с C++, затем работал на пхп, после чего писал на C#, а теперь использую на руби и кофескрипт.
Побывал фактически с обеих сторон баррикад (хотя есть ещё мечта с эрлангом поработать). Так вот, слова о том, что компилятор и статическая типизации сильно помогают кому-то от ошибок, вызывают лишь недоумение. Если у вас компилируется программа, это означает лишь то, что вы научились грамотно писать на синтаксисе данного языка. И всё, больше это ничего не гарантирует. А умение грамотно писать автоматом приходит где-то через месяц-два работы на новом для вас языке, после чего этап компиляции приносит лишь весьма длинную и совершенно ненужную паузу перед запуском проекта или тестов. Да, тестов, т.к. — это единственное мне известное, что может хотя бы кое-как гарантировать, что ваш промышленный код работает как задумано. Если вы конечно не работаете на НАСА и не пишете на чёрт-знает-чем-с-математическим-доказательством-корректности-кода, производя в месяц несколько сотен строк кода.
А если вы на том же javascript пишете что-то сложнее нескольких обработчиков на jQuery, то тут могут и должны писаться тесты, для которых уже существуют на данный момент технологии(ещё пару лет назад с этим было гораздо хуже), позволяющие запускать js тесты как из консоли, так и на билд-сервере.
Вот это имхо очень правильно.
Любят некоторые «магазины» после отмены платежа за товар деньги возвращать не туда, откуда средства были получены, а на «личный счёт пользователя» на своём сайте.
Тоесть делается либо так
либо так
| title some text
Проект опенсорсный
Или «хороший сайт» в размещении рекламы не нуждается? Ну да. На первых порах. Потом с каждой дополнительной тысячей посетителей в день и пропорциональным ростом счетов за хостинг энтузиазм владельцев начнёт стремительно уменьшаться.
И в итоге по достижению определённого процента посетителей с адблоком сайты начнут ставить залушку — «режете рекламу? тогда до свидания. в интернете много других сайтов, идите куда-нибудь ещё»
Выписать многомиллионный штраф или временно закрыть доступ к сервисам, лишив аудитории и прибыли от неё, было бы гораздо более эффективно. Для забывших — компании имеет своё представительство в стране, зарабатывает там деньги, и обязана подчиняться местным законам, не важно какие они есть.
Обёртка микроскопических js библиотек(или плагинов джейквери) гемами не привносит никаких удобств, наоборот даёт лишь противоположный эффект. А всё потому, что это не оригинальные библиотеки, как с гемами руби кода, а обёртки над другими репозиториями.
Если вы хотите последнюю версию и прямо сейчас, то гемы не всегда помогают, версия может быть быть не совсем свежей, меинтейнер может обновить лишь завтра, или послезавтра, или вовсе через неделю. А вы хотите здесь и сейчас. Форк, пулреквест… да… проверить версию, подправить, если надо… мы говорим об экономии времени по сравнению со «скачать с гитхаба»?
А если вы хотите не последнюю версию, а какую-то определённую старую, то гемы и вовсе бесполезны, зачастую версиям оригинальных библиотек они не следуют.
Второй косяк с гемами в том, что порой, особенно в долгом проекте, нужно посмотреть, какие плагины и библиотки используются, какие из них уже не нужны, и какие стоит выпилить вовсе. С гемом смотреть теперь надо не в одном месте, а в двух.
О том, как подключить гем к рельсам? Полезность статьи зашкаливает.
О «возможно» интересной js библиотеке? Тогда при чём тут рельсы?
1) вводит свой менеджер событий, причём не следуя конвенциям и бекбона, и джейквери, и многих других современных библиотек, — addListeners и fireEvent вместо лаконичных on и trigger.
2) завуалированно и в особо извращённой форме хранит глобальные объекты, доступные в единственном экземпляре
От подобного делегирования меньшей связанности не будет, наоборот оно лишь поощряет использования глобальных объектов.
3) создаёт объекты через строковые литералы для геттеров из пункта 2. и ещё, как я понимаю, чтобы передать параметры в конструктор, придётся создавалку переопределять.
С пунктом 1 отлично справляется view, который будет сверху всех остальных, который будет содержать в себе прочие view. А пункты 2 и 3 вовсе вредны.
Про контроллеры бекбона выше верно написали, их в прошлом выпилили потому, что всё, кроме взаимодействия с урлами, дублирует логику Backbone.View
Да, если подключить сначала view, а потом модели или коллекции перед моделями, то работать ничего не будет. Но зачем загружать файлы в произвольном порядке, если есть над этим контроль? Имхо этот вовсе не проблема.
Вот чего в действительности не хватает бекбону, это:
1) более мощного роутера, чтобы можно было задавать опциональные параметры урлам и накладывать ограничения на содержимое параметров.
2) из коробки механизма отношений сежду моделями и коллекциями, подобно тому как в backbone.relational плагине сделано(только там реализация не самая лучшая).
3) из коробки механизма рендеринга партиалов
Вот про мерж непонятно. Если он у вас по часу у вас каждый день занимает, то итоговый мерж потребует времени за все предыдущие дни разом, плюс большой оверхед из-за того, что массу изменений за долгий период скопом мержить труднее, чем по чуть-чуть.
Или меркуриал не запоминает как конфликты при ребейзе разрешаются и каждый раз заново? С гитом при последующих ребейзах конфликты, возникшие при предыдущих, больше не появляются.
«Подливание» произвольных коммитов в бранч тоже есть — cherry pick.
Тут немного поясню. Когда двумя коммитами A и B в одном и том же файле вы сделали конфликтующие с «транком» изменения, то сначала при ребейзе у вас будет возможность поправить конфликт из коммита A(процесс ребейза остановится), а затем продолжить ребейз, после чего он остановится уже на конфликте из коммита B.