Блог компании Ciklum → Поделись опытом и послушай Java-гуру на Сиклум Java Субботнике 11 февраля
Мы снова открываем сезон Сиклум Субботников в Киеве! Наш прошлый Сиклум Java Субботник в столице Украины был настоящим фуррором — его посетили 150 человек! Видя такой интерес и учитывая пожелания встретиться вновь, мы решили повторить :) и организовать еще одно полезное и приятное мероприятие для всех, кто программирует или только собирается начинать работать на Java.
По традиции, мы приглашаем всех желающих бесплатно посетить Сиклум Java Субботник 11 февраля в нашем киевском офисе
По традиции, мы приглашаем всех желающих бесплатно посетить Сиклум Java Субботник 11 февраля в нашем киевском офисе
Блог компании Ciklum → Приезжай в Харьков и отожги вместе с нами на Ciklum Mobile Субботнике и iPhoneDevCamp 2012
Вы не поверите, но начало 2012 года началось для нас жаркой зимой! Все дело в том, что мы, в Сиклум, ежемесячно проводим около 60(!) как внутренних, так и внешних мероприятий для разработчиков, таких как тематические Сиклум Субботники, Хакатоны, кемпы и т.д.
Обмен опытом и знаниями, живые дискуссии и неформальное общение — вот цель таких мероприятий, на которые, кстати говоря, может прийти любой разработчик. И представьте себе, такой формат мероприятий пришелся по душе многим в разных городах в Украине! Например, недавно мы провели самый первый .NET Субботник в Виннице, а также очередной .NET Субботник в Харькове, поддержали DOU STARTUP MIXER и Drupal Cafe в Киеве.
11 февраля 2012 в рамках Мобильного Сиклум Субботника пройдет и iPhoneDevCamp 2012, который все так долго ждали! Таким образом, суббота в нашем харьковском офисе будет очень насыщенной. По нашей замечательной традиции, мы открыты к тем, кто хочет выступить. Так, на Мобильный Сиклум Субботник мы пригласили зубров мобильной разработки, отчаянных борцов за чистоту кода и ярых яблочников.
Обмен опытом и знаниями, живые дискуссии и неформальное общение — вот цель таких мероприятий, на которые, кстати говоря, может прийти любой разработчик. И представьте себе, такой формат мероприятий пришелся по душе многим в разных городах в Украине! Например, недавно мы провели самый первый .NET Субботник в Виннице, а также очередной .NET Субботник в Харькове, поддержали DOU STARTUP MIXER и Drupal Cafe в Киеве.
11 февраля 2012 в рамках Мобильного Сиклум Субботника пройдет и iPhoneDevCamp 2012, который все так долго ждали! Таким образом, суббота в нашем харьковском офисе будет очень насыщенной. По нашей замечательной традиции, мы открыты к тем, кто хочет выступить. Так, на Мобильный Сиклум Субботник мы пригласили зубров мобильной разработки, отчаянных борцов за чистоту кода и ярых яблочников.
Perl → Почему в Perl так редко используется IoC, DI и магическая пилюля Kaiten::Container
Думаю многие понимают значение баззвордов Inversion of Control (Ioc) и Dependency Injection (DI). Если не очень, но интересно — на хабре было несколько статей на эту тему, очень познaвательно и доступно изложено.
Методики отличные, но применить их в настоящей жизни как-то не получалось.
Под катом — небольшой обзор плачевного состояния дел в Perl и самостийное «кажется» решение.
Методики отличные, но применить их в настоящей жизни как-то не получалось.
Под катом — небольшой обзор плачевного состояния дел в Perl и самостийное «кажется» решение.
Разработка под Android → Aibolit для android из песочницы
Как же утомителен процесс инициализации UI при разработке android-приложений. Раз за разом приходится писать горы шаблонного кода: findViewbyId, setOnClickListener, getResources().getDrawable, … Возникает естественное желание переложить эту работу на плечи AOP. Беглый поиск готовых решений, адаптированных под android, навел разве что на RoboGuice, о котором уже упоминалось на хабре. Однако библиотека имеет значительный размер (~0.5 mb), что для многих приложений недопустимо много, и к тому же требует наследования ваших классов application и activity от RoboApplication и RoboActivity, чего не всегда хочется делать. Потому и появился Aibolit, легкая (~40kb), простая в использовании и функциональная библиотека, использующая dependency injection для инициализации UI на android.


.NET → IoC, DI, IoC-контейнер — Просто о простом из песочницы
Думаю сейчас слова IoC, DI, IoC-контейнер, как минимум у многих на слуху. Одни этим активно пользуются, другие пытаются понять, что же это за модные веяния.
На данный момент, на эту тему уже довольно сказано, написано, в том числе и на хабре, но как раз из-за обилия информации сложно найти действительно полезный контент. Кроме того, данные понятия часто смешивают и/или путают. Проанализировав множества материалов я решил изложить вам свое видение предмета.
На данный момент, на эту тему уже довольно сказано, написано, в том числе и на хабре, но как раз из-за обилия информации сложно найти действительно полезный контент. Кроме того, данные понятия часто смешивают и/или путают. Проанализировав множества материалов я решил изложить вам свое видение предмета.
.NET → Получение экземпляра класса запроса по сигнатуре его интерфейса
Не так давно на Хабре была опубликована статья (ссылка на топик) моего коллеги AlexanderByndyu, описывающая уход от использования Repository в сторону применения связки QueryFactory + классы запросов Query. При этом в комментариях разгорелся весьма интересный диспут, касающийся целесообразности приведенного в статье решения. Было достаточно много интересных отзывов, среди которых особенно выделялись высказывания о том, что, дескать, QueryFactory не нужен и является лишней обузой, мешающей безболезненному добавлению, изменению и удалению классов запросов. В данной статье я хочу показать подход, который позволяет избавиться от применения QueryFactory, через активное использование IoC контейнера. Данную организацию работы со структурой классов запросов мы использовали в одном из наших недавних проектов, где в качестве IoC использовался Castle.Windsor.
.NET → PostSharp. Отложенная загрузка зависимостей
Кусок кода, представленный ниже, вы наверняка писали не один раз. А что более вероятно – десятки раз. Обычно это пишется, когда необходимо использовать некий репозиторий, который будет предоставлять данные для вашего приложения. Если у вас мало времени, и вы торопитесь, это отличный способ получить что-либо таким образом, что это будет загружено в память только тогда, когда это вам понадобится, но не раньше (например, операция сохранения повлекла за собой обращение к подсистеме сериализации, однако до этого она не была нужна). И ведь на самом деле получается, что этот кусок кода с одной стороны одинаков, а с другой – его приходится писать не один раз. Как правило, я и многие программисты, предпочитаем использовать в данном месте IoC контейнер, чтобы решать задачи такого рода. Однако это не всегда так просто сделать, особенно когда я программирую в рамках отсутствия Dependency Injection в библиотеке, которую я использую (WinForms, WebForms, …). Давайте разберемся, почему решая эту задачу без использования PostSharp, вы потратите гораздо больше времени и проделаете больше работы.
symfony framework → Symfony2 Dependency Injection в разрезе из песочницы
Из статьи можно узнать как стартует и работает приложение Symfony2. Мне бы хотелось продолжить цикл статей про этот современный фреймворк и уделить более пристальное внимание такому компоненту как Dependency Injection (DI — внедрение зависимости) так же известный как Service Container.
Разработка под Android → RoboGuice или «Андроид подсел на инъекции»
Как несложно догадаться, RoboGuice основан на Google Guice.
Сразу оговорюсь, что в качестве перевода слова «injection» я буду использовать слово «инъекция».
Зачем колоться?
Думаю, что у многих читателей сразу возникнет вопрос: «Зачем эти сложности с CDI на мобильной платформе? Наверняка это всё занимает много места и медленно работает.»
Попробую убедить таких читателей в обратном, а именно в том, что CDI на мобильной платформе очень даже жизнеспособен и существенно облегчает жизнь разработчикам.
Python → Антипаттерн settings.py

Хабрапитонерам привет!
Время от времени я сталкиваюсь с паттернами разработки, которые существуют не потому что они хорошо решают какую-то проблему, а потому что так сделано в популярном фреймворке X, следовательно, думают многие — это хорошо.
Сейчас я хочу понегодовать на паттерн «все настройки — в settings.py». Понятно, что популярность он набрал благодаря Django. Я то и дело встречаю в проектах, никак не завязанных на этот фреймворк ту же самую историю: большая кодовая база, маленькие, хорошенькие никак не связанные друг с другом компоненты, и нате вам: все дружно из произвольных мест лезут в волшебный недомодуль settings за своими константами.
Итак, почему же такой подход на мой взгляд отвратителен.