С развитием смартфонов в последние годы было разработано много инструментов, чтобы упростить жизнь разработчикам, обеспечив их максимальной производительностью и качеством. Занимать лидирующие позиций в App Store сегодня не простое задание. А научить ваше приложение масштабироваться еще сложнее. Когда приложением пользуются миллионы пользователей, вы должны следить за приложением и при необходимости выполнять все операции моментально. Поэтому одной из проблем, с которой сталкиваются многие разработчики, является Database. Она действительно вызывает сильную головную боль для каждого из нас, и я думаю, что сегодня у вас есть только два варианта: SQLite и Core Data. Я был большим поклонником Core Data и его способностью работать с записями и сохраняющимися данными, но я понял, что впустую трачу много времени, работая с ним при разработке приложений. Недавно, я столкнулся с Realm, новой лучшей заменой SQLite и Core Data.

Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

В наши дни сложные Javascript-приложения можно увидеть повсюду. Со временем они становятся все сложнее и уже неприемлемо просто писать цепочку callback-функций на jQuery. Javascript-программисты постепенно узнают то, что обычные разработчики знали уже несколько десятилетий. Организация и эффективность может сыграть важную роль при разработке. Таким образом, такие MVC-фреймворки на Javascript, как Backbone, Knockout и Ember появились для того, чтобы заполнить пустоту между начинающими, средними и опытными разработчиками. Они предлагают разные возможности и функционал, который подойдет разным людям, в зависимости от их потребностей.

В последнее время в вебе идет тенденция к «утончению» сервера и «утолщению» клиента. С каждым днем вакансий Full-stack разработчиков становится все больше, а чистого бэкенда все меньше. Последние 2 года я работаю разработчиком Ruby on Rails и в скором будущем без работы остаться не хотелось бы. Поэтому я начал рассматривать варианты изучения клиентского фреймворка.

Вариантов было несколько:

• Meteor
• Angular
• Ember

Но остаться должен только один. Meteor предлагает интересную концепцию – общий код клиента и сервера, но он пока сыроват и мне не хотелось оставлять прекрасный язык Ruby. Поэтому Метеор отпал. Так как Ember был похож на Rails (магия, convention over configuration), то был выбран именно он. Помимо этого, очень симпатично выглядел шаблонизатор Handlebars по сравнению с директивами Angular.

Выбор сделан. Вот тут и начались проблемы.

Ember.js сложный в обучении. Хотя даже не так. Концепты Ember.js сложны в освоении и понимании. Мне кажется, что любой курс обучения Ember.js должен начинаться с этих слов.

Я разработчик, работающий с Ruby on Rails (до этого я программировал в .NET и Python). Для меня было довольно проблематично понять магию, заставляющую Ember.js работать. Иногда я общаюсь с другими начинающими разработчиками, вставшими (или пытающимися встать) на путь Ember.js — все их проблемы начинаются из-за того, что они не понимают, как устроен данный фреймворк.

Да, с одной стороны есть официальная документация в которой детально описаны все аспекты данного фреймворка. Но ей не хватает концепции; для начинающего разработчика это просто осколки информации разбросанные случайным способом. Из документации, например, можно узнать что у нас есть в арсенале контроллеры, модели и виды (controller, model, view). Но для того что-бы узнать за что они отвечают и как работают начинающему разработчику предлагают сначала наступить на грабли пару десятков раз. Плюс в нагрузку к контроллерам, моделям и видам Ember.js нам дает целый взвод разношерстых объектов типа компонентов, шаблонов, маршрутизатора и путей (component, template, router, route).

Доброго времени суток!

История данного текста такова. Ребёнку задали задание запрограммировать btree. Я иногда ему помогаю. Решил, что это тривиально. Но попытки наскоком решить задачу успехом не увенчались. Поиски сколько-нибудь разумного описания и/или кода также были тщетны. Зачёт сын давно сдал, но мой параноидальный характер заставил меня решить задачу. Может кому-нибудь пригодится.

Недавно нам нужно было сделать простое приложение для Google Drive. Приложение должно было формировать список пользователей, на которых расшарены документы в указанной папке с возможностью редактирования. Задача, в принципе, простая, поэтому недолго думая развернул болванку проекта на angularJS и начал кодить. Гугл, подумал я, это же большая компания, у него должен быть понятный и стабильный API и я сделаю это за пару дней.

Я был слишком наивен.

У меня достаточно часто появляется задача получить данные от стороннего сайта, при этом далеко не всегда этот сайт предоставляет возможность удобно получить эти данные через API. Единственное решение в таком случае — парсить html содержимое страниц. Когда-то я писал регэкспы, потом появились библиотеки, позволяющие получить нужное содержимое по css-селектору, а сейчас и это кажется сложной задачей, которую хотелось бы упростить.

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

Привет Хабр!

Фреймворк Laravel быстро набирает популярность и уже обрел большую армию фанатов. В этой статье я опишу разработку простого пакета для Laravel, а так же публикацию созданного нами пакета на сайте packagist.org для того, чтобы добавлять наш пакет в проект одной строчкой в composer.json.

Итак, о чем все это

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

В итоге мы получим это.

Предоставляемая информация верна для любой платежной системы. В том числе для систем DSS PCI, простого эквайринга (прием платежей банковскими картами), виртуальных платежных систем (яндекс.деньги, вебмани, робокасса и др).

Обсуждение статьи «Скомпрометированы транзакции плательщиков RBK Money» показало критичную безграмотность некоторых комментирующих. Обычно свет знаний у невежества вызывает страх и раздражение, что интересно отследить по комментариям. Я попытался дать разъяснения там в обсуждениях, за что и поплатился.

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

Было время, достаточно недавно, когда PHP и его сообщество ненавидели. Главная шутка была про то, насколько ужасен PHP.

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

Но позже, на удивление, вещи начали меняться — и достаточно быстро. Как будто пока ведьма помешивала горшочек, из ниоткуда начали появляться новаторские проекты. Наверно, самый заметный проект был Composer: наиболее полный менеджер зависимостей для PHP (как Bundler для Ruby или NPM для Node.js). В прошлом PHP разработчики были вынуждены совладать с PEAR (что было страшным сном, на самом деле), сейчас, благодаря Composer, они могут просто обновить JSON файл, и немедленно подтянуть все нужные зависимости. Здесь — профайлер, там — фреймворк для тестирования. Это занимает секунды.

Несколько месяцев назад наша компания решила выбрать корпоративный PHP-фреймворк, который мы бы использовали для большинства проектов. До этого у нас был целый зоопарк: Symfony, Zend Framework, Yii — кому что больше нравилось. После рассмотрения популярных фреймворков мы решили попробовать Laravel. Результатом нескольких обучающих дней стал конспект, в котором строится простенькое приложение, но так как подробный туториал уже присутствует на хабре, то я решил написать только о четырёх инструментах, которые будут полезны при разработке и о которых почему-то не упоминают в туториалах:

1. Laravel IDE Helper Generator
2. Laravel 4 Debugbar
3. Faker
4. Homestead