Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 121 сообщений
Cообщения с меткой

разработка программного обеспечения - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Что предпочесть: собственные ресурсы, покупку или аутсорсинг?

Вторник, 23 Августа 2016 г. 14:36 (ссылка)

image

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

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



1. Передача разработки целевого продукта компании-разработчику программных решений.

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

3. Или же организация может решить нанять команду специалистов и создавать целевой продукт своими силами.



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



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



1) Сокращение накладных затрат



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



2) Сокращение расходов на оплату труда



Говоря об эксплуатационных расходах, трудовой арбитраж (labor arbitrage ) часто рассматривается как наиболее очевидное преимущество аутсорсинга. Многие руководители считают, что, если за свои деньги можно получить больше производительности, когда работа выполняется в другом месте, нет смысла платить больше собственным сотрудникам.



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



3) Попрощайтесь с долгосрочными обязательствами



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



4) Повышение производительности за счет широкого географического присутствия



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



5) Свобода от лицензионных обязательств



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



6) Свобода от проблем, связанных с инфраструктурой и обслуживанием ресурсов



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



7) Аутсорсинг экономит время, деньги и ресурсы



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308340/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Через тернии к сборке

Вторник, 09 Августа 2016 г. 10:31 (ссылка)

Привет, дорогие читатели. Я – разработчик в компании “RTL Service”, в которой мои обязанности по разработке продукта пересекаются с обязанностями DevOps. Конкретнее – я создаю и поддерживаю инфраструктуру сборки и первичного тестирования наших продуктов еще до их попадания в отдел тестирования.



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

В качестве сервера CI (непрерывной интеграции) у нас используется Hudson, можете кидать в меня тапками, но мы руководствуемся принципом «Работает — не трогай».

В дальнейшем есть планы попробовать TeamCity либо Jenkins.



Общая информация о задачах и группах на нашем CI сервере.



Все задачи по сборкам у нас разбиты на 5 больших групп:

https://habrahabr.ru/post/307398/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Конечные автоматы в среде динамического моделирования SimInTech. Часть 2

Понедельник, 08 Августа 2016 г. 17:32 (ссылка)

В первой части мы показали как создать алгоритм работы на основе «конечных автоматов» в SimInTech и использовать его совместно с «классическими» алгоритмами в виде функционально блочных диаграмм.



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



Вложенные структуры конечных автоматов. Реализация обмена данными с конечными автоматами



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



Соберите схему, как показано на рис. 30





Рисунок 30. Внутренняя структура автомата индикатора.



В качестве активного состояния выберете состояние on. Выделите блок и нажмите на него правой кнопкой мыши. В выпадающем меню выберите пункт «Свойства». Появится окно редактирования свойств, в котором нужно выбрать да в единственном свойстве «По умолчанию» Да (см. рис 31.)



image


Рисунок 31. Настройка начального активного состояния.



Внутренняя структура логики работы в состоянии включен представлена на рис. 32.



image


Рисунок 32. Логика работы в состоянии On



После включения состояния таймер вырабатывает сигнал 0 (false) в течение заданного времени. Это сигнал блоком «оператор НЕ» превращается в 1 (true) и передается на выход Оn. Пока не истечет время, заданное в блоке «Выдержка состояния», на выходе из блока состояния On будет 1. Как только время закончится, выход блока «Выдержка состояния» станет равен 1 (true), произойдет срабатывание перехода, одновременно сигнал на выходе станет On — 0 (false) и не будет меняться, пока состояние неактивно. Таким образом, можно использовать это выход в качестве индикации состояния включен.



Поднимитесь на один уровень схемы выше и поставьте на схему блок «Выходной порт» из закладки «Субструкутры». Этот порт будет передавать наружу сигнал работы индикатора. Соберите схему, как показано на рис. 33.



image


Рисунок 33 Схема автомата индикации.



Войдите в состояние off и наберите простую схему, как показано на рис. 34



image


Рисунок 34. Схема работы в состоянии off.



После включения состояния включается таймер и через указанный в настройках интервал времени происходит выход из состояния.



Поднимитесь на два уровня вверх и соедините появившийся выход из субмодели «Автомат индикатора» с выходом «Led» на схеме контроллера, как показано на рисунке 35.



image


Рисунок 35. Схема контроллера нагревателя с вложенным автоматом индикатора.



Если сейчас запустить общую схему на расчет, то индикатор будет переключаться между 0 и 1 с интервалом, заданным в таймере состояний автомата индикатора ( см. рис. 32 и 34). По умолчанию это время равно 1 секунде и график «Индикация» на общей схеме (см. рис. 8) будет представлять из себя меандр с интервалом 1 сек, как на рисунке 36:



image


Рисунок 36. График работы автомата индикации.



Чтобы интервал автомата индикации зависел от состояния контроллера (1 секунда при нагреве и 5 секунд в выключенном состоянии), необходимо в него передать данные из параллельно работающего автомата состояния. Для этого существует несколько способов. Поскольку автоматы состояния реализованы с использованием обычных субмоделей могут быть использованы все методы передачи данных. В нашем примере мы используем один из них – сигналы модели.



Перейдите внутрь субмодели «Контроллер нагревателя». Схема на экране должна выглядеть как на рис. 35. В главном меню главного окна SimInTech выберите пункт «Сервис» подменю «Сигналы» (см рис. 37)



image


Рисунок 37. Вызов настройки сигналов проекта.



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



Создайте новый сигнал (кнопка «добавить» внизу окна), задайте имя flash_time. Режим установите в «Ненаправленный» это позволит читать и записывать данный сигнал в любом месте проекта (см. рис. 38)



image


Рисунок 38. Добавление сигнала проекта.



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



Перейдите в автомат индикации и в таймерах состояния для состояний on и off вместо значения по умолчанию 1 поставьте имя сигнала flash_time. (см. рис. 39)



image


Рисунок 39. Задание выдержки состояния индикации через имя сигнала.



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



Перейдите в карту состояний «Контроллер нагревателя» и состояние выключен. Поместите на схему блок «Константа» из закладки «Источники» и блок «Язык программирования» из закладки «Динамические». Соедините их, как показано на рис. 40.



image


Рисунок 40. Схема состояния выключен с заданием времени индикатора.



Задайте в свойствах константы значение 5 (5 секунд интервал в выключенном состоянии). В общем случае вместо константы может быть схема расчета интервала любой сложности и любой глубины вложенности.



Войдите в редактор блока «Язык программирования» двойным кликом и присвойте значение входа (u) переменной flash_time, как показано на рис. 41.



image


Рисунок 41. Задание интервала индикации в языке программирования.



Данный текст присваивает сигналу flash_time значение, полученное из входа в блок «Язык программирования». Для принятия изменений нажмите кнопку «Закрыть и применить» вверху окна. (см. рис. 41).



Можно не использовать блоки и задать интервал работы индикатора прямо в тексте программы. Давайте так сделаем для состояния включен.



Перейдите в состояние включен и поместите на схему блок «Язык программирования» из закладки «Динамические». Войдите в редактор блока двойными кликом и введите в окне редактирования текст, как показано на рис 42.

Закройте окно нажатием на кнопку «Закрыть и применить» в верхней части окна редактирования.



image


Рисунок 42. Задание интервала индикации для состояния включен в языке программирования.



Если сейчас запустить расчет, то график «Индикация» покажет нам, что автомат индикации меняет интервал переключения в зависимости от состояния контроллера нагревателя. В выключенном состоянии интервал равен 5 секундам, во включенном состоянии – 1 сек. (см рис. 43)



image


Рисунок 43. График работы индикатора с разным периодом.



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



Например, для изменения расчета цвета индикатора можно доработать схему контроллера так, чтобы, кроме включения и выключения индикатора (0,1) на выход, подавалось также значение цвета индикатора (0 – выключен, 1 – включен зеленый, 2 – выключен красный). Схема вычисления цвета приведена на рисунке 44.

image


Рисунок 44. Схема работы контроллера нагревателя с вычислением цвета индикатора



Если вы собрали все схемы, как описано в данном тексте, то графики работы модели будут похожи на приведенные ниже (см. рис. 45):



image


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



На графике индикации работы нагревателя (верхний график рисунка 45), видно, что в выключенном состоянии с периодом 5 секунд выход на индикатор меняет значение 0 — 1 (выключен-зеленый), а во включенном состоянии это выход с периодом 1 секунда меняет значение 0 — 2 (выключен красный). Обратите внимание что в приведенном примере на схемах комбинируются два подхода к созданию алгоритмов управления логика «конечных автоматов»



Выводы



Среда динамического моделирования технических систем SimInTech содержит средства для создания модели систем управления на основе конечных автоматов (state flow). Данная логика может быть использована вместе со стандартной логикой функционально-блочных схем (data flow), при этом средства разработки и создания схем полностью между собой совместимы.



В примере приведены основные приемы работы при использовании логики «конечных автоматов» в SimInTech. Скачать версию SimInTech c блоками конечных автоматов можно здесь.



В следующей части мы покажем как генерировать код Си из схемы в SimInTech.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307162/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Un-FuckUp-able Development Protocol (UDP)

Четверг, 04 Августа 2016 г. 17:40 (ссылка)

Недавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но, в этот раз конструкция показалась мне очень удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:



В эту сиесту на веранде практически никто не курил, потому, что все ушли на очередной двухдневный SCRUM тренинг. Джонни устало окинул взглядом присутствующих: Дёму и Варю. Они тоже не были в восторге от происходящего, было слишком жарко и душно, лето в Долине было в самом разгаре, и казалось, что на улице даже жарче чем в Task Tracker’е.








Дела были не ахти, все трое это знали. Они все в решении своих задач зависели от людей, которые ушли учиться как надо организовывать процесс разработки. Реальная работа, которую надо было сделать ещё вчера, сегодня переносилась на тот незримый момент в будущем, когда остальные “бойцы” вернутся с фронта борьбы за ликвидацию безграмотности.



— А хотите, ребята, я Вам сказкочку расскажу, про программистский Рай? — спросил Джонни, стряхивая пепел после очередной затяжки.



Варя и Дёма уныло кивнули, но постарались улыбнуться. Тогда Джонни достал из кармана трубку, и, пояснив, что это будет Long Run Story, стал неторопливо погружаться в клубы Balkan Delight (сорт табака).



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



Инициализация BIOS выдала слушателям сведения об оборудовании:





Ну и прочий IO и периферия, типа “сторонних” тестировщиков, верстальщиков и дизайнеров, с которой все были согласны. Все так же согласились, что дисплей это SCRUM доска, а операционная система это Linux, то есть движение Open Source конкретно и прорывные инновации IT сферы в частности.



Менеджмент, безусловно, отнесли к прикладному софту — Task Tracker’у и Cron. Электроснабжение, по понятным причинам, заменили на понятие Cash Flow от Заказчиков и Клиентов. Ведь компьютеру не важно откуда придёт энергия, важно просто делать расчёты, поэтому данность наличия энергии и источник её возникновения тоже никем не оспаривался. Корпус, в их случае, конечно же был кастомный, с водяным охлаждением (бассейн и сауна), разлоченным генератором тактовой частоты (любые ништяки, от кальяна и пива на веранде, куда не запрещалось брать ноутбук, до спортзала в подвале их особняка). ИБП в виде угарнейших корпоративных вечеринок и прочих значительных поблажек в presence time schedule так же, конечно, обозначился как неотъемлемый и очень нужный девайс.



Пропустив остальные несущественные моменты описания Джонни подвёл итог:



— Итак, мы имеем 50+ человек, которые уже пару лет дышат той или иной методологией разработки, но при этом всё равно у нас регулярно происходит какой-нибудь FuckUp. Мы начали с самоорганизованного хаоса, тогда нас было 10. Потом нас стало 20, и 30, и 40 и у нас был “Водопад” (модель разработки). И, когда всё завертелось не так, как мы привыкли, мы стали делать SCRUM. И, вроде бы, всё у нас отлично, стабильная ЗП, отличный менеджмент, довольные пользователи регулярно заносят копеечку, но все же видят проблемы? — подитожил Джонни.



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



Все знали, что каждый из разработчиков регулярно получает не только премии, но и “по шапке” за факапы. Что тестировщики “не тестируют”, а джуны не джунят. Верстальщикам то не хватало “еды”, так как дизайнеры были перегружены микроменеджментом, то их заваливало так, что уже разработчики были вынуждены их ждать. Про саппорт — этих бравых ребят — могучих викингов во главе с самим Тором можно было с удовольствием писать лишь панигирики да некрологи. А первой ассоциацией к менеджменту у всех единогласно был утренний будильник, всегда звенящий не вовремя. Пожалуй, не будем продолжать, Вы и сами все всё про всё это знаете, оно везде так, не только в IT.



— Все же понимают, что вне зависимости от методологии процесса разработки наши задачи никуда не денутся? Их количество и качество останутся неизменными?



Все так же понимали, что ни Скрам, ни Водопад, и ничто в этой вселенной не отменит здравый смысл. Что если происходит пожар на продакшене — его надо тушить. Что если что-то упустили и надо срочно — то будет прерывание и выпадение из контекста, это естественно. Что нельзя отказаться от необоснованного общения с менеджментом, и никакой SCRUM не спасёт от внезапно возникшей “чудо-идеи”. Что технический долг никуда не денется, и задач сопровождения будет всё больше и больше, до тех пор пока число пользователей будет расти. А именно обеспечение этого роста и есть ключевая задача, не менее важная чем разработка новых продуктовых фич. И что ни скрам, ни канбан, ничто не спасёт от всего этого бардака, так как система не может быть замкнутой, она дышит, она — живой организм.



— Таким образом, мы все хотим расти, развиваться, писать код, но, чтобы всё это было так же интересно как и сейчас, нам нужен какой-нибудь новый “paradise”?



Все кивнули. Джонни снова раскурил уже давно погасшую трубку.



“Мы владеем коммандой, которую нужно Ре-Инжинирить!”



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



— Все же помнят разницу между TCP и UDP? — Джонни пояснил, что это метафорично в контексте сказки, и все согласились, что UDP лучше подходит для стриминга, но не гарантирует доставку.



Потом всем стало ясно, что менеджмент хочет, чтобы мы совместили в себе и UDP и TCP, то есть гарантировали доставку для высокой скорости поставки новых фич.



— У нас есть коллектив разработчиков, который, так уж сложилось, поделился на комманды. Во главе каждой комманды стоит Team Lead, и почти всегда это кто-то из наших Senior Developer’ов. Над нами есть CEO и CTO. Так же у нас здесь все остальные непонятные люди, которые постоянно прерывают процесс и вносят свои коррективы. И, вот, вроде бы все разработчики вроде бы постоянно заняты разработкой, но кто-то всё время простаивает или перегружен и/или попутно занят решением какого-нибудь из типов прерываний: от руководства, от саппорта, от технического долга. То есть, мы постоянно имеем дело с каким нибудь FuckUp, кторый происходит потому, что просто всё так сложилось. У нас вроде бы есть процесс, но он не решает проблему того, что когда Ты хочешь писать код — ты не можешь, а когда можешь, то уже не хочешь, так как устал, пока не мог, и вообще решал другие “важные” задачи. Кто на митинг пошёл, кто за чаем, и вот так вот плов всё никак не сварится до нужной кондиции.



— Ну, и что Ты предлагаешь? — наконец-то озвучил давно звенящий в знойном воздухе вопрос самый неопытный и нетерпеливый Василий.



— Я предлагаю объединить комманды по другому. Во главе комманды не может стоять Team Lead. То есть, всё будет как и раньше, только управлять коммандой будет не Senior Developer, а кто-нибудь более-менее грамотный из Middle или даже перспективных Jun’ов.



Это как-это?



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



Например, у нас есть Pool высококвалифицированных и самых компетентных специалистов, давайте так обзозначим Senior Developer’ов. Далее у нас есть менее компетентные, которые очень хотят “расти” и стать более компетентными. Но им постоянно не хватает ни времени “старших” братьев, ни уважения менеджмента, ни, тем более, понимания процессов.



Конечно, здравым смыслом пренебрегать не стоит, Senior — он на то и Senior, что может сам поднять упавший сервер, когда и в каком бы состоянии Ты его не разбуди. Но только руководить разработкой он не должен. Он должен разрабатывать, принимать решения и ответственность за их реализацию. А вот управлять процессом должен Middle или опытный Jun, просто потому, что они смогут:


  • — всё увидеть сами

  • — захотят задать правильные вопросы

  • — осознают, что им ещё расти и расти, но они уже могут что-то сами

  • — натаскаются, в конце концов

  • — опылятся и т.п. и т.д.





И тогда, через год у нас будет не 8 Сеньоров, а минимум в два раза больше. Мы же уже два года не меняем перспективы. Нанимаем вроде бы отличных сеньоров, а джуны в мидлов почти не растут, да и мидлы почти не растут в сеньоров.



Вспомните! У всех мидлов же глаза горят, когда они к нам приходят, а потом пообвыкнутся немного, и всё стекается в это болото. Уставшие сеньоры вешают на них никому из них не понятные задачи, и что в итоге — процесс еле ползёт.



— Представь, Дёма, что Ты смог бы работать, именно Работать, а не просто сидеть в скайпе ежечасно отрываясь на кодец, не по 20+, а по 30-40+ часов в неделю? Ты же и так работаешь по 60+ часов только из-за того, что постоянно кто-нибудь врзывает Тебе мозг, а работа стоит, а сделать её надо, ты же ответственный!



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



— Представь, Вася, что Ты бы был начальником у Дёмы? У Тебя же бы все дела спорились, Может и Анита из аккаунтов, наконец бы Тебя заметила? А там, глядишь, Ты бы увидел код Дёмы из-за спины, и понял бы, что в нём нет никакой “магии”.



Конечно у Васи загорелись глаза. Он и представить себе не мог это в самых радужных снах, руководить отделом! Уж он то знал точно, как всё устроить, если бы у него только были ещё и такие подчинённые как Дёма, он бы давно всё порешал.



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



Варя просияла, так как она поняла, в чём проблема. В основном она работала с Аристархом, тем ещё Хипстером: “коммандиром” FrontEnd комманды. Личность он был весьма импозантная, и код у него был великолепен. Проблема была толкьо в том, что ему некогда было его писать, и большая часть задач решалась его подчинёнными, и у него даже не всегда было время на Code Review. Так как он был чуть ли не единственный человек, который понимал процесс создания красивостей “в комплексе”, то порой даже и отдел продаж контактировал с ним напрямую, минуя всю технологическую цепочку. Это был единственный человек в комманде, который мог понять дизайнера сразу, не переспрашивая, и не уточная. Конечно, вся его комманда на него молилась, но Варя страдала. Она понимала, что половина его подчинённых ждут когда же он обратит внимание на ею, Варей, найденные баги.



Конечно же, этой ночью никто из-них уже не мог сомкнуть глаз, несмотря на усталость.

Утром они встретились на веранде и определили желаемые новые субординации и составы команд.



К вечеру был готов “меморандум”, который они тайком приклеили на SCRUM доску.

В меморандуме было лишь следующее:



Un-FuckUp-able Development Protocol (UDP)




  • Team Lead !== Team Manager

  • Team Manager == Middle Developer

  • Senior Developer == Code Leader (GOD of Code)





И QR код на “по-быстрому” подготовленный документ, излагающий основные принципы вчерашней PR компании идей Джона.



***



Do You like my Story, man?



Конечно, у них было всё, и метрики производительности, и Grade’ы, и SMART и всё такое остальное важное-преважное, что мы все так сильно любим. Но все же мы понимаем, что хотим, не так ли?



Sincerely Yours John…
Original source: habrahabr.ru.

https://habrahabr.ru/post/307134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Sailfish OS — летняя школа в Университете Иннополис для разработчиков мобильных приложений и энтузиастов Linux

Четверг, 07 Июля 2016 г. 16:35 (ссылка)

image

С 27 по 30 июля в Университете Иннополис пройдёт первая летняя школа, посвящённая платформе Sailfish OS. Компания «Открытая Мобильная Платформа» приглашает студентов, аспирантов, разработчиков приложений и энтузиастов, ценящих проекты на основе Linux. Участников школы ожидают вводные лекции, знакомство с представителями сообщества разработчиков, технические мастер-классы, конкурс по программированию, развлекательная программа и общение в неформальной обстановке.



Жми «Читать дальше», если хочешь узнать больше о Школе.



С 27 по 30 июля в Университете Иннополис пройдёт первая летняя школа, посвящённая платформе Sailfish OS. Компания «Открытая Мобильная Платформа» приглашает студентов, аспирантов, разработчиков приложений и энтузиастов, ценящих проекты на основе Linux. Участников школы ожидают вводные лекции, знакомство с представителями сообщества разработчиков, технические мастер-классы, конкурс по программированию, развлекательная программа и общение в неформальной обстановке.



Сергей Масягин, проректор — начальник управления по работе со студентами и абитуриентами Университета Иннополис: «Летняя школа по Sailfish OS открыта для тех, кого интересует разработка приложений под новую операционную систему на базе Linux. Новички познакомятся с профессионалами и зададут им интересующие вопросы, узнают, с чего начинается приложение. На мой взгляд, представителям индустрии мобильных приложений будет интересно пообщаться с теми, кто в ближайшем будущем придёт к ним работать или составит конкуренции на этом рынке. Это мероприятие станет для новичков возможностью получить дополнительную мотивацию развивать навыки в одном из самых востребованных направлений ИТ-сферы».


Летняя школа подойдёт для новичков и профессионалов. Разработчики продуктов для мобильных устройств узнают о способах и особенностях создания приложений для Sailfish OS. Специалисты по Qt и QML научатся применять свой опыт при программировании для смартфонов и планшетов. Новички получат основные знания о платформе и попрактикуются в разработке приложений. Профессионалы продемонстрируют свои умения и поделятся опытом с коллегами.



Павел Эйгес, генеральный директор компании «Открытая Мобильная Платформа»: «Sailfish OS для нашей компании — это, технологический фундамент, на базе которого мы создаём отечественную мобильную платформу максимально широкого применения. В основе лежит качество самой операционной системы, над развитием которой трудится несколько десятков инженеров-разработчиков. Но для становления платформы не менее значимо создание экосистемы, включающей и наших партнёров, и сообщество разработчиков, и пользователей — всех людей, которым действительно интересно то, над чем мы работаем. Создание такой экосистемы — ключевая задача на ближайший год. Для её решения мы используем различные площадки и форматы, и Летняя школа в Иннополисе, нашем домашнем регионе, является одним из центральных мероприятий. В рамках школы участникам будет предложена самая актуальная техническая информация, проведен ряд мастер-классов и конкурсов. Будет организована ярмарка вакансий. Наша компания старается быть максимально открытой для общения со всеми, и мы ожидаем продуктивного диалога с сообществом, новых идей и предложений».


Регистрация, условия участия и подробная программа доступны на странице летней школы
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305120/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка микро-учётной системы на lua, часть шестая. И снова модуль управления базой

Среда, 01 Июня 2016 г. 19:26 (ссылка)

В связи с высказаным мной предположением в части 3-й и 4-й я решил модифицировать модуль базы. Изменение этого модуля повлекло модификацию всех исполнительных. Но это того стоило. Модификация состоит в том, что для вызова СУБД — зависимых запросов можно настроить однотипные процедуры, принимающие параметры на входе.



Оассмотрим функцию database.select_from_where(select, from, where), которая часто используется в процедурах для получения табличной информации:

function database.select_from_where(select, from, where)

text = "SELECT " .. select .. " FROM " .. from

if where ~= nil then
text = text .. " WHERE " .. where .. " ;"
else
text = text .. " ;"
end

query = database.link()
thread = query:execute(text)
result = thread:fetch({}, "a")
return result

end


Читать дальше →

https://habrahabr.ru/post/302406/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка микро-учётной системы на lua, часть пятая. Модуль управления

Среда, 01 Июня 2016 г. 18:11 (ссылка)

Модуль управления является frontend — узлом проекта. Скрипт cvs.lua взаимодействует с исполнительными модулями, которые являются бизнес — логикой проекта.



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



Модуль cvs.lua: Читать дальше →

https://habrahabr.ru/post/302402/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка микро-учётной системы на lua, часть четвёртая. Модуль доступа к базе

Пятница, 27 Мая 2016 г. 16:30 (ссылка)


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

image

Читать дальше →

https://habrahabr.ru/post/302004/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка микро-учётной системы на lua, часть третья. Lua и взаимодействие модулей

Четверг, 26 Мая 2016 г. 21:03 (ссылка)


Помните, в прошлой части была схема взаимодействия модулей? Теперь пришло время рассмотреть её подробнее:



image



Для первоначального обучения всем желающим есть учебник «Язык Lua за 15 минут». Здесь я постараюсь рассматривать детали, которые относятся к проекту и не упоминаются в учебниках — только в справочниках и форумах (по возможности).



Для понимания кода нужно принять во внимание следующие особенности разработки на Lua:


  • Язык разрабатывался, как система обработки семантических и числовых массивов данных.

  • В языке большое количество конструкций и функций, предназначенных для парсинга информационных потоков (да-да!)

  • И самое главное — практически все виды сложных данных представляют собой табличные области. В прямом смысле!

  • Таким образом, опять-таки, все усложнённые объекты представляют собой так называемые метатаблицы — это массивы, которые хранят в себе описание и информацию экземпляра. Вложенность метатаблиц может быть поистине феерической!



Читать дальше →

https://habrahabr.ru/post/301920/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Что делает программное обеспечение качественным?

Среда, 16 Марта 2016 г. 21:26 (ссылка)

image

КДПВ



Кто-то создает программное обеспечение с открытым исходным кодом, а я провожу много времени размышляя над тем, как сделать программное обеспечение лучше. Бесконечный поток просьб о помощи на форумах Stack Overflow, GitHub, Slack, в электронных письмах и личных сообщениях неизбежен. К счастью, в итоге вы знаете многих людей, которые добились определенного успеха и сделали фантастические вещи, и знание о том, что вы приняли в этом участие благодаря вам и вашей помощи, является хорошей мотивацией для новых достижений.



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

https://habrahabr.ru/post/279459/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сопротивляйтесь добавлению в проект новых библиотек

Пятница, 15 Января 2016 г. 12:03 (ссылка)


Что нам строит дом построитьИтак, вам понадобилось реализовать в проекте функциональность X. Теоретики разработки программного обеспечения в этот момент говорят, что для этого нужно взять уже существующую библиотеку Y и использовать её для реализации необходимых вам вещей. Собственно, это классический подход в разработке программного обеспечения — повторное использование своих или чужих наработок (сторонних библиотек). И именно этим путём движется большинство программистов.



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



Читать дальше →

http://habrahabr.ru/post/275159/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<разработка программного обеспечения - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda