Привет!
В этом посте я хотел бы рассказать историю развития бесплатной версии моего приложения, которая увидела свет чуть больше года назад. Рассказать о том, как мне удалось исключительно техническими средствами увеличить количество загрузок (и, в данном случае, прибыль) в три раза.
Кому интересно, добро пожаловать под кат.
Читать полностью »
.jpeg "Смена парадигмы программирования на C#, переход на сигналы и очереди (слоты)")
В этом посте я рассматриваю концепцию и ее реализацию (пока в начальной, но рабочей стадии), которая с недавних пор стала меня сильно привлекать. Опыта в программировании на сигналах у меня ранее не было, поэтому что-то мог упустить или неоптимально продумать, потому и пишу сюда. Надеюсь на квалифицированные отзывы и советы. Несмотря на то что библиотека только начала развиваться, я уже начал ее использование в реальных проектах, на реальной нагрузке, это помогает быстро понять что действительно нужно и куда двигаться дальше. Так что весь приведенный код находится в рабочем состоянии, компилируется и готов к использованию. Единственное все делается на Framework 4.5, но не думаю что это будет для кого-то препятствием, если же идея окажется стоящей, пересобрать под 3.5 проблем не будет.
Устройство обычного приложения на .NET подразумевает что у нас есть набор классов, в классах есть данные, и методы которые эти данные обрабатывают. Также нашим классам надо знать друг о друге, о public методах, свойствах и событиях. То есть у нас сильносвязная архитектура. Конечно мы можем уменьшить связность, построить взаимодействие исключительно через интерфейсы и фабрики (что увеличит размер кода раза в два, и существенно усложнит читабельность), можем убрать открытые методы и стоить все на событиях, придумать можно много чего, но перейти к слабосвязанной архитектуре все равно не выйдет, получим в лучшем случае «среднюю» связанность.
Да, и еще есть такая вещь, которая с развитием процессоров становится все более актуальной, это асинхронность, microsoft делает много хорошего в этом направлении, тот же PLINQ, всякий сахар вроде await, но все это делается все равно в привычных рамках ООП, и нам все еще приходится самим создавать потоки, пускай и в виде тасков, но самим. Нужно отслеживать окончание исполнения задач, чтобы определить когда рессурсы станут ненужными.
В общем все это постепенно надоедает, становится лень писать одни и те же вещи в каждом новом проекте, когда правильнее было бы сосредоточиться на логике задачи.
Читать полностью »
Практически все существующие html-шаблонизаторы используют проверенный способ — «директивы в разметке». Это позволяет создать видимость инкапсуляции шаблона и, как будто бы, позволяет достичь разделения логики и отображения. На практике, шаблоны невозможно реализовать без условий, циклов и вызовов функций, а это — зависимость непосредственно разметки от используемого языка и его возможностей. При этом поддержка и изменение шаблона ложится на плечи программиста — ведь верстальщик не должен знать о ядре системы и ее объектах.
Меня давно заинтересовал другой подход к проблеме — он пришел из JavaScript, а если взять глобальнее, то из самой сути HTML.
Итак, в этой статье я расскажу о способе шаблонизации «HTML+Код».
Имеется довольно наболевшая для программистов организаций-пользователей MS Project задачка — получение заметок ответственных лиц. Заметки имеют значительную ценность (при правильной постановке задачи управления), потому что без исходной информации проблемы не классифицировать и правильное решение не принять. Их, заметки, конечно, надо выводить в отчеты.
С точки зрения пользователя все вроде бы просто — отчет он и есть отчет, но с технической точки зрения открывается масса нюансов и вопросов. В этой статье я привожу свое решение, основанное на некоторых кусках кода, раскиданных то тут, то там, по сети, и надеюсь, что оно пригодится моим коллегам.
Не претендую на оригинальность, однако аналоги данного решения почему-то не нашел, пришлось собирать самому. Кроме того, я не очень глубокий спец по MS SQL, поэтому, буде возникнут дельные комментарии — прошу комментировать.
Достаточно большое число людей используют github для хранения исходного кода своих проектов. Идеология fork/pull request позволяет достаточно легко выполнять обзоры кода (code review). Обзоры кода в значительной степени позволяют поднять качество кодирования в проекте. Однако, часто человек выполняющий обзор кода вынужден заниматься проверкой стандартов кодирования принятых в проекте, и прочих очевидных вещей не связанных непосредственно с задачей решенной в pull запросе. Такие ошибки кодирования могут и должны быть обнаружены автоматически.
Читать полностью »
Привет!
Не для широких масс, но для любителей программирования и графики решился я опубликовать сей пост.
Читать полностью »
JavaScript отличается от многих других «объектно-ориентированных» языков программирования тем, что в нём объекты есть, а классов — нет. Вместо классов в JavaScript есть прототипные цепочки и некоторые другие хитрости, которые требуют времени на осмысление. Перед профессиональными программистами в других языках при переходе на JavaScript встаёт проблема быстрого вхождения в его объектную модель.
Этот текст написан для того, чтобы дать начинающему или эпизодическому разработчику на JavaScript представление о способах создания объектов в JavaScript, от простого «структурного», как в языке C, к более «объектно-ориентированному», как в C++/C#/Java.
Статья может быть рекомендована как новичкам в программировании, так и профессиональным бэкенд-программистам, эпизодически вынужденным погружаться в JavaScript.
Читать полностью »
Не в совокупности ищи единства, но более – в единообразии разделения.
Козьма Прутков
Нельзя не заметить, что аспектно-ориентированное программирование с каждым годом берет новые рубежи популярности. На хабре было уже несколько статей посвященных этому вопросу, от Java до PHP. Пришло время обратить свой взор на С/C++. Теперь я в первом же абзаце признаюсь, что речь пойдет не об «настоящих аспектах», но о чем-то, близко с ними связанном. Также рассуждение будет вестись в контексте embedded-проектов, хотя описываемые методы могут применяться где угодно, но именно embedded, это та область, где эффект будет максимально ощутимым. Еще я буду использовать слова «хидер» и «дефайн» для обозначения, соответственно, «заголовочного файла» и «макроопределения». Сухой и академичный язык это хорошо, но в данном случае, мне кажется, все будет проще понять, если пользоваться устоявшимися англицизмами.
Читать полностью »
Facebook — одно из самых функциональных приложений, доступных на Android. С такими функциями, как push-нотификации, новостная лента и встроенная версия Facebook Messenger (фактически, являющаяся полноценным приложением), которые работают одновременно в реальном времени, сложность и объём кода порождает ряд технических сложностей, с которыми сталкиваются в том числе и другие Android разработчики — особенно на старых версиях платформы. (Наши последние приложения поддерживают старую версию Android 2.2 — Froyo, которой уже почти 3 года).
Одна из таких проблем связана с тем, как виртуальная машина Android — Dalvik, обращается с Java методами. В конце прошлого года мы закончили переработку нашего Android приложения, которая включала в себя перевод большого объёма JavaScript кода в Java, а так же использование новых абстракций, которые породили большое число небольших методов (в большинстве случаев, это считается хорошей практикой программирования). К сожалению, это привело к резкому увеличению числа методов в нашем приложении.
