Это проблема (ок, гугл — это архитектура) реализации конкретного языка, который требует больше вводных для точного ответа. Int в контексте языка Java имеет конкретный железобетонный размер. Поэтому да, задание контекста в виде языка упрощает коммуникацию. К тому же, будет справедливо заметить, что команды редко включают разношёрстных спецов и ситуация «встретились инженеры на асме, питоне и го» больше соответствует курилке или интернет форуму. Внутри команды контекст известен день ото дня, поэтому всё не так плохо. Но сравнивать языка становится интересно и анекдотичные ситуации появляются. Спасибо за статью.
А можно узнать больше деталей про сбор статистики? Я замечал, что компании несколько вакансий на одну позицию открывали, но с разными заголовками и ЗП.
моё мнение: не тратить время, которые не окупиться.
В первом случае можно сказать, что вас «тестировали» на проф пригодность. Время специалиста ценно и тратить его на каждого новичка рассказывая и обучая не выгодно финансово. Особенно, если речь будет идти об азах и общих решениях по области.
Во втором случае, выгодно провести несколько-часовое (дни, недели) «погружение» в архитектуру, дизайн и решения конкретного проекта. То, что новичок не сможет «схватить» без базы (а она нарабатывается годами).
Тут несколько напоминает японщину:
I. толпа новичков смотрит и повторяет за мастером
II. мастер работает с небольшой группой учеников
III. два-три специалиста продолжают дело мастера
Ну или по-русски:
Ни один царь не пошлет юнца девичьи покои охранять.
Автоматизация бизнес-процессов…
Я надеюсь, что наступит тут день, когда вся кухня из SAP-вых решений, хранилищ, BPM и ETL процессов с системами документооборота и интеграции с CRM, ERP, BI и прочий мутью будет будет обходится без участия человека.
Имхо кодировать и костылить в таких «интегрированных» и «автоматизированных» системах нужно на порядок больше.
скучно и серо, с лихвой компенсируется ЗП — как контракт с дьяволом.
Вам «еще» нужно для спора, а не ликбеза. PHP это большая экосистема, которая приносит фирмочке Zend весьма ощутимый профит. Я не подписывался лично вас переубеждать в обратном или менять ваш взгляд.
Для бизнеса нет понятия «нормальный язык». Ребята, вкладывающие деньги, не мыслят категориями динамичная или строгая типизация или там много синтаксического сахара или тут соль добавили. Есть ресурс, есть задача, нужно решение для получения какого-либо профита. Программистов нанимают для решения задачи. В среднем на зп одного среднего джависта или сишника/шарпера можно нанять полтора-два PHP разработчика. Или разработчика и фронт-енда, что уже маленькая команда из двух разнопрофильных спецов. Это уже реальный шанс сделать что-то, проверить и получить опыт/первый профит.
Я молчу уже о стоимости «расходников», типа хостинга и проч. И да проекты разные (мы только про веб), достаточно купить хостинг и тремя кликами поставить форумы, блоги, магазин, соц. сеть, вики… Сходите сюда веб-хостинги, не поленитесь — тыкните на compare. Там есть категории софта для установки (Instant Blogs,Instant Portals, **) — нажмите (?), появиться окно с конкретикой — что можно поставить. Посчитайте и сравните, что PHP, а что нет.
При цене в 4 бакса в месяц, у вас будет работающий сайт. И о да, вам даже программист не нужен. Если хочется, предлагаю сравнить со стоимостью решения такой же задачи, но с другим языком…
Про сообщество не понял. Чем оно плохо? Какое сообщество вы имеете в виду (ru, en, школьников, ZCE, guru)?
Если судить по эмоциональной наполнению вашего первого комментария, оно у вас очень негативное.
Незнаю, может мне кажется =) Но похапэфобия то ли рвет вас изнутри, то ли отравила до тошноты, то ли зарядила нехилый баттхёрт.
Я не хочу вас лично обидеть, да и вряд ли это возможно в интернете, моя идея такая (про php):
«easy to learn, hard to master»
Вы из секты анти-верующих, даже скорее анти-евангилист.
У вас PHP — это такой гном, который «не поощряет программирование, его изучение». И самое печальное это то, как вы видите людей, которые его используют — «сообщество PHP никогда не даст вам чего-то большего». Хотя строчками выше вы перечисляете достижения комьюнити вокруг языка (ага, HipHop, оно же HHVM, да и php-fpm до кучи...). Даже такие «кальки», как phing и composer скорее добавляют к экосистеме (задачи и проблемы надо решать), чем отнимают.
Я думаю, что правильно понимаю вашу мысль — PHP из тех языков, которые созданы для зарабатывания денег сейчас.
У него низкий порог вхождения, он массовый, он то, что упростило разработку веба до формата книжки для чайника.
Более того, я считаю, что это один из языков сильно толкнувших распространение веба, как явления (ASP хотел кусающуюся лицензию).
Плюс, имхо, PHP одно из бюджетных средств для проверки любой, сколько угодно сумасшедший идеи.
Facebook и Wikipedia выросли на дешевом и «бюджетном» языке, как и различные CMS, CRM и e-commerce.
Сильно сомневаюсь, что для постройки прототипа нужно использовать самый «навороченный» язык, 10500 боевых серверов и тыщу-три спецов. Вон, у Google c Wave не вышло. Это все равно что просить инженеров формулы-1 сделать самокат. Сделать-то сделают, но вряд ли у среднестатистического человека будет дом, машина и яхта, чтобы оплатить счет.
Естественно, что у языка своя ниша и граница. Это ооочень хорошо чувствуется в период роста и жизни проекта.
Дешевизна разработки обходится дорогим развитием и преодолением узких мест, которых в других языках нет.
Поощрять изучение программирования должен сам программист — это в его компетенции изучать различные парадигмы, пробовать реализации и языки.
Ну, до тех пор, пока в синтаксис языка не станут внедрять рекламу…
Тридцать-сорок лет назад, были другие «массовые языки» (привет, cobol), которые упрощали задачи программиста.
Чтоб у вас поменьше «рвало» знайте — *.php когда-нибудь отправится на свалку, что случилось уже со многими языками.
Впрочем, профессию «программист» ждет та же участь. Нельзя же назвать «программированием» голосовое управление бытовой техникой или машиной?
Я люблю сравнивать софтверные продукты с кораблями. Ну так, по-наркомански.
С развитие виртуализации и клауда работа с такими стендами действительно не большая проблема (я про browserstack, как частный случай).
Но это по силу средним/большим проектам и решается не на уровне выше разработчика (но в праве выставить условия). Не каждая компания готова заплатить за админов, СМов, виртуалки и проч. дребедень.
На этом стоп-машина, речь в статье была про другое.
И да и нет.
Найденые баги хорошо и полезно покрывать тестами. Но сами тесты требуют код с хорошей тестируемостью.
Покрыть тестами двух страничную функцию со множеством API вызовов? Если идти в «лоб», то на выходе будет бардачный код с хрупкими, ломкими и нестабильными тестами. Которые еще будут требовать специфичные стенды для запуска. В итоге их отключат сначала разработчики, а потом и при сборке. Я молчу о том, что уйма времени уйдет на написание теста. Тесты, CI это багаж который может и помочь и за собой утянуть.
Нужно сделать много телодвижений, чтобы все это зажило нормально:
— любой высокоуровневый тест (интеграционный, ui/api, компонентный)
— аккуратный рефакторинг (лучше-автоматический), чтобы разделить и перегруппировать код при этом НЕ похерив результаты оптимизаций (любая низкоуровневая оптимизация/инструкции компилятору запутывают оригинальную логику)
— расширение базы тестов (юнит-тесты, интеграционные) для критичного функционала
— глубокий рефакторинг
— тесты для частных случаев, баги и пр. — специальные тесты
— игра с дизайном (модули, компоненты)
— игра с архитектурой (замена компонент, сервисов)
Представляете сколько времени это займет?
Да, бизнес может не захотеть платить такую цену.
Поэтому что платиться за фикс бага, а не на «нормальное» решение. Отсюда и привет двухстраничным функциям.
Ваш дали хороший совет, но чертовски легкомысленно.
Подождите-подождите. SOLR надстройка над lucene. Lucene ориентирован на хранение поисковых индексов, т.е. это более узкое решение. Давайте тогда еще-больше специализированных решений добавим, типо файловых систем — это тоже «nosql».
А вот Jena, имхо, можно в список добавить. Впрочем чур меня чур, семантические хранилища тройки или четверки хранят — ими можно граф описать. В принципе sparql — язык поиска пересечений по сем. графу.
Скажите, вот зачем вы это сделали?
Ведь после кадров выше невольно начинаешь сравнивать работы и ваша в пух и прах проигрывает.
Я не вижу тут ничего, кроме чб снимка на длинной выдержке. Еще больше раздражает отсутствие идеи. Что вы хотели показать? Приведений? Движение жизни у приведений? Флуктуации пикселей из худ салона?
Зачем справа вот этот заваленый черный гроб?
Если вы свою технологию хотели показать, то отдельный пост с технологией и примерами самый лучший выбор. Я первый его прочитаю.
Есть аутсорсинговые компании, которые продают мозги, как сервис (Epam, Luxoft, тыщи их). Зачастую они не владеют продуктами, у них много проектов с другими большими и не очень компаниями (банками, гос-вом и т.д.). Да, иногда они ведут внутренние разработки — которые выливаются в продукт, что и делает их от части продуктовыми. Но подавляющая часть прибыли — это аутсорс.
Есть компании, которые продают свой продукт по SaaS модели. Такая модель саму компанию сервисной не делает, т.к. она работает и развивает одно решение. Это решение дает основную прибыль.
С точки зрения беготня и в первом и во втором случае присутствует.
В первом бизнес парится при оценке ресурса/сделанной работе. Во втором бегает за клиентом, чтобы понять его желания и решать проблемы.
Нирваны, «продать и стричь» не вижу ни в первом, ни во втором случае…
Где же такое обитает? И что у вас сервисная компания?
не рушьте мой мир — это абсолютно разные профили, и как следствие, разные требования к психологии программиста.
Я работаю в сервисной компании — там лишнего рубля никто не даст, если за это не платит клиент. У многих должен быть определенного градуса пофигизм (как и у любого сервиса).
Это скамейки запасных, это разные проекты, это то, во что трудно влюбиться во второй, третий и четвертый раз.
Моя компания пыталась стать продуктовой — не вышло.
Продуктовая компания — это тот же проект (да, иногда с под-проектами), это максимум несколько сфер или областей (мне больше нравится домены). Это упертость и некоторая здоровая консервативность, это болезнь «за продукт». Да, это все выходит боком, когда продукт трещит под тех. долгом, а заплатить за него компания не может.
Маразм, неадекват от профиля компании не зависит. Тонут как те, так и другие.
… в генеральные директора чаще попадают с места финансового директора, но почти никогда с места директора ИТ ...
Для банка — это самое естественное карьерное развитие. Все таки, управлять финансовым институтом должен человек с финансовым же образованием. Вы же не поймете, если у руля MS или Гугла встанет крутой дядька, бывший финансист, который в технологиях ни алё.
CIO из банка переходят потом как VP или другие executive (помогите с переводом) в продуктовые или аутсорсинговые IT компании — им там и тепло, и уютно и, главное, сухо.
IТ, это обслуга
Не соглашусь. По крайне мере, не на 100%. Для меня IT и бизнес — две противоположности.
IT хочет много денег и времени для идеального кода, продукта, сервиса.
Бизнес хочет «сейчас» и «дешево», ему насрать (да, насрать) на идеал. И как старший брат, он прав. Крупный банк может пережить целые эпохи (Wells Fargo), а вы все о чем-то мелком… новые продукты, языки, эффективность…
Если побеждает IT — бизнес скатывается в убыток (да, есть исключения).
Если побеждает бизнес, то IT обслуга, а то и рабы — ни люди, а body.
Мой совет — если ты разработчик и, тем более, лид — борись за продукт. Отстаивай его чистоту, бейся за качество.
Спойлер
да, это тяжело — справляются не все. И без фанатизма — фанатиков никто не любит. Но если его умело спрятать, никто и не поймет. Главное, если решите развалить чужой бизнес, то хотя бы знайте «зачем». =)
Если ты заказчик, и если вы знаете про Win-Win…
Спойлер
… то мне вам сказать больше нечего =) Вы лучше меня знаете что и как делать.
А как велось (и велось ли вообще) управление требованиями?
Я могу сильно ошибиться, но BPM, как и ClearCase, и тем более Issue tracker не самые подходящие инструменты для отслеживания поступающих требований.
Тем более в условиях, когда нет владельца продукта и очередей поступающих задач более двух. Плюс еще очередь из срочных задач, багов и т.п.
Управление требованиями сильно помогает при обучении новых сотрудников — про on-boarding, кстати, ни слова. Текучка на большом проекте совсем другая, чем на маленьком.
Менялся ли процесс в зависимости от команды?
Например, у Java команды куда больше телодвижений нужно совершить, чтобы выпустить версию, в то время как у php команды может не хватать общепризнанных решений (как, например, Composer — мы адаптировали ant/maven для той же цели).
А что было у программиста?
Т.е. был ли какой-либо стандарт на окружение у разработчика, лида или вхождение в проект начиналось с настройки окружения?
Можно еще пару слов об атмосфере на проекте?
На нашем проекте «удаленность» ощущалась весьма остро, вплоть до недоверия, непонимания и взаимного переписывания кода. Мы были маленькими и о тестах либо не слышали, либо откладывали. Решение было очень логичным — в этот самый период вторую (или первую :) команду привезли на месяц или полтора к нам. Все проблемы с коммуникацией были решены, атмосфера улучшилась. Да, код идеальным не стал и его работоспособность от выпитого в баре не улучшалась, но стабильность начала повышаться и баги стали уменьшаться.
Идею понимаю, но я скептик:
— сторонний разработчик разве что может угадать с приложением, если он, конечно, не спец в пожарном деле или есть хорошие друзья.
— под описание попадает куча существующих кейсов: мониторинг, оповещение, предупреждение
— валидность, качество и постоянство данных
Но это все детали, я буду только рад системам/решениям способным решать такие важные задачи.
«люди от бизнеса» питаются только сильно упрощенными отбросами научной мысли. Желательно в виде продукта, которого нет на полках, который им по карману и который сделает профит за следующие пару кварталов сам по себе.
Те немногие, которые излучают интерес, сами организуют исследования и R&D в области Semantic Web/Linked Data.
я понимаю, что это офтопик, чувства вслух и все давно знают эту истину.
Просто у самого есть также.
Больше четырех лет работы в этой области заморожено на неопределенный срок.
Поэтому на любые умные графики можно сразу забить, если идет охота на инвестора.
Юзкейс должен быть проще кнопки Like (а десять лет назад написал бы — проще пареной репы).
Подождите, сем. вики не позволяет делать автоматическое аннотирование контента, о чем собственно спрашивает sainnr.
Все, что идет из коробки всего-лишь возможность установить значение проперти в вики тексте через UI.
Это все равно ручной, адский труд — текст надо читать и осмыслять.
Смотреть нужно в сторону анализатора текста, который по указанной онтологии/онтологиям проставит или предложит проставить те или иные обнаруженные свойства и значения. Помню несколько демок (пример) в инете, с разной степенью успешности.
Вся область слишком молодая, естественно, что она требует больше усилий для вхождения (без отсылок к Фрейду, пожалуйста).
Но подождите пару, максимум 5 лет и у вас будут под рукой необходимый набор инструментов, чтобы "просто получить данные.".
Нетривиальный способ не такой уж сложный, это цена ETL-процесса, который не должен пугать больших взрослых дядек.
Ну есть у нас вики текст, ну взяли библиотеки Protégé, ну накрутили поверх Gate для лексического анализа и text-mining-а, ну сложили все в RDF/Triple store налюбойвкус…
Накладно? Да, как и любой ETL процесс.
Что до «просто использовать», те же модные NoSQL местами не что иное, как графовые СУБД, некоторые даже имеют нужные фичи из коробки.
На практике придется много возиться с конкретной реализацией — область и инструменты слишком молоды по сравнению с теми же решениями на реляционных БД.
И, замечу, делать что-то подобное LinkedData на базе только существующих решений есть костыль и репродукция велосипеда.
Только вперед!
Только к звездам через минные поля!
мы не привыкли придумывать юзкейсы, видя перед собой только данные
Я не понимаю такой подход. Юзкейсы пишутся как описание решения какой-либо проблемы. Да, их в том числе используют для описания какой-либо идеи — именно это мне не нравится.
На самом деле искать пути применения данных очень просто.
Алгоритм:
— взять 1 существующий кейс
— выделить все затронутые домены
— описать «человеческую» сторону кейса
— определить контекст выполнения кейса
— отыскать подходящих провайдеров с данными
— mix & match — на этом этапе уже появится идея кейс
— готовим POC
— ???
— profit
На мой взгляд проблема не в подходе, а в зрелости рынка.
Имхо супер-дупер-умный софт нахер не сдался рядовому потребителю или частному бизнесу. Его совершенно другие проблемы волнуют — как выжить, например.
Разработка приложений для Big/Linked/SemanticData в данный момент стоит на порядок больше, а ожидаемый профит гораздо меньше.
Хочу добавить сайт-коллекцию APIs, end-points и других интерфейсов для доступа к данным: datahub.io
Например, тут есть данные от РИА Новости, a так же упомянутые Freebase и dbpedia. Wikidata нету.
В первом случае можно сказать, что вас «тестировали» на проф пригодность. Время специалиста ценно и тратить его на каждого новичка рассказывая и обучая не выгодно финансово. Особенно, если речь будет идти об азах и общих решениях по области.
Во втором случае, выгодно провести несколько-часовое (дни, недели) «погружение» в архитектуру, дизайн и решения конкретного проекта. То, что новичок не сможет «схватить» без базы (а она нарабатывается годами).
Тут несколько напоминает японщину:
I. толпа новичков смотрит и повторяет за мастером
II. мастер работает с небольшой группой учеников
III. два-три специалиста продолжают дело мастера
Ну или по-русски:
Ни один царь не пошлет юнца девичьи покои охранять.
Я надеюсь, что наступит тут день, когда вся кухня из SAP-вых решений, хранилищ, BPM и ETL процессов с системами документооборота и интеграции с CRM, ERP, BI и прочий мутью будет будет обходится без участия человека.
Имхо кодировать и костылить в таких «интегрированных» и «автоматизированных» системах нужно на порядок больше.
скучно и серо, с лихвой компенсируется ЗП — как контракт с дьяволом.
Для бизнеса нет понятия «нормальный язык». Ребята, вкладывающие деньги, не мыслят категориями динамичная или строгая типизация или там много синтаксического сахара или тут соль добавили. Есть ресурс, есть задача, нужно решение для получения какого-либо профита. Программистов нанимают для решения задачи. В среднем на зп одного среднего джависта или сишника/шарпера можно нанять полтора-два PHP разработчика. Или разработчика и фронт-енда, что уже маленькая команда из двух разнопрофильных спецов. Это уже реальный шанс сделать что-то, проверить и получить опыт/первый профит.
Я молчу уже о стоимости «расходников», типа хостинга и проч. И да проекты разные (мы только про веб), достаточно купить хостинг и тремя кликами поставить форумы, блоги, магазин, соц. сеть, вики… Сходите сюда веб-хостинги, не поленитесь — тыкните на compare. Там есть категории софта для установки (Instant Blogs,Instant Portals, **) — нажмите (?), появиться окно с конкретикой — что можно поставить. Посчитайте и сравните, что PHP, а что нет.
При цене в 4 бакса в месяц, у вас будет работающий сайт. И о да, вам даже программист не нужен. Если хочется, предлагаю сравнить со стоимостью решения такой же задачи, но с другим языком…
Про сообщество не понял. Чем оно плохо? Какое сообщество вы имеете в виду (ru, en, школьников, ZCE, guru)?
Если судить по эмоциональной наполнению вашего первого комментария, оно у вас очень негативное.
Незнаю, может мне кажется =) Но похапэфобия то ли рвет вас изнутри, то ли отравила до тошноты, то ли зарядила нехилый баттхёрт.
Я не хочу вас лично обидеть, да и вряд ли это возможно в интернете, моя идея такая (про php):
«easy to learn, hard to master»
У вас PHP — это такой гном, который «не поощряет программирование, его изучение». И самое печальное это то, как вы видите людей, которые его используют — «сообщество PHP никогда не даст вам чего-то большего». Хотя строчками выше вы перечисляете достижения комьюнити вокруг языка (ага, HipHop, оно же HHVM, да и php-fpm до кучи...). Даже такие «кальки», как phing и composer скорее добавляют к экосистеме (задачи и проблемы надо решать), чем отнимают.
Я думаю, что правильно понимаю вашу мысль — PHP из тех языков, которые созданы для зарабатывания денег сейчас.
У него низкий порог вхождения, он массовый, он то, что упростило разработку веба до формата книжки для чайника.
Более того, я считаю, что это один из языков сильно толкнувших распространение веба, как явления (ASP хотел кусающуюся лицензию).
Плюс, имхо, PHP одно из бюджетных средств для проверки любой, сколько угодно сумасшедший идеи.
Facebook и Wikipedia выросли на дешевом и «бюджетном» языке, как и различные CMS, CRM и e-commerce.
Сильно сомневаюсь, что для постройки прототипа нужно использовать самый «навороченный» язык, 10500 боевых серверов и тыщу-три спецов. Вон, у Google c Wave не вышло. Это все равно что просить инженеров формулы-1 сделать самокат. Сделать-то сделают, но вряд ли у среднестатистического человека будет дом, машина и яхта, чтобы оплатить счет.
Естественно, что у языка своя ниша и граница. Это ооочень хорошо чувствуется в период роста и жизни проекта.
Дешевизна разработки обходится дорогим развитием и преодолением узких мест, которых в других языках нет.
Поощрять изучение программирования должен сам программист — это в его компетенции изучать различные парадигмы, пробовать реализации и языки.
Ну, до тех пор, пока в синтаксис языка не станут внедрять рекламу…
Тридцать-сорок лет назад, были другие «массовые языки» (привет, cobol), которые упрощали задачи программиста.
Чтоб у вас поменьше «рвало» знайте — *.php когда-нибудь отправится на свалку, что случилось уже со многими языками.
Впрочем, профессию «программист» ждет та же участь. Нельзя же назвать «программированием» голосовое управление бытовой техникой или машиной?
С развитие виртуализации и клауда работа с такими стендами действительно не большая проблема (я про browserstack, как частный случай).
Но это по силу средним/большим проектам и решается не на уровне выше разработчика (но в праве выставить условия). Не каждая компания готова заплатить за админов, СМов, виртуалки и проч. дребедень.
На этом стоп-машина, речь в статье была про другое.
Найденые баги хорошо и полезно покрывать тестами. Но сами тесты требуют код с хорошей тестируемостью.
Покрыть тестами двух страничную функцию со множеством API вызовов? Если идти в «лоб», то на выходе будет бардачный код с хрупкими, ломкими и нестабильными тестами. Которые еще будут требовать специфичные стенды для запуска. В итоге их отключат сначала разработчики, а потом и при сборке. Я молчу о том, что уйма времени уйдет на написание теста. Тесты, CI это багаж который может и помочь и за собой утянуть.
Нужно сделать много телодвижений, чтобы все это зажило нормально:
— любой высокоуровневый тест (интеграционный, ui/api, компонентный)
— аккуратный рефакторинг (лучше-автоматический), чтобы разделить и перегруппировать код при этом НЕ похерив результаты оптимизаций (любая низкоуровневая оптимизация/инструкции компилятору запутывают оригинальную логику)
— расширение базы тестов (юнит-тесты, интеграционные) для критичного функционала
— глубокий рефакторинг
— тесты для частных случаев, баги и пр. — специальные тесты
— игра с дизайном (модули, компоненты)
— игра с архитектурой (замена компонент, сервисов)
Представляете сколько времени это займет?
Да, бизнес может не захотеть платить такую цену.
Поэтому что платиться за фикс бага, а не на «нормальное» решение. Отсюда и привет двухстраничным функциям.
Ваш дали хороший совет, но чертовски легкомысленно.
А вот Jena, имхо, можно в список добавить. Впрочем чур меня чур, семантические хранилища тройки или четверки хранят — ими можно граф описать. В принципе sparql — язык поиска пересечений по сем. графу.
Ведь после кадров выше невольно начинаешь сравнивать работы и ваша в пух и прах проигрывает.
Я не вижу тут ничего, кроме чб снимка на длинной выдержке. Еще больше раздражает отсутствие идеи. Что вы хотели показать? Приведений? Движение жизни у приведений? Флуктуации пикселей из худ салона?
Зачем справа вот этот заваленый черный гроб?
Если вы свою технологию хотели показать, то отдельный пост с технологией и примерами самый лучший выбор. Я первый его прочитаю.
Есть аутсорсинговые компании, которые продают мозги, как сервис (Epam, Luxoft, тыщи их). Зачастую они не владеют продуктами, у них много проектов с другими большими и не очень компаниями (банками, гос-вом и т.д.). Да, иногда они ведут внутренние разработки — которые выливаются в продукт, что и делает их от части продуктовыми. Но подавляющая часть прибыли — это аутсорс.
Есть компании, которые продают свой продукт по SaaS модели. Такая модель саму компанию сервисной не делает, т.к. она работает и развивает одно решение. Это решение дает основную прибыль.
С точки зрения беготня и в первом и во втором случае присутствует.
В первом бизнес парится при оценке ресурса/сделанной работе. Во втором бегает за клиентом, чтобы понять его желания и решать проблемы.
Нирваны, «продать и стричь» не вижу ни в первом, ни во втором случае…
Где же такое обитает? И что у вас сервисная компания?
Я работаю в сервисной компании — там лишнего рубля никто не даст, если за это не платит клиент. У многих должен быть определенного градуса пофигизм (как и у любого сервиса).
Это скамейки запасных, это разные проекты, это то, во что трудно влюбиться во второй, третий и четвертый раз.
Моя компания пыталась стать продуктовой — не вышло.
Продуктовая компания — это тот же проект (да, иногда с под-проектами), это максимум несколько сфер или областей (мне больше нравится домены). Это упертость и некоторая здоровая консервативность, это болезнь «за продукт». Да, это все выходит боком, когда продукт трещит под тех. долгом, а заплатить за него компания не может.
Маразм, неадекват от профиля компании не зависит. Тонут как те, так и другие.
Для банка — это самое естественное карьерное развитие. Все таки, управлять финансовым институтом должен человек с финансовым же образованием. Вы же не поймете, если у руля MS или Гугла встанет крутой дядька, бывший финансист, который в технологиях ни алё.
CIO из банка переходят потом как VP или другие executive (помогите с переводом) в продуктовые или аутсорсинговые IT компании — им там и тепло, и уютно и, главное, сухо.
Не соглашусь. По крайне мере, не на 100%. Для меня IT и бизнес — две противоположности.
IT хочет много денег и времени для идеального кода, продукта, сервиса.
Бизнес хочет «сейчас» и «дешево», ему насрать (да, насрать) на идеал. И как старший брат, он прав. Крупный банк может пережить целые эпохи (Wells Fargo), а вы все о чем-то мелком… новые продукты, языки, эффективность…
Если побеждает IT — бизнес скатывается в убыток (да, есть исключения).
Если побеждает бизнес, то IT обслуга, а то и рабы — ни люди, а body.
Мой совет — если ты разработчик и, тем более, лид — борись за продукт. Отстаивай его чистоту, бейся за качество.
Если ты заказчик, и если вы знаете про Win-Win…
Я могу сильно ошибиться, но BPM, как и ClearCase, и тем более Issue tracker не самые подходящие инструменты для отслеживания поступающих требований.
Тем более в условиях, когда нет владельца продукта и очередей поступающих задач более двух. Плюс еще очередь из срочных задач, багов и т.п.
Управление требованиями сильно помогает при обучении новых сотрудников — про on-boarding, кстати, ни слова. Текучка на большом проекте совсем другая, чем на маленьком.
Менялся ли процесс в зависимости от команды?
Например, у Java команды куда больше телодвижений нужно совершить, чтобы выпустить версию, в то время как у php команды может не хватать общепризнанных решений (как, например, Composer — мы адаптировали ant/maven для той же цели).
А что было у программиста?
Т.е. был ли какой-либо стандарт на окружение у разработчика, лида или вхождение в проект начиналось с настройки окружения?
Можно еще пару слов об атмосфере на проекте?
На нашем проекте «удаленность» ощущалась весьма остро, вплоть до недоверия, непонимания и взаимного переписывания кода. Мы были маленькими и о тестах либо не слышали, либо откладывали. Решение было очень логичным — в этот самый период вторую (или первую :) команду привезли на месяц или полтора к нам. Все проблемы с коммуникацией были решены, атмосфера улучшилась. Да, код идеальным не стал и его работоспособность от выпитого в баре не улучшалась, но стабильность начала повышаться и баги стали уменьшаться.
— сторонний разработчик разве что может угадать с приложением, если он, конечно, не спец в пожарном деле или есть хорошие друзья.
— под описание попадает куча существующих кейсов: мониторинг, оповещение, предупреждение
— валидность, качество и постоянство данных
Но это все детали, я буду только рад системам/решениям способным решать такие важные задачи.
Те немногие, которые излучают интерес, сами организуют исследования и R&D в области Semantic Web/Linked Data.
я понимаю, что это офтопик, чувства вслух и все давно знают эту истину.
Просто у самого есть также.
Больше четырех лет работы в этой области заморожено на неопределенный срок.
Поэтому на любые умные графики можно сразу забить, если идет охота на инвестора.
Юзкейс должен быть проще кнопки Like (а десять лет назад написал бы — проще пареной репы).
Все, что идет из коробки всего-лишь возможность установить значение проперти в вики тексте через UI.
Это все равно ручной, адский труд — текст надо читать и осмыслять.
Смотреть нужно в сторону анализатора текста, который по указанной онтологии/онтологиям проставит или предложит проставить те или иные обнаруженные свойства и значения. Помню несколько демок (пример) в инете, с разной степенью успешности.
Но подождите пару, максимум 5 лет и у вас будут под рукой необходимый набор инструментов, чтобы "просто получить данные.".
Нетривиальный способ не такой уж сложный, это цена ETL-процесса, который не должен пугать больших взрослых дядек.
Ну есть у нас вики текст, ну взяли библиотеки Protégé, ну накрутили поверх Gate для лексического анализа и text-mining-а, ну сложили все в RDF/Triple store на любой вкус…
Накладно? Да, как и любой ETL процесс.
Что до «просто использовать», те же модные NoSQL местами не что иное, как графовые СУБД, некоторые даже имеют нужные фичи из коробки.
На практике придется много возиться с конкретной реализацией — область и инструменты слишком молоды по сравнению с теми же решениями на реляционных БД.
И, замечу, делать что-то подобное LinkedData на базе только существующих решений есть костыль и репродукция велосипеда.
Только вперед!
Только к звездам через минные поля!
Я не понимаю такой подход. Юзкейсы пишутся как описание решения какой-либо проблемы. Да, их в том числе используют для описания какой-либо идеи — именно это мне не нравится.
На самом деле искать пути применения данных очень просто.
Алгоритм:
— взять 1 существующий кейс
— выделить все затронутые домены
— описать «человеческую» сторону кейса
— определить контекст выполнения кейса
— отыскать подходящих провайдеров с данными
— mix & match — на этом этапе уже появится идея кейс
— готовим POC
— ???
— profit
На мой взгляд проблема не в подходе, а в зрелости рынка.
Имхо супер-дупер-умный софт нахер не сдался рядовому потребителю или частному бизнесу. Его совершенно другие проблемы волнуют — как выжить, например.
Разработка приложений для Big/Linked/SemanticData в данный момент стоит на порядок больше, а ожидаемый профит гораздо меньше.
Например, тут есть данные от РИА Новости, a так же упомянутые Freebase и dbpedia. Wikidata нету.