Прошлой осенью, вернувшись из отпуска, я обнаружил, что Дехана, наш Product Manager в UserVoice, заменила мой любимый «Roadmap» в Google Docs на доску Trello.

Моя первоначальная реакция на такие перемены была отнюдь не положительной. Проблема заключалась не в самом Trello, а в том, как мы им пользовались. Trello – это ОЧЕНЬ открытый проект. Не существует единственного “правильного” способа работы в Trello, поэтому, чтобы чувствовать себя в нем как дома, вам потребуется время для настройки «под себя».

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

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Некоторое время назад я прочитал интересный пост, посвященный полезным фрэймворкам и библиотекам для разработки под iOS. С вашего позволения и согласия Coder89 представляю «Полезные штуки для iOS-разработчика часть вторая».

На хабре в прошлом месяце была опубликована статья Конкурс ВК: Мессенджер для Android. Как это было!, в которой автор поделился своими мыслями о конкурсе и опубликовал список ресурсов и статей, которые помогли ему в создании приложения. Так как в последнее время я начал изучать разработку под iOS, то у меня скопилось некоторое количество ссылок, которые могут быть полезны для начинающих. Поэтому я последую его примеру и сделаю то же самое, только для своей платформы. Надеюсь, кому-нибудь они окажутся полезны и сэкономят немного времени.

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

Но мы меня простим и сделаем вид, что это цикл статей ;).

Итак. В процессе разработки большинства мобильных приложений возникает необходимость локализации. И в этот неловкий момент может возникнуть ряд правомерных вопросов: на какие языки переводить, что именно переводить, куда обращаться, на какие мелочи стоит обратить внимание.

Попробуем ответить на каждый из этих вопросов по отдельности.

На Хабре в свое время было несколько статей «Очень много полезных штук для AS3». Автор попытался собрать ссылки на самые полезные и интересные библиотеки. И т.к. в последнее время я разрабатываю под iOS, решил последовать его примеру и сделать то же самое, но для своей платформы. Описания почти прикладывать не буду, все есть на страничках проектов.

Мне бы хотелось рассказать об интересном опыте, приобретенном в процессе разработки бесплатного пока что конвертера валют, моего второго приложения в категории Finance. Первое, Money iQ, было написано во время работы в небольшой компании и даже успело побывать на 1м месте российского App Store. Небольшую dev story о создании приложения я опубликую чуть позже и в другом блоге, если будет интересно, а в этой статье мне хотелось бы остановиться на такой проблеме как мгновенное изменение языка внутри приложения.

Собственно, проблема.

Наверное, многим приходилось сталкиваться с мультиязычными приложениями. Я говорю не только о приложениях под iOS, а вообще о приложениях, поддерживающих несколько языков. Во из них в сеттингах есть пункт «Language/Язык/Idioma», позволяющий установить язык, нужный пользователю.

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

В последнее время у меня собралось много отмеченных репозиториев на GitHub со всякими разными, полезными и не очень кусками кода. Решил их как структурировать для себя, так и поделиться с общественностью.

Не первое десятилетие продолжается спор между архитекторами настольных приложений на предмет, какой же подход, statefull или stateless, более предпочтителен, и в каких случаях.
Сейчас мы наблюдаем определенный тренд сдачи позиций апологетами statefull. Не в последнюю очередь в этом виноват даже не столько web, сколько банальный HTTP, вполне заслуженно занявший нишу «универсального протокола для всего». Причем возможность передачи Cookie весьма слабо влияет на его насквозь stateless природу.

Но что HTTP может нам предложить, в случае необходимости создания интерактивного приложения на вебе? Для того чтобы достичь «реактивности» оффлайнового statefull приложения, классического варианта с постоянным опросом состояния сервера короткими AJAX запросами по таймеру явно недостаточно. HTML5 несет нам технологию WebSockets, призванную решить эту проблему. Но ведь нужно чтобы работало «здесь и сейчас» на всех браузерах выпущенных в текущем тысячелетии.

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

Итак, знакомьтесь. Клуб интеллектуальных игр «Трельяж»
trellis-club.com