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

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

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

Тема корпоративного календаря – извечный источник холиваров. Многие не понимают, зачем они нужны, но каждый раз под новый год тема поднимается в новостях и разгораются ожесточенные бои. А мы сняли и не пожалели! Хотя это было очень тяжело.

Android-проекты бывают большими. Иногда действительно большими. Один из наших проектов — новостное приложение, которое разрабатывается одновременно под две альтернативные платформы: Android и FireOS, что от Amazon. Это позволяет расширить круг читателей новостей, ведь пользователи читалок Kindle Fire любят почитать:). Однако, это же накладывает обязательство считаться с особенностями каждой из платформ. Например, если в Android вы используете GCM для push-сообщений, то в FireOS вы должны использовать для этого Amazon AWS. Аналогично и для систем покупок внутри приложения: Google in-app billing vs. In-App Purchasing. Но большой размер проекта != большой размер приложения!

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

Что готовим?

Введение

Недавно у нас закончился крупный проект с довольно сложным продвинутым UI. Не вдаваясь в детали, скажем, что внутри браузера было реализовано что-то вроде рабочего стола (desktop) с окнами, перекрытиями и всем, чем полагается. Разумеется, проблемы с утечками памяти не обошли нас стороной. Признаемся честно, до поры до времени сосредоточились на получении бизнес-результата. Когда дошли руки до утечек памяти, то обнаружилось, что окна браузера занимают гигабайты оперативной памяти. Мы классифицировали ошибки и в общем виде выработали подход к их устранению. Этим подходом и хотим поделиться с вами.

По теме утечек памяти в клиентских приложениях написано уже немало. Изначально основную проблему представляли из себя браузеры IE8 и младших версий (смотрите, например:
http://habrahabr.ru/post/141451/
http://habrahabr.ru/post/146784/
https://learn.javascript.ru/memory-leaks).
Но и теперь, когда можно сказать, что IE8 в прошлом, проблемы остаются. Даже применение такого языка как TypeScript не гарантирует их отсутствия. А с учетом того что front-end в web-приложениях становится все сложнее, актуальность проблемы только возрастает.

Из диалога двух программистов:
— Кажется, у нас дыра в безопасности!
— Слава Богу, хоть что-то у нас в безопасности…

1. Введение

Пару лет назад мы уже затрагивали тему безопасности в веб-приложениях. Тогда в рамках исследовательских работ был реализован собственный Service Provider для интеграции с продуктом Shibboleth по протоколу SAML 2.0.

В сегодняшней статье речь снова пойдет о безопасности веб-приложений. Мы сделаем небольшой обзор продукта KeyCloak (доселе оставленного без внимания сообществом Habr).



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

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



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

Привет хабр!

Мы любим разрабатывать мобильные приложения, отличающиеся от своих собратьев как по функциям, так и по пользовательскому интерфейсу. В прошлый раз мы рассказали о клиент-серверном взаимодействии в одном из наших приложений, а в этот раз поделимся реализацией его UI фичи с помощью написанного с нуля LayoutManager. Думаем, что статья будет полезна не только начинающим андроид-разработчикам, но и более продвинутым специалистам.

Нашему заказчику, одному из крупнейших мировых издательств, потребовалось увеличить производительность приложения для публикации видео новостей в связи с возросшим объемом трафика. Пользователи приложения — редакторы media-ресурсов. В день через него проходит порядка 200 новостных роликов, средний размер каждого из них ~ 500 мб, итого около 100 Гб свежих новостей в сутки.

Сегодня мы поделимся опытом, как CloudFront и S3 помогли нам построить высоконагруженную и устойчивую систему обработки контента.



Надеемся, наш опыт заинтересует разработчиков/проектировщиков систем по хранению и обработке медиаконтента (видео, аудио, изображения) и технических специалистов, активно использующим сервисы AWS.

Старо как мир…

Люди всегда стремятся быть в курсе последних событий. Благодаря этому стремлению возникло много media, которым необходимо собственное мобильное приложение для доставки контента своим читателям. Так в магазинах появилось великое множество новостных приложений. Сотни приложений для чтения новостей, газет и журналов.

Когда разработка мобильных приложений в компании переходит на промышленные рельсы, неизменно всплывает вопрос об автоматической сборке. Continuous Integration — это то, что является неотъемлемой частью процесса. Итог этого процесса — сборки для тестирования на устройствах компании для OTA распространения заказчикам и удаленным тестировщикам.

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

Итак, эта статья о том, как реализовать копирование сертификатов и профилей для iOS сборок и свойств, и ключей для Android сборок на все слейвы дженкинса в рамках Continuous Integration. Такая автоматизация экономит время и помогает избежать ошибок. Статья будет интересна разработчикам мобильных приложений и тем, кто администрирует Jenkins.

Поехали!

Предыстория

Проект начинался как портал на основе SP 2007, а позже на основе 2010 SP. Изначально все пользователи были в Active Directory. Был только один тип пользователей. Связи между ними были достаточно простыми. Появлялись новые типы пользователей, которые сложным образом становились связаны друг с другом. Также постепенно проект обрастал различными связанными подсистемами, часть из которых работала внутри портала, часть вне его. И это все усложняло схему авторизации.

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

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

Привет, Хабр.

Сегодня мы поговорим о том, как здорово читать в темноте. В детстве нам всем мамы запрещали это делать, но теперь есть планшеты! В отличие от бумажных книг, на них не надо светить фонариком, они сами за вас все сделают. И именно мы их этому обучаем. Однако обо всем по порядку.

Всем привет!

Нам понравилось писать о жизни нашей компании. Надеемся, вам тоже интересно читать о нас и наших событиях. На этот раз расскажем о том, как мы готовились и участвовали в Днях карьеры, которые прошли в НГУ 8, 9 и 10 апреля. Какой опыт получили и что вынесли для себя на будущее.

Вот и закончилось наше путешествие на загадочный остров Пасхи. Трудно уместить в одну статью все яркие впечатления: были и бюрократические преграды, и диковинные фрукты, и киты, и акулы. Но давайте все по порядку.

Подготовка и сборка катамарана – середина Ноября

Началось все с короткого телефонного разговора с моим другом Димой Трубициным.
Дима: — “Привет, а поплыли через Тихий океан, примерно через 3 месяца?!”
Я: — “Океан?? Да поплыли!!! Давай вечерком встретимся, обсудим...”

Введение

Жизнь в современном мире развивается динамично, технологии появляются и умирают, а вместе с ними устаревают и наши навыки. 20 лет назад нужно было помнить функции Windows API, сейчас многие специалисты даже не знают, что это такое, и это не мешает им работать. На первый план вышли другие технологии, требующие совершенно другого опыта. Например, Java Script, HTML 5, CSS. Через 10 лет на смену, скорее всего, придут другие технологии и инструменты, другой способ мышления. Поэтому процесс обучения в современном меняющемся мире становится непрерывным и все более интенсивным. Это must have любого современного специалиста.

Всем привет!

У хабраблога EastBanc Technologies юбилей — 2 года! Это были горячие годы, мы развлекали вас, как могли, и, считаем, заработали право на статью, посвященную себе любимым. Материал предполагается пригодным к прочтению молодыми и не очень соискателями, заказчиками в поисках ИТ-подрядчика, желающими подробно узнать подноготную наших процессов, и просто для всех, кто интересуется развитием ИТ-компаний в одной маленькой силиконовой тайге (т.к. мы во многом типичны для своего сегмента, пытливый читатель сделает много интересных выводов для себя).
В новосибирском Академгородке несколько десятков ИТ-компаний. Среди них есть гиганты типа ЦФТ и 2ГИС, есть небольшие оффшорные конторки с десяток человек, а есть крепкая середина стремительно развивающихся компаний со штатом 50-100 человек, к коей относимся и мы. Чтобы не плодить многа букав, большой экскурс в историю Академа и его ИТ-компаний делать не будем, но скажем, что здесь сотрудница EastBanc Technologies занятно рассуждает об особенностях академовской ИТ-тусовки.

Поздравляю, Вы второй человек,
взломавший сегодня сейф Ван дер Водэ.
Таким образом, мистер Оушен,
Вы вступили в длинные ряды тех,
кто приложил титанические усилия,
чтобы добиться цели
и, в итоге, стать только вторым.
Вам неизвестны имена этих людей,
потому что они покрыты забвением.
Вам знакомо слово «забвение»?
Это означает, что о Вас
забывают все и навсегда".
Мистер Ночной Лис (к/ф «12 друзей Оушена»)

Привет, читатель Хабра!
Представь, что ты портной и ты сшил человеку костюм на заказ. Человек рассказал тебе, как он хочет выглядеть в этом костюме, куда в нем ходить и сколько примерно готов за него заплатить. Ты его внимательно выслушал, снял все мерки, с любовью шил этот прекрасный костюм мечты, используя все современные модные тренды. Соблюдал все пожелания своего дорогого клиента. И вот настал звездный час: костюм готов, человек его надел, и он счастлив, разглядывая себя в зеркале. Вечером он позвонил и сказал, что жене и гостям на его юбилее он тоже понравился. Но один из гостей сказал, что у этого костюма есть недостатки: он не желтого цвета, в нем нельзя тушить пожар, любой может украсть этот костюм, и (оба на!) – у него нет капюшона и в карман нельзя положить молоток или пилу.

Введение

Мы хотим поделиться опытом небольшого, но полезного усовершенствования функционала работы с бизнес-процессами различных типов в Microsoft Dynamics CRM 2013. Наш подход не претендует на гениальность, но он позволил решить некоторые проблемы, которые мы опишем ниже, а также выполнить пожелания Заказчика. Может быть, кейс будет полезен кому-то в своей работе.

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