На Хабре уже было несколько статей об общих принципах написания кода под Pebble. Для программирования используется язык C, а сам процесс разработки происходит в браузере, при этом компиляция происходит на удаленных серверах, и изменить ее параметры нет возможности, разве что установить Ubuntu и инсталлировать необходимые инструменты для офлайн-компиляции. Но даже такой ход не избавит основного ограничения – на устройстве доступно только 24 Кб оперативной памяти, которая используется и для скомпилированного кода, то есть действительно динамической памяти остается 5-10 Кб. И если для простых программ, которые используются как тонкие клиенты или дополнительные датчики для телефона, этого с головой достаточно, то для написания самодостаточной более или менее сложной игры, которой не нужен смартфон, этого откровенно мало. Вот здесь и понадобится оптимизация кода под размер.

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

Простой поиск на stackoverflow.com показывает, что тема получения сообщения ACTION_BOOT_COMPLETED остается актуальной и по сей день. Как видно, многие новички сталкиваются с проблемой: они не получают в своих приложениях сообщение ACTION_BOOT_COMPLETED. В этой статья я попробую резюмировать данные из официальной документации, опыт многих разработчиков из stackoverflow.com, а также свой опыт. Итак, как же победить этого «коварного врага» под названием «ACTION_BOOT_COMPLETED»?

Недавно, на хакатоне от Petamelon нам в руки попал датасет с ~6 000 000 резюме с НН. Там, естественно, не было никаких персональных данных и контактов, но было много других интересных вещей: ожидаемая зарплата, возраст, пол, примерный адрес, образование и индустрии, в которых человек ищет работу. Было решено попробовать использовать эти данные в нашем проекте про выбор школ. Идея заключалась в том, чтобы определить в каких индустриях работают выпускники школ и сколько примерно зарабатывают. Но я, конечно, не удержался и построил кучу других бесполезных, но прикольных таблиц и графиков.

Распределение резюме по возрасту имеет интересную форму и как будто разделено на две части: до окончания института и после:


В Москве с возрастом ожидаемая зарплата выходит на плато в ~50 000 рублей:

В этой статье хотелось бы поделиться одним из способов простого и удобного интеграционного тестирования http-сервиса, написанного на Go. Интеграционные тесты бывает непросто создавать так, чтобы обходиться без сложных скриптов, но на помощь нам придет Docker, пакет из стандартной библиотеки httptest и билд-теги. Для примера мы будем использовать MySQL базу данных с миграциями, управляемыми пакетом goose. Финальной целью является получить простое и удобное кроссплатформенное интеграционное тестирование простым запуском команды go test, будь это рабочий ноутбук или Continuous Integration сервер.

Первое впечатление об МБЛТ Дев 2015… пока еще не забыл все.

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

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

Некоторые могут возразить, что следование гайдам может убить творчество, и в итоге все приложения будут выглядеть одинаково. С точки зрения UX, я тут вижу другую проблему. Может казаться, что применение лучших шаблонов, которые используют Google / Facebook / Instagram / [вставить любимое приложение], всегда является отличным решением. Что они ставят себе такие же задачи, что и вы. Вот несколько шаблонов, которые считаются (или считались) лучшими, но в то же время не такие уж они и хорошие, какими кажутся на первый взгляд.

Компания IBM уже много лет ведет свой блог на Хабрахабре. Около года назад мы открыли блог и на Geektmes. И на Хабрахабре, и на GT мы стараемся максимально интересно рассказывать о своих продуктах, сервисах, достижениях. Хотелось бы верить, что наши публикации интересны вам, а возможно, некоторые новости или статьи представляют для наших читателей и практическую пользу.

Для того, чтобы обеспечить более полное информационное взаимодействие с Хабрахабром, мы решили открыть еще один блог, на этот раз для нашей облачной платформы IBM Bluemix.

Подходит к концу разработка моего первого приложения под Apple TV, и я решил поделиться собранной информацией об этой платформе.

tvOS поддерживает два типа приложений: TVML и традиционные.

Традиционные приложения — практически то же самое, что и приложения под iOS (UIKit, Storyboard);
TVML — фреймворк для создания клиент-серверных приложений. Вся логика, дизайн и данные находятся на удаленном сервере.

Одним из краеугольных камней в Material design являются осмысленные движения между экранами. Lollipop предоставляет поддержку этих анимаций в форме фреймворка переходов между Activity и Fragment. Поскольку статей по данной теме не так много, я решил написать свою собственную!

Наш конечный продукт будет достаточно прост. Мы будем делать приложение-галерею с котиками. При нажатии на изображение будет открываться экран с подробностями. Благодаря фреймворку переход из сетки изображений в окно с подробностями будет сопровождаться анимацией.

Если вы желаете увидеть, что получилось — готовое приложение находится на GitHub.

Все уже много раз слышали про конкурс по машинному обучению от Билайн и даже читали статьи (раз, два). Теперь конкурс закончился, и так вышло, что первое место досталось мне. И хотя от предыдущих участников меня и отделяли всего сотые доли процента, я все же хотел бы рассказать, что же такого особенного сделал. На самом деле — ничего невероятного.

Московское метро меняется. Желающий представить себе схему, скажем, 1945 года без проблем соберёт данные из открытых источников; остаётся вопрос с представлением результата, — не на круговой диаграмме же его показывать. В статье я расскажу об основных шагах в создании proof-of-concept сервиса, позволяющего показать схему метро, например, на 1 мая 74 года (слева) или станции с глубиной заложения больше 30 метров (справа).

Как-то увидев очередную статью на Хабре, посвященную для меня совершенно новому и неизведанному языку Go, решил попробовать, что это за зверь и с чем его едят (В основном, конечно, понравился логотип). Конечно, язык имеет много возможностей и достаточно удобен. Но что меня сразу удивило, это отличный от C-подобных языков принцип объявления переменных, а именно тип переменных описывается справа от имени переменной. У меня как человека, практически выросшего на С, это вызывало удивление. Потом я конечно вспомнил Pascal, что там тоже тип переменной был справа. Заинтересовавшись этим вопросом, я попытался разобраться, почему используется тот или иной синтаксис описания типа переменных в этих 2-х языках.

На презентации Google I/O 15, компания Google представила новую версию библиотеки поддержки которая реализует несколько компонентов, сильно связанных со спецификациями Material Design, среди этих компонентов вы можете найти новые типы ViewGroup такие как AppbarLayout, CollapsingToolbarLayout и CoordinatorLayout.

При правильном комбинировании и настройке данные Viewgroup могут быть очень мощным инструментом, по этому я решил написать статью с некоторыми настройками и советами.

В последнее (и не только последнее) время ломают много копий по поводу неудобства обработки ошибок в Go.

Суть претензий сводится к тому, что прямое использование:

customVar, err := call()
if err != nil {
	doSomething(err)
	return err
}

на больших количествах повторений гораздо менее удобно, чем классическое:

try {
	String customVar = call();
} catch (BadException e) {
	doSomething(e);
	sendException();
}

Можно долго спорить как по самому предмету претензий, так и по поводу обходных манёвров, однако же логика в «пакетном» подходе действительно имеется.

В связи с чем у меня и возникла мысль по поводу обработки исключений без особого отхода от «Go-way». Вариант не рабочий — всего лишь моя фантазия.

Выглядело бы это так:

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

В общем, стоит начать с того, что в моей компании имеется отдел ios разработки в составе > 10 человек, которые работают над пачкой приложений. Для автоматизации рутинной работы нам пришлось развернуть CI сервер (пока самописный, ввиду особых исторических причин (ну как у всех), планируется миграция на jenkins). К рутинным вещам я отношу — сборку проектов, запуск тестов (если, конечно, вы их пишете), создание ипашек для тестеров и для выкладки в app store. В общем, хотелось чтобы по нажатию кнопочки или по хуку в гите всё это начинало работать. Пока у нас всё работает по нажатию кнопки разработчиком, про гит пока только в планах. В данной статье я только затрону тему компиляции проекта и упаковку его в ipa файла. Функционал запуска проектов на девайсах на стороне CI сервера еще находится в стадии разработки, а вот сам процесс упаковки уже давно в «бою», может кому пригодиться.

Что планируем:

• соберем приложение и запустим на симуляторе
• соберем ipa и запустим на реальном девайсе
• соберем ipa для выкладки на маркет
• немного подэбажим ошибки сборки

От переводчика: данная статья написана Manuel Kiessling в сентябре 2012 года, как реализация статьи Дядюшки Боба о чистой архитектуре с учетом Go-специфики.



Перед этой статьей я перевел ее прообраз — смотреть здесь. Поскольку в рамках этой статьи будет активно использоваться описанное в статье Дядюшки Боба, то лучше начать с нее… если Вы, конечно, ее еще не читали.

В отличие от первой статьи, в названии внутреннего слоя здесь фигурирует Domain вместо Entity (Сущность) и при переводе я так и оставил этот термин, чтобы избежать путаницы, поскольку он фигурирует так же и в исходном коде примеров. Так же я перевел Domain как Домен, поскольку на мой взгляд этот термин тут имеет более широкую смысловую нагрузку.

В данной части будет описана общая концепция и работа с внутренним слоем.

(Перевод статьи из официального блога Go)

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

if err != nil {
    return err
}

появляется слишком часто. Недавно мы просканировали все open-source проекты, которые мы только смогли найти и увидели, что этот сниппет появляется лишь раз на страницу или две, гораздо реже, чем многие могли бы подумать. И всё же, если впечатление того, что вы должны всегда писать

 if err != nil

остается, значит, очевидно, что-то тут не так, и мишенью оказывается сам Go.

Это неверно, это вводит в заблуждение и это легко исправить. Наверное происходит следующее — программист, знакомясь с Go, задаёт вопрос — «Как я должен обрабатывать ошибки?», заучивает этот паттерн и тут и останавливается. В других языках, это может быть блок try-catch или другой механизм обработки ошибок. Соответственно, думает программист, там где я бы использовал try-catch в моём старом языке, в Go я просто напечатаю if err != nil. Со временем, в Go коде накапливается много таких сниппетов, и результат выглядит неуклюже.

Но вне зависимости от того, как это объясняется на самом деле, очевиден тот факт, что эти Go программисты упускают фундаментальную идею ошибок: Ошибки это значения.

В недавнем посте с критикой Go, который был выдан за перевод, пользователь tucnak, помимо избыточной фамильярности в адрес Роба Пайка, поднял несколько интересных моментов языка. Поскольку формат статьи предполагал, увы, не желание разобраться в теме, а разжечь холивары, предлагаю в этой статье пройтись по озвученным «проблемам» и понять, о чём же речь на самом деле, и что же заставляет современные компании выбирать Go.