люди дышат, кашляют, разговаривают, шутят, телефоны звонят, техника шумит, блоки питания гудят и всё это сливается в непрекращающийся гул. Подобное помещение — АД для разработки.
А начать следовало бы с уважения к коллегам: так и вижу картину как иванушка-дурачёк«начинающий productowner» прочтёт этот опус и начнёт что-то такое «выжимать максимум» и «воспитывать» тех.дира и всех подряд «толкать в зад». Только сотрудничество и только уважение.
Повышение доступности стоит денег. Зачастую немалых.Чем ближе мы приближаемся к 1 тем дороже каждый шаг. Если у компании есть ресурсы пойти по этому пути и есть потребность — так надо разработать план, выделить ресурсы и реализовывать его. Ну а если нет — то так и не надо заниматься ИБД.
Ещё один «плюс» который экономит время (особенно если это например Java-разработка) — «отлаживаться» быстрей в окружении автотеста (неважно насколько он «большой», но чем ближе он к модульным — тем быстрей): не надо запускать всю систему, не надо вручную проходить все шаги работы с системой чтобы обеспечить вызов нужного метода в нужном контексте.
«самолюбие остается нетронутым» — в этом всё дело. Если линейные руководители (тим-лиды, пмы и т.п.) уклоняются от работы с людьми, то со временем вместо «мы в одной лодке, делаем общее дело и сейчас, рассмотрев альтернативы, хотим выбрать, по крайней мере, хорошее решение» в обсуждения начинают управляться идеей «все идиоты, а я д'артаньян». В такой ситуации вместо выбора лучшего решения люди начинают тянуть одеяло каждый в свою сторону: ведь каждый хочет быть д'артаньяном и не хочет быть идиотом. Обычно это сопровождается высказыванием утверждений в категоричной форме + «уколы» вроде «это очевидно каждому», «это понятно даже студенту», + обращение к чужим авторитетам.
Помимо прочего такое неконструктивное поведение делает людей заложниками высказанных в категоричной форме тезисов: ведь когда ты назвал всех идиотами — признать свою неправоту становится ещё трудней)
Так что надо стремиться чтобы в обсуждениях ничьё «самолюбие» не фигурировало, всячески пресекать бескомпромиссные утверждения и уколы адресованные коллегам.
Скажите, вы строите модель поведения пользователей на основании анализа access-логов предшествующих атаке? Точней даже так — насколько важно их наличие для успешной борьбы с «умными» ботами? Просто если пытаться строить модель после начала атаки — не очевидно как сделать так чтобы поведение преобладающей армии ботов не стало «нормой».
Кстати, возможно ли получить аксеслоги? «до» и «вовремя» атаки?
Как бы «это» не называлась — цель в головах менеджмента всегда одна — узнать сколько времени займёт работа. «сложность» в вакууме редко кого интересует — чаще по прошествии нескольких спринтов сложность делят на человеко-часы и в дальнейшем сложность «становится» синонимом «времени».
«Практически — скорее всего ценность выводов не окупит расходов на анализ.» — в главном мы сходимся)
)
Работа займёт столько времени, сколько она займёт, и «планы» на это повлиять не смогут. Это реальное время распределяется между плановым временем и рисками. Так например я могу «распланировать» создание системы для которой нужно пол-года на месяц. Замечательно — её создание всё-равно займёт пол года, просто 5 дополнительных месяцев будут постепенно материализоваться из «рисков».
Если мои коллеги всячески стремятся завысить сроки с целью побольше времени «почитать хабр» — то наверно это я или плохо разбираюсь в людях и «нанял» людей проекция целей которых на цели проекта мала (стремится к нулю?) или я создал в коллективе атмосферу при которой «чем-меньше тем лучше» или… здесь ещё несколько вариантов но суть одна — я плохой «манагер» и наверно надо менять причину, а не искать способы правильно считать сферических коней в вакууме с привлечением хоть каких-то формул для приданию процессу «весомости».
«а если это изменение не цель, а только средство? ;)»
«это изменение» и есть средство для достижения какой-то цели. А иначе — это ибд. ТакТо.
Вот мне и интересно какая была цель, какие критерии достижения и была ли она достигнута.
В таких «нововведениях» всегда интересно как формулировалась ЦЕЛЬ, каким образом планировали проверить её достижение и собственно была ли она достигнута.
KISS как раз будет со встроенным http-сервером)
Есть html страница в браузере. Её делают те кто в этом хорошо понимает и взаимодействуют привычным образом.
Использование стандартных вещей (status/title) нестандартным образом на KISS (который «никто не отменял») никак не тянет :)
Да что CustomFunction == KISS — тоже ниоткуда не следует
Возможно по ссылкам выше уже описано такое решение: использовать в клиенте встроенный в JRE http-сервер (com.sun.net.httpserver.HttpServer).
Тогда можно будет очевидным образом взаимодействовать со страницы браузера с приложением.
Плюсы такого решения: всё достаточно «очевидно» в том смысле что нет черной магии JS с изменением статуса а потом чтением этого статуса и нет BrowserFunction. Если есть ForntEnd разработчик — он может ваять свои интерфейсы и взаимодействие привычным и понятным способом. Это становится особенно важным когда взаимодействие становится сложней чем просто передать содержимое поля.
У нокии есть неплохой сервис доступный разарботчикам бесплатно (к сожалению сейчас не могу найти ссылку)
Там через java-апплет получаешь удаленный доступ к телефону. Моделей телефоннов там много. Время сеанса работы с телефоном ограничено несколькими десятками минут. На некоторые модели телефонов бывают «очереди». Но в GMT+3 вроде бы нечасто и не большие.
Если может и может это сделать точно — хорошо — лишним не будет (особенно если человек хороший).
Проблема только в том что это умение часто переоценено, и столь же часто отсутсвует у людей которые снисходительным тоном другим рассказывают как это важно.
У кого не хватает обсуждения на работе — могут заглянуть в ЖЖ — часто можно видеть как умные (дейсвтиетльно умные в академичекском смысле люди, которые постоянно изуччают что-то новое в области CS и возможно часть из этого применяют) допускают ошибки при попитке вывенсти оценку простых алгоритмов «из википедии». Что уж говорить об оценках действительно сложных алгоритмов и обычных людях. Да и когда ответ посмотреть не где — то и проверить отсутсвие ошибок непросто. Поэтому в сложных ситуациях (если это действительно нужно и важно) я больше доверяю способу «реализовать и сделать 10 замеров». Оценить таким образом можно даже если у вас в команде только обычные люди и ответ этот часто будет точней чем мыслительный эксперимент.
Кстати пример «из жизни». Кто знаком с Java — там есть HashMap. Внутри он грубо говоря устроен как массив спсиков. В документации заявлено что сложность получения из этой структуры по ключу O(1).
Но это не так если: у объектов int hashCode(){return 1;} или если объектов в это коллекции больше чем 2^32 — тогда сложность операции становится O(N).
Ну и вот — попросили вы человека оценить эту сложность. Он «вывел» вам O(1). Ответ не правильный — но значит ли это что специалист плохой? Наверно нет. В общем случае — неизвестно) Поэтому важность этого навыка кажется мне часто переоцененной.
Кажется преждевременным возводить конкретную реализацию в конкретной железке в ранг «основ», которые, якобы, все должны неприменно знать.
«Многозатачность» можно реализовать в любом микропроцессоре в котором есть таймер или внешнии линии прерываний (к которым опять же подключить уже внешний таймер). Так что линейка x86 тут совсем не причём и на «основы» не тянет.
Почему 386? многозадачность можно было и в 086 реализовать. Потому что был защищенный режим? Он был и в 286. Почему тогда не они.
А что делать если люди не застали 386? срочно читаь документацию по ним? глупо. Можно быть прекрасным специалистом и не зная как какая то фича реализовывалась в конкретном железе много лет назад.
Так что вопрос скорей бы звучал так «а вы читали документацию к 386 процессору», а цель — асимптотически стермится к «потешить ЧСВ»
люди дышат, кашляют, разговаривают, шутят, телефоны звонят, техника шумит, блоки питания гудят и всё это сливается в непрекращающийся гул. Подобное помещение — АД для разработки.
иванушка-дурачёк«начинающий productowner» прочтёт этот опус и начнёт что-то такое «выжимать максимум» и «воспитывать» тех.дира и всех подряд «толкать в зад». Только сотрудничество и только уважение.Повышение доступности стоит денег. Зачастую немалых.Чем ближе мы приближаемся к 1 тем дороже каждый шаг. Если у компании есть ресурсы пойти по этому пути и есть потребность — так надо разработать план, выделить ресурсы и реализовывать его. Ну а если нет — то так и не надо заниматься ИБД.
Помимо прочего такое неконструктивное поведение делает людей заложниками высказанных в категоричной форме тезисов: ведь когда ты назвал всех идиотами — признать свою неправоту становится ещё трудней)
Так что надо стремиться чтобы в обсуждениях ничьё «самолюбие» не фигурировало, всячески пресекать бескомпромиссные утверждения и уколы адресованные коллегам.
Кстати, возможно ли получить аксеслоги? «до» и «вовремя» атаки?
«Практически — скорее всего ценность выводов не окупит расходов на анализ.» — в главном мы сходимся)
Работа займёт столько времени, сколько она займёт, и «планы» на это повлиять не смогут. Это реальное время распределяется между плановым временем и рисками. Так например я могу «распланировать» создание системы для которой нужно пол-года на месяц. Замечательно — её создание всё-равно займёт пол года, просто 5 дополнительных месяцев будут постепенно материализоваться из «рисков».
Если мои коллеги всячески стремятся завысить сроки с целью побольше времени «почитать хабр» — то наверно это я или плохо разбираюсь в людях и «нанял» людей проекция целей которых на цели проекта мала (стремится к нулю?) или я создал в коллективе атмосферу при которой «чем-меньше тем лучше» или… здесь ещё несколько вариантов но суть одна — я плохой «манагер» и наверно надо менять причину, а не искать способы правильно считать сферических коней в вакууме с привлечением хоть каких-то формул для приданию процессу «весомости».
«это изменение» и есть средство для достижения какой-то цели. А иначе — это ибд. ТакТо.
Вот мне и интересно какая была цель, какие критерии достижения и была ли она достигнута.
Есть html страница в браузере. Её делают те кто в этом хорошо понимает и взаимодействуют привычным образом.
Использование стандартных вещей (status/title) нестандартным образом на KISS (который «никто не отменял») никак не тянет :)
Да что CustomFunction == KISS — тоже ниоткуда не следует
Тогда можно будет очевидным образом взаимодействовать со страницы браузера с приложением.
Плюсы такого решения: всё достаточно «очевидно» в том смысле что нет черной магии JS с изменением статуса а потом чтением этого статуса и нет BrowserFunction. Если есть ForntEnd разработчик — он может ваять свои интерфейсы и взаимодействие привычным и понятным способом. Это становится особенно важным когда взаимодействие становится сложней чем просто передать содержимое поля.
Там через java-апплет получаешь удаленный доступ к телефону. Моделей телефоннов там много. Время сеанса работы с телефоном ограничено несколькими десятками минут. На некоторые модели телефонов бывают «очереди». Но в GMT+3 вроде бы нечасто и не большие.
Проблема только в том что это умение часто переоценено, и столь же часто отсутсвует у людей которые снисходительным тоном другим рассказывают как это важно.
У кого не хватает обсуждения на работе — могут заглянуть в ЖЖ — часто можно видеть как умные (дейсвтиетльно умные в академичекском смысле люди, которые постоянно изуччают что-то новое в области CS и возможно часть из этого применяют) допускают ошибки при попитке вывенсти оценку простых алгоритмов «из википедии». Что уж говорить об оценках действительно сложных алгоритмов и обычных людях. Да и когда ответ посмотреть не где — то и проверить отсутсвие ошибок непросто. Поэтому в сложных ситуациях (если это действительно нужно и важно) я больше доверяю способу «реализовать и сделать 10 замеров». Оценить таким образом можно даже если у вас в команде только обычные люди и ответ этот часто будет точней чем мыслительный эксперимент.
Кстати пример «из жизни». Кто знаком с Java — там есть HashMap. Внутри он грубо говоря устроен как массив спсиков. В документации заявлено что сложность получения из этой структуры по ключу O(1).
Но это не так если: у объектов int hashCode(){return 1;} или если объектов в это коллекции больше чем 2^32 — тогда сложность операции становится O(N).
Ну и вот — попросили вы человека оценить эту сложность. Он «вывел» вам O(1). Ответ не правильный — но значит ли это что специалист плохой? Наверно нет. В общем случае — неизвестно) Поэтому важность этого навыка кажется мне часто переоцененной.
«Многозатачность» можно реализовать в любом микропроцессоре в котором есть таймер или внешнии линии прерываний (к которым опять же подключить уже внешний таймер). Так что линейка x86 тут совсем не причём и на «основы» не тянет.
Почему 386? многозадачность можно было и в 086 реализовать. Потому что был защищенный режим? Он был и в 286. Почему тогда не они.
А что делать если люди не застали 386? срочно читаь документацию по ним? глупо. Можно быть прекрасным специалистом и не зная как какая то фича реализовывалась в конкретном железе много лет назад.
Так что вопрос скорей бы звучал так «а вы читали документацию к 386 процессору», а цель — асимптотически стермится к «потешить ЧСВ»