JIRA широко используется в Mail.Ru Group. Сейчас мы применяем эту систему не только для управления проектами и отслеживания ошибок, но и для организации самых разнообразных операционных процессов — рекрутинга, согласования договоров, командировок и так далее. Это с одной стороны очень удобно, так как многие бизнес-процессы отлично ложатся на модель Issue в JIRA. Однако часто требуются также и специфичные функции, реализуемые с помощью специально написанных нами плагинов.

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

Сейчас многие JIRA-плагины сторонних разработчиков не могут похвастаться качественным интерфейсом. Это касается даже некоторых платных плагинов. Однако все средства для быстрой разработки удобных и красивых интерфейсов есть. В статье рассматривается одно из них — AUI Framework (Atlassian User Interface Framework).

Предполагается, что читатель знаком с тем, как можно сделать плагин в принципе. Если нет, то об этом можно почитать, например, здесь.

Помни: сила рыцаря-джедая — это сила Вселенной.
Но помни: гнев, страх — это всё ведет на темную сторону Силы.
Как только ты сделаешь первый шаг по темному пути,
ты уже не сможешь с него свернуть…

Добрый день, уважаемый галактический сенат! На связи снова Денис Мельский, и сегодня на повестке дня — определение теоретического минимума познания *nix систем для юного падавана web-мастерства.

Хотелось бы начать с того, что все мы прекрасно знаем: на 67.4 % наши любимые интернеты крутятся на *nix-based-серверах, а в жизни среднестатистического web-разработчика в вакууме — так и на все 90 %.



Для любителей пруфов — welcome.

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

Предлагаю рассмотреть три юниорских степени познания дзена управлением шайтан-машиной ака *nix-сервак на примере всеми любимой ubuntu.

Я —.NET разработчик. Но в последнее время всё чаще сталкиваюсь с JavaScript. Причём, процентах в 50 случаев я что-то на нём пишу, в остальных 50 — разбираюсь с чужим кодом, да ещё и прошедшим через минификацию, а иногда и обфускацию. В этой статье захотелось поделиться теми моментами, которые мне показались важными для понимания языка и эффективной работы с ним. Тут не будет ничего нового или неизвестного для людей, уже имевших дело с языком, и не будет чего-то такого, чего нельзя найти в других источниках. Для меня статья будет полезна как способ лучше разобраться в предмете, для читателей, я надеюсь, — как повод освежить знания.

Брендан Айк упоминал, что JavaScript был создан за 10 дней. Думаю, идея вынашивалась дольше. Как бы то ни было, язык получился и с тех пор только набирает популярность. Особенно после появления AJAX.

JavaScript — язык со слабой динамической неявной типизацией, автоматическим управлением памятью и прототипным наследованием.

JavaScript состоит из трёх обособленных частей:

• ядро (ECMAScript),
• объектная модель браузера (Browser Object Model или BOM),
• объектная модель документа (Document Object Model или DOM).

В статье, в основном, пойдёт речь о ядре. Конечно, в примерах кода будут использоваться элементы DOM и BOM, но заострять на них внимание не буду.

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

Walkway.js и Vivus.js

Вы видели этот великолепный лэндинг посвященный анонсу Sony PlayStation 4? Обратите внимание на анимацию SVG объектов состоящих из контуров. Они словно рисуются художником в режиме реального времени. Отныне этот эффект можно легко повторить с помощью Walkway и Vivus. Обе библиотеки максимально просты в использовании и применимы только для path элементов, поскольку принцип их работы основывается на взаимодействии с CSS свойством strokeDashoffset. Хоть и у Walkway значительно больше звезд на Гитхабе, зато Vivus предоставляет несколько вариантов отрисовки: Delayed, Async и OneByOne.

//Walkway
var svg = new Walkway('#test');

svg.draw(function() {
  console.log('Animation finished');
});

//Vivus
new Vivus('my-svg-id', {type: 'delayed', duration: 200}, myCallback);

И снова здрасьте! IVR — сегодня это даже не фишка, а некий стандарт работы предприятия. В некоторых случаях многие, как клиенты, так и конкуренты считают, что если этого самого IVR нет, то «там» низкое качество предоставляемых услуг. Этой штукой нынче никого не удивишь. Однако, мы же говорим про реализацию IVR на языке lua под Астериском. И если вы переходите от обычного плана набора к Lua, то тут можно кое-что пояснить.

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

В данной статье хочу описать свой вариант реализации некоторого функционала, реализованного на моем Asterisk-сервере.

Описано:
— вариант реализации переадресации на мобильные, используя двухканальный SIP-GSM шлюз и многоканальный Мультифон;
— SMS-уведомление абонента посредством бесплатной услуги email2sms;
— реализация «прямого» входа в общий внутренний план нумерации для мобильного абонента программным (для Android) и аппаратным (SIM-Dialer для обычных мобильников) способами.

Подробности под катом.

Предлагаю вашему вниманию перевод отличной статьи Майкла Аррингтона из TechCrunch, которую я регулярно подкидываю своим знакомым стартаперам, когда их начинают терзать сомнения и лезут в голову вопросы наподобие «Да какого черта я все еще этим занимаюсь?»



Добро пожаловать под кат.

Приветствую всех. Когда-то тема использования языка программирования lua при написании диалплана в Астериске для меня стояла довольно жёстко. Дело в том, что мне сильно не нравится работать с различными GUI (типа FreePBX) при настройке Астериска.

Когда я всё настраивал в первый раз, работал с обычным линейным extensions.conf. Время шло, потребности в функционале телефонии росли. Язык lua постепенно немного изучил. И вот пришёл я работать админом в одну крупную компанию в нашем городе (одно крупное агентство недвижимости) — около 45 филиалов на тот момент было, примерно 650 — 700 пользователей, включая межгород и т.д. Там уже стоял Asterisk, но всё настроено было с использованием FreePBX.

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

Сколько часов в неделю вы тратите на работу? Около 40, не так ли? А как вы думаете, что будет, если работать 90 часов в неделю?

Автор сайта a Year of Productivity Chris Bailey решил провести такой эксперимент. К чему это привело? Читайте о 10 уроках, которые он извлек, в нашем переводе его статьи.

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



Работа в e-commerce дала мне лучший практический опыт в жизни. Те вещи, которые я узнал, запуская онлайн-бизнес не рассказывают на лекциях MBA или других обучающих курсах.

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

За последний год я очень много говорил о Symfony 3.0 на разных конференциях. Я думал о наилучшей стратегии для этой версии уже давно, и теперь настало время поделиться моими мыслями со всеми.

Мажорные версии

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

Страх перед мажорными версиями растет своими корнями из нашего прошлого: вспомните Perl 6 или PHP 6. В мире Symfony вторая версия тоже была революционной по сравнению с symfony 1. Я понимаю, почему люди нервничают, когда слышат о третьей версии, и именно в этом посте я расскажу, почему вам не нужно паниковать.

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

Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 2011 и 2012 году они показывали высокую прибыль, при которой можно забыть об оптимизации и просто фигачить как можно быстрее дальше, пока получается. «Что тут думать, трясти надо» — оптимальная бизнес-стратегия на таких нормах прибыли. В 2013-м году из-за общей экономической ситуации стало понятно, что прибыль будет снижаться. Соответственно, первое, что начало делать большое руководство — это разбираться, куда и как конкретно тратятся деньги, чтобы найти то, что можно безболезненно оптимизировать или просто убрать.

В статье пойдет речь о том, как из любого запроса на естественном языке получить реальные данные, с которыми может работать ваше приложение. А именно, о REST API сервиса SpeechMarkup, который преобразует обычную строчку текста в JSON со всеми найденными смысловыми сущностями с конкретными данными в каждой из них.

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

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

Очень многие из нас верят в существование волшебной субстанции под названием «призвание». «Если бы я только мог найти свое призвание», — с горечью говорим мы. «Я был бы счастлив, если бы нашел свое призвание...»

Что сказать? Призвание — реальность, причем, невероятно могущественная. Но почти все, что люди знают о его поиске, в корне неверно. Именно об этом ведет речь в своей последней статье Оливер Эмбертон. Продолжаем размышлять над личной эффективностью!

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

Если вы хотите найти и/или поделиться хорошими книгами, добро пожаловать под кат.

Добрый день!

В этой серии статей мы хотим рассказать об Ultima Businessware — нашей платформе для построения ERP систем.
Это первая, вводная статья, в которой расскажем об эволюции (т.е. среде и взаимодействии с ней) платформы и перечислим основные и самые интересные возможности платформы.
В следующих постах мы планируем рассказать о подробностях устройства и реализации этих самых возможностей. Кроме того, по ходу изложения мы будем делиться с особенностями организации процесса разработки у нас.

В середине лета мы впервые услышали слово «холакратия». За пару дней отвадили себя от неправильного написания (холОкратия) и научились отличать эту модель организации бизнеса от почившей в бозе формы правления с созвучным названием «охлократия». Дальше началось самое интересное: мы решили попробовать холакратию в деле. Момент был подходящим, не хватало только информации. Пришлось изучать скудно описанный опыт западных коллег, призывать на помощь менторов из Амстердама и нырять в бездны поисковиков. Спустя полгода новая концепция начала приживаться, а у нас появился опыт, которым не стыдно поделиться.



В предыдущей статье мы писали о том, что такое холакратия и почему она вам не нужна. Сегодня разбавим сладкую теорию горькой практикой и посмотрим, как это работает в Кнопке. Не обойдём стороной опыт Zappos, Medium, David Allen Company и поспорим в комментах о ситуации в GitHub. Вы с нами? :)

Проблема в том, что в любом традиционном обучении переговорам предполагается, что стороны должны в итоге договориться.

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

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

Организация очередей звонков и распределение звонков по операторам является одной из основных задач колл-центра, обслуживающего входящие вызовы, когда количество вызовов превышает количество доступных операторов (стандартная ситуация для большинства колл-центров). Звонящего ставят в очередь под определенным номером, о чем ему сообщает IVR, и проигрывают музыку, переодически рассказывая об изменении места в очереди и предполагаемом времени ожидания (до того как ответит оператор). Если повезет, то музыка будет приятной, а ожидание не слишком долгим. Хотите узнать как быстро организовать колл-центр с описанным функционалом, не влезая в дебри и сложности IP-телефонии — добро пожаловать под кат.

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?