КОТ++
Прикладное программирование
Системное программирование
Программирование микроконтроллеров

640 Кб должно хватить для любых задач. (c) Билл Гейтс

Поиск по тегам

Опубликовано
Комментарии 0

И так мне понадобилось разобрать данные из файла шрифта woff (Web Open Font Format). Я прям с самого начала скажу, что там чёрт ногу сломит, а разработчики формата это представители инопланетной жизни страдающие от старческого маразма. Отправляемся на https://www.w3.org/TR/WOFF/, читаем, в принципе всё понятно (нет). Если кратко, то это бинарный файл, который имеет заголовок с информацией о таблицах. Таблицы – это некоторые структурированные данные, информация в которых отражает только один технический аспект шрифта. И все эти таблицы в woff заархивированы DEFLATE алгоритмом сжатия. На картинках ниже формат woff файла представлен более подробно.

Я буду рассматривать в этой статье только таблицы cmap и CFF, так как основная информация о символах именно в них.

cmap таблица по сути содержит информацию о том, как перейти от unicode байт к глифам (к начертаниям). По каким-то неведомым причинам видов cmap таблицы существует аж 14 штук, что за балаган? Но мне нужен только 4-ый. Документация просто ужасная, но методом проб и ошибок я пришёл к правильному способу перехода от unicode к глифам. Мне повезло в том, что количество сегментов равнялось количеству символов, и соответственно каждый startCode равнялся коду каждого символа. Но glyphIdArray почему-то был пустой. В итоге я сделал так: к startCode прибавил idDelta, и отсортировал полученные результаты по порядку. Этот порядок строго соответствовал порядку глифов в CFF. Може я сделал не совсем правильно, но иного способа не нашёл. Потому что везде пишут о том, что для этой задачи нужны ещё таблицы glyf и loca, но в woff файлах я этих таблиц не видел.

Перейдём к CFF. Если вы открыли документацию по CFF, то думаю вы поняли, что особо ничего и не понятно. CFF таблица состоит из заголовка, индексов (INDEX) и словарей (DICT). Индексами названы данные, которые структурированы как массив, словарями названы данные, которые структурированы как ключ-значение данные. В CFF присутствуют следующие данные: NameIndex, TopDictIndex, StringIndex, GlobalSubrIndex, Charsets, Encodings, CharStringIndex, PrivateDict, FontDictIndex, LocalSubrIndex. Мне понадобилось разобрать именно CharStringIndex, но так как данные предусматривалось находить по offset’ам, а offset говорит о нахождении только следующего блока, то разбирать пришлось практически всю CFF таблицу, чтобы дойти до CharStringIndex. Для идентификации глифов из CharStringIndex я просто сранивал длину каждого CharString из этого массива, дальше расковыривать формат не требовалось.

Кстати, в процессе поиска информации о форматах нашёл блог одного очень умного азиата, его исходники мне очень помогли в работе, парень проделал огромную работу по разбору шрифтов. В его исходниках всё понятно, написано очень классно, в отличие от мудацких исходников opentype.js, по которым понятно только одно, что автору платили за кривость кода.

В заключении вернусь к вопросу о том, что почему же woff формат такой сложный? Этот формат несёт в себе наследие CFF формата. CFF насколько я понимаю по документации был разработан в 2003 году, и вероятно он тоже в себе таит тайны прошлого. Прошлого, когда был важен каждый байт и важна скорость загрузки информации в память (а самая быстрая загрузка это когда просто копирование последовательности байт в память), видимо поэтому вся информация о шрифтах структурировалась в бинарный вид, вид который хорошо понятен машине, а не человеку – это вам не json смотреть.

Теги , ,
Автор

Опубликовано
Комментарии 0

В этом посте я хочу озвучить что же не так со многими скриптовыми языками. Я очень давно не люблю что JavaScript, что Python, что PHP, но какое-то время не мог чётко сформулировать причину. И вот недавно разбираясь в исходниках opentype.js, я полностью понял что же не так с этими скриптовыми языками.

Главный аспект программирования это управление сложностью, то есть код должен быть простым и понятным для чтения. А значит разрабатывая проект программист должен уменьшать сложность конкретных участков кода, чтобы логика каждого просматриваемого участка кода была понятной другому человеку. Это как жонглирование, или же жонглировать 20-ю яблоками, или например 7-ю, разница почти в три раза. Также и в программировании, уменьшая количество сущностей, которые нужно держать в голове в один момент времени упрощается мысленное жонглирование. По некоторым исследованиям говорят, что оптимальное количество сущностей должно быть не более 7-и, по этой причине, например, советуют не использовать в одном методе более 7 переменных.

Поэтому от профессионала требуется определённая дисциплина, чтобы писать код понятный не только машине, но и другим людям. Многие языки в этом помогают, например наличие классов, наличие строгой типизации, наличие хорошего синтаксиса приближенного к человеческому восприятию и так далее. Так вот JavaScript не имеет из этого ничего, в результате мы имеем очень низкий порог входа, что очень радует людей по складу ума далёких от программирования и в добавок к этому получаем кучу некачественного кода. Да, на JavaScript можно писать хорошо, можно в имена переменных добавлять постфикс или префикс для обозначения типа, эмулировать классы (но про интерфейсы придётся забыть), не злоупотреблять динамической типизацией и прочее. Но для этого человек должен быть сильно дисциплинированным, и вот парадокс – хорошо дисциплинированный человек не посмотрит в сторону JavaScript, Python, PHP и прочего. Разжёвывать дальше недостатки, которыми болеют Python и PHP, у меня нет желания, мысль и так ясна.

Такие языки будут привлекать только людей, которые не испытывают тягу к программированию по-настоящему, а лишь людей с тягой к деньгам, ведь JavaScript и Python на мой взгляд очень раскручены корпорациями и пузырь зарплат разработчиков на скриптовых языках чрезмерно надут. И как вы думаете какого качества проекты в итоге получатся от выше описанных кодеров?

Теги ,
Автор

Опубликовано
Комментарии 0

Как-то много раз передо мной мелькали различные статьи по поводу языка Haxe, описывали его достаточно красочно, и я очень сильно загорелся попробовать что это такое собственно. Для тех кто совсем не в курсе: Haxe позволяет транслировать свой код в код других языков (php, javascript, flash, c++, java, c#). Тем самым достигается мультиплатформенность. На словах, конечно, очень всё красиво и замечательно. Но на деле всё несколько иначе.

Чтобы плотно познакомиться с этим языком, я решил, что возьму свой старый flash проект и попробую переделать на Haxe. Почему flash? Да потому, что синтаксис Haxe максимально близок к синтаксису ActionScript 3, так заявлено разработчиками, на деле же есть множество маленьких несостыковок, из-за которых пришлось конкретно промучаться при переделывании проекта. Обрадовало, что для Haxe есть очень хорошая среда HaxeDevelop, это практически копия среды FlashDevelop, за которой я создал несколько игр, так что было очень приятно увидеть уже знакомый интерфейс.

И так, я беру проект Hot Jihod и начинаю пытаться собрать его под Haxe. Также очень круто, что под Haxe есть библиотека OpenFL, которая практически повторяет Flash, что существенно упрощает работу по сборке проекта в Haxe. Но на деле я промучался с жутким синтаксисом языка Haxe, меня очень расстроили циклы, синтаксис циклов for очень стал далёк от синтаксиса циклов for в C/C++, я считаю, что такие циклы for как в Haxe очень понятны и удобны новичкам в программировании, а для тех кто выучил C/C++ такой синтаксис только раздражает.

for (var i: int = 0; i < rest.length; i++) //AS3 синтаксис 
for (i in 0…rest.length) //синтаксис Haxe, 1-ый вариант
for (item in rest) //синтаксис Haxe, 2-ой вариант

Кто-то скажет: «что в Haxe то лучше!». Возможно в каком-то смысле так и есть. Но мне не по душе такие циклы, да и к тому же пришлось ходить по всему коду и исправлять циклы на Haxe вариант. И ещё на самом деле очень много чего исправлять пришлось, по сути обещанный ActionScript подобный синтаксис я не особо получил.

Но и самое главное, что в итоге, когда проект собрался, то игра не заработала, она не заработала ни под одну платформу. Вывод графики напоминал то, что программа неправильно обрабатывает шейдеры. Хотя под некоторые платформы был какой-то проблеск того, что вроде какая-то там графика пытается нарисоваться, но например под HTML5 вообще пусто, чёрный экран. А я то ведь уже замечтался, что у меня в руках хороший инструмент, который почти Flash, и с помощью него я смогу делать игры и под Windows и под HTML5, используя по сути всё тот же Flash. В общем я проверил отрисовку через GPU, правильные ли остались шейдеры от прежней программы, потратил на это несколько часов. В итоге пришёл к выводу, что эта OpenFL очень сырая, отрисовка через GPU содержит много ошибок и не повторяет того как работает Flash.

Но может быть Haxe применим в чём-то другом? Я попробовал поискать вакансии на hh.ru с ключевым словом Haxe, но он нашёл ровно 0 результатов. Мой вывод: Haxe и библиотеки под него работают достаточно криво, сфера использования этого языка очень ограничена (если вообще существует), изучать и копаться в нём нет смысла, так как он никому не нужен, а для самостоятельного использования не даёт нужного результата.

Теги , ,
Автор

Опубликовано
Комментарии 0

Привет, котаны! Я недавно подумал, что этот блог не совсем подходит для новичков в программировании. Т.е. я не даю каких-то основ или помощи начинающим программистам. И я решил, что это пора исправить. Эта статья откроет целый цикл статей, которые помогут освоиться в программировании новичку. Почему именно мой блог может помочь в этом? Ведь есть множество статей на данную тему и множество книг. Это верно. Но я не встречал публикаций, которые могут максимально точно заложить в новичка начальных знаний для некоторого понимания процесса программирования. Т.к. я практически самостоятельно прошёл путь от полного аномального непонимания программирования до уверенной разработки программных продуктов, то на своём опыте знаю что и как нужно объяснить человеку для этого. Сейчас прошу отойти от экранов опытных программистов, и остаться тем, кто только-только осваивается или хочет освоиться в мире программирования.

Базовые вещи, которые нужно знать, чтобы упростить понимание:
1. Программа – набор команд, которые компьютер выполняет по очереди.
2. Программа пишется, с помощью инструкций (команд), эти инструкции ещё называются операторами.
3. У программы всегда есть точка входа (место в коде откуда она запустится). Но так называемой точки выхода может и не быть, т.е. программа может и не быть (программа должна работать всегда).

Далее чтобы очень быстро окунуться в мир программирования лучше начать с практики. Т.е. предлагаю метод от к практике к теории. Ставите себе не очень сложную задачу по программированию, пытаетесь решить, в процессе решения возникнет много вопросов, которые просто нужно уметь правильно сформулировать и гуглить.

Например, я когда начинал изучать программирование почему-то захотел написать программу по переводу чисел из различных систем счисления в различные системы счисления. До этого я вообще ничего не умел и не знал в программировании. Некоторое время потупил в среде PascalABC и ко мне пришло хоть какое-то понимание. В итоге моя задача разбилась на несколько подзадач: ввод данных, разбиение числа на цифры, хранение этих цифр, проверка условий для перевода в нужную систему счисления из заданной, перевод, вывод рассчитанной информации. Далее эти подзадачи в голове разбивались ещё на подподзадачи и т.д. Годы практики и всё это тщательное обдумывание решения будет уже на автомате, нужен только опыт. А самое сложное это начать, преодолеть тот момент, когда мозг уже кипит, а понимания нет, просто нужно пытаться до тех пор пока не придёт это так называемое понимание.

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

Теги , ,
Автор

Опубликовано
Комментарии 0

АААААААААААААА блять сколько можно требовать от человека всё что угодно, сопровождая требования фразой: «ТЫЖ ПРОГРАММИСТ»?! Я думаю, что все уже поняли о чём пойдёт речь в данном посте. Готовьтесь пост взорвёт ваши пуканы. Хотя может бомбанёт только мой. Да, скорее всего взорвётся только у меня.

Я думаю, что все эти удивительные ситуации со сказочными требованиями к программистам идут от непонимания того, кем является программист. Вернее от понимания, от понимания в IT чуть меньше чем нихуя. Так вот я исправлю эту проблему раз и навсегда. Программист – это тот кто пишет блядский код, он блять программирует, программы делает. Он не взламывает злоебучую, безумно глючную, бело-синию соц. сеть, не занимается установкой ОС и программ, не продаёт компы, не чинит компы, не собирает компы. Он блять просто пишет ёбаный код. Хотя не исключено, что всё вышеперечисленное он может делать, и это не значит что только этим программист и занимается целыми днями дома и на работе.

Бывает общаешься с кем-нибудь:
-Кем ты работаешь?
-Программист
-Всего-то
-ЧТО ВСЕГО-ТО?
-Винду устанавливаешь
(БЛЯТЬ, неужели многие думают, что кодеры это такие люди, которые на работе целыми днями винду ставят, это же сколько компов нужно, или он просто на один и тот же комп весь день ставит и сносит винду, ставит и сносит)

-У меня комп не работает почему-то
-И что?
-Почини, ты ж умеешь
-Во-первых я не экстрасенс, а во-вторых не чиню я ебучие компы
-ПОЧЕМУ O_O
(действительно нахуй почему же? O_o)

-Посмотри эту страничку ВК
-Зачем?
-Ну достань инфу из сообщений
-Какую ещё блядскую инфу?
-Ну взломай, ты же можешь, программист же
-ААААААААААААААААААААААААААААААААААА, уйди от меня, не общайся больше со мной

Что же с этим можно сделать и как исправить все эти недоразумения? Покажите им этот пост, если не помогло, то нахуй не общайтесь с этими динозаврами! На сем завершу, всем пока!

Теги , ,
Автор

Опубликовано
Комментарии 0

В очередной раз хочу поднять тему NIH (not invented here) синдрома в программировании. Многие люди в том числе и я склонны к тому, чтобы каждый элемент проекта был разработан с нуля и своими руками. Это чревато беспричинно большими затратами времени, а также собственная разработка чаще всего не проходит должного тестирования. В итоге получается проект на который было затрачено уйма времени, т.к. разработчики писали помимо основного кода ещё и собственные движки и библиотеки, а он ещё и глючит.

Но у синдрома неприятия чужой разработки есть и свои плюсы. Программист, который «болен» NIH синдромом в процессе написания велосипедов досконально начинает разбираться в том как что работает получше своих коллег. Но это не значит, что всегда нужно делать все с 0. Потому как лепить велосипеды – это не единственный способ узнать, как работает тот или иной движок и пр. К тому же давайте тогда и компьютер свой с 0 сделаем. Ведь тот компьютер, которым мы пользуемся это чужая разработка, придётся свой изобретать.

Каждый раз, когда в проекте встаёт выбор между написанием своей библиотеки/движка и выбором уже существующих решений, очевидный вариант это определить, что будет быстрее: написать свою либу или освоить чужую. Могут быть разные ситуации, может даже случиться так, что придётся исправлять ошибки в чужой библиотеке (если она опенсорс). Но это в случае, если вам важны ваши времязатраты. Если же вас интересует делать все самому, то лучше делать самому, только сильно не увлекайтесь. Это опасный путь, можно случайно начать разрабатывать свою ОС.

Теги ,
Автор

Опубликовано
Комментарии 0

Если вы любитель состряпать очередной высер на юнити или в геймейкере. Или же вы пишите неебические скрипты на питоне, максимальные возможности которых это решить квадратное уравнение. То закрывайте вкладку, досвидания, всего вам доброго. Речь сейчас пойдёт о вас. И кстати мамкины кулхацкеры, которые юзают в очередной раз Ettercap и Metasploit в Kali Linux и пытаются получить доступ к страничке своей подружки, вас это тоже каснется, но когда-нибудь позже. Но ни в коем случае ни хочу задеть тех, кто реально с умом пользуется всеми вышеперечисленными инструментами.

Какая разработка игр была раньше? Перед разработчиками стояла дикая и невыполнимая задача: написать свой движок, саму игру и нарисовать графику. Сейчас почти также? Начнём с того, что для всех движки уже готовые. А продолжим тем, что из доступных инструментов не было удобных юнитей, был матёрый ассемблер для самых лютых прогеров. И при этом нужно уместить движок игры, саму игру и графику в память какого-нибудь картриджа сеги. А в картридж сеги влезает чуть меньше чем нихуя. И к тому же всё это сооружение не должно лагать. 99/100 сегодняшних прогеров скажут: СЛОЖНА!!!

Поэтому статус разраба игр и программиста в целом ранее был выше. Если ты разрабатываешь игры, то компилить код игры ты мог исключительно своей головой, мог знать кучу различных приёмов и хитростей по оптимизации.
А что же сейчас? А сейчас и компы мощные, которые простят огрехи в алгоритмах, и движки, которые сделают всё за вас. Это же хорошо, не так ли? Это тоже самое, что изобрести парктроник для помощи в парковке, но потом не удивляйтесь откуда берутся люди, которые не могут припарковаться самостоятельно без помощи техники. В программировании также. Дай программисту безумно полезный инструмент, который не будет его ограничивать ни в чём и программист будет писать настолько кривожопый код, что сатана подготовит отдельный котёл лично для этого жопорукого уебана. Обилие современных библиотек, движков и инструментов расслабляет разработчиков и делает из них твердолобых бездарей.

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

По сути получается, что большое количество инструментов снижающее количество начальных знаний для старта разработки снижает порог в хода в эту индустрию. Порог входа снижен – и тут же туда прутся уебки. Они уже повсюду!

Но в чём же ещё проблема? Так в том, что программировать игры уже не так круто. Ведь все недоразвитые думают, что разработчик юзает хитровыебанное юнити, в котором за один вечер можно сваять проект и кидаться им перед друзьями в стиле «я невъебенный гейм разраб». А то что чел изучил хитрости в работе конечной платформы, паттерны игрового программирования и вероятней всего написал свой движок, заточенный под его игру, так это никому уже не понять, кроме небольшой группы разрабов, которые в теме.

Юзайте юнити, юзайте движки, юзайте либы, но не забывайте изучать как это всё работает изнутри, всем удачи в разработке!

Теги
Автор

Опубликовано
Комментарии 0

Всякий раз, когда упоминаю то, что отлично прогаю на AS3, в ответ слышу одно: «Ты чо, flash же умер давно!». И в качестве аргумента выступает одно и то же, что на флеше уже никто ничего не делает. От этого ловлю дикий facepalm. С чего вы это всё берёте?

Чтобы развеять миф о том, что на флеше ничего уже не делают и не сделать пишу эту статью.

Для начала рассмотрим flash в мире браузеров. Flash якобы заменили HTML5, и поэтому flash ушёл умирать. Но даже на данный момент HTML5 не догоняет флеш, а возможно не догонит его никогда. HTML5 это прежде всего язык гипертекстовой разметки. В 5-ой версии добавлены всякие штуки для удобной работы с мультимедиа. Безусловно HTML5 это очень хорошая штука и позволяет делать сайты со всякими интерактивными плюхами без использования дополнительных плагинов. Но мне попадались куча сайтов, где этот хвалёный HTML5 давал жуткие тормоза, где Flash бы себе такого не позволил. С простыми анимациями HTML5 справляется, но уже даже на воспроизведении видео он даёт тормоза. Поэтому до сих пор на многих сайтах можно выбрать плеер для проигрывания видео (Flash или HTML5).

Но тут проблема не только у юзеров, а ещё и разработчиков. Флеш является некой виртуальной средой, в которой уже и запускается само флеш приложение. Разработчику без разницы где эта среда будет запущена, т.е. неважно под какой браузер разрабатывать приложение, оно везде будет работать одинаково. Поэтому для игр и для сложных интерактивных приложений Flash очень хороший вариант. Безумно сложно будет протестировать работу приложения во всех браузерах, ведь порой даже бывает неудобно проверять и подстраивать под все браузеры простую html вёрстку. Делая же на Flash, разработчику не надо заботиться о том, что очередной браузер чем-то может выделиться, ведь каждый браузер хочет как лучше, а получается как всегда. Ах да, ещё у HTML5 нет аппаратного ускорения, которое безусловно нужно для игр. Есть сырой WebGL, но связка HTML5 и WebGL не может соревноваться с флеш, флеш всё равно выиграет.

Поэтому на флеше до сих пор появляется множество браузерных игр. Поиграть в них можно, например, на одном из самых крупных флеш порталов http://www.kongregate.com/ И даже во ВК есть флеш игры.

Теперь перейдём на мобильные платформы. С помощью Adobe AIR можно, используя флеш, разрабатывать под мобильные платформы. А HTML5 такое умеет? Ладно, при чём тут HTML5, возьмём к примеру Unity. Unity тоже позволяет создавать мобильные игры и при чём очень хорошие. Но из-за того, что unity предназначен для любых игр, в него понавешано множество всяких штук, которые вряд ли будут использоваться при создании любой 2d игры. Использоваться не будут, а место в конечном файле игры занимать будут, а на мобильных платформах вес является важной вещью, отчасти потому, что игру будут скачивать через интернет, порой человеку, который сидит с мобилы не через вайфай очень важно, чтобы игра вместо 40мб весила всего 10мб. Ведь тогда сидя в пробке он поиграет в игру, а не будет ждать пока она скачается.

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

Но Adobe AIR позволяет разрабатывать игры ещё и под десктопную виндовс. Обилие неплохих таких игр на стиме говорит само за себя.

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

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

Возможно кто-то захочет прокомментировать в стиле: «У автора бобмит, он просто консерватор, любит старые технологии». Может так оно и есть, поэтому не тратьте своё время на банальные комменты.

Теги ,
Автор

Опубликовано
Комментарии 0

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

Разрабатывая очередную игру я столкнулся с проблемами производительности прорисовки графики стандартными средствами. Т.к. жутко не хотелось использовать Starling, самый популярный графический движок для AIR, одобренный адобовцами, то было решено изобрести велосипед.
После прочтения нескольких книг по Molehill в голове уже образовалась архитектура будущего графического движка для игры. За пару вечеров движок был написан.

Бенчмарк тесты показали такой фпс при 1200 анимированных объектах, анимация которых состоит из 4 кадров:
10 при отрисовке через обычный display list
22 с помощью starling
30 с помощью своего велосипеда
Также с уверенностью могу сказать, что просторы для оптимизации ещё существуют.

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

Теги , ,
Автор