Усилия и деньги, вкладываемые в продвижение языка Go, часто приносят пользу и другим разработчикам. В конце прошлого года на сайте gopheracademy была опубликована очень удачная статья о семантическом версионировании. Том самом, которое используется в npm, начинается с домика ^ и все ломает. Под катом спрятан перевод, который поможет вам быстро осмотреть сад граблей версионирования и как сейчас принято им пользоваться. И немного примеров на Go. Передаем слово автору!

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

Привет, Хабр. Меня зовут Максим, я iOS-разработчик в компании FINCH. Сегодня я покажу вам некоторые практики использования функционального программирования, которые мы наработали у себя в отделе.

Используя курсоры, вы сможете порционно получить из БД и обработать большое количество данных, не расходуя при этом память приложения. Уверен, перед каждым веб-разработчиком хотя бы раз вставала подобная задача, передо мной тоже — и не раз. В этой статье я расскажу, в каких задачах курсоры могут быть полезны, и дам готовый код по работе с ними из PHP + Doctrine на примере PostrgeSQL.

Привет, меня зовут Илья. Я — iOS разработчик в компании Tinkoff.ru. В этой статье я сделаю краткий обзор основных изменений в Swift 5. Данные изменения описаны в release notes. Для тех, кто еще не ознакомился, добро пожаловать под кат!

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

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

1. Исключения — это гибкий, расширяемый метод обработки ошибок;
2. Это стандартизованный механизм – человеку, не работавшему с вашим кодом, не нужно будет читать мануал, чтобы понять, как обрабатывать ошибки. Ему достаточно знать, как работают исключения;
3. С исключениями гораздо проще находить источник ошибок, так как всегда есть стек вызовов (trace).

Сразу скажу, что в этой статье я не открываю Америку. Описаны стандартные принципы работы с исключениями плюс некоторые особенности, налагаемые PHP. Полезно будет почитать новичкам, хотя может быть и опытные разработчики найдут что-нибудь новое для себя.

Бизнес в России учится делать не только скучные проекты по автоматизации бизнес-процессов, но и создавать IT-решения, способные помочь в борьбе с конкурентами. Например, проекты по предсказанию спроса, real-time offer management, оптимизации логистики, микротаргетированию. Такие сложные задачи отличаются от типовых внедрений CRM или выбора CMS. Надо иначе искать разработчиков, иначе мотивировать, думать об IT-архитектуре и методологии управления.

Шпаргалка — навигация по темам, которые стоит знать руководителю компании и топ-менеджеру, чтобы грамотно реализовать IT-проекты нового уровня сложности. По каждой теме будет много ссылок на статьи, интервью, обзоры и видео.

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

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

Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.

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

CodeX крутые ребята, которые базируются в Университете ИТМО. На базе этого университета студенты и выпускники создают интересные и полезные проекты: Hawk.so, Capella, AR-tester и другие.

Один проект очень помог нашему бизнесу. Редактор Editor.js сохраняющий исходный код в JSON.

Laravel имеет мощный IoC-контейнер, но, к сожалению, официальная документация Laravel не описывает все его возможности. Я решил изучить его и задокументировать для собственного использования.

Примеры в данной статье основаны на Laravel 5.4.26, другие версии могут отличаться.

Введение в Dependency Injection

Я не буду объяснять, что такое DI и IoC в этой статье — если вы не знакомы с этими принципами, вы можете прочитать статью "What is Dependency Injection?" от Fabien Potencier (создателя фреймворка Symfony).

В первой части рассказа по мотивам выступления Дмитрия Стогова из Zend Technologies на HighLoad++ мы разбирались во внутреннем устройстве PHP. Детально и из первых уст узнали, какие изменениях в базовых структурах данных позволили ускорить PHP 7 более чем в два раза. На этом можно было бы и остановиться, но уже в версии 7.1 разработчики пошли существенно дальше, так как идей по оптимизации у них было еще много.

Накопленный опыт работы над JIT до семёрки теперь можно интерпретировать, смотря на результаты в 7.0 без JIT и на результаты HHVM с JIT. В PHP 7.1 было решено c JIT не работать, а опять обратиться к интерпретатору. Если раньше оптимизации касались интрепретатора, то в этой статье посмотрим на оптимизацию байт-кода, с использованием вывода типов, который реализовали для нашего JIT.



Под катом Дмитрий Стогов покажет, как это все работает, на простом примере.

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

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

Однако, в реальных проектах, если репозитории таки было решено использовать, в них часто добавляются методы для выборок записей:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Всем привет! Меня зовут Дмитрий Павлов, в компании Align Technology мы с коллегами занимаемся разработкой Web API для взаимодействия внутренних систем и интеграции нашей компании со сторонними вендорами. Об идеях создания API для веба, а точнее RESTful API я хотел бы рассказать в этой статье.

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

Введение

Одним из достоинств Angular является широкий набор инструментов “из коробки”, которые позволяют быстро создавать формы любой сложности.

В Angular существует 2 подхода к созданию форм:

Template-driven forms — подход, в котором ключевую роль играет шаблон компонента, и все описание производится в нем — этот подход является развитием работы с формами в AngularJS;

Reactive forms — новый подход для работы с формами в реактивном стиле. Описание формы происходит в компоненте в виде дерева объектов, после чего это дерево связывается с шаблоном. Все манипуляции (проверка валидности, подписка на изменение значения и прочее) производятся в компоненте, что делает работу более гибкой, удобной и предсказуемой.

В данной статье мы разберем, как начать работать с reactive forms на примере простой формы с валидацией и сообщениями об ошибках. Код примера.

Реактивные формы. Часть 2.

Привет, Хабр! Представляю вашему вниманию перевод статьи Creating UIViews Constraints Programmatically Using PureLayout автора Aly Yaka.



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

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

Я регулярно вижу статьи в стиле "как использовать шаблон Репозиторий с Eloquent" (одна такая попала в недавний PHP-дайджест). Обычное содержание их: давайте создадим интерфейс PostRepositoryInterface, EloquentPostRepository класс, красиво их забиндим в контейнере зависимостей и будем использовать вместо стандартных элоквентовских методов save и find.

Зачем этот шаблон нужен иногда вовсе не пишут ("Это же шаблон! Разве не достаточно?"), иногда что-то пишут про возможную смену базы данных (очень частое явление в каждом проекте), а также про тестирование и моки-стабы. Пользу от введения такого шаблона в обычный Laravel проект в таких статьях сложно уловить.

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

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



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

Сейчас практически 100% приложений используют работу с сетью, поэтому вопрос организации и использования сетевого слоя встает перед каждым. Есть два основных подхода к решению этой проблемы, это либо использование сторонних библиотек, либо собственная реализация сетевого слоя. В данной статье мы рассмотрим именно второй вариант, причем попробуем реализовать сетевой слой с использованием всех последних возможностей языка, применяя протоколы и перечисления. Это избавит проект от лишних зависимостей в виде дополнительных библиотек. Те, кто хоть раз видел Moya, сразу узнают множество схожих деталей в реализации и использовании, так оно и есть, только в этот раз мы все сделаем своими руками, не трогая Moya и Alamofire.