Возможно более простым и надежным было бы написать свое xul приложение и запускать его через firefox для того что бы сохранились все его настройки xulrunner. Приложение вышло бы на 50 строк js кода, за то не пришлось бы делать снимок из фреймбуффера.
В xulrunner доступен метод drawWindow
Фактически это должно полностью решить проблемы битых скриншотов, и одновременно дать полный доступ к DOM и JS показываемого сайта. Можно подписыватся на любые события, модифицировать сайт — например вырезать\затенять рекламу и тд.
Мне кажется вы путаете теплое с мягким и немного недоговариваете.
С точки зрения бизнеса, работник это инструмент. Задача бизнеса и предпринимателя в частности, это найти схему при которой те инструменты которые у него есть, способны решать задачи за которые готовы платить люди, больше чем цена инструментов. Фактически это продажа гарантии этим людям что работа действительно будет заделана.
Так что если бы работники попадали вам по распределению то тогда да — Ваши претензии были бы обоснованы. Но Вы выбираете их сами. Фактически если позволить себе немного не полит корректную терминологию, то Вы покупаете инструмент на рынке труда, за ту сумму за которую договоритесь с продавцом(человеком). А инструмент это его знания и умения. Вы не покупаете результат, у только умения которые Вы можете встроить в свою бизнес идею а продавец нет.
Заставить Вас купить что то никто не может. Собеседование это способ оценить соответствие заявленных умений реальности. Если Вы из неправильно определили — в Вашем бизнес плане проблема: отсутствие умений(инструмента) оценивать квалификацию, и это можно решить купив их на рынке :-).
Если смотреть с этой точки зрения то получается все очень просто — Вы покупаете умения и пытаетесь их применить с целью получения прибыли после продажи результата труда за одну сумму и оплаты затрат за другую. Все риски исключительно на Вас. Но и цена «чистая» только оплата инструментов которые реально производят ценность.
Оплата за результат — это покупка страховки, и она не может быть дешевле(в краткосрочной перспективе), то есть Вы платите за инструмент, за риск его выхода из строя, за его подбор и за его мотивацию.
Если Вы готовы пойти на риск (не купить страховку) то вы нанимаете сотрудника, но тогда перерасход Ваша потеря, и экономия Ваша прибыль. С которой работник не получает ничего.
Так что это просто разные модели бизнеса с разными дивидендами, и ТК тут не причем.
Если упрощенно смотрите на это как будто бы все таблицы вдруг стали view с условием которое берется из policy function. Например если в запросе используется view, который внутри делает агрегацию, то все произойдет как и задумано — сумма\среднее\etc агрегации построится по тем рядкам которые вам доступны.
Это PL/SQL блок, это значит что в нем можно делать все что угодно.
Стандартная практика для Oracle, это вызвать setContext в самом начале обработки запроса в веб приложении, и в запросах брать значения из контекста. В контексте может быть все что угодно, это просто таблица ключ\значение. У нас например устанавливается id пользователя, язык, регион.
Некоторое время назад перешел на unittest++
Он очень хороше подходит для случаев когда дополнительный функционал не нужен а хочется простоты.
TEST(UnitTestName) {
//Any code
}
это все что нужно для написания теста. Это позволяет очень быстро их строчить, что у меня очень положительно сказывается на их количестве и вообще использованиями — быстрее написать тест чем запустить.
Также очень хороший вывод результатов и ошибок.
Советую посмотреть тем кто хочеть простоты и не нуждается в больших возможностях.
Что еще приятно в линукс системах подключается просто добавление библиотеки.
А авто тестирование такой интерфейс позволяет проводить?
Если я правельно понял, то весь интерфейс это просто картинка — без возможности выделить конкретные елементы?
В далеком 6 класе тоже взломал школьную систему. Написал эмулятор логина на QBasic, «социальным инженирингом» («хитрым способом») заставил в нем авторизироватся учителя. Наказали настолько сильно что просто страшно вспомнить — отстранили от подготовки к олимпиаде… Кроме злобы на всех ничего не дало. Наказание здесь безсмысленно. Но обяснить можно было что-то. Хо тя ничего не стирал, и не удалял — понимал что это доставит работы другим.
Сидя как-то раз в барчике со своим другом проводили подобные эксперименты. Чтобы сильно сократить количество строк можете пройтись так:
strings /proc/kcore | grep -A 50 -B 50 {username} | sort -u | uniq -u > /tmp/kdump.uniq
Странно но пароль всегда находился в пределах +-50 строк от имени пользователя
1) и как думаеш что быстрее( а. написать, б. скорость работы)
2) ну знетели, итак цыфры отличаются на 1000 голосов почти. Если бы таким способом получались совсем разные цифры то согласитесь это бы было уже совсем черезчур
В xulrunner доступен метод drawWindow
Фактически это должно полностью решить проблемы битых скриншотов, и одновременно дать полный доступ к DOM и JS показываемого сайта. Можно подписыватся на любые события, модифицировать сайт — например вырезать\затенять рекламу и тд.
С точки зрения бизнеса, работник это инструмент. Задача бизнеса и предпринимателя в частности, это найти схему при которой те инструменты которые у него есть, способны решать задачи за которые готовы платить люди, больше чем цена инструментов. Фактически это продажа гарантии этим людям что работа действительно будет заделана.
Так что если бы работники попадали вам по распределению то тогда да — Ваши претензии были бы обоснованы. Но Вы выбираете их сами. Фактически если позволить себе немного не полит корректную терминологию, то Вы покупаете инструмент на рынке труда, за ту сумму за которую договоритесь с продавцом(человеком). А инструмент это его знания и умения. Вы не покупаете результат, у только умения которые Вы можете встроить в свою бизнес идею а продавец нет.
Заставить Вас купить что то никто не может. Собеседование это способ оценить соответствие заявленных умений реальности. Если Вы из неправильно определили — в Вашем бизнес плане проблема: отсутствие умений(инструмента) оценивать квалификацию, и это можно решить купив их на рынке :-).
Если смотреть с этой точки зрения то получается все очень просто — Вы покупаете умения и пытаетесь их применить с целью получения прибыли после продажи результата труда за одну сумму и оплаты затрат за другую. Все риски исключительно на Вас. Но и цена «чистая» только оплата инструментов которые реально производят ценность.
Оплата за результат — это покупка страховки, и она не может быть дешевле(в краткосрочной перспективе), то есть Вы платите за инструмент, за риск его выхода из строя, за его подбор и за его мотивацию.
Если Вы готовы пойти на риск (не купить страховку) то вы нанимаете сотрудника, но тогда перерасход Ваша потеря, и экономия Ваша прибыль. С которой работник не получает ничего.
Так что это просто разные модели бизнеса с разными дивидендами, и ТК тут не причем.
www.aosabook.org/en/bdb.html — можете почитать может может подкинет идей.
www.symantec.com/connect/articles/oracle-row-level-security-part-1
Ответ на твой вопрос в секции «So how does it work — a brief example»
Если упрощенно смотрите на это как будто бы все таблицы вдруг стали view с условием которое берется из policy function. Например если в запросе используется view, который внутри делает агрегацию, то все произойдет как и задумано — сумма\среднее\etc агрегации построится по тем рядкам которые вам доступны.
Стандартная практика для Oracle, это вызвать setContext в самом начале обработки запроса в веб приложении, и в запросах брать значения из контекста. В контексте может быть все что угодно, это просто таблица ключ\значение. У нас например устанавливается id пользователя, язык, регион.
Он очень хороше подходит для случаев когда дополнительный функционал не нужен а хочется простоты.
TEST(UnitTestName) {
//Any code
}
это все что нужно для написания теста. Это позволяет очень быстро их строчить, что у меня очень положительно сказывается на их количестве и вообще использованиями — быстрее написать тест чем запустить.
Также очень хороший вывод результатов и ошибок.
для проверок доступны простые макросы
CHECK(condition), condition == true
CHECK_EQUAL(expected, actual) — любые типы данных
CHECK_CLOSE(expected, actual, tolerance) — для проверки double/float
CHECK_ARRAY_EQUAL(expected, actual, count)
CHECK_ARRAY_CLOSE(expected, actual, count, tolerance)
CHECK_THROW(expression, ExpectedExceptionType)
Советую посмотреть тем кто хочеть простоты и не нуждается в больших возможностях.
Что еще приятно в линукс системах подключается просто добавление библиотеки.
Если я правельно понял, то весь интерфейс это просто картинка — без возможности выделить конкретные елементы?
strings /proc/kcore | grep -A 50 -B 50 {username} | sort -u | uniq -u > /tmp/kdump.uniq
Странно но пароль всегда находился в пределах +-50 строк от имени пользователя
2) ну знетели, итак цыфры отличаются на 1000 голосов почти. Если бы таким способом получались совсем разные цифры то согласитесь это бы было уже совсем черезчур