Спасибо за статью. К сожалению, я не все понял, и хотел уточнить у Вас кое-какие детали.
Каким образом Вы с помощью автоэнкодера решаете аномален ли запрос или нет? Выдаёт ли Ваша модель ответ вида Да/Нет? Расскажите подробнее как выглядит ответ для НЕ аномального запроса? Или это отдельная модель на основе кодера — используете мультатскинг?
Когда декодер выдаёт результат, то длина выходного вектора в общем то может не равняться длине входа. Как Вы потом эти вероятности маппите на исходный входной текст запроса, если размеры не совпали?
Допустим вероятности получены и их количество равно количеству символов входного запроса. Как Вы определяете трешхолд вероятности выше «нормальной», что символ должен быть помечена как аномальный символ? Просто используете 0.5?
Как Вы решали проблему несбалансированных классов примтреннировке? Ведь аномальных запросов намного меньше, чем нормальных и модель, не так ли?
Как выглядела Ваша тренировочная выборка — Вы вручную разметили в анормальных запросах аномальные куски текста?
А я, как житель Торонто, постоянно удивляюсь, когда гуляю по downtown, что же это за сервис такой? :) Очень часто вижу их рекламные баннеры.
Уж не знаю как насчет «рождения нового Facebook», но если ребятам удастся донести канадцам, что этот сервис сделан их соотечественниками, то популярность им обеспечена. Канадцы будут пользоваться этим сервисом чисто из солидарности. У них это тут очень сильно развито.
«В августе 2012 года японский математик Синъити Мотидзуки заявил, что ему удалось доказать эту гипотезу.[3] В октябре того же года Веселин Димитров и Акшай Венкатеш (Akshay Venkatesh) обнаружили ошибку в доказательстве. Мотидзуки признал этот факт, но заявил, что данная ошибка не влияет на основные результаты, а также обещал в ближайшее время опубликовать исправленную версию.»
Я правильно понимаю, что после этого Мотидзуки обновления не выкладывал? Значит можно считать, что проблема то есть, а раз кроме Мотидзуки не может сказать, что она «несущественная», а он сам исправления не выкладывает, то значит доказательство неверное.
По-моему, подобный подход может привести к дубляжу кода запросов. Хорошо, когда запрос — это просто «загрузи все посты». А представьте, если посты могут быть помеченными как «archived» с помощью флага. Пользователь же всегда должен работать с активными постами, и есть редкие случаи, когда ему показываются и архивные посты тоже.
В таком случае надо будет искать все Query к постам и добавлять везде, где надо, .IsNotArchived(), нежели просто поменять методы в репозитории Post. Имхо, это уже дубляж пойдет.
Абсолютно согласен с вашими постулатами по работе с кодом.
Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?
Соблазнившись описанием устройства на официальном сайте, я в свое время учавствовал в предзаказе этой модели е-ридера, чтобы получить скидку, чтобы цена не так кусалась… Но при тестировании устройства в салоне отказался от покупки.
Даже с учетом скидки на 2к, в современном мире планшетов это устройство выглядит жалким. При всех преимуществах е-инка, юзабилити устройства осталось на таком же низком уровне, что и годами раньше. Сенсорный экран добавлен скорее как дань моде, а ведь из него можно было выжать столько класных и удобных фич.
Все кончилось тем, что я отписал в Pocketbook мысли по улучшению этого устройства, но не уверен, что что-то изменится. А на сэкономленные деньги я присматриваю себе планшет-нетбук.
Я не очень понимаю, как именно работает Твиттер, но разве его API не открытый? И, почему, например, аська, которая уже сто лет воюет с «неофициальными» клиентами, но никак их не победит, а вот твиттер легко может это сделать?
Как и большинство общих фраза, фраза «спецификация — бесполезна» неверна. Ведь в момент написания спецификации ты задумываешься, а что вообще будет делать софт, кому это нужно, зачем это нужно и пр.
При этом конечный софт, скорее всего, будет отличаться от исходной спецификации, но не во всем же.
Разработка софта — процесс итеративный, и это нормально, когда ты допиливаешь спецификации и уточняешь требования по ходу выполнения. И я согласен с Линусом — слепое следование спецификации вряд ли позволит сделать лучший продукт.
Лично я являюсь сторонником написания тестов, но меня всегда забавляли «менеджерские» фразы типа: «На самом деле вас ожидает гораздо больше разных временных потерь, если вы не пишите юнит-тестов». Ведь большинство людей здесь связаны с разработкой ПО и прекрасно понимают психологию программистов: если тестировщики найдут баг, то я его поправлю.
Так значит кто именно тратит больше времени? Я готов согласится, что выпуск релиза может удленниться, потому что возникает пинание фичи между тестировщиком и разработчиком, но… Во-первых, разработчику проще писать код без тестов, потому что это требует меньше интеллектуальных затрат, а во-вторых, его _личного_ времени уйдет меньше, потому что именно тестировщик будет придумывать сложные сценарии отлова багов. Программист при этом будет занят чем-то другим, и если тестировщик таки найдет багу, то программист достаточно быстро ее поправит и дело с концом. Т.е. для себя лично программист будет уверен, что справился с задачей быстро, хотя таких round-trip'ов может быть много и реально время на разработку фичу в целом будет затрачено больше.
Я думаю, что правильнее мотивировать разработчиков писать тесты не словами типа «вы будете меньше времени тратить на фичи» или что-то в этом духе, а тем, что вы будете говорить: С тестами ты напишишь реально классный код, потому что если ты можешь его покрыть тестами, значит ты классно развязал все зависимости и отлично спроектировал интерфейсы. А фразы про меньше времени оставьте на убеждение менеджеров, программистам они не нужны.
Крайне рекомендую в плане интерфейса посмотреть в сторону ToDoBox — www.androidzoom.com/android_applications/productivity/todobox_hqyo.html Ваш интерфейс «уныл», и программой неинтересно пользоваться. На мой взгляд, это самый главный недостаток программ организации задач. Программа должна мотивировать пользователя делать задачи, которые он записал, именно тогда пользователь почувствует, что его персональная эффективность выросла и именно благодаря вашей программе.
В ToDoBox же есть несколько очень существенных недостатков в плане функционала, но я пользуюсь именно этой программой просто потому, что ей приятно пользоваться и на функциональные недостатки я просто не обращаю внимания
Общий вопрос: а насколько сейчас актуально применение Linq2SQL вообще? Насколько я понимаю MS подзабило на этой технологии и вовсю продвигает Entity Framework. Стоит ли сейчас относится к Linq2SQL как скорее к proof of concept?
Спасибо за статью. К сожалению, я не все понял, и хотел уточнить у Вас кое-какие детали.
Каким образом Вы с помощью автоэнкодера решаете аномален ли запрос или нет? Выдаёт ли Ваша модель ответ вида Да/Нет? Расскажите подробнее как выглядит ответ для НЕ аномального запроса? Или это отдельная модель на основе кодера — используете мультатскинг?
Когда декодер выдаёт результат, то длина выходного вектора в общем то может не равняться длине входа. Как Вы потом эти вероятности маппите на исходный входной текст запроса, если размеры не совпали?
Допустим вероятности получены и их количество равно количеству символов входного запроса. Как Вы определяете трешхолд вероятности выше «нормальной», что символ должен быть помечена как аномальный символ? Просто используете 0.5?
Как Вы решали проблему несбалансированных классов примтреннировке? Ведь аномальных запросов намного меньше, чем нормальных и модель, не так ли?
Как выглядела Ваша тренировочная выборка — Вы вручную разметили в анормальных запросах аномальные куски текста?
Уж не знаю как насчет «рождения нового Facebook», но если ребятам удастся донести канадцам, что этот сервис сделан их соотечественниками, то популярность им обеспечена. Канадцы будут пользоваться этим сервисом чисто из солидарности. У них это тут очень сильно развито.
«В августе 2012 года японский математик Синъити Мотидзуки заявил, что ему удалось доказать эту гипотезу.[3] В октябре того же года Веселин Димитров и Акшай Венкатеш (Akshay Venkatesh) обнаружили ошибку в доказательстве. Мотидзуки признал этот факт, но заявил, что данная ошибка не влияет на основные результаты, а также обещал в ближайшее время опубликовать исправленную версию.»
Я правильно понимаю, что после этого Мотидзуки обновления не выкладывал? Значит можно считать, что проблема то есть, а раз кроме Мотидзуки не может сказать, что она «несущественная», а он сам исправления не выкладывает, то значит доказательство неверное.
По-моему, подобный подход может привести к дубляжу кода запросов. Хорошо, когда запрос — это просто «загрузи все посты». А представьте, если посты могут быть помеченными как «archived» с помощью флага. Пользователь же всегда должен работать с активными постами, и есть редкие случаи, когда ему показываются и архивные посты тоже.
В таком случае надо будет искать все Query к постам и добавлять везде, где надо, .IsNotArchived(), нежели просто поменять методы в репозитории Post. Имхо, это уже дубляж пойдет.
Как этот термин звучит на английском?
Но я только одного не пойму, разве для этого необходимо переходить на Git? Почему в Subversion тоже самое нельзя сделать? При этом я подразумеваю, что создание нового бранча — это не часы, а минут 10. Или в Git'е реализована еще более крутая система автомерджинга?
Даже с учетом скидки на 2к, в современном мире планшетов это устройство выглядит жалким. При всех преимуществах е-инка, юзабилити устройства осталось на таком же низком уровне, что и годами раньше. Сенсорный экран добавлен скорее как дань моде, а ведь из него можно было выжать столько класных и удобных фич.
Все кончилось тем, что я отписал в Pocketbook мысли по улучшению этого устройства, но не уверен, что что-то изменится. А на сэкономленные деньги я присматриваю себе планшет-нетбук.
При этом конечный софт, скорее всего, будет отличаться от исходной спецификации, но не во всем же.
Разработка софта — процесс итеративный, и это нормально, когда ты допиливаешь спецификации и уточняешь требования по ходу выполнения. И я согласен с Линусом — слепое следование спецификации вряд ли позволит сделать лучший продукт.
Так значит кто именно тратит больше времени? Я готов согласится, что выпуск релиза может удленниться, потому что возникает пинание фичи между тестировщиком и разработчиком, но… Во-первых, разработчику проще писать код без тестов, потому что это требует меньше интеллектуальных затрат, а во-вторых, его _личного_ времени уйдет меньше, потому что именно тестировщик будет придумывать сложные сценарии отлова багов. Программист при этом будет занят чем-то другим, и если тестировщик таки найдет багу, то программист достаточно быстро ее поправит и дело с концом. Т.е. для себя лично программист будет уверен, что справился с задачей быстро, хотя таких round-trip'ов может быть много и реально время на разработку фичу в целом будет затрачено больше.
Я думаю, что правильнее мотивировать разработчиков писать тесты не словами типа «вы будете меньше времени тратить на фичи» или что-то в этом духе, а тем, что вы будете говорить: С тестами ты напишишь реально классный код, потому что если ты можешь его покрыть тестами, значит ты классно развязал все зависимости и отлично спроектировал интерфейсы. А фразы про меньше времени оставьте на убеждение менеджеров, программистам они не нужны.
1. Сначала выбираем фильм, а потом время.
2. Сначала выбираем время («что там у нас сегодня вечером будет?»), а уже потом фильм.
В ToDoBox же есть несколько очень существенных недостатков в плане функционала, но я пользуюсь именно этой программой просто потому, что ей приятно пользоваться и на функциональные недостатки я просто не обращаю внимания