А как можно узнать, защищен ли алгоритм или является ли это коммерческой тайной без декомпиляции?
Мне кажется, что если проект не с открытым исходным кодом, значит авторы считают этот код закрытым, и будут очень против декомпиляции.
Я конечно не против чтоб кто-то проверял проги в маркетах, но немного смущает моральный аспект и то, как явно идет упоминание «бывшего сотрудника Майкрософт» — типа вроде бы как бы и упомянута компания, но и как бы и не при чем.
Забавно… не нарушил ли какие-то законы «бывший сотрудник» когда декомпилировал? Имел ли он право это делать?
В случае с аппстором то все ясно — там вроде девелоперы обязаны давать сорсы эплу, а вот как с этим обстоит в МС маркете?
Обычный софт вроде бы даже бесплатный, если он не опенсорсный, то обычно в лицензии написано что вы имеете право свободно использовать но не декомпилировать/изменять код.
У меня нет блокировщиков но на данный момент что под моим аккаунтом, что под другим броузеров без привязки к аккаунту — пусто. Никаких рекламных ссылок.
Ребята специально зарыли полезные модули среди модулей, которые подходят под «поржал и забыл»?
У меня в папке ~/temp/testingnode/ находятся много подобных «модулей»… смысл их «опенсорсить»? Некоторые ну уж совсем мусорные…
Я понимаю юмор, но зачем все-таки тратить чужое время — ведь там есть и полезные модули, по этому переходя к каждому следующему описанию гадаешь стеб это или что-то нормальное.
уф, хорошо что сказали! А то я уже начал беспокоится о своем эммоциональном состоянии и еще раз пересматривать клип ищя какой-то смысл, пытаясь разгадать НЛП-шные загадки :)
Отличная эллюстрация того, что исскуству не всегда нужно иметь смысловое содержание, а достаточно просто визуального эффекта :)
Ну… просто надо внимательно читать что расширение/приложение требует — для «фонового» запуска нужно отдельное разрешение.
Самое интересное, что для запуска NaCL внутри аппа/екстеншена нужно расширение «native_client», которое пока даже не документированно и скорее как экспеременатльное, так что даже если потребует, то, думаю, очень заметно будет :)
Чуть выше я примерно рассказал почему так — в Хроме есть два понятия «фоноввости» это "фоновые страницы" — одни те, которые запущенны всегда, когда вы броузете (думаю почти все расширения имеют такую страницу), а есть "фоновое расширение" — которые потребовали от вас разрешения на запуск тогда, когда ни одного окна брозуера не открыто, оно конечно же содержит в себе «фоновую страницу».
Как-то так… немного запутанно но в принципе понятно :)
m1el, как разработчик расширения скажу, что информация про background.html не совсем верна — это страница является «сендбоксом» для данных самого расширения вне зависимо от текущей вкладки.
Но это не является гарантией, что ваше расширение будет запущенно в «фоновом режиме» — т.е. еще до того как пользователь запустит Хром или после того как закроет все окна.
Для того, чтоб расширение было «фоновым», необходимо добавить «background» в manifest.json.
Более детальная инфомарция доступна тут. Вот выдержка:
When any installed hosted app, packaged app, or extension has «background» permission, Chrome runs (invisibly) as soon as the user logs into their computer—before the user launches Chrome. The «background» permission also makes Chrome continue running (even after its last window is closed) until the user explicitly quits Chrome.
You typically use the «background» permission with a background page or (for hosted apps) a background window.
Конечно же без background page смысла требовать пермишенна background нет, но само наличие background page не говорит о том, что расширение будет работать на том «фоне», о говорится в статье.
А отвечая на вопрос VolCh я так сходу даже не могу сказать, как определить какие расширения уже получили от вас разрешение на запус «на фоне» (т.е. без основного окна Хрома), разве что при инсталяции оно спросит разрешения, и при апдейте если расширение требует дополнительных разрешений, оно будет временно отключенно пока пользователь не подтвердит новые разрешения.
ну эту задачку на чистом CSS можно было бы сделать, канвас использовать только чтоб нарисовать картинки.
А использовать тайлы вместо спрайтов (как внешних картинков) имеет смысл если резолюшен зарание не известен. SVG для анимации совсем плохо подходит — тормозит сильно. А вот нарисовать когда мы уже знаем размеры окна на канвасе и использовать — это можно уже.
Не думаю, что есть смысл смешивать сам сайт и суть проекта — на сайте там, где есть инденты и граватарки именна переменных не сокращены. А в гистах по 140 байт нет индентов и граватарок.
Тут важна сама идея, гисты и описание то, как и чем достигнуты 140 байт, чем то, как сделан сайт.
С парсинтом ваабще отдельная история — я сравнивал по скорости разные варианты, это "+", "|0", "~~" и т.д. и очень интересные результаты выходили: см. например jsperf.com/number-vs-plus-vs-toint-vs-tofloat/10
как оказалось в Chrome parseFloat почти в два раза быстрее pareInt :)
Jed, автор «фремворка» (fab) недавно устраивал конкурс — «фреймворк в твите» 140byt.es/, и к нему давал набор рекомендаций о том, как можно минимизировать руками код.
Не определения, а… черт, замыкание несколькоих локальных переменных таким образом, чтоб они были доступны в функции, которая может быть «отдана» за пределы видимости замыкаемых переменных.
Простейший пример замыкания:
function a() {
var x = 5;
return function() { return x; }
}
тут происходит замыкание переменной «х» внутрь возвращаемой функции.
Это никак не относится к hoisting-гу, который определяет видимость деклараций переменных и названий функций.
Т.е. если «замыкание» действительно делает что-то закрытое доступным, когда мы уже ушли из области видимости, то «поднятие» просто определяет что доступно, что нет, не делая что-то.
К примеру, «замыкание» на С# реализованно через создание анонимных классов, члены которого содержат «замкнутные» переменные, и который создается тогда, когда мы используем эти переменные и экземпляр которого доступен в «замкнутых» функциях (делегатах).
В то же время, если бы в С# было бы «поднятие», то оно было бы реализованно строго на уровне синтаксического анализатора, не создавая никаких новых сущностей (как в «замыкании»).
Мне кажется тут действительно серьезное отличие. И ИМХО лучше бы не было «поднятия» — оно только конфузит чтение кода.
небольшое замечание — в тегах Google Developers Day (буква «s» лишняя)
И еще стоит добавить автора(ов) фото и видео — мне было очень приятно посмотреть на себя со стороны, и, думаю, это заслушивает отдельных «кредитов» :)
Но Циклуму большое спасибо за хороший хостинг мероприятния. Стоит добавить, что киевский хакатон был саммый массовый по количеству людей (и, если не ошибаюсь, проектов).
До сих пор поражаюсь, как за два дня мы успели с нуля разобратся в том, что такое екстеншены, как их писать, написать сам екстеншен и серверную часть для нее. Хоть и не полностью закончили, но работающий proof-of-concept вышел неплохой.
Мне кажется, что если проект не с открытым исходным кодом, значит авторы считают этот код закрытым, и будут очень против декомпиляции.
Я конечно не против чтоб кто-то проверял проги в маркетах, но немного смущает моральный аспект и то, как явно идет упоминание «бывшего сотрудника Майкрософт» — типа вроде бы как бы и упомянута компания, но и как бы и не при чем.
В случае с аппстором то все ясно — там вроде девелоперы обязаны давать сорсы эплу, а вот как с этим обстоит в МС маркете?
Обычный софт вроде бы даже бесплатный, если он не опенсорсный, то обычно в лицензии написано что вы имеете право свободно использовать но не декомпилировать/изменять код.
У меня в папке ~/temp/testingnode/ находятся много подобных «модулей»… смысл их «опенсорсить»? Некоторые ну уж совсем мусорные…
Я понимаю юмор, но зачем все-таки тратить чужое время — ведь там есть и полезные модули, по этому переходя к каждому следующему описанию гадаешь стеб это или что-то нормальное.
В общем… неоднозначно.
Отличная эллюстрация того, что исскуству не всегда нужно иметь смысловое содержание, а достаточно просто визуального эффекта :)
Самое интересное, что для запуска NaCL внутри аппа/екстеншена нужно расширение «native_client», которое пока даже не документированно и скорее как экспеременатльное, так что даже если потребует, то, думаю, очень заметно будет :)
Как-то так… немного запутанно но в принципе понятно :)
Но это не является гарантией, что ваше расширение будет запущенно в «фоновом режиме» — т.е. еще до того как пользователь запустит Хром или после того как закроет все окна.
Для того, чтоб расширение было «фоновым», необходимо добавить «background» в manifest.json.
Более детальная инфомарция доступна тут. Вот выдержка:
Конечно же без background page смысла требовать пермишенна background нет, но само наличие background page не говорит о том, что расширение будет работать на том «фоне», о говорится в статье.
А отвечая на вопрос VolCh я так сходу даже не могу сказать, как определить какие расширения уже получили от вас разрешение на запус «на фоне» (т.е. без основного окна Хрома), разве что при инсталяции оно спросит разрешения, и при апдейте если расширение требует дополнительных разрешений, оно будет временно отключенно пока пользователь не подтвердит новые разрешения.
А использовать тайлы вместо спрайтов (как внешних картинков) имеет смысл если резолюшен зарание не известен. SVG для анимации совсем плохо подходит — тормозит сильно. А вот нарисовать когда мы уже знаем размеры окна на канвасе и использовать — это можно уже.
Тут важна сама идея, гисты и описание то, как и чем достигнуты 140 байт, чем то, как сделан сайт.
С парсинтом ваабще отдельная история — я сравнивал по скорости разные варианты, это "+", "|0", "~~" и т.д. и очень интересные результаты выходили: см. например
jsperf.com/number-vs-plus-vs-toint-vs-tofloat/10
как оказалось в Chrome parseFloat почти в два раза быстрее pareInt :)
Очень рекомендую прочитать внимательно каждый пунктик: https://github.com/jed/140bytes/wiki/Byte-saving-techniques
Я уверен, найдете как еще ужать код :)
Ну и там есть просто охренительные твиты, несколько из которых я уже использую активно :)
Простейший пример замыкания:
тут происходит замыкание переменной «х» внутрь возвращаемой функции.
Это никак не относится к hoisting-гу, который определяет видимость деклараций переменных и названий функций.
Т.е. если «замыкание» действительно делает что-то закрытое доступным, когда мы уже ушли из области видимости, то «поднятие» просто определяет что доступно, что нет, не делая что-то.
К примеру, «замыкание» на С# реализованно через создание анонимных классов, члены которого содержат «замкнутные» переменные, и который создается тогда, когда мы используем эти переменные и экземпляр которого доступен в «замкнутых» функциях (делегатах).
В то же время, если бы в С# было бы «поднятие», то оно было бы реализованно строго на уровне синтаксического анализатора, не создавая никаких новых сущностей (как в «замыкании»).
Мне кажется тут действительно серьезное отличие. И ИМХО лучше бы не было «поднятия» — оно только конфузит чтение кода.
sDay (буква «s» лишняя)И еще стоит добавить автора(ов) фото и видео — мне было очень приятно посмотреть на себя со стороны, и, думаю, это заслушивает отдельных «кредитов» :)
Но Циклуму большое спасибо за хороший хостинг мероприятния. Стоит добавить, что киевский хакатон был саммый массовый по количеству людей (и, если не ошибаюсь, проектов).
До сих пор поражаюсь, как за два дня мы успели с нуля разобратся в том, что такое екстеншены, как их писать, написать сам екстеншен и серверную часть для нее. Хоть и не полностью закончили, но работающий proof-of-concept вышел неплохой.