Сегодня речь пойдет о том, как создать игру не используя js и прочих скриптов. Только HTML / CSS, только хейткор.

Многие документы содержат защитные элементы, такие как голограммы, водяные знаки, гильош и т.д. В процессе сканирования таких документов возникает проблема — защитные элементы мешают системам распознавания (OCR). При разработке Smart PassportReader мы провели исследование, направленное на поиск и устранение подобных защитных элементов с изображений документов.



В нашей предыдущей статье по этой теме мы рассказали о первой половине решения задачи поиска — детектировании, т.е. определении наличия периодических элементов на изображении. Сегодня мы расскажем, как найти непосредственное положение периодических элементов на изображении, при условии, что детектирование прошло успешно: мы уверены, что элементы на изображении присутствуют. Вторая часть сильно зависит от первой, поэтому настоятельно рекомендуется сначала ознакомиться с первой, если вы этого еще не сделали.

Как и в прошлый раз, для этого будет использоваться преобразование Фурье.

1. Вступление

Сталкиваясь с необходимостью контролировать работу других программистов, начинаешь понимать, что, помимо вещей, которым люди учатся достаточно легко и быстро, находятся проблемы, для устранения которых требуется существенное время.

Сравнительно быстро можно обучить человека пользоваться необходимым инструментарием и документацией, правильной коммуникации с заказчиком и внутри команды, правильному целеполаганию и расстановке приоритетов (ну, конечно, в той мере, в которой сам всем этим владеешь).

Но когда дело доходит собственно до кода, все становится гораздо менее однозначно. Да, можно указать на слабые места, можно даже объяснить, что с ними не так. И в следующий раз получить ревью с абсолютно новым набором проблем.

Профессии программиста, как и большинству других профессий, приходится учиться каждый день в течение нескольких лет, а, по большому счету, и всю жизнь. Вначале ты осваиваешь набор базовых знаний в объеме N семестровых курсов, потом долго топчешься по различным граблям, перенимаешь опыт старших товарищей, изучаешь хорошие и плохие примеры (плохие почему-то чаще).

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

Кевин Поулсен, редактор журнала WIRED, а в детстве blackhat хакер Dark Dante, написал книгу про «одного своего знакомого».

В книге показывается путь от подростка-гика (но при этом качка), до матерого киберпахана, а так же некоторые методы работы спецслужб по поимке хакеров и кардеров.

Начало и план перевода тут: «Шкворень: школьники переводят книгу про хакеров».
Пролог
Глава 1. «Ключ»
Глава 3. «The Hungry Programmers»
Глава 5. «Cyberwar!»
Глава 34. DarkMarket
(публикуем по мере готовности переводов)

Логика выбора книги для работы со школьниками у меня следующая:

• книг про хакеров на русском языке мало (полторы)
• книг про кардинг на русском нет вообще (UPD нашлась одна)
• Кевин Поулсен — редактор WIRED, не глупый товарищ, авторитетный
• приобщить молодежь к переводу и творчеству на Хабре и получить обратную связь от старших
• работать в спайке школьники-студенты-специалисты очень эффективно для обучения и показывает значимость работы
• текст не сильно хардкорный и доступен широкому кругу, но затрагивает вопросы информационной безопасности, уязвимости платежных систем, структуру кардингового подполья, базовые понятия инфраструктуры интернет
• книга иллюстрирует, что «кормиться» на подпольных форумах — плохо заканчивается

Кто хочет помочь с переводом других глав пишите в личку magisterludi.

Глава 1. Ключ

(текст переведен в рамках коллективного проекта школьников в лагере GoToCamp, спасибо Алене, Кате, Соне, Грише, Саше и хабраюзеру ShiawasenaHoshi)

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

С удивлением обнаружил, что на Хабре отсутствует информация о таком замечательном движке как Urho3D. Поэтому спешу исправить это досадное упущение. В этой вводной статье я постараюсь заострить внимание на тех вещах, которые пригодятся новичкам сразу же, но в тоже время не буду залезать в глубокие дебри, чтобы сходу не перегрузить большим объемом информации.

Что это за зверь?

Не будет преувеличением сказать, что Urho3D по возможностям сопоставим с Unity3D и работать с ним так же легко. При этом он бесплатен без каких-либо оговорок (лицензия MIT), доступен для многих платформ (Windows, Linux, Mac OS X, Android, iOS, Raspberry Pi, HTML5), невероятно быстр и легковесен. Позволяет писать игры на AngelScript (синтаксис похож на C#), LUA и C++. Если вы заинтересовались, то добро пожаловать под кат.

Недавно потребовалось мне сделать небольшую прогу под Windows. Раньше мне не доводилось разрабатывать под нее.
Сама программа несложная, написалась относительно быстро. Намного больше времени отъела сборка ее под винду. Понятно, что выбранные инструменты (Python3 + Qt5) не родные, а универстальные, но что потребуется столько времени затратить на сборку, я не предполагал.
Соответственно, хочется поделиться практикой, может кому еще придется стучаться лбом в эту стену.
Под катом выстраданная инструкция как легко собирать PyQt5 приложения в single-file.exe не требующий инсталлятора.

Привет, Хабр!

Наш образовательный проект Хекслет продолжает развиваться. Мы готовим два важных изменения: 1 — вместо каталога разрозненных курсов мы будем публиковать «стеки», наборы последовательных курсов, готовящих специалистов в определенной области; 2 — добавляем элементы менторства и личного общения с преподавателями.

В качестве первого шага предлагаем вам выполнить небольшое, но очень полезное практическое задание. В пятницу, 24 июля в 20:30 МСК наш технический директор Кирилл Мокевнин toxicmt проведет код–ревью нескольких типичных решений, укажет на хорошие и плохие моменты и расскажет о том, как это задание помогает многое прояснить в понимании парадигм программирования.

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

Здравствуй хабрхабр!

В данной статье я хотел бы рассказать, сформулировать свои мысли по поводу такой замечательной библиотеки как wxPython. Под катом вы найдете небольшую теорию, описание форм, разбор свойств форм, различных контролов и всё что касается wxPython.
Welcome to wxPython.

Ни одному дизайнеру не удаётся всё время создавать восхитительные работы. Создание хорошего дизайна требует значительных усилий, но достигать удивительного результата порой получается совершенно не напрягаясь. Многие дизайнеры следуют интуиции во время творческого процесса, и включают общепринятые символы и метафоры в свои работы просто потому, что они «чувствуют» их уместность. Интуицией можно воспользоваться любой, а особенно полезна она в творческой деятельности. Она ведёт дизайнеров к решениям, согласующимся с общепринятыми знаниями.

На дизайн бывает три реакции: да, нет и ОГО! К «ого» и нужно стремиться.

— Милтон Глейзер

Хороший логотип открывает широкие возможности для рекламы. Именно этого и пытаются достичь. Конечно, в дизайне не последнюю роль играет работа интеллекта, но комбинируя интуицию, символы и метафоры со стратегическим мышлением вы собираете информацию, которая необходима для создания выдающегося и запоминающегося логотипа.

Интуитивный процесс дизайна

Интуиция – это бессознательное восприятие

— Карл Юнг

Всегда есть люди, отметающие то, что нельзя измерить. Но многие мыслители отдавали должное интуиции. Альберт Эйнштейн, Ричард Бакминстер Фуллер, Карл Юнг, Рэй Бредбери, Стив Джобс и даже Алан Тьюринг, знаменитый логик и криптоаналист, понимали, что математические доказательства основываются на «интуиции и гениальности». Великие мыслители и футуристы отводят интуиции ключевую роль в процессе решения задач. Для дизайнеров интуиция – это не нечто чужеродное, это больше похоже на дыхание. В интуиции, как в воде, плавают многие творцы, в то время, как их интеллект диктует формулу для исполнения и оформления конечного продукта.

Для многих, кто никогда не программировал, обучение программированию кажется невероятно сложной задачей. Как бы то ни было, спасибо тому огромному количеству ресурсов, которые недавно стали доступны в Интернет и являются бесплатными — самообучение программированию никогда еще не было таким простым.

Я начал изучать программирование в начале этого года, и могу сказать по своему опыту, что изучение достаточного количества материала, чтобы создать свой собственный прототип не такая уж и сложная задача, как вам кажется. В самом деле, если вы хотите иметь рабочий прототип в течение двух месяцев, не прибегая к использованию отгулов, это абсолютно выполнимая задача.

Ниже я описал простой путь от ничего не зная о разработке программного обеспечения до обладания рабочим прототипом за восемь недель, который примерно повторяет шаги, которые я выполнил.

Сегодня все больше приложений создается сразу для нескольких мобильных платформ, а приложения, созданные изначально для одной платформы, активно портируются на другие. Теоретически можно полностью писать приложение «с нуля» для каждой платформы (т.е. фактически «кроссплатформенной» оказывается только идея приложения). Но это означает, что трудозатраты на его разработку и развитие будут расти пропорционально количеству поддерживаемых платформ. Если же многоплатформенность изначально заложить в архитектуру приложения, то эти затраты (плюс, в особенности, затраты на поддержку) могут существенно сократиться. Вы разрабатываете общий кроссплатформенный код один раз — значит используете его на текущих (и будущих) платформах. Но в этом случае сразу возникает несколько взаимосвязанных вопросов:

• Должна ли быть граница между общим (кроссплатформенным) и нативным (специфичным для данной платформы) кодом?
• Если да, то где и как провести эту границу?
• Как сделать так, чтобы кроссплатформенный код было удобно использовать на всех платформах, как на тех, что надо поддержать сейчас, так и на тех, чья поддержка, вероятно, может потребоваться в будущем?

Конечно, ответы на эти вопросы зависят от конкретного приложения, предъявляемых к нему требований и накладываемых ограничений, поэтому универсальный ответ найти, по всей видимости, невозможно. В этой статье мы расскажем, как мы искали свои ответы на эти вопросы в процессе разработки мобильного клиента Parallels Access для iOS и Android, какие архитектурные решения были приняты и что в итоге получилось.

Хочу сразу предупредить, что букв в этом посте много, но дробить тему на куски не хотелось. Поэтому запаситесь терпением.