Антон, благодарю за конструктивный ответ.
Конечно, проблемы есть. И поэтому система эволюционирует. Однако общая схема и концепция остается неизменной, а основной ее базис — повышение удовлетворенности заказчика, тем более.
В любом случае возникающие проблемы — это отклонения от стандартного процесса и их приходится решать руками, придумывать для них упреждающие воздействия (собственно что надо поменять в схеме) и после этого ждать следующего отклонения.
Про аналитиков я планировал сделать аналогичную статью, однако передумал. Но в целом вы угадали задачу аналитика. Базис тот же — чтобы клиент был доволен. Свобода действий аналитика, конечно, значительно больше — он может сам предлагать изменения в процессах, может помогать руководителям отдела сформулировать задачу и так далее. Главное — зарабатывать бабки клиенту. Ну и нам малую толику.
Теперь к вопросам.
1. В разных ситуациях по-разному. Если вас интересуют детали, то в группе, занимающейся разработкой платформы документированием занимаются совместно разработчики (собственно тех частей, где документируются детали API) и технический писатель (в основном — поддержка документации пользователя и изменений экранных форм).
На проектах разработчики не занимаются документированием (если не считать комментирования кода и объектов метаданных). Документированием процессов, как правило, занимаются аналитики или специальные люди со стороны клиента (50/50). Разработчик в обсуждение требований обычно не привлекается, но разработчик у нас сам себе архитектор. Так что разработчик, естесвенно, описывает кратко результат работы, но назвать это документированием нельзя.
2. Мы небольшая компания, но разработчиков больше 20-30. Однако, схема начала работать когда у нас было 5(пять) разработчиков. Простые командные технологии начали буксовать уже тогда. Уменьшать фонд з/п есть смысл, если доход с сотрудника не превышает расходов от его содержания. Аналогично, и в отношении нас и наших клиентов. Однако, если доход значительно превышает расходы уменьшать его нет смысла — это инвестиции которые приносят деньги. Поясню на примере. За счет внедрения мотивировочной схемы на складе компания смогла увеличить оборот на 40% процентов за год не набирая новых людей. План по набору был примерно на 20-30%. Схему сделали за примерно, пятьсот тысяч рублей (для клиента). 20-30% ФОТ склада — 1.5 миллионов рублей. Неразумная жадность как известно, ведет к потерям.
3. Потому, что заказчик платит нам деньги, а не разработчик. Если Вы имеете ввиду что попадется неадекватный заказчик, постоянно меняющий требования, то виноват тут будет скорее аналитик, за что и поплатится. В любом случае при проявлениях неадекватного поведения сотрудниками клиента, они лишь тратят деньги собственника компании. Если всех все устраивает — нет проблем, будем жаловаться, но терпеть.
4. С момента написания статьи мы добавили еще 2. Пока для равномерной загрузки достаточно. В очень редких случаях может потребоваться ручное вмешательство. Плодить сущности с оценкой часов нам не дает бритва Оккама и зравый смысл :)
5. Да, все верно. Однако, надо понимать, что главная оценка — от заказчика. И если в он хотел попробовать 10 разных шрифтов и 50 оттенков серого для фона формы, то план может сильно отличаться от факта. Однако клиент доволен, значит разработчик молодец.
6. Специализация есть, но не такая узкопрофильная. По сути — мобильные приложений, веб, и desktop. Необходимость разбираться в чужом незнакомом коде имеет полезные последствия — улучшается читаемость собственного кода и его наполненность комментариями.
7. Во-первых срочные задачи это аврал. Он не может быть одновременно у нескольких клиентов и продолжительным. Иначе что-то надо менять в консерватории. Так что тут ответ простой — нет, такой проблемы нет.
8. Бывают, но до сих пор удавалось преодолевать блокировки. Протитипчики, сгенерированные метаданные. Пока удавалось что-то придумать.
Если мем про месье знает толк в извращениях Вам не понятен, могу только посочуствовать Вашему чувству юмора.
Про доступ — фраза означает, что ни с какого клиентского приложения или устройства невозможно выполнить произвольные SQL запросы к базе, кроме того база просто недоступна по сети с любого клиентского места или устройства.
Передача произвольных запросов в базу — огромная дырка в безопасности.
У нас есть крупная ERP система, но в ней легко и быстро делать отчеты. И в ней НЕВОЗМОЖНО получить доступ на чтение из базы с клиентского места.
Так что мы немного иным образом решили задачу. И да, выгрузить в Excel можно.
Для MySQL есть родной как раз.
А вот для постгреса — насколько я знаю нет. Написать можно все что угодно конечно, хоть процедуру на C и ее в триггере вызывать. Сложность миграции при этом правда не снижается.
Совсем точно стоило бы говорить о ассимптотическом количестве операций для машины Тюринга.
О(F) и о(F) проходят в первом семестре матанализа.
Однако, на машине Тьюринга адресования нет, а чтение «заданной» ячейки выполняется путем последовательного перемещения.
Если два алгоритма ассимптотически эквивалентны по сложности, то отличаются они только компоненты низших порядков. Т.е. для двух алгоритмов O(n) — в константу раз.
1. Предлагаете только название статей читать? Мне кажется суть в статье, а не в названии.
2. Может быть. С чего вы решили, что это повысит его мотивированность больше, чем посещение конференции?
3. На моей практике ходят группами. Да и при чем тут по одному от фирмы или нет.
Вы просто неверно оцениваете.
Программерские конференции нужны:
1. Для самопиара докладчиков.
2. Для работодателей — как средство мотивации сотрудников.
Оба этих фактора действительно важны и среди нет ничего про узнавание информации.
Ее конечно можно (и часто удобнее) получить из других источников. В приницпе — тимбилдинг с профессиональным уклоном.
Не совсем хорошо это мягко сказано. На самом деле без сильной боли можно мигрировать только в простых случаях, когда субд как записная книжка используется (кстати, а Оракл то вам зачем нужен был тогда?).
Кроме проблем конвертации кода (не, разобрать PLSQL, построить дерево, трансформировать и кодогенерировать я и сам могу). есть проблема совместимости пакетов, работы с датами, работы с лобами. Для трехзвенок приходится в отсутствии такого понятия как context в PostgreSQL весьма изощрятся. Временные таблицы в оракле временные данные, в постгресе — существуют во время сессии только.
Так что конвертнуть данные это только первый шаг по дороге миграции.
А в чем преимущество в переносимости тогда перед DevArt? Для Managed ODP надо таскать одну библиотеку, котороую просто можно включить в дистрибутив (в некоторых случаях — две или три если с разной архитектурой:
Oracle.DataAccess.dll
Oracle.ManagedDataAccess.dll
Oracle.ManagedDataAccessDTC.dll
Managed ODP.NET пока не поддерживается на Mono. По скорости тесты не гоняли. У DevArt есть проблемы совместимости (уже плохо помню, но кажется с блобами какие-то косяки были) и распределенными транзакциями.
Мы думали использовать его, по полезли баги и отказались. В случае с ораклом производительность провайдера скорее последнее что будет тормозить :)
Баги висят в металинке пока тишина по ним.
Конечно, проблемы есть. И поэтому система эволюционирует. Однако общая схема и концепция остается неизменной, а основной ее базис — повышение удовлетворенности заказчика, тем более.
В любом случае возникающие проблемы — это отклонения от стандартного процесса и их приходится решать руками, придумывать для них упреждающие воздействия (собственно что надо поменять в схеме) и после этого ждать следующего отклонения.
Про аналитиков я планировал сделать аналогичную статью, однако передумал. Но в целом вы угадали задачу аналитика. Базис тот же — чтобы клиент был доволен. Свобода действий аналитика, конечно, значительно больше — он может сам предлагать изменения в процессах, может помогать руководителям отдела сформулировать задачу и так далее. Главное — зарабатывать бабки клиенту. Ну и нам малую толику.
Теперь к вопросам.
1. В разных ситуациях по-разному. Если вас интересуют детали, то в группе, занимающейся разработкой платформы документированием занимаются совместно разработчики (собственно тех частей, где документируются детали API) и технический писатель (в основном — поддержка документации пользователя и изменений экранных форм).
На проектах разработчики не занимаются документированием (если не считать комментирования кода и объектов метаданных). Документированием процессов, как правило, занимаются аналитики или специальные люди со стороны клиента (50/50). Разработчик в обсуждение требований обычно не привлекается, но разработчик у нас сам себе архитектор. Так что разработчик, естесвенно, описывает кратко результат работы, но назвать это документированием нельзя.
2. Мы небольшая компания, но разработчиков больше 20-30. Однако, схема начала работать когда у нас было 5(пять) разработчиков. Простые командные технологии начали буксовать уже тогда. Уменьшать фонд з/п есть смысл, если доход с сотрудника не превышает расходов от его содержания. Аналогично, и в отношении нас и наших клиентов. Однако, если доход значительно превышает расходы уменьшать его нет смысла — это инвестиции которые приносят деньги. Поясню на примере. За счет внедрения мотивировочной схемы на складе компания смогла увеличить оборот на 40% процентов за год не набирая новых людей. План по набору был примерно на 20-30%. Схему сделали за примерно, пятьсот тысяч рублей (для клиента). 20-30% ФОТ склада — 1.5 миллионов рублей. Неразумная жадность как известно, ведет к потерям.
3. Потому, что заказчик платит нам деньги, а не разработчик. Если Вы имеете ввиду что попадется неадекватный заказчик, постоянно меняющий требования, то виноват тут будет скорее аналитик, за что и поплатится. В любом случае при проявлениях неадекватного поведения сотрудниками клиента, они лишь тратят деньги собственника компании. Если всех все устраивает — нет проблем, будем жаловаться, но терпеть.
4. С момента написания статьи мы добавили еще 2. Пока для равномерной загрузки достаточно. В очень редких случаях может потребоваться ручное вмешательство. Плодить сущности с оценкой часов нам не дает бритва Оккама и зравый смысл :)
5. Да, все верно. Однако, надо понимать, что главная оценка — от заказчика. И если в он хотел попробовать 10 разных шрифтов и 50 оттенков серого для фона формы, то план может сильно отличаться от факта. Однако клиент доволен, значит разработчик молодец.
6. Специализация есть, но не такая узкопрофильная. По сути — мобильные приложений, веб, и desktop. Необходимость разбираться в чужом незнакомом коде имеет полезные последствия — улучшается читаемость собственного кода и его наполненность комментариями.
7. Во-первых срочные задачи это аврал. Он не может быть одновременно у нескольких клиентов и продолжительным. Иначе что-то надо менять в консерватории. Так что тут ответ простой — нет, такой проблемы нет.
8. Бывают, но до сих пор удавалось преодолевать блокировки. Протитипчики, сгенерированные метаданные. Пока удавалось что-то придумать.
Про доступ — фраза означает, что ни с какого клиентского приложения или устройства невозможно выполнить произвольные SQL запросы к базе, кроме того база просто недоступна по сети с любого клиентского места или устройства.
Передача произвольных запросов в базу — огромная дырка в безопасности.
Так что мы немного иным образом решили задачу. И да, выгрузить в Excel можно.
habrahabr.ru/company/ultima/blog/256527
А вот для постгреса — насколько я знаю нет. Написать можно все что угодно конечно, хоть процедуру на C и ее в триггере вызывать. Сложность миграции при этом правда не снижается.
О(F) и о(F) проходят в первом семестре матанализа.
Однако, на машине Тьюринга адресования нет, а чтение «заданной» ячейки выполняется путем последовательного перемещения.
Если два алгоритма ассимптотически эквивалентны по сложности, то отличаются они только компоненты низших порядков. Т.е. для двух алгоритмов O(n) — в константу раз.
2. Может быть. С чего вы решили, что это повысит его мотивированность больше, чем посещение конференции?
3. На моей практике ходят группами. Да и при чем тут по одному от фирмы или нет.
Программерские конференции нужны:
1. Для самопиара докладчиков.
2. Для работодателей — как средство мотивации сотрудников.
Оба этих фактора действительно важны и среди нет ничего про узнавание информации.
Ее конечно можно (и часто удобнее) получить из других источников. В приницпе — тимбилдинг с профессиональным уклоном.
Кроме проблем конвертации кода (не, разобрать PLSQL, построить дерево, трансформировать и кодогенерировать я и сам могу). есть проблема совместимости пакетов, работы с датами, работы с лобами. Для трехзвенок приходится в отсутствии такого понятия как context в PostgreSQL весьма изощрятся. Временные таблицы в оракле временные данные, в постгресе — существуют во время сессии только.
Так что конвертнуть данные это только первый шаг по дороге миграции.
Oracle 12c
Oracle.DataAccess.dll
Oracle.ManagedDataAccess.dll
Oracle.ManagedDataAccessDTC.dll
Мы думали использовать его, по полезли баги и отказались. В случае с ораклом производительность провайдера скорее последнее что будет тормозить :)